February 2000 - USR-TC - mailman.xmission.com

(usr-tc) Compression?
by Scott Kupferschmidt 02 Feb '00

02 Feb '00

Hi... At work we have a 3com/USR Total Control NETserver.. fully populated with 12 quad cards (48 modems). I am using RADIUS for authentication and all, but I'm wondering if there's a way to know or check to see if it supports STAC compression on the ISDN at all or not. If so I'd really like to know howto turn it on. For the curious, we are using Cistron radiusd, and which I don't know how to make it use/recognize the STAC compression if it's available. Also, how do you turn on / check for regular tcp header compression? The reason why I ask is at home I have my Cisco 1004 dialing in (at 128kbps) and when I tell it to use compression.. it just rejects it on the NETserver from what my debugging tells me. >From what other people have told me, NETserver's aren't the greatest for compression, but considering I'd probably be the only one using it, I'd rather attempt to use it. If anyone is of help, please write back.. Thanks. Scott - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

5 6

RE: (usr-tc) Problem with new PRI
by Stainforth, Matthew 02 Feb '00

02 Feb '00

What I typically do is get on the phone with the switch guy and get him to watch the status of the channels as I busy them out to make sure the switch actually sees them go busy. If they don't (or sometimes they go into "lockout"...whatever that is) there's a D channel problem. Either your NFAS settings aren't jiving (presuming you use NFAS) or you don't have a translation that supports service messages. A custom 5ESS translation should support them though. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Scot Desort [mailto:scot@njaccess.net] > Sent: Wednesday, February 02, 2000 11:00 AM > To: usr-tc(a)lists.xmission.com > Subject: Re: (usr-tc) Problem with new PRI > > > Thanks for the specifics, Lon. > > What was happening is that if a call hit a channel that was > soft busied, the > call wasn't rolling over to the next channel. The telco > switch was either > presenting a reorder tone to the end user, or an intercept > stating "Your > call cannot be completed as dialed" -- NOT a good thing. The > reorder isn't > too bad, but the intercept was ugly. If the user re-dialed > and landed on a > channel that was not soft-busied, the call would go through. > > What is distressing is that the DSP did not communicate > correctly with the > switch. The call should have never landed on that channel - > it should have > rolled to the next channel in the rotary. If there were no > other available > non-busied channels, user should get regular busy signal. > > Any thoughts as to why this would not work properly? Switch is a 5ESS > through a CLEC. > > -- > Scot > > > > ----- Original Message ----- > From: Lon R. Stockton, Jr. <lon(a)moonstar.com> > To: <usr-tc(a)lists.xmission.com> > Sent: Wednesday, February 02, 2000 2:27 AM > Subject: Re: (usr-tc) Problem with new PRI > > > > > > On Thu, 27 Jan 2000, Scot Desort wrote: > > > > > Where can one tell if modems are soft-busied. That is > what was wrong. I > have > > > since restored to service all of those channels. But > before I figured it > > > out, there didn't seem to be anywhere in TCM that told me > the channels > were > > > busied out. Did I miss something??? > > > > Didn't see an answer for this one, although it's very > possible I just > > missed it. Whichever, here's an answer for ya... > > > > 1) bring up TCM & open your chassis > > 2) click on the span leds of the DSP card(s) you want to check > > 3) click 'Performance' > > 4) select 'Timeslot' and then 'Select All'; click 'OK' > > 5) Under 'Parameters', select 'DS0 Service State' and > > 'Queued Action for DS0'. Click 'Add' and then 'OK'. > > 6) Voila. Timeslots which are busied-out are listed as > > 'localOutOfService' under 'DS0 Service State'. > > > > If the timeslot was hard-busied (or soft-busied with no > call currently > > active on the timeslot), you'll see the 'localOutOfService' > indication > > under 'DS0 Service State'. > > > > If the timeslot was soft-busied and there's a call > currently active on > > that timeslot, you'll see that the 'DS0 Service State' is > 'inService' > > and the 'Queued Action...' is 'localOutOfService'. As soon as the > > current call terminates, you'll see the service state go to > > localOutOfService. > > > > That, of course, being the difference between hard-busy and > soft-busy. > > Hard-busy does it NOW. Soft-busy waits for the current call > to complete. > > > > Hope this helps! > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

RE: (usr-tc) IP multicast and IPSec support
by Ricky 02 Feb '00

02 Feb '00

Thanks for the quick response Krish. Sincerely, Rickyz -----Original Message----- From: Tatai SV Krishnan [SMTP:tkrishna@bubba.ae.usr.com] Sent: Tuesday, February 01, 2000 11:20 PM To: Ricky Cc: usr-tc(a)lists.xmission.com Subject: Re: (usr-tc) IP multicast and IPSec support On Tue, 1 Feb 2000, Ricky wrote: > Does 3Com TC-Hub support any of the following: > > a) IP Multicast (I find a lots on their Docs as a topic but not as a > feature) Yes - its the IGMP feature that you can enable and configure the hiper arc for IGMP services, and also you can use multicast in rip v 2 mode. > > b) IPSec > TCS 4.0 will support this. krish > Thanks in advance, > Rickyz > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

