DragonFly bugs List (threaded) for 2004-08
Re: Internet problem after recent rewrite of mbuf
:On 10:15, Mon 09 Aug 04, Matthew Dillon wrote:
:> I don't think it could be the 29 July commit, but it could
:> be one of the later ones.
:I backed out changes to 3 August when the new network code
:went in, and that wasn't the problem.
So you are saying it was something that went in after Aug 3 or are
you saying that it is something that went in on Aug 3 ?
What is the cvs rev on the file /usr/src/sys/netinet/tcp_input.c and
/usr/src/sys/netinet/tcp_output.c of the last known working kernel?
From examining your output the point where it really starts to stall
21:21:04.752575 IP 126.96.36.199.3340 > 188.8.131.52.80: P 909:1389(480) ack 659 win 58400
21:21:06.949765 IP 184.108.40.206.3340 > 220.127.116.11.80: P 909:1389(480) ack 659 win 58400
21:21:07.300225 IP 18.104.22.168.80 > 22.214.171.124.3340: . ack 1389 win 6432
21:21:24.249690 IP 126.96.36.199.80 > 188.8.131.52.3340: . 659:2119(1460) ack 1389 win 6432
What this seems to show is packet loss. Your machine sends a packet but
does not get an ack. Then it sends the packet again.. Then it gets an
ack, then 17 seconds later amazon sends you a data packet.
What I believe is happening is that amazon in fact sent you a data packet
immediately, but the packet was lost, as were a number of retries until
17 seconds later a packet amazon sent actually made it through.
So the question is what is causing the data loss? Could it be serial
port buffer overflows? Check your 'dmesg' output when things fail.
I suspect it is either something like that, which means that it will in
fact work with a later kernel 'sometimes' depending on how fast the
modem negotiates its connection. Or something we did broke ppp.
What makes me suspect a serial port issue is that large packets are
clearly being dropped more often then small packets.
Try reducing the baud rate at which you talk to your modem. I suspect
you have it set to 115200. Try 38400 and try 9600.