News Group Posts

tcp/ip established connections

Also see TCP/IP keepalives.

However, as Jeff suggested, fixing the frame relay problem would eliminate the TCP/IP timeout issues.

Message-ID: <39CAAB98.DE532910@ncs.co.nz> 
Date: Fri, 22 Sep 2000 12:45:12 +1200
From: Greg M Lee <greg@ncs.co.nz>
Newsgroups: comp.unix.sco.misc
Subject: Re: SCO TCP/IP
References: <20000921141930.E5119@jpradley.jpr.com> 

Hi
  I have seen something similar happen a number of times when the link goes
  down whilst the server is communicating to the client. It seems to "remember"
  that the client is "unavailable" because when the link comes back the SCO
  5.0.5 server can't ping the clients.  We ping the server from the client,
  wait a couple of minutes (TCP timeout ??), then everything is fine again.
  We use James River, Anzio, NetTerm, and even TeraTerm on Win 9x and Win2k.

Hope this helps.
-Greg

Jean-Pierre Radley wrote:
> 
> A customer is having a problem with telnet from remote sites via frame
> relay.  When a connection drops or appears to be consuming all available
> bandwidth, the PC cannot telnet back into the SCO host (using Windows'
> telnet, or Anzio, or IceTCP -- no login prompt comes up) unless that
> Windows box changes its IP number.  Telnetting back to a Linux box
> located alongside the SCO box, on the same 176.16 network, does not show
> this behavior; if connection to a Linux box drops, telnetting right back
> in works fine.
> 
> His analysis:
> 
>     Our WAN consists of 14 sites connecting to headquarters over a
>     Frame Relay network, running TCP/IP as main protocol. Our users
>     are connecting to an OSR 5.0.5 server, running Oracle, by using
>     telnet. Clients are from JRiver, a mix of 16-bit DejawinT and 32-bit
>     Ice Tcp Pro. Workstations are Intel based boxes, running Win98.
> 
>     Server specs (SCO):
> 
>     Dell Poweredge 6300 4 x 550 Mhz proc. (quad)
>     1 Gb memory
>     6 x 9.1 Gb (10K rpm) HDs runnng Raid 5, one hotspare.
> 
>     NICs:
> 
>     1 (LAN and WAN NIC) 3Com EtherLink XL PCI (3C900) 3Com Fast
>     EtherLink XL PCI (3C905) (ver 5.0.5c)
>     2 Intel(R) PRO/100B / PRO/100+ PCI Adapter (ver 5.0.5e) (This is
>     due to us mirroring the server, where these NICs are isolated)
> 
>     The SCO box has the following patches on it:
> 
>     OSS471C: Pentium Pro/PII microcode download supplement
>     OSS497C: Core OS Supplement
>     OSS605A: NetBIOS Drivers Supplement
>     RS505A: Release Supplement for SCO OpenServer Release 5.0.5
> 
>     When the Frame gets overloaded or the PVC drops, the connection to
>     the SCO box is either timed out or dropped, due to the packets not
>     getting forth and back to the server in a timely manner. When this
>     happens, the user is trying to reconnect and the connection is timed
>     out, simply not getting a login.
> 
>     We have done the following in order to troubleshoot:
> 
>     We tried to connecting to other servers on the network at same
>     location (headquarters), mostly Linux (Redhat) servers and this
>     works fine (still over the WAN from a remote site). Please note that
>     this is using the same client from the same workstation. However,
>     reconnecting to the SCO box is not possible.
> 
>     After this we tried to use various Telnet clients: we tried Anzio
>     and Windows built in telnet client. Still not possible to reconnect to
>     the SCO box but possible to reconnect to other servers on the network.
> 
>     We have found a temporary fix for this: we change the IP (on the
>     workstation) and then it is possible to reconnect. By the way, the WAN
>     and the LAN are based on static RFC1597 IPs.
> 
>     With this in mind, we performed another test. We took two machines
>     at a remote site, one was working fine and the other one had the
>     connection problem. We switched IPs and the roles were reversed;
>     please also keep in mind that it was possible to telnet in to other
>     boxes on the network using either machine.
> 
>     We believe we have most likely isolated the problem to the SCO box
>     and SCO's implementation or the specific configuration of TCP/IP.
> 
>     Could it be the OS not dropping the established connection after
>     getting the syn_ack?? If so, is there any way we can drop it faster
>     after it is timing out??
> 
>     Know that I am out in deep waters here, since my knowledge of SCO
>     TCP/IP is limited, but, could it be security related? I.e. this
>     would make sense when one wants to prevent IP spoofing or syn
>     flooding attacks, could it be that the box receives the syn request
>     but will not send back the syn_ack due to the timed out connection?
> 
>     Furthermore, also know that some systems are placing SYN or RST
>     cookies, which I guess could cause the above. Would be interesting
>     to know if SCO is using these cookies. Also, someone told me
>     that Windows networking can get problems with RST cookies, which
>     potentially could explain the problem.
> 
>     Would sincerely appreciate any help on the matter.
> 
> --
> JP

From: Jeff Liebermann <je...@comix.santa-cruz.ca.us>
Subject: Re: SCO TCP/IP
Date: 2000/09/22
Message-ID: <6f1mssc61qn3rndaisucm0fdi7dir2dcba@4ax.com#1/1> 

On Thu, 21 Sep 2000 18:19:30 GMT, Jean-Pierre Radley <j...@jpr.com> wrote:

>    Could it be the OS not dropping the established connection after
>    getting the syn_ack?? If so, is there any way we can drop it faster
>    after it is timing out??

See the file:
	/etc/default/inet
Some timouts and parameters to play with.  This is from my 3.2v5.0.6 box
so some parameters may not be present.

# TCP timeout for connection establishment (in seconds)
# defaults to 3 minutes per RFC 1122
#
tcp_initial_timeout             180

# Control the use of delayed acks. If immediate acks are required,
# set to 0
#
tcp_delay_acks                  1

# default time that connections will remain in TIME-WAIT.
# defaults to 4 minutes per RFC 793.  Those who like to live
# dangerously can set this lower.
#
tcp_2msl                        30

This is a good place to Learn by Destroying(tm).

>    Know that I am out in deep waters here, since my knowledge of SCO
>    TCP/IP is limited, but, could it be security related? I.e. this
>    would make sense when one wants to prevent IP spoofing or syn
>    flooding attacks, could it be that the box receives the syn request
>    but will not send back the syn_ack due to the timed out connection?

Probably not.  Run:
	netstat -an
and see if there are any open sockets waiting for connection completion.

Frame relay is weird animal that doesn't handle the 1500 byte packets
very well.  I've found that I have to decrease the value of the Max MTU
to get a decent connection.  I've suspected that OSR5 does not do a
proper job of MTU negotiation (but haven't bothered to verify) under
certain circumstances.  

Try this test.  Run:
	ifconfig eth0 mtu 1490
This assumes that eth0 is the name of the ethernet card that eventually
goes to the router.  No need to reboot.  See if the problem goes away.
The new value should be reflected when you run:
	ifconfig -a



-- 
Jeff Liebermann   je...@comix.santa-cruz.ca.us
150 Felker St #D  Santa Cruz CA  95060
831-421-6491 pager   831-429-1240 fax
http://www.cruzio.com/~jeffl/sco/   SCO stuff
 

Comments?

More Articles by Tony Lawrence

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.