(I am not on the mailing list)
This has got to be a bug in the kernel's tcp code....
[root@cericon root]# ifconfig
lo Link encap:Local Loopback
inet addr:127.0.0.1 Bcast:127.255.255.255 Mask:255.0.0.0
UP BROADCAST LOOPBACK RUNNING MTU:3584 Metric:1
RX packets:182879 errors:0 dropped:0 overruns:0 frame:0
TX packets:182879 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
ppp0 Link encap:Point-to-Point Protocol
inet addr:196.34.157.62 P-t-P:168.209.2.65 Mask:255.255.255.0
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:15944 errors:1 dropped:0 overruns:0 frame:0
TX packets:15669 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
Memory:38b1034-38b1c00
[root@cericon root]# tcpdump -i ppp0 -n
tcpdump: listening on ppp0
14:21:40.358887 196.34.157.96.28696 > 196.4.160.12.21: P
2512925526:2512925532(6) ack 938574253 win 32120 (DF)
1 packets received by filter
0 packets dropped by kernel
[root@cericon root]#
what happened here is that the ppp connection went down after a period of
inactivity: i.e. pppd is set on `demand' mode. Then it came up again a
while later for no apparent reason. The only process I had doing ftp was
mc, and these had all been killed.
I then entered the commands shown above.
It also sometimes does the same for .80 - i.e. sending web ACK's even
after the app has closed.
Pppd could get around this problem by not initialising a dialout because
of an ACK packet and not updating its timeout counter because of ack
packets.
-paul
Obsidian Systems . . . . Linux installations, support, networking
[EMAIL PROTECTED] . . . . . . . . . . . . Tel (+27 11) 792 6500
http://www.obsidian.co.za . . . . . . . . Fax (+27 11) 792 6522
__ __ __ __ __ __ __ __
/ / / // |/ // / / / \ \/ /
/ /_ / // /| // /_/ / \ /
/___//_//_/ |_/ \____/ / \
/_/\_\
-
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to [EMAIL PROTECTED]
