February 1997

I'm new to the list and have had some difficulty getting subscribed, so I wanted to just drop a note to insure I was getting the list postings. Thanks, Timothy

my beta dsp software is not working can anyone send it to me.. thanks

I'm using the TCM software purchased from USR. It's version 4.1.1 and I'm using 3 TC chassis' with all analog/digital modems. I am able to remotely manage the chassis' and collect the *.con event files just fine. Is anyone that is using this software running a process against the log files that will produce a "PEAK simultaneous modem usage over the 24 hours of the log" type of report? If so, I'd appreciate being able to obtain a copy of the process. The idea is to obtain, on a daily basis, the highest number of modems that were in use at the same time so I can plan future expansion needs proactively rather than reactively ("hey, we got busy signals")... Thanks, Timothy

I have a bunch of TCs and I have noticed in my syslogs occasional entries indicated failed logins that end with a ppp_sync failed dest: Feb 1 21:51:21 tc2 MODEM: S18: CALL_REF >0x01040cc9< PRI_SLOT >0< TS >50< SPAN >0< B_CH >0< Feb 1 21:51:21 tc2 acct 18008 dial: S18 call arrived. Feb 1 21:51:21 tc2 sent out answer incoming call for S18. Feb 1 21:51:34 tc2 acct 18008 dial: S18 answered the phone using handle 14. Feb 1 21:51:37 tc2 acct 18008 dialnet: port S18 PPP succeeded dest Negotiated Feb 1 21:51:53 tc2 dialnet: port S18 ppp_sync failed dest Feb 1 21:51:54 tc2 acct 18008 dial: S18 hung up the phone. Call duration 0:0:33. Anyone know what causes this? Is it a PAP authentication failing? -- /// Marcus Needham /// marcus@theriver.com \\\ VP & Webmaster \\\ The River, Tucson AZ USA, http://www.theriver.com/

We have had the USR TC rack installed for a couple of weeks now, and it is working out prety well. We already had two portmasters, and are running a radius server on a sun station runing solaris. We have noticed two problems: 1] Dial-in lines on the TC do not timeout. It is as if the radius client does not honor the idle and session timeout values. 2] The usr-tc does not seem to generate the input and output octet counts in the accounting records. It is keeping track of them, as a "show all" displays non-zero values. Can anyone confirm or deny this? Will these features be in a future firmware upgrade? -- Stephen Corbesero What are we going to do tonight, Brain? flash@early.com The same thing we do every night, Pinky -- Re-Install Windows '95.

Once upon a time Stephen Corbesero shaped the electrons to say... > 1] Dial-in lines on the TC do not timeout. It is as if the radius > client does not honor the idle and session timeout values. AFAIK it doesn't. We added that in a release after 3.1.4 and I don't think USR has added it in their work. > 2] The usr-tc does not seem to generate the input and output octet > counts in the accounting records. It is keeping track of them, > as a "show all" displays non-zero values. We also added that to ComOS after 3.1.4 - again, I have not heard of USR adding this themselves. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

