[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+FuTSfw+-6Xb_0xchM5E6vCMSsyiSvSYF3MbuE25pEt07RRbw@mail.gmail.com>
Date: Wed, 29 Jul 2015 02:05:33 -0400
From: Willem de Bruijn <willemb@...gle.com>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: Network Development <netdev@...r.kernel.org>,
Eric Dumazet <edumazet@...gle.com>,
Daniel Borkmann <dborkman@...hat.com>,
David Miller <davem@...emloft.net>, johann.baudy@...-log.net
Subject: Re: [PATCH] packet: Allow packets with only a header (but no payload)
On Mon, Jul 27, 2015 at 6:35 PM, Martin Blumenstingl
<martin.blumenstingl@...glemail.com> wrote:
> Hi Johann,
>
> On Tue, Jul 21, 2015 at 6:51 PM, Willem de Bruijn <willemb@...gle.com> wrote:
>> I don't see a simple way of verifying the safety of allowing packets
>> without data short of a code audit, which would be huge, especially
>> when taking device driver logic into account. Perhaps someone
>> remembers why that statement was added and what edge case(s)
>> it refers to. I'm afraid that I don't. It was added in 69e3c75f4d54. I
>> added the author to this thread.
> I know it's summer (and thus vacation-time), but did you already have
> a chance to look into this?
Martin, to return to your initial statement that PPPoE PADI packets can
have a zero payload: the PPPoE RFC states that PADI packets "MUST
contain exactly one TAG of TAG_TYPE Service-Name, indicating the
service the Host is requesting, and any number of other TAG types."
(RFC 2516, 5.1). Is the observed behavior (no payload) perhaps
incorrect?
Even if it is, if this is breaking established userspace expectations,
we should look into it. Ethernet specifies a minimum payload size of
46 on the wire, but perhaps that is handled with padding, so that
0 length should be valid within the stack. Also, there may be other
valid uses of 0 length payload on top of link layers that are not Ethernet.
>
> Regards,
> Martin
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists