On Tue, Aug 14, 2001 at 08:06:39PM -0500, Bill Dodd wrote:
> OK, in pcap_read_packet(), there is this code:
>
> packet_len = recvfrom(
> handle->fd, handle->buffer + offset + handle->offset,
> handle->md.readlen - offset, MSG_TRUNC,
> (struct sockaddr *) &from, &fromlen);
>
> handle->buffer was malloced as 2256 bytes (handle->bufsize is 2256), but
> we're telling recvfrom() that the buffer is 16384 (!) bytes long
> (handle->md.readlen is 16384, offset is 0). The recvfrom() is writing
> beyond the 2256 allocated bytes.
>
> handle->bufsize was determined from (MAX_LINKHEADER_SIZE + mtu). My mtu
> is 2000 and MAX_LINKHEADER_SIZE is 256, so this looks right. And
> handle->md.readlen came from handle->snapshot, which came from
> the snaplen passed to pcap_open_live(). nids_init() from libnids
> called pcap_open_live() with a snaplen of 16384.
I've checked in my patch (as Sebastian noted, the duplicate code for
allocating the buffer is ugly and bug-prone), but this still raises the
question "so why is 'recvfrom()' returning more than 2256 bytes?" If the
MTU, as reported by SIOCGIFMTU, is 2000, how can you be getting a packet
bigger than 2000+256? Is the link-layer header bigger than 256 bytes, or
is the SIOCGIFMTU lying about the MTU, or is "recvfrom()" writing past
the actual maximum packet size?
-
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
