OpenWrt/LEDE Project

Welcome to the OpenWrt/LEDE Project bug reporting and issue tracking system

Problems to be reported here are for the OpenWrt/LEDE Project targets, sources, toolchain, core packages, build procedures, distribution and infrastructure. Guidelines for submitting a good bug report can be found at the OpenWrt/LEDE Project website. Problems related to LuCI or OpenWrt packages need to be reported in their repositories:

Notifications of all submissions and task changes are sent to lede-bugs@infradead.org.

OpenedIDCategoryTask TypePrioritySeveritySummaryReported InStatus
17.06.20203189Base systemBug ReportVery LowMediumWAN interface does not reconnect a lost PPPoE linkTrunkUnconfirmed Task Description

Hi,

- Device problem occurs on: TP-Link Archer C7 v5
- Software versions of OpenWrt: SNAPSHOT r13565-373f446049 / LuCI Master git-20.165.17827-7b30b88
- Steps to reproduce: remove the WAN cable(or bring down the link from the ISP router), wait , reconnect the WAN cable(or bring up the link in the ISP router), the OpenWrt router still has the old ppp IP because the ppp link is not negotiated again.

[OpenWrt router] ←-(PPPoE link)–> [ISP router] ←-(fiber link)–> [Inet]

Thanks.

08.06.20203165Base systemBug ReportVery LowMedium[opkg | ppp ] installation collision TrunkUnconfirmed Task Description
{”kernel”:”4.14.180”,”hostname”:”OpenWrt”,”system”:”ARMv7 Processor rev 1 (v7l)”,”model”:”Turris Omnia”,”board_name”:”cznic,turris-omnia”,”release”:{”distribution”:”OpenWrt”,”version”:”19.07.3”,”revision”:”r11063-85e04e9f46”,”target”:”mvebu/cortexa9”,”description”:”OpenWrt 19.07.3 r11063-85e04e9f46”}}
—-
Collected errors:
 * check_data_file_clashes: Package ppp-multilink wants to install file /etc/ppp/chap-secrets
	But that file is already provided by package  * ppp
 * check_data_file_clashes: Package ppp-multilink wants to install file /etc/ppp/filter
	But that file is already provided by package  * ppp
 * check_data_file_clashes: Package ppp-multilink wants to install file /etc/ppp/options
	But that file is already provided by package  * ppp
 * check_data_file_clashes: Package ppp-multilink wants to install file /etc/ppp/resolv.conf
	But that file is already provided by package  * ppp
 * check_data_file_clashes: Package ppp-multilink wants to install file /lib/netifd/ppp-down
	But that file is already provided by package  * ppp
 * check_data_file_clashes: Package ppp-multilink wants to install file /lib/netifd/ppp-up
	But that file is already provided by package  * ppp
 * check_data_file_clashes: Package ppp-multilink wants to install file /lib/netifd/ppp6-up
	But that file is already provided by package  * ppp
 * check_data_file_clashes: Package ppp-multilink wants to install file /lib/netifd/proto/ppp.sh
	But that file is already provided by package  * ppp
 * check_data_file_clashes: Package ppp-multilink wants to install file /usr/sbin/pppd
	But that file is already provided by package  * ppp
 * opkg_install_cmd: Cannot install package ppp-multilink.

The opkg install command failed with code 255.


03.06.20203149KernelBug ReportVery LowHighpppoe-only-process-padt-targeted-at-local-interfaces.pa...AllUnconfirmed Task Description

The issue is well outlined in the forum https://forum.openwrt.org/t/pppoe-disconnects-every-few-hours/61239

Whilst being patched in kernel 4.19 | 5.4 | 5.6 https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/log/?id=a1b8c8b81a0c8c1dba9acaf2f85e7dbd6cbdc5b1&qt=grep&q=pppoe-only-process-padt-targeted-at-local-interfaces.patch&showmsg=1

kernel 4.14 (OpenWrt stable 19.07.x) seems to fall through the cracks somehow. With kernel 5.4 in upcoming stable OpenWrt 20.x still far out it would make sense to backport the patch into OpenWrt stable 19.07.x

18.05.20203107PackagesBug ReportVery LowHigh[netifd] wan Command failed: Permission denied | repeat...TrunkUnconfirmed Task Description

