Pppd killed on signal 15 after reconnect, repeatedly

fantomas · July 9, 2020, 2:59pm

I have put this into /etc/config/network:

config interface 'wan'
        option pppd_sleep '5'

and I’ll see

anon82920800 · July 9, 2020, 6:00pm

some ISP disconnect every 24 hours and roll over the IP addresses for the subscriber on the subsequent reconnect, thus likely not an issue caused by the router’s software (settings).

fantomas · July 10, 2020, 4:46pm

I know this is the reason I was disconnected. The problem was not that I was disconnected, but the repeated inability to reconnect.
the “force link” option worked, the 10 seconds timeout seems to work, although the sleep is called on two different places:

Jul 10 14:58:22 blah netifd: wan (15541): ppp: warning: Sleeping for '5' seconds
Jul 10 14:58:23 blah netifd: Interface 'wan6' is now down
Jul 10 14:58:23 blah netifd: Interface 'wan6' is disabled
Jul 10 16:58:23 blah kernel: [1123888.843354] mvneta f1034000.ethernet eth2: Link is Down
Jul 10 14:58:23 blah netifd: Network device 'eth2' link is down
Jul 10 14:58:23 blah netifd: Interface 'wan' has link connectivity loss
Jul 10 14:58:23 blah netifd: Interface 'wan' is now down
Jul 10 14:58:23 blah netifd: Interface 'wan' is disabled
Jul 10 16:58:24 blah kernel: [1123888.990128] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Jul 10 16:58:24 blah kernel: [1123888.999864] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Jul 10 16:58:24 blah kernel: [1123889.007398] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Jul 10 14:58:24 blah netifd: Interface 'wan' is enabled
Jul 10 16:58:27 blah kernel: [1123892.199640] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Jul 10 16:58:27 blah kernel: [1123892.207681] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Jul 10 14:58:27 blah netifd: Network device 'eth2' link is up
Jul 10 14:58:27 blah netifd: Interface 'wan' has link connectivity 
Jul 10 14:58:27 blah netifd: Interface 'wan' is setting up now
Jul 10 14:58:27 blah insmod: module is already loaded - slhc
Jul 10 14:58:27 blah insmod: module is already loaded - ppp_generic
Jul 10 14:58:27 blah insmod: module is already loaded - pppox
Jul 10 14:58:27 blah insmod: module is already loaded - pppoe
Jul 10 14:58:27 blah netifd: wan (15729): ppp: warning: Sleeping for '5' seconds

seems that the lowered sleep time is fine. I have no idea if that would work with sleep time lower than 4 seconds though, since the difference between those sleeps is 5 seconds…

anon82920800 · July 11, 2020, 9:37am

If the node is running TOS 5.0.3 you could try instead:

disable the sleep patch (probably option pppd_sleep '0' should do)
add option padi_timeout '30' to the config interface 'wan' section in /etc/config/network (option is not exposed in LuCi)
reboot and see how it works out

fantomas · July 21, 2020, 5:51pm

I do have 5.0.3, but unfortunately, didn’t help. after 151 tries and 16 minutes I have reverted to the sleep option.
What should the padi_timeout cause?

anon82920800 · July 21, 2020, 6:20pm

It is described in the commit messages

Basically it sets a timeout period (in sec, covering the potential time for xDSL line sync with ISP on the modem to complete) between

first Send PPPOE Discovery on the router and
first Recv PPPOE Discovery on the router

prior restarting the discovery process again and therefore mitigate the number of restarts for the discovery process. On my node said timeout period worked out to 20 sec and mitigated the number of discovery process to just one.

But that may not work out for users that have observed the SIGTERM issue in the first place and for whose the sleep patch provides relief, for whatever reason that maybe (e.g. modem’s firmware implementation).

fantomas · July 22, 2020, 3:56pm

maybe it could work, however I see no ‘padi’ related option in pppd:

root@blah:~# strings /usr/sbin/pppd |grep -i padi
root@blah:~# ldd /usr/sbin/pppd
	/lib/ld-musl-armhf.so.1 (0xb6f55000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6edf000)
	libc.so => /lib/ld-musl-armhf.so.1 (0xb6f55000)

maybe in 5.0.4.

yes, the problem apparently lies outside of pppd (netifd kills it too soon)

anon82920800 · July 22, 2020, 4:20pm

check output of strings /lib/netifd/proto/ppp.sh | grep -i padi instead.

The question is whether netifd’s code is at fault or whether it acts on (lack of) signal(s) from the modem. Given that there are few reports however appears no widespread issue amongst the OpenWrt user base.

