David Balažic <xerces9@xxxxxxxxx> 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@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