- Master 5.4.41
- mvebu → cortex-A9
- upstream connectivity VDSL2 dual-stack | PPPoE | IPv4 via PPPoE | IPv6 via DHCP (only after PPPoE is completed)
- SFP VDSL modem residing in router’s SFP cage


ifup wan

produces

40:49  netifd: Interface 'wan' is enabled
40:49  kernel: [ 4539.310854] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
40:49  kernel: [ 4539.629747] sfp sfp: module transmit fault indicated
40:51  netifd: Network device 'eth2' link is up
40:51  netifd: Interface 'wan' has link connectivity
40:51  netifd: Interface 'wan' is setting up now
40:51  kernel: [ 4541.699901] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
40:51  kernel: [ 4541.699917] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
40:51  insmod: module is already loaded - slhc
40:51  insmod: module is already loaded - ppp_generic
40:51  insmod: module is already loaded - pppox
40:51  insmod: module is already loaded - pppoe
40:51  pppd[29207]: Plugin rp-pppoe.so loaded.
40:51  pppd[29207]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
40:51  pppd[29207]: pppd 2.4.8 started by root, uid 0
41:06  pppd[29207]: Timeout waiting for PADO packets
41:06  pppd[29207]: Unable  complete PPPoE Discovery
41:06  pppd[29207]: Exit.
41:06  netifd: Interface 'wan' is now down
41:06  kernel: [ 4556.940117] mvneta f1034000.ethernet eth2: Link is Down
41:06  netifd: Interface 'wan' is disabled
41:06  netifd: Interface 'wan' is enabled
41:06  netifd: Interface 'wan' is setting up now
41:06  kernel: [ 4556.954502] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
41:06  netifd: Network device 'eth2' link is down
41:06  netifd: Interface 'wan' has link connectivity loss
41:06  insmod: module is already loaded - slhc
41:06  insmod: module is already loaded - ppp_generic
41:06  insmod: module is already loaded - pppox
41:06  insmod: module is already loaded - pppoe
41:07  netifd: wan (29306): Command failed: Permission denied
41:07  netifd: Interface 'wan' is now down
41:07  netifd: Interface 'wan' is disabled
41:07  netifd: Interface 'wan' is enabled
41:07  kernel: [ 4557.042474] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
41:07  netifd: Network device 'eth2' link is up
41:07  netifd: Interface 'wan' has link connectivity
41:07  netifd: Interface 'wan' is setting up now
41:07  kernel: [ 4557.209931] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
41:07  kernel: [ 4557.209948] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
41:07  insmod: module is already loaded - slhc
41:07  insmod: module is already loaded - ppp_generic
41:07  insmod: module is already loaded - pppox
41:07  insmod: module is already loaded - pppoe
41:07  pppd[29362]: Plugin rp-pppoe.so loaded.
41:07  pppd[29362]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
41:07  pppd[29362]: pppd 2.4.8 started by root, uid 0
41:22  pppd[29362]: Timeout waiting for PADO packets
41:22  pppd[29362]: Unable  complete PPPoE Discovery
41:22  pppd[29362]: Exit.
41:22  netifd: Interface 'wan' is now down
41:22  kernel: [ 4572.446438] mvneta f1034000.ethernet eth2: Link is Down
41:22  netifd: Interface 'wan' is disabled
41:22  netifd: Interface 'wan' is enabled
41:22  netifd: Interface 'wan' is setting up now
41:22  netifd: Network device 'eth2' link is down
41:22  netifd: Interface 'wan' has link connectivity loss
41:22  kernel: [ 4572.459786] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
41:22  insmod: module is already loaded - slhc
41:22  insmod: module is already loaded - ppp_generic
41:22  insmod: module is already loaded - pppox
41:22  insmod: module is already loaded - pppoe
41:22  netifd: wan (29492): Command failed: Permission denied
41:22  netifd: Interface 'wan' is now down
41:22  netifd: Interface 'wan' is disabled
41:22  netifd: Interface 'wan' is enabled
41:22  kernel: [ 4572.544765] mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
41:22  netifd: Network device 'eth2' link is up
41:22  netifd: Interface 'wan' has link connectivity
41:22  netifd: Interface 'wan' is setting up now
41:22  kernel: [ 4572.712631] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
41:22  kernel: [ 4572.712647] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
41:22  insmod: module is already loaded - slhc
41:22  insmod: module is already loaded - ppp_generic
41:22  insmod: module is already loaded - pppox
41:22  insmod: module is already loaded - pppoe
41:22  pppd[29549]: Plugin rp-pppoe.so loaded.
41:22  pppd[29549]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
41:22  pppd[29549]: pppd 2.4.8 started by root, uid 0
41:29  pppd[29549]: PPP session is 31713
41:29  pppd[29549]: Connected  78:ba:f9:73:f5:74 via interface eth2
41:29  kernel: [ 4579.318874] pppoe-wan: renamed from ppp0
41:29  pppd[29549]: Renamed interface ppp0  pppoe-wan
41:29  pppd[29549]: Using interface pppoe-wan
41:29  pppd[29549]: Connect: pppoe-wan <--> eth2
41:35  pppd[29549]: PAP authentication succeeded
41:35  pppd[29549]: peer from calling number 78:BA:F9:73:F5:74 authorized
41:35  pppd[29549]: local  IP address 
41:35  pppd[29549]: remote IP address 
41:35  pppd[29549]: primary   DNS address 
41:35  pppd[29549]: secondary DNS address 
41:35  pppd[29549]: local  LL address fe80::b931:4e21:f7f2:a0ad
41:35  pppd[29549]: remote LL address fe80::7aba:f9ff:fe73:f574
41:35  netifd: Network device 'pppoe-wan' link is up
41:35  netifd: Interface 'wan' is now up
41:35  netifd: Network alias 'pppoe-wan' link is up
41:35  netifd: Interface 'wan_6' is enabled
41:35  netifd: Interface 'wan_6' has link connectivity
41:35  netifd: Interface 'wan_6' is setting up now

Unclear how this could be debugged. With the repeated loading of ppp modules it looks like a timing issue.

 


29.04.20203058Base systemBug ReportVery LowMediumPPPoE fails repeatedly; until rebootopenwrt-19.07Unconfirmed Task Description

I’m using the pre-built OpenWRT firmware for BT HomeHub 5a and am generally very happy with it. The problem that shows up is that every once in a while, the PPPoE connection goes down and stays down. I see in the log that the PPPoE is retried repeatedly but keeps failing. Disabling the corresponding interface and then re-enabling it (e.g. from LuCI) does not help (I do see that it takes the PPPoE and the DSL down and after a while the DSL comes back up but the PPPoE still keeps failing in the same way).

Rebooting fixes the issue, OTOH.

The system log repeats the following lines every 15 seconds or so:

Wed Apr 29 07:16:55 2020 daemon.notice netifd: Interface 'wan' is enabled
Wed Apr 29 07:16:55 2020 daemon.notice netifd: Interface 'wan' is setting up now
Wed Apr 29 07:16:55 2020 daemon.err insmod: module is already loaded - slhc
Wed Apr 29 07:16:55 2020 daemon.err insmod: module is already loaded - ppp_generic
Wed Apr 29 07:16:55 2020 daemon.err insmod: module is already loaded - pppox
Wed Apr 29 07:16:55 2020 daemon.err insmod: module is already loaded - pppoe
Wed Apr 29 07:16:55 2020 daemon.info pppd[13912]: Plugin rp-pppoe.so loaded.
Wed Apr 29 07:16:55 2020 daemon.info pppd[13912]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Wed Apr 29 07:16:55 2020 daemon.notice pppd[13912]: pppd 2.4.7 started by root, uid 0
Wed Apr 29 07:17:10 2020 daemon.warn pppd[13912]: Timeout waiting for PADO packets
Wed Apr 29 07:17:10 2020 daemon.err pppd[13912]: Unable to complete PPPoE Discovery
Wed Apr 29 07:17:10 2020 daemon.info pppd[13912]: Exit.
Wed Apr 29 07:17:10 2020 daemon.notice netifd: Interface 'wan' is now down
Wed Apr 29 07:17:10 2020 daemon.notice netifd: Interface 'wan' is disabled

I cannot reproduce it at will. The problem occurred more often (like once a week maybe) in the past and I thought it had magically been resolved since it hadn’t re-appeared for the last 2 months, but it happened again today.

root@router:~# opkg list_installed | grep ppp
kmod-ppp - 4.14.167-1
kmod-pppoa - 4.14.167-1
kmod-pppoe - 4.14.167-1
kmod-pppox - 4.14.167-1
luci-proto-ppp - git-20.029.45734-adbbd5c-1
ppp - 2.4.7.git-2019-05-25-2
ppp-mod-pppoa - 2.4.7.git-2019-05-25-2
ppp-mod-pppoe - 2.4.7.git-2019-05-25-2
root@router:~# 

I suspect the above info is not sufficient to find the problem, so at this point, I’m mostly looking for suggestions as to how to get more verbose logs, or commands to try and run parts individually

03.03.20202875PackagesBug ReportVery LowLowppp-mod-pptp ipk install error on k2p routerTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
- Software versions of OpenWrt/LEDE release, packages, etc.
- Steps to reproduce

 

I want to setup pptp site-to-site vpn on k2p router which install openwrt. when i instlall ppp-mode-pptp ipk,the error occur below.

root@Router:~# opkg install ppp-mod-pptp
Installing ppp-mod-pptp (2.4.7-13) to root...
Downloading http://mirrors.tuna.tsinghua.edu.cn/lede/releases/18.06.7/packages/mipsel_24kc/base/ppp-mod-pptp_2.4.7-13_mipsel_24kc.ipk Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for ppp-mod-pptp:
* kernel (= 4.14.167-1-16b77c6fbb9d9192d39ab642ba67d11a)
* opkg_install_cmd: Cannot install package ppp-mod-pptp.

my version
root@Router:~# cat /proc/version
Linux version 4.14.167 (runner@fv-az50) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r7976-ca47026b7d)) #0 SMP Wed Jan 29 16:06:05 2020

07.02.20202819Base systemBug ReportVery LowMediumDefault configuration for PPPoE client (PPPd) is not pr...openwrt-19.07Unconfirmed Task Description

Default configuration for PPPoE client is not properly set.

Certain HW manufacturers (Alcatel Lucent for example) have implemented LCP flooding prevention systems for PPP clients if multiple LCP request/echos arrive in < 30s. When this occours BNG (BRAS) sends a PPP disconnect request and the PPP session gets dropped and PPP username gets remporary banned.

LCP echo interval default values for PPPoE connections should be set in the value of at least 30 (60 perferably) (seconds that is) and not 5s as set per current default value. Currently all users using PPPoE are affected.

Still present in –> OpenWrt 19.07.1 r10911-c155900f66 / LuCI openwrt-19.07 branch git-20.029.45734-adbbd5c

05.02.20192101Base systemBug ReportVery LowHighWDS bridge and PPPoE MTU problemAllUnconfirmed Task Description

Device: Netgear R7800
This issue is not present with original Netgear firmware and is not present with LEDE 17 (older kernel).

Preface:
I have very strange issue with interfaces MTU and it looks to be introduced with newer kernel (4.14).

My network is attached as a png:
1. my ISP uses VDSL, i just have a PPPoE (MTU=1492) on the ethernet interface through the ISP modem
2. all other internal clients and routers interfaces have MTU=1500

Ping from R7800 to 1.1.1.1 with 2000 packet size and fragmentation allowed = success
Ping from ArcherC7v2 to R7800 with 2000 packet size and fragmentation allowed = success
Ping from PC1 to R7800 with 2000 packet size and fragmentation allowed = success
Ping from PC2 to R7800 with 2000 packet size and fragmentation allowed = success
Ping from PC1 to 1.1.1.1 with 2000 packet size and fragmentation allowed = failure
Ping from PC2 to 1.1.1.1 with 2000 packet size and fragmentation allowed = success

Now the fun part:
Ping from PC1 to 1.1.1.1 with 1473 packet size and fragmentation allowed = failure
Ping from PC1 to 1.1.1.1 with 1472 packet size (1492-20) and fragmentation allowed = success

It seems a WDS (4addr) problem combined with PPPoE being at MTU=1492 at this point, but:
Ping from ArcherC7v2 to 1.1.1.1 with 2000 packet size and fragmentation allowed = success

I’ve messed up with MTU on all the interfaces, the only thing that fix the issue is setting the br-lan interface of the R7800 to MTU=1491, as soon as the bridge has MTU>1491 the pings fail.

R7800 network config

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '5 0t'

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option stp '1'
        option mtu '1500'
        option ifname 'eth1.1'

config interface 'TIM_FTTC'
        option proto 'pppoe'
        option ifname 'eth0.2'
        option username '***'
        option password '***'
        option ipv6 'auto'
        option metric '1'
        option peerdns '0'
        option keepalive '5 6'

R7800 wireless config

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option htmode 'VHT80'
        option channel '136'
        option txpower '23'
        option country 'US'
        option legacy_rates '0'
        option noscan '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option mode 'ap'
        option ssid '***'
        option encryption 'psk2+ccmp'
        option key '***'
        option wps_pushbutton '0'
        option network 'lan'
        option wds '1'

ArcherC7v2 network config

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 2 3 4 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '5 0t'

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.2'
        option netmask '255.255.255.0'
        option stp '1'
        option mtu '1500'
        option ifname 'eth1.1'

ArcherC7v2 wireless config

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'pci0000:01/0000:01:00.0'
        option htmode 'VHT80'
        option txpower '23'
        option country 'US'
        option legacy_rates '0'
        option noscan '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option mode 'sta'
        option wds '1'
        option ssid '***'
        option encryption 'psk2+ccmp'
        option key '***'
        option wps_pushbutton '0'
        option network 'lan'

WAN zone on firewall on R7800 has

option mtu_fix '1'
18.01.20192062Base systemBug ReportVery LowHighMTU is not set to 1508/1500 when using PPPoEopenwrt-18.06Unconfirmed Task Description

TP-LINK Archer C7, OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152).

Use PPPoE for WAN. Set MTU to 1508.

Observe ifconfig result. MTU is set at 1492, it should be 1500.

Add

config interface ‘eth0’

option ifname 'eth0'
option mtu '1508'

to /etc/config/network, ensure PPPoE MTU (as above) is set to 1508 and restart the network/reboot the router.

Observe ifconfig result. MTU is set at 1500 as expected.

