>Number:         877
>Category:       kern
>Synopsis:       PPP stops and waits for an ACK before reaching advertized window
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people (Kernel Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 15 04:35:03 1995
>Originator:     Simon J. Gerraty
>Organization:
Zen Programming...
>Release:        1.0
>Environment:
	
System: NetBSD zen.void.oz.au 1.0 NetBSD 1.0 (ZEN) #6: Tue Dec 13 09:55:20 EST 1994 root@zen.void.oz.au:/usr/src/sys/arch/i386/compile/ZEN i386


>Description:
	
Using tcpdump to look at hung ftp sessions over PPP, suggests that
there may indeed be a bug.  

Having remembered that unlike when using NIT on SunOS, tcpdump using
bpf can watch outgoing as well as incoming traffic, so I took some
packet traces.  The results are interesting.

In current-users I wrote:
> seeing over PPP.  Basically lots of data sitting in tcp Send-Q's
> (according to netstat) but nothing being transmitted.
> 
> Now a lost ACK followed by failure of the TCP re-transmission logic
> would account for the symptoms.

But this is not the case.

Again we have an FTP session with lots of data waiting to be sent.

root:3584$ netstat -n | head -20 
Active Internet connections
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0  15104  144.136.188.164.1790   144.136.188.211.20     ESTABLISHED
tcp        0      0  144.136.188.164.1789   144.136.188.211.21     ESTABLISHED

The first trace below shows that after the 1st 256 bytes is ACKed by the
remote end, no further ACKs are received.

Now 256 is a very magic number and we _are_ running over x.25, so I
figured I'd cut the MTU to ensure that we always fit in a single
packet...  the second trace below shows an ftp transfer with MTU=128
so not much data at all gets sent... again, after the initial ACK we
don't receive any more...

The above test plus the fact that I have no trouble getting single
char echo via the same link - in telnet sessions that is, and the fact
that ppp checks for non-8bit clean path, makes me think that whatever
the problem is, is not related to the fact that we are running over
X.25.

One thing that is consitent in each case... we only receive a single
ACK from the remote end.  Why?  Because he is advertising a window.

Now PPP has transmitted 256 bytes and is insisting on an ACK, yet the
advertised window is 24k and we are obviously no where near it.

So why not send more data?  

MTU=296 trace

22:09:37.389637 144.136.188.211.20 > 144.136.188.164.1790: S 76736000:76736000(0) win 24576 <mss 1460>
22:09:37.390720 144.136.188.164.1790 > 144.136.188.211.20: S 1093056000:1093056000(0) ack 76736001 win 16384 <mss 256>
22:09:37.855479 144.136.188.211.20 > 144.136.188.164.1790: . ack 1 win 24576
22:09:38.227658 144.136.188.164.1790 > 144.136.188.211.20: . 1:257(256) ack 1 win 16384 [tos 0x8]
22:09:38.229556 144.136.188.164.1790 > 144.136.188.211.20: . 257:513(256) ack 1 win 16384 [tos 0x8]
22:09:39.159289 144.136.188.211.20 > 144.136.188.164.1790: . ack 257 win 24576
22:09:39.159811 144.136.188.164.1790 > 144.136.188.211.20: . 513:769(256) ack 1 win 16384 [tos 0x8]
22:09:39.160856 144.136.188.164.1790 > 144.136.188.211.20: . 769:1025(256) ack 1 win 16384 [tos 0x8]
22:09:41.479498 144.136.188.164.1790 > 144.136.188.211.20: . 257:513(256) ack 1 win 16384 [tos 0x8]
22:09:46.479369 144.136.188.164.1790 > 144.136.188.211.20: . 257:513(256) ack 1 win 16384 [tos 0x8]
22:09:56.479367 144.136.188.164.1790 > 144.136.188.211.20: . 257:513(256) ack 1 win 16384 [tos 0x8]
22:10:16.479943 144.136.188.164.1790 > 144.136.188.211.20: . 257:513(256) ack 1 win 16384 [tos 0x8]
22:10:56.479568 144.136.188.164.1790 > 144.136.188.211.20: . 257:513(256) ack 1 win 16384 [tos 0x8]
22:12:00.479583 144.136.188.164.1790 > 144.136.188.211.20: . 257:513(256) ack 1 win 16384 [tos 0x8]
22:13:04.479729 144.136.188.164.1790 > 144.136.188.211.20: . 257:513(256) ack 1 win 16384 [tos 0x8]
22:14:08.479573 144.136.188.164.1790 > 144.136.188.211.20: . 257:513(256) ack 1 win 16384 [tos 0x8]


Here is the MTU=128 trace

22:32:24.017826 144.136.188.211.20 > 144.136.188.164.1792: S 251904000:251904000(0) win 24576 <mss 1460>
22:32:24.018929 144.136.188.164.1792 > 144.136.188.211.20: S 1268160000:1268160000(0) ack 251904001 win 16456 <mss 88>
22:32:24.542603 144.136.188.211.20 > 144.136.188.164.1792: . ack 1 win 24576
22:32:24.657870 144.136.188.164.1792 > 144.136.188.211.20: . 1:89(88) ack 1 win 16456 [tos 0x8]
22:32:24.658891 144.136.188.164.1792 > 144.136.188.211.20: . 89:177(88) ack 1 win 16456 [tos 0x8]
22:32:25.291202 144.136.188.211.20 > 144.136.188.164.1792: . ack 177 win 24576
22:32:25.291720 144.136.188.164.1792 > 144.136.188.211.20: . 177:265(88) ack 1 win 16456 [tos 0x8]
22:32:25.292524 144.136.188.164.1792 > 144.136.188.211.20: . 265:353(88) ack 1 win 16456 [tos 0x8]
22:32:25.293010 144.136.188.164.1792 > 144.136.188.211.20: . 353:441(88) ack 1 win 16456 [tos 0x8]
22:32:25.979522 144.136.188.211.20 > 144.136.188.164.1792: . ack 265 win 24576
22:32:25.980010 144.136.188.164.1792 > 144.136.188.211.20: . 441:529(88) ack 1 win 16456 [tos 0x8]
22:32:25.980636 144.136.188.164.1792 > 144.136.188.211.20: . 529:617(88) ack 1 win 16456 [tos 0x8]
22:32:28.979489 144.136.188.164.1792 > 144.136.188.211.20: . 265:353(88) ack 1 win 16456 [tos 0x8]
22:32:34.979357 144.136.188.164.1792 > 144.136.188.211.20: . 265:353(88) ack 1 win 16456 [tos 0x8]
22:32:46.979385 144.136.188.164.1792 > 144.136.188.211.20: . 265:353(88) ack 1 win 16456 [tos 0x8]
22:33:10.979642 144.136.188.164.1792 > 144.136.188.211.20: . 265:353(88) ack 1 win 16456 [tos 0x8]
22:33:58.979555 144.136.188.164.1792 > 144.136.188.211.20: . 265:353(88) ack 1 win 16456 [tos 0x8]

>How-To-Repeat:
	
>Fix:
	
>Audit-Trail:
>Unformatted: