linux-ppp.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Carlson <carlsonj@workingcode.com>
To: linux-ppp@vger.kernel.org
Subject: Re: PPPoE Modem hangup after random time - how to debug?
Date: Mon, 27 Apr 2020 13:43:06 +0000	[thread overview]
Message-ID: <92e78022-55ca-862c-fcda-3f728be89774@workingcode.com> (raw)
In-Reply-To: <CAPJ9Yc8Wvxb_UoqGu=wrrWX2HP5AwE98jvcS3XYnvevxa0RZpg@mail.gmail.com>

On 2020-04-26 15:03, David Balažic wrote:
> tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size
> 262144 bytes
> 17:34:34.805424 a4:7b:2c:9e:c7:44 (oui Unknown) > 44:4e:6d:fd:c7:39
> (oui Unknown), ethertype 802.1Q (0x8100), length 60: vlan 3902, p 1,
> ethertype PPPoE D, PPPoE PADT [ses 0x1]
> 17:34:34.815673 c4:3d:c7:90:ce:ed (oui Unknown) > a4:7b:2c:9e:c7:44
> (oui Unknown), ethertype 802.1Q (0x8100), length 52: vlan 3902, p 0,
> ethertype PPPoE D, PPPoE PADT [ses 0x1] [Host-Uniq 0x00003003]
> [AC-Cookie 0xED****************************75]
> tcpdump: pcap_loop: The interface went down
[...]
> Sun Apr 26 17:34:35 2020 daemon.debug pppd[20289]:  dst
> c4:XX:XX:XX:XX:ed  src a4:XX:XX:XX:XX:44

That's really good evidence right there.  It certainly looks like the
Roaring Penguin PPPoE kernel driver is blindly accepting a bad PADT
packet meant for someone else.  Your peer probably shouldn't have sent
this down the line to you, but that's another matter.

I don't maintain the RP software, but I have a guess.  Either something
on the system is keeping the Ethernet driver itself in promiscuous mode,
or some defect in the driver allows non-matching non-multicast
destinations to be sent up the receive pipe.

Either way, it's usually responsibility of the receiving protocol
software after ethertype demux (in this case, the PPPoE implementation,
and NOT the PPP code) to validate that the addresses are correct when
necessary.  It's not the driver's problem.

I think the PPPoE code may be missing a check here.  This looks like a
bug to me.

> Sun Apr 26 17:35:06 2020 daemon.debug pppd[20289]: sent [IPV6CP
> ConfReq id=0x1 <addr fe80::d035:60ed:928e:f741>]
> Sun Apr 26 17:35:09 2020 daemon.warn pppd[20289]: IPV6CP: timeout
> sending Config-Requests

I don't think this is causing the problem, but it's interesting evidence
nonetheless.  If the peer you're talking to actually implemented PPP in
a reasonable manner, it would send LCP Protocol-Reject in response to
your attempt to negotiate IPV6CP rather than just ignoring you.  The
peer isn't healthy.  Not much you can do about it at this point (other
than disabling IPv6 on your side with "noipv6"), but still interesting.

> The strange part is in the tcpdump there is a PADT sent to an
> "unknown" MAC and my pppd responds. At least that is how I see it.

Yes, EXCEPT that pppd isn't involved at all.  PADT is part of the PPPoE
protocol, not PPP.  pppd doesn't know anything about this.  It's the
rp-pppoe software that's responding improperly.  As I suggested
previously in a private message, I think you should discuss the problem
with the maintainers of the PPPoE stuff.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

  parent reply	other threads:[~2020-04-27 13:43 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-22 17:45 PPPoE Modem hangup after random time - how to debug? David Balažic
2020-04-22 19:51 ` Michael Richardson
2020-04-22 22:00 ` James Carlson
2020-04-23  0:08 ` Guillaume Nault
2020-04-23  0:41 ` Michael Richardson
2020-04-23  2:01 ` James Carlson
2020-04-23 10:37 ` David Balažic
2020-04-23 11:12 ` David Balažic
2020-04-23 12:13 ` David Balažic
2020-04-23 15:59 ` Michael Richardson
2020-04-23 16:01 ` Michael Richardson
2020-04-24 13:47 ` David Balažic
2020-04-24 14:02 ` David Balažic
2020-04-24 14:26 ` James Carlson
2020-04-24 15:44 ` Guillaume Nault
2020-04-24 15:54 ` Guillaume Nault
2020-04-26  1:38 ` Michael Richardson
2020-04-26 12:44 ` David Balažic
2020-04-26 12:48 ` David Balažic
2020-04-26 19:03 ` David Balažic
2020-04-27  2:14 ` Michael Richardson
2020-04-27  9:59 ` David Balažic
2020-04-27 13:43 ` James Carlson [this message]
2020-04-27 20:08 ` Guillaume Nault
2020-04-27 20:30 ` Guillaume Nault
2020-04-27 23:34 ` David Balažic
2020-04-28 10:18 ` David Balažic
2020-04-28 11:00 ` Guillaume Nault
2020-04-29 11:58 ` David Balažic
2020-05-03 10:31 ` David Balažic
2020-05-04 12:27 ` Guillaume Nault
2020-05-04 13:01 ` Guillaume Nault
2020-05-04 15:54 ` David Balažic
2020-05-04 16:36 ` David Balažic
2020-05-04 18:11 ` Guillaume Nault
2020-05-04 18:43 ` David Balažic
2020-05-06  9:52 ` David Balažic
2020-05-06 10:34 ` David Balažic
2020-05-06 14:26 ` Guillaume Nault
2020-05-06 15:02 ` Guillaume Nault
2020-05-06 15:15 ` James Carlson
2020-05-06 15:39 ` David Balažic
2020-05-06 15:54 ` David Balažic
2020-05-06 20:20 ` Guillaume Nault

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=92e78022-55ca-862c-fcda-3f728be89774@workingcode.com \
    --to=carlsonj@workingcode.com \
    --cc=linux-ppp@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).