Re: [ECOS] Re: FreeBSD-Stack not responding (Update)

[Andrew Lunn <andrew dot lunn at ascom dot ch>]

On Wed, Jul 31, 2002 at 12:11:15PM +0200, Christoph Csebits wrote:
> Sorry something missing at the bottom,
> 
> On Wed, Jul 31, 2002 at 12:02:41PM +0200, Christoph Csebits wrote:
> > hi,
> > 
> > i have a simple time client in ecos,
> > connecting to TCP port 13 of a linux host
> > in the same subnet performing one read
> > and then closing the socket.
> > 
> > i used ethereal to monitor the app
> > with 
> > 
> > the old stack:
> > 
> > ecos > host [SYN]       Seq=4212 Ack=0
> > host > ecos [SYN, ACK]  Seq=6307 Ack=4213
> > ecos > host [ACK]       Seq=4213 Ack=6308
> > host > ecos [PSH, ACK]  Seq=6308 Ack=4213
> > host > ecos [FIN, ACK]  Seq=6334 Ack=4213
> > ecos > host [ACK]       Seq=4213 Ack=6335
> > ecos > host [FIN, ACK]  Seq=4213 Ack=6335
> > host > ecos [ACK]       Seq=6335 Ack=4214
> > 
> > read gives me a time/date string.
> > 
> > and the new stack:
> > 
> > ecos > host [SYN]       Seq=0625 Ack=0
> > host > ecos [SYN, ACK]  Seq=0897 Ack=0626
> > ecos > host [ACK]       Seq=0626 Ack=0898
> > host > ecos [PSH, ACK]  Seq=0898 Ack=0626
> > host > ecos [FIN, ACK]  Seq=0924 Ack=0626
> > ecos > host [ACK]       Seq=0626 Ack=0898    <----- (1)

Here it is acking the data packet, but not the connection close packet.

> > after 3 seconds
> > host > ecos [FIN, PSH, ACK]       Seq=0898 Ack=0626
> > after 6 seconds
> > host > ecos [FIN, PSH, ACK]       Seq=0898 Ack=0626
> > after 12 seconds
> > host > ecos [FIN, PSH, ACK]       Seq=0898 Ack=0626

These are the re-tries from linux to try to close the socket.

> > :
> > 
> read is blocking
> 
> at line (1) the Ack should be 0925, isnt it?
> (pattern matching with the old stack)

Not necessarily. There are many different ways things could be
ordered. The stack could receive the data packet and the close packet
and then send one ACK. Thats what the OpenBSD stack is doing. A second
option is that the stack receives the Data packet and imeadiately ACKs
it before receiving the close packet. It should then ack the close.
 
> what is going wrong here?

I wild guess.....

The close packet is getting lost somewhere before the stack processes
it. There have been reports of ping packets with length % 4 != 0
getting dropped. The close packet could have this problem.

Put some break points into places like ether_input, ip_input,
tcp_input etc and see where the packet gets dropped.

          Andrew

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss