problem with telnet and SCO 5.0.5

problem with telnet and SCO 5.0.5

Post by jjsm » Mon, 14 Aug 2000 04:00:00



I am presently running the following:

SCO:Unix::5.0.5Eb  rs505a.Unix505.1.0a  oss471c.Unix505.1.0a
oss600a.Unix505  oss497c.Unix505.1.0a

I am trying to telnet in from home to this office computer running SCO.

at home I have Win98 connected through a cable modem and optonline ISP.

at work the computer is connected to a Ugate 3200 router to a westell  XDSL
modem and  ISP is bell atlantic. At work there are a few other Win98
machines connected locally to the network through the  Ugate3200
router/switch.

When I use one of the Win98 computers at work and telnet into SCO everything
works fine.

From home when I telnet in to the SCO , I get the Login prompt and I do log
in. It seems that whatever I run, after about  1 or
maybe 2 minutes the computer hangs and I have to close down the telnet
session to continue. It does not seem to make a diff if I run an application
or if I just doing things like system commands ( i.e.  ls, cd  and so on). I
am using PoweTerm Interconnect
terminal emulation program from Ericom Software to telnet. It does not seem
to be the telnet software at home since the same thing happens with
Hyperterminal as well as the Windows telnet software.

Any suggestions? Please help

Joe

 
 
 

problem with telnet and SCO 5.0.5

Post by Jeff Lieberman » Mon, 14 Aug 2000 04:00:00



>I am presently running the following:

>SCO:Unix::5.0.5Eb  rs505a.Unix505.1.0a  oss471c.Unix505.1.0a
>oss600a.Unix505  oss497c.Unix505.1.0a

>I am trying to telnet in from home to this office computer running SCO.

>at home I have Win98 connected through a cable modem and optonline ISP.

>at work the computer is connected to a Ugate 3200 router to a westell  XDSL
>modem and  ISP is bell atlantic. At work there are a few other Win98
>machines connected locally to the network through the  Ugate3200
>router/switch.

>When I use one of the Win98 computers at work and telnet into SCO everything
>works fine.

>From home when I telnet in to the SCO , I get the Login prompt and I do log
>in. It seems that whatever I run, after about  1 or
>maybe 2 minutes the computer hangs and I have to close down the telnet
>session to continue. It does not seem to make a diff if I run an application
>or if I just doing things like system commands ( i.e.  ls, cd  and so on). I
>am using PoweTerm Interconnect
>terminal emulation program from Ericom Software to telnet. It does not seem
>to be the telnet software at home since the same thing happens with
>Hyperterminal as well as the Windows telnet software.

Methinks the important thing to do first is to isolate whether the
problem is at the Windoze end, there router in between, or at the OSR5
end.  Basically, I start at the furthest part of the puzzle (the
application) and work my way back to your Windoze machine.  This is often
called "assigning the blame".

It's not clear from your description if the telnet session on the Windoze
box is what is hung, or if the application you're running on the OSR5 end
is hung.  The easiest way to determine this is to run *TWO* telnet
sessions, using whatever Windoze telnet client is convenient, connected
to the OSR5 box.  One runs the application, the other just sits on the
shell prompt.  If the application is hung, but not the shell prompt, then
methinks there is something wrong with the application.  Perhaps it
doesn't appreciate packet loss or something.  If both sessions hang
simultaneously, then it's not the application.

Try checking for network errors on the OSR5 end:
        llistat
        llistat -l  (long and messy).
Since you're on a switched port, you should have absolutely no
collisions.  If there are a bunch, it's possible that your OSR5 NIC is
broken, or possibly the driver.  However, as local traffic works, this is
probably not the case.

Are there any other machines, on your office lan, that are accessible
from your home computer?  Try maintaining a connection to those those.
It doesn't have to be telnet, but can be some other service (email, web,
ftp, whatever).  If it also hangs, then it's not the OSR5 server.  If it
works well, then I don't have a clue.

