You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I can confirm this happens on EdgeRouter X and AMD64. I'm currently using a Ryzen 3100 with OpenWRT 21.02.0-rc1.
When we configure WAN interfaces, we create them and point to a ifname. In my example, for a ISP that uses DHCP, I create interfaces //wan_mrd// and //wan_mrd6// both using ifname //eth2//. When we're gonna use softwares like ping, traceroute and curl that support specifying the interface, I'd use ping -I eth2.
But when a WAN uses PPPoE, apart from the interface name, OpenWRT creates a second name on the format pppoe-. In example, I have another ISP on port //eth3//, then on config I create interfaces named //want// and //want6//. Then when I use ping I must use ping -I pppoe-want.
If I use ping -I eth3 it fails with message ping: connect: Permission denied. ping -I want fails with ping: unknown iface: want.
Oddly, //pppoe-want// works for IPv6 too. There were times that even //pppoe-want// resulted on Permission denied, I don't know what had changed and it's working at the moment.
I don't know why it was implemented this way and how to fix it or improve its compatibility. I guess there's a reason, or PPPoE connections would just use the port ifname as other protocols do.
The text was updated successfully, but these errors were encountered:
Why is that? Could you suggest some article explaining how it works?
I can't refer to any article explaining this particular detail but it is an essential property of encapsulated protocols. PPPoE is PPP protocol frames encapsulated in ethernet frames. The ethX interface receives the raw, encapsulated traffic which is processed and unwrapped by the kernel and the resulting decapsulated traffic is sent to another network device, pppoe-wan in the case of OpenWrt or ppp0 on normal Desktop Linux distros.
This mechanism is the same for any kind of tunneling or encapsulation protocol like OpenVPN, gre, ipip tunnels, PPPoE and numerous others.
And if it's expected, why are mwan3 and ddns having trouble with it?
I don't know, maybe because the authors naively assumed that layer 2 netdev == layer 3 netdev in all cases, but as you noticed, that is not necessarily the case, e.g. for PPPoE links. Note that neither package is maintained in OpenWrt base, so there's nothing we can do about it here.
HikariWS:
I can confirm this happens on EdgeRouter X and AMD64. I'm currently using a Ryzen 3100 with OpenWRT 21.02.0-rc1.
When we configure WAN interfaces, we create them and point to a ifname. In my example, for a ISP that uses DHCP, I create interfaces //wan_mrd// and //wan_mrd6// both using ifname //eth2//. When we're gonna use softwares like ping, traceroute and curl that support specifying the interface, I'd use
ping -I eth2
.But when a WAN uses PPPoE, apart from the interface name, OpenWRT creates a second name on the format pppoe-. In example, I have another ISP on port //eth3//, then on config I create interfaces named //want// and //want6//. Then when I use ping I must use
ping -I pppoe-want
.If I use
ping -I eth3
it fails with messageping: connect: Permission denied
.ping -I want
fails withping: unknown iface: want
.Oddly, //pppoe-want// works for IPv6 too. There were times that even //pppoe-want// resulted on Permission denied, I don't know what had changed and it's working at the moment.
There are some reports of this causing conflicts. In example, openwrt/packages#15434 has people having trouble with mwan3 because of this. On https://forum.openwrt.org/t/ddns-not-working-with-pppoe-interface/96778 package ddns doesn't work because it uses ethX instead of pppoe-X.
I don't know why it was implemented this way and how to fix it or improve its compatibility. I guess there's a reason, or PPPoE connections would just use the port ifname as other protocols do.
The text was updated successfully, but these errors were encountered: