On Wed, Jul 29, 2015 at 8:05 AM, Willem de Bruijn [off-list ref] wrote:

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?

As far as I can see you are right, but the real world seems to be different.
My ISP for example lists the PPPoE connection settings, but they are
nowhere mentioning the "service name".

I have also re-read pppd's source code again and that seems to confirm
what you are reading in the RFC: Leaving the service name away makes
seems to violate the RFC, but pppd still accepts those configurations.

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.

Good catch. I would also like to note that the documentation for
"hard_header_len" describes it as "Hardware header length". When the
purpose of this field we should check whether the documentation should
be updated to "Minimum hardware header length" -> that would mean the
condition has to be a "len < hard_header_len" instead of a "len <=
hard_header_len" (as it is now).

PS: I have also added the pppd maintainer (Paul Mackerras) to this
thread because I think he should know about this issue (and he can
probably provide more details if required).
As a quick summary for him: linux  >= 3.19 rejects PADI packets when
no service name is configured.


Regards,
Martin