fantomas · July 22, 2020, 6:39pm

aha it is there. so it’s not pppd but a netifd option.
however I see no padi text in messages (grep -i)

to me it seems that the time to make ppp reconnect is too short and netifd kills pppd prematurely. is padi_timeout supposed to handle this?

i can retry, but it will take time

anon82920800 · July 22, 2020, 7:14pm

whilst it is a netifd invoked script the specified options are are pertinent to ppp and being parsed by UCI, should print with

ps -aux | grep ppp something like (on this node):

[…] /usr/sbin/pppd […] pppoe-padi-timeout 20 […]

That is rather strange, on this node (5.0.3)

strings /lib/netifd/proto/ppp.sh | grep -i padi produces:

proto_config_add_int “padi_attempts”
proto_config_add_int “padi_timeout”
json_get_var padi_attempts padi_attempts
json_get_var padi_timeout padi_timeout
${padi_attempts:+pppoe-padi-attempts $padi_attempts}
${padi_timeout:+pppoe-padi-timeout $padi_timeout} \

It is not clear to me what causes the SIGTERM and I cannot reproduce it with the modem on this node (different modem)

To get a better look it could be helpful to provide debug output for netifd which requires to manipulate /etc/init.d/network in the start_service() section though:

- procd_set_param command /sbin/netifd
+ procd_set_param command /sbin/netifd -l 5
+ procd_set_param stderr 1

fantomas · August 2, 2020, 6:29pm

tried, (without the padi thing) we’ll see

fantomas · August 3, 2020, 6:48pm

nothing useful here:

Aug  3 18:28:53 blah pppd[5687]: LCP terminated by peer
Aug  3 18:28:53 blah pppd[5687]: Connect time 1440.1 minutes.
Aug  3 18:28:53 blah pppd[5687]: Sent 359624587 bytes, received 1548661586 bytes.
Aug  3 18:28:53 blah netifd: Network device 'pppoe-wan' link is down
Aug  3 18:28:53 blah netifd: Network alias 'pppoe-wan' link is down
Aug  3 18:28:53 blah netifd: Interface 'wan6' has link connectivity loss
Aug  3 18:28:53 blah pppd[5687]: Modem hangup
Aug  3 18:28:53 blah pppd[5687]: Connection terminated.
Aug  3 18:28:53 blah netifd: Interface 'wan' has lost the connection
Aug  3 18:28:53 blah pppd[5687]: Sent PADT
Aug  3 18:28:53 blah pppd[5687]: Exit.
Aug  3 18:28:53 blah netifd: Interface 'wan' is now down
Aug  3 20:28:53 blah kernel: [86414.702281] mvneta f1034000.ethernet eth2: Link is Down
Aug  3 18:28:53 blah netifd: Interface 'wan' is disabled
Aug  3 20:28:53 blah kernel: [86414.812589] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Aug  3 20:28:53 blah kernel: [86414.822048] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Aug  3 20:28:53 blah kernel: [86414.829456] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Aug  3 20:28:53 blah kernel: [86414.835473] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Aug  3 18:28:53 blah netifd: Interface 'wan' is enabled
Aug  3 18:28:53 blah netifd: Interface 'wan' is setting up now
Aug  3 18:28:53 blah insmod: module is already loaded - slhc
Aug  3 18:28:53 blah insmod: module is already loaded - ppp_generic
Aug  3 18:28:53 blah insmod: module is already loaded - pppox
Aug  3 20:28:53 blah kernel: [86414.869045] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Aug  3 18:28:53 blah insmod: module is already loaded - pppoe
Aug  3 18:28:53 blah pppd[31234]: Plugin rp-pppoe.so loaded.
Aug  3 18:28:53 blah pppd[31234]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Aug  3 18:28:53 blah pppd[31234]: pppd 2.4.7 started by root, uid 0
Aug  3 18:28:54 blah netifd: Interface 'wan6' is now down
Aug  3 18:28:54 blah netifd: Interface 'wan6' is disabled
Aug  3 20:28:54 blah kernel: [86415.995383] mvneta f1034000.ethernet eth2: Link is Down
Aug  3 18:28:54 blah netifd: Network device 'eth2' link is down
Aug  3 18:28:54 blah netifd: Interface 'wan' has link connectivity loss
Aug  3 20:28:56 blah kernel: [86418.072117] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Aug  3 18:28:56 blah netifd: Network device 'eth2' link is up
Aug  3 18:28:56 blah netifd: Interface 'wan' has link connectivity 

