On Tue, Dec 29, 2009 at 02:51:00PM +0200, Denis Doroshenko wrote: > Hi, > > as I mentioned earlier, I have a test FTP/HTTP server running > OpenBSD-current on HP notebook Compaq nc6000, and I increased tcp send > space to make it send stuff faster. > > In my earlier mail I mentioned, that when it sends stuff really fast > (a box besides downloads a file via fast ethernet link) bge0 stops > transmission (my ssh sessions pauses too) and I see a warning on the > console about bge watchdog timeout and reset of the device. If the > transmission of data is stopped by the time the bge resets, it > recovers. Otherwise it freezes for some time with the watchdog warning > again. > > Today I tried to download a 4MB file from nearby test linux server to > that FTP server of mine and had > > tcpdump -i eth0 -s 2000 -w capture.pcap host linux.test.server > > command running and then I find difference between the results of > tcpdump run on the linux server and the one run on OpenBSD. The linux > one shows 4847 packets captured, OpenBSD one shows 4505. Also OpenBSD > capture loaded in Wireshark (ver. 1.2.2) shows several bunches of TCP > ACK entitled "TCP ACKed lost segment". This is the conclusion of the > Wireshark TCP analysis, which says the capture file contains ACKs to a > TCP segments that are missing from the capture file. > > The server IPv4 setup is trivial, static IP, static default route. The > server also has gif0 configured to a IPv6 provider (if it counts > here), with IPv6 default route being set to the tunnel. The box also > has a pf ruleset that allows SSH inside from particular hosts and does > pass out [keep state], block in. > > Can it be that BPF isn't getting all the packets being sent? >
BPF is implemented as a ring buffer if it overflows it will drop packets. That's why tcpdump is printing the statistics at the end: 4 packets received by filter 0 packets dropped by kernel If you tcpdump with a snapsize of 2000 as shown above you will run out of the default bpf bufsize very quickly since the default is 32k and I guess you cranked up your tcp buffers to much bigger numbers so that bpf has no chance to queue the incomming packets, call userland and be done with them before the 32k buffer overflows. You may want to look into sysctl net.bpf.bufsize. -- :wq Claudio
