We've recently seen the release of HiPer Arc releases 4.2.32 and 4.1.22. So now seems to be an appropriate time to take a look at the State of the Hub (with apologies to the U.S. Government and Larry Wall for the name). I'm trying to bring about some structure to these messages that I post to give people a bit more assistance in finding the content that they need/are interested in out of my greater ramblings. I'll start off with some specific issues and questions that I have (essentially like the rest of my messages), and then go into some rather more broad thoughts. First, with release of 4.1.22, 3Com seems to have added some support, or at least control over directed broadcasting. Specifically disable/enable ip directed_bcast_forwarding. The release notes describe it as "When enabled, it allows directed broadcast forwarding from the user." My question is...how does this work? It seems to imply that it magically figures out what's going to be a directed broadcast that the user is sending out and drops it on the floor. I hope this isn't the case, but that it only drops directed broadcasts for directly connected networks. This, of course, because there is no way for the Arc to know if something is going to be a directed broadcast on a remote network. :) Second, SAA (Source Address Assurance) now pays attention to the netmask assigned on a connection to check to make sure that the source address coming in from that connection is indeed supposed to be able to be sourced from there. Previously, this only worked for /32's, but the description in the Release Notes indicates that it now considers the netmask for that. Does it consider a seperate route? I can understand if it wouldn't...that's considerably less trivial, but it would be good functionality to add to this feature. Even further...would be to allow it if the address is reachable (As best the Arc can tell) from that connection...which means that it may not even be in the routing table. You'd have to consult with the OSPF table (well...not in 4.1.x, but in later code), as well as any other routing protocol tables and static routes that aren't preferred. Anyway...just a question that I'm sure will come up before long that will be good to get clarified. :) OK...now on to greater, broader, longer-standing issues. :) 3Com's release numbering (at least on the total control stuff) is still nuts. I'm not sure what would be a good solution...but some releases counting up, and some releases counting down is just completely confusing to customers. Even long-time customers can have difficulty figuring out what the status of a particular release is, and which releases are newer than others. New customers are usually totally baffled, and understandbly so. This really needs to be changed...its been a call that those of us on the list have been making for many years, with no result. The best response (and given the people that are responding, this is understandable) that we get is yet another explanation of the current release numbering system, which isn't what is needed. I applaud Mike Wronski's and Krish's and Chuck Stace's, and the rest of the crew's patience in explaining this time and time again to new folks, and clarifying the status of releases when they're asked about. Really though, 3Com as a whole, would be much better served by letting these people do the job they were hired to do, not looking up (I know, most of you know them well enough that you don't have to look them up) what the status of a specific version of code is. Security releases are still taking *WAY* too long to be made widely available. There have been several security issues that have been made public in the last year or so, ER's have been made available that address these issues. Due to the nature of ER's though, these are not widely available, or publicized, or clearly understood (see the release number issue above ;). HiPerBomb was announced (I believe by Ed Taylor?) in mid-August. I had announced an SNMP security hole before that...both of which affected 4.1.59-6. Though ER's were available, it has taken 5 months for an SR to be made available (in the 4.1.x tree) that includes these fixes. This is an order of magnitude or two off from the amount of time this should be. Security fixes for problems of the magnitude represented by HiPerBomb and the SNMP issues that had been brought should have code widely available that addresses these on the order of a week or so from the time that they are made known to 3Com. I still get reports of people running into problems with NETServers, and 3Com continues to be unresponsive in dealing with thier handling of the practical end of support for this product. At this point, support contracts for the NETServer products should have all expired (unless 3Com continued to sell support for NETServers after they lost access to the source code which would be even worse!), so complaints have less of a basis at this point, but given the poor way that 3Com originally handled the NETServer to HiPer Arc transition, some complaints still are valid. Hopefully, 3Com has at least learned from the NETServer fiasco and won't repeat the same mistake twice, but that's little consolation for people that are still making do with buggy NETServer code as a result of 3Com's abrupt transition from the NETServer platform to the HiPer Arc platform. (cont. due to message size limitations) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.