Aug  3 18:28:59 blah netifd: Interface 'wan' is now down
Aug  3 20:28:59 blah kernel: [86421.009192] mvneta f1034000.ethernet eth2: Link is Down
Aug  3 18:28:59 blah netifd: Interface 'wan' is disabled
Aug  3 20:29:00 blah kernel: [86421.122151] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Aug  3 20:29:00 blah kernel: [86421.131085] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Aug  3 20:29:00 blah kernel: [86421.138500] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Aug  3 20:29:00 blah kernel: [86421.146908] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Aug  3 18:29:00 blah netifd: Interface 'wan' is enabled
Aug  3 18:29:00 blah netifd: Interface 'wan' is setting up now
Aug  3 20:29:00 blah kernel: [86421.158393] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Aug  3 18:29:00 blah insmod: module is already loaded - slhc
Aug  3 18:29:00 blah insmod: module is already loaded - ppp_generic
Aug  3 18:29:00 blah insmod: module is already loaded - pppox
Aug  3 18:29:00 blah insmod: module is already loaded - pppoe
Aug  3 18:29:00 blah pppd[31511]: Plugin rp-pppoe.so loaded.
Aug  3 18:29:00 blah pppd[31511]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Aug  3 18:29:00 blah pppd[31511]: pppd 2.4.7 started by root, uid 0

… I wonder if it’s something with wan vs. wan6
not even the “terminating…” message.
the “sleep” option is set to 0, “force link” is disabled.

anon82920800 · August 3, 2020, 7:01pm

is it wan6 or wan_6 interface (ubus list network.interface.wa*)?

fantomas · August 3, 2020, 7:03pm

wan6… standard on turris unless I remove it. It’s quoted above

anon82920800 · August 3, 2020, 7:28pm

For whatever inexplicable reason that is it is however deviating from OpenWrt but the TOS developer contested such by implying re/Foris compatibility issues.

Not sure whether it would make a difference but if you want to make the effort you could try instead the WAN setup according to OpenWrt default which would automatically spawn wan_6 instead.

One more thing - been mentioned earlier in this thread - unless your ISP is providing ds-lite there would be no need for the ds-lite package being present on the node and therefore suggest to remove it.

fantomas · August 3, 2020, 8:09pm

that could make a difference e.g. if the problem was hidden in multiple definition of WAN interface and it there was special handling for interface names with _* extension

the first case can be simply verified by disabling wan6

I haven’t noticed this one before (this was reply to someone other’s note).
the ds-lite package was preinstalled, do you have reason to believe it can cause troubles?

anon82920800 · August 3, 2020, 8:21pm

Depends on the ISP back-end for the subscriber line - if both, native dual-stack and ds-lite, being served on the same subscriber line it will cause some grievance.

If you decide to test with auto IPv6 perhaps use the padi_timeout along with it.

fantomas · August 5, 2020, 2:05pm

so far (without padi_timeout) I can’t find any explanation. Even logs don’t show “Terminating on signal 15” anymore.
I’ll test again with padi_timeout (has started), and then will try disabling wan6 or removing ds-lite

