Re: PPPoE Modem hangup after random time - how to debug?

Michael Richardson
2020-04-27T02:14:11Z

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

David Balažic <xerces9@gmail.com> wrote:
> Sun Apr 26 17:34:57 2020 daemon.debug pppd[20289]: sent [IPV6CP
> ConfReq id=0x1 <addr fe80::d035:60ed:928e:f741>]
> Sun Apr 26 17:35:00 2020 daemon.debug pppd[20289]: sent [IPV6CP
> ConfReq id=0x1 <addr fe80::d035:60ed:928e:f741>]
> Sun Apr 26 17:35:03 2020 daemon.debug pppd[20289]: sent [IPV6CP
> ConfReq id=0x1 <addr fe80::d035:60ed:928e:f741>]
> 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

Could this be the reason for the hangup?
pppd gets tired of no IPv6, decides it should hangup?

> 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.

> You think NOT putting the interface into promiscuous mode (done by
> tcpdump) would prevent this?
> Anyway, now I startted tcpdump with the -p option: tcpdump -e -v -p
> -i eth1 vlan 3902 and pppoed

It could be that promisc mode (no -p) means that the PADT makes something
break, different than what you are investigating. -p avoid promisc mode, so
would avoid seeing that packet.

You mention in another thread that you were trying to do DHCPv6 on a
different (non-PPPoE) interface. I don't see how that would matter unless
the failure caused netifd to decide to retry it all.

It seems that you ought to try the noipv6 option to pppd.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]