On Thu, 23 Aug 2001, Guy Harris wrote:
> 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?
Good question. I was wondering about that as well after I sent my original
note. This was on a 16Mb token ring network, and the apparently default
mtu for the driver I'm using is 2000. I was regularly seeing packets that
were between 4000 and 4500 bytes. I changed the mtu to 4500, but would
still occasionally see even bigger packets. Seems like the actual maximum
packet size for 16Mb token ring is something like 16k or 18k.
Thanks,
-bill
-
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
