[3119] in linux-net channel archive

home help back first fref pref prev next nref lref last post

Re: Linux TCP/IP wedges talking to DG AViiON

daemon@ATHENA.MIT.EDU (Thomas Koenig)
Wed Jun 5 15:21:19 1996

To: submit-linux-dev-net@ratatosk.yggdrasil.com
From: ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig)
Date: 	5 Jun 1996 15:03:22 +0200
Reply-To: Thomas.Koenig@ciw.uni-karlsruhe.de

In linux.dev.net, Kris Karas <ktk@ktk.bih.harvard.edu> wrote:

>14:16:40.703796 AViiON.smtp > Linux.1105: . ack 7788 win 511
>14:16:40.903796 Linux.1105 > AViiON.smtp: P 7788:8299(511) ack 210 win 29696
>14:16:40.913796 AViiON.smtp > Linux.1105: . ack 8299 win 963
>14:16:40.913796 Linux.1105 > AViiON.smtp: P 7788:8556(768) ack 210 win 29696
>14:16:40.913796 AViiON.smtp > Linux.1105: . ack 8299 win 963
>14:16:41.103796 Linux.1105 > AViiON.smtp: P 7788:8556(768) ack 210 win 29696
>14:16:41.113796 AViiON.smtp > Linux.1105: . ack 8299 win 963

Somehow, the AViiON isn't getting that package.

What does a dump look like on the AViiON side?  Is there some gateway
in between which throws away packets larger than 512 bytes, for
example?  Is somebody fragmenting IP packets, and the AViiON has
problems with that?

Did you turn on MTU path discovery in your kernel?  I don't see any DF
flags sent from the Linux side - this might help if there's a problem
with IP fragmentation somewhere.

As a (VERY UGLY) workaround, you could set the MTU of your Linux box
to a smaller value.


home help back first fref pref prev next nref lref last post