Aug  4 19:04:44 blah pppd[5577]: rcvd [LCP TermReq id=0x3]
Aug  4 19:04:44 blah pppd[5577]: LCP terminated by peer
Aug  4 19:04:44 blah pppd[5577]: Connect time 1440.1 minutes.
Aug  4 19:04:44 blah pppd[5577]: Sent 1323003116 bytes, received 1650086503 bytes.
Aug  4 19:04:44 blah netifd: Network device 'pppoe-wan' link is down
Aug  4 19:04:44 blah netifd: Network alias 'pppoe-wan' link is down
Aug  4 19:04:44 blah netifd: Interface 'wan6' has link connectivity loss
Aug  4 19:04:44 blah pppd[5577]: Script /lib/netifd/ppp-down started (pid 483)
Aug  4 19:04:44 blah pppd[5577]: sent [LCP TermAck id=0x3]
Aug  4 19:04:44 blah pppd[5577]: Modem hangup
Aug  4 19:04:44 blah pppd[5577]: Connection terminated.
Aug  4 19:04:44 blah netifd: Interface 'wan' has lost the connection
Aug  4 19:04:44 blah pppd[5577]: Send PPPOE Discovery V1T1 PADT session 0x93bc length 28
Aug  4 19:04:44 blah pppd[5577]:  dst 7c:ad:74:f2:2f:30  src d8:58:d7:00:ac:39
Aug  4 19:04:44 blah pppd[5577]:  [host-uniq  c9 15 00 00] [AC-cookie  aa f7 b9 0e 15 29 fc f2 c6 3e a6 6e 29 ef 58 80]
Aug  4 19:04:44 blah pppd[5577]: Sent PADT
Aug  4 19:04:44 blah pppd[5577]: Script /lib/netifd/ppp-down finished (pid 483), status = 0x1
Aug  4 19:04:44 blah pppd[5577]: Exit.
Aug  4 19:04:44 blah netifd: Interface 'wan' is now down
Aug  4 21:04:44 blah kernel: [86414.810639] mvneta f1034000.ethernet eth2: Link is Down
Aug  4 19:04:44 blah netifd: Interface 'wan' is disabled
Aug  4 21:04:44 blah kernel: [86414.942998] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Aug  4 21:04:44 blah kernel: [86414.951788] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Aug  4 21:04:44 blah kernel: [86414.959182] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Aug  4 21:04:44 blah kernel: [86414.965462] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Aug  4 19:04:44 blah netifd: Interface 'wan' is enabled
Aug  4 19:04:44 blah netifd: Interface 'wan' is setting up now
Aug  4 21:04:44 blah kernel: [86414.976030] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Aug  4 19:04:44 blah pppd[576]: Plugin rp-pppoe.so loaded.
Aug  4 19:04:44 blah pppd[576]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Aug  4 19:04:45 blah pppd[576]: pppd 2.4.7 started by root, uid 0
Aug  4 19:04:45 blah pppd[576]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Aug  4 19:04:45 blah pppd[576]:  dst ff:ff:ff:ff:ff:ff  src d8:58:d7:00:ac:39
Aug  4 19:04:45 blah pppd[576]:  [service-name] [host-uniq  40 02 00 00]
Aug  4 19:04:45 blah netifd: Interface 'wan6' is now down
Aug  4 19:04:45 blah netifd: Interface 'wan6' is disabled
Aug  4 21:04:46 blah kernel: [86416.095858] mvneta f1034000.ethernet eth2: Link is Down
Aug  4 19:04:46 blah netifd: Network device 'eth2' link is down
Aug  4 19:04:46 blah netifd: Interface 'wan' has link connectivity loss
Aug  4 19:04:48 blah netifd: Network device 'eth2' link is up
Aug  4 19:04:48 blah netifd: Interface 'wan' has link connectivity 
Aug  4 21:04:48 blah kernel: [86418.172598] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Aug  4 19:04:51 blah netifd: Interface 'wan' is now down
Aug  4 21:04:51 blah kernel: [86421.108990] mvneta f1034000.ethernet eth2: Link is Down
Aug  4 19:04:51 blah netifd: Interface 'wan' is disabled
Aug  4 21:04:51 blah kernel: [86421.222628] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Aug  4 21:04:51 blah kernel: [86421.231418] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Aug  4 21:04:51 blah kernel: [86421.238886] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Aug  4 21:04:51 blah kernel: [86421.244913] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Aug  4 19:04:51 blah netifd: Interface 'wan' is enabled
Aug  4 19:04:51 blah netifd: Interface 'wan' is setting up now
Aug  4 21:04:51 blah kernel: [86421.253754] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Aug  4 19:04:51 blah pppd[864]: Plugin rp-pppoe.so loaded.

fantomas · August 6, 2020, 1:27pm

no success with padi_timeout.
I have removed the wan6 interface, since disabling ipv6 via foris just set “option ipv6 ‘0’”

It seems that disabling ipv6 via foris, which causes restarting network initiates the problem, pppd starts flapping.

This happens even when I remove wan6 interface.

fantomas · August 7, 2020, 2:29pm

summary:

no change with:
padi_timeout 30
disabling wan6 + disabling ipv6.

helped:
option pppd_sleep ‘5’ (or default 10)
option force_link ‘1’

… either one.

wan config

config interface ‘wan’
option ifname ‘eth2’
option proto ‘pppoe’
option username REDACTED
option password REDACTED
option padi_timeout ‘30’
option pppd_sleep ‘0’
option pppd_options ‘debug kdebug 7’

pppd reconnect log