The next step is to telnet to the Ugate 3200 router IP address or perhaps
fire up the web browser configuration interface.  No need to change
anything, just see if there's a reliable connection.  I'm not sure this
is possible as some cheap routers (i.e. Linksys) are not accessible from
the WAN side.  I'm also curious as to how many services are running on
the router.  Cacheing DNS?  VPN Pass-thru?  DHCP server?  Etc?  Just
curious.  Are you connecting directly to the SCO OSR5 box via IP port
re-direction, or are you running a VPN to some kind of NT server, and
connecting from there?  Just guessing.
        http://www.maxgate.net/product_3200.htm
Yech.  Worthless data sheet from marketting.

Assuming the Umax Ugate 3200 can be eliminated as a potential problem,
that leaves Bell Atlantic.  I'll assume that you're getting a reliable
connection with reasonable packet loss.  Run:
        netstat -e -s
on your Windoze box for clues.  Look for errors.  A small percentage are
acceptable.

Moving to the Windoze machine, do other services to high traffic web
sites and such work well?  I'll assume they do.  Have you done any of the
RWIN tweaks?  See:
        http://www.dslreports.com/tweaks
        http://Cable-DSL.home.att.net/
The RWIN tweak (maximum receive window) is necessary to get decent
performance over xDSL and cable modems.  There is a similar tweak for
OSR5 that I described in the past.  It's probably NOT necessary if you
have a 100baseT card in the OSR5 server.  However, the 10baseT defaults
are much too small.  See:
        http://www.deja.com/=dnc/getdoc.xp?AN=645387888
It's at the bottom.  If running:
        ifconfig -a
yields:
        perf. params: recv size: 4096; send size: 8192;
It's time to tweak.  Also, be careful about running inconfig.  It breaks
a needed symlink.
        http://www.sco.com/cgi-bin/ssl_reference?105698

Good luck.

--

150 Felker St #D  Santa Cruz CA  95060
831-421-6491 pager   831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/   SCO stuff

 
 
 

problem with telnet and SCO 5.0.5

Post by Jeff Lieberman » Tue, 15 Aug 2000 04:00:00


On Tue, 15 Aug 2000 02:43:46 GMT, "Joseph Schwartz"


>Thank you Jeff for your previous reply.

I take the easy questions and leave the tough ones to JPR and those that
know what they're doing.

Quote:>So I have effectively found the culprit to be the Linksys
>router.

No big deal.  Do you use PPPoE (PPP over Ethernet) on your DSL
connection?  If so, you *CANNOT* use an MTU (max tranfer unit) of 1500
Bytes because PPPoE borrows some of them for its overhead.  SCO OSR5 sets
the MTU at 1500 and also sets the "thou shalt not fragment my packets"
flag.  From: ifconfig -a
   net0: flags=4043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
   inet 192.168.111.5 netmask ffffff00 broadcast 192.168.111.255
   perf. params: recv size: 4096; send size: 8192; full-size frames: 1
   ether 00:aa:00:b7:bb:e5
Note the "full-size frames: 1" flag.  You could change the flag to 0 on
the OSR5, but you'll take a performance hit when it starts sending
smaller packets and a reliability hit when the maximum receive window
causes more packets to waiting for acknowledgement.  (Drivel:  IPv6
specifies that the no-fragment flag is always on).

So, the best idea is to tweak the RWIN and max MTU on your Windoze
machine.  See:
  http://www.dslreports.com/tweaks/MTU
for instructions.  MaxMTU=1492 is the maximum recommended, but I've had
some weird problems with this value and use 1490 instead.  Do the ping
test as described to be sure.  I pinged your router from here and it
looks like 1492 will work.

For a related problem with packet fragmentation see:
        http://www.rahul.net/dhesi/webmtu/
for a 2 year old discussion about a problem that I keep seeing.  Using
OSR5 as any kind of server, with the default "don't fragment flag" turned
on *AND* ICMP responses blocked by a firewall, is asking for problems.

You'll also need to check the firmware on the Linksys.  Current for the
BEFR41 and BEFR11 is 1.30 at:
        ftp://ftp.linksys.com/pub/befsr41/befsr_v130.exe
