Very Computer

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

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

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

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.

--

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

--

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

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

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

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.

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

     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