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
29.05.20203134Base systemBuild FailureVery LowHighCan't build netifdopenwrt-19.07Unconfirmed Task Description

Environment: x86_64
Arch Linux
Description: Can’t build current openwrt-19.07. (Arch Linux, tried both GCC 10.1.0 and 8.4.0. Getting two build errors:

CFLAGS="-Os -pipe -mno-branch-likely -mips32r2 -mtune=74kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -mips16 -minterlin
k-mips16 -iremap/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944:netifd-2019-08-05-5e02f944 -Wformat -Werror=format-security -fstack-protector -D_F
ORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include/libnl-tiny -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mips
el_74kc_musl/usr/include -flto  -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/includ
e -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/usr/include -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/include/fo
rtify -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/include " CXXFLAGS="-Os -pipe -mno-branch-likely -mips32r2 -mtune=74kc -fno-caller-saves -fno-plt -fho
nour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -mips16 -minterlink-mips16 -iremap/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-
2019-08-05-5e02f944:netifd-2019-08-05-5e02f944 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/legogris/dev/openwrt-fresh/staging_dir/tar
get-mipsel_74kc_musl/usr/include/libnl-tiny -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include -flto  -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mips
el_74kc_musl/usr/include -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/include -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/usr/
include -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/include/fortify -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/
include " LDFLAGS="-L/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/lib -L/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/lib -L/home/legogris/de
v/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/usr/lib -L/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/lib -znow -zrelro -flto -fuse-linke
r-plugin " make  -C /home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/. AR="mipsel-openwrt-linux-musl-gcc-ar" AS="mipsel-openwrt-linux-musl-gcc -c -
Os -pipe -mno-branch-likely -mips32r2 -mtune=74kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -iremap/home/legogris/dev/o
penwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944:netifd-2019-08-05-5e02f944 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,re
lro -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include/libnl-tiny -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include -flto" LD=m
ipsel-openwrt-linux-musl-ld NM="mipsel-openwrt-linux-musl-gcc-nm" CC="mipsel-openwrt-linux-musl-gcc" GCC="mipsel-openwrt-linux-musl-gcc" CXX="mipsel-openwrt-linux-musl-g++" RANLIB="mipsel-open
wrt-linux-musl-gcc-ranlib" STRIP=mipsel-openwrt-linux-musl-strip OBJCOPY=mipsel-openwrt-linux-musl-objcopy OBJDUMP=mipsel-openwrt-linux-musl-objdump SIZE=mipsel-openwrt-linux-musl-size CROSS="
mipsel-openwrt-linux-musl-" ARCH="mipsel" CMAKE_COMMAND='/home/legogris/dev/openwrt-fresh/staging_dir/host/bin/cmake' CMAKE_DISABLE_cmake_check_build_system=1 ;
make[4]: Entering directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[5]: Entering directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[6]: Entering directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[6]: Leaving directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[6]: Entering directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
[  4%] Building C object CMakeFiles/netifd.dir/main.c.o
In file included from /home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/netifd.h:29:0,
                 from /home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/main.c:22:
/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/utils.h:116:51: error: 'struct uci_blob_param_list' declared inside parameter list will not be vis
ible outside of this definition or declaration [-Werror]
 const char * uci_get_validate_string(const struct uci_blob_param_list *p, int i);
                                                   ^~~~~~~~~~~~~~~~~~~
cc1: error: unrecognized command line option '-Wno-unknown-warning-option' [-Werror]
cc1: all warnings being treated as errors
make[6]: *** [CMakeFiles/netifd.dir/build.make:63: CMakeFiles/netifd.dir/main.c.o] Error 1
make[6]: Leaving directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[5]: *** [CMakeFiles/Makefile2:76: CMakeFiles/netifd.dir/all] Error 2
make[5]: Leaving directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[4]: *** [Makefile:130: all] Error 2
make[4]: Leaving directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[3]: *** [Makefile:49: /home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/.built] Error 2
make[3]: Leaving directory '/home/legogris/dev/openwrt-fresh/package/network/config/netifd'
time: package/network/config/netifd/compile#0.33#0.08#0.39
make[2]: *** [package/Makefile:113: package/network/config/netifd/compile] Error 2
make[2]: Leaving directory '/home/legogris/dev/openwrt-fresh'
make[1]: *** [package/Makefile:107: /home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/legogris/dev/openwrt-fresh'
make: *** [/home/legogris/dev/openwrt-fresh/include/toplevel.mk:227: world] Error 2
make -j1 V=s  20,02s user 4,25s system 102% cpu 23,565 total
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.

 


07.04.20202977Base systemBug ReportVery LowHighParameters sendopts seems to be bad formated in the cal...openwrt-19.07Unconfirmed Task Description

The options parameters sendopts define in /etc/config/network seems to be badly formated in the call of the command odhcp6c

In /etc/config/network:

 

option sendopts “11:00 15:456544 16:1234”

is parsed like this (show via ps|grep odhcp6c)
-x11 00 -x15 456544 -x16 1234

The syntax given by the help of odhcp6c is different:

-x <opt>:<val> Add option opt (with value val) in sent packets (cumulative)

		Examples of IPv6 address, string and base-16 encoded options:
		-x dns:2001:2001::1,2001:2001::2 - option 23
		-x 15:office - option 15 (userclass)
		-x 0x1f4:ABBA - option 500
		-x 202:'"file"' - option 202

It appears than the : is replace by a space in the call of the command.
Regarding the help of the command, it should be :
-x 11:00 -x 15:456544 -x 16:1234

Thanks
Regards

24.02.20202853Base systemBug ReportVery LowLowThe netifd is unable to find correct network interfaceTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
RouterBoard RB912UAG-5HPnD + R11e-LTE PCIe LTE card
- Software versions of OpenWrt/LEDE release, packages, etc.
NAME=”OpenWrt” VERSION=”19.07.1” Configuration of network device:
config interface ‘wwan’

      option proto 'ncm'
      option ifname 'wwan0'
      option device '/dev/ttyACM1'
      option apn 'internet.eplus.de'
      option mode 'preferlte'
      option delay '5'

- Steps to reproduce

The netifd is unable to find which logical ethXXX interface is bound with serial port /dev/ttyACM1 for NCM - both handled by the R11e-LTE card.
In logread following messages appear:
Mon Feb 24 17:19:42 2020 daemon.notice netifd: wwan (3952): ls: /sys/devices/platform/ehci-platform/usb1/1-1/1-1:1.4/../../*/net: No such file or directory

The only net directory in the tree /sys/devices/platform/ehci-platform/usb1 is /sys/devices/platform/ehci-platform/usb1/1-1/1-1:1.0/net - the content of the directory is a directory eth1. Really eth1 is correct network interface name bound, so the problem looks like listing with ls not assuming the partigular directory tree depth.

09.02.20202824Base systemBug ReportVery LowLow[netifd] bridge STP - mcast_last_member_interval syntaxTrunkUnconfirmed Task Description

* issue as described in [1] and observed by various users on different branches | target devices
* potential cause syntax error in [2]

cfg->last_member_interval = 100;

according to [3] the expected syntax reads

mcast_last_member_interval

[1] https://forum.openwrt.org/t/bridge-stp-potential-syntax-error-last-member-interval/51885
[2] https://git.openwrt.org/?p=project/netifd.git;a=blob;f=bridge.c;hb=70b50118c7b063fab5c1383f12e6e92ca0fc82c3#l576
[3] https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/tree/ip/iplink_bridge.c#n53


27.12.20192698Base systemBug ReportVery LowMediumnetifd DFS-delayed wireless interfaces not correctly ha...TrunkRequires testing Task Description

Found on TP-Link Archer C7 v4 on master (commit db992e7b53 - 5 days ago).

When having 3 interfaces on channel requiring radar scan (DFS), only the main interface is shown - see logs, where radio0 wifi should have 3 interfaces wlan0-lan, wlan0-guest and wlan0-admin, but only wlan0-lan is shown. Due to DFS scan it comes up after a minute after `/etc/init.d/network start` is executed.

Configuration:

  • 2 wifis: 2,4GHz (radio1) + 5GHz (radio0)
  • each band has 3 SSIDs (domaci-soukroma, domaci, domaci-admin), each one’s interface assigned to one bridge - lan, guest and admin, respectively.

Called `ubus call network.wireless status`, received result:

  • wlan0-lan exists
  • wlan0-guest and wlan0-admin not recognised
  • wlan1-lan, wlan1-guest, wlan1-admin exist

Expected result:

  • wlan0-guest and wlan0-admin recognised

Configuration, logread (produced by `/sbin/netifd -d 15 -l 7`), `ubus network.device status` and `ubus network.wireless status` attached (removed IP and MAC addresses).

19.12.20192689Base systemBug ReportVery LowMediumnetifd /etc/config/wireless wifi-iface requires a key o...TrunkUnconfirmed Task Description

What the subject says.

If /etc/config/wireless is configured to use a wpa_psk_file to supply the wpa pre shared keys, but no “key” option is provided, the interface will refuse to start.

You can see the flawed logic here: https://github.com/openwrt/openwrt/blob/24b97579d20b6ac6df81654a953386d2912fc324/package/network/services/hostapd/files/hostapd.sh

psk|sae|psk-sae)
			json_get_vars key wpa_psk_file
			if [ ${#key} -lt 8 ]; then
				wireless_setup_vif_failed INVALID_WPA_PSK
				return 1
			elif [ ${#key} -eq 64 ]; then
				append bss_conf "wpa_psk=$key" "$N"
			else
				append bss_conf "wpa_passphrase=$key" "$N"
			fi
			[ -n "$wpa_psk_file" ] && {
				[ -e "$wpa_psk_file" ] || touch "$wpa_psk_file"
				append bss_conf "wpa_psk_file=$wpa_psk_file" "$N"
			}
			[ "$eapol_version" -ge "1" -a "$eapol_version" -le "2" ] && append bss_conf "eapol_version=$eapol_version" "$N"

			wps_possible=1

The existence of the wpa_psk_file option should mean that the key value is optional. But instead the wpa_psk_file option is treated as an additional option, not a replacement.

19.12.20192688Base systemBug ReportVery LowLownetifd /etc/config/wireless wpa_psk_file changes not de...TrunkUnconfirmed Task Description

If a wifi-iface is configured to use a wpa_psk_file to supply the pre-shared keys for wifi authentication, and that wpa_psk_file has it’s contents changed (The file path stays the same), then reload_config has no effect.

Hostapd, apparently, does not check the wpa_psk_file after startup, and netifd / UCI does not understand to track the contents of the file to determine if the hostapd instance should be restarted.

Ideal outcome:

If the contents of the file indicated by the wpa_psk_file option in the wifi-iface section of /etc/config/wireless changes when reload_config is called, then hostapd is sent a signal that causes it to gracefully reload the wpa_psk_file information without shutting down existing connections.

Acceptable outcome:

If the contents of the file indicated by the wpa_psk_file option in the wifi-iface section of /etc/config/wireless changes when reload_config is called, then hostapd is restarted.

25.08.20192464Base systemBug ReportVery LowLownetifd: changing metric, ip4table or defaultroute flush...openwrt-18.06Unconfirmed Task Description

Tested device: Virtual x86_64
Software versions:
openwrt 18.06.4
netifd 2019-01-31-a2aba5c7-2.1

Reproduce:
* Use babeld as dynamic routing daemon.
* Verify that the main table contains routes inserted by babeld.
* Change one of metric, ip4table and defaultroute on a interface which have babeld’s routes in the main table.
* Run /etc/init.d/network reload
* The routes inserted by babeld for the above interface are now gone, which was unexpected.

It seems to be caused by the following section in interface.c:

        UPDATE(metric, reload_ip);
        UPDATE(proto_ip.no_defaultroute, reload_ip);
        UPDATE(ip4table, reload_ip);
        UPDATE(ip6table, reload_ip);
...
        if (reload_ip) {
                bool config_ip_enabled = if_old->config_ip.enabled;
                bool proto_ip_enabled = if_old->proto_ip.enabled;

                interface_ip_set_enabled(&if_old->config_ip, false);
                interface_ip_set_enabled(&if_old->proto_ip, false);
                interface_ip_set_enabled(&if_old->proto_ip, proto_ip_enabled);
                interface_ip_set_enabled(&if_old->config_ip, config_ip_enabled);
        }
10.07.20192372PackagesBug ReportVery LowLow[netifd] error code language semantics misleadsAllUnconfirmed Task Description

I would have preferred to submit a patch but my coding skills are not up to speed/standard...

Trying to debug a PPPoE issue it was not possible to utilize –verbose with ifup || ifdown since it would appear not being implemented. Thus started to look at what LuCI has on display when stopping || starting the WAN iface via LuCI:

Unknown error (USER_REQUEST)

Whilst USER_REQUEST would seem logical as being manually initiated by the user the Unknown error however led me down the garden path until having traced its source

https://openwrt-devel.openwrt.narkive.com/piBGMKkc/patch-ppp-detailed-last-error-support

To my understanding

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/ppp/files/ppp.sh;h=b553effd889e7662f366793665c789ed0d0c0ff2;hb=refs/heads/openwrt-master#l64

*) echo "UNKNOWN_ERROR" ;;

gets tagged to any of the potential error codes (1 - 21), even to

0) echo "OK" ;;

Which could introduce some sort of confusion to a simple minded user (being me).

0) echo "OK" ;;
5) echo "USER_REQUEST" ;;

would not appear to warrant an error tag at all. And the remainder, except 21, would appear to be rather specific than to be labelled as Unknown error.

Perhaps

*) echo "UNKNOWN_ERROR" ;;

is meant to be anything else that is not covered by codes 1 - 21 but that is not how it turns out on (LuCI) display.

I would thus humbly suggest to sort non-errors from actual errors and not tag the Unknown error to any of the specific error codes. It may help others that find themselves in a similar situation.


Whilst not being part of the topic but in a way related perhaps implementing

--verbose

for ifup || ifdown might go a long way in debugging connectivity issues.

18.11.20181960Base systemBug ReportVery LowLowhostapd/netifd: multicast_to_unicast/hairpin not set fo...openwrt-18.06Unconfirmed Task Description

I noticed that multicast_to_unicast and hairpin_mode are not set on the dynamically created wlan interfaces, and the wireless ap is not running in isolate mode. This is because these interfaces are created by hostapd, unlike other wlan interfaces which are created from netifd/system-linux.

The attached patch fixes this:
- it sets ap_isolate for the hostapd interface, if the interface is using dynamic vlan
- it sets multicast_to_unicast and hairpin_mode after the dynamic interface is created

I haven’t handled the case where the isolate option is not set for the wifi interface, or where multicast_to_unicast is not set on the bridge, since this requires passing additional information to hostapd, and I wasn’t sure what the preferred way to do this would be. I’d probably overload the ap_isolate option to have value 2 mean that multicast_to_unicast and hairpin_mode should be set.


03.08.20181726Base systemBug ReportVery LowCriticalNetifd lockup when USB LTE modem was restartedopenwrt-18.06Unconfirmed Task Description

OpenWrt 18.06.0, r7188-b0b5c64c22
Device: Xiaomi Mir3G
Modem: Huawei E3372

How to reproduce:
1. Bring up wwan interface
2. Reconnect modem (or echo ‘at^reset’ > /dev/ttyUSB0)
3. See in logs:

Fri Aug  3 16:59:02 2018 kern.info kernel: [  950.710901] usb 1-1: USB disconnect, device number 3
Fri Aug  3 16:59:02 2018 kern.info kernel: [  950.716646] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
Fri Aug  3 16:59:02 2018 kern.info kernel: [  950.725206] option 1-1:1.0: device disconnected
Fri Aug  3 16:59:02 2018 kern.info kernel: [  950.730738] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
Fri Aug  3 16:59:02 2018 kern.info kernel: [  950.739145] option 1-1:1.1: device disconnected
Fri Aug  3 16:59:02 2018 kern.info kernel: [  950.744808] huawei_cdc_ncm 1-1:1.2 wwan0: unregister 'huawei_cdc_ncm' usb-1e1c0000.xhci-1, Huawei CDC NCM device
Fri Aug  3 16:59:02 2018 daemon.notice netifd: Network device 'wwan0' link is down
Fri Aug  3 16:59:02 2018 daemon.notice netifd: Network alias 'wwan0' link is down
Fri Aug  3 16:59:02 2018 daemon.notice netifd: Interface 'wwan_4' has link connectivity loss
Fri Aug  3 16:59:02 2018 daemon.notice netifd: Interface 'wwan_4' is disabled
Fri Aug  3 16:59:02 2018 daemon.info chronyd[1303]: Source 94.247.111.10 offline
Fri Aug  3 16:59:02 2018 daemon.info chronyd[1303]: Source 195.91.239.8 offline
Fri Aug  3 16:59:02 2018 daemon.info chronyd[1303]: Source 91.207.136.50 offline
Fri Aug  3 16:59:02 2018 daemon.info chronyd[1303]: Source 195.210.189.106 offline
Fri Aug  3 16:59:02 2018 daemon.info chronyd[1303]: Can't synchronise: no selectable sources
Fri Aug  3 16:59:02 2018 daemon.notice netifd: wwan_4 (4421): udhcpc: SIOCGIFINDEX: No such device
Fri Aug  3 16:59:02 2018 daemon.notice netifd: wwan_4 (4421): udhcpc: received SIGTERM
Fri Aug  3 16:59:03 2018 daemon.notice netifd: wwan (4800): Stopping network wwan
Fri Aug  3 16:59:03 2018 daemon.notice netifd: wwan (4800): Can't open device /dev/ttyUSB1.
Fri Aug  3 16:59:03 2018 daemon.notice netifd: wwan (4800): Failed to disconnect
Fri Aug  3 16:59:03 2018 daemon.notice netifd: Interface 'wwan' is now down
Fri Aug  3 16:59:03 2018 daemon.warn dnsmasq[4567]: no servers found in /tmp/resolv.conf.auto, will retry
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.683961] usb 1-1: new high-speed USB device number 4 using xhci-mtk
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.867590] option 1-1:1.0: GSM modem (1-port) converter detected
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.874380] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB0
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.882334] option 1-1:1.1: GSM modem (1-port) converter detected
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.889115] usb 1-1: GSM modem (1-port) converter now attached to ttyUSB1
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.915707] huawei_cdc_ncm 1-1:1.2: resetting NTB format to 16-bit
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.926799] huawei_cdc_ncm 1-1:1.2: MAC-Address: 00:1e:10:1f:00:00
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.933038] huawei_cdc_ncm 1-1:1.2: setting rx_max = 16384
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.938957] huawei_cdc_ncm 1-1:1.2: NDP will be placed at end of frame for this device.
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.947454] huawei_cdc_ncm 1-1:1.2: cdc-wdm0: USB WDM device
Fri Aug  3 16:59:09 2018 kern.info kernel: [  957.955970] huawei_cdc_ncm 1-1:1.2 wwan0: register 'huawei_cdc_ncm' at usb-1e1c0000.xhci-1, Huawei CDC NCM device, 00:1e:10:1f:00:00
Fri Aug  3 16:59:10 2018 daemon.notice netifd: Interface 'wwan' is setting up now
Fri Aug  3 16:59:10 2018 daemon.notice netifd: wwan (5197): Stopping network wwan
Fri Aug  3 16:59:11 2018 daemon.notice netifd: wwan (5197): sending ->
Fri Aug  3 16:59:15 2018 daemon.notice netifd: Interface 'wwan' is now down

Now ``ifup wwan`` or ``ifdown wwan`` doesn’t do anything until restart of netifd process.

08.06.20181581OtherBug ReportVery LowHighnetifd:Failed to bring up static 6rd tunnel after we mo...AllUnconfirmed Task Description

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

netifd-0f96606b7040b8e14190ff055d5761744bc15f6d

- Steps to reproduce

Step 1: Create a DHCPv4 + dynamic 6rd wan connection. Below is the /etc/config/network. wan and wan6 go up after “/etc/init.d/network reload”

[CXNK00123457] /lib/netifd/proto # cat /etc/config/network 

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 'auto'

config interface 'lan'
	option ifname 'eth0'
	option type 'bridge'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '64'

config interface 'pvtlan'
	option proto 'static'
	option ipaddr '169.254.1.1'
	option netmask '255.255.255.0'

config interface 'wan'
	option ifname 'eth1'
	option proto 'dhcp'
	option peerdns '1'
	option defaultroute '1'
	option vendorid '844Ei.ONT.dslforum.org'
	option reqopts '43 120 121'
	option iface6rd 'wan6'

Step 2: Edit /etc/config/network file, disable dynamic 6rd and provision a static one

[CXNK00123457] /etc/config # cat network.static6rd 

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 'auto'

config interface 'lan'
	option ifname 'eth0'
	option type 'bridge'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '64'

config interface 'pvtlan'
	option proto 'static'
	option ipaddr '169.254.1.1'
	option netmask '255.255.255.0'

config interface 'wan'
	option ifname 'eth1'
	option proto 'dhcp'
	option peerdns '1'
	option defaultroute '1'
	option vendorid '844Ei.ONT.dslforum.org'
	option reqopts '43 120 121'

config interface 'wan6'
	option ifname 'eth1'
	option proto '6rd'
	option peerdns '0'
	option defaultroute '1'
	list dns '2001:db8:1::a'
	list dns '2001:db8:1::b'
	option tunlink 'wan'
	option peeraddr '10.101.1.1'
	option ip6prefix '2602::'
	option ip6prefixlen '32'
	option ip4prefixlen '24'

Step 3: Run “/etc/init.d/network reload”. However, netifd failed to bring up the static 6rd tunnel wan6.

Here is the log of netifd from /var/log/messages. From the log, it seems that netifd was trying to bring up wan6 before wan (DHCPv4) went up. See “netifd: Interface ‘wan6’ is setting up now”. Does this matter?

[CXNK00123457] /etc/config # /etc/init.d/network reload 
Wed Jun  6 06:26:25 2018 daemon.notice netifd: Interface 'wan6' has lost the connection
Wed Jun  6 06:26:25 2018 daemon.warn dnsmasq[19262]: no servers found in /tmp/resolv.conf.auto, will retry
Wed Jun  6 06:26:25 2018 daemon.notice netifd: tunnel '6rd-wan6' link is down
Wed Jun  6 06:26:26 2018 daemon.notice netifd: Interface 'wan6' is now down
Wed Jun  6 06:26:26 2018 daemon.notice netifd: Interface 'wan6' is setting up now
Wed Jun  6 06:26:26 2018 daemon.notice netifd: wan (2641): Received SIGTERM
Wed Jun  6 06:26:26 2018 daemon.notice netifd: Interface 'wan' is now down
Wed Jun  6 06:26:26 2018 daemon.notice netifd: Interface 'wan' is disabled
Wed Jun  6 06:26:26 2018 daemon.notice netifd: Interface 'wan' has link connectivity loss
Wed Jun  6 06:26:26 2018 kern.info kernel: [119305.628866] 8021q: adding VLAN 0 to HW filter on device eth1
Wed Jun  6 06:26:26 2018 kern.info kernel: [119305.630319] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
Wed Jun  6 06:26:26 2018 daemon.notice netifd: Interface 'wan' is enabled
Wed Jun  6 06:26:27 2018 daemon.notice netifd: Interface 'wan6' is now down
Wed Jun  6 06:26:28 2018 daemon.notice netifd: Network device 'eth1' link is up
Wed Jun  6 06:26:28 2018 daemon.notice netifd: Interface 'wan' has link connectivity 
Wed Jun  6 06:26:28 2018 daemon.notice netifd: Interface 'wan' is setting up now
Wed Jun  6 06:26:28 2018 kern.info kernel: [119307.631409] e1000: eth1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Wed Jun  6 06:26:28 2018 kern.info kernel: [119307.632184] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Wed Jun  6 06:26:29 2018 daemon.notice netifd: wan (3351): udhcpc (v1.23.2) started
=========== interface wan disconnected ===========
Wed Jun  6 06:26:30 2018 daemon.notice netifd: wan (3351): Sending discover...
Wed Jun  6 06:26:31 2018 daemon.notice netifd: wan (3351): Sending select for 10.101.1.100...
Wed Jun  6 06:26:31 2018 daemon.notice netifd: wan (3351): Lease of 10.101.1.100 obtained, lease time 503
Wed Jun  6 06:26:31 2018 daemon.notice netifd: Interface 'wan' is now up
Wed Jun  6 06:26:31 2018 daemon.info dnsmasq[19262]: reading /tmp/resolv.conf.auto
Wed Jun  6 06:26:31 2018 daemon.info dnsmasq[19262]: using local addresses only for domain lan
Wed Jun  6 06:26:31 2018 daemon.info dnsmasq[19262]: using nameserver 10.101.0.1#53
=========== interface wan connected ===========
Wed Jun  6 06:26:31 2018 daemon.notice netifd: wan (3351): rgcommon>sys update-interface-status wan
Wed Jun  6 06:26:32 2018 user.notice firewall: Reloading firewall due to ifup of wan (eth1)

20.05.20181554Base systemBug ReportVery LowMediumprocd/netifd: on shutdown direct start stopping netifd ...AllUnconfirmed Task Description

procd does not stop services managed by procd or not on shutdown before start stopping netifd
If there is no tun-ovpn and br-guest then br-lan is the first network that is stopped.
Consequence: ie radicale (not managed by procd) and dropbear (managed by procd) get no chance to correctly close their client connections.
So client-site running into timeout with possibly incomplete data transfer.

Log:

....
12:00:51 daemon.info procd: - shutdown -
12:00:53 daemon.notice netifd: Network device 'tun-ovpn' link is down
12:00:53 daemon.notice netifd: Interface 'ovpn' has link connectivity loss
12:00:53 daemon.notice netifd: Interface 'ovpn' is now down
12:00:53 daemon.notice netifd: Interface 'ovpn' is disabled
12:00:56 user.warn radicale[----]: Service shutdown FORCED
12:00:56 user.notice radicale[6141]: Service stoped successfully
12:00:56 authpriv.info dropbear[5674]: Early exit: Terminated by signal
12:00:56 authpriv.info dropbear[5675]: Early exit: Terminated by signal
12:00:56 daemon.notice netifd: Interface 'guest' is now down
12:00:56 kern.info kernel: [ 245.292858] br-guest: port 2(wlanif5g) entered disabled state
12:00:56 kern.info kernel: [ 245.298826] br-guest: port 1(wlanif2g) entered disabled state
....


30.03.20181463PackagesBug ReportVery LowMediumnetifd disagrees with static route documentationTrunkUnconfirmed Task Description

https://openwrt.org/docs/guide-user/network/routes_configuration says, of the static route “gateway” configuration variable, “If omitted, the gateway from the parent interface is taken; if set to 0.0.0.0 no gateway will be specified for the route”. However, netifd HEAD does not distinguish all zeros from unset. In particular, https://git.openwrt.org/?p=project/netifd.git;a=blob;f=interface-ip.c;h=1c84d4f8afed8bbe8af9fcc868fb1472b048019d;hb=HEAD#l343 is the only place where ROUTE_GATEWAY is decoded from a blob message and will leave route→nexthop all zeros if none is provided:

 343         if ((cur = tb[ROUTE_GATEWAY]) != NULL) {
 344                 if (!inet_pton(af, blobmsg_data(cur), &route->nexthop)) {
 345                         DPRINTF("Failed to parse route gateway: %s\n", (char *) blobmsg_data(cur));
 346                         goto error;
 347                 }
 348         }

When it comes time to actually use the resulting route→nexthop value, https://git.openwrt.org/?p=project/netifd.git;a=blob;f=system-linux.c;h=0ca525602d9ea63ac5b845b2be9c6c7bdec7c26c;hb=HEAD#l1851 just checks for all-zeros and, if so, declares it to be a link-local route:

1851         if (alen == 4)
1852                 have_gw = !!route->nexthop.in.s_addr;
1853         else
1854                 have_gw = route->nexthop.in6.s6_addr32[0] ||
1855                         route->nexthop.in6.s6_addr32[1] ||
1856                         route->nexthop.in6.s6_addr32[2] ||
1857                         route->nexthop.in6.s6_addr32[3];
...
1882                         rtm.rtm_scope = (have_gw) ? RT_SCOPE_UNIVERSE : RT_SCOPE_LINK;
...
1925         if (have_gw)
1926                 nla_put(msg, RTA_GATEWAY, alen, &route->nexthop);

I believe that struct device_route needs a flag to indicate whether the incoming blobmsg had a ROUTE_GATEWAY or not, and that system_rt should use the device’s configured default gateway if not. There is, at present, no workaround except to hard-code the next hop in the configuration, which is gross.

24.08.2017978Base systemBug ReportVery LowLownetifd: support smaller ipv6 segments than /64TrunkUnconfirmed Task Description

netifd makes the assumption that ipv6 segments will never be any smaller than a /64; it quite often computes things like (1 « (64 - prefix→length)) which obviously won’t work out very well when prefix→length > 64. (Incidentally, it looks like it’s never been tested with prefixes larger than a /32, too, since things like “int32_t current = 0, asize = (1 « (64 - assign→length)) - 1;” will also not work out very well when assign→length ⇐ 32.)

The Linux network stack itself is more than happy to operate with these smaller segments, and odhcpd happily hands out leases. I know SLAAC won’t work on these segments, but that’s no reason to keep netifd from believing in them, IMHO. As it stands, I have several interfaces configured that the ubus-centric tools refuse to believe are set up!

19.04.2017718Base systemBug ReportVery LowLownetifd fails to set rps for WDSTrunkUnconfirmed Task Description

netifd sets the packet steering for all interfaces it controls to better spread the load over multiple cores. But it fails to set it for wds interfaces like wlan0.sta1. As result, the performance in WDS setups is limited by a single core of a multi-core device.

To reproduce: enable an AP in /etc/config/wireless. Enable the wds option for the AP interface. Connect a client to the AP and check /sys/devices/*/net/wlan*.sta1/queues/rx-*/rps_cpus. All BITS for all available CPUs should be enabled (when it would work). It stays currently at 0.

17.04.2017713Base systemBug ReportVery LowLownetifd: substantially more IFUP events are being create...TrunkResearching Task Description

I have noticed that some services reloaded with a procd “interface.*” raw trigger are reloading on a much more frequent cadence (few minutes or so). LEDE 17.01 does not do this. LEDE Trunk does. I can not find an obvious cause in procd. Though procd should not stop-start for reload without a command line change or explicit file under watch. Perhaps netifd commit a03216660797173fbe67866f75564e3fec9c1e8d is generating unusual numbers of IFUP.

procd_add_raw_trigger “interface.*” 2000 /etc/init.d/[script] reload

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 - 19 of 19 Page 1 of 1

Available keyboard shortcuts

Tasklist

Task Details

Task Editing