On May 27, 2011, at 5:20 AM, ri...@happyleptic.org wrote: > If I understand this code correctly, in the next release of the libpcap > if a client program ask for a capture length bigger than the MTU then > the size allocated for each frame in the ring buffer will be sized down > to avoid wasting space ?
If, for a device that's supplying frames with Ethernet headers, and that's not doing any form of offloading that might lead to oversized "packets" being delivered, a program asks for a capture length bigger than the current MTU + 18, the size allocated for each frame in the ring buffer will be sized down. That's not currently being done for any other link-layer type, as the "+ 18" part is necessary - the frame size needs to be large enough to include not just the payload but the link-layer header (and, in case it happens to get delivered, the CRC), and the MTU for an interface is the size of the largest chunk of data that can be handed to the Ethernet layer to have the header and CRC added, i.e. it's 1500 for non-jumbo-frame Ethernet, and that's not big enough for a maximum-sized Ethernet packet. I also say "current MTU" because, if you don't have jumbo frames turned on when the capture starts, and turn it on while it's capturing, the ring buffer won't be reconstructed with a newer larger frame size. > If so then I just have to wait for the new libpcap :-) Yes, but I'm just guessing that this is the cause of the packet drops people are seeing with the ring buffer enabled; I could try spraying a Linux VM from the host, and see whether that causes packet drops with the older ring buffer code and not with the new ring buffer code, but that might not count as a "real live" test, so you might want to see whether, for example, just hardwiring the snaplen to 1514 or 1518 in the program you're using improves things, as a quick test.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
