October 1999 - USR-TC - mailman.xmission.com

Re: (usr-tc) Radius question
by Steve Valiunas 13 Oct '99

13 Oct '99

Aaron & Corneliu, >RFC states as clear as posibile: "For retransmissions where the contents >are identical, the Identifier MUST remain unchanged.". And the RFC warns just as clearly in the next sentence: " Note that if Acct-Delay-Time is included in the attributes of an Accounting-Request then the Acct-Delay-Time value will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator." If you look closer at the retransmitted accounting packet you will notice that it is NOT identical, due to this fact. Therefore the packet MUST have a new identifier. >My question: how is suposed a Radius server to identify the duplicates? This is a tough one- The radius server needs to be able to overcome the shortcomings of the radius protocol. It Can't rely simply on a single field that allows only values of 1 to 254 to decide if it's seen a packet before. Imagine a busy server- taking 1000 or more requests a second... One solution might be for the server to build it's own key- based on NAS_IP, SESSION_ID, and USER_NAME for example. That would make the packets pretty unique in most situations. This is the method used by the latest version of 3Com's security server. >>But later, when it comes time to send another request, it has >>"forgotten" that it previously incremented the identifier and merrily >>uses the last one again! Can you send along an example of this happening (using the same packet-ID twice in a row for the same destination port and with current HiperArc code)? If it is an issue it will be fixed. Keep in mind though that it only takes a couple hundred packets to wrap back around and reuse the same ID again. >The Radius server is supposed to contact the System Administrator >and get him to purchase products from a vendor that knows how to >read a RFC, or, failing that, at least fixes problems when they >are pointed out to them. What exactly was it that 3com missed in the RFC? You can send the trace directly to me if you don't want to post to the list. Thanks, Steve_valiunas(a)3com.com Aaron Nabil <nabil(a)spiritone.com> on 10/12/99 08:14:07 PM Please respond to usr-tc(a)lists.xmission.com Sent by: Aaron Nabil <nabil(a)spiritone.com> To: usr-tc(a)lists.xmission.com cc: (Steve Valiunas/MW/US/3Com) Subject: Re: (usr-tc) Radius question Corneliu Rudeanu writes... >I was really surprised to see how HARC deals with the radius packet >identifier. > >RFC states as clear as posibile: "For retransmissions where the contents >are identical, the Identifier MUST remain unchanged.". > >Yet watching (monitor radius) the id-s of the packets being retransmited I >found that hiperArc (4.2.29) assigns diferrent id for the packets being >re-sent to radius server for the same accounting request. Hah! It's much better than that! (Note the date, too!) >From: Aaron Nabil <nabil(a)spiritone.com> >Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit >Date: 14 Jun 1998 16:58:15 -0700 (PDT) > > >The HiperArc has a nasty Radius bug. > >If a packet get lost in transit or for some other reason is never >acknoweldged, the HiperArc increments the identifier and tries >sending it again after the timeout period. > >But later, when it comes time to send another request, it has >"forgotten" that it previously incremented the identifier and merrily >uses the last one again! Not only does it incorrectly increment the identifier, it then goes on to re-use the same identifier again later! Yes, this is so incredibly broken it's not even imaginable that it hasn't been fixed. But it hasn't. >My question: how is suposed a Radius server to identify the duplicates? The Radius server is supposed to contact the System Administrator and get him to purchase products from a vendor that knows how to read a RFC, or, failing that, at least fixes problems when they are pointed out to them. -- Aaron Nabil - To unsubscribe to usr-tc, send an email to "majordomo(a)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. - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

3 2

Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
by Steve Valiunas 13 Oct '99

13 Oct '99