Dig around the ftp site (when it's working) as there are sometimes later
versions.  Hmmm... I can tell you have a version older than 1.23 because
the default for responding to ping and traceroute commands changed from
"why not" to "no way" in 1.23.  Your router is responding to my pings.
Be careful with the upgrade proceedure as there's no recovery to a
screwup or accident.

Quote:>Now my only question is what in the router is causing this to happen? I can
>successfully telnet into other machines , including Unix boxes without any
>problems. Someone mentioned that the Linksys uses something called NAT
>technology and that may be what is causing the problem when interaction with
>the SCO box.

Nope.  If you can connect to the SCO box through TWO routers, you're
doing fine.  No NAT problems involved.

--

150 Felker St #D  Santa Cruz CA  95060
831-421-6491 pager   831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/   SCO stuff

 
 
 

problem with telnet and SCO 5.0.5

Post by Jeff Lieberman » Tue, 15 Aug 2000 04:00:00


On Tue, 15 Aug 2000 02:43:46 GMT, "Joseph Schwartz"


>I have a few windoz machines at home connected to a Linksys router and then
>connected to my cable modem.

Argh.  I didn't see the part about the cable modem.  I thought you had
ADSL.  The stuff I posted on PPPoE does NOT apply to cable modems.  That
leaves firmware problems on the Linksys, a busted internal switch section
if it's the BEFR41 model, or ratty CAT5 cabling.

--

150 Felker St #D  Santa Cruz CA  95060
831-421-6491 pager   831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/   SCO stuff

 
 
 

problem with telnet and SCO 5.0.5

Post by Joseph Schwart » Wed, 16 Aug 2000 11:43:46


Thank you Jeff for your previous reply.

I took your advice and kept on switching machines and services in order to
"assign the blame" and this is what I found.

I have a few windoz machines at home connected to a Linksys router and then
connected to my cable modem. Whenever I telnet through the Linksys  I got
hung up in middle of my connection to the Sco box ( it doesn't matter if I
am in an application or just at the shell level).  I connected one of my
machines directly to the cable modem and Viola the telnet session performed
flawlessly. So I have effectively found the culprit to be the Linksys
router.

Now my only question is what in the router is causing this to happen? I can
successfully telnet into other machines , including Unix boxes without any
problems. Someone mentioned that the Linksys uses something called NAT
technology and that may be what is causing the problem when interaction with
the SCO box. I haven't got a clue as to how to check that out.
Any suggestions?

Thanks in advance

Joe Schwartz



> >I am presently running the following:

> >SCO:Unix::5.0.5Eb  rs505a.Unix505.1.0a  oss471c.Unix505.1.0a
> >oss600a.Unix505  oss497c.Unix505.1.0a

> >I am trying to telnet in from home to this office computer running SCO.

> >at home I have Win98 connected through a cable modem and optonline ISP.

> >at work the computer is connected to a Ugate 3200 router to a westell
XDSL
> >modem and  ISP is bell atlantic. At work there are a few other Win98
> >machines connected locally to the network through the  Ugate3200
> >router/switch.

> >When I use one of the Win98 computers at work and telnet into SCO
everything
> >works fine.

> >From home when I telnet in to the SCO , I get the Login prompt and I do
log
> >in. It seems that whatever I run, after about  1 or
> >maybe 2 minutes the computer hangs and I have to close down the telnet
> >session to continue. It does not seem to make a diff if I run an
application
> >or if I just doing things like system commands ( i.e.  ls, cd  and so
on). I
> >am using PoweTerm Interconnect
> >terminal emulation program from Ericom Software to telnet. It does not
seem
> >to be the telnet software at home since the same thing happens with
> >Hyperterminal as well as the Windows telnet software.

> Methinks the important thing to do first is to isolate whether the
> problem is at the Windoze end, there router in between, or at the OSR5
> end.  Basically, I start at the furthest part of the puzzle (the
> application) and work my way back to your Windoze machine.  This is often
> called "assigning the blame".

> It's not clear from your description if the telnet session on the Windoze
> box is what is hung, or if the application you're running on the OSR5 end
> is hung.  The easiest way to determine this is to run *TWO* telnet
> sessions, using whatever Windoze telnet client is convenient, connected
> to the OSR5 box.  One runs the application, the other just sits on the
> shell prompt.  If the application is hung, but not the shell prompt, then
> methinks there is something wrong with the application.  Perhaps it
> doesn't appreciate packet loss or something.  If both sessions hang
> simultaneously, then it's not the application.

> Try checking for network errors on the OSR5 end:
> llistat
> llistat -l  (long and messy).
> Since you're on a switched port, you should have absolutely no
> collisions.  If there are a bunch, it's possible that your OSR5 NIC is
> broken, or possibly the driver.  However, as local traffic works, this is
> probably not the case.

> Are there any other machines, on your office lan, that are accessible
> from your home computer?  Try maintaining a connection to those those.
> It doesn't have to be telnet, but can be some other service (email, web,
> ftp, whatever).  If it also hangs, then it's not the OSR5 server.  If it
> works well, then I don't have a clue.

