[96] in linux-net channel archive
linux<->linux<->solaris problems persist...
daemon@ATHENA.MIT.EDU (eichin@cygnus.com)
Sat Feb 18 02:48:46 1995
Date: Sat, 18 Feb 95 00:56:05 -0500
To: linux-net@vger.rutgers.edu
Reply-To: eichin@cygnus.com
From: eichin@cygnus.com
Here's a discussion that we've had before on the old NET channel, and
while there were some attempts to diagnose it, it didn't really get
straightened out. Now that .91 is out, I thought I'd give it another
try, since it hasn't "magically disappeared"...
The set up: I've got a linux box acting as a bridge (not really as a
router, which may be the bug :-) talking to a Livingston Portmaster
for a CSLIP connection (MTU 296). The Portmaster is on my office
ethernet (MTU 1500, mask 24/8) and the Linux box is on my home
ethernet (MTU 1500, mask 26/6 -- with published arp entries on the
office net to fake it out; the Portmaster is dumb enough to do the
right thing :-)
The bridge itself has no problem talking with the outside world -- in
particular, it can talk to solaris boxes (and whatever sunsite is.)
When I put another machine on my home net, though (and last I checked
it could be either a linux box or a sun, though I haven't re-unpacked
the sun yet since that experiment) it can talk to most outside
machines (DECstations like TSX-11, SunOS 4 machines in my office) but
loses talking to Solaris machines (in my office, at MIT... and
sunsite -- which is presumably a sun, and based on the tty fields in
finger, probably a solaris system...)
By "loses" I mean a connection is established, small amounts of data
can be exchanged, and then the connection hangs (and is eventually
reset by the solaris side.) While the connection is hung, I get
netstat output like this:
remote solaris box:
Local Address Remote Address Swind Send-Q Rwind Recv-Q State
tweedledumber.klogin pernoctem.1340 14335 1023 9216 0 ESTABLISHED
local linux box:
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp -1 0 pernoctem:1340 tweedledumber:klogin ESTABLISHED
I can try sniffing all packets on one side of the connection, and
possibly both... but does anyone have suggestions as to what to look
for? I know bits and pieces about IP (mostly from sniffing for other
things, which I do professionally :-) but this is a subtlety I've not
before encountered.
(Note that one reason I've isolated the problem to the gateway is that
if I bring the laptop into the office and plug it in there, the
problems go away. I'll also note that there was some mention of
the Solaris 2.x IP layer having some unusual features which might be
coming in to play here, but I don't recall what.)
_Mark_ <eichin@cygnus.com>