>Do you mean 6.09 ? If so, what about 6.08 ? It's available in an Engineering Release, so you'll have to call tech support. (I know- another example of excess bureaucracy <g>). It is in the process of being posted as a service release. When this is completed you'll be able to grab it directly off of totalservice.3com.com. The Version is 6.0.83 and is available for WIndows. The more robust duplicate/out-of-order checking only affects accounting. Authentication still relies on packet identifier Steve jeff.binkley(a)asacomp.com (Jeff Binkley) on 10/13/99 08:13:00 AM Please respond to usr-tc(a)lists.xmission.com Sent by: jeff.binkley(a)asacomp.com (Jeff Binkley) To: USR-TC(a)LISTS.XMISSION.COM cc: (Steve Valiunas/MW/US/3Com) Subject: (usr-tc) RE: (USR-TC) RADIUS QUEST U>Aaron & Corneliu, U>>RFC states as clear as posibile: "For retransmissions where the U>contents >are identical, the Identifier MUST remain unchanged.". U>And the RFC warns just as clearly in the next sentence: " Note that if U>Acct-Delay-Time is included U>in the attributes of an Accounting-Request then the Acct-Delay-Time U>value will be updated when U>the packet is retransmitted, changing the content of the Attributes U>field and requiring a new U>Identifier and Request Authenticator." U> If you look closer at the retransmitted accounting packet you will U>notice that U>it is NOT identical, due to U>this fact. Therefore the packet MUST have a new identifier. U>>My question: how is suposed a Radius server to identify the U>duplicates? U> This is a tough one- U> The radius server needs to be able to overcome the shortcomings of U>the radius protocol. It Can't rely simply on a single field that U>allows only values of 1 to 254 to decide if it's seen a packet before. U>Imagine a busy server- taking 1000 or more requests a second... U> One solution might be for the server to build it's own key- based on U>NAS_IP, SESSION_ID, and USER_NAME for example. That would make the U>packets pretty unique in most situations. This is the method used by U>the latest version of 3Com's security server. Do you mean 6.09 ? If so, what about 6.08 ? Jeff Binkley ASA Network Computing U> Thanks, U> Steve_valiunas(a)3com.com CMPQwk 1.42 9999 - To unsubscribe to usr-tc, send an email to "majordomo(a)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. - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

2 1

(usr-tc) OSPF default route problem
by Mike McHenry 12 Oct '99

12 Oct '99

Hello all, I have been running OSPF on the 4.2.32-1 ARC code for several weeks and have just started to see a disturbing problem. In certain cases it appears as though the ARC is replacing it's own default route with the one advertised in my OSPF broadcasts. My core router is set to advertise the default route via OSPF with the following IOS config router ospf 10 default-information originate always and in certain non-reproducable cases my chassis decide to favor this OSPF default route over their own. Obviously this is NOT correct behavior, OSPF-learned routes should NOT be favored above static routes and that is what is happening here. After some time the OSPF hiccups and I am left with several chassis that no longer have a default route, not good. Has anyone else run into this issue? I almost wonder if I am getting a little too many routes in my OSPF area, things have been acting very odd lately with OSPF in general on my USR TC chassis. Mike McHenry Systems Administrator MinnNet Communications, Inc. - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

1 0

Re: (usr-tc) 2.0.60 HDM Code
by Todd Keister 12 Oct '99

12 Oct '99

Jeff was right "On the Money" with this one.... The purchase of a new kit, or product gives you access to the website for software upgrades, as well as technical support for 90 days. If you have problems accessing the site, please call us at Tech Support. We may be able to help. The hours for this kind of support are 8AM to 5PM, but since this covers the entire country this works out to 8AM EST to 5 PM PST, or 7AM to 7PM Central (we're in Chicago). If you, the members of this list, ever have issues, then please call us at (800) 231-8770. You will also find that our Knowledgebase tool has been making great strides. We have populated the database with many more solutions, and many of these have now been published on the web based interface for use by anyone. This is located at http://knowledgebase.3com.com/ I hope this helps. Todd ;-} PS: If you are wondering why you may get cards with "old code" it may be related to the card being warehoused first by 3Com, and then by the Wholesaler/Distributor, and possibly a Reseller as well. Supply chains and beaurocracy - I won't go there.... ;-} Jeff Mcadams <jeffm(a)iglou.com> on 10/12/99 01:13:46 PM Please respond to usr-tc(a)lists.xmission.com Sent by: Jeff Mcadams <jeffm(a)iglou.com> To: usr-tc(a)lists.xmission.com cc: (Todd Keister/MW/US/3Com) Subject: Re: (usr-tc) 2.0.60 HDM Code Thus spake Marshall Morgan >We just purchased additional DSP Upgrade kits. How to we get more recent code >on them if they ship with older code without a service contract? In this specific situation, you can go to the totalservice website and register your new cards for warranty support. This last for 90 days and gets you full access to all the code I believe. The suggestion I heard, because of a bug in the registration code on their web site, is that its a good idea to set up a new login and password for the totalservice web site each time you do this...something about overlapping warranty periods not being recognized correctly and when the first warranty period runs out your access to the code is revoked...even though you have other warranties still in effect. -- Jeff McAdams Email: jeffm(a)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(a)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. - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

