On Wed, Jul 29, 2015 at 8:05 AM, Willem de Bruijn <will...@google.com> 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 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
