[RP-PPPoE] Unexpected connection termination - stray PADT
David Balažic
xerces9 at gmail.com
Thu Apr 30 09:36:27 EDT 2020
Hi!
Just a few more questions.
It seems (as I am not a kernel hacker) OpenWRT uses the kernel pppoe module.
That is the file linux-4.14.171/drivers/net/ppp/pppoe.c if I'm not mistaken.
It seems, it does not check the DST addr of the received PADT packet
(it checks src addr and session id for match).
What is the angle from the standards point of view? Should/must the
dst addr be checked?
Or is it something that emerged from users experience?
IOW: why does the rp-ppoe code do this? (following the standard, or
fixing a user reported problem, something else?)
Regards,
David
On Mon, 27 Apr 2020 at 18:19, Dianne Skoll <dianne at skoll.ca> wrote:
>
> Hi,
>
> The comment on that list is wrong; it's not an RP-PPPoE bug.
> We do check to make sure the PADT is for the right session,
> that it's destined for our MAC and that the source is our
> peer's MAC.
>
> Relevant code is below. The code has been this way
> since July 13, 2001, so unless your router is running
> truly ancient or forked-from-ancient software, it
> isn't an RP-PPPoE bug.
>
> Regards,
>
> Dianne.
>
> /* It's a PADT, all right. Is it for us? */
> if (packet->session != Connection->session) {
> /* Nope, ignore it */
> return;
> }
> if (memcmp(packet->ethHdr.h_dest, Connection->myEth, ETH_ALEN)) {
> return;
> }
>
> if (memcmp(packet->ethHdr.h_source, Connection->peerEth, ETH_ALEN)) {
> return;
> }
More information about the RP-PPPoE
mailing list