> The next step is to telnet to the Ugate 3200 router IP address or perhaps
> fire up the web browser configuration interface.  No need to change
> anything, just see if there's a reliable connection.  I'm not sure this
> is possible as some cheap routers (i.e. Linksys) are not accessible from
> the WAN side.  I'm also curious as to how many services are running on
> the router.  Cacheing DNS?  VPN Pass-thru?  DHCP server?  Etc?  Just
> curious.  Are you connecting directly to the SCO OSR5 box via IP port
> re-direction, or are you running a VPN to some kind of NT server, and
> connecting from there?  Just guessing.
> http://www.maxgate.net/product_3200.htm
> Yech.  Worthless data sheet from marketting.

> Assuming the Umax Ugate 3200 can be eliminated as a potential problem,
> that leaves Bell Atlantic.  I'll assume that you're getting a reliable
> connection with reasonable packet loss.  Run:
> netstat -e -s
> on your Windoze box for clues.  Look for errors.  A small percentage are
> acceptable.

> Moving to the Windoze machine, do other services to high traffic web
> sites and such work well?  I'll assume they do.  Have you done any of the
> RWIN tweaks?  See:
> http://www.dslreports.com/tweaks
> http://Cable-DSL.home.att.net/
> The RWIN tweak (maximum receive window) is necessary to get decent
> performance over xDSL and cable modems.  There is a similar tweak for
> OSR5 that I described in the past.  It's probably NOT necessary if you
> have a 100baseT card in the OSR5 server.  However, the 10baseT defaults
> are much too small.  See:
> http://www.deja.com/=dnc/getdoc.xp?AN=645387888
> It's at the bottom.  If running:
> ifconfig -a
> yields:
> perf. params: recv size: 4096; send size: 8192;
> It's time to tweak.  Also, be careful about running inconfig.  It breaks
> a needed symlink.
> http://www.sco.com/cgi-bin/ssl_reference?105698

> Good luck.

> --

> 150 Felker St #D  Santa Cruz CA  95060
> 831-421-6491 pager   831-429-1240 fax
> http://www.cruzio.com/~jeffl/sco/   SCO stuff

 
 
 

problem with telnet and SCO 5.0.5

Post by jjsm » Wed, 16 Aug 2000 04:00:00


I am slightly confused about your last response:

at the SCO box I am connected to a Ugate3200 router which is connected to a
ADSL modem using PPOE.

at the Windoz end I am connected to a Linksys router which is connected to a
cable modem.

when you mentioned adjusting the MTU on the windoz machine was that even
though the SCO box is the one connected to PPOE while the windoz is
connected to a cable modem.?
If that would be the case why would it work if I eliminate the Linksys? It
seems that whaever is wrong is in the connection between my windoz and the
Linksys including the Linksys.

I appreciate all the help your giving me/

TIA

joseph Schwartz


> On Tue, 15 Aug 2000 02:43:46 GMT, "Joseph Schwartz"

> >I have a few windoz machines at home connected to a Linksys router and
then
> >connected to my cable modem.

> Argh.  I didn't see the part about the cable modem.  I thought you had
> ADSL.  The stuff I posted on PPPoE does NOT apply to cable modems.  That
> leaves firmware problems on the Linksys, a busted internal switch section
> if it's the BEFR41 model, or ratty CAT5 cabling.

> --

> 150 Felker St #D  Santa Cruz CA  95060
> 831-421-6491 pager   831-429-1240 fax
> http://www.cruzio.com/~jeffl/sco/   SCO stuff

 
 
 

problem with telnet and SCO 5.0.5

Post by Jeff Lieberman » Wed, 16 Aug 2000 04:00:00



>I am slightly confused about your last response:

>at the SCO box I am connected to a Ugate3200 router which is connected to a
>ADSL modem using PPOE.

>at the Windoz end I am connected to a Linksys router which is connected to a
>cable modem.

>when you mentioned adjusting the MTU on the windoz machine was that even
>though the SCO box is the one connected to PPOE while the windoz is
>connected to a cable modem.?

Naw.  I blew it.  I was doing 3 other things while responding (like I'm
doing right now) over a period of about an hour.  I got everything
backwards.

Quote:>If that would be the case why would it work if I eliminate the Linksys? It
>seems that whaever is wrong is in the connection between my windoz and the
>Linksys including the Linksys.

Some box is doing Path MTU discovery and coming up with the wrong answer.
Allow me to change my mind (again).  Even though taking the Linksys out
of the puzzle "solved" the problem, methinks the source of the problem is
at the SCO end.  MaxMTU is a negotiated value and methinks the Linksys is
screwing up.  This was solved in Linksys firmware 1.23 where nobody could
connect to www.pcconnection.com because of Path MTU negotiation screwups.
It's the PPPoE part of the puzzle that's causing the problem.  Fire up
your web browser and disclose your Linksys version.

Try this on the OSR5 box.  Edit /etc/tcp and change the ifconfig line
from something like this (all on one line):

ifconfig -p net0 192.168.111.5  netmask 255.255.255.0 broadcast \
     192.168.111.255 perf 4096 8192 1

to something like this (all on one line):

ifconfig -p net0 192.168.111.5  netmask 255.255.255.0 broadcast \
     192.168.111.255 mtu 1492 perf 32768 24576 1

You can probably just run this from the command line and without a reboot
(not sure).  This does 3 things:
   Changes the maximum receive window from whatever to 32768 for DSL rx.
   Leave maximum send window at 24576 for both 10baseT or 100baseTX.
   Changes the Maximum MTU from 1500 to 1492 for PPPoE.
   Leaves the "don't fragment" flag turned on.
See man page at:
 http://www.sco.com/cgi-bin/ssl_getmanpage?ifconfig+ADMN+OS5+ifconfig
Please do NOT run "inconfig" as the instructions indicate as it breaks a
symlink causing side effects.  See:
        /etc/default/inet
for current values.  Edit manually as required and reboot when you're
convinced it works.  Check for the busted symlink:
  http://www.sco.com/cgi-bin/ssl_reference?105698

I don't think you're going to notice any performance changes as you're
limited in speed by the *OUTGOING* performance of the cable modem and DSL
lines which methinks Bell Altantic throttles to 128KB.

I'm not sure if you have to change your MaxMTU value on your Windoze
boxes (on the cable modem end).  Probably not.  If the server limits
packets to 1492, and everyone negotiates the Path MTU correctly, then it
should not be a problem.  You can sorta tell (i.e. guess) if there's a
problem by running:
        netstat -s
on the Windoze end and looking at the IP section for "datagrams failing
fragrmentation."

Also, you should re-check that the office LAN Windoze boxes still work
reliably.  Dropping the MaxMTU from 1500 to 1492 will require them to
negotiate the value.  If anything in the path blocks ICMP echo (like
through a router), the MTU negotiation may fail as previously described.

--

150 Felker St #D  Santa Cruz CA  95060
831-421-6491 pager   831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/   SCO stuff

 
 
 