2 1

Re: (usr-tc) 2.0.60 HDM Code
by Todd Keister 12 Oct '99

12 Oct '99

Jeff: I think you have missed the point. We don't just want to "Throw Code" at given issues. It may seem like extra steps, and sometimes it is laborious to follow these procedures, but in business, law, and especially in science, if you don't have clearly documented data trails, and reproducible results - then you have not accomplished a darn thing. Once again: >This is done so that we can document the use of these special codes to >see if the code fixes the specific issue it was designed to address, AND also >to see if the new fix for one issue causes issues with any other >processes in the code or product. If we were to just release code "willy nilly" and not track what we've done, it would be of no use to anyone, and we would be breaking many more things than we fix. ER code is "special issue" code that addresses one speicific problem, and it is not feasible to stress check this code for all possible issues in all possible configurations. A specific ER code may have a known issue with another process - and that will be fixed before an ER is promoted to a Service Release. In the meanwhile customers who desperately need one item fixed, and who can "make due" while any other errors are resolved - can do just that - they can get the fix that they need - and they can get it NOW (which is the whole point of this process). I hope this clarifies my prior statements, and I hope this helps to clarify what could on the surface seem to be another "Stupid Policy" that is actually just a part of the Scientific Method. Todd ;-} Jeff Mcadams <jeffm(a)iglou.com> on 10/12/99 12:12:31 PM Please respond to usr-tc(a)lists.xmission.com Sent by: Jeff Mcadams <jeffm(a)iglou.com> To: usr-tc(a)lists.xmission.com cc: (Todd Keister/MW/US/3Com) Subject: Re: (usr-tc) 2.0.60 HDM Code Thus spake Todd Keister > ER or Engineering Release Code is only available by calling to >Tech Support, and then WE (Tech Support) must get permission to release >the code. Good grief, its getting worse. What's next? Are we going to have to get a note from our mother's to use ER code? Blech. >This is done so that we can document the use of these special codes to >see if the fix the specific issue they are supposed address, and also >to see if the new fix for one issue causes issues with any other >processes in the code or product. Is it at all possible that 3Com could ever *eliminate* beaurocracy in their processes rather than constantly adding layer upon layer of it? > I hope this helps. Unfortunately, no, I doubt it really does. :/ Does anyone in upper management at 3Com listen to what we're saying? I sometimes get the distinct impression that they really don't give a crap what we feel. I guess that is progress though...we do have *some* people at 3Com listening to us now...even if they aren't the people making decisions on most of these things. Jeff "getting frustrated with 3Com idiocy again" McAdams - To unsubscribe to usr-tc, send an email to "majordomo(a)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. - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

4 5

RE: (usr-tc) TC user's conference?
by Scott Trautman 12 Oct '99

12 Oct '99

-----Original Message----- From: Jeff Mcadams [mailto:jeffm@iglou.com] Sent: Monday, October 11, 1999 10:08 AM To: usr-tc(a)lists.xmission.com Subject: (usr-tc) TC user's conference? Thus spake Scott Trautman >I concur on the training; I know in our area there are plans to have a >session in the near future. Even those that think they "know it all", >will learn some new tricks. I've been fortunate to get to know George >Ebert at 3Com, and he's been a fantastic resource for those types of >things. It'll be nice, though, to retain more than say 30% from those >valuable informal sessions; as well as send a couple of our Admins to >the training. Indeed...those informal training sessions are good...and they're a good way for 3Com folks to get feedback from customers (there were about 8 of us at the one in Louisville...there was some good give and take there). I just wish they could get 3Com folks to come that aren't in the sales side of things...while the sales folks are good (Tom Goodman and George Ebert are indeed wonderful resources), it seems that, within 3Com, feedback doesn't really seem to be taken seriously from the sales folks. :/ Unfortunately, this seems to be the case in many companies...not just 3Com. Yep, similiar experiences. Unfortunate. Understand that they can't be all things to all people, but seems like there'd be a few strategic things they could do without a whole huge effort. Also understood is the things you'd like to see maybe only a handful think is as important. My thing (currently) is I'd like to see the ptrace style output. Then I go look at my Cisco routers, they have even less than that where it's even more important. Shrug. >I had suggested perhaps a TC users conference would be cool; something >like an ISPCON but specifically for TC units. 1-2 days with conferences >on many of the subjects we talk about here. There's a lot more "under >the hood" than many of us ever get to, and I know we could, if we knew >about them, use a lot more features than we currently do. Neat idea...I'd certainly go for it (if I could get my company to pay for the travel ;) >A few examples....I'm sure y'all can think of many more..... >- T1 provisioning/trouble resolution (line, trunk, PRI, signal/noise >ratio's, etc.) Good...unfortunately, there's not much in the way of tools in the TC's to do trouble resolution on these things. More control over the CSU/DSU's would be *very* useful here. Well, useful to the extent that problems they're seeing <through> the TC equipment is really telco issues, and being able to better tell the difference would be really helpful. >- Getting more mileage out of TCM Hrmm...unfortunately, I've pretty much given up on TCM...you can only get so much mileage out of a VW bug. :/ I'm beginning to write some Perl5 (with SNMP module) scripts to interact with the TC's... I'm not quite to the point of putting TCM type functionality together...I'm starting with scripts to fulfull specific functions...I may, eventually, get to that point. George helped me along off of the same thought. I get quite a bit of use from TCM, and it beats the snot out of any other dialup control interface I've seen. Cisco, for example, I'm not sure they have ANY such graphical interface. >- Advanced SNMP Isn't that a contradiction in terms? ;) Well, no, kind of like TCM, I think one could do a lot more if one understood better "how it all fits together". Some of recent trails on SNMP manipulation that I've not delved into could be quite useful. For example, have a feeling I could probably find my "no answer" modems via SNMP a lot easier than any sort of RADIUS accounting grooming or the usual expect-like scripting. I just don't know how at this point. Session on, say, okay, (and we use this tool...great) RRD for modems in use monitoring, but other types of trap monitoring perhaps. >- Dialup user issues (monitoring, filtering, setup, etc.) >- Getting to the bottom of modem compatibility issues I see these two kinda being two different sides of the same coin...most specifically, I would benefit from a seriously in depth seminar about modem technology...unfortunately, I'm not sure how generally useful this would be as I'm thinking about actually getting down into the encoding of the data into the analog waveform and stuff. :) Sure. I'm personally not all that interested in the encoding level of things, but would be in understanding more fully WHY Rockwell chipset modems are such a problem. (I mean other than "they suck") >- HiperARC setup >- TC "future" - VoIP, ? Indeed...this would be nice...especially to give feedback to 3Com through it. Where do you/I/we want this platform to go? I sent a nice long letter to the list the other day and got very little feedback...one person agreeing with me (in private, asked for his message not to be publically posted), and one person sort of disagreeing with me in public. :) >I'd pay $1-2k for such a day-2day conference.....Just thoughts.... Unfortunately, that'd probably be out of our price range...but I would be interested in such a conference in idea at least. :) Shrug. SMT -- Jeff McAdams Email: jeffm(a)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(a)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. - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

2 2

RE: (usr-tc) Finding that no-answering modem
by Scott Trautman 12 Oct '99

12 Oct '99