: The idea is to obtain, on a daily basis, the highest number of modems that : were in use at the same time so I can plan future expansion needs : proactively rather than reactively ("hey, we got busy signals")... I never had the time to put together a workable solution with SNMP at our shop, so I just do it with telnet and `show sessions' glued together with tcl/expect. The scripts telnet in, `show sessions' and page through the prompts, then I count and record the number of established connections from that list to a file, along with the current time. Dump that through gnuplot, and you've got a nice usage graph. (I'll put this code up for download if anybody wants it.) --- Mark R. Lindsey, mark@datasys.net DSS Online Network Engineer (912) 241-0607, Fax: 241-0190

I just installed some USR's with the dual T1 card. None of the modems are picking up though. Dealing with the phone company, its tough to find out if they are loopstart etc...Is there an easy way to tell? or an 'autoconfig'???? Bob _____________________________________________________________________ Bob D'Amato SNET 300 George St. New Haven, CT 06510 203-771-7081 http://www.quattro.org Drive Safe, Drive Fast, Drive a Quattro

On Sat, 1 Feb 1997 22:10:48 -0600 (CST), Timothy Deem <tdeem2@alpha.comsource.net> wrote: >I'm using the TCM software purchased from USR. It's version 4.1.1 and I'm >using 3 TC chassis' with all analog/digital modems. I am able to remotely >manage the chassis' and collect the *.con event files just fine. > > >Is anyone that is using this software running a process against the log >files that will produce a "PEAK simultaneous modem usage over the 24 hours >of the log" type of report? If so, I'd appreciate being able to obtain a >copy of the process. > >The idea is to obtain, on a daily basis, the highest number of modems that >were in use at the same time so I can plan future expansion needs >proactively rather than reactively ("hey, we got busy signals")... Take a look at http://vellocet.insync.net/tools/channels.html The fellow that wrote that is Steve Uurtamo, <uurtamo@insync.net> for his Ascend MAX log files. I'd just imagine the process could be easily ported to process most any log file. Insync makes this URL available for public viewing as one of their advertising gimmicks to compete with the "oversold capacity" folks (of which there are many here in Houston).

Howdy, We've two Netservers, one with the 3.1 firmware, and another with version 3.2 PRI capacity; we're using both for analog-modem service. Is there a setting to determine the assigned-address pool size? Whereas we have only 48 modems in each unit, they seem to be assigning 64 different addresses each. (I had already figured this out before we installed the second, so we don't have overlapping addresses or any such.) But it would be nice to reclaim those unneeded addresses; I haven't studied it, but the Netserver could be using an algorithm to assign the oldest-unassigned address, which would help if there's a chance that newly-dialed-in users could just step into the TCP connections of the previous user with that address. Thanks much. --- Mark R. Lindsey, mark@datasys.net DSS Online Network Engineer (912) 241-0607, Fax: 241-0190

Hadn't seen any messages, just checking to insure I'm still here... Thanks!

Timothy Deem said once upon a time: > > >Hadn't seen any messages, just checking to insure I'm still here... ACK

In response to Mark's query, you can set the pool size with: help set limit Limits the size of assigned IP addresses pool [1-%d] Usage: set limit <desired Assigned IP Address Pool size> This is on version 3.3.28, which I noticed is higher than what you've got, so you'll probably want to update anyway. There are a lot of new features. However, you may want to evaluate your routing since the closest IP subnet size to 48 is 64. Trim it down and you'll either need to deal with more subnets or host routes. -- Pete XMission

On 3.3.28, "help set net0" reveals: Ethernet Interface Parameters ripv2 - Set the Internet Address broadcast- Set the broadcast ripv2 disabled - Disable ethernet interface enabled - Enable ethernet interface ifilter - Set the input filter ipxframe - Set IPX Frame Type ipxnet - Set the IPX Network Number netmask - Set the ethernet netmask ofilter - Set the output filter network - Set the network options Usage: set net0 option value However, "set net0 ripv2" reveals: Invalid net0 option This makes RIPv2 rather useless. Is there a newer version that works? -- Pete XMission

MegaZone <megazone@livingston.com> writes: > Once upon a time Stephen Corbesero shaped the electrons to say... > > 1] Dial-in lines on the TC do not timeout. It is as if the radius > > client does not honor the idle and session timeout values. > AFAIK it doesn't. We added that in a release after 3.1.4 and I don't > think USR has added it in their work. The Idle-Timeout parameter has worked for me since NETServer 3.2.x. The documentation for NETServer 3.3.x indicates that Session-Timeout is also supported as of that release, although I haven't personally used it myself. > > 2] The usr-tc does not seem to generate the input and output octet > > counts in the accounting records. It is keeping track of them, > > as a "show all" displays non-zero values. > > We also added that to ComOS after 3.1.4 - again, I have not heard of USR > adding this themselves. It's also supported as of NETServer 3.3.x. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Pete Ashdown <pashdown@xmission.com> writes: > On 3.3.28, "help set net0" reveals: > > Ethernet Interface Parameters > ------------------------------------ > ripv2 - Set the Internet Address > broadcast- Set the broadcast ripv2 (...) > However, "set net0 ripv2" reveals: > > Invalid net0 option > > This makes RIPv2 rather useless. Is there a newer version that works? Looks like a typo in the help table. The first option is supposed to say "destination" not "ripv2". The description (Set the Internet Address) is for the destination option of set net0. Under 3.3.3 (the 4MB version) it looks like it's correct. Actually, it looks like the word destination got replaced with ripv2 in general, since the help for "broadcast" should say "Set the broadcast destination". RIPv2 is a global configuration option, which you should be able to control with "set ripv2 on" or "set ripv2 off", although its current status does show up on a "show net0" output screen. It's like the "set routing on/off" setting. You can also use "set ripv2 authentic <password>" to configure the password to embed in each RIP packet, and "show global" reflect if RIPv2 authentication is configured. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Marcus Needham <marcus@theriver.com> writes: > I have a bunch of TCs and I have noticed in my syslogs occasional > entries indicated failed logins that end with a ppp_sync failed dest: (...) > Feb 1 21:51:37 tc2 acct 18008 dialnet: port S18 PPP succeeded dest Negotiated > Feb 1 21:51:53 tc2 dialnet: port S18 ppp_sync failed dest (...) > Anyone know what causes this? Is it a PAP authentication > failing? Yes, or I believe a CHAP failure may cause this as well. The previous log that shows "dest Negotiated" is an indication that the NETServer autodetected a PPP frame at the login prompt, which is then either a PAP or CHAP authentication. If that fails you get the ppp_sync message. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

I reread the discussion from January on the US West A->D D->A problems, and I don't think this applies to the current problem I'm having. I have a newly installed advanced DSS circuit for a Total Control with a Dual T1 interface. There are 24 quad-digital modems installed. For some dial-in users, everything is working great. They get >28K every time. However, for some, even those using USR products, and myself who is dialing the POP long distance, a strange thing happens. About 1/4 connection attempts result in a >28K connection. The other three either don't connect at all, or connect at 1200 baud. I read about the possibility of bit-stuffed signaling stomping on the data at USR's web site. Could this be my problem? USR mentioned no solution for that. If it is my problem, I'd think that I'd never be able to connect at >28K, instead of 1 out of 4. I've ruled out bad modem cards, since it seems to be distributed through the pool. I haven't checked the revision on the quads yet though, I have yet to get my authorization for downloading the software from USR. It seems almost as if I've got some small setting on the T1 card that doesn't jive with US West, although the formatting (ESF,B8ZS) matches. -- Pete XMission

The quad card rev level may be important. We had awful connects with the rev that came with the cards, then we flashed them to newer code and all was well (or as well as it gets in US West land!). On Tuesday, February 04, 1997 8:47 PM, Pete Ashdown wrote: > I reread the discussion from January on the US West A->D D->A problems, and I > don't think this applies to the current problem I'm having. > > I have a newly installed advanced DSS circuit for a Total Control with a Dual > T1 interface. There are 24 quad-digital modems installed. > > For some dial-in users, everything is working great. They get >28K every > time. However, for some, even those using USR products, and myself who is > dialing the POP long distance, a strange thing happens. About 1/4 connection > attempts result in a >28K connection. The other three either don't connect at > all, or connect at 1200 baud. > > I read about the possibility of bit-stuffed signaling stomping on the data at > USR's web site. Could this be my problem? USR mentioned no solution for > that. If it is my problem, I'd think that I'd never be able to connect at > >28K, instead of 1 out of 4. I've ruled out bad modem cards, since it seems > to be distributed through the pool. I haven't checked the revision on the > quads yet though, I have yet to get my authorization for downloading the > software from USR. It seems almost as if I've got some small setting on the > T1 card that doesn't jive with US West, although the formatting (ESF,B8ZS) > matches. > > -- > Pete > XMission > -- /// Marcus Needham /// marcus@theriver.com \\\ VP & Webmaster \\\ The River, Tucson AZ USA, http://www.theriver.com/

wdg@hal-pc.org said once upon a time: >Assuming the "problem" only occurs on LD calls suggests a strong >likelihood of clocking problem at USW with the LD provider.=20 The problem happens with local calls as well. >Since you didn't mention, I'll ask; What's at USW on their end of >your T1? Is there a channel bank ahead of the switching machine or is >the T1 'digitally integrated' direct into the switch module? Knowing >USW's penchant for pricing trunk-side integrated T1 interfaces beyond >reasonable reach, you're either paying alot for this T1 or there's a >channel bank in it at the CO end. It is straight digital into the switch. I verified this with the CO people. It really wasn't all that pricey when you make the lines in-dial only.

On Tue, 4 Feb 1997 20:47:35 -0700 (MST), Pete Ashdown <pashdown@xmission.com> wrote: >I reread the discussion from January on the US West A->D D->A problems, = and I >don't think this applies to the current problem I'm having. >I have a newly installed advanced DSS circuit for a Total Control with a= Dual >T1 interface. There are 24 quad-digital modems installed. >For some dial-in users, everything is working great. They get >28K = every >time. However, for some, even those using USR products, and myself who = is >dialing the POP long distance, a strange thing happens. About 1/4 = connection >attempts result in a >28K connection. The other three either don't = connect at >all, or connect at 1200 baud. >I read about the possibility of bit-stuffed signaling stomping on the = data at >USR's web site. Could this be my problem? No. This would result in only a =3Dslightly=3D diminished connect speed, ie 26.4, not the symptoms you describe. Assuming the "problem" only occurs on LD calls suggests a strong likelihood of clocking problem at USW with the LD provider.=20 Suggest you try the alternate carrier access codes (AT&T 10288, MCI 10222, SPRINT 10333, etc) and see if you can isolate this anomaly=20 to one specific carrier. If you can, then the problem is with that LD carrier. If the problems shows up equally with all the carriers then the problem is likely at USW's central office where your T1 comes from. Since you didn't mention, I'll ask; What's at USW on their end of your T1? Is there a channel bank ahead of the switching machine or is the T1 'digitally integrated' direct into the switch module? Knowing USW's penchant for pricing trunk-side integrated T1 interfaces beyond reasonable reach, you're either paying alot for this T1 or there's a channel bank in it at the CO end.

We're having a problem setting up a 3Com OfficeConnect 510u ISDN router with a USR TC. the 3Com has pre-configured modes only for the "usual suspects" (cisco, ascend, 3com, etc.) and nothing for the TC. we've got the TC to automatically assign an IP to the 3Com, but the 3Com doesn't update it's routing tables correctly. if anyone has done this successfully (both MPPP & no MPPP) and could let me know what their settings are on both sides that would be great! then we could let 3Com know too. ;) thanks. pete@ebay.com

