March 1998

On Tue, 24 Mar 1998, Pete Ashdown wrote: > Tatai SV Krishnan said once upon a time: > > > >Do an > > > >_auth username password > > > >from the ARC. > > Hmmm, pretty quick response. Any idea why it takes 6 to 8 seconds for ISDN > to get to this point? > What I think is happening is that the HDM is taking around 5-6 seconds Let me check with our HDM group and see why it is such. krish > - > 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. >

What are you talking about here. There is no problem with IP pools. The way you assign your IP pools is to assign +1 the number of modems you activate. This is because you do have a console port which can also be used as the port. So if you have 96 ports have 97 address in your pool. You will loose address from the pool only if you are using hint assinged feature and if your radius server does not free up the address. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 25 Mar 1998, Kelly Shaw wrote: > Great! So much for documentation. I searched the entire web and > totalservice.usr.com site and found no mention of this problem. > > I'll give your suggestion a try. > > Kelly > > > -----Original Message----- > From: John Lange <microjl@palacenet.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Tuesday, March 24, 1998 8:55 PM > Subject: Re:(usr-tc) IP pool out of addresses > > > >HI > > > >I heard somewhere that you need to over allocate your pool by 10% because > >the TC doesn't immediately release the ip's on disconnect. > > > >JOhn :} > > > >At 10:12 PM 3/23/98 -0600, you wrote: > >>At 21:47 -0600 on 3/23/98, A. Kelly Shaw wrote: > >> > >> > >>> I know this is probably very simple to fix, but it sure is tough > >>> for me. > >>> > >>> I just recently added 2 HIPER DSP cards to my TCH and increased > >>> my IP pool size appropriately ( I thought) by the number of > >>> channels that I am using on the card. However, I am still > >>> getting the error > >>> > >>> IP pool out of addresses. > >>> > >>> Any ideas? > >> > >>Did you restart the server? > >> > >>Butch > >> > >> > >>Butch Kemper | Free sound advice available > >>Kemper & Associates Consulting Group | "95% sound and 5% advice" > >>409-361-2324 | Refunds cheerfully provided > >> > >> > >> > >>- > >> 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. > >> > >> > > > >John C. Lange, Sr. PALACE dot NET, INC. > >microjl@palacenet.net MICRO-TECH Computers, Inc. > >608.742.1601 & 6980 2800 New Pinery Road > >http://www.palacenet.net/ Portage, WI 53901 > >Visit our online store @ http://www.microt.com/ > >Authorized iPSwitch WebVar @ http://www.microt.com/iPSwitch/index.html > > > > --- __o > > --- _-\<,_ Fastest Service in Town > > --- (_)/ (_) > > > > > >- > > 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. > > > > > - > 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. >

It is autodetect, the HiPer ARC when booted will try FullDuplex 100 Base T, then 100Base half duplex, then 10 ... etc krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Wed, 25 Mar 1998, Charles Hill wrote: > > How do I get a 100BaseT interface on the HiPer ARC to do full duplex? The > switch is set for full duplex and I rebooted the HiPer ARC after plugging > it into the switch, but judging from the number of late collisions the > HiPer ARC did not operate at full duplex. > > Regards, > > Charles Hill > ioNET Network Specialist > > work: 405.270.7020 > cell: 405.833.5477 > pager: 405.559.6697 or 4058335477@mobile.att.net > email: chill@ionet.net > http://www.ionet.net/~chill > ICQ: 4923465@pager.mirabilis.com > > > - > 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. >

On Thu, 26 Mar 1998, Marshall Morgan wrote: > All, > > That cute ARC _auth command we learned does nothing for me as I can _auth > myself and anyone else without issue. When calls come in they just don't get > auth'ed as you can see from the following records. This command is to make sure if your radius server is working or not. Now that you can authenticate users this way that means that the Radius server is fine and the configuration of Hiper ARC is fine also. > > WTF? What do I do now? I have tried everything I can think of, asked the list > of masters and typed in the hidden, debug stuff. What gives? I have > singlehandedly pissed off many, many customers over the last two "trials" of > this ... and remember, I did this a little over a week ago with the exact same > setup and it went without flaw. HELP! > Now from what you say here it looks like that your templetes on the modems are not properlly set. Select the HDM card choose the four templetes. Make sure from call control options that you have all the templete options set properlly. Now save the templete to nvram and REFRESH the templete. Dial again -- krish > ==================================== > > > Start Start > IfName User Name Type DLL Date Time > slot:1/mod:8 DIALIN NONE 00- -0000 00:00:00 > > > AUTHENTICATION COUNTERS > Local Successful Authentications: 1 > Local Failed Authentications: 0 > Remote Successful Authentications: 1 > Remote Failed Authentications: 0 > > ============= > > recap: running 6 HiperDSP's (1.07) and (2) ARCs (4.0.69) in a dual PS chassis. > Have another one configured the same w/o issue for over two weeks. > > Marshall Morgan > > Internet Doorway, Inc. (aka NETDOOR) > http://www.netdoor.com > 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28 >

On Thu, 26 Mar 1998, Marcelo Souza wrote: > On Wed, 25 Feb 1998, Tatai SV Krishnan wrote: > > |What are you talking about here. There is no problem with IP pools. The > |way you assign your IP pools is to assign +1 the number of modems you > |activate. This is because you do have a console port which can also be > |used as the port. So if you have 96 ports have 97 address in your pool. > > Should it be +5. I'm saying that because here, the port > allocation begin on port s4. I dont know why it does not start at s1. > No only the active ports, if you have Pri/T1 in the chassis - you do not set the ports active. 3.7.24 code does allow you to may ports from S1 so even so you can start your port mapping from S1. krish > |> From: John Lange <microjl@palacenet.net> > |> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > |> Date: Tuesday, March 24, 1998 8:55 PM > |> Subject: Re:(usr-tc) IP pool out of addresses > |> > |> > |> >HI > |> > > |> >I heard somewhere that you need to over allocate your pool by 10% because > |> >the TC doesn't immediately release the ip's on disconnect. > |> > > |> >JOhn :} > |> > > |> >At 10:12 PM 3/23/98 -0600, you wrote: > |> >>At 21:47 -0600 on 3/23/98, A. Kelly Shaw wrote: > |> >> > |> >> > |> >>> I know this is probably very simple to fix, but it sure is tough > |> >>> for me. > |> >>> > |> >>> I just recently added 2 HIPER DSP cards to my TCH and increased > |> >>> my IP pool size appropriately ( I thought) by the number of > |> >>> channels that I am using on the card. However, I am still > |> >>> getting the error > |> >>> > |> >>> IP pool out of addresses. > |> >>> > |> >>> Any ideas? > |> >> > |> >>Did you restart the server? > |> >> > |> >>Butch > |> >> > |> >> > |> >>Butch Kemper | Free sound advice available > |> >>Kemper & Associates Consulting Group | "95% sound and 5% advice" > |> >>409-361-2324 | Refunds cheerfully provided > |> >> > |> >> > |> >> > |> >>- > |> >> 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. > |> >> > |> >> > |> > > |> >John C. Lange, Sr. PALACE dot NET, INC. > |> >microjl@palacenet.net MICRO-TECH Computers, Inc. > |> >608.742.1601 & 6980 2800 New Pinery Road > |> >http://www.palacenet.net/ Portage, WI 53901 > |> >Visit our online store @ http://www.microt.com/ > |> >Authorized iPSwitch WebVar @ http://www.microt.com/iPSwitch/index.html > |> > > |> > --- __o > |> > --- _-\<,_ Fastest Service in Town > |> > --- (_)/ (_) > |> > > |> > > |> >- > |> > 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. > |> > > |> > |> > |> - > |> 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. > |> > | > |- > | 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. > | > > []s Marcelo > mpsouza@centroin.com.br > Rio de Janeiro - RJ > > > - > 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. >

No - Netserver has a plain old ethernet interface - 10 base T only , no autodetect or autonegotiation. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 26 Mar 1998, Brian wrote: > On Wed, 25 Feb 1998, Tatai SV Krishnan wrote: > > > It is autodetect, the HiPer ARC when booted will try FullDuplex 100 Base > > T, then 100Base half duplex, then 10 ... etc > > > > krish > > > And does the netserver behave the same in regards to Full Duplex? > > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Wed, 25 Mar 1998, Charles Hill wrote: > > > > > > > > How do I get a 100BaseT interface on the HiPer ARC to do full duplex? The > > > switch is set for full duplex and I rebooted the HiPer ARC after plugging > > > it into the switch, but judging from the number of late collisions the > > > HiPer ARC did not operate at full duplex. > > > > > > Regards, > > > > > > Charles Hill > > > ioNET Network Specialist > > > > > > work: 405.270.7020 > > > cell: 405.833.5477 > > > pager: 405.559.6697 or 4058335477@mobile.att.net > > > email: chill@ionet.net > > > http://www.ionet.net/~chill > > > ICQ: 4923465@pager.mirabilis.com > > > > > > > > > - > > > 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. > > > > > > > - > > 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. > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > >

On Thu, 26 Mar 1998, Ricky Beam wrote: > Brian Elfert was heard to say: > >The Netserver sends a special accounting packet to the radius server upon > >reboot. > > Well, that depends on the NetServer code version... > > >USR's radius software should clear out the current login table for that > >Netserver as soon as that packet is received. > > > >Now, if it does that or not is another question. > > I doesn't unless you teach it to do so. And, there is no "login table" > so unless you add a field to the user table, you don't know who to mark > as cleared. (USR never really put any deep thought into an ISP usable > RADIUS setup. And, HARP is a bandaid over a marginal RADIUS server.) > HARP is not a bandaid. Harp is totally different krish > --Ricky > > PS: I have the USR RADIUS v4.3(11) handling 100x what USR thinks it can > actually do. (radius1-25 auth reqs in one sec, radius2-50 acct reqs in > the same sec, both attached to the same postgreSQL DB) > > - > 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. >

On Thu, 26 Mar 1998, Scott Kreuser wrote: > My question of the day deals with Framed Routes. > > The below worked fine on my Portmasters. > > user Password ="UNIX" > Framed-Address = 208.6.184.212, > Framed-Netmask = 255.255.255.255, > Framed-Route = "208.6.184.213 208.6.184.212 1" Your Framed-Router should be like this Framed-Route = "208.6.184.213/32 208.6.184.212 1" krish > As you can see I'm just trying to route this guy another IP > for his home linux network. With this he can ping from > the .213 machine out of our network, but not anywhere inside > it. The .212 machine works fine. > > Also, on the same note what is this route? > > #1) 208.006.184.000/C LOCAL 208.6.184.29 1 eth:1 > > .29 is my TC, and I don't really care for all my traffic > to go through it that's why I have a > > #2) 000.000.000.000/0 NetMgr 208.6.184.1 1 eth:1 > > How can I delete this route (#1)? It's causing troubles. > Today the user from the radius file above logged in and > eventually that route(#2) turned into this > > 208.006.184.000/C LOCAL 208.6.184.212 1 eth:1 > > basically all traffic for my network got diverted over > to his network... shutting down all the users connected to > the TC. > > Why do TCs act so different then Portmasters???? > > Scott > > - > 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. >

On Fri, 27 Mar 1998, Scott Kreuser wrote: > That works. But on some of the linux machines that are'nt running RIP > they can't get to the .213 address. My router can get to it. The route > is broadcasted to my router. But, my internal unix machines can't. > > It's like eth:1 is not announcing to the LAN that it is using that IP. > If eth:1 is not announcing how did your router get the route? > Also, why does a "Framed-Route" show up as a "NetMgr" route and not a > LOCAL route? > It is not a local route, a local route is via a local attached device Here we are saying that the remote address is attached via a connected device. So it is a Netmgr route krish > Scott > > > > > Your Framed-Router should be like this > > > > Framed-Route = "208.6.184.213/32 208.6.184.212 1" > > > > - > 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. >

We use a NETServer 16/I for dial-up access. I would appreciate any pointers on the following: 1. Right out of the box, there is a default init string called "USR_int" with the command of "ATS0=0" However, the modem(s) ANSWERS incoming calls as if S0 is set to a non-zero value. I've checked by issuing an "ati4" and confirmed that S0=0. Why is it answering when S0=0? 2. If I have the modems use an init script with the command of "ATS0=1", the modem will answer but will IMMEDIATELY hang up! Is this a known problem with NETServer? "ATS0=2" seems work fine. Any ideas? Many Thanx. fbsd

On Sat, 28 Mar 1998, Rev. Jim wrote: > > I am using Merit 3.5.6 on a Linux box. I have been trying to get the > default authentication working. The docs say that i should not have to > modify the user file. I disagree. In order for a user to authenticate and > make a network connection I had to add five extra lines under DEFAULT. > When I remove them (comment them out) the connection is refused. Here is > what I am using for the users file. > > [ users file ] > # Copyright [C] The Regents of the University of Michigan and Merit Network, > # RCSID: $Id: users,v 1.3 1997/02/14 17:58:26 web Exp $ > > #DEFAULT Authentication-Type = Realm > DEFAULT Authentication-Type = Unix-PW > # Filter-Id = "unlim" do not have a filter by this name > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Address = 255.255.255.254, > Framed-IP-Netmask = 255.255.255.0, > Framed-Compression = Van-Jacobson-TCP-IP > The above Defaul user will work, but will cause problems because of the Netmask, the netmask here should be 255.255.255.255 > dumbuser Authentication-Type = None > Service-Type = Login, > Login-Service = Telnet, > Login-IP-Host = 255.255.255.255 > No problem here. > pppuser Authentication-Type = None > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Address = 255.255.255.254, > Framed-IP-Netmask = 255.255.255.0, > Framed-Compression = Van-Jacobson-TCP-IP > Same here with the netmask. set the netmask 255.255.255.255 krish > I am running a NetServer 8/I with 4.0.13/2.2.2. > > Can this be caused by either a miss-configured Merit Makefile or Netserver > config? > > A side effect of this is that EVERY entry in the accounting file is for the > 'default' user - talk about useless. > > It would seem to me that I should enable > > # Define USR_CCA to enable USR support: > USR = -DUSR_CCA > > in the Makefile - but when I do, the logfile fills with error messages and > no authentication takes place. Could someone please enlighten me on what > USR_CCA actually is, and should I be using it. > > Most appreciative for you time spent in reviewing this. > > > "Sometimes it seems like the gene pool needs a little chlorine." > > packrat > > > - > 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. >

On Sat, 28 Mar 1998, Brian wrote: > Has anyone every noticed a single modem marked "disabled"? > > HiPer>> list intERFACES > > INTERFACES > Interface Oper Admin > Name Status Status > eth:1 Up Up > eth:2 Down Up > slot:5/mod:1 Up Up > slot:5/mod:2 Up Up > slot:5/mod:3 Up Up > slot:5/mod:4 Up Up > slot:5/mod:5 Up Up > slot:5/mod:6 Up Up > slot:5/mod:7 Up Up > slot:5/mod:8 Up Up > slot:5/mod:9 Up Up > slot:5/mod:10 Up Up > slot:5/mod:11 Up Up > slot:5/mod:12 Up Up > slot:5/mod:13 Up Up > slot:5/mod:14 Down Up What version of HDM code are you using? Also does this happen on a regular basis? Also does the modem come back if you use this command set ch slo 5 o y card_type hdm_24 Also does this chassis consits of more than one HiPer ARC? krish > slot:5/mod:15 Up Up > slot:5/mod:16 Up Up > > > So I try "enable interface slot:5/mod:14", and it doesnt work. I can do > "disable interface slot:5/mod:14" and get: > > slot:5/mod:14 Down Down > > and then "enable interface slot:5/mod:14" puts it back at: > > slot:5/mod:14 Down Up > > > Why is it down? > > software reset modem: doesnt work > hardware reset card: doesnt work > swap card: same modem still disabled! > > only known solution: reboot the ARC! > > why is this modem down, and why cant I bring it back..........it seems > like an ARC issue.............. > > Brian > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > - > 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. >

On Mon, 2 Mar 1998, FBSD wrote: > Krish: > > Thanx for the info. But... please see below; > > On Sat, 28 Feb 1998, Tatai SV Krishnan wrote: > > > > We use a NETServer 16/I for dial-up access. I would appreciate any > > > pointers on the following: > > > > > > 1. Right out of the box, there is a default init string called > > > "USR_int" with the command of "ATS0=0" However, the modem(s) ANSWERS > > > incoming calls as if S0 is set to a non-zero value. I've checked by > > > issuing an "ati4" and confirmed that S0=0. Why is it answering when > > > S0=0? > > > > There is a reason why thee is a INIT script in the first place. The init > > script has to set the modem in a proper way for it to answer. Here in > > this case, when a call comes in, the modem senses the call and informs > > the above layer about the call - which will then tell the modem to answer. > > But that doesn't explain why incoming calls are answered though S0 is set > to 0 by the default "USR_int" init-script. Is it because the dip switches > on the back of the NETServer overrides the S0 setting? I thought the dip > switches are overriden by AT commands. This is not a modem attached to a PC, it is a modem/router combination. This is the way it works. The above explanation that I gave you is how the modem in a NETServer works. My explanation above is clear - I cannot make it any more clear. > > > > 2. If I have the modems use an init script with the command of > > > "ATS0=1", the modem will answer but will IMMEDIATELY hang up! Is this > > > a known problem with NETServer? "ATS0=2" seems work fine. > > > > > ats0=1 is to tell the modem to answer on one ring, which is good for a > > modem connected to a pc, not this this case. The modem should inform its > > above layer about the call, when you set ats0=2 it will work since the > > modem sense the first ring and the calls is told to answer from above > > The reason why I fiddled with S0 in the first place was because of this; > everything was working fine for the first two weeks we've installed the > NETServer. We let the default init-script "USR_int" run and set S0=0 but > calls were answered and that was that. Then one evening, one of the > interfaces (mod:9) was NOT answering any calls at all. The user would > hear the ringing tone but the NETServer (mod:9) wasn't detecting the > incoming call. I've tried resetting the modem but nothing helped. It was > then I tried setting S0=1 manually. It sure did answer after that but > that's when I discovered the S0=1 problem. > Your modem may not be set active ( 3.x.x netserver code ) or it may not be set to incoming calls or something strange must have happened that the modem did not answer. > S0 is set to 2 now but any ideas why all of a sudden, with the default > init-script, the NETServer stopped detecting incoming calls? > Read the explanation above in my previous email. The modem detects the call and informs the router process and therefore the call is answered. > There was a new problem tonight; PPP users couldn't get authenticated on a > particular interface. Win95 users would get an error message complaining > that their "server type, protocol" settings were wrong... Meanwhile, the > NETServer would log the following: > > Mar 2 00:27:30 term1 At 00:28:03, Facility "Telnet", Level "UNUSUAL":: > Bad state/event combination: link status update received in state: 0x9 > Mar 2 00:27:30 term1 At 00:28:03, Facility "Auth Facility", Level > "COMMON":: The connection on if mod:4 was dropped for user UNKNOWN > > What's "Telnet" doing in there? You are combing problems, This syslog events has two events, Your ppp users could not authenticate could have several reason like.: 1. wrong password 2. radius server down, 3. wrong username 4. Win 95 itself. All the above event is telling you is the there was bad state/event in a telnet session and the second one is about droping a user - since it does not recognize the user. > > BTW, I posted a question about the number of IP pool members. I found > that the NETServer would claim to run out of IP addresses if I set the > "Dynamic Address Pool Size" to 16. (We have a NETServer 16/I) Does the > pool size has to be larger than 16? > Technically you have 17 ports including the console. If your console is also configured for dialing/network you must have 17 ports else 16 krish > Thanks in advance for any pointers. > > fbsd > > > - > 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. >

On Sun, 1 Mar 1998, Russ Miescke wrote: > I am having a problem telneting into my hiper arc card. It all worked fine > until I used the Hiper Access Router manager. When I made a small change to > a different user, I was asked to save (which I did), and have not been able > to telnet into the card ever since. I have gone through every possible > option in the router manager, but have had no luck. It asks for my logon > and password, but as soon as I hit return after the password it disconnects > me. If I enter the wrong user name or password, it prompts me again. Any > ideas? > There are two things that you may have done a. set the HiPer arc not to allow telnet manage users or b. stoped the telnet demon on the card. You should be able to dialin and logon as a manage users then use the following commands enabLE secURITY_OPTION reMOTE_USER_ADMINISTRATION telnet then do a list network ser this should should you a telnetd service and tftp server if telnetd service is not up that means something caused it to die or someone caused it to die. then start a telnetd service add network service telnetd serv telnetd krish > Russ Miescke > Power Web Connect > russm@powerweb.net > > > > - > 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. >

On Fri, 27 Feb 1998, Brian wrote: > On Fri, 27 Feb 1998, Mike wrote: > > > At 03:07 PM 2/27/98 -0600, you wrote: > > >Do the two ARC's have to use seperate IP pools? Or can I delcare the same > > >pool on both and have them share it? > > > > 2 Pools Will be required. > > > > >Does MPP work between ARC's within the same hub? > > > > No. MPIP is not supported in the current ARC code. > > > > >Is there any concerns or caveats I need to know about using 2 ARC's in one > > >hub? (that's not clearly expalined in the docs) > > > > You must turn off Chassis awareness. This is done by typing > > 'dissable nmc chassis_awareness' at the ARC CLI. > > > > gotcha, then I would suspect I would have to assign all card > types/ownership statically....... > Yes, something like this if you have PRI. set chassis slot x card_type hdm_24 ports 23 owner yes -M

i am working on configuring my first NetServer box - i have gotten it to answer and connect the dial-in to the local net without a problem, but i cannot get the dial-in to route through the gateway for anything (ain't flipped the right switch yet) INFORMATION FOR USER: alpha Status: ACTIVE Type: NETWORK [snip] PARAMETERS FOR NETWORK USERS: Network Service PPP Header Compression: TCPIP (D) MTU: 1514 Send Password: Appletalk: DISABLED Filter Zones ENABLED (D) IP Usage: ENABLED (D) Address Selection: SPECIFIED Remote IP Address: 207.8.15.123/C IP Routing: LISTEN Default Route Option: ENABLED (D) IP RIP Routing Protocol: RIPV2 IP RIP Routing Policies: SPLIT_HORIZON POISON_REVERSE FLASH_UPDATE RIPV1_RECEIVE RIPV2_RECEIVE IP RIP Authentication Key: IPX Usage: DISABLED (D) [more snip] PARAMETERS for NETWORK PPP USERS Max Channels 1 (D) Channel Decrement Percent: 20 (D) Channel Expansion Percent: 60 (D) Expansion Algorithm: LINEAR (D) Receive ACC Map: ffffffff (D) Transmit ACC Map: ffffffff (D) Compression Algorithm: NONE Compression Reset Mode: AUTO (D) Min Compression Size: 256 (D) 207.8.15.0 /24 network 207.8.15.21 NetServer 207.8.15.10 gateway 207.8.15.101 start of dial-in pool my at rest routing table looks thus IP ROUTES Destination Prot NextHop Metric Interface 000.000.000.000/0 NetMgr 207.008.015.010 1 eth:1 127.000.000.000/A LOCAL 127.000.000.001 1 loopback 127.000.000.001/H LOCAL 127.000.000.001 1 loopback 127.255.255.255/H LOCAL 127.255.255.255 1 loopback 207.008.015.000/C LOCAL 207.008.015.021 1 eth:1 207.008.015.021/H LOCAL 207.008.015.021 1 eth:1 207.008.015.255/H LOCAL 207.008.015.255 1 eth:1 255.255.255.255/H LOCAL 255.255.255.255 1 eth:1 but when the dial-in connects, i loose the gateway IP ROUTES Destination Prot NextHop Metric Interface 000.000.000.000/0 LOCAL 207.008.015.101 1 mod:5 127.000.000.000/A LOCAL 127.000.000.001 1 loopback 127.000.000.001/H LOCAL 127.000.000.001 1 loopback 127.255.255.255/H LOCAL 127.255.255.255 1 loopback 207.008.015.000/C LOCAL 207.008.015.021 1 eth:1 207.008.015.021/H LOCAL 207.008.015.021 1 eth:1 207.008.015.101/H LOCAL 207.008.015.101 1 mod:5 207.008.015.255/H LOCAL 207.008.015.255 1 eth:1 255.255.255.255/H LOCAL 255.255.255.255 1 eth:1 from this i can see that i am barking up the wrong tree, but do not know which tree is the right one to dog next - i am studying about adding the service httpd (only have telnetd and tftpd now) - do i need that service added also one or two unimportant side questions 1 - is it possible to turn the paging off for a list/show so that it does not want a <CR> after every 24 lines or so 2 - how can i assign a static IP for one user, but let the remaining ones draw from the pool 3 - where is the FAQ - i have been reading through the archive but missed the FAQ so much to learn and such a short life TIA for any suggestions and help rendered =================================================================== a Golf Tip - Don't pick up a lost ball before it stops rolling 8-) ===================================================================

Thus spake FBSD >BTW, I posted a question about the number of IP pool members. I found >that the NETServer would claim to run out of IP addresses if I set the >"Dynamic Address Pool Size" to 16. (We have a NETServer 16/I) Does the >pool size has to be larger than 16? Isn't this in the archives? Certainly should be in the FAQ. Because it counts the console port as a port, so it needs the number of dialin ports + 1. The additional one being for the console. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I am having a problem telneting into my hiper arc card. It all worked fine until I used the Hiper Access Router manager. When I made a small change to a different user, I was asked to save (which I did), and have not been able to telnet into the card ever since. I have gone through every possible option in the router manager, but have had no luck. It asks for my logon and password, but as soon as I hit return after the password it disconnects me. If I enter the wrong user name or password, it prompts me again. Any ideas? Russ Miescke Power Web Connect russm@powerweb.net

Howdy. This is a generally non-technical request for those of you with experience with both TC Netservers and HiPer ARCs -- how would you compare the two? In general, most of the configuration I do on my Netserver is done through telnet. Some of the commands do exhibit an odd syntax and behavior, but, in general, it's not that bad. I think the main deficiency with the Netserver that there's no good way to get a list of connected users through SNMP. How does the ARC compare? Thanks.

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

Thank you for your recent mail concerning unsolicited commercial email from 1stlook@whereever.com. If you take a closer look at the email headers you will notice that this mail did NOT originate from sundial.net. We do not permit unsolicited email by our users, and we never have. Our only involvement with 1stlook was that we sold them space on our web server, before we realized that these pages were to be referenced in unsolicited email. Once we realized exactly what was happening, we notified 1stlook that we will not be providing web page hosting for them in the future, and their pages will be removed in the next few days. This will terminate the ONLY service that we ever provided to them. 1stlook will not have a web page account, email account, PPP account, or any other account once the period of "reasonable notice" expires. Sundial does not collect mailing lists, sell mailing lists, or have any other involvement with the unsolicited emailers, and as stated earlier, it has always been strictly prohibited. Obviously, we can do nothing about any future email from 1stlook, since it has ALWAYS been sent from another provider. Sincerely, Tom Holderby President Sundial Internet Services

I am the not-so-proud owner of a TC that I bought a month back. I have 50 Courier I-modems setup with Livingston Portmasters that never fail to perform perfectly. The TC disconnects people for no reason. The CT1 has intermittent static that is only fixed by re-seating the T1 card. I have intermittent problems with lower than normal connect speeds. My customers using the Couriers love me. The one's using the TC hate me. I need a fix. Any suggestions other than re-seating the cards is appreciated. Sincerely, John Scrivner John Scrivner (john@mountvernon.net) President (john@scrivner.com) Mount Vernon Net Inc. (johnscrivner@cablenow.com)

Krish: Thanx for the info. But... please see below; On Sat, 28 Feb 1998, Tatai SV Krishnan wrote: > > We use a NETServer 16/I for dial-up access. I would appreciate any > > pointers on the following: > > > > 1. Right out of the box, there is a default init string called > > "USR_int" with the command of "ATS0=0" However, the modem(s) ANSWERS > > incoming calls as if S0 is set to a non-zero value. I've checked by > > issuing an "ati4" and confirmed that S0=0. Why is it answering when > > S0=0? > > There is a reason why thee is a INIT script in the first place. The init > script has to set the modem in a proper way for it to answer. Here in > this case, when a call comes in, the modem senses the call and informs > the above layer about the call - which will then tell the modem to answer. But that doesn't explain why incoming calls are answered though S0 is set to 0 by the default "USR_int" init-script. Is it because the dip switches on the back of the NETServer overrides the S0 setting? I thought the dip switches are overriden by AT commands. > > 2. If I have the modems use an init script with the command of > > "ATS0=1", the modem will answer but will IMMEDIATELY hang up! Is this > > a known problem with NETServer? "ATS0=2" seems work fine. > > > ats0=1 is to tell the modem to answer on one ring, which is good for a > modem connected to a pc, not this this case. The modem should inform its > above layer about the call, when you set ats0=2 it will work since the > modem sense the first ring and the calls is told to answer from above The reason why I fiddled with S0 in the first place was because of this; everything was working fine for the first two weeks we've installed the NETServer. We let the default init-script "USR_int" run and set S0=0 but calls were answered and that was that. Then one evening, one of the interfaces (mod:9) was NOT answering any calls at all. The user would hear the ringing tone but the NETServer (mod:9) wasn't detecting the incoming call. I've tried resetting the modem but nothing helped. It was then I tried setting S0=1 manually. It sure did answer after that but that's when I discovered the S0=1 problem. S0 is set to 2 now but any ideas why all of a sudden, with the default init-script, the NETServer stopped detecting incoming calls? There was a new problem tonight; PPP users couldn't get authenticated on a particular interface. Win95 users would get an error message complaining that their "server type, protocol" settings were wrong... Meanwhile, the NETServer would log the following: Mar 2 00:27:30 term1 At 00:28:03, Facility "Telnet", Level "UNUSUAL":: Bad state/event combination: link status update received in state: 0x9 Mar 2 00:27:30 term1 At 00:28:03, Facility "Auth Facility", Level "COMMON":: The connection on if mod:4 was dropped for user UNKNOWN What's "Telnet" doing in there? BTW, I posted a question about the number of IP pool members. I found that the NETServer would claim to run out of IP addresses if I set the "Dynamic Address Pool Size" to 16. (We have a NETServer 16/I) Does the pool size has to be larger than 16? Thanks in advance for any pointers. fbsd

Just testing to see if the list is up. John Scrivner (john@mountvernon.net) President (john@scrivner.com) Mount Vernon Net Inc. (johnscrivner@cablenow.com)

On Fri, 27 Feb 1998, I. Dwayne Koonce wrote: > Hello...I'm new to the list, so bear with me if this has been asked since > the last message in the archive... > > We're currently running Ascend RADIUS on a Linux box for authentication & > accounting for two TC's, two Ascend's, and a Portmaster. We've just > decided to expand the information that we keep in our logs (in a MySQL > database, courtesy of homegrown patch), but some of the information we > want is sent by the TC's in the Vendor-Specific attribute, which Ascend > radiusd doesn't support. > > I've tried Merit AAA 3.5.6, which appears to go out of its way to support > vendor-specific attributes, but it logs them as an empty string and > outputs errors like the following: > > Fri Feb 27 14:01:26 1998: generate26: Vendor 429 attribute 0 unknown > Fri Feb 27 14:01:26 1998: gen_valpairs: non-encapsulated vendor specific > attribute Vendor-Specific=vUSR-000000c700000001 > Fri Feb 27 14:01:26 1998: generate26: Vendor 429 attribute 0 unknown > Fri Feb 27 14:01:26 1998: gen_valpairs: non-encapsulated vendor specific > attribute Vendor-Specific=vUSR-0000901900000000 > > ...which I see from the list archives that some others have as well. In > fact, it looks like there's been quite a lot of discussion along these > lines, but the threads appeared to mostly die out with no solution posted. > > So, my question is: Is anyone currently using these attributes > successfully (with source-available software)? If so, then what? -------------------------schanipp--------------------------------- Hello Florian, we have opened a new case for you under 6929, an engineer will contact you as soon as possible. Best regards Paul Brennan Carrier Customer Services -----------------schanipp------------------------------------------ As you can see i have a open ticket for this since 3 weeks. No engineer contacted me, i got no solutions etc ... We have someone from USR/3Com here today ... hope that he has got some solutions for me ... Flo -- Florian.Lohoff@mediaWays.net +49-5241-80-7085 aka flo@mini.gt.owl.de @HOME +49-5241-470566

On Fri, 27 Feb 1998, I. Dwayne Koonce wrote: > Hello...I'm new to the list, so bear with me if this has been asked since > the last message in the archive... > > We're currently running Ascend RADIUS on a Linux box for authentication & > accounting for two TC's, two Ascend's, and a Portmaster. We've just > decided to expand the information that we keep in our logs (in a MySQL > database, courtesy of homegrown patch), but some of the information we > want is sent by the TC's in the Vendor-Specific attribute, which Ascend > radiusd doesn't support. > > I've tried Merit AAA 3.5.6, which appears to go out of its way to support > vendor-specific attributes, but it logs them as an empty string and > outputs errors like the following: > > Fri Feb 27 14:01:26 1998: generate26: Vendor 429 attribute 0 unknown > Fri Feb 27 14:01:26 1998: gen_valpairs: non-encapsulated vendor specific > attribute Vendor-Specific=vUSR-000000c700000001 > Fri Feb 27 14:01:26 1998: generate26: Vendor 429 attribute 0 unknown > Fri Feb 27 14:01:26 1998: gen_valpairs: non-encapsulated vendor specific > attribute Vendor-Specific=vUSR-0000901900000000 > > ...which I see from the list archives that some others have as well. In > fact, it looks like there's been quite a lot of discussion along these > lines, but the threads appeared to mostly die out with no solution posted. > > So, my question is: Is anyone currently using these attributes > successfully (with source-available software)? If so, then what? -------------------------schanipp--------------------------------- Hello Florian, we have opened a new case for you under 6929, an engineer will contact you as soon as possible. Best regards Paul Brennan Carrier Customer Services -----------------schanipp------------------------------------------ As you can see i have a open ticket for this since 3 weeks. No engineer contacted me, i got no solutions etc ... We have someone from USR/3Com here today ... hope that he has got some solutions for me ... Flo -- Florian.Lohoff@mediaWays.net +49-5241-80-7085 aka flo@mini.gt.owl.de @HOME +49-5241-470566

Rev. Jim said once upon a time: >207.8.15.0 /24 network >207.8.15.21 NetServer >207.8.15.10 gateway >207.8.15.101 start of dial-in pool Pull out your favorite TCP/IP book and read the section on subnetting again. The NetServer and the gateway should be in their own subnet, as should your dialin pool.

We recently updated our 2059s to version TCS 3.0.2. We now are getting complaints from many of our NT customers that they are having problems either connecting or going anywhere after connecting. Has anyone else had this happen and how did you fix it. I looked through the archives but found nothing relevant. TIA Harry Landers =============================================================== Harry Landers, President Panda Communications LLC 185 Walnut Avenue Santa Cruz CA 95060 Home of CRUZERS 408-457-CRUZ (2789) fax 408-457-056k

Brian said once upon a time: >How old is 2.6 now? Sun is about due out for a new version............ Not that old. I believe it was released last October, correct? Usually Sun has a period of 18 or so months before OS revisions.

On Sun, 1 Mar 1998, Tom Holderby wrote: > > Thank you for your recent mail concerning unsolicited commercial email > from 1stlook@whereever.com. If you take a closer look at the email > headers you will notice that this mail did NOT originate from sundial.net. > We do not permit unsolicited email by our users, and we never have. > > Our only involvement with 1stlook was that we sold them space on our web > server, before we realized that these pages were to be referenced in > unsolicited email. Once we realized exactly what was happening, we > notified 1stlook that we will not be providing web page hosting for them > in the future, and their pages will be removed in the next few days. This > will terminate the ONLY service that we ever provided to them. 1stlook > will not have a web page account, email account, PPP account, or any other > account once the period of "reasonable notice" expires. > > Sundial does not collect mailing lists, sell mailing lists, or have any > other involvement with the unsolicited emailers, and as stated earlier, it > has always been strictly prohibited. > > Obviously, we can do nothing about any future email from 1stlook, since it > has ALWAYS been sent from another provider. > What is this? We are getting tons of copies of this and it is really annoying. Can you please turn it off? :::::::::::::::::::::::::::::::::::: :: :: :: bjay@ionet.net :: :: ioNET network specialist :: :: break out the blender and :: :: mix me a spam margarita! :: :: 1-800-360-5183 405-270-0999 :: :: :: ::::::::::::::::::::::::::::::::::::

Hi, How many ISDN calls can I have in a filled TCH chassis using Dual PRI cards and NetServer modules? I am assuming you can have 5 Netservers, each using 2 Dual PRIs for a total of 460 calls. Is this the max you can have in one Chassis? In this case there would be no async calls... Then, assume using ARC. Can I use 2 ARCs with 7 Dual PRIs each for a total of 644 ISDN only calls? How about with the EdgeServer PRO? Will this configuration work in a single chassis? 2 EdgeServer PROs, 10 Dual PRIs. So that each EdgeServer PRO handles 5 Dual PRIs for a total of 230 ports for each EdgeServer PRO and a max of 460 ports in the chassis. Some folks saw the chassis at ComNet that had EdgeServer PRO on display for Voice applications. Will HiPer ARC support Voice or will this only work with the EdgeServer PROs? Thanks in advance. ++++++++++++++++++++++++ mailto:turners@best.com ++++++++++++++++++++++++

Maybe I wasn't looking in the right place but does HiPer DSP support DNIS? If so, where do I set it up? Thanks. ++++++++++++++++++++++++ mailto:turners@best.com ++++++++++++++++++++++++

Upgraded to 3.0.2 this weekend, and put ISDN back on the quads. Everything actually (*finally*) seems pretty groovy. :) One note: I did set maxbchan 0 after the upgrade. This may have been the cause of my previously very poor performance w/ ISDN on quads. Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

Hello, We are in the process of upgrading all our equipment to Total control Racks, and have thus purchased the Security and Accounting Server for UNIX (solaris 2.5.1) and got it installed. It's lots nicer than livingston 1.16, but I habe one big question still open=A0: how do I import my 25'000 lines 'users' database into this server=A0without entering it all by hand (this works fine for one user) ?=A0?=A0?=20 I tried to figure it out, but the docs are far from complete on this point and I haven't understood the finesses of the import/export features of saUtil, and have found no trace of a similar feature in secdb. Has anyone done this before=A0? Thanks for any pointers Robert von Bismarck Petrel Communications S.A.

Looking to purchase (1) Dual Analog MP Card that will fit in a Rackmount 32 Chassis. Let me know if you have one to sell Thanks BECCOM@aol.com

does someone have the configuration handy to define a chassis with 48 quad cards and 2 hiper dsp cards for pmmon? matthew

We've had the same problem on chassis filled with nothing but quads. It turned out we didn't have Proxy ARP turned on. If you redid any routing and/or sub/supernetting to accomodate extra IP addresses necessary for your HDMs, you should probably double check all your routing configs. That's my guess. Good luck. # Kenneth Agena keagena@aloha.net # System Administrator GST Hawaii On-Line On Mon, 2 Mar 1998, Mark van Wouw wrote: > I have a problem I haven't seen mentioned on this list. > We have a number of HiPer DSPs in various hardware configurations > all showing the same result. When a connection is made through a > shell (as opposed to PPP) I get the "*** Host Is Currently > navailable ***" message. In a doubled up chassis (12 quads, 2 HDMS, > and a netserver card), for example, if I call into one of the PRIs > going (through a Dual PRI card) to the quads there is no problem. > PPP connection are no problem either. If I dial straight into the > HDM I get this message about 90% of the time. The host is set on > the netserver and as I said there is no problem going through the quads. > Has anyone else seen this kind of problem? > --- > Global OnLine Japan - The Provider > Mark van Wouw Network Operations > vanwouw@gol.com 03-5341-8000 > ZZ - I'm not sleepy, I just forget to escape sometimes... > > > - > 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. >

I have a problem I haven't seen mentioned on this list. We have a number of HiPer DSPs in various hardware configurations all showing the same result. When a connection is made through a shell (as opposed to PPP) I get the "*** Host Is Currently navailable ***" message. In a doubled up chassis (12 quads, 2 HDMS, and a netserver card), for example, if I call into one of the PRIs going (through a Dual PRI card) to the quads there is no problem. PPP connection are no problem either. If I dial straight into the HDM I get this message about 90% of the time. The host is set on the netserver and as I said there is no problem going through the quads. Has anyone else seen this kind of problem? --- Global OnLine Japan - The Provider Mark van Wouw Network Operations vanwouw@gol.com 03-5341-8000 ZZ - I'm not sleepy, I just forget to escape sometimes...

This is a multi-part message in MIME format. ------=_NextPart_000_001E_01BD4600.3CCB6970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I must be missing something. What do you have to do to preserve the database information when = upgrading from Sec & acct (4.3) to Sec & Acct (5.0.7). The only reference for this was in the newly created 507 help screen and = it didn't make sense. Thanks for your time, Jim Faulkner ------=_NextPart_000_001E_01BD4600.3CCB6970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>I must be missing = something.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>What do you have to do to preserve = the database=20 information when upgrading from Sec &amp; acct (4.3) to Sec &amp; Acct=20 (5.0.7).</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>The only reference for this was in = the newly=20 created 507 help screen and it didn't make sense.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>Thanks for your time,</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>Jim = Faulkner</FONT></DIV></BODY></HTML> ------=_NextPart_000_001E_01BD4600.3CCB6970--

The common thread between the NT customers that can't connect to TCS 3.0.2 is service pack 2 or lower. A quick upgrade to SP3 fixes it; a free download from www.microsoft.com. I had to have them dial into a non-upgraded Netserver, sometimes long distance, to download the service pack. OR they can call microsoft support (for money) and wait for a CD to arrive. -CH On Mon, 2 Mar 1998, Harry Landers wrote: > We recently updated our 2059s to version TCS 3.0.2. We now are getting > complaints from many of our NT customers that they are having problems > either connecting or going anywhere after connecting. Has anyone else had > this happen and how did you fix it. I looked through the archives but found > nothing relevant. > > TIA > > Harry Landers > =============================================================== > Harry Landers, President > Panda Communications LLC 185 Walnut Avenue Santa Cruz CA 95060 > Home of CRUZERS 408-457-CRUZ (2789) fax 408-457-056k > > > - > 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. >

On Mon, 2 Mar 1998, Mark van Wouw wrote: > I have a problem I haven't seen mentioned on this list. > We have a number of HiPer DSPs in various hardware configurations > all showing the same result. When a connection is made through a > shell (as opposed to PPP) I get the "*** Host Is Currently > navailable ***" message. In a doubled up chassis (12 quads, 2 HDMS, > and a netserver card), for example, if I call into one of the PRIs > going (through a Dual PRI card) to the quads there is no problem. > PPP connection are no problem either. If I dial straight into the > HDM I get this message about 90% of the time. The host is set on > the netserver and as I said there is no problem going through the quads. > Has anyone else seen this kind of problem? We've had that happen using Livingston RADIUS 1.16 when we forgot to set security on all ports. If you upgraded from 3.5.34 to 3.7.24 you might have forgotten to set security on the extra ports after 52. Just a suggestion. :::::::::::::::::::::::::::::::::::: :: :: :: bjay@ionet.net :: :: ioNET network specialist :: :: break out the blender and :: :: mix me a spam margarita! :: :: 1-800-360-5183 405-270-0999 :: :: :: ::::::::::::::::::::::::::::::::::::

If anyone associated with 3-Com can look at trouble ticket 44522, I would really appreciate it. I'm about to throw this new chassis with the HiPer Arc out the window and run over it several times. We're currently talking to our local Bay representative for a replacement for this unit, but I'd really rather stick with USR. For those who may have had a similar problem, here's the basic scenario (as posted previously to this list): Whenever we set up the new hub to accept calls (we currently have another TC-hub with the Netserver which doesn't have this problem), it arbitrarily assigns IP addresses from other computers on my network to the MAC address on the eth:1 port on the HiPer ARC. Eventually, no computers on my network are reachable through TCP/IP. We're consistantly losing customers now because of the Quake lag problem this is supposed to fix and because we can't turn up any more telephone lines (our hub with the Netserver is maxed out). A fine bottle of Merlot to whomever can solve this problem for us. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

On Sat, 28 Feb 1998, Jason Brunette wrote: > Having read through the usr-tc archive, I've noticed that many other people > are having trouble with their TCs and Quake performance. I did quite a few > tests with QuakeWorld, and have come to this conclusion: > > The more packets being sent and received by the user playing QuakeWorld on a > TC, the worse the lag is. > Does the "PPP in modem" option help or hurt? I've always had it enabled and Quake players have not complained. Seems like it should help but you never know. --- Brian K. Uechi Email: brianu@lava.net Technical Support Engineer Phone: 808-545-5282 LavaNet, Inc. FAX : 808-545-7020

On Sat, 28 Feb 1998, Jason Brunette wrote: > Having read through the usr-tc archive, I've noticed that many other people > are having trouble with their TCs and Quake performance. I did quite a few > tests with QuakeWorld, and have come to this conclusion: > > The more packets being sent and received by the user playing QuakeWorld on a > TC, the worse the lag is. > Does the "PPP in modem" option help or hurt? I've always had it enabled and Quake players have not complained. Seems like it should help but you never know. --- Brian K. Uechi Email: brianu@lava.net Technical Support Engineer Phone: 808-545-5282 LavaNet, Inc. FAX : 808-545-7020

Thus spake Harry Landers >We recently updated our 2059s to version TCS 3.0.2. We now are getting >complaints from many of our NT customers that they are having problems >either connecting or going anywhere after connecting. Has anyone else had >this happen and how did you fix it. I looked through the archives but found >nothing relevant. Saw another response to this as well, so it might be a better help than my response, but you also might try having them disable software compression as NT and TC's don't always play nice with software compression on PPP links. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake matthew > does someone have the configuration handy to define a chassis with 48 quad >cards and 2 hiper dsp cards for pmmon? Wow! How do you fit 48 quad cards in a single USR chassis?! ;) -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

--------------84505DF949F040E15E4EE067 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You have to import the accounting data and the user data. Postmaster Account wrote: > I must be missing something. What do you have to do to preserve the > database information when upgrading from Sec & acct (4.3) to Sec & > Acct (5.0.7). The only reference for this was in the newly created 507 > help screen and it didn't make sense. Thanks for your time,Jim > Faulkner --------------84505DF949F040E15E4EE067 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <HTML> <BODY BGCOLOR="#FFFFFF"> You have to import the accounting data and the user data. <BR>&nbsp; <P>Postmaster Account wrote: <BLOCKQUOTE TYPE=CITE>&nbsp;<FONT COLOR="#000000"><FONT SIZE=-1>I must be missing something.</FONT></FONT>&nbsp;<FONT COLOR="#000000"><FONT SIZE=-1>What do you have to do to preserve the database information when upgrading from Sec &amp; acct (4.3) to Sec &amp; Acct (5.0.7).</FONT></FONT>&nbsp;<FONT COLOR="#000000"><FONT SIZE=-1>The only reference for this was in the newly created 507 help screen and it didn't make sense.</FONT></FONT>&nbsp;<FONT COLOR="#000000"><FONT SIZE=-1>Thanks for your time,</FONT></FONT><FONT COLOR="#000000"><FONT SIZE=-1>Jim Faulkner</FONT></FONT></BLOCKQUOTE> &nbsp; </BODY> </HTML> --------------84505DF949F040E15E4EE067--

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --416219727-1036599753-888893401=:6985 Content-Type: TEXT/PLAIN; charset=US-ASCII For what it is worth... Attached is radius server code, which supports USR vendor specific attributes. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 2 Mar 1998, I. Dwayne Koonce wrote: > Hi. I'm currently trying to find a RADIUS daemon that supports logging > USR's vendor-specific attributes, so we can expand the types of > information logged by our TC. I've had no luck so far with Livingston, > Ascend, or even Merit. While looking through the usr-tc mailing list > archive, I came across the following message: > > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > To : > > Date: 28 Aug 1997 06:44:09 -0500 (CDT) > > Re: (usr-tc) Disconnect causes > > > >We do provide Radius server that supports our Vendor specific > >attributes. We also have given users modified livingston code that > >supports these attributes > > > >krish > > Is it possible to obtain this source code, or patches against Livingston > source, from US Robotics? > > Thanks in advance for any help > ____________________________________________________________________________ > I. Dwayne Koonce E-mail: dwayne@txcyber.com > ____________________________________________________________________________ > "It's dangerous to be right when the government is wrong." --Voltaire > --416219727-1036599753-888893401=:6985 Content-Type: APPLICATION/octet-stream; name="errs.1.2.1.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.91.980302205001.6985C@bubba.ae.usr.com> Content-Description: H4sICPejkDQCA2VycnMuMS4yLjEudGFyAOyc3XPiOLbA+9X5K1zVL7NV44y/ ga3aBwKkm21CGCDpufclZbACrhibtU13sn/9Hsk2+OtIysP0vXduU1ubHqKf jqTzoXNkOde/kSRJf/vwZ3503TZ7jgM/dcs0bfpTN+z8Z/H5oLu2bRum0bPg 37phuG7vg/PhB3xOaeYlIPLbi6gdSfiT1HXTtopJ9T78H/lc5/q/3n5Lg10U J+TP0L+hU/Xi+qe24Vp6zwALcFyqf8t14buf+v/TP4nnB6fUv4KfRy9N6U9v u82uNqcg9P3N4apocE3//eHn56/2KfwftOxv/qxdQDL+647r0sBP/R/a2z/j /4/W/5+0Cwjjv2XR+G/1DNdw7B7Vv92zf8b/H/EJ491zEJKrbRiQKEuv6DTT qwOJTj+j/f+7+F8YwXXqHY4h+WH+b7u5/7uQ/OvMhQzHNfSf/v8DPh+vPirr fZCqNAqo2zjKvCBKVU8NgzRT42e1sAn1+z7Y7lUvIaoXhvF34qtZDOzBe4Fv TtkeGgVbLwviSE3Iv04kBcaLoNWeBIlKom3ydmS/fSFv10woAZkJCHkOSOir ARX6zQsDX93HaRZ5B/h9nFC+GENJpQSG6RfYLyk5ksTLYDybN3UTetFLqlLM 26R/o51SHsDWAK4+jliv6hwkKcoX8nb1UWt8FK39ubr66/t/RsD/YU1/mP+b hf/buqmz+t81rJ/7/0///9/o/3/h/d8PtnSFvOTtx+X/hmXD19T/bdfomb1i /4eS8af//8/5/8US1CzxojRknp0yjzx6SRpEOwBrjr4jEXVE+A0EgPQIrUl6 rarDMMy78LZ5FxBCAN3Gh2OcgtdCiBlmWRJsThn57dELT0RdeBAXAKXO/o19 A42IR8NP2RJ6gDGnR7INIA74qgdOH7F2tup7madmb0cm/pFFlMtXVPzfqfcr KXQFY9VUXTMdS423GYH6B/o9gi8k8L1dfKcGkRqR7HucvECMyUBK4pOEtowy siO0qWWqmyArBgvNN8EOQp4feFHeWP1lH+z2Oc2C3t8Ah0ERGVYrIh7MN4i2 dOr0o+t/Z/9TP92tf1XVf3oRzNaAfxmDns4mOIlOhyI0ss7Z3NU0g/Lep4Jo ZKRWnav+e5DtK2oH/nE4e5i01U+89E31/EMQwQ6RsF9c5/JeWdmQr+5wvV5O bx7WEwV0QDuC7xqRVFXVPKJ+VG4TCMK+tkjiLN7GofoPdbFYwPc9RfmHaii/ lCsNUTz2QWuwfFdXZxFq/nmAuWg0mqv1j1H8zBXewhZemoJu/Qalmnxs9Hm4 0DpYS4CxTUebNsXZxc/c+jBsESd11imxfIG612RFkm/BlmhrcIDie1fANRVS fnpy3BDmQNL0Ms4+f3oFNifZwUtfLthAClvGJxZ2LhrXpUZ5G4QZLM9lPQ2D q7sCu1s/NAzMlBI3gpBHV4XmIDln8blZvAsi7TNkQw15NndVcqxQehVzZMSt RwtmZhXOrXMfm+B96Hd5gmr0+I5HjfkOFsTb1VzW6HOxceCFG2/7os3j+qoM JLF6hDD1Gtaa3OT1GORRrhEeCluhUZxnmLWpmaaMgU0Xf1BXYBtOjln84LCH lJxEO6KtMq8i0LQFociruugFc7jYKjdhbR0cCMzvgvX45jX1Q9KCKNfnc2uS wF7DNKANtxdFmAM+N6KL4rMloejZyy2dvyqAwfctzuLHhvlwBU1pEQT5SFLZ DvgahwD7+tZQG8MsLpa76my4bri5ZUti89ivCLQcSexTEp+OF8yVsebhEZKC tRe+aLMgogZt9eT2kDNX+oLVfx/33zQlpAIHvGEOt9uMaeCUVndI1RZsIowb k9B7Y1Z92ckNCW4aHU+Zdp/nlwVnSnD3p6wJ2pYEVzptJXew+bbCsGFZ2FcS Fecd4ioLY7vSy7KAMH2ZXk9+Waqg3ZfgythCtJEHqTDjBhLc3SnMgsqiKo6u 8NaRWj7s/6coUxTHUNCQRXPKczS/rLmrC2MP20yr5ksxgSUyZhYcgkZ+4Zoy iQKNB7QHRXHrweojjWqHY1nSpPv4FPrqhkAizuqH7T7+VdXZv6O4+E+fPHuw pqpx3RUiaWetj2s30hL1YbWEKjB8u5SJrHbK1KA8xioHsw8g/J3rH1oY5hUR ec26dlcoK2I6zvou2YgPrOyZFoXKulI10VoFiuzWNnZ1lVdY6B43zhcFaj1R y+VwPH1Yacu8HlcMUfs7L4KkC9qn8SnZklQx6RBpsaBSG0qLoSlKq35QcuXT 75VSTlezIhjn7Uy83Tktq/RrSTSv9m/j7SEwbMDtyoE4eMthpaL9RvL2Lt6c +RyzzKLrHqfry/Fo0XFfYoZUAms8uDpXyGpZkF001KjUFAUqZ6WimtbvV7Mp bWBWei0LKHb80uq6+K2izGE/Vc7W2P79TRJ7/tYDA2yJP7eZwRKTSKnYBNqL VrS1KiOt1lB1S20XWdh4q00evUj7p7eNNynJSx9YG4PKY+aoFpq5SKnVVgo4 dRiRrCqj0WAZ0v+u6qPZA8gchcSrekmjCQ2yd7Ae1MrYWuTJSmP+zTSGtqLB +SK5o0V8rGqi1QC+oHsWTYfvo4qJcxs+Pytg3/QIqP5UoGO45xZt22r+Po9w relUWszirRe2plPtghzijAqxWKxmx4vPMX2YQW2/ckQW0GOsA1D5wOnhZhrA ZuKTI4lojg8w/TKKs/x4DHbQLD+EPMKa01NIurccC5fL4/8ojp6D3akoJRue RnUNgSBvAxovimntUnwqli5q/NVLIupBDpse2w/BszcxTP58VLq97I0pazO/ G13OX1PYD1kcgGnGEJdK5nLa9kTb50kA9dD56bCBodCYBY51Xy3s9Fddd91G zsLFp5E2nk9XF3zS5+OswkvSspvhfFqTPhmgOOzpUURCFfvorze3tNoozx1b HUy+dZ7i1Tq4mTRTqCY/phtCrXio8uZt7XShMnqYt8bcu7sHCt/2ePAEdkRE OINdBC4yEm28nlDe05b1wpUuu8OZ9jQKMlC2tnzNU+JmH2zaY5y/hVQGpwt+ JJa/RuWD0Q5F8tcc+cDf4DzYHew7EDTJgT21PCWkbXeGHK+t97CL7ePQr/GT vo3zkAGeYAKPcZg1Dt0q8k2O2b5CSIBQh/XAeAvnF/F3mu+coER/K9y2zXPG P/IgzjWqnAY/6Tvi9VuFcYb6/QDnV2/RVhum9P/vaicoVf33cP4+CXZ5vTmM UroUjV4Y38d5aH7Kq4ruVWA8x/5hz4hIUfdC9u+ljVNNyg849nvrBSHYrJbF WtlVrRcmn7N+k3+B+QX/RmfA+Fue/DBPjieRt4E9o2v+PV1i/hD2uipfqv8J R3/FThM/a0vYVtJWF4x3cf4cN8vD0MZZKB2/3efab+KBA8Kmt6LlbOf8DSl+ SbYECh2/zXP8/yaMty+I7DPvCPlO2WfeleDT7hEwnqO/JYF8LYjSslJuDoHx fQn+E6R9GWJ/HPuHbYNW3ZC+pV6YIuMfCu3v/lmraHJ2eUDE+BsZ+72hmVO3 /LEMzzbA4jQ/rfMTGb705LQt/1aGfzim++A5S9vj7+vS458Pv7Tl9w2e/y7p yNPOBxkFz0v7zvGrI/ac+VuB/WuTJImT/Dix0RHlRzp//OvkhA2f8WOO/a3I 9pQE2VtxWtOaBd1/xxMJHjz42LEIlL8d8uMnjbzaPC530FonNP4aHP+/oWtf JP9dCSyzP87+uaKlIbtxot3NF9oMPLnmxmz/HEjxj7a5gUzkofb0k+mPM/67 TfA0yp4Wy+kTTYWemnkM8AYv/yv49fjuiVpAN++8Q/7Ri55oUKvyrpC/KVTw 9JDWYyjjOfNf7N/SAMr8jidmZ/vhxf/8AYF2c0rLw/v2/m/YPPtlpXdnyZbz t7quF8UTVNd0PM5Yoz9cS2WbFrtncy4fewOsNi0TLDCVddyco8OJ0VSnKFzy E05tOybsNBLtgnXAC9K39FnomFdcT1xOkPp9YBmstoco8UwSEsFg8othFZ6X 5LAKl63wqDtJB56T5IxXusr7FNqsPHgAIu3Ubu/XXr+r/1TYv115nPIJrOm7 96ZNF+eLNV3CjF97ZktYB9sW5p6vFpxPxlLCjsJGo6G6ZG+A1g+OWo719elh tXya5ldqnqaL1pwGzDGQ85gW/kcHbojwe650Sx7vkm7L4qvhogN3ePjjYv6E OgzDOTG14DsuvlX4nkj8nAS7/SZOuvF+4+5JDc+P1Z+KA/ynR7OFD4SjL8wU Gb3HG/36xLaSxmlzFd/w8Gnkk1eVt/Zb7uhHpyx+fubxPk98viPxcILjSXDw kren8Xz1lO9MHfgzqroVu1WKd0BxepMO03whfX7TLZ7hhoT07g4YbuL4WxrG O23tHfGlMyzxSVB+lto+DmL8QJaHNKiLH0ryHcfRjOdUcl/IG3uIhWfywHMy 2Yeo8tIG3eNbZ8jAV7KMfGNYBOEO1F7bC9oJxA2BrQMKFO/obYIwyALSrLIG fZ2TAKyOhD5NeC5TkKB1SgU8JwG4817LJU0R2+jrJlc3LAObvIJe20lizlti fky2CXuO1MXb3FPWXK42DHcx1Ev7Q5vnnXJeHnB29sB4l3fKwY5ntOF2q911 OBjjOVn2ungmhnXA+L7c+OlRT9Y4JmW8x9E/lKbVPlbBv0lL/obzlGChChJA 4Lc8/g8x7/OeMrB7yfT6Gm6/hHPKT2/AZV74wpP/zKmSk8Df1S5Ut3mD679x /CziOf5LbzzzT/mBN3lVWuRraD5U8Hg6yHDsrYASx9PB/MEcWiLmOMd76bM5 nC54VzD71TYJjpmB8ng+uCT02QzOM7zPX7ycNlHpAynpJoZ7MtItVPpGSrqF 4VsZ6TYq3ZeSbmM4kZHuoNKfpaQ7CG7qMtJdTLppSEl3MdxE8eKWW4hFDYbj Hn8OmOVVY23pRbVjOcA5Gza7eoKW2AWPV4BF5dR+26aKu9ynguTQuJvd4nv1 m4rlpXzsvqLKuSZb3C7svEE7HI3WT+vJ8g5q4snyaTn5/WGyWpevaMiRs/vV +mk0XC6nk2V52/IdJMh9nI7K65uWHDkdzyZP6+nd5P6hHK0tR64mq9X0fl6F HTlyOL6bzmGJVpP1+VLr+8ib+/sS7cmRi/vl+mmyXN4vL+9myZHz4aoBqgN5 sm4IqqG/B61Mk76k9Y6ZPsznk8l4Mi5f1HoHulhOJneLdcEa1jvQ1cNqMZmX Yg1pQ2J2C2MePg6ns/yVLTl0NJzNboajL9XXodx3uGldr4akLX2m3tbw8P4l drCTSXUand+KSS83npv3p9jFBqJNo5QkHc9Vz36BkvRyX9cT5bNftMnF6qG8 xwJlkpccGmSfS9KrEAS5/zVAyc8PN/nlnftTxq4R1PaZil+00Vsv4go1DBT9 6mXbvU+PS7oPC85+0bG8u0P+vKS4+tFCLRSdRpUCXps032K8+EUbpavDY89+ IZJKjbeBurJSW6yB21IF69SR0ZdBO9Vj4NZEH4eei216paT5Jp/OQfMnwViV YRpclD0Ex1DcmqrPr72sfYPNtDjmX1wY6ATpy44oOo/ZFVNtDQW1NiYZe6pV e5WDh87i+KiNTknCbmw2aBO3pv8i9GpxZ2Qp3pdE0SV9jQ3j2CuTKDqL05Qe na2CHeTDHShuTcvtN5CaHCAK+128hVsTGC57Z5K9TaKtvgcQb2qowYvf5FAc 82ze6M3S+oAtU4TW7gPUX6Lkeg4O0hcp8eD/UnuAzN6q+VZ7mVIaBdffkfRy vmm50uis8Va41ZNGp5FXG7KFWxN7PYXWCMmztyW5lmpScWsqHzyyl8yK3a76 sqqty6Hsok59jW1ObKJ+TqXlF1Ram5Zt8tFphJGqbYmlwgJBiccemldvt9o2 H2XXUrpZ2+Er5yYElv6tpnZaYOPWNMzon/iiovLZNnuxebEp/9suWtFHfgFH m7xuCfEBt3mxicpCOPbqpXiF2fOS8an5Rr6jC/WKkKpjSHsObFzFay8FilsT FOf03ZOYLhddLdima8W5g1tT8QZt+ZJH5tEXSOPLqYJjS+05+WtFdZNwHPGe 08VR1JXcc9q803vPnlPjnT4n0dvGbNepJ4reBux4DwblDHiJ3i7moK7+Lqnn Csmn79y+S2oNNWVyxNJ9agHKtXhoFkSnGMx4tBy10wrXfhda1Y7L2elqF7XY 07haneO6wuhfHsU18+meIY3SkMr+2lGJ4itcuRk2YklqY4PtWfJoQ2yPE/3P lxGnXX+xRe05EmjH5kpRfIXpBSREYI72+Gi3wBzF/XVt/LY2FsvpbxP6/9rl llaJ4v66SE8ac7wjBO9Nq8xR+/rV5Wih+Y4Ifbg/AY95Q5Jpg0s+RC9R/D3q TsNRkhrg3S6jX3eSFkqOT164NubDETJam0uyjBiBHZT8/eT5PNJFyXVSuBxC 9lDyD9Phon3uPB8tGx3wgDvPR8scB7sg61qryuELgg5hf4p3HaINQ0LqMOpS kGEKUBvQ7tkalgjtFlk/fMGlIgPGLWkF21tIcPs1cFOaZHuSRCTDrMLAbQkS JkjQum5AtQ5fmqjdd7k2bAx4KHfMps414eXKtExknUyTJ5XrOiZuEvQpV3E9 Ll+rBm7iep2uxnOeu5ouFz0mAWoTJq7XUfhCfAilWCQ1cb0ys13EcZj/pQt6 CYfJV8yBmAGRaWWBFEsXM42IpFiGmKFLU1kVxeJsKOtOlSkAWRKOTOPdp9La FMWyxXGDBrpPFwNVLEcuYFQgxcLNYj4pZsRujy7pn1HKFWT1xMw6fiERPb4p FdTn7TOmXWRKXRZo4fbwNUhICIGlNHxv29iKTTzpmEQgckt8PDTZthDGvc52 rkQZxBTLIAxdN7jwkG5x/qGzB4D529V4l4UcmG+sVDLWAcD4il0MonvaAEts WsiS0b9eLNy2ODBu0Kt9nGSfvVOI6AzgvlhVO38adawZwAOeW+AWwmBBMkQl z+MIhLeVBbAhhPFhCxKii+Q2DzDfwmapPws6B81gWwwjkwbYkZLcNWmAXVnJ LR5g3MI+r0oD/Rpk+0fLaauqLwnHp6zBAzzgmufnYLdnl3nbggE2Rem2w3Kk Wfyd9VGXbPJj2KTLmxXATDlnZLxCAdyebkgYbqHOn8XRrubEFHOE2Grf8H2K 4WawGq2mE39HijygGF2vUvjy/zqHYejazWLVUfbyOUuvc6Yk5zY4S3acZh20 JTnTrnOOJGf365wryfUa4+xJcoPGwvSl1+VLbT0Hspx9bVfJSlwXgO51vyrR kLUYY3BdG6shazJWvzFUWZvpObWlqRa3AuU7DaeQtZqH+Zf5/df5GTZkzcbp Xbu1OcrajWk0wL60Y9QNx5C1HNOtg6as5Zj9BihtOYZTIyFaX8Kb6G8H4QFO ROIhTkTiQU44WjTMiUgW6P64oI40iYc6EYkHOxGJhzvxCmEBT0jiIU+I4kFP iOJhT2iAeOATagYPfUJzwIOfCOWEPxHKCYBCy8dDoNhp0CAoRPEwKETxQMhF lY5AKG1LRkOmvC1ZVgOVsCXFyo1eUUxHprVbtpawGMXWy9Y9mdZ22bov07pf th7ItB5YlsXaWxLqVxzddd28uSHTvFxDy5RpbZ3HYsk0t89jkdGnU2rIktGn 0zuPRUahTv88FhmNuqX+LRmNusZ5LDIqdUtzsatPD0V/YRDPMkQknmWISDzL EI4WzTJEJF5OiUg8yxCReJYhIvEsQ7xCWJYhJPEsQ4jiWYYQxbMMoQHiWYZQ M3iWITQHPMsQoZwsQ4Rysgyh5eNZhthp/sPetT+3jSPp/Gr+FawkVYmnIll8 SH7s+eoc2ZnRnmP7LHgyV1tbLoqkLG4kkkNStrV//XUDfAsQQV4mM7NrV2Zs kcAHoNHobnzCQxhlNGYVRxmNWcVRhiDr3q4Ao1GNxAFGY1ZxgCGsKS++ECfm hBfCxLzoQpyYE1yIE3NiC3FiXmghTM2NLMSpOYGFODEvrhCn5oUV4tScqEKc mBdUiFPzYgphal5IIU7MiyjEqbkBRdORw820BelMW5DOtAXpTFuQXbQFN6Bo ytlMW5DOtAXpTFuQzrQF6U5bkO60BelOW5DutAXpTluQ7rQF6U5bkO60BelO W5DutAXpTluQ7rTFVtZyRLGnt9ChrWiC/ZYHaCYtSCvSgrQiLUgr0oK0Ii1I K9KCtCMtSDvSgrQiLUg70oK0Iy1IK9KCtCMtSDvSgrQiLUg70oK0Ii1IZ9KC dCYtSGfSgnQmLUhn0oJ0Ji1IZ9KCdCYtSGfSgnQnLUh30oJ0Jy1Id9KCdCct SHfSgnQnLUh30oJ0Jy1Id9KCdCctSHfSgnQgLUh30oJ0Jy1IG9KCtCEtSBvS grQhLUgb0oK0Ii1IK9KCtCEtSCvSgrQiLUgb0oK0Ii1IK9KCtCEtSCvSgjSR Fm+KmIJ71c0efbCIAj9Yx9Wldbszps+LnHt7RUiRZxVdj5M/v/f8++JD+rZU thQAe0Vz7+mNWdPUvIJrcU0zQqnkypauHEJ0v886zi5y+6k4Q4m7h02EYNte kvxs6MLzPiQRdLy1oGFPmwhh5i6X2sAQLjo2ZeugiRCGUnXQNaEYSoFfkyRF cjiUbYVQEEeNCL77ANpAX3CPmzmWk8PgaCZeAN4I8ahrn6xneos8t0M0TQLi cDeELgFxvBuiWS8ftYZamG1kwdUtbdhGFnrD3jkJWfAhDtvIQm/YSyeEMHTi RrNAqFrHEhCmuutHl9DOT+PdEJpMLcLlWnxXg17eACS4Wc1JovMoCMUbLRoR 3Ni2QneKF1b5nM3a5V3IAgQrWYyD1QqvLG3ajSxAsK0o8tyofAqFaFeyAMFj h854yWb71rPa7mQBwsoPd+0BL+9SFiCsfcede77oALXybmUBQkSvkBWfDXzU iLCE+GvH2cLl3cvCOmR3zvIvkSpv3NlRiXMvttnrz/FD7UI2rVkr/QDPxUqP xdptucUq8WgtPYdu7miw3OIexWsASZDey7bLcgvVKt8gyh8j2lBCFnjGDJ4u pjbuehZAfHU3Z7MgSoRm4lCmU92P63gjhDiSaAjvLCz+bmgBxGPAO1GCvyu6 oRYigeoy2jlmFktsuWWMRUJPZ+Frp96snY+mPrVmK1dw6mKZSdgB8TFyra9C iKEMRDHWxytn195tMcTEuXi26SkuGHDu2MO9oyGWM3UTwRnF+pFULZjJwGud vmwZUP1YqkfoGcwkwF1b255w0KoWPHthyGinv2uIqNksrbkuhk6P43EEJ5QY zTrqgOXKbuXjQpiSTpHtdD53fa8+XoxmHV2CLxEGF2rlYDxhQ+IB2SGK8gF5 IogwgugiuQoSwe2yhowFvaEgoGITHxmPHdvNxdpxFv3KvV6YxVrNOrqCzLti JVOTbsjEv4L63P7PFoQupVp4sh1STtyGGFKByi6/aDZrp7VOghACLtHRuWaz doazH13fjTybHlzKgRhJQKAUID95volgrNQFYh62gSCg55vqcc9q+eA9MUR2 WiwEChyXYh5LQKSxIh+hfBCfTEPOLjkkjiYPcSuA0FvI4rMVg6OvN2ZoSEDQ 874+e3HMve1kaMqL07mMvyxAQ7Fdd4WLHMpo5/U6uZ5nE0R6nkalFjLaCb55 K2MJQkY7Qam/WF4iiFSGRy1kAVDQHOjeKkQL7bx+jObLp9ur22q0MhrIQ8C0 6ON6zoDK08xm7YzsRyc9twMjr62Ya9SsnQkeaIHzRIxVOBIdSXj2OKQnt0br kNspI1Nmyp3dSfGzFyzrJ2eWDwAUMgeUSfpkPf8EseM63JZFs3Yu4oTOEdmx wttNGR2WVkI0XFAvomM0aQQRHaNLI4joGEMaQUTHmNIIIjpmKI0gomNG0ggi OuZQGkFExxxJI4jomOMWdeDTMeWVFRKVqNMx9RUWDRAiOkbTW6gEn47RjBY9 yqdjNHnFFNEx2rCFLPh0jCavmiI6Rjts06lcOkY7atEQPh2jyWuniI7RB61r UReo3kY7+XSMrrcyFjw6RpfXThEdo5ttILh0jD5sA8GlY/RRGwguHaMftmoI j47Rj1rVgkfH6MeteoRHxxiDTrUo2wujjXby6ZgtGqaxLgI6xpDXUREdY5gt neI2HWPI66iIjjHkdVRExxjyOiqiY4w2FpRPxxjHbbSDS8eY8joqomNMrXVD 6nSMqbdSLR4dYxqtAhWeXzTltVNEx5jy2imiY8xRCwg+HWMedoGo0DHmUQsI Ph1jHreA4NMxw0GnhpS5lKHWHqJGxwz1DrKo0jFDowUEn44Zmu3FWaNjhm20 k0/HDNtoJ5+OGbbRTj4dMzzqIIsqHTPsoJ01OmY0aA9Ro2NG8topomNG8top omNGLTy7gI4ZmW2m3Fw6ZiSvnSI6ZiSvnSI6pkzDTL1VuMQ7/5ze56ub3qX7 yK5i36OxFl37WV4xKkoNDaYfspVypeWajXmyBUR7RnMetiDPzBc87ZnNeepL MveGzXlKi2evqCBG8u3JKrd3KJUH7+cGQR81J4YI+iKxMfExtwNBLjMv7t3F MC9PO5BCa82JM7lmSyX5/VfNk7V3WPRfcS/Er2uI9P/JWarFfurf6WrSOenh n5VFVWVOkd081xN8LQhGpfJck85Zf1wuld4JlV3xsb0rAbeoVHe3SOc0BtWc unTOq9pMqdQ15y7eBZJZDOhVUl3/V8+qSef0YsdPzXetuk05f83utdiubnH7 SG/M+6bVD5LpOgyD6mWkmnT+mLvQQZfOv44jzloJQzp/4i7toOAZtpfpNZe/ lbt6hUiT/D5FrlsWfm2JXkN+nDKtwEgmZ3ihVdYHhy3z37r/QJIF0m4tz5PJ T3ug7KuPW7Z/8uMX4dK8BgDv4ale+9rCvGaArfrXLhuRaQJxVkksWJTXADCz WQvES/KamuByAeS10F54zjaEJq+GYRQ8cADk9dCG9xAz3lhRsimAtKNWAK5T y1+9lqShF3BOtOV6dHlNtOhVEB9rMLq8Jjrs/okagi6viQGbUNVum9JbaCJ3 WaQur4l27aLO7cV3zYpE4/YqZaGP1JbD8aPNvDNv5V3TaPJhYoqJxgHoZJy2 RT9SXtb//Ruv/+sfwJQ0Pogsx5kdrFx/3Y8tiMzdV9/wZ4A3aJjmq8FgYOg6 /T3Q2Gf8MYbD4avByDBGh+ZgpA/guTbUdP3V4NV3+FnHiRVBkY9fm9K50c5G wo9uGmmjDl/9SX7eqGQBs7O5t3TRyiWW58cq6gF+mnsP6X2pfeWNemHZC/bK SyCsW1ixamGgqwZz1UpgWM3WiRurycJKVCty4ZWfqEkAD1z16myqPi1cn74F LIoA5dqLAJIpb+DRGcD5qvtM1U9dAu4a3kcuzkCsUrnMI6pg6NZpYdiDEKRY AEIuLq8uCBRNL2zNSl/gXY6+tcqy9aHRrjoPopXFal+C9+ITWp276W3v88XV XW9CLj73WGn5SoFT9e5q8sue8maPXsKb+iY2sTxN77nFNx8gBfuUua9TlbhL 302KNz9h5U5ZxWjJV9fkYnqian0Vgt+iZjEVahi5c+8ZGvLkJQvauBhvTU3w KtB31Tq/gyJUnbU1rznIHLsMBIMt+AAI8AT+wYRHtewEZsnLDQgeCoDehBeI QTcc0kt6IdtX1w1puR6yWXhHeGhF0FTQhzDcYHKDFRmBw0ThYlpwf1TDoKB/ wIBTQXW8OSv7yYWaz1xkbFlnO9gxabEWoDysl1aEVYqgSIr2Dj/E76jSYkKT FciE9PluSgAP0+LMIQJ9iV0mSooRpfcXM3GCkj+6OMlLC4QGFrkABqqS1w6/ v8FbPa0HHCQJrQqoeOQBFq1ZLi2sGIwY0A/1E7j7MdVYehUqvX/bUd+fX02m ++rMQkHH7pLd7fqBQqZq6cWsd5EFdp9tN8RhQ9UdH2N+FljF0KJwaYFq4fNc W/rqRf+hz9FkTTdM+vjLAiWPH6kkaqiQpJovDMO6/itc7afEtZOq/176KeMt 4f3NzU3x/MxxoENieKwPh/3iP7NIcuUmKyv+upVk+EHJ/Fya8jO5g1TacDDY egW+OoxSo3Cq/mz5vb9adjAD29Mj45ve5EapNTdeet+ovdPLyY1Ea+oVSKiZ kKtC2eAI7U3V3DSUHi0x8Tco/ZYCNZW+VyueGuwta/ut2o7oWr3F2mig/bZF 6sof0P9vx394vfQS7PB3i//0gaHl8Z8+YPGfabzEfy/x30v89xL/vcR/v0v8 9+rl59/hp+L/6bj69gRQk/8/HGX8D/ypDan/N178//fx/2CmOBFAnK1BRYKz EgmAqWMWCv6GvPC36mJggPLpq8yxehGYx7nnLp3MjOHbdzH1wQgJGW1w9mCm 1yHa3CMIBKwI/A/oH7Xcrv+QLCgcc0/zIP0e8D0tNbeMuMp+v/CFS4/5HGsN n/wkve0cLOSvay+iuwritM7UkuZ1xkjEwqbZy7UD7ir1lh/Q6K9Udhk4rTy6 7fIz/IZY9derGfh6KisawoReKisHg5fUBzIRQP4MHUr+giERZOHUF72nh8ad rn5S51GwShteKp96DHBUj9ZynXo0CMHAnQH2mRqHru1Zqd+j4Q8gvD6/+HR2 d0leq2kPZF73PVY/XgRr6DV4TH0KtCfzcw60I60AxUN92ce+o6XMNxDeWTSu cALWH9SY0Lgi1SpafOrCc4hKRTPJoMheY3ySV5IV4lEIKANQsUhEqoku7RdI A0XQGKdAfX/gJvYB/ejsA1AtK1MLkDlVC/SRexPfgQQonFzFEmtWKOs+VcBM PTFKSDL9h9z4DnTKwQKYg62OpLTXoK4zpnMYdVn2V3iy3dWYzMJS0uDLS8// YvErlWca9fazIV1WaWiY/xBDdb+ymtzc3HBrA3mpGNKgmcZDD0WXQU8GKBoF lCVyn8oR8euV7a+Xyeb1vxItBOURuuuEhW5nNE6DpJ/pNqXerRsH68h2Y0h3 E3krK9rcn19N79ML36FU87ivaXpf7xsDRcGxuVcWGT4QyOusUE6XSi2vu5KO 4AoSHS2ySLv9/zcnAJr8v3ZYnv9r1P+PjOGL/3/x/y/+/8X/v/j/P6D//3/7 oJfx/4cY/6n//2x9delwxEUtgf9tfUyD/x/qI/gbEpiaro00yv+bdE3Ii/// Dvz/24lzotb6/8OjqvV1VTs+PjwYDA+0kToYnBhHJ9qR+vg18uKFb6kXz6H6 ljKJby+DBx4EvFVv3Ue21gzxuIA5IqTWQG+nbgimAI0uKvv40+XZj1MkmwP1 49n04j59gGPt4hdye5Y+YFRnqTRtqzTzBBdW1Ur7GAWpRQzA72VtYOVZ9Tax EZ5954FBMoZCgESXfDMXZeeZYlonGHJp5hwc7c/t2fnkbqr2VHi/d0u37JaN JLYBTzFQJ76K5lJN7SlFnN6Ozye3p338BvMehHBxNZ1cX01P1d45Pvn54ur8 +vZ+enMxnnyajNOnyACXEqdPz8bj67srMrn6cfsdssEsGxLHys3d7eTT/95f 3xCaBkpjRrlnL7yl0wujAHccu/HpBixRD5yhEzzFp36g9sCD9LDhpyHElPNN Hz1Kz1o+WZu4B8OqZ0P86PYcL6JZlVI3QyEPBqT1Y0/tha5joXSgevEmHqpv 31fbv6+kmd6+L0HsQ7qyouwrl+csmTIenz7YtvIGfqusapC22sx9FVNML25/ vri9v/741+kpzJS8dez0IdDx7KQfsDgHfyfeEn6tnCH8H78PCyPQIvzbpunA XFPvHKRw5x8/70J0Zit5UJo4qyaoRwFqM1A7rabNEG2KaJcQbYZo59W0lcnV +PLu/ALlyTRu/4Ch9hdq8QiDiP5CUc4uL0/20lJV+I1eTlGgYvnTPnxQZ2tQ FvhDUeznyJ2fKHv093Znqj183sPV7z3QJfeZ/blIVvD/a/oLKlG0eF9R0nJO ihco331l7+378Rj1INOIXqBmNa0mhY+Xk48lLKxzgZd12U5I2sytHDAK2PMa fnCi1sWLnfb2fSZ9Xlk2L4+iMJ0oA6Z9Ko/GMgBUoWoVvJK+tAAtcoFGePVK pgoqj8cyKEo68spYmZbLg6U5UjQ6kNoDnkM/owqURq6gEDqeKwWw8diiwjSD ouT2pIyWj94GwJI5qqIXw18p25YuZWRCKeMIC0stxklmOnKjxyQmGnCYVJCl MtbY+9pYow9bjjWWR1FoSWU8ZlCrnxcNeDSPomQ28SS3joIGZ69L6ep2pXhT rlz+1G6oUSmhAnOrBOxzD3+D4YWZ6eMz9Orl5IrUTS8/Ub9fkjJ8YCKCPzIV tpeu5UMR0QqCCfWHfmGWs67NW1wyri9fTX/773/zQNfynr95GQ3zv8EQpkvp 97/DkUH5X1PTRi/zv99h/gf9Tyd/Gmf2ZEhM/lj+txJzMeN3mYvxJmEAdjb5 hc7FlPJU4bR3fnU9/ens/PoLmDRomaJkDFGtMsq/zPifxc53H/+HbPwfjkx9 qGsmG/+DF/7n9xj/0P+V8X90oB2runGiayemDPnD8ovGfxWtPv4rYxPNAN3x OD1Xr6cZS5t+P/EURF9x2MLLiZoEgRz788e0OBi4nUIYZ0ebMPnu9qc+/iGO Wz9/9/FvZv4f/zH+F78Hfhn/33380/7n0r+meTIYSViADKGJ/WV49RF5iblV J3BjdWE9ujDgLSd4Kr7Di9mpHHQs0lRX14SuToYR5MdL1ce1w2zbOb71kuxl jLvPkz+hoWASAVPxmwQf9fEfB0sLWv59439TK8X/Ol3/McDvgV7G/3cf/2n/ C+cApoQFKDBk5gHmH2mwTVnVq54Z7UpmQGoO+jr9MuJPOzNIxz/jfX+jMnaP f42N+ZExGoAFgH84/vXD0cv8/7uMf2+Ox/DjQopEiXGHik3XYqg/3I6nHl3W 8fYn13Lc6EQ9WMfRwTKwreWB/RhHQZDQJyUFomZjmA5yjPfVweGJCeP8uGY2 Xv9FeeP6jjdXlIMfFPWH1ITkKG/xWclyDFUuaGE5IDmaDvwm9TH96lj8/aYd QNH4Hau1pNt60A4EId3nhieVPSEaPTJlnm9ei107cpNsp9Q8WIPVSdcy2UsP F5bQ5UxsC4/vPuGhNQ+B5z9kWKUlHmBxcMFJEOLZzLiwI13SA1XBJUSVlH3I X5OFWZXFCGVhmtuyOHNwyxb0ln3veHh8zft9unmOLtoC4d+jtO9x99BGjYNi b5EdRBEeNMSanMsiZtvCoNEISS9MTdc7VZuGBhWQQUI0Qb7fitMSI2uJcaAf qdrRiamfDLRqS8b00BkI9tzZ+iFdbgUNoN8n0dKdIEnoe9tbQX9Ce6BIqE6+ OipbzIRo73HnFqhz/tx9trKcbBnP/nY1Weg6OtD0A81QtREEiNvVRCobqrEO QX6O+yGTIi6hA5E/WZFPF2BB9dihcrNN/Xvt7YK1UsEa+svh4YlxWC14QleC YbtZNoZyQMdV1neZgzvLu6V4I7/0gALnGS+9R2xQAqkvcCcgdAh08gfIZffz RKNjfaD+dwACGOM6uki9saKvT9YmT3ADYouh9bj5bXyGR6yZw9GoXM44CDeR 97BIUBQ6OGb4ZTaVXuDj4u18LygoMHZMuPmAB7x58w1bs+V4cbp7la3/i4N5 8oRrqagq+0Vtw3UUBjFdwUrXnOG5anOXbmvEzXTQpQ+RhesFP+COx0ePbplk w8qLcxQ7bxHihEUNcVWjDehh6Fq41I5qDjUTMU2azn3K3ecE9nqVKXtqfHBd HKj3LhFRIzaja9KcHAtGtuXgbkiPnp8MbQ/Xs6Vn4zJgqCUu4aQjPigEVoyw QkZRAEJY5fLJQzAoHyHz5jLZp22Gujx4j65frkzR3GozmUhRitRaljuQrk+O YWwV1SnE2yQTVZXVb3UFQR56gpq1gW6aQZtzDLpMce0l1sxbohSDOV/BMsWC OkzoptuSMJkWvcYds/HrXKruM923gJ1ED1LFDcFWhMq36ecWoOzOY9uOPedv f1dPldf/9f7NPvO0e1p/VBtiorGFDQevrbxJA929/4C49yDZhGDZF/9Ze5xO treeJ97K3X5Kw+XKU9+FbneTA8+vPrei0DrAN/i4jJI4XrAF4cyqj8Inp/pg uzo2Nqj6aO2DdtUy0j3Xy+ozCIP8YLtxT5ZXq+3rbBXNa0Vxn3ETNesicBeP 97P1fO5GfzMHx6O//6Xymrps8esfcODh2M8fo4OkXvN+vrQeaqmhDv/X3pf3 tZEkic6/4lNkM2NbsgXo5Gw8jwbZ1jYGFuE+nu3Vr5BKoLWQtCrJmOn2++wv rrzqEPKBu3sH72zbqrwjIyMj46Trv9ufJEtgdl7Bq+bRWc2xa20DawAsVBSr IJdcohQnQtAB9OGayEEg8FW+sEP6+bbDMeSRn5iE/1NUlKMq7HUL7Puy9+rs Rfu08Z/qsdTYWRJaMTVVd5Z+g4/PmocN9RgOCn5QsrD+uI1sANFHHFe+M/uG X1+XK5tvzXcBdb1coW8USK19stc8BVAHCBzMk4F+4bMJLgXWAe/N6aQzvlF5 22dRecPKxFee9sdBtzspFKgZssAKmQgd7QCAD7zDaHJjjdK5y1WquIZDEQfU U3meZ1EtP4jWHkTLReVsbdFZHa346h18tW1KG/W6P4WfJ32YwUE4xSh/7Md+ y4hrXap8y8DASufztCHwpOiNxuHQ6SdYLhTU7q7K874V1NGrw0Pe9N/E7Sk+ +FJOvKGWgamZbgMNmw26w0dTRV3Ty96d3Zvhsm0yb56c/uSiDfiqxzLf1x7D RYRjME/bxUVdh2hHDd8ilFbCrqGQksCl1Ef4bziIQlmI7eUETesDhWgDNPpq rBsojUwAIz4eJTN4bzyDN0Zejs1DqVgoKgIqb6J0z3tIXjkmLscamYjrgBho gUkwMgMjSsOoBj/FBF2Pfo3JEFSean0HG+WeBr1dud8QwjLP5TfTZTs3+o4b 2MYJtWEuipGhSAPrGtJy6LeUqeFfK0+HQFPg60cfKn4bKeoMkFfL+18BPBha BJ9074ajaxQQw+E6/pHYmhCK2NReTr+FT/zBZIlUCiwA1TSu5Zn2yHdL0XYE Q5Z4fb1J6FIHgT4f2fAKhVt2wFJRRf1/hcBM5DVFLFBNrxP6Au+32WS4s/QR nwNf6w/zF7lnsyF5Q27HYSPlJ8zTbMMTAwEmmKddG8hlIxiqvf0fj45/Pmwc PG/gk3UQkZkroC52kVMMbIPF7OhAEIvE3eKG3RvgJFH8eM0xCRf0tf4gN5WJ AfQbnhTRxcJXlosz1Fy+M7ZAT5lXG/X44uCUe8Rqs3ZE0euno2kwaLPrzA5f RjN8xgMvhndNG1nqgLNDZRQ/BsafexSWYkrXHE4CusV/8vU9oG1warJ84XV5 /a2uz8IDaZV1/8oU+sM2zgA4zDY6/hIpw8XBoc/b5RZcDkjuLPUD2odhAKBh NwDCe0mSKj612MPKU3yMo3fxz64o6LTROjk+ajV2TDWSdNnLuSsHjy5zrvGe LuSiraQ/0Ax/auyfHZ+2DxtHTIllKasRr8ztmy5+7P+g8cOr50C7WigIA0bC vs4VZiSC8w2zekBBdx4AjXsQFeQWc+YJ7AUwum14QAcqL4MWFuI5XGxBBy2B My5BA/dwFJBAI9NzTevp6QQS0AFjZLErT7vBNMB1yt3Bpybr8nDvemZaiezn gfUGAi5nzFBxxMwnT2Ak+rzy1BAIcw1GlJ1ERl15imw93VBLOYrsA/hw9utJ o906OwWE2MZrBkABHQJK4j90O/hJa+WbyAyLVZ6oCn3UPJ+h9FCpqFLbI3Se 7PJZysW24Inf6zmmGdyJTxdOX+N543Q7/vlk7+DgdNubor4i6MQWTL98dDEi HbzvBmadA2eWGu9pHQ+5pBjrz1uPX5S6tIzZmFV2w14wG0y3nY+5j3ovGXPM ZjMLYK5PQNS98RgdVA0q6suAUBI5TyCohHnuZezjnL/7UN/gGrbHj09VST18 SBW/5+PCyEOHXpgfA33YmZPj07P2y0artfe8kY09HrDpBoHST8SWjxYYfPLM qcZNBtLhNtXsvnrWF5AxB/wo0jJuAzVHdKzy/LehfwWEZ8mHIXSKogQ1IndV FM1Sm1V1MCI1PXLHV2O8xg1b9dk0NoW/tpMQ+XQoHAcLoGU2LksnV5Sz8QZD zBS4lsEGPWHnLoJdcAFcjLct2pFsN916G8Fr4eqNXIztdloPqZDTvaUDzDKT 86ZfSk6YcAuYA7yR0/iGgnroshZ6FLMmaFpUj96UHlk6ousz6woVAFzACPSC qz4d9r1nQO0aZ15h4F2pQsHi15vXgmxFzDkwVWfdMRWZw4B3ML4FhEu1FxoC Cj7mNROW2Kg8cDuFGAT5W4lenHF4GXAYQCTgiSD5uPRt9b/WRedb639L69V6 9W+l9Uq9Vi1VahsU/6tW2riP//WX0v9aBCIlcC1VZbaYEtjr6h+p2s8/QBlX 9ZVxFTReqcUGPgimoY7T2afAERSGEiDG8pwgUqMxvopJh3lxhR/n6xtppHJl uxZT+8GbVIVX4+kNyXIMw6Nf53eoRfzLqg7vdYb3OsN7neEX6AxJb2iJcw5p 4kJn7I50h76W8E7VgenauzuUqcbE5XGZKov4A75mMImk9rLVhi1GIrJC73eW ppJIRVhcPCmEA89YyfOVpaUJcb+R9fNLhDU9rJ5Tado1fM8dNPfP2pzB6DE6 fWNPF/iwICbfK4WSuOauxso8T5hJ7xgRDbFCgSVDjoYmVT6ktQ2ihMLFLD/A +IRvlpeLWjXh6pBYEJbXgxekjpYHGTmVCMdwdviixjeSFibgE/y7fJ81X1yl UCiwFus3rczyp/TmTenDg1LlA8yJqu9wtY/4F72U441n0w73XFRa3SLVSVgR 07RA3UfLj6SqpFYTCU4CckZUJZcOIsGu8naRQaIFTClARAhQQ5TduNsdVzkl toUUobbHIo1vejeLYphkdjLoxnpxZ+z2kw0FkczJeuiFWgEksMrPWJeZiJZY UUw5mTmFg72zxrYRi04nPdYg6vH1M1S6w+FebD94uf2gpR6cqwehevArCp1z xMVy0zz+1Z7Ss9+f/7wFvIG/Yqdl7iKMSDCtx1dD1N7BtY7hxR7YbaLTHOuN Ufrjvdv4nPe/9fv/9vbfZXj50/u/WivB/8j/u7qOPqH37/+/zPvfIpB1HUk8 ORd6/ns9/eP+LXv/lr1/y96/Zb/2W9ZSmRzKFP/IZ+wiJrCf/LiNKM1t9DUM YBFKmU/guO1p3Og0aVO69He4bzAy7rPm0UH75fFBo32097KRK6UUnDZODn/N lVNKWj82T3KVlIJnh69aL3LVpSV+YeK1ja/MpSs4viofTC46cPAmF+8LjoEN fPTsbx5jBX6C0oekcSiGNAasf12GO99+deDAPfP7thtMZ1ccgNX+lB66xO3q dnDdytjaZJLsJdlccpmjiI2DC2B3j9s/nx4fHf6qfod/7p829s7oX2enr472 i6q0XioVCur7uIbWMNGARHBtE2set500o9DpvJ70kQKRfZ2epWGwww99eMat lB19rBjdyQsxYwmAB99gCWjp+uVLsKiLvNDqsl4WnAoMwqzXtJymEE+ZqzNV ag7dLDgxa0mDA7Yn6MWU51eU4BLZ0MamQFi32mVxhEZNpwCff47+25uCRlHd XH4ni2Od6Om4z3igpUDvqf+umXBXAy32BE/fWu6CTw/uKzwnyR4qp+wBKir9 xPcgaEwkFAJcNpjmx5VKhbu2kTR7lrSORBNNG0NfexWi9RTmB1MrzNHAtfku vNGQY3kefKsoofRQr3MZdt6JbRZzF2w5I9ZaUQjMAAbW5cbArQXoqYgudV9f /peJoy6ddfCRPxgM+y0my6vU110ya+0SsQuxMsSfwNaGcWt9AkubgrLHiwg+ usixgj8eh06cehKwGjN4xGa+VT7RZN2z0BeaUpSHSPtVq3Ha8k6MGSRhLj9J N5efc4h88viALfdwd4Quxg+REctkHCO08WDDSv8S33GoVO8iRNPsTDkTL69w i10WWW/RUPGx9IJhz3K0acagCZPy3XBWSOSQTXR4yUgAK+QWa1rK+lgsYVAA +/dHaOXlfnkzfRSXujI91KaouXRRruKejGR3ir+1ZXhM4ItLQRMxnBzZiD3W 8tfcR93/Y+EQsIkZlKZP04n3hWepP0RRs9OH7jU5412e8e+/K9vd1OkuOR/j 7MKHtqgcibO5Hcj4L3EvSJ0EDhG/Z6XQKWJad7ucKTtfPme7/ojF6zoru2IK 6E5KFzoTcz95k5OClRVvgvLV2W3bQwoK5c10VJnO5KOiMwT7EfA9acbI0iqg B0pIRhDd0TCUY8Z2nE4v3hbjf7W/htAF674gxOdegHuH8l+O4v2HxP+Ab5jr geS/5VqlKvE/7u2/vskfV/LKSJAidb03SLoX4t4Lce+FuH+EEHdNrwaltkyh uFuKUFhZq1TWtmpc9e/AybA8sJtvt4PB+DIoIAtuv42iXrtdWEIZJyq9ZkN0 5CcrzSm7tqFKCjmaRA1y9TZVWGvljjcb9j8gNArIq+mPGBnM+/CyjTmyCkaU qlM6iriW5K44PvJQukdcWkZ9Fu/SbOItvMmdR91+yqBXQecSytf6Q5IBOELf RBUcIxh688NOU+d2hWnKOv7UdGVvWkH/QyEuNadc6H5bqKb4uXbPrt0V/8cp Nf4Q/q9SqZTJ/n+jVluvVqp1if9Wvef//kL6f0YgL/5bea1aVpXydnUL7eQX 0v2bXjLjv/mdfi4HWrPdYQi1ze1afbu8/tndVZ3uqqq8gZnNaltpccwo9pqE sH3VOlU/ARDg+mtp/sKYbVIaRJI+wvUpkSv/1wYmu+fg7zn4ew7+39EMgwl+ Dgn855pgJM0hMqwyEtYPt1j3f1l0LWvvIOsn++W9s7NTtmXH6KOTm7Yl+Dte RcfqXWqyFg9N2OHOxis7Jdcjml8sSfgEthp/P+p3C9aYnsfHQTnKxpQk4xnz MeJoqmZssLmPNGWNVj2hpe/0zfQnnPG2Kn148OHNFBMBb6sH3TdTmDdfe/rW o89OgCYcThsI87/FRJx/4K7pfyf6soGQZG3SmRMzQKlebzCLLnVwCU/UzJpg y5vcmUKYLOHRBCCuEJZ7E1Xq7EOv94bC2wZ8beMeNH94ddbg1Kis0fWrO1tJ eZHd5oRdc5qKxpiafXXVMOGoXr3KF5yIbfjZCdnWnV1d3QBNfb3uGNkgXsS/ wXzjn3D18W9EFOw3imsDL9E2RqZLOSC3u5hotTT2ZGLiUGBaGGln3kHlas0I yjTq7pkoR7uqZPnjT1Qk45Sbx0d7p79aCxwG6+Ka5E+1t7GYs22sMpS9h1NN /T3djtEqy3YwBBZWJfP6blMlS9+oEbOxIlrv+mNh86Nx0HFCU8Q1jX9PahpL yU9D477j6F8/Ls1HBWskMxl2rsbOBvE5bx+93IfdLpe0hQ+PkIk95XQXl3nY ljNEz7FAyJoP0B2YzpaezZy1wagAoXzWyDDVgh43J/F5aFuIUiFRMgPS9jk6 +yjqBEP/TPD/wcw03ShqYmEDsjGlKGpSQDhTy3SqEpy34dwI+ZtD6AXexjYs GTApNL0HFFjaHgdrW+GfBUFFqwz2ToPoRj3jhp9wRAoOCeQbDRyAG49ZMbg2 XLS0p6pa/sylEfcu0UfubHHk4NaPuv0LvAce89YUPnPGHNfobuY6H8Flj2Ar HtOb/j2/6aPEm14bYiHLDQ+LF41fYjs495j4UNHor/F5+QE6/T10wji5Cnp9 xLwudCSoYDrq646SG4SGDkgC5MDASCx7Xja0yOuUHLJ2Y/6T8flkdIwREy7C yWI9i3/hol2T592CPZPP3oId45lcrFv0w7vVH3MhVKeO75Dk2Di0mMjAoq8O 94ZsoYO1eeG0/dcBawFgKXJZm8ICsRx6FmlPivlAYVjg6xO6vQqvRllrnr9U J3Kb+97QxJPqOY8PWJ8weOa77O+trJ5pkHisQOv0I2+5P96Q5jAKJ1MKVjrU IVztJtgnTvZbDqqlPw34hRRjGDK4EeKEgczUHT4kfmEzt/xZl7Ww7HYr9e0t t/YXXda8i2wa+Ke6rmXVn3BdZzAh3+K6vucx7ojy5jLv4zSazIeMkTmLKovH fcxvPpUsU2kaXY67239jwsxO+4jhVhhkiLNfKYV6c0GMei9EUKXLBEHVIjif mApXt6tYQpBi0ijv0x1Wf5eWTIhTltEVduzby5dD3bkACiF6EU4znBIQLL0Z UDBLZDha3Qw4WHRO6CqSg0t4EVsLTzdl0/n60iOHX1hyl8CElIZ3XbvsjfqN ZKB49jy+YVc5E+OHuN5kLHDDSMwRWeomKcN/M0Tp9Yfdr40peGK/EZLg9Bnm RIRcvxP98ZtiiX5MxMXdNDtP0PMXxBdA/kXQhc/IPFThGneIJnLHLbnTpus3 gSXyLRmbiOj+Et3g6ReGwY95wWyy8MO53/SsUrEDCl3k4MmYmywLNfxJfCvc WODOuR01AigIdMVAnH+CKBp1+gHZN3wLKhNHH7qKHH2Vg0UcPN/oCeZRn2+H WD53ZbGLfJWUcnkoYaLuCu/ujfH+OPu/q279zsz/brP/q9fK62j/t16t1Cql OsX/qdQr9/4ffyX7P0IgL2+8bwu3kPmf7iTd/2S+fd1pMFTPj14B199l/+iv a7KmXh7U91f31Yo6be1hnN9AtcLObNKf3rAxThFraDPBFYk1D9fBCKpcXplu rJVLfr+AMyqvVIpZfcqjv0v1VtXeYIDElJqjwR5g5HvMdLNEdkKdEIPcw2MW TZLoOpxFcUsy+LeYhsUsw9AMgXK89hF6/R5a8gQRXajLWZPD9b6U9R7QerGP Pb3kZbLkgov8CpYwQbCi6RRAVay6JmEvnITDDmeRdWaJveisZz3hHPxFQkGA mYL0WmDRaAplFg3Y2n8fYMB2dT2avIvMYpfIGgrWG806l1JGcPFWvUzt3dy8 GgTY/lYozAHBEoXgz4aCTB3NqGBuvOgs8Gcaf3VGw05IVp0qhFmEkyWxAbsK J3C0h9l2YCJJSrEVwy6S5mLoYI2ZFibWcowMxxIGY9h8AZsxHA07fgeHmBd/ dgkrE+u8SF0BsUYbvQnmdGO/DaovxonSGqflztu32gMcWUPtnCxmVbuOiBPD MtIgju0KZ3WImYWm7C4PG30Gs4wwvbyawEokbsKaCULTAsKy4fxC/xTnJ1Iu 52dNVZzSSlnVnV8VteX8gpY15ye0tMFyWtWycgqrMGjZ+Ylmwc5PaFq1P2tl 5RTWoKnTbw2aOlOqQdOyMWZDszIfIienx2fH7cNm6ww4POJ0X9feFq0DDV4q aHiDMSLdThpDStFkm8OW5fNeM/W4KLzz46LnsxPv6yBM6yvZVHc6ry9YXFty bHhLOzlGzeNpUZl/LNALZsNI76WPvuPxHnQX/oRRLdk8eo5AVLv0VCh92CxR vo4v+B92U1R/YDdLH3fotD0rqudF9YKIeJOoMrz4AAhIYPU1EPkH7ln+Q1EB PfxXAUCa/4DhSPM3hYL6HX7+P/75LwyZq+s/T6n/L6l/Q7/+n1f/hVsfqv8X do///ZdTqelW4mKs+7vuDNcGW7931mgfNp6dAemYUpaAD2oQ9qZqqM7709i6 nOrY+VBP9/vvVX4o84WfT5+qfLWygp9knGcIRITiCzZrbjbVVJ9QuR0o8gem r49UuaiA96hy1Rol+jwdCZnsU7yYAOPF8DUYdLv9qRiwAwF/j7ECdEKfgK9o b2ue5YOiOi+qTlF1iwpWgSFpOgX1m3qzpPJBAWMjPIN1nBcwpQr+p1vAxFC4 sCc6UVQeWuzoBrseGPPwCRpFBVsBeoTu6Cc8OM2mP19gJs+/xUxevFhgJi++ xUyazQVm0rzLmSzZDEhwlY4xxVt/KH9h3iEWJsQoNtfcSS2j1js5OAT0L3UO D5V3xprP8/SkEaiq1j724o2QuiLt3j/7hSNpfOAAQfCtSVarD+UrGS/C11dj Uvea77HlSK1n/aGkPqUyp5OP+pFBYcHI/pdPlfohvOijSf+QSkcUw4n8FiSu magEpSs+hXj3LJm56lEYFHpZj/W6cggJ+aHXLj8xf+JsOH1deqvDf9lv5bfa SlOnCrwKLoBe+/PHVsxE2UTCpiO85kLuvPRhfaNWr1RL5Z1kDR7qQ9jrdIPz za2UGhWusbV5HnQ7vTClRpVrlDHcRG1j3YU47/qMd9AAeBX5P7LgNMD3X3f0 TrHbATwv8KgRO4OMkO82TmM0AJNZGkWY/SWl0rdNI1MSl+CvQ3M6bt3JLz4n PNztR8VvVqRH+IciceLYXpJs7Uv2N1YNYlfnN3gTXo26ar0m0bWwJUXOd3ki TCWWwEi4/qp4aZc+VJ+ZRF4COmcIuF1t4K6UbpAu6byEesV401YLAmb1/fwK iXOBFsYpn9NHglVUtnj6Ai5YPUBjhUGh12UZbXhRXeEzh7JH4y94eEX9czdT N67UDrCrO/YlwZbBXcoZhhThaSYuRu40D2DlbR1BR93tju3RTjPvn79ivFvr qIEcSb6vzDR3VB/umPUqwN1gIH5CsBSWcvNHeUhNXvff2v41SpVSsgb2+btO Jkt23JPwSnzMGNMJpA60yDzi0wD2UOlpFbVuWnYHttmj/j28IQztbyCblkp8 0i4CISn81GfKo+VQQHn+FU5G/X9pOUMq3ZHrSScR9O8Nn444GX+ROsTG0+Rk obvG7xjP62vJ3OETIyEpXYeitDDpetpZl1dlHr8UY0exqDYNuTiBawuFEsDU 1teFEDnn6LOIUY8OBE8UG3Mv38MABfVPlYdx5GwX1LbKlysl8zvGSxjyLy8/ vXoze8l7KqQ5fx72MEImmrrCNhcM4ib6Y6hYKLQosiadIBSpuJuoARnDCXPe yuuml/9LCBZiysSoT8K3/tA8PCxQnSexc4rM3Jzs5hprCt4J4Veh/6xZtfQx knUYdSFdVIznzst8yScjshqq62nrmHlgf6HEIaDq7E30m0mOHVAkVGZsoEfz qwy/OuZXBX51za8q/PrA6bNRA8hiDHz6CeewXjNQPsW3myozLJ/BC8pj5GnM VhledqUP3Y31IKhtwDbjoXNaQEXT6APNq1WuYItws7NxvgF4Si0qtgX3zo0+ 0Nxb5Sq2QI3NRql7zi2qtoWZUoAtqtSihi065fNuJwxDblHLWkfNrqNX3+iU ekGPW9Sz1lG364BFb3TWKwG3WM9ax7pdR7BZLdXWy1VusZG1jg27jl63tr5V L5W5xWbWOjbtOta3Nktbm13Zj62sdWzZdWye12q9Db3ycilrIeWSXUkP/tTP z2Ve5XLWUsplu5bNrXqnu3Eue1KuZC2mXHFWc76FqTsq0qaaiV5Vu55ed2tz o7wlUC7XMtdTc3ZmfWOrVt3Uc6tnrqdu11PbOq+VNisaBoQA7umRBT5/nlgg 9lFhrFsvh5X6ul7fhm3ir4+QqELL65RqpfNqrSRNNm2T2PJ4GD5A6/WwHtT1 VLdsG395tMMVWl24db7e2QgEuyulrMXU7WK665VeuVTvSpNy1mIYkXg1lVqt XKvLXlUqmYup28V0N4NyuL4pi6lUsxZTcxaz0a32zjtyKCq1rMVs2cVUymG5 0w01lapnLqbmbE21ulHa6Oo261mrqdrF9Grdeqm7uSFNNrIWs2kXU6vXg3It 1GDezESzql1NsBVWw61SXdpsZa2mYhfT64S9oNoTmFVLWYvZsItZ31jvlSrd LWlSzloMn3BezWa3EtQ6m4Jn1Ur8FMn2vniRinjVslCjoLpVk1NUdZr4qyMg VpnobWyUewaJqjXbJO0UVXl53a3uuiFG1bptE1seoURVCHhYr26WOtJmPWs1 ZbuaoHYehkGtJk02slZTs6upnXfDTi/QgN/MWs2GXUxv/fy8dr4uZKS6lbmY kl3MeXgOp2hD2tRKmYup2tVUNrfON8KOnIlaOWs1JbuaMAjKlY2eoEStkrWa ql1Ntxb2qqVNwe9aNWs163Yxtc3NclefiFotay1bdimw/bVuqSpQrtWzlsLo LWtZ755vbYV6mPVMPKvbxZR7QWWjo09ebSNrMRW7mE4t6NTX1/Uwm/FTJMtr NlM5uRqfolplq1LReFfbsk385RES1RjvqpWg19sS6lUv2SZpV22Nr9pzOKnV QLcp2zb+6gggNT5Ena1qYABfr2QthgHPq1mv18/rWx25WerVrNVU7Wo2e6VO p7Ml57tey1xNya4GnuK9Xm1DiHG9nrWasl3NZn2zVu92hfTU17NWs+ksphds boQ1zZxuZC2GsYhX0wsrnXA9lMNa38xazbqzNdVSuVYtCwbUtzIXU7WrqYWl zXI5kNWsl7JWU3MQbaNe3Qg3Bc7r5czVlO1qzrvVoFepCoKvV7JWU7GrqQTd jW7lXF4N69Ws1WzZxYTnm+vd6pZeTE2OkZEgP9lVwY75wMK2c/uhQh869kOV PnS/ytv1g/dq/WCfq/x4jkSOZEV/05FiFYDyFd2FVbUXRTOU66GXFZsvBOpq Npj2xwMKp1RLvmT1Ez2mR1lMiyLKcZYKp8iAKbdCmoj3vwl0RnYHAPhvkqXB X99TK9V/8gQ/PiGfPVfyyBN4/d9vPdEKAUDklq/7b0mW0usZ4aJupJ6ocmpD 2/LpU7VZmNO+cnv78vq8Dqq3d1CpxTr4KDjBj3uDE7FOPNxgfPksnNAihEyc kH2/XaN2xzghUO0TRD3hOOAHa7pjXwkBSBcOm/y7bE5arQrXwq1M76bKFSo1 c2CPRlOyRB8PMBTIMq5kMBqNOeAVUo5hN5h0ldiF9Huu7N0JdaUFTNqAJHsb hIYobx/0x0/dgBj0UWhuwZ4Et0bXT1880r/E4lPWTnRSr11s4m9ZuxdJ5+ut O2/iwvBoBcE4PnUy4L+jCbpj/335x9h/l2r1ynoi/j/8uLf//sbx/wkJ/vTh /9Xzw+Mf9g5XX7At9mnjGQfzISWXsTYwtcnsDgNwtFR0iVGr0IAUCRNetEOK dIANR8MBEXTWjV2N+4NwokM/0pWrTdAwWyCZk6LCfzqCoTFwt9iqAhUaDEbX qGRj81xndMlnjeOWcKT+VF0GEYXADAaYi4k0i+chxtPiANlMePftfDDSoDYV E7t9O4Ax7nHGLDlm9obecjWAl7oIh+EEY2KO+hQPlSJaQOeJ6OdMPKUDNtfD 27Ti9DW9HpE6Hy2Xu6mdAPgnUxNqvWK7qTnd9Eazid/PnUd196pZaFlzzX5k dqQbosaNbLeH6nJ07QLbqRacj96zPr4Jo5FNiK1I8VGH7gDsGRUZN/SiIvuR 6z7aupOdia4RDPUpk9B8DJ8sLKDu81i3QC0EDpl18gUXBHCL0ym7JP8PhVGI tSX0/ur+vUvDvUvDvUvDn9elQdTl2tDDJcnsVLukX+QxTTfZaLASPb/3w/5B QZtzcD02eahIPd/4ggJazwYjVfmv9ZrKD6JzRckVTRcx/Tnby6AC3TFIYysc avBxSSxI4LLQ9vRk0+gZ0xsrE5S86Gpi9BDzBTBVF/AG0D2xVYw3ou/VUEZB nTeJvxz/r8Me/wH8f3md+f9qqVyu1UuVEvL/1eq9/+c35/81EqQ8Aba0Bybw 7Oh+tF2pbdc2fZ59r4vk0XoNILuA6Q7IuAio1Qyu5PAqLY/Bptc7vC5ggHot 1jv00OWLES4YzBKjTp/tRzCX+ibdkvCPrWTXG07X6Jm6XSpv1+tpExeeSIdT OtprqeaBjSGQ7Ho9LSfFVlrXge4cWRnJAwFDwKXR639AzwpeV2ChJCwMsSsU jR5D5BM0wwBuPPg8Gc0u3LSmOl9wcp71uPdsrbRd+gbZKWr2nYcua5Xt0sZ2 qRR/53WAH4w4GcXoGhPtSkJjbdUGU6rUS6t4bQIaXeN/otFVqKNs2ilhdwS1 8EMnDJkNJBivaK5cwnf1AMM2s5J4/AHJNP5Mz+v75Bz3yTnuk3P8u6bX0wwA p9fbUuUy3MdrWzUVd5LmPHzLS0aSsPfq7EX7p8b+2fFp+7BxlMs5XsdUdrLX aqWXcIhgLqvUSmRNHnzoX82uEBYVtg+YGz5dd+eUNg9yuVpl69CIM2JvHzW+ bgdAyNqX3Yl5B83a9BToSA5586Hf1T9ZhMU3k1flPVwCo8nrGBjeenXwhsZ3 E71rqOYLDDPsQwM+MShyjo/3/ou9Ew6Yg2XPz14QFK0Y5+c2tX11cNI+OT49 w9Ja3Sve3z/zi/3mTqxmGLmUKJJgy1BWTpZRuGSccKIIQx5DQZXRjAJk852i xQssuUXsgoMlrXOynMbRWXN/D3MZtE8b//mq0Tqzg6fU2dv/0ZlCaif/ARuT q3pV9vePX0EVwD89Rq6WWaF1cnzUggXVM2q0zvbOXrVyuXUXEIj4Px+fHtgB NlKLaf65zYymNPXcVsbALxut1t5zmFm5FNt1KGgD9hwi2mB5ObkVe7Hw5Lwb 3na8ajVO20d7LxsuAuScGeZioCeEtYUezPcPm7ArdEJ9WEsBoiiV1hNTgP// qbnfIORywIzlz05hegdteqXvHx86UHZKEVEBIg6YncKjxtnLvdaPMShL4enx qzM6HBbCTumz5uFZg4lOuZxS/vLsFUKuklK0f/zyBOcEGAo1PEAdHj9vHrVf HCPO5Mq1ZJGAAwrrycKzfXvaXaQ4Pjxwt63sYyPC3mBTruyh40Fz7/AHQNP2 0TGWbaWXEZZUPDxs/HLSPKVDiHjiURAHvDhgpZJS2Dz5BfYGCqtuIR42alJz v+4f7uH+5ioe+YtdGVDsgaTF8G+fNV82YCJQ7AGleXDYsGW5igcU2PeXzSNN gniNFQ80+3j6Dmi+WAmRpFqKV9Dkw9TwoARvUfiKtOxZE6lw1QMT4Pwvvxp4 VD0oMS4c7p1ZZKnW0iscHR9gaT299Dls0QkUr6ds0N7JyWHjbO/wxzas48dc dWNuHdhLwD2otukDIVHx/x4fNXLVrcQ9xmRWiECtlCg/aBzu/UobBsXlRHHz 6OTVWft4/6xx1kImIVEBttmrUU3OQBCGuIxaothcPFBaz2wsE1zPmOAJnCYe fyNrhrbKZqKKxssGQPYVXlq1JCBfvjo8a7qLqSeBiTvaposGCLIHTKLxzt2y XoqjLFETodXlBJk5bL5s4nlar6RjHBOv9arDowobos5O945ah3RaWkbYzWZN LSwmdZySpMFJ0oiV4jeZYJ8UeZTa0Da3dTW1hteLhxiwZT8AFHWZjxYHsFVN YL9gRT81pMZ6ApqncFWcSelGnPkTRke3TifcyYpbFnQ8d6Vv0JbO5xwD4ckJ kIEY8FqHTfron6XTPfpYTQwhl6nOQpYY4ggPvsuH4scfTo/3Dvb3+DL09hQg xwxzanVTnpyHc/e6OJOYz097R+3/2Ns//qHV4HsVV+shNFxR7ReNvQNgAtwL vWKHJNxRQoRbiSHOGod0x/lrPqVW8QXjDPYPG3sJRMUTAyzMGaGwfw3sYd+A kWY+PnOsDhs/NQ5jSzfvCtmPUqKAOcj4q4CKDo/hWqMJmiGZbltIx4YSsg5/ nZ7FuzRlxydxNJOivUM4Ohrbcii8RWjIYLGRiPzstX492o+vikqkIEmxmq2D IymtpBdSp+2f2uVKyd+AlCrlkk8hqMpPzdOzVwS4uliLstHIgUh31TOUqh9h mHtvVSb5G2z98lo47aBGp3u+7Fbgy5FrYNzGoHuFtYJOZ7qc0pNOI5dbtnFn l+PVmGcHFFjuDPrhcBolaiCZwXKSUidKXwA7CoWXo0E3vQKcACgfjC5Qypwo fdk4As56GcXmywgulD+G/NK2kYMZUrH3v4kKbl7/Jrng62pFHu4xY8QFE/tx xUSylx1FryqbZC0+E/VYx8v9aAOY76TPnGblT12H77XTv31FiS4TcyAanZwE VW6Pg/6t8HMi8N8BDFklPXCWxGlmpxP69DomYXrrLdsuwl02y1lO9popsCeR 0ST8n5jqnLNL+UKiWXfcRtFkhiQpXdIkYqTyui85isLOJJzaz3aK6jHMBh7t UwvdzmV/0G2PYShS0J9wWBrUZY16XOjr8ymOyDS4Gnuw0SsVyGBPRxizIeiQ DYqMqrX0fBs0/tORZh00fnj1PNfv5W2S3AInDLF1Wo3946MDYG3g3jzY+xXY lvVayRLkl3u/aKkJc8vOuwkvwKNXJ8zsu/yU06iFz/WSl74NCQa8R4EhaDHz 6AkPqRQYIMyGCX83njV/UWoZSlawZKV51ni5LNjHwWaSPbIo6y+q/+/eTQzo ufr/8nq5XK/+DSvUypXy+gbFf67WNu7tf/9K8Z8NAnEMaB0Eur5WXleV6nZ1 fbtWXywItNtTwhLZRIL2O/aUm+VVJXr3zujqCnU/lK4JKRAp4GHHR1fo7EXa 9stwMNYKVdJGVkxzDqw2I0G1Vrk65geopklRe1fKeo7VtcqmKm9u18vbMNn4 HPeN6hhVujjVkKOk0RTOUAfE+n+4FSbUtzZNOA0H7XK7DBNBlWiKxr9Sik+h BpCqJaagodQVy4Sw807bQCMHzebJKrqJSF+IRtPRyDWO6JNBqjzOJYkuKe9R STVki8RAdZBvvQ7FdjM0htDjyQiaqPPZZGjTMElnoiHU0GDzBNbos1ueAQZd L9plCu0X0Cq3O5pOyaSj078KBmhhgZow4ASle2x8OYqmaMcQTTF1HWsoARs+ BLoVD5SiYN/yoFsqbcP/KqU0w4/L6Wg4UNcTVNdO0C6TXH5pTzlpFKoFUY9J WkA4DG3gxsPxNF8ggwea7mjSvyALtMM+Hi3AJNqwS863BzAF5ko1oXV4xSYi lxgUCSZ/gUDArlEdfY0mx6T6FwsU0TqT9hQD6NB4APbzQXilzsMO7jhMO5jg DKk1oR7rDMhMd4LdXWM4stF7bcAy6E+ngxU81YAY40EwpfA612S70ddbPkA0 CSZi5tqZBNGlYusNwKxwykx8yskqb1rAl+oI+Fplu1zNQOuDo2ZL64cFjV7C 3vKpB3QYj4aIEYSdgAXa8TNl2I2E8VN9u1S/3fgJscyxe2IQHzSe7b06PJPk bbL1bMKDjTRMOwGbjbORK/SBBsH9qNcHQOahpBPaIuqeTWPIhpgsrtCMUQPV dl9IWd76wiZSmlLok4xkwNgZT7R1tZxrWRpg2wAVpmmArduRS1WyEKptl+tz KCVcNQBTRicylmcboWvxozgPEWTR7Hw6Cai+mOcMKEueJi1B5x2mEyfnCuTt +PWxol8fjkkRbVkfHS/Z7iwAMtJ5zxaw1sJiHERTmg3G4hI6woOQ4QE5WXDM x2g8m/RHs0jl2ax7BqC5ofrToD+Q7uSmiayp9gAH4B4L5n4Yjd7BebuGlzMS 1/CdDC4DIwDEIoQIZITzx9Q0ZFuAfi/fffddyo7U/iI2beWqnWhlS5WqiDr1 2ERfOQZqCmjUZNJHz1uc0Co6ZuiB6KLT9QgtAqJwaHSCD0Ciwj11cnIirhum YZ/iKXfYZniENcRghVetTwLacaNNfDdlIW5uC7hM4KquJ7iFT7H+Ki+QK+Mu rP3KpU8y9xMrb3SaF0wvw11Kxn7rhDcd4IhGZMI9CCYX4UQ4Czzo19gV2Quy hR1ZNAGnxhIMmKu2Y0nOcuuPMvLbdAau4DaXgHGNQedZ/wMdLGRoLI1DwLeZ NxNnkAk8zMdAOIjiW7rXm4RsqQW7BOzG4GY1yxzWTGNju14BFjo+jUk0Jaez QYjL4wOMv4x5FRDGl8F/A7J0EFazMWIImwYFaDUvtJFQZgCECisQCyHUoHM5 wrOFx4783a7gXl7NMrB1JgtcbGXzs49G3e8O9h748tJnd1dLdFfaLm99dndV vzuivNXyZ3dX8bsrbdc3t5HW/DE+m/cmpfcmpfcmpf82JqUAuOGjKZF+wlDz WBdJRlFNZvqW7qqV94pDTbxD8EuV1Y4TU4KF4J1O1O++xtwny9ZYtbvaydET baGTimBc3rGWrLnvo5tojYwQVy+fxj5HI2Slk99RYJ78inyR/3UYYoqg6Vp/ 6H8PJuNgDUvws9vLtNsfJbronvufep3hdOB/Gl93/Q/JGXZwjf6n2RDQN9YQ vdqCWO/ANg9HyfVeB329gJ76TjtjHx23XuwdHP9ccGtfBt3RNfXAonNAkO90 Rc+wOLesObflpSXadHxvtcVNsFbaQgWIaESG3bTvj3WO8Z0l1IXgFva6/G/U c+p/W52E1BsH10PnN9YlFYr0ytNqd/sT5wtVok+sSIHD0eeQ3O0o7IyG3UiX CMtoP4cfACWHpK4h8JqkQVqRoh6T32TbaHfmKTHcU/IS+KsX4WAsBrYpCjAt cyX3Rtjwdg9eWQPKQm4+XQLv630QPs9+hPW34eEbydMPvyPkljB0OjxvJxed IkZKeO/m4oaPXt7Tx1iBA7rQJgQU34V/AJmZDaYcr4sUUriVKMfDaiiCTi+a EEORUtaGaT2GC8YtQjkTDPU4ek+6L2PerdV2djNQGwZb4X/U4oA8RXhiHSws iKdGek79jzHr/Ug7B+Qa/93rtlGeinEfet1Il+JOziJOBiCIrHYVwYmTCiAM V1aogsVhHdveYjF8oTwaDpZighZrAyCFgtRcJgYE0Dn2RZRA5VvN5y9enRQ1 VtBSnTJA76JFonjpf75qzituHh7OKT073TuZ1/h4XtfPThrzum6cvpxTvP/i 8KDoon1h5xYlIttUk1U1xzfwBN2uisGEkotYGarysRNbVMsteG/erKqjEbcM 3gf9AXrGvRm+mSwXdhwymq6ApA3UCckBYXT0NScFMJ89zBj8aOWRTujLmo48 J/PVKcYJoxEJ89zkiSqbkGgaG21VxFL5GQHT0LmkGWCGYBxjKUfS1kfBo20c DyeCXehs1jzLHDd3JsPh03JxdBbykbPzyNlJwD/PYSfe7ZhBu58/qD0mi445 B1tkOlefOR1AtZzBNQyLQZFr8jE6r1ZUVRWIKKEkdBLZRvkyBu4iluzN0KSq wU9vJhIKJ4R3isO1vSmpwEg4eY6AZLm5OPxg9XFE+FpUKVMrMiALt0PydlwX eEaPtsneoQUX7SDU2XjwwRWa2TrksZSGIu95T7S+TQAfq/SBK3nkt+xXlIO/ HTtUpobkyv64JNEnmzplktANY29l07mQiU6f0jkV8NiW/JCK4QcsWSmbYIOJ jvdHw17/YsYMivqJ1U+m+w6VfuIAcG/C2i/CKd6k5zd0W+WFhYN9X551x8tU n5KOY+VdSj7uXb6F+Eg9jVTAnQJzhLgUbSMxJHWiyGW1mngNxngzXC7qE2Ou TUOjEhNXfMFTBEe+8Qu4kpWnkdjr4MqIb8T0DPQGgOP1rN08asCN0zre/7F9 8Px0Dy6Qkl0c1/8+vpY88koFfA2i3iK/jHyE9LmcPUO6jSh1SBoTU1APHRbI RCPV8e2gZVE9elN6ZCOSSvWC3HNDWGofDkJw1QfKsatkbV4hjrYa0V9Qo3mE njPtvaNfvUoCxoEBGzNt8Om8D3REoFI083Uye0DzgoGeNFsMetj1fNiJg5M6 HodDtdfR2hrV4vecuYExykkWBpNRpIvC6nYs1vNeEIEfRGsPIsJdD3Ghesb4 uFa7VPWRV6GRGVXNkcoPp6NL+Iu+FsxlzW+fxfFZ6t++Ix3Bzn8LfGaofEV8 Rugtjs/w56AfAaUeovUJ6UyiMGJJq5P4y72YEmR8TCY9cLG/k2eLRmwsoAkz K5iOw/sYPw8lO9gBk92cT3Nz3hLknrMjPLUjcLVSwb0N5651Or0x66Rgn7gx 1cqOmmKKsyr8vbLiLxZHneJdJuT54UNFP3kf9UQ6A5St5qfeTDyhxsv2q6Pm L4U4aYluItRq4osOlbABZh5CYLl5DiOY4wgr55fXuuH7NakMR/u4/fPp8dHh r+p3+OfR8f7Z2a8GgaghTLTir6c7G1e4sAhFevdk/vjZYI2xkNUTbvbQAgdl fxRiAzV/yA1pNgkljNeo+xwM2DQDzXbQVJRbQ3WMDxeyCZJDUkU8gYpyGAFY SdsNt3SaAWdzpUazSRQOen6qOsuY+evVUph0jDWld4u2ZhgHdwXkgkfMuWoK u1J2OqBoe14bRkVuY7gMp038FJyGnRANbkmXpsFtH5G3kFUtDtFHZmcn9hZ8 dtD+v43TY5V/KJIID8Qywae7dunQoNU4c+522y4Btoymhox6TfWrkSQgeFOF ZGSXx2QNumZRHb1CmYH9rz9daYsA1YPidxKx4edG8+jsVB5ZHUnuyTthxWDl UgIFHDAgDYF1NFvpQNCjkigLF2FuLN4J3ndzraD4iGib6clce47gE9GV2ds8 pZ/TnTpVCvE6paLdfr6wOG1czruhniafnCLpwslp8RZ2DaXIWQzI9ihxpfLw Uidy6hAXogvdJQkM9MtW8Whok4X3LM+hqNzDIs9fPFGxSxb3JHWLzaIMwEu2 qwxk9Tc4gaqfvcG6p/sNdjfYpaB3s8ESdv9r/WElV+6ZxPDc1kCU7yesUNs2 ZPvVwYlizyhDvIvqfIZOGMGQ9mI00ZmSpQL2k7PeS6yvDKbTAI1ptUnOCtu6 oO8KRcc0wSO5NUoRtIsG29WSgYzpVJR1X+vP2tKSFYsvGbxCC9uicYQpKo0a bLXnJSLAqjrie6oDjXaFecydONHidTQWigsvlcbTiZHVvzg4ZQG+EcuPpmSS qH97Hkr6g5QbPyzoYsqdOp+M6xZa1jlqADZV4sSQSR8lya4wbuOi+clJTV2v Htb+4PbGS8aT8H3im9RLVVgIcyAHWjWH7T1yVnL4jJNJuIL2VB0tuUZk0fjj O9MJ66HTKVtqkreDF9QV9YZ0gimZLisUCnCG9XPIbUGX+QJyIDKtuxpNbpCP W0Das8QUz0yQsKGgLBZpbIAaQtyw/spTQVKCk8DMPiA1upKTE0sMEOXx3DPQ iOhjLXjmkxXZ7gMg/v0u/cVdwz9FcoW64DYMHqi8jFQoKp4FG6Dxv/vQVM+2 4O3fM2S4TZTmcNC1HKJsELQex+ZuSvRBgzL3zNmWyKLqKXglZA+860xVXvCU 88LUYqc2vQr9KxYqyV9Q4wNZ8KbTO7M2OOVmdMRSHF0sgld2vXBKpHEzRwqR wT0+jH2UtBcOV1ap1anIGE/t41o/WEwonV2iQayz0yWMZP534j6k7Ht87zF7 ISPo+8zhVT/GOoSFVnx9Q5ozpdVQiRKgGbFJCFxCaPopwRSjhOnnP5esS3xq R5zjiAx3eq4VaZRiRZqnU2Es/DGN+Qw1Q05/ft8l/WNT/kbDWPpTqck/qhW/ yZMV+TPvH36T37E/7Ph3dchwhyf55CIY6ouZTHS+dJDmgcrXKlv0DkM4wSD4 l7G2/SqDOMGc+M/vHGebF8lfvmAUgwQabQXZd1OC7BhUxhD7Z4fwX+ZONXl4 SN+KeIitHI1T9DA/iGMIS0pV8ebwQ7zFuUCkB092Y50ZBtQ5MRk1LO3IqGB0 bwK95+FUzJoycJ5N7UbMdZC9mtc+3o6uWmDqA1ONNVfsFjAHbhKxOpckQx4E d74RpIj79jV3MewQHkLjEiETzNZnqMw6iGtQeYfz0gwD45i+hoXr7qrZ8N1w dD10IMGXrf3gCR3Mm0Ov/OluXGsZH8rtGfZ2RHhexB/QNj4YCZyk74Q+NDET R3KRT7+u4uyVLRUGS7Yp5R6Ln5kFuKylXIpyLZfgt+wTDphFQlWc/MpTVmrg 6vnfXJXLXEzlGsIlmxqUkkQXcuAAU4ae6Zm3dc6xQDCNzepFBoQKXT/84Xb8 vPFQOqCAnDvZS+dAebVeSzmmmELVhanGsnnaVAT4CPNi4S/bEe66y6nsZmwi 4kguxtTwMyCX+2h2h7BJqiJvY2CWqCqcj3znb0afnYCVBGLaTiuicJBpJRgN MgHehwMXrmn3gAUvV7VEjX8X/jdA17UYIOWHkBn8N7wg8q+EoJ3hcXjQLRj6 4p8vwnEzAjqEMAIX4qPKYbX8pNwIztPXp/OaMj5BdlMr0g2Lr9+Ku8p/uHLa GvMW0Hn27lYaQ0KmpECGZU/W5wmuCS2S2ZbaOZUZe1StxL0UJs5TjxrncoGW 9cCDDrOdoHwLjVAi16NVRklEHsUREpqVz+w9HnQU+n7lKBAcn70A3RcjzLX0 9WVCGSI/9LJF9ZuJQ5UQWWiDUanKsh1Dzd3Xp/cA09QmfQe3XYm+o3Hi2xbt Wfkrh0hJmXC6XgcbBhYzwlta6lPvzTeBC3qu1LlFitSus/uNY4Hbq2u7u1iv hkR5RZoU6JNe4jN+16fc3av4UW9hUSShboyCE3F+HE7IH12jvAq8I83HB1n2 iaUW4vEu4a20R7BO4sRZm7ghGYtG7DbIvnMyByv5xb7hrKK7dKRddEIUqmF7 cswd3JD9nTZfk4mIA0yIMmB9hvPd2XhAKMfN9Sik5e31B1N0OMXACHdysG87 LJ96um3NzmySMLXG+1M+ShKi2QSdHKy1OK29TSfFyFivoovXlToHTcoSuvoR kxDTpWtkLCVjLP3Ms3WMN5I2vOYpm9vPCckkE4/LR7W8SQRK0v673dtkomQc QJWB/OlZs8JTPXxIoiIpNVGd4Mb2YiWp73f1EjXtw1z0glTG67MI551QuD+V RyjZcOjlpM409rJwYaF2zcw40pbD2DGbooulQZyL4WL7NQvkviIpLiDg6Rs+ 7Y6m5A2T1Dia16buX4tmdxPSWt5Tp3eWxroVu84u6qAxgTK0wZCLFfXfmGqs OxmN7Z4aA144KvD0O4DCMTm+6ebbLMkGFnRFNQ+2lZZZ46y8wxSbuQiw9RR3 WBJ00YYnJg1mH4EMyzgnyeVemVat2nsm7Tp24eqegXgsMecYOFBOnq3vxJjA wyMNag1bjL0SmdArlzOA4Ip6h0J5A2n2ejEnNjmSQSNvT+zbe/lH6A/3ZjaU 4CWoX5RLDrp0d8YbzJHaJDYgfc1ikMLFtIy8KSwq9gjxHvyWymninXOOQ+KU eTSUzL092xcHjV09lDEX8knwUy/im08us9DbXKEouLkKhjeFLDwXYH4SqqcC O05bUhDepS0W57WC26K9C6q9bpcF+TFtL9pdxRRAWlqSdg9ZnjqGBE6RPU27 9vpdWuRe8LR6sVvB4wsQDegseyaLMaIda8FwIPswTB3rBDh01+LYjxGFMEUJ I80YzjzDhr2gjyFgeqOJ9y67Y3T5mJhs0p7TOS0cbAeqFpHqSK7ji5EKUDHo cbVGjL/Y28WV9MXx7zS8QAs/9hPZt7BPRSiH1iUeDJQ23vc0tI6B4hVH5qtt 406XZBmTZm6u1St6rOK/8nnqpgB7V0bTGeq9qH4+On6xd/TcLPgWh7CY6Szb ufGiWB9nkgHng/4HreRiaqrp6I9NsmDTHpl+l7u7xgDSWB25ZmreDZjNgeKf RdjM5PXp4R3PwrsFb7k4krdwGkedKpaac3t8M6se54Ucf2Dua9EJRynSr8mv /syiM3H7Y/1Tn1quxBNJVJqVCcWbaWPUpngJXMk4nbRGo0E3qwh2EYvin21s m9QSCnNjXm/j63aXshHrQLgptjZcEUY6n/Vee4mn3urXXt8421JUXZF2Lvhg ZKqn9X44SSoimqdhqXYTglHnrWdqfZchfI6/93QDT1tCGleTlkefXt+9zJuR 7UVHOrYXjK22wJRi7KnmTk8Mirqs1NGI5Y4cP3I2ppARi1+VX8xMaW8Sc2hK VsdgbZIWYb1S/DEOMWKFCQUGV5ZEvLNRyxwbd8LnHrmR2K2wWqWH9iToH4T8 aa54n7QDzSGMAKQZtwF9jj6FT0lOdP6GUFCGSfjfZLdtQG4sXtlqO8FY/NHb +BPCRxu+0VauUAGX/hzyow7D+AwxkCez2xi0hvX2AUYEu6HwNEBPbsZTDkuD bUcD5rvwFaMvCR0GklJzBwNMNW7CxwRRKA4XI8Yk7MCI57kdm09hdWAZKM/6 VEpG2lvDSDehUjikOaFK3ISTtN/ciXFbjPcyjWQU6ditldEnN57AYgHvpBxX pWc79CxS2VJt1ZoSrlmLL6xHuizXwFU7IqcCVDP7+sKaT36deosSYNskSYK1 iF1TYOd2JIbX3qIp4p85/bpZunTfzvWa1bcHBbd/l+gzwH9CMfQNC6HPR9NL Z1staDndrtBtS8y8VaZCUf2u7Yy8WS8AcUxbj5GT0KJsGNp4mt5ufzIZ1F2e SD9/WVJoq9gbI6uQb5A7JqKGGSJGHYOdaFJh4pfqC1FOKrOCaG3qcX/2kULF C59Orn/70YwzR3Yeposka2Smk4G6gOe2uUYNquxudTaGzzDwFdwDFFcsjuxf iOuH1PE9xn9FjNd+ZpMOPGfziY0vqmX0FF0upEtq9gN0QpSHnKVoRIIxzvaj qQ60ysGa5+1/xt6LT6rBIBkM4+5JwNR7PPhqlO/AMnweqya+mfp5iW5ibDyT xJiCazHPT9miSsEr01lKA/XEFhddDsTtIGluD910623kQVXePK2LSk8i1sAd xJuDPLaL7kWfGFg/wqkliej6pDtVffW9XwM+PXkSk97Jc77/Vv3XriMF6L+N bUefIuLfMMPCYYEldK/dmn/+85+O4/F0MqSTbBaRAnp/AV/+HtNTuifMd3og vVcL7fhXPWYJ75a7P2DzTvY3OWCvxt47OYoTPDxNOOMUwJpFxGdr1Vis7bNB FBUN1reBCy5wE2IPAXLvTsRdJOZRRM3xwxpO284YeVfukuyokAkAn6c1Ep4Z 10iV8bhD3SLh+awjuwAdmg11+AeZqGXWAWdidGhxQpOtvKOVjK+Dzrts3RI2 vIXcZJKaTDKzOIlJkhdNWu5ex+Aq3+JaBp24jTV3dKGNtNNw0gz1Tmy8btMN flvNA6WkSytYVIvgxxW9XaegVQFGa5CuJJgl1QY0Lny+zfIMME3ihTp+y/ND TYbD2ZV3xKjKaePk8Nf28QkavBaTBY2XJ2e/pnx/0Tg8Sav+S/Ms5fNPjVOc BR9avYRnE1hSF5B1OuqMBmJHFna1aRxWweiAp5Jwx/1+tNdqHrRCa0eHH/cx XdHwmOSHFjCnuIcSXRBqa7sFLsT+W1PA0RZf1LtOzj6ToHrZ1pekqtjshDN0 QIujxhm7JT5VtqqtkppJ0g4vYvYWBS3BYwk9atF7pD9SPES/XeNDf2qXtfx8 NOqe34Tf+TVRdq/hlz2PHzgaclq5eyR+CgYncuxMnjcT6B+zvekf25xv7R84 l38ckC1YWuq1f8hcF4jU6MVJTejQjLjIUDT1l9WraenRbZo1FB/l9eMw5b5l u4K5BiqOV0Kq6g1zBf/v0LgR2hixdai9IfB+3BdNCvNmqFvRryt4FV64yEQi Q6gtZN/jzPU8UjiyNdIEdUd8g5AVjeREQ2PwoD/IEkxnb1ArBD4Zw/P/MEG7 7rt+Bv4J9s498knp8DdRl2Zvx72iNH0H5zAjokF9rCSZ1iRkq00goc9OgXwe YC7ds+P940NN0ylEDev4OuLfYGn9Y6Wza0EvhCPX/eiSPTe6fcnjNgwvRtM+ nvQA5o+sB/pKEO/hT4Z6eGTzeomTNXRHWbrYXi7WQ1FSk5nJ8DQoTB8GCXWb +gnCMsCAyekbRKFQb/o/s2CAi0Gp/xU8ZzuSsYpWfc2KZt1VMNQh3/je19/3 MMFfXxJ60DBePkMnQZl1ctHXm+5D4gVFdoW6+aqusk/5poDEUXBoU4/SVcJD fTRc4cRBuuE/l5Z0UFVz3CWPlM0qKtvqbAomJQF8nY05JUnqjmKvwrRonZHh 6OXu18Xf7Wbc9VIhedXH8NSEqstkass7aQyBnZ8ZKcYO2BpzeJjEQjDyVT5z Mkne4HPW6gYUd50EKRVZbENW1XO0Ou+TnfFl/8qJBb44yBaZKx0c1yhR61xM C3sZxNj/Qmoo9Xjohp+Rz5RoAXKGDJ+eEn0h9oQpu14d6YFRyDpIGy5Qvlyb KDOVBq665MPrajSEVZrAmph8EzYgNdkmjJMaqyMTztCg3TxAZ8lnzcZpGkr4 gOLEv5T+7R1aBnBa1z6n3ySSsOo1xTgOTCmaB5HOLawTCkszpAAjO3+LUrLv xBwn9r2QFtzOC0jPDzeKaPB0uaiSPRjrU/ch+qlbu4/xmLorLU7FtIJhXjDz bCFjk/0oPM594W+ypMSUPgg9TUrZQPfg9XUVTDuX+PqlxLKrCPwppqLQWTmB dHeMOQXlxtUXGWyF11NgNopoPibn8xP3YW7iWWQ7Og87oyu4WNHByO9JkgtQ W5qXg50OY4G9MHfRPGu8XARv9/FVf0BkAl18mwe3oy5vlOxT84AzstlFmATU HjE8NfdqJMyrRwkoyjKlZWMZNTwQwlU3QYJEwvC7ysDEVBpjyab/vvZBtuBp j5tEuMBydSeGdUCfU8cwy+dI7DK1quKWZSal/7nFlBX+IffEIWk6C2tFnpSc GHNgNzSHCwc3LyyxOzOKkuVmNy9Kdhexl7JtDdzoDJPd4EUwOUfhDpzk/hRD vwEXiU4EE6Sbs/Hi1O77lEvNW14pFm3kY8bKkgjMXFjR8KEak21TSopLDNxg NIpP2uvwu5Rpxoz7F2eaHGayadPSd/tduTcoHSruDlBdSUutyfJYiP91aLpI zz/vPTudiyD5jpSz7F4tCUliYe7sXXpquA3N+bP/4LA7oCu1G45D9vuejdE8 tGf6gkLMd21xUndU5HRBzu+Y/LGoRhPbTVw66QEiZVM/lReNXZrQGVNQ6A+e MLBojGgiN80NQ4CSwQbsuZ7gY5w8uFYAbApYQ+IXuKJkKEoIyndcVjRxlvgw aVIZE0AvLxM+Z49AEvc4u0tc7OUkTigf/fNRwbL8v/+OPRuG16+6jFus7Ysy 5hZLxnPLRFEFkDrPlMHRB0wPfss8/2dmq2bMk7dqPhR/aZ7FJ5cxoCTtMbZX qUM6su5bRhZdR3xwv0EKTqVdrda2OZiap6+RfxnmLkZW8buIwPyl3ib8uvXh owkodR5YzlGmtgoM7oUOD9n1WxPNNaQM/5GgIybTWfIVFRPFIaKimpPgQRMa zYZkD4N0nv72pXG6Rx8e84VztlWqlG6ua3TKwYorem5/LbwQBp8zel8T49Dv assGAiimVg1spvoJsdsmXZzDTnfp/lXBRdAfpj70vBkbcYh4D2ro/yBxmOFh 9AATNbmNisq7zHIirOxcUthZzwFNdxN7f98aMeeWc4RnPvGuSxWYxhRo/sDz 4kBQd/gwG7vd2ZNUTIpgb9tlShqPDF18V76R1NYIzfmGjG19hv2EFwTfuUbn t9ZGFhYWvsh4ofSEa2mONzotk3lgG9IkUsQpxlmgWm7Ed2EB4OiqmOH1Ttwz JNXkXPcl4f8/0UXEIsJjEZtm2zB1R64NE5s0raYe5HnOIY1fTpqne/5to14E kS9i1YPQbNh7g+NncD5HeDLpEm8wN6geR1ugBt8nbxazBY7Tr7MRy0YFh1Nr 8FhvJkDJbzmdzqgs4pEQe4Z+zfj6MP3/jK8tHgDfWQ+66iC4iWiooiwY15Pz pjcj8wwnRt8tvjOOa7IbjTkFCTzxkMFgu4m+N1Ry+42dS4aw2PHotlWzMNVx 687CKNOJ8/2WJ9zijlFOcJW0cbQ458XeiSudmDM2JduJQcjfKC+zh605F0Bx XL5tj1vi+kcPNtxe3G/Hb+qyj9kaJo6zXdE2xns8Gl2F5Bnv2nOhnAqv9ojF LehLwJ12jZbUogurgujx1IGrB0VwjpPfGaBNuPJzcKMQtrbVJxObuMzIg+on 7uQaCdVIPw+P3fesyrfsIcdzZxmLoSgcL51Sr9pRNQNng+bokLMYRdRdTpLV 07GPtUn+3MrGCHc6WcjmVzebY/iLyVLKGJULIcUYiQZKZy/UEyyaOy83FLXa Bx4NUYwSa1ko8tvhiu3afeOGWHeYHlDyyiQmYx4TQnz9A6KpZhYJX8uQJybD WWuJWsr0UsWFxAEtIjLUlwab8qWKCS3tl1rZEkIdawVNRvYx6wHOYd8wxT70 9QtVr23ZcM/2daqnl8Fc62w/y7+OZuo6GE4BYBK1U6rejGb//Cfeccfv4JA3 SeS4rDPxLJeXfe711mBbucXZ0FxaZK6c5QIduHreUikIHXeY0mAhfnTY/0CR L9JNQCJR9mk0FfxL5U2SzEmMS8xpbPaj+y4w//g0Uk/L/KE/pkaI0482iXrq jv6JkaxvX0TK4Vvs/H+NGNHJK0jiPH/nXe7Cl37ahOJhldNY1gzp9EKu1F6y rUXt+DUupBrCOxb0c82A03J6OEJmLeIxkc4kdBWwyIWkWr/o9eOao1C8ZBRR XPYdaVXekKFCKj8xV0qsETtLrODK1xcXLUgMJafvue/71D2w0YVufbZ/iXvB pzszfBuHBAdbk9Gzxf/ADeNASqFAnTb+AzigVTFN4kRlOpLujag8RCAF+Pa+ 3w3vINR0+knzN3i+twJTZbHZzw5R62UTi+XdVDbhZqKMcnICdz7PI4C+C4MS Yy3fpgYtMtnM2joJWiIFmmRIuyURWFqKLAKpzpPFcpkfKHFdNIUHTDDpGk2w Tj1ltEexBFG7acGoY6leTQopFa+N2DUnPGC8ZSL4t99e57FSXgzVeN4qP2nV rX5+7h6oeOYp8XAbjz3RuT4SBmbIHHw3N26A70rs2pNie0pbwgIsTiaVkcAk mTQr5zyyEPTHp2dw4bRae88bfqGJ/5+LPYzonJl8GPLAIqzLxYDzxO3Fj/rZ CgWZddYBkZO4yOWmZrM5z90RjEuhbxJuUFXMvjM9tA38zcZzLd8h1B4NWIo7 fDHeLuFTal6G+mHmjViMgSvDJ9THUd1TqguqXFTzplzyJ/kJeYUXzdcuyVE/ O2E7bvQgqdxJy94uOJHIbpeRyS/WpZvUryUK+FO+VmAlFGYXr0FMyfEgKoiN uENIiqnJ/DDH3y1eF/oMoKmwieJqheK4ffAxr2+kBNpwVlh/X3WmWK2n9e4q dyOdrUrseKHwTfgOwwl+CuthnLs+ifvghKoUVTRkC+w74kfSuFsilTT0Z3Mm /Jv6+HxeBc/yPbuSwj7s78PV1zaYtXPPM/yJeQYHQnyc+8PeyLFi4o8JEJEp kwYK1WFr4nmw42oaeu7iyVY9UeAlS4qtXc6/vtUdqbSTeykTBvdM0z3T9Kdn mqxs/J5vuku+iWJrfALPNFR7+z8eHf982DgAtok5JfL6MTqayyBiQ8xoRq4L vdkAOuMIInclucmMEPJZaYT+VDKaP4aNMfIT2O07Y2HSLxaXk/kDLhZ3+C+/ WNze7uxi8ad8f7HMvVhOflZ7QCv+CreKv6/urfJnukFYT/LZV0jKy5uNCK1l iBvKmd7e31gvkNAEiRLoU9QDrumQcT/+TLXBrB1d4vGIv4U/86pyntBF9RiV w23+J/Qs/8JHW9t/YmvVdVvuKc6rNxCzGtOrHx0pPW1CyjX51W+9uW92X+R/ d1feZ5Ksb0KvFpAnHI6CLvrac2DMYa9/MRMzVdp1G2fdUrrky9+xmhVT4Vst ZNPyMvsBIWOa7JNR1Kd5kfHQCLAOow3q1FYjjnwW6bfuGHhHuPTYvl6C0Svr kkeFeCqK+ocAKRDJARxXDMyAyyOTPRjnHOUJozQvJH280IKWz5OICuxHNKvS BfrgmZLKjiddKPnhvn5qHB0AtrVOGvvNZ839JdcgFuC18hQq/QRYNZq0OJxF R5tpJJxOzmIrw72F1uo9NdfhMDqWTFM4CVm16SXo6eRO2JaHRm87hJ3zpZXo zfWCfewADY5rbJFsq2Fyewtz4UCjeVDwxEcapkVlkoen5Q03oEdjP688fUSB sDWBvZNBUYizqyrqcaI4zZ5BG9HHQEZw/S0O2vgCXNtVbUYkdcSCCLrIMhyy l4PDjktr30xSzIt07ae7KVJE3/vC7TpWF3NyuWbGAi/3qsJV2/OWJl+0exWb sHvnxeWOppds2aNjXJRh6ZRl5aSXEd/yzKVkIKdrnP+JmPm5K3VNqBIxPLTX pUwvmWXiTyPC/sOl1Z8ghRWgMaNFpLZzL5e9l8smns93Kvj8kzxRjRVwMgkf ulqlxKJ2PSjM8wGtjPlxamNbYCjkr//ijJktF8WBo+A+F7HAez9yHX4vCpTF 7+Px+Lq7k/x6EU7H19CNK5V8HA4742v7k+3vYxXYGaXNyfgwS+V3kqYyf3Tc erF3cPxzwU1emX/ZRtAVkjOIaGJ/F3ssjRpjt4gsMi0j850ewWZ9woiAybxD 7Bttf5lUGKTTwyF2lQUAArNABuTJu0MnGV0pu4EZfDCQL1x35en4uq23IQsw vi2136qolj+kJv5gRaSZdTROnbV2Q3LmizFfUneCmMT4GqL4Iv5uTOUya0dA Ta674x1nk3gU/d75OH/7TmdDN9tXMLgYTW6ml1fcnNARjacZDzWY/LlYCbF4 eHrZGQjO1E+i3a0bnUgxe4dUyokoGqdT2ss1ciVp5NLK4UuP9lqrysrHI37B IqWS252fo0DkOEi7hJ3Rfl6JFKTQkBLJ6ZBaPAyG3Ou/RwbiXXjz9YmeF1E1 Hk6Vt0hLqbh0J1Pahjv6rHnYAPpFM+91HWkU3/km2LZ85fveSwFK0pIrPyr3 7dk9UwRcLBazsh3+Dee4zd+crKDP+sLpys7G0kHKvaydWM11fG698dfIHX8S dPuzCMAJH0/3DpqvWu39w2bj6Kxl8lfnNWwotfXY4/VMf5NlJjB5BmdqNm49 m2jaDSc8CcBmTB2N2Yio5wckeaFYEYJLXmjU8WR0wRcdD5xIWe4dSQGak57B kSj1KMZmciWa/5ABikqvvnDL0wFB9Vj4RIzn8ncTzsXz73TcZKJOMMzYHNob xivNYtL4lXl96uW6CMN9eK8YXS8hTkyPQI3/7XUGQF+UwQSPQdbTLiWAp7E1 JfelQ5uaJwpHx8B1nAxTHVHApc5sQhs9VUBtKCRUKK75FJiug4EthmiNIn1F XlAhWeV3KatMC7SkYe2d0nic6lhIER27cmLmf9WPyAebwonA0LHIvjLI14iO bV8n/FZygC/oMu9sLBn3WI4uS28/8r6ZishWU34MK7Dow89572mwJnA7rbJ+ m5lH1uenvtHXgTnNZr5PUlsm5pl4hGZM+HbMX3iPvh3nYGXjyfwfZC8JG7+n JXpOUlT94uuGEcVweNa/i8eMK7nHNyT+S+5zvlT4do7pxzitx29y6rkPDDQX v3tmSO2Xyc21qJxA13wrtVGQ2cYoEHbonVhbivDg+M/d8VuUI/L423TQj8aD 4EYCmwLx+0C0EF6eE2HS+hTv+GISXN3Ba5OkafnC0i3ugsmL/hW2JKL4Wq0E SLunyHKot+r1yhW7+VE4OZHYvcVqEZQuc/pB+PVB0ceu6p5zS0NYNU9QsK+Q T5oAj7T4EPTQhAfHB3g+ME29W0QQ8h9HBQ6bFSooGqWYncuJ5VLogtTp6Msa KIwEgShzNf76KOLdVQmltWW34Sef5jROGyfYntJflLDG5WQXYWAPj59b5pVG spyraR98JsO6H+dXewxgjK7zBbyqLBYmSttDl4EzA1oFTmClUlut1CJEZVh8 hys/lNYFkh1zS+HYqOE3vmZY3dvuD/uJByqspg9s4L/g6ZmmFN6W+rmU9Ghq Rf2MzsKUTIyC3LAEUj9Hi9QwR0rWq9FsSE40BB9MZdU1R0KnDsYiaTIyAXep /nUiqj2FWOUIRmzGmDuTkPisw9ThjeliMulAVhpmEdxIP9L6BKhgcoPthrOr c1gGTLYb3ESrGgLXwWSI2qPY6oMORrIchN0LBwR+li5ZFK5kEl4F/aEOGcOx 89x4u8PRFKOiYCfcCmbhx3KiHu/gDW9RhC8UpQ6a+2ccFQTe7ZKoyvsGUMMb mqMU8tOCTniXz41fvpyyCfrEu72mnfsU3Iu9ITPcQ1Mb4vSAfSVm6rHpptXY Pz46aLVPGqftg71fY4mgb1nSz4wbi64njkqLLSbZ6hNX8u0Ijp9nMU5zWqFN 0ulES6MDcn5j6cmI3nHwL7wmsYHFHGtq4HDFd2FAtki+yEKSCfYjzSktObJt kinxoCwtI954Er53VAD6WpqOYx//NRoCtfzX2BxDN2LuAmY6mY9SE9AMYw5/ 6LOIwAEKRXYXmS8vIRFpD9egUufgyH9040UzeEn9RQLkxRN2yHwciAuxkNmb rpPRPkylhWIDOqlNcZbuC84LmWG7jfd6hYm74R2t36m2tEDEhrwUsiObpYv4 hiN8Co8mN/SCcpjpnMdGG3jBQppwMTCjYKT0rrTGQowYrGWXxsfg622Yv1+J mmipwpXIpuLAdbUylUxAKx2xKdaJsaaIEVnl73MWgjqbSVaujsJ10MfEHTbY J6CV6ctDLn2WrCY/ke+WerkIp3iWRz3gPJCLHBfVQzjTBMLkeqbj1el7vA7U E4+yfEtKbwNJxqk8RsuKWIYVuiklIt/ZRFprNuuUZr6tjjwmTJ2HQIFCF17Q Y6CvROT7JL4NKUEo78R1H9jtEj/H2ZeFjClWyvQJs7bNJncgNHEja8I/cDsL sSsAv3na3gWIutO8zUykVljYL8C9TQ35T2N9MvMiu/hi8HUeMuIIFv2eKm+l c9Vy2DLOyWQnbM4YB5jvWB+a4Flo8BmU2qaPnViltd1svsmricDlLg38HZWt X6/gyepjh/H9qN9dioDX7gUoKwfKrh/mpH7qX1jhGUlFxvBEeBqHyzt8/5jy omo1n//YBLLvbF866SfyDscHxhni6A+6Be8SQImoPFh7g1l0qZsLCcK7oRxb x+VsnLkKJ3bRvf3fn8/+b3UNtjZamwRdpMmrnb/dwZ9SuVRar9X+ViqVqpUK /V0q82/810a9vv630nqlXquWKrWNOnwvV+uljb+V/vYN/sxQUgtDvn93W71w MneR8KdSq8qiNv72F/nz935viGLjARzaJfRL73dsXmBynlj+xwvyvdhWa7No sobm94O1zvtoMhpN6YuPQMX3mDcYUwWvr5Ura+WqKq9vV6vbpbJ6/27Sjy6H Ab7i1D+WjeSWEkk+Vv84HF1QWnTT0T/ws0lOjN2m9ms6xuoUiD0kPwf0EME0 TxPMHYkSIaCYcmkgt4CGdPAV3psrwTDqq5Vx2A1QZMMcgTtw2Rm4rEql7frG dnXDH1j4Y+iYm3Eva7Q6LOeMAiQOtT/Jwk7t+SndD7Cb5pD9clucZ5J7Mw0P ++9xFUAcVAO9I4DSR2FUhFadVVNpfatSUj+OYNX7IVZSJ8Hk3XVwYyqcAKwi WDKmhtnfgw9btfr6ujvO/mh8M+lfXE5x/ZXbhrUdh5OrfkTA47w8nG2rqK5G sOHwN/Jh3X6kXwGkJIlGvek1OmDwU9NOc8wMJSfa6k8vMV1CL6SkCujzARt4 MYFVhN2iI2y/pNRnmElPeumYpWA/YztDlLh1oPfxGNMykR3TAGtjrlAK1Twb I6qgFEL31R11Zleo6ea0OiTKQI0xEN15IKKQjGLMY/oCFiTovg9hgEhEHuPZ +aDfwdTAMMupSAspCaoADGfNmdwsjFjDZOBj/DtgfOzSLJdhL2uGuVz032PK UzsZu1x/mQxShCKJOd0NJG4cWHRnyyx4b4MJ5rFbDLHhKfwuxJyBeHgpo91U PIGCc1iz6YNUcbP+NDjvDxCKo146gmnEgjk0p8pBFYNFy5gLL1o2UAUmj4wK oH3/ajzoQxXoEJFPG1WhyMiholGnE/W7r9+q3aXl/5P/e8FQt1x5tb7Y6cKl U371/rAzmHXD3PfRTbSG7+Jo9fJp7DPa5oZT//swnKJb2Vp/iN/dBtNuf+TX nQ1hT7uJ9t1z/9P4uuv3tcw6n9XLZfjIFovq5d4vJz8f7b3MbXqf9lqtXK68 vrQk1ltAnN+LMffrWmkL9U3GrsuYecdKHmtmdWeJmE1YNequpJTtElLc86V8 NKBNiIV7BhDTeyAfTC46cEomF+8dfhY/7viWbFjj9Vvh1XEWgRPniGPCpnt1 0hX6BQ6fughuBtSaPI7ej1230uh9h4zEdzKcT3n2yM9oO2T5NgyvES7lBGDi NSrZNbAYtiy7wlW3juUxE77HsCe8bZlGdvozxwQ2Bnl61QRUs+7FQ01JYWqw qr41FUR7YzLqZi2Hxj90jkQ0KL01z27EFLELc99rWlNv38FrsYzo1B8JgfTe 6N7L3Dvss9gQw86f37CNkpw8eMAtz7rjZfM2p8qO24NGlsQDO/lKPBqhvORS p7hGxeYam02ptNFYjmZkhnp5Gg1hysBhXKJhn+xVAVcCrzLflUHDwrE9k2yl vi6Nl+JEG807GBEztZPprnATrZxJFzQk4WD0yqTsQbMw5fX3ZjgHAAgBIkto lkVUWeXFNwQe68f7P7YPnp/uvSyqkt0yrv99fGZ5fGgX8E5Fy4H8Mnd3y9i3 OL0YGrSYzwtV/3yXl+YRPoXbe0e/0m7bs4p5TkuVOjbtjny3L1PnyRNj7Jfu HmPxyjZyEFEn1z4nlR0DuWhgMN+9hTaDc5g4k/5erdfgkWc2zil6uitl3mJE 889jm32L7ytOcP6uahRd3sdwPBQOw3hJQBdERuSkahoSP199uv+8lAwpNndy RRaVoXvLx9BKj7a9XDCLfyx1bcZEX/+KqyjFNEp2LigDv2Uu+lpyJ3MEzVIn oyt/hdmQI9H8OVXcOZ2GK6StyJqb9mdIWVii30JKNHmz+e4AEYZ6RxpFRq63 USQTVyGwy+TITibGh4mwMDdGw9yIzRTfORaCgTQuwCh3R1dtvugB/envOb6A nx0/MS1wgTGwnagjc9O6bqGvWo3TNvCrpGAyHSdMap2DZVxQsepTw/Am/Fe5 J11sKZPrd8oekhUXGCTU08MVlfESdYV5wr6kCC1Nh7xwF2mSa9e7t+N+93g4 t6/G0OZ28fvMBptG9nSwwSBzoAalFmj6whJOk2x444liHBjqWvawOXBMRKbC 1EQHixpXC+FLt1pmPtc52m5tPTuulDSvXtS2mn2TZaTbDKsNi21jV8D6f9EJ k/U+6kToBAvX0HyRtDvuFgoeYd4deRT03zrWdTGMzUQ2995JIu7x4cE3QF53 7/4A3DW38Z8cdQ2GfUW8/StgaYpv/yDNt/9P7Inevt0LXT/oZC3iYK756bty L8ehAsHi+MJ33ESgKEcix+HklBwRk8kHzJPRXTo1CrEqpaI72Yc0GWvqKMM/ TerT8Xsb+0XVaBL8MooH66I3U+kjxtCVnJdN/AGBrZkBTD44bGvgBL3Z4cMW +AwJLWAddQRzXdMFrGqkYCx30e1iwjHLKCpf1JIeEs3Ia26JK2ZkhuPBTXtO GE6p5/ilLhKtM4PztWvRU7QyDffoW6ww9b7zOdMMhv407IT992HXJNPmuCpC UAipF5M4YFZdzqrIDn3Yi0scNfF24bcQx/HJ7PnCt0/C08yPmmiuvqzII84W z43eaTdHJ0f0geD1E1/RvNeYWP5iyMTUXRT4p+7ixyUnY056upy9/R8zBjbM S1qgXneMFEtiB/X42XcQDvt+q4+ed5HTxDru6LdJ3Igw7oqT/u7zCYaW/mpp OrYZjhxJLCIVfoTTJe4YbKSSdt/brduJkWXqFW+LQEzW/fDsGqUfckV7OeFV YGrLQhyLDjb5ER1aegFC9M+n/xf7DzLLuxvrj9vsP6rr61X493q1tFGuleq1 dbL/qNzbf/yl7D8Egcj6o47qzI21UnWtVEdjiVplu1xbzPrDdhO3/air1F49 E4zyKppbAwU+OGq2tCIbCyqr6iWsgd0adfisiJNS9uGfQ4w3+T5MGn7U9KiV NRisUtqu1LdheG9UHjIKx8EE32IUroaS1+NglLJ+VVE4xoPGs71Xh2diLy+e R2wQi42wr+sAZ2XTOFMfwGZf9aMepjdHVrIT2iLqXl1j5MsAw/CK71OfNPp+ 94Xk6qp6dWUAqypvbFc3t2tbMXsaFg+iFS/Dc37cR4rKyU5gkxEOq92nMux4 KgDVynZpY7tUipvTwH1PgUyEM4jIRY2u0XJlEydUqa+TI1mnM7oaURiDQTC5 wKpk5YeWAtfYFRrQX7Olj3Y6YfM6mKrWW9/b/Nzb/Nzb/Nzb/NyBzY/caTkg KZVvZPJD1YFL/nxDoGyjH/shOUIH5yidUzSCgx9eugN1z6+41EQVgwoEwFRL ovADgGSo4iY/8hnfBTa4xI5f2/qg75jdQWkJXIXhoEu8PvDlUoA94S7BDR6F 8QJU/rdRrkZaZHxGamumZ82jg/bL44MGaY1ypZSC08bJ4a+5ckpJ68fmSa6S UvDs8FXrRa66NC+gwx268yBb0cY1x715THirIeWONuyHZmTogw52hSHN4Pqe hjacGcoz4VSmuW1GnNoeHRWRxvC7maIjUEsOSw6H2Y5JbIAbXWtVfW0/HgMI HciRk4DTfMWzgH9khXZ0XckeO43Tip3unCdwOBWna53yD9ka8xu1mD+wdVzM i8KGOMssX7JB1x9j6LJJhHR+iHeSvdqQuYJ7EbmnCTPLlBvcNLsIh+FE6x+E 35OWeG84OcQH4kK6agJCaa2DXUXRSA94ofD2sIWOm6jAISbGN22mI56vqbez 5PqdaGuSj3gH2SAWP9ggFisUx8Ecu5PTY4xHAX83njV/KTpzop7ZxYWdw/M+ rdB9ZiGOiY6B43iBh/TOf1T2TywkeIwkCNd5h7FvwskiZIFYf+9pc7ckgcZL UoOvTQzM8v8QYqD9x3z0mj8Rg1xo1tC6+0C97txuwRH31hCeFb7eLZ5k3Bpc q8l2hkjh2kYYgKaXxAkjm4tMfImpXxeIIhNDPTndIIK3ROdSB940Np2raj8m Z5CaYSSZaidOfE+643T518ZjJiTC3HwaNmmQtVmWICqyr43tTnfegG6gIgRs dqSijFCfjtEvztMx8oXnaRgPucBT7uGtGC/i6UqRw+VS7ofZFaP4jvmJQSEB h7o7KTwv6Ws4vOK+CaLIqoP+cIxZUv4VTkZaDYQdMyLSQ2uKvktym6JChA2x fJaUTZXJEkpvjr5D8et3aSZyZEVHbaAU/u/335X5+Wb6yI2nb9zt/dQVJmcs XrVuCHwBvKMRsgaKOKwu/16VFwlT6gLHWEx78EnqJbLiXDgxMY/HoXOAKUq4 ZVoWinnlH5UYllBIvPMrDrMjGmdPvUQR0xw0ESNnxvqUqFlzw7wmkO5Tw2gB Je5+SRgtOoDmMGWHAHGOVWYYBh+QdNBWuz56y0eUFSbRTJnTiGAMKSEKNbAo qCvoLhJqP2/UZZHoLu/4pbHhTTUDqOx52EOYOhU+W4A/ouAv7KSFDXf0wYzT J/SwtdFaObSXQWtejR1QiKX34bU/n7fm8DvBZuT9zM7Izran6U9jgVvxQPMs 2ZghZs6cgnvemU4gtBuYNTVaK144vUmIEXSdiZq8TS6E58QySJDT4SNMRZJN XoUsurEQ3Maxyl9ljmbIJDYwuxTDhtTddM5n2m6mU+gv2ND5S7el7rw+FTBe vQTdTcSlzgxHzaR5kWDUV6Lg96/pWPouJ5I4a4pMLFHKv2hfVggwJ82WZDyf DMm6Qc/WwhZtJ4iMsD+D+CAI+yQV3jrXfloJcgAFKHRiOfjDGVpXVBs6G4Kf /klM4RdohlAx2ecfynQ2gKnL5T7q3pjjSK2pJ+7VNynS5pDFnE365sx5EQKn J/KpxC2XSzsJuVwmYcOiGFkjAGScGupJcF2wlT/6N4cFU4KdJEGmjcyRwvDF g60L7+h8YfbRQ4aM7fDo0q3boZEojUjpHYnDUWD+JVszD9hZBOoTN4L+YhjH wKZ+Dund2MX4QBYyyb4Fds4jDK96932jqzgPMZ3SK1bFjWPjY4Ibkd6MnfHi eTU2Iec7aCWH8aB0jkdzAbn84CLx4OYt8Pb1ZcVAiu3LRyv7P9k7bTUc4b8j /XeKGv/5au/QEf87RbQgRwHgFDWPoLB5gDqAO5bo0QFKBB7Hjxw8VQ7vdKTC D9NJ0GHZcKoc5g5CLxodzFLKYaedazsByVPsTj05g21gJez67U9tcVlwMXl5 RGCBzieK6rl3doaGq1PmkZ1PFBoUv5twqJ8RQTUtkrr/bdAfvnMzk8D8KoMR cAeuk3TCd1qHFLtSj6dXGRGdhejHUNuVGgg+uJyu+8kyuxkJOFLvhPinohEy 8EcSI8TSa8TSWuLMqZEOweQvYZu5KxtI33iAITk2CkFBgKLmIGx+SyrS0V/t FksDE4aRGCoHI0wkRo94+6TekPkk9Il6pMWdilXRy2v8D2Z7xbheDkfoQnY3 cf8mByVUMxTf24Hs+yhjSZnTpkH0tH/i6LWxzeCT5+6F2YzPj5NJG5QaK9Nb zgIxM7UAVMWCZ8Yssy0stL7LDZJJEUGf2sbJ4JhcQ5Jyz0kUHEv+SynZ0WyD 6DWqx1kjB1iLBkdopSX2EXawfmTbG0sSoPyvWup0dI62I5Hz2OCpJtMR6ykn Soy9n2ksoT25Pv7gLdZn2lbytycrY60bjNQPC1oUMm53yCBmokMby83JzhN1 +xe4pY+lH+dt4sfjDKajvkbdQuKdMieQtO6Y8NS8zdKiSBuGlrhLyYoxj5X3 X0j+fJ3w0V6bOfCxQe30Q9zpz712Foc5BnU1PaZF3ddFV+gqi/ansRj7pgap 6SRqpSUh0ysrhD1rvmwcHu/vHWasQAeHwB5oKJXn5lo6YDpwuO6MPq7e8Tyk A80Mp/XgAcdNuUvkyNvquRT39mC2+lqw7FBmJGOfKHotFHMmcy8FZFSgpsd4 SZHwE1hDZpvF42vElc5sCw9fnY6SU8tia7KyHN9ePzu0550qWPlqTCRCRTIf SJJ3rGPVnHx1riq1Bwdd2w3zR5MMdWoUotz6zvh4ihZq73e2xiiq2Xjqc/DW ysV8ejwjifRvvjbPCK6lOKa7Ws6WvCbltssJsa3/e2gVX9qMBAf2lVyuFYob hzoxrTQNmeJlWN9se8odXUp83io2z+mt62Dhn/my61coPko1q/FWa6IXJBYb W4ET+vWuLVMoY0DiJcuShkjn5IglZFxFW+zxIOjIY3c0gVt+GAwk2wmJXo3E lRk2HfIbrRE6krA0vIrYvtaYK+gaLMUSE/3LPjA1KLFBW1u0Ir2LZFAGElqf 76YroH/TnBYxUknkL0gUUleuYn406LJefmE9PX8rm4+Z6vlPzTfERi87yWbl +e1eHB8eGKfzl6P3YUwTTCZxCnZ0PJpgshhkEWzwdhZcsbuqnqUMu7jSxKhh pacH0ZcoX9cchTbG/WF7KSIi1svErsfGICNelXY0rnMuf0lu0c9WMpdvc3w1 y0T/DrvMBTTo1191MdeT/nRhjXnaWjJMOebbT2A4CP3ew32W6AgAi6IaDYEM TdB/NjB5g8VN1MkYv6Cyi1Diy3Vd30xZZdhYV3YOWwRgmnHAp/4Qtu3KHOO4 DIDRhnb8zXTZagA8RsJJtXIbJ5vIbqgHsH3Ii87P4WIYZfNAzBhGmPDMdcD/ ZABikHNKuYliVHxEj9FO9vZm+IZC0aXAg++/L4MH31cxeEg09K8FD7OEOEh4 AbsqPuitIHEAkjjNaPh/y8tJ0lvqU+Erc2Lat4yzhqMUUjRzDtPoSm6Tmrm5 c0hZFrktzFUQZvaYVCExkdlJUyp9yycX7ft4Imnp/NwmMIWIfeKJLxBemMLS SMRxlFeI2B2ZyT6Ze97J00ryOY6G08uI/I6QDi//R0ARO5+F5/jXy2CCf+2N J/zrBv/6jxneUlh3NqDS2QX+1QrH+NdxB+nd8tHoPf51EHaWP+4Il5kmY3GZ Sv4st1xM9/BbjCOsbb713fydYKC0pvTAPuVKSjQfz7hAANJ/qwWARVUteIZU 06uVp9OrNlSEfvssHMGQlNW4GZWZ0EEgma50U0yNogV/D0VdVHtrLuWj0TW1 u0E/Q7chfYg33HhbwAwYW6USova3sP/T/v/T/uCu3P9vy/9QLa9T/of1Uqle KZVq5P8PVe/9//9K/v+EQLHkD65z92Lu/7qXf9x7jN97jN97jN97jP97eowT GfyGKSL+DP7iKf7fd8jaO6Hl4qw9JyDEEMmGu6fY7yzXg011ItT30R9sigdF 54G1XmdW1Ou0uIO8zXRbL3mx8iSYoxu6T2dMcJIOYn3KCXApWQctRl5yT0Yw y30MTd4FlEbZkPsSR9IJIXkpmQpwiPMbVggbedFD3TQR+1FCJBaKOnilibh6 OU5xxuBeKtAYKvCMi8qZhSsWlfIU077L8crTy7YU3u2D0urHs5BuGMMuwjwy 79I4xgxNQCWMbnypTLKQ8uujHGHDkqvsx8l4D0COFLkYssk7sFp5m2nXJlhw MRp1/TFTsELvq9sF1Y0FxON3lY+pfHy4tps+w8x+XuJkm1giiWQYLhKOyGOu g/0w2hGu3j3eWbgl1Mcxz0Mf/WCbht1g0r1jhPL21SFdkmjHEC4K+TGatjuj 2dDkeSHjHP2JEknILx123qmgP2k9Ko3oakrNB5XmF8n0DkpXjRbXjCZGconB ktK676xBEW9/vCtoWE/3qnR6l/HIn9AZ86mqxkV58X5jIjqcQ9wnyTYBWFQX SOqaiDCZNKb+eMcXur4LFiWtqbit726xj9As3lyK/PXPg3uxaUGPd6enGDsn r3nKW4WRlM9vpuHr2lsvrRFX/4BFdGri4rVainSNaqOkjE/q06fY4rHaNJet rsB/P7Spdj6wWOTZsx0H6Xhe/be6gZM7KKnrna3q/y0XndbVt+6vylvWudkv Za+89Pbu02GL50cSC/EZrUP3oRkp+/yfo/GOthiIWdZrI507Ma+3LiqOEX3S +Py3mPk56z8sCSV7sEU8NBzrLK1FSTFvswZ16NVrat099dC8whcyZrxl6JRj mP9vd40yX+byPfAqiGL2VfzJF8O/zgiV0Nf/MBeuT2WkcMbHi9k0/SgwZ39n QerCtkMwG+sl7dzYOlZ/zLZKX+S8Krq5V/kmd77I5c79weCuYsy5jAVYWfb6 Lntn1Xcm4YQ0N94K+or+6Pl00xW9q2qos5b1OfqI1KE+Zq9eQ94oEgB6vhO5 rvC9KtGQ+vdTVanXFxrWLst9dNlb4Pvv1ab63Wy3RYY4C2weZn/GOMj/rn9E //M+nKAY7o/I/11ar5TKGP+5vAEV6xtlzv9dLt/rf/4k+p9md1sZBLEqHorF XNlU5c3tWm27tLWYisftKF3Lk+g3JdoyRcqfjlhEp1DoinwVRiaW/rVFJl7Z VB9mgpdugEL7q7GEW0bPmLQAxV+kyblX5dyrcu5VOfeqHFLlGHKXQ/L2Wdoc HQAyU6mT0MYsEEMXiJTCuHc3oxlBmcDDRqERG4+68Bvz23WmPfcFdJrWDmdX 5+Fkh1x00UlcMOr/DMz6VoHoIkMKw1HLa7SchUsHB8ZcHBd0lKS/iPTv6KfI IfFu0FJzxtH61owLfi73U+MUY1/mcstAsdfVVp0C2a8v2xrsKsm1loms69vl brVLspD4W/KgH40HgU7OI7cNA89GKpSD/dUfh3qzKJ3LUlpEDI6H8Wa4zM+b ZQc9J2EPCC+6EEk328qtiRdvOLxEH6Nueo19unTlnYy37jYaosI0/PAasllF 5eycMsZUl5TngHIdDNiK2bnWe2EA7wz2dqVAEsDaKEaEbv7gB8rKmTTjRruo ZeOe57U5Om692Ds4/jmjoS7OaJ3ipZvRUUrNOX3G4r7O6TNWc06fe/v7x6+O zjA68EI9p9Z3+s/aLiBgGIaThu4zIe84eDFD4hfbuHY7GIwvg4zJSGnG0trt UdRrtzPbUmlG26D/IaMdlGS0OY+6/YxGWJTRKpoNMxpBSVabm6ie1QiKMlrN hv0PSM4zWurijNYv26+Omr9ktOVCp2VaLZ1dyksOdf8Ev/9z/+f+z/2fP+TP /wdpF3PMAFYDAA== --416219727-1036599753-888893401=:6985--

Two things, Make sure that you have IP header compression option on the NT disabled and also that NT has the latest sp3... krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Mon, 2 Mar 1998, Harry Landers wrote: > We recently updated our 2059s to version TCS 3.0.2. We now are getting > complaints from many of our NT customers that they are having problems > either connecting or going anywhere after connecting. Has anyone else had > this happen and how did you fix it. I looked through the archives but found > nothing relevant. > > TIA > > Harry Landers > =============================================================== > Harry Landers, President > Panda Communications LLC 185 Walnut Avenue Santa Cruz CA 95060 > Home of CRUZERS 408-457-CRUZ (2789) fax 408-457-056k > > > - > 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. >

Are you using 3Com equipment at your end? Are you using the latest firmware? Have the users upgraded to v.90? From what I understand, if you are using certain Bay equipment, and user has a v.90 modem, they will not get an x2 connection. If you have 3Com equipment and quad firmware before 5.6, v.90 modems will not connect with x2. Certain Sportsters upgraded to pre v.90 firmware are known to get gibberish (Buggy code reported by PCWeek 1/8/98) & referenced at my site: http://pages.prodigy.net/bbhi/r-rnut-x2.htm - buggy code reference: http://pages.prodigy.net/bbhi/r-rnut-x2-2.htm#bug) -Richard- -----Original Message----- >We have had three customers in the past two days call because >they upgraded their x2 modems with the wizard from the 3com site >and it apaprently screwed up their x2 conenctions. When they >call into our x2 modems they get screens full of gibberish when >i had then open a terminal ascreen after dialing in win 95. >They are able to connect to our flex modems but any attempt to make >x2 conenctions results in failure. This is on multiple >chassis in different locations. What is the customer to do to >resolve the problem? Any insight as to why the problem is occuring? >thanks >Eric >Delaware Online!.........The SMART Choice! With 56K X2 & Flex Modems >Phone : 302-762-0375 Eric = mrdol >Fax: 302-762-3462 Failure is NOT an option... >www.dol.net > > > >- > 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.

i'm having an odd problem. i took a chassis that was working fine with just 48 digital modems and i swapped in a newer nmc card and added two double up cards. now x2 doesn't seem to work for all 96 ports. stupid question #1 is the x2 enable code stored in the nmc card? stupid question #2 if answer to #1 is now what did i break? matthew

On Mon, 2 Mar 1998, Jeff Mcadams wrote: > Yes...of course, why USR sees a need to charge for x2 seperately is > beyond me...so much for wanting the ISP's to push it. :/ I think we > all went ahead and did it, but its pricing like this that really pisses > us off (you listening 3Com folks?) > > I could see charging for the desktop modems much more than for the > central site equipment. :/ Ah well... Hear, Hear. My customers love X2 and I love the solid v.everything compatibility. But hats off to Livingston/Lucent for providing FREE software for the live of their product. Watch out 3COM. They just might someday beome as solid in connect quality and compatibility. Do not underestimate the possibility for them to go toe-to-toe on the analog signal processing now that they have Bell Labs behind them. No offense, but Livingston already has the upperhand in ComOS. And I don't have to buy a pricey maintenance contract to get free updates. ========================================================================= Jeffrey A. Lynch, President JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

Thus spake matthew >i'm having an odd problem. > i took a chassis that was working fine with just 48 digital modems and >i swapped in a newer nmc card and added two double up cards. > now x2 doesn't seem to work for all 96 ports. > stupid question #1 is the x2 enable code stored in the nmc card? Yes...of course, why USR sees a need to charge for x2 seperately is beyond me...so much for wanting the ISP's to push it. :/ I think we all went ahead and did it, but its pricing like this that really pisses us off (you listening 3Com folks?) I could see charging for the desktop modems much more than for the central site equipment. :/ Ah well... -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

We have had three customers in the past two days call because they upgraded their x2 modems with the wizard from the 3com site and it apaprently screwed up their x2 conenctions. When they call into our x2 modems they get screens full of gibberish when i had then open a terminal ascreen after dialing in win 95. They are able to connect to our flex modems but any attempt to make x2 conenctions results in failure. This is on multiple chassis in different locations. What is the customer to do to resolve the problem? Any insight as to why the problem is occuring? thanks Eric Delaware Online!.........The SMART Choice! With 56K X2 & Flex Modems Phone : 302-762-0375 Eric = mrdol Fax: 302-762-3462 Failure is NOT an option... www.dol.net

matthew <matthew@the-spa.com> writes: > now x2 doesn't seem to work for all 96 ports. > > stupid question #1 is the x2 enable code stored in the nmc card? Unless the quad modems were ordered with x2 installed at 3Com (which I heard was going to encode the feature enable right in the modem, but haven't actually verified myself), then yes, the NMC maintains the feature enable key from which the modems take their queue as to what features should be enabled. You can check the current features by querying the MIB object "uchasSlotStatFeEna" for any specific slot. When queried for the NMC (slot 17), you want to see bit 6 (0x40) set in the feature mask (or _possibly_ bit 5 (0x20) if you had a really old key and older NMC code, but I'm not sure that ever was released). When querying an individual quad modem card slot, you want to see bit 5 (0x20) set in the feature mask. TCM may break these features out automatically, I'm not sure. > stupid question #2 if answer to #1 is now what did i break? I assume you mean if the answer is yes - then in terms of "breaking" you'll prevent x2 connections being made to the quad cards, until the feature is re-enabled on the NMC, and thus passed on to the quad cards. I'm not sure how 3Com handles the feature enable key in double up situations when you swap the NMC, since the feature enable key should be linked with the serial number of the NMC (presumably the old one at this point). -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

At 08:11 PM 3/2/98 -0500, Jeff Mcadams wrote: >Thus spake matthew >> does someone have the configuration handy to define a chassis with 48 quad >>cards and 2 hiper dsp cards for pmmon? > >Wow! How do you fit 48 quad cards in a single USR chassis?! ;) >-- Aw that's easy with a good can opener, some duct tape, and a soldering iron.. Should be in the faq... am

At 11:04 PM 3/1/98 CST, John Scrivner wrote: >I am the not-so-proud owner of a TC that I bought a month back. I have 50 >Courier I-modems setup with Livingston Portmasters that never fail to >perform perfectly. The TC disconnects people for no reason. The CT1 has >intermittent static that is only fixed by re-seating the T1 card. What do you mean my "intermittent static"? If you mean that you can jiggle or reseat the card and clear up an intermittent problem due to a bad connection, then you have 90 days warranty at least. I would get that fixed! But when you reseat the card you are also rebooting it too. That's a different matter entirely.. It's rare we have to reboot a dual t1/pri card to clear things up but it happens.. How long after reseating/rebooting the card does the problem return? Are you seeing any crc's, slips, or other errors on the spans? (as viewed from the console port) am >I have >intermittent problems with lower than normal connect speeds. My customers >using the Couriers love me. The one's using the TC hate me. I need a fix. >Any suggestions other than re-seating the cards is appreciated. >Sincerely, >John Scrivner > > John Scrivner (john@mountvernon.net) > President (john@scrivner.com) > Mount Vernon Net Inc. (johnscrivner@cablenow.com) > > > >- > 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. > >

Hello, Does anyone know the importance of the management bus failure trap?? We have over 50 chassis all at various levels of nmc code and quads at various levels...All seem to occasionally send this trap. Should I be worried about it or can this one be taken lightly. Thanks, tjh

thanks, We have a boss who is very interested in traps and what we can do to work from them...I am getting sick of ring no answers. (as probably customers are too). I have noticed that the new nmc codes (from 5.1.8 and up) do not allow for the NIC side modem ring no answer traps to be set. I have a case open with USR but they have not come back with an answer after two weeks. You can set the trap with sets, and through tcm but it always reverts back to disableall every time..Hve you seen this at all? >---------- >From: David Bolen[SMTP:db3l@ans.net] >Sent: Monday, March 02, 1998 10:48 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) management bus failures... > >"Heim, Tom J." <tom.heim@teldta.com> writes: > >> Does anyone know the importance of the management bus failure trap?? We >> have over 50 chassis all at various levels of nmc code and quads at >> various levels...All seem to occasionally send this trap. Should I be >> worried about it or can this one be taken lightly. > >It really depends on frequency. The trap is generated when the NMC >loses management contact with a particular manageable entity in the >chassis. Until that contact is resumed, you won't be able to manage >that entity through the NMC, nor will other traps or information flow >from the entity to the NMC. > >Typically you'll see this trap when a card and/or device on a card >where appropriate, reboots, and it'll be a transient thing. For >example, the occasional quad modem reboot or something, or if you >explicitly reset anything via management. > >I probably wouldn't worry terribly about a small percentage of such >traps, but if you get them repeatedly on a single device and/or you >get a bunch of them at once, you should probably look more closely at >the logs for the hub in question to see if you have a device that >might be malfunctioning or spontaneously rebooting. Sometimes you >might not otherwise notice the reboots (particularly if it's just a >single quad card or modem that likes to drop its users) but in other >cases, like a circuit card rebooting, you'll probably have other >indications of a problem as well. > >Often you'll also see a trap for a watchdog failure on the same entity >depending on how quickly it can reboot. > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > 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. >

These trap settings revert back to disableall even after a save to NVRAM, and a save chassis to NVRAM and a save nmc to NVRAM. They show up disable all just as soon as you do another get of the mib value. anic.mib.......1.3.6.1.4.1.429.1.7.2.1.1.2 this is for mdm rna on the backside. Even the robotics guy I dealt with reproduced the problem and said yes that's a problem. I wished we did not have analog modems to deal with but such is life. >---------- >From: David Bolen[SMTP:db3l@ans.net] >Sent: Monday, March 02, 1998 11:03 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) management bus failures... > >"Heim, Tom J." <tom.heim@teldta.com> writes: > >> You can set the trap with sets, >> and through tcm but it always reverts back to disableall every time..Hve >> you seen this at all? > >Well, we don't really use any analog connections except for OOB >modems, so I can't say that I would have noticed a change there. When >you say it reverts, reverts upon what action? > >And just in case - although I'm guessing you know, since you mention a >change in behavior in later releases - you do know that the trap >enables are maintained by the NMC and not the quad card itself right? >So after changing them you ha ve to issue a save to NMC to ensure they >will stay across a reboot. > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > 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. >

Allen Marsalis <am@shreve.net> writes: > At 08:11 PM 3/2/98 -0500, Jeff Mcadams wrote: > >Thus spake matthew > >> does someone have the configuration handy to define a chassis with 48 quad > >>cards and 2 hiper dsp cards for pmmon? > > > >Wow! How do you fit 48 quad cards in a single USR chassis?! ;) > >-- > > Aw that's easy with a good can opener, some duct tape, and a soldering iron.. > Should be in the faq... Yeah - I found it most helpful to remove the faceplates to the cards as well as the midplane connectors. Then just slide the cards in next to each other (forget those annoying guide rails) and let them contact the tracings right on the midplane board. Don't forget to jam them in really well since you need to have a solid connection or you may get packet bus errors. That duck tape can come in handy then along with all those black slot fillers that end up lying all over the place to help keep the cards in place. -- David PS: If anyone wants, I've got the specs for a detachable rack griddle we've designed. We hold picnics near our largest colo sites to make use of the racks as a free cooking source... just be careful where you let that grease drain. /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

eric@dol.net writes: > We have had three customers in the past two days call because > they upgraded their x2 modems with the wizard from the 3com site > and it apaprently screwed up their x2 conenctions. When they > call into our x2 modems they get screens full of gibberish when > i had then open a terminal ascreen after dialing in win 95. Kind of sounds like an initialization/setup problem where the modem isn't set to lock down the DTE rate regardless of connection speed. Any chance that when they upgraded the modem they also changed any of their init/config settings? I would imagine that since the modem probably returns something different during identification that you may need an updated INF file or something to go with the code - I'm not sure how the wizard is handling that. Worst comes to worst, a quick test would be to use a terminal program like HyperTerminal, issue an AT&F1 to the modem and manually dial your number and see how it looks in the terminal program. That would at least take random configuration issues based on whatever program (or Win95) they were using to dial. If that works ok, then the issue is to find out what might be incorrect in the setup string, whether from the INF file or manually configured. I've seen people grow the strangest setup strings over time while trying to "fine tune" x2. Since the newer V.90 code does make use of some bits that were previously unallocated in various S registers, that's perhaps another place to see what those users have in place. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

"Heim, Tom J." <tom.heim@teldta.com> writes: > Does anyone know the importance of the management bus failure trap?? We > have over 50 chassis all at various levels of nmc code and quads at > various levels...All seem to occasionally send this trap. Should I be > worried about it or can this one be taken lightly. It really depends on frequency. The trap is generated when the NMC loses management contact with a particular manageable entity in the chassis. Until that contact is resumed, you won't be able to manage that entity through the NMC, nor will other traps or information flow from the entity to the NMC. Typically you'll see this trap when a card and/or device on a card where appropriate, reboots, and it'll be a transient thing. For example, the occasional quad modem reboot or something, or if you explicitly reset anything via management. I probably wouldn't worry terribly about a small percentage of such traps, but if you get them repeatedly on a single device and/or you get a bunch of them at once, you should probably look more closely at the logs for the hub in question to see if you have a device that might be malfunctioning or spontaneously rebooting. Sometimes you might not otherwise notice the reboots (particularly if it's just a single quad card or modem that likes to drop its users) but in other cases, like a circuit card rebooting, you'll probably have other indications of a problem as well. Often you'll also see a trap for a watchdog failure on the same entity depending on how quickly it can reboot. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

PPP in modem was on. I turned it off and tried it again. Same results. Jason Brunette - Technical Support Support - support@tcbi.com TCB Internet - http://www.tcbi.com/ Personal - jbrunett@tcbi.com 920-451-7776 - Fax: 920-457-6616 Serving Sheboygan and Manitowoc, WI -----Original Message----- Cc: usr-tc@xmission.com <usr-tc@xmission.com> >On Sat, 28 Feb 1998, Jason Brunette wrote: > >> Having read through the usr-tc archive, I've noticed that many other people >> are having trouble with their TCs and Quake performance. I did quite a few >> tests with QuakeWorld, and have come to this conclusion: >> >> The more packets being sent and received by the user playing QuakeWorld on a >> TC, the worse the lag is. >> > >Does the "PPP in modem" option help or hurt? I've always had it >enabled and Quake players have not complained. Seems like it should >help but you never know. > >--- >Brian K. Uechi Email: brianu@lava.net >Technical Support Engineer Phone: 808-545-5282 >LavaNet, Inc. FAX : 808-545-7020 > > >- > 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. >

"Heim, Tom J." <tom.heim@teldta.com> writes: > You can set the trap with sets, > and through tcm but it always reverts back to disableall every time..Hve > you seen this at all? Well, we don't really use any analog connections except for OOB modems, so I can't say that I would have noticed a change there. When you say it reverts, reverts upon what action? And just in case - although I'm guessing you know, since you mention a change in behavior in later releases - you do know that the trap enables are maintained by the NMC and not the quad card itself right? So after changing them you ha ve to issue a save to NMC to ensure they will stay across a reboot. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

At 11:34 PM 3/2/98 EST, David Bolen wrote: >PS: If anyone wants, I've got the specs for a detachable rack griddle >we've designed. We hold picnics near our largest colo sites to make >use of the racks as a free cooking source... just be careful where you >let that grease drain. > Another cooking tip: The TC with 12 (or 48) quads makes an excellent food dehydrator.. At 85-90 degrees off the top, you can make beef jerky, dried fruit, and all the snacks and treats offered by the Ronco model costing much less.. but do they have that delicious "modulated" flavor?.. Not for three easy payments of $29.95 they don't!... am

At 11:41 PM 3/3/98 -0500, Dan Irvin wrote: >> >>No offense, but Livingston already has the upperhand in ComOS. And I >>don't have to buy a pricey maintenance contract to get free updates. > > >This is exactly why We will not be purchasing _any_ additional >USR TC equipment.... we will be getting rid of or TCs if >at all possible.... Livingston SW update (modems and all) is free >and takes all of about 5 min per chassis to upgrade. > > 3COM how about: > > Free Tech Support Now that things have improved (albeit no new music) I bet the support is worth what we paid. I forget exactly how much that was but we certainly have opened enough tickets.. If they got $50/ticket i'd be surprised.. that won't make them millions in itself.. not with their 800 bill from last year :) > Free SW upgrades including X2 and V.90 We opened a year ago exclusively with a TC hub w/contract and got free x2 from the start and never had to pay for a single upgrade to date. V.90 is free too I'm told.. > Lower Pricing ( your pricing would need to be %20 lower > than Livingstons for me to make the switch) Man, Source Technology is selling the new 48 port Hiper bundle for $10,458!! I can't imagine Linvingston being that much cheaper, especially if you compare it to the PM4 which ain't even here yet. On the heals of the PM4, this bundle has got to hurt Livingston. And it's here and now! > > My TC are working well now and have given us many new and > happy X2 customers. But if v.90 works well on the PM3 it > levels the playing field. Service, price, and performance are > what will be driving our purchases. > Me too. X2 was/is alot of who we are in our market and together we have made alot of happy x2 customers also.. flex lost in this area. Look what we have done for customers in the last year! This buys some loyality in our shop. And the modems are great too! Can't imagine 10-20% or so being a driving force over here in light of this... am

Old livigston 1.16..Modified to support USR attributes. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 3 Mar 1998, Pete Ashdown wrote: > Tatai SV Krishnan said once upon a time: > > >For what it is worth... Attached is radius server code, which supports > >USR vendor specific attributes. > > Thank you! > > WHat RADIUS implementation is this code based on? > > - > 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. >

On Tue, 3 Mar 1998, Pete Ashdown wrote: > Andrew Aken said once upon a time: > > >Whenever we set up the new hub to accept calls (we currently have > >another TC-hub with the Netserver which doesn't have this problem), it > >arbitrarily assigns IP addresses from other computers on my network to > >the MAC address on the eth:1 port on the HiPer ARC. Eventually, no > >computers on my network are reachable through TCP/IP. We're consistantly > >losing customers now because of the Quake lag problem this is supposed > >to fix and because we can't turn up any more telephone lines (our hub > >with the Netserver is maxed out). > > > >A fine bottle of Merlot to whomever can solve this problem for us. > > Send a description of your network addressing (interfaces, routers, ip > pools, etc), a dump of "list networks", and "list ip route" from the ARC, > *when the problem is occuring* and I'll take a look at it. > No Pete, this bottle of Merlot is mine ... :-) The customer is sending a netmask of 255.255.255.0 for his users, the netserver does not care, the hiper arc does... krish > - > 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. >

On Tue, 3 Mar 1998, Liping Chen wrote: > Krish, > > Do you also have a version for windowsNT? > > > Liping Chen I do not have a windowsNT version currently. We can sure try and compile the same under winNT, but does require some modification. I do not promise but will try to do that some time. krish > > Tatai SV Krishnan wrote: > > > For what it is worth... Attached is radius server code, which supports > > USR vendor specific attributes. > > > > krish > > > > ----------------------------------------- > > \ T.S.V. Krishnan \ > > \ Network System Engineer \ ( : - : ) > > \ 3Com ............ \ > > ----------------------------------------------/ > > tkrishna@bubba.ae.usr.com > > ----------------------------/ http://interproc.ae.usr.com ----/ > > -------------------------------------------------------------------------\ > > Any Sufficiently advanced bug is indistinguishable for a feature. > > - Rick Kulawiec > > -------------------------------------------------------------------------/ > > > > On Mon, 2 Mar 1998, I. Dwayne Koonce wrote: > > > > > Hi. I'm currently trying to find a RADIUS daemon that supports logging > > > USR's vendor-specific attributes, so we can expand the types of > > > information logged by our TC. I've had no luck so far with Livingston, > > > Ascend, or even Merit. While looking through the usr-tc mailing list > > > archive, I came across the following message: > > > > > > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > > To : > > > > Date: 28 Aug 1997 06:44:09 -0500 (CDT) > > > > Re: (usr-tc) Disconnect causes > > > > > > > >We do provide Radius server that supports our Vendor specific > > > >attributes. We also have given users modified livingston code that > > > >supports these attributes > > > > > > > >krish > > > > > > Is it possible to obtain this source code, or patches against Livingston > > > source, from US Robotics? > > > > > > Thanks in advance for any help > > > ____________________________________________________________________________ > > > I. Dwayne Koonce E-mail: dwayne@txcyber.com > > > ____________________________________________________________________________ > > > "It's dangerous to be right when the government is wrong." --Voltaire > > > > > > > ------------------------------------------------------------------------ > > > > Name: errs.1.2.1.tar.gz > > errs.1.2.1.tar.gz Type: GNU Zip Compressed Data (application/x-gzip) > > Encoding: BASE64 > > > > -- > Netsol Technologies > 805 S. Lemon Ave. Walnut, CA 91789 > (909) 869-6455 > (909) 869-6459 fax > Liping@netsol.net > > - > 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. >

On Mon, 2 Mar 1998, Allen Marsalis wrote: > But when you reseat the card you are also rebooting it too. That's a > different matter entirely.. It's rare we have to reboot a dual t1/pri > card to clear things up but it happens.. How long after reseating/rebooting > the card does the problem return? Are you seeing any crc's, slips, or > other errors on the spans? (as viewed from the console port) > > am > > >I have > >intermittent problems with lower than normal connect speeds. My customers > >using the Couriers love me. The one's using the TC hate me. I need a fix. > >Any suggestions other than re-seating the cards is appreciated. > >Sincerely, > >John Scrivner Don't forget about the cards in the back. We had a similar problem with a CT1 and replaced the NIC. The problem returned a few weeks later so we replaced the NAC (in the rear). Problem solved. ========================================================================= Jeffrey A. Lynch, President JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

I'm having problems connecting over ISDN to my ISP (P&T Luxembourg), who uses Total Control NETserver cards. 1. The problem does not occur at every time, but only one every 2nd or 3rd time (frequency varies over time: it was pretty bad in December, and somewhat better now, but it is not yet gone entirely). I speculate that the reason for this intermittent behavior is that I sometimes get connected to the new (buggy) equipment, and sometimes to older (well working) equipment. N.B. The old equipment is Total Control as well, but *probably* a different revision of the firmware. 2. When the problem happens, an ISDN (phone) connection is built up alright, but no PPP (Internet) connection can be established on top of it. The problem happens right at the start, before the LCP negotiation dialogue even starts. After some two seconds, I get a CRC error, or an invalid frame. After this CRC error, the Total Control NETserver card does not answer to any LCP configure request. As the problem happens right at the start, I do not think that it could be related to authentication or to the Radius server. 3. Even when the problem does NOT happen, there is a 3-4 second delay after the ISDN connection is established, and before LCP negotiation starts. This is odd, as other people using different ISPs with different equipment seem to get an "instant" (less than 1 second) start of LCP negotiation. Why do Total Control NETserver cards have this delay? Could this delay also be indicative of a problem? N.B. This delay stays the same even if I set the LCP retransmission time to 1 second, so it is not just the case that the first LCP configure request gets lost. N.B. The delay does not comprise the actual PPP negotiation, that'd be another 3 seconds coming on top of these. 4. Occasionnally, CRC errors happen when the connection is already established. In that case, the connection stays up, and all data transmission seems to be unaffected. N.B. The problems seems not to be due to line noise: last Wednsesday I had my line checked by a telephone repairman: all seemed ok. I also had the line monitored from the switch, and their equipment showed that all was ok at the line level even during connections which did get the CRC error. The problem seems not to be due neither to my ISDN card (a Teles 16.3) nor to my OS (Linux), as connections to the SuSE test server in Germany (0049 911 3206726) succeed without any problems (and also without that pesky 3-4 second startup delay!). A few weeks ago, I already posted about my problem on de.alt.comm.isdn4linux. Some people speculated that the problem may be due to the Total Control card falling back into x.75 mode if it doesn't get data from my side fast enough. Hence they suggested tinkering with the initial transmission delay on my end. However, neither the minimal value (0 milliseconds) nor the maximal one (1000 milliseconds) seemed to affect the outcome. However, with 0 milliseconds the problem seemed to have become slightly less frequent. If this theory is correct, is there any way to switch off this fallback to x.75 mode? AFAIK, my ISP only uses HDLC for its dialin lines, so disabling that x.75 fallback feature should do them no harm. Unfortunately, the telephone repairman's equipment was not designed to show whether HDLC or x.75 frames were transmitted, so we could not confirm or invalidate that theory... Other responses to my de.alt.comm.isdn4linux article were just other people experiencing similar problems than I have, but they did not have a solution either :-( And what is causing the 3-4 second startup delay? Could it be that the Total Control NETserver card is expecting something else than an LCP configure request at the start of the connection? If so, _what_ is it expecting? Thanks in advance for any help, Alain

-----Original Message----- >>Have the users upgraded to v.90? >don't know. would be useless to do so since no term servers >support it. I think it is important to find out from the users what revision of the code they have. (Have them do AT I7) Apparently, 3Com has 'posted' v.90 updates for some Sportster models (even though their web site doesn't confirm this). There are users claiming to have this code in ng messages. According to 3Com, users are encouraged to update to the v.90 firmware release even though no ISP server code has been released because the firmware includes updates to the x2 code to make it "more reliable". Aloha, Richard

On Wed, 4 Mar 1998, Bob Purdon wrote: > > > Don't forget about the cards in the back. We had a similar problem > > with a CT1 and replaced the NIC. The problem returned a few weeks later > > so we replaced the NAC (in the rear). Problem solved. > > Actually, to be pedantic, it's the other way around. The NIC is the rear > card, and the NAC the front. I think of it as the NIC being the > 'Interface card' and the NAC being the 'Application card'. I stand corrected. Thanks. ========================================================================= Jeffrey A. Lynch, President JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

At 11:15 AM 3/2/98 +0100, you wrote: >> Fri Feb 27 14:01:26 1998: generate26: Vendor 429 attribute 0 unknown >> Fri Feb 27 14:01:26 1998: gen_valpairs: non-encapsulated vendor specific >> attribute Vendor-Specific=vUSR-000000c700000001 >> Fri Feb 27 14:01:26 1998: generate26: Vendor 429 attribute 0 unknown >> Fri Feb 27 14:01:26 1998: gen_valpairs: non-encapsulated vendor specific >> attribute Vendor-Specific=vUSR-0000901900000000 >> >> ...which I see from the list archives that some others have as well. In >> fact, it looks like there's been quite a lot of discussion along these >> lines, but the threads appeared to mostly die out with no solution posted. >> >> So, my question is: Is anyone currently using these attributes >> successfully (with source-available software)? If so, then what? >Hello Florian, > >we have opened a new case for you under 6929, an engineer will >contact you as soon as possible. > >Best regards >Paul Brennan >Carrier Customer Services >-----------------schanipp------------------------------------------ > >As you can see i have a open ticket for this since 3 weeks. No engineer >contacted me, i got no solutions etc ... We have someone from USR/3Com >here today ... hope that he has got some solutions for me ... > I dont know about the above ticket.. That would be opened in a European office. I can tell you that we don't provide code or support for making our VSA's work in MERIT RADIUS.. You can see how we encode attribute 26 by reading the netserver manual or check out my RADIUS debuger at http://coredump.ae.usr.com/raddebug. It supports the USR/3Com VSA's and will compile on your LINUX platform.. `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer PGP: http://coredump.ae.usr.com/pgp (Prefered)

Thus spake Allen Marsalis >> Free Tech Support >Now that things have improved (albeit no new music) I bet the >support is worth what we paid. I forget exactly how much that >was but we certainly have opened enough tickets.. If they got >$50/ticket i'd be surprised.. that won't make them millions in >itself.. not with their 800 bill from last year :) I don't think so, for several reasons: 1) if their software was well done, they wouldn't have such high support costs. 2) if their tech support was up to snuff (yes, getting better, but still has a ways to go) they wouldn't have such high support costs. As witness for this, look at Cisco support. Though that's almost unfair as Cisco has some of the best tech support in the industry (IMHO), but it is an example of what can be done. >> Free SW upgrades including X2 and V.90 >We opened a year ago exclusively with a TC hub w/contract and got >free x2 from the start and never had to pay for a single upgrade to >date. V.90 is free too I'm told.. define "free." With a support contract, yes, its "free", but a support contract with USR ain't cheap! -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 09:55 PM 3/3/98 +1100, you wrote: > >> thanks, We have a boss who is very interested in traps and what we can >> do to work from them... > >Speaking of which, does anyone have any decent suggestions on how to trap >these things under Unix? I know snmptrapd does it, but it doesn't log >anything meaningful. > >Is there anything I can feed the USR MIB to and have it log traps one per >line in a flat ASCII file? > >I'm doing it with the Alarm Manager that comes with TCM at the moment, but >the Alarm Manager really sucks. > For UNIX and FREE there really isnt much.. The latest version of UCD SNMP can load 3Com/USR mibs and produce readable trap output from snmptrapd. -m

Thus spake Jeff Lynch >Don't forget about the cards in the back. We had a similar problem >with a CT1 and replaced the NIC. The problem returned a few weeks later >so we replaced the NAC (in the rear). Problem solved. You got those reversed.... NIC's are in the back (cards are about 5 inches long), and the NAC's are in the front (about 14 inches long). What are the dimensions on the cards anyway? I know the rack is 8 1/2" high (with the integrated fan tray). We don't do much co-lo at all, so dimensions haven't been a big deal for us. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I checked out www.3com.com/56k and it shows that the V.90 upgrade for some of their USR modems is available for download. The code for the Sportster I have won't be available till the 9th according to their Upgrade Advisor, though. Jason Brunette - Technical Support Support - support@tcbi.com TCB Internet - http://www.tcbi.com/ Personal - jbrunett@tcbi.com 920-451-7776 - Fax: 920-457-6616 Serving Sheboygan and Manitowoc, WI

Hi. ISDN connection to my PRI and netserver cards work without problems. But when I dial in to the PRI card with an analog modem none of the quad modems answers the call. Most times I get immediately a busy signal. I have enabled analog calls, activated s-port (s5-s12) on the netserver, DIP 5 on quad modems is off (should be answer on first ring). What am I doing wrong? any suggestions are welcome Martin oberle@ima.uni-stuttgart.de

At 09:05 PM 3/2/98 -1000, you wrote: >Are you using 3Com equipment at your end? yes. >Are you using the latest firmware? 5.6.7 on the quad cards >Have the users upgraded to v.90? don't know. would be useless to do so since no term servers support it. What is the policy of 3com for updaing our tc units with v.90 code? Since they said it was a free upgrade from x2 to v.90 what is the plan to roll this out? Are they going to try and muscle $ from us to upgrade? I would hope not. Eric > >If you have 3Com equipment and quad firmware before 5.6, v.90 modems will >not connect with x2. > >Certain Sportsters upgraded to pre v.90 firmware are known to get gibberish >(Buggy code reported by PCWeek 1/8/98) & referenced at my site: >http://pages.prodigy.net/bbhi/r-rnut-x2.htm - buggy code reference: >http://pages.prodigy.net/bbhi/r-rnut-x2-2.htm#bug) > >-Richard- > >-----Original Message----- >From: eric@dol.net <eric@dol.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Monday, March 02, 1998 6:38 PM >Subject: (usr-tc) x2 wizard corrupts customer modem > > >>We have had three customers in the past two days call because >>they upgraded their x2 modems with the wizard from the 3com site >>and it apaprently screwed up their x2 conenctions. When they >>call into our x2 modems they get screens full of gibberish when >>i had then open a terminal ascreen after dialing in win 95. >>They are able to connect to our flex modems but any attempt to make >>x2 conenctions results in failure. This is on multiple >>chassis in different locations. What is the customer to do to >>resolve the problem? Any insight as to why the problem is occuring? >>thanks >>Eric >>Delaware Online!.........The SMART Choice! With 56K X2 & Flex Modems >>Phone : 302-762-0375 Eric = mrdol >>Fax: 302-762-3462 Failure is NOT an option... >>www.dol.net >> >> >> >>- >> 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. > > >- > 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. > Delaware Online!.........The SMART Choice! With 56K X2 & Flex Modems Phone : 302-762-0375 Eric = mrdol Fax: 302-762-3462 Failure is NOT an option... www.dol.net

Krish, Do you also have a version for windowsNT? Liping Chen Tatai SV Krishnan wrote: > For what it is worth... Attached is radius server code, which supports > USR vendor specific attributes. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Mon, 2 Mar 1998, I. Dwayne Koonce wrote: > > > Hi. I'm currently trying to find a RADIUS daemon that supports logging > > USR's vendor-specific attributes, so we can expand the types of > > information logged by our TC. I've had no luck so far with Livingston, > > Ascend, or even Merit. While looking through the usr-tc mailing list > > archive, I came across the following message: > > > > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > To : > > > Date: 28 Aug 1997 06:44:09 -0500 (CDT) > > > Re: (usr-tc) Disconnect causes > > > > > >We do provide Radius server that supports our Vendor specific > > >attributes. We also have given users modified livingston code that > > >supports these attributes > > > > > >krish > > > > Is it possible to obtain this source code, or patches against Livingston > > source, from US Robotics? > > > > Thanks in advance for any help > > ____________________________________________________________________________ > > I. Dwayne Koonce E-mail: dwayne@txcyber.com > > ____________________________________________________________________________ > > "It's dangerous to be right when the government is wrong." --Voltaire > > > > ------------------------------------------------------------------------ > > Name: errs.1.2.1.tar.gz > errs.1.2.1.tar.gz Type: GNU Zip Compressed Data (application/x-gzip) > Encoding: BASE64 -- Netsol Technologies 805 S. Lemon Ave. Walnut, CA 91789 (909) 869-6455 (909) 869-6459 fax Liping@netsol.net

I had problems with NT RAS when some of the checkboxes in the RAS Settings (that one that the user of NT has to set up when he first make an entry to the phonebook) where check. I do not exactly remember which one it was: something like "IP-header compression" or "LPC-..." Uncheck them all. Martin oberle@ima.uni-stuttgart.de -----Urspr=FCngliche Nachricht----- Von: Harry Landers <harryl@cruzers.com> An: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> Datum: Dienstag, 3. M=E4rz 1998 10:06 Betreff: (usr-tc) TCS 3.0.2 and NT >We recently updated our 2059s to version TCS 3.0.2. We now are getting >complaints from many of our NT customers that they are having problems >either connecting or going anywhere after connecting. Has anyone else h= ad >this happen and how did you fix it. I looked through the archives but found >nothing relevant. > >TIA > >Harry Landers >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Harry Landers, President >Panda Communications LLC 185 Walnut Avenue Santa Cruz CA 95060 >Home of CRUZERS 408-457-CRUZ (2789) fax 408-457-056k > > >- > 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.

Has anyone here had any luck with using the Inventory feature in TCM for Windows? Every time we've tried to use it, TCM will crash with a kernel32.dll error. Comments? -- Tom Claydon, Internetworking System Engineer Troika Technologies, Inc. Phone: (907) 274-3348 Pager: (907) 268-0406

Tatai SV Krishnan said once upon a time: >For what it is worth... Attached is radius server code, which supports >USR vendor specific attributes. Thank you! WHat RADIUS implementation is this code based on?

Brent Jay said once upon a time: >> Thank you for your recent mail concerning unsolicited commercial email >> from 1stlook@whereever.com. If you take a closer look at the email >> headers you will notice that this mail did NOT originate from sundial.net. >> We do not permit unsolicited email by our users, and we never have. > >What is this? We are getting tons of copies of this and it is really >annoying. > >Can you please turn it off? We turned it off, but not until the moron had sent dozens of copies to the list.

At 11:25 AM 3/3/98 -0500, you wrote: >Mike was heard to say: >>----------------------------------------- >>>Hello Florian, >>> >>>we have opened a new case for you under 6929, an engineer will >>>contact you as soon as possible. >>> >>>Best regards >>>Paul Brennan >>>Carrier Customer Services >>>-----------------schanipp------------------------------------------ >>> >>>As you can see i have a open ticket for this since 3 weeks. No engineer >>>contacted me, i got no solutions etc ... We have someone from USR/3Com >>>here today ... hope that he has got some solutions for me ... >>> >> >> >>I dont know about the above ticket.. That would be opened in a European >>office. I can tell you that >>we don't provide code or support for making our VSA's work in MERIT >>RADIUS.. You can see how we >>encode attribute 26 by reading the netserver manual or check out my RADIUS >>debuger at >>http://coredump.ae.usr.com/raddebug. It supports the USR/3Com VSA's and >>will compile on your >>LINUX platform.. >> >>`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' >>Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics >>Network Systems Engineer >>PGP: http://coredump.ae.usr.com/pgp (Prefered) > >Gee, there's customer commitment... > >The patch(s) you need for Merit RADIUS 3.5.6 can be found at: ><URL:http://lacota.interpath.net/~jfbeam/RADIUS/merit-usr.diff> > Commitment? How many vendors do you know of that fix other vendors issues? MERIT didn't support the USR attribute.. This is somehow 3Com's problem? We educate in the format of the VSA and provide our own product that works with them.. How much more should we do? -m

Mike was heard to say: >----------------------------------------- >>Hello Florian, >> >>we have opened a new case for you under 6929, an engineer will >>contact you as soon as possible. >> >>Best regards >>Paul Brennan >>Carrier Customer Services >>-----------------schanipp------------------------------------------ >> >>As you can see i have a open ticket for this since 3 weeks. No engineer >>contacted me, i got no solutions etc ... We have someone from USR/3Com >>here today ... hope that he has got some solutions for me ... >> > > >I dont know about the above ticket.. That would be opened in a European >office. I can tell you that >we don't provide code or support for making our VSA's work in MERIT >RADIUS.. You can see how we >encode attribute 26 by reading the netserver manual or check out my RADIUS >debuger at >http://coredump.ae.usr.com/raddebug. It supports the USR/3Com VSA's and >will compile on your >LINUX platform.. > >`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' >Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics >Network Systems Engineer >PGP: http://coredump.ae.usr.com/pgp (Prefered) Gee, there's customer commitment... The patch(s) you need for Merit RADIUS 3.5.6 can be found at: <URL:http://lacota.interpath.net/~jfbeam/RADIUS/merit-usr.diff> --Ricky

Andrew Aken said once upon a time: >Whenever we set up the new hub to accept calls (we currently have >another TC-hub with the Netserver which doesn't have this problem), it >arbitrarily assigns IP addresses from other computers on my network to >the MAC address on the eth:1 port on the HiPer ARC. Eventually, no >computers on my network are reachable through TCP/IP. We're consistantly >losing customers now because of the Quake lag problem this is supposed >to fix and because we can't turn up any more telephone lines (our hub >with the Netserver is maxed out). > >A fine bottle of Merlot to whomever can solve this problem for us. Send a description of your network addressing (interfaces, routers, ip pools, etc), a dump of "list networks", and "list ip route" from the ARC, *when the problem is occuring* and I'll take a look at it.

Alain Knaff said once upon a time: >fallback to x.75 mode? AFAIK, my ISP only uses HDLC for its dialin >lines, so disabling that x.75 fallback feature should do them no harm. >Unfortunately, the telephone repairman's equipment was not designed to >show whether HDLC or x.75 frames were transmitted, so we could not >confirm or invalidate that theory... In the "ISDN Modem" configuration of the modem cards, there is a section for enabling and disabling x.75. I would really like to know whether v.110 and x.75 are necessary for robust ISDN communications. If I disable them, will I lose the ability to connect to some adapters?

Please respond to usr-tc@lists.xmission.com cc: (bcc: Jason Kelton/AU/3Com) Hi, How many ISDN calls can I have in a filled TCH chassis using Dual PRI cards and NetServer modules? I am assuming you can have 5 Netservers, each using 2 Dual PRIs for a total of 460 calls. Is this the max you can have in one Chassis? In this case there would be no async calls... NO. In an ISDN configuration, you're restricted to a MAX of 240 ISDN calls, as the TDM only has 256x64K timeslots. You are only allowed a MAX of 4 Dual PRI's per Chassis. Then, assume using ARC. Can I use 2 ARCs with 7 Dual PRIs each for a total of 644 ISDN only calls? How about with the EdgeServer PRO? Will this configuration work in a single chassis? 2 EdgeServer PROs, 10 Dual PRIs. So that each EdgeServer PRO handles 5 Dual PRIs for a total of 230 ports for each EdgeServer PRO and a max of 460 ports in the chassis. Some folks saw the chassis at ComNet that had EdgeServer PRO on display for Voice applications. Will HiPer ARC support Voice or will this only work with the EdgeServer PROs? Thanks in advance. ++++++++++++++++++++++++ mailto:turners@best.com ++++++++++++++++++++++++ - 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.

Sorry... accidentally hit the send button.... please see this response for the complete package!!! Please respond to usr-tc@lists.xmission.com cc: (bcc: Jason Kelton/AU/3Com) How many ISDN calls can I have in a filled TCH chassis using Dual PRI cards and NetServer modules? I am assuming you can have 5 Netservers, each using 2 Dual PRIs for a total of 460 calls. Is this the max you can have in one Chassis? In this case there would be no async calls... NO. In an ISDN configuration, you're restricted to a MAX of 240 ISDN calls, as the TDM only has 256x64K timeslots. You are only allowed a MAX of 4 Dual PRI's per Chassis. Then, assume using ARC. Can I use 2 ARCs with 7 Dual PRIs each for a total of 644 ISDN only calls? NO. You would still be limited to 240 ISDN calls. You could add 10 HiPER DSP cards, taking the chassis to a MAX. of 540, but I don't know if this configuration would work, as I'm not sure if you can terminate the calls directly from a Dual PRI onto the HiPER. How about with the EdgeServer PRO? Will this configuration work in a single chassis? 2 EdgeServer PROs, 10 Dual PRIs. So that each EdgeServer PRO handles 5 Dual PRIs for a total of 230 ports for each EdgeServer PRO and a max of 460 ports in the chassis. No and for the same reasons..... Some folks saw the chassis at ComNet that had EdgeServer PRO on display for Voice applications. Will HiPer ARC support Voice or will this only work with the EdgeServer PROs? As I currently understand it, the Edgeserver PRO is the only product available to support Voice over IP. I would assume something available eventually for HiPER ARC, but would still require Servers of some denomination, hence, making it practically unfesable.

On Mon, 2 Mar 1998 eric@dol.net wrote: > We have had three customers in the past two days call because > they upgraded their x2 modems with the wizard from the 3com site > and it apaprently screwed up their x2 conenctions. When they > call into our x2 modems they get screens full of gibberish when Where they getting x2 connections in the past? > i had then open a terminal ascreen after dialing in win 95. > They are able to connect to our flex modems but any attempt to make > x2 conenctions results in failure. This is on multiple > chassis in different locations. What is the customer to do to > resolve the problem? Any insight as to why the problem is occuring? If they are not getting x2 connections, and the modem trys to fall back to V.34, they will get garbage. There is a bug in the 10/6/97 code that cause this problem. The customer needs to contact 3Com and get the downgrade wizard to go back to older code. Brian

I don't think it's x2. I tried my "tests" with a v.34 modem and the results were still the same. Jason Brunette - Technical Support Support - support@tcbi.com TCB Internet - http://www.tcbi.com/ Personal - jbrunett@tcbi.com 920-451-7776 - Fax: 920-457-6616 Serving Sheboygan and Manitowoc, WI -----Original Message----- >Had one of my coworkers read and respond to the stuff on the Quake >lag message from a few days ago: > >> ------- Forwarded Message Follows ------- >> From: "Jason Brunette" <root@tcbi.com> >> Subject: (usr-tc) QuakeWorld Lag info... >> Having read through the usr-tc archive, I've noticed that many other >> people are having trouble with their TCs and Quake performance. I >> did quite a few tests with QuakeWorld, and have come to this >> conclusion: > >Been there done that. Most people have it at the 2500 rate as all the >"Quake Experts" point out that this is the max for the modems. What >he does not mention is that if you also lower this you get lag as you >start having delays. My roommate is set at 2500 as well as my clans >men. However, if you use ISDN the recommended setting is 5000. If >you use a T1 the recommended is 25000. The problem is that even with >the rate set to 2500 that people such as my roommate logins in to a >quake server and his ping will be fine initially. Then sporadically >he gets 999 all of sudden. Then back down to 250 then up and then >down. In this guy's tests he had consistent reproducible results. The >problem in the case with my roommate is that the problem is not >necessarily reproducible nor consistent. One moment things are going >great and hten the next blamo 999. The tweaks I did worked intially, >but then the problem occured again. From what I understand the >problem lies with X2 part in the Netserver code. > >Hopefully the new code will fix the problem. I am setting my roommate >up with Q2 tonight and it will be interesting to see how the lag is >with Q2 as the multiplayer network code is supposedly better than >QW. > >WingNET System Administrator >423-559-LINK (v) >423-559-5444 (f) > >- > 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. >

Had one of my coworkers read and respond to the stuff on the Quake lag message from a few days ago: > ------- Forwarded Message Follows ------- > From: "Jason Brunette" <root@tcbi.com> > Subject: (usr-tc) QuakeWorld Lag info... > Having read through the usr-tc archive, I've noticed that many other > people are having trouble with their TCs and Quake performance. I > did quite a few tests with QuakeWorld, and have come to this > conclusion: Been there done that. Most people have it at the 2500 rate as all the "Quake Experts" point out that this is the max for the modems. What he does not mention is that if you also lower this you get lag as you start having delays. My roommate is set at 2500 as well as my clans men. However, if you use ISDN the recommended setting is 5000. If you use a T1 the recommended is 25000. The problem is that even with the rate set to 2500 that people such as my roommate logins in to a quake server and his ping will be fine initially. Then sporadically he gets 999 all of sudden. Then back down to 250 then up and then down. In this guy's tests he had consistent reproducible results. The problem in the case with my roommate is that the problem is not necessarily reproducible nor consistent. One moment things are going great and hten the next blamo 999. The tweaks I did worked intially, but then the problem occured again. From what I understand the problem lies with X2 part in the Netserver code. Hopefully the new code will fix the problem. I am setting my roommate up with Q2 tonight and it will be interesting to see how the lag is with Q2 as the multiplayer network code is supposedly better than QW. WingNET System Administrator 423-559-LINK (v) 423-559-5444 (f)

At 10:49 AM 3/3/98 -0900, you wrote: >Has anyone here had any luck with using the Inventory feature in TCM for >Windows? >Every time we've tried to use it, TCM will crash with a kernel32.dll error. > >Comments? > make sure you are using all of the latest patches for NT(service pack 3) and for 95 service pack 1 or Rev B. -m

Allen Marsalis said once upon a time: >And some of the best hardware too. I see your point. We purchased >a cisco contract for our switch and haven't had to use it once. So >their cost of support is nil (for us anyway..) this could be highly >profitable.. Ho ho ho. I taxed my Cisco support to the limit last year. Thanks to a two dead power supplies, a dead ATM card, a FDDI card upgrade, and an absolutely disasterous RSP7000 upgrade.

Folks, I have recently purchased upgrades from 3com with the part code 80-2149-00 called "NMC / Netserver DRAM/FlashROM upgrade for 386 and 486 only". Question. How important is it to upgrade the 4 meg flash ROM to 8 meg on the Netserver? Will there be a need in the future for the 8 meg flash? thanks. ______________________________________________________________________ | Henry Moats Network Services Support nc0419 ext 3671 | ______________________________________________________________________|

At 09:09 AM 3/3/98 -0500, Jeff Mcadams wrote: >Thus spake Allen Marsalis >>> Free Tech Support > >>Now that things have improved (albeit no new music) I bet the >>support is worth what we paid. I forget exactly how much that >>was but we certainly have opened enough tickets.. If they got >>$50/ticket i'd be surprised.. that won't make them millions in >>itself.. not with their 800 bill from last year :) > >I don't think so, for several reasons: > >1) if their software was well done, they wouldn't have such high >support costs. >2) if their tech support was up to snuff (yes, getting better, but >still has a ways to go) they wouldn't have such high support costs. > >As witness for this, look at Cisco support. Though that's almost unfair >as Cisco has some of the best tech support in the industry (IMHO), but >it is an example of what can be done. And some of the best hardware too. I see your point. We purchased a cisco contract for our switch and haven't had to use it once. So their cost of support is nil (for us anyway..) this could be highly profitable.. >>> Free SW upgrades including X2 and V.90 > >>We opened a year ago exclusively with a TC hub w/contract and got >>free x2 from the start and never had to pay for a single upgrade to >>date. V.90 is free too I'm told.. > >define "free." With a support contract, yes, its "free", but a support >contract with USR ain't cheap! >-- Well we have purchased 6 or more hubs over the past year and only paid for a contract on 1. However with a 90 day warranty, we always have something under regular warranty. And x2 (and v.90) were free for all of them. We have probably spent around 2% of USR purchases on support.. Not bad.. But without this list, that would not have been possible.. am _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

Thus spake Pete Ashdown >Allen Marsalis said once upon a time: >>And some of the best hardware too. I see your point. We purchased >>a cisco contract for our switch and haven't had to use it once. So >>their cost of support is nil (for us anyway..) this could be highly >>profitable.. >Ho ho ho. I taxed my Cisco support to the limit last year. Thanks to a >two dead power supplies, a dead ATM card, a FDDI card upgrade, and an >absolutely disasterous RSP7000 upgrade. Yes, but that's extremely uncommon for cisco equipment (unless you're running bleeding edge stuff with them), and I bet their response in all those cases was quite satisfactory...or even spectacular. We had a 4000-M router motherboard blow up, they had us a replacement in 10 hours...coming from the west coast to Louisville, KY. I was impressed. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I have a user that has an internal Sportster 56K using win95. When he dials in via DUN with us, he constantly gets "Cannot Negotiate a compatible set of Network Protocols" error. I have pinpointed this down to the fact that he's not even getting a login prompt when the handshaking is done. The equipment on my end is a USR TC using CT1. I have tried various init strings and still cannot get it to work. The thing that is really boggling my mind is that he also has an account with AOL. Using AOL's dialer he can connect up without any problems (to AOL). I tried pulling the init string out of the AOL dialer and using with DUN but that did not work either. Any clues? -Eric

Get rid of the AOL adapter. -----Original Message----- I have a user that has an internal Sportster 56K using win95. When he dials in via DUN with us, he constantly gets "Cannot Negotiate a compatible set of Network Protocols" error. I have pinpointed this down to the fact that he's not even getting a login prompt when the handshaking is done. The equipment on my end is a USR TC using CT1. I have tried various init strings and still cannot get it to work. The thing that is really boggling my mind is that he also has an account with AOL. Using AOL's dialer he can connect up without any problems (to AOL). I tried pulling the init string out of the AOL dialer and using with DUN but that did not work either. Any clues? -Eric - 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.

Krish was right. Setting the netmask in our RADIUS users file to 255.255.255.255 fixed the problem. Apparently with the netmask set to 255.255.255.0 in the users file the HiPer ARC was giving each dial-in user the entire class C. Of course, why it took this long to figure out is anyone's guess, but Krish spotted it right away. BTW, Krish declined having me send him the bottle of Merlot. So if anyone's in the Murphysboro, IL area tonight we will be toasting Krish when we bring the new hub fully on-line. Tatai SV Krishnan wrote: > > On Tue, 3 Mar 1998, Pete Ashdown wrote: > > > Andrew Aken said once upon a time: > > > > >Whenever we set up the new hub to accept calls (we currently have > > >another TC-hub with the Netserver which doesn't have this problem), it > > >arbitrarily assigns IP addresses from other computers on my network to > > >the MAC address on the eth:1 port on the HiPer ARC. Eventually, no > > >computers on my network are reachable through TCP/IP. We're consistantly > > >losing customers now because of the Quake lag problem this is supposed > > >to fix and because we can't turn up any more telephone lines (our hub > > >with the Netserver is maxed out). > > > > > >A fine bottle of Merlot to whomever can solve this problem for us. > > > No Pete, this bottle of Merlot is mine ... :-) The customer is sending a > netmask of 255.255.255.0 for his users, the netserver does not care, the > hiper arc does... > > krish > ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

On Tue, 3 Mar 1998, Allen Marsalis wrote: > And some of the best hardware too. I see your point. We purchased > a cisco contract for our switch and haven't had to use it once. So > their cost of support is nil (for us anyway..) this could be highly > profitable.. I had to use Cisco SmartNet maintenance *once* on a 4000. It was shortly after midnight when I called up. Apparently they have a FedEx distribution point co-located at their main warehouses, because they had, inside of 10 minutes, shipped me a brand new 4000 (FULLY loaded, I might add) which arrived promptly the next morning. Blew me away, I'd never experienced that level of customer support before. :) Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

At 05:36 PM 3/3/98 -0800, you wrote: >Get rid of the AOL adapter. > Nope. He'll need that. Make sure that there is a TCP/IP bound to the dial-up adapter. He should have: AOL Adapter DialUp Adapter TCP/IP -> AOL Adapter TCP/IP -> DialUp Adapter The last is probably what's missing. Just do an Add-Protocol to get it in there. Bruce info@sltic.com >-----Original Message----- >From: Eric Forcey <eric@psnw.com> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Tuesday, March 03, 1998 5:30 PM >Subject: (usr-tc) My mind is boggled > > > >I have a user that has an internal Sportster 56K using win95. > >When he dials in via DUN with us, he constantly gets "Cannot Negotiate a >compatible set of Network Protocols" error. I have pinpointed this down to >the fact that he's not even getting a login prompt when the handshaking is >done. The equipment on my end is a USR TC using CT1. > >I have tried various init strings and still cannot get it to work. > >The thing that is really boggling my mind is that he also has an account >with AOL. Using AOL's dialer he can connect up without any problems (to >AOL). > >I tried pulling the init string out of the AOL dialer and using with DUN >but that did not work either. > >Any clues? > >-Eric >

Eric Forcey <eric@psnw.com> writes: > When he dials in via DUN with us, he constantly gets "Cannot Negotiate a > compatible set of Network Protocols" error. I have pinpointed this down to > the fact that he's not even getting a login prompt when the handshaking is > done. The equipment on my end is a USR TC using CT1. Well, unless he sets the dialer to open up a terminal window after dialing, he's not going to get a login prompt, since Win95 will use PPP authentication with PAP or CHAP (or that MS-CHAP gunk). One thing he might try is editing his dialer location, so that on the Server Types tab he de-selects all but the TCP/IP option (e.g., don't select NetBEUI or IPX) since sometimes there might be a negotiation problem for those protocols. The other option is to set the dialer (on the scripting tab) to open a terminal window after connect. When he dials in, he'll get a window and should see your login prompt and can try logging in manually. After PPP starts, he hits a function key (f7 I think) and Win95 proceeds normally. If this works, but Win95 alone doesn't, then I think, but am not positive, it's because Win95 is trying to negotiate MS-CHAP for authentication but you've got a NETServer release that doesn't understand it. > The thing that is really boggling my mind is that he also has an account > with AOL. Using AOL's dialer he can connect up without any problems (to > AOL). Well, that's a completely different beast. AOL controls the modem directly, and doesn't use PPP, so you're basically talking about a straight async call at that point with a scripted login. Apples to oranges comparison. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

At 06:39 PM 3/2/98 -0600, Brent Jay wrote: >On Mon, 2 Mar 1998, Mark van Wouw wrote: > >> all showing the same result. When a connection is made through a >> shell (as opposed to PPP) I get the "*** Host Is Currently >> navailable ***" message. > >We've had that happen using Livingston RADIUS 1.16 when we forgot to set >security on all ports. If you upgraded from 3.5.34 to 3.7.24 you might >have forgotten to set security on the extra ports after 52. That was exactly it, thanks! Mark. --- Global OnLine Japan - The Provider Mark van Wouw Network Operations vanwouw@gol.com 03-5341-8000 ZZ - I'm not sleepy, I just forget to escape sometimes...

> thanks, We have a boss who is very interested in traps and what we can > do to work from them... Speaking of which, does anyone have any decent suggestions on how to trap these things under Unix? I know snmptrapd does it, but it doesn't log anything meaningful. Is there anything I can feed the USR MIB to and have it log traps one per line in a flat ASCII file? I'm doing it with the Alarm Manager that comes with TCM at the moment, but the Alarm Manager really sucks. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Has anyone gotten the mrtg scripts to work with the netserver 8/16i? Would like to see your config file if possible. Thanks, Ken :) - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated connectivity. 33.6, 56k, ISDN Dialup coming soon to Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

> >No offense, but Livingston already has the upperhand in ComOS. And I >don't have to buy a pricey maintenance contract to get free updates. This is exactly why We will not be purchasing _any_ additional USR TC equipment.... we will be getting rid of or TCs if at all possible.... Livingston SW update (modems and all) is free and takes all of about 5 min per chassis to upgrade. 3COM how about: Free Tech Support Free SW upgrades including X2 and V.90 Lower Pricing ( your pricing would need to be %20 lower than Livingstons for me to make the switch) My TC are working well now and have given us many new and happy X2 customers. But if v.90 works well on the PM3 it levels the playing field. Service, price, and performance are what will be driving our purchases. -Dan

> Don't forget about the cards in the back. We had a similar problem > with a CT1 and replaced the NIC. The problem returned a few weeks later > so we replaced the NAC (in the rear). Problem solved. Actually, to be pedantic, it's the other way around. The NIC is the rear card, and the NAC the front. I think of it as the NIC being the 'Interface card' and the NAC being the 'Application card'. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Hi: I have problems getting decent speeds out of v.34 modems. Nearly all of the connections to my rack are at 26,400 or less and some customers never can achieve 19,200. While "digital" modems may be a step forward in technology, from a customer service standpoint they are a leap backwards. I now have four modules with 48 modems each, and am using channelized T-1's. Speeds are ridiculously slow, and there is no apparent solution. The future isn't looking bright. We were better of with our analog modem pool. Steve Buza steve@nemaine.com System Administrator North Coast Internet

: I have problems getting decent speeds out : of v.34 modems. Nearly all of the connections : to my rack are at 26,400 or less and some : customers never can achieve 19,200. The intial connection to a modem is a hairsbreadth from meaningless (which is better, a 56k connection that dies after 3 seconds, or a 26.4k connection that lasts a week?). Are you monitoring the transmit link rates?

Can someone post/email me a good mib.txt for the TC's? What would be great is the instructions for creating a mib.txt, basically, If I remmber right, you just concatenate all the files together, and put something at the top like: RFC1155-SMI DEFINITIONS ::= BEGIN nullOID OBJECT IDENTIFIER ::= { ccitt 0 } internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } END RFC1213-MIB DEFINITIONS ::= BEGIN DisplayString ::= OCTET STRING END except thats not it, I think I am missing a semicolon or something somewhere. Thanks (using it with cmu and ucd snmp) /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Tue, 3 Mar 1998, Andrew Aken wrote: > Krish was right. Setting the netmask in our RADIUS users file to > 255.255.255.255 fixed the problem. Apparently with the netmask set to > 255.255.255.0 in the users file the HiPer ARC was giving each dial-in > user the entire class C. Of course, why it took this long to figure out > is anyone's guess, but Krish spotted it right away. For what it's worth, I saw this with Netservers too. All of my static IP customers had 255.255.255.0 netmasks, and they could connect, but got no routing. It didn't screw up the network thankfully. Changing the netmasks to 255.255.255.255 fixed it right up. My Portmasters were ignoring the netmask setting. Brian

On Wed, 4 Mar 1998, Stephen W. Buza wrote: > Hi: > > I have problems getting decent speeds out > of v.34 modems. Nearly all of the connections > to my rack are at 26,400 or less and some > customers never can achieve 19,200. > > While "digital" modems may be a step forward > in technology, from a customer service standpoint > they are a leap backwards. > > I now have four modules with 48 modems each, > and am using channelized T-1's. Speeds are > ridiculously slow, and there is no apparent > solution. > > The future isn't looking bright. We were better > of with our analog modem pool. > > Steve Buza It sounds like you have line-side channelized T1s without B8ZS connecting the telco side of d4 channel bank line interface cards to analog centrex telephone office equipment. Get a clueful telco person to discuss this with. You have got to get trunk-side T1's that connect directly into the telco switch without A/D conversion. This scenario will definately cause the symptoms you describe. But make sure you monitor the modem transmit/receive link speeds with TCM to make sure you have valid data to word with. Any good X2 connection 40K+ on a T1 span will invalidate this and you might just have some loud users complaining. ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

At 10:35 AM 3/4/98 -0600, you wrote: >Can someone post/email me a good mib.txt for the TC's? > >What would be great is the instructions for creating a mib.txt, basically, >If I remmber right, you just concatenate all the files together, and put >something at the top like: > RFC1155-SMI DEFINITIONS ::= BEGIN > nullOID OBJECT IDENTIFIER ::= { ccitt 0 } > internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 } > directory OBJECT IDENTIFIER ::= { internet 1 } > mgmt OBJECT IDENTIFIER ::= { internet 2 } > experimental OBJECT IDENTIFIER ::= { internet 3 } > private OBJECT IDENTIFIER ::= { internet 4 } > enterprises OBJECT IDENTIFIER ::= { private 1 } > END > > RFC1213-MIB DEFINITIONS ::= BEGIN > DisplayString ::= OCTET STRING > END > > >except thats not it, I think I am missing a semicolon or something >somewhere. Thanks (using it with cmu and ucd snmp) If you use UCD snmp you dont have to cat the files together.. Just copy the USR mibs to your SNMP mib directory and set the environment variables to point there.. It will load all of the mibs.. -m

On Tue, 3 Mar 1998, David Bolen wrote: > > The thing that is really boggling my mind is that he also has an account > > with AOL. Using AOL's dialer he can connect up without any problems (to > > AOL). > > Well, that's a completely different beast. AOL controls the modem > directly, and doesn't use PPP, so you're basically talking about a > straight async call at that point with a scripted login. Apples to > oranges comparison. The latest AOL software installs something called the AOL adaptor in the network settings in Windows 95. There is also TCP/IP pointed at this. What exactly is this? Is AOL using TCP/IP now? Brian

At 10:53 AM 3/4/98 -0600, you wrote: > >The latest AOL software installs something called the AOL adaptor in the >network settings in Windows 95. There is also TCP/IP pointed at this. > >What exactly is this? Is AOL using TCP/IP now? > >Brian > The TCP/IP -> AOL Adapter is there so AOL lusers can use the "Bring your own access" plan and connect through a "real" ISP to get to AOL. Direct dial to AOL doesn't use TCP/IP. Bruce info@sltic.com

Disagree, he won't need the AOL adapter or TCP/IP-->AOL Adapter All his problems will be solved once AOL adapter is gone from the Network Configuration control panel. I've encountered this situation many times and removal of AOL adapter has solved the problem everytime. If the customer insists on using AOL also, then recommend him to use AOL's "Third Party Provider" plan in which AOL Adapter is not needed. Plus, it will cost them less. (Unless they raised the rate) However, if he is using Win 3.1 with IE 3.x, he will need to use a different dialer than Microsofts Dialer because the winsocks are different and AOL is picky on the Win 3.x system. -----Original Message----- At 05:36 PM 3/3/98 -0800, you wrote: >Get rid of the AOL adapter. > Nope. He'll need that. Make sure that there is a TCP/IP bound to the dial-up adapter. He should have: AOL Adapter DialUp Adapter TCP/IP -> AOL Adapter TCP/IP -> DialUp Adapter The last is probably what's missing. Just do an Add-Protocol to get it in there. Bruce info@sltic.com >-----Original Message----- >From: Eric Forcey <eric@psnw.com> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Tuesday, March 03, 1998 5:30 PM >Subject: (usr-tc) My mind is boggled > > > >I have a user that has an internal Sportster 56K using win95. > >When he dials in via DUN with us, he constantly gets "Cannot Negotiate a >compatible set of Network Protocols" error. I have pinpointed this down to >the fact that he's not even getting a login prompt when the handshaking is >done. The equipment on my end is a USR TC using CT1. > >I have tried various init strings and still cannot get it to work. > >The thing that is really boggling my mind is that he also has an account >with AOL. Using AOL's dialer he can connect up without any problems (to >AOL). > >I tried pulling the init string out of the AOL dialer and using with DUN >but that did not work either. > >Any clues? > >-Eric > - 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.

On Wed, 4 Mar 1998, Stephen W. Buza wrote: > I have problems getting decent speeds out > of v.34 modems. Nearly all of the connections > to my rack are at 26,400 or less and some > customers never can achieve 19,200. Are these trunk-side CT1s? This almost sounds like you have line-side T1s. When we switched 100s of customers to our Total Control racks from MP/16s, we got like 5 complaints about people getting connect speeds one notch lower than they had been. Our solution was to have the customer call our Livingston PM3. For some customers at V.34, it connects a notch or two higher than the Total Control gear. The Total Control stuff is much better than the PM3 at 56k speeds. Brian

Actually, the problem turned out to be the modem. I put a call into USR support this morning (modem side support not TC). I was informed that any of the new modems that shipped (with v.90) are not working. They recommend using s35=4 in the init string. They instructed us that if it didn't work that he would need to call USR support. Apparently he did call support (I am finding this out after the fact) and they are going to be getting him a patch to his code on the modem. AOL Adapter is still installed.. and it is now working (however he can't get x2 speeds until he applies the patch). On Wed, 4 Mar 1998, Jose de Leon wrote: > Disagree, he won't need the AOL adapter or TCP/IP-->AOL Adapter > > All his problems will be solved once AOL adapter is gone from the Network > Configuration control panel. > > I've encountered this situation many times and removal of AOL adapter has > solved the problem everytime. If the customer insists on using AOL also, > then recommend him to use AOL's "Third Party Provider" plan in which AOL > Adapter is not needed. Plus, it will cost them less. (Unless they raised > the rate) > > However, if he is using Win 3.1 with IE 3.x, he will need to use a different > dialer than Microsofts Dialer because the winsocks are different and AOL is > picky on the Win 3.x system. > > -----Original Message----- > From: info@sltic.com <info@sltic.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Tuesday, March 03, 1998 5:54 PM > Subject: Re: (usr-tc) My mind is boggled > > > At 05:36 PM 3/3/98 -0800, you wrote: > >Get rid of the AOL adapter. > > > > Nope. He'll need that. Make sure that there is a TCP/IP bound to the > dial-up adapter. He should have: > > AOL Adapter > DialUp Adapter > TCP/IP -> AOL Adapter > TCP/IP -> DialUp Adapter > > The last is probably what's missing. Just do an Add-Protocol to get > it in there. > > Bruce > info@sltic.com > > >-----Original Message----- > >From: Eric Forcey <eric@psnw.com> > >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > >Date: Tuesday, March 03, 1998 5:30 PM > >Subject: (usr-tc) My mind is boggled > > > > > > > >I have a user that has an internal Sportster 56K using win95. > > > >When he dials in via DUN with us, he constantly gets "Cannot Negotiate a > >compatible set of Network Protocols" error. I have pinpointed this down to > >the fact that he's not even getting a login prompt when the handshaking is > >done. The equipment on my end is a USR TC using CT1. > > > >I have tried various init strings and still cannot get it to work. > > > >The thing that is really boggling my mind is that he also has an account > >with AOL. Using AOL's dialer he can connect up without any problems (to > >AOL). > > > >I tried pulling the init string out of the AOL dialer and using with DUN > >but that did not work either. > > > >Any clues? > > > >-Eric > > > > > - > 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. > > > > - > 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. >

I have a total control hub that currently has one pri on it for inbound calls for my dialup customers. I would like to order a second pri and place in on the second pri slot and after it is working cancell the first one...... So I would like to know if I cancell the first one can the second pri run independently or does there have to be one working on the first pri port? Also, the pri I currently have is connected to a 5ESS switch and the new one will be Nortel DMS 500...Will this be a problem ? Thanks in advance... Richard SurfNet Corporation

On Mon, 2 Mar 1998, Tatai SV Krishnan wrote: > For what it is worth... Attached is radius server code, which supports > USR vendor specific attributes. > > > krish Thanks! This logs the VSA's just fine. One question though--is there any way to cause it to require clients to be listed in the clients file? I tried testing it with just one of our TC's, but it took accounting requests from all of our NASes, even though only the test machine was listed in the clients file. ____________________________________________________________________________ I. Dwayne Koonce E-mail: dwayne@txcyber.com ____________________________________________________________________________ "It's dangerous to be right when the government is wrong." --Voltaire

Hint: Word wrap at somewhere around 72 columns is generally considered a "Good Thing(tm)" on the 'net. :) Thus spake Richard Mazurowski >I have a total control hub that currently has one pri on it for inbound calls for my dialup customers. I would like to order a second pri and place in on the second pri slot and after it >is working cancell the first one...... So I would like to know if I cancell the first one can the second pri run independently or does there have to be one working on the first pri port? It will continue to work just fine. >Also, the pri I currently have is connected to a 5ESS switch and the new one will be Nortel DMS 500...Will this be a problem ? Thanks in advance... Uhm...my understanding is that this *should* work ok...might find weird issues with timing if they're on different switches, but my understanding is that it should be alright. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Wed, 4 Mar 1998, Jeff Mcadams wrote: > OK, this one is weird... > > TCS 3.0.2, lines on PRI's off a 5ESS, Quad modems with netservers (no > hyper stuff at all here) ISDN terminated on quads. > > I've got two or three customers that are dialing in and after a few > seconds (anywhere from 2-3 up to 6) during which they're sending LCP > conf req's to our equipment. After that slight pause, they start > getting their own packets back (send a conf ack with a specific magic, > and get back a conf ack with that same magic, repeat with a conf nak, > and so on). Obviously, something is causing these packets to turn > around and get sent back to the customer....my question is what? I saw this recently with a client I set up. Their 33.6 modem connected at 26.4 just fine the first few times, and it logged in and worked those times. I was about to go, and had them try it before I go. It quits working. I finally had to set the modem to a max rate of 19.2 to get it to work. I was seeing the same LCP conf requests just like you were. Brian - 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. From: Jeff Mcadams <jeffm@iglou.com> Subject: Re: (usr-tc) Possible Loopback? Date: 04 Mar 1998 16:27:47 -0500 (EST) Thus spake Brian Elfert >On Wed, 4 Mar 1998, Jeff Mcadams wrote: >> OK, this one is weird... >> TCS 3.0.2, lines on PRI's off a 5ESS, Quad modems with netservers (no >> hyper stuff at all here) ISDN terminated on quads. >> I've got two or three customers that are dialing in and after a few >> seconds (anywhere from 2-3 up to 6) during which they're sending LCP >> conf req's to our equipment. After that slight pause, they start >> getting their own packets back (send a conf ack with a specific magic, >> and get back a conf ack with that same magic, repeat with a conf nak, >> and so on). Obviously, something is causing these packets to turn >> around and get sent back to the customer....my question is what? >I saw this recently with a client I set up. Their 33.6 modem connected at >26.4 just fine the first few times, and it logged in and worked those >times. >I was about to go, and had them try it before I go. It quits working. >I finally had to set the modem to a max rate of 19.2 to get it to work. I >was seeing the same LCP conf requests just like you were. Eh? Modem speeds? Anyone have any even semi-logical theories on why that would affect this? This just seems like this wouldn't have any significance whatsoever on how that would work. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

OK, this one is weird... TCS 3.0.2, lines on PRI's off a 5ESS, Quad modems with netservers (no hyper stuff at all here) ISDN terminated on quads. I've got two or three customers that are dialing in and after a few seconds (anywhere from 2-3 up to 6) during which they're sending LCP conf req's to our equipment. After that slight pause, they start getting their own packets back (send a conf ack with a specific magic, and get back a conf ack with that same magic, repeat with a conf nak, and so on). Obviously, something is causing these packets to turn around and get sent back to the customer....my question is what? One customer is using a Bay Networks Instant Internet box, another is on a sportster x2 modem. Anyone run into this before? Any ideas on what to look at and consider? I'm pretty stumped here. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Once upon a time I. Dwayne Koonce shaped the electrons to say... >Thanks! This logs the VSA's just fine. One question though--is there >any way to cause it to require clients to be listed in the clients file? >I tried testing it with just one of our TC's, but it took accounting >requests from all of our NASes, even though only the test machine was >listed in the clients file. Accounting servers generally do not check the clients file - they are just dumb logging machines. Newer servers will use the file, but just to check the authenticator field on the accounting packets - the digital signature. All that I am familiar with will still log packets from an unknown client, they just add a notifier to the record to indicate it was not authenticated. -MZ, btw, new deal on PM-3s today - $210 a port. -- <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human being, me "A little nonsense now and then, is relished by the wisest men" 508-791-9803 <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail Discordia!

Brian <signal@shreve.net> writes: > except thats not it, I think I am missing a semicolon or something > somewhere. Thanks (using it with cmu and ucd snmp) In the CMU case, thinking back on some fixes I made, depending on what you have it might not like a MIB definition that doesn't have any imports (or something like that). I'll try to look deeper, but try adding a semicolon just after the BEGIN in each of the mibs, e.g., something like: RFC1155-SMI DEFINITIONS ::= BEGIN ; Yeah, it looks dumb, but... Also, on the RFC1213 front, I generally junk the MIB1 file that might be included with the MIBs and include RFC1213 directly. You pick up a few objects that the NMC doesn't support in the ip table, but you need to have the transmission tree (not in MIB I) if using any of the later HDM-compatible MIBs that include RFC1406. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Jeff Lynch <jeff@mercury.jorsm.com> writes: > It sounds like you have line-side channelized T1s without > B8ZS connecting the telco side of d4 channel bank line > interface cards to analog centrex telephone office > equipment. Note that the line-side connection (pretty much assured if you're dealing with ground start or loop start circuits) is much more important than the B8ZS/AMI distinction. We have AMI stuff that works just as well or sometimes better than B8ZS. But going through those channel banks and analog copper pairs is ugly. However, it's interesting that the behavior is worse than what was previously being encountered with pure POTS lines, as typically the line side T1 with channel banks performs more or less the same as a POTS line. Of course, the POTS lines may have just been going into a different switch and been of better quality, but to throw out a few other suggestions to the original poster: * Check the transmit line level on your modems. If you've previously been running them on analog lines, they might be at 11db - try dropping it to 13db in case you might be too "hot" for the digital line. * Check your DS1 interval statistics and ensure that you aren't getting physical layer errors that might be corrupting the modem sessions. * If your T1 circuit is passing through multiple segments within a telco or carrier, ensure that the provisioning of the circuit hasn't swapped line codings along the way. For example, if your last leg of the circuit is B8ZS, but somewhere in the middle someone configured a segment as AMI, you might not see any errors on your last segment, but calls going through are going to see horrible performance hits and poor quality connections. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Brian Elfert <brian@citilink.com> writes: > The latest AOL software installs something called the AOL adaptor in the > network settings in Windows 95. There is also TCP/IP pointed at this. > > What exactly is this? Is AOL using TCP/IP now? Nope - it's simply the way for you to run other TCP/IP applications over your AOL connection. For Windows 3.1 users AOL provides an AOL-specific 16-bit WINSOCK. For Windows 95 users it installs the adapter. This has been true since AOL 3.0 was released (although the WINSOCK was downloadable for AOL 2.5 users). -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

info@sltic.com writes: > The TCP/IP -> AOL Adapter is there so AOL lusers can use the "Bring your > own access" plan and connect through a "real" ISP to get to AOL. Direct > dial to AOL doesn't use TCP/IP. Actually, the adapter provides the reverse - TCP/IP access for other applications through a standard AOL dialup through their own system. If you're using the BYOA approach, then the AOL client just connects using a normal TCP/IP session, over whichever standard LAN (or dialup PPP) "adapter" you may be using for your network access. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Recently I started getting calls from clients that claimed they were not getting x2 connects. Seeing x2 callers online, I did not suspect the TC hub. After reading these posts I went through and looked (Using TC Manager 4.3.6) and found some interesting issues. First, the NMC Card says X2 is disabled. I have not had problems running the hub with the NMC card removed. The features set is all zeros, except the last section is 0100. Last fall USR replaced my NMC card, which, if I'm reading this right, did not have the X2 feature enabled. More surprising to me, I looked at each quad card. Under features, 3 cards show X2 is disabled. Except for the 45th port, I can connect at X2 speeds on all of them. (???) Is this hub maintaining its X2 feature simply because its never been reset or repowered since the original NMC card was replaced? Another thing I found interesting on this hub is when I select a slot (Again using TC Manager) and select x2 Configuration, many of the ports have error messages under Remote X2 client transmitter of "Invalid enumeration 8" on x2 calls. I'm also seeing occasional errors under Remote X2 server transmitter "Invalid Enumeration:38" Does anyone know what these mean? Thanks, Steve@flasuncoast.net >matthew <matthew@the-spa.com> writes: > >> now x2 doesn't seem to work for all 96 ports. >> >> stupid question #1 is the x2 enable code stored in the nmc card? > >Unless the quad modems were ordered with x2 installed at 3Com (which I >heard was going to encode the feature enable right in the modem, but >haven't actually verified myself), then yes, the NMC maintains the >feature enable key from which the modems take their queue as to what >features should be enabled. > >You can check the current features by querying the MIB object >"uchasSlotStatFeEna" for any specific slot. > >When queried for the NMC (slot 17), you want to see bit 6 (0x40) set >in the feature mask (or _possibly_ bit 5 (0x20) if you had a really >old key and older NMC code, but I'm not sure that ever was released). > >When querying an individual quad modem card slot, you want to see bit >5 (0x20) set in the feature mask. > >TCM may break these features out automatically, I'm not sure. > >> stupid question #2 if answer to #1 is now what did i break? > >I assume you mean if the answer is yes - then in terms of "breaking" >you'll prevent x2 connections being made to the quad cards, until the >feature is re-enabled on the NMC, and thus passed on to the quad cards. > >I'm not sure how 3Com handles the feature enable key in double up >situations when you swap the NMC, since the feature enable key should >be linked with the serial number of the NMC (presumably the old one at >this point). > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > 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. > >

usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox) writes: > First, the NMC Card says X2 is disabled. I have not had problems > running the hub with the NMC card removed. The features set is all zeros, > except the last section is 0100. Last fall USR replaced my NMC card, which, > if I'm reading this right, did not have the X2 feature enabled. Well, in general the way the x2 feature code works is in a "semi-permanent" mode, providing it's the NMC supplying the feature to the modems and not something built into the modems directly. When a modem resets for any reason, or upon the NMC insertion/boot, or upon issuing a change to the feature code to the NMC, the modems sync up with the NMC as far as features. In the absence of an NMC when a modem boots, it continues to use the previously set features (thus "semi-permanent"). So if you were to enable x2 on a rack via the NMC, and then pull the NMC, those modem cards would continue to treat the x2 feature as enabled as long as the NMC was gone. If you reinserted an NMC, the modems would immediately sync up their feature set, so if that new NMC didn't have x2 they'd lose it as soon as the NMC finished starting up. Of course, if you reinserted an NMC with x2 enabled, nothing apparent would happen. Note that querying the feature set for active modems in such case does not always reflect the new feature set immediately, but it does change in the modems. > More surprising to me, I looked at each quad card. Under features, 3 cards > show X2 is disabled. Except for the 45th port, I can connect > at X2 speeds on all of them. (???) Is this hub maintaining its X2 feature > simply because its never been reset or repowered since the original NMC > card was replaced? If you actually inserted the new NMC (without x2 enabled), the modems would sync their features immediately. What it sounds like you might have is perhaps quad cards ordered with x2 enabled, in which case the feature key doesn't really matter - the enable is built into the modem regardless of what the NMC says. It's strange about those not reflecting the x2 feature. I think that it reflects x2 whether built into the modem or learned from the NMC. You were definitely getting "x2" as your modulation type on calls to those modems? If you could, it might be useful to connect to the modem and issue an ATI7 to see what features that output thinks are enabled. > Another thing I found interesting on this hub is when I select a slot > (Again using TC Manager) and select x2 Configuration, many of the ports > have error messages under Remote X2 client transmitter of "Invalid > enumeration 8" on x2 calls. I'm also seeing occasional errors under > Remote X2 server transmitter "Invalid Enumeration:38" Does anyone > know what these mean? I'm not positive which MIB objects those TCM names translate to, but if they refer to part of the remote modem stuff (rmdm.mib) I haven't really found that to be functional at this point. At the very least, unless the remote client status field has a value of "ok" I don't think you can make use of the other objects in that table for the modem. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

> Has anyone here had any luck with using the Inventory feature in TCM for > Windows? Every time we've tried to use it, TCM will crash with a > kernel32.dll error. Works fine here - we run it over our chassis' prior to an upgrade so that we can check each item off during the upgrade cycle (typically a couple of weeks). Regards, Bob Purdon, Technical Manager, Southern Internet Services.

On a related note, I just lost a management card, but the rack is still taking calls... What will happen with X2 in this case? On the next modem reset will X2 go away? What is lost besides monitoring/remote-management in this case? Thanks, Charles ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com On Wed, 4 Mar 1998, Suncoast Networking USR Mailbox wrote: > Date: Wed, 4 Mar 1998 17:15:04 -0500 > From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.Net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) x2 not enabled all of a sudden? A similar problem. > > Recently I started getting calls from clients that claimed they were not > getting x2 connects. Seeing x2 callers online, I did not suspect the TC hub. > After reading these posts I went through and looked (Using TC Manager > 4.3.6) and found some interesting issues. > > First, the NMC Card says X2 is disabled. I have not had problems > running the hub with the NMC card removed. The features set is all zeros, > except the last section is 0100. Last fall USR replaced my NMC card, which, > if I'm reading this right, did not have the X2 feature enabled. > > More surprising to me, I looked at each quad card. Under features, 3 cards > show X2 is disabled. Except for the 45th port, I can connect > at X2 speeds on all of them. (???) Is this hub maintaining its X2 feature > simply because its never been reset or repowered since the original NMC > card was replaced? > > Another thing I found interesting on this hub is when I select a slot > (Again using TC Manager) and select x2 Configuration, many of the ports > have error messages under Remote X2 client transmitter of "Invalid > enumeration 8" on x2 calls. I'm also seeing occasional errors under > Remote X2 server transmitter "Invalid Enumeration:38" Does anyone > know what these mean? > > Thanks, > Steve@flasuncoast.net > > >matthew <matthew@the-spa.com> writes: > > > >> now x2 doesn't seem to work for all 96 ports. > >> > >> stupid question #1 is the x2 enable code stored in the nmc card? > > > >Unless the quad modems were ordered with x2 installed at 3Com (which I > >heard was going to encode the feature enable right in the modem, but > >haven't actually verified myself), then yes, the NMC maintains the > >feature enable key from which the modems take their queue as to what > >features should be enabled. > > > >You can check the current features by querying the MIB object > >"uchasSlotStatFeEna" for any specific slot. > > > >When queried for the NMC (slot 17), you want to see bit 6 (0x40) set > >in the feature mask (or _possibly_ bit 5 (0x20) if you had a really > >old key and older NMC code, but I'm not sure that ever was released). > > > >When querying an individual quad modem card slot, you want to see bit > >5 (0x20) set in the feature mask. > > > >TCM may break these features out automatically, I'm not sure. > > > >> stupid question #2 if answer to #1 is now what did i break? > > > >I assume you mean if the answer is yes - then in terms of "breaking" > >you'll prevent x2 connections being made to the quad cards, until the > >feature is re-enabled on the NMC, and thus passed on to the quad cards. > > > >I'm not sure how 3Com handles the feature enable key in double up > >situations when you swap the NMC, since the feature enable key should > >be linked with the serial number of the NMC (presumably the old one at > >this point). > > > >-- David > > > >/-----------------------------------------------------------------------\ > > \ David Bolen \ Internet: db3l@ans.net / > > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ > >\-----------------------------------------------------------------------/ > > > >- > > 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. > > > > > > > - > 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. >

Most of my users report download speeds of under 1.5kbps. The traffic on my backbone never exceeds a third of the bandwidth available even at peak times. If the initial connection was poor, but the sessions straightened out eventually, that wouldn't be a problem. I have several customers who report 300bps download times with 28.8 modems. And NO it is not because they are connecting to slow sites. Steve -----Original Message----- >: I have problems getting decent speeds out >: of v.34 modems. Nearly all of the connections >: to my rack are at 26,400 or less and some >: customers never can achieve 19,200. > >The intial connection to a modem is a hairsbreadth from meaningless >(which is better, a 56k connection that dies after 3 seconds, or a 26.4k >connection that lasts a week?). > >Are you monitoring the transmit link rates? > > >- > 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. >

Bob Purdon <bobp@southcom.com.au> writes: > Confused? Let me rephrase slightly - I won't say (nor will say :-)) that at some point along the way IP isn't used as one of the underlying transports for AOL client data, but only that the AOL client on a Windows 95 machine acts as a typical async modem client - unless set up for TCP/IP connections in BYOA mode - and is not a user of a local PPP stack like the DUN, which was the context of "TCP/IP" in the original message. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

We have an opportunity to acquire a Dual PRI NAC/Dual T1 NIC card set (for a TC chassis) at a pretty good price. The problem is that we need a card set for channelized T1 service, not PRI ISDN. Does anyone know if the Dual PRI NAC/Dual T1 NIC card set can be configured (or flash upgraded) to support channelized T1? If so, what is the procedure? Thanks in advance, Gary

Dave, Thanks for the info. Per Standard here are the values 1 PPP 2 SLIP 3 AppleTalk Remote Access Protocol (ARAP) 4 Gandalf proprietary SingleLink/MultiLink protocol 5 Xylogics proprietary IPX/SLIP We use 9 as PPTP and we can autodetect the same. I am not sure if 9 is the correct value either. Since we autodetect for people not using appletalk ( we do not support it currently on NETServer ) 3 will not cause a problem with our product. It may with yours so it is safe to use 9. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 5 Mar 1998, Dave Mitton wrote: > Dear USR, > > This value is not RFC compliant. > > Framed-Protocol = 3 is defined as ARAP (Appletalk Remote Access Protocol) > > Please pick a different value. > > Dave. > > At 09:20 PM 2/24/98 -0600, Tatai SV Krishnan wrote: > >On Wed, 25 Feb 1998, Richard Bosire wrote: > > > >> Hi Guys , > >> > >> Does anyone know which version of Radius ptpp and what version of the > >> netserver code this will > >> with .. > >> > >> TIA > >> > >> cheers > >> > >> bosire > > > > > >Every Radius will support PPTP, see in the dictionary file under the > >framed-protocol section you will see something like this > > > >VALUE Framed-Protocol PPP 1 > > > >now go ahead and add a new item there > > > >VALUE Framed-Protocol PPTP 3 > > > >and when you add users you should say Framed-Protocol is PPTP > > > >krish > > > > --------------------------------------------------------------- > David Mitton 978-670-8888 Main > Consulting Engineer 978-916-4570 Direct > Bay Networks, Remote Access Srv Div 978-916-4789 FAX > Billerica, MA 01821 dmitton@baynetworks.com > > - > 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. >

David, Three questions then. First, if I upgrade an NMC to 16 meg flash (i.e. the doubleup program) will the X2 feature be lost ? Second, if I save the configuration to disk and then reload an NMC, can a lost X2 be recovered via the backup. Lastly, if the NMC has the X2 key enabled and HDMs are installed (i.e. the doubleup program again) will the HDMs also pickup the X2 key ? I think yu can see where this is all heading. Maybe there's some info on performing the doubleup process on a TC rack that is available for review ? Jeff Binkley ASA Network Computing U>usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox) writes: U>> First, the NMC Card says X2 is disabled. I have not had problems U>> running the hub with the NMC card removed. The features set is all U>> zeros, except the last section is 0100. Last fall USR replaced my U>> NMC card, which, if I'm reading this right, did not have the X2 U>> feature enabled. U>Well, in general the way the x2 feature code works is in a U>"semi-permanent" mode, providing it's the NMC supplying the feature to U>the modems and not something built into the modems directly. U>When a modem resets for any reason, or upon the NMC insertion/boot, or U>upon issuing a change to the feature code to the NMC, the modems sync U>up with the NMC as far as features. In the absence of an NMC when a U>modem boots, it continues to use the previously set features (thus U>"semi-permanent"). U>So if you were to enable x2 on a rack via the NMC, and then pull the U>NMC, those modem cards would continue to treat the x2 feature as U>enabled as long as the NMC was gone. If you reinserted an NMC, the U>modems would immediately sync up their feature set, so if that new NMC U>didn't have x2 they'd lose it as soon as the NMC finished starting up. U>Of course, if you reinserted an NMC with x2 enabled, nothing apparent U>would happen. TOP 32\REMHOOKS.DLL �! ��4��4� a�3,�  a aL:\PCBUU 3 3  a3678 Mar �+�� ^ a ; Thu, 5 Mar 1998 7:43:07 -500 [199.178.136.5] by bbs2.a���+W� ��4�4� a�3,�  a aL:\PCBUUCP\MTA\NXMAIL.INm,� �@��� a4a@�+� ����:/B� 4a aP�@� � �@4a a�@d�A a @@��� a4a~�+� ����:/B� 4a a��@�+4a a�KW� x��+]_4a a? a5T�+�+9$Q
�  )x�+��4� 02�+4a J av� iO� a��4�� a�� iQ� �=250 <USR-TC@LISTS.XMISSION.COM>... Recipient ok aKW� x��+]_�+4a aKW� x��+]_4a a? a5T4a a� a�+�L� 2�+^4a a�n��i� < a�+�2 a��/i a�KW� x��+]_4a a? a5T4a a� ��4��44a a��M� ��4��44a a  a
  * I U � �                                                   L:\pcbuucp\mta>cd\pcbuucp\mta\pktdrv                                                                                                                            L:\pcbuucp\mta\pktdrv>rem in220p /d /utp 0x69 10 0300                                                                                                           L:\pcbuucp\mta\pktdrv>rem slipper com3 irq=5 baud=38400 non-ethernet                                                                         w�6�@r6�B� &�>
�t <
t$<t2<t66�#�
��6�#���6�2���S��?���[w�6���6�� �D�L��XV�u�_�[�V� �D�t�\^6��6��6�r��/�� �� �:+�+���� 6�(�D6�*�D6�&�D6�&#�.�'?&�0&;2 &�E$�<pt� �&�����r�>�֧�ܧ�r�>�����r�h����3��s� w&U&M���&�E&�U�x��T�&�E�u &U&M��&�E�u�&�E%� �u�&�M
�6��� �u6�6@HV6�#6�r�t!PW6���6��A��&�EC �t��ߪu��� �t�����t�N �t�\��X O�+ �t����;�rO&���u��ð�Ã�VWU��.��8�u���t��8�uW���uR2���v�G�v��;vt?6�r�u��
6 �t/�v�K�~ W蛼_菬IN;N 6�>z�t��PX3ɉL�L3��Rmu ��t$� �r�鼝Q��l�����P$A�X��u��U��� ����t� 6�� �/��� �/���� �����s�Y���tM���t=$<uB�>� ���� ���� ���� �H�� �� *�Ã>� ���Ë I;Mv�� �H�E �E���EU�.�W��_r]�.�2�&� �tP<�t�&"G<t�=
uh&���@�H� �H�E��� � � �D6� ��� &�<.uN�
r,���� s����׊��x �K2��rV�6��L^�6�K��&�N&�F2�R6� �t;�s����s
��.��~����Cr ��� Y[3ɸ ;uu;Mw .;>ŏ�=u��P�E@t.QRVW��+E�؍u&�N��6�>�6������_^ZY���.;ŏXu����s���
&�e��&�E�&�E��.������������� �t���_r��� 6�] 6;w
r�>���� �t2����6��� �&V6� �� &�EIt&�EI��X���.���&�F����� u�� �� &hy�dt<��U&�n&�F]t&W�K�>i�*�>(� QR�ٌ�;�ZY�3���&�F
3��t&�F�E &�F�E���6�>�6����<�u3۹ 2�6�K��t6�K �EW���SWQP�
��+Ўځ���������t ��+Ў����Ì�H�؎�� � P� 0 �� ��и
.�O
�
��f[fX�
��.�T.�|
�t��^Y�ظ
��f�γ�f�t2�f_f^��QVW3���.��.���u.�?
u.f;Ww����u.�?u���� ���uA�tPf�uG��.f�D ��.f�T.�|
�^Y�
�� ��Y����Yf��.fD.f�E.f�Df+�.f�E.�
.�E
&f�G &f�GfXf�� &f�VWfR�������fZ_^���.�M
.�L
.f�Df+�.f�Tt.fT.f�U.f�E��.���3�_^fZ]�VR�k����Z^���t�.�E
.�D
����&�w&� f3�&f�G&f�G.f�Df�� &f�VW�������_^���.f�D.f�E.f�D.f�D.f�E.f�D.�L
.�M
��_^fZ��]��.f�D.f�Tf�3���.��.��fV.�?
u .f�wf;�u���u.fwf;�u���u�� ��f^� � f+�r=f;�r0.�G
.f�Gf�� f����f��f��f��f�f��f�f=�� ��t.�E

=u�&g��Bt��
r��w����� �t�.X�PSRW��4 Ƅ� ���3ɋѸ ��Y

Honestly, there are a lot of things that I've found myself unable to do without using the TotalControl Manager. It's the only reason I use Windows for my workstation. If I were a little smarter (give me time, I'm getting there :-) ), I'd figure out how to use a different program - like Scotty/Tkined on my FreeBSD box - to do the job, if it has to be done via SNMP, and I've never seen the options on a command line. Maybe if I put a terminal server back there connected to the console ports or something... On Thu, 5 Mar 1998, I. Dwayne Koonce wrote: > Okay, I finally have my RADIUS server properly logging Vendor-Specific > RADIUS attributes, but now it appears that many of the attributes we're > interested in aren't being sent. Of particular interest is connection > performance data, such as Initial-Rx-Link-Data-Rate (0xBF2D), > Final-Rx-Link-Data-Rate (0xBF2C), Initial-Tx-Link-Data-Rate (0x006A), > Final-Tx-Link-Data-Rate (0x006B), etc., but these do not appear to be sent > by default. > > USR tech support said I needed to use their Total Control SNMP software to > set the Configure->Programmed Settings->Logging Group->Log Group Selection > to "all" on the NMC (which seemed odd, since the accouting info I'm > currently getting is coming from the NetServer). I did so, and pointed > the NMC at my RADIUS server--no luck. > > Another call to tech support, and they tell me I have to go back into > Total Control Manager and manually enable log traps for each of a dozen > events *on each individual modem*. > > We configured the first modem, and dialed into it--nada. None of the info > that the NMC is supposed to be able to send made it to our radiusd. So, > does anyone have any idea what's necessary to log this? (And is there any > way to do it w/o using TCM [blech] to change a dozen settings per > individual modem?) > > ____________________________________________________________________________ > I. Dwayne Koonce E-mail: dwayne@txcyber.com > ____________________________________________________________________________ > "It's dangerous to be right when the government is wrong." --Voltaire > > > > - > 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. > Timothy A. Gregory Northwest Link Systems Administrator Arabic > English Translator

Honestly, there are a lot of things that I've found myself unable to do without using the TotalControl Manager. It's the only reason I use Windows for my workstation. If I were a little smarter (give me time, I'm getting there :-) ), I'd figure out how to use a different program - like Scotty/Tkined on my FreeBSD box - to do the job, if it has to be done via SNMP, and I've never seen the options on a command line. Maybe if I put a terminal server back there connected to the console ports or something... On Thu, 5 Mar 1998, I. Dwayne Koonce wrote: > Okay, I finally have my RADIUS server properly logging Vendor-Specific > RADIUS attributes, but now it appears that many of the attributes we're > interested in aren't being sent. Of particular interest is connection > performance data, such as Initial-Rx-Link-Data-Rate (0xBF2D), > Final-Rx-Link-Data-Rate (0xBF2C), Initial-Tx-Link-Data-Rate (0x006A), > Final-Tx-Link-Data-Rate (0x006B), etc., but these do not appear to be sent > by default. > > USR tech support said I needed to use their Total Control SNMP software to > set the Configure->Programmed Settings->Logging Group->Log Group Selection > to "all" on the NMC (which seemed odd, since the accouting info I'm > currently getting is coming from the NetServer). I did so, and pointed > the NMC at my RADIUS server--no luck. > > Another call to tech support, and they tell me I have to go back into > Total Control Manager and manually enable log traps for each of a dozen > events *on each individual modem*. > > We configured the first modem, and dialed into it--nada. None of the info > that the NMC is supposed to be able to send made it to our radiusd. So, > does anyone have any idea what's necessary to log this? (And is there any > way to do it w/o using TCM [blech] to change a dozen settings per > individual modem?) > > ____________________________________________________________________________ > I. Dwayne Koonce E-mail: dwayne@txcyber.com > ____________________________________________________________________________ > "It's dangerous to be right when the government is wrong." --Voltaire > > > > - > 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. > Timothy A. Gregory Northwest Link Systems Administrator Arabic > English Translator

On Thu, 5 Mar 1998, Jason Allen wrote: > I have a customer with a WebRamp ISDN router who would like to use both B > channels on their BRI. My question is do I have to configure anything in > the TC, Radius, etc to make this happen? Or will the 2 B channels "bond" > automagically when the WebRamp dials in? I dug through the documentation CD > but it didn't shed much light on the subject. > > Thanks, > > Jason mp is enabled by default, do a show mp on the RADIUS side set a Port-Limit = 2 for this user. > > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

I have a customer with a WebRamp ISDN router who would like to use both B channels on their BRI. My question is do I have to configure anything in the TC, Radius, etc to make this happen? Or will the 2 B channels "bond" automagically when the WebRamp dials in? I dug through the documentation CD but it didn't shed much light on the subject. Thanks, Jason

It has been my experience that calls will connect at a standard rate, then "upshift" to x2. If you read previous posts, the modems must be x2 enabled, rather than getting their x2 feature enabling from the NMC. Apparantly different racks/cards/OS versions react differently. But the bottom line appears to be you should not replace the NMC card until you are ready to replace it with a working one complete with the x2 feature enable code. Steve >On a related note, I just lost a management card, but the rack is still >taking calls... What will happen with X2 in this case? On the next modem >reset will X2 go away? What is lost besides monitoring/remote-management >in this case? > >Thanks, > >Charles > >~~~~~~~~~ ~~~~~~~~~~~ >Charles Sprickman Internet Channel >INCH System Administration Team (212)243-5200 >spork@inch.com access@inch.com > >On Wed, 4 Mar 1998, Suncoast Networking USR Mailbox wrote: > >> Date: Wed, 4 Mar 1998 17:15:04 -0500 >> From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.Net> >> Reply-To: usr-tc@lists.xmission.com >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) x2 not enabled all of a sudden? A similar problem. >> >> Recently I started getting calls from clients that claimed they were not >> getting x2 connects. Seeing x2 callers online, I did not suspect the TC hub. >> After reading these posts I went through and looked (Using TC Manager >> 4.3.6) and found some interesting issues. >> >> First, the NMC Card says X2 is disabled. I have not had problems >> running the hub with the NMC card removed. The features set is all zeros, >> except the last section is 0100. Last fall USR replaced my NMC card, which, >> if I'm reading this right, did not have the X2 feature enabled. >> >> More surprising to me, I looked at each quad card. Under features, 3 cards >> show X2 is disabled. Except for the 45th port, I can connect >> at X2 speeds on all of them. (???) Is this hub maintaining its X2 feature >> simply because its never been reset or repowered since the original NMC >> card was replaced? >> >> Another thing I found interesting on this hub is when I select a slot >> (Again using TC Manager) and select x2 Configuration, many of the ports >> have error messages under Remote X2 client transmitter of "Invalid >> enumeration 8" on x2 calls. I'm also seeing occasional errors under >> Remote X2 server transmitter "Invalid Enumeration:38" Does anyone >> know what these mean? >> >> Thanks, >> Steve@flasuncoast.net >> >> >matthew <matthew@the-spa.com> writes: >> > >> >> now x2 doesn't seem to work for all 96 ports. >> >> >> >> stupid question #1 is the x2 enable code stored in the nmc card? >> > >> >Unless the quad modems were ordered with x2 installed at 3Com (which I >> >heard was going to encode the feature enable right in the modem, but >> >haven't actually verified myself), then yes, the NMC maintains the >> >feature enable key from which the modems take their queue as to what >> >features should be enabled. >> > >> >You can check the current features by querying the MIB object >> >"uchasSlotStatFeEna" for any specific slot. >> > >> >When queried for the NMC (slot 17), you want to see bit 6 (0x40) set >> >in the feature mask (or _possibly_ bit 5 (0x20) if you had a really >> >old key and older NMC code, but I'm not sure that ever was released). >> > >> >When querying an individual quad modem card slot, you want to see bit >> >5 (0x20) set in the feature mask. >> > >> >TCM may break these features out automatically, I'm not sure. >> > >> >> stupid question #2 if answer to #1 is now what did i break? >> > >> >I assume you mean if the answer is yes - then in terms of "breaking" >> >you'll prevent x2 connections being made to the quad cards, until the >> >feature is re-enabled on the NMC, and thus passed on to the quad cards. >> > >> >I'm not sure how 3Com handles the feature enable key in double up >> >situations when you swap the NMC, since the feature enable key should >> >be linked with the serial number of the NMC (presumably the old one at >> >this point). >> > >> >-- David >> > >> >/-----------------------------------------------------------------------\ >> > \ David Bolen \ Internet: db3l@ans.net / >> > | ANS Communications, Inc. \ Phone: (914) 701-5327 | >> > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >> >\-----------------------------------------------------------------------/ >> > >> >- >> > 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. >> > >> > >> >> >> - >> 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. >> > > >- > 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. > >

Okay, I finally have my RADIUS server properly logging Vendor-Specific RADIUS attributes, but now it appears that many of the attributes we're interested in aren't being sent. Of particular interest is connection performance data, such as Initial-Rx-Link-Data-Rate (0xBF2D), Final-Rx-Link-Data-Rate (0xBF2C), Initial-Tx-Link-Data-Rate (0x006A), Final-Tx-Link-Data-Rate (0x006B), etc., but these do not appear to be sent by default. USR tech support said I needed to use their Total Control SNMP software to set the Configure->Programmed Settings->Logging Group->Log Group Selection to "all" on the NMC (which seemed odd, since the accouting info I'm currently getting is coming from the NetServer). I did so, and pointed the NMC at my RADIUS server--no luck. Another call to tech support, and they tell me I have to go back into Total Control Manager and manually enable log traps for each of a dozen events *on each individual modem*. We configured the first modem, and dialed into it--nada. None of the info that the NMC is supposed to be able to send made it to our radiusd. So, does anyone have any idea what's necessary to log this? (And is there any way to do it w/o using TCM [blech] to change a dozen settings per individual modem?) ____________________________________________________________________________ I. Dwayne Koonce E-mail: dwayne@txcyber.com ____________________________________________________________________________ "It's dangerous to be right when the government is wrong." --Voltaire

Jason, Thanks for the info but it still leaves me with some questions that I hope can be answered. See below... At 12:12 PM 3/3/98 +1000, Jason_Kelton@3com.com wrote: >Sorry... accidentally hit the send button.... please see this response for >the complete package!!! > > > >Please respond to usr-tc@lists.xmission.com > >To: usr-tc@lists.xmission.com >cc: (bcc: Jason Kelton/AU/3Com) >Subject: (usr-tc) [usr-tc] more questions on ports > >How many ISDN calls can I have in a filled TCH chassis using Dual PRI cards >and NetServer modules? I am assuming you can have 5 Netservers, each using >2 Dual PRIs for a total of 460 calls. Is this the max you can have in one >Chassis? In this case there would be no async calls... > NO. In an ISDN configuration, you're restricted to a MAX of 240 ISDN > calls, as the TDM only has 256x64K timeslots. You are only allowed a > MAX of 4 Dual PRI's per Chassis. I thought the newer chassis' TDM was 512x64K. Can you confirm? If it is 512, then does this change anything or am I still limited to just 4 Dual PRIs in one chassis. If I had 4 Dual PRIs (the MAX), can I additionally add HiPer DSPs to this chassis? Why, then can I have 14 HiPer DSPs in one chassis if the TDM is limited to 256x64K? Making the assumption that there is a 512x64K TDM, is it the Dual PRIs can only use the 256 part and the new HiPer DSPs can use the 512? Could it be that there's two TDMs in the newer chassis? >Then, assume using ARC. Can I use 2 ARCs with 7 Dual PRIs each for a total >of 644 ISDN only calls? > NO. You would still be limited to 240 ISDN calls. You could add 10 > HiPER DSP cards, taking the chassis to a MAX. of 540, but I don't know > if this configuration would work, as I'm not sure if you can terminate > the calls directly from a Dual PRI onto the HiPER. Are you saying that I can't terminate Dual PRI calls into a HiPer ARC? Please find out for sure. >How about with the EdgeServer PRO? Will this configuration work in a >single chassis? 2 EdgeServer PROs, 10 Dual PRIs. So that each EdgeServer >PRO handles 5 Dual PRIs for a total of 230 ports for each EdgeServer PRO >and a max of 460 ports in the chassis. > > No and for the same reasons..... Okay, I think I understand that. Since only 4 Dual PRIs are allowed in the chassis, the limit would be 240, too. >Some folks saw the chassis at ComNet that had EdgeServer PRO on display for >Voice applications. Will HiPer ARC support Voice or will this only work >with the EdgeServer PROs? > > As I currently understand it, the Edgeserver PRO is the only product > available to support Voice over IP. I would assume something available > eventually for HiPER ARC, but would still require Servers of some > denomination, hence, making it practically unfesable. ++++++++++++++++++++++++ mailto:turners@best.com ++++++++++++++++++++++++

Oops. I meant NFAS. I didn't see that HiPer DSP supports NFAS. If it does, can you point out the chapter on the CD that explains it? At 12:15 PM 3/2/98 -0800, G. Turner wrote: >Maybe I wasn't looking in the right place but does HiPer DSP support DNIS? >If so, where do I set it up? > >Thanks. ++++++++++++++++++++++++ mailto:turners@best.com ++++++++++++++++++++++++

> We have an opportunity to acquire a Dual PRI NAC/Dual T1 NIC card set (for > a TC chassis) at a pretty good price. > > The problem is that we need a card set for channelized T1 service, not PRI > ISDN. > > Does anyone know if the Dual PRI NAC/Dual T1 NIC card set can be configured > (or flash upgraded) to support channelized T1? If so, what is the procedure? Yes, the 386 based PRI cards can be flashed with the T1 code - I've done it several times - the first order I placed for TC Chassis (25 fully chassis) all came with PRI code, and I needed to flash the T1 code in them. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Strongly suggest you listen to the just-posted Brian McWilliams PCWorld NewsRadio. Lead story is on v.90 problems, and other 3Com issues. 3Com spokesperson Bert Murray indicates that 3Com is going to be modifying its policy for ISPs and make updated x2 code available to them without them having to pay thousands of dollars for service contracts. Go to http://www.pcworld.com/news/newsradio/index.html and listen for yourself. In my opinion, McWilliams has been covering v.90/56k *very* well, and in a fair and unbiased fashion. The bias, if any, comes from sound bites, and he is doing an admirable job to present all sides. Aloha, Richard for the biased view of 56k, visit my site at http://pages.prodigy.net/bbhi/r-rnut-x2.htm

Original message from CyberPort Montana: > >Does anyone know if the Dual PRI NAC/Dual T1 NIC card set can be configured >(or flash upgraded) to support channelized T1? If so, what is the procedure? Yes it can, it's actually really simple. Download the ChanT1 code from 3Com, then use TCM to do a software download, for the NAC and SDL files, type in what you just downloaded. Cake walk. Jas, Interpath Communications Data Network Technician Jas.Eckard@interpath.net

Dear USR, This value is not RFC compliant. Framed-Protocol = 3 is defined as ARAP (Appletalk Remote Access Protocol) Please pick a different value. Dave. At 09:20 PM 2/24/98 -0600, Tatai SV Krishnan wrote: >On Wed, 25 Feb 1998, Richard Bosire wrote: > >> Hi Guys , >> >> Does anyone know which version of Radius ptpp and what version of the >> netserver code this will >> with .. >> >> TIA >> >> cheers >> >> bosire > > >Every Radius will support PPTP, see in the dictionary file under the >framed-protocol section you will see something like this > >VALUE Framed-Protocol PPP 1 > >now go ahead and add a new item there > >VALUE Framed-Protocol PPTP 3 > >and when you add users you should say Framed-Protocol is PPTP > >krish > David Mitton 978-670-8888 Main Consulting Engineer 978-916-4570 Direct Bay Networks, Remote Access Srv Div 978-916-4789 FAX Billerica, MA 01821 dmitton@baynetworks.com

Hi, I just confirmed utter and total death of an NMC. A new one should be here tomorrow they tell me... Is is standard/acceptable practice to just swap flash memory between the cards rather than setting it up from scratch? Other than the flash possibly being the problem, I don't see anything wrong with it. Anyone? Otherwise I have to dig up those darned X2 keys, which I thought wouldn't even work on different serial # cards... Also, as a "gift" we were given an old chassis. It doesn't have a model number on it, and the TCM inventory function doesn't tell me either. It's the old 2x45A power supplies model with a single small fan in the back and no fan tray on the bottom. It was made in early June of '95. Most of the cards are '95 vintage including the NMC and NetServer. Is there anything I should beware of in bringing this up to modern code? It seems to be doing OK with 16M in both cards, but I noticed the NMC is missing a daughterboard that my newer cards have. Anyone know what it is? Is there an official hardware compat. guide anywhere? Thanks, C ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com

> Direct dial to AOL doesn't use TCP/IP. Now I'm not in the US, I don't use AOL, and I've never seen their setup, but that sounds a bit odd to me. I always thought ANS provided much (all?) of AOL's dialup? ANS use TC gear, with NETServers, and I've often heard David speaking of how the routing at their POP's works. Surely they use TCP/IP in one way or another? What else do they do - rlogin to a *nix box and do some jiggery-pokery there? Confused? Cheers, Bob.

we have occasional occurences where a modem card will go yellow and will not respond to software/hardware resets in tcm. of course when this happens it is when nobody is at the office and you are checking tcm remotely. what is the best way to busy out the modem when you can't physically pull out the card? also, we have very isolated incidents where you will get a fast busy when a ton of lines are free, we call the telco and they are able to tell us that one channel in one pri trunk is "bad" the last time it happened it was a double up card and they said it was sending a "45" error code. what can be done to avoid this causing fast busy's? matthew

Thus spake G. Turner >Oops. I meant NFAS. I didn't see that HiPer DSP supports NFAS. If it >does, can you point out the chapter on the CD that explains it? I don't believe it does (at least yet), along with MPIP and several other features that make the ARC's useless for us at this point. :/ -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

FAQ ? what faq ? ;-) RvB -----Original Message----- From: Allen Marsalis [SMTP:am@shreve.net] Sent: mardi, 3. mars 1998 05:19 To: usr-tc@lists.xmission.com Subject: Re: (usr-tc) pmmon settings for hiper cards At 08:11 PM 3/2/98 -0500, Jeff Mcadams wrote: >Thus spake matthew >> does someone have the configuration handy to define a chassis with 48 quad >>cards and 2 hiper dsp cards for pmmon? > >Wow! How do you fit 48 quad cards in a single USR chassis?! ;) >-- Aw that's easy with a good can opener, some duct tape, and a soldering iron.. Should be in the faq... am - 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.

>If it's anything like the WebRamp units here (which are made in the USA >anyway), then the 2nd & 3rd channels are independent - there is no >bonding. So much so, that each of the 3 channels can be dialled into >different ISP's if you so desire. > >Cheers, > >Bob. I think you're refering to the WebRamp M3 (analog). Our customer is using a WebRamp IP which is an 8 port hub / ISDN router. Thanks Brain for answering my question regarding MP setup on the TC side of things. -Jason

usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox) writes: > It has been my experience that calls will connect at a standard rate, > then "upshift" to x2. Unfortunately, that can't happen. During the course of a session a retrain can cause a modem to "fall out" of x2 into V.34, but there will never be a shift into x2 if it was not using x2 during the initial training of the call. So once you are in V.34 (whether due to falling out of x2 or never achieving x2 initially) you'll max out at the V.34 max of 33.6 - line permitting - for the lifetime of that connection. > But the > bottom line appears to be you should not replace the NMC card until you > are ready to replace it with a working one complete with the x2 feature > enable code. Or you don't mind the few seconds it will take to re-enable it once it is running again as a small "window of opportunity". If you're doing replacements during some sort of maintenance window you can just replace the card, download code if necessary and then re-activate the feature key before calling it a night. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

jeff.binkley@asacomp.com (Jeff Binkley) writes: > Three questions then. First, if I upgrade an NMC to 16 meg flash (i.e. > the doubleup program) will the X2 feature be lost ? I believe so, since the flash replaces all of the "brains" of the NMC both code and data so it will no longer have the previously configured feature information stored in flash. > Second, if I save > the configuration to disk and then reload an NMC, can a lost X2 be > recovered via the backup. That I'm not sure - I guess it depends on how you save the information, and I'm not familiar enough with TCM in this regard. (I seem to recall it just dumps the entire MIB tree, in which case while it could get the status of features, there's no way to recover the feature enable key to use later when restoring) > Lastly, if the NMC has the X2 key enabled and > HDMs are installed (i.e. the doubleup program again) will the HDMs also > pickup the X2 key ? It's my understanding that HDMs don't need an x2 key or care about the NMC x2 "feature", at least I thought I heard that from someone locally. > I think yu can see where this is all heading. > Maybe there's some info on performing the doubleup process on a TC rack > that is available for review ? Well, for our part, we just yank the NMC, replace it with a new one (rather than doing the memory swap in the field we just cycle cards back to a depo - also avoids having to use a TTY based SDL to the NMC in the field), install the HDMs and some ancillary management hardware changes for the upgrade, rewire a bunch of stuff, and then perform a "standard" code download to ensure everything has production code and configuration. The x2 feature is then re-enabled on all NMCs. So we have a small window of time during the process when the x2 feature may be deactivated but it's a relatively minor issue compared to the rest of the work. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Charles Sprickman <spork@inch.com> writes: > I just confirmed utter and total death of an NMC. A new one should be > here tomorrow they tell me... Is is standard/acceptable practice to just > swap flash memory between the cards rather than setting it up from > scratch? Other than the flash possibly being the problem, I don't see > anything wrong with it. Anyone? Otherwise I have to dig up those darned > X2 keys, which I thought wouldn't even work on different serial # cards... I guess it depends what "utter and total death" means in this case, and whether or not it might have affected your memory. I don't really see a problem swapping it unless it's dead too. > Also, as a "gift" we were given an old chassis. It doesn't have a model > number on it, and the TCM inventory function doesn't tell me either. It's > the old 2x45A power supplies model with a single small fan in the back and > no fan tray on the bottom. It was made in early June of '95. Most of the > cards are '95 vintage including the NMC and NetServer. Is there anything > I should beware of in bringing this up to modern code? Shouldn't be. You might want to verify that your NMC is a 486 based card rather than 386, although if you're already running the 16MB NMC code then I think that answers the question (since I think that's 486 only). It's not a killer if it's 386, but it will be a tad slower and may not run the HDM compatible code base. The other risk is that your NETServer is missing some of the later engineering changes that helped stabilize the hardware as the newer software stressed it more. But that's one of those "if it isn't broke, don't change it" issues - if there's a problem you'll see reboots and know to get it checked out. > I should beware of in bringing this up to modern code? It seems to be > doing OK with 16M in both cards, but I noticed the NMC is missing a > daughterboard that my newer cards have. That's a clock daughterboard and only necessary in the newer "clocked" chassis (with the integrated fan trans) where the NMC can act as a backup clock source to the chassis. > Is there > an official hardware compat. guide anywhere? Not sure, but the answer is everything should be compatible. As far as I know any card that you purchased since at least late 94 can still be used in the most recent chassis (well, you're supposed to use an NMC with the daughterboard in the new hub) and all of the latest cards continue to work in the older chassis. I believe the older chassis has a lower limitation on total timeslots available on the midplane and thus the maximum density of the chassis is less, but that's only any issue if you don't use quads. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

what i don't understand is when you install the double up kit with the nmc memory and flash upgrade you don't need to do anything to reenable the x2. i took the flash and memory out of an older nmc that had x2 enabled, put the chips in a new nmc that came with one of the new bundles (chassis/2 double up cards/nmc and arc card) and the x2 didn't work. so the x2 code must be stored in the card but not the flash or the memory? matthew At 06:43 PM 3/5/98 -0500, you wrote: >jeff.binkley@asacomp.com (Jeff Binkley) writes: > >> Three questions then. First, if I upgrade an NMC to 16 meg flash (i.e. >> the doubleup program) will the X2 feature be lost ? > >I believe so, since the flash replaces all of the "brains" of the NMC >both code and data so it will no longer have the previously configured >feature information stored in flash. > >> Second, if I save >> the configuration to disk and then reload an NMC, can a lost X2 be >> recovered via the backup. > >That I'm not sure - I guess it depends on how you save the >information, and I'm not familiar enough with TCM in this regard. (I >seem to recall it just dumps the entire MIB tree, in which case while >it could get the status of features, there's no way to recover the >feature enable key to use later when restoring) > >> Lastly, if the NMC has the X2 key enabled and >> HDMs are installed (i.e. the doubleup program again) will the HDMs also >> pickup the X2 key ? > >It's my understanding that HDMs don't need an x2 key or care about the >NMC x2 "feature", at least I thought I heard that from someone >locally. > >> I think yu can see where this is all heading. >> Maybe there's some info on performing the doubleup process on a TC rack >> that is available for review ? > >Well, for our part, we just yank the NMC, replace it with a new one >(rather than doing the memory swap in the field we just cycle cards >back to a depo - also avoids having to use a TTY based SDL to the NMC >in the field), install the HDMs and some ancillary management hardware >changes for the upgrade, rewire a bunch of stuff, and then perform a >"standard" code download to ensure everything has production code and >configuration. The x2 feature is then re-enabled on all NMCs. > >So we have a small window of time during the process when the x2 >feature may be deactivated but it's a relatively minor issue compared >to the rest of the work. > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > 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. >

On Fri, 6 Mar 1998, Richard Bosire wrote: > Tatai .,, > > You remember you recommended this to me ..??..**^&$%$%. > Read the email that I sent, If you are using our product only - you can set PPTP value to 3. The value 3 is OK only for us because, we autodetect, The RFC are also defined in the email. So if you are using Radius with our product and with someelse product set PPTP value to 9. krish > Now this is what i call chaos mania > > bosire > > Dave Mitton wrote: > > > Dear USR, > > > > This value is not RFC compliant. > > > > Framed-Protocol = 3 is defined as ARAP (Appletalk Remote Access Protocol) > > > > Please pick a different value. > > > > Dave. > > > > At 09:20 PM 2/24/98 -0600, Tatai SV Krishnan wrote: > > >On Wed, 25 Feb 1998, Richard Bosire wrote: > > > > > >> Hi Guys , > > >> > > >> Does anyone know which version of Radius ptpp and what version of the > > >> netserver code this will > > >> with .. > > >> > > >> TIA > > >> > > >> cheers > > >> > > >> bosire > > > > > > > > >Every Radius will support PPTP, see in the dictionary file under the > > >framed-protocol section you will see something like this > > > > > >VALUE Framed-Protocol PPP 1 > > > > > >now go ahead and add a new item there > > > > > >VALUE Framed-Protocol PPTP 3 > > > > > >and when you add users you should say Framed-Protocol is PPTP > > > > > >krish > > > > > > > --------------------------------------------------------------- > > David Mitton 978-670-8888 Main > > Consulting Engineer 978-916-4570 Direct > > Bay Networks, Remote Access Srv Div 978-916-4789 FAX > > Billerica, MA 01821 dmitton@baynetworks.com > > > > - > > 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. > > > > -- > > \\|// - ? > (o o) > +==================================oOOo=(_)=oOOo========+ > | Richard Bosire rbosire@africaonline.co.ke | > | AfricaOnline Ltd | > | union towers, 2nd floor | > | tel: 254-2-243775 | > | .oooO | > | http://www.africaonline.co.ke ( ) Oooo. | > +===================================\ (==( )==========+ > \_) ) / > (_/ > >

On Thu, 5 Mar 1998, I. Dwayne Koonce wrote: > Okay, I finally have my RADIUS server properly logging Vendor-Specific > RADIUS attributes, but now it appears that many of the attributes we're > interested in aren't being sent. Of particular interest is connection > performance data, such as Initial-Rx-Link-Data-Rate (0xBF2D), > Final-Rx-Link-Data-Rate (0xBF2C), Initial-Tx-Link-Data-Rate (0x006A), > Final-Tx-Link-Data-Rate (0x006B), etc., but these do not appear to be sent > by default. > > USR tech support said I needed to use their Total Control SNMP software to > set the Configure->Programmed Settings->Logging Group->Log Group Selection > to "all" on the NMC (which seemed odd, since the accouting info I'm > currently getting is coming from the NetServer). I did so, and pointed > the NMC at my RADIUS server--no luck. yes you want to turn the appropriate logging groups on in the NMC, The logging groups are well documented in the nmc documentaton as far as which group logs what. > > Another call to tech support, and they tell me I have to go back into > Total Control Manager and manually enable log traps for each of a dozen > events *on each individual modem*. > yes, i think you can set under "traps", either to trap, to log, or both. You will need to do this depending on which data you would like. > We configured the first modem, and dialed into it--nada. None of the info > that the NMC is supposed to be able to send made it to our radiusd. So, > does anyone have any idea what's necessary to log this? (And is there any > way to do it w/o using TCM [blech] to change a dozen settings per > individual modem?) > Be sure to set up the nmc ip as a client on your RADIUS software. Also make sure your running accounting not just authentication. Make sure the secret is correct on the nmc. > ____________________________________________________________________________ > I. Dwayne Koonce E-mail: dwayne@txcyber.com > ____________________________________________________________________________ > "It's dangerous to be right when the government is wrong." --Voltaire > > > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Dunno what you think of Jack Rickard but you might want to take a look at this related article on 56K issues also.... I just loved the empirical results of his 56K dialup tests.. x2 was a good 10kbps faster on average than kflex across 89 national isps.. Can only imagine what MZ thinks of Jack and his methods.. http://www.boardwatch.com/mag/98/mar/bwm24.html I also heard MPIP for HiPer is shipping in the next release scheduled for mid to late March. Can't hardly wait.. allen At 01:15 PM 3/5/98 -1000, Richard Gamberg wrote: >Strongly suggest you listen to the just-posted Brian McWilliams PCWorld >NewsRadio. Lead story is on v.90 problems, and other 3Com issues. > >3Com spokesperson Bert Murray indicates that 3Com is going to be modifying >its policy for ISPs and make updated x2 code available to them without them >having to pay thousands of dollars for service contracts. > >Go to http://www.pcworld.com/news/newsradio/index.html and listen for >yourself. > >In my opinion, McWilliams has been covering v.90/56k *very* well, and in a >fair and unbiased fashion. The bias, if any, comes from sound bites, and he >is doing an admirable job to present all sides. > >Aloha, >Richard >for the biased view of 56k, visit my site at >http://pages.prodigy.net/bbhi/r-rnut-x2.htm > _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

matthew <matthew@the-spa.com> writes: > what i don't understand is when you install the double up kit with the nmc > memory and flash upgrade you don't need to do anything to reenable the x2. > > i took the flash and memory out of an older nmc that had x2 enabled, put > the chips in a new nmc that came with one of the new bundles (chassis/2 > double up cards/nmc and arc card) and the x2 didn't work. Hmm, your second paragraph seems to contradict your first. If you don't need to do anything to re-enable x2 then x2 would work, but since it didn't you must need to do something :-) We don't swap flash chips and always reissue the feature key to a new NMC, so I'm not really sure whether it should work or not. But presuming it doesn't, my guess would be that somehow the information stored in the NMC is specific to that card (much as the key itself is with the serial number). I guess in theory they might have stored the information in some CMOS bits rather than flash, but my guess is it's in flash somewhere but just not applicable to the new card. Depending on how paranoid the NMC folks were in terms of people circumventing the feature, this could be considered a protection. After all, if the flash just knew if the feature was enabled or not, it would be relatively simple to make duplicates of the flash contents of an enabled card and then just stick it into new cards without having a feature key. Our method for "doubling up" a chassis is to ship out new NMC cards with all the flash and code ready and just swap on site, so perhaps those more familiar with the double-up kits as sold by 3Com could add some comments on whether they have to re-issue feature keys. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

> I have a customer with a WebRamp ISDN router who would like to use both > B channels on their BRI. My question is do I have to configure anything > in the TC, Radius, etc to make this happen? Or will the 2 B channels > "bond" automagically when the WebRamp dials in? I dug through the > documentation CD but it didn't shed much light on the subject. If it's anything like the WebRamp units here (which are made in the USA anyway), then the 2nd & 3rd channels are independent - there is no bonding. So much so, that each of the 3 channels can be dialled into different ISP's if you so desire. Cheers, Bob.

Tatai .,, You remember you recommended this to me ..??..**^&$%$%. Now this is what i call chaos mania bosire Dave Mitton wrote: > Dear USR, > > This value is not RFC compliant. > > Framed-Protocol = 3 is defined as ARAP (Appletalk Remote Access Protocol) > > Please pick a different value. > > Dave. > > At 09:20 PM 2/24/98 -0600, Tatai SV Krishnan wrote: > >On Wed, 25 Feb 1998, Richard Bosire wrote: > > > >> Hi Guys , > >> > >> Does anyone know which version of Radius ptpp and what version of the > >> netserver code this will > >> with .. > >> > >> TIA > >> > >> cheers > >> > >> bosire > > > > > >Every Radius will support PPTP, see in the dictionary file under the > >framed-protocol section you will see something like this > > > >VALUE Framed-Protocol PPP 1 > > > >now go ahead and add a new item there > > > >VALUE Framed-Protocol PPTP 3 > > > >and when you add users you should say Framed-Protocol is PPTP > > > >krish > > > > --------------------------------------------------------------- > David Mitton 978-670-8888 Main > Consulting Engineer 978-916-4570 Direct > Bay Networks, Remote Access Srv Div 978-916-4789 FAX > Billerica, MA 01821 dmitton@baynetworks.com > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

I have been unable to find if the Total Control Enterprise Hubs are Year2000 compliant. I spent most of the day yesterday trying to search throughout the entire 3Com family of websites without results. Does anyone know if these things are y2k compliant? Specifically, 386 PRIcards, Quad modem cards, 486 NetServer cards, and NMC cards? Jas, Interpath Communications Data Network Technician Jas.Eckard@interpath.net

This is not an "offical" 3Com answer, but our parent company, ACSI hired a Y2K consulting firm and as reported by them, all of our USR equipment (which ranges from MP16's to HyperARC's) IS Y2K compliant. Steve =========================================================================== S t e v e n R. S h e p h e r d =========================================================================== CyberGate Internet Technologies | ICQ: 1412432 An ACSI Company | NetDudeFL @ EFnet Field Engineer | E-Mail: steven@gate.net (800)NET-GATE/(954)429-8065 | 9542595004@alphapage.airtouch.com ============================================================================ On Fri, 6 Mar 1998, Jas - Net Tech wrote: > Date: Fri, 6 Mar 1998 09:29:32 -0500 (EST) > From: Jas - Net Tech <jaeckard@Interpath.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Y2K compliance? > > I have been unable to find if the Total Control Enterprise Hubs are > Year2000 compliant. I spent most of the day yesterday trying to search > throughout the entire 3Com family of websites without results. > > Does anyone know if these things are y2k compliant? Specifically, 386 > PRIcards, Quad modem cards, 486 NetServer cards, and NMC cards? > > > Jas, Interpath Communications Data Network Technician > Jas.Eckard@interpath.net > > - > 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. >

Being besieged by performance complaits by our customers, I have decided to try using 2 netservers per rack. 24 modems each. We only run X2 connections over T1 lines. No PRI. Any tried this? or needed to? The customers connect at fine rates, just don't move data at acceptable rates.

If anyone finds an "official" statement of Y2K compliance, please post a URL! many thanks Pris Sears (sears@vt.edu)

We have the SAME problem as STeven B. had. We alson noticed that slowness problem only happened on the DOWNLOAD not on the UPLOAD FILE (by FTP). And the same computer , if move to a different EXCHANGE number, it can work fine. I did that test myself. So I wonder if this has to do with Inter EXCHANGE setup. But how can I present the data to pursade the telco to look into it ? What's best was, I opened a ticket to this matter. Email more than 10 evidence to the support. Assigned case # 39140. Guess what ? You know better. Meng tsaim@mft.com, ISP Stephen W. Buza wrote: > Most of my users report download speeds > of under 1.5kbps. The traffic on my backbone > never exceeds a third of the bandwidth available > even at peak times. If the initial connection was > poor, but the sessions straightened out eventually, > that wouldn't be a problem. > > I have several customers who report 300bps > download times with 28.8 modems. And NO it > is not because they are connecting to slow sites. > > Steve > > -----Original Message----- > From: Mark R. Lindsey <mark@vielle.datasys.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, March 04, 1998 8:08 AM > Subject: Re: (usr-tc) Performance > > >: I have problems getting decent speeds out > >: of v.34 modems. Nearly all of the connections > >: to my rack are at 26,400 or less and some > >: customers never can achieve 19,200. > > > >The intial connection to a modem is a hairsbreadth from meaningless > >(which is better, a 56k connection that dies after 3 seconds, or a 26.4k > >connection that lasts a week?). > > > >Are you monitoring the transmit link rates? > > > > > >- > > 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. > > > > - > 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.

We have a couple of racks running with 24-48 modems each and don't have this exact issue. Both are on T1's, not PRI. One is the older style chassis and we have one newer one with the fan tray built in. Neither gives us much of a problem but the newer one has drawn some comments about being slow when fairly busy even though only 24 modems are lit now, 48 next week. Some say they get a better transfer rate when they disable x2 (during the evening hours). x2 runs great when not too busy according to a few. I have had no complaints at all regarding the older chassis with 48 lit in it. We recently upgraded the software in the older one (2 weeks ago) and it was not pretty. It did finally take but it doesn't give me a warm fuzzy feeling to go through that on the newer chassis sitting in a closet in a remote town. The software in the newer one was current as of last December. At 10:19 AM 3/6/98 -0800, you wrote: >Being besieged by performance complaits by our customers, >I have decided to try using 2 netservers per rack. 24 modems >each. We only run X2 connections over T1 lines. No PRI. Any >tried this? or needed to? The customers connect at fine rates, >just don't move data at acceptable rates. > > >- > 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. > > Thanks, Greg Coffey, CoffeyNet ** Casper- Douglas USR x2 56k access ** 142 S. Center St. Wheatland, Pinedale, Lander, Lusk Casper, WY 82601 Douglas & Rawlins (307) 234-5443 http://www.coffey.com Open 8-6 M-F / 10-2 Saturday

What do the Netserver and HiPer ARC do that needs to know the time and date? (Sorry, if this is a dumb question.) Mark

Thus spake Mark R. Lindsey >What do the Netserver and HiPer ARC do that needs to know the time and date? >(Sorry, if this is a dumb question.) Not sure about the Hiper ARC at this point (though the need will definitely arise in the future), but the netserver has to have the exact time for MPIP. There might be other reasons, but I do know for sure that the time is needed for MPIP on the netservers, and I assume it will be needed when (hopefully soon) the ARC supports MPIP. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Well, things like the start time, uptime, .... etc when you are looking at the interfaces. Not sure, but that time date, might also be the time that radius uses when generating accounting records. Ken :) At 12:03 PM 3/6/98 -0500, you wrote: > >What do the Netserver and HiPer ARC do that needs to know the time and date? >(Sorry, if this is a dumb question.) > > >Mark > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

Jeff Mcadams was heard to say: >Thus spake Mark R. Lindsey >>What do the Netserver and HiPer ARC do that needs to know the time and date? >>(Sorry, if this is a dumb question.) > >Not sure about the Hiper ARC at this point (though the need will >definitely arise in the future), but the netserver has to have the exact >time for MPIP. There might be other reasons, but I do know for sure >that the time is needed for MPIP on the netservers, and I assume it will >be needed when (hopefully soon) the ARC supports MPIP. They need it for syslog reporting (maybe) and RADIUS event times. Other than that, all they need to do is count a number of seconds... As I understand it, they are both "unix" based -- i.e. 32bit gmt time value good 'til sometime in 2032. The NMC will need basically the same (log info, and timing) --Ricky

Thus spake Ricky Beam >They need it for syslog reporting (maybe) and RADIUS event times. Other >than that, all they need to do is count a number of seconds... >As I understand it, they are both "unix" based -- i.e. 32bit gmt time >value good 'til sometime in 2032. <nit> Actually, I believe its early 2038 (Feb. or Mar.?) </nit> -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff Mcadams was heard to say: >Thus spake Ricky Beam >>They need it for syslog reporting (maybe) and RADIUS event times. Other >>than that, all they need to do is count a number of seconds... > >>As I understand it, they are both "unix" based -- i.e. 32bit gmt time >>value good 'til sometime in 2032. > ><nit> >Actually, I believe its early 2038 (Feb. or Mar.?) ></nit> [I knew someone would want the exact time...] Mon Jan 18 22:14:07 2038 --Ricky

Here is the URL for the 3Com policy on year 2000 compliance: http://www.3com.com/products/yr2000.html

We are using the TC hubs to offer cable modem access with telco-return in several systems. The CARC as far as I can tell is a fairly new product which started out as the HARC. There is no mention of the CARC on the Total Service website. This prompts me to ask the following: 1-Is the firmware exactly the same for the HARC and CARC? 2-Is it known that the latest TCS release (3.0.2) known to be compatible for hubs with a CARC? 3-We're also using the brand new QAM NICs in conjuction with the CARC. Does anyone know of any compatibilities with this setup in regards to my above questions? Thanks, Eric |0| Eric J. Lorenzo MediaCity World/ISPchannel |0| |0| 650.237.1465 - voice 650.301.2465 - pager |0| |0| Lorenzo@MediaCity.com http://www.ISPchannel.com |0|

At 03:17 PM 3/3/98 , you wrote: > >Folks, > >I have recently purchased upgrades from 3com with the part code >80-2149-00 called "NMC / Netserver DRAM/FlashROM upgrade for 386 and >486 only". > >Question. How important is it to upgrade the 4 meg flash ROM >to 8 meg on the Netserver? Will there be a need in the future >for the 8 meg flash? We received a whole package of those things. It turns out that to allow SNMP control of our new HiPer DSP NACs (which have 24 onboard modems allowing you to utilize a PRI with just one slot), the NMC has to have the new flash and 16Mb of RAM. What other applications you might need the upgrades, our sales guy didn't go into. Eric |0| Eric J. Lorenzo MediaCity World/ISPchannel |0| |0| 650.237.1465 - voice 650.301.2465 - pager |0| |0| Lorenzo@MediaCity.com http://www.ISPchannel.com |0|

mt said once upon a time: >We finally nailed down the problem and resolved it by >using TCM -> program setting -> Line interface option > >Change the transmitter Lever from default 11 to 14. > >The slowness problem went away. I will continue >monitor the situtation until next week. Does anyone know what happened to this setting on the HDMs? Doesn't it matter anymore?

Thanks to Mike McFarland , 3COM USR Engineer. I was on the phone with he for 3 hours today doing the trouble shooting. We finally nailed down the problem and resolved it by using TCM -> program setting -> Line interface option Change the transmitter Lever from default 11 to 14. The slowness problem went away. I will continue monitor the situtation until next week. Thanks again, Mr. McFarland. Sincerely yours Meng Tsai tsaim@mft.com Stephen W. Buza wrote: > Most of my users report download speeds > of under 1.5kbps. The traffic on my backbone > never exceeds a third of the bandwidth available > even at peak times. If the initial connection was > poor, but the sessions straightened out eventually, > that wouldn't be a problem. > > I have several customers who report 300bps > download times with 28.8 modems. And NO it > is not because they are connecting to slow sites. > > Steve > > -----Original Message----- > From: Mark R. Lindsey <mark@vielle.datasys.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, March 04, 1998 8:08 AM > Subject: Re: (usr-tc) Performance > > >: I have problems getting decent speeds out > >: of v.34 modems. Nearly all of the connections > >: to my rack are at 26,400 or less and some > >: customers never can achieve 19,200. > > > >The intial connection to a modem is a hairsbreadth from meaningless > >(which is better, a 56k connection that dies after 3 seconds, or a 26.4k > >connection that lasts a week?). > > > >Are you monitoring the transmit link rates? > > > > > >- > > 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. > > > > - > 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.

Charles Sprickman said once upon a time: > >What is the AS51 card? That output looks very Cisco-like... I thought I >saw something like that at the NYC ANS BIGDial once... USR and Cisco had an affair during USR's failed marriage with Livingston.

On Fri, 6 Mar 1998, Ricky Beam wrote: > They need it for syslog reporting (maybe) and RADIUS event times. Other > than that, all they need to do is count a number of seconds... The Radius server and Syslog server time stamp the entries themselves. They don't depend on any time from the NAS. Livingston equipment doesn't even have a clock, and entries are properly time stamped. Brian

Does anyone know what the default IP address the ethernet interface of a NMC is given? ie: what it ships from the factory with... Thanks, Charles ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com

>Original message from Peggy Malecki: >> >>Here is the URL for the 3Com policy on year 2000 compliance: >> >>http://www.3com.com/products/yr2000.html > >Yes, I've _seen_ this already. I think our equipment was bought _before_ Feb 1, 1997 from >_U_S_Robotics_. > >I do not want to assume this covers it. > > The products you referred to in your other e-mail, <cut in below> > >Does anyone know if these things are y2k compliant? Specifically, 386 PRIcards, Quad modem >cards, 486 NetServer cards, and NMC cards? > are still in production and can be obtained today. The Feb-1-97 date is only "magical" for products that are OBSOLETED by that date. And, since the merger last June, everything under the U.S. Robotics name is now 3Com Corporation, so the statement in the above URL is still true. Kurtiss Johnson Product Manager 3Com Corporation kurtiss_johnson@mw.3com.com

This isn't that strange of a problem, it's just a bitch to get it fixed... If you are seeing the slowness *only from certain exchanges* I think you can rule out either end of the connection and start looking at the telco as a possibility. We've had (and still have to a lesser extent) problems with certain COs in Brooklyn. Our CLEC, ACC telecom, has direct T1 connections to some of these COs, and when the technician forced the call to go out an LD path, a user of ours with *horrible* performance got his first 53K X2 connection. Same if he takes his laptop to work in Manhattan, X2 all the time... They are still trying to find the cause. They've checked all they could on their end and are waiting on Bell Atlantic to do some troubleshooting on theirs. My guess is a misconfigured repeater or some fried hardware somewhere in between... Good luck, Charles ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com On Fri, 6 Mar 1998, mt wrote: > Date: Fri, 06 Mar 1998 11:27:17 -0500 > From: mt <tsaim@mft.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Cc: Michael Folorunso <Michael_Folorunso@3com.com>, > "mike_McFarland@3com.com" <mike_McFarland@3com.com>, > "Jeffrey_Burton@3com.com" <Jeffrey_Burton@3com.com> > Subject: Re: (usr-tc) Performance > > We have the SAME problem as STeven B. had. > > We alson noticed that slowness problem only happened > on the DOWNLOAD not on the UPLOAD FILE (by FTP). > > And the same computer , if move to a different EXCHANGE > number, it can work fine. I did that test myself. > > So I wonder if this has to do with Inter EXCHANGE > setup. But how can I present the data to pursade the > telco to look into it ? > > What's best was, I opened a ticket to this matter. Email more than > 10 evidence to the support. Assigned case # 39140. Guess what ? > You know better. > > Meng > tsaim@mft.com, ISP > > Stephen W. Buza wrote: > > > Most of my users report download speeds > > of under 1.5kbps. The traffic on my backbone > > never exceeds a third of the bandwidth available > > even at peak times. If the initial connection was > > poor, but the sessions straightened out eventually, > > that wouldn't be a problem. > > > > I have several customers who report 300bps > > download times with 28.8 modems. And NO it > > is not because they are connecting to slow sites. > > > > Steve > > > > -----Original Message----- > > From: Mark R. Lindsey <mark@vielle.datasys.net> > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > Date: Wednesday, March 04, 1998 8:08 AM > > Subject: Re: (usr-tc) Performance > > > > >: I have problems getting decent speeds out > > >: of v.34 modems. Nearly all of the connections > > >: to my rack are at 26,400 or less and some > > >: customers never can achieve 19,200. > > > > > >The intial connection to a modem is a hairsbreadth from meaningless > > >(which is better, a 56k connection that dies after 3 seconds, or a 26.4k > > >connection that lasts a week?). > > > > > >Are you monitoring the transmit link rates? > > > > > > > > >- > > > 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. > > > > > > > - > > 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. > > > > > - > 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. >

--IMA.Boundary.854622988 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part > >What do the Netserver and HiPer ARC do that needs to know the time and date? (Sorry, if this is >a dumb question.) > > >Mark > It's needed for VTP, our layer-3 tunneling protocol that provides protection against replay attacks by using the time stamping and the delta from tunnel origination time to protect the tunnel authentication keys. And since MPIP uses a variant of VTP, it's also necessary there (although we're using VTP in this application because of performance rather than for security concerns). It's not necessary for the RADIUS or SYSLOG messages, since they're handled by the destination server, not the NAS. Kurtiss Johnson Product Manager 3Com Corporation kurtiss_johnson@mw.3com.com - 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. --IMA.Boundary.854622988 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 5002D960; Fri, 6 Mar 98 11:08:38 -0600 Received: from lists.xmission.com by usr.com (8.8.5/3.1.090690-US Robotics) id KAA02327; Fri, 6 Mar 1998 10:49:03 -0600 (CST) Received: from domo by lists.xmission.com with local (Exim 1.73 #4) id 0yB0WU-0000XX-00; Fri, 6 Mar 1998 10:03:02 -0700 Received: from mail.xmission.com [198.60.22.22] by lists.xmission.com with smtp (Exim 1.73 #4) id 0yB0WR-0000X4-00; Fri, 6 Mar 1998 10:02:59 -0700 Received: from vielle.datasys.net [204.252.164.2] (mark) by mail.xmission.com with smtp (Exim 1.73 #4) id 0yB0WP-00033l-00; Fri, 6 Mar 1998 10:02:57 -0700 Received: (from mark@localhost) by vielle.datasys.net (8.6.11/8.6.9.MRL) id MAA28694 for usr-tc@xmission.com; Fri, 6 Mar 1998 12:03:42 -0500 Message-Id: <199803061703.MAA28694@vielle.datasys.net> X-Pgp-Fingerprint: DB 6B 9E 9F B5 F2 9B 6D A0 BE D8 10 6B 22 8F 06 X-Mailer: Mail User's Shell (7.2.6 1995-03-03) Sender: owner-usr-tc@lists.xmission.com Precedence: bulk Reply-To: usr-tc@lists.xmission.com --IMA.Boundary.854622988--

Original message from Peggy Malecki: > >Here is the URL for the 3Com policy on year 2000 compliance: > >http://www.3com.com/products/yr2000.html Yes, I've _seen_ this already. I think our equipment was bought _before_ Feb 1, 1997 from _U_S_Robotics_. I do not want to assume this covers it. Jas, Interpath Communications Data Network Technician Jas.Eckard@interpath.net

On Fri, 6 Mar 1998, David Bolen wrote: > The AS51 is a Cisco 2511 on a TC form factor card. The NIC provides > the fanout to the serial ports using a 50-pin dense connector similar > to (but not identical, particularly in form factor) the connector on > actual 2511s, one connector per 8 serial ports. If Cisco went to all the work of creating a card to fit into the USR rack, why didn't they just use the packet bus? Brian

What is the AS51 card? That output looks very Cisco-like... I thought I saw something like that at the NYC ANS BIGDial once... ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com On Fri, 4 Jan 1980, CyberPort Montana wrote: > Date: Fri, 04 Jan 1980 13:55:56 -0700 > From: CyberPort Montana <netboss@cyberport.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Help with AS51 card > > Thanks to all that responded to my plea for help with the PRI/T1 card. > > I have a new (actually used, but new to me) TC chassis populated with 12 > Analog/Digital Quad modems, 2 45 amp PSs, NMC and three AS51 server cards. > > One of the AS51 cards seems not to communicate through the Ethernet port on > the card. I have "cleaned" the card's configuration through the RS-232 > terminal port and set the basic IP stuff (see the "show int e0" output below). > > The "show int e0" output was taken shortly after clearing the counters. If > I interpret it correctly, there are packets coming and going through the > interface. > > TC3-3#sho int e0 > Ethernet0 is up, line protocol is down > Hardware is Lance, address is 00c0.4901.9541 (bia 00c0.4901.9541) > Internet address is 208.136.100.88 255.255.255.0 > MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 218/255, load 1/255 > Encapsulation ARPA, loopback not set, keepalive set (10 sec) > ARP type: ARPA, ARP Timeout 4:00:00 > Last input 0:00:03, output 0:00:01, output hang never > Last clearing of "show interface" counters 0:02:02 > Output queue 0/40, 0 drops; input queue 0/75, 0 drops > 5 minute input rate 0 bits/sec, 0 packets/sec > 5 minute output rate 0 bits/sec, 0 packets/sec > 48 packets input, 7484 bytes, 0 no buffer > Received 40 broadcasts, 0 runts, 0 giants > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort > 0 input packets with dribble condition detected > 18 packets output, 1316 bytes, 0 underruns > 18 output errors, 0 collisions, 0 interface resets, 0 restarts > 0 output buffer failures, 0 output buffers swapped out > TC3-3# > > The interface seems to be cycling between up and down (see the console > output below). These cycles seems to be occurring every minute or so, with > the interface remaining up for only 10 seconds or so. > > When I try to ping this interface from another machine, an interesting > thing occurs. If I examine the ARP entry for the IP address of the AS51 > before doing a ping, there is no entry. I then do a ping and even though > the ping is unsuccessful, immediately after the ping is aborted there is an > ARP entry for the AS51. A listing of the output from this procedure follows; > > cpmt2# arp 208.136.100.88 > 208.136.100.88 (208.136.100.88) -- no entry > cpmt2# ping 208.136.100.88 > PING 208.136.100.88 (208.136.100.88): 56 data bytes > ^C > --- 208.136.100.88 ping statistics --- > 54 packets transmitted, 0 packets received, 100% packet loss > cpmt2# arp 208.136.100.88 > ? (208.136.100.88) at 0:c0:49:1:95:41 > > I've tried all the obvious things, changing cables, switching ports on the > Ethernet hub, switching slots in the TC chassis, etc. There are two other > AS51 cards in this chassis that work fine with the same configuration > (different IP addresses of course). I've even tried a different IP > address with the malfunctioning card. > > Any ideas will be appreciated. > > - > 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. >

-----Original Message----- >Dunno what you think of Jack Rickard but you might want to take a look >at this related article on 56K issues also.... I just loved the >empirical results of his 56K dialup tests.. x2 was a good 10kbps >faster on average than kflex across 89 national isps.. Can only imagine >what MZ thinks of Jack and his methods.. > >http://www.boardwatch.com/mag/98/mar/bwm24.html > >I also heard MPIP for HiPer is shipping in the next release scheduled for >mid to late March. Can't hardly wait.. > >allen I found the article to be very interesting. Also think his dialup tests were severely flawed. I've put a link to the article and added why the tests are worthless on my page at http://pages.prodigy.net/bbhi/r-rnut-x2.htm Thanks for the info. Aloha, Richard

Charles Sprickman <spork@inch.com> writes: > What is the AS51 card? That output looks very Cisco-like... I thought I > saw something like that at the NYC ANS BIGDial once... Peekin' at our equipment, eh? Guess that's what we get for putting big labels on our cabinets :-) The AS51 is a Cisco 2511 on a TC form factor card. The NIC provides the fanout to the serial ports using a 50-pin dense connector similar to (but not identical, particularly in form factor) the connector on actual 2511s, one connector per 8 serial ports. Other connectivity (standard Cisco console/aux/ethernet and a single WAN) ports are actually on the NAC. These were used in the Cisco 5100 product line, which was basically a stock 48-port TC hub with 3 AS51s rather than a NETServer. Each AS51 had two special-purpose fanout cables from a port on the AS51 to two quad modem cards. The cards tended to be inserted in the chassis so each AS51 was in between 4 quad cards for efficiency of cabling. I think USR also sold this as an option to the NETServer for a short period of time. Then there was a bit of a falling out between Cisco and USR, and when Cisco when to their 5200 (I think I have the product numbers right) they went another path. For our second phase design, we used AS51 cards as onboard OOB terminal servers rather than wasting rack space on separate Cisco units, although from a logical perspective its no different than having rack mounted 2511s for centralizing OOB access. (We wire all TTY ports on all cards for remote access, in case we need to do pcsdl downloads, access TTY menus, debug screens, etc..). Unfortunately, the USR/Cisco thing kept getting worse and I think the AS51 is a dead product now (which is highly annoying since they worked quite well). -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

CyberPort Montana <netboss@cyberport.net> writes: > The "show int e0" output was taken shortly after clearing the counters. If > I interpret it correctly, there are packets coming and going through the > interface. Well, it shows some frames being recognized but just from that data it's hard to say if it's working properly. What did the stats look like before you cleared them. This dump doesn't show any interface resets, which would typically increment if the AS51 thought the ethernet was down. > The interface seems to be cycling between up and down (see the console > output below). These cycles seems to be occurring every minute or so, with > the interface remaining up for only 10 seconds or so. I didn't see any console output included. > When I try to ping this interface from another machine, an interesting > thing occurs. If I examine the ARP entry for the IP address of the AS51 > before doing a ping, there is no entry. I then do a ping and even though > the ping is unsuccessful, immediately after the ping is aborted there is an > ARP entry for the AS51. A listing of the output from this procedure follows; That's pretty typical behavior for filling an ARP cache. Before you tried to reach the machine there was no entry, but your machine needed to locate the AS51 in response to your PING. The fact that there is an entry in the ARP afterwards is a reasonable indication that there is some physical connectivity and that the AS51 is at least responding to an ARP request. So your issue may in fact be more one relating to IP configuration, or some routing thing. > Any ideas will be appreciated. It might be helpful to know a little more about the addressing setup you are using on the wire where these machines site (addresses, netmasks, etc..), along with a configuration dump of the bad AS51, a current routing table and the ARP table from the AS51. That console log of the interface cycling would be useful too. If things are working in the reverse direction, you should be able to see the ARP table on your AS51 get populated with the ethernet hardware address of the machine from which you are doing the ping at the same time as the ARP table on the machine generating the ping got filled. While the ARP stuff here seems to show something ok physically, the interface cycling is not normal, so there may still be some hardware problem as the root cause. And in particular because you have other AS51s to compare configuration and status too, a lot of typical misconfiguration possibilities become less likely or you would probably have caught them in such a comparison. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Brian Elfert <brian@citilink.com> writes: > If Cisco went to all the work of creating a card to fit into the USR rack, > why didn't they just use the packet bus? Probably because that would have been significantly more effort than just making the existing hardware fit into the rack. I expect it was really fairly simple to make the NAC - after all, the motherboard of a 25xx class Cisco isn't all that large so it's mostly just an issue of chip layout - for all I know they just pumped it into a circuit design program with new parameters for size. All of the interfacing except for the serial lines was kept on the NAC, so Cisco could just use all the same components. They may have had to tweak their code slightly to access the serial lines through the NIC but that would depend on how the signals got through the midplane - if there were enough pins to just carry them straight, then there might not have been any changes at all. In effect, the AS51 is a NAC that is fairly "dumb" with respect to the chassis. It does obey the reset lines (but that's just a physical interfacing issue) but nothing more complex. However, to do the packet bus, they'd have had to add the new chipset and more importantly, written packet bus interface code into IOS. The software overhead for doing that might have been to much for the first pass. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Make sure you allow more than one simultaneous login for that account. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ken Hunter, Aspiring Technologies Sent: Friday, March 06, 1998 8:37 PM Multilink ppp disabled ? Ken :) At 09:24 PM 3/6/98 -0500, you wrote: >Hi Everyone, > > >I have a problem. We are running a USR TC Network Hub with the quad modems. >Our ISDN dialups cannot log in at 128k, but if they connect using single >channel 64k they have no problem. > >Everyone else, analog X2 dialups are fine. > >Any ideas? > > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************ - 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.

Hi Everyone, I have a problem. We are running a USR TC Network Hub with the quad modems. Our ISDN dialups cannot log in at 128k, but if they connect using single channel 64k they have no problem. Everyone else, analog X2 dialups are fine. Any ideas?

Multilink ppp disabled ? Ken :) At 09:24 PM 3/6/98 -0500, you wrote: >Hi Everyone, > > >I have a problem. We are running a USR TC Network Hub with the quad modems. >Our ISDN dialups cannot log in at 128k, but if they connect using single >channel 64k they have no problem. > >Everyone else, analog X2 dialups are fine. > >Any ideas? > > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

also, do you have more than one chassis? if so, do you have universal call distribution? (that is where one call come in on chassis number one and the next on chassis #2 etc.) if you do have ucd then 128 won't work because for 128 both calls need to come in on the same chassis. your telco can give you a number that will point at the last box to avoid this. matthew Ken Hunter, Aspiring Technologies wrote: > > Multilink ppp disabled ? > > Ken :) > > At 09:24 PM 3/6/98 -0500, you wrote: > >Hi Everyone, > > > > > >I have a problem. We are running a USR TC Network Hub with the quad modems. > >Our ISDN dialups cannot log in at 128k, but if they connect using single > >channel 64k they have no problem. > > > >Everyone else, analog X2 dialups are fine. > > > >Any ideas? > > > > > >- > > 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. > > > - > ************************************************************************ > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. > > Ken Hunter Aspiring Technologies > mailto:ken@aspire.net 9304 Troy Drive > http://www.aspire.net Nokesville, Va 20181 > ************************************************************************ > > - > 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. -- the spa! online services - www.the-spa.com - info@the-spa.com 654b new ludlow road, south hadley, ma 01075 - 413 539-9818 providing online services since 1989!

we have found that if our customers include a one and the area code infront of our dial up number that they get the 128k connection. ie 1-650-xxx-xxxx. But if they use the only the prefix and station (xxx-xxxx) they only get in at the 64k rate. Sorry I don't know why. CDNET wrote: > Hi Everyone, > > I have a problem. We are running a USR TC Network Hub with the quad modems. > Our ISDN dialups cannot log in at 128k, but if they connect using single > channel 64k they have no problem. > > Everyone else, analog X2 dialups are fine. > > Any ideas? > > - > 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.

From what I have been told, either put the username into the internal table on the netserver and limit the port count there, or run a radius configuration that uses a database for authentication - when running with a db, the radius engine can then track simultaneous logins. I have not tried this - don't have a db yet - but that's what I have been told. Ya can also hack the radius code - and add your own simultaneous login tracking engine. Ken :) At 03:08 PM 3/7/98 +0300, you wrote: > > >wjordan@pcl.net wrote: > >> Make sure you allow more than one simultaneous login for that account. >> > >Hi Jordan ,, > >How can I disable more than 1 simulatenous logins to netserver.....? > >TIA > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ken Hunter, >> Aspiring Technologies >> Sent: Friday, March 06, 1998 8:37 PM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) 128k ISDN Calls not accepted 64k and others OK >> >> Multilink ppp disabled ? >> >> Ken :) >> >> At 09:24 PM 3/6/98 -0500, you wrote: >> >Hi Everyone, >> > >> > >> >I have a problem. We are running a USR TC Network Hub with the quad modems. >> >Our ISDN dialups cannot log in at 128k, but if they connect using single >> >channel 64k they have no problem. >> > >> >Everyone else, analog X2 dialups are fine. >> > >> >Any ideas? >> > >> > >> >- >> > 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. >> > >> - >> ************************************************************************ >> Web Hosting, E-mail addresses, DNS services, Dedicated circuits. >> 33.6, X2(56k), ISDN Dialup available in Prince William County VA. >> >> Ken Hunter Aspiring Technologies >> mailto:ken@aspire.net 9304 Troy Drive >> http://www.aspire.net Nokesville, Va 20181 >> ************************************************************************ >> >> - >> 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. >> >> - >> 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. > > > >-- > > \\|// - ? > (o o) > +==================================oOOo=(_)=oOOo========+ > | Richard Bosire rbosire@africaonline.co.ke | > | AfricaOnline Ltd | > | union towers, 2nd floor | > | tel: 254-2-243775 | > | .oooO | > | http://www.africaonline.co.ke ( ) Oooo. | > +===================================\ (==( )==========+ > \_) ) / > (_/ > > > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

Look in the dictionary file that came with your radius.... make sure that 3 is interpreted as the value that you want... Ken :) At 03:25 PM 3/7/98 +0300, you wrote: >All my products are 3com products ( usr) .. !!! > >thanx > >Tatai SV Krishnan wrote: > >> On Fri, 6 Mar 1998, Richard Bosire wrote: >> >> > Tatai .,, >> > >> > You remember you recommended this to me ..??..**^&$%$%. >> > >> >> Read the email that I sent, If you are using our product only - you can >> set PPTP value to 3. The value 3 is OK only for us because, we >> autodetect, The RFC are also defined in the email. So if you are using >> Radius with our product and with someelse product set PPTP value to 9. >> >> krish >> >> > Now this is what i call chaos mania >> > >> > bosire >> > >> > Dave Mitton wrote: >> > >> > > Dear USR, >> > > >> > > This value is not RFC compliant. >> > > >> > > Framed-Protocol = 3 is defined as ARAP (Appletalk Remote Access Protocol) >> > > >> > > Please pick a different value. >> > > >> > > Dave. >> > > >> > > At 09:20 PM 2/24/98 -0600, Tatai SV Krishnan wrote: >> > > >On Wed, 25 Feb 1998, Richard Bosire wrote: >> > > > >> > > >> Hi Guys , >> > > >> >> > > >> Does anyone know which version of Radius ptpp and what version of the >> > > >> netserver code this will >> > > >> with .. >> > > >> >> > > >> TIA >> > > >> >> > > >> cheers >> > > >> >> > > >> bosire >> > > > >> > > > >> > > >Every Radius will support PPTP, see in the dictionary file under the >> > > >framed-protocol section you will see something like this >> > > > >> > > >VALUE Framed-Protocol PPP 1 >> > > > >> > > >now go ahead and add a new item there >> > > > >> > > >VALUE Framed-Protocol PPTP 3 >> > > > >> > > >and when you add users you should say Framed-Protocol is PPTP >> > > > >> > > >krish >> > > > >> > > >> > > --------------------------------------------------------------- >> > > David Mitton 978-670-8888 Main >> > > Consulting Engineer 978-916-4570 Direct >> > > Bay Networks, Remote Access Srv Div 978-916-4789 FAX >> > > Billerica, MA 01821 dmitton@baynetworks.com >> > > >> > > - >> > > 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. >> > >> > >> > >> > -- >> > >> > \\|// - ? >> > (o o) >> > +==================================oOOo=(_)=oOOo========+ >> > | Richard Bosire rbosire@africaonline.co.ke | >> > | AfricaOnline Ltd | >> > | union towers, 2nd floor | >> > | tel: 254-2-243775 | >> > | .oooO | >> > | http://www.africaonline.co.ke ( ) Oooo. | >> > +===================================\ (==( )==========+ >> > \_) ) / >> > (_/ >> > >> > > > > >-- > > \\|// - ? > (o o) > +==================================oOOo=(_)=oOOo========+ > | Richard Bosire rbosire@africaonline.co.ke | > | AfricaOnline Ltd | > | union towers, 2nd floor | > | tel: 254-2-243775 | > | .oooO | > | http://www.africaonline.co.ke ( ) Oooo. | > +===================================\ (==( )==========+ > \_) ) / > (_/ > > > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

There was a discussion a while back about DNS functions on the TC. I'm having a problem where some users are not allowed access to some sites (mostly telnet) because reverse DNS lookup is failing. If I telnet into the TC I often notice only the IP number is listed for an open port, then another 'show sessions' will cause all of them to update with our PTR records, 'gnv-tc0-ip-port1.accelerate.net' etc.... I can access all of the sites complained about on any static IP machine. I believe the DNS attribute is 'on' when I "show global'. Should I be ading all these entries to the TC's hosts table? Thanks, Kent Tambling Systems Support Kent@Acceleration.NET www.Acceleration.NET

Thus spake David Bolen >Charles Sprickman <spork@inch.com> writes: >> What is the AS51 card? That output looks very Cisco-like... I thought I >> saw something like that at the NYC ANS BIGDial once... >Peekin' at our equipment, eh? Guess that's what we get for putting >big labels on our cabinets :-) They are kinda hard to miss! :) >For our second phase design, we used AS51 cards as onboard OOB >terminal servers rather than wasting rack space on separate Cisco >units, although from a logical perspective its no different than >having rack mounted 2511s for centralizing OOB access. (We wire all >TTY ports on all cards for remote access, in case we need to do pcsdl >downloads, access TTY menus, debug screens, etc..). The nice thing about the AS51's doing that (I'm trying to convince my higher ups to let me buy some to do the same here, seeing your racks helped my cause a lot :) is that there is less power consumption (slightly since its pulling off the TC chassis power), tons easier wiring (again, less power cables, less rack space, etc.). I also see the AS51's being the answer to the "POP in a box" solution since I don't really trust the frame-relay on the netservers and would rather have a Cisco only router solution. I just wish the AS51's had a built-in CSU/DSU. :) Ah well...can't have everything I guess. >Unfortunately, the USR/Cisco thing kept getting worse and I think the >AS51 is a dead product now (which is highly annoying since they worked >quite well). Last time I called about it (2 months ago maybe?) it took some explanation to get them to know what I was asking about, but once I got through to them about what I wanted, they pulled up a price for it and were willing to sell me some, so I suspect you can still get them. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

You need Radius running with a database system. We run RadiusNT and Emerald. It really works well for this. don't know if you can support multiple logins without the database. But mainly the database is used to restrict the number of logins. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Bosire Sent: Saturday, March 07, 1998 6:09 AM wjordan@pcl.net wrote: > Make sure you allow more than one simultaneous login for that account. > Hi Jordan ,, How can I disable more than 1 simulatenous logins to netserver.....? TIA > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ken Hunter, > Aspiring Technologies > Sent: Friday, March 06, 1998 8:37 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 128k ISDN Calls not accepted 64k and others OK > > Multilink ppp disabled ? > > Ken :) > > At 09:24 PM 3/6/98 -0500, you wrote: > >Hi Everyone, > > > > > >I have a problem. We are running a USR TC Network Hub with the quad modems. > >Our ISDN dialups cannot log in at 128k, but if they connect using single > >channel 64k they have no problem. > > > >Everyone else, analog X2 dialups are fine. > > > >Any ideas? > > > > > >- > > 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. > > > - > ************************************************************************ > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. > > Ken Hunter Aspiring Technologies > mailto:ken@aspire.net 9304 Troy Drive > http://www.aspire.net Nokesville, Va 20181 > ************************************************************************ > > - > 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. > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/ - 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.

wjordan@pcl.net wrote: > Make sure you allow more than one simultaneous login for that account. > Hi Jordan ,, How can I disable more than 1 simulatenous logins to netserver.....? TIA > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ken Hunter, > Aspiring Technologies > Sent: Friday, March 06, 1998 8:37 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 128k ISDN Calls not accepted 64k and others OK > > Multilink ppp disabled ? > > Ken :) > > At 09:24 PM 3/6/98 -0500, you wrote: > >Hi Everyone, > > > > > >I have a problem. We are running a USR TC Network Hub with the quad modems. > >Our ISDN dialups cannot log in at 128k, but if they connect using single > >channel 64k they have no problem. > > > >Everyone else, analog X2 dialups are fine. > > > >Any ideas? > > > > > >- > > 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. > > > - > ************************************************************************ > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. > > Ken Hunter Aspiring Technologies > mailto:ken@aspire.net 9304 Troy Drive > http://www.aspire.net Nokesville, Va 20181 > ************************************************************************ > > - > 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. > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

All my products are 3com products ( usr) .. !!! thanx Tatai SV Krishnan wrote: > On Fri, 6 Mar 1998, Richard Bosire wrote: > > > Tatai .,, > > > > You remember you recommended this to me ..??..**^&$%$%. > > > > Read the email that I sent, If you are using our product only - you can > set PPTP value to 3. The value 3 is OK only for us because, we > autodetect, The RFC are also defined in the email. So if you are using > Radius with our product and with someelse product set PPTP value to 9. > > krish > > > Now this is what i call chaos mania > > > > bosire > > > > Dave Mitton wrote: > > > > > Dear USR, > > > > > > This value is not RFC compliant. > > > > > > Framed-Protocol = 3 is defined as ARAP (Appletalk Remote Access Protocol) > > > > > > Please pick a different value. > > > > > > Dave. > > > > > > At 09:20 PM 2/24/98 -0600, Tatai SV Krishnan wrote: > > > >On Wed, 25 Feb 1998, Richard Bosire wrote: > > > > > > > >> Hi Guys , > > > >> > > > >> Does anyone know which version of Radius ptpp and what version of the > > > >> netserver code this will > > > >> with .. > > > >> > > > >> TIA > > > >> > > > >> cheers > > > >> > > > >> bosire > > > > > > > > > > > >Every Radius will support PPTP, see in the dictionary file under the > > > >framed-protocol section you will see something like this > > > > > > > >VALUE Framed-Protocol PPP 1 > > > > > > > >now go ahead and add a new item there > > > > > > > >VALUE Framed-Protocol PPTP 3 > > > > > > > >and when you add users you should say Framed-Protocol is PPTP > > > > > > > >krish > > > > > > > > > > --------------------------------------------------------------- > > > David Mitton 978-670-8888 Main > > > Consulting Engineer 978-916-4570 Direct > > > Bay Networks, Remote Access Srv Div 978-916-4789 FAX > > > Billerica, MA 01821 dmitton@baynetworks.com > > > > > > - > > > 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. > > > > > > > > -- > > > > \\|// - ? > > (o o) > > +==================================oOOo=(_)=oOOo========+ > > | Richard Bosire rbosire@africaonline.co.ke | > > | AfricaOnline Ltd | > > | union towers, 2nd floor | > > | tel: 254-2-243775 | > > | .oooO | > > | http://www.africaonline.co.ke ( ) Oooo. | > > +===================================\ (==( )==========+ > > \_) ) / > > (_/ > > > > -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

Jeff Mcadams was heard to say: >>Unfortunately, the USR/Cisco thing kept getting worse and I think the >>AS51 is a dead product now (which is highly annoying since they worked >>quite well). > >Last time I called about it (2 months ago maybe?) it took some >explanation to get them to know what I was asking about, but once I got >through to them about what I wanted, they pulled up a price for it and >were willing to sell me some, so I suspect you can still get them. If USR would be a little more open about its hardware platform, then there could be a fair number of third party TC cards. I for one would like to have enough information to know what's going on inside there -- mid-plain and TDM bus info. I think most of the people I work for would put there sole(s) in escrow for a NetBlazer to replace the NetServer. --Ricky Beam PS: If you cannot tell, I'm all for public domain...

On Friday, March 06, 1998 4:59 PM, Kurtiss_Johnson/MW/US/3Com@usr.com [SMTP:Kurtiss_Johnson/MW/US/3Com@usr.com] wrote: > > > >What do the Netserver and HiPer ARC do that needs to know the > time and date? (Sorry, if this is >a dumb question.) .. and why can't my v4.0.19 ARC's save NTP information? Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) http://www.netdoor.com 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28

And I'll be the 4th. 33k is an x2 rate (33,333bps).33.6 is a v.34+ rate. In fact, 29,333 is also an x2 rate. A non x2 connection will *not* upshift to x2. Once an x2 connection drops to v.34, it will not upshift back to x2. Aloha, Richard. -----Original Message----- >Your the third person to say that. But thats not what TCM is telling me. >I'm getting 33k connects that upshift almost instantly to 4?k sessions. >I've confirmed it with big ftp downloads from local servers. Maybe it's >a TCM bug. (Wouldn't that be shocking!) > >Steve >

The current version of HiPer ARC does not support Frame-relay. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 7 Mar 1998, Brian wrote: > Can the HiPer ARC take Frame Relay like a netserver can (right out of a > CSU/DSU)? Or does it have to goto a router first that is capible of Frame > Relay and then into the ARC? > > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > - > 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. >

Can the HiPer ARC take Frame Relay like a netserver can (right out of a CSU/DSU)? Or does it have to goto a router first that is capible of Frame Relay and then into the ARC? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

I sometimes have users who dial into one of our USR Total Control hubs, and are coming from say hub #1, and hitting a server. Then there connection drops, and they dial back in but get on Hub #2. The server they were connected to still thinks they are on Hub #1, and since I am not running RIP on this machine, just a single /24 route, loopback, and default route, I am assuming this is coming from the arp cache. Is there a way to expire it manually? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

At 12:33 AM 3/8/98 -0500, Suncoast Networking USR Mailbox wrote: >Your the third person to say that. But thats not what TCM is telling me. >I'm getting 33k connects that upshift almost instantly to 4?k sessions. >I've confirmed it with big ftp downloads from local servers. Maybe it's >a TCM bug. (Wouldn't that be shocking!) > 33kbps uncompressed might yield 4?k with compression turned on, depending on the filetype.. So it might appear that your 33k connect is "instantly" shifting to 4?k (x2?)... just a thought... allen

On Sun, 8 Mar 1998, Suncoast Networking USR Mailbox wrote: > Your the third person to say that. But thats not what TCM is telling me. > I'm getting 33k connects that upshift almost instantly to 4?k sessions. > I've confirmed it with big ftp downloads from local servers. Maybe it's > a TCM bug. (Wouldn't that be shocking!) But, are the 33k connects reported as x2 or V.34 initially? I've noticed some sort of bug in the speed reporting in TCM. Every x2 connect is reported initially as being at 29000, and then at the first screen refresh, it is reported at the proper 48000 or whatever. The client modems are reporting the correct initial connect speed. Brian

>usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox) writes: > >> It has been my experience that calls will connect at a standard rate, >> then "upshift" to x2. > >Unfortunately, that can't happen. During the course of a session a >retrain can cause a modem to "fall out" of x2 into V.34, but there >will never be a shift into x2 if it was not using x2 during the >initial training of the call. So once you are in V.34 (whether due to >falling out of x2 or never achieving x2 initially) you'll max out at >the V.34 max of 33.6 - line permitting - for the lifetime of that >connection. Your the third person to say that. But thats not what TCM is telling me. I'm getting 33k connects that upshift almost instantly to 4?k sessions. I've confirmed it with big ftp downloads from local servers. Maybe it's a TCM bug. (Wouldn't that be shocking!) Steve

On Saturday, March 07, 1998 1:53 PM, Jeff Mcadams [SMTP:jeffm@iglou.com] wrote: > Thus spake David Bolen > >Charles Sprickman <spork@inch.com> writes: > >> What is the AS51 card? That output looks very Cisco-like... I thought I > >> saw something like that at the NYC ANS BIGDial once... > > >Peekin' at our equipment, eh? Guess that's what we get for putting > >big labels on our cabinets :-) > > They are kinda hard to miss! :) I agree .. ANS in big letters. > >For our second phase design, we used AS51 cards as onboard OOB > >terminal servers rather than wasting rack space on separate Cisco > >units, although from a logical perspective its no different than > >having rack mounted 2511s for centralizing OOB access. (We wire all > >TTY ports on all cards for remote access, in case we need to do pcsdl > >downloads, access TTY menus, debug screens, etc..). We have several old Livingston PM-2E30's and do the same thing ... but have yet to get the pinouts correct for RJ-45 keys /DB25 (Livingston end) and RJ-45 (USR end) cables. Anyone got an idea for pins 8 and 24 I think or where to get the cables? Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) http://www.netdoor.com 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28

On Sat, 7 Mar 1998, Brian wrote: > I sometimes have users who dial into one of our USR Total Control hubs, > and are coming from say hub #1, and hitting a server. Then there > connection drops, and they dial back in but get on Hub #2. The server > they were connected to still thinks they are on Hub #1, and since I am not > running RIP on this machine, just a single /24 route, loopback, and > default route, I am assuming this is coming from the arp cache. Is there ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This implies that you are running proxyarp!?! I would think the solution would be to turn proxyarp off, and have your dial-in pools on a completely different subnet than the tcr boxen, no? Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

Interesting, I currently have the exact same problem with the arp cache. I currently have Proxy Arp enabled on the TCC. It was USR tech who told me to enable proxy arp because the TCC was claiming certain IPs that were not specified assigned to the TCC and thus preventing Win95 machines from starting up on the network or even causing havoc. If I disable Proxy Arp, I expect to get the same problem. USR Tech didn't solve the problem, he just went around it. -----Original Message----- Cc: USRobotics TC Mailing List <usr-tc@xmission.com> On Sat, 7 Mar 1998, Brian wrote: > I sometimes have users who dial into one of our USR Total Control hubs, > and are coming from say hub #1, and hitting a server. Then there > connection drops, and they dial back in but get on Hub #2. The server > they were connected to still thinks they are on Hub #1, and since I am not > running RIP on this machine, just a single /24 route, loopback, and > default route, I am assuming this is coming from the arp cache. Is there ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This implies that you are running proxyarp!?! I would think the solution would be to turn proxyarp off, and have your dial-in pools on a completely different subnet than the tcr boxen, no? Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key * - 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.

On Sun, 8 Mar 1998, Marshall Morgan wrote: > > >For our second phase design, we used AS51 cards as onboard OOB > > >terminal servers rather than wasting rack space on separate Cisco > > >units, although from a logical perspective its no different than > > >having rack mounted 2511s for centralizing OOB access. (We wire all > > >TTY ports on all cards for remote access, in case we need to do pcsdl > > >downloads, access TTY menus, debug screens, etc..). > > We have several old Livingston PM-2E30's and do the same thing ... but > have yet to get the pinouts correct for RJ-45 keys /DB25 (Livingston > end) and RJ-45 (USR end) cables. Anyone got an idea for pins 8 and 24 I > think or where to get the cables? Just use a male<->female null modem adapter on the PM2 and use the cables that come with the chassis. If those aren't long enough, get some RJ-45 <-> DB25 hoods and use ethernet patch cables and make the pinouts in the hoods match the USR cables. -CH

What kind of ISDN terminal adapters/routers do your customers have? I know that CISCO 766 ISDN routers can't properly bind both b's. Motorola Bitsuffers seem to connect OK. Maybe it's not in your authentication, but a compatibility issue. Mike Hamrich Telecommunications Director DrFast.Net, Inc.

On Mon, 9 Mar 1998, FBSD wrote: > > Have been trying to get radius-assigned packet filters working. I would > appreciate any pointers... > > I've created a simple test filter named "test.fil" to stop web-access: > > #filter > IP: > 030 REJECT tcp-dst-port=80; > 040 REJECT tcp-src-port=80; > > It works perfectly when I assign it to a particular interface such by: > > set interface mod:1 INPUT_FILTER test.fil OUTPUT_FILTER test.fil > > Anyone loggin on via mod:1 won't be able to access the web. So far so > good. Good. > > However, if I have radius to assign it as an "user filter", nothing > happens. I have the following lines in the users file: > > gpig Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 255.255.255.254, > Framed-Netmask = 255.255.255.224, > Framed-Routing = Broadcast-Listen, > Framed-MTU = 1500, > Framed-Filter-Id= test.fil/test.fil, > Framed-Compression = Van-Jacobsen-TCP-IP > > User "gpig" still has access to the web when he logs on. I've also tried > using: > > Framed-Filter-Id= test.fil, > or > > Framed-Filter-Id= "test.fil", > > but nothing seems to work. BTW, I'm using radius 1.16 from Livingston. > Thanks in advance for ANY help. > Well this is not working since, the Radius is sending the test.fil as the filter name and the HiPer ARC is looking for test.fil.in and test.fil.out as filters and since there is not test.fil.in and test.fil.out the filter is not working. This was set up this way to be compatable with NETServer. However there are ER releases which will allow you to work the way you have setup here. reagards krish > fbsd > (a struggling NETServer 16/I newbie) > > > - > 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. >

They are using a 3Com ta, I don't remember offhand what the model was, but the USR engineer seemed surprised that it didn't work. Can you tell me anything about the MPIP settings on the TC? Thanks, Mike -----Original Message----- >What kind of ISDN terminal adapters/routers do your customers have? I know >that CISCO 766 ISDN routers can't properly bind both b's. Motorola >Bitsuffers seem to connect OK. Maybe it's not in your authentication, but a >compatibility issue. > >Mike Hamrich >Telecommunications Director >DrFast.Net, Inc. > > > >---------- >> From: wjordan@pcl.net >> To: usr-tc@lists.xmission.com >> Subject: RE: (usr-tc) 128k ISDN Calls not accepted 64k and others OK >> Date: Saturday, March 07, 1998 4:06 PM >> >> You need Radius running with a database system. We run RadiusNT and >Emerald. >> It really works well for this. don't know if you can support multiple >logins >> without the database. But mainly the database is used to restrict the >number >> of logins. >> >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Bosire >> Sent: Saturday, March 07, 1998 6:09 AM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) 128k ISDN Calls not accepted 64k and others OK >> >> >> >> >> wjordan@pcl.net wrote: >> >> > Make sure you allow more than one simultaneous login for that account. >> > >> >> Hi Jordan ,, >> >> How can I disable more than 1 simulatenous logins to netserver.....? >> >> TIA >> >> > -----Original Message----- >> > From: owner-usr-tc@lists.xmission.com >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ken Hunter, >> > Aspiring Technologies >> > Sent: Friday, March 06, 1998 8:37 PM >> > To: usr-tc@lists.xmission.com >> > Subject: Re: (usr-tc) 128k ISDN Calls not accepted 64k and others OK >> > >> > Multilink ppp disabled ? >> > >> > Ken :) >> > >> > At 09:24 PM 3/6/98 -0500, you wrote: >> > >Hi Everyone, >> > > >> > > >> > >I have a problem. We are running a USR TC Network Hub with the quad >> modems. >> > >Our ISDN dialups cannot log in at 128k, but if they connect using >single >> > >channel 64k they have no problem. >> > > >> > >Everyone else, analog X2 dialups are fine. >> > > >> > >Any ideas? >> > > >> > > >> > >- >> > > 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. >> > > >> > - >> > >************************************************************************ >> > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. >> > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. >> > >> > Ken Hunter Aspiring Technologies >> > mailto:ken@aspire.net 9304 Troy Drive >> > http://www.aspire.net Nokesville, Va 20181 >> > >************************************************************************ >> > >> > - >> > 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. >> > >> > - >> > 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. >> >> >> >> -- >> >> \\|// - ? >> (o o) >> +==================================oOOo=(_)=oOOo========+ >> | Richard Bosire rbosire@africaonline.co.ke | >> | AfricaOnline Ltd | >> | union towers, 2nd floor | >> | tel: 254-2-243775 | >> | .oooO | >> | http://www.africaonline.co.ke ( ) Oooo. | >> +===================================\ (==( )==========+ >> \_) ) / >> (_/ >> >> >> >> - >> 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. >> >> >> - >> 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. > >- > 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.

On Sun, 8 Mar 1998, Michael H. Hamrich wrote: > What kind of ISDN terminal adapters/routers do your customers have? I know > that CISCO 766 ISDN routers can't properly bind both b's. Motorola > Bitsuffers seem to connect OK. Maybe it's not in your authentication, but a > compatibility issue. A number of our customers have had recent success with Netgear RT328 ISDN routers. I don't know how I feel about their ability to do NAT behind a dynamic IP, though. The First Gear software makes them super simple to configure and they use an Ethernet interface, which is preferable to a serial connection for performance and lack of DUN and flow control headaches. They get very reliable 2B connections. And the price ($319 includes a free 8-port hub at www.warehouse.com) is not too bad for a TA, much less a full-featured router. 3Com Courier I-Modem is not so easy, but works well. And one thing I can say for the 3Com Lanlinker as an ISDN router is that the command line interface is familiar. Motorola Bitsurfr users require extra support effort, but what ISDN users don't need a little hand-holding? They work great. Ascend Pipeline routers work well with 3Com NAS, but quality control has been a problem in the past. -CH

> Your the third person to say that. But thats not what TCM is telling me. > I'm getting 33k connects that upshift almost instantly to 4?k sessions. We've seen this also, but from both ends. The modem connecting reports anything up to 52k connect speed, while TCM reports 29k as the initial connection speed. The current speeds match at both ends though. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> > On Sun, 8 Mar 1998, Tatai SV Krishnan wrote: > > > Well this is not working since, the Radius is sending the test.fil as the > > filter name and the HiPer ARC is looking for test.fil.in and test.fil.out > > as filters and since there is not test.fil.in and test.fil.out the filter > > is not working. This was set up this way to be compatable with > > NETServer. However there are ER releases which will allow you to work > > the way you have setup here. > > HiPer ARC? Do I have that (whatever that is) on my NETServer 16/I? > Lastly, what are "ER releases?" Sorry for all these newbie questions. > Same as above, create a filter in you NETServer 16 and call it test.fil.in and test.fil.out. Set the radius Attribute as framed filter id test.fil and there are not ER releases for NETServer 8/16. ER releases are engineering/emergency release address some problem/fixes in the code for one/many customers krish > fbsd >

usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox) writes: > Your the third person to say that. But thats not what TCM is telling me. > I'm getting 33k connects that upshift almost instantly to 4?k sessions. > I've confirmed it with big ftp downloads from local servers. Maybe it's > a TCM bug. (Wouldn't that be shocking!) When you say "33k" do you mean "33,333" or do you mean "33,600". The former is an x2 modulation rate, but the latter is V.34. You might want to check your initial modulation type. Trust me - it's impossible to shift up from V.34 to x2 once the initial negotation has selected V.34. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Brian Elfert <brian@citilink.com> writes: > But, are the 33k connects reported as x2 or V.34 initially? > > I've noticed some sort of bug in the speed reporting in TCM. > > Every x2 connect is reported initially as being at 29000, and then at the > first screen refresh, it is reported at the proper 48000 or whatever. For what it's worth, there's no bug in TCM - it's reflecting what the modems are really working at during the first few seconds of the connection. (Trust the server more than the client) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

>I found the article to be very interesting. Also think his dialup tests were severely flawed. I've put a link to the article and >added why the tests are worthless on my page at http://pages.prodigy.net/bbhi/r-rnut-x2.htm >Thanks for the info. >Aloha, >Richard Aloha Richard, I checked out your web page, and it sure looks like you have had a bad time with x2 (and even more with K56). For the x2 problems, I apologize. I can say with a great deal of certainty, this issue you are encountering is a pad issue. The ability to get x2 on LD calls and not on local (with the definition of "local" and "LD" being a judgement call by the telco) is a tell-tale sign. I can also say with a great deal of confidence that you are REALLY going to like our implementation of V.90! The pad problems are quite rare, as we got most of them covered, but there were certainly enough people having problems to justify an overhaul of the pad detection scheme. I think you hit the issue on the head in your comments on the pad issue and telco configurations. There is no way that the telcos will be able to put only pads on the network that 3Com/USR, Rockwell, Lucent or whoever wants to be in the path. We came to that conclusion quite some time ago. We could have tried to put a patch in for every possible digital pad we have found over the last year (and various combinations of digital impairments), but that would have been an endless process, would have taken up huge chunks of memory and would have caused incredible havoc for ISPs and client customers trying to figure out what revs of code are on either end and what pad or RBS pattern was causing the problem, in addition to sucking up development and test resources that were best put on the "total kill solution". The only way to do this right was to kill them all at once, on the fly, automatically. This took a fairly signiificant amount of research and development and had to be implemented carefully. The Boardwatch article pretty much covers the topic, see the section on "DIL" (or "Digitial Impairment Learning"). The way the "DIL" was implemented in 3Com V.90 modems will solve exactly the logistical problems you describe. It is designed (and tested) to detect the digital impairments during training, and build a custom constellation on the fly designed to overcome or circumvent whatever digital impairments it encounters in the path. This works on a call-by-call basis to handle different routing paths and for use on different lines served by different COs and/or PBXs with different settings. It even works through A-law to mu-law conversions. It is very automatic and requires no configuration, it just works. When you get the V.90 upgrade for your Courier, and connect to a V.90 server, you will hear a new "bong-bong" sound at the end of the training sequence, that is the DIL sequence. This concept has been in field testing since way back in October, works great and is very refined now. As far as your points that the Boardwatch testing was flawed due to the testing being mostly toll calls. You are right to a degree, but not totally. You would be surprised how many ISPs use creative, innovative techniques pioneered by the CLECs to provide local dialup numbers to super POPs concentrated in cities far away. These calls are backhauled over digital lines back to the real POP, often over multiple AMI links that add additional Robbed Bits with digital padding applied that is consistent with an LD call. Boardwatch's tests showed mostly 1-3 Robbed bits in the path, which is pretty typical of a CLEC networked Super-POP "local" call. Also note that the "throughput tests" done to verify connect message to throughput consistency were done to local Denver ISPs, not over LD calls. They also "favored" local POPs in their wardialer program (both for the reasons you mention, plus the obvious cost factor). On the similar note you made on 3Com's testing procedures. The description of the testing in the article was just a "gloss-over". The concept of ensuring a duplication of the "typical local call" was not lost in the test design and site choices. There were 11 POPs in 10 countries, with 2 POPs in the US. One on the "left coast", and one in the middle (Skokie). The vast bulk (roughly 70%) of the testers were local to the test POPs, and the remainder were long distance. This provided a very wide variety of pad, robbed bit and Round trip delay values and covered the "network model" very, very well. We also made special efforts to test on local calls in areas known to cause trouble to x2. Raleigh/Durham, NC. and Korea are two that come to mind. I wish I had known their were problems in Hawaii a few months ago, that would have been a real nice field trip in December ;-) Anyway, I did not want to barrage you with data and facts, but the conclusions you made were based on some partially false assumptions and begged for clarification. I truly regret the trouble you have encountered, but know that there are many, many people at 3Com that totally "give a hoot", do know what some of our customers are experiencing and are dedicated to resolving the problems once and for all. I am confident you will be totally blown away by the improvements we have put in this code. Our goal is to achieve 92% network coverage. 5% are taken off the top due to additional A/D conversions, and another 3% that have so much noise or other analog impairments that it is just not possible. We believe we have reached, or are very close to, that goal with our V.90 release. We will probably not be perfect, but this is the result of two years of solid R&D and should please many a user. I hope this clears the air a bit, and gives you something to look forward to. I know you are pessimistic, and for good reason, but I know you will be pleased when you get a chance to make a V.90 call with your Courier. Remember, these improvements in digital impairment detection require V.90 code at the server end also, otherwise you are in x2 backwards compatibility mode with the same restrictions (which will be fine for most, but you really need the V.90 fixes for your environment). Regards, John Powell 3Com Carrier Systems Division x2/V.90 Engineering Team

On Mon, 9 Mar 1998, Robert von Bismarck wrote: > I've put some loggins system on my HiPerARC console ports after the > multiple reboots with code version 4.0.19. I updated to 4.0 72 and, > guess what, it still reboots=A0!=A0!=A0! (not as often as before, but any= way, > it's beginning to piss me off...) >=20 > The only item I logged was this cryptic messsage (I forwarded it to USR > R&D and should get an updated code soon...) >=20 > DD_ERROR, Entering While 1 loop ERROR_NO 0x64 0xffffffe9 >=20 > Anyone ever saw this before=A0? Happens with 4.0.75 and 4.0.72... I Run 4.0.69 ER Code and have no problems, prior I was running other ER releases which did cause the ARC to reboot. Brian >=20 > Robert von Bismarck > Petrel Communications S.A. >=20 > - > 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. >=20 /-------------------------- signal@shreve.net -----------------------------= \ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 = | | Network Administrator | Perl, Linux | Web hosting, online stores, = | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs = | | 89 CRX DX w/MPFI, lots of |-=3D*:Quake:*=3D-| http://www.shreve.net/ = | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 = | \-------------------------- 318-222-2638 x109 -----------------------------= /

On Mon, 9 Mar 1998, matthew wrote: > we have found that the best way to control multiple logins is pmmon > www.pmmon.com > > it not only stops it but notifies you. > > matthew > > > >How can I disable more than 1 simulatenous logins to netserver.....? > > > >TIA > > You can use RADIUS.. 1) set Port-Limit = 1 . This will prevent Multilink calls 2) Use a RADIUS that supports Max Concurrent Sessions.

we have found that the best way to control multiple logins is pmmon www.pmmon.com it not only stops it but notifies you. matthew >How can I disable more than 1 simulatenous logins to netserver.....? > >TIA > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ken Hunter, >> Aspiring Technologies >> Sent: Friday, March 06, 1998 8:37 PM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) 128k ISDN Calls not accepted 64k and others OK >> >> Multilink ppp disabled ? >> >> Ken :) >> >> At 09:24 PM 3/6/98 -0500, you wrote: >> >Hi Everyone, >> > >> > >> >I have a problem. We are running a USR TC Network Hub with the quad modems. >> >Our ISDN dialups cannot log in at 128k, but if they connect using single >> >channel 64k they have no problem. >> > >> >Everyone else, analog X2 dialups are fine. >> > >> >Any ideas? >> > >> > >> >- >> > 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. >> > >> - >> ************************************************************************ >> Web Hosting, E-mail addresses, DNS services, Dedicated circuits. >> 33.6, X2(56k), ISDN Dialup available in Prince William County VA. >> >> Ken Hunter Aspiring Technologies >> mailto:ken@aspire.net 9304 Troy Drive >> http://www.aspire.net Nokesville, Va 20181 >> ************************************************************************ >> >> - >> 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. >> >> - >> 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. > > > >-- > > \\|// - ? > (o o) > +==================================oOOo=(_)=oOOo========+ > | Richard Bosire rbosire@africaonline.co.ke | > | AfricaOnline Ltd | > | union towers, 2nd floor | > | tel: 254-2-243775 | > | .oooO | > | http://www.africaonline.co.ke ( ) Oooo. | > +===================================\ (==( )==========+ > \_) ) / > (_/ > > > >- > 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. >

On Mon, 9 Mar 1998, Charles Sprickman wrote: > Has anyone been able to use the Performance Monitor function on any > version of TCM under NT? Everything else seems to work well, but as soon > as you've picked any parameters to monitor and you click "OK", Dr. Watson > arrives with the message that TCM.exe has caused an access violation... it works fine for me > > Thanks, > > Charles > > ~~~~~~~~~ ~~~~~~~~~~~ > Charles Sprickman Internet Channel > INCH System Administration Team (212)243-5200 > spork@inch.com access@inch.com > > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Brian said once upon a time: >I Run 4.0.69 ER Code and have no problems, prior I was running other ER >releases which did cause the ARC to reboot. Do you folks use either the login prompt or login menu? Do you have any idea if 4.0.69 resolves the disappearing bug?

Has anyone been able to use the Performance Monitor function on any version of TCM under NT? Everything else seems to work well, but as soon as you've picked any parameters to monitor and you click "OK", Dr. Watson arrives with the message that TCM.exe has caused an access violation... Thanks, Charles ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com

At 11:15 AM 3/9/1998 -0500, you wrote: >Has anyone been able to use the Performance Monitor function on any >version of TCM under NT? Everything else seems to work well, but as soon >as you've picked any parameters to monitor and you click "OK", Dr. Watson >arrives with the message that TCM.exe has caused an access violation... I have that problem on one system (the one I'm using now), but not on any other. I'd love to know why. DCP

> ---------- > From: Charles Hill[SMTP:chill@ionet.net] > Reply To: usr-tc@lists.xmission.com > Sent: Sunday, March 08, 1998 9:46 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 128k ISDN Calls not accepted 64k and others > OK > > > > A number of our customers have had recent success with Netgear RT328 > ISDN > routers. I don't know how I feel about their ability to do NAT behind > a > dynamic IP, though. The First Gear software makes them super simple > to > configure and they use an Ethernet interface, which is preferable to a > serial connection for performance and lack of DUN and flow control > headaches. They get very reliable 2B connections. And the price > ($319 > includes a free 8-port hub at www.warehouse.com) is not too bad for a > TA, > much less a full-featured router. > Charles, My configuration is a T1 ISDN 24 channel, edgeserver running NT RAS. Has anyone try dialing in with any TA with ethernet interface and 8 port hub. If this work, how does NT assign extra IP address to other ports of the 8 port hub? Willie Lau > 3Com Courier I-Modem is not so easy, but works well. And one thing I > can > say for the 3Com Lanlinker as an ISDN router is that the command line > interface is familiar. > > Motorola Bitsurfr users require extra support effort, but what ISDN > users > don't need a little hand-holding? They work great. > > Ascend Pipeline routers work well with 3Com NAS, but quality control > has > been a problem in the past. > > -CH > > > - > 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. >

Original message from Charles Sprickman: > >Has anyone been able to use the Performance Monitor function on any >version of TCM under NT? Everything else seems to work well, but as soon >as you've picked any parameters to monitor and you click "OK", Dr. Watson >arrives with the message that TCM.exe has caused an access violation... > Most of the time it works fine for me. I assume you have service pack 3? Jas, Interpath Communications Data Network Technician Jas.Eckard@interpath.net

Once upon a time Allen Marsalis shaped the electrons to say... >faster on average than kflex across 89 national isps.. Can only imagine >what MZ thinks of Jack and his methods.. I'd laugh at him if only so many people weren't so gullible as to believe his reports. He's a hazard. I've met Jack and was less impressed in person than through his written reports. Good businessman, bad tester and analyst. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human being, me "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail Discordia!

I've put some loggins system on my HiPerARC console ports after the multiple reboots with code version 4.0.19. I updated to 4.0 72 and, guess what, it still reboots=A0!=A0!=A0! (not as often as before, but = anyway, it's beginning to piss me off...) The only item I logged was this cryptic messsage (I forwarded it to USR R&D and should get an updated code soon...) DD_ERROR, Entering While 1 loop ERROR_NO 0x64 0xffffffe9 Anyone ever saw this before=A0? Happens with 4.0.75 and 4.0.72... Robert von Bismarck Petrel Communications S.A.

I have this working on my netserver/16 , for emailonly clients netserver_1> show filter emailonly.out - IP rules - 1 permit 199.103.176.x/24 0.0.0.0/0 tcp src eq 25 2 permit 199.103.176.x/24 0.0.0.0/0 tcp src eq 110 3 permit 199.103.176.x/32 0.0.0.0/0 tcp src eq 80 4 permit 199.103.176.x/24 0.0.0.0/0 tcp src eq 53 5 permit 199.103.176.x/24 0.0.0.0/0 udp src eq 53 where 199.103.176.x are the ips of the machines you want to restrict access to ,... cheers bosire FBSD wrote: > Have been trying to get radius-assigned packet filters working. I would > appreciate any pointers... > > I've created a simple test filter named "test.fil" to stop web-access: > > #filter > IP: > 030 REJECT tcp-dst-port=80; > 040 REJECT tcp-src-port=80; > > It works perfectly when I assign it to a particular interface such by: > > set interface mod:1 INPUT_FILTER test.fil OUTPUT_FILTER test.fil > > Anyone loggin on via mod:1 won't be able to access the web. So far so > good. > > However, if I have radius to assign it as an "user filter", nothing > happens. I have the following lines in the users file: > > gpig Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 255.255.255.254, > Framed-Netmask = 255.255.255.224, > Framed-Routing = Broadcast-Listen, > Framed-MTU = 1500, > Framed-Filter-Id= test.fil/test.fil, > Framed-Compression = Van-Jacobsen-TCP-IP > > User "gpig" still has access to the web when he logs on. I've also tried > using: > > Framed-Filter-Id= test.fil, > or > > Framed-Filter-Id= "test.fil", > > but nothing seems to work. BTW, I'm using radius 1.16 from Livingston. > Thanks in advance for ANY help. > > fbsd > (a struggling NETServer 16/I newbie) > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

US Robotics Total Control Hub 12 Quad v.34 Ang/Dig Modem Cards Single sided 1 Net Server PRI Card 1 Network Management Card 2 AC PSU 45A. Power Supplies 12 Quad Analog/RS-232 NIC Cards 1 High Speed Wan Ethernet NIC (net server) 1 Ethernet NIC (net manager) this chassis is dated 9/6/96 it has been running flawlessly in our NYC noc from 11/1/96 when we purchased it factory direct until today. Plug in 48 pots lines, two ethernets, and the two ac cords, and your ready to sell dialup. best offer takes it email aspen@bway.net or call Aspen at 212.982.9800

Once upon a time Brett Hawn shaped the electrons to say... >So you would have us believe that K56flex or whatever its being called >today, is better than X2? I'm going to have to seriously disagree with you >here. Regardless of your opinion of yon Boardwatch writer, or his likes, X2 >has consistently been the more reliable protocol every time. K56Flex has >been nothing but a pain in our ass from the get go, and say what you may And I can cite a few dozen posts with 180 degrees from you - your point? For ever person bitching about K56flex and praising X2 there is someone bitching about X2 and praising K56flex. So I don't give a fuck. The problem is Jack's test is seriously skewed. The K56flex results he got have not been reflected by a single real world user who followed up, which is why tens of ISPs are jumping down his throat on portmaster-users and isp-ceo. He made a poorly architected test, using only connect speeds (BTW, a friend of mine on the inside tells be X2's connect speeds are deliberately optimistic and are not the real sustainable speeds - this seems confirmed by the myriad of reports on scores of lists and newsgroups), and then generalized that to the entire K56flex market. When really, even in his flawed way, all that was being tested was Rockwell client to Rockwell server - there was one PM user in the batch. He further went on, on the basis of just that test, to make a comment in public email directly slamming performance on PMs - a comment he later 'corrected' (retracted). Just a few minutes ago on PM users was a person talking about how they just decided to never by 3Com servers and have standardized on PM-3s for ease of use and superior performance. Right now they have more TCs than PM-3s, but are frozen on the TC side. They switched from 3Com/USR to Lucent RABU because their experience was exactly the opposite of yours. And for all I know you have Ass-End servers on the K56flex side, or Shiva, or what have you. Does that make your experience a universal truth? No. Does that make the other users experience a universal truth. No. I'm sure both of you have exactly the experiences you claim. I do contend that K56flex was a generally superior protocol to X2 in most regards, including max speed and sustained throughput. But implementations vary. X2 had the advantage of being primarily a single vendor. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human being, me "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail Discordia!

Is limiting logins a function of the radius server or of the total control rack? We are using netserver/16 with quad analog modems and are having a heck of a time with users logging in multiple times. The company we get our access from has control of the radius server. I have control of the USR rack. Chuck Simons..

At 05:12 PM 3/9/98 -0600, you wrote: >Is limiting logins a function of the radius server or of the total control >rack? > >We are using netserver/16 with quad analog modems and are having a heck >of a time with users logging in multiple times. > >The company we get our access from has control of the radius server. I >have control of the USR rack. > The RADIUS server.. It must keep a database of who is logged in and not auth dupe logins.. -m

Thanks Mike, That's what I thought. I had searched everywhere to see if it was a function of the hub or not. Thanks. Chuck.. At 05:23 PM 03/09/1998 -0600, you wrote: >The RADIUS server.. It must keep a database of who is logged in and not >auth dupe logins.. > >-m >

So you would have us believe that K56flex or whatever its being called today, is better than X2? I'm going to have to seriously disagree with you here. Regardless of your opinion of yon Boardwatch writer, or his likes, X2 has consistently been the more reliable protocol every time. K56Flex has been nothing but a pain in our ass from the get go, and say what you may about his procedures and methods, our methods are simple, we just watch our userbase. Granted we can't do national tests but I don't think we need to, being in several large cities tells us all we need to know about which works better. On Mon, Mar 09, 1998 at 01:57:35PM -0800, MegaZone stated > Once upon a time Allen Marsalis shaped the electrons to say... > >faster on average than kflex across 89 national isps.. Can only imagine > >what MZ thinks of Jack and his methods.. > > I'd laugh at him if only so many people weren't so gullible as to believe his > reports. He's a hazard. > > I've met Jack and was less impressed in person than through his written > reports. Good businessman, bad tester and analyst. > > -MZ > -- > <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human being, me > "A little nonsense now and then, is relished by the wisest men" 781-788-0130 > <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail Discordia! > > - > 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. -- #define SIGHEIL 40 /* fascist process has taken control of cpu */

As of today, 3/9, it's almost impossible for me to connect my Courier to = my provider in Hilo, HI. I get a connect at 48,000, but within a few seconds= , the ARQ light on my Courier goes out, and there's such a high error rate that when data does comes through, it's only a little, sort of like a 300-baud modem, except that when data does come, it spurts out real fast. [As of 3/2, the connect rate I was getting was almost always 37.3, around 3/2 it took a sudden jump to 46-49k with 48k the most common. From about 10/26 - 3/2 the connect rate was 37.3, but often with high error rates, retrains, downshifts, and disconnects, although it got pretty solid around 2/98. 10/6-10/26/97-speed was 48k and reliable. 6/97-10/97 x2 connect impossible on all local #s.] I have seen *a large number* of posts in the Prodigy groups about similar problems in other areas of the country - ie, connect but can't go anywher= e or do anything. I used Procomm to dial IBM - Hilo, and am pasting the session. Note the connect rate (48000) and the rate reported in i6 as well as blers and CHA= RS RECEIVED & SENT. I then tried calling another ISP in Hilo; same thing - the ARQ light goes OUT - doesn't even blink, but some data gets through. You'll see me logon= as guest here, and notice the time on the i6 display, and also note the CHAR= S RECEVEIED - ZERO even though you can see it's not! I then tried calling an ISP in Kona (different CO - GTD5; Hilo has DMS100= ) - and I got a connection that would work. About 1 out of 10 I can get a connection that works (although I've had th= ree disconnects today) calling Hilo. About 1 out of 2 of the connections tha= t works downtrains to 33,333 or as low as 26,400 but still with a blinking = ARQ light. Excuse me, but damn, this is getting frustrating! I'm thinking of trying &N&U (although they've never worked for me before) and flashing my modem back to the 2/97 firmware..... Anyway, here's the terminal session paste: CONNECT 48000/ARQ/x2/LAPM/V42BIS ********************************************** Welcome to the IBM Global Network ********************************************** Enter dial script version =3D=3D> Gateway:834AL Chassis:6 Port:9 Select one of the following services: INTERNET SECUREIP DUALACCESS FIXEDIP Enter service =3D=3D> Enter account userID password [/new_password]=3D=3D> OK ati6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 0 Chars Received 0 Chars lost 0 Octets sent 18 Octets Received 295 Blocks sent 18 Blocks Received 11 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 976 Link Timeouts 0 Link Naks 0 Data Compression V42BIS 2048/32 Equalization Long Fallback Enabled Protocol LAPM SREJ 128/15 Speed 33333/26400 Current Call 00:01:03 ato Online OK at i6 USRobotics Courier V.Everything Link Diagnostics... Modulation x2/V.34+ Carrier Freq ( Hz ) NONE/1920 Symbol Rate 8000/3200 Trellis Code NONE/64S-4D Nonlinear Encoding NONE/ON Precoding NONE/OFF Shaping OFF/ON Preemphasis Index NONE/8 Recv/Xmit Level (-dBm) 20.6/17.0 SNR ( dB ) 36.1 Near Echo Loss ( dB ) 16.6 Far Echo Loss ( dB ) Roundtrip Delay (msec) 6 Timing Offset ( ppm) -943 Carrier Offset ( ppm) 52 RX Upshifts 4 RX Downshifts 4 TX Speedshifts 0 x2 Status 0001; 1000-1000-1000-1000-1010-1000; 00,00 0031;= 03 OK CONNECT 33333/ARQ/x2/LAPM/V42BIS !Error 20 Incorrect account or user ID. ath OK ati6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 22 Chars Received 400 Chars lost 0 Octets sent 22 Octets Received 325 Blocks sent 22 Blocks Received 15 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 1558 Link Timeouts 0 Link Naks 0 Data Compression V42BIS 2048/32 Equalization Long Fallback Enabled Protocol LAPM SREJ 128/15 Speed 33333/26400 Last Call 00:01:36 Disconnect Reason is Escape code OK -same thing to Aloha.net atdt9357029 CONNECT 48000/ARQ/x2/LAPM/V42BIS hawaii-tcr4 login: guest Connected Last login: Mon Mar 9 14:17:00 from maui-tcr2.aloha. Guest Menu - H A W A I I O N L I N E - Internet Services --- -- Services Description & System Information Menu --- -- 1 Hawaii OnLine Overvi OK **(note - the rest of the menu never displayed; look a= t the time online)** at i6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 0 Chars Received 0 Chars lost 0 Octets sent 9 Octets Received 254 Blocks sent 9 Blocks Received 24 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 675 Link Timeouts 0 Link Naks 0 Data Compression V42BIS 2048/32 Equalization Long Fallback Enabled Protocol LAPM SREJ 128/15 Speed 33333/26400 Current Call 00:01:01 Online OK ato CONNECT 33333/ARQ/x2/LAPM/V42BIS OK at i6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 0 Chars Received 0 Chars lost 0 Octets sent 12 Octets Received 254 Blocks sent 12 Blocks Received 24 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 993 Link Timeouts 0 Link Naks 0 Data Compression V42BIS 2048/32 Equalization Long Fallback Enabled Protocol LAPM SREJ 128/15 Speed 33333/26400 Current Call 00:01:27 Online OK at o CONNECT 33333/ARQ/x2/LAPM/V42BIS OK ath OK at i6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 15 Chars Received 423 Chars lost 0 Octets sent 15 Octets Received 254 Blocks sent 15 Blocks Received 24 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 1237 Link Timeouts 0 Link Naks 0 Data Compression V42BIS 2048/32 Equalization Long Fallback Enabled Protocol LAPM SREJ 128/15 Speed 33333/26400 Last Call 00:01:47 Disconnect Reason is Escape code OK to il hawaii - arq light will blink on and off; but doesn't stay off like= to Hilo #s atdt3311999 CONNECT 46666/ARQ/x2/LAPM/V42BIS interLink Hawaii p4s30 login:xxxxxx Password: PPP session from (206.127.242.7) to 206.127.241.16 beginning....~=FF}#=C0!}!}!} }8}! }$}&} }"}&} } } } }%}&})=DF}0=F4}'}"}(}",}3~~=FF}#=C0!}!}"} }8}!}$}&} }"}= &} } } } }% }&}) =DF}0=F4}'}"}(}"f=81~~=FF}#=C0!}!}#} }8}!}$}&} }"}&} } } } }%}&})=DF}0=F4= }'}"}(}"=AF}(~ OK at i6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 0 Chars Received 0 Chars lost 0 Octets sent 18 Octets Received 257 Blocks sent 18 Blocks Received 34 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 2 Link Timeouts 0 Link Naks 0 Data Compression V42BIS 2048/32 Equalization Long Fallback Enabled Protocol LAPM SREJ 128/15 Speed 45333/26400 Current Call 00:00:31 Online OK ath OK at i7 USRobotics Courier V.Everything Configuration Profile... Product type US/Canada External Options HST,V32bis,Terbo,VFC,V34+,x2 Fax Options Class 1,Class 2.0 Clock Freq 20.16Mhz Flash ROM 512k Ram 64k Supervisor date 07/31/97 DSP date 06/06/97 Supervisor rev 7.2.1 DSP rev 2.2.7

Once upon a time William Behrens shaped the electrons to say... >time my TC's support x2). Yes Jack is a very questionable individual but >lets face it, if the tests had proved K56Flex as a better protocol you >would be now hailing Jack as a sound engineer with good methodology. I BULLSHIT, and I resent this statement. I have openly criticised Jack for some time now. I've never liked his methods, even when favorable to Lucent. The ends do not justify the means. I've even corrected things before in favor of other vendors. I case people haven't noticed, I stopped working for Lucent. I don't work for any NAS vendor, so I don't have a stake in what you buy one way or the other. I really don't care if I win people over or piss people off, not that I ever did in the first place. I do both on a regular basis. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human being, me "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail Discordia!

Once upon a time System Administrator shaped the electrons to say... >technology. (Yes, I tried the AS5200, and I can tell you that the >microcom modem firmware was definitely nothing to write home about). You might take a second look with the AS5300 and MICA modems, see if they got any better. The AS5300 is definitely vastly superior to the AS5200 in most areas. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human being, me "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail Discordia!

Well MegaZone I would have to say you have become a little more testy as of late :-). Visiting a TC user list with your condescending attitude will not win over anyone (and if you not here to win people over then why post). This man was speaking from direct experience and its not really a valid point with v.90 being a somewhat valid standard now. I like Livingston products Hell I would have bought PM3's if they would have supported NFAS when I needed them to. I have been happy with my TC's and x2 and I'm sure I would have been happy with PM3's (although they didn't support 56k at the time my TC's support x2). Yes Jack is a very questionable individual but lets face it, if the tests had proved K56Flex as a better protocol you would be now hailing Jack as a sound engineer with good methodology. I believe K56Flex could have been much better if Lucent and Rockwell could have got on the same page. I'll say it again I like Livingston products and I don't make it a habit of bashing them on the Livingston list groups with such bitterness. I hope you get to feeling better. Cheers! William Behrens Director of Network Operations ParaCom Technologies Inc.

Thus spake Mike Wronski >On Mon, 9 Mar 1998, matthew wrote: >> we have found that the best way to control multiple logins is pmmon >> www.pmmon.com >> >> it not only stops it but notifies you. >> >> matthew >> >> >> >How can I disable more than 1 simulatenous logins to netserver.....? >> > >> >TIA >> > >You can use RADIUS.. >1) set Port-Limit = 1 . This will prevent Multilink calls <nit> Not strictly true. You can still connect with Multilink, but its limited to only a single channel in the bundle, so it accomplishes what they were asking for. </nit> -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Kent Tambling >There was a discussion a while back about DNS >functions on the TC. I'm having a problem where >some users are not allowed access to some sites >(mostly telnet) because reverse DNS lookup is failing. >If I telnet into the TC I often notice only the IP number >is listed for an open port, then another 'show sessions' >will cause all of them to update with our PTR records, >'gnv-tc0-ip-port1.accelerate.net' etc.... >I can access all of the sites complained about on any >static IP machine. >I believe the DNS attribute is 'on' when I "show global'. >Should I be ading all these entries to the TC's hosts table? No, that won't help at all. They need to have valid PTR records available in the global DNS. Currently, you have the PTR records in your local DNS server from what I can tell, but do not have your block of IP's delegated down to you correctly from your upstream ISP (most likely...didn't troubleshoot in depth). You need to either: 1) call your upstream ISP about DNS issues 2) read DNS and Bind...published by O'Reilley and Associates (www.ora.com) to get a better understanding of how DNS works. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Have been trying to get radius-assigned packet filters working. I would appreciate any pointers... I've created a simple test filter named "test.fil" to stop web-access: #filter IP: 030 REJECT tcp-dst-port=80; 040 REJECT tcp-src-port=80; It works perfectly when I assign it to a particular interface such by: set interface mod:1 INPUT_FILTER test.fil OUTPUT_FILTER test.fil Anyone loggin on via mod:1 won't be able to access the web. So far so good. However, if I have radius to assign it as an "user filter", nothing happens. I have the following lines in the users file: gpig Password = "UNIX" User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 255.255.255.254, Framed-Netmask = 255.255.255.224, Framed-Routing = Broadcast-Listen, Framed-MTU = 1500, Framed-Filter-Id= test.fil/test.fil, Framed-Compression = Van-Jacobsen-TCP-IP User "gpig" still has access to the web when he logs on. I've also tried using: Framed-Filter-Id= test.fil, or Framed-Filter-Id= "test.fil", but nothing seems to work. BTW, I'm using radius 1.16 from Livingston. Thanks in advance for ANY help. fbsd (a struggling NETServer 16/I newbie)

The customers are running internal Sportster ISDN terminal adapters with no luck another custom has a Bitsurfer and can connect at 64k but not 128k. >What kind of ISDN terminal adapters/routers do your customers have? I know >that CISCO 766 ISDN routers can't properly bind both b's. Motorola >Bitsuffers seem to connect OK. Maybe it's not in your authentication, but a >compatibility issue. > >Mike Hamrich >Telecommunications Director >DrFast.Net, Inc. > > > >---------- >> From: wjordan@pcl.net >> To: usr-tc@lists.xmission.com >> Subject: RE: (usr-tc) 128k ISDN Calls not accepted 64k and others OK >> Date: Saturday, March 07, 1998 4:06 PM >> >> You need Radius running with a database system. We run RadiusNT and >Emerald. >> It really works well for this. don't know if you can support multiple >logins >> without the database. But mainly the database is used to restrict the >number >> of logins. >> >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Bosire >> Sent: Saturday, March 07, 1998 6:09 AM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) 128k ISDN Calls not accepted 64k and others OK >> >> >> >> >> wjordan@pcl.net wrote: >> >> > Make sure you allow more than one simultaneous login for that account. >> > >> >> Hi Jordan ,, >> >> How can I disable more than 1 simulatenous logins to netserver.....? >> >> TIA >> >> > -----Original Message----- >> > From: owner-usr-tc@lists.xmission.com >> > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ken Hunter, >> > Aspiring Technologies >> > Sent: Friday, March 06, 1998 8:37 PM >> > To: usr-tc@lists.xmission.com >> > Subject: Re: (usr-tc) 128k ISDN Calls not accepted 64k and others OK >> > >> > Multilink ppp disabled ? >> > >> > Ken :) >> > >> > At 09:24 PM 3/6/98 -0500, you wrote: >> > >Hi Everyone, >> > > >> > > >> > >I have a problem. We are running a USR TC Network Hub with the quad >> modems. >> > >Our ISDN dialups cannot log in at 128k, but if they connect using >single >> > >channel 64k they have no problem. >> > > >> > >Everyone else, analog X2 dialups are fine. >> > > >> > >Any ideas? >> > > >> > > >> > >- >> > > 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. >> > > >> > - >> > >************************************************************************ >> > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. >> > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. >> > >> > Ken Hunter Aspiring Technologies >> > mailto:ken@aspire.net 9304 Troy Drive >> > http://www.aspire.net Nokesville, Va 20181 >> > >************************************************************************ >> > >> > - >> > 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. >> > >> > - >> > 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. >> >> >> >> -- >> >> \\|// - ? >> (o o) >> +==================================oOOo=(_)=oOOo========+ >> | Richard Bosire rbosire@africaonline.co.ke | >> | AfricaOnline Ltd | >> | union towers, 2nd floor | >> | tel: 254-2-243775 | >> | .oooO | >> | http://www.africaonline.co.ke ( ) Oooo. | >> +===================================\ (==( )==========+ >> \_) ) / >> (_/ >> >> >> >> - >> 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. >> >> >> - >> 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. > >- > 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. > >

Thus spake MegaZone >And I can cite a few dozen posts with 180 degrees from you - your point? >For ever person bitching about K56flex and praising X2 there is someone >bitching about X2 and praising K56flex. So I don't give a fuck. I will definitely agree that this is largely a religious issue at this point, but will try to put in some fairly reasonable, hopefully not too skewed points for what they're worth. :/ >The problem is Jack's test is seriously skewed. From Boardwatch? I'm not surprised. >The K56flex results he >got have not been reflected by a single real world user who followed up, >which is why tens of ISPs are jumping down his throat on portmaster-users >and isp-ceo. He made a poorly architected test, using only connect speeds >(BTW, a friend of mine on the inside tells be X2's connect speeds are >deliberately optimistic and are not the real sustainable speeds - this seems >confirmed by the myriad of reports on scores of lists and newsgroups), My experiences on this are actually the reverse. x2 on the TC hubs seems to be initially pretty pessimistic as most connections I've seen have upshifted after initial connection. This is a fairly limited sample size though, so take it with a grain of salt. >and >then generalized that to the entire K56flex market. When really, even in >his flawed way, all that was being tested was Rockwell client to Rockwell >server - there was one PM user in the batch. He further went on, on the >basis of just that test, to make a comment in public email directly slamming >performance on PMs - a comment he later 'corrected' (retracted). I certainly can't comment on the pm's as I'm so out of touch with the pm equipment at this point. At the time that I was using it there were some minor useability issues, and some major support issues, but being that was a *long* time ago (vintage 3.1.4 ComOS days) I wouldn't even think of accusing Livingston^WLucent of continuing to have these problems. >Just a few minutes ago on PM users was a person talking about how they >just decided to never by 3Com servers and have standardized on PM-3s for >ease of use and superior performance. Right now they have more TCs than >PM-3s, but are frozen on the TC side. They switched from 3Com/USR to >Lucent RABU because their experience was exactly the opposite of yours. 3Com gear certainly has its problems...as does its support (does second-level tech support really even *exist* anymore? I can't seem to get a call-back from them ever), but overall I'm fairly happy with the equipment...though the software could use a bit better QA IMHO. >And for all I know you have Ass-End servers on the K56flex side, or Shiva, >or what have you. Heh...I see you share my love, or lack thereof, of ASND equip. I'm still looking to banish that company from our network (about to eliminate the last of the long-time majorly entrenched Xyplex equip.), but USR's 128Kbps ISDN dial-up just isn't solid enough to really do away with that "fall-back" line. >I do contend that K56flex was a generally superior protocol to X2 in most >regards, including max speed and sustained throughput. But implementations >vary. X2 had the advantage of being primarily a single vendor. My general understanding was that x2 did better on clean lines, but dropped speed dramatically on much impairment, and that k56flex held its speed up better on impaired lines, but on clean lines didn't get as fast as connects as x2. What's better? Eh...depends on where you are I suspect. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Mon, 9 Mar 1998, Brett Hawn wrote: > So you would have us believe that K56flex or whatever its being called > today, is better than X2? I'm going to have to seriously disagree with you > here. Regardless of your opinion of yon Boardwatch writer, or his likes, X2 > has consistently been the more reliable protocol every time. K56Flex has > been nothing but a pain in our ass from the get go, and say what you may > about his procedures and methods, our methods are simple, we just watch our > userbase. Granted we can't do national tests but I don't think we need to, > being in several large cities tells us all we need to know about which works > better. Heh. My ultimate dream is a NAS box that is a compilation of Livingston networking hardware and USR/3Com DSP technology. :) If only ONE box could do what we ALL want, life would be a dream. Actually, let me amend that. The _truely_ ultimate dream would be a compilation of high-end cisco networking hardware and USR/3com modem technology. (Yes, I tried the AS5200, and I can tell you that the microcom modem firmware was definitely nothing to write home about). Regards, Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

Neither will do that. Radius is just that, an authentication server nothing more. Although I have heard that there are hacks to prevent multiple logins. At 08:22 AM 3/10/98 +0300, you wrote: >Hi Chuck ,,, > >Kind of have the same problem here ... > >give me a buzz if you find a solution > >TIA >bosire > >Chuck Simons wrote: > >> Is limiting logins a function of the radius server or of the total control >> rack? >> >> We are using netserver/16 with quad analog modems and are having a heck >> of a time with users logging in multiple times. >> >> The company we get our access from has control of the radius server. I >> have control of the USR rack. >> >> Chuck Simons.. >> >> - >> 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. > > > >-- > > \\|// - ? > (o o) > +==================================oOOo=(_)=oOOo========+ > | Richard Bosire rbosire@africaonline.co.ke | > | AfricaOnline Ltd | > | union towers, 2nd floor | > | tel: 254-2-243775 | > | .oooO | > | http://www.africaonline.co.ke ( ) Oooo. | > +===================================\ (==( )==========+ > \_) ) / > (_/ > > > >- > 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. > >

I have a total control hub with quad modems and netserver and nmc...I would like to have my users be able to dial in on only one chasis(that is all I have) and get 128k isdn dialup...I have read the list and people are talking about terminating isdn calls on certain cards and I am getting a bit lost...I did a "version" from the command line prompt of the netserver and it tells me my isdn configuration is MUNICH32(4)..Can anyone elaborate on if this is a good version or not and also the easiest way to enable my tch to have people get the 128k connections. My concern is with the tch only. I am aware that I have to have the radius setup for multiple logins...Thanks.

Thanks for the reponse. Actually I've got the whole O'Reilley set on the shelf (and read them too), makes for interesting conversation with clients who want to be Internet experts. Keeps me from answering endless questions since the answers are readily available. I took my upstream provider's word for it about the ARIN entries and they were in fact wrong. I'm dealing with it properly now. Thanks for the advice. Kent Tambling Kent@Acceleration.NET www.Acceleration.NET (352) 335-6500 -----Original Message----- >Thus spake Kent Tambling >>There was a discussion a while back about DNS >>functions on the TC. I'm having a problem where >>some users are not allowed access to some sites >>(mostly telnet) because reverse DNS lookup is failing. >>If I telnet into the TC I often notice only the IP number >>is listed for an open port, then another 'show sessions' >>will cause all of them to update with our PTR records, >>'gnv-tc0-ip-port1.accelerate.net' etc.... >>I can access all of the sites complained about on any >>static IP machine. > >>I believe the DNS attribute is 'on' when I "show global'. > >>Should I be ading all these entries to the TC's hosts table? > >No, that won't help at all. They need to have valid PTR records >available in the global DNS. Currently, you have the PTR records in >your local DNS server from what I can tell, but do not have your block >of IP's delegated down to you correctly from your upstream ISP (most >likely...didn't troubleshoot in depth). You need to either: >1) call your upstream ISP about DNS issues >2) read DNS and Bind...published by O'Reilley and Associates >(www.ora.com) to get a better understanding of how DNS works. >-- >Jeff McAdams Email: jeffm@iglou.com >Chief 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.

At 10:31 AM 3/9/98 -0600, Brian wrote: >On Mon, 9 Mar 1998, Charles Sprickman wrote: > >> Has anyone been able to use the Performance Monitor function on any >> version of TCM under NT? Everything else seems to work well, but as soon >> as you've picked any parameters to monitor and you click "OK", Dr. Watson >> arrives with the message that TCM.exe has caused an access violation... > >it works fine for me > Has anyone used TCM on NT Server as well as NT Workstation? Our NT Server box has a nasty memory leak and I am suspecting TCM.. We have other NT Server boxes configured identically but without TCM and they are functioning just fine. Also I noticed the hole develop right before my eyes while using TCM which was about the only thing running at that time.. Just wondering if anyone using NT Server has noticed a major chuck of memory gone and subsequent low virtual memory error messages after using TCM?.. am _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

I'm currently running TCM 5.1.1 on NT server with 9 Netscape windows, Task Manager, Performance Monitor, Netserver, HARM, Adobe Acrobat, Telnet, HomeSite 3.0, MS Outlook (a real hog), MS Access, NAV, and explorer on a machine with "just" 64 MB of RAM. I only have problems when I open several Outlook files or some graphics intensive apps. I used to have more problems when I had more (but cheaper) memory installed on this box. This box currently gets rebooted about twice a week, though. Allen Marsalis wrote: > > At 10:31 AM 3/9/98 -0600, Brian wrote: > >On Mon, 9 Mar 1998, Charles Sprickman wrote: > > > >> Has anyone been able to use the Performance Monitor function on any > >> version of TCM under NT? Everything else seems to work well, but as soon > >> as you've picked any parameters to monitor and you click "OK", Dr. Watson > >> arrives with the message that TCM.exe has caused an access violation... > > > >it works fine for me > > > > Has anyone used TCM on NT Server as well as NT Workstation? Our NT Server > box has a nasty memory leak and I am suspecting TCM.. We have other NT > Server boxes configured identically but without TCM and they are functioning > just fine. Also I noticed the hole develop right before my eyes while > using TCM which was about the only thing running at that time.. Just > wondering if anyone using NT Server has noticed a major chuck of memory > gone and subsequent low virtual memory error messages after using TCM?.. > > am > > _____________________________________________________________ > Allen Marsalis > President Voice: 318.222.2NET (2638) > Shrevenet, Inc. mailto:am@shreve.net > 333 Texas St. Suite 619 FAX: 318.221.6612 > Shreveport, LA 71101 http://www.shreve.net > _____________________________________________________________ > Thoughtful Provider of Internet Services > > - > 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. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

On Sun, 8 Mar 1998, Tatai SV Krishnan wrote: > Well this is not working since, the Radius is sending the test.fil as the > filter name and the HiPer ARC is looking for test.fil.in and test.fil.out > as filters and since there is not test.fil.in and test.fil.out the filter > is not working. This was set up this way to be compatable with > NETServer. However there are ER releases which will allow you to work > the way you have setup here. HiPer ARC? Do I have that (whatever that is) on my NETServer 16/I? Lastly, what are "ER releases?" Sorry for all these newbie questions. fbsd

> Framed-Filter-Id= test.fil/test.fil, Try: Framed-Filter-Id = test, That's what we use here with the TC - I imagine it'd be the same, since this sort of stuff needs to interoperate between vendors and boxes. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Be a little leary of the AS5300 for a little while longer now. We put a lot of them into service and had a whole bunch of trouble. The As5300 has some troubles with 5ESS phone switches. We had Cisco come out and they have gotten them working very nicely now, but we almost felt like a beta-test site at times. Still have some issues we are working out with Cisco at this time, but we are liking them. -dnr

At 04:38 PM 3/9/98 -0800, MegaZone scribed with a stick: >Once upon a time Brett Hawn shaped the electrons to say... >>So you would have us believe that K56flex or whatever its being called >>today, is better than X2? I'm going to have to seriously disagree with you >>here. Regardless of your opinion of yon Boardwatch writer, or his likes, X2 >>has consistently been the more reliable protocol every time. K56Flex has >>been nothing but a pain in our ass from the get go, and say what you may > >And I can cite a few dozen posts with 180 degrees from you - your point? >For ever person bitching about K56flex and praising X2 there is someone >bitching about X2 and praising K56flex. So I don't give a fuck. Now be honest MZ, you most certainly do give a fuck. And I respect that. At least you have an opinion and give a fuck.. Otherwise you would be lame and truly a waste of bandwidth.. but you're not IMO.. a "devil's advocate" approach is good analysis.. And I'm not always smart enough to do my homework.. And you are obviously smart when it comes to NASing.. >The problem is Jack's test is seriously skewed. The K56flex results he >got have not been reflected by a single real world user who followed up, probably right. like magazine editorial is never skewed?.. >which is why tens of ISPs are jumping down his throat on portmaster-users >and isp-ceo. whole ten's huh.. k56flex must have made deep market penetration elsewhere from our humble region. here it only made deep customer penetration.. :) By the time k56flex is any competition here, it will no longer be an issue and the x2/k56flex war will be over.. or will it? Being V.90 doesn't necessarily mean that performance-wise all manufacturers will all be on the same level. Performance will probably vary significantly when a USR client/host V.90 connection is compared with another. We'll know once V.90 starts to take hold. In fact, I'm counting on it.. We are the perfect testbed since we are 100% USR and we've sold hundreds and hundreds of sportsters in this area by creating the demand.. The x2 to kflex client ratio in this area has to be above 100:1 >He made a poorly architected test, using only connect speeds I'll have to give that to you MZ, didn't sound too scientific to me. So I am writing a little perl script to sample our network and maybe our competitors.. Just for fun.. However there is only one PM in this town that I know of.. and I don't think they can get kflex to work.. they keep waiting to make the big announcement (x2 got TV coverage here). Maybe it will be V.90 by then... >(BTW, a friend of mine on the inside tells be X2's connect speeds are >deliberately optimistic and are not the real sustainable speeds - this seems >confirmed by the myriad of reports on scores of lists and newsgroups), and >then generalized that to the entire K56flex market. When really, even in >his flawed way, all that was being tested was Rockwell client to Rockwell >server - there was one PM user in the batch. He further went on, on the >basis of just that test, to make a comment in public email directly slamming >performance on PMs - a comment he later 'corrected' (retracted). I don't know Jack (Rickard that is ;) But he seems to have an opinion and give a fuck.. So he is alright I guess.. >Just a few minutes ago on PM users was a person talking about how they >just decided to never by 3Com servers and have standardized on PM-3s for >ease of use and superior performance. Right now they have more TCs than >PM-3s, but are frozen on the TC side. They switched from 3Com/USR to >Lucent RABU because their experience was exactly the opposite of yours. Superior performance?.. I'll put our high density hub with twin ARC's up against any PM-3, even for quake.. I'm really not bragging.. It's probably not even a fair comparison. the PM-4 should be interesting since it's makers have seen the other player's hand.. I'll be on the lookout at ispcon.. >And for all I know you have Ass-End servers on the K56flex side, or Shiva, >or what have you. Or not even K56flex.. I mean, how do you *really* know.. listen to each and every carrier.. That would be worse than Pachalbel's Canon over and over. >Does that make your experience a universal truth? No. Does that make the >other users experience a universal truth. No. I'm sure both of you have >exactly the experiences you claim. so neither one is superior to the other? Now there's a thought. >I do contend that K56flex was a generally superior protocol to X2 in most >regards, including max speed and sustained throughput. But implementations >vary. X2 had the advantage of being primarily a single vendor. > It's had lot's of advantages, many of which were not technical.. The marketing was superior to 56Kflex.. USR also understood that customers purchase modems.. not necessarily computers with modems.. Their only mistake was ever taxing ISP's for promoting x2 sportster and courier sales by charging for x2 and for running the Sally ride ad on network TV.. (we ran it on cable at no charge) Anyway, it's good to see you back MZ.. But please don't curse at us.. Generally, your points will be taken into consideration without it.. How's that new job going?.. I guess you aren't recommending to GTE that they purchase 3COM/USR equipment, that's for sure... am _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

I am having the same problem as well. Does anyone have a solution? Steve Buza -----Original Message----- >There was a discussion a while back about DNS >functions on the TC. I'm having a problem where >some users are not allowed access to some sites >(mostly telnet) because reverse DNS lookup is failing. >If I telnet into the TC I often notice only the IP number >is listed for an open port, then another 'show sessions' >will cause all of them to update with our PTR records, >'gnv-tc0-ip-port1.accelerate.net' etc.... >I can access all of the sites complained about on any >static IP machine. > >I believe the DNS attribute is 'on' when I "show global'. > >Should I be ading all these entries to the TC's hosts table? > >Thanks, > >Kent Tambling >Systems Support >Kent@Acceleration.NET >www.Acceleration.NET > >- > 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. >

At 09:11 PM 3/9/98 -0500, System Administrator wrote: > >Heh. My ultimate dream is a NAS box that is a compilation of Livingston >networking hardware and USR/3Com DSP technology. :) If only ONE box >could do what we ALL want, life would be a dream. It could.. with some NAS industry standards and conventions for hardware. >Actually, let me amend that. The _truely_ ultimate dream would be a >compilation of high-end cisco networking hardware and USR/3com modem >technology. (Yes, I tried the AS5200, and I can tell you that the >microcom modem firmware was definitely nothing to write home about). > An open ended chassis based on an industry standard form factor manufactured by cisco, usr, or a variety of choices would be a dream.. Standardizing the card slots and packet bus has *alot* of advantages. The idea is to promote third party developement of hardware and software instead of shunning it.. Third party developement is the evolution of all computer related industries.. It's a tremendous unstoppable force. "How do I sign-up to become a certified 3COM/USR developer?" or a "Z48" form factor developer or something like that.. So I can add my technology to the picture.. How about a dual powersupply by APC that's actually a single powersupply integrated with a small "high-density" ups for a true pop in a box.. Or an xDSL access card from pairgain.. Or a vocaltec IP telephony card. Might be stretching it a bit with these examples but having some standards is a good thing right? Like 19" racks.. I guess it's just too early for this sort of thing.. Or the NAS market is too vertical.. As it is now, we have to take the bad with the good and sometimes pay twice for the priviledge.. am _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

On Tue, 10 Mar 1998, Brian wrote: > > If anyone knows how to add a route to the ARC for the pool, I suppose that > would help me also, since it would eliminate all this. The manual says > "aggregate" should cause a route to be "immediatly" added to the local > routing table, this is not the case however. > > add ip route 208.214.44.0/25 gateway 208.206.76.35 > > but it says you cant use the arc as a gateway! > > dying for an answer on this, icmp redirects look messy, they flood the > console. This is the way you do it. Add IP pool <poolname> initial address 208.214.44.1 set ip pool <poolname> size <size> route agg Now whey you do this you will not see in list ip route the route being advertised. However this route will be seen if you do a snoop or from the network. You see list ip route follows a different path and it cannot show you the route, but the route will be advertised on the wire. krish > > Brian > > > > On Tue, 10 Mar 1998, Brian wrote: > > > I have an IP pool setup on an ARC as follows: > > > > Name Address Size InUse State Route Status > > shreveport1 208.214.044.001 /25 126 73 PUBLIC AGGREGATE ACTIVE > > > > Ok, so I beleive this is correct. > > > > now I problem is this: I thought that by creating the pool, the ARC would > > add an entry to its routing table for the pool, I mean, it just makes > > sense right? > > > > It doesn't. It *does* broadcast an aggregate route, and my other ARC's > > add: > > > > 208.214.044.000/25 RIP 208.206.76.35 2 eth:1 > > > > which is fine. But why doesn't the ARC who owns the pool add an entry for > > the route? > > > > This matters. For without the route we have the following lovely > > scenerio: > > > > user gets assigned 208.214.44.5, and connects to our mail server. For > > whatever reason his connection drops. Our mail server tries to goto the > > ARC to find him, but can't, and then follows the default route out of the > > ARC to the router, which goes back to the arc, and we have this icmp > > redirect loop that sucks. > > > > On a netserver, if you add an ippool, and an entry to netmasks, you get a > > route for that pool in the netservers routing table. This route gets > > propogated via rip as well. > > > > Is there something I am missing on the ARC? What do I need to do to get > > the ip pool of 208.214.44.0/25 into the ARC that serves it? I would have > > thought that adding the pool would setup the local entry in the routing > > table, since it *does* add a broadcasted routing entry. > > > > Brian > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > - > > 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. > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > - > 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. >

On Tue, 10 Mar 1998, Brian wrote: > Krish, > > but the problem is, that when an IP is not in use I get this: > > venus:~$ traceroute 208.214.44.250 > traceroute to 208.214.44.250 (208.214.44.250), 30 hops max, 40 byte > packets > 1 stargate.shreve.net (208.206.76.1) 2.499 ms 1.965 ms 4.276 ms > 2 usr1ts2.shreve.net (208.206.76.43) 0.874 ms 0.914 ms 0.829 ms > 3 stargate.shreve.net (208.206.76.1) 2.639 ms 389.137 ms 2.856 ms > 4 usr1ts2.shreve.net (208.206.76.43) 1.92 ms 1.554 ms 1.62 ms > 5 stargate.shreve.net (208.206.76.1) 4.66 ms 3.942 ms 4.651 ms > 6 usr1ts2.shreve.net (208.206.76.43) 2.666 ms 3.227 ms 9.934 ms > . Set this command on the HiPer ARC enable ip address_pool_filtering krish > . > . > > continuously, nonstop. usr1ts2, an ARC, should not try to look back to > its defaultroute (our cisco "stargate") to find this person, since > 208.214.44.128/25 is its very own ip pool! I think there is something > very the matter here, since my linux servers are being "flooded" with ICMP > redirects and I'm really not liking this. > > # tcpdump -i eth0 |grep icmp > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > usr1-250.shreve.net to host stargate.shreve.net > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > usr1-250.shreve.net to host stargate.shreve.net > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > usr1-250.shreve.net to host stargate.shreve.net > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > usr1-250.shreve.net to host stargate.shreve.net > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > usr1-250.shreve.net to host stargate.shreve.net > > *not good* > > stargate, the cisco, has a route in its routing table for > 208.214.44.128/25, of course since it was sent out via a RIP update, and > sends it right back to usr1ts2, which sends right back to stargate. The > result is a ICMP storm on my network which *is* effecting performance. > > HiPer>> list ip pool > > IP ADDRESS POOLS > Name Address Size InUse State Route Status > shreveport2 208.214.044.129 /25 126 66 PUBLIC AGGREGATE ACTIVE > > > *if* there is a route on my ARC, then why this: > > HiPer>> trace 208.214.44.250 > > HOP IP ADDRESS ROUND TRIP TIME > 1 208.206.76.1 0 > 2 208.206.76.43 0 > 3 208.206.76.1 0 > 4 208.206.76.43 10 > 5 208.206.76.1 0 > 6 208.206.76.43 0 > 7 208.206.76.1 10 > . > . > . > > The ip pool statment clearly shows that I have an ip pool defined > 208.214.44.128/25, and 208.214.44.250 is well within the scope of that > pool............so why would the ARC look to the cisco? why the icmp > storms? my netservers dont behave like this, and maybe I just need you to > take a look around the arc...........let me know > > Brian > > > On Tue, 10 Mar 1998, Tatai SV Krishnan wrote: > > > On Tue, 10 Mar 1998, Brian wrote: > > > > > > > > If anyone knows how to add a route to the ARC for the pool, I suppose that > > > would help me also, since it would eliminate all this. The manual says > > > "aggregate" should cause a route to be "immediatly" added to the local > > > routing table, this is not the case however. > > > > > > add ip route 208.214.44.0/25 gateway 208.206.76.35 > > > > > > but it says you cant use the arc as a gateway! > > > > > > dying for an answer on this, icmp redirects look messy, they flood the > > > console. > > > > This is the way you do it. > > > > Add IP pool <poolname> initial address 208.214.44.1 > > set ip pool <poolname> size <size> route agg > > > > Now whey you do this you will not see in list ip route the route being > > advertised. > > > > However this route will be seen if you do a snoop or from the network. > > > > You see list ip route follows a different path and it cannot show you the > > route, but the route will be advertised on the wire. > > > > krish > > > > > > > > Brian > > > > > > > > > > > > On Tue, 10 Mar 1998, Brian wrote: > > > > > > > I have an IP pool setup on an ARC as follows: > > > > > > > > Name Address Size InUse State Route Status > > > > shreveport1 208.214.044.001 /25 126 73 PUBLIC AGGREGATE ACTIVE > > > > > > > > Ok, so I beleive this is correct. > > > > > > > > now I problem is this: I thought that by creating the pool, the ARC would > > > > add an entry to its routing table for the pool, I mean, it just makes > > > > sense right? > > > > > > > > It doesn't. It *does* broadcast an aggregate route, and my other ARC's > > > > add: > > > > > > > > 208.214.044.000/25 RIP 208.206.76.35 2 eth:1 > > > > > > > > which is fine. But why doesn't the ARC who owns the pool add an entry for > > > > the route? > > > > > > > > This matters. For without the route we have the following lovely > > > > scenerio: > > > > > > > > user gets assigned 208.214.44.5, and connects to our mail server. For > > > > whatever reason his connection drops. Our mail server tries to goto the > > > > ARC to find him, but can't, and then follows the default route out of the > > > > ARC to the router, which goes back to the arc, and we have this icmp > > > > redirect loop that sucks. > > > > > > > > On a netserver, if you add an ippool, and an entry to netmasks, you get a > > > > route for that pool in the netservers routing table. This route gets > > > > propogated via rip as well. > > > > > > > > Is there something I am missing on the ARC? What do I need to do to get > > > > the ip pool of 208.214.44.0/25 into the ARC that serves it? I would have > > > > thought that adding the pool would setup the local entry in the routing > > > > table, since it *does* add a broadcasted routing entry. > > > > > > > > Brian > > > > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > > > > > > - > > > > 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. > > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > > - > > > 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. > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > - > 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. >

Is there a hack of radius nt where the tracking of concurrent logins is enabled? ken :) - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

Mike Wronski wrote: > On Mon, 9 Mar 1998, matthew wrote: > > > we have found that the best way to control multiple logins is pmmon > > www.pmmon.com > > > > it not only stops it but notifies you. > > > > matthew > > > > > > >How can I disable more than 1 simulatenous logins to netserver.....? > > > > > >TIA > > > > > You can use RADIUS.. > > 1) set Port-Limit = 1 . This will prevent Multilink calls > 2) Use a RADIUS that supports Max Concurrent Sessions. Hi Can this work with my current settings .. Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.3.28 Build date: Dec 13 1996 Build time: 13:54:59 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Enhanced Licensed for 60 ports. TIA bosire > > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

Hi Chuck ,,, Kind of have the same problem here ... give me a buzz if you find a solution TIA bosire Chuck Simons wrote: > Is limiting logins a function of the radius server or of the total control > rack? > > We are using netserver/16 with quad analog modems and are having a heck > of a time with users logging in multiple times. > > The company we get our access from has control of the radius server. I > have control of the USR rack. > > Chuck Simons.. > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

Mike wrote: > At 05:12 PM 3/9/98 -0600, you wrote: > >Is limiting logins a function of the radius server or of the total control > >rack? > > > >We are using netserver/16 with quad analog modems and are having a heck > >of a time with users logging in multiple times. > > > >The company we get our access from has control of the radius server. I > >have control of the USR rack. > > > The RADIUS server.. It must keep a database of who is logged in and not > auth dupe logins.. Hi Mike .. Can you suggest a solution for this .. I have the same problem ....!! cheers & TIA bosire > > > -m > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

Newsgroups: 3com.totalservice.support I'm seeing lots of different disconnect reasons, but when a customer complains about a series of unwanted disconnects it's almost always ds0Teardown. I rarely see ds0Teardown when the user wants to disconnect, or even when it's line noise. When talking to USR's tech support, the tech wanted to know the disconnect reasons, so I started gathering them. I have the reason for every disconnect from every call on every box for the last month or two. On request I sent USR a breakout of the disconnect reasons. For your amusement, here they are again: 21360 v42DisconnectCmd 10293 ds0Teardown 5684 none 5212 rcvdGatewayDiscCmd 1646 retransmitLimit 933 carrierLoss 413 397 linkDisconnectMsgReceived 382 unableToRetrain 367 v32Cleardown 87 v42InvalidCodeWord 54 v42InvalidCommand 48 pbOutOfSequenceFrame 20 v42BadSetup 7 v42StringToLong 7 managementCommand 6 dtrDrop 1 dspInterruptTimeout I wish I had a solution to the problem. We've tried different init strings, some of which seem to work, but the problem always reappears. Some of the users I can dismiss as having line noise problems, but not all of them. Many of the users getting disconnects have no problems at all on our analog lines. I've already lost several customers, and I'll probably lose more. This is a major problem, but USR tech support denies its existance. I'm already looking at other similar products. If the V.90 code doesn't fix the problem, I'll be switching to something else for all future purchases. Bill Dyess Vice President GulfNet Technologies David Bolen wrote in message ... >In article <6dpnns$fjp$1@tempest.nsd.usr.com> "john bittner" <john@simlab.net> writes: > >>Anyone having problems with people just droping off for no reason. >> >>Error on USR box is ds0 Teardown anyone know what this is . > >Providing that you're talking about a total control chassis... > >This is a telco disconnect - it means that the hangup was remotely >initiated from the other end of the phone call - the TC gear sees this >as a disconnect request from the phone network. This might be the >remote user breaking the call (e.g., reset or pulling the phone plug), >the remote modem deciding to hang up (either normally or due to a >perception of an error) or something going wrong within the phone >network itself that broke the call from the "middle." Unfortunately, >it's a pretty big bucket, which covers a lot of "normal" call >disconnects in addition to abnormal ones. ... My modem: at z OK at&n19&u14 OK atdt9345201 CONNECT 37333/x2/NONE NO CARRIER at i6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 1 Chars Received 0 Chars lost 0 Octets sent 0 Octets Received 0 Blocks sent 0 Blocks Received 0 Blocks resent 0 Retrains Requested 0 Retrains Granted 1 Line Reversals 0 Blers 0 Link Timeouts 0 Link Naks 0 Data Compression NONE Equalization Long Fallback Enabled Protocol NONE Speed 37333/000 Last Call 00:00:13 Disconnect Reason is GSTN Cleardown OK at&u15&n19 OK atdt9345201 NO CARRIER at i6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 0 Chars Received 0 Chars lost 0 Octets sent 0 Octets Received 0 Blocks sent 0 Blocks Received 0 Blocks resent 0 Retrains Requested 0 Retrains Granted 1 Line Reversals 0 Blers 0 Link Timeouts 0 Link Naks 0 Data Compression NONE Equalization Long Fallback Enabled Protocol NONE Speed 37333/000 Last Call 00:00:13 Disconnect Reason is GSTN Cleardown OK at&u16&n19 OK atdt9345201 NO CARRIER at i6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 0 Chars Received 0 Chars lost 0 Octets sent 0 Octets Received 0 Blocks sent 0 Blocks Received 0 Blocks resent 0 Retrains Requested 0 Retrains Granted 1 Line Reversals 0 Blers 0 Link Timeouts 0 Link Naks 0 Data Compression NONE Equalization Long Fallback Enabled Protocol NONE Speed 37333/000 Last Call 00:00:13 Disconnect Reason is GSTN Cleardown OK at&u18&n20 OK atdt9345201 CONNECT 37333/ARQ/x2/LAPM/V42BIS ********************************************** Welcome to the IBM Global Network ********************************************** Enter dial script version ==> Gateway:834AL Chassis:3 Port:28 Select one of the following services: INTERNET SECUREIP DUALACCESS FIXEDIP Enter service ==> OK at i6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 0 Chars Received 0 Chars lost 0 Octets sent 8 Octets Received 252 Blocks sent 8 Blocks Received 9 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 0 Link Timeouts 0 Link Naks 0 Data Compression V42BIS 2048/32 Equalization Long Fallback Enabled Protocol LAPM SREJ 128/15 Speed 29333/26400 Current Call 00:00:27 Online OK ato CONNECT 37333/ARQ/x2/LAPM/V42BIS !Error 10 The service requested is not defined. Please contact customer support . NO CARRIER at i6 USRobotics Courier V.Everything Link Diagnostics... Chars sent 17 Chars Received 394 Chars lost 0 Octets sent 17 Octets Received 323 Blocks sent 17 Blocks Received 13 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 1 Link Timeouts 0 Link Naks 0 Data Compression V42BIS 2048/32 Equalization Long Fallback Enabled Protocol LAPM SREJ 128/15 Speed 29333/26400 Last Call 00:00:49 Disconnect Reason is DISC Received

Any pointers on what to hack in particular ??..... Eric C Forcey wrote: > Neither will do that. Radius is just that, an authentication server nothing > more. Although I have heard that there are hacks to prevent multiple logins. > > At 08:22 AM 3/10/98 +0300, you wrote: > >Hi Chuck ,,, > > > >Kind of have the same problem here ... > > > >give me a buzz if you find a solution > > > >TIA > >bosire > > > >Chuck Simons wrote: > > > >> Is limiting logins a function of the radius server or of the total control > >> rack? > >> > >> We are using netserver/16 with quad analog modems and are having a heck > >> of a time with users logging in multiple times. > >> > >> The company we get our access from has control of the radius server. I > >> have control of the USR rack. > >> > >> Chuck Simons.. > >> > >> - > >> 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. > > > > > > > >-- > > > > \\|// - ? > > (o o) > > +==================================oOOo=(_)=oOOo========+ > > | Richard Bosire rbosire@africaonline.co.ke | > > | AfricaOnline Ltd | > > | union towers, 2nd floor | > > | tel: 254-2-243775 | > > | .oooO | > > | http://www.africaonline.co.ke ( ) Oooo. | > > +===================================\ (==( )==========+ > > \_) ) / > > (_/ > > > > > > > >- > > 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. > > > > > > - > 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.

Hi Zhang .. What version of radius are you using ?.. TIA bosire Zhang Hongzhong wrote: > I'm using Ascend AAC 1.0ai9 radius server limiting concurrent logins, It > worked fine > for me. It supports USR attributes too. > > BG/jamesz > > >X-Sender: eric@mail.psnw.com > >Date: Mon, 09 Mar 1998 21:34:08 -0800 > >To: usr-tc@lists.xmission.com > >From: Eric C Forcey <eric@psnw.com> > >Subject: Re: (usr-tc) Limiting concurrent Logins > >References: <3.0.32.19980306020914.017247f0@mercury.shreve.net> > > <3.0.3.32.19980309171229.0070cd64@simons.net> > >Sender: owner-usr-tc@lists.xmission.com > >Reply-To: usr-tc@lists.xmission.com > > > > > >Neither will do that. Radius is just that, an authentication server nothing > >more. Although I have heard that there are hacks to prevent multiple logins. > > > >At 08:22 AM 3/10/98 +0300, you wrote: > >>Hi Chuck ,,, > >> > >>Kind of have the same problem here ... > >> > >>give me a buzz if you find a solution > >> > >>TIA > >>bosire > >> > >>Chuck Simons wrote: > >> > >>> Is limiting logins a function of the radius server or of the total control > >>> rack? > >>> > >>> We are using netserver/16 with quad analog modems and are having a heck > >>> of a time with users logging in multiple times. > >>> > >>> The company we get our access from has control of the radius server. I > >>> have control of the USR rack. > >>> > >>> Chuck Simons.. > >>> > >>> - > >>> 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. > >> > >> > >> > >>-- > >> > >> \\|// - ? > >> (o o) > >> +==================================oOOo=(_)=oOOo========+ > >> | Richard Bosire rbosire@africaonline.co.ke | > >> | AfricaOnline Ltd | > >> | union towers, 2nd floor | > >> | tel: 254-2-243775 | > >> | .oooO | > >> | http://www.africaonline.co.ke ( ) Oooo. | > >> +===================================\ (==( )==========+ > >> \_) ) / > >> (_/ > >> > >> > >> > >>- > >> 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. > >> > >> > > > >- > > 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. > > > > > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

You don't need a hack of it. RadiusNT (at least version 2.2) has concurrency checking built in. It works pretty well too. Peter D. Mayer NetWalk Tech Support dmayer@netwalk.com -----Original Message----- Is there a hack of radius nt where the tracking of concurrent logins is enabled? ken :) - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

> > Ascend Access Control 1.0ai9, you can get free 30-days test-drive release from > Ascend ftp site: ftp.ascend.com/pub/software-release/aac/current/ doesn't exist, can you clarify, please. > > BG/jamesz > > > At 10:21 AM 3/10/98 +0300, you wrote: > >Hi Zhang .. > > > >What version of radius are you using ?.. > > > >TIA > > > >bosire > > > >Zhang Hongzhong wrote: > > > >> I'm using Ascend AAC 1.0ai9 radius server limiting concurrent logins, It > >> worked fine > >> for me. It supports USR attributes too. > >> > >> BG/jamesz > >> > >> >X-Sender: eric@mail.psnw.com > >> >Date: Mon, 09 Mar 1998 21:34:08 -0800 > >> >To: usr-tc@lists.xmission.com > >> >From: Eric C Forcey <eric@psnw.com> > >> >Subject: Re: (usr-tc) Limiting concurrent Logins > >> >References: <3.0.32.19980306020914.017247f0@mercury.shreve.net> > >> > <3.0.3.32.19980309171229.0070cd64@simons.net> > >> >Sender: owner-usr-tc@lists.xmission.com > >> >Reply-To: usr-tc@lists.xmission.com > >> > > >> > > >> >Neither will do that. Radius is just that, an authentication server > nothing > >> >more. Although I have heard that there are hacks to prevent multiple > logins. > >> > > >> >At 08:22 AM 3/10/98 +0300, you wrote: > >> >>Hi Chuck ,,, > >> >> > >> >>Kind of have the same problem here ... > >> >> > >> >>give me a buzz if you find a solution > >> >> > >> >>TIA > >> >>bosire > >> >> > >> >>Chuck Simons wrote: > >> >> > >> >>> Is limiting logins a function of the radius server or of the total > control > >> >>> rack? > >> >>> > >> >>> We are using netserver/16 with quad analog modems and are having a heck > >> >>> of a time with users logging in multiple times. > >> >>> > >> >>> The company we get our access from has control of the radius server. I > >> >>> have control of the USR rack. > >> >>> > >> >>> Chuck Simons.. > >> >>> > >> >>> - > >> >>> 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. > >> >> > >> >> > >> >> > >> >>-- > >> >> > >> >> \\|// - ? > >> >> (o o) > >> >> +==================================oOOo=(_)=oOOo========+ > >> >> | Richard Bosire rbosire@africaonline.co.ke | > >> >> | AfricaOnline Ltd | > >> >> | union towers, 2nd floor | > >> >> | tel: 254-2-243775 | > >> >> | .oooO | > >> >> | http://www.africaonline.co.ke ( ) Oooo. | > >> >> +===================================\ (==( )==========+ > >> >> \_) ) / > >> >> (_/ > >> >> > >> >> > >> >> > >> >>- > >> >> 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. > >> >> > >> >> > >> > > >> >- > >> > 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. > >> > > >> > > >> > >> - > >> 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. > > > > > > > >-- > > > > \\|// - ? > > (o o) > > +==================================oOOo=(_)=oOOo========+ > > | Richard Bosire rbosire@africaonline.co.ke | > > | AfricaOnline Ltd | > > | union towers, 2nd floor | > > | tel: 254-2-243775 | > > | .oooO | > > | http://www.africaonline.co.ke ( ) Oooo. | > > +===================================\ (==( )==========+ > > \_) ) / > > (_/ > > > > > > > >- > > 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. > > > > > > - > 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. > =============================================================== Ray Stell stellr@vt.edu (540) 231-4109 KE4TJC 28^D You're in a maze of twisty little passages, all different.

Anyone out understand merrit radius? If you do and are interested in some side work programming this software to meet our specific needs, then I would like to here form you. Please reply directly to me terry@olypen.com. We have a few specific issues, mainly performance related. We also, like everyone else need to limit concurrent logins. The radius servers run on SCO. Thanks to anyone who feels upto the task.

> > Ascend Access Control 1.0ai9, you can get free 30-days test-drive release from > Ascend ftp site: ftp.ascend.com/pub/software-release/aac/current/ got it: /pub/Software-Releases/Access-Control/Incremental/Release-1.0Ai10 > > BG/jamesz > > > At 10:21 AM 3/10/98 +0300, you wrote: > >Hi Zhang .. > > > >What version of radius are you using ?.. > > > >TIA > > > >bosire > > > >Zhang Hongzhong wrote: > > > >> I'm using Ascend AAC 1.0ai9 radius server limiting concurrent logins, It > >> worked fine > >> for me. It supports USR attributes too. > >> > >> BG/jamesz > >> > >> >X-Sender: eric@mail.psnw.com > >> >Date: Mon, 09 Mar 1998 21:34:08 -0800 > >> >To: usr-tc@lists.xmission.com > >> >From: Eric C Forcey <eric@psnw.com> > >> >Subject: Re: (usr-tc) Limiting concurrent Logins > >> >References: <3.0.32.19980306020914.017247f0@mercury.shreve.net> > >> > <3.0.3.32.19980309171229.0070cd64@simons.net> > >> >Sender: owner-usr-tc@lists.xmission.com > >> >Reply-To: usr-tc@lists.xmission.com > >> > > >> > > >> >Neither will do that. Radius is just that, an authentication server > nothing > >> >more. Although I have heard that there are hacks to prevent multiple > logins. > >> > > >> >At 08:22 AM 3/10/98 +0300, you wrote: > >> >>Hi Chuck ,,, > >> >> > >> >>Kind of have the same problem here ... > >> >> > >> >>give me a buzz if you find a solution > >> >> > >> >>TIA > >> >>bosire > >> >> > >> >>Chuck Simons wrote: > >> >> > >> >>> Is limiting logins a function of the radius server or of the total > control > >> >>> rack? > >> >>> > >> >>> We are using netserver/16 with quad analog modems and are having a heck > >> >>> of a time with users logging in multiple times. > >> >>> > >> >>> The company we get our access from has control of the radius server. I > >> >>> have control of the USR rack. > >> >>> > >> >>> Chuck Simons.. > >> >>> > >> >>> - > >> >>> 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. > >> >> > >> >> > >> >> > >> >>-- > >> >> > >> >> \\|// - ? > >> >> (o o) > >> >> +==================================oOOo=(_)=oOOo========+ > >> >> | Richard Bosire rbosire@africaonline.co.ke | > >> >> | AfricaOnline Ltd | > >> >> | union towers, 2nd floor | > >> >> | tel: 254-2-243775 | > >> >> | .oooO | > >> >> | http://www.africaonline.co.ke ( ) Oooo. | > >> >> +===================================\ (==( )==========+ > >> >> \_) ) / > >> >> (_/ > >> >> > >> >> > >> >> > >> >>- > >> >> 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. > >> >> > >> >> > >> > > >> >- > >> > 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. > >> > > >> > > >> > >> - > >> 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. > > > > > > > >-- > > > > \\|// - ? > > (o o) > > +==================================oOOo=(_)=oOOo========+ > > | Richard Bosire rbosire@africaonline.co.ke | > > | AfricaOnline Ltd | > > | union towers, 2nd floor | > > | tel: 254-2-243775 | > > | .oooO | > > | http://www.africaonline.co.ke ( ) Oooo. | > > +===================================\ (==( )==========+ > > \_) ) / > > (_/ > > > > > > > >- > > 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. > > > > > > - > 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. > =============================================================== Ray Stell stellr@vt.edu (540) 231-4109 KE4TJC 28^D You're in a maze of twisty little passages, all different.

Ken Hunter, Aspiring Technologies said once upon a time: > >Is there a hack of radius nt where the tracking of concurrent logins is >enabled? RADIUS is stateless, so tracking concurrent logins between chassis depends on a few assumptions. The primary assumption is that your chassis never crashes, and you never reboot it. It would be nice if there was an extension in RADIUS to poll the clients to determine who was online.

I have an IP pool setup on an ARC as follows: Name Address Size InUse State Route Status shreveport1 208.214.044.001 /25 126 73 PUBLIC AGGREGATE ACTIVE Ok, so I beleive this is correct. now I problem is this: I thought that by creating the pool, the ARC would add an entry to its routing table for the pool, I mean, it just makes sense right? It doesn't. It *does* broadcast an aggregate route, and my other ARC's add: 208.214.044.000/25 RIP 208.206.76.35 2 eth:1 which is fine. But why doesn't the ARC who owns the pool add an entry for the route? This matters. For without the route we have the following lovely scenerio: user gets assigned 208.214.44.5, and connects to our mail server. For whatever reason his connection drops. Our mail server tries to goto the ARC to find him, but can't, and then follows the default route out of the ARC to the router, which goes back to the arc, and we have this icmp redirect loop that sucks. On a netserver, if you add an ippool, and an entry to netmasks, you get a route for that pool in the netservers routing table. This route gets propogated via rip as well. Is there something I am missing on the ARC? What do I need to do to get the ip pool of 208.214.44.0/25 into the ARC that serves it? I would have thought that adding the pool would setup the local entry in the routing table, since it *does* add a broadcasted routing entry. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

System Administrator said once upon a time: > >On Tue, 10 Mar 1998, Pete Ashdown wrote: > >> Ken Hunter, Aspiring Technologies said once upon a time: >> > >> >Is there a hack of radius nt where the tracking of concurrent logins is >> >enabled? >> >> RADIUS is stateless, so tracking concurrent logins between chassis depends >> on a few assumptions. The primary assumption is that your chassis never >> crashes, and you never reboot it. > >It is stateless, but I believe there is a USR vendor specific RADIUS >attribute that attempts to inform RADIUS servers that a client has >rebooted. This could be used by the server to "dump" all stateful >information for a given client. How about an attribute to state that the client has crashed? I'd sure like that one.

On Tue, 10 Mar 1998, Pete Ashdown wrote: > Ken Hunter, Aspiring Technologies said once upon a time: > > > >Is there a hack of radius nt where the tracking of concurrent logins is > >enabled? > > RADIUS is stateless, so tracking concurrent logins between chassis depends > on a few assumptions. The primary assumption is that your chassis never > crashes, and you never reboot it. It is stateless, but I believe there is a USR vendor specific RADIUS attribute that attempts to inform RADIUS servers that a client has rebooted. This could be used by the server to "dump" all stateful information for a given client. Regards, Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

I'm using Ascend AAC 1.0ai9 radius server limiting concurrent logins, It worked fine for me. It supports USR attributes too. BG/jamesz >X-Sender: eric@mail.psnw.com >Date: Mon, 09 Mar 1998 21:34:08 -0800 >To: usr-tc@lists.xmission.com >From: Eric C Forcey <eric@psnw.com> >Subject: Re: (usr-tc) Limiting concurrent Logins >References: <3.0.32.19980306020914.017247f0@mercury.shreve.net> > <3.0.3.32.19980309171229.0070cd64@simons.net> >Sender: owner-usr-tc@lists.xmission.com >Reply-To: usr-tc@lists.xmission.com > > >Neither will do that. Radius is just that, an authentication server nothing >more. Although I have heard that there are hacks to prevent multiple logins. > >At 08:22 AM 3/10/98 +0300, you wrote: >>Hi Chuck ,,, >> >>Kind of have the same problem here ... >> >>give me a buzz if you find a solution >> >>TIA >>bosire >> >>Chuck Simons wrote: >> >>> Is limiting logins a function of the radius server or of the total control >>> rack? >>> >>> We are using netserver/16 with quad analog modems and are having a heck >>> of a time with users logging in multiple times. >>> >>> The company we get our access from has control of the radius server. I >>> have control of the USR rack. >>> >>> Chuck Simons.. >>> >>> - >>> 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. >> >> >> >>-- >> >> \\|// - ? >> (o o) >> +==================================oOOo=(_)=oOOo========+ >> | Richard Bosire rbosire@africaonline.co.ke | >> | AfricaOnline Ltd | >> | union towers, 2nd floor | >> | tel: 254-2-243775 | >> | .oooO | >> | http://www.africaonline.co.ke ( ) Oooo. | >> +===================================\ (==( )==========+ >> \_) ) / >> (_/ >> >> >> >>- >> 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. >> >> > >- > 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. > >

At 01:52 PM 3/10/98 -0500, you wrote: >On Tue, 10 Mar 1998, Pete Ashdown wrote: > >> Ken Hunter, Aspiring Technologies said once upon a time: >> > >> >Is there a hack of radius nt where the tracking of concurrent logins is >> >enabled? >> >> RADIUS is stateless, so tracking concurrent logins between chassis depends >> on a few assumptions. The primary assumption is that your chassis never >> crashes, and you never reboot it. > >It is stateless, but I believe there is a USR vendor specific RADIUS >attribute that attempts to inform RADIUS servers that a client has >rebooted. This could be used by the server to "dump" all stateful >information for a given client. > Every time a Netserver (3.6+) or a ARC reboot (newer ER's not 4.0.19) there is a RADIUS accounting entry sent. This is Type 40- Acct-Status-Type With a value of 7 - Accounting-on.. This information can signal RADIUS to clear any user in its concurrent session database that was logged into the NAS that was reset. I have seen this implemented at a customer site. -m

: Ken Hunter, Aspiring Technologies said once upon a time: : > : >Is there a hack of radius nt where the tracking of concurrent logins is : >enabled? Pete Ashdown thus responded: : : RADIUS is stateless, so tracking concurrent logins between chassis depends : on a few assumptions. The primary assumption is that your chassis never : crashes, and you never reboot it. : : It would be nice if there was an extension in RADIUS to poll the clients to : determine who was online. That'd be a stretch -- even for RADIUS accounting. As it is that the radacct information has the NAS address and port ID in it, I think it'd make more sense to make the information related to who's online available in the SNMP MIB. The Netserver can't do it now, and Tatai K. said they had no plans to make it do it. Does anybody know if the ARC provides login info in its MIB? Thanks. --- Mark R. Lindsey, mark@datasys.net Internet Engineer, DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190

If anyone knows how to add a route to the ARC for the pool, I suppose that would help me also, since it would eliminate all this. The manual says "aggregate" should cause a route to be "immediatly" added to the local routing table, this is not the case however. add ip route 208.214.44.0/25 gateway 208.206.76.35 but it says you cant use the arc as a gateway! dying for an answer on this, icmp redirects look messy, they flood the console. Brian On Tue, 10 Mar 1998, Brian wrote: > I have an IP pool setup on an ARC as follows: > > Name Address Size InUse State Route Status > shreveport1 208.214.044.001 /25 126 73 PUBLIC AGGREGATE ACTIVE > > Ok, so I beleive this is correct. > > now I problem is this: I thought that by creating the pool, the ARC would > add an entry to its routing table for the pool, I mean, it just makes > sense right? > > It doesn't. It *does* broadcast an aggregate route, and my other ARC's > add: > > 208.214.044.000/25 RIP 208.206.76.35 2 eth:1 > > which is fine. But why doesn't the ARC who owns the pool add an entry for > the route? > > This matters. For without the route we have the following lovely > scenerio: > > user gets assigned 208.214.44.5, and connects to our mail server. For > whatever reason his connection drops. Our mail server tries to goto the > ARC to find him, but can't, and then follows the default route out of the > ARC to the router, which goes back to the arc, and we have this icmp > redirect loop that sucks. > > On a netserver, if you add an ippool, and an entry to netmasks, you get a > route for that pool in the netservers routing table. This route gets > propogated via rip as well. > > Is there something I am missing on the ARC? What do I need to do to get > the ip pool of 208.214.44.0/25 into the ARC that serves it? I would have > thought that adding the pool would setup the local entry in the routing > table, since it *does* add a broadcasted routing entry. > > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Pete Ashdown was heard to say: >RADIUS is stateless, so tracking concurrent logins between chassis depends >on a few assumptions. The primary assumption is that your chassis never >crashes, and you never reboot it. ... and you get every bit of the accounting data ... >It would be nice if there was an extension in RADIUS to poll the clients to >determine who was online. There sorta is, but resource management in V2 is still just as much of a cloodge. There simply is no solid method to do this sort of thing correctly. I modified the USR Radius database to store the last known NAS a user logged into. So, when ever I detect (by what ever means) that a NAS has been rebooted, then I can reset the counters for those users. But USR has changed the way the NetServer restarts so I don't get the same accounting data I was using. (They use some resource management crap that's not even supposed to exist in V1.) --Ricky

Is the USR Total Control equipment year 2000 compliant??? If so, where is this documented? I checked the 3Com web site, and the only page on y2k compliance I could find didn't list the Total Control products at all.

Krish, but the problem is, that when an IP is not in use I get this: venus:~$ traceroute 208.214.44.250 traceroute to 208.214.44.250 (208.214.44.250), 30 hops max, 40 byte packets 1 stargate.shreve.net (208.206.76.1) 2.499 ms 1.965 ms 4.276 ms 2 usr1ts2.shreve.net (208.206.76.43) 0.874 ms 0.914 ms 0.829 ms 3 stargate.shreve.net (208.206.76.1) 2.639 ms 389.137 ms 2.856 ms 4 usr1ts2.shreve.net (208.206.76.43) 1.92 ms 1.554 ms 1.62 ms 5 stargate.shreve.net (208.206.76.1) 4.66 ms 3.942 ms 4.651 ms 6 usr1ts2.shreve.net (208.206.76.43) 2.666 ms 3.227 ms 9.934 ms . . . continuously, nonstop. usr1ts2, an ARC, should not try to look back to its defaultroute (our cisco "stargate") to find this person, since 208.214.44.128/25 is its very own ip pool! I think there is something very the matter here, since my linux servers are being "flooded" with ICMP redirects and I'm really not liking this. # tcpdump -i eth0 |grep icmp 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect usr1-250.shreve.net to host stargate.shreve.net 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect usr1-250.shreve.net to host stargate.shreve.net 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect usr1-250.shreve.net to host stargate.shreve.net 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect usr1-250.shreve.net to host stargate.shreve.net 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect usr1-250.shreve.net to host stargate.shreve.net *not good* stargate, the cisco, has a route in its routing table for 208.214.44.128/25, of course since it was sent out via a RIP update, and sends it right back to usr1ts2, which sends right back to stargate. The result is a ICMP storm on my network which *is* effecting performance. HiPer>> list ip pool IP ADDRESS POOLS Name Address Size InUse State Route Status shreveport2 208.214.044.129 /25 126 66 PUBLIC AGGREGATE ACTIVE *if* there is a route on my ARC, then why this: HiPer>> trace 208.214.44.250 HOP IP ADDRESS ROUND TRIP TIME 1 208.206.76.1 0 2 208.206.76.43 0 3 208.206.76.1 0 4 208.206.76.43 10 5 208.206.76.1 0 6 208.206.76.43 0 7 208.206.76.1 10 . . . The ip pool statment clearly shows that I have an ip pool defined 208.214.44.128/25, and 208.214.44.250 is well within the scope of that pool............so why would the ARC look to the cisco? why the icmp storms? my netservers dont behave like this, and maybe I just need you to take a look around the arc...........let me know Brian On Tue, 10 Mar 1998, Tatai SV Krishnan wrote: > On Tue, 10 Mar 1998, Brian wrote: > > > > > If anyone knows how to add a route to the ARC for the pool, I suppose that > > would help me also, since it would eliminate all this. The manual says > > "aggregate" should cause a route to be "immediatly" added to the local > > routing table, this is not the case however. > > > > add ip route 208.214.44.0/25 gateway 208.206.76.35 > > > > but it says you cant use the arc as a gateway! > > > > dying for an answer on this, icmp redirects look messy, they flood the > > console. > > This is the way you do it. > > Add IP pool <poolname> initial address 208.214.44.1 > set ip pool <poolname> size <size> route agg > > Now whey you do this you will not see in list ip route the route being > advertised. > > However this route will be seen if you do a snoop or from the network. > > You see list ip route follows a different path and it cannot show you the > route, but the route will be advertised on the wire. > > krish > > > > > Brian > > > > > > > > On Tue, 10 Mar 1998, Brian wrote: > > > > > I have an IP pool setup on an ARC as follows: > > > > > > Name Address Size InUse State Route Status > > > shreveport1 208.214.044.001 /25 126 73 PUBLIC AGGREGATE ACTIVE > > > > > > Ok, so I beleive this is correct. > > > > > > now I problem is this: I thought that by creating the pool, the ARC would > > > add an entry to its routing table for the pool, I mean, it just makes > > > sense right? > > > > > > It doesn't. It *does* broadcast an aggregate route, and my other ARC's > > > add: > > > > > > 208.214.044.000/25 RIP 208.206.76.35 2 eth:1 > > > > > > which is fine. But why doesn't the ARC who owns the pool add an entry for > > > the route? > > > > > > This matters. For without the route we have the following lovely > > > scenerio: > > > > > > user gets assigned 208.214.44.5, and connects to our mail server. For > > > whatever reason his connection drops. Our mail server tries to goto the > > > ARC to find him, but can't, and then follows the default route out of the > > > ARC to the router, which goes back to the arc, and we have this icmp > > > redirect loop that sucks. > > > > > > On a netserver, if you add an ippool, and an entry to netmasks, you get a > > > route for that pool in the netservers routing table. This route gets > > > propogated via rip as well. > > > > > > Is there something I am missing on the ARC? What do I need to do to get > > > the ip pool of 208.214.44.0/25 into the ARC that serves it? I would have > > > thought that adding the pool would setup the local entry in the routing > > > table, since it *does* add a broadcasted routing entry. > > > > > > Brian > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > > - > > > 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. > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > - > > 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. > > > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Ascend Access Control 1.0ai9, you can get free 30-days test-drive release from Ascend ftp site: ftp.ascend.com/pub/software-release/aac/current/ BG/jamesz At 10:21 AM 3/10/98 +0300, you wrote: >Hi Zhang .. > >What version of radius are you using ?.. > >TIA > >bosire > >Zhang Hongzhong wrote: > >> I'm using Ascend AAC 1.0ai9 radius server limiting concurrent logins, It >> worked fine >> for me. It supports USR attributes too. >> >> BG/jamesz >> >> >X-Sender: eric@mail.psnw.com >> >Date: Mon, 09 Mar 1998 21:34:08 -0800 >> >To: usr-tc@lists.xmission.com >> >From: Eric C Forcey <eric@psnw.com> >> >Subject: Re: (usr-tc) Limiting concurrent Logins >> >References: <3.0.32.19980306020914.017247f0@mercury.shreve.net> >> > <3.0.3.32.19980309171229.0070cd64@simons.net> >> >Sender: owner-usr-tc@lists.xmission.com >> >Reply-To: usr-tc@lists.xmission.com >> > >> > >> >Neither will do that. Radius is just that, an authentication server nothing >> >more. Although I have heard that there are hacks to prevent multiple logins. >> > >> >At 08:22 AM 3/10/98 +0300, you wrote: >> >>Hi Chuck ,,, >> >> >> >>Kind of have the same problem here ... >> >> >> >>give me a buzz if you find a solution >> >> >> >>TIA >> >>bosire >> >> >> >>Chuck Simons wrote: >> >> >> >>> Is limiting logins a function of the radius server or of the total control >> >>> rack? >> >>> >> >>> We are using netserver/16 with quad analog modems and are having a heck >> >>> of a time with users logging in multiple times. >> >>> >> >>> The company we get our access from has control of the radius server. I >> >>> have control of the USR rack. >> >>> >> >>> Chuck Simons.. >> >>> >> >>> - >> >>> 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. >> >> >> >> >> >> >> >>-- >> >> >> >> \\|// - ? >> >> (o o) >> >> +==================================oOOo=(_)=oOOo========+ >> >> | Richard Bosire rbosire@africaonline.co.ke | >> >> | AfricaOnline Ltd | >> >> | union towers, 2nd floor | >> >> | tel: 254-2-243775 | >> >> | .oooO | >> >> | http://www.africaonline.co.ke ( ) Oooo. | >> >> +===================================\ (==( )==========+ >> >> \_) ) / >> >> (_/ >> >> >> >> >> >> >> >>- >> >> 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. >> >> >> >> >> > >> >- >> > 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. >> > >> > >> >> - >> 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. > > > >-- > > \\|// - ? > (o o) > +==================================oOOo=(_)=oOOo========+ > | Richard Bosire rbosire@africaonline.co.ke | > | AfricaOnline Ltd | > | union towers, 2nd floor | > | tel: 254-2-243775 | > | .oooO | > | http://www.africaonline.co.ke ( ) Oooo. | > +===================================\ (==( )==========+ > \_) ) / > (_/ > > > >- > 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. > >

"Richard Gamberg" <bbhi@prodigy.net> writes: I'm not entirely sure what you are trying to show in this note, since there is no commentary - just output dumps, but I'll comment on those.. > My modem: (...) > at&n19&u14 > OK > atdt9345201 > CONNECT 37333/x2/NONE (...) > Disconnect Reason is GSTN Cleardown > at&u15&n19 > OK > atdt9345201 > NO CARRIER (...) > Disconnect Reason is GSTN Cleardown > at&u16&n19 > OK > atdt9345201 > NO CARRIER (...) > Disconnect Reason is GSTN Cleardown These are artifically created disconnects because you are limiting your connection rates. In these cases you are trying to force your connection to maintain a speed no higher than 30666 (&N19) and no lower than 28800 (&U14), 31200 (&U15) or 33600 (&U16). This is a really limited range. If the modem is unable to maintain this range, you will be forceably disconnected - that's what the GSTN cleardown indicates - it's a retrain to a speed of 0 forcing a disconnect. This disconnect can occur at the initial training of the call, or at any point during the call when the modem has to retrain. My guess is your first example is a case of a retrain - you connected ok, but then immediately retrained out of the permissible range. Note that in the ATI6 output for all of these disconnects the server end requested a retrain, in the first probably just after the connect and in the others probably during the initial connect. Normally the upper bound isn't a problem because the modem will just stay below it, but the problem is if you happen to get an x2 connection, having an upper range of only 30666 gives very little room for x2 to work and it might fail trying to train lower than that within the x2 protocol. To be fair, there have also been various problems with the &U/&N implementation in different client releases as well as some server releases. So I generally don't suggest using them in a production setting if you can avoid it. Also, it can be a little tricky with x2 since the limitation is imposed on a "base" x2 rate (at least in some releases of code if not all) which you don't always see, so while your ATI6 connection may show something like 29333, your "base" rate may actually be like 32000 or 33333. > at&u18&n20 > OK > atdt9345201 > CONNECT 37333/ARQ/x2/LAPM/V42BIS (...) > Speed 29333/26400 > Current Call 00:00:27 > > Online This case probably works because you opened up your upper level to include 32000bps (which may be the base you are at for your 29.3K rate). Or it may be because you increased your lower limit to 29333 and thus both upper and lower are in the x2 range, perhaps getting around some wrinkles in the &N&U support - I'm not sure. But was there a specific problem being targeted here? -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Thus spake Pete Ashdown >How about an attribute to state that the client has crashed? I'd sure like >that one. Actually, I believe the attribute informs the RADIUS server that the client has *booted*, not rebooted or crashed or whatever (for the obvious reason that rebooting it means it quits running so can't send packets to the RADIUS server, so it sends it first thing when it boots). -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Brian <signal@shreve.net> writes: > The ip pool statment clearly shows that I have an ip pool defined > 208.214.44.128/25, and 208.214.44.250 is well within the scope of that > pool............so why would the ARC look to the cisco? why the icmp > storms? my netservers dont behave like this, and maybe I just need you to > take a look around the arc...........let me know Well, presumably the ARC is looking to the Cisco because it doesn't actually have access to that address at the moment so it follows a default or other route back to the Cisco. It's not so much that something is behaving incorrectly given its state (e.g., the traffic is being routed "properly" given the tables involved), but it's an issue of what I'd agree is a bug in how the ARC is doing the aggregate versus its own tables. By announcing an aggregate but not maintaining an equivalent internal route, the ARC is effectively creating an inconsistent routing environment, of which the natural consequence is the loop you see. Part of this is how the ARC deals with an aggregate pool - it creates an aggregate for announcement, but still expects to install per-dialup routes locally. I also think announcing the aggregate even when it has no users is somewhat debatable as an implementation choice - I felt they should have separated the act of aggregation versus non-aggregation of a pool, from the issue of dynamic announcements based on usage versus static announcements, but... I don't know of an immediate way around it - you might want to turn off ICMP redirects on your Cisco just to avoid adding to the traffic storm at least, unless you really need them for some other routing kludge. You might also try adding a route for the dialup pool using the loopback interface of the ARC, to see if it permits that. At a worst case, try adding a route for the aggregate and pointing it to an invalid local IP address - the traffic will blackhole without any packet storm or loops. Ugly, but efficient, and if you get a real dialup user, their host route will be a longer match and override the aggregate route. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

On Tue, 10 Mar 1998, David Bolen wrote: > Brian <signal@shreve.net> writes: > > > The ip pool statment clearly shows that I have an ip pool defined > > 208.214.44.128/25, and 208.214.44.250 is well within the scope of that > > pool............so why would the ARC look to the cisco? why the icmp > > storms? my netservers dont behave like this, and maybe I just need you to > > take a look around the arc...........let me know > > Well, presumably the ARC is looking to the Cisco because it doesn't > actually have access to that address at the moment so it follows a > default or other route back to the Cisco. It's not so much that > something is behaving incorrectly given its state (e.g., the traffic > is being routed "properly" given the tables involved), but it's an > issue of what I'd agree is a bug in how the ARC is doing the > aggregate versus its own tables. > > By announcing an aggregate but not maintaining an equivalent internal > route, the ARC is effectively creating an inconsistent routing > environment, of which the natural consequence is the loop you see. > Part of this is how the ARC deals with an aggregate pool - it creates > an aggregate for announcement, but still expects to install per-dialup > routes locally. right, its so wierd, whats the ideology in not adding an internal route on the arc, yet broadcasting an aggregate? > > I also think announcing the aggregate even when it has no users is > somewhat debatable as an implementation choice - I felt they should > have separated the act of aggregation versus non-aggregation of a > pool, from the issue of dynamic announcements based on usage versus > static announcements, but... > > I don't know of an immediate way around it - you might want to turn > off ICMP redirects on your Cisco just to avoid adding to the traffic > storm at least, unless you really need them for some other routing > kludge. > I don't think I need them.......i'll turn them off. > You might also try adding a route for the dialup pool using the > loopback interface of the ARC, to see if it permits that. > I wish you could add a route for the pool to the eth interface, but it won't allow that, why, i have no idea...............i'll try the loopback. > At a worst case, try adding a route for the aggregate and pointing it > to an invalid local IP address - the traffic will blackhole without > any packet storm or loops. Ugly, but efficient, and if you get a real > dialup user, their host route will be a longer match and override the > aggregate route. assuming 3com's host routes correctly take precedence over there larger aggregate routes :)) fingers crossed The thing is, our mail server has some serious icmp storming going on. 1. user establishes connection to mail server 2. user drop connection, who knows why, who cares 3. the mail server continuously icmp storms until tcp times out when this is going on for a dozen users, its not pretty. Brian > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ > \-----------------------------------------------------------------------/ > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Tue, 10 Mar 1998, Tatai SV Krishnan wrote: > On Tue, 10 Mar 1998, Brian wrote: > > > Krish, > > > > but the problem is, that when an IP is not in use I get this: > > > > venus:~$ traceroute 208.214.44.250 > > traceroute to 208.214.44.250 (208.214.44.250), 30 hops max, 40 byte > > packets > > 1 stargate.shreve.net (208.206.76.1) 2.499 ms 1.965 ms 4.276 ms > > 2 usr1ts2.shreve.net (208.206.76.43) 0.874 ms 0.914 ms 0.829 ms > > 3 stargate.shreve.net (208.206.76.1) 2.639 ms 389.137 ms 2.856 ms > > 4 usr1ts2.shreve.net (208.206.76.43) 1.92 ms 1.554 ms 1.62 ms > > 5 stargate.shreve.net (208.206.76.1) 4.66 ms 3.942 ms 4.651 ms > > 6 usr1ts2.shreve.net (208.206.76.43) 2.666 ms 3.227 ms 9.934 ms > > . > > Set this command on the HiPer ARC > > enable ip address_pool_filtering > > krish > What will this accomplish? Sounds like major overhead since it is turning on a packet filter for the address pool. I added the above, it removed my ip pool. so i did "disable ip address_pool_filtering" and now I am back to where I started. 1. is the above command (enable ip address_pool_filterin) suppose to remove my ippool? 2. If it is, then do I just re-add the pool and all is well, and it won't icmp redirect back and forth anymore? Brian > > . > > . > > > > continuously, nonstop. usr1ts2, an ARC, should not try to look back to > > its defaultroute (our cisco "stargate") to find this person, since > > 208.214.44.128/25 is its very own ip pool! I think there is something > > very the matter here, since my linux servers are being "flooded" with ICMP > > redirects and I'm really not liking this. > > > > # tcpdump -i eth0 |grep icmp > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > usr1-250.shreve.net to host stargate.shreve.net > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > usr1-250.shreve.net to host stargate.shreve.net > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > usr1-250.shreve.net to host stargate.shreve.net > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > usr1-250.shreve.net to host stargate.shreve.net > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > usr1-250.shreve.net to host stargate.shreve.net > > > > *not good* > > > > stargate, the cisco, has a route in its routing table for > > 208.214.44.128/25, of course since it was sent out via a RIP update, and > > sends it right back to usr1ts2, which sends right back to stargate. The > > result is a ICMP storm on my network which *is* effecting performance. > > > > HiPer>> list ip pool > > > > IP ADDRESS POOLS > > Name Address Size InUse State Route Status > > shreveport2 208.214.044.129 /25 126 66 PUBLIC AGGREGATE ACTIVE > > > > > > *if* there is a route on my ARC, then why this: > > > > HiPer>> trace 208.214.44.250 > > > > HOP IP ADDRESS ROUND TRIP TIME > > 1 208.206.76.1 0 > > 2 208.206.76.43 0 > > 3 208.206.76.1 0 > > 4 208.206.76.43 10 > > 5 208.206.76.1 0 > > 6 208.206.76.43 0 > > 7 208.206.76.1 10 > > . > > . > > . > > > > The ip pool statment clearly shows that I have an ip pool defined > > 208.214.44.128/25, and 208.214.44.250 is well within the scope of that > > pool............so why would the ARC look to the cisco? why the icmp > > storms? my netservers dont behave like this, and maybe I just need you to > > take a look around the arc...........let me know > > > > Brian > > > > > > On Tue, 10 Mar 1998, Tatai SV Krishnan wrote: > > > > > On Tue, 10 Mar 1998, Brian wrote: > > > > > > > > > > > If anyone knows how to add a route to the ARC for the pool, I suppose that > > > > would help me also, since it would eliminate all this. The manual says > > > > "aggregate" should cause a route to be "immediatly" added to the local > > > > routing table, this is not the case however. > > > > > > > > add ip route 208.214.44.0/25 gateway 208.206.76.35 > > > > > > > > but it says you cant use the arc as a gateway! > > > > > > > > dying for an answer on this, icmp redirects look messy, they flood the > > > > console. > > > > > > This is the way you do it. > > > > > > Add IP pool <poolname> initial address 208.214.44.1 > > > set ip pool <poolname> size <size> route agg > > > > > > Now whey you do this you will not see in list ip route the route being > > > advertised. > > > > > > However this route will be seen if you do a snoop or from the network. > > > > > > You see list ip route follows a different path and it cannot show you the > > > route, but the route will be advertised on the wire. > > > > > > krish > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > On Tue, 10 Mar 1998, Brian wrote: > > > > > > > > > I have an IP pool setup on an ARC as follows: > > > > > > > > > > Name Address Size InUse State Route Status > > > > > shreveport1 208.214.044.001 /25 126 73 PUBLIC AGGREGATE ACTIVE > > > > > > > > > > Ok, so I beleive this is correct. > > > > > > > > > > now I problem is this: I thought that by creating the pool, the ARC would > > > > > add an entry to its routing table for the pool, I mean, it just makes > > > > > sense right? > > > > > > > > > > It doesn't. It *does* broadcast an aggregate route, and my other ARC's > > > > > add: > > > > > > > > > > 208.214.044.000/25 RIP 208.206.76.35 2 eth:1 > > > > > > > > > > which is fine. But why doesn't the ARC who owns the pool add an entry for > > > > > the route? > > > > > > > > > > This matters. For without the route we have the following lovely > > > > > scenerio: > > > > > > > > > > user gets assigned 208.214.44.5, and connects to our mail server. For > > > > > whatever reason his connection drops. Our mail server tries to goto the > > > > > ARC to find him, but can't, and then follows the default route out of the > > > > > ARC to the router, which goes back to the arc, and we have this icmp > > > > > redirect loop that sucks. > > > > > > > > > > On a netserver, if you add an ippool, and an entry to netmasks, you get a > > > > > route for that pool in the netservers routing table. This route gets > > > > > propogated via rip as well. > > > > > > > > > > Is there something I am missing on the ARC? What do I need to do to get > > > > > the ip pool of 208.214.44.0/25 into the ARC that serves it? I would have > > > > > thought that adding the pool would setup the local entry in the routing > > > > > table, since it *does* add a broadcasted routing entry. > > > > > > > > > > Brian > > > > > > > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > > > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > > > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > > > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > > > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > > > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > > > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > > > > > > > > > > - > > > > > 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. > > > > > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > > > > > > - > > > > 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. > > > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > - > > 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. > > > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Tue, 10 Mar 1998, Brian wrote: > On Tue, 10 Mar 1998, Tatai SV Krishnan wrote: > > > On Tue, 10 Mar 1998, Brian wrote: > > > > > Krish, > > > > > > but the problem is, that when an IP is not in use I get this: > > > > > > venus:~$ traceroute 208.214.44.250 > > > traceroute to 208.214.44.250 (208.214.44.250), 30 hops max, 40 byte > > > packets > > > 1 stargate.shreve.net (208.206.76.1) 2.499 ms 1.965 ms 4.276 ms > > > 2 usr1ts2.shreve.net (208.206.76.43) 0.874 ms 0.914 ms 0.829 ms > > > 3 stargate.shreve.net (208.206.76.1) 2.639 ms 389.137 ms 2.856 ms > > > 4 usr1ts2.shreve.net (208.206.76.43) 1.92 ms 1.554 ms 1.62 ms > > > 5 stargate.shreve.net (208.206.76.1) 4.66 ms 3.942 ms 4.651 ms > > > 6 usr1ts2.shreve.net (208.206.76.43) 2.666 ms 3.227 ms 9.934 ms > > > . > > > > Set this command on the HiPer ARC > > > > enable ip address_pool_filtering > > > > krish > > > > What will this accomplish? Sounds like major overhead since it is turning > on a packet filter for the address pool. > > I added the above, it removed my ip pool. so i did "disable ip > address_pool_filtering" and now I am back to where I started. > > 1. is the above command (enable ip address_pool_filterin) suppose to > remove my ippool? > No It should not remove your IP Pool. Enable IP address pooling is the command that would check to see if the IP address pool is aggregate and if it is it will not direct the request for the IP address query ( ping traceroute etc ) to the gateway. It is not a over head. > 2. If it is, then do I just re-add the pool and all is well, and it won't > icmp redirect back and forth anymore? > Apparently the command enable IP address pooling seems to be broken. Will get it fixed. krish > Brian > > > > > . > > > . > > > > > > continuously, nonstop. usr1ts2, an ARC, should not try to look back to > > > its defaultroute (our cisco "stargate") to find this person, since > > > 208.214.44.128/25 is its very own ip pool! I think there is something > > > very the matter here, since my linux servers are being "flooded" with ICMP > > > redirects and I'm really not liking this. > > > > > > # tcpdump -i eth0 |grep icmp > > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > > usr1-250.shreve.net to host stargate.shreve.net > > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > > usr1-250.shreve.net to host stargate.shreve.net > > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > > usr1-250.shreve.net to host stargate.shreve.net > > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > > usr1-250.shreve.net to host stargate.shreve.net > > > 17:42:37.561464 usr1ts2.shreve.net > mercury.shreve.net: icmp: redirect > > > usr1-250.shreve.net to host stargate.shreve.net > > > > > > *not good* > > > > > > stargate, the cisco, has a route in its routing table for > > > 208.214.44.128/25, of course since it was sent out via a RIP update, and > > > sends it right back to usr1ts2, which sends right back to stargate. The > > > result is a ICMP storm on my network which *is* effecting performance. > > > > > > HiPer>> list ip pool > > > > > > IP ADDRESS POOLS > > > Name Address Size InUse State Route Status > > > shreveport2 208.214.044.129 /25 126 66 PUBLIC AGGREGATE ACTIVE > > > > > > > > > *if* there is a route on my ARC, then why this: > > > > > > HiPer>> trace 208.214.44.250 > > > > > > HOP IP ADDRESS ROUND TRIP TIME > > > 1 208.206.76.1 0 > > > 2 208.206.76.43 0 > > > 3 208.206.76.1 0 > > > 4 208.206.76.43 10 > > > 5 208.206.76.1 0 > > > 6 208.206.76.43 0 > > > 7 208.206.76.1 10 > > > . > > > . > > > . > > > > > > The ip pool statment clearly shows that I have an ip pool defined > > > 208.214.44.128/25, and 208.214.44.250 is well within the scope of that > > > pool............so why would the ARC look to the cisco? why the icmp > > > storms? my netservers dont behave like this, and maybe I just need you to > > > take a look around the arc...........let me know > > > > > > Brian > > > > > > > > > On Tue, 10 Mar 1998, Tatai SV Krishnan wrote: > > > > > > > On Tue, 10 Mar 1998, Brian wrote: > > > > > > > > > > > > > > If anyone knows how to add a route to the ARC for the pool, I suppose that > > > > > would help me also, since it would eliminate all this. The manual says > > > > > "aggregate" should cause a route to be "immediatly" added to the local > > > > > routing table, this is not the case however. > > > > > > > > > > add ip route 208.214.44.0/25 gateway 208.206.76.35 > > > > > > > > > > but it says you cant use the arc as a gateway! > > > > > > > > > > dying for an answer on this, icmp redirects look messy, they flood the > > > > > console. > > > > > > > > This is the way you do it. > > > > > > > > Add IP pool <poolname> initial address 208.214.44.1 > > > > set ip pool <poolname> size <size> route agg > > > > > > > > Now whey you do this you will not see in list ip route the route being > > > > advertised. > > > > > > > > However this route will be seen if you do a snoop or from the network. > > > > > > > > You see list ip route follows a different path and it cannot show you the > > > > route, but the route will be advertised on the wire. > > > > > > > > krish > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > On Tue, 10 Mar 1998, Brian wrote: > > > > > > > > > > > I have an IP pool setup on an ARC as follows: > > > > > > > > > > > > Name Address Size InUse State Route Status > > > > > > shreveport1 208.214.044.001 /25 126 73 PUBLIC AGGREGATE ACTIVE > > > > > > > > > > > > Ok, so I beleive this is correct. > > > > > > > > > > > > now I problem is this: I thought that by creating the pool, the ARC would > > > > > > add an entry to its routing table for the pool, I mean, it just makes > > > > > > sense right? > > > > > > > > > > > > It doesn't. It *does* broadcast an aggregate route, and my other ARC's > > > > > > add: > > > > > > > > > > > > 208.214.044.000/25 RIP 208.206.76.35 2 eth:1 > > > > > > > > > > > > which is fine. But why doesn't the ARC who owns the pool add an entry for > > > > > > the route? > > > > > > > > > > > > This matters. For without the route we have the following lovely > > > > > > scenerio: > > > > > > > > > > > > user gets assigned 208.214.44.5, and connects to our mail server. For > > > > > > whatever reason his connection drops. Our mail server tries to goto the > > > > > > ARC to find him, but can't, and then follows the default route out of the > > > > > > ARC to the router, which goes back to the arc, and we have this icmp > > > > > > redirect loop that sucks. > > > > > > > > > > > > On a netserver, if you add an ippool, and an entry to netmasks, you get a > > > > > > route for that pool in the netservers routing table. This route gets > > > > > > propogated via rip as well. > > > > > > > > > > > > Is there something I am missing on the ARC? What do I need to do to get > > > > > > the ip pool of 208.214.44.0/25 into the ARC that serves it? I would have > > > > > > thought that adding the pool would setup the local entry in the routing > > > > > > table, since it *does* add a broadcasted routing entry. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > > > > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > > > > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > > > > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > > > > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > > > > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > > > > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > 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. > > > > > > > > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > > > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > > > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > > > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > > > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > > > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > > > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > > > > > > > > > > - > > > > > 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. > > > > > > > > > > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > > - > > > 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. > > > > > > > - > > 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. > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > - > 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. >

On Tue, 10 Mar 1998, David Bolen wrote: > Brian <signal@shreve.net> writes: > > > right, its so wierd, whats the ideology in not adding an internal route on > > the arc, yet broadcasting an aggregate? > > Maybe because they didn't have the facility for handling the > destination of the route, as when you have problems pointing it at the > ethernet, since... > > > I wish you could add a route for the pool to the eth interface, but it > > won't allow that, why, i have no idea...............i'll try the loopback. > > But think about it - pointing it at the ethernet is non-sensical, > because what you are trying to create is a route to point traffic back > at itself - in effect a guaranteed routing loop. > > Of course, that's also what we're trying to create with the loopback > interface, but maybe the ARC won't be smart enough to notice and > prevent it in that case :-) > > What the ARC probably really needs is the same sort of concept of a > "Null" interface like a Cisco, or something equivalent, so that it can > install routes used to "absorb" traffic to aggregated blocks when it > has no more specific information for individual users of the block. > This is what exactly the command enable IP address pooling is supposed to do. Apparently that command is broken. The whold idea is to check to see if the route to the IP address belongs to the ARC or not and if it does, check to see if active and send the request/response to the proper IP else do not send the same to any other device/gateway - krish > Pointing at the "bad" address should accomplish the same thing as a > Null interface though, with the expense of one more packet generated > on the wire. > > Unless Krish's comment on the ip address_pool_filtering also > effectively blackholes such traffic, accomplishing the same thing. > It's not well documented in the documentation I have though, so I'm > not quite sure on exactly what this activates... Krish? :-) > > > assuming 3com's host routes correctly take precedence over there larger > > aggregate routes :)) fingers crossed > > That's a pure routing table match, so I don't think you should have a > problem. > > > The thing is, our mail server has some serious icmp storming going on. > > > > 1. user establishes connection to mail server > > 2. user drop connection, who knows why, who cares > > 3. the mail server continuously icmp storms until tcp times out > > > > when this is going on for a dozen users, its not pretty. > > Stopping the ICMP redirects won't stop the retransmitted TCP packets > during session teardown from looping, but that's just a quick ~255 > packets per transmitted packet, without the positive feedback being > created by the ICMP messages. Still ugly, but every little bit can > help. > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ > \-----------------------------------------------------------------------/ > > - > 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. >

Brian <signal@shreve.net> writes: > right, its so wierd, whats the ideology in not adding an internal route on > the arc, yet broadcasting an aggregate? Maybe because they didn't have the facility for handling the destination of the route, as when you have problems pointing it at the ethernet, since... > I wish you could add a route for the pool to the eth interface, but it > won't allow that, why, i have no idea...............i'll try the loopback. But think about it - pointing it at the ethernet is non-sensical, because what you are trying to create is a route to point traffic back at itself - in effect a guaranteed routing loop. Of course, that's also what we're trying to create with the loopback interface, but maybe the ARC won't be smart enough to notice and prevent it in that case :-) What the ARC probably really needs is the same sort of concept of a "Null" interface like a Cisco, or something equivalent, so that it can install routes used to "absorb" traffic to aggregated blocks when it has no more specific information for individual users of the block. Pointing at the "bad" address should accomplish the same thing as a Null interface though, with the expense of one more packet generated on the wire. Unless Krish's comment on the ip address_pool_filtering also effectively blackholes such traffic, accomplishing the same thing. It's not well documented in the documentation I have though, so I'm not quite sure on exactly what this activates... Krish? :-) > assuming 3com's host routes correctly take precedence over there larger > aggregate routes :)) fingers crossed That's a pure routing table match, so I don't think you should have a problem. > The thing is, our mail server has some serious icmp storming going on. > > 1. user establishes connection to mail server > 2. user drop connection, who knows why, who cares > 3. the mail server continuously icmp storms until tcp times out > > when this is going on for a dozen users, its not pretty. Stopping the ICMP redirects won't stop the retransmitted TCP packets during session teardown from looping, but that's just a quick ~255 packets per transmitted packet, without the positive feedback being created by the ICMP messages. Still ugly, but every little bit can help. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Hi: I hate to bother everyone with this question but I am stumped :( . Is there a listing of the reasons for the packet bus disconnects? We seem to get only a few reasons over and over. Mar 10 19:13:33 xs03.phx.primenet.com S11 packet bus disconnected. reason: 10 Mar 10 20:47:13 xs03.phx.primenet.com S27 packet bus disconnected. reason: 99 Mar 10 19:56:26 xs04.phx.primenet.com S17 packet bus disconnected. reason: 8 Mar 10 19:58:19 xs04.phx.primenet.com S26 packet bus disconnected. reason: 23 Reason 8 and 23 are the most common. Thanks for your time. Chris Gruttke Advanced Tech Support GlobalCenter/Primenet cgruttke@primenet.com

Bob Purdon <bobp@southcom.com.au> writes: > Is that *really* the case? For PRI? I was under the impression that > the call would arrive on the D-channel; the PRI card would look for the > necessary resources, and either reject or accept the call. Well, what you describe is what happens, but that leads to the problem that I described, somewhat depending on your hunting sequence, and even if you might have other available channels elsewhere. The "problem" is exactly the fact that the call is going to get rejected unnecessarily. For example, let's assume that your overall hunt group is ascending through a series of hubs. If you end up with more B channels than modems in an early hub in the hunt group, it will suck down calls and never let them get further in the group. That's because the time it takes to accept the call, decide it has no resources, and reject it, is extremely fast. And once the channel is available, the hunt will re-select it for the next call. So the only calls that get "above" that block are those that might occur during the fractions of a second when it is busy rejecting some other call - which is the only time the telco switch things that B channel is occupied. Now, if you have a random, round-robin or least idle hunting pattern you'll be "hurt" less unless your hunt group fills, particularly if your group never fills. But for example, in the UK, we have groups that we have to segment because the switches can't handle call distribution across groups of more than about 64 E1 circuits. So although we have a random distribution, it's random across 64 circuits until they fill, then it moves to randomly fill the next 64 circuits, and so on. But those original 64 circuits stay filled, so effectively you end up with an ascending "hunt" among groups of 64 E1 circuits. I've seen just a single modem "mismatch" (B channel capacity to modems) "absorb" thousands of calls in just a few peak hours in one night, even though there was plenty of capacity in the higher hunt groups - the calls couldn't get past the one channel that the telco thought was available, and was willing to pump calls down as fast as they could be refused. So users get a lot of unnecessary busy signals. > In our case, > a reject generates NU tone. > > We're led to believe that this results in a non-completed call, at zero > cost to the customer (local calls are charged here in Australia). Well, that's probably a local telco issue. You can configure the PRI card to return specific reject codes in the PRI D channel RELEASE message based on what the failure was. What the end user perceives as the result based on that code can differ between telcos, and whether they get normal busies, what we call domestically a "reorder" or fast busy tone (probably the same as your NU tone), or for example in the UK carriers can present either a busy or a solid tone as equivalents. Whether or not there is charging involved may also depend on exactly what code is returned and whether the carrier interprets this as an incomplete call, although my guess that since it is releasing a call during the setup, that it is most likely to be considered incomplete. But that's part of the problem, since having a channel mismatch results in incomplete calls when there's no reason to have any - since presumably other channels and modems are available elsewhere in the hunt group. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Hi, is there a free RADIUS for NT that provides accounting of transferred bytes per user (and that works without big problems with an USR total contrl hub) ? Thanks Martin Oberle

Could you share the name with us Best Regads Rasmus Helmich WebPartner -----Original Message----- >Hi, > >is there a free RADIUS for NT that provides accounting >of transferred bytes per user (and that works without >big problems with an USR total contrl hub) ? > >Thanks > >Martin Oberle > > > >- > 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.

I'm looking for a Comport redirector to provide dial out support with the Netserver or Hiper ARC Router under Windows NT. Does anyone has such a configuration? What is the experience? Is it better to use the Netserver or the Hiper ARC Router for such an application? Any information is wellcom. Thanks a lot Ralph

turners@best.com on 06/03/98 05:44:07 Please respond to usr-tc@lists.xmission.com cc: (bcc: Jason Kelton/AU/3Com) Jason, Thanks for the info but it still leaves me with some questions that I hope can be answered. See below... I thought the newer chassis' TDM was 512x64K. Can you confirm? If it is 512, then does this change anything or am I still limited to just 4 Dual PRIs in one chassis. I'm not sure. I was under the impression that there were still only 256 Timeslots, however, I will double check on that. I do know that there is a limitation, only allowing you to install Dual PRI's in Slots 1-4 on the chassis, hence, if you install a PRI card in slot 15, chances are, it won't work. Nevertheless, I will double check on the Size of the TDM to be certain. If I had 4 Dual PRIs (the MAX), can I additionally add HiPer DSPs to this chassis? Yes. Why, then can I have 14 HiPer DSPs in one chassis if the TDM is limited to 256x64K? Because the HiPER cards don't require the use of the TDM to transfer data, because all communication happens over the front-to-back bus. The data from there is then transferred to the HiPER ARC/NETServer via the Packetbus. Making the assumption that there is a 512x64K TDM, is it the Dual PRIs can only use the 256 part and the new HiPer DSPs can use the 512? Could it be that there's two TDMs in the newer chassis? Once again, the Dual PRI's will take advantage of the TDM as it needs to transfer the ISDN/PSTN orignating calls to a processor, being the NETServer/HiPER ARC or the Quad Modems. I do believe you can terminate incoming calls off the Dual PRI card onto a Hiper, but that doesn't seem to make much practical sense. In any event, I'm not sure if the latter can actually be done, as I haven't had a chance to test it!!! :) Are you saying that I can't terminate Dual PRI calls into a HiPer ARC? Please find out for sure. I'll check that out for you later this week. Regards, Jason.

Unfortunately I only have a hardcopy of this document relating to Y2K compliance, so I will abbreviate below.... These facts were current as at February 17, 1998. Some public information is available at http://www.3com.com/products/yr2000.html Desktop Modems, Internal PC Modems, PC Card Modems, Telephony, Modem Pool, PalmPilot, CDMA IWF Release 1.0, Edgeserver and HiPER DSP are all 100% Yr 2000 compliant. There maybe third party communications software which may not be y2k compliant, and are outside the control of 3Com. the only problem identified so far, occurs when initiating a delayed fax send before January 1, 2000 for transmission on or after that date. In this instance, transmission would be immediate. After Jan1, 2000 there will be no further problems until the year 3000. TOTALcontrol Remote Access Concentrator - Network Access cards, Management Software, Transcend Remote Access Manager, Managed modem pool Netserver /8 and /16 and HiPER ARC are currently 100% Year 2000 compliant. All TCS 3.0 software components are also y2k compliant. Managed Modem Pool is not currently y2k compliant (as at 17th Feb, 98). However, a software update to bring it to compliance will be available before the end of 98. The Current NETServer 8/16 v4.0 is y2k compliant, however, the old 3.x product is not. This can be fixed with the software upgrade to 4.0. HiPER ARC 4.0 is not currently 100% compliant. A software update to bring it to conformance is scheduled prior to the end of 98. The Release of HiPER ARC 4.1 shall bring it to compliance with the IETF Standard NTP being introduced. This upgrade is 100% software upgradable and will require no software changes. sears@vt.edu on 07/03/98 02:17:40 Please respond to usr-tc@lists.xmission.com cc: (bcc: Jason Kelton/AU/3Com) If anyone finds an "official" statement of Y2K compliance, please post a URL! many thanks Pris Sears (sears@vt.edu) - 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.

We are running 4.0.61 with an HiperArc, Hiper DSP. Total ports 96 (48 DSP, 48 Quad) and still having reboot problems. So far I've found a way to crash it (make it rebooted) and 3Com was able to reproduce it in their lab. I know also that 3Com found another way. We have an R&D person in our office and he found another way also.Because 3Com is working hard at those problems, and we suppose to receive a fix today, I would like to give them a little bit more time... If you want to see if you have a reboot, here what I was looking for in the log: Mar 11 10:17:28 test.nbnet.nb.ca At 10:17:29, Facility "Configurator", Leve l "INFORMATION":: HiPer system configuration complete at 3/10/1998 10:17:29 Also, I'm still having this error on one of my HiperArc: Mar 8 20:12:13 test.nbnet.nb.ca At 20:12:51, Facility "IP", Level "CRITICA L":: ip_fwd_get_opt: no IP address available for dynamic address assignment It seems to have problem releasing IP in a busy modem shelve. At 03:00 PM 3/9/98 +0100, you wrote: >I've put some loggins system on my HiPerARC console ports after the >multiple reboots with code version 4.0.19. I updated to 4.0 72 and, >guess what, it still reboots=A0!=A0!=A0! (not as often as before, but= anyway, >it's beginning to piss me off...) > >The only item I logged was this cryptic messsage (I forwarded it to USR >R&D and should get an updated code soon...) > >DD_ERROR, Entering While 1 loop ERROR_NO 0x64 0xffffffe9 > >Anyone ever saw this before=A0? Happens with 4.0.75 and 4.0.72... > >Robert von Bismarck >Petrel Communications S.A. > >- > 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. > Richard Roy (rjroy@nbnet.nb.ca) NBTel Internet Technical Analyst / Analyste Technique

As I understand, The Netserver card will do multi link with no special configuration. So with that in mind, I set NT up for multi link. Dialed into the TC rack and all seems well. I did notice one strange thing, all outbound traffic is on one modem, all inbound traffic is on the other. So all in all, I don't get any better transfer rates. Overall I could see a combined increase. But since most of my traffic is in one direction, I don't gain a whole lot. I don't know if this is the way it's supposed to be or not. Any one have any ideas? Chuck..

Is there any place/Site offering used usrTC chassis cards for sale? Also, I currently have for sale the following: 1 MP8/isdn modem bank with X2 code Asking: 1500$ 24 Usr Courrier modems Asking: 3600$ Let me know if you're interested

Hi Netserver users I am to say that for the firts time i got a working solution from 3com regarding idletime on my netservers. This was a real pain, with my cleinst logging on for hours on end and doing nothing and this meant others could not logon. I finally got a case opened ( # 6935) and Technical Support Engineed , a Mr Tareq_Elkurdi, was able to suggest the solution and he called me up and i implented his solution while he was on the line .. This actually worked ... Thanx Tareq. As for restricting multiple concurent logins, he suggested I upgraded my RADIUS from the current 4.5 to 5.7 and above. This were the actual commands set routing off set all idletime <#of mins you want> save all reset all .. voila and it worked ... bosire Tareq_Elkurdi@3com.com wrote: > Hi Richard > > this is a reply to you queries > Q: Do you have any ideas how to disable multiple login can be achieved? > A: set the max. concurrent session to 1 > > Q: You asked if there was workaround for the idle-timeout bug? > A: From the command line type the following: > > set user(??) routing off > set routing off > > I hope this will solve the problem. > > Please update me. > > Thank you > Tareq Elkurdi > Tech Support Eng. > 3COM Dublin -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

A big Thank You to all those folks who helped. On Sun, 8 Mar 1998, Tatai SV Krishnan wrote: > Same as above, create a filter in you NETServer 16 and call it > test.fil.in and test.fil.out. Set the radius Attribute as framed filter > id test.fil I've done what you've suggested and it's working great on ONE of our NETServer 16/I. However, it's not working on our 2nd NETServer 16/I. Both boxes has the exact same system info: netserver> show system SYSTEM DESCRIPTION System Descriptor: U.S. Robotics NetServer/16I, Version: V4.0.14, Built on Sep 11 1997 at 13:10:08. Object ID: 1.3.6.1.4.1.429.2.15 System UpTime: 0d 00:37:15 System Contact: xxxx System Name: xxxx System Location: xxxx System Services: Internet EndToEnd Applications System Transmit Authentication Name: Netserver System Version: V4.0.14 Both boxes authentication from the same Radius (Livingston 1.16) server. Both boxes have the same filters. The one which isn't working has the following sypmtons; the filters work if I assign them manually to an interface but nothing happens if it's assigned by Radius. Strange that it's working on one and not the other... What have I missed? TIA for any help. fbsd

Has anyone seen a situation where an inbound ISDN call connects but never authenticates? Typing "show isdn" at the Netserver command prompt shows the ISDN caller stuck at the "USERNAME" phase of authentication. My analog dial-up works fine, so I assume my RADIUS server is fully functional. Thanks for any advice on this problem. Tom Walters

On Wed, 11 Mar 1998, FBSD wrote: > I've done what you've suggested and it's working great on ONE of our > NETServer 16/I. However, it's not working on our 2nd NETServer 16/I. ...skipped... > Strange that it's working on one and not the other... What have I missed? > TIA for any help. My mistake! I forgot to: "set interface mod:n filter_access on" for all of the modems. Thanks again to all who helped. fbsd

> If you take too many modems out of service (such that you have more > input channels than modems) you can run into big trouble. Since the > circuit card will continue to accept calls, but not be able to > distribute it to a free modem, it will rapidly drop the call, only to > take another call - you'll end up sucking down calls faster than you > can imagine :-) Is that *really* the case? For PRI? I was under the impression that the call would arrive on the D-channel; the PRI card would look for the necessary resources, and either reject or accept the call. In our case, a reject generates NU tone. We're led to believe that this results in a non-completed call, at zero cost to the customer (local calls are charged here in Australia). Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Thus spake Chuck Simons >As I understand, The Netserver card will do multi link with no special >configuration. >So with that in mind, >I set NT up for multi link. Dialed into the TC rack and all seems well. >I did notice one strange thing, all outbound traffic is on one modem, all >inbound traffic is on the other. >So all in all, I don't get any better transfer rates. Overall I could see a >combined increase. But since most of my traffic is in one direction, >I don't gain a whole lot. Given that modems are full-duplex, you proly wouldn't see *any* benefit from this. >I don't know if this is the way it's supposed to be or not. No, its not how it is supposed to work. Sounds to me (having never used NT beyond putz'in on a cow-orker's box) like its just running two seperate PPP connections and the routing is making the decision on which connection to use in each direction. It doesn't sound like you have a true multilink PPP connection. Unfortunately, not being an NT user, I don't have any clue on what to tell you to check. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Thu, 12 Mar 1998, Charles Sprickman wrote: > Hi all, > > It seems like this works for some folks and not for others. Looking more > closely, I'm now seeing opening any submenu (command, config, monitor) > generates an "access violation". > > I'm going to be calling tech support today to officially open a case, so > I'll share the results... > Dr. Watson should give you a log when this problem happens. Do you have a log which you can send to us? krish > C > > ~~~~~~~~~ ~~~~~~~~~~~ > Charles Sprickman Internet Channel > INCH System Administration Team (212)243-5200 > spork@inch.com access@inch.com > > On Mon, 9 Mar 1998, Jas - Net Tech wrote: > > > Date: Mon, 9 Mar 1998 12:03:17 -0500 (EST) > > From: Jas - Net Tech <jaeckard@Interpath.net> > > Reply-To: usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > > > Original message from Charles Sprickman: > > > > > >Has anyone been able to use the Performance Monitor function on any > > >version of TCM under NT? Everything else seems to work well, but as soon > > >as you've picked any parameters to monitor and you click "OK", Dr. Watson > > >arrives with the message that TCM.exe has caused an access violation... > > > > > > > Most of the time it works fine for me. I assume you have service pack 3? > > > > Jas, Interpath Communications Data Network Technician > > Jas.Eckard@interpath.net > > > > - > > 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. > > > > > - > 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. >

There should be a file on your NT server - this is a log file created by Dr. Watson it should be called as drwatson.log. Check for this file and email the same. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 12 Mar 1998, Charles Sprickman wrote: > This is all I see in the event log that seems relevant: > > >Date: Mon, 9 Mar 1998 13:02:28 -0500 (EST) > >From: Charles Sprickman <spork@inch.com> > >To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > >Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > > >Hi, > > > >I just re-applied SP3, and I still get the same error. Dr. Watson > >consistently says: "The exception generated was c0000005 at address > >0176ec16 [<nosymbols>]" > > same error everytime, same address, etc... > > C > > ~~~~~~~~~ ~~~~~~~~~~~ > Charles Sprickman Internet Channel > INCH System Administration Team (212)243-5200 > spork@inch.com access@inch.com > > On Thu, 12 Mar 1998, Tatai SV Krishnan wrote: > > > Date: Thu, 12 Mar 1998 00:15:52 -0600 (CST) > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > To: Charles Sprickman <spork@inch.com> > > Cc: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > > > On Thu, 12 Mar 1998, Charles Sprickman wrote: > > > > > Hi all, > > > > > > It seems like this works for some folks and not for others. Looking more > > > closely, I'm now seeing opening any submenu (command, config, monitor) > > > generates an "access violation". > > > > > > I'm going to be calling tech support today to officially open a case, so > > > I'll share the results... > > > > > > > Dr. Watson should give you a log when this problem happens. Do you have > > a log which you can send to us? > > > > krish > > > > > > > C > > > > > > ~~~~~~~~~ ~~~~~~~~~~~ > > > Charles Sprickman Internet Channel > > > INCH System Administration Team (212)243-5200 > > > spork@inch.com access@inch.com > > > > > > On Mon, 9 Mar 1998, Jas - Net Tech wrote: > > > > > > > Date: Mon, 9 Mar 1998 12:03:17 -0500 (EST) > > > > From: Jas - Net Tech <jaeckard@Interpath.net> > > > > Reply-To: usr-tc@lists.xmission.com > > > > To: usr-tc@lists.xmission.com > > > > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > > > > > > > Original message from Charles Sprickman: > > > > > > > > > >Has anyone been able to use the Performance Monitor function on any > > > > >version of TCM under NT? Everything else seems to work well, but as soon > > > > >as you've picked any parameters to monitor and you click "OK", Dr. Watson > > > > >arrives with the message that TCM.exe has caused an access violation... > > > > > > > > > > > > > Most of the time it works fine for me. I assume you have service pack 3? > > > > > > > > Jas, Interpath Communications Data Network Technician > > > > Jas.Eckard@interpath.net > > > > > > > > - > > > > 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. > > > > > > > > > > > > > - > > > 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. > > > > > > > > - > 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. >

There is an ER release of code which address this problem. Call support and get the same. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 12 Mar 1998, Jeff Mcadams wrote: > Thus spake Peter D. Mayer > >We have a user who is doing uucp to us through telnet from our TC boxes. > >Everthing was working fine through telnet, but when he tried to send > >messages with attached binaries, it got hundreds of resent blocks and NAKS. > > >I remembered a discussion on the list about 8 bit clean telnet being messed > >up in the new versions of code, so I tried it on one of our boxes with TCS > >2.5.1 still on it. It worked perfectly. Tried it with rlogin on both boxes > >and it worked fine. So I guess my question is, is this a problem with the > >new code's inability to do 8 bit telnet, and will this ever be fixed? Also, > >is there a separate attribute you can set to force binary telnet? > > Netserver code 3.7.24 most definitely breaks the binary mode (8-bit > clean) telnet, and it will break most file transfer's (kermit is fine, > but that's only because it only uses 7-bit transfers, x, y, and zmodem > are all toasted by it), definitely breaks UUCP, and also breaks PPP over > telnet. > > There are no options to force binary modem telnet, its just plain > broken as the netserver attempts to negotiate binary mode telnet (when > it works) always. Hopefully it will be fixed in the next release. > -- > Jeff McAdams Email: jeffm@iglou.com > Chief 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. >

On Thu, 12 Mar 1998, Jeff Mcadams wrote: > Thus spake Tatai SV Krishnan > > >There is an ER release of code which address this problem. Call support > >and get the same. > > Uhm...may I ask why on earth I wasn't notified of this?! > > I, to the best of my knowledge, was the first person to bring this to > USR/3Com's attention, have had an open ticket on this since the 13th of > Feb. The ticket was escalated to second-level tech support to the best > of my knowledge. > You were the first person to notice this - but also Charles at IOnet also notices this. I should have informed you but I did not - it somehow sliped my mind. In any case to fix this problem we were working closely with Charles and then got traces from him to solve the problem. You can get that code too no problems, If you need it let me know. regards krish > I'll say again, first level tech support is improving by leaps and > bounds, but it seems to me that once you get past them at this point > (once the ticket is escalated) that *nothing* ever comes of these > things. This is exactly the opposite of what support used to be like, > where you'd have someone totally clueless on the first level and then > get someone who could really solve your problem if you could get it > escalated, now it just seems like escalation is a black-hole. > > I've had no less than 4 trouble tickets opened in the past 3 months, > every one of them has been escalated (I think this speaks to the > reasonableness of being able to skip past first level tech support for > certain people), and I haven't gotten a call-back on *any* of them > without extraordinary measures. > > Most of these issues have been solved by other means, some of which > might have come about from the escalation to second-level (new code revs > perhaps with input from the escalation of those tickets), but the total > lack of communication is disheartening. > > Anyway....sorry to rant on this, Tatai, I know its not your fault, but I > figure the more people hear about my (and other people's) displeasure at > this situation, then the better the chance of getting it dealt with in > something resembling a decent timeframe. > -- > Jeff McAdams Email: jeffm@iglou.com > Chief 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. >

Check this out, looks *very* interesting.......................... /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/ ---------- Forwarded message ---------- Reply-To: inet-access@earth.com Resent-Date: Tue, 10 Mar 1998 22:19:29 -0700 (MST) Resent-From: inet-access@earth.com FYI, trawling around the web looking for RADIUS servers I've just come across what looks like a feature-full, perl based server. http://www.open.com.au/products.html Looks ok. Cheers, ian --- Dr Ian Hoyle http://www.connect.com.au | connect.com.au Email: ianh@connect.com.au | Level 9, 114 Albert Rd, Phone: +61 3 9251 3673 | South Melbourne, VIC, 3205 Fax: +61 3 9251 3666 | AUSTRALIA

Try radius-esva. It does this. > Is limiting logins a function of the radius server or of the total control > rack? > > We are using netserver/16 with quad analog modems and are having a heck > of a time with users logging in multiple times. > > The company we get our access from has control of the radius server. I > have control of the USR rack. > > > Chuck Simons.. > > > > - > 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. > > WingNET System Administrator 423-559-LINK (v) 423-559-5444 (f)

Is there anything special that needs to be done on either client/server side for an Adtran XRT to work with the HDM's/ARC? We have a user with an Adtran XRT and can't seem to connect. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

I've seen the NetServer card reboot spontaneously on a couple of our chassis'. All of the lights on the NetServer card go orange for a quick second and then the first two lights stay red as the card reboots. Of course all of the modem sessions get dropped when this happens.... pretty frustrating. I believe it has something to do with MPIP - but that's just me guessing. Hopefully I'll have some better evidence when I catch the event with a packet sniffer. BTW: Anyone know if a unix based MPIP server really exists? (mpipd is mentioned in detail in one of the NetServer release notes) I heard a rumor that Merit made one... but I can't find evidence of that. Is this whole mpipd thing just a pipe dream? -jeremy -- .------------------------------------------------------------------. | Jeremy Lingmann \ http://www | jeremy@europa.com | | Network Manager \ .europa | fax: 503-796-9134 | | Europa Communications, Inc. \ .com | phone: 503-222-9508 | On Tue, 17 Feb 1998, Bob Purdon wrote: > > Has anyone seen spontaneous reboots with 3.7.24? > > I've observed (last night) our only 3.7.24 rack spontaneously reboot. > It's not done it since. With 3.5.33 this chassis ran for months, only to > go down for a flash upgrade. > > I'm hoping this isn't a common problem, and that it was only the NETserver > getting crabby because I upgraded it's Quad cards without asking it really > nicely first :-) > > Regards, > > Bob Purdon, > Technical Manager, > Southern Internet Services. > > > - > 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. >

Is there a way to tell if a NetServer card is running off the FC3 chip from the console or TCM? -jeremy -- .------------------------------------------------------------------. | Jeremy Lingmann \ http://www | jeremy@europa.com | | Network Manager \ .europa | fax: 503-796-9134 | | Europa Communications, Inc. \ .com | phone: 503-222-9508 | On Tue, 17 Feb 1998, Brent Jay wrote: > On Tue, 17 Feb 1998, Chris Getman wrote: > > > I haven't seen any yet. Here I have noticed that I will loose one to > > two racks a week on the older code. The racks just drop off the network. > > Either a power cycle or a hardware reset from the TCM gets them going > > again. I never loose any configurations. Weird. I am hoping that the > > new code helps with that problem. > > > > -Chris > > > > > > We fixed that problem here by sending all our netservers with FC3 chips > on them in for RMA. When you get them back they have FC2 chips on them > instead. USR told us it was a hardware bug and we have not had the > problem since. > > > > :::::::::::::::::::::::::::::::::::: > :: :: > :: bjay@ionet.net :: > :: ioNET network specialist :: > :: break out the blender and :: > :: mix me a spam margarita! :: > :: 1-800-360-5183 405-270-0999 :: > :: :: > :::::::::::::::::::::::::::::::::::: > > > - > 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. >

Yup... I've seen it from one or two of our NMC cards. We are also running Livingston's 2.01 Radius server (except on Solaris 2.5.1). The thing that is interesting is that these requests will only come from one or two particular chassis', even though they are all configured 99% the same. I've got packet sniffer dumps if anyone is interested in taking a look.... haven't had time myself. -jeremy -- .------------------------------------------------------------------. | Jeremy Lingmann \ http://www | jeremy@europa.com | | Network Manager \ .europa | fax: 503-796-9134 | | Europa Communications, Inc. \ .com | phone: 503-222-9508 | On Tue, 24 Feb 1998, Edward Kern wrote: > Hi all. > > I just upgraded one of our USR TC racks to TCS 3.0.2. The NMC card, > running 5.3.2, keeps causing error messages in the syslog on my RADIUS server: > > Feb 24 18:37:00 pelican radius[5563]: unknown request type 12 from > 198.69.84.249 ignored > > We're running BSD/OS and Livingston's RADIUS 2.0.1. The tech I talked to > at USR (we have a support contract) wouldn't help me because we're not > running USR's server..... <sigh> > > Anyone ever seen anything like this before? Am I overlooking something > stupid? :> > > Thanks, > > Ed. > > --- > Edward Kern (dag@soulfood.org) > > - > 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. >

Hi all, It seems like this works for some folks and not for others. Looking more closely, I'm now seeing opening any submenu (command, config, monitor) generates an "access violation". I'm going to be calling tech support today to officially open a case, so I'll share the results... C ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com On Mon, 9 Mar 1998, Jas - Net Tech wrote: > Date: Mon, 9 Mar 1998 12:03:17 -0500 (EST) > From: Jas - Net Tech <jaeckard@Interpath.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > Original message from Charles Sprickman: > > > >Has anyone been able to use the Performance Monitor function on any > >version of TCM under NT? Everything else seems to work well, but as soon > >as you've picked any parameters to monitor and you click "OK", Dr. Watson > >arrives with the message that TCM.exe has caused an access violation... > > > > Most of the time it works fine for me. I assume you have service pack 3? > > Jas, Interpath Communications Data Network Technician > Jas.Eckard@interpath.net > > - > 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. >

On Wed, 11 Mar 1998, tw wrote: > Has anyone seen a situation where an inbound ISDN call connects but > never authenticates? Typing "show isdn" at the Netserver command prompt > shows the ISDN caller stuck at the "USERNAME" phase of authentication. > > My analog dial-up works fine, so I assume my RADIUS server is fully > functional. > This can > > Thanks for any advice on this problem. > Tom Walters > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

At 12:15 AM 3/12/98 -0600, you wrote: >On Thu, 12 Mar 1998, Charles Sprickman wrote: > >> Hi all, >> >> It seems like this works for some folks and not for others. Looking more >> closely, I'm now seeing opening any submenu (command, config, monitor) >> generates an "access violation". >> >> I'm going to be calling tech support today to officially open a case, so >> I'll share the results... >> > >Dr. Watson should give you a log when this problem happens. Do you have >a log which you can send to us? > >krish > > >> C >> >> ~~~~~~~~~ ~~~~~~~~~~~ >> Charles Sprickman Internet Channel >> INCH System Administration Team (212)243-5200 >> spork@inch.com access@inch.com >> >> On Mon, 9 Mar 1998, Jas - Net Tech wrote: >> >> > Date: Mon, 9 Mar 1998 12:03:17 -0500 (EST) >> > From: Jas - Net Tech <jaeckard@Interpath.net> >> > Reply-To: usr-tc@lists.xmission.com >> > To: usr-tc@lists.xmission.com >> > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson >> > >> > Original message from Charles Sprickman: >> > > >> > >Has anyone been able to use the Performance Monitor function on any >> > >version of TCM under NT? Everything else seems to work well, but as soon >> > >as you've picked any parameters to monitor and you click "OK", Dr. Watson >> > >arrives with the message that TCM.exe has caused an access violation... >> > > I opened a trouble ticket regarding this issue a little over a month ago. I have not heard much since I opened it, but I do know that they have been able to reproduce this error in their lab. The ticket number is 24871. Eric Koramblyum krmblme@akula.com Operations http://www.akula.com Akula Communications Corp. (212) 292-8892

This is all I see in the event log that seems relevant: >Date: Mon, 9 Mar 1998 13:02:28 -0500 (EST) >From: Charles Sprickman <spork@inch.com> >To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> >Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > >Hi, > >I just re-applied SP3, and I still get the same error. Dr. Watson >consistently says: "The exception generated was c0000005 at address >0176ec16 [<nosymbols>]" same error everytime, same address, etc... C ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com On Thu, 12 Mar 1998, Tatai SV Krishnan wrote: > Date: Thu, 12 Mar 1998 00:15:52 -0600 (CST) > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Charles Sprickman <spork@inch.com> > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > On Thu, 12 Mar 1998, Charles Sprickman wrote: > > > Hi all, > > > > It seems like this works for some folks and not for others. Looking more > > closely, I'm now seeing opening any submenu (command, config, monitor) > > generates an "access violation". > > > > I'm going to be calling tech support today to officially open a case, so > > I'll share the results... > > > > Dr. Watson should give you a log when this problem happens. Do you have > a log which you can send to us? > > krish > > > > C > > > > ~~~~~~~~~ ~~~~~~~~~~~ > > Charles Sprickman Internet Channel > > INCH System Administration Team (212)243-5200 > > spork@inch.com access@inch.com > > > > On Mon, 9 Mar 1998, Jas - Net Tech wrote: > > > > > Date: Mon, 9 Mar 1998 12:03:17 -0500 (EST) > > > From: Jas - Net Tech <jaeckard@Interpath.net> > > > Reply-To: usr-tc@lists.xmission.com > > > To: usr-tc@lists.xmission.com > > > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > > > > > Original message from Charles Sprickman: > > > > > > > >Has anyone been able to use the Performance Monitor function on any > > > >version of TCM under NT? Everything else seems to work well, but as soon > > > >as you've picked any parameters to monitor and you click "OK", Dr. Watson > > > >arrives with the message that TCM.exe has caused an access violation... > > > > > > > > > > Most of the time it works fine for me. I assume you have service pack 3? > > > > > > Jas, Interpath Communications Data Network Technician > > > Jas.Eckard@interpath.net > > > > > > - > > > 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. > > > > > > > > > - > > 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. > > >

Try to force 56k on the TA and see if it begins to work. The call may be mis-routed over a robbed-bit channel somewhere. Also check for CRC errors on the BRI. The telco can loop the NT-1 to test the quality of the line. -CH On Wed, 11 Mar 1998, tw wrote: > Has anyone seen a situation where an inbound ISDN call connects but > never authenticates? Typing "show isdn" at the Netserver command prompt > shows the ISDN caller stuck at the "USERNAME" phase of authentication. > > My analog dial-up works fine, so I assume my RADIUS server is fully > functional. > > > Thanks for any advice on this problem. > Tom Walters > > - > 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. >

Heres a modified pmwho program I recently hacked together to take care of our increasing problems with duplicate logins, and excessive users. Since we started running this from crontab, duplicate user attempts have dropped to an absolute minimum (the program resets their ports), and excessive users on our system is a thing of the past for us. (Our quads now go the extra mile, before addtional modems are required). Two things you should note: 1. This isn't the best way of doing these things. A solution using snmp would be much better, however due to time constraints and other projects I have, this is a quick and easy solution for the small ISP with only 5 or 6 Total Control Hubs. 2. I know my C code isn't the best. (Hell, I haven't done C in a coupla years.) If you find anything that could've been done better in my code, please let me know! http://users.trip.net/~ghopwood I hope some of you find this useful in some way.

Does anyone have any experience using Diamond's ShotGun with TCH? I got some people interested in using it, but looking at Diamond's site, it doesn't tell me what OS to use. If you have any experience doing this with either HiPer or classic TCH please share your finding with me. Check out this site for RAS units that Diamond seems to have checked out. http://www.diamondmm.com/shotgun/isp-support.html ++++++++++++++++++++++++ mailto:turners@best.com ++++++++++++++++++++++++

We have a user who is doing uucp to us through telnet from our TC boxes. Everthing was working fine through telnet, but when he tried to send messages with attached binaries, it got hundreds of resent blocks and NAKS. I remembered a discussion on the list about 8 bit clean telnet being messed up in the new versions of code, so I tried it on one of our boxes with TCS 2.5.1 still on it. It worked perfectly. Tried it with rlogin on both boxes and it worked fine. So I guess my question is, is this a problem with the new code's inability to do 8 bit telnet, and will this ever be fixed? Also, is there a separate attribute you can set to force binary telnet? Thanks, Peter D. Mayer NetWalk Tech Support dmayer@netwalk.com

Jeff Mcadams said once upon a time: >Netserver code 3.7.24 most definitely breaks the binary mode (8-bit >clean) telnet, and it will break most file transfer's (kermit is fine, >but that's only because it only uses 7-bit transfers, x, y, and zmodem >are all toasted by it), definitely breaks UUCP, and also breaks PPP over >telnet. FYI, rzsz has a 7-bit mode for ZModem transfers. I think it is -e.

Thus spake Peter D. Mayer >We have a user who is doing uucp to us through telnet from our TC boxes. >Everthing was working fine through telnet, but when he tried to send >messages with attached binaries, it got hundreds of resent blocks and NAKS. >I remembered a discussion on the list about 8 bit clean telnet being messed >up in the new versions of code, so I tried it on one of our boxes with TCS >2.5.1 still on it. It worked perfectly. Tried it with rlogin on both boxes >and it worked fine. So I guess my question is, is this a problem with the >new code's inability to do 8 bit telnet, and will this ever be fixed? Also, >is there a separate attribute you can set to force binary telnet? Netserver code 3.7.24 most definitely breaks the binary mode (8-bit clean) telnet, and it will break most file transfer's (kermit is fine, but that's only because it only uses 7-bit transfers, x, y, and zmodem are all toasted by it), definitely breaks UUCP, and also breaks PPP over telnet. There are no options to force binary modem telnet, its just plain broken as the netserver attempts to negotiate binary mode telnet (when it works) always. Hopefully it will be fixed in the next release. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Thu, 12 Mar 1998, Peter D. Mayer wrote: > We have a user who is doing uucp to us through telnet from our TC boxes. > Everthing was working fine through telnet, but when he tried to send > messages with attached binaries, it got hundreds of resent blocks and NAKS. > > I remembered a discussion on the list about 8 bit clean telnet being messed > up in the new versions of code, so I tried it on one of our boxes with TCS > 2.5.1 still on it. It worked perfectly. Tried it with rlogin on both boxes > and it worked fine. So I guess my question is, is this a problem with the > new code's inability to do 8 bit telnet, and will this ever be fixed? Also, > is there a separate attribute you can set to force binary telnet? > UUCP was designed with 7bit connections in mind, if I'm not mistaken. In any case, if you use netdata and port 540 (the default uucp/uucico port) it will come through 8bit clean and you wont have any problems. - lv

Thus spake Laszlo Vecsey >On Thu, 12 Mar 1998, Peter D. Mayer wrote: >> We have a user who is doing uucp to us through telnet from our TC boxes. >> Everthing was working fine through telnet, but when he tried to send >> messages with attached binaries, it got hundreds of resent blocks and NAKS. >> >> I remembered a discussion on the list about 8 bit clean telnet being messed >> up in the new versions of code, so I tried it on one of our boxes with TCS >> 2.5.1 still on it. It worked perfectly. Tried it with rlogin on both boxes >> and it worked fine. So I guess my question is, is this a problem with the >> new code's inability to do 8 bit telnet, and will this ever be fixed? Also, >> is there a separate attribute you can set to force binary telnet? >> >UUCP was designed with 7bit connections in mind, if I'm not mistaken. In >any case, if you use netdata and port 540 (the default uucp/uucico port) >it will come through 8bit clean and you wont have any problems. That, of course, assumes that you're doing authentication on the netserver for uucp accounts, which we don't. RLogin worked for us though. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I found the file, but all it includes is system startup and shutdown notification... C ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com On Thu, 12 Mar 1998, Tatai SV Krishnan wrote: > Date: Thu, 12 Mar 1998 04:45:30 -0600 (CST) > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Charles Sprickman <spork@inch.com> > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > There should be a file on your NT server - this is a log file created by > Dr. Watson it should be called as drwatson.log. Check for this file and > email the same. > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > tkrishna@bubba.ae.usr.com > ----------------------------/ http://interproc.ae.usr.com ----/ > -------------------------------------------------------------------------\ > Any Sufficiently advanced bug is indistinguishable for a feature. > - Rick Kulawiec > -------------------------------------------------------------------------/ > > On Thu, 12 Mar 1998, Charles Sprickman wrote: > > > This is all I see in the event log that seems relevant: > > > > >Date: Mon, 9 Mar 1998 13:02:28 -0500 (EST) > > >From: Charles Sprickman <spork@inch.com> > > >To: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > >Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > > > > >Hi, > > > > > >I just re-applied SP3, and I still get the same error. Dr. Watson > > >consistently says: "The exception generated was c0000005 at address > > >0176ec16 [<nosymbols>]" > > > > same error everytime, same address, etc... > > > > C > > > > ~~~~~~~~~ ~~~~~~~~~~~ > > Charles Sprickman Internet Channel > > INCH System Administration Team (212)243-5200 > > spork@inch.com access@inch.com > > > > On Thu, 12 Mar 1998, Tatai SV Krishnan wrote: > > > > > Date: Thu, 12 Mar 1998 00:15:52 -0600 (CST) > > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > To: Charles Sprickman <spork@inch.com> > > > Cc: usr-tc@lists.xmission.com > > > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > > > > > On Thu, 12 Mar 1998, Charles Sprickman wrote: > > > > > > > Hi all, > > > > > > > > It seems like this works for some folks and not for others. Looking more > > > > closely, I'm now seeing opening any submenu (command, config, monitor) > > > > generates an "access violation". > > > > > > > > I'm going to be calling tech support today to officially open a case, so > > > > I'll share the results... > > > > > > > > > > Dr. Watson should give you a log when this problem happens. Do you have > > > a log which you can send to us? > > > > > > krish > > > > > > > > > > C > > > > > > > > ~~~~~~~~~ ~~~~~~~~~~~ > > > > Charles Sprickman Internet Channel > > > > INCH System Administration Team (212)243-5200 > > > > spork@inch.com access@inch.com > > > > > > > > On Mon, 9 Mar 1998, Jas - Net Tech wrote: > > > > > > > > > Date: Mon, 9 Mar 1998 12:03:17 -0500 (EST) > > > > > From: Jas - Net Tech <jaeckard@Interpath.net> > > > > > Reply-To: usr-tc@lists.xmission.com > > > > > To: usr-tc@lists.xmission.com > > > > > Subject: Re: (usr-tc) TCM 5.1.1 + NT = Dr. Watson > > > > > > > > > > Original message from Charles Sprickman: > > > > > > > > > > > >Has anyone been able to use the Performance Monitor function on any > > > > > >version of TCM under NT? Everything else seems to work well, but as soon > > > > > >as you've picked any parameters to monitor and you click "OK", Dr. Watson > > > > > >arrives with the message that TCM.exe has caused an access violation... > > > > > > > > > > > > > > > > Most of the time it works fine for me. I assume you have service pack 3? > > > > > > > > > > Jas, Interpath Communications Data Network Technician > > > > > Jas.Eckard@interpath.net > > > > > > > > > > - > > > > > 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. > > > > > > > > > > > > > > > > > - > > > > 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. > > > > > > > > > > > > > - > > 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. > > >

Thus spake Tatai SV Krishnan >There is an ER release of code which address this problem. Call support >and get the same. Uhm...may I ask why on earth I wasn't notified of this?! I, to the best of my knowledge, was the first person to bring this to USR/3Com's attention, have had an open ticket on this since the 13th of Feb. The ticket was escalated to second-level tech support to the best of my knowledge. I'll say again, first level tech support is improving by leaps and bounds, but it seems to me that once you get past them at this point (once the ticket is escalated) that *nothing* ever comes of these things. This is exactly the opposite of what support used to be like, where you'd have someone totally clueless on the first level and then get someone who could really solve your problem if you could get it escalated, now it just seems like escalation is a black-hole. I've had no less than 4 trouble tickets opened in the past 3 months, every one of them has been escalated (I think this speaks to the reasonableness of being able to skip past first level tech support for certain people), and I haven't gotten a call-back on *any* of them without extraordinary measures. Most of these issues have been solved by other means, some of which might have come about from the escalation to second-level (new code revs perhaps with input from the escalation of those tickets), but the total lack of communication is disheartening. Anyway....sorry to rant on this, Tatai, I know its not your fault, but I figure the more people hear about my (and other people's) displeasure at this situation, then the better the chance of getting it dealt with in something resembling a decent timeframe. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Pete Ashdown >Jeff Mcadams said once upon a time: >>Netserver code 3.7.24 most definitely breaks the binary mode (8-bit >>clean) telnet, and it will break most file transfer's (kermit is fine, >>but that's only because it only uses 7-bit transfers, x, y, and zmodem >>are all toasted by it), definitely breaks UUCP, and also breaks PPP over >>telnet. >FYI, rzsz has a 7-bit mode for ZModem transfers. I think it is -e. Ah, yeah, I do recall that. That, however, is beside the point. :) The file transfer problems were actually incidental, the uucp and ppp over telnet were the really critical ones for us, but switching to rlogin (with a modified rlogind) is actually a better solution for us than the telnet was. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Had the same problem. I put him on the quad cards and he is fine. Something with the HDM's. I called 3com about it but they were no help. -----Original Message----- >Is there anything special that needs to be done on either client/server >side for an Adtran XRT to work with the HDM's/ARC? We have a user with an >Adtran XRT and can't seem to connect. > >Brian > > >/-------------------------- signal@shreve.net -----------------------------\ >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | >| Network Administrator | Perl, Linux | Web hosting, online stores, | >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | >| 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | >| mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | >\-------------------------- 318-222-2638 x109 -----------------------------/ > > > >- > 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. >

> I believe it has something to do with MPIP - but that's just > me guessing. In our case that's unlikely as we don't run MPIP. > BTW: Anyone know if a unix based MPIP server really exists? I've never actually seen it. Cheers, Bob.

I am interested in acquiring a minimum of 7-10 14.4 speed modems. If you have these available, please respond directly via email with: - Make/Model (Prefer, but not limiting to 3Com/USR) - Number available - Per unit price - Price per bundle (and how many in bundle) - Availability (how quickly) Thanks, Timothy

Sorry to be somewhat off USR topic, but I know the answer is in this group... ProdigyInternet uses a combination of providers for their POPs. IBM is one - they use USR TCH. Split Rock is another - they use Bay Networks. As I monitor the Prodigy help ng, I see an unusually large amount of connectivity complaints - from both x2 and v.34 users on Split Rock POPs. Are there some basic problems getting the Bay equipment to work with v.34 and/or x2 client modems, or is it a problem with implementation and configuration on the part of Split Rock? (We already know that 3Com v.90 enabled modems have trouble getting an x2 connection to the Bay equipment; solution was to disable v.90; 3Com apparently released a v.90 update for the new v.90-out-of-the-box models and I've got reports that this prevents both x2 and v.90 connection where the original code would get x2 with v.90 disabled to the Bay gear.) Aloha, Richard 56k update at http://pages.prodigy.net/bbhi/x2-7.htm

Because the ARC contains usernames which can be retreived via SNMP it should be even easier now to have a web interface that: 1. user clicks on link 2. IP address is grabbed 3. snmp to arc and get username on that ip address/interface as well as all kinds of "performance monitor" info for that user 4. print to user If anyone has done this I would be interested, we had something working on the quads, but now with hdm we don't. We will be 100% hdm very soon, so something like this will be good to have. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Why would anybody in their right mind run a perl radius server? On Thu, 12 Mar 1998, Brian wrote: > > Check this out, looks *very* interesting.......................... > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > ---------- Forwarded message ---------- > Date: Wed, 11 Mar 1998 16:18:43 +1100 (EST) > From: Ian Hoyle <ianh@connect.com.au> > Reply-To: inet-access@earth.com > To: inet-access@earth.com > Subject: perl RADIUS server > Resent-Date: Tue, 10 Mar 1998 22:19:29 -0700 (MST) > Resent-From: inet-access@earth.com > > > FYI, trawling around the web looking for RADIUS servers I've just come > across what looks like a feature-full, perl based server. > > http://www.open.com.au/products.html > > Looks ok. > > Cheers, > > ian > > --- > Dr Ian Hoyle > http://www.connect.com.au | connect.com.au > Email: ianh@connect.com.au | Level 9, 114 Albert Rd, > Phone: +61 3 9251 3673 | South Melbourne, VIC, 3205 > Fax: +61 3 9251 3666 | AUSTRALIA > > > > - > 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. >

At 10:11 AM 3/13/98 -0800, Brandon's Mailing lists wrote: >Why would anybody in their right mind run a perl radius server? > To go where no man has gone before??.. authentication from SQL databases such as Oracle, Informix, mSQL, mysql.. Full source code provided - Runs on nearly all hosts. Vendor-Specific attributes, both in and out. CHAP authentication. Plug-in authentication handlers. (cool..) Username rewriting and realm stripping. Object-Oriented design and understandable code (with many comments) Fault tolerant connection to SQL. Proxy-State support. Multiple DEFAULT users with optional Fall-Through. Auth-Type cascades authentication to another user database of any type. Block authentication according to time of day with Block-Logon-From and Block- Logon-Until (cool for 9to5 service..) allen _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

> > Why would anybody in their right mind run a perl radius server? > Easy to program, easy to modify, and CPU is cheap. (Try adding snmp to any of the currently available radius servers written in C) -Luke

Brandon's Mailing lists was heard to say: > >Why would anybody in their right mind run a perl radius server? > Proof of concept? Anyone want a JAVA RADIUS server? --Ricky

Ok, I've asked this question before and never gotten a complete answer so I'll try one more time. We have a 4 meg NMC which we just ordered the 16 meg upgrade for it. WHat is the correct process for upgrading it without loosing the chassis configuration, X2 key etc .. ? I assume 3Com has this documented somewhere I just need pointed towards it. Jeff Binkley ASA Network Computing

At 12:02 PM 3/13/98 -0600, you wrote: >At 10:11 AM 3/13/98 -0800, Brandon's Mailing lists wrote: >>Why would anybody in their right mind run a perl radius server? >> > >To go where no man has gone before??.. > >authentication from SQL databases such as Oracle, Informix, mSQL, mysql.. >Full source code provided - Runs on nearly all hosts. >Vendor-Specific attributes, both in and out. >CHAP authentication. >Plug-in authentication handlers. (cool..) >Username rewriting and realm stripping. >Object-Oriented design and understandable code (with many comments) >Fault tolerant connection to SQL. >Proxy-State support. >Multiple DEFAULT users with optional Fall-Through. >Auth-Type cascades authentication to another user database of any type. >Block authentication according to time of day with Block-Logon-From and Block- >Logon-Until (cool for 9to5 service..) > >allen Don't forget LDAP authentication! :) ____________________________________________________________________ Jay Christner Office: UN-019 Technical Services Phone:(219)-535-7640 Residential Computer Technician Goshen College ____________________________________________________________________

On Fri, 13 Mar 1998, Brandon's Mailing lists wrote: > Why would anybody in their right mind run a perl radius server? > And the reason why no one in there right mind would run a perl radius server is? > On Thu, 12 Mar 1998, Brian wrote: > > > > > Check this out, looks *very* interesting.......................... > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > ---------- Forwarded message ---------- > > Date: Wed, 11 Mar 1998 16:18:43 +1100 (EST) > > From: Ian Hoyle <ianh@connect.com.au> > > Reply-To: inet-access@earth.com > > To: inet-access@earth.com > > Subject: perl RADIUS server > > Resent-Date: Tue, 10 Mar 1998 22:19:29 -0700 (MST) > > Resent-From: inet-access@earth.com > > > > > > FYI, trawling around the web looking for RADIUS servers I've just come > > across what looks like a feature-full, perl based server. > > > > http://www.open.com.au/products.html > > > > Looks ok. > > > > Cheers, > > > > ian > > > > --- > > Dr Ian Hoyle > > http://www.connect.com.au | connect.com.au > > Email: ianh@connect.com.au | Level 9, 114 Albert Rd, > > Phone: +61 3 9251 3673 | South Melbourne, VIC, 3205 > > Fax: +61 3 9251 3666 | AUSTRALIA > > > > > > > > - > > 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. > > > > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Fri, 13 Mar 1998, Brandon's Mailing lists wrote: > Why would anybody in their right mind run a perl radius server? > RADIUS begs for perl. Perl was designed to do things just like RADIUS does. PERL's strengths are working on data, writing log files, formating text, and acting on the text as with regex's. Perls socket code is robust enough, and RADIUS servers don't put much strain at all on a machine. > On Thu, 12 Mar 1998, Brian wrote: > > > > > Check this out, looks *very* interesting.......................... > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > ---------- Forwarded message ---------- > > Date: Wed, 11 Mar 1998 16:18:43 +1100 (EST) > > From: Ian Hoyle <ianh@connect.com.au> > > Reply-To: inet-access@earth.com > > To: inet-access@earth.com > > Subject: perl RADIUS server > > Resent-Date: Tue, 10 Mar 1998 22:19:29 -0700 (MST) > > Resent-From: inet-access@earth.com > > > > > > FYI, trawling around the web looking for RADIUS servers I've just come > > across what looks like a feature-full, perl based server. > > > > http://www.open.com.au/products.html > > > > Looks ok. > > > > Cheers, > > > > ian > > > > --- > > Dr Ian Hoyle > > http://www.connect.com.au | connect.com.au > > Email: ianh@connect.com.au | Level 9, 114 Albert Rd, > > Phone: +61 3 9251 3673 | South Melbourne, VIC, 3205 > > Fax: +61 3 9251 3666 | AUSTRALIA > > > > > > > > - > > 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. > > > > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

On Fri, 13 Mar 1998, Ricky Beam wrote: > Brandon's Mailing lists was heard to say: > > > >Why would anybody in their right mind run a perl radius server? > > > > Proof of concept? Anyone want a JAVA RADIUS server? I think that would rock. At least a JAVA front end would really be cool. I think "front ends" to databases, servers, administrative packages, shold all be html/java. This makes the front end more scalable, and also makes for more efficient use, since from my machine, whatever I run, I can administrate. Brian > > --Ricky > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Is there an archive of this mailing list somewhere? I was interested in finding copies of a couple of messages a day or so ago that concerned broken FTP and Telnet in certain versions of tc software. Thanks Steve Buza

Dear friends, Does anybody know if NetServer Card works with DHCP?? If it works, how can I configure the DHCP Server?? Thanks, Rizzi

>RADIUS begs for perl. Perl was designed to do things just like RADIUS >does. PERL's strengths are working on data I'm sitting here scratching my head trying to think of all the non-data-friendly languages I've used recently. Other than INTERCAL, Visual Basic, and possibly TCL, none exactly leap to mind. I long ago wrote a RADIUS server based partially around a Scheme interpreter because I thought RADIUS just begged for Scheme. One might detect some ear-of-the-beholder qualities to such begging, I expect. Perl was basically designed (sic) for frobbing flat files into other flat files with some reporting calculation in between. And then it overachieved. >writing log files, formating >text, and acting on the text as with regex's. ...none of which seems especially relevant to RADIUS. So many problems seem appropriate for regexs because of the "all the world's a nail" side-effect of hammer ownership. But just out of perversity I'd love to see regexs for packing and unpacking RADIUS attribute lists. >Perls socket code is robust enough, That's the easy part. > and RADIUS servers don't put much >strain at all on a machine. That depends on your network :-) I've had some pretty bad experiences with long-running, multi-threaded (or forking) servers written in Perl. I'm not saying that it's always a bad idea, but keep in mind that most Perl programs are short little single-threaded things that live for a relatively short period of time, and thus aren't bothered by little leaks and idiosyncracies in the Perl runtime. regards, -- Robert

Jeff Binkley said once upon a time: > > >Ok, I've asked this question before and never gotten a complete answer so I'll >try one more time. We have a 4 meg NMC which we just ordered the 16 meg >upgrade for it. WHat is the correct process for upgrading it without loosing >the chassis configuration, X2 key etc .. ? I assume 3Com has this documented >somewhere I just need pointed towards it. For some reason, when I upgraded my NMC's via the PC SDL program, none of the settings were lost, in spite of the fact that I pulled and replaced both the RAM and the VRAM. I'd imagine there is a small snippet of VRAM on the board itself.

: Is there an archive of this mailing list somewhere? The authoritative archives are at ftp://ftp.xmission.com/pub/lists/usr-tc/archive/ those are periodically mirrored and represented in a searchable web page at http://usr-tc.datasys.net/ The archives at this latter site are at least a month behind. I'll get them updated soon. --- Mark R. Lindsey, mark@datasys.net

On Friday, March 13, 1998 5:20 PM, Charles Sprickman [SMTP:spork@inch.com] wrote: > This got me once, and the problem was that I had used the GUI client to > configure the NetServer. That's bad news, as it didn't quite set all the > ports as I'd wanted. Check all of your NetServer settings to see that > what you have set agrees for all 48 ports... Just to make sure .... from the command line interface... set all security on set all login network dialin set all prompt login: set limit 60 set modem s5-s64 active Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) http://www.netdoor.com 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28

This got me once, and the problem was that I had used the GUI client to configure the NetServer. That's bad news, as it didn't quite set all the ports as I'd wanted. Check all of your NetServer settings to see that what you have set agrees for all 48 ports... C ~~~~~~~~~ ~~~~~~~~~~~ Charles Sprickman Internet Channel INCH System Administration Team (212)243-5200 spork@inch.com access@inch.com On Fri, 13 Mar 1998, Rob Fisher wrote: > Date: Fri, 13 Mar 1998 23:19:07 > From: Rob Fisher <rob@dbn.lia.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com, usr-tc@xmission.com > Subject: (usr-tc) Host unavailable > > Hi All, > > I run a small ISP in Durban South Africa and have had a Total Control Rack > for some time. We had one PRI running 30 ports and it worked 100%. We now > added a further PRI and 30 ports and all was well until the last week or > so... when the lines get relatively busy (say 40 ports being used) the > balance answer but will not authenticate (to radius) and give the error > "Host Unavailable". > > Any ideas? > > Kind Regards Rob > rob@dbn.lia.net - Web http://www.dbn.lia.net > Phone +27(31)705-4767 Fax +27(31)705-2031 > Club Internet Durban - Neptune Software - USRobotics > Give a man a fish and you feed him for a day; teach him to use the Net and > he won't bother you for weeks. > > - > 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. >

On Fri, 13 Mar 1998, Brandon's Mailing lists wrote: > Why would anybody in their right mind run a perl radius server? Actually... :) I am _this close_ to being finished with my first "real beta" of a GPLed radius engine which is completely modular in design, and has the *ability* to hook into perl. The engine itself is written in C, but is complete "bare bones" (i.e. featureless). It requires external modules be plugged into it (in the form of dynamically loadable libraries, which also means that the host platform must support some type of libdl [sun and linux do, AFAIK, not sure about others]) to do anything useful. One of the modules I have is an embedded perl module which allows you to easily hook into all accounting/authentication functions in one or more perl programs (which are then dynamically loaded as needed), making extensibility a snap. :) I'll post a URL here to the beta source tree once I'm _relatively_ comfortable with it's semi-functionality (I'm currently having to rewrite a lot of code because much of it consists of EVCom specific hacks). I'll also put it on my anonymous CVS server so that any interested parties can refresh from my various works-in-progress (which will mostly be centered around module development). It's not going to be as robust as a dedicated monolithic radius server, but there is always a trade off between extensibility and resource usage. > On Thu, 12 Mar 1998, Brian wrote: > > > > > Check this out, looks *very* interesting.......................... > > > > > > /-------------------------- signal@shreve.net -----------------------------\ > > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > | Network Administrator | Perl, Linux | Web hosting, online stores, | > > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > ---------- Forwarded message ---------- > > Date: Wed, 11 Mar 1998 16:18:43 +1100 (EST) > > From: Ian Hoyle <ianh@connect.com.au> > > Reply-To: inet-access@earth.com > > To: inet-access@earth.com > > Subject: perl RADIUS server > > Resent-Date: Tue, 10 Mar 1998 22:19:29 -0700 (MST) > > Resent-From: inet-access@earth.com > > > > > > FYI, trawling around the web looking for RADIUS servers I've just come > > across what looks like a feature-full, perl based server. > > > > http://www.open.com.au/products.html > > > > Looks ok. > > > > Cheers, > > > > ian > > Regards, Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

Why is it when I see a post from MegaZone in this mailing list I know the biased view will always shine thru..... I did read you now consider yourself a person of independant thoughts....Well, I still see the same slant of view ......... MegaZone wrote: > Once upon a time Brett Hawn shaped the electrons to say... > >So you would have us believe that K56flex or whatever its being called > >today, is better than X2? I'm going to have to seriously disagree with you > >here. Regardless of your opinion of yon Boardwatch writer, or his likes, X2 > >has consistently been the more reliable protocol every time. K56Flex has > >been nothing but a pain in our ass from the get go, and say what you may > > And I can cite a few dozen posts with 180 degrees from you - your point? > For ever person bitching about K56flex and praising X2 there is someone > bitching about X2 and praising K56flex. So I don't give a fuck. > > The problem is Jack's test is seriously skewed. The K56flex results he > got have not been reflected by a single real world user who followed up, > which is why tens of ISPs are jumping down his throat on portmaster-users > and isp-ceo. He made a poorly architected test, using only connect speeds > (BTW, a friend of mine on the inside tells be X2's connect speeds are > deliberately optimistic and are not the real sustainable speeds - this seems > confirmed by the myriad of reports on scores of lists and newsgroups), and > then generalized that to the entire K56flex market. When really, even in > his flawed way, all that was being tested was Rockwell client to Rockwell > server - there was one PM user in the batch. He further went on, on the > basis of just that test, to make a comment in public email directly slamming > performance on PMs - a comment he later 'corrected' (retracted). > > Just a few minutes ago on PM users was a person talking about how they > just decided to never by 3Com servers and have standardized on PM-3s for > ease of use and superior performance. Right now they have more TCs than > PM-3s, but are frozen on the TC side. They switched from 3Com/USR to > Lucent RABU because their experience was exactly the opposite of yours. > > And for all I know you have Ass-End servers on the K56flex side, or Shiva, > or what have you. > > Does that make your experience a universal truth? No. Does that make the > other users experience a universal truth. No. I'm sure both of you have > exactly the experiences you claim. > > I do contend that K56flex was a generally superior protocol to X2 in most > regards, including max speed and sustained throughput. But implementations > vary. X2 had the advantage of being primarily a single vendor. > > -MZ > -- > <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human being, me > "A little nonsense now and then, is relished by the wisest men" 781-788-0130 > <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail Discordia! > > - > 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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick----Network Engineer | Connect to a Backbone not a Wishbone http://www.monmouth.com | Monmouth Internet Corporation 732-842-5366 | Network Operations Center -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

The X2 enable feature on the NMC is independant of the flash. When we upgraded half our NMC cards we installed the 16meg dram and 8 meg flash and then of course upgraded to 5.2.2 for the nmc firmware. All our X2 enabled NMC cards stayed X2 enabled......We did have to upgrade one card to 5.2.2 via the dos based pcsdl.exe .....So if you have never used this (but rather used the TCM manager) I would recommend having pcsdl ready to go.......... Jeff Binkley wrote: > Ok, I've asked this question before and never gotten a complete answer so I'll > try one more time. We have a 4 meg NMC which we just ordered the 16 meg > upgrade for it. WHat is the correct process for upgrading it without loosing > the chassis configuration, X2 key etc .. ? I assume 3Com has this documented > somewhere I just need pointed towards it. > > Jeff Binkley > ASA Network Computing > > - > 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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick----Network Engineer | Connect to a Backbone not a Wishbone http://www.monmouth.com | Monmouth Internet Corporation 732-842-5366 | Network Operations Center -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Nothing like the command line interface....One of the reasons I have always liked cisco and 3com over our ascend ISDN equipment...... Marshall Morgan wrote: > On Friday, March 13, 1998 5:20 PM, Charles Sprickman [SMTP:spork@inch.com] > wrote: > > This got me once, and the problem was that I had used the GUI client to > > configure the NetServer. That's bad news, as it didn't quite set all the > > ports as I'd wanted. Check all of your NetServer settings to see that > > what you have set agrees for all 48 ports... > > Just to make sure .... from the command line interface... > > set all security on > set all login network dialin > set all prompt login: > set limit 60 > set modem s5-s64 active > > Marshall Morgan > > Internet Doorway, Inc. (aka NETDOOR) > http://www.netdoor.com > 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28 > > - > 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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick----Network Engineer | Connect to a Backbone not a Wishbone http://www.monmouth.com | Monmouth Internet Corporation 732-842-5366 | Network Operations Center -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

I have netserver 8/i plus running, with radius nt 2.0b11. I managed to get the radius accounting going to the radius.mdb database. this works goodly. 2 questions - 1. Why doesn't port-limit work? If I set a port-limit to 1, then two simultaneous logins by user 'x' should not be allowed... right? 2. Is there a way to put the user entries into this database also - without having to put those users into a flat file? Thanks in Advance, Ken :) - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

case #: 39140 Hi Charles, Yes, neighbor. See my other mail to you. And keep my email address in case you want to grab me later. I did keep yours. After the paramater change, those problematic exchange area call in did improve. But not 100 % as good as those from other exchange area. I am not sure why. For example, 28.8K dialin can achieve about 1MB/8 minutes instead of 6 MB/minutes (that consider as normal) BTW, I use PRI line, how about yours , T1 or PRI ? And another route will be to ask ACC SERIOUSLY look into this problem. I just don't know how to report this problem. Meng Tsai tsaim@mft.com Charles Sprickman wrote: > By any chance are you in the Eagle colo across from a rack full of 5 Total > Control Hubs? If so, Hello, neighbor! > > I would appreciate it if you could keep me updated on your progress on > this issue, as we've seen a similar problem only on certain exchanges... > > Thanks, > > Charles > > ~~~~~~~~~ ~~~~~~~~~~~ > Charles Sprickman Internet Channel > INCH System Administration Team (212)243-5200 > spork@inch.com access@inch.com > > ---------- Forwarded message ---------- > Date: Fri, 06 Mar 1998 14:58:16 -0500 > From: mt <tsaim@mft.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Cc: Michael Folorunso <Michael_Folorunso@3com.com>, > "mike_McFarland@3com.com" <mike_McFarland@3com.com>, > "Jeffrey_Burton@3com.com" <Jeffrey_Burton@3com.com>, > steve_bilder@usr.com > Subject: Re: (usr-tc) Performance - in progress > > Thanks to Mike McFarland , 3COM USR Engineer. > I was on the phone with he for 3 hours today doing the > trouble shooting. > > We finally nailed down the problem and resolved it by > using TCM -> program setting -> Line interface option > > Change the transmitter Lever from default 11 to 14. > > The slowness problem went away. I will continue > monitor the situtation until next week. > > Thanks again, Mr. McFarland. > > Sincerely yours > > Meng Tsai > tsaim@mft.com > > Stephen W. Buza wrote: > > > Most of my users report download speeds > > of under 1.5kbps. The traffic on my backbone > > never exceeds a third of the bandwidth available > > even at peak times. If the initial connection was > > poor, but the sessions straightened out eventually, > > that wouldn't be a problem. > > > > I have several customers who report 300bps > > download times with 28.8 modems. And NO it > > is not because they are connecting to slow sites. > > > > Steve > > > > -----Original Message----- > > From: Mark R. Lindsey <mark@vielle.datasys.net> > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > Date: Wednesday, March 04, 1998 8:08 AM > > Subject: Re: (usr-tc) Performance > > > > >: I have problems getting decent speeds out > > >: of v.34 modems. Nearly all of the connections > > >: to my rack are at 26,400 or less and some > > >: customers never can achieve 19,200. > > > > > >The intial connection to a modem is a hairsbreadth from meaningless > > >(which is better, a 56k connection that dies after 3 seconds, or a 26.4k > > >connection that lasts a week?). > > > > > >Are you monitoring the transmit link rates? > > > > > > > > >- > > > 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. > > > > > > > - > > 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. > > - > 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.

Hi All, I run a small ISP in Durban South Africa and have had a Total Control Rack for some time. We had one PRI running 30 ports and it worked 100%. We now added a further PRI and 30 ports and all was well until the last week or so... when the lines get relatively busy (say 40 ports being used) the balance answer but will not authenticate (to radius) and give the error "Host Unavailable". Any ideas? Kind Regards Rob rob@dbn.lia.net - Web http://www.dbn.lia.net Phone +27(31)705-4767 Fax +27(31)705-2031 Club Internet Durban - Neptune Software - USRobotics Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks.

Hi All, I run a small ISP in Durban South Africa and have had a Total Control Rack for some time. We had one PRI running 30 ports and it worked 100%. We now added a further PRI and 30 ports and all was well until the last week or so... when the lines get relatively busy (say 40 ports being used) the balance answer but will not authenticate (to radius) and give the error "Host Unavailable". Any ideas? Kind Regards Rob rob@dbn.lia.net - Web http://www.dbn.lia.net Phone +27(31)705-4767 Fax +27(31)705-2031 Club Internet Durban - Neptune Software - USRobotics Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks.

On Fri, 13 Mar 1998, Rob Fisher wrote: > Hi All, > > I run a small ISP in Durban South Africa and have had a Total Control Rack > for some time. We had one PRI running 30 ports and it worked 100%. We now > added a further PRI and 30 ports and all was well until the last week or > so... when the lines get relatively busy (say 40 ports being used) the > balance answer but will not authenticate (to radius) and give the error > "Host Unavailable". Check your configuration. You may have one of the following. 1. Check the setting on the modem Make sure they are set for login/network with security on set all login network dialin reset all set all security on 1. Check to see if you have changed the modem setup set it to default. krish > > Any ideas? > > Kind Regards Rob > rob@dbn.lia.net - Web http://www.dbn.lia.net > Phone +27(31)705-4767 Fax +27(31)705-2031 > Club Internet Durban - Neptune Software - USRobotics > Give a man a fish and you feed him for a day; teach him to use the Net and > he won't bother you for weeks. > > - > 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. >

we are doing a lot of isdn to schools. in the past we have used pipelines and given them subnets for their computer labs. stupid question, how would one route a subnet of addresses to one particular line or one particular login on a tc hub? matthew

God bless the command line... I don't know why I started with the GUI, but it was a mistake. I just wish the NetServer had something along the lines of "show config". It would make backing up the config trivial, and would take us all one step closer to a TCM-less world. Charles > Nothing like the command line interface....One of the reasons I have always > liked cisco and 3com over our ascend ISDN equipment...... > > Marshall Morgan wrote: > > > On Friday, March 13, 1998 5:20 PM, Charles Sprickman [SMTP:spork@inch.com] > > wrote: > > > This got me once, and the problem was that I had used the GUI client to > > > configure the NetServer. That's bad news, as it didn't quite set all the > > > ports as I'd wanted. Check all of your NetServer settings to see that > > > what you have set agrees for all 48 ports... > > > > Just to make sure .... from the command line interface... > > > > set all security on > > set all login network dialin > > set all prompt login: > > set limit 60 > > set modem s5-s64 active > > > > Marshall Morgan > > > > Internet Doorway, Inc. (aka NETDOOR) > > http://www.netdoor.com > > 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28 > > > > - > > 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. > > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rick----Network Engineer | Connect to a Backbone not a Wishbone > http://www.monmouth.com | Monmouth Internet Corporation > 732-842-5366 | Network Operations Center > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > - > 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. >

Charles Sprickman <spork@inch.com> writes: > I just wish the NetServer had something along the > lines of "show config". It would make backing up the config trivial, and > would take us all one step closer to a TCM-less world. Or, you can approach it from the other side, and rather than worrying about saving a NETServer configuration, just ensure that you can recreate its configuration from scratch - then you don't need to have a current copy of its configuration anywhere. Of course this presumes some sort of consistency in configurations or some central config file from which NETServer configurations can be automated, but I'd bet most people with more than a few NETServers already have something like that. That way, whenever you have to deal with a new NETServer, you just "re-configure" it - it doesn't matter if it's an existing one or a replacement. And you can always "erase flash" and reboot to ensure you are starting from all known quantities before sending over the specific commands. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Your problem is either 1. you do not have a IP address pool or 2. your have a problem with the filter ID that your are using. The filter id which you have in your radius is unlim - therefore you should have a unlim.in and unlim.out in the NAS. So check your IP address pool if you do have one then fine, not comment the filter line and connect. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sat, 14 Mar 1998, Rev. Jim wrote: > > I have a NetServer /8-I that will connect any user that i set up a local > account on the NetServer. They connect and have full network access. > Below is a snippet from the syslog file on the Radius server for a > successful connection. > > [trimmed syslog] > "COMMON":: A call has arrived on interface mod:5 > "COMMON":: A call is established on interface mod:5 > "COMMON":: Port mod:5 successful local authentication for user: default > > "VERBOSE":: User default successfully connected to the PPP process on > interface mod:5 > "COMMON":: Port mod:5 successful local authentication for user: packrat > > "COMMON":: Port mod:5 user default session connected protocol: PPP - ip > address: 207.8.15.161 - ip > "COMMON":: The connection on if mod:5 was dropped for user packrat > "COMMON":: Port mod:5 user default session disconnected protocol: PPP - ip > address 207.8.15.161 - > > [trimmed radius logfile] > Mar 14 13:22:53 1998: Original-Accounting: 3/0 'default' from > darkstar.aus-etc.com port 7 $"default69358725" PPP/207.8.15.161 Stop > Mar 14 13:22:53 1998: Received-Accounting: 3/1 'default' from > darkstar.aus-etc.com port 7 $"default69358725" PPP/207.8.15.161 Stop > Mar 14 13:22:53 1998: Accounting: 3/1 'default' from darkstar.aus-etc.com > port 7 $"default69358725" PPP/207.8.15.161 Stop - OK -- t > > > But when I try to pull the authentication from the Radius server, the IP > address (line 6) is never assigned and the connection is severed. > > [trimmed syslog] > "COMMON":: A call has arrived on interface mod:5 > "COMMON":: A call is established on interface mod:5 > "COMMON":: Port mod:5 successful local authentication for user: default > > "VERBOSE":: User default successfully connected to the PPP process on > interface mod:5 > "COMMON":: Port mod:5 successful RADIUS authentication for user: catz > > "COMMON":: The connection on if mod:5 was dropped for user default > > [trimmed radius logfile] > Mar 14 13:23:35 1998: Original-Authentication: 13/0 'catz' from > darkstar.aus-etc.com port 0 > Mar 14 13:23:35 1998: Received-Authentication: 13/1 'catz' from > darkstar.aus-etc.com port 0 > Mar 14 13:23:35 1998: Authentication: 13/1 'catz' from darkstar.aus-etc.com > port 0 - OK -- total 0, holding 0 > > Now my radius config file > > [users] > #DEFAULT Authentication-Type = Realm > DEFAULT Authentication-Type = Unix-PW > Filter-Id = "unlim" > > pppuser Authentication-Type = None > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Netmask = 255.255.255.255, > Framed-Routing = None, > Framed-MTU = 1500, > Framed-Compression = Van-Jacobson-TCP-IP > > and everything else is commented out. I have tried variations of 0, 254 & > 255 in the last octet of the netmask. I am wanting the NetServer to assign > the IP address from the pool. What obvious thing have I overlooked here?? > > Thanks in Advance > > > If you've ever paid for a 6-pack of beer with pennies... > you might be a redneck. > > packrat > > > - > 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. >

Hi. is there an AT-command to configure a quad modem that it should not wait for a dial tone. I am using the total control behind an pbx. Therefor the modems will never get a dial tone. Thanks Martin

Hi. is there an AT-command to configure a quad modem that it should not wait for a dial tone. I am using the total control behind an pbx. Therefor the modems will never get a dial tone. Thanks Martin

On Fri, 13 Mar 1998, matthew wrote: > we are doing a lot of isdn to schools. in the past we have used > pipelines and given them subnets for their computer labs. > > stupid question, how would one route a subnet of addresses to one > particular line or one particular login on a tc hub? > > matthew > > - > 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. > Using RADIUS give the user something like: signal Authentication-Type = Unix-PW Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address = 208.214.45.1, Framed-IP-Netmask = 255.255.255.240, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP if the routed network is not used for the Point-to-Point connection with the client, but just router thru it you can do: signal Authentication-Type = Unix-PW Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address = 208.214.45.1, Framed-IP-Netmask = 255.255.255.240, Framed-Route = "208.214.46.0/28 208.214.45.1 1", Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP You can put more than one Framed-Route if needed /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Anybody know the proper way to have RADIUS return a filter to a TC hub? The filter was created and named bess.in on the chassis The return attribute id Framed-Filter-Id -OR- Filter-Id by definition I am trying to send either back to the chassis as Framed-Filter-Id = bess.in Filter-Id = bess.in and it does not take it. The everyting works fine without the string. Is this another documented but unsupported "feature" of the USR software? Sean -- - Sean P. Barrett, Vice President - Mailing Address: - - MicroLine Computer Systems - 507-511 Norwich Road- - CyberZone Internet Services - Plainfield, CT 06374- - http://www.mcs-corp.com - USA - - http://www.cyberzone.net - Phone:(860) 564-7400- - sbarrett@cyberzone.net - Fax: (860) 564-7402-

thanks. we run an unusual radius that is part of a large accounting package that works great but doesn't allow any manual intervention. but now i'll share the examples you gave me with the author of the software. matthew Brian wrote: > > On Fri, 13 Mar 1998, matthew wrote: > > > we are doing a lot of isdn to schools. in the past we have used > > pipelines and given them subnets for their computer labs. > > > > stupid question, how would one route a subnet of addresses to one > > particular line or one particular login on a tc hub? > > > > matthew > > > > - > > 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. > > > > Using RADIUS give the user something like: > > signal Authentication-Type = Unix-PW > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Address = 208.214.45.1, > Framed-IP-Netmask = 255.255.255.240, > Framed-MTU = 1500, > Framed-Compression = Van-Jacobson-TCP-IP > > if the routed network is not used for the Point-to-Point connection with > the client, but just router thru it you can do: > > signal Authentication-Type = Unix-PW > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Address = 208.214.45.1, > Framed-IP-Netmask = 255.255.255.240, > Framed-Route = "208.214.46.0/28 208.214.45.1 1", > Framed-MTU = 1500, > Framed-Compression = Van-Jacobson-TCP-IP > > You can put more than one Framed-Route if needed > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > - > 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. -- the spa! online services - www.the-spa.com - info@the-spa.com 654b new ludlow road, south hadley, ma 01075 - 413 539-9818 providing online services since 1989!

You should be sending: Framed-Filter (Attribute 11) Data=bess Leave the .in or .out off. That's so you can specify an in and out filter with just one attribute by calling one bess.in, and the other bess.out. Peter D. Mayer NetWalk Tech Support dmayer@netwalk.com -----Original Message----- Anybody know the proper way to have RADIUS return a filter to a TC hub? The filter was created and named bess.in on the chassis The return attribute id Framed-Filter-Id -OR- Filter-Id by definition I am trying to send either back to the chassis as Framed-Filter-Id = bess.in Filter-Id = bess.in and it does not take it. The everyting works fine without the string. Is this another documented but unsupported "feature" of the USR software? Sean -- - Sean P. Barrett, Vice President - Mailing Address: - - MicroLine Computer Systems - 507-511 Norwich Road- - CyberZone Internet Services - Plainfield, CT 06374- - http://www.mcs-corp.com - USA - - http://www.cyberzone.net - Phone:(860) 564-7400- - sbarrett@cyberzone.net - Fax: (860) 564-7402- - 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.

On Sat, 14 Mar 1998, Sean Barrett wrote: > Anybody know the proper way to have RADIUS return a filter to a TC hub? > > The filter was created and named bess.in on the chassis > > The return attribute id Framed-Filter-Id -OR- Filter-Id by definition > > I am trying to send either back to the chassis as > > Framed-Filter-Id = bess.in > Filter-Id = bess.in > > and it does not take it. The everyting works fine without the string. Is > this another documented but unsupported "feature" of the USR software? filters are just "bess". So create bess.in and bess.out on the TC, and then just tell RADIUS to use filter "bess" and your good to go. Brian > > > Sean > > > -- > > ------------------------------------------------------------------ > - Sean P. Barrett, Vice President - Mailing Address: - > - MicroLine Computer Systems - 507-511 Norwich Road- > - CyberZone Internet Services - Plainfield, CT 06374- > - http://www.mcs-corp.com - USA - > - http://www.cyberzone.net - Phone:(860) 564-7400- > - sbarrett@cyberzone.net - Fax: (860) 564-7402- > ------------------------------------------------------------------ > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

I have a NetServer /8-I that will connect any user that i set up a local account on the NetServer. They connect and have full network access. Below is a snippet from the syslog file on the Radius server for a successful connection. [trimmed syslog] "COMMON":: A call has arrived on interface mod:5 "COMMON":: A call is established on interface mod:5 "COMMON":: Port mod:5 successful local authentication for user: default "VERBOSE":: User default successfully connected to the PPP process on interface mod:5 "COMMON":: Port mod:5 successful local authentication for user: packrat "COMMON":: Port mod:5 user default session connected protocol: PPP - ip address: 207.8.15.161 - ip "COMMON":: The connection on if mod:5 was dropped for user packrat "COMMON":: Port mod:5 user default session disconnected protocol: PPP - ip address 207.8.15.161 - [trimmed radius logfile] Mar 14 13:22:53 1998: Original-Accounting: 3/0 'default' from darkstar.aus-etc.com port 7 $"default69358725" PPP/207.8.15.161 Stop Mar 14 13:22:53 1998: Received-Accounting: 3/1 'default' from darkstar.aus-etc.com port 7 $"default69358725" PPP/207.8.15.161 Stop Mar 14 13:22:53 1998: Accounting: 3/1 'default' from darkstar.aus-etc.com port 7 $"default69358725" PPP/207.8.15.161 Stop - OK -- t But when I try to pull the authentication from the Radius server, the IP address (line 6) is never assigned and the connection is severed. [trimmed syslog] "COMMON":: A call has arrived on interface mod:5 "COMMON":: A call is established on interface mod:5 "COMMON":: Port mod:5 successful local authentication for user: default "VERBOSE":: User default successfully connected to the PPP process on interface mod:5 "COMMON":: Port mod:5 successful RADIUS authentication for user: catz "COMMON":: The connection on if mod:5 was dropped for user default [trimmed radius logfile] Mar 14 13:23:35 1998: Original-Authentication: 13/0 'catz' from darkstar.aus-etc.com port 0 Mar 14 13:23:35 1998: Received-Authentication: 13/1 'catz' from darkstar.aus-etc.com port 0 Mar 14 13:23:35 1998: Authentication: 13/1 'catz' from darkstar.aus-etc.com port 0 - OK -- total 0, holding 0 Now my radius config file [users] #DEFAULT Authentication-Type = Realm DEFAULT Authentication-Type = Unix-PW Filter-Id = "unlim" pppuser Authentication-Type = None Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP and everything else is commented out. I have tried variations of 0, 254 & 255 in the last octet of the netmask. I am wanting the NetServer to assign the IP address from the pool. What obvious thing have I overlooked here?? Thanks in Advance If you've ever paid for a 6-pack of beer with pennies... you might be a redneck. packrat

On Sat, 14 Mar 1998, Ken Hunter, Aspiring Technologies wrote: > Try this. I run a netserver 8/i with the new code. > > xxxxx Password = "xxxxxx" > Service-Type = Framed-User, > Framed-Compression = Van-Jacobsen-TCP-IP, > Framed-IP-Address = 255.255.255.254, > Framed-IP-Netmask = 255.255.255.255, > Framed-MTU = 1514, > Framed-Protocol = PPP, > Framed-Routing = None > > If you are running the livingston'ish code in the netserver, change the > 1514 to 1500. The 255.255.255.254 framed ip address causes the netserver to > pick an address from the pool. > > Ken :) > > So Netserver 8/i's use an MTU of 1514? TC hubs use 1500 right? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Try this. I run a netserver 8/i with the new code. xxxxx Password = "xxxxxx" Service-Type = Framed-User, Framed-Compression = Van-Jacobsen-TCP-IP, Framed-IP-Address = 255.255.255.254, Framed-IP-Netmask = 255.255.255.255, Framed-MTU = 1514, Framed-Protocol = PPP, Framed-Routing = None If you are running the livingston'ish code in the netserver, change the 1514 to 1500. The 255.255.255.254 framed ip address causes the netserver to pick an address from the pool. Ken :) >[users] >#DEFAULT Authentication-Type = Realm >DEFAULT Authentication-Type = Unix-PW > Filter-Id = "unlim" > >pppuser Authentication-Type = None > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Netmask = 255.255.255.255, > Framed-Routing = None, > Framed-MTU = 1500, > Framed-Compression = Van-Jacobson-TCP-IP > >and everything else is commented out. I have tried variations of 0, 254 & >255 in the last octet of the netmask. I am wanting the NetServer to assign >the IP address from the pool. What obvious thing have I overlooked here?? > >Thanks in Advance > > >If you've ever paid for a 6-pack of beer with pennies... >you might be a redneck. > >packrat > > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

thankx for such a quick reply ken, brian and krish At 05:28 PM 3/14/98 -0500, you wrote: >Try this. I run a netserver 8/i with the new code. > >xxxxx Password = "xxxxxx" > Service-Type = Framed-User, > Framed-Compression = Van-Jacobsen-TCP-IP, > Framed-IP-Address = 255.255.255.254, > Framed-IP-Netmask = 255.255.255.255, > Framed-MTU = 1514, > Framed-Protocol = PPP, > Framed-Routing = None > >If you are running the livingston'ish code in the netserver, change the >1514 to 1500. The 255.255.255.254 framed ip address causes the netserver to >pick an address from the pool. > >Ken :) i put in uname Password = "upasswd" Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Framed-MTU = 1514, Framed-Compression = Van-Jacobson-TCP-IP and could log right in and surf the net under uname account in the NetServer - it finally dawned on me that the Framed-MTU used by my box and Merit differed and changed that in my users file #DEFAULT Authentication-Type = Realm DEFAULT Authentication-Type = Unix-PW # Filter-Id = "unlim" pppuser Authentication-Type = None Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address = 255.255.255.254, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Framed-MTU = 1514, Framed-Compression = Van-Jacobson-TCP-IP about the MTU - this was chosen for me by the USR box PARAMETERS FOR NETWORK USERS: Network Service PPP Header Compression: TCPIP MTU: 1514 [ . . .] Filter Zones ENABLED IP Usage: ENABLED Address Selection: ASSIGN Remote IP Address: 0.0.0.0/H IP Routing: NONE Default Route Option: DISABLED IP RIP Routing Protocol: RIPV2 IP RIP Routing Policies: IP RIP Authentication Key: [. . . .] PARAMETERS for NETWORK PPP USERS [. . . .] Expansion Algorithm: LINEAR Compression Algorithm: NONE Compression Reset Mode: AUTO >Your problem is either > >1. you do not have a IP address pool or >2. your have a problem with the filter ID that your are using. > >The filter id which you have in your radius is unlim - therefore you >should have a unlim.in and unlim.out in the NAS. > >So check your IP address pool if you do have one then fine, not comment >the filter line and connect. > >krish netserver>show ip settings IP SYSTEM SETTINGS IP Dynamic Address Pool Begin: 207.008.015.161 IP Dynamic Address Pool Size: 8 IP System Host Address: 207.008.015.021 IP Forwarding ENABLED if i log in as one of the users in the Local NetServer database (add user xxxx) the first address out of the pool is infact given and everything is kool - side question - i heard from my ISP that he uses about 2x IP pool to modem ports, any consent/dissent on that the filter thing bothered me - there is no unlim that i set up but i thought that there could be a default one that i have not found yet - i am still green at doing this - so i also tried Filter-Id = "" and there was no change - i also commented it out as can be seen above, again without change - then i did a netserver>set network user default filter_zones disable netserver>save all and guess what - no change win95 gives the error message Dial-Up Networking could not negotiate a compatible set of network protocols you specified in the Server Type settings. Check your network configuration in the Control Panel then try the connection again and win NT4.0W gives TCP/IP CP reported error 733: The PPP control protocol for this network protocol is not available on this server. i am at a point now where i need to ask if there is a possibility that i did not make all the correct choices in my radius Makefile - like should # Define USR_CCA to enable USR support: USR = -DUSR_CCA be defined or not - when i have it defined, my log file gets about 100 extra entries in it (i have radiusd -x -x in inetd.conf) =================================================================== a Golf Tip - Don't pick up a lost ball before it stops rolling 8-) ===================================================================

If they are running the new pilgrim code 4.x.x - the recommended mtu is 1514, if they are running the livingston'ish code, the recommended mtu is 1500 Ken :) > >So Netserver 8/i's use an MTU of 1514? TC hubs use 1500 right? > >Brian > >/-------------------------- signal@shreve.net -----------------------------\ >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | >| Network Administrator | Perl, Linux | Web hosting, online stores, | >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | >| 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | >| mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | >\-------------------------- 318-222-2638 x109 -----------------------------/ > > > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

Also, change that async ppp map to 0 vice 255 - a knowlegable source said that the default value of 255 was a goof. Ken :) At 07:23 PM 3/14/98 -0600, you wrote: >thankx for such a quick reply ken, brian and krish > >At 05:28 PM 3/14/98 -0500, you wrote: >>Try this. I run a netserver 8/i with the new code. >> >>xxxxx Password = "xxxxxx" >> Service-Type = Framed-User, >> Framed-Compression = Van-Jacobsen-TCP-IP, >> Framed-IP-Address = 255.255.255.254, >> Framed-IP-Netmask = 255.255.255.255, >> Framed-MTU = 1514, >> Framed-Protocol = PPP, >> Framed-Routing = None >> >>If you are running the livingston'ish code in the netserver, change the >>1514 to 1500. The 255.255.255.254 framed ip address causes the netserver to >>pick an address from the pool. >> >>Ken :) > >i put in > >uname Password = "upasswd" > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Address = 255.255.255.254, > Framed-IP-Netmask = 255.255.255.255, > Framed-Routing = None, > Framed-MTU = 1514, > Framed-Compression = Van-Jacobson-TCP-IP > >and could log right in and surf the net under uname account in the >NetServer - it finally dawned on me that the Framed-MTU used by my box and >Merit differed and changed that in my users file > >#DEFAULT Authentication-Type = Realm >DEFAULT Authentication-Type = Unix-PW ># Filter-Id = "unlim" >pppuser Authentication-Type = None > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Address = 255.255.255.254, > Framed-IP-Netmask = 255.255.255.255, > Framed-Routing = None, > Framed-MTU = 1514, > Framed-Compression = Van-Jacobson-TCP-IP > >about the MTU - this was chosen for me by the USR box > >PARAMETERS FOR NETWORK USERS: >Network Service PPP >Header Compression: TCPIP >MTU: 1514 >[ . . .] >Filter Zones ENABLED >IP Usage: ENABLED >Address Selection: ASSIGN >Remote IP Address: 0.0.0.0/H >IP Routing: NONE >Default Route Option: DISABLED >IP RIP Routing Protocol: RIPV2 >IP RIP Routing Policies: >IP RIP Authentication Key: >[. . . .] >PARAMETERS for NETWORK PPP USERS >[. . . .] >Expansion Algorithm: LINEAR >Compression Algorithm: NONE >Compression Reset Mode: AUTO > > > >>Your problem is either >> >>1. you do not have a IP address pool or >>2. your have a problem with the filter ID that your are using. >> >>The filter id which you have in your radius is unlim - therefore you >>should have a unlim.in and unlim.out in the NAS. >> >>So check your IP address pool if you do have one then fine, not comment >>the filter line and connect. >> >>krish > >netserver>show ip settings > >IP SYSTEM SETTINGS >IP Dynamic Address Pool Begin: 207.008.015.161 >IP Dynamic Address Pool Size: 8 >IP System Host Address: 207.008.015.021 >IP Forwarding ENABLED > >if i log in as one of the users in the Local NetServer database (add user >xxxx) the first address out of the pool is infact given and everything is >kool - side question - i heard from my ISP that he uses about 2x IP pool to >modem ports, any consent/dissent on that > >the filter thing bothered me - there is no unlim that i set up but i >thought that there could be a default one that i have not found yet - i am >still green at doing this - so i also tried > > Filter-Id = "" > >and there was no change - i also commented it out as can be seen above, >again without change - then i did a > >netserver>set network user default filter_zones disable >netserver>save all > >and guess what - no change > >win95 gives the error message > >Dial-Up Networking could not negotiate a compatible set of network >protocols you specified in the Server Type settings. Check your network >configuration in the Control Panel then try the connection again > >and win NT4.0W gives > >TCP/IP CP reported error 733: The PPP control protocol for this network >protocol is not available on this server. > >i am at a point now where i need to ask if there is a possibility that i >did not make all the correct choices in my radius Makefile - like should > ># Define USR_CCA to enable USR support: >USR = -DUSR_CCA > >be defined or not - when i have it defined, my log file gets about 100 >extra entries in it (i have radiusd -x -x in inetd.conf) > > >=================================================================== >a Golf Tip - Don't pick up a lost ball before it stops rolling 8-) >=================================================================== > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

It'd still be really slick if there was a utility somewhere to decompile a NetServer config file (i.e. a .NCF as saved by Netserver Manager) into an ASCII format that could be cut & pasted into the command line to recreate the whole configuration. I've tweaked our running Netservers so much that I'd be a bit lost trying to build a template config from scratch... (It would also be nice if Livingston had a similar utility for ComOS; since the Netserver code is based on an ancient version of it, one might be tweaked to work for the other... and we still have a bit of Livingston hardware...) The last place I worked had Xyplex gear, and there was a utility called "apgen" that would do exactly this. You could then take a new terminal server out of the box, and either paste this config in or have it download it from a tftp server. All you'd have to do later is put passwords back in; apgen stripped all password info out so you didn't have to worry about plaintext passwords appearing. And Cisco, of course, has something like this built into IOS. If I had a pointer to some info about the format of the thing (maybe some .h files) I might be willing to do this myself. Does the ARC have anything like this? We have two that I have yet to start trying to set up... Mike Andrews/MA12/icq6602506 (this chromosome intentionally left blank) mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ Senior Systems & Network Administrator, Digital Crescent, Frankfort, KY Providing x2 Internet Access in Franklin, Anderson, and Shelby Counties On Sat, 14 Mar 1998, David Bolen wrote: > Charles Sprickman <spork@inch.com> writes: > > > I just wish the NetServer had something along the > > lines of "show config". It would make backing up the config trivial, and > > would take us all one step closer to a TCM-less world. > > Or, you can approach it from the other side, and rather than worrying > about saving a NETServer configuration, just ensure that you can > recreate its configuration from scratch - then you don't need to have > a current copy of its configuration anywhere. Of course this presumes > some sort of consistency in configurations or some central config file > from which NETServer configurations can be automated, but I'd bet most > people with more than a few NETServers already have something like that. > > That way, whenever you have to deal with a new NETServer, you just > "re-configure" it - it doesn't matter if it's an existing one or a > replacement. And you can always "erase flash" and reboot to ensure > you are starting from all known quantities before sending over the > specific commands. > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ > \-----------------------------------------------------------------------/ > > - > 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. >

On Sun, 15 Mar 1998, Brian wrote: > On Sat, 14 Mar 1998, Ken Hunter, Aspiring Technologies wrote: > > > If they are running the new pilgrim code 4.x.x - the recommended mtu is > > 1514, if they are running the livingston'ish code, the recommended mtu is 1500 > > > > Ken :) > > > ok, so an arc which runs 4.0.x pilgrim code wants its ppp interfaces to > have mtu's of 1514..........next question.......... No this is not true - The default user on the HiPer/pilgrim is set to 1514. For PPP set user MTU to 1500 in radius or do not give a MTU. krish > > If i set an MTU in RADIUS of 1514, is windows going to fight me on it, or > accept the server suggested MTU of 1514? > > > > > > > > > > > >So Netserver 8/i's use an MTU of 1514? TC hubs use 1500 right? > > > > > >Brian > > > > > >/-------------------------- signal@shreve.net -----------------------------\ > > >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > >| Network Administrator | Perl, Linux | Web hosting, online stores, | > > >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > >| 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > >| mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > >\-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > >- > > > 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. > > > > > - > > ************************************************************************ > > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. > > > > Ken Hunter Aspiring Technologies > > mailto:ken@aspire.net 9304 Troy Drive > > http://www.aspire.net Nokesville, Va 20181 > > ************************************************************************ > > > > - > > 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. > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > - > 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. >

I've an HDM running (ER?) code 1.0.95, and I've noticed that it's recently been reporting bps110 for mdmCsFinalTxLinkRate on all 24 of its channels. It has kept doing it despite a reboot. Has anyone else seen this? Thanks. --- Mark R. Lindsey, mark@datasys.net Internet Engineer, DSS Online Voice: +1 912 241 0607; Fax: +1 912 241 0190 288 4.usr: mdmCsFinalTxLinkRate.2024 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2023 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2022 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2021 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2020 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2019 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2018 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2017 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2016 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2015 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2014 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2013 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2012 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2011 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2010 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2009 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2008 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2007 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2006 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2005 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2004 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2003 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2002 = bps110(1) 288 4.usr: mdmCsFinalTxLinkRate.2001 = bps110(1)

Hello fellow TCH users, Has anyone found an SNMP OID that can be polled to see which B channels are in operation? Thanks, Tom

On Sat, 14 Mar 1998, Ken Hunter, Aspiring Technologies wrote: > If they are running the new pilgrim code 4.x.x - the recommended mtu is > 1514, if they are running the livingston'ish code, the recommended mtu is 1500 > > Ken :) ok, so an arc which runs 4.0.x pilgrim code wants its ppp interfaces to have mtu's of 1514..........next question.......... If i set an MTU in RADIUS of 1514, is windows going to fight me on it, or accept the server suggested MTU of 1514? > > > > > >So Netserver 8/i's use an MTU of 1514? TC hubs use 1500 right? > > > >Brian > > > >/-------------------------- signal@shreve.net -----------------------------\ > >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > >| Network Administrator | Perl, Linux | Web hosting, online stores, | > >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > >| 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > >| mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > >\-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > >- > > 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. > > > - > ************************************************************************ > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. > > Ken Hunter Aspiring Technologies > mailto:ken@aspire.net 9304 Troy Drive > http://www.aspire.net Nokesville, Va 20181 > ************************************************************************ > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Anyone ever have one of there modems wig out and answer with a steady "tone" instead of a carrier tone? Its very monotone sounding. 1. What setting is wigging out when this happens? What should I look for? 2. Why does it happen? I am not sure which modem it is, I will have to see in the morning, either a quad or a hdm. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

tw <tomw@athena.3-cities.com> writes: > Has anyone found an SNMP OID that can be polled to see which B channels > are in operation? It depends on the specific card type you are querying, but you can use either "ids0StatDs0" for the Dual-PRI cards, or "usrds0StatDs0" for HDM cards. You mention B channels, but in case you have any channelized sites, you can use "ds0StatDs0" for dual cards (both older 186 and current 386 based) in channelized T1 mode. The "usrds0StatDs0" object works for any HDM configuration. There are also "bulk" objects for each card type that makes a quicker job of querying all channels - although you have to wait for a future HDM code release for it to support the object defined in the MIB. You might want to look back in the archives at some messages of mine (such as "Re: (usr-tc) mdmCsStatus" on 2/24/98) which gets into these objects in a bit more detail - it has come up in the past under the context of determining usage of a chassis. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

I have a user that has an AMJET modem. Just recently, she is having problems connecting to our main PoP (which is using TC racks). What happens, is she calls in, the TC answers, and continuously goes through handshaking. The weird thing is that she can change the number in her DUN to one of our other PoP's and connect just fine. The other PoP's are set up exactly the same as our main PoP, also using TC's. Any clues? -Eric

I've seen (heard) this problem too. I was told by a USR techie that it is the result of the phone line taking a noise hit during the negotiation process. Tom Walters, Network Janitor Brian wrote: > Anyone ever have one of there modems wig out and answer with a steady > "tone" instead of a carrier tone? Its very monotone sounding. > > 1. What setting is wigging out when this happens? What should I look for? > > 2. Why does it happen? > > I am not sure which modem it is, I will have to see in the morning, either > a quad or a hdm. > > Brian > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > - > 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.

Is it possible to find out who's logged in on a given port via SNMP? I'm using cmu-snmp utils, and I've got a working mib.txt, but I can't find a variable name that appears to contain a username. ____________________________________________________________________________ I. Dwayne Koonce E-mail: dwayne@txcyber.com System Administrator Phone: (409) 268-6800 Cybercom Corporation Fax: (409) 260-2652 ____________________________________________________________________________

I believe ATX3. oberle@ima.uni-stuttgart.de on 14/03/98 18:24:18 Please respond to usr-tc@lists.xmission.com cc: (bcc: Jason Kelton/AU/3Com) Hi. is there an AT-command to configure a quad modem that it should not wait for a dial tone. I am using the total control behind an pbx. Therefor the modems will never get a dial tone. Thanks Martin - 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.

I have a netserver 8I that hangs up on each modem, or user every 60 minutes. A user can log in and do what ever, but in 60 minutes, it hangs up. I've looked at the config and can't find any timeouts. Has anyone had this problem, or know of a solution? Tony

I don't think it is possible (I used snmpwalk to check all the variables) But I can come close if you use static address for each user. I think you = could probably figure out who was on from route information. I wrote an interface between the netserver and mrtg to show the number of = users that are on (http://dns1.syssrc.com/netserver.html Bob Roswell broswell@syssrc.com System Source 338 Clubhouse Road Hunt Valley, MD 21031 (410) 771-5544 ext 336 >>> "I. Dwayne Koonce" <dwayne@txcyber.com> 03/16 4:54 PM >>> Is it possible to find out who's logged in on a given port via SNMP? I'm using cmu-snmp utils, and I've got a working mib.txt, but I can't find a variable name that appears to contain a username. ___________________________________________________________________________= _ I. Dwayne Koonce E-mail: dwayne@txcyber.co= m=20 System Administrator Phone: (409) 268-6800 Cybercom Corporation Fax: (409) 260-2652 ___________________________________________________________________________= _ - 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.

On Mon, 16 Mar 1998, Eric Forcey wrote: > What happens, is she calls in, the TC answers, and continuously goes > through handshaking. > > The weird thing is that she can change the number in her DUN to one of our > other PoP's and connect just fine. The other PoP's are set up exactly the > same as our main PoP, also using TC's. > > Any clues? Let me guess. . . the other POP she dialed was long distance and the one with continuous handshaking was a local number. Your local telco has bad inter-office trunks, probably some piece is coming out of a 1A switch with AMI into a newer switch set for B8ZS. The long distance call is fine, and if she dials the local one with a pick code (i.e. 10288) it will probably work fine, since it will be routed as long distance and won't traverse the bad trunks. Hey, if that works it will eliminate your equipment as the culprit. Just a guess, though. -CH

Right now I'm struggling with HDM cards which are generating busy signals even though the line is free. Isn't there some sort of "four-way-green-light" prevention that could be built into the cards so if a modem is available, it is never generating a busy signal? I'd rather have modems that answer 100% of the time than modems that are busy 20% of the time due to a fault. If I need to busy out the card for a reason, I'll yank the PRI.

: I don't think it is possible (I used snmpwalk to check all the variables) : But I can come close if you use static address for each user. I think you : could probably figure out who was on from route information. :-D As soon as they start handing out class-B blocks to ISPs, we can all start doing that.

Does anyone know what 3com's stance on hot-swappability is on the Total Control racks ? Or can share experiences ? I've occassionally pulled quad modem cards and reseated them but I try and minimize this. Just wondering. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

At 05:19 AM 3/17/98 , you wrote: > > >Does anyone know what 3com's stance on hot-swappability is on the Total >Control racks ? Or can share experiences ? I've occassionally pulled >quad modem cards and reseated them but I try and minimize this. Just >wondering. Went over to 3Com's complex last week and was speaking to one of their engineers. He said if you pull a NAC (the cards in front) you should pull its NIC out first. Then you should reseat the NIC and then the NAC. I don't know if they do that to be cautious, but that's how he said we should do it. This is one of those things I'm sure you'll get a different answer from every person you ask at 3Com. Eric |0| Eric J. Lorenzo MediaCity World/ISPchannel |0| |0| 650.237.1465 - voice 650.237.1499 - fax |0| |0| Lorenzo@MediaCity.com http://www.ISPchannel.com |0|

We were told that was one of the best 'features' of a Total Control Chassis by a 3com installaion engineer. I think the manual even says that the way to reboot the NMC is by removing it and reseating it. We've never ha d a problem with it at all, and have used that feature several times. I wouldn't worry about it. -jay At 08:19 AM 3/17/98 -0500, you wrote: > > >Does anyone know what 3com's stance on hot-swappability is on the Total >Control racks ? Or can share experiences ? I've occassionally pulled >quad modem cards and reseated them but I try and minimize this. Just >wondering. > > Jeff Binkley > ASA Network Computing > >CMPQwk 1.42 9999 > >- > 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. > ____________________________________________________________________ Jay Christner Office: UN-019 Technical Services Phone:(219)-535-7640 Residential Computer Technician Goshen College ____________________________________________________________________

On Tue, 17 Mar 1998, Jeff Lynch wrote: > On Mon, 16 Mar 1998, Charles Hill wrote: > > > Let me guess. . . the other POP she dialed was long distance and the one > > with continuous handshaking was a local number. Your local telco has bad > > inter-office trunks, probably some piece is coming out of a 1A switch with > > AMI into a newer switch set for B8ZS. The long distance call is fine, and > > if she dials the local one with a pick code (i.e. 10288) it will probably > > work fine, since it will be routed as long distance and won't traverse the > > bad trunks. > > 1A is an analog switch. will kill X2 unless it's the customers > local CO and even then I would count on good connects. > I just got off the phone with her. I tried using a pick code (10228 didn't work here so I tried 10321). Same thing, she will get modem tone, but it will not complete the handshake. -Eric

Hot-Swapping a Netserver, T1, PRI, or HyperArc card will "kick" everyone off the entire chassis. Hot-Swapping a quad modem or HiperDsp will kick everyone off that modem/card. Hot-Swapping an NMC will not affect the users, just the remote manageabilty. =========================================================================== S t e v e n R. S h e p h e r d =========================================================================== CyberGate Internet Technologies | ICQ: 1412432 An ACSI Company | NetDudeFL @ EFnet Field Engineer | E-Mail: steven@gate.net (800)NET-GATE/(954)429-8065 | 9542595004@alphapage.airtouch.com ============================================================================ On Tue, 17 Mar 1998, Jay M Christner wrote: > Date: Tue, 17 Mar 1998 09:35:52 -0500 > From: Jay M Christner <jaymc@goshen.edu> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Hot Swappable ? > > We were told that was one of the best 'features' of a Total Control Chassis > by a 3com installaion engineer. I think the manual even says that the way > to reboot the NMC is by removing it and reseating it. We've never ha d a > problem with it at all, and have used that feature several times. I > wouldn't worry about it. > -jay > > At 08:19 AM 3/17/98 -0500, you wrote: > > > > > >Does anyone know what 3com's stance on hot-swappability is on the Total > >Control racks ? Or can share experiences ? I've occassionally pulled > >quad modem cards and reseated them but I try and minimize this. Just > >wondering. > > > > Jeff Binkley > > ASA Network Computing > > > >CMPQwk 1.42 9999 > > > >- > > 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. > > > ____________________________________________________________________ > Jay Christner Office: UN-019 > Technical Services Phone:(219)-535-7640 > Residential Computer Technician > Goshen College > ____________________________________________________________________ > > - > 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. >

This is a multi-part message in MIME format. --------------26CD84B02306F58195F36A1F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi. I've got 2 chassis, one with a Dual PRI, 12 Quad cards and an Edgeserver card. The Edgeserver is NOT hot swappable, the PRI is but obviously you lose all sessions. The Quad cards are hot-swappable but with a hitch. You have to remove them from the Edgeserver config before you remove them from the chassis. You do not need to remove the NIC unless you plan to replace that as well. Cheers, Jim Pergolizzi Autodesk Network Engineer CyberPort Montana wrote: > At 09:08 AM 3/17/98 -0800, you wrote: > This is exactly opposite of their printed instructions. > > From the "Quad V.34 Modem Card Hardware Install Guide"; > > Page 13 - "NOTE: When installing NICs and NACs into the Total Control > Chassis, always install the NICs first." > > Page 15 - "NOTE: When removing NICs and NACs from the Total Control > Chassis, always remove the NACs first." > > > > >Went over to 3Com's complex last week and was speaking to one of their > >engineers. He said if you pull a NAC (the cards in front) you should > >pull its NIC out first. Then you should reseat the NIC and then the > >NAC. > > > >I don't know if they do that to be cautious, but that's how he said we > >should do it. This is one of those things I'm sure you'll get a > >different answer from every person you ask at 3Com. > > > >Eric > > > >|0| Eric J. Lorenzo MediaCity World/ISPchannel |0| > >|0| 650.237.1465 - voice 650.237.1499 - fax |0| > >|0| Lorenzo@MediaCity.com http://www.ISPchannel.com |0| > > > >- > > 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. > > > > > > - > 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. --------------26CD84B02306F58195F36A1F Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Pergolizzi, Jim Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Jim Pergolizzi n: Pergolizzi;Jim org: Autodesk, Inc. adr: 3900 Civic Center Dr.;;;San Rafael;CA;94903;USA email;internet: jim.pergolizzi@autodesk.com title: Network Engineer tel;work: 415-507-8897 tel;fax: 415-507-8395 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------26CD84B02306F58195F36A1F--

At 09:08 AM 3/17/98 -0800, you wrote: This is exactly opposite of their printed instructions. From the "Quad V.34 Modem Card Hardware Install Guide"; Page 13 - "NOTE: When installing NICs and NACs into the Total Control Chassis, always install the NICs first." Page 15 - "NOTE: When removing NICs and NACs from the Total Control Chassis, always remove the NACs first." > >Went over to 3Com's complex last week and was speaking to one of their >engineers. He said if you pull a NAC (the cards in front) you should >pull its NIC out first. Then you should reseat the NIC and then the >NAC. > >I don't know if they do that to be cautious, but that's how he said we >should do it. This is one of those things I'm sure you'll get a >different answer from every person you ask at 3Com. > >Eric > >|0| Eric J. Lorenzo MediaCity World/ISPchannel |0| >|0| 650.237.1465 - voice 650.237.1499 - fax |0| >|0| Lorenzo@MediaCity.com http://www.ISPchannel.com |0| > >- > 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. > >

On Mon, 16 Mar 1998, Charles Hill wrote: > Let me guess. . . the other POP she dialed was long distance and the one > with continuous handshaking was a local number. Your local telco has bad > inter-office trunks, probably some piece is coming out of a 1A switch with > AMI into a newer switch set for B8ZS. The long distance call is fine, and > if she dials the local one with a pick code (i.e. 10288) it will probably > work fine, since it will be routed as long distance and won't traverse the > bad trunks. 1A is an analog switch. will kill X2 unless it's the customers local CO and even then I would count on good connects. ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

On Tue, 17 Mar 1998, Jeff Lynch wrote: > On Mon, 16 Mar 1998, Charles Hill wrote: > > > Let me guess. . . the other POP she dialed was long distance and the one > > with continuous handshaking was a local number. Your local telco has bad > > inter-office trunks, probably some piece is coming out of a 1A switch with > > AMI into a newer switch set for B8ZS. The long distance call is fine, and > > if she dials the local one with a pick code (i.e. 10288) it will probably > > work fine, since it will be routed as long distance and won't traverse the > > bad trunks. > > 1A is an analog switch. will kill X2 unless it's the customers > local CO and even then I would count on good connects. ^^^^^^ oops, i meant "would not". i hate correcting myself. ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

: Went over to 3Com's complex last week and was speaking to one of their : engineers. He said if you pull a NAC (the cards in front) you should : pull its NIC out first. Then you should reseat the NIC and then the : NAC. Hmm. So he told you that to pull a NAC/NIC pair, you'd (1) pull the NIC and then (2) pull the NAC, and to insert a NAC/NIC pair you'd (3) insert the NIC and then (4) insert the NAC. Right? I've understood that, for cards which use a NIC module, the NIC should already be present any time that the NAC is present; that is, steps 3 and 4 make sense to my way of thinking, but not 1 and 2. (Some (or all?) NACs will reset when the NIC is removed or inserted, btw.)

Jay M Christner was heard to say: >We were told that was one of the best 'features' of a Total Control Chassis >by a 3com installaion engineer. I think the manual even says that the way >to reboot the NMC is by removing it and reseating it. We've never ha d a >problem with it at all, and have used that feature several times. I >wouldn't worry about it. >-jay > >At 08:19 AM 3/17/98 -0500, you wrote: >> >> >>Does anyone know what 3com's stance on hot-swappability is on the Total >>Control racks ? Or can share experiences ? I've occassionally pulled >>quad modem cards and reseated them but I try and minimize this. Just >>wondering. From what I remember, all the from cards (NAC's) are hot swappable with the exception of the power supplies. The back cards (NIC's) are not hot swappable, but I've done it anyway. If it has them funcky rack latches on it, it says "hot swap" to me. --Ricky

I am experiencing intermittent errors on my T1 lines. Mostly Code Violation Errors. The telco has been out numerous times to test it, and never saw any problems. It seems like whenever they are testing or 'monitoring' for errors they dont appear. When they stop watching the errors come back. The problem is very intermittent, some days the line wont even stay up, sometimes its weeks without a problem. Anybody experience anything like this? Ted

Does anyone know if the external courier imodem is supposed to be able to take inbound analog calls? And if so, what's the magic setting to get it to work. As I recall, there is logic inside there to ring the analog line. So far, I've only gotten it to take digital calls. --Ricky

Original message from Ricky Beam: > >Jay M Christner was heard to say: >>We were told that was one of the best 'features' of a Total Control Chassis >>by a 3com installaion engineer. I think the manual even says that the way >>to reboot the NMC is by removing it and reseating it. Yes, I've been on the phone w/ 3Com tech support, and after my suggestions of "How about I just power cycle the whole chssis?" I could hear the terror in his voice. To reboot the NMC, NetServer, and dualPRI cards if you can't do it from the console, they suggest re-seating the cards. And power cycle the whole unit only as a last resort. >>We've never had a >>problem with it at all, and have used that feature several times. I >>wouldn't worry about it. In my experience, it's sometimes necessary to make a flacky card behave, or at least show up on TCM. >From what I remember, all the from cards (NAC's) are hot swappable with the >exception of the power supplies. The back cards (NIC's) are not hot >swappable, but I've done it anyway. > >If it has them funcky rack latches on it, it says "hot swap" to me. > >--Ricky Actually, Ricky, you and I have yanked some live power supplies. Jas, Interpath Communications Data Network Technician Jas.Eckard@interpath.net

On Tue, 17 Mar 1998, Ted Cekan wrote: > I am experiencing intermittent errors on my T1 lines. Mostly Code Violation > Errors. The telco has been out numerous times to test it, and never saw any > problems. It seems like whenever they are testing or 'monitoring' for > errors they dont appear. When they stop watching the errors come back. The > problem is very intermittent, some days the line wont even stay up, > sometimes its weeks without a problem. > > Anybody experience anything like this? > > Ted > Those types of problems are very difficult to track down. From my limited experience I've seen those problems to one of the several listed below. o telco cable pair problems (affected by vibration or moisture) o interior wiring ( your cable from smart jack to your box) o interference o equipment If you can afford to do it, loopback your connection for a day or two and have them send you some test patterns on their equipment. Then over that period of time they may be able to catch some of the errors in real time. Otherwise, most HDSL equipment has counters which can be cleared and viewed with a history of a week. Tell your carrier services to clear the counters and then when you see errors see if their equipment is getting them too. You should be able to do this on a live circuit...the loopback will of course take you down... Probably before that, you may want to just replace your interior wiring or cabling for sanity sake. Interference is definitely a hard one to track down. We had some kind of harmonic noise on a an used T1 to our facility which was up for testing and the cross talk hosed 4 operational T1's for about 3 hours. Luckily our telco guy had a hunch to kill the open line and our T1's came back. It's always a good idea make sure your racks are grounded properly. Lastly, if all else fails, it could be your equipment or CSU causing the problems. Try swapping them out if you have spare equipment and see if that helps. Good luck...let me know if you need any other ideas. ============================================================================= Eric Merkel | URL: www.metalink.net | Local Access in MetaLink Technologies, Inc | EMail: merkel@defnet.com | Defiance, Fulton, 419-782-3472 Ext. 4 | Sales: 1-888-999-8002 | Henry, & Williams Co. =============================================================================

Original message from Ted Cekan: > >I am experiencing intermittent errors on my T1 lines. Mostly Code Violation >Errors. The telco has been out numerous times to test it, and never saw any >problems. It seems like whenever they are testing or 'monitoring' for >errors they dont appear. When they stop watching the errors come back. The >problem is very intermittent, some days the line wont even stay up, >sometimes its weeks without a problem. > >Anybody experience anything like this? Yes, I call this "repairman's syndrome". :^) Seriously, check that the settings that the telco has for these circuits are the same as are on your cards. There have been numerous times when one of our circuits "mysteriously changed" its configuration at the telco. When the telco tested, was your equipment still connected? If not, it's very likely your card has gone bad. (Or that the telco changed the config.) Jas, Interpath Communications Data Network Technician Jas.Eckard@interpath.net

we are using os version 4.0.14 Ken Hunter, Aspiring Technologies wrote: > What os are you running? > > At 06:14 PM 3/16/98 -0700, you wrote: > >I have a netserver 8I that hangs up on each modem, or user every 60 > minutes. A > >user can log in and do what ever, but in 60 minutes, it hangs up. I've > looked at > >the > >config and can't find any timeouts. > > > >Has anyone had this problem, or know of a solution? > > > > > >Tony > > > >- > > 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. > > > - > ************************************************************************ > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. > > Ken Hunter Aspiring Technologies > mailto:ken@aspire.net 9304 Troy Drive > http://www.aspire.net Nokesville, Va 20181 > ************************************************************************ > > - > 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.

What os are you running? At 06:14 PM 3/16/98 -0700, you wrote: >I have a netserver 8I that hangs up on each modem, or user every 60 minutes. A >user can log in and do what ever, but in 60 minutes, it hangs up. I've looked at >the >config and can't find any timeouts. > >Has anyone had this problem, or know of a solution? > > >Tony > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

Are you using RADIUS? If so, what version?

A couple of things (straight from usr) 1. enable the syslog facility. If you are running nt, get the syslogd kit and install it - ya should be watching your equipment anyway. Why do syslog? Because it will spaz and cause neat things like random reboots, hangs, slowdowns, etc. 2. Set your ppp async map to 0 for trans and receive - do this on the default user. The current default value is 255 - a goof according to one source. I know some of this stuff sounds kinda crazy, but it makes the 4.0.14 pilgrim code behave itself quite well. Ken :) At 05:24 PM 3/17/98 -0700, you wrote: >we are using os version 4.0.14 > > > > >Ken Hunter, Aspiring Technologies wrote: > >> What os are you running? >> >> At 06:14 PM 3/16/98 -0700, you wrote: >> >I have a netserver 8I that hangs up on each modem, or user every 60 >> minutes. A >> >user can log in and do what ever, but in 60 minutes, it hangs up. I've >> looked at >> >the >> >config and can't find any timeouts. >> > >> >Has anyone had this problem, or know of a solution? >> > >> > >> >Tony >> > >> >- >> > 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. >> > >> - >> ************************************************************************ >> Web Hosting, E-mail addresses, DNS services, Dedicated circuits. >> 33.6, X2(56k), ISDN Dialup available in Prince William County VA. >> >> Ken Hunter Aspiring Technologies >> mailto:ken@aspire.net 9304 Troy Drive >> http://www.aspire.net Nokesville, Va 20181 >> ************************************************************************ >> >> - >> 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. > > > > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

Hi All: I wrote a very clumsy shell script that checked my unix server syslog file to extract all Netserver related log information . A sample of the log is here : 0x0000080f Mar 17 18:48:49 - Mar 17 19:14:59 MODEM S13 user1 209.8.6.48 0:26:1. 0x00000810 Mar 17 18:54:53 - Mar 17 19:23:10 MODEM S14 user2 209.8.6.57 0:28:21. 0x00000811 Mar 17 19:13:45 - Mar 17 19:52:58 MODEM S15 user3 209.8.6.39 0. 0x00000812 Mar 17 19:42:44 - Mar 17 19:43:39 MODEM S16 user4 209.8.6.41 0:0:54. It reports, infos like event ID, Start , Stop, [Modem|PRI], port #, UserName, PPP/IP, SessionDuration. The code is only 50 lines. I would be happy to mail you one if you like. I would appreciate any feedback you can give me. Again, the coding is very unprofessional. And the generated log is lack of info as, Traffic amount and Modem Speed. Thanks Meng tsaim@mft.com

We're having some trouble with logins for DOVBS callers. Connections are fine, but no login. Here is a sample from the syslog for a normal analog caller (date and time removed): MODEM: S2: CALL_REF >0x0000015b< PRI_SLOT >0< TS >25< SPAN >0< B_CH >14< acct 0x0000015b dial: S2 call arrived. sent out answer incoming call for S2. acct 0x0000015b dial: S2 answered the phone using handle 6. NetS: port S2 Login succeeded for chaser S2 TCP port 1030 to 156.121.5.59 port 23 connection established S2 to 156.121.5.59 port 23 terminated( 4) NetS: port S2 session disconnected user chaser And here is the same caller over DOVBS: acct 0x0000015b dial: S2 hung up the phone. Call duration 0:0:44. MODEM: S2: CALL_REF >0x0000015c< PRI_SLOT >0< TS >26< SPAN >0< B_CH >15< acct 0x0000015c dial: S2 call arrived. sent out answer incoming call for S2. S2 didn't get online! status=-1, connect_fail=21, link_fail=31 As you can see, on the DOVBS call there is no equivalent to: dial: S2 answered the phone using handle 6. on the DOVBS call. We have followed the instructions assiduously -- perhaps this log snippit will help identify what we must be missing. All equipment is up to the latest code. Thanks, DCP

As I recall, MTU is negotiated as the least common denominator, so it should be a nonissue. However, I also recall reading that MTU negotiation takes place as part of the PPP setup stuff, so by the time the radius server passes the info back, the MTU has already been fixed. Scripted logins don't have this problem, since they get the info back before the start of PPP negotiation. YMMV, and I could be completely bonkers. On Sun, 15 Mar 1998, Brian wrote: > On Sat, 14 Mar 1998, Ken Hunter, Aspiring Technologies wrote: > > > If they are running the new pilgrim code 4.x.x - the recommended mtu is > > 1514, if they are running the livingston'ish code, the recommended mtu is 1500 > > > > Ken :) > > > ok, so an arc which runs 4.0.x pilgrim code wants its ppp interfaces to > have mtu's of 1514..........next question.......... > > If i set an MTU in RADIUS of 1514, is windows going to fight me on it, or > accept the server suggested MTU of 1514? > > > > > > > > > > > >So Netserver 8/i's use an MTU of 1514? TC hubs use 1500 right? > > > > > >Brian > > > > > >/-------------------------- signal@shreve.net -----------------------------\ > > >| Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > > >| Network Administrator | Perl, Linux | Web hosting, online stores, | > > >| ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > > >| 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > > >| mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > > >\-------------------------- 318-222-2638 x109 -----------------------------/ > > > > > > > > > > > >- > > > 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. > > > > > - > > ************************************************************************ > > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. > > > > Ken Hunter Aspiring Technologies > > mailto:ken@aspire.net 9304 Troy Drive > > http://www.aspire.net Nokesville, Va 20181 > > ************************************************************************ > > > > - > > 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. > > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > - > 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. >

I am using the Radius that comes with Netware 4.1=20 It is one of the few things that works properly w/ my netserver Bob Roswell broswell@syssrc.com System Source 338 Clubhouse Road Hunt Valley, MD 21031 (410) 771-5544 ext 336 >>> "Brian McIntire" <Brian_McIntire@mw.3com.com> 03/17 9:15 PM >>> Are you using RADIUS? If so, what version? - 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.

On 17 Mar 1998, Jaye Mathisen wrote: > > As I recall, MTU is negotiated as the least common denominator, so > it should be a nonissue. > > However, I also recall reading that MTU negotiation takes place as > part of the PPP setup stuff, so by the time the radius server > passes the info back, the MTU has already been fixed. > > Scripted logins don't have this problem, since they get the info back > before the start of PPP negotiation. > > YMMV, and I could be completely bonkers. Nope - That is correct. The MTU specified in RADIUS is useless for PAP based PPP logins since PPP has already started before the RADIUS server even comes into the picture. --jr ---- Josh Richards - <jrichard@livingston.com> - [Beta Engineer] LUCENT Technologies - Remote Access Business Unit (formerly Livingston Enterprises, Inc.) http://www.livingston.com/

I will confess, I don't see anything in this message related to MTU. If the >> was user supplied, the indicated message has nothing to do with MTU that I can see, there's no correlation between the line speed and MTU directly. On Wed, 18 Mar 1998, Ricky Beam wrote: > Jaye Mathisen was heard to say: > >As I recall, MTU is negotiated as the least common denominator, so > >it should be a nonissue. > > > >However, I also recall reading that MTU negotiation takes place as > >part of the PPP setup stuff, so by the time the radius server > >passes the info back, the MTU has already been fixed. > > I guess that depends... > > 03/18/98 03:44:07 PPP: IPCP negotiated, session 1, rem: 199.72.1.93 > 03/18/98 03:44:07 PPP: MP negotiated, session 1 > 03/18/98 03:44:07 PPP: PAP remote accepted us, Channel 1 > 03/18/98 03:44:07 PPP: NCP up, session 1, Channel 1 > 03/18/98 03:44:01 PPP: Channel 1 up, Dialout > 03/18/98 03:44:01 Received Connect Ind. for DN: 9547284 > 03/18/98 03:44:00 >>Issued 64Kb Setup Request from our DN: 8447355 > 03/18/98 03:44:00 IP: Demand call requested by 199.72.252.1 > > MTU is negotiated via IPCP after PAP and thus after consulting RADIUS. Think > about it for a second. If you can set the IP address via RADIUS, then why > wouldn't you be able to set the MTU (another IP option). > > --Ricky > > - > 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. >

Jaye Mathisen was heard to say: >As I recall, MTU is negotiated as the least common denominator, so >it should be a nonissue. > >However, I also recall reading that MTU negotiation takes place as >part of the PPP setup stuff, so by the time the radius server >passes the info back, the MTU has already been fixed. I guess that depends... 03/18/98 03:44:07 PPP: IPCP negotiated, session 1, rem: 199.72.1.93 03/18/98 03:44:07 PPP: MP negotiated, session 1 03/18/98 03:44:07 PPP: PAP remote accepted us, Channel 1 03/18/98 03:44:07 PPP: NCP up, session 1, Channel 1 03/18/98 03:44:01 PPP: Channel 1 up, Dialout 03/18/98 03:44:01 Received Connect Ind. for DN: 9547284 03/18/98 03:44:00 >>Issued 64Kb Setup Request from our DN: 8447355 03/18/98 03:44:00 IP: Demand call requested by 199.72.252.1 MTU is negotiated via IPCP after PAP and thus after consulting RADIUS. Think about it for a second. If you can set the IP address via RADIUS, then why wouldn't you be able to set the MTU (another IP option). --Ricky

Try getting it to accept 2 different users at the same time. If so, probably has to do with the max channels limit in the netserver profile for that user. My thinkig is this setting has to do with the isdn channels avail - but try it anyway.=20 Ken :) At 11:37 AM 3/18/98 +0100, you wrote: >I have a couple questions about the Netserver 16 > >I want to use a Netserver 16 with 8 ISDN BRI's for my signup users >(using MS IEAK 4) I do not want this machine to access the network. The >setup is done, it works splendidly, but the Netserver doesn't accept >more than one signup connection. I defined the user in the Netserver, as >I do not want to use a Radius server for this (who needs radius for just >one user=A0?=A0?=A0?) >Any pointers to that=A0? > >I'm using Netserver + with 4.0.14 software on it and Netserver Manager >Plus... > >Thanks, > >Robert von Bismarck >Petrel Communication S.A. > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

send a copy !!! cheers bosire Meng Tsai wrote: > Hi All: > > I wrote a very clumsy shell script that checked my unix server > syslog file to extract all Netserver related log information . A > sample of the log is here : > > 0x0000080f Mar 17 18:48:49 - Mar 17 19:14:59 MODEM S13 user1 209.8.6.48 > 0:26:1. > 0x00000810 Mar 17 18:54:53 - Mar 17 19:23:10 MODEM S14 user2 209.8.6.57 > 0:28:21. > 0x00000811 Mar 17 19:13:45 - Mar 17 19:52:58 MODEM S15 user3 209.8.6.39 > 0. > 0x00000812 Mar 17 19:42:44 - Mar 17 19:43:39 MODEM S16 user4 209.8.6.41 > 0:0:54. > > It reports, infos like > event ID, Start , Stop, [Modem|PRI], port #, UserName, PPP/IP, > SessionDuration. > > The code is only 50 lines. I would be happy to mail you one if > you like. I would appreciate any feedback you can give me. > > Again, the coding is very unprofessional. And the generated > log is lack of info as, Traffic amount and Modem Speed. > > Thanks > > Meng > tsaim@mft.com > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

> Yes, I call this "repairman's syndrome". :^) We experienced this on one of our fibre runs a few months ago - turned out to be a faulty power supply card in the optomux. Every time they came to look at it, it ran fine. Cheers, Bob.

Tony, Do you have re-chap timeout set on your Netserver 8I? --Tom Tony Loosle wrote: > I forgot to mention this as well: > > If I add a user into the local database of the 8Iplus, it does not hang up > on him. > > Mike wrote: > > > At 06:14 PM 3/16/98 -0700, you wrote: > > >I have a netserver 8I that hangs up on each modem, or user every 60 > > minutes. A > > >user can log in and do what ever, but in 60 minutes, it hangs up. I've > > looked at > > >the > > >config and can't find any timeouts. > > > > > >Has anyone had this problem, or know of a solution? > > > > 1) If your using RADIUS is there an Idle-Timout attribute sent to your > > users with a 60 minute time out? > > 2) Check the DEFAULT user. If an idle timeout is defined for the default > > user then it will apply to ALL of your > > callers unless overwritten by RADIUS. > > > > -m > > > > - > > 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. > > - > 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.

I am using the Total Control Security and Accounting from USR. Brian McIntire wrote: > Are you using RADIUS? If so, what version? > > - > 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.

I'm useing USR's total control accounting and security. Whats interesting is that the netserver 16's don't have a problem, only my 8Iplus box does this. Mike wrote: > At 06:14 PM 3/16/98 -0700, you wrote: > >I have a netserver 8I that hangs up on each modem, or user every 60 > minutes. A > >user can log in and do what ever, but in 60 minutes, it hangs up. I've > looked at > >the > >config and can't find any timeouts. > > > >Has anyone had this problem, or know of a solution? > > 1) If your using RADIUS is there an Idle-Timout attribute sent to your > users with a 60 minute time out? > 2) Check the DEFAULT user. If an idle timeout is defined for the default > user then it will apply to ALL of your > callers unless overwritten by RADIUS. > > -m > > - > 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.

I forgot to mention this as well: If I add a user into the local database of the 8Iplus, it does not hang up on him. Mike wrote: > At 06:14 PM 3/16/98 -0700, you wrote: > >I have a netserver 8I that hangs up on each modem, or user every 60 > minutes. A > >user can log in and do what ever, but in 60 minutes, it hangs up. I've > looked at > >the > >config and can't find any timeouts. > > > >Has anyone had this problem, or know of a solution? > > 1) If your using RADIUS is there an Idle-Timout attribute sent to your > users with a 60 minute time out? > 2) Check the DEFAULT user. If an idle timeout is defined for the default > user then it will apply to ALL of your > callers unless overwritten by RADIUS. > > -m > > - > 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.

Thus spake Tatai SV Krishnan >On Wed, 18 Mar 1998, Josh Richards <Josh Richards wrote: >> Nope - That is correct. The MTU specified in RADIUS is useless for PAP >> based PPP logins since PPP has already started before the RADIUS server >> even comes into the picture. >The above statement is correct for Livingston and NETServer - Not for >HiPer ARC. How does the ARC handle this? Restart LCP negotiations? Means a slightly longer delay in the PPP startup procedure doesn't it? If the ARC's take half as long to auth and start PPP as the netserver do, I'm not sure I like adding any more time to it. Not that its a *really* big deal, but I do have customers that notice the length of time it takes to start passing packets. :/ -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 06:14 PM 3/16/98 -0700, you wrote: >I have a netserver 8I that hangs up on each modem, or user every 60 minutes. A >user can log in and do what ever, but in 60 minutes, it hangs up. I've looked at >the >config and can't find any timeouts. > >Has anyone had this problem, or know of a solution? 1) If your using RADIUS is there an Idle-Timout attribute sent to your users with a 60 minute time out? 2) Check the DEFAULT user. If an idle timeout is defined for the default user then it will apply to ALL of your callers unless overwritten by RADIUS. -m

The primary reason is because of the following... If you install a NETServer NAC before its associated NIC, it will not be able to identify the interfaces attached and hence, fail to initialise them. If this was a V.35/Ethernet NIC, and it was installed after the NAC, then the Ethernet and V.35 Interfaces would not work. The reason for this, is because of the modularity with the NIC. Although we only have Ethernet/FrameRelay and TokenRing NICs, its theory (I would assume) is futures based. What happens when ATM and E3 nics are available for example, and they are all supported on the one firmware release. I would assume this not to be the case for NETServer, but more possibly for ARC. The same for the NMC and Quad Modems. for a Quad card to operate, you don't necessarily need a NIC installed. If the NMC NAC is installed first, before the NIC, it can't initialise a NIC on bootup if one is not installed, it won't activate that interface. Hope this helps. Regards, Jason. ELorenzo@MediaCity.com on 18/03/98 03:08:02 Please respond to usr-tc@lists.xmission.com cc: (bcc: Jason Kelton/AU/3Com) At 05:19 AM 3/17/98 , you wrote: > > >Does anyone know what 3com's stance on hot-swappability is on the Total >Control racks ? Or can share experiences ? I've occassionally pulled >quad modem cards and reseated them but I try and minimize this. Just >wondering. Went over to 3Com's complex last week and was speaking to one of their engineers. He said if you pull a NAC (the cards in front) you should pull its NIC out first. Then you should reseat the NIC and then the NAC. I don't know if they do that to be cautious, but that's how he said we should do it. This is one of those things I'm sure you'll get a different answer from every person you ask at 3Com. Eric |0| Eric J. Lorenzo MediaCity World/ISPchannel |0| |0| 650.237.1465 - voice 650.237.1499 - fax |0| |0| Lorenzo@MediaCity.com http://www.ISPchannel.com |0| - 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.

Yeah... when removing the cards, there is no actual order of priority. Just take whichever out first. see my other email regarding insertion.... mark@vielle.datasys.net on 18/03/98 03:18:11 Please respond to usr-tc@lists.xmission.com cc: (bcc: Jason Kelton/AU/3Com) : Went over to 3Com's complex last week and was speaking to one of their : engineers. He said if you pull a NAC (the cards in front) you should : pull its NIC out first. Then you should reseat the NIC and then the : NAC. Hmm. So he told you that to pull a NAC/NIC pair, you'd (1) pull the NIC and then (2) pull the NAC, and to insert a NAC/NIC pair you'd (3) insert the NIC and then (4) insert the NAC. Right? I've understood that, for cards which use a NIC module, the NIC should already be present any time that the NAC is present; that is, steps 3 and 4 make sense to my way of thinking, but not 1 and 2. (Some (or all?) NACs will reset when the NIC is removed or inserted, btw.) - 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.

Our Netserver (TC-Hub) reset itself recently. It does it fairly often but I didn't have logging on before. Now I do. Can anyone tell me what these messages mean? I noticed this in the log from a couple days ago. There were hundreds of them repeated over the course of a few minutes until the call was finally terminated: Mar 15 20:58:42 netserver.tidewater.net S36: error -19 setting remote ACCM Also, these messages (and many more like them) came through around the time the netserver reset: Mar 18 09:20:52 netserver.tidewater.net S5 packet bus handle opened. Handle = 0. Mar 18 09:20:52 netserver.tidewater.net S6 packet bus handle opened. Handle = 1. Mar 18 09:20:52 netserver.tidewater.net S7 packet bus handle opened. Handle = 2. Mar 18 09:20:52 netserver.tidewater.net S8 packet bus handle opened. Handle = 3. Mar 18 09:20:52 netserver.tidewater.net S9 packet bus handle opened. Handle = 4. Mar 18 09:20:52 netserver.tidewater.net S10 packet bus handle opened. Handle = 5. Mar 18 09:20:52 netserver.tidewater.net S11 packet bus handle opened. Handle = 6. Mar 18 09:20:52 netserver.tidewater.net S12 packet bus handle opened. Handle = 7. Mar 18 09:20:52 netserver.tidewater.net S13 packet bus handle opened. Handle = 8. Mar 18 09:20:52 netserver.tidewater.net S14 packet bus handle opened. Handle = 9. Mar 18 09:20:52 netserver.tidewater.net S5 packet bus connected. Mar 18 09:20:52 netserver.tidewater.net S6 packet bus connected. Mar 18 09:20:52 netserver.tidewater.net S10 packet bus connected. Mar 18 09:20:52 netserver.tidewater.net S14 packet bus connected. Mar 18 09:22:20 netserver.tidewater.net Chassis Awareness notice: slot# 0, all channels, NAC type = 4, new status 1 Mar 18 09:22:20 netserver.tidewater.net Chassis Awareness notice: slot# 1, all channels, NAC type = 13, new status 1 Mar 18 09:22:20 netserver.tidewater.net Chassis Awareness notice: slot# 2, all channels, NAC type = 13, new status 1 Mar 18 09:22:20 netserver.tidewater.net Chassis Awareness notice: slot# 3, all channels, NAC type = 13, new status 1 When it was noticed that we had no calls in progress and the modems were not answering, I had to telnet into the netserver and do the commands: set modem s5-s52 active reset all save all so we could answer calls again. I'm stumped, any ideas? It's an older netserver with 4 meg of memory running 3.3.3. I've tried upgrading the software and putting more memory in, but then the netserver would reset every 3-10 minutes. - Wayne Barber - barberw@tidewater.net Internet System Administrator Coastal Telco Services

Quite frequently we have problems with netservers who's ports will not go active. typically it happens when the netserver card is upgraded with software. typical chassis will have pri/ 12 quads/ 16meg netsv/ 4meg NMC I have tried upgrading the chassis to current suite. powercycle chassis reset quads remove quads from service then back set modem s5-s52 active reset all ports reset netserver nac/ nic any ideas ______________________________________________________________________ | Henry Moats Network Services Support nc0419 ext 3671 | ______________________________________________________________________|

I have a couple questions about the Netserver 16 I want to use a Netserver 16 with 8 ISDN BRI's for my signup users (using MS IEAK 4) I do not want this machine to access the network. The setup is done, it works splendidly, but the Netserver doesn't accept more than one signup connection. I defined the user in the Netserver, = as I do not want to use a Radius server for this (who needs radius for = just one user=A0?=A0?=A0?) Any pointers to that=A0? I'm using Netserver + with 4.0.14 software on it and Netserver Manager Plus... Thanks, Robert von Bismarck Petrel Communication S.A.

At 05:59 PM 3/18/98 +0100, you wrote: >Nope, MS IEAK is the MS Internet Explorer Administration Kit, which >automates the setup of win95, Nt, win3.11 and Mac for Internet access. >There's nothing in there with fixed IP's... I tried tracing the PPP >facility, and here's what makes me tick : > This is a known issue with compression in the 4.0.14 code.. Looks like compression is the problem in your case. Try this on your localy defined user.. set net user register ppp compression_algorithm none let me know your results.. This is fixed in the next release that will be comming out soon.. -m =20 >At 19:29:34, Facility "PPP", Level "COMMON":: [csm_drv_state_change] >bundle 14, link 17, state 1=20 >At 19:29:34, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: >sending frame to L1=20 >At 19:29:34, Facility "PPP", Level "COMMON":: [psm_chkrej]: type 0x11=20 >At 19:29:34, Facility "PPP", Level "COMMON":: [psm_chkrej]: Remote >Swacked MRRU=20 >At 19:29:34, Facility "PPP", Level "COMMON":: [psm_chkrej]: type 0x13=20 >At 19:29:34, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: >sending frame to L1=20 >At 19:29:37, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: >sending frame to L1=20 >At 19:29:37, Facility "PPP", Level "COMMON":: [psm_open(LCP)]: PPP >Connection Open=20 >At 19:29:37, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: >sending frame to L1=20 >At 19:29:37, Facility "PPP", Level "COMMON":: PPP - UNKNOWN Compression >allocation reqeust to .=20 >(USR should check its spelling sometimes ;-)))) >At 19:29:37, Facility "PPP", Level "COMMON":: [ppp_load_config]: >LOCAL_IP_ADDR 0xc233cbe1=20 >At 19:29:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: >sending frame to L1=20 >At 19:29:38, Facility "PPP", Level "COMMON":: [psm_open(CHAP)]: PPP >Connection Open=20 >At 19:29:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: >sending frame to L1=20 >At 19:29:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: >sending frame to L1=20 >At 19:29:38, Facility "PPP", Level "UNUSUAL":: [psm_open]: No more room, >Releasing link (17)!! =20 >This line is really weird, at that moment (2 minutes after a reboot) >there was just another modem with a 'register' user connected !! >At 19:29:38, Facility "PPP", Level "COMMON":: [csm_release_link] bundle >14, link 17, drop_id 42=20 >At 19:29:38, Facility "PPP", Level "COMMON":: [csm_release_dialup_link] >bundle 14, link 17=20 >At 19:29:38, Facility "PPP", Level "UNUSUAL":: PPP connection down to >register. >At 19:29:38, Facility "PPP", Level "COMMON":: [csm_fwdr_state_change] >bundle 14, proto_type -2, state 3 >At 19:29:40, Facility "PPP", Level "COMMON":: [csm_drv_state_change] >bundle 14, link 17, state 3 >At 19:29:40, Facility "PPP", Level "COMMON":: [csm_release_link] bundle >14, link 17, drop_id 87 > >Here's the definition of register : > >netserver>sh user register > >INFORMATION FOR USER: register >Status: INACTIVE >Type: NETWORK >Expiration: 00- -0000 >Message: >Callback Type: NORMAL >Phone Number: >Alternate Phone Number: >Input Filter: >Output Filter: >Modem Group: all (D) >Session Timeout 0 >Idle Timeout: 0 > >PARAMETERS FOR NETWORK USERS: >Network Service PPP >Header Compression: TCPIP (D) >MTU: 1514 (D) >Send Password: >Appletalk: DISABLED >Appletalk Address Range: 0 - 0 >Filter Zones ENABLED (D) >IP Usage: ENABLED >Address Selection: ASSIGN >Remote IP Address: 0.0.0.0/H (D) >IP Routing: NONE (D) >Default Route Option: DISABLED (D) >IP RIP Routing Protocol: RIPV1 (D) >IP RIP Routing Policies: >IP RIP Authentication Key: >IPX Usage: DISABLED >IPX Address: 0 >IPX Routing: RESPOND (D) >IPX WAN Usage: DISABLED (D) >Spoofing: ENABLED > >PARAMETERS for NETWORK PPP USERS >Max Channels 2 >Channel Decrement Percent: 20 (D) >Channel Expansion Percent: 60 (D) >Expansion Alg Receive ACC Map: 0 (D) >Transmit ACC Map: 0 (D) >Compression Algorithm: AUTO (D) >Compression Reset Mode: AUTO (D) >Min Compression Size: 256 (D) >Spoofing Protocols: >Connection Reservation: DISABLED >Suspend Timer: 0 >Reconnect Type: PEER >NetBIOS Proxy KeepAlive Timeout: 0 orithm: >LINEAR (D) > >I don't think anything's wrong with my config, should I downgrade to >3.xxx so that it'll work, or is there a workaround to have multiple >users called 'register' on at the netserver at the same time ? > >Thanks for any further info, > >Robert > > -----Original Message----- > From: Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] > Sent: mercredi, 18. f=E9vrier 1998 14:25 > To: Robert von Bismarck > Cc: 'usr-tc@xmission.com' > Subject: Re: (usr-tc) Netserver user definitions > > On Wed, 18 Mar 1998, Robert von Bismarck wrote: > > > I have a couple questions about the Netserver 16 > >=20 > > I want to use a Netserver 16 with 8 ISDN BRI's for my signup >users > > (using MS IEAK 4) I do not want this machine to access the >network. The > > setup is done, it works splendidly, but the Netserver doesn't >accept > > more than one signup connection. I defined the user in the >Netserver, as > > I do not want to use a Radius server for this (who needs >radius for just > > one user=A0?=A0?=A0?) > > Any pointers to that=A0? > > I guess when you say MS IEAK - you mean Microsoft Internet >Explorer -=20 > Check the IP address of the user, if this is a static IP user >the you can=20 > have only one connection. > > krish > > >=20 > > I'm using Netserver + with 4.0.14 software on it and Netserver >Manager > > Plus... > >=20 > > Thanks, > >=20 > > Robert von Bismarck > > Petrel Communication S.A. > >=20 > > - > > 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. > >=20 > > - > 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. > >- > 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. > `'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`' Mike Wronski(mwronski@coredump.ae.usr.com) 3Com/U.S.Robotics Network Systems Engineer=20 PGP: http://coredump.ae.usr.com/pgp (Prefered) =09 =20 =20

Jeff Mcadams said once upon a time: >>The above statement is correct for Livingston and NETServer - Not for >>HiPer ARC. > >How does the ARC handle this? Restart LCP negotiations? Means a >slightly longer delay in the PPP startup procedure doesn't it? If the >ARC's take half as long to auth and start PPP as the netserver do, I'm >not sure I like adding any more time to it. Not that its a *really* big >deal, but I do have customers that notice the length of time it takes to >start passing packets. :/ I've got an ISDN user who is complaining that it takes 7 seconds to connect and authenticate to the ARC.

Our Netserver (TC-Hub) reset itself recently. It does it fairly often but I didn't have logging on before. Now I do. Can anyone tell me what these messages mean? I noticed this in the log from a couple days ago. There were hundreds of them repeated over the course of a few minutes until the call was finally terminated: Mar 15 20:58:42 netserver.tidewater.net S36: error -19 setting remote ACCM Also, these messages (and many more like them) came through around the time the netserver reset: Mar 18 09:20:52 netserver.tidewater.net S5 packet bus handle opened. Handle = 0. Mar 18 09:20:52 netserver.tidewater.net S6 packet bus handle opened. Handle = 1. Mar 18 09:20:52 netserver.tidewater.net S7 packet bus handle opened. Handle = 2. Mar 18 09:20:52 netserver.tidewater.net S8 packet bus handle opened. Handle = 3. Mar 18 09:20:52 netserver.tidewater.net S9 packet bus handle opened. Handle = 4. Mar 18 09:20:52 netserver.tidewater.net S10 packet bus handle opened. Handle = 5. Mar 18 09:20:52 netserver.tidewater.net S11 packet bus handle opened. Handle = 6. Mar 18 09:20:52 netserver.tidewater.net S12 packet bus handle opened. Handle = 7. Mar 18 09:20:52 netserver.tidewater.net S13 packet bus handle opened. Handle = 8. Mar 18 09:20:52 netserver.tidewater.net S14 packet bus handle opened. Handle = 9. Mar 18 09:20:52 netserver.tidewater.net S5 packet bus connected. Mar 18 09:20:52 netserver.tidewater.net S6 packet bus connected. Mar 18 09:20:52 netserver.tidewater.net S10 packet bus connected. Mar 18 09:20:52 netserver.tidewater.net S14 packet bus connected. Mar 18 09:22:20 netserver.tidewater.net Chassis Awareness notice: slot# 0, all channels, NAC type = 4, new status 1 Mar 18 09:22:20 netserver.tidewater.net Chassis Awareness notice: slot# 1, all channels, NAC type = 13, new status 1 Mar 18 09:22:20 netserver.tidewater.net Chassis Awareness notice: slot# 2, all channels, NAC type = 13, new status 1 Mar 18 09:22:20 netserver.tidewater.net Chassis Awareness notice: slot# 3, all channels, NAC type = 13, new status 1 When it was noticed that we had no calls in progress and the modems were not answering, I had to telnet into the netserver and do the commands: set modem s5-s52 active reset all save all so we could answer calls again. I'm stumped, any ideas? It's an older netserver with 4 meg of memory running 3.3.3. I've tried upgrading the software and putting more memory in, but then the netserver would reset every 3-10 minutes. - Wayne Barber - barberw@tidewater.net Internet System Administrator Coastal Telco Services

Wayne Barber said once upon a time: >Are you sure this is what you want? According to my handy IP Subnet >Calculator (www.net3group.com) that netmask would only work with a >class A network broken into 8151 subnets. Since goshen.edu's address >starts with 199, you have a class C. Maybe you need 255.255.255.248 >which would give you 32 subnets. Bzzzt. Here's how I figure masks and available addresses: 256 - 4th mask = available addresses + 1 subnet number + 1 broadcast number Thusly, 256 - 248 = 6 available addresses + 1 subnet + 1 broadcast This is actually easier with supernetting. Just remember you still have a subnet and a broadcast in there. I don't use anything smaller than a class C on interfaces, so this mainly applies to BGP and CIDR calculation: 256 - 3rd mask = available class C sized subnets 256 - 2nd mask = available class B sized subnets 256 - 1st mask = available class A sized subnets

I have two problems with my TC chassis: 1) I want to use ppp call-back, but it kit doesn't appear to support the lcp extensions to facilitate this (RFC1570). 3Com are saying it should be compliant, but it doesn't work. 2) Using a scripted dialback login (because of the problem above) the netserver will not route to or from destinations that have been called back. The unit works fine for straight dial-in connections. The chassis configuration and software revisions are: Pri E1 - 2.5.4 Quad modem's - 5.5.7 Netserver - 3.5.34 NMC - 4.3.9 Has anyone had the same problems and is aware of a fix (or not!)? Alan Cross

CyberGate Field Engineer said once upon a time: >One issue, not really a problem is that the login message comes across the >screen as: > >Welcome To CyberGate Username: > >What we would like is at least one carraige return after the login prompt. >In the regular Netserver, it's done with "set message sxxxx Welcome To >CyberGate^^^". The three "^^^" gives 3 carraige returns. > >I have tried putting <cr>, ^, and ^M after the login message, but the >HiperARC won't accept that, and when putting it IN the login message it >prints the actual characters. arc>set modem_group all message ? This field is an alphanumeric String It has a maximum size of 64. If the string is surrounded by double quotes: There is no maximum field size. There can be an escape character '\' inside the quoted string if followed by a b, f, n, r, t or v it will cause special characters to be placed in the string \b = backspace \f = formfeed \n = newline \r = carriage return \t = tab \v = vertical tab if followed by an x, will cause the next two characters to be interpreted as a hexadecimal constant. x0A = 0x0a if followed by any other character, will cause that character to be placed in the token a Double Quote will place the Double Quote in the token a '\' will place one '\' in the token I think "\r\n" is what you're after.

I'm trying to change the netmask setting on my NMC (4.3.9) in a Total Control Chassis from 255.255.255.0 to 255.255.248.0 However it gives me an "Invalid subnet mask" message when I try to save it to memory. Is there anyway to change this, because this is really giving us fits? ____________________________________________________________________ Jay Christner Office: UN-019 Technical Services Phone:(219)-535-7640 Residential Computer Technician Goshen College ____________________________________________________________________

Tom Bilan said once upon a time: > >We're getting our first Hiper ARC soon. Is there a cut and dry >configuration example telnet script thingy that someone threw together >that possible they could post in the group? (with the sensitive stuff >changed of-course) > >I have a big text file for the netserver's which is a big help for >setting up those but with the complete OS rewrite, nothing looks the >same on the ARC. Here's my latest and greatest. Much is specific to the way I have things set up here, but you should be able to get the basic idea. Change the X.X.X.X to the IP address needed, and the XXXXX to your RADIUS key. set chassis slot 1 car hdm_24 own yes type static ports 23 set chassis slot 2 car hdm_24 own yes type static ports 23 set chassis slot 3 car hdm_24 own yes type static ports 23 set chassis slot 4 car hdm_24 own yes type static ports 23 set chassis slot 5 car hdm_24 own yes type static ports 23 set chassis slot 6 car hdm_24 own yes type static ports 23 set chassis slot 7 car hdm_24 own yes type static ports 23 set chassis slot 8 car hdm_24 own yes type static ports 23 set chassis slot 9 car hdm_24 own yes type static ports 23 set chassis slot 10 car hdm_24 own yes type static ports 23 set chassis slot 11 car hdm_24 own yes type static ports 23 add user guest password "" login_service rlogin type login set login user guest login_host_ip_address X.X.X.X set login user guest terminal_type dialup enable user guest add dns server X.X.X.X preference 2 set dns domain_name xmission.com set modem_group all message "Welcome to XMission Internet Access\r\n\r\n Type 'guest' for Guest Services\r\n\r\n 'account' for PPP\r\n 'account@slip' for SLIP\r\n 'account@shell' for Shell\r\n\r\n" set modem_group all prompt "rackname-tc login: " # Don't do this section over telnet! disable ip network ip set ip network ip routing_protocol ripv2 set ip network ip rip_policies_update no_ripv1_receive set ip network ip rip_policies_update no_send_compat enable ip network ip set authentication primary_secret XXXXX set accounting primary_secret XXXXX set system name XMission set system contact support@xmission.com set command prompt rackname-tc set syslog X.X.X.X facility log_local3 set ppp receive_authentication pap add ip pool rackname initial X.X.X.X size 254 enable ip security_option disallow_source_route_options set ntp primary_server X.X.X.X set ntp secondary_server X.X.X.X set ntp enabled yes

> From: "Jay M Christner" <jaymc@goshen.edu> > I'm trying to change the netmask setting on my NMC (4.3.9) in a Total > Control Chassis from 255.255.255.0 to 255.255.248.0 However it gives me an > "Invalid subnet mask" message when I try to save it to memory. Is there > anyway to change this, because this is really giving us fits? Are you sure this is what you want? According to my handy IP Subnet Calculator (www.net3group.com) that netmask would only work with a class A network broken into 8151 subnets. Since goshen.edu's address starts with 199, you have a class C. Maybe you need 255.255.255.248 which would give you 32 subnets. - Wayne Barber - barberw@tidewater.net Internet System Administrator Coastal Telco Services

This is a multi-part message in MIME format. --------------8F905B0DB497254458BD51E0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >> Jason_Kelton@3com.com wrote: > >> The same for the NMC and Quad Modems. for a Quad card to operate, you > >> don't necessarily need a NIC installed. If the NMC NAC is installed first, > > >> before the NIC, it can't initialise a NIC on bootup if one is not > >> installed, it won't activate that interface. > > This is true. I do not have any NICS installed behind my Quad cards. This is > because our users are dialing in over PRI lines, not analog lines that would > normally plug into the NICS. Cheers, Jim Pergolizzi --------------8F905B0DB497254458BD51E0 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Pergolizzi, Jim Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Jim Pergolizzi n: Pergolizzi;Jim org: Autodesk, Inc. adr: 3900 Civic Center Dr.;;;San Rafael;CA;94903;USA email;internet: jim.pergolizzi@autodesk.com title: Network Engineer tel;work: 415-507-8897 tel;fax: 415-507-8395 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------8F905B0DB497254458BD51E0--

At 04:13 PM 3/18/98 -0500, you wrote: >> From: "Jay M Christner" <jaymc@goshen.edu> >> I'm trying to change the netmask setting on my NMC (4.3.9) in a Total >> Control Chassis from 255.255.255.0 to 255.255.248.0 However it gives me an >> "Invalid subnet mask" message when I try to save it to memory. Is there >> anyway to change this, because this is really giving us fits? > >Are you sure this is what you want? According to my handy IP Subnet >Calculator (www.net3group.com) that netmask would only work with a >class A network broken into 8151 subnets. Since goshen.edu's address >starts with 199, you have a class C. Maybe you need 255.255.255.248 >which would give you 32 subnets. > We have 8 consecutive class C subnets, and we were told (quite correctly I believe) that the subnet mask of 255.255.248.0 would eliminate the need to do any IP routing between the subnets. ____________________________________________________________________ Jay Christner Office: UN-019 Technical Services Phone:(219)-535-7640 Residential Computer Technician Goshen College ____________________________________________________________________

Original message from Jay M Christner: > >At 04:13 PM 3/18/98 -0500, you wrote: >>> From: "Jay M Christner" <jaymc@goshen.edu> >>> I'm trying to change the netmask setting on my NMC (4.3.9) in a Total >>> Control Chassis from 255.255.255.0 to 255.255.248.0 However it gives me an >>> "Invalid subnet mask" message when I try to save it to memory. Is there >>> anyway to change this, because this is really giving us fits? >> >>Are you sure this is what you want? According to my handy IP Subnet >>Calculator (www.net3group.com) that netmask would only work with a >>class A network broken into 8151 subnets. Since goshen.edu's address >>starts with 199, you have a class C. Maybe you need 255.255.255.248 >>which would give you 32 subnets. >> >We have 8 consecutive class C subnets, and we were told (quite correctly I >believe) that the subnet mask of 255.255.248.0 would eliminate the need to >do any IP routing between the subnets. Technically, you are _supernetting_, 8 class-C _networks_. I imagine what is happening is the equipment recognizes that the IP is a class C, and will allow you to _subnet_, but not _supernet_. I could be wrong, tho... Jas, Interpath Communications Data Network Technician Jas.Eckard@interpath.net

Thus spake Jas - Net Tech >Original message from Jay M Christner: >>We have 8 consecutive class C subnets, and we were told (quite correctly I >>believe) that the subnet mask of 255.255.248.0 would eliminate the need to >>do any IP routing between the subnets. >Technically, you are _supernetting_, 8 class-C _networks_. I imagine what >is happening is the equipment recognizes that the IP is a class C, and will >allow you to _subnet_, but not _supernet_. I could be wrong, tho... Well, in the world of (technically) classless address, it would be just a 21 (IICIC[1]) bit netmask, and not a supernet or subnet. [1] "I"f "I"'m "C"alculating "I"t "C"orrectly -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 04:48 PM 3/18/98 -0500, you wrote: >Original message from Jay M Christner: >> >>At 04:13 PM 3/18/98 -0500, you wrote: >>>> From: "Jay M Christner" <jaymc@goshen.edu> >>>> I'm trying to change the netmask setting on my NMC (4.3.9) in a Total >>>> Control Chassis from 255.255.255.0 to 255.255.248.0 However it gives me an >>>> "Invalid subnet mask" message when I try to save it to memory. Is there >>>> anyway to change this, because this is really giving us fits? >>> >>>Are you sure this is what you want? According to my handy IP Subnet >>>Calculator (www.net3group.com) that netmask would only work with a >>>class A network broken into 8151 subnets. Since goshen.edu's address >>>starts with 199, you have a class C. Maybe you need 255.255.255.248 >>>which would give you 32 subnets. >>> >>We have 8 consecutive class C subnets, and we were told (quite correctly I >>believe) that the subnet mask of 255.255.248.0 would eliminate the need to >>do any IP routing between the subnets. > >Technically, you are _supernetting_, 8 class-C _networks_. I imagine what >is happening is the equipment recognizes that the IP is a class C, and will >allow you to _subnet_, but not _supernet_. I could be wrong, tho... > > Jas, Interpath Communications Data Network Technician > Jas.Eckard@interpath.net Yes, that's my guess too, but is there anyway around it? ____________________________________________________________________ Jay Christner Office: UN-019 Technical Services Phone:(219)-535-7640 Residential Computer Technician Goshen College ____________________________________________________________________

Hello - We are in the process of setting up a HiperARC. We are able to obtain a PPP session and everything works great. One issue, not really a problem is that the login message comes across the screen as: Welcome To CyberGate Username: What we would like is at least one carraige return after the login prompt. In the regular Netserver, it's done with "set message sxxxx Welcome To CyberGate^^^". The three "^^^" gives 3 carraige returns. I have tried putting <cr>, ^, and ^M after the login message, but the HiperARC won't accept that, and when putting it IN the login message it prints the actual characters. Any suggestions? Thanks =) =========================================================================== S t e v e n R. S h e p h e r d =========================================================================== CyberGate Internet Technologies | ICQ: 1412432 An ACSI Company | NetDudeFL @ EFnet Field Engineer | E-Mail: steven@gate.net (800)NET-GATE/(954)429-8065 | 9542595004@alphapage.airtouch.com ============================================================================

We're getting our first Hiper ARC soon. Is there a cut and dry configuration example telnet script thingy that someone threw together that possible they could post in the group? (with the sensitive stuff changed of-course) I have a big text file for the netserver's which is a big help for setting up those but with the complete OS rewrite, nothing looks the same on the ARC. Thanks, Tom Bilan

Nope, MS IEAK is the MS Internet Explorer Administration Kit, which automates the setup of win95, Nt, win3.11 and Mac for Internet access. There's nothing in there with fixed IP's... I tried tracing the PPP facility, and here's what makes me tick : =20 At 19:29:34, Facility "PPP", Level "COMMON":: [csm_drv_state_change] bundle 14, link 17, state 1=20 At 19:29:34, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1=20 At 19:29:34, Facility "PPP", Level "COMMON":: [psm_chkrej]: type 0x11=20 At 19:29:34, Facility "PPP", Level "COMMON":: [psm_chkrej]: Remote Swacked MRRU=20 At 19:29:34, Facility "PPP", Level "COMMON":: [psm_chkrej]: type 0x13=20 At 19:29:34, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1=20 At 19:29:37, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1=20 At 19:29:37, Facility "PPP", Level "COMMON":: [psm_open(LCP)]: PPP Connection Open=20 At 19:29:37, Facility "PPP", Level "VERBOSE":: [psm_simple_send_frames]: sending frame to L1=20 At 19:29:37, Facility "PPP", Level "COMMON":: PPP - UNKNOWN Compression allocation reqeust to .=20 (USR should check its spelling sometimes ;-)))) At 19:29:37, Facility "PPP", Level "COMMON":: [ppp_load_config]: LOCAL_IP_ADDR 0xc233cbe1=20 At 19:29:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1=20 At 19:29:38, Facility "PPP", Level "COMMON":: [psm_open(CHAP)]: PPP Connection Open=20 At 19:29:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1=20 At 19:29:38, Facility "PPP", Level "VERBOSE":: [psm_send_frames]: sending frame to L1=20 At 19:29:38, Facility "PPP", Level "UNUSUAL":: [psm_open]: No more room, Releasing link (17)!! =20 This line is really weird, at that moment (2 minutes after a reboot) there was just another modem with a 'register' user connected !! At 19:29:38, Facility "PPP", Level "COMMON":: [csm_release_link] bundle 14, link 17, drop_id 42=20 At 19:29:38, Facility "PPP", Level "COMMON":: [csm_release_dialup_link] bundle 14, link 17=20 At 19:29:38, Facility "PPP", Level "UNUSUAL":: PPP connection down to register. At 19:29:38, Facility "PPP", Level "COMMON":: [csm_fwdr_state_change] bundle 14, proto_type -2, state 3 At 19:29:40, Facility "PPP", Level "COMMON":: [csm_drv_state_change] bundle 14, link 17, state 3 At 19:29:40, Facility "PPP", Level "COMMON":: [csm_release_link] bundle 14, link 17, drop_id 87 Here's the definition of register : netserver>sh user register INFORMATION FOR USER: register Status: INACTIVE Type: NETWORK Expiration: 00- -0000 Message: Callback Type: NORMAL Phone Number: Alternate Phone Number: Input Filter: Output Filter: Modem Group: all (D) Session Timeout 0 Idle Timeout: 0 PARAMETERS FOR NETWORK USERS: Network Service PPP Header Compression: TCPIP (D) MTU: 1514 (D) Send Password: Appletalk: DISABLED Appletalk Address Range: 0 - 0 Filter Zones ENABLED (D) IP Usage: ENABLED Address Selection: ASSIGN Remote IP Address: 0.0.0.0/H (D) IP Routing: NONE (D) Default Route Option: DISABLED (D) IP RIP Routing Protocol: RIPV1 (D) IP RIP Routing Policies: IP RIP Authentication Key: IPX Usage: DISABLED IPX Address: 0 IPX Routing: RESPOND (D) IPX WAN Usage: DISABLED (D) Spoofing: ENABLED PARAMETERS for NETWORK PPP USERS Max Channels 2 Channel Decrement Percent: 20 (D) Channel Expansion Percent: 60 (D) Expansion Alg Receive ACC Map: 0 (D) Transmit ACC Map: 0 (D) Compression Algorithm: AUTO (D) Compression Reset Mode: AUTO (D) Min Compression Size: 256 (D) Spoofing Protocols: Connection Reservation: DISABLED Suspend Timer: 0 Reconnect Type: PEER NetBIOS Proxy KeepAlive Timeout: 0 orithm: LINEAR (D) I don't think anything's wrong with my config, should I downgrade to 3.xxx so that it'll work, or is there a workaround to have multiple users called 'register' on at the netserver at the same time ? Thanks for any further info, Robert -----Original Message----- From: Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] Sent: mercredi, 18. f=E9vrier 1998 14:25 To: Robert von Bismarck Cc: 'usr-tc@xmission.com' Subject: Re: (usr-tc) Netserver user definitions On Wed, 18 Mar 1998, Robert von Bismarck wrote: > I have a couple questions about the Netserver 16 >=20 > I want to use a Netserver 16 with 8 ISDN BRI's for my signup users > (using MS IEAK 4) I do not want this machine to access the network. The > setup is done, it works splendidly, but the Netserver doesn't accept > more than one signup connection. I defined the user in the Netserver, as > I do not want to use a Radius server for this (who needs radius for just > one user=A0?=A0?=A0?) > Any pointers to that=A0? I guess when you say MS IEAK - you mean Microsoft Internet Explorer -=20 Check the IP address of the user, if this is a static IP user the you can=20 have only one connection. krish >=20 > I'm using Netserver + with 4.0.14 software on it and Netserver Manager > Plus... >=20 > Thanks, >=20 > Robert von Bismarck > Petrel Communication S.A. >=20 > - > 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. >=20 - 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.

On 18 Feb 1998, Tatai SV Krishnan wrote: > On Wed, 18 Mar 1998, Jeff Mcadams wrote: > > > Thus spake Tatai SV Krishnan > > >On Wed, 18 Mar 1998, Josh Richards <Josh Richards wrote: > > >> Nope - That is correct. The MTU specified in RADIUS is useless for PAP > > >> based PPP logins since PPP has already started before the RADIUS server > > >> even comes into the picture. > > > > >The above statement is correct for Livingston and NETServer - Not for > > >HiPer ARC. > > > > How does the ARC handle this? Restart LCP negotiations? Means a > > slightly longer delay in the PPP startup procedure doesn't it? If the > > ARC's take half as long to auth and start PPP as the netserver do, I'm > > not sure I like adding any more time to it. Not that its a *really* big > > deal, but I do have customers that notice the length of time it takes to > > start passing packets. :/ > > No HiPer ARC does not restart LCP negotiations. What happens is that you > can have a user as login and network on the Hiper ARC - depending upon > how he logs in the Mtu is either utilized or not. So you dialin and open > a terminal and login and then join the network as a network user then the > MTU is taken - if you are doing PPP as soon as you connect then the MTU > from radius is not used. How is that different from how the PortMaster and 3Com NETServer handle it? That sounds like exactly what I and several others already described. --jr ---- Josh Richards - <jrichard@livingston.com> - [Beta Engineer] LUCENT Technologies - Remote Access Business Unit (formerly Livingston Enterprises, Inc.) http://www.livingston.com/

I don't know if anyone has ran into this problem but I'm open for solutions that I'm sure many of you have come up with to solve this scenario. TDI is primarily a local ISP but we have started to grow slowly into other areas. We have recently had a T1 piped back from an area near us but not a local call to us. We need to support users in that area for tech support calls and we have a need to split a channel or two off that T1 so we can have local dial-tone (not having to pay long distance or 800# fees). I've done some preliminary checking but I can't find a straight solution to this problem. 1) Can we somehow get a voice call out through a TC Chassis in any way shape or form? 2) Does anyone know of a MUX/IMUX that will peel off x # of channels for use in an analog application while keeping the 64k channels in tact? Keeping x2 is a must so it needs to remain digital. 3) Any other creative ideas? It just seems rediculous that we have 24 lines going to an area but we can't us any of them to call out on! Also, has anyone been able to fight the 911 charges on your incoming lines? It also seems rediculous to pay 911 charges for lines that never dial out! Any help is greatly appreciated! Thanks, Tom Bilan TDI Internet

Thus spake Josh Richards >On 18 Feb 1998, Tatai SV Krishnan wrote: >> No HiPer ARC does not restart LCP negotiations. What happens is that you >> can have a user as login and network on the Hiper ARC - depending upon >> how he logs in the Mtu is either utilized or not. So you dialin and open >> a terminal and login and then join the network as a network user then the >> MTU is taken - if you are doing PPP as soon as you connect then the MTU >> from radius is not used. >How is that different from how the PortMaster and 3Com NETServer handle >it? That sounds like exactly what I and several others already described. The ability to have a single user in the user table be either a login user or network user (I believe), where previously, you would've had to have two seperate user definitions (though, could have same userid and password, etc.) one login user, and one network user (changing one password wouldn't change the other for example). At least, I *think* this is the distinction...like I said, not too significant in the overall scheme of things from what I can tell. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I have a Dual PRI card that keeps giving busies intermentely. They have been up for about 16 months with out a problem. Last night we had a power faliure and the systems went down. I don't know what happened to the equipment but every thing seems to be fine for abotu 20 minutes then it gives busies for about 10 minutes. On 10 off 10, but the peoples that are connected stay on line. I am at a lost of ideas why this is happening? do I need to reload the code? My net server is running V3.7.24 the Dual PRI is the latest as well. There seems to be nothing wrong with Modems. Does anybody have any help on this topic? Joe Zulanas CEO The Metropolitan Network, Inc. _______________________________________________________________ http://www.met-net.com The Earl Scheib of the Internet. "We'll put any Computer any color on the Internet for only $19.95 / month." _______________________________________________________________

I'm curious about how netbios/wins services work, such that users can click on network neighborhood and see who is logged into the network the chasis is sitting on. Is this data sent around via broadcast messages on the network? Or how else does each dialup user find the server acting as the master wins/samba system on the local network, if thats how it works. My reasoning is to eliminate any unnecessary transmissions on the network that might affect quake play for example. I'm thinking an access filter would do this. Or does the broadcast address serve some other function for dialup users? - lv

On Wed, 18 Mar 1998, Tom Bilan wrote: > I don't know if anyone has ran into this problem but I'm open for > solutions that I'm sure many of you have come up with to solve this > scenario. > > TDI is primarily a local ISP but we have started to grow slowly into > other areas. We have recently had a T1 piped back from an area near us > but not a local call to us. We need to support users in that area for > tech support calls and we have a need to split a channel or two off that > T1 so we can have local dial-tone (not having to pay long distance or > 800# fees). I've done some preliminary checking but I can't find a > straight solution to this problem. Yes, I'm interested in this too. We have a large pop in a remote city (in a different LATA as well), that generates large amounts of 800# support calls. Seeing as we are already paying an IXC for an inter-lata clear-channel loop, it would be nice to take advantage of the bandwidth we DO have for some of our voice traffic. In our case, we are pretty lucky, because a clear-channel t-span actually cost us LESS than an FR circuit, even though it gives us more bw than we actually need. Rather than splitting off channels, I was looking at VoIP (Voice over IP) technologies that might interface directly into a trunk card(s) on our phone system, which has the benefit of not robbing you of precious bandwidth when no voice calls are needed (such as fairly "prime time" hours, 9-11 PM). Unfortunately, I haven't been successful in finding some solution that goes beyond "PC based". T'would be ideal to have some hardware that implements VoIP and outputs as a standard dial-tone analog line. Regards, Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

On 18 Mar 1998, Jeff Mcadams wrote: > Thus spake Josh Richards > >On 18 Feb 1998, Tatai SV Krishnan wrote: > >> No HiPer ARC does not restart LCP negotiations. What happens is that you > >> can have a user as login and network on the Hiper ARC - depending upon > >> how he logs in the Mtu is either utilized or not. So you dialin and open > >> a terminal and login and then join the network as a network user then the > >> MTU is taken - if you are doing PPP as soon as you connect then the MTU > >> from radius is not used. > > >How is that different from how the PortMaster and 3Com NETServer handle > >it? That sounds like exactly what I and several others already described. > > The ability to have a single user in the user table be either a login > user or network user (I believe), where previously, you would've had to > have two seperate user definitions (though, could have same userid and > password, etc.) one login user, and one network user (changing one > password wouldn't change the other for example). At least, I *think* > this is the distinction...like I said, not too significant in the > overall scheme of things from what I can tell. Hmm..regardless this still doesn't change anything. From what was described as the HiPer ARC behavior, if someone does a PAP authentication (i.e. "if you are doing PPP as soon as you connect then the MTU from RADIUS is not used.") it still ignores the MTU setting. It only takes affect if a terminal/scripted login takes place instead. This is exactly what Lucent does and exactly what we both described, although it is being inferred that this is somehow different? Am I missing something? --jr ---- Josh Richards - <jrichard@livingston.com> - [Beta Engineer] LUCENT Technologies - Remote Access Business Unit (formerly Livingston Enterprises, Inc.) http://www.livingston.com/

At 11:34 AM 3/19/98 +0300, you wrote: >Jay , > >Why do you want to change the default subnet mask / how many networks do you >have? 8 consecutive Class C subnets. We are going to a completely routerless campus and using this subnet mask takes care of that. >Jay M Christner wrote: > >> I'm trying to change the netmask setting on my NMC (4.3.9) in a Total >> Control Chassis from 255.255.255.0 to 255.255.248.0 However it gives me an >> "Invalid subnet mask" message when I try to save it to memory. Is there >> anyway to change this, because this is really giving us fits? ____________________________________________________________________ Jay Christner Office: UN-019 Technical Services Phone:(219)-535-7640 Residential Computer Technician Goshen College ____________________________________________________________________

The only way you're going to get that to work is put the NMC's (and a gateway) in the last class C of the supernet so the broadcast address is correct even if it forces you to use a netmask of 255.255.255.0. OR you can try to get 3Com to fix the classfullness of the NMC. -CH On Thu, 19 Mar 1998, Jay M Christner wrote: > At 11:34 AM 3/19/98 +0300, you wrote: > >Jay , > > > >Why do you want to change the default subnet mask / how many networks do you > >have? > > 8 consecutive Class C subnets. We are going to a completely routerless > campus and using this subnet mask takes care of that. > > >Jay M Christner wrote: > > > >> I'm trying to change the netmask setting on my NMC (4.3.9) in a Total > >> Control Chassis from 255.255.255.0 to 255.255.248.0 However it gives me an > >> "Invalid subnet mask" message when I try to save it to memory. Is there > >> anyway to change this, because this is really giving us fits? > > ____________________________________________________________________ > Jay Christner Office: UN-019 > Technical Services Phone:(219)-535-7640 > Residential Computer Technician > Goshen College > ____________________________________________________________________ > > - > 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. >

With ISDN processing off of the munich cards, afaik the only way to determine if a call is ISDN is to check if its speed is 56000 or 64000. At least on the netservers. Will v.90 be capable of 56000? Hopefully there will be a new way to distinguish those calls in the future. - lv

Thus spake Laszlo Vecsey >With ISDN processing off of the munich cards, afaik the only way to determine >if a call is ISDN is to check if its speed is 56000 or 64000. At least on >the netservers. Will v.90 be capable of 56000? Hopefully there will be a new >way to distinguish those calls in the future. Look at the Modulation Type. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jay , Why do you want to change the default subnet mask / how many networks do you have? Jay M Christner wrote: > I'm trying to change the netmask setting on my NMC (4.3.9) in a Total > Control Chassis from 255.255.255.0 to 255.255.248.0 However it gives me an > "Invalid subnet mask" message when I try to save it to memory. Is there > anyway to change this, because this is really giving us fits? > ____________________________________________________________________ > Jay Christner Office: UN-019 > Technical Services Phone:(219)-535-7640 > Residential Computer Technician > Goshen College > ____________________________________________________________________ > > - > 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. -- \\|// - ? (o o) +==================================oOOo=(_)=oOOo========+ | Richard Bosire rbosire@africaonline.co.ke | | AfricaOnline Ltd | | union towers, 2nd floor | | tel: 254-2-243775 | | .oooO | | http://www.africaonline.co.ke ( ) Oooo. | +===================================\ (==( )==========+ \_) ) / (_/

Thus spake Robert von Bismarck >Heh, I thought I was the only one who had this problem... I have exactly >the same problem with a Netserver 16/I + and Radius 1.16 (livingston) >The problem is in USR's hands now, they told me it had been upped to >level 3 tech support, whatever that means. It means you'll proly never hear back from them unless you press the issue. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Laszlo Vecsey was heard to say: >With ISDN processing off of the munich cards, afaik the only way to determine >if a call is ISDN is to check if its speed is 56000 or 64000. At least on >the netservers. Will v.90 be capable of 56000? Hopefully there will be a new >way to distinguish those calls in the future. Nope, look at NAS port type. --Ricky

Laszlo Vecsey was heard to say: >With ISDN processing off of the munich cards, afaik the only way to determine >if a call is ISDN is to check if its speed is 56000 or 64000. At least on >the netservers. Will v.90 be capable of 56000? Hopefully there will be a new >way to distinguish those calls in the future. Nope, look at NAS port type. --Ricky

>>>>> "Laszlo" == Laszlo Vecsey <master@micro.internexus.net> writes: Laszlo> With ISDN processing off of the munich cards, afaik the Laszlo> only way to determine if a call is ISDN is to check if its Laszlo> speed is 56000 or 64000. At least on the netservers. Will Laszlo> v.90 be capable of 56000? Hopefully there will be a new Laszlo> way to distinguish those calls in the future. Can't you check the modulation? ISDN calls tend to show up as v.120 or AsyncSyncPPP. Rick -- Rick Payne, Senior Network Admin | Taxation is about extracting the NETCOM Internet Ltd. | maximum amount of milk with the rickp@corp.netcom.net.uk | minimum of moo.

Since it appears that USR/3com's remote access QA team is asleep at the wheel, I thought I would put up some helpful checkpoints for future releases. This may just be spitting in the wind, but I spent most of last night trying to get a setting to "stick" into the HDM's NVRAM and finally gave up. Yet another bug. 1. Test equipment with *ALL* other vendors connection equipment. Chances are, if it is sold, then your customers will have to deal with it as well. Compatibility issues are absolutely inexcusable for a company catering to remote access and ISPs. 2. Go overboard on documentation. I've found TCM's "help" to be sparse and usually useless. It would be nice to not only know the settings, but what the settings do and mean. What does the "refresh template channels" function do? Why aren't all the card settings in the templates? What is the difference between individual modem NVRAM and card-modem NVRAM? Why are modem defaults for TCM different from modem defaults for the card different from modem AT defaults for the console? Is there nobody out there that believes these types of situations aren't the most aggravating thing you've seen? 3. Test a raft of common card configurations and see if they successfully "stick" to the card after all forms of reset abuse. I've found this problem with two separate settings on the HDM card with two different code releases. Example, on ER 1.0.93 set the CRITICAL "ISDN Async-Sync" setting to "enable", save to modem NVRAM, save to card modem NVRAM. Hardware reset and SHAZAM! Its back to "disable". 4. Test the RADIUS client code against as many RADIUS servers you can find. Try to be compliant to the most common form. 5. Test *ALL* the RADIUS settings. Assuming they work hasn't worked in the past. 6. Try to establish the most common configurations of your client base. Survey them frequently. Test all code releases against these configurations. I am praying to all the modem gods that 4.1 of the HiPer software will not only come soon, but will be successful in most if not all of the above terms. If I feel that I've been recruited as an unwilling beta tester AGAIN, I'm going to be pissed beyond belief. On a positive note, THANK YOU for releasing the USR RADIUS source.

Our TOTALcontrol product will do what you're requesting. Phase 3 of the VoIP implementation for Edgeserver PRO includes the ability to autodetect between voice, data and fax calls, allowing you your IP point of presence, aswell as a VoIP solution. You should speak to your local 3Com sales office to obtain more information, but I'm surprised this is an approach that hasn't been looked at.... Regards, Jason. sysadmin@evcom.net on 19/03/98 15:03:21 Please respond to usr-tc@lists.xmission.com cc: (bcc: Jason Kelton/AU/3Com) On Wed, 18 Mar 1998, Tom Bilan wrote: > I don't know if anyone has ran into this problem but I'm open for > solutions that I'm sure many of you have come up with to solve this > scenario. > > TDI is primarily a local ISP but we have started to grow slowly into > other areas. We have recently had a T1 piped back from an area near us > but not a local call to us. We need to support users in that area for > tech support calls and we have a need to split a channel or two off that > T1 so we can have local dial-tone (not having to pay long distance or > 800# fees). I've done some preliminary checking but I can't find a > straight solution to this problem. Yes, I'm interested in this too. We have a large pop in a remote city (in a different LATA as well), that generates large amounts of 800# support calls. Seeing as we are already paying an IXC for an inter-lata clear-channel loop, it would be nice to take advantage of the bandwidth we DO have for some of our voice traffic. In our case, we are pretty lucky, because a clear-channel t-span actually cost us LESS than an FR circuit, even though it gives us more bw than we actually need. Rather than splitting off channels, I was looking at VoIP (Voice over IP) technologies that might interface directly into a trunk card(s) on our phone system, which has the benefit of not robbing you of precious bandwidth when no voice calls are needed (such as fairly "prime time" hours, 9-11 PM). Unfortunately, I haven't been successful in finding some solution that goes beyond "PC based". T'would be ideal to have some hardware that implements VoIP and outputs as a standard dial-tone analog line. Regards, Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key * - 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.

Ken Hunter, Aspiring Technologies said once upon a time: > Are you saying that their radius source is available? > >>On a positive note, THANK YOU for releasing the USR RADIUS source. Login to totalservice.usr.com then go to the "Total Control Hubs" under the "Latest Code" section. There is a link for "Security and Accounting RADIUS Server Source Code Application" in the top frame. You need to fill out a form, then fax in a PDF with your signature.

At 04:13 PM 3/19/98 +1000, Jason_Kelton@3com.com wrote: >Our TOTALcontrol product will do what you're requesting. Phase 3 of the >VoIP implementation for Edgeserver PRO includes the ability to autodetect >between voice, data and fax calls, allowing you your IP point of presence, >aswell as a VoIP solution. > >You should speak to your local 3Com sales office to obtain more >information, but I'm surprised this is an approach that hasn't been looked >at.... > >Regards, > >Jason. Let me ask you a little bit more about VoIP implementataion. Does it do exactly the same thing as Vocaltec Telephony Gateway, with all the same capabilities? Garry Shtern shterng@akula.com Chief Network Administrator http://www.akula.com Akula Communications Corp. tel. (212) 292-8892

Thus spake Jason_Kelton@3com.com >Our TOTALcontrol product will do what you're requesting. Phase 3 of the >VoIP implementation for Edgeserver PRO includes the ability to autodetect >between voice, data and fax calls, allowing you your IP point of presence, >aswell as a VoIP solution. When will the hyperarc's be supporting VOIP? I say "when" as opposed to "if and when" because I truly believe that 3Com would be making a collosal (sp?) mistake to not support this on the Arc. There are supposedly two extra PPC chips sitting there unused at this point, I'd think that now would be a good time to put one of them to use. We are quite eager to be able to do some VOIP stuff, but there is absolutely no way on earth that we're going to be running edgeservers to do it. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I'm having some problem with TC and Netserver16 when I configure Radius to give a Login-Service as TELNET. After a user logon on Netserver, he is transfered to the telnet machine prompt. Then After he puts his login name he gets a "^@" before the passwoord prompt and before any line, as shown: username: abacate ^@password: xxxxxxx ^@machine> ^@machine> Does any one know how to handle with this? ps: On Livingston portmasters it doesn't happen. []s Marcelo Souza

Vienna systems (http://www.viennasys.com/) has Solaris x86 software for a VoIP gateway. If they could write drivers for the Edgeserver Pro/HiPer DSP hardware platform, it would be a great solution. NT is bane around here, too. So if we do IP Telephony it probably won't be on an NT platform unless there is a huge price advantage. And if there's not a Unix flavor for Edgeserver, we'll probably deploy non-3Com hardware for that purpose. 3Com is not alone. . . we eliminated Vocaltec because of their commitment to NT. *sigh* -CH On Thu, 19 Mar 1998, Rick Payne wrote: > >>>>> "Jeff" == Jeff Mcadams <jeffm@iglou.com> writes: > > > Jeff> We are quite eager to be able to do some VOIP stuff, but > Jeff> there is absolutely no way on earth that we're going to be > Jeff> running edgeservers to do it. > > I agree with your sentiments on Edgeservers. We recently had the > presentations about VoIP from the UK marketing people who in response > to my refusal to run NT stated that "95% of all VOIP developement is > on NT". My response that less than 5% of ISP's used NT for their > servers fell on deaf ears. > > Seems marketing people (3Com) just listen to marketing people > (Microsoft), and not to what the customer wants *sigh*. > > Rick (who asked for OSPF in July '96 and was promised it for Summer > '97 *rofl*) > -- > Rick Payne, Senior Network Admin | Taxation is about extracting the > NETCOM Internet Ltd. | maximum amount of milk with the > rickp@corp.netcom.net.uk | minimum of moo. > > - > 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. >

Heh, I thought I was the only one who had this problem... I have exactly the same problem with a Netserver 16/I + and Radius 1.16 (livingston) The problem is in USR's hands now, they told me it had been upped to level 3 tech support, whatever that means. If you find out, let me please know, I need this box up and running ASAP. Robert Tony, Do you have re-chap timeout set on your Netserver 8I? --Tom Tony Loosle wrote: > I forgot to mention this as well: > > If I add a user into the local database of the 8Iplus, it does not hang up > on him. > > Mike wrote: > > > At 06:14 PM 3/16/98 -0700, you wrote: > > >I have a netserver 8I that hangs up on each modem, or user every 60 > > minutes. A > > >user can log in and do what ever, but in 60 minutes, it hangs up. I've > > looked at > > >the > > >config and can't find any timeouts. > > > > > >Has anyone had this problem, or know of a solution? > > > > 1) If your using RADIUS is there an Idle-Timout attribute sent to your > > users with a 60 minute time out? > > 2) Check the DEFAULT user. If an idle timeout is defined for the default > > user then it will apply to ALL of your > > callers unless overwritten by RADIUS. > > > > -m > > > > - > > 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. > > - > 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. - 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.

I don't agree with you. I do use Unix here but just for innd which I can't find a suitable replacement for on NT. I came from a solaris and *nix background and over 3 years we've switched 5 systems from Unix to NT for various reasons. One major reason was that we had more commercial solutions on NT and I didn't need someone with 10 years experience to run NT to do basic administration tasks. Don't just put the blinders on for Unix. Just like everything in this business, if you buy the right equipment then you have less problems. I have Compaq Proliant servers and haven't had an NT crash on any of them in 2 years and I did everything I could in Unix and more. Tom > -----Original Message----- > From: Rick Payne [SMTP:rickp@corp.netcom.net.uk] > Sent: Thursday, March 19, 1998 5:18 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Splitting off a few channels for voice > > >>>>> "Jeff" == Jeff Mcadams <jeffm@iglou.com> writes: > > > Jeff> We are quite eager to be able to do some VOIP stuff, but > Jeff> there is absolutely no way on earth that we're going to be > Jeff> running edgeservers to do it. > > I agree with your sentiments on Edgeservers. We recently had the > presentations about VoIP from the UK marketing people who in response > to my refusal to run NT stated that "95% of all VOIP developement is > on NT". My response that less than 5% of ISP's used NT for their > servers fell on deaf ears. > > Seems marketing people (3Com) just listen to marketing people > (Microsoft), and not to what the customer wants *sigh*. > > Rick (who asked for OSPF in July '96 and was promised it for Summer > '97 *rofl*) > -- > Rick Payne, Senior Network Admin | Taxation is about extracting > the > NETCOM Internet Ltd. | maximum amount of milk with the > rickp@corp.netcom.net.uk | minimum of moo. > > - > 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.

Pete Ashdown was heard to say: >Ken Hunter, Aspiring Technologies said once upon a time: >> Are you saying that their radius source is available? >> >>>On a positive note, THANK YOU for releasing the USR RADIUS source. > >Login to totalservice.usr.com then go to the "Total Control Hubs" under the >"Latest Code" section. There is a link for "Security and Accounting RADIUS >Server Source Code Application" in the top frame. You need to fill out a >form, then fax in a PDF with your signature. If I read the form correctly, that is a release for SA version 4.3. If they are providing the same thing I got back in Aug., then I would suggest people not waste their time. The code does not pull out of the USR development tree well and does have a few notable bugs. Additionally, v4 is a deadend source. On the other hand, if USR is releasing v5 source, why have they given me such a hard time about getting it to make it do what I have v4 doing? I've already got the system working 100x faster than USR has tested it. (And, yes, USR does have my source tree.) --Ricky

I don't want to talk to the cannon fodder at the local sales office. Give me a phone number of someone who can talk at my level and who is using the technology now. Please. Tom Bilan tom@tdi.net 313.457.3377 > -----Original Message----- > From: Jason_Kelton@3com.com [SMTP:Jason_Kelton@3com.com] > Sent: Thursday, March 19, 1998 1:13 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Splitting off a few channels for voice > > Our TOTALcontrol product will do what you're requesting. Phase 3 of > the > VoIP implementation for Edgeserver PRO includes the ability to > autodetect > between voice, data and fax calls, allowing you your IP point of > presence, > aswell as a VoIP solution. > > You should speak to your local 3Com sales office to obtain more > information, but I'm surprised this is an approach that hasn't been > looked > at.... > > Regards, > > Jason. > > > > > sysadmin@evcom.net on 19/03/98 15:03:21 > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (bcc: Jason Kelton/AU/3Com) > Subject: Re: (usr-tc) Splitting off a few channels for voice > > > > > > > On Wed, 18 Mar 1998, Tom Bilan wrote: > > I don't know if anyone has ran into this problem but I'm open for > > solutions that I'm sure many of you have come up with to solve this > > scenario. > > > > TDI is primarily a local ISP but we have started to grow slowly into > > other areas. We have recently had a T1 piped back from an area near > us > > but not a local call to us. We need to support users in that area > for > > tech support calls and we have a need to split a channel or two off > that > > T1 so we can have local dial-tone (not having to pay long distance > or > > 800# fees). I've done some preliminary checking but I can't find a > > straight solution to this problem. > Yes, I'm interested in this too. We have a large pop in a remote city > (in > a different LATA as well), that generates large amounts of 800# > support > calls. Seeing as we are already paying an IXC for an inter-lata > clear-channel loop, it would be nice to take advantage of the > bandwidth we > DO have for some of our voice traffic. In our case, we are pretty > lucky, > because a clear-channel t-span actually cost us LESS than an FR > circuit, > even though it gives us more bw than we actually need. Rather than > splitting off channels, I was looking at VoIP (Voice over IP) > technologies > that might interface directly into a trunk card(s) on our phone > system, > which has the benefit of not robbing you of precious bandwidth when no > voice calls are needed (such as fairly "prime time" hours, 9-11 PM). > Unfortunately, I haven't been successful in finding some solution that > goes beyond "PC based". T'would be ideal to have some hardware that > implements VoIP and outputs as a standard dial-tone analog line. > Regards, > Jesse Sipprell > Senior Systems Engineer > Evolution Communications, Inc. > * Finger sysadmin@evcom.net for my PGP Public Key * > - > 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. > > - > 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.

Thus spake Tom Bilan >I don't agree with you. I do use Unix here but just for innd which I >can't find >a suitable replacement for on NT. >I came from a solaris and *nix background and over 3 years we've >switched >5 systems from Unix to NT for various reasons. One major reason was >that >we had more commercial solutions on NT and I didn't need someone with >10 years experience to run NT to do basic administration tasks. >Don't just put the blinders on for Unix. Just like everything in this >business, >if you buy the right equipment then you have less problems. I have >Compaq >Proliant servers and haven't had an NT crash on any of them in 2 years >and >I did everything I could in Unix and more. Well...while I agree to some degree with you (use the OS that does what you need it to do), I don't agree that you should have to get the high-end fancy-shmancy hardware to reliably support an OS. I can throw Linux (and most likely just about any of the x86 BSD's) on just about any ol' PC hardware, and it runs like a top. I consider that a flaw in NT's robustness. There are other reasons that I won't touch NT (we do have one or two NT boxen around here, but nothing mission critical), but this one really touches on your point above. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

This shouldn't be a OS war issue. I have both NT and UNIX systems. From a pure networking standpoint based on resource utilization I would agree that UNIX is more efficient on smaller hardware platforms. From a business standpoint NT has a lot of benefits and a much larger array of software that will run on it. All in all both operating systems have there place. Blindly discounting NT due to some zealot like attachment to anything thats not Microsoft is silly. A lot of people devote a lot of time to trying to find some other solution other than NT and Intel. I'm not opposed to NT doing VoIP (although it doesn't belong on an edgeserver). I'm opposed to a solution that doesn't work, takes to much time to manage, costs to much or has to be developed in house because of a choice of OS. In short I'm in business to make money not rant and rave on OS choices. 3Com just give us a solution that works with an independent gateway and then the OS issue is a mute point. William Behrens Director of Network Operations ParaCom Technologies Inc. > Thus spake Jason_Kelton@3com.com > >Hmm... thats a fair argument. If the ARC were to implement a VoIP > >solution, you would still need a H.323 Gatekeeper and some type of > >directory server like LDAP. > > To be honest, I'm not particularly familiar with VOIP yet, so some of > this sailed over my head at this point. > > >These would need to operate on potentially > >thrid party equipment, which doesn't really make VoIP anything special for > >any one vendor (apart from other issues like codecs etc). A completely <blah, blah, blab, rant and rave. so on and so forth> > penetration into the ISP market. Yes, there are quite a few ISP's that > are using NT, but by and large (not all though) they are *very* small > and account for an extremely small part of Internet and Carrier access > as a whole. > > Listen to your market 3Com, we've had 4 people respond on this thread > (within hours), and 3 of us refuse to use NT for this. > -- > Jeff McAdams Email: jeffm@iglou.com > Chief Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456

Thus spake Jason_Kelton@3com.com >Hmm... thats a fair argument. If the ARC were to implement a VoIP >solution, you would still need a H.323 Gatekeeper and some type of >directory server like LDAP. To be honest, I'm not particularly familiar with VOIP yet, so some of this sailed over my head at this point. >These would need to operate on potentially >thrid party equipment, which doesn't really make VoIP anything special for >any one vendor (apart from other issues like codecs etc). A completely >integrated solution on the Edgeserver platform is the way to go. I'm sorry you feel this way, perhaps I need to start planning our migration to AS5[238]00's now then. >This >allows 3Com to tailor your requirements into OUR solution, and also allow >you additional development through higher level API's. Well, as we've seen with so many things in the past, *MOST OF US WANT AN OPEN SOLUTION SO WE DON'T HAVE TO RELY ON CRAP QA FROM 3COM*. Sorry, but I really get tired of vendors assuming that the customers are all in favor of everything they do. Have you gone back to look at all of the rants in the archives of this list about USR/3Com tech support, QA on their software releases, and other issues? If you haven't, I would urge you to do so. Please keep in mind as I say this and vent some that this doesn't only affect 3Com, although you all do seem to be the worst offenders in my experience. >I also believe >issues like OSPF, L2TP etc are more important in the ARC for the time being >- especially considering the fact that the ARC is an Access router, which >provides one part of the Carrier/ISP market, whilst Edgeserver is >corporate/enterprise based and hence, the reason for Windows NT. There >would be some obvious interest here from the carrier, but I would doubt any >concerns by them with using NT. Whoa...whose saying that VOIP is only of interest to carriers and corporate? We've heard from 4 people here (including myself) that are *extremely* interested in VOIP as ISP's (I believe we were all ISP's anyway). >The reason why VoIP is predominantly being seen on NT I would assume, to be >because of Marketing for one reason, but primarily because most of the >API's developed for VoIP at the moment are being developed for NT. H.323 >is quite a broad umbrella standard, and for any company to develop a >complete solution from the ground up, would take hundreds of engineers to >get VoIP solutions to market as quickly as they are able to today. The >problem here, is if we developed a BSDI solution, and it took another year, >then everyone would be wondering why we hadn't developed a solution by now! Well...let me refine the point that I originally made though. I didn't say that I didn't want to run NT, I said that I didn't want to run *Edgeservers*. I don't care what OS they run, I don't want to have to use them to get VOIP. Now, if they're running NT, I'm absolutely not going to use them, but even running BSDI I'm not really interested. >(typical catch 22). One major reason for deploying a H.323 API for NT is >so companies like Microsoft can develop client-based solutions. Oh, now *there's* a winning argument, we want to do it this way so M$ can come in and totally screw everyone over in this market too! Thanks a ton 3Com. >I believe we are about 6months ahead of our nearest competitor on VoIP >solutions for the moment, which does provide a major marketing advantage to >us... If we're not the leader, then someone else always will..... And why, pray tell, is being a leader so gosh dern important? Who is leading in gigabit ethernet? Certainly not Cisco, but they're still kicking everyone's butt up and down the street in the router market, and making inroads (without NT based VOIP solutions, I understand they're implementing it in IOS) in the access arena too. >I don't know about you guys, but Microsoft seems to be taking Market Share >from everywhere these days, on a daily basis. Oh, another winning argument there. >In Australia, just about >every new ISP, or Corporate setup is using an NT solution of some sort, and >can therefore support our VoIP solution. I do understand the advantages >for using Unix platforms, but most ISP's and carriers these days, will have >some type of interoperable NT solution in their network (whether they like >it or not!). Great, "ISP's have already been forced to use NT somewhat, so lets screw them even more and force them to use NT for other functions too." What was the web page for the AS5300's again? >Now I don't know who's using our solutions at the moment, but my guess is >that the Carrier is scared of the ISP due to the threat of lost revenue. >With this in mind, my guess is the Carriers are already 5 steps ahead of >the ISP. So at the end of the day, if you want VoIP, then you'll have to >take a risk and go for a solution quickly, cause chances are, the Carrier >is going to try and keep you out of their heritage money-making market. How? Noone has any VOIP applications that actually really work at this point because they're all based on a crap OS that doesn't scale to what the Carrier, Enterprise, or even a decent sized ISP needs! The simple fact is that, there is an extremely small NT market penetration into the ISP market. Yes, there are quite a few ISP's that are using NT, but by and large (not all though) they are *very* small and account for an extremely small part of Internet and Carrier access as a whole. Listen to your market 3Com, we've had 4 people respond on this thread (within hours), and 3 of us refuse to use NT for this. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I love Linux, I was using it when it was version .99pl13. I had a 386/16 with 10MB of ram and 2 200MB hard drives and I was the talk of the CIS department. I still use it now but after YEARS of deliberation I moved into NT. I won't say I wasn't pushed because our billing system, Emerald, completely redifined how we ran our ISP and it is native to MS SQL Server. I love Unix. No doubt about it. I'd have a Unix machine in some flavor here whether I need it for operations or not. It's just too convenient. All I'm saying is that NT isn't a joke, it's a good OS. I don't believe it's technologically superior but you have Bill Gate$ and 10,000 of his fanatical tech support people waiting for me to call and give them $195 to fix WHATEVER problem I have with their OS. I once had an exchange server problem that I couldn't solve (and NO I don't use Exchange server for ISP mail, that would be suicide) and I whipped out the CC and spent the $195. It took a total of 2 weeks for them to get my problem fixed but I spent every minute on an 800 # and I ended up talking to the end-all be-all of Exchange server techs who frightened me with his depth of knowledge about the product. They lost $1000 easily in time and labor but they took every one of my phone calls and was willing to sit on the phone for 3 hours at a stretch and do anything it took to try to make it work. I pay $1600 per box for tech support for the USR people and if it wasn't for this list and Krish answering questions I'd never get anything solved. My .02. Tom > -----Original Message----- > From: Jeff Mcadams [SMTP:jeffm@iglou.com] > Sent: Thursday, March 19, 1998 8:27 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Splitting off a few channels for voice > > Thus spake Tom Bilan > >I don't agree with you. I do use Unix here but just for innd which I > >can't find > >a suitable replacement for on NT. > > >I came from a solaris and *nix background and over 3 years we've > >switched > >5 systems from Unix to NT for various reasons. One major reason was > >that > >we had more commercial solutions on NT and I didn't need someone with > > >10 years experience to run NT to do basic administration tasks. > > >Don't just put the blinders on for Unix. Just like everything in > this > >business, > >if you buy the right equipment then you have less problems. I have > >Compaq > >Proliant servers and haven't had an NT crash on any of them in 2 > years > >and > >I did everything I could in Unix and more. > > Well...while I agree to some degree with you (use the OS that does > what > you need it to do), I don't agree that you should have to get the > high-end fancy-shmancy hardware to reliably support an OS. I can > throw > Linux (and most likely just about any of the x86 BSD's) on just about > any ol' PC hardware, and it runs like a top. I consider that a flaw > in > NT's robustness. There are other reasons that I won't touch NT (we do > have one or two NT boxen around here, but nothing mission critical), > but > this one really touches on your point above. > -- > Jeff McAdams Email: jeffm@iglou.com > Chief 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.

(<RANT>) Jeff Mcadams was heard to say: >Well, as we've seen with so many things in the past, *MOST OF US WANT AN >OPEN SOLUTION SO WE DON'T HAVE TO RELY ON CRAP QA FROM 3COM*. What, you're not used to it by now? I've personally been working with USR/3Com server modem hardware for a year now, and nothing -- absolutely nothing -- has worked right and done what it was supposed to do without modification and refinement on my part. I may be a little bit on the picky side, but we (and most of the other here) have a substantial ammount of capitol invested in this hardware to not have things work without having to fiddle with it. >Great, "ISP's have already been forced to use NT somewhat, so lets screw >them even more and force them to use NT for other functions too." What >was the web page for the AS5300's again? Just my opinion, but NT is not a viable option for unmanned servers. How many NT disks from MicroSoft install a telnet server? The only way to manage an NT box is from the console or via 3rd party software that gives you remote access to the consol. I've never seen an NT box without a video card, while I have several PC's (linux) running perfectly for years without a video card. >The simple fact is that, there is an extremely small NT market >penetration into the ISP market. Yes, there are quite a few ISP's that >are using NT, but by and large (not all though) they are *very* small >and account for an extremely small part of Internet and Carrier access >as a whole. I would have to say, NT is being forced onto ISP's to support what the customers want/need. I know of no ISP (sane ISP that is) that is not a UNIX shop at the core. >Listen to your market 3Com, we've had 4 people respond on this thread >(within hours), and 3 of us refuse to use NT for this. If you really want to make your customers happy (read: me), stop keeping so much information closed. We (Interpath) used to use netblazers as dialup terminal servers/routers. The stability and functionality of the netblazer far, far, exceeds anything I've ever seen out of USR/3Com. They do in 4M of RAM loaded from a 1.44M floppy (mostly empty I might add) what the Netserver has trouble doing with 16M. The interface is much better documented and does not provide mis-information. Have you guys ever used Cisco IOS? Basically, give me an edgeserver and the TDM interface specs, and I'll have linux running on there in a few days. With enough knowledge, I could do the same for a NetServer or ARC. I'm not in the market of making hardware, but I'll spew C code for just about thing... How long has USR been working on OSPF? BSDI for the EdgeServer? (</RANT>) --Ricky

>>>>> "Jeff" == Jeff Mcadams <jeffm@iglou.com> writes: Jeff> We are quite eager to be able to do some VOIP stuff, but Jeff> there is absolutely no way on earth that we're going to be Jeff> running edgeservers to do it. I agree with your sentiments on Edgeservers. We recently had the presentations about VoIP from the UK marketing people who in response to my refusal to run NT stated that "95% of all VOIP developement is on NT". My response that less than 5% of ISP's used NT for their servers fell on deaf ears. Seems marketing people (3Com) just listen to marketing people (Microsoft), and not to what the customer wants *sigh*. Rick (who asked for OSPF in July '96 and was promised it for Summer '97 *rofl*) -- Rick Payne, Senior Network Admin | Taxation is about extracting the NETCOM Internet Ltd. | maximum amount of milk with the rickp@corp.netcom.net.uk | minimum of moo.

Tom Bilan was heard to say: >I pay $1600 per box for tech support for the USR people and >if it wasn't for this list and Krish answering questions I'd >never get anything solved. No, that money is for software maint. :-) --Ricky

On Fri, 20 Mar 1998 Jason_Kelton@3com.com wrote: > The reason why VoIP is predominantly being seen on NT I would assume, to be > because of Marketing for one reason, but primarily because most of the > API's developed for VoIP at the moment are being developed for NT. H.323 > is quite a broad umbrella standard, and for any company to develop a > complete solution from the ground up, would take hundreds of engineers to > get VoIP solutions to market as quickly as they are able to today. The > problem here, is if we developed a BSDI solution, and it took another year, > then everyone would be wondering why we hadn't developed a solution by now! > (typical catch 22). One major reason for deploying a H.323 API for NT is > so companies like Microsoft can develop client-based solutions. This then > allows PC-PC communications over H.323 almost immediate, once client > software is avaialble (NetMeeting). As a result, most MFR's are > capitalising on these API's (enhanced) to develop Head-End solutions, > bringing a VoIP solution to market within an acceptable time-frame; mainly > due to the fierce cometition in the marketplace toay. > > I believe we are about 6months ahead of our nearest competitor on VoIP > solutions for the moment, which does provide a major marketing advantage to > us... If we're not the leader, then someone else always will..... > > I don't know about you guys, but Microsoft seems to be taking Market Share > from everywhere these days, on a daily basis. In Australia, just about > every new ISP, or Corporate setup is using an NT solution of some sort, and > can therefore support our VoIP solution. I do understand the advantages > for using Unix platforms, but most ISP's and carriers these days, will have > some type of interoperable NT solution in their network (whether they like > it or not!). > > Now I don't know who's using our solutions at the moment, but my guess is > that the Carrier is scared of the ISP due to the threat of lost revenue. > With this in mind, my guess is the Carriers are already 5 steps ahead of > the ISP. So at the end of the day, if you want VoIP, then you'll have to > take a risk and go for a solution quickly, cause chances are, the Carrier > is going to try and keep you out of their heritage money-making market. There are numerous flaws in your logic. First off, the entire approach you take to this subject is "market based" instead of "technology based." You (and probably many others at 3com) are taking a *short-term* view of the current market situation and attempting to capitalize on it. Time has shown us, again and again, that short-term views are USELESS, if you want have continued growth and success over a long period of time. When developing and deploying a new technology, one should focus on the _functionality_, _performance_ and _robustness_ of a product rather than on what is currently "hot" at the marketplace. If these two happen to mesh well, then you have a very happy market indeed. However, eventually they will and DO mesh, because when it comes to long-term solutions, what *works* best is eventually what *sells* best; it's just not always an immediate return. This so called "western" mindset of quick return and no longetivity is a severely flawed paradigm, and will become exceedingly obsolete in the next decade. You'll notice the impact this sort of thinking had on US automobile manufacturers in the late 70s and 80s; until they decided to wake up and realize that they had to actually produce a _quality_ product. Don't get bit by this -- because, it will hurt; badly. Microsoft is currently a monopoly (well, it's not REALLY a monopoly; more like a "psuedo-monolopy") which represents EXACTLY this sort of thinking. Their entire objective is to sell products based on their ability to market them (which is, IMO, the very best thing they do) and penetrate _heavily_, rather than selling products based on what _really_ matters, which is true performance (meaning performance in the "big" picture here, which consists of many, many components). I'm speaking more on the server/mission critical side here than other consumer level products. I know of absolutely NO companies with a reasonably high clue level (which directly translates into technical superiority, BTW) which would EVER use NT for mission critical purposes; it's that simple. This includes organizations from small ISPs to large Fortune 1000 companies. Sure, everyone has NT servers to play with (and/or support market-forced applications), but nobody really actually uses such in the _important_ places (not for long, anyway). To do so is either (a) suicide or (b) exceedingly expensive -> see a. No matter HOW good Microsoft's marketing abilities are, they will never be able to convince people who _really_ know what they are doing that their server-end products are usable; we aren't blind and we can analyze and decide for ourselves. If you decide to attempt to "leverage" the marketing muscle of Microsoft, you WILL probably experience short-term success, however in the long term you will NOT be successful because eventually, other products will be available which will significantly out-perform (in all aspects of the word) solutions based on NT. Especially with products which deal with voice, which is probably THE most mission-critical aspect of any operation, the big "performance word" takes on even larger proportions. I'm not sure how familiar you are with phone switches, but I can tell you from experience that a switch crashing or otherwise causing denial-of-service is generally cause for wide-spread panic and/or someone's head on a platter. To be honest, I would not be comfortable with any VoIP solution that uses "PCish" hardware and/or "PCish" operating systems (NT, Unix or otherwise). If you REALLY want to make inroads with carriers and/or ISPs, you need to look at developing custom hardware/software applications that are engineered from the *ground-up* to be _very_ robust and _completely_ (or as close to completely as humanly possible) stable; just like a phone switch. I also agree that Cisco is in a unique position to deploy VoIP solutions that are high quality and _useable_. Cisco, like Microsoft, is also a "psuedo-monopoly". The difference, and boy is it a difference, is that Cisco's monopoly is based on superior _products_ rather than superior _marketing_. You'll notice that few complain about Cisco's strangle hold on their market niche, because consumers genuinely don't mind a monopoly if the monopoly provides them with *good*, *reliable* products that meet their needs. I fear that Cisco may have a bit of work ahead of them in order to integrate smoothly into existing voice products (key systems, switches, etc), but it's not out of the question. Regards, Jesse Sipprell Senior Systems Engineer Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

Actually you need to integrate RadiusNT with Emerald. RadiusNT sends the accounting packets via ODBC to the ServerPorts table. If you enable variable login limits and concurrency control in RadiusNT administrator, RadiusNT will then check the ServerPorts table to see who is currently on and then either allow or not allow them depending on the number of allowable ports that user is set for in Emerald. It's pretty slick but you need Emerald to work it correctly. Tom > -----Original Message----- > From: Peter D. Mayer [SMTP:dmayer@netwalk.com] > Sent: Tuesday, March 10, 1998 10:43 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) radius nt hack > > You don't need a hack of it. RadiusNT (at least version 2.2) has > concurrency checking built in. It works pretty well too. > > Peter D. Mayer > NetWalk Tech Support > dmayer@netwalk.com > > > -----Original Message----- > From: Ken Hunter, Aspiring Technologies <ken@aspire.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Tuesday, March 10, 1998 8:22 AM > Subject: (usr-tc) radius nt hack > > > Is there a hack of radius nt where the tracking of concurrent logins > is > enabled? > > ken :) > > - > ********************************************************************** > ** > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. > > Ken Hunter Aspiring Technologies > mailto:ken@aspire.net 9304 Troy Drive > http://www.aspire.net Nokesville, Va 20181 > ********************************************************************** > ** > > > > > - > 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.

Great, now I find out... :^) Tom > -----Original Message----- > From: Ricky Beam [SMTP:jfbeam@Interpath.net] > Sent: Thursday, March 19, 1998 10:21 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Splitting off a few channels for voice > > Tom Bilan was heard to say: > >I pay $1600 per box for tech support for the USR people and > >if it wasn't for this list and Krish answering questions I'd > >never get anything solved. > > No, that money is for software maint. :-) > > --Ricky > > - > 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.

I am having the same problem, but I am not using Radius. Bob Roswell broswell@syssrc.com System Source 338 Clubhouse Road Hunt Valley, MD 21031 (410) 771-5544 ext 336 >>> Mike <mwronski@coredump.ae.usr.com> 03/18 10:31 AM >>> At 06:14 PM 3/16/98 -0700, you wrote: >I have a netserver 8I that hangs up on each modem, or user every 60 minutes. A >user can log in and do what ever, but in 60 minutes, it hangs up. I've looked at >the >config and can't find any timeouts. > >Has anyone had this problem, or know of a solution? 1) If your using RADIUS is there an Idle-Timout attribute sent to your users with a 60 minute time out? 2) Check the DEFAULT user. If an idle timeout is defined for the default user then it will apply to ALL of your callers unless overwritten by RADIUS. -m - 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.

This is not true. RadiusNT is full featured even when run as a standalone product. It does not need Emerald to do concurrency checking. All you need is any ODBC database with the correct tables and fields, and it works great. It may be slightly harder to manage without Emerald (I've never used Emerald personally), but it works fine without it. Peter D. Mayer NetWalk Tech Support dmayer@netwalk.com -----Original Message----- >Actually you need to integrate RadiusNT with Emerald. RadiusNT sends >the accounting packets via ODBC to the ServerPorts table. If you enable >variable login limits and concurrency control in RadiusNT administrator, >RadiusNT will then check the ServerPorts table to see who is currently >on and then either allow or not allow them depending on the number of >allowable ports that user is set for in Emerald. > >It's pretty slick but you need Emerald to work it correctly. > >Tom > >> -----Original Message----- >> From: Peter D. Mayer [SMTP:dmayer@netwalk.com] >> Sent: Tuesday, March 10, 1998 10:43 AM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) radius nt hack >> >> You don't need a hack of it. RadiusNT (at least version 2.2) has >> concurrency checking built in. It works pretty well too. >> >> Peter D. Mayer >> NetWalk Tech Support >> dmayer@netwalk.com >> >> >> -----Original Message----- >> From: Ken Hunter, Aspiring Technologies <ken@aspire.net> >> To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >> Date: Tuesday, March 10, 1998 8:22 AM >> Subject: (usr-tc) radius nt hack >> >> >> Is there a hack of radius nt where the tracking of concurrent logins >> is >> enabled? >> >> ken :) >> >> - >> ********************************************************************** >> ** >> Web Hosting, E-mail addresses, DNS services, Dedicated circuits. >> 33.6, X2(56k), ISDN Dialup available in Prince William County VA. >> >> Ken Hunter Aspiring Technologies >> mailto:ken@aspire.net 9304 Troy Drive >> http://www.aspire.net Nokesville, Va 20181 >> ********************************************************************** >> ** >> >> >> >> >> - >> 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. > >- > 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. >

I have a full time dial up customer is is calling in with a two month old = USR x2 modem. For the first 6 weeks everything was OK. Then we started = dropping the connection a few times a day, and now is rarely stays up for = an hour. I have had him change phone lines, I have changed ISDN lines, and modem on = the Netserver. What would your try next? Here is the link Diagnostic USRobotics Total Control MP I-modem with ISDN/V.34 Link Diagnostics... Chars sent 565 Chars Received 193 Chars lost 0 Octets sent 215 Octets Received 151 Blocks sent 22 Blocks Received 8 Blocks resent 0 Retrains Requested 0 Retrains Granted 0 Line Reversals 0 Blers 399 Link Timeouts 1 Link Naks 0 Data Compression V42BIS 2048/32 Equalization Long Fallback Disabled Protocol LAPM SREJ 128/15 Speed 31200/49333 Last Call 00:00:23 Disconnect Reason is Retransmit Limit OK =20 Bob Roswell broswell@syssrc.com System Source 338 Clubhouse Road Hunt Valley, MD 21031 (410) 771-5544 ext 336 Bob Roswell broswell@syssrc.com System Source 338 Clubhouse Road Hunt Valley, MD 21031 (410) 771-5544 ext 336

Too many blers, could be telco issue or possibly the modem. I would try a different modem, seeing as how you have changed the phone lines, borrow one just for the test. It would also be nice to see the ati11 and aty11 screen prints.

On Fri, 20 Mar 1998, RAR wrote: > I have several netservers. The code posted on their regular (non beta) > Web site reliabley crashes. They have much better (but still > unreliable) code on the beta site. The keep the old code there (with no Are you using the Netserver cards, or the Netserver 8/16? I have 144 ports running off the Netserver cards, and I've only had one crash, ever. For some reason, one night, one of the Netservers lost communications with all of the modems, and the modems picked up the line, but emitted no tone. This was on an older code rev. I'm currently running 3.6.28 in production with no problems. (Well, except for the Quake lag issue.) My test Netserver with two modem cards is running 3.7.24 with no issues to date. (I have two Netservers in one rack, with my test unit talking to just two modem cardss.) Brian

What exactly is a bler? I have narrowed it down to the Netserver itself I have two known good = ISDN BRI lines (acutally about 25..) The problem shows up with both ISDN lines. I have reproduced the customer's problem myself with a totally different = modem and analog line. The weird thing is that 4 other customers onthe same netserver are rock = solid. (ports 5,6,7,8) the problem is on ports 3 and 4 while 1 and 2 are dead. Next test is too hook them up to a different netsetserver, then abandon = the netserver and go back to a plain old analog system Bob Roswell broswell@syssrc.com System Source 338 Clubhouse Road Hunt Valley, MD 21031 (410) 771-5544 ext 336 >>> HBoyle4646 <HBoyle4646@aol.com> 03/20 2:00 AM >>> Too many blers, could be telco issue or possibly the modem. I would try a different modem, seeing as how you have changed the phone lines, borrow = one just for the test. It would also be nice to see the ati11 and aty11 screen prints. - 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.

Peters comments are mild. I have several netservers. The code posted on their regular (non beta) = Web site reliabley crashes. They have much better (but still unreliable) = code on the beta site. The keep the old code there (with no notes, = pointers, buglists or anything else) because the are "an ISO 9000 company" and that is just the beginning. Bob Roswell broswell@syssrc.com System Source 338 Clubhouse Road Hunt Valley, MD 21031 (410) 771-5544 ext 336 >>> Pete Ashdown <pashdown@xmission.com> 03/19 5:49 PM >>> Since it appears that USR/3com's remote access QA team is asleep at the wheel, I thought I would put up some helpful checkpoints for future releases. This may just be spitting in the wind, but I spent most of last night trying to get a setting to "stick" into the HDM's NVRAM and finally gave up. Yet another bug. 1. Test equipment with *ALL* other vendors connection equipment. Chances are, if it is sold, then your customers will have to deal with it as well. Compatibility issues are absolutely inexcusable for a company catering to remote access and ISPs. 2. Go overboard on documentation. I've found TCM's "help" to be sparse = and usually useless. It would be nice to not only know the settings, but what the settings do and mean. What does the "refresh template channels" function do? Why aren't all the card settings in the templates? What is the difference between individual modem NVRAM and card-modem NVRAM? Why are modem defaults for TCM different from modem defaults for the card different from modem AT defaults for the console? Is there nobody out there that believes these types of situations aren't the most aggravating thing you've seen? 3. Test a raft of common card configurations and see if they successfully "stick" to the card after all forms of reset abuse. I've found this problem with two separate settings on the HDM card with two different code releases. Example, on ER 1.0.93 set the CRITICAL "ISDN Async-Sync" = setting to "enable", save to modem NVRAM, save to card modem NVRAM. Hardware = reset and SHAZAM! Its back to "disable". 4. Test the RADIUS client code against as many RADIUS servers you can find. Try to be compliant to the most common form. 5. Test *ALL* the RADIUS settings. Assuming they work hasn't worked in = the past. 6. Try to establish the most common configurations of your client base. Survey them frequently. Test all code releases against these configurations. I am praying to all the modem gods that 4.1 of the HiPer software will not only come soon, but will be successful in most if not all of the above terms. If I feel that I've been recruited as an unwilling beta tester AGAIN, I'm going to be pissed beyond belief. On a positive note, THANK YOU for releasing the USR RADIUS source. - 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.

What version of the imodem code are you running? set switched interface mod:n at_command ati7 (i think) You should be running 2.2.2 on the Imodem code. ken :) At 07:17 AM 3/20/98 -0500, you wrote: >What exactly is a bler? > > >I have narrowed it down to the Netserver itself I have two known good ISDN BRI lines (acutally about 25..) >The problem shows up with both ISDN lines. >I have reproduced the customer's problem myself with a totally different modem and analog line. >The weird thing is that 4 other customers onthe same netserver are rock solid. >(ports 5,6,7,8) the problem is on ports 3 and 4 while 1 and 2 are dead. > >Next test is too hook them up to a different netsetserver, then abandon the netserver and go back to a plain old analog system > >Bob Roswell >broswell@syssrc.com >System Source >338 Clubhouse Road >Hunt Valley, MD 21031 >(410) 771-5544 ext 336 > >>>> HBoyle4646 <HBoyle4646@aol.com> 03/20 2:00 AM >>> >Too many blers, could be telco issue or possibly the modem. I would try a >different modem, seeing as how you have changed the phone lines, borrow one >just for the test. It would also be nice to see the ati11 and aty11 screen >prints. > >- > 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. > > > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

On Wed, 18 Mar 1998, Henry Moats wrote: > > Quite frequently we have problems with netservers who's ports > will not go active. typically it happens when the netserver card > is upgraded with software. > > typical chassis will have > pri/ 12 quads/ 16meg netsv/ 4meg NMC > > I have tried upgrading the chassis to current suite. > powercycle chassis > reset quads > remove quads from service then back > set modem s5-s52 active > reset all ports > reset netserver nac/ nic make sure the DTE is set right (nic, priTdm, t1) > > any ideas > ______________________________________________________________________ > | > Henry Moats Network Services Support nc0419 ext 3671 | > ______________________________________________________________________| > > > > - > 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. > /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Hmm... thats a fair argument. If the ARC were to implement a VoIP solution, you would still need a H.323 Gatekeeper and some type of directory server like LDAP. These would need to operate on potentially thrid party equipment, which doesn't really make VoIP anything special for any one vendor (apart from other issues like codecs etc). A completely integrated solution on the Edgeserver platform is the way to go. This allows 3Com to tailor your requirements into OUR solution, and also allow you additional development through higher level API's. I also believe issues like OSPF, L2TP etc are more important in the ARC for the time being - especially considering the fact that the ARC is an Access router, which provides one part of the Carrier/ISP market, whilst Edgeserver is corporate/enterprise based and hence, the reason for Windows NT. There would be some obvious interest here from the carrier, but I would doubt any concerns by them with using NT. The reason why VoIP is predominantly being seen on NT I would assume, to be because of Marketing for one reason, but primarily because most of the API's developed for VoIP at the moment are being developed for NT. H.323 is quite a broad umbrella standard, and for any company to develop a complete solution from the ground up, would take hundreds of engineers to get VoIP solutions to market as quickly as they are able to today. The problem here, is if we developed a BSDI solution, and it took another year, then everyone would be wondering why we hadn't developed a solution by now! (typical catch 22). One major reason for deploying a H.323 API for NT is so companies like Microsoft can develop client-based solutions. This then allows PC-PC communications over H.323 almost immediate, once client software is avaialble (NetMeeting). As a result, most MFR's are capitalising on these API's (enhanced) to develop Head-End solutions, bringing a VoIP solution to market within an acceptable time-frame; mainly due to the fierce cometition in the marketplace toay. I believe we are about 6months ahead of our nearest competitor on VoIP solutions for the moment, which does provide a major marketing advantage to us... If we're not the leader, then someone else always will..... I don't know about you guys, but Microsoft seems to be taking Market Share from everywhere these days, on a daily basis. In Australia, just about every new ISP, or Corporate setup is using an NT solution of some sort, and can therefore support our VoIP solution. I do understand the advantages for using Unix platforms, but most ISP's and carriers these days, will have some type of interoperable NT solution in their network (whether they like it or not!). Now I don't know who's using our solutions at the moment, but my guess is that the Carrier is scared of the ISP due to the threat of lost revenue. With this in mind, my guess is the Carriers are already 5 steps ahead of the ISP. So at the end of the day, if you want VoIP, then you'll have to take a risk and go for a solution quickly, cause chances are, the Carrier is going to try and keep you out of their heritage money-making market. Please respond to usr-tc@lists.xmission.com cc: (bcc: Jason Kelton/AU/3Com) Jeff> We are quite eager to be able to do some VOIP stuff, but Jeff> there is absolutely no way on earth that we're going to be Jeff> running edgeservers to do it. I agree with your sentiments on Edgeservers. We recently had the presentations about VoIP from the UK marketing people who in response to my refusal to run NT stated that "95% of all VOIP developement is on NT". My response that less than 5% of ISP's used NT for their servers fell on deaf ears.

At 09:46 AM 3/20/98 -0600, Brian wrote: >On Wed, 18 Mar 1998, Henry Moats wrote: >> Quite frequently we have problems with netservers who's ports >> will not go active. typically it happens when the netserver card >> is upgraded with software. >> >> typical chassis will have >> pri/ 12 quads/ 16meg netsv/ 4meg NMC >> >> I have tried upgrading the chassis to current suite. >> powercycle chassis >> reset quads >> remove quads from service then back >> set modem s5-s52 active >> reset all ports >> reset netserver nac/ nic > >make sure the DTE is set right (nic, priTdm, t1) We had this problem on all our 16-meg netserver cards running 3.5.34, even with the Line Interface Source set properly (we're on priTdm). When we upgraded the cards to 3.7.24, the problem disappeared.. :> --- Edward Kern (dag@soulfood.org)

On Fri, 20 Mar 1998, Brian Elfert wrote: > On Fri, 20 Mar 1998, RAR wrote: > > > I have several netservers. The code posted on their regular (non beta) > > Web site reliabley crashes. They have much better (but still > > unreliable) code on the beta site. The keep the old code there (with no > > Are you using the Netserver cards, or the Netserver 8/16? > > I have 144 ports running off the Netserver cards, and I've only had one > crash, ever. For some reason, one night, one of the Netservers lost > communications with all of the modems, and the modems picked up the line, > but emitted no tone. This was on an older code rev. > > I'm currently running 3.6.28 in production with no problems. (Well, > except for the Quake lag issue.) My test Netserver with two modem cards > is running 3.7.24 with no issues to date. (I have two Netservers in one > rack, with my test unit talking to just two modem cardss.) > > Brian Wish I had a spare Netserver to do that sorta thing. We recently added one HDM to a chassis full of quads and a Netserver, and started getting our first major complaints about Quake lag. We're running 3.6.28 on the Netservers, and I'm scared to go to 3.7.24 because of the problems with it I've seen here on the list (slowdowns, 8-bit telnet, etc). I'm also scared to plug one of our new ARCs in because of all the rebooting problems reported here with the current release of ARC code. We haven't yet paid for a support contract so I don't even know if we can get the beta code that fixes any of these glitches. I'm just crossing my fingers and hoping that TCS 3.1 (the v.90 release) is solid and fixes Quake problems before my gaming customers start to storm the office :) I have a feeling I'm going to have to use Netservers only for quads and ARCs for the HDMs to get good performance. If any of you have any tips in the meantime on what I can twiddle to help Quake -- if anything -- I'm game. I've run into the non-sticking HDM setting problem in 1.0.7 too, so I finally sat down and wrote a Perl script to snmpwalk and snmpset all our modem settings to be exactly the same, so I wouldn't have to keep checking things in TCM. That helps, except that for quads, you can't change settings when the modem's in use. HDM's don't appear to have that problem, which is a nice touch. It almost makes up for the NVRAM problem. Almost. :) I also flashed 5.8.6 onto some of our quads this week and suddenly started getting calls saying x2 was broken. Having them run the connection analysis cgi, it came up with an x2 status of "incompatible x2 versions". Oh, yay. Fix program to change the "x2 version 2" setting to disabled, re-run once everyone logs out again... bleah. I believe we might be seeing some channels on our HDM get stuck, where the %utilization bar graph had an LED or two lit and the Netserver showed no logons, and our MRTG graph showed a few too many calls that night... Rebooting the HDM (and thus losing all the ISDN settings) seemed to fix it. I won't get into the packet fragmentation bug, or the netmask limitations, on the NMC. Oh well, that's my rant of the week. :) FWIW, I don't think we've ever had a Netserver reboot, and I've only seen ONE quad take itself out of service since we turned up all this stuff in August. When it works, it's very reliable and solid. Our main problem is that we've got a large chunk of our service area with SLC's scattered aroudn and they're mad that they can't get x2 in those areas. Fortunately we have Bellsouth's ear on this and they've been out pulling new fiber. Still, for some of these Quake-type problems, I've got half a mind to get a used PM2E (or maybe a Cisco 2511) and a half dozen Couriers or I-modems to keep them quiet... Mike Andrews/MA12/ICQ 6602506 this chromosome intentionally left blank mandrews@dcr.net -- mandrews@termfrost.org -- http://www.termfrost.org/ Senior Systems & Network Administrator, Digital Crescent, Frankfort, KY Providing x2 Internet Access in Franklin, Anderson, and Shelby Counties

> I'm the type of person that once something is working you lock it up in a > closet and don't let anyone touch it. However, on occasion we have to > shutdown one of our TC boxes. The problem is when we bring it back up, > sometimes the first span on the dual T-1/PRI card will act funny. By that I > mean it will let the couple of channels connect and operate, but the rest > will either give dead air or go in and out (orange light blinks on and off > on the quad modem card). The second span works fine. I've tried resetting > the T-1 Card, reseating the front card, and reseating the front and back > cards. Nada. What has worked is simply pulling the cord from the smart > jack to the T-1 for a few seconds and putting it back in. It's not that big > of a deal now I know what to do, but I'd like to know if it's a quirk of the > TC, telco programming on the T-1, or what. It is the central office switch. They all do this at times. You are doing exactly what I end up doing too, although my lines don't give dead air - they actually get busied out by the switch. At one time, I even had to call up the phone company to get the trunks released because they stayed that way for days no matter what I tried. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

I'm the type of person that once something is working you lock it up in a closet and don't let anyone touch it. However, on occasion we have to shutdown one of our TC boxes. The problem is when we bring it back up, sometimes the first span on the dual T-1/PRI card will act funny. By that I mean it will let the couple of channels connect and operate, but the rest will either give dead air or go in and out (orange light blinks on and off on the quad modem card). The second span works fine. I've tried resetting the T-1 Card, reseating the front card, and reseating the front and back cards. Nada. What has worked is simply pulling the cord from the smart jack to the T-1 for a few seconds and putting it back in. It's not that big of a deal now I know what to do, but I'd like to know if it's a quirk of the TC, telco programming on the T-1, or what. The Dual T-1 card is hardware version 4.0 and running version 4.2.1 code Quad modems are hardware version 3.0.0 and running version 5.6.7 code TIA Walter N. Gnann ISLC, Manager Phone: 803.770.1000 Fax: 803.770.1002 http://www.islc.net wgnann@islc.net

So who is using the 3com xDSL cards in there TC hubs? I saw these at ISPcon, and the sales people told me "these have been out for over a month". Yet I never heard it mentioned here, and didn't see anything on there site about it. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

At 11:29 AM 3/20/98 -0500, Mike Andrews wrote: >Wish I had a spare Netserver to do that sorta thing. not really.. netserver:=quake lag now spare hiperarcs to play with would be cool.. (and if we are going to dream, make it count ;) >We recently added >one HDM to a chassis full of quads and a Netserver, and started getting >our first major complaints about Quake lag. Yep. >We're running 3.6.28 on the >Netservers, and I'm scared to go to 3.7.24 because of the problems with it >I've seen here on the list (slowdowns, 8-bit telnet, etc). I'm also >scared to plug one of our new ARCs in because of all the rebooting >problems reported here with the current release of ARC code. We haven't >yet paid for a support contract so I don't even know if we can get the >beta code that fixes any of these glitches. Bet you could if you really tried. Can't imagine them denying you working code for a new hiperarc.. It's worth it. With ER code our arcs work ok but we are anxiouly awaiting new code (w/ MPIP). Hope it's soon.. >I'm just crossing my fingers >and hoping that TCS 3.1 (the v.90 release) is solid and fixes Quake >problems before my gaming customers start to storm the office :) HiperArc *is* the fix... and always will be IMO... >I have a >feeling I'm going to have to use Netservers only for quads and ARCs for >the HDMs to get good performance. If any of you have any tips in the >meantime on what I can twiddle to help Quake -- if anything -- I'm game. Sell all your netservers and be a hiper only isp. We are a netserverless (and quadless) isp and it didn't cost more than $1100-$2000 per chassis to do it.. when those extra PPC risc engines crank up with something to do (like ip telephony?) then we'll be glad we did it now. But having happy quake players is a good enough reward.. Our signsup increased as soon as we stomped quakelag.. We've had two record months in a row.. [snip] >Fortunately >we have Bellsouth's ear on this and they've been out pulling new fiber. >Still, for some of these Quake-type problems, I've got half a mind to get >a used PM2E (or maybe a Cisco 2511) and a half dozen Couriers or I-modems >to keep them quiet... selling off a 2059 or a 1706 in exchange for a 02861 makes good economic sense here. Source technology is was selling them for $10,126 at ispcon and we just sold a 2059 for $8500 and a 1706 for $9000.. the "upgrade" might cost less than the PM or 2511! And everybody wins.. the folks that purchase our netserver chassis don't care about quake or ip telephony.. allen P.S. what's the trick to getting bellsouth's ear? i'd really like to know.. _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

Thus spake Allen Marsalis >At 11:29 AM 3/20/98 -0500, Mike Andrews wrote: >>I'm just crossing my fingers >>and hoping that TCS 3.1 (the v.90 release) is solid and fixes Quake >>problems before my gaming customers start to storm the office :) >HiperArc *is* the fix... and always will be IMO... Nope, HiperArc is a workaround, there is absolutely no reason that the netserver shouldn't be able to handle UDP packet streams better than it does. There are all sorts of access servers out there that work on the same scale with much the same processing power (or less) that handle UDP streams like that with no problem. The fix would be to work on the netserver code to fix its handling of UDP streams, *not* having all their customers spend many thousands of dollars to replace the netservers. Or, if they're looking at the HiperArc's as a solution to the UDP stream problem, then give us HiperArc's in exchange for our netservers at no charge. >P.S. what's the trick to getting bellsouth's ear? i'd really like to know.. Lots of screaming and yelling, and, if you have a legitimate complaint, calls to the Public Service (or Utility, whatever its called in your state) Commision. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

> So who is using the 3com xDSL cards in there TC hubs? I saw these at > ISPcon, and the sales people told me "these have been out for over a > month". Yet I never heard it mentioned here, and didn't see anything on > there site about it. What they didn't tell you is that it is a different chassis. The mid-plane in that chassis is totally different than a standard TC chassis. The packet bus is gone, and I believe, replaced with a cell based ATM bus. Not exactly sure on that, though... Despite that, it looks like a nice box. A lot better than the original model. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

> not really.. netserver:=quake lag > now spare hiperarcs to play with would be cool.. (and if > we are going to dream, make it count ;) I've got about 60 extras! <grin> We just put together a big deal where we purchased the new double up kit that includes the ARC - purchased the new 130A chassis, and built fully loaded ones with 5 extra ARC's per box. We now have 12 fully loaded HiPer chassis, and 60 extra ARC's to replace all my netservers with (well, not all, but most). > Bet you could if you really tried. Can't imagine them denying you working > code for a new hiperarc.. It's worth it. With ER code our arcs work ok > but we are anxiouly awaiting new code (w/ MPIP). Hope it's soon.. ER code is solid once it is running, but flakey if you tinker with it while it is taking calls. I'm happy with it right now, though. I'll take OSPF way before MPIP, though. > HiperArc *is* the fix... and always will be IMO... I'm afraid you are correct on this one, which is why we purchased the double up's with ARC's. HINT: Building fully loaded HiPer chassis with the double up w/ARC is about the same price as double up w/o ARC, since you would need to buy 2 ARC's at standard price to load the box. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

At 10:13 AM 3/21/98 -0500, Jeff Mcadams wrote: >Thus spake Allen Marsalis > >>HiperArc *is* the fix... and always will be IMO... > >Nope, HiperArc is a workaround, there is absolutely no reason that the >netserver shouldn't be able to handle UDP packet streams better than it >does. There are all sorts of access servers out there that work on the >same scale with much the same processing power (or less) that handle UDP >streams like that with no problem. The fix would be to work on the >netserver code to fix its handling of UDP streams, *not* having all >their customers spend many thousands of dollars to replace the >netservers. Or, if they're looking at the HiperArc's as a solution to >the UDP stream problem, then give us HiperArc's in exchange for our >netservers at no charge. > I wish I could agree with you. glancing at the hardware, sure there is enough potential horsepower, but almost all hardware/software systems have limits based on prior design decisions.. like 640k base memory in dos... Of course I am strickly speculating, but if there wasn't a *major* problem with solving quake lag, it would have seen daylight by now... However I do agree that the exchange should have been at no charge.. I really did spend too much to solve the problem.. But what else to do? Sit and wait *forever*?... Now I'm happily signing up folks in record numbers.. I feel it was a good decision for two reasons; my known benefit *right now* having rid ourselves of quake lag, and unknown benefits of future services that use the extra PPC's.. and once they come out with new really cool "must have" stuff, then the FMP of netservers, quads, and low density chassis will go through the floor.. >>P.S. what's the trick to getting bellsouth's ear? i'd really like to know.. > >Lots of screaming and yelling, and, if you have a legitimate complaint, >calls to the Public Service (or Utility, whatever its called in your >state) Commision. >-- I certainly have tried both.. There must be another trick, like holding a "thermal coupled detenator" in your hand.. Worked on Jabba the Hut... allen

Thus spake Allen Marsalis >At 10:13 AM 3/21/98 -0500, Jeff Mcadams wrote: >>Thus spake Allen Marsalis >>>HiperArc *is* the fix... and always will be IMO... >>Nope, HiperArc is a workaround, there is absolutely no reason that the >>netserver shouldn't be able to handle UDP packet streams better than it >>does. There are all sorts of access servers out there that work on the >>same scale with much the same processing power (or less) that handle UDP >>streams like that with no problem. The fix would be to work on the >>netserver code to fix its handling of UDP streams, *not* having all >>their customers spend many thousands of dollars to replace the >>netservers. Or, if they're looking at the HiperArc's as a solution to >>the UDP stream problem, then give us HiperArc's in exchange for our >>netservers at no charge. >I wish I could agree with you. glancing at the hardware, sure there >is enough potential horsepower, but almost all hardware/software systems >have limits based on prior design decisions.. like 640k base memory in >dos... Which is purely a software issue...just like the limitations of the netserver are purely software issues...should be easily fixed. >Of course I am strickly speculating, but if there wasn't a *major* >problem with solving quake lag, it would have seen daylight by now... Not so sure I agree with you here. >However I do agree that the exchange should have been at no charge.. I >really did spend too much to solve the problem.. But what else to do? >Sit and wait *forever*?... Now I'm happily signing up folks in record >numbers.. I feel it was a good decision for two reasons; Well, let me make sure on this. I was in no way faulting your decision. I can't, in good conscience, make that same decision yet because of the lack of MPIP support in the Arc's, but we will most assuredly make that move soon after the Arc's support MPIP. And it will mean that we will no longer be affected by Quake Lag, but I in no way consider it a "fix" for Quake Lag, but a upgrade to new equipment that happens to not be affected by the same problem. That's a subtle, but important distinction in my eyes. >>>P.S. what's the trick to getting bellsouth's ear? i'd really like to know.. >>Lots of screaming and yelling, and, if you have a legitimate complaint, >>calls to the Public Service (or Utility, whatever its called in your >>state) Commision. >I certainly have tried both.. There must be another trick, like holding >a "thermal coupled detenator" in your hand.. Worked on Jabba the Hut... Oh, I forgot the other element of what worked for us last time. Have all of our customers that called us, call them as well. We had people from their call centers calling us to find out what the problem was because we totally swamped their call centers. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 03:32 PM 3/21/98 -0500, Jeff Mcadams wrote: >Thus spake Allen Marsalis >>At 10:13 AM 3/21/98 -0500, Jeff Mcadams wrote: >>>Thus spake Allen Marsalis >>>>HiperArc *is* the fix... and always will be IMO... > >>>Nope, HiperArc is a workaround, there is absolutely no reason that the >>>netserver shouldn't be able to handle UDP packet streams better than it >>>does. There are all sorts of access servers out there that work on the >>>same scale with much the same processing power (or less) that handle UDP >>>streams like that with no problem. The fix would be to work on the >>>netserver code to fix its handling of UDP streams, *not* having all >>>their customers spend many thousands of dollars to replace the >>>netservers. Or, if they're looking at the HiperArc's as a solution to >>>the UDP stream problem, then give us HiperArc's in exchange for our >>>netservers at no charge. > >>I wish I could agree with you. glancing at the hardware, sure there >>is enough potential horsepower, but almost all hardware/software systems >>have limits based on prior design decisions.. like 640k base memory in >>dos... > >Which is purely a software issue...just like the limitations of the >netserver are purely software issues...should be easily fixed. Not necessarily. Had MS "fixed" the 640K barrier, much code would be broken, both OS and application... So fixing it might force a total rewrite of all other subsystems (like MPIP, etc) and that is probably out of the question for the netserver.. unless they plan to port pilgrim code over.. would be my luck if they did. but the arcs are nice anyway. We were just fortunate to own relatively little equipment (4 chassis) at the time.. >>Of course I am strickly speculating, but if there wasn't a *major* >>problem with solving quake lag, it would have seen daylight by now... > >Not so sure I agree with you here. You guys have scared me with your faith (or lack thereof) in USR from the day I signed onto this list.. I often think back to my very first post showing concern that we couldn't expect simple ports of TCM or bug fixes from USR.. Now that I've hung out for a while, I see your point. Still no OSPF or true (free?) quake lag fix for netservers.. NMC classlessfulness, and so forth.. However, I must have some faith in my chosen vendor.. If we receive arc MPIP in the next 30 days and we don't have to call the Pachalbel Canon hotline, I'll still be a very happy camper.. PM's might be good or bad, I really don't know but they arn't much to look at.. >>However I do agree that the exchange should have been at no charge.. I >>really did spend too much to solve the problem.. But what else to do? >>Sit and wait *forever*?... Now I'm happily signing up folks in record >>numbers.. I feel it was a good decision for two reasons; > >Well, let me make sure on this. I was in no way faulting your decision. >I can't, in good conscience, make that same decision yet because of the >lack of MPIP support in the Arc's, but we will most assuredly make that >move soon after the Arc's support MPIP. And it will mean that we will >no longer be affected by Quake Lag, but I in no way consider it a "fix" >for Quake Lag, but a upgrade to new equipment that happens to not be >affected by the same problem. That's a subtle, but important >distinction in my eyes. Well actually, it wasn't quite as fair a deal as I would have liked.. But being robbed of 10K to totally eliminate one of my biggest problems was the decision. And I have chosen not to hold a grudge.. Why I'm not so sure. Money is tight. I guess I'm just elated to be able to move on.. The only thing that might make me feel bitter would be a wonderful and free fix for quake lag without such extreme measures that I have taken.. Or no MPIP for months.. >>>>P.S. what's the trick to getting bellsouth's ear? i'd really like to know.. > >>>Lots of screaming and yelling, and, if you have a legitimate complaint, >>>calls to the Public Service (or Utility, whatever its called in your >>>state) Commision. > >>I certainly have tried both.. There must be another trick, like holding >>a "thermal coupled detenator" in your hand.. Worked on Jabba the Hut... > >Oh, I forgot the other element of what worked for us last time. Have >all of our customers that called us, call them as well. We had people >from their call centers calling us to find out what the problem was >because we totally swamped their call centers. >-- heh. thanks, that's a great idea.. Allen _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

We are going to be multi-homing soon (priori/savvis perhaps) and when the time comes to do this, I am going to be changing some of the routing on our network at the same time. Right now I am basically just running RIPv2 on the TC hubs, and occasionally a UNIX server, and of course our cisco and a few other leaf routers. What I am thinking of doing is running OSPF on our border router, OSPF (a la gated) on our UNIX servers, and basically redistributing ripv2 so that the TC's can be happy. Is anyone doing this now? If so can I see a sample of your gated.conf file? Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/

Once upon a time Allen Marsalis shaped the electrons to say... >dos... Of course I am strickly speculating, but if there wasn't a *major* >problem with solving quake lag, it would have seen daylight by now... I disagree. I don't see any reason why the lag can't be fixed in the old HW. It certainly isn't a problem with the core of the OS - that is ComOS. It could be one of the modifications made to it, but what is done can be undone. As for 'would have seen daylight' - how long have they been making noise about OSPF on the TC now? 2 years? More? Now they are talking about it being on the HiPer soon? A lot of people I talked to at ISPCon are feeling screwed over. Like suddenly TC users are second class citizens, and oddly all of the 'fixes' involved upgrading their HW... Quake lag should be fixed on the TC, and OSPF should be supported on it. When there are valid HW limitations, fine, that happens. But I can't see any HW limitation stopping these fixes and features. -MZ -- <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human being, me "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail Discordia!

Hi all. New to this list just setup our first TC rack.. Now, it seems everyone is logging in ok but I'm getting the following critical event whenever someone logs out. At 18:35:29, Facility "Call Initiation Process", Level "CRITICAL":: CIP: User ca ryn is not configured as dial out user. Set the type to dial_out in the user record Any clues?? I don't have any users trying to dial out. Scott

On Saturday, March 21, 1998 7:55 PM, MegaZone [SMTP:megazone@megazone.org] wrote: > Once upon a time Allen Marsalis shaped the electrons to say... > >dos... Of course I am strickly speculating, but if there wasn't a *major* > >problem with solving quake lag, it would have seen daylight by now... > > <snip> > > A lot of people I talked to at ISPCon are feeling screwed over. Like > suddenly TC users are second class citizens, and oddly all of the 'fixes' > involved upgrading their HW... > > Quake lag should be fixed on the TC, and OSPF should be supported on it. > When there are valid HW limitations, fine, that happens. But I can't see > any HW limitation stopping these fixes and features. I second that. There are a lot of Quads/Netservers out there and will be for some time. For an official USR/3COM response please see ..... http://www.3com.com/............ (now what was that URL?) Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) http://www.netdoor.com 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28

To disable v.90 on Courier - S58.5=1 Personally, I've gotten much better x2 connections to the IBM/Prodigy local gateway (and other x2 servers) and do not have to disable v.90. My v.90 tests (long-distance) have not been as encouraging. I've put RealAudio v.90 handshake recording, and a "less than total v.90 kill" update on my web site at http://pages.prodigy.net/bbhi/r-rnut-x2.htm Aloha, Richard > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Curt Shambeau > Sent: Sunday, March 22, 1998 8:26 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) V.90 for Couriers > > > > Well, USR has released the V.90 code for Couriers, and after upgrading I can > > only connect with our Total Controls at 28.8. Before I got 48k+. It almost > > runs through 2 complete handshakes, one sounds like X2 (one boing), and the What version code do you have on the server modems?

Thus spake Allen Marsalis >Not necessarily. Had MS "fixed" the 640K barrier, much code would >be broken, both OS and application... So fixing it might force a >total rewrite of all other subsystems (like MPIP, etc) and that is >probably out of the question for the netserver.. Well...it may be more effort to rewrite it (like the 640K barrier would be) but regardless, that is the fix, not forcing everyone to upgrade to arc's. The upgrade to arc's is a cop-out, plain and simple. I'm not saying its not a valid thing for customers to do at all, we'll proly do it to when they support MPIP, but I guarentee you we'll be grumbling about it all the way, and be pushing and prodding for every possible price break we can get, and the "upgrade" complaint here is certainly one tactic we'll be using. :) The point is...MSDOS was never fixed (it still exists in win95 even to some degree) because there was third party software that depended upon it, there is no third party software that depends on the netserver code. Yes, it might require a rewrite of the netserver subsystems, but I would highly surprised if they did, and regardless, USR/3Com is gonna catch a lot of flack because of the lack of a true fix, at least from me. >You guys have scared me with your faith (or lack thereof) in USR from >the day I signed onto this list.. Its not just USR. :) Although they are the most egregious offenders IMHO. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I agree that the comparison to the memory model in DOS is a weak one (after all, there _are_ ways for an OS to present multiple memory models). Microsoft's decision not to fix DOS was an financially profitable one. And it does appear USR/3Com is adopting the same strategy toward the Netserver, at least. The fact that Netservers have a hard time routing UDP bothers me a little; the fact that 3Com Corporation has decided to continue to sell a faulty product bothers me a lot. Is this a habit we see forming? If fundamental problems are discovered with the ARC, is 3Com going to fix them? (Or will the ARC be replaced by something with *another* set of problems?) I'm a programmer, too. I'm willing to forgive a lot when it comes to maintaining or rewriting ancient code. I'd just like some idea that they're going to make a better stab at perfection with the ARC.

> What I am thinking of doing is running OSPF on our border router, OSPF (a > la gated) on our UNIX servers, and basically redistributing ripv2 so that > the TC's can be happy. > > Is anyone doing this now? Yep. So far it's configured to the point where it works, but probably needs adjustment to make it technically correct. Authentication is also on the 'to do' list. > If so can I see a sample of your gated.conf file? -- cut -- traceoptions "/var/log/gated.log" size 100k files 2 general; rip no { } ; ospf yes { backbone { authtype none ; networks { 203.60.16.0 ; } ; interface ef0; } ; } ; -- cut -- This is from a BSDi box, but we run identical configurations on our Linux boxes as well. Cheers, Bob.

I agree with MZ. My PM2ER has an i386 processor with 4 megs of RAM, 2.8MB of which is still unused, and it processes 20 B channel ISDN calls (some multilinked) and runs quake a full speed with 40-50ms round trip ping times in quake. I'm so happy with it that I almost want to cry *snif*. The netserver has a 486 and 16meg of RAM and can't process a non-multilinked analog call. We get pings of 1300+ on a 48 port chassis which isn't even full of calls. Just the facts as seen by a lowly customer. Tom > -----Original Message----- > From: MegaZone [SMTP:megazone@megazone.org] > Sent: Saturday, March 21, 1998 8:55 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Lack of quality assurance at USR/com > > Once upon a time Allen Marsalis shaped the electrons to say... > >dos... Of course I am strickly speculating, but if there wasn't a > *major* > >problem with solving quake lag, it would have seen daylight by now... > > I disagree. I don't see any reason why the lag can't be fixed in the > old > HW. It certainly isn't a problem with the core of the OS - that is > ComOS. > It could be one of the modifications made to it, but what is done can > be > undone. > > As for 'would have seen daylight' - how long have they been making > noise > about OSPF on the TC now? 2 years? More? Now they are talking about > it > being on the HiPer soon? > > A lot of people I talked to at ISPCon are feeling screwed over. Like > suddenly TC users are second class citizens, and oddly all of the > 'fixes' > involved upgrading their HW... > > Quake lag should be fixed on the TC, and OSPF should be supported on > it. > When there are valid HW limitations, fine, that happens. But I can't > see > any HW limitation stopping these fixes and features. > > -MZ > -- > <URL:mailto:megazone@megazone.org> Gweep, author, webmaster, human > being, me > "A little nonsense now and then, is relished by the wisest men" > 781-788-0130 > <URL:mailto:megazone@gweep.net> <URL:http://www.megazone.org/> Hail > Discordia! > > - > 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.

I got a copy of the v.90 code on Thursday and it connected just fine to our rack. I connected before at 49999 almost every time and after the upgrade to the courier, I connected at 52000. We are running 3.0.2 on the TC unit. No problem connecting at all on any of the calls that I placed on Friday. At 12:26 PM 3/22/98 -0600, you wrote: >> Well, USR has released the V.90 code for Couriers, and after upgrading I can >> only connect with our Total Controls at 28.8. Before I got 48k+. It almost >> runs through 2 complete handshakes, one sounds like X2 (one boing), and the >> second sounds like v.34 (two boings). (Real technical right?). The ati11 >> reveals no helpful diagnostics, the field for v.90 is blank. Anyone else >> have any experiences to share? I know there's an S-register that can turn >> off V.90 and force X2. Is it s33-66 or something like that? This has >> happened with at least 2 others who have upgraded their Couriers and tried >> to connect to our TC's. I haven't tried upgrading a Sportster yet, can I >> expect the same? Our TC's are running the 3.0.2 system release. > >I've heard this already from customers. You need to disable v.90, and the >X2 connects will be back to normal or even better than normal. Sorry, I >don't have the "S" register off hand. > >-------------------------------------------------------------------------- >| Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | >| Executive Vice President - Exec-PC, Inc. | >-------------------------------------------------------------------------- > > >- > 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. > >

> Well, USR has released the V.90 code for Couriers, and after upgrading I can > only connect with our Total Controls at 28.8. Before I got 48k+. It almost > runs through 2 complete handshakes, one sounds like X2 (one boing), and the > second sounds like v.34 (two boings). (Real technical right?). The ati11 > reveals no helpful diagnostics, the field for v.90 is blank. Anyone else > have any experiences to share? I know there's an S-register that can turn > off V.90 and force X2. Is it s33-66 or something like that? This has > happened with at least 2 others who have upgraded their Couriers and tried > to connect to our TC's. I haven't tried upgrading a Sportster yet, can I > expect the same? Our TC's are running the 3.0.2 system release. I've heard this already from customers. You need to disable v.90, and the X2 connects will be back to normal or even better than normal. Sorry, I don't have the "S" register off hand. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Well, USR has released the V.90 code for Couriers, and after upgrading I can only connect with our Total Controls at 28.8. Before I got 48k+. It almost runs through 2 complete handshakes, one sounds like X2 (one boing), and the second sounds like v.34 (two boings). (Real technical right?). The ati11 reveals no helpful diagnostics, the field for v.90 is blank. Anyone else have any experiences to share? I know there's an S-register that can turn off V.90 and force X2. Is it s33-66 or something like that? This has happened with at least 2 others who have upgraded their Couriers and tried to connect to our TC's. I haven't tried upgrading a Sportster yet, can I expect the same? Our TC's are running the 3.0.2 system release. Thanks for any info, Peter D. Mayer NetWalk Tech Support dmayer@netwalk.com

At 09:33 AM 3/22/98 -0500, Jeff Mcadams wrote: >Thus spake Allen Marsalis >>Not necessarily. Had MS "fixed" the 640K barrier, much code would >>be broken, both OS and application... So fixing it might force a >>total rewrite of all other subsystems (like MPIP, etc) and that is >>probably out of the question for the netserver.. > >Well...it may be more effort to rewrite it (like the 640K barrier would >be) but regardless, that is the fix, not forcing everyone to upgrade to >arc's. I stand corrected to a degree. The big difference here with this analogy is that NAS is a total proprietary solution and an OS has an application base. In theory USR has control over 100% of the code base.. So a hardware limitation would be the only excuse. And everyone here seems to agree that is unlikely.. as for "forcing everyone to upgrade", not everyone, only those who want to offer quake. (I for one) For folks not caring about quake or hosting "future services" on the hiper cards, the netservers are great. or would be with OSPF and all the other stuff currently working on the competition's products.. >The upgrade to arc's is a cop-out, plain and simple. Oh I agree.. please don't misunderstand me. But the upgrade cost can be kept to a minimum with a little creativity was my point. And also that I can't fight every battle with USR and win. wish I could though. After suffering for so long, I would either have to get *way mad* or just move on.. I just got though battling the telco and I just don't have the breath left.. :-\ >I'm not >saying its not a valid thing for customers to do at all, we'll proly do >it to when they support MPIP, but I guarentee you we'll be grumbling >about it all the way, and be pushing and prodding for every possible >price break we can get, and the "upgrade" complaint here is certainly >one tactic we'll be using. :) I agree with all this. However it is my opinion (gamble?) that once the masses start upgrading, the market price of netservers, quads, and low density chassis will go way down.. >The point is...MSDOS was never fixed (it still exists in win95 even to >some degree) because there was third party software that depended upon >it, there is no third party software that depends on the netserver code. Yep. >Yes, it might require a rewrite of the netserver subsystems, but I would >highly surprised if they did, and regardless, USR/3Com is gonna catch a >lot of flack because of the lack of a true fix, at least from me. yeah but what else is new? They absorb flack like water to a sponge.. >>You guys have scared me with your faith (or lack thereof) in USR from >>the day I signed onto this list.. > >Its not just USR. :) Although they are the most egregious offenders >IMHO. Don't know what "egregious" means but I get your drift... We never "walked around the block" with all the other nas providers and sorta just bet on USR.. So I'll have to take your word on it.. am _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

At 09:53 AM 3/22/98 -0500, Mark R. Lindsey wrote: >I agree that the comparison to the memory model in DOS is a weak one >(after all, there _are_ ways for an OS to present multiple memory >models). Microsoft's decision not to fix DOS was an financially >profitable one. OK how about a hardware limitation then. Like available interrupts on the card.. perhaps interrupts are being shared and the interrupt handlers are all kludged for this. Might be hard to get rid of lag with alot of hokus pokus going on. Of course speculation such as this is total BS and we may never know why quake is not completely fixed on the netserver.. One thing for sure tho.. At least one engineer at USR was (is?) in denial of the problem. How is anything going to be fixed if they don't believe it exists? This was my orignal concern and much of the reason i joined this list.. >And it does appear USR/3Com is adopting the same strategy toward the >Netserver, at least. The fact that Netservers have a hard time routing >UDP bothers me a little; the fact that 3Com Corporation has decided to >continue to sell a faulty product bothers me a lot. Yeah I can't imagine buying one *today*.. and they still retail at over $10k I do believe.. >Is this a habit we see forming? > >If fundamental problems are discovered with the ARC, is 3Com going to >fix them? (Or will the ARC be replaced by something with *another* set >of problems?) > Now hear me clearly.. If this sort of thing is discovered with the ARC, I will bitch the loudest of all.. Or worse, write some more lousy rhymes and top 10 lists... > > > >I'm a programmer, too. I'm willing to forgive a lot when it comes to >maintaining or rewriting ancient code. I'd just like some idea that >they're going to make a better stab at perfection with the ARC. > me too. but without any comment on their part, I'm assuming it's their flagship enterprise product that deserves perfection.. Hope they feel that way too.. allen

As a side note, I CAN connect properly with X2 to a TC running the much older 2.5.1 system release code. The newer TC code must be biased toward the v.90 connect :-) Peter D. Mayer NetWalk Tech Support dmayer@netwalk.com -----Original Message----- >Well, USR has released the V.90 code for Couriers, and after upgrading I can >only connect with our Total Controls at 28.8. Before I got 48k+. It almost >runs through 2 complete handshakes, one sounds like X2 (one boing), and the >second sounds like v.34 (two boings). (Real technical right?). The ati11 >reveals no helpful diagnostics, the field for v.90 is blank. Anyone else >have any experiences to share? I know there's an S-register that can turn >off V.90 and force X2. Is it s33-66 or something like that? This has >happened with at least 2 others who have upgraded their Couriers and tried >to connect to our TC's. I haven't tried upgrading a Sportster yet, can I >expect the same? Our TC's are running the 3.0.2 system release. > >Thanks for any info, > >Peter D. Mayer >NetWalk Tech Support >dmayer@netwalk.com > > >- > 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. >

Standard RADIUS authentication from a UNIX box. check it out I remmed the three lines out below, now I'm not getting the error. But, I still don't see why I'm getting the error when they are not remmed out. I was looking in some of the docs and they said PORT-LIMIT was not supported. Maybe thats the problem. But how do you prevent users from logging in twice?? Scott DEFAULT Password = "UNIX" User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 255.255.255.254, Framed-Netmask = 255.255.255.255, Framed-Routing = None, Framed-Compression = Van-Jacobsen-TCP-IP, Framed-Filter-Id = "std.ppp.in", Framed-MTU = 1500 # Idle-Timeout = 1200, # Session-Timeout = 28800, # Port-Limit = 1 > > Hi all. > > > > New to this list just setup our first TC rack.. Now, it seems > > everyone is logging in ok but I'm getting the following critical > > event whenever someone logs out. > > > > At 18:35:29, Facility "Call Initiation Process", Level "CRITICAL":: CIP: > > User ca > > ryn is not configured as dial out user. > > Set the type to dial_out in the user record > > > How is the user caryn configured? > > krish > > > Any clues?? > > > > I don't have any users trying to dial out. > > > > Scott > > > >

i have been working at learning SNMP monitoring with the Netserver 8/I an observation that i am not impressed with is that i can SEE two lights on the front of the Netserver telling me that two users are logged on - as may be verified by netserver>list connections CONNECTIONS IfName User Name Type DLL mod:1 jagwire DIAL_IN PPP mod:4 davidw DIAL_IN PPP netserver> check - but if i do an snmpwalk server:/# snmpwalk darkstar xxxxxx | grep .ifSpeed. interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.3 = Gauge: 28800 interfaces.ifTable.ifEntry.ifSpeed.4 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.5 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.6 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.7 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.8 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.9 = Gauge: 0 interfaces.ifTable.ifEntry.ifSpeed.10 = Gauge: 0 and server:/# snmpwalk darkstar xxxxxx | grep .ifOperStatus. interfaces.ifTable.ifEntry.ifOperStatus.1 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.3 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.4 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.5 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.6 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.7 = up(1) interfaces.ifTable.ifEntry.ifOperStatus.8 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.9 = down(2) interfaces.ifTable.ifEntry.ifOperStatus.10 = down(2) i am open to the suggestion that i have some setting with the incorrect value, but i cannot think of one that would apply to this situation - my imodem registers are still the stock out of the box as well as the modem init string - how these would affect the SNMP reporting i can only guess, but have seen how describing the color of an apple can affect the taste of a banana ;^) i am running 4.0.13 on the netserver i have been lurking on this list and browsing the archive for a while and see that there are many of you that use SNMP - let me guess, i am the first to observe this, correct? i would be most appreciative for any insight on this matter If four pairs of pants and two squirrels are hanging on your clothesline... you might be a redneck. packrat

[Quoth MegaZone] ] Once upon a time Allen Marsalis shaped the electrons to say... ] >dos... Of course I am strickly speculating, but if there wasn't a *major* ] >problem with solving quake lag, it would have seen daylight by now... ] ] I disagree. I don't see any reason why the lag can't be fixed in the old ] HW. It certainly isn't a problem with the core of the OS - that is ComOS. ] It could be one of the modifications made to it, but what is done can be ] undone. Agreed. I believe 3Com is working to port the new OS (does this OS have a name?), the one that currently runs on the HiPer back to the NetServer. Will this solve the 'udp-lag' problems? Anyone at 3Com care to comment when ComOS on the NetServers will be phased out? ] As for 'would have seen daylight' - how long have they been making noise ] about OSPF on the TC now? 2 years? More? Now they are talking about it ] being on the HiPer soon? A long, long time. I looked at the PM4 with wide eyes at ISPCon. I talked to a 3Com person at the show. I asked what was in the pipeline for the Total Control platform in next few months. He said things like IP Telephony, video conferencing, all that fancy stuff. How about some non-fancy stuff, eh? OSPF? Packet filters that work good? There is a tremendous installed-base of sites which do one thing, and that's IP over dialup. I'd like to see the features for this huge installed base to be priority one. OSPF seems to not be priority one, two, or three. I'm told I can use RipV2 as a workaround. Why should I use a workaround? The rest of my network is using OSPF, and it works like a champ, and converges in half a jiffy. -- Michael Mittelstadt meek@execpc.com VP - Internet Techologies ExecPC Internet http://www.execpc.com/~meek 1-800-ExecPC-1

At 02:38 PM 3/22/98 -0600, Michael Mittelstadt wrote: [snip] >A long, long time. I looked at the PM4 with wide eyes at ISPCon. I >talked to a 3Com person at the show. I asked what was in the pipeline >for the Total Control platform in next few months. He said things >like IP Telephony, video conferencing, all that fancy stuff. How >about some non-fancy stuff, eh? OSPF? Packet filters that work good? I also talked with some "product specialists" at the show and I wasn't too impressed. I got two 180 degree answers when I posed the same question to two of them after the first answer sounded bogus.. Wanted to know if you can bond 4B+D off of two of the new 3com lan routers (2 bri's).. a buddy of mine said you could and I wanted to check it out.. 3com's answer, yes/no... The DSL stuff did look interesting though.. But "Where's the meat and potatoes?" like you say.. Some nice announcement would have been great for a tradeshow.. and 3COM could learn how to party from NeoPlanet, that's for sure! >There is a tremendous installed-base of sites which do one thing, and >that's IP over dialup. I'd like to see the features for this huge >installed base to be priority one. OSPF seems to not be priority one, >two, or three. I'm told I can use RipV2 as a workaround. Why should >I use a workaround? The rest of my network is using OSPF, and it >works like a champ, and converges in half a jiffy. > One of the things this list is for, i hope, is to organize ourselves and maybe apply alittle collective pressure from time to time.. What are our current gripes and how long have they been stuck that way? Although trying to preach to 3com from this list seems ineffective, if I were in charge, I would create a "taskforce" to clear up age old issues that will develop into cancers if they are not careful. Someone with enough drive, instinct, guts, perserverance, to at least change the "on hold" music.. :) But is anyone assigned to the job? If we could put together a "USR-TC Gripe List", then we might have a platform for a change.. And push USR/3COM to put someone on it? Sort of a problem solver whos into "search and distroy" missions.. I mean what good is identifying a problem if you aren't going to act quickly on it.. a Customer Driven Idea System (CDIS) just sound's like something even marketing would like ;) like a good old fashioned "suggestion box".. Only whos going to empty and look at it over at 3com??.. Just in case any of you think that tracking and logging USR's response time on universally recognized deficiencies is a good idea, here's my quick stab at it.. The USR-TC Gripe List ===================== Gripe Result (Netserver) Result (ARC) ===== ================== ============ ARC reboots - improvement MPIP? Yes No(2mos) OSPF? No(2yrs) No Quake Lag No(7mos) Yes NMC classlessfulness none good packet filters ? Telephone Support improvement Pachalbel's Canon none(7mos) It looks to me that the only thing accomplished over the last 6 months is an improvement in the telephone support response time and some ER code to fix arc reboots.. That's really very little for so much griping.. No one is listening then acting... you would think that isp's would be a large enough force (market) to get some *real* attention.. But a few at 3com really do seem to care.. keep us going.. just wish they were not so few and far between... Allen _____________________________________________________________ Allen Marsalis President Voice: 318.222.2NET (2638) Shrevenet, Inc. mailto:am@shreve.net 333 Texas St. Suite 619 FAX: 318.221.6612 Shreveport, LA 71101 http://www.shreve.net _____________________________________________________________ Thoughtful Provider of Internet Services

Don't know alot about getting snmp to work with the netserver, but you do need to get rid of 4.0.13, upgrade to 4.0.14. 1. then enable syslog - give it the address of a host that is capable of syslogging - you will see alot of things that happen within the netserver. 2. Flash your imodems to 2.2.2 - if you haven't already done so. Ken :) At 02:05 PM 3/22/98 -0600, you wrote: > >i have been working at learning SNMP monitoring with the Netserver 8/I > >an observation that i am not impressed with is that i can SEE two lights on >the front of the Netserver telling me that two users are logged on - as may >be verified by > >netserver>list connections > >CONNECTIONS >IfName User Name Type DLL >mod:1 jagwire DIAL_IN PPP >mod:4 davidw DIAL_IN PPP >netserver> > >check - but if i do an snmpwalk > >server:/# snmpwalk darkstar xxxxxx | grep .ifSpeed. >interfaces.ifTable.ifEntry.ifSpeed.1 = Gauge: 0 >interfaces.ifTable.ifEntry.ifSpeed.2 = Gauge: 0 >interfaces.ifTable.ifEntry.ifSpeed.3 = Gauge: 28800 >interfaces.ifTable.ifEntry.ifSpeed.4 = Gauge: 0 >interfaces.ifTable.ifEntry.ifSpeed.5 = Gauge: 0 >interfaces.ifTable.ifEntry.ifSpeed.6 = Gauge: 0 >interfaces.ifTable.ifEntry.ifSpeed.7 = Gauge: 0 >interfaces.ifTable.ifEntry.ifSpeed.8 = Gauge: 0 >interfaces.ifTable.ifEntry.ifSpeed.9 = Gauge: 0 >interfaces.ifTable.ifEntry.ifSpeed.10 = Gauge: 0 > >and >server:/# snmpwalk darkstar xxxxxx | grep .ifOperStatus. >interfaces.ifTable.ifEntry.ifOperStatus.1 = up(1) >interfaces.ifTable.ifEntry.ifOperStatus.2 = up(1) >interfaces.ifTable.ifEntry.ifOperStatus.3 = up(1) >interfaces.ifTable.ifEntry.ifOperStatus.4 = down(2) >interfaces.ifTable.ifEntry.ifOperStatus.5 = down(2) >interfaces.ifTable.ifEntry.ifOperStatus.6 = down(2) >interfaces.ifTable.ifEntry.ifOperStatus.7 = up(1) >interfaces.ifTable.ifEntry.ifOperStatus.8 = down(2) >interfaces.ifTable.ifEntry.ifOperStatus.9 = down(2) >interfaces.ifTable.ifEntry.ifOperStatus.10 = down(2) > > >i am open to the suggestion that i have some setting with the incorrect >value, but i cannot think of one that would apply to this situation - my >imodem registers are still the stock out of the box as well as the modem >init string - how these would affect the SNMP reporting i can only guess, >but have seen how describing the color of an apple can affect the taste of >a banana ;^) > >i am running 4.0.13 on the netserver > >i have been lurking on this list and browsing the archive for a while and >see that there are many of you that use SNMP - let me guess, i am the first >to observe this, correct? > >i would be most appreciative for any insight on this matter > > >If four pairs of pants and two squirrels are hanging on your clothesline... >you might be a redneck. > >packrat > > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

rip is not something I do every day. does anyone out there have ripv2 working between the netserver 8/16i and a cisco series router running ios 11.2 - that doesn't mind sharing configuration notes. Ken :) - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

Quad v34 Digital Modem NAC $1000 ea qty 100 Netserver PRI (20 meg RAM) w/HighSpeed WAN,Ethernet NIC $2750 ea qty 9 Dual PRI NIC/NAC $2000 ea qty 9 Dual T1 (186) NIC/NAC $2000 ea qty 1 Shipping (not express) anywhere is included. Contact me via email if interested.

The isp test account is active and available again for use by anyone that is an isp or network professional. You can telnet to: sage.aspire.net username: ispguest password: ispguest You can ping, traceroute, and send test mail messages. This account runs on an old Vax Station 3100 Model 38 running Vax VMS 6.2. Feel free to visit any time you need to do test pings, traceroutes, or emails. Suggestions, ideas, comments are always welcome. Ken :) - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************

Thus spake Scott Kreuser >Standard RADIUS authentication from a UNIX box. >check it out I remmed the three lines out below, >now I'm not getting the error. But, I still >don't see why I'm getting the error when they are >not remmed out. I was looking in some of the >docs and they said PORT-LIMIT was not supported. >Maybe thats the problem. But how do you prevent users >from logging in twice?? Not sure about Port-Limit support on the Arc's, but Port-Limit doesn't prevent a user from logging in twice, but prevents them from using more than that number of channels in an MLPPP bundle. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Ok ... so I am no dummy when it comes to Radius Authentication and 3COM/USR TC products. I read the list, get several ARC's in, play with them for a few days and then ... put them in service - (2) ARCs and (6) HiperDSPs. Flawless install. 10 days later all is well, so we decided to fire some more up. Go over every detail to ensure a smooth cutover, busy out the old chassis' and when everyone is gone, boom! ... we make the cut. Phew .... all done. Success Success! <Queen's "We are the Champions" plays in the background> A few minutes later the first of many calls to these shiny new chassis' arrive. Not authenticated. Checked the authentication parameters, all looks fine. Cut and paste the secret and such again to ensure this is right. Still no go. So we jump over to the other arc in this chassis and same thing. Callers are not getting authenticated. Just to be sure I understand what is going on we get on the radius server and kill and restart radius in debug mode ... no pa ckets from the newly installed ARC's! What?? hiper2-arc2> sh authentication AUTHENTICATION SETTINGS Local Authentication is: ENABLED RADIUS Authentication is: ENABLED Hint Assigned is: DISABLED Primary Server is: 208.137.128.29 Primary Server Port is: 1645 Secondary Server is: 208.137.128.7 Secondary Server Port is: 1645 Retransmission Timeout: 3 Max Retranmissions: 10 hiper2-arc2> sh authentication counters AUTHENTICATION COUNTERS Local Successful Authentications: 1 Local Failed Authentications: 0 Remote Successful Authentications: 0 Remote Failed Authentications: 0 Remote No Responses: 0 ============== What is going on ?? What to do? I have checked and checked and 2 people went behind me and have done the same thing. Any ideas? Rad log files are not unhappy and the /etc/raddb/clients files are correct. ARG!! Running V4.0.69 of the ARC code. Marshall Morgan Confused! Internet Doorway, Inc. (aka NETDOOR) http://www.netdoor.com 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28

We use the AxCell cards with Viper routers for the remote side and they are excellent. I have to reset an ADSL port about once every 2 or 3 months when an ADSL line goes down. The reason you don't see much about them is because I have no problems with them. I have some ADSL running in the same chassis with modems and Netservers. . . no complaints here except they don't work with TCM, but with a separate management software like HARM. -CH On Fri, 20 Mar 1998, Brian wrote: > So who is using the 3com xDSL cards in there TC hubs? I saw these at > ISPcon, and the sales people told me "these have been out for over a > month". Yet I never heard it mentioned here, and didn't see anything on > there site about it. > > Brian > > > /-------------------------- signal@shreve.net -----------------------------\ > | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | > | Network Administrator | Perl, Linux | Web hosting, online stores, | > | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | > | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | > | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | > \-------------------------- 318-222-2638 x109 -----------------------------/ > > > > - > 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. >

Ken: Wow, what a great service. I have quite often wanted a remote shell to test getting into my system. Thanks. I will definitely make use of this. Steve Buza SysAdmin, North Coast Internet -----Original Message----- > >The isp test account is active and available again for use by anyone that >is an isp or network professional. You can > >telnet to: sage.aspire.net >username: ispguest >password: ispguest > >You can ping, traceroute, and send test mail messages. >This account runs on an old Vax Station 3100 Model 38 running Vax VMS 6.2. >Feel free to visit any time you need to do test pings, traceroutes, or emails. >Suggestions, ideas, comments are always welcome. > > >Ken :) > >- >************************************************************************ >Web Hosting, E-mail addresses, DNS services, Dedicated circuits. >33.6, X2(56k), ISDN Dialup available in Prince William County VA. > >Ken Hunter Aspiring Technologies >mailto:ken@aspire.net 9304 Troy Drive >http://www.aspire.net Nokesville, Va 20181 >************************************************************************ > >- > 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. >

This is a multi-part message in MIME format. ------------=_890606724-16037-0 Received: by news.LF.net (Smail3.2.0.101/news.LF.net) via LF.net GmbH Internet Services from nf1.netforward.com with esmtp for 9.5.9.7.1.2.2.2.7.9.4.tpc.int id m0yGtMA-000byPa; Sun, 22 Mar 1998 23:36:42 +0100 (CET) X-Forwarder: NetForward.com Received: from domo by lists.xmission.com with local (Exim 1.82 #1) id 0yGtGM-0007Dd-00; Sun, 22 Mar 1998 15:30:42 -0700 Received: from (pimout1-int.prodigy.net) [198.83.18.53] by lists.xmission.com with esmtp (Exim 1.82 #1) id 0yGtGJ-0007D9-00; Sun, 22 Mar 1998 15:30:39 -0700 Received: from rg (slip166-72-203-100.hi.us.ibm.net [166.72.203.100]) by pimout1-int.prodigy.net (8.8.5/8.8.5) with SMTP id OAA74900 for <usr-tc@lists.xmission.com>; Sun, 22 Mar 1998 14:07:08 -0500 Message-Id: <199803221907.OAA74900@pimout1-int.prodigy.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal In-Reply-To: <Pine.GSO.3.95.980322122529.7478A-100000@earth> X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Importance: Normal Sender: owner-usr-tc@lists.xmission.com Precedence: bulk Reply-To: usr-tc@lists.xmission.com Thanks for using NetForward! http://www.netforward.com v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v To disable v.90 on Courier - S58.5=1 Personally, I've gotten much better x2 connections to the IBM/Prodigy local gateway (and other x2 servers) and do not have to disable v.90. My v.90 tests (long-distance) have not been as encouraging. I've put RealAudio v.90 handshake recording, and a "less than total v.90 kill" update on my web site at http://pages.prodigy.net/bbhi/r-rnut-x2.htm Aloha, Richard > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Curt Shambeau > Sent: Sunday, March 22, 1998 8:26 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) V.90 for Couriers > > > > Well, USR has released the V.90 code for Couriers, and after upgrading I can > > only connect with our Total Controls at 28.8. Before I got 48k+. It almost > > runs through 2 complete handshakes, one sounds like X2 (one boing), and the What version code do you have on the server modems? - 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. ------------=_890606724-16037-0--

This is a multi-part message in MIME format. ------------=_890610342-21564-0 Received: by news.LF.net (Smail3.2.0.101/news.LF.net) via LF.net GmbH Internet Services from nf2.netforward.com with esmtp for 9.5.9.7.1.2.2.2.7.9.4.tpc.int id m0yGuBn-000byPa; Mon, 23 Mar 1998 00:30:03 +0100 (CET) X-Forwarder: NetForward.com Received: from domo by lists.xmission.com with local (Exim 1.82 #1) id 0yGu5y-00029Y-00; Sun, 22 Mar 1998 16:24:02 -0700 Received: from (thyme.aspire.net) [207.233.170.7] by lists.xmission.com with esmtp (Exim 1.82 #1) id 0yGu5u-00028l-00; Sun, 22 Mar 1998 16:23:59 -0700 Received: from thyme (207.233.170.5) by thyme.aspire.net (Worldmail 1.3.167) for usr-tc@lists.xmission.com; 22 Mar 1998 18:21:23 -0500 Message-Id: <3.0.2.32.19980322182123.0090e100@mailhost.aspire.net> X-Sender: ken%aspire.net@mailhost.aspire.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) In-Reply-To: <199803192249.PAA03173@slack.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-usr-tc@lists.xmission.com Precedence: bulk Reply-To: usr-tc@lists.xmission.com Thanks for using NetForward! http://www.netforward.com v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v The isp test account is active and available again for use by anyone that is an isp or network professional. You can telnet to: sage.aspire.net username: ispguest password: ispguest You can ping, traceroute, and send test mail messages. This account runs on an old Vax Station 3100 Model 38 running Vax VMS 6.2. Feel free to visit any time you need to do test pings, traceroutes, or emails. Suggestions, ideas, comments are always welcome. Ken :) - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 ************************************************************************ - 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. ------------=_890610342-21564-0--

At 01:48 PM 3/22/98 -0600, Scott wrote: >Standard RADIUS authentication from a UNIX box. >check it out I remmed the three lines out below, >now I'm not getting the error. But, I still >don't see why I'm getting the error when they are >not remmed out. I was looking in some of the >docs and they said PORT-LIMIT was not supported. >Maybe thats the problem. But how do you prevent users >from logging in twice?? Once again, Port-Limit is a multilink PPP setting. It prevents multiple channel bonding.. It is not meant to limit concurrent logins.. This feature would be a function of your RADIUS server and not the Netserver or HARC. As for errors, what errors are you seeing? All of the options shown below are supported on the NS & ARC. > >DEFAULT Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 255.255.255.254, > Framed-Netmask = 255.255.255.255, > Framed-Routing = None, > Framed-Compression = Van-Jacobsen-TCP-IP, > Framed-Filter-Id = "std.ppp.in", > Framed-MTU = 1500 ># Idle-Timeout = 1200, ># Session-Timeout = 28800, ># Port-Limit = 1 > Mike Wronski (mike@coredump.ae.usr.com) ! 3Com Network Systems Engineer / BETA Engineer <!> PGP: http://coredump.ae.usr.com/pgp !

Original message from Charles Hill: > >. . . no complaints here >except they don't work with TCM, but with a separate management software >like HARM. -CH > What is HARM? Website? Jas, Interpath Communications Data Network Technician Jas.Eckard@interpath.net

On Sun, Mar 22, 1998 at 12:22:30PM -0700, Greg Coffey wrote: > I got a copy of the v.90 code on Thursday and it connected just fine to our > rack. I connected before at 49999 almost every time and after the upgrade > to the courier, I connected at 52000. We are running 3.0.2 on the TC unit. A simple, related, question; should I have 'X2 Version 2 Modulation' enabled or disabled in TCM (running TCS 3.0.2)? At the moment, I have some quads enabled and some disabled, but I'm seeing no appreciable difference in performance. -- Phil Dye | Work: pmd@tcp.net.uk Network Manager | Play: phil@lart.ing.co.uk Total Connectivity Providers | Consider myself properly disclaimed "The nice thing about standards is that there are so many to choose from" -anon

>DEFAULT Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 255.255.255.254, > Framed-Netmask = 255.255.255.255, > Framed-Routing = None, > Framed-Compression = Van-Jacobsen-TCP-IP, > Framed-Filter-Id = "std.ppp.in", > Framed-MTU = 1500 ^^^ Not sure if this is what causing it, but there should be a comma on the end of the Framed-MTU line, and the Framed-Filter-Id should probably be std.ppp, unless you have std.ppp.in.in and std.ppp.in.out defined on the TC. ># Idle-Timeout = 1200, ># Session-Timeout = 28800, ># Port-Limit = 1 > > >> > Hi all. >> > >> > New to this list just setup our first TC rack.. Now, it seems >> > everyone is logging in ok but I'm getting the following critical >> > event whenever someone logs out. >> > >> > At 18:35:29, Facility "Call Initiation Process", Level "CRITICAL":: CIP: >> > User ca >> > ryn is not configured as dial out user. >> > Set the type to dial_out in the user record >> > >> How is the user caryn configured? >> >> krish >> >> > Any clues?? >> > >> > I don't have any users trying to dial out. >> > >> > Scott >> > >> > > > >- > 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. >

We're in the process of setting up some remote POP's and I was wondering if it would be possible for us to use the WAN ports on the TCH's as our routers for the Frame connections between the sites. Has anyone done this or is it even possible? -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

Has anyone used NFAS support on the TC chassis? Any gotcha I should know about? I'm connected to a GTD-5 switch. More headaches... Thanks! Tom

On Mon, 23 Mar 1998, Pete Ashdown wrote: > Andrew Aken said once upon a time: > > > >We're in the process of setting up some remote POP's and I was wondering > >if it would be possible for us to use the WAN ports on the TCH's as our > >routers for the Frame connections between the sites. Has anyone done > >this or is it even possible? > > Yes, it is possible, but I wouldn't recommend it. First you need USR's V35 > cable, which is difficult to obtain. Second, once you hook the Netserver > to the frame directly, you will never be able to upgrade the Netserver via > remote means again. I have this setup in one POP currently and I'm going > to put in a Cisco router instead. > Pete, Why can you not upgrade the netserver via remote means? I have a PoP set up that way already, and will be converting 2 others (they are now running the frame connection through a PM2eR). I haven't tried to upgrade the chassis remotely yet.

Andrew Aken said once upon a time: > >We're in the process of setting up some remote POP's and I was wondering >if it would be possible for us to use the WAN ports on the TCH's as our >routers for the Frame connections between the sites. Has anyone done >this or is it even possible? Yes, it is possible, but I wouldn't recommend it. First you need USR's V35 cable, which is difficult to obtain. Second, once you hook the Netserver to the frame directly, you will never be able to upgrade the Netserver via remote means again. I have this setup in one POP currently and I'm going to put in a Cisco router instead.

I am attempting to install a 48 TC rack with analog quad modems, and 3 COM says it won't work with the analog modems, they have to be A/D. (After three hours on the phone...) How can USR quad analog modems not work in a TC rack? Something about the bus and PRI, got this second hand from one of my techs. Best Regards; Dwight G. Jones Imagen Communications Inc. http://www.imagen.net Information Architects tm

> >We're in the process of setting up some remote POP's and I was wondering > >if it would be possible for us to use the WAN ports on the TCH's as our > >routers for the Frame connections between the sites. Has anyone done > >this or is it even possible? > > Yes, it is possible, but I wouldn't recommend it. First you need USR's V35 > cable, which is difficult to obtain. Second, once you hook the Netserver > to the frame directly, you will never be able to upgrade the Netserver via > remote means again. I have this setup in one POP currently and I'm going > to put in a Cisco router instead. Same here... We tried it, and later put a Cisco 2501 in its place. Although the cables were never hard to find... They are pretty standard from what I've seen - Cisco and 3COM both use the same. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Is anyone aware of how to fix the concurrency problem in the USR supplied Security and Accounting software ? The problem is that when you enable login tracking and have the # of allowed connections set to 1, after a certain amount of time RADIUS doesn't seem to get a disconnect message and shows a connection in the USERS table for userids which aren't logged onto a Netserver. Krish had told be this was fixed in version 5.X but after upgrading from 4.3 to 5.X last night, the problem is still occuring. I've had to shutoff login tracking again. I am runing version 3.6.28 code and the Security and Acounting Manager software version 5.11 with an Access 95 database. Thanks in advance, Jeff Binkley ASA Network Computing

Ok ... so I am no dummy when it comes to Radius Authentication and 3COM/USR TC products. I read the list, get several ARC's in, play with them for a few days and then ... put them in service - (2) ARCs and (6) HiperDSPs. Flawless install. 10 days later all is well, so we decided to fire some more up. Go over every detail to ensure a smooth cutover, busy out the old chassis' and when everyone is gone, boom! ... we make the cut. Phew .... all done. Success Success! <Queen's "We are the Champions" plays in the background> A few minutes later the first of many calls to these shiny new chassis' arrive. Not authenticated. Checked the authentication parameters, all looks fine. Cut and paste the secret and such again to ensure this is right. Still no go. So we jump over to the other arc in this chassis and same thing. Callers are not getting authenticated. Just to be sure I understand what is going on we get on the radius server and kill and restart radius in debug mode ... no pa ckets from the newly installed ARC's! What?? hiper2-arc2> sh authentication AUTHENTICATION SETTINGS Local Authentication is: ENABLED RADIUS Authentication is: ENABLED Hint Assigned is: DISABLED Primary Server is: 208.137.128.29 Primary Server Port is: 1645 Secondary Server is: 208.137.128.7 Secondary Server Port is: 1645 Retransmission Timeout: 3 Max Retranmissions: 10 hiper2-arc2> sh authentication counters AUTHENTICATION COUNTERS Local Successful Authentications: 1 Local Failed Authentications: 0 Remote Successful Authentications: 0 Remote Failed Authentications: 0 Remote No Responses: 0 ============== What is going on ?? What to do? I have checked and checked and 2 people went behind me and have done the same thing. Any ideas? Rad log files are not unhappy and the /etc/raddb/clients files are correct. ARG!! Running V4.0.69 of the ARC code. Marshall Morgan Confused! Internet Doorway, Inc. (aka NETDOOR) http://www.netdoor.com 601.969.1434 Ext. #28 | Fax 601.969.3838 | 800.952.1570 Ext. #28

Jeff, This happens to us too.. Although it seems to be much better after I set these traps to "enable log" on incoming call on outgoing call on incoming termination on outgoing termination on connection failure on connection timeout dial in call duration Good luck! Liping Chen Jeff Binkley wrote: > Is anyone aware of how to fix the concurrency problem in the USR supplied > Security and Accounting software ? The problem is that when you enable login > tracking and have the # of allowed connections set to 1, after a certain amount > of time RADIUS doesn't seem to get a disconnect message and shows a connection > in the USERS table for userids which aren't logged onto a Netserver. Krish had > told be this was fixed in version 5.X but after upgrading from 4.3 to 5.X last > night, the problem is still occuring. I've had to shutoff login tracking > again. I am runing version 3.6.28 code and the Security and Acounting Manager > software version 5.11 with an Access 95 database. > > Thanks in advance, > > Jeff Binkley > ASA Network Computing > > - > 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. -- Netsol Technologies 805 S. Lemon Ave. Walnut, CA 91789 (909) 869-6455 (909) 869-6459 fax Liping@netsol.net

Yay! I upgraded my external Courier to v.90, and now I only get 33.6 connects (I was getting 52,000 with x2). I even tried disabling v.90, but I still can't hit anything higher than v.34. I can hear the modems starting normal x2 handshaking, but then they start a re-handshake and drop back to v.34. We're running TCS 3.0.2 on 2059 bundles over PRI, FWIW. :> At 09:06 AM 3/22/98 -1000, you wrote: >To disable v.90 on Courier - S58.5=1 > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Curt Shambeau >> Sent: Sunday, March 22, 1998 8:26 AM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) V.90 for Couriers >> >> >> > Well, USR has released the V.90 code for Couriers, and after upgrading I >can >> > only connect with our Total Controls at 28.8. Before I got 48k+. It >almost >> > runs through 2 complete handshakes, one sounds like X2 (one boing), and >the > > >What version code do you have on the server modems?

That version of the os is hosed for lcp extensions ..... roll 'er back to 4.0.14 Ken :) At 11:06 PM 3/23/98 +0100, you wrote: > I never been able to get my US Robotics Netserver 16 modem pool to do > callback correct at all. This weekend 3Com released new code ( 4.1.7) for >it > so I was eager to try it out today. > Now I am getting it to work somewhat. If I _do not_ use Microsoft IAS >RADIUS > it will > actually call back, but I don't like the idea of getting rid of RADIUS just > because of this. > > What happens when I use IAS is that the WIN 95 / NT DUN ( dial up > networking) will connect and > then negotiate with IAS and give me an accept. A dialogue window will show > up telling me that the dialup number is "Administrator specified". I can > press CANCEL and will then not use callback or I can press OK. The computer > will hangup and ... then nothing... it wont call me back. > > In the NT Server I have configured User Manager to set Call Back "Set by > user". I wont get the chance to do this, all I get is the "Administrator > specified" choice when I dial up. If I use a preset number it is still the > same thing, nothing happens. > > So, here's the essential part: Here under you can see what my user profile > in IAS looks like. Can I change anything to be able to set the callback > number when connecting? Is there any Vendor specific setting (e.g USR) I >can > use? > > Successful authentication: Source = 10.0.0.155:1645 > Code = Access-Accept > Identifier = 18 > Framed-Compression = Van-Jacobsen-TCP-IP > Framed-IP-Address = 255.255.255.254 > Framed-IP-Netmask = 255.255.255.255 > Framed-MTU = 1514 > Framed-Protocol = PPP > Framed-Routing = None > Service-Type = Callback-Framed-User > > Has anyone been able to use US Robotics Netserver 16+ with code 4.1.7 > together with MS IAS and get a succesfull callback function? > >All help would be terrible appreciated... > > /Ronny Roe > Intranet / Internet developer > Micros Fidelio Sweden AB > >- > 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. > - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 telnet://sage.aspire.net Try our ISP/Net Guest account username: ispguest password: ispguest ************************************************************************

Thus spake Dwight G. Jones >I am attempting to install a 48 TC rack with analog quad modems, and 3 COM >says it won't work with the analog modems, they have to be A/D. (After three >hours on the phone...) >How can USR quad analog modems not work in a TC rack? Something about the >bus and PRI, got this second hand from one of my techs. The analog modems do not have the right circuitry to handle receiving calls off of the TDM bus. They are able to handle calls plugged into modem NIC cards with regular analog phone lines (rj-11). So, they do work with the chassis, just not to pull calls off of a T1 or PRI card. -- Jeff McAdams Email: jeffm@iglou.com Chief Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Dwight G. Jones was heard to say: >I am attempting to install a 48 TC rack with analog quad modems, and 3 COM >says it won't work with the analog modems, they have to be A/D. (After three >hours on the phone...) > >How can USR quad analog modems not work in a TC rack? Something about the >bus and PRI, got this second hand from one of my techs. They may lie about many things, but not this time... If you are trying to use Analog Quad Modems, then they need an analog phone line. They cannot take the priTdm digital traffic from the PRI card. That takes a Digital Quad Modem. There are also Analog/Digital Quads that work in either case. Note: they will work in the rack, but they need an analog back card for the analog phone line. --Ricky

One should be very careful about what they do on this account. If you were to telnet from this account, your keystrokes could be monitored/captured. You don't know who has been there before you! Butch Kemper At 17:21 -0600 on 3/22/98, Ken Hunter, Aspiring Technologies wrote: > The isp test account is active and available again for use by anyone that > is an isp or network professional. You can > > telnet to: sage.aspire.net > username: ispguest > password: ispguest > > You can ping, traceroute, and send test mail messages. > This account runs on an old Vax Station 3100 Model 38 running Vax VMS 6.2. > Feel free to visit any time you need to do test pings, traceroutes, or >emails. > Suggestions, ideas, comments are always welcome. > > > Ken :) > > - > ************************************************************************ > Web Hosting, E-mail addresses, DNS services, Dedicated circuits. > 33.6, X2(56k), ISDN Dialup available in Prince William County VA. > > Ken Hunter Aspiring Technologies > mailto:ken@aspire.net 9304 Troy Drive > http://www.aspire.net Nokesville, Va 20181 > ************************************************************************ > > - > 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. Butch Kemper | Free sound advice available Kemper & Associates Consulting Group | "95% sound and 5% advice" 409-361-2324 | Refunds cheerfully provided

At 21:47 -0600 on 3/23/98, A. Kelly Shaw wrote: > I know this is probably very simple to fix, but it sure is tough > for me. > > I just recently added 2 HIPER DSP cards to my TCH and increased > my IP pool size appropriately ( I thought) by the number of > channels that I am using on the card. However, I am still > getting the error > > IP pool out of addresses. > > Any ideas? Did you restart the server? Butch Butch Kemper | Free sound advice available Kemper & Associates Consulting Group | "95% sound and 5% advice" 409-361-2324 | Refunds cheerfully provided

The isp guest tester account now has an NSLOOKUP option in the menu. This was requested by a fellow isp'r - and makes pretty good sense - so here ya go. Ken :) - ************************************************************************ Web Hosting, E-mail addresses, DNS services, Dedicated circuits. 33.6, X2(56k), ISDN Dialup available in Prince William County VA. Ken Hunter Aspiring Technologies mailto:ken@aspire.net 9304 Troy Drive http://www.aspire.net Nokesville, Va 20181 telnet://sage.aspire.net Try our ISP/Net Guest account username: ispguest password: ispguest ************************************************************************

On Mon, 23 Mar 1998, Curt Shambeau wrote: > > >We're in the process of setting up some remote POP's and I was wondering > > >if it would be possible for us to use the WAN ports on the TCH's as our > > >routers for the Frame connections between the sites. Has anyone done > > >this or is it even possible? > > > > Yes, it is possible, but I wouldn't recommend it. First you need USR's V35 > > cable, which is difficult to obtain. Second, once you hook the Netserver > > to the frame directly, you will never be able to upgrade the Netserver via > > remote means again. I have this setup in one POP currently and I'm going > > to put in a Cisco router instead. > > Same here... We tried it, and later put a Cisco 2501 in its place. > Although the cables were never hard to find... They are pretty standard > from what I've seen - Cisco and 3COM both use the same. > I think there was a difference in the past, which perhaps was finally corrected for in the latest netserver release. Something about a single pin (dtr?) being different, or nonexistent. For a good while I tried to get it to work with the Cisco v35 cable, but 'show wan0' would always report 'CONNECTING' every so often and it would never establish. I havent tried it with the latest release -- can someone confirm any of this? - lv

I know this is probably very simple to fix, but it sure is tough for me. I just recently added 2 HIPER DSP cards to my TCH and increased my IP pool size appropriately ( I thought) by the number of channels that I am using on the card. However, I am still getting the error IP pool out of addresses. Any ideas? Kelly

I never been able to get my US Robotics Netserver 16 modem pool to do callback correct at all. This weekend 3Com released new code ( 4.1.7) for it so I was eager to try it out today. Now I am getting it to work somewhat. If I _do not_ use Microsoft IAS RADIUS it will actually call back, but I don't like the idea of getting rid of RADIUS just because of this. What happens when I use IAS is that the WIN 95 / NT DUN ( dial up networking) will connect and then negotiate with IAS and give me an accept. A dialogue window will show up telling me that the dialup number is "Administrator specified". I can press CANCEL and will then not use callback or I can press OK. The computer will hangup and ... then nothing... it wont call me back. In the NT Server I have configured User Manager to set Call Back "Set by user". I wont get the chance to do this, all I get is the "Administrator specified" choice when I dial up. If I use a preset number it is still the same thing, nothing happens. So, here's the essential part: Here under you can see what my user profile in IAS looks like. Can I change anything to be able to set the callback number when connecting? Is there any Vendor specific setting (e.g USR) I can use? Successful authentication: Source = 10.0.0.155:1645 Code = Access-Accept Identifier = 18 Framed-Compression = Van-Jacobsen-TCP-IP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1514 Framed-Protocol = PPP Framed-Routing = None Service-Type = Callback-Framed-User Has anyone been able to use US Robotics Netserver 16+ with code 4.1.7 together with MS IAS and get a succesfull callback function? All help would be terrible appreciated... /Ronny Roe Intranet / Internet developer Micros Fidelio Sweden AB

There was an interesting part in a posting in Microsofts newsgroup "microsoft.public.internet.radius" some week ago, regarding the possibility to use RADIUS logging if you have a USRobotics Netserver 16+ and wants to use Microsoft Internet Authentication Server (IAS RADIUS). >Here's what was done to get USR NET 8/16 authentication to work with >Microsoft's Radius. NOTE: With the current release of Netserver Plus code >(v4.0.13), accounting packets are not sent with a shared secret. MS Radius >software needs to use the same shared secret for authentication as >accounting.. this means right now users can authenticate but no logging... >with USR NET8/16 until USR comes out with a code fix for this.. So, this weekend, 3Com / USR released new code ( V4.1.7) for the Netserver. In the manual it states under Resolved Issues that "Clear text login is now sending accounting records to Radius server". If I get this right this means that I will now be able to do RADIUS logging with IAS and Netserver 16+. So the (hopefully) easy question is, how do I modify my RADIUS profile to enable logging? Right now it looks like this: Successful authentication: Source = 10.0.0.155:1645 Code = Access-Accept Identifier = 18 Framed-Compression = Van-Jacobsen-TCP-IP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1514 Framed-Protocol = PPP Framed-Routing = None Service-Type = Callback-Framed-User Any ideas what I should add to this profile to get it to work? Thanks a lot for any input or idea you might have... /Ronny Roe Intranet / Internet developer Micros Fidelio Sweden AB

I have set up a Netserver 16+ for my company to enable them to work at home as well as surf the Internet via the company's leased lines. Quite often my users experience lags, delays and slow responses when they use the Netserver connection. When they ping machines on the network they often get PING replies of >1000ms. Some of the more experienced users tell me that this is unacceptable and must be a misconfiguration. One of the reasons that they believe so is that I also have a couple of ordinary Sportster Flash modems connected to my NT Server, and when they use the RAS service there they don't have any trouble what so ever with lag or strange PING results. One of my users told me today that he opened a document in MS Word when he was connected via the NS16 and that Word timed out and crashed before he could finish saving it. That user had a Sportster Flash connected with 48Kbit/s... If anyone here could help me to point in which direction I should be looking for what is wrong I would be most helped. I don't have a clue myself. This only happens randomly, if the same user logs on the next day again it will work allright for a while. It seems to happen when they been connected for over an hour. Some details: I am using RADIUS (Microsoft IAS) to authenticate the users. My default profile looks like this: Successful authentication: Source = 10.0.0.155:1645 Code = Access-Accept Identifier = 18 Framed-Compression = Van-Jacobsen-TCP-IP Framed-IP-Address = 255.255.255.254 Framed-IP-Netmask = 255.255.255.255 Framed-MTU = 1514 Framed-Protocol = PPP Framed-Routing = None Service-Type = Callback-Framed-User I haven't done any other drastic configuration of the Netserver I guess. I have put the adress 10.0.0.1 as my default gateway because that is the firewall/router to the internet. There is a lot of things I could set I guess regarding RIP but I feel quite insecure about that so I have enabled support for RIP V2 (have to admit that I do not really know what is different from V1). Is there anything you could help me to have a look at? What would normally be the case of the NS16 giving slow response times and lags? All help or input appreciated... /Ronny Roe Intranet / Internet developer Micros Fidelio Sweden AB

argghhh. I setup a user on my TC and when I dialed in to test he was connected to another term server somewhere and I got a IP address conflict on my TC. I disconnected him from the other term server, and now we are still getting IP Address conflicts when he tries to log in. I know that this IP does not exist any where on my network! At 23:12:01, Facility "IP", Level "CRITICAL":: User mediat is configured for an existing IP network address (d006b800). Anyone seen this? Scott

On Tue, Mar 10, 1998 at 10:20:07AM +0300, Richard Bosire wrote: > Any pointers on what to hack in particular ??..... > Eric C Forcey wrote: > > Neither will do that. Radius is just that, an authentication server nothing > > more. Although I have heard that there are hacks to prevent multiple logins. Its not that hard to write a perl and expect nightmare that does cute things like: tell you the total port utilisation. punt duplicate logins and send them a mail warning (with exemptions too) do a cute little html page showing the state of affaires. warn you if a netserver melts (fails to respond in a timely fashion) A sample of the current output can be seen here: http://www.anime.org/~peter/demo/ note that detail pages are missing. 2000 lines of commented spagetti and 2 expect scripts. Typical runtime with 24 netservers, ~ 60 seconds (sequential) a work in progress. The next version will include a concept of licenses (ie, total number of simultaneous sessions per user) and possibly a "lart" button. Peter ----* -- O_u \\ Our routers contain the export \\ Connected to the Internet U \Beh! \\ controlled XOR flamingo encryption system! \\ at 27.5 bits!