[FS#4008] PPPoE: connect fails if no other interface defined on underlying NIC
openwrt-bugs at lists.openwrt.org
Sun Sep 5 10:18:43 PDT 2021
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Cheddoleum (Cheddoleum)
Attached to Project - OpenWrt/LEDE Project
Summary - PPPoE: connect fails if no other interface defined on underlying NIC
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Medium
Priority - Very Low
Reported Version - openwrt-21.02
Due in Version - Undecided
Due Date - Undecided
Details - If no other interface is defined on the underlying phy device (eg eth1) PPPoE fails to connect and loops continually. Speculatively, the issue seems to be that netifd does not bring up the lower device before starting the daemon; it works by default because another interface is defined for that device, causing it to be live when the pppoe daemon runs.
Steps to reproduce:
On a default installation, WAN and WAN6 are initially defined respectively as DHCP and DHCPV6 interfaces on the same underlying device, eg eth1. Switching the WAN protocol to PPPoE succeeds and connection works as it should.
However, if you delete WAN6, or alter it so that it does not use the same (eg eth1) device, PPPoE will not connect again the next time it's started and will loop.
If you then create a new interface on the WAN's underlying device (eg eth1) using some other protocol which forces the device up, such as static IP using 0.0.0.0/32 as the address, this is sufficient to keep the device alive, and PPPoE works as it should.
Platform: x86_64, Sophos SG-105, Intel e3826 CPU, 4x i211 (igb) NICs, 2GB RAM, 64GB SSD
(Anecdotally, while tracing the issue, the problem appeared to be present even in 19.07.8, but I have not done all he steps to reproduce it in that version.)
More information can be found at the following URL:
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
More information about the openwrt-bugs