I really like running faster then 28.8/33.6... The 56k is almost like ISDN.... Sure a tiny tiny lag.. but think I don't have to pay for megs I download.. like ISDN...

> And since we've broached the subject, how do we price it (56k) > compared to ISDN? If we're charging our ISDN (1B/64k) callers a > bandwidth premium over std. 28.8 dialups (as several are), shouldn't > the same bandwidth premium (or nearly the same premium) be applied to > 56k? If not, why not?? > I don't see how we can. For the ISDN customer they are getting a digital connection which is more true to the 64k it boasts, whereas the 56k customer is still getting an asych connection which still has the greater overhead and therefor less than true 56k (for example as compared to a true 56k digital circuit). The ISDN customer is still getting a connection that is of higher bandwidth and reliability, so the costing is justified. The real question to ask is whether or not a 56k analog customer should pay more than a 33.6 (and down) analog customer....? Using the above argument I could justify it, but I don't think it would be accepted... Timothy

On Sun, 09 Feb 1997 23:58:47 -0600, MIS Operations <hudgens@citizensbnk.com> wrote: >I really like running faster then 28.8/33.6... The 56k is almost like >ISDN.... Sure a tiny tiny lag.. but think I don't have to pay for megs I >download.. like ISDN... But from what I've seen 56k (X2)requires nearly ISDN-quality lines and even then you don't get full 56k, more like something down in the mid 40's. I have ISDN; This "56k"(X2), albeit less expensive from a phone line standpoint, doesn't begin to measure up to real-McCoy ISDN and doesn't seem worth the hassle. It will be interesting to see what the masses think of it when it's released. And since we've broached the subject, how do we price it (56k) compared to ISDN? If we're charging our ISDN (1B/64k) callers a bandwidth premium over std. 28.8 dialups (as several are), shouldn't the same bandwidth premium (or nearly the same premium) be applied to 56k? If not, why not??

