> I'll look at cleaning the code up so that it doesn't assume that the MTU
> is also the MRU.
Oh, hell. There's no obvious way to dredge the MRU out of the kernel.
Fortunately, it appears that, on 2.2 and later kernels, you can just
pass the snapshot length as the argument to "recvfrom()", and still get
the *actual* length (rather than the number of bytes read) as the return
value, so the MRU isn't relevant there.
In 2.0[.x] kernels, a "recvfrom()" on a SOCK_PACKET socket, with
MSG_TRUNC set, returns the number of bytes read, not the number of bytes
that were in the packet, so, on those kernels, we read the entire packet
and truncate it ourselves. On those kernels, the buffer needs to be big
enough to hold an MRU-sized packet, i.e. MRU+link-layer header; we could
either assume the MRU is the same as the MTU, or infer the MRU from the
link-layer type.
Packet capture on 2.0[.x] kernels sucks for other reasons, so I'm
inclined not to try to get fancy and infer the MRU; the current CVS code
works fine on 2.2 and later kernels. (We could, I guess, just set the
buffer size to the snapshot length on 2.2 and later kernels, which might
save some memory if you use a small snapshot, but that's just a
refinement.)
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