19.09.20181857Base systemBug ReportVery LowLowpppd 14 failed attempts to set up wan (+ system log spa...TrunkUnconfirmed Task Description

Device: TD-W8970 v1
OpenWRT version affected:

  • LEDE 17.0x NOT AFFECTED
  • 18.06.00 NOT TESTED
  • 18.06.01 YES
  • 18.06 SNAPSHOT (r7313-4f6ad3c13a) YES
  • master YES

Protocol: PPPoA (other not tested).

What happen:

Too many early attempts to bring up the wan interface. The system logs is filled with:

daemon.notice netifd: Interface 'wan' is setting up now
daemon.info pppd[<pid>]: Plugin pppoatm.so loaded.
daemon.info pppd[<pid>]: PPPoATM plugin_init
daemon.info pppd[<pid>]: PPPoATM setdevname_pppoatm - SUCCESS:0.8.35
daemon.notice pppd[<pid>]: pppd 2.4.7 started by root, uid 0
daemon.err pppd[<pid>]: connect(0.8.35): No such device
daemon.info pppd[<pid>]: Exit.
daemon.notice netifd: Interface 'wan' is now down

14 attempts before successful one. This wasn’t the case on LEDE where only 1 failed attempt was made.
After all the failed connection, this shows up:

daemon.notice dsl-notify: Switching to TC-Layer ATM
kern.info kernel: [<time>] ATM1.0.26    ATM (A1) firmware version 0.24
kern.warn kernel: [<time>] ifxmips_atm: ATM init succeed

... and after that, finally:

daemon.info pppd[2218]: Plugin pppoatm.so loaded.
daemon.info pppd[<pid>]: PPPoATM plugin_init
daemon.info pppd[<pid>]: PPPoATM setdevname_pppoatm - SUCCESS:0.8.35
daemon.notice pppd[<pid>]: pppd 2.4.7 started by root, uid 0
kern.info kernel: [<time>] pppoa-wan: renamed from ppp0
daemon.info pppd[<pid>]: Using interface pppoa-wan
daemon.notice pppd[<pid>]: Connect: pppoa-wan <--> 0.8.35
daemon.info pppd[<pid>]: CHAP authentication succeeded
daemon.notice pppd[<pid>]: CHAP authentication succeeded
daemon.notice pppd[<pid>]: local  IP address 151.95.61.61
daemon.notice pppd[<pid>]: remote IP address 151.6.141.72
daemon.notice netifd: Network device 'pppoa-wan' link is up
daemon.notice netifd: Interface 'wan' is now up

Regarding the whole “Switching to TC-Layer ATM” block of messages:
* I do not know if is 100% needed to properly setup wan ..
* ... but for sure I’ve always seen failed attempts before it and the successful one after it ...
* Sometimes there is 1 more failed attempt after the “Switching to TC-Layer ATM” stuffs (and before the successful one).
* I do not know if is triggered by the failures or if is simple placed “too late” in the boot order

Also:
* After the first failure all the other after it will also trigger warnings (more spam inside logs) form insmod since each needed module (slhc, ppp_generic and pppoatm) is already loaded.
* On LEDE the whole process required only one “failure”

17.01.2017394Base systemBug ReportVery LowLowPPPoE/802.1Q issues on Linksys WRT1900ACSTrunkUnconfirmed Task Description

Device: Linksys WRT1900ACS
LEDE commit: b9a408c2b49ccfa0e906bda00ef77f4002e401fd

diffconfig:
CONFIG_TARGET_mvebu=y
CONFIG_TARGET_mvebu_DEVICE_linksys-wrt1900acs=y
CONFIG_TARGET_BOARD=”mvebu” CONFIG_LIBSODIUM_MINIMAL=y
CONFIG_PACKAGE_dnscrypt-proxy=y
CONFIG_PACKAGE_dnscrypt-proxy-resolvers=y
CONFIG_PACKAGE_libsodium=y

I have an ISP that requires PPPoE on vlan 201 with 802.1Q tags (CenturyLink fiber). On OpenWRT 15.05.1 and on earlier versions of LEDE (not sure about an exact revision, but maybe October/November timeframe) I could simply define my wan interface in /etc/config/network like this and it just worked:

```
config interface ‘wan’

  option ifname 'eth0.201'
  option proto 'pppoe'
  option username 'user@provider'
  option password 'password'

```

I can’t find any way to make this work on recent versions of LEDE. I’ve tried new builds at least every few weeks, but none have worked for the past few months. I’ve tried configuring the switch_vlan section by adding a ‘t’ after the appropriate switch port to enable tagging, I’ve tried defining a new interface and then using that as the wan ifname, and I’ve tried the command line `ip link` and `ppp` invocations that work on every other linux system I’ve tried, but I can’t find anything that works on recent versions of LEDE.

On other linux systems I can do roughly the following and it works:

```
ip link add link eth0 name eth0.201 type vlan id 201
ip link set eth0.201 up
pppd call centurylink
```

where /etc/ppp/peers/centurylink and /etc/ppp/chap-secrets looks like this:
```
> cat /etc/ppp/peers/centurylink
plugin rp-pppoe.so

eth0.201
name “user@provider” usepeerdns
persist
defaultroute
hide-password
noauth

cat /etc/ppp/chap-secrets
#USERNAME PROVIDER PASSWORD IPADDRESS
user@provider * password
```

I’ve tried using tcpdump to capture what’s happening and on other systems (Ubuntu 16.10, Debian Jessie, pfsense) I see an 802.1Q tag, but I don’t see that on LEDE. That might be expected though because it seems totally possible that the switch itself is doing the 802.1Q stuff and tcpdump doesn’t see the actual packets sent over the wire. I have no idea if that’s the case, though. I guess I could also try this on OpenWRT as well, but I haven’t taken the time to do that yet.

The only other difference I’ve seen is that by default LEDE doesn’t send a Host-Uniq tag, but even if I set the host_uniq uci config it doesn’t fix things. Regardless of what I do I see logs that look like this:

```
Tue Jan 17 01:55:26 2017 daemon.notice netifd: Interface ‘wan’ is now down
Tue Jan 17 01:55:26 2017 daemon.notice netifd: Interface ‘wan’ is disabled
Tue Jan 17 01:55:26 2017 daemon.notice netifd: Interface ‘wan’ has link connectivity loss
Tue Jan 17 01:55:26 2017 kern.info kernel: [23415.581135] mvneta f1034000.ethernet eth0: configuring for fixed link mode
Tue Jan 17 01:55:26 2017 kern.info kernel: [23415.588150] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Tue Jan 17 01:55:26 2017 kern.info kernel: [23415.594095] mvneta f1034000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Tue Jan 17 01:55:26 2017 daemon.notice netifd: Interface ‘wan’ is enabled
Tue Jan 17 01:55:26 2017 daemon.notice netifd: Network device ‘eth0’ link is up
Tue Jan 17 01:55:26 2017 daemon.notice netifd: VLAN ‘eth0.201’ link is up
Tue Jan 17 01:55:26 2017 daemon.notice netifd: Interface ‘wan’ has link connectivity
Tue Jan 17 01:55:26 2017 daemon.notice netifd: Interface ‘wan’ is setting up now
Tue Jan 17 01:55:26 2017 kern.info kernel: [23415.602431] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Tue Jan 17 01:55:26 2017 daemon.info pppd[2263]: Plugin rp-pppoe.so loaded.
Tue Jan 17 01:55:26 2017 daemon.info pppd[2263]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Tue Jan 17 01:55:26 2017 daemon.notice pppd[2263]: pppd 2.4.7 started by root, uid 0
...
Tue Jan 17 01:55:41 2017 daemon.warn pppd[2263]: Timeout waiting for PADO packets
Tue Jan 17 01:55:41 2017 daemon.err pppd[2263]: Unable to complete PPPoE Discovery
Tue Jan 17 01:55:41 2017 daemon.info pppd[2263]: Exit.
```

A sample /etc/config/network looks like this:
```
config interface ‘loopback’

      option ifname 'lo'
      option proto 'static'
      option ipaddr '127.0.0.1'
      option netmask '255.0.0.0'

config globals ‘globals’

      option ula_prefix 'fd25:2a59:2a7b::/48'

config interface ‘lan’

      option type 'bridge'
      option ifname 'eth1'
      option proto 'static'
      option ipaddr '192.168.2.1'
      option netmask '255.255.255.0'
      option ip6assign '60'

config interface ‘wan’

  option ifname 'eth0.201'
  option proto 'pppoe'
  option username 'user@provider'
  option password 'password'

config switch

      option name 'switch0'
      option reset '1'
      option enable_vlan '1'

config switch_vlan

      option device 'switch0'
      option vlan '1'
      option ports '0 1 2 3 6'

config switch_vlan

      option device 'switch0'
      option vlan '2'
      option ports '4 5'

config interface ‘guest’

      option _orig_ifname 'wlan1'
      option _orig_bridge 'false'
      option proto 'static'
      option ipaddr '192.168.3.1'
      option netmask '255.255.255.0'

```

Interestingly, OpenWRT has exactly the same version of ppp and rp-pppoe (2.4.7 and 3.8p, respectively) so it seems like there’s something else in play and my guess is it’s related to vlan tagging, but I don’t seem to have the same issue as FS#227 which mentions both PPPoE and vlan config, but it is quite difficult to follow the discussion there so maybe I’m missing something.

16.08.201694Base systemBug ReportVery LowMediumnetifd: PPPoE MTU problemTrunkNew Task Description

When you set the MTU of a ppp interface with proto=pppoe and ifname=nas0 via the mtu option,
the configured mtu will not be set on the ppp interface (what you want), but on the
underlying interface named by ifname (what you normally don’t want to change).

This leeds to log messages like this:


pppd[5641]: Interface nas0 has MTU of 1448 – should be at least 1500.


and MTUs other than what you really want.

example:


desired PPPoE MTU: 1448
actual nas0 MTU: 1448
actual PPPoE MTU: 1440

This issue seems to be related to the commit 7ac29b75319fd69a8a7c0aeea7804d381ec07d3d of netifd.

Regards,
Martin

Showing tasks 1 - 12 of 12 Page 1 of 1

Available keyboard shortcuts

Tasklist

Task Details

Task Editing