All USWorst has told me about my DSS circuit is that it is ESF/B8ZS. How important are these other settings, and where can I find documentation on them? Jitter Attenuation Transmitter Attenuation Dial-in Address Dial-in/Dial-out Trunk Signaling Acknowledgement Wink Delay Sending Address Info Stuffed Byte Sent to Telco Dial-in/Dial-out Trunk Type Idle Byte Pattern -- Pete XMission

What is a good value for the transmitter db level on the digital quad cards? I was using the default of 11 for a while, and found that I got better connects when I bumped it up to 20. Is there a danger in going too high? -- Pete XMission

Bob D'Amato said once upon a time: >I was told (By USR) to use a lower level if feeding the box with T1's. I >was told to lower it to 9db. I cant say Ive noticed any difference though. >What do you mean you have "better connects" @ 20db? Well, less of the weird 1200 baud connects. The whole test had psychological influences I'm sure. ;-) I'll try 9db and see where that gets me.

On Wed, 12 Feb 1997, Pete Ashdown wrote: > What is a good value for the transmitter db level on the digital quad cards? > I was using the default of 11 for a while, and found that I got better > connects when I bumped it up to 20. Is there a danger in going too high? > I was told (By USR) to use a lower level if feeding the box with T1's. I was told to lower it to 9db. I cant say Ive noticed any difference though. What do you mean you have "better connects" @ 20db? THanks! Bob _____________________________________________________________________ Bob D'Amato SNET 300 George St. New Haven, CT 06510 203-771-7081 http://www.quattro.org Drive Safe, Drive Fast, Drive a Quattro

On Wed, 12 Feb 1997, Pete Ashdown wrote: > What is a good value for the transmitter db level on the digital quad cards? > I was using the default of 11 for a while, and found that I got better > connects when I bumped it up to 20. Is there a danger in going too high? > I was told (By USR) to use a lower level if feeding the box with T1's. I was told to lower it to 9db. I cant say Ive noticed any difference though. What do you mean you have "better connects" @ 20db? THanks! Bob _____________________________________________________________________ Bob D'Amato SNET 300 George St. New Haven, CT 06510 203-771-7081 http://www.quattro.org Drive Safe, Drive Fast, Drive a Quattro

------ =_NextPart_000_01BC18E8.96B11C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have an application that is wireless and 1200 baud. What setting = would anyone recommend? I have 1 T-1 into quad digital modems. All = connections will be 1200 or 300.

On Wednesday, February 12, 1997 2:37 PM, David Bolen wrote: > > What is a good value for the transmitter db level on the digital quad cards? > > I was using the default of 11 for a while, and found that I got better > > I believe the recommended value for cards communicating digitally is > -13db (the transmit level set to "13"), at least that's what I've been > using for some time now. I actually thought the digital cards > defaulted to that value, but since I manually set it for any new card > installation I can't say for sure, and the dual cards probably default > to the analog values. All my digital quads came set to 11 as their default (for [line-side] channelized-Ts). Maybe I will try 13. We do get occasional reports of negotiation problems... Can this be changed while the cards are in use? -- /// Marcus Needham /// marcus@theriver.com \\\ VP & Webmaster \\\ The River, Tucson AZ USA, http://www.theriver.com/

Marcus Needham said once upon a time: >All my digital quads came set to 11 as their default (for [line-side] >channelized-Ts). Maybe I will try 13. We do get occasional reports of >negotiation problems... > >Can this be changed while the cards are in use? No, you'll get an SNMP error from TCM if you try.