Aug 7 13:25:01 blah pppd[5680]: rcvd [LCP TermReq id=0x2]
Aug 7 13:25:01 blah pppd[5680]: LCP terminated by peer
Aug 7 13:25:01 blah pppd[5680]: Connect time 1440.1 minutes.
Aug 7 13:25:01 blah pppd[5680]: Sent 466153870 bytes, received 401546033 bytes.
Aug 7 13:25:01 blah netifd: Network device ‘pppoe-wan’ link is down
Aug 7 13:25:01 blah pppd[5680]: Script /lib/netifd/ppp-down started (pid 29393)
Aug 7 13:25:01 blah pppd[5680]: sent [LCP TermAck id=0x2]
Aug 7 13:25:01 blah pppd[5680]: Modem hangup
Aug 7 13:25:01 blah pppd[5680]: Connection terminated.
Aug 7 13:25:01 blah netifd: Interface ‘wan’ has lost the connection
Aug 7 13:25:01 blah pppd[5680]: Send PPPOE Discovery V1T1 PADT session 0xc74d length 28
Aug 7 13:25:01 blah pppd[5680]: dst 7c:ad:74:f2:2f:30 src d8:58:d7:00:ac:39
Aug 7 13:25:01 blah pppd[5680]: [host-uniq 30 16 00 00] [AC-cookie aa f7 b9 0e 15 29 fc f2 c6 3e a6 6e 29 ef 58 80]
Aug 7 13:25:01 blah pppd[5680]: Sent PADT
Aug 7 13:25:01 blah pppd[5680]: Script /lib/netifd/ppp-down finished (pid 29393), status = 0x1
Aug 7 13:25:01 blah pppd[5680]: Exit.
Aug 7 13:25:01 blah netifd: Interface ‘wan’ is now down
Aug 7 15:25:01 blah kernel: [86415.088954] mvneta f1034000.ethernet eth2: Link is Down
Aug 7 13:25:01 blah netifd: Interface ‘wan’ is disabled
Aug 7 15:25:01 blah kernel: [86415.104439] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Aug 7 15:25:01 blah kernel: [86415.202684] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Aug 7 15:25:01 blah kernel: [86415.211482] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Aug 7 15:25:01 blah kernel: [86415.219199] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Aug 7 13:25:01 blah netifd: Interface ‘wan’ is enabled
Aug 7 13:25:01 blah netifd: Interface ‘wan’ is setting up now

Aug 7 13:25:01 blah pppd[29476]: Plugin rp-pppoe.so loaded.
Aug 7 13:25:01 blah pppd[29476]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Aug 7 13:25:01 blah pppd[29476]: pppd 2.4.7 started by root, uid 0
Aug 7 13:25:01 blah pppd[29476]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Aug 7 13:25:01 blah pppd[29476]: dst ff:ff:ff:ff:ff:ff src d8:58:d7:00:ac:39
Aug 7 13:25:01 blah pppd[29476]: [service-name] [host-uniq 24 73 00 00]
Aug 7 15:25:02 blah kernel: [86416.405561] mvneta f1034000.ethernet eth2: Link is Down
Aug 7 13:25:02 blah netifd: Network device ‘eth2’ link is down
Aug 7 13:25:02 blah netifd: Interface ‘wan’ has link connectivity loss
Aug 7 15:25:04 blah kernel: [86418.482222] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Aug 7 13:25:04 blah netifd: Network device ‘eth2’ link is up
Aug 7 13:25:04 blah netifd: Interface ‘wan’ has link connectivity
Aug 7 13:25:07 blah netifd: Interface ‘wan’ is now down
Aug 7 15:25:07 blah kernel: [86421.421843] mvneta f1034000.ethernet eth2: Link is Down
Aug 7 13:25:07 blah netifd: Interface ‘wan’ is disabled
Aug 7 15:25:07 blah kernel: [86421.435149] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Aug 7 15:25:08 blah kernel: [86421.542295] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Aug 7 15:25:08 blah kernel: [86421.551085] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Aug 7 15:25:08 blah kernel: [86421.558608] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Aug 7 13:25:08 blah netifd: Interface ‘wan’ is enabled
Aug 7 13:25:08 blah netifd: Interface ‘wan’ is setting up now

Aug 7 13:25:08 blah pppd[29702]: Plugin rp-pppoe.so loaded.
Aug 7 13:25:08 blah pppd[29702]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Aug 7 13:25:08 blah pppd[29702]: pppd 2.4.7 started by root, uid 0
Aug 7 13:25:08 blah pppd[29702]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Aug 7 13:25:08 blah pppd[29702]: dst ff:ff:ff:ff:ff:ff src d8:58:d7:00:ac:39
Aug 7 13:25:08 blah pppd[29702]: [service-name] [host-uniq 06 74 00 00]

I’m going to comment https://gitlab.nic.cz/turris/turris-build/-/issues/107