problem with telnet and SCO 5.0.5

Post by Joseph J Schwart » Tue, 22 Aug 2000 04:00:00


     Thank you Jeff for your help,
      I did as you suggested and I edite the etc/tcpfile on the SCO box
      and inserted the MTU of 1492 and all seems to work well .

I will test it with diff windoz boxes and get back toyou if theproblem
resurfaces.

Thanks again

Joseph J Schwartz



> >I am slightly confused about your last response:

> >at the SCO box I am connected to a Ugate3200 router which is connected to
a
> >ADSL modem using PPOE.

> >at the Windoz end I am connected to a Linksys router which is connected
to a
> >cable modem.

> >when you mentioned adjusting the MTU on the windoz machine was that even
> >though the SCO box is the one connected to PPOE while the windoz is
> >connected to a cable modem.?

> Naw.  I blew it.  I was doing 3 other things while responding (like I'm
> doing right now) over a period of about an hour.  I got everything
> backwards.

> >If that would be the case why would it work if I eliminate the Linksys?
It
> >seems that whaever is wrong is in the connection between my windoz and
the
> >Linksys including the Linksys.

> Some box is doing Path MTU discovery and coming up with the wrong answer.
> Allow me to change my mind (again).  Even though taking the Linksys out
> of the puzzle "solved" the problem, methinks the source of the problem is
> at the SCO end.  MaxMTU is a negotiated value and methinks the Linksys is
> screwing up.  This was solved in Linksys firmware 1.23 where nobody could
> connect to www.pcconnection.com because of Path MTU negotiation screwups.
> It's the PPPoE part of the puzzle that's causing the problem.  Fire up
> your web browser and disclose your Linksys version.

> Try this on the OSR5 box.  Edit /etc/tcp and change the ifconfig line
> from something like this (all on one line):

> ifconfig -p net0 192.168.111.5  netmask 255.255.255.0 broadcast \
>      192.168.111.255 perf 4096 8192 1

> to something like this (all on one line):

> ifconfig -p net0 192.168.111.5  netmask 255.255.255.0 broadcast \
>      192.168.111.255 mtu 1492 perf 32768 24576 1

> You can probably just run this from the command line and without a reboot
> (not sure).  This does 3 things:
>    Changes the maximum receive window from whatever to 32768 for DSL rx.
>    Leave maximum send window at 24576 for both 10baseT or 100baseTX.
>    Changes the Maximum MTU from 1500 to 1492 for PPPoE.
>    Leaves the "don't fragment" flag turned on.
> See man page at:
>  http://www.sco.com/cgi-bin/ssl_getmanpage?ifconfig+ADMN+OS5+ifconfig
> Please do NOT run "inconfig" as the instructions indicate as it breaks a
> symlink causing side effects.  See:
> /etc/default/inet
> for current values.  Edit manually as required and reboot when you're
> convinced it works.  Check for the busted symlink:
>   http://www.sco.com/cgi-bin/ssl_reference?105698

> I don't think you're going to notice any performance changes as you're
> limited in speed by the *OUTGOING* performance of the cable modem and DSL
> lines which methinks Bell Altantic throttles to 128KB.

> I'm not sure if you have to change your MaxMTU value on your Windoze
> boxes (on the cable modem end).  Probably not.  If the server limits
> packets to 1492, and everyone negotiates the Path MTU correctly, then it
> should not be a problem.  You can sorta tell (i.e. guess) if there's a
> problem by running:
> netstat -s
> on the Windoze end and looking at the IP section for "datagrams failing
> fragrmentation."

> Also, you should re-check that the office LAN Windoze boxes still work
> reliably.  Dropping the MaxMTU from 1500 to 1492 will require them to
> negotiate the value.  If anything in the path blocks ICMP echo (like
> through a router), the MTU negotiation may fail as previously described.

> --

> 150 Felker St #D  Santa Cruz CA  95060
> 831-421-6491 pager   831-429-1240 fax
> http://www.cruzio.com/~jeffl/sco/   SCO stuff