> What is a good value for the transmitter db level on the digital quad cards? > I was using the default of 11 for a while, and found that I got better I believe the recommended value for cards communicating digitally is -13db (the transmit level set to "13"), at least that's what I've been using for some time now. I actually thought the digital cards defaulted to that value, but since I manually set it for any new card installation I can't say for sure, and the dual cards probably default to the analog values. The -11db value is best for analog (using the POTS line). You want the signal a bit weaker on a digital path since the path itself is better, and a signal that is too "hot" can cause a problem for training. > connects when I bumped it up to 20. Is there a danger in going too high? The transmit level is an attenuation (-db), so going up actually makes the signal weaker, not stronger. I think there is some internal boundary, so I don't actually think you're value of 20 is truly using -20db, but I'm not positive. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

> Well, less of the weird 1200 baud connects. The whole test had psychological > influences I'm sure. ;-) I'll try 9db and see where that gets me. I'm a little surprised that such a high setting would have been recommended for for a digital path. At least given some of the current tests I have been involved with, I've been led to believe that such a level might exceed FCC regulations for signal strength. Of course, it is true that sending such a "hot" signal can help break through various levels of interference (as it provides a better signal to noise ratio) than a weaker signal might do - but at the same time a too hot signal can actually hurt your connection rates. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Pete Ashdown said; > >What is a good value for the transmitter db level on the digital quad cards? I was advised by USR to increase it to 13, which seems to work for me (bear in mind this is PRI, not T1). >I was using the default of 11 for a while, and found that I got better >connects when I bumped it up to 20. Is there a danger in going too high? I guess you can overdo it, and it will start clipping. On the other hand, we're talking about digital, so can it clip? -- Phil Dye | Work: pmd@tcp.net.uk Network Manager | Play: phil@lart.ing.co.uk Total Connectivity Providers | Consider myself properly disclaimed "There are many ways to skin a cat. Currently, we are all eating fur"

On my TC hubs, Im using the default IP address of 192.77.203.65 so I can SLIP into the back of the boxes, with the ethernet port (UTP) having our local network address. I have many TC chassis, and therefore many ethernet addresses associated with them. Each one still has the 192 address still associated with the SLIP port though. Our management stations are complaining that I have duplicate IP addresses, from these modems. I KNOW that each ethernet port is unique. What appears to be happening, is that through the ethernet port, it is advertising the SLIP address, and showing up as duplicates. How can I prevent this routing? If I go into TCM, I click on the enet card, go to UI settings and turn off LAN to WAN routing. THis doesnt seem to make a difference. That is all I did though, do I have to reset them afterword? Also...some of my hardware isnt as up to date, and I dont have that option to turn off routing in TCM. How would I do it in these cases? Sometime I cant get to some of the chassis either, and the NIC card needs to be reset manually on site. ANyone else experience this? Is there a cure? Thanks all. Bob _____________________________________________________________________ Bob D'Amato SNET 300 George St. New Haven, CT 06510 203-771-7081 http://www.quattro.org Drive Safe, Drive Fast, Drive a Quattro

Bob D'Amato said once upon a time: >On my TC hubs, Im using the default IP address of 192.77.203.65 so I can >SLIP into the back of the boxes, with the ethernet port (UTP) having our >local network address. I have many TC chassis, and therefore many >ethernet addresses associated with them. Each one still has the 192 >address still associated with the SLIP port though. >Our management stations are complaining that I have duplicate IP >addresses, from these modems. I KNOW that each ethernet port is unique. >What appears to be happening, is that through the ethernet port, it is >advertising the SLIP address, and showing up as duplicates. > >How can I prevent this routing? If I go into TCM, I click on the enet >card, go to UI settings and turn off LAN to WAN routing. THis doesnt seem >to make a difference. That is all I did though, do I have to reset them >afterword? The TC's don't do any sort of proxying or address translation. So using the same IP pool for all of them is going cause you problems. What I would suggest if you don't have enough NIC allocated address space is to use reserved IPs, then proxy them at your gateway(s). I can never remember what is the exact block for internal addresses (192.0.0.0?), so someone else will need to fill in here. Of course, using real addresses makes life a whole lot easier. >Also...some of my hardware isnt as up to date, and I dont have that >option to turn off routing in TCM. How would I do it in these cases? Your network will still need to know how to get to the SLIP client. >Sometime I cant get to some of the chassis either, and the NIC card needs >to be reset manually on site. ANyone else experience this? Is there a cure? I had this happen after I upgraded on of our remote TC's. I was able to dial in and login as !root to fix the addressing. Can you do that?

Bob D'Amato said once upon a time: >I assume you mean you have a modem on your SLIP port...I do not.. :( Only >through the LAN. I may change this now... >The boxes, arent 'telnet'able are they?? No, this was a connection made through the T1 NIC to the Quad modems. The netserver card is telnetable if you configure it properly.