(usr-tc) Connect Speed issues
by jeff.binkley＠asacomp.com 02 Feb '00

02 Feb '00

Folks, I know this issue has been belabored numerous times but I thought I'd kick the dead horse one more time. Recently we have had 3 customers with HSP modems either leave or threaten to leave due to them being able to connect to other ISPs at higher speeds. As a last resort on two of them we replaced their modems with 3Com modems and they stayed. Here is what we saw: HSP 3Com Cust 1 26400 37333 Cust 2 29333 41666 In both cases all that was changed is the modem. As expected the connections got more stable too (i.e. less disconnects). In the case of the third customer he won't replace his modem but swears he gets 40K connections with other ISPs. I tend to believe him and we will probably lose him. In all cases when we looked at the analog stats, all we saw was a slight rolloff at 3750 but everything else looked good. With the HSP and other el cheapo' modems now shipping as standard issue on the low end machines, including the dreaded E-Machines, I suspect this problem is going to get worse not better unless 3Com can help us here. I am running the latest Quad code and 2.0.51 DSP code. Jeff CMPQwk 1.42-21 9999 - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

7 7

(usr-tc) IP multicast and IPSec support
by Ricky 02 Feb '00

02 Feb '00

Does 3Com TC-Hub support any of the following: a) IP Multicast (I find a lots on their Docs as a topic but not as a feature) b) IPSec Thanks in advance, Rickyz - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

(usr-tc) which Radius to use?
by Nate Smith 01 Feb '00

01 Feb '00

Hi, I'm trying to move Radius server that we are using now to a new server but I'm having some problems getting the current radius to run on the new server. So I was thinking of just reinstalling but the old network admin is no longer around and I can't figure out what version of radius we're running one the other box. All I get when I try to find out is: ./radiusd -v ./radiusd: RADIUS version 1.16.1 97/12/16 sun I would really like to use a radius that could check multiple logins. If anyone could point me in the right direction in which radius to use (on Sun Solaris 2.6) and where to get it I'd be much appreciative. Thanks, Nate - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

4 3

(usr-tc) adding 24 modems / T-1
by Richard Mann 01 Feb '00

01 Feb '00

Would vendors and/or individuals please contact me off the list, I need to buy one DSP card for a HiPer Arc chassis 80-002861-00. --rich Richard Mann, System Administrator A d v a n c e N e t Champaign, Illinois USA rmann(a)advancenet.net http://www.advancenet.net (888) 992-8008 (217) 356-4009 - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

1 0

Re: (usr-tc) Quad modem x2 tx level
by Ray Whelan 01 Feb '00

01 Feb '00

Hi , Is the modem enforcing a maximum signal level on country-code basis? If so, can I bypass this limit? No depending on your country code setting for each country , you have and max and a min range with in that you can not change. Ray W Dan Borlovan <danb(a)dnttm.ro> on 01/02/2000 10:35:01 Please respond to usr-tc(a)lists.xmission.com Sent by: Dan Borlovan <danb(a)dnttm.ro> To: usr-tc(a)lists.xmission.com cc: (Ray Whelan/IE/3Com) Subject: Re: (usr-tc) Quad modem x2 tx level On Mon, 31 Jan 2000, Ray Whelan wrote: > There are slight differences in setting between modems from different country > settings, as our modems must comply with the different country specification > settings set by each Telco , ATI7 tells you your country code setting. Is the modem enforcing a maximum signal level on country-code basis? If so, can I bypass this limit? > By the way -10 dB is a stronger signal than -12 dB Yes I know, and -10dB gives me better x2 connect speeds. Dan -- Dan Borlovan <danb(a)dnttm.ro> System Administrator, Network Operation Center Dynamic Network Technologies - Timisoara, Romania Telefon: +40-56-204967 FAX: +40-56-220201 - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

Re: (usr-tc) Quad modem x2 tx level
by Ray Whelan 01 Feb '00

01 Feb '00

