Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Nov 2001 10:37:26 -0600 (CST)
From:      Jonathan Lemon <jlemon@flugsvamp.com>
To:        rizzo@aciri.org, net@freebsd.org
Subject:   Re: Garbage tacked onto end of packet
Message-ID:  <200111211637.fALGbQX69784@prism.flugsvamp.com>
In-Reply-To: <local.mail.freebsd-net/20011121060557.A32497@iguana.aciri.org>
References:  <local.mail.freebsd-net/xzpvgg44553.fsf@flood.ping.uio.no>

next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-net/20011121060557.A32497@iguana.aciri.org> you write:
>[Bcc to Przemyslaw Frasunek who submitted the example in case
>he can tell what hardware was involved]
>
>On Wed, Nov 21, 2001 at 02:36:56PM +0100, Dag-Erling Smorgrav wrote:
>> http://lcamtuf.coredump.cx/mobp/
>> 
>> See Exhibit 5.  Is this a known bug?
>
>Looks more like one or more bugs in a specific device driver, tcpdump or bpf.
>
>Here we have a short IP packet (44 bytes) which is later shown as having
>46 and then 64 bytes.
>
>On the wire, ethernet frames are supposed to have at least 64 bytes (including
>CRC ?) which is exactly 14+46+4 -- so the second example makes perfect sense,
>it is the only legal format of such a frame coming from an ethernet interface.
>
>As for the third one, it might well be that some device driver misinterprets
>the padding (possibly on the output side) and tries to generate 64-bytes
>in addition to the headers.

Yup.  My guess is the first (short) packet was captured on the originating
host, so bpf saw it before it hit the wire.  The driver should have padded
the packet out to 64 bytes on transmission, and the second hop sees the 
correct (64 - 14 - 4 = 46 byte) payload.

I'm not sure what the third system is doing; it looks like it is returning
the total packet length, unadjusted for the ethernet headers, which would
be a driver bug.  However, this is harmless in this case, since the system
is using the length from the IP header, not the mbuf length.  It isn't clear
if the third system is even a FreeBSD box.
-- 
Jonathan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111211637.fALGbQX69784>