Simply highlighting the modem, actions/commands, software reset. Busy out modems? Simple. At the T1; before it hits the modem. Highlight your T1 card, actions/commands, select the TRUNK # corresponding to the problem modem, and do a soft or hard busy out of the DS0. THIS much I DO know! :^) USED to have to pull the card on stuck modems, but hasn't seemed to be the case since the last modem code update quite some time ago. Also doesn't seem to happen nearly as often either. SMT > -----Original Message----- > From: Greg Owens [mailto:gowens@magnolia-net.com] > Sent: Sunday, October 10, 1999 10:00 AM > To: usr-tc(a)lists.xmission.com > Subject: Re: (usr-tc) Finding that no-answering modem > > > Where in the TCM are you going to reset it successfully. > Seems like every > time we have a hung (no answer) modem we have to unplug the > card and and > plug it back in. Also is there a way to busy out 1 or 2 > modems in a card > (DSP) from the TCM. Thanks > Greg Owens > Magnolia Internet Services > http://www.magnolia-net.com > ----- Original Message ----- > From: Scott Trautman <scottt(a)corp.gdinet.com> > To: <usr-tc(a)lists.xmission.com> > Sent: Sunday, October 10, 1999 9:29 AM > Subject: (usr-tc) Finding that no-answering modem > > > > Went for months without a no-answer modem, now seem to have > had a real > spate > > of them. > > Fortunately it does seem that simply resetting the modem in > TCM 'fixes' > it, > > but we don't > > fix it before we get a call or two of 'no answer modem'. > > > > Anyone running any kind of script/log analysis that finds no answer > modems? > > > > I also had a fellow from 3Com show me an "Autoresponse" > trick to reset the > > modem automatically > > if it got a no answer. I've since forgotten how, and not > really sure if > > that'd really do the > > trick anyway. And it would be mighty tedious to set all our > ports for > this. > > > > SMT > > > > Scott M. Trautman 800-482-4638 > > Global Dialog Internet 608-240-4638,4637fax > > 2810 Crossroads, STE LL2 scott(a)gdinet.com > > Madison WI 53718 http://www.gdinet.com > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo(a)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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)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. > - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

4 4

(usr-tc) 2.0.60 HDM Code
by Jim Johnson 12 Oct '99

12 Oct '99

Is anyone using HDM 2.0.60.0 code. It is an Engineering Release which implements a DSP reset whenever the DSP goes idle on both ports. It is a temporary fix to the hanging pair of modems problem, but I just wanted some feedback, if any was available, before we put it on any of our production modems. Thanks, Jim - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

4 4

RE: (usr-tc) Finding that no-answering modem
by K Mitchell 11 Oct '99

11 Oct '99

At 09:26 PM 10/11/99 -0400, you wrote: >On Mon, 11 Oct 1999, K Mitchell wrote: > >> Where do I get a copy of SNMP_Session.pm? > >Quick answer: Install MRTG :) > >(The library is available separately, but MRTG is indispensable enough on >its own...) I've had mrtg running for over a year :) Copied SNMP_Session.pm and BER.pm into perl\lib, now it has a problem because I don't have NTsendmail.pm, as I use JMail, which doesn't appear to have a jmail.pm. What do I need to change to have it use JMail? Thanks, -- Kirk Mitchell-General Manager mitch(a)keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

1 0

(usr-tc) Finding that no-answering modem
by Scott Trautman 11 Oct '99

11 Oct '99

Went for months without a no-answer modem, now seem to have had a real spate of them. Fortunately it does seem that simply resetting the modem in TCM 'fixes' it, but we don't fix it before we get a call or two of 'no answer modem'. Anyone running any kind of script/log analysis that finds no answer modems? I also had a fellow from 3Com show me an "Autoresponse" trick to reset the modem automatically if it got a no answer. I've since forgotten how, and not really sure if that'd really do the trick anyway. And it would be mighty tedious to set all our ports for this. SMT Scott M. Trautman 800-482-4638 Global Dialog Internet 608-240-4638,4637fax 2810 Crossroads, STE LL2 scott(a)gdinet.com Madison WI 53718 http://www.gdinet.com - To unsubscribe to usr-tc, send an email to "majordomo(a)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.

5 4