Hi , Typically the tranmit s39 value is -12 dB for the US with a range for the US from -9 dB max. to an Min -20 db , I would suggest been very careful about adjusting this value. The country codes is in DSP . Regards RayW Greg Coffey <greg(a)coffey.com> on 31/01/2000 20:59:22 Please respond to usr-tc(a)lists.xmission.com Sent by: Greg Coffey <greg(a)coffey.com> To: usr-tc(a)lists.xmission.com cc: (Ray Whelan/IE/3Com) Subject: Re: (usr-tc) Quad modem x2 tx level So what db level do you recommend that the quads be set to assuming we're in the US? What about the dsp's? At 08:54 PM 1/31/00 +0000, you wrote: >Hi Dan, > >There are slight differences in setting between modems from different country >settings, as our modems must comply with the different country specification >settings set by each Telco , ATI7 tells you your country code setting. >Country like US/Canada , Japan, Finland, Sweden, UK, Norway, South Africa, >Italy, New Zealand, Czech / Slovkia, Belgium, Denmark, Austria, France, >Germany, >Austria , Ireland , Spain, Portugal and Malaysia all have very slight >difference >in values and limits, what you are seeing is more likely differences in modem >country settings , we also have a country code setting that covers >International >ITU-T spic. > >By the way -10 dB is a stronger signal than -12 dB > >Hope it helps > >Ray W > > > > > >Dan Borlovan <danb(a)dnttm.ro> on 30/01/2000 09:22:41 > >Please respond to usr-tc(a)lists.xmission.com > >Sent by: Dan Borlovan <danb(a)dnttm.ro> > > >To: usr-tc(a)lists.xmission.com >cc: (Ray Whelan/IE/3Com) >Subject: (usr-tc) Quad modem x2 tx level > > > > > >Hello, > >In order to try improve user x2 connect speeds, I tried to raise the x2 >transmit level on quad modem cards. The problem is I have two quad modem >models (analog/digital vs. digital only) and the first don't let me go >higher than -12dB, while the other ones happily accepted -10dB (this is as >far as I may go from the telco point of view) > >Now the only difference between modems is the analog capability (referring >to the possibility of getting signal from nic or pritdm) and the country >code. > >All modems are setup as digital, taking signal via pritdm from e1 card. > >Is there anything I can do about this one? > >Dan >-- >Dan Borlovan <danb(a)dnttm.ro> >System Administrator, Network Operation Center >Dynamic Network Technologies - Timisoara, Romania >Telefon: +40-56-204967 FAX: +40-56-220201 > > >- > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey(a)vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center Suite #100, Casper, WY 82601 www.vcn.com - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1

RE: (usr-tc) Quirky CHAP on 2.0.51
by Ian Quinn 01 Feb '00

01 Feb '00

It doesn't look like a CHAP problem - more a LCP negotiation problem. After the HARC sends it's CHAP Challenge, it receives another LCP Request from the remote end, effectively restarting the LCP phase. It's not obvious what's wrong from this end since during the initial set of LCP negotion, there seems to be an LCP Request-Acknowledge eventually negotiated in each direction so both ends should think the LCP state is open and be happy to move on to authenticate. 1. LCP Negotiated Remote Client -> HARC Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 2. LCP Negotiated HARC -> Remote Client Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df I'd get a trace from the remote device and see if it receives the outgoing LCP Acknowledge from the HARC. Maybe it's corrupt, lost or just late for some reason forcing the remote client to resend it's LCP config request. The remote end definately seems to be pushing the HARC back into negotiating LCP after the HARC thinks it's open and has moved on to authenticate. Also not sure what AUTH_TYPE c2 23 81 is? c2 23 05 is CHAP, c2 23 80 is MS-CHAP (I think)... Hope this helps (and that I didn't misread this!). Regards Ian > -----Original Message----- > From: Scot Desort [SMTP:scot@njaccess.net] > Sent: Tuesday, February 01, 2000 4:12 PM > To: usr list > Subject: (usr-tc) Quirky CHAP on 2.0.51 > > Have a few DSP's upgraded to 2.0.51. Just noticed a quirk in CHAP > authentication. After LCP is done, and PPP authentication begins, the auth > packets do not make it to the Radius server. I have made several test > calls, > logging both radius info on my Vircom radius server, and PPP packets on > the > TC. The radius server does not receive any incoming packet. The TC shows > the > following: > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM bc 93 87 df > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 > CALLBACK 06 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REJ CALLBACK 06 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REJ PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM bc 93 87 df > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_NAK AUTH_TYPE c2 23 81 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c2 23 05 > MAGIC_NUM bc 93 87 df > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_ACK MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c2 23 05 > MAGIC_NUM bc 93 87 df > > Outgoing PPP Data on interface: slot:4/mod:17 > CHAP CHALLENGE 10 a9 8a 81 83 ad dc b9 > 06 13 f2 bc ad 63 d4 76 > 28 48 69 50 65 72 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 8b cf 11 8b > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REJ PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 8b cf 11 8b > > Outgoing PPP Data on interface: slot:4/mod:17 > CHAP CHALLENGE 10 50 b8 b1 f5 4d a4 9a > d0 e1 c9 af ef 3e 1d 1c > 82 48 69 50 65 72 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_NAK AUTH_TYPE c2 23 05 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c2 23 05 > MAGIC_NUM 8b cf 11 8b > > > And the process continues until I cancel the connection attempt. > > It *will* however sometimes authenticate just fine using CHAP. It always > authenticates using PAP. This test call is ISDN. I am about to try the > same > series of tests using analog dialup. > > Anyone else seen this??? > > -- > Scot > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo(a)xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

2 1