On Thu, 13 Feb 1997, Pete Ashdown wrote: > > The TC's don't do any sort of proxying or address translation. So using the > same IP pool for all of them is going cause you problems. Hmm... Well, I see what you're saying (I think) I dont have more that one TC per subnet. We do weird subnetting (our mask is 255.255.255.192) Go figure! Anyway..I dont have more than one TC per subnet. But I have a lot of subnets. The only address in common with all these is the OE 192.77.203.65 so I can slip in (Directly with my PC) I dont have a dialup slip access to them. Then I use TCM over the LAN. > > What I would suggest if you don't have enough NIC allocated address space is > to use reserved IPs, then proxy them at your gateway(s). I can never remember > what is the exact block for internal addresses (192.0.0.0?), so someone else > will need to fill in here. Of course, using real addresses makes life a whole > lot easier. > Good idea, Ill just make that address unique. It would be much easier. > >Also...some of my hardware isnt as up to date, and I dont have that > >Sometime I cant get to some of the chassis either, and the NIC card needs > >to be reset manually on site. ANyone else experience this? Is there a cure? > > I had this happen after I upgraded on of our remote TC's. I was able to dial > in and login as !root to fix the addressing. Can you do that? > I assume you mean you have a modem on your SLIP port...I do not.. :( Only through the LAN. I may change this now... The boxes, arent 'telnet'able are they?? Thanks for the help. Bob _____________________________________________________________________ Bob D'Amato SNET 300 George St. New Haven, CT 06510 203-771-7081 http://www.quattro.org Drive Safe, Drive Fast, Drive a Quattro

On Thu, 13 Feb 1997, Pete Ashdown wrote: > Bob D'Amato said once upon a time: > > >I assume you mean you have a modem on your SLIP port...I do not.. :( Only > >through the LAN. I may change this now... > >The boxes, arent 'telnet'able are they?? > > No, this was a connection made through the T1 NIC to the Quad modems. The > netserver card is telnetable if you configure it properly. > OH oh oh oh...OK. No netserver card either...Using a Bay Networks 5390. _____________________________________________________________________ Bob D'Amato SNET 300 George St. New Haven, CT 06510 203-771-7081 http://www.quattro.org Drive Safe, Drive Fast, Drive a Quattro

Does the USR TCE support unnumbered links and if so what are the setup parameters for that? I'm trying to get a 3Com OfficeConnect ISDN router to connect to a TCE hub and been having some problems. If anyone has any advice that would be great. pete@ebay.com

Some of you may recall that I had a problem with an all digital TC, connected to all digital US West DSS services. After a couple weeks of searching for a capable USW tech, we tracked it down. The equipment in question was connected to a 5E (5ESS?) switch. Another TC with the exact same configuration was connected to a DMS-100 and was having no problems at all. What it turned out to be is that the TC was configured (by default) to accept 0 digits in its DNIS configuration. US West by default sends 4. The 5E switch is more sensitive to this fact than the DMS-100. Whereas the DMS-100 didn't seem to care that I did an immediate pickup, the 5E had all sorts of problems. Anything from no connect, to 1200 baud bad connects. Setting the TC to accept 4 digits fixed everything. Just to be safe, I did the same for the other box on the DMS-100. -- Pete XMission

It looks as if MPPP works very well with 3.3.28. The question is, how do I restrict it? Since making RADIUS restrict multiple dialins doesn't work all that well, is there any sort of RADIUS flag sent from the TC to state an additial PPP channel is trying to bond? -- Pete XMission

On Tuesday, February 25, 1997 3:40 PM, Pete Ashdown wrote: > It looks as if MPPP works very well with 3.3.28. The question is, how do I > restrict it? Since making RADIUS restrict multiple dialins doesn't work > all that well, is there any sort of RADIUS flag sent from the TC to state > an additial PPP channel is trying to bond? Strictly speaking RADIUS is a stateless protocol, and has never addressed the issue of multiple logins. Some RADIUS server implementors have tried to do it though, with, as you say, mixed results. I do not have a PRI into a TC, but I know that on my ISDN Portmaster each channel is accounted for entirely seperately, so looks just like second concurrent login. We do not block it--we simply charge $1/hour usage fee for using a second channel if you have a single channel account. -- /// Marcus Needham /// marcus@theriver.com \\\ VP & Webmaster \\\ The River, Tucson AZ USA, http://www.theriver.com/

Pete Ashdown <pashdown@xmission.com> writes: > It looks as if MPPP works very well with 3.3.28. The question is, how do I > restrict it? Since making RADIUS restrict multiple dialins doesn't work > all that well, is there any sort of RADIUS flag sent from the TC to state > an additial PPP channel is trying to bond? There is an accounting attribute (Acct-Multi-Session-Id) that is used in records relevant to a MLPPP session to correlate different records. I haven't verified this recently, but I believe that as of NETServer 3.3.x in addition to accounting packets you should also see this attribute show up in any RADIUS request packets for the MLPPP session, so you could use that to decide if you wanted to allow the authentication or not. You'd probably need to add some special support to the RADIUS server to check for that attribute as the gating factor for the authentication. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

At 6:59 -0600 on 2/26/97, wdg@hal-pc.org wrote: > On Tue, 25 Feb 1997 21:29:09 -0000, Marcus Needham > <marcus@theriver.com> wrote: > > >I do not have a PRI into a TC, but I know that on my ISDN Portmaster each > >channel is accounted for entirely seperately, so looks just like > >second concurrent login. We do not block it--we simply charge $1/hour > >usage fee for using a second channel if you have a single channel account. The Livingston PortMaster supports the Radius return field "Port-Limit" to control how many channels the user is allowed to establish. When this field is omitted or set to "2", the user can have two channels. If it is set to "1", they only get one channel. Butch Butch Kemper | Free sound advice available Brazos Internet Consulting Group | "95% sound and 5% advice" 409-696-6057 | Refunds cheerfully provided

On Wednesday, February 26, 1997 5:59 AM, wdg@hal-pc.org wrote: > On Tue, 25 Feb 1997 21:29:09 -0000, Marcus Needham > <marcus@theriver.com> wrote: > > >Strictly speaking RADIUS is a stateless protocol, and has never addressed the > >issue of multiple logins. Some RADIUS server implementors have tried to > >do it though, with, as you say, mixed results. > > > >I do not have a PRI into a TC, but I know that on my ISDN Portmaster each > >channel is accounted for entirely seperately, so looks just like > >second concurrent login. We do not block it--we simply charge $1/hour > >usage fee for using a second channel if you have a single channel account. > > A buck an hour additional over the subscribed rate for 2b vs 1b seems > fair enough, but what sort of an accounting hassle does tracking this > create for the billing dept? Its designed into our billing system. We also charge $1/hour for concurrent use of regular analog lines by what should be a single user account, and for use of ISDN by a regular analog account holder.

Marcus Needham said once upon a time: >Strictly speaking RADIUS is a stateless protocol, and has never addressed the >issue of multiple logins. Some RADIUS server implementors have tried to >do it though, with, as you say, mixed results. State is not necessary though. Doesn't the server send any sort of indication that this is a MPPP session, vs a PPP session?

Recently we noticed that two different Netserver cards which have been running the same version of the firmware for around a year now had crashed on different days but at similar times and with the same result, in that the netserver card rebooted and then stopped communicating with the modems. Although when the cards were reset (via a reboot command) they worked fine. What I was wondering was were there any issues with the USR netserver cards and the so called Ping O Death? Does any one have any pointers other than the standard Ping O Death pages which don't seem to mention the USR kit? Thanks in advance. K. Brooks. -- | Kevin Brooks - Senior Systems Engineer Email : Kevin.Brooks@onyx.net | | You don't have to be serious you don't have to be a walrus, | | Lazy Bone, Shonen Knife | | For more information about Octacon Ltd look at http://www.onyx.net | |Octacon LTD,Zetland Buildings,Exchange Square,Middlesbrough,TS1 1DE.ENGLAND.| | Tel:+44(0)1642 216200 Direct Tel:+44(0)1642 216231 Fax:+44(0)1642 216201 |

On Tue, 25 Feb 1997 21:29:09 -0000, Marcus Needham <marcus@theriver.com> wrote: >Strictly speaking RADIUS is a stateless protocol, and has never = addressed the=20 >issue of multiple logins. Some RADIUS server implementors have tried to= =20 >do it though, with, as you say, mixed results. > >I do not have a PRI into a TC, but I know that on my ISDN Portmaster = each >channel is accounted for entirely seperately, so looks just like=20 >second concurrent login. We do not block it--we simply charge $1/hour >usage fee for using a second channel if you have a single channel = account. A buck an hour additional over the subscribed rate for 2b vs 1b seems=20 fair enough, but what sort of an accounting hassle does tracking this create for the billing dept?

Once upon a time Bill Garfield shaped the electrons to say... >CHICAGO (AP) -- 3Com Corp., a maker of computer networking products, >is buying modem maker U.S. Robotics for $6.6 billion as the two seek >to become a leader in the business of connecting computers. Ok, the big question on my mind... 3Com has loudly supported K56flex and have committed to using it in their remote access products. So, what's going to happen with X2/K56flex? -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

CHICAGO (AP) -- 3Com Corp., a maker of computer networking products, is buying modem maker U.S. Robotics for $6.6 billion as the two seek to become a leader in the business of connecting computers. The deal, announced Wednesday, will create a high-tech company with $5 billion in annual revenue and more than 12,000 employees. ``The combination of 3Com and U.S. Robotics dramatically alters the networking landscape,'' Eric Benhamou, 3Com's chairman and chief executive, said in a statement. Computer networking involves the linking of groups of machines, often within a single company, to allow employees to work together even if they are several hundred miles apart. It is one of the fastest-growing areas in the computer business today. 3Com will acquire U.S. Robotics for its own stock, giving Robotics shareholders 1.75 shares of 3Com for each share they hold. The works out to $6.6 billion as Wednesday's close. The combined company will retain the 3Com name and Benhamou will remain chairman and CEO. 3Com and U.S. Robotics together will be able to provide customers with the hardware necessary to create networks, including interface cards that allow computers to understand each other to high-speed modems. Casey Cowell, chairman and chief executive of U.S. Robotics, said the combination will allow the new company to sell its products to a variety of customers including big and small corporations, telephone carriers, network and Internet service providers, and consumers. The news took Wall Street by surprise. In fact, 3Com shares have fallen by almost 50 percent in the past month amid concerns about general weakness in the networking sector that have also weighed on U.S. Robotics' stock. 3Com shares closed at $39, down 12� cents on the Nasdaq Stock Market. U.S. Robotics was off 50 cents at $61 in Nasdaq trading. Cowell will become vice chairman of 3Com after the deal is completed, which is expected this summer. The companies said there would be an unspecified charge against earnings to account for the deal in the quarter in which it is completed. Home | US News | World News | Business | Sports | Index | Search | Help <Picture> Copyright 1997 Associated Press. All rights reserved. This material may not be published, bro adcast, rewritten or redistributed. Send comments and questions about The WIRE to feedback@ap.org.

On Wed, 26 Feb 1997 21:03:04 -0800 (PST), MegaZone <megazone@livingston.com> wrote: >Once upon a time Bill Garfield shaped the electrons to say... >>CHICAGO (AP) -- 3Com Corp., a maker of computer networking products, >>is buying modem maker U.S. Robotics for $6.6 billion as the two seek >>to become a leader in the business of connecting computers.=20 > >Ok, the big question on my mind... > >3Com has loudly supported K56flex and have committed to using it in = their >remote access products. > >So, what's going to happen with X2/K56flex? Geez, maybe as before "Veedot Everything" could take on a whole new meaning. <g>

Has anyone heard anything about when X2 is going to be released for the TC? What genius at USR decided it would be better to release the standalone modem code before the TC code? What good is the modem code if your provider hasn't got the TC code? -- Pete XMission

> > Has anyone heard anything about when X2 is going to be released for the TC? > > What genius at USR decided it would be better to release the standalone > modem code before the TC code? What good is the modem code if your > provider hasn't got the TC code? > > -- > Pete > XMission I heard that AOL and Compu$seve are getting the code a week before everyone else, so it must be a marketing decision... Bill -- bill@xmission.com http://www.xmission.com/~bill/ "I wish people who have trouble communicating would just shut up." ---Tom Lehrer

It was done to satisfy AOL and Mindspring, who are presently offering X2 in several areas. << Forsan et haec olim meminisse iuvabit. >> -----Original Message----- Sent: Friday, February 28, 1997 4:46 PM Sender: owner-usr-tc@xmission.com Reply-to: usr-tc@xmission.com Has anyone heard anything about when X2 is going to be released for the TC? What genius at USR decided it would be better to release the standalone modem code before the TC code? What good is the modem code if your provider hasn't got the TC code? -- Pete XMission ----------------------- Headers -------------------------------- From usr-tc-owner@xmission.com Fri Feb 28 16:45:24 1997 Return-Path: usr-tc-owner@xmission.com Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by emin43.mail.aol.com (8.6.12/8.6.12) with ESMTP id QAA03183; Fri, 28 Feb 1997 16:45:20 -0500 Received: from localhost (daemon@localhost) by mail.xmission.com (8.8.5/8.7.5) with SMTP id OAA28272; Fri, 28 Feb 1997 14:34:33 -0700 (MST) Received: by mail.xmission.com (bulk_mailer v1.5); Fri, 28 Feb 1997 14:34:32 -0700 Received: (from daemon@localhost) by mail.xmission.com (8.8.5/8.7.5) id OAA28224 for usr-tc-goout; Fri, 28 Feb 1997 14:34:16 -0700 (MST) Received: from slack.xmission.com (pashdown@slack.xmission.com [199.104.120.18]) by mail.xmission.com (8.8.5/8.7.5) with ESMTP id OAA28153 for <usr-tc@mail.xmission.com>; Fri, 28 Feb 1997 14:33:50 -0700 (MST) Received: (from pashdown@localhost) by slack.xmission.com (8.8.5/8.7.5) id OAA23490 for usr-tc; Fri, 28 Feb 1997 14:33:44 -0700 (MST) Message-Id: <199702282133.OAA23490@slack.xmission.com> X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-usr-tc@xmission.com Reply-To: usr-tc@xmission.com

On Sat, 01 Mar 1997 00:31:35 GMT, Bill Garfield wrote: >USR was under enormous pressure to release something as people were >getting tired of all the ad hype and were demanding product. The Client >product which released is an all new flash rom based external Sportster. >Nothing else released (no upgrades yet). Courier code was released tonight (2-28-97). Emails will be sent to those that registered for the free upgrades spread out over the next few days. It will be a 2 step process of downloading a new SDL then calling a toll free number to have x2 enabled. The SDL is available right now on the BBS (847-982-5092) or the totalservice.usr.com web site. More information can be found on the web site or in the readme.doc file downloaded from the BBS.