OpenWrt/LEDE Project

Welcome to the OpenWrt Project bug reporting and issue tracking system

Problems to be reported here are for the current OpenWrt and legacy LEDE Project’s targets, sources, toolchain, core packages, build procedures, distribution and infrastructure. Guidelines for submitting a good bug report can be found at the OpenWrt 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 openwrt-bugs@infradead.org.

OpenedIDCategory  ascTask TypePrioritySeveritySummaryReported InStatus
26.05.20213830Base systemBug ReportVery LowMediumOpenVPN Client Using TCP Connection Has MTU or TCPMSS I...openwrt-21.02Unconfirmed Task Description

OpenVPN Client connects to a TCP based OpenVPN server connects fine. However, the connections to remote network servers connect but can’t transfer data. The mangle rule with clamp-mss-to-pmtu won’t receive any data. Setting tcpmss to something around 1000 will only receive the first 100 - 200 bytes and hang. It’s not working until reduced tcpmss to 59.

iptables -t nat -A postrouting_rule -o tun0 -j MASQUERADE
iptables -t mangle -A POSTROUTING -o tun0 -p tcp -m tcp –tcp-flags SYN,RST SYN -j TCPMSS –set-mss 59
#iptables -t mangle -A POSTROUTING -o tun0 -p tcp -m tcp –tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu

26.05.20213829Base systemBug ReportVery LowHighNo WiFi after upgrading from 19.07 to 21.02openwrt-21.02Unconfirmed Task Description

Device : Zyxel P2812 F1
Version : 21.02 snapshot r16824-91abeebd3b

Steps:
- Router with 19.07.4
- Upgrade to 21.02 (this is a custom build version because the version on the openwrt-download does not work (bug 2226))
- after reboot the WiFi device is not available
- run WiFi up resuls in message in logread:

Wed May 26 22:30:03 2021 daemon.notice netifd: radio0 (2491): Could not find PHY for device ‘radio0’ Wed May 26 22:30:03 2021 daemon.notice netifd: radio0 (2499): WARNING: Variable ‘data’ does not exist or is not an array/object


Attached is dmesg-log and config


26.05.20213828Base systemBug ReportVery LowLowNAT Reflection is not workingopenwrt-21.02Unconfirmed Task Description

Forwarding port 443 from WAN to an internal machine on LAN works from outside but not LAN. The https access from LAN to the WAN public IP is not working. It looked like the packet is dropped after NAT PREROUTING.

 


24.05.20213823Base systemBug ReportVery LowCriticalethernet down after rebootopenwrt-21.02Unconfirmed Task Description

the problemi is with turris omnia and owrt 21.02-rc1 , fresh installation, no additional package
the turris is connected to
wan device
a second wan device (lan4)
a raspberry (lan3)
a switch (lan2)

all work with the 19.07.7
logread https://pastebin.com/XbzQL9aN ip address https://pastebin.com/9hcES8WQ

after upgrading to 21.02.0-rc1 at first reboot , i have in the serial console an error about “partx: /dev/mmcblk0 delete/adding” , i don’t know if it is normal or not
https://pastebin.com/g3CL8j1f

at first boot , here logread https://pastebin.com/V7Tsuvbd
i lost the device on the lan2 , it says “LOWERLAYERDOWN” and no led light on, but the user is connected https://pastebin.com/0033LAnL

if i reboot , here logread https://pastebin.com/8yxyvyL5 , i lost the other lan3 device , no light on https://pastebin.com/BmwRj5B3

no matter if i reboot the device or power it on/off
the front panel led litgh on according to the ip address state (UP/DOWN)

reverting to 19.07.7 , solve the problem

tried 3 time to flash 21.02 , same beahviour

 


22.05.20213821Base systemBug ReportVery LowCriticalRandom link down on RB 750Gr3openwrt-21.02Unconfirmed Task Description

HW: Mikrotik Routerboard 750Gr3
SW: linux version 5.4.119 (cezary@eko.one.pl) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r15819-0011c7ad12)) #0 SMP Fri May 14 21:36:47 2021

I am randomly loosing connection with the router for a few seconds. Here is the system log after the link is reestablished:

Sat May 22 16:32:05 2021 kern.info kernel: [24372.328509] mt7530 mdio-bus:1f lan2: Link is Down
Sat May 22 16:32:05 2021 kern.info kernel: [24372.333341] br-lan: port 1(lan2) entered disabled state
Sat May 22 16:32:05 2021 daemon.notice netifd: Network device 'lan2' link is down
Sat May 22 16:32:06 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sat May 22 16:32:06 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sat May 22 16:32:09 2021 kern.info kernel: [24376.424716] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control rx/tx
Sat May 22 16:32:09 2021 kern.info kernel: [24376.432249] br-lan: port 1(lan2) entered blocking state
Sat May 22 16:32:09 2021 kern.info kernel: [24376.437506] br-lan: port 1(lan2) entered forwarding state
Sat May 22 16:32:09 2021 daemon.notice netifd: Network device 'lan2' link is up
Sat May 22 16:32:09 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sat May 22 16:32:09 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sat May 22 16:32:10 2021 kern.info kernel: [24377.448578] mt7530 mdio-bus:1f lan2: Link is Down
Sat May 22 16:32:10 2021 kern.info kernel: [24377.453413] br-lan: port 1(lan2) entered disabled state
Sat May 22 16:32:10 2021 daemon.notice netifd: Network device 'lan2' link is down
Sat May 22 16:32:11 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sat May 22 16:32:11 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sat May 22 16:32:13 2021 kern.info kernel: [24380.520779] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control rx/tx
Sat May 22 16:32:13 2021 kern.info kernel: [24380.528342] br-lan: port 1(lan2) entered blocking state
Sat May 22 16:32:13 2021 kern.info kernel: [24380.533562] br-lan: port 1(lan2) entered forwarding state
Sat May 22 16:32:13 2021 daemon.notice netifd: Network device 'lan2' link is up
Sat May 22 16:32:13 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sat May 22 16:32:13 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sat May 22 16:32:14 2021 kern.info kernel: [24381.544635] mt7530 mdio-bus:1f lan2: Link is Down
Sat May 22 16:32:14 2021 kern.info kernel: [24381.549486] br-lan: port 1(lan2) entered disabled state
Sat May 22 16:32:14 2021 daemon.notice netifd: Network device 'lan2' link is down
Sat May 22 16:32:15 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sat May 22 16:32:15 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sat May 22 16:32:17 2021 kern.info kernel: [24384.616828] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control rx/tx
Sat May 22 16:32:17 2021 kern.info kernel: [24384.624361] br-lan: port 1(lan2) entered blocking state
Sat May 22 16:32:17 2021 kern.info kernel: [24384.629611] br-lan: port 1(lan2) entered forwarding state
Sat May 22 16:32:17 2021 daemon.notice netifd: Network device 'lan2' link is up
Sat May 22 16:32:17 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sat May 22 16:32:17 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sat May 22 16:32:18 2021 kern.info kernel: [24385.640683] mt7530 mdio-bus:1f lan2: Link is Down
Sat May 22 16:32:18 2021 kern.info kernel: [24385.645511] br-lan: port 1(lan2) entered disabled state
Sat May 22 16:32:18 2021 daemon.notice netifd: Network device 'lan2' link is down
Sat May 22 16:32:19 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sat May 22 16:32:19 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sat May 22 16:32:21 2021 kern.info kernel: [24388.712887] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control rx/tx
Sat May 22 16:32:21 2021 kern.info kernel: [24388.720458] br-lan: port 1(lan2) entered blocking state
Sat May 22 16:32:21 2021 kern.info kernel: [24388.725684] br-lan: port 1(lan2) entered forwarding state
Sat May 22 16:32:21 2021 daemon.notice netifd: Network device 'lan2' link is up
Sat May 22 16:32:21 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sat May 22 16:32:21 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sat May 22 16:32:22 2021 kern.info kernel: [24389.736743] mt7530 mdio-bus:1f lan2: Link is Down
Sat May 22 16:32:22 2021 kern.info kernel: [24389.741572] br-lan: port 1(lan2) entered disabled state
Sat May 22 16:32:22 2021 daemon.notice netifd: Network device 'lan2' link is down
Sat May 22 16:32:23 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sat May 22 16:32:23 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sat May 22 16:32:25 2021 kern.info kernel: [24392.808941] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control rx/tx
Sat May 22 16:32:25 2021 kern.info kernel: [24392.816473] br-lan: port 1(lan2) entered blocking state
Sat May 22 16:32:25 2021 kern.info kernel: [24392.821720] br-lan: port 1(lan2) entered forwarding state
Sat May 22 16:32:25 2021 daemon.notice netifd: Network device 'lan2' link is up
Sat May 22 16:32:25 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sat May 22 16:32:25 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sat May 22 16:32:26 2021 kern.info kernel: [24393.832799] mt7530 mdio-bus:1f lan2: Link is Down
Sat May 22 16:32:26 2021 kern.info kernel: [24393.837630] br-lan: port 1(lan2) entered disabled state
Sat May 22 16:32:26 2021 daemon.notice netifd: Network device 'lan2' link is down
Sat May 22 16:32:27 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sat May 22 16:32:27 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sat May 22 16:32:30 2021 kern.info kernel: [24396.904992] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control rx/tx
Sat May 22 16:32:30 2021 kern.info kernel: [24396.912523] br-lan: port 1(lan2) entered blocking state
Sat May 22 16:32:30 2021 kern.info kernel: [24396.917771] br-lan: port 1(lan2) entered forwarding state
Sat May 22 16:32:30 2021 daemon.notice netifd: Network device 'lan2' link is up
Sat May 22 16:32:30 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sat May 22 16:32:30 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sat May 22 16:32:31 2021 kern.info kernel: [24397.928855] mt7530 mdio-bus:1f lan2: Link is Down
Sat May 22 16:32:31 2021 kern.info kernel: [24397.933692] br-lan: port 1(lan2) entered disabled state
Sat May 22 16:32:31 2021 daemon.notice netifd: Network device 'lan2' link is down
Sat May 22 16:32:32 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sat May 22 16:32:32 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sat May 22 16:32:34 2021 kern.info kernel: [24401.001066] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow control rx/tx
Sat May 22 16:32:34 2021 kern.info kernel: [24401.008643] br-lan: port 1(lan2) entered blocking state
Sat May 22 16:32:34 2021 kern.info kernel: [24401.013868] br-lan: port 1(lan2) entered forwarding state
Sat May 22 16:32:34 2021 daemon.notice netifd: Network device 'lan2' link is up
Sat May 22 16:32:34 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sat May 22 16:32:34 2021 daemon.notice netifd: Interface 'lan' has link connectivity
Sat May 22 16:32:35 2021 kern.info kernel: [24402.024917] mt7530 mdio-bus:1f lan2: Link is Down
Sat May 22 16:32:35 2021 kern.info kernel: [24402.029756] br-lan: port 1(lan2) entered disabled state
Sat May 22 16:32:35 2021 daemon.notice netifd: Network device 'lan2' link is down
Sat May 22 16:32:36 2021 daemon.notice netifd: bridge 'br-lan' link is down
Sat May 22 16:32:36 2021 daemon.notice netifd: Interface 'lan' has link connectivity loss
Sat May 22 16:32:41 2021 kern.info kernel: [24408.169236] mt7530 mdio-bus:1f lan2: Link is Up - 100Mbps/Full - flow control rx/tx
Sat May 22 16:32:41 2021 kern.info kernel: [24408.176955] br-lan: port 1(lan2) entered blocking state
Sat May 22 16:32:41 2021 kern.info kernel: [24408.182189] br-lan: port 1(lan2) entered forwarding state
Sat May 22 16:32:41 2021 daemon.notice netifd: Network device 'lan2' link is up
Sat May 22 16:32:41 2021 daemon.notice netifd: bridge 'br-lan' link is up
Sat May 22 16:32:41 2021 daemon.notice netifd: Interface 'lan' has link connectivity


20.05.20213820Base systemBug ReportVery LowHighCannot install package openwrt-keyringopenwrt-19.07Unconfirmed Task Description

Asus RT-AC51U
MediaTek MT7620A
OpenWrt 19.07.7 r11306-c4a6851c72 / LuCI openwrt-19.07 branch git-21.132.36199-d0cf6e4

 

Upgrading openwrt-keyring on root from 2019-07-25-8080ef34-1 to 2021-02-20-49283916-2...
Collected errors:
* check_data_file_clashes: Package openwrt-keyring wants to install file /etc/opkg/keys/f94b9dd6febac963

But that file is already provided by package  * base-files

* opkg_install_cmd: Cannot install package openwrt-keyring.
Downloading http://downloads.openwrt.org/releases/19.07.7/packages/mipsel_24kc/base/openwrt-keyring_2021-02-20-49283916-2_mipsel_24kc.ipk


20.05.20213819Base systemBug ReportVery LowMediumopenwrt-keyring 2021-02-20-49283916-2 update conflicts ...openwrt-19.07Unconfirmed Task Description
# opkg upgrade openwrt-keyring
Upgrading openwrt-keyring on root from 2019-07-25-8080ef34-1 to 2021-02-20-49283916-2...
Collected errors:
 * check_data_file_clashes: Package openwrt-keyring wants to install file /etc/opkg/keys/f94b9dd6febac963
	But that file is already provided by package  * base-files
Downloading http://downloads.openwrt.org/releases/19.07.7/packages/mips_24kc/base/openwrt-keyring_2021-02-20-49283916-2_mips_24kc.ipk
19.05.20213817Base systemBug ReportVery LowMediumSSIDs on 5GHz radio dissapear a few days after bootopenwrt-21.02Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

BT homehub 5a (xrx200)

- Software versions of OpenWrt/LEDE release, packages, etc.

21.02-rc1

- Steps to reproduce

 

after upgrade from 19.07 all worked, then after a few days my 5GHz SSID was no longer visible, tried disable/enable the radio0, that didn’t help, radio1 on 2.4GHz still working, had to reboot to get 5GHz back

after another 5.75 days, same happened again.

most recent messages in dmesg

[508519.675343] device wlan0 left promiscuous mode
[508519.678732] br-lan: port 3(wlan0) entered disabled state
[508519.713414] ath10k_pci 0000:02:00.0: mac flush null vif, drop 0 queues 0xffff
[508520.786031] ath10k_pci 0000:02:00.0: 10.1 wmi init: vdevs: 16  peers: 127  tid: 256
[508520.802066] ath10k_pci 0000:02:00.0: wmi print 'P 128 V 8 T 410'
[508520.806810] ath10k_pci 0000:02:00.0: wmi print 'msdu-desc: 1424  sw-crypt: 0 ct-sta: 0'
[508520.815553] ath10k_pci 0000:02:00.0: wmi print 'alloc rem: 24984 iram: 38672'
[508520.884894] ath10k_pci 0000:02:00.0: pdev param 0 not supported by firmware
[508520.898436] ath10k_pci 0000:02:00.0: rts threshold -1
[508520.912045] br-lan: port 3(wlan0) entered blocking state
[508520.916090] br-lan: port 3(wlan0) entered disabled state
[508520.922193] device wlan0 entered promiscuous mode
15.05.20213812Base systemBug ReportVery LowMediumWAVLINK WL-WN570HA1 low txpower activate amplifier v...AllUnconfirmed Task Description

Device : WAVLINK WL-WN570HA1

Firmwareversion : all (19.07.7)

At this moment it is impossible to use the full txpower of the WN570HA1 on both bands (2,4Ghz and 5Ghz).
Possible txpower at the moment:
2,4 Ghz —>24dbm (should have at least 27dbm)
5 Ghz —> 11 dbm or 13 dbm (can`t remember right now)

Is it possible, that the device uses an external amplifier which has to be activated via gpio settings?

Referring to this post for the Asus Lyra 2200, could some sort of same method activate the amp in the WN570HA1 ?
https://forum.openwrt.org/t/asus-map-ac2200-low-transmit-receive-signal-5ghz/69005

I hope that one or two replies from more experienced users/programmers could lead us in the right direction.
Thanks in advance.


13.05.20213809Base systemBug ReportVery LowHighv21.02.0-rc1 reports false missing "which" on fedora 34openwrt-21.02New Task Description

i use fedora 34, installed the required software and “which” is available on the command line

[oli@lucy openwrt]$ which which | grep which
which ()

eval ${which_declare} ) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot "$@"

but when i run “./scripts/feeds update -a” i get:
hecking ‘perl’... ok.
Checking ‘python2-cleanup’... ok.
Checking ‘python’... ok.
Checking ‘python3’... ok.
Checking ‘git’... ok.
Checking ‘file’... ok.
Checking ‘rsync’... ok.
Checking ‘which’... failed.
Checking ‘ldconfig-stub’... ok.

Build dependency: Please install ‘which’

Prerequisite check failed. Use FORCE=1 to override.
gmake: *** [/home/oli/openwrt/include/toplevel.mk:180: staging_dir/host/.prereq-build] Fehler 1

[oli@lucy ~]$ rpm -qa | grep which
which-2.21-26.fc34.x86_64

corrected the meta infos of this ticket and copied it from https://bugs.openwrt.org/index.php?do=details&task_id=3805

13.05.20213808Base systemBug ReportVery LowHighASUS RT-AC57N wrong wan interfaceopenwrt-21.02Unconfirmed Task Description

After installation LEDE 21.02-rc1 on ASUS RT-AC57N wan interface was assigned to eth0, not eth0.2 as it was on 19.07, thus it cannot obtain an IP address from ISP.

I’ve tried to copy interface setup from 19.07, as:

config interface ‘wan’

      option ifname 'eth0.2'
      option proto 'dhcp'

config device ‘wan_eth0_2_dev’

      option name 'eth0.2'
      option macaddr '40:b0:76:9d:89:f0'

but it also has not helped.


13.05.20213807Base systemBug ReportVery LowLowlsusb not working only with one deviceTrunkUnconfirmed Task Description

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

 

the problem is on unielec U7621 (several unit)
fresh install OpenWrt 21.02.0-rc1 , add usbutils , lte modem huawei me909 (tried several unit) , doesn’t show with lsusb command , the same hardware with OpenWrt 19.07.3 work correctly
if i see /sys/kernel/debug/usb/devices , the device is present, and if i load the modem module it works!!
on the same router if i try sierra wireless mc 7430 modem,the lsusb command see it!!
the same huawei modem, tried with an usb adapter into a unielec U7621 , work

link to 19.07 test https://pastebin.com/gUSTqcXM link to 21.02 test https://pastebin.com/Web7kXGe

let me know if i can test something else


11.05.20213798Base systemBug ReportVery LowMediumflashing the install image leaves overlay filesystem in...openwrt-21.02Unconfirmed Task Description

I’m using the image builder for 21.02.0-rc1, specifically the one targeting bcm2709.

When I flash an install image, the resulting system image references an overlay filesystem (an ext4), the superblock of which is beyond the end of the install image itself. Therefore, flashing an install image may leave files from a previous overlay filesystem in place. This is counterintuitive, because I expected that flashing the install image would leave the OS in a well-defined state.

As a workaround, I’ve been appending 64KB of zeroes to the end of the install image, which seems to fix the problem.

Reproduction steps:

1. Build an image, flash it, boot it
2. Create files in the overlay filesystem
3. Remove card and reflash; files in the overlay filesystem remain

Thanks for your time!


09.05.20213791Base systemBug ReportVery LowHighMT7603E disconnects or at the very least has terrible l...TrunkUnconfirmed Task Description

To reproduce just do a flent test:

 //flent rrul -p all_scaled -l 60 -H netperf.bufferbloat.net -o image.png//

The only configuration changes was to set the wireless to enabled with encryption set to mixed WPA2/WPA3 PSK, SAE (CCMP)

Attached are images from a WSL2 instance on a windows 10 Intel 9560 laptop connected to the 2.4GHz radio (MT7603E) on a Linknetgear r6220 running OpenWrt 21.02 rc1. The laptop will disconnect before finishing. When running on wrt3200acm or r7800 there are no connection issues like this. Test was also done with a local 192.168.1.2 host directly wired into the r6220.

06.05.20213787Base systemBug ReportVery LowMedium21.02 RC1: BUG: Bad page state in process swapper/0openwrt-21.02Unconfirmed Task Description

Device used: RT-AC57U (mt7621 based device)
Version used: 21.02 RC1
Steps to reproduce: This ended up in my kernel log after a few days of uptime. I am unsure what exactly caused the issue.

I am currently beta testing the new 21.02 RC1 release on two different devices. Stability seems very good, but I did run into an issue with the aforementioned RT-AC57U. I found this stacktrace in the kernel log. I am unsure if this caused the network to go down, since I am not sure if I was using the network at that time. Does anyone have any idea what is causing this?

[410758.374134] BUG: Bad page state in process swapper/0  pfn:05edc
[410758.386105] page:809236f0 refcount:-1 mapcount:0 mapping:00000000 index:0x0
[410758.400121] flags: 0x0()
[410758.405331] raw: 00000000 00000000 00000122 00000000 00000000 00000000 ffffffff ffffffff
[410758.421588] raw: 00000000
[410758.426956] page dumped because: nonzero _refcount
[410758.436644] Modules linked in: xt_connlimit pppoe ppp_async nf_conncount iptable_nat xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT wireguard pppox ppp_generic nf_nat_pptp nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack_pptp nf_conntrack_netlink nf_conntrack mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 libchacha20poly1305 libblake2s ipt_REJECT cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_recent xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY ts_kmp ts_fsm ts_bm slhc sch_cake poly1305_mips nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 libcurve25519_generic libblake2s_generic iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat chacha_mips br_netfilter sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit
[410758.436829]  act_mirred ledtrig_usbport xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ifb ip6_udp_tunnel udp_tunnel kpp leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd gpio_button_hotplug usbcore nls_base usb_common
[410758.712580] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.111 #0
[410758.724692] Stack : 00000000 80840000 00000003 8007d6e0 00000000 00000000 00000000 00000000
[410758.741481]         00000000 00000000 00000000 00000000 00000000 00000001 87c0db80 5fc2ce17
[410758.758268]         87c0dc18 00000000 00000000 00000000 00000038 805e1804 2e352064 31312e34
[410758.775053]         00000000 00004fd5 00000000 70617773 00000000 87c0db60 00000000 80840000
[410758.791840]         80604b20 806b0000 00000000 806d7f20 00000000 80359e2c 00000000 80810000
[410758.808627]         ...
[410758.813649] Call Trace:
[410758.813663] [<8007d6e0>] 0x8007d6e0
[410758.825779] [<805e1804>] 0x805e1804
[410758.832880] [<80359e2c>] 0x80359e2c
[410758.839978] [<8000b05c>] 0x8000b05c
[410758.847075] [<8000b064>] 0x8000b064
[410758.854173] [<805c6f9c>] 0x805c6f9c
[410758.861271] [<8014dabc>] 0x8014dabc
[410758.868420] [<80150ca4>] 0x80150ca4
[410758.875519] [<804a8b28>] 0x804a8b28
[410758.882662] [<806e0000>] 0x806e0000
[410758.889769] [<80151c80>] 0x80151c80
[410758.896866] [<80063508>] 0x80063508
[410758.903966] [<80150015>] 0x80150015
[410758.911063] [<804326ac>] 0x804326ac
[410758.918163] [<8001e448>] 0x8001e448
[410758.925262] [<80152bc4>] 0x80152bc4
[410758.932359] [<80433040>] 0x80433040
[410758.939456] [<800939cc>] 0x800939cc
[410758.946554] [<803dd720>] 0x803dd720
[410758.953652] [<800104dc>] 0x800104dc
[410758.960754] [<80433858>] 0x80433858
[410758.967852] [<80433acc>] 0x80433acc
[410758.974952] [<805e7d1c>] 0x805e7d1c
[410758.982053] [<80030768>] 0x80030768
[410758.989150] [<802f8404>] 0x802f8404
[410758.996249] [<80006c28>] 0x80006c28
[410759.003344] 
[410759.006466] Disabling lock debugging due to kernel taint
05.05.20213783Base systemBug ReportVery LowCriticalMT7621 WiFi driver crash openwrt-21.02Unconfirmed Task Description

Summary

The WiFi driver crashes on an MT7621 router running OpenWRT21.02rc1 (5 commits further to be exact 6f053e5b).
The router used is an InvizBox Go (WiFi only) i.e. MT7621 + MT7603E (not supported by OpenWRT just yet - I’m working on getting there). I don’t believe the issue is specific to that hardware though.

The crash seems to happen in AP/STA mode when an AP gets added to the configuration and the STA was connected (I’ll add more information if I come across more scenarios). I’m not able to reproduce consistently at the moment.
Once crashed the WiFi stack is not usable anymore until a reboot. Following a reboot, things are back to normal.

The crash stack is as follow:

[  726.587920] ------------[ cut here ]------------
[  726.597570] WARNING: CPU: 0 PID: 1767 at backports-5.10.16-1/net/mac80211/ieee80211_i.h:1468 sta_info_alloc+0x5c4/0x5fc [mac80211]
[  726.621113] Modules linked in: xt_connlimit pppoe ppp_async nf_conncount iptable_nat xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADEr
[  726.621458]  algif_skcipher algif_rng algif_hash algif_aead af_alg sha256_generic libsha256 sha1_generic jitterentropy_rng drbg md5 hmac echainiv des_generic libdes cbc authec
[  726.859235] CPU: 0 PID: 1767 Comm: hostapd Not tainted 5.4.111 #0
[  726.871379] Stack : 8e375fb4 8007ce5c 80660000 80660d78 806c0000 80660d40 8065fe94 8e257a34
[  726.888032]         80800000 8dc34188 806aa6e3 805f993c 00000000 00000001 8e2579d8 72c69b9f
[  726.904659]         00000000 00000000 80830000 00000000 30232031 0000014b 2e352064 31312e34
[  726.921286]         00000000 00000024 00000000 000d1c63 80000000 806c0000 00000000 8e3075b8
[  726.937913]         00000009 8e146480 00000005 00000002 00000000 8034dfbc 00000000 80800000
[  726.954538]         ...
[  726.959397] Call Trace:
[  726.964284] [<8000b64c>] show_stack+0x30/0x100
[  726.973153] [<80542370>] dump_stack+0xa4/0xdc
[  726.981832] [<8002bee0>] __warn+0xc0/0x10c
[  726.989981] [<8002bf88>] warn_slowpath_fmt+0x5c/0xac
[  727.000018] [<8e3075b8>] sta_info_alloc+0x5c4/0x5fc [mac80211]
[  727.011712] [<8e3259b0>] ieee80211_nan_func_match+0x3d88/0x4410 [mac80211]
[  727.025846] ---[ end trace bc705bf94f0c5c24 ]---

Steps to reproduce

The following steps do not necessarily lead to the crash. I expect them to be what leads to it but am still unsure. The stack may show the way to a better reproduction scenario...

On an MT7621 router setup as AP/STA, add a second AP and possibly a third one.
Call /etc/init.d/network reload after each change

Current behaviour

Crash stack is visible in console/dmesg and the STA fails to reconnect (which also leads all APs to become not accessible - expected).

Expected behaviour

No crash

Notes This crash was also observed on builds before the rc1 tag. I don’t know the conditions leading to these crashes.

I had saved one older crash stack (truncated by console unfortunately) as a reference (early 21.02 branch when I started testing in preparation for release):

[ 1939.972549] ------------[ cut here ]------------
[ 1939.982051] WARNING: CPU: 2 PID: 2079 at backports-5.10.16-1/net/mac80211/ieee80211_i.h:1468 sta_info_alloc+0x5c4/0x]
[ 1940.005526] Modules linked in: xt_connlimit pppoe ppp_async nf_conncount iptable_nat xt_state xt_nat xt_helper xt_cor
[ 1940.005842]  algif_skcipher algif_rng algif_hash algif_aead af_alg sha256_generic libsha256 sha1_generic jitterentroc
[ 1940.243641] CPU: 2 PID: 2079 Comm: hostapd Not tainted 5.4.111 #0
[ 1940.255784] Stack : 8df75fb4 8007ce5c 80660000 80660d78 806c0000 80660d40 8065fe94 8dd01a34
[ 1940.272451]         80800000 8fe51fc8 806aa6e3 805f993c 00000002 00000001 8dd019d8 91468ee6
[ 1940.289110]         00000000 00000000 80830000 00000000 30232031 0000012f 2e352064 31312e34
[ 1940.305752]         00000000 00000060 00000000 0003b7b9 80000000 806c0000 00000000 8df075b8
[ 1940.322392]         00000009 8fed4480 00000005 00000002 00000000 8034dfbc 00000008 80800008
[ 1940.339021]         ...
[ 1940.343883] Call Trace:
[ 1940.348778] [<8000b64c>] show_stack+0x30/0x100
[ 1940.357652] [<80542370>] dump_stack+0xa4/0xdc
[ 1940.366336] [<8002bee0>] __warn+0xc0/0x10c
[ 1940.374487] [<8002bf88>] warn_slowpath_fmt+0x5c/0xac
[ 1940.384532] [<8df075b8>] sta_info_alloc+0x5c4/0x5fc [mac80211]
[ 1940.396280] [<8df259b0>] ieee80211_nan_func_match+0x3d88/0x4410 [mac80211]
[ 1940.410460] ---[ end trace dda71e821ee728c4 ]---
05.05.20213782Base systemBug ReportVery LowCriticalTP-Link CPE510 v2 bootloop with 21.02.0-rc1openwrt-21.02Requires testing Task Description

Installing the 21.02.0-rc1 Sysupgrade image on the TP-Link CPE510 v2 or TP-Link CPE610 v1 results in the same bootloop as reported in https://bugs.openwrt.org/index.php?do=details&task_id=3750

Here is a log from my device with a line length of 80 chars

TP-LINK SafeLoader (Build time: Jun 14 2017 - 10:08:41)
CPU: 560MHz AHB: 225MHz DDR: 8MB
Performing LED check..  PASS
Press CTRL+B to enter SafeLoader: 1

Allocated memory for elf segment ok: addr: 0x80060000, size 0x16dc
Loading .text @ 0x80060000 (5852 bytes)

Starting kernel


OpenWrt kernel loader for AR7XXX/AR9XXX
Copyright (C) 2011 Gabor Juhos <juhosg@openwrt.org>
Looking for OpenWrt image... found at 0xbf043000
Decompressing kernel... done!
Starting kernel at 80060000...
[    0.000000] Linux version 5.4.111 (builder@buildhost) (gcc version 8.4.0 (Ope
[    0.000000] printk: bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 0001974c (MIPS 74Kc)
[    0.000000] MIPS: machine is TP-Link CPE510 v2
[    0.000000] SoC: Atheros AR9344 rev 2
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff]
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16240
[    0.000000] Kernel command line: console=ttyS0,115200 rootfstype=squashfs,jf
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, li
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, lin
[    0.000000] Writing ErrCtl register=00000000
[    0.000000] Readback ErrCtl register=00000000
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 57336K/65536K available (5216K kernel code, 190K rwdata,
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 51
[    0.000000] random: get_random_bytes called from 0x80655984 with crng_init=0
[    0.000000] CPU clock: 560.000 MHz
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_
[    0.000010] sched_clock: 32 bits at 280MHz, resolution 3ns, wraps every 7669
[    0.009095] Calibrating delay loop... 278.78 BogoMIPS (lpj=557568)
[    0.052225] pid_max: default: 32768 minimum: 301
[    0.057783] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, line
[    0.066284] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes,
[    0.080827] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, m
[    0.092208] futex hash table entries: 256 (order: -1, 3072 bytes, linear)
[    0.100259] pinctrl core: initialized pinctrl subsystem
[    0.109580] NET: Registered protocol family 16
[    0.117299] GPIO line 18 (tp-link:ext:lna0) hogged as output/high
[    0.124466] GPIO line 19 (tp-link:ext:lna1) hogged as output/high
[    0.159972] workqueue: max_active 576 requested for napi_workq is out of ran
[    0.176037] clocksource: Switched to clocksource MIPS
[    0.183518] NET: Registered protocol family 2
[    0.189793] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096
[    0.199606] TCP established hash table entries: 1024 (order: 0, 4096 bytes, 
[    0.208534] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.216742] TCP: Hash tables configured (established 1024 bind 1024)
[    0.224301] UDP hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.231970] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear)
[    0.240490] NET: Registered protocol family 1
[    0.245632] PCI: CLS 0 bytes, default 32
[    0.255091] workingset: timestamp_bits=14 max_order=14 bucket_order=0
[    0.271344] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.278179] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORI
[    0.307686] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
[    0.321044] pinctrl-single 1804002c.pinmux: 544 pins, size 68
[    0.329034] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
[    0.339440] printk: console [ttyS0] disabled
[    0.344535] 18020000.uart: ttyS0 at MMIO 0x18020000 (irq = 9, base_baud = 25
[    0.354585] printk: console [ttyS0] enabled
[    0.354585] printk: console [ttyS0] enabled
[    0.363495] printk: bootconsole [early0] disabled
[    0.363495] printk: bootconsole [early0] disabled
[    0.388005] spi-nor spi0.0: gd25q64 (8192 Kbytes)
[    0.392920] 6 fixed-partitions partitions found on MTD device spi0.0
[    0.399384] Creating 6 MTD partitions on "spi0.0":
[    0.404285] 0x000000000000-0x000000020000 : "u-boot"
[    0.410563] 0x000000020000-0x000000030000 : "partition-table"
[    0.417611] 0x000000030000-0x000000040000 : "info"
[    0.423688] 0x000000040000-0x0000007c0000 : "firmware"
[    0.430160] 0x0000007c0000-0x0000007f0000 : "config"
[    0.436538] 0x0000007f0000-0x000000800000 : "art"
[    0.445059] libphy: Fixed MDIO Bus: probed
[    0.768479] libphy: ag71xx_mdio: probed
[    0.773748] libphy: ar8xxx-mdio: probed
[    0.785848] switch0: Atheros AR8229 rev. 1 switch registered on mdio.0
[    1.145976] ag71xx 19000000.eth: connected to PHY at mdio.0:1f:04 [uid=004dd
[    1.156116] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: mii
[    1.162648] i2c /dev entries driver
[    1.169430] NET: Registered protocol family 10
[    1.180091] random: fast init done
[    1.184945] Segment Routing with IPv6
[    1.188879] NET: Registered protocol family 17
[    1.193512] bridge: filtering via arp/ip/ip6tables is no longer available by
[    1.206679] 8021q: 802.1Q VLAN Support v1.8
[    1.212391] hctosys: unable to open rtc device (rtc0)
[    1.218812] /dev/root: Can't open blockdev
[    1.223069] VFS: Cannot open root device "(null)" or unknown-block(0,0): err
[    1.230673] Please append a correct "root=" boot option; here are the availa
[    1.239162] 1f00             128 mtdblock0 
[    1.239166]  (driver?)
[    1.245826] 1f01              64 mtdblock1 
[    1.245829]  (driver?)
[    1.252485] 1f02              64 mtdblock2 
[    1.252488]  (driver?)
[    1.259138] 1f03            7680 mtdblock3 
[    1.259140]  (driver?)
[    1.265792] 1f04             192 mtdblock4 
[    1.265795]  (driver?)
[    1.272452] 1f05              64 mtdblock5 
[    1.272455]  (driver?)
[    1.279103] Kernel panic - not syncing: VFS: Unable to mount root fs on unkn
[    1.287482] Rebooting in 1 seconds..


03.05.20213780Base systemBug ReportVery LowLowuhttpd error "Request Entity Too Large" on luci page af...TrunkUnconfirmed Task Description

Router: WRT1900AC v1 (mamba)
Openwrt: my build, r16521, includes luci-ssl, tvheadend server and dvb driver

Luci page ok at first.
After configuring tvheadend, including accounts, dvb muxes, channels, etc., luci page won’t open anymore. uhttpd error: Request Entity Too Large.
Starts working again after clearing browser cookies. Some of those cookies are set by tvheadend.

03.05.20213779Base systemBug ReportVery LowLowPossible less space on Netgear D7800 on 21.02TrunkUnconfirmed Task Description

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

 

Netgear D7800

/dev/root 3.8M 3.8M 0 100% /rom
tmpfs 106.6M 1.1M 105.4M 1% /tmp
/dev/ubi0_1 17.2M 11.5M 4.9M 70% /overlay
overlayfs:/overlay 17.2M 11.5M 4.9M 70% /
tmpfs 512.0K 0 512.0K 0% /dev

I usually have transmission, minidlna and samba set up (OpenWRT 19.07)

Now samba4 libs are too big to install, is there simply more in a base install of 21.02-rc1 so there isn’t room, or are the partitions misconfigured?

This is a clean install of OpenWRT 21.02-rc1

Commands on OpenWRT 19.07:

opkg update
opkg install libblkid luci-app-samba block-mount kmod-fs-exfat kmod-fs-ext4 kmod-usb-storage kmod-usb-storage-uas transmission-daemon-mbedtls luci-app-transmission luci-app-minidlna

Commands on OpenWRT 21.02:

opkg update
opkg install libblkid luci-app-samba4 block-mount kmod-fs-exfat kmod-fs-ext4 kmod-usb-storage kmod-usb-storage-uas transmission-daemon luci-app-transmission luci-app-minidlna

03.05.20213776Base systemBug ReportVery LowHighSwitch bridge VLANs are not configured correctly with D...TrunkUnconfirmed Task Description

Device: Ubiquiti EdgeRouter X (MT7621)
Version: latest master from github and latest packages.

With this network config (only relevant parts shown:

config interface 'test'
	option proto 'static'
	option ifname 'eth4'
	option ipaddr '192.168.4.1'
	option netmask '255.255.255.0'

config interface 'switch'
	option proto 'static'
	option type 'bridge'
	option ifname 'eth1 eth2 eth3'

config bridge-vlan
	option device 'br-switch'
	list ports 'eth1:t'
	list ports 'eth2:t'
	list ports 'eth3:t'
	option vlan '9'

I get this bridge config after reboot:

# bridge vlan
port              vlan-id  
eth1              1 PVID Egress Untagged
eth2              1 PVID Egress Untagged
eth3              1 PVID Egress Untagged
br-switch         1 PVID Egress Untagged

And if I reload network configuration I get this:

root@erx-router:~# ubus call network reload
root@erx-router:~# bridge vl
port              vlan-id  
eth1              1 PVID Egress Untagged
                  9
eth2              1 PVID Egress Untagged
                  9
eth3              1 PVID Egress Untagged
                  9
br-switch         1 PVID Egress Untagged
                  9

Both result are wrong and do not work.

I did a small debugging session and it looks like `bridge_state.has_vlans` is always false - but I’m not exactly sure this is relevant.

Unfortunately this bugs make impossible to run any VLAN tagged ports on this device with any version of OpenWrt. Given that current releases are using DSA for this platform this is a regression from non-DSA setup.

I’ll be happy to provide any additional information.
I’ve tried to debug it myself by could not really find any obvious problems. So any ideas for this would be welcome too.

Thanks!

02.05.20213775Base systemBug ReportVery LowVery LowR7800 & 21.02.0-rc1 : no client connected to Wifi 5GHzopenwrt-21.02Unconfirmed Task Description

Environment : - Netgear R7800 (Nighthawk X4S AC2600)
- OpenWrt 21.02.0-rc1 (sysupgraded from OpenWrt 19.07.7 with some basic configuration)

Problem encountered : After doing a sysupgrade from OpenWrt 19.07.7 to OpenWrt 21.02.0-rc1, everything looked fine at first sight, but I have noticed that none of the WiFi clients were connected to the 5GHz WiFi, they were all connected to the 2.4GHz WiFi, which leaded to a bandwidth diminution and my printer was not anymore accessible.
Now, I am back to OpenWrt 19.07.7 and the printer is working fine again.

Sorry I don’t have more details on that problem, I am creating that bug ticket to see if I am the only one concerned by that bug.
I don’t even know if the 5GHz WiFi was emitting for real or not.

02.05.20213772Base systemBug ReportVery LowCriticalOpenWrt 21.02.0-rc1 reboots frequently after turning on...openwrt-21.02Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on TP-Link TL-WR1043ND v1
- Software versions of OpenWrt/LEDE release, packages, etc. OpenWrt 21.02.0-rc1 r16046-59980f7aaf / LuCI openwrt-21.02 branch git-21.106.55967-06dd6b5

- Steps to reproduce

 

Upgrade go OpenWrt 21.02.1-rc1 without saving previous configs (otherwise system will become unstable immediately after upgrade). Turn on Wireless in Network–>Wireless–>.... After this a device becomes unstable and completely unusable starting to reboot again and again.

01.05.20213771Base systemBug ReportVery LowLowodhcpd fails to send Router AdvertisementsTrunkUnconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
Linksys EA3500

- Software versions of OpenWrt/LEDE release, packages, etc.
21.02.0rc1

- Steps to reproduce
1. Install 21.02.0rc1 on device
2. After successful install, note that your ethernet connected laptop has only a link-local address (no ULA, or GUA).
3. Log into router and run logread command looking for odhcpd errors. Note the following:

logread | grep odhcp
Sun Apr 18 03:07:34 2021 user.notice ucitrack: Setting up /etc/config/dhcp reload dependency on /etc/config/odhcpd
Sun Apr 18 03:07:38 2021 daemon.err odhcpd[1799]: Failed to send to ff02::1%lan@br-lan (Address not available)
Sun Apr 18 03:07:41 2021 daemon.err odhcpd[1799]: Failed to send to fe80::9ed6:43ff:feae:1915%lan@br-lan (Address not available)
Sun Apr 18 03:07:41 2021 daemon.err odhcp6c[2528]: Failed to send RS (Address not available)
Sun Apr 18 03:07:42 2021 daemon.err odhcpd[1799]: Failed to send to ff02::1%lan@br-lan (Address not available)
Sun Apr 18 03:07:42 2021 daemon.err odhcp6c[2528]: Failed to send SOLICIT message to ff02::1:2 (Address not available)
Sun Apr 18 03:07:48 2021 daemon.info dnsmasq[2569]: read /tmp/hosts/odhcpd - 0 addresses

The router does NOT, in fact, have the interface ff02::1%lan@br-lan

After installing ip-full, it is possible to see ‘ip maddr’ and see the correct interfaces on the router:

# ip maddr
1: lo

inet  224.0.0.1
inet6 ff02::1
inet6 ff01::1

...
13: br-lan

link  33:33:00:00:00:01
link  33:33:00:00:00:02
link  01:00:5e:00:00:01
link  33:33:ff:01:70:f1
link  33:33:ff:00:00:01
link  33:33:ff:00:00:00
link  33:33:00:00:00:09
inet  224.0.0.1
inet6 ff02::9
inet6 ff02::1:ff00:0 users 3
inet6 ff02::1:ff00:1 users 2
inet6 ff02::1:ff01:70f1
inet6 ff02::2
inet6 ff02::1
inet6 ff01::1

IMPACT: No attached device can receive an IPv6 address from the router

 


29.04.20213769Base systemBug ReportVery LowHighDuplicate LAN MAC address on RB750Gr3openwrt-21.02Unconfirmed Task Description

Device: RB750Gr3
OpenWrt: 21.02.0-rc1 and 21.02-SNAPSHOT r16053-f066ee2ad5 (clean flash)

The kernel log has several lines of the following

br-lan: received packet on lan2 with own address as source address (addr:08:55:31:2e:c0:34, vlan:0)

/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 packet_steering '1'
        option ula_prefix 'fd60:2450:7cfe::/48'

config interface 'lan'
        option type 'bridge'
        option ifname 'lan2 lan3 lan4 lan5'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config device 'lan_lan2_dev'
        option name 'lan2'
        option macaddr '08:55:31:2e:c0:34'

config device 'lan_lan3_dev'
        option name 'lan3'
        option macaddr '08:55:31:2e:c0:34'

config device 'lan_lan4_dev'
        option name 'lan4'
        option macaddr '08:55:31:2e:c0:34'

config device 'lan_lan5_dev'
        option name 'lan5'
        option macaddr '08:55:31:2e:c0:34'
                                          
config interface 'wan'
        option ifname 'wan'
        option proto 'dhcp'
                                          
config device 'wan_wan_dev'
        option name 'wan'
        option macaddr '08:55:31:2e:c0:33'
                                          
config interface 'wan6'
        option ifname 'wan'
        option proto 'dhcpv6'


29.04.20213768Base systemBug ReportVery LowLowAP/master + STA/client doesn't work in almost all casesopenwrt-19.07Unconfirmed Task Description

I have GL-Inet GL-AR150 (Atheros 933x, single radio) configured with three WiFi interfaces/networks: two APs (main+guest) and one client (WWAN). I would like to use them as a wireless repeater, but in most cases is able to use as pure AP or pure client only.

If client interface is disabled, both APs work perfectly. If the client is enabled, it successfully connects to the specified external AP and routing between LAN and WWAN works perfectly, but none of the APs are visible/accessible in most cases.

There was only a single case of dozens experiments when I saw all three interfaces working. In that case, both APs were visible and accessible, the client was connected to the external AP, and packet routing was established between LAN (RJ-45 and APs) and WWAN (the client). It means that this SoC is technically capable of running mixed mode interfaces on a single radio. Unfortunately, in that case I didn’t think to save the logs.

In most cases, when AP networks are not exposed, system log contains repeated error messages from hostapd:

daemon.err hostapd: Failed to set beacon parameters
daemon.notice hostapd: handle_probe_req: send failed

I’m afraid that client initialization is performed first, and some beacon parameters are set for the radio driver. When hostapd tries to set its own parameters, the driver fails the request. But in the case where all three interfaces worked, initialization sequence most probably was slightly different, so there was no conflict. Unfortunately, I cannot reproduce that successful case, but at that time, I carefully checked all the functionality to ensure that it really worked as expected.

I tried to change AP channel from Auto to a particular number, as suggested in FS#3114, but this didn’t help.


The problem occurs in many stable OpenWRT releases. The latest are 19.07.3 and 19.07.7 (both are generic).


Steps to reproduce:

 
* Create at least two wireless interfaces: one client/STA, one or more master/AP.
* When client/STA is enabled, AP(s) is(are) not exposed.
29.04.20213767Base systemBug ReportVery LowLowAP/master + STA/client don't work in almost all casesopenwrt-19.07Unconfirmed Task Description

I have GL-Inet GL-AR150 (Atheros 933x, single radio) configured with three WiFi interfaces/networks: two APs (main+guest) and one client (WWAN). I would like to use them as a wireless repeater, but in most cases is able to use as pure AP or pure client only.

If client interface is disabled, both APs work perfectly. If the client is enabled, it successfully connects to the specified external AP and routing between LAN and WWAN works perfectly, but none of the APs are visible/accessible in most cases.

There was only a single case of dozens experiments when I saw all three interfaces working. In that case, both APs were visible and accessible, the client was connected to the external AP, and packet routing was established between LAN (RJ-45 and APs) and WWAN (the client). It means that this SoC is technically capable of running mixed mode interfaces on a single radio. Unfortunately, in that case I didn't think to save the logs.

In most cases, when AP networks are not exposed, system log contains repeated error messages from hostapd:

daemon.err hostapd: Failed to set beacon parameters
daemon.notice hostapd: handle_probe_req: send failed

I'm afraid that client initialization is performed first, and some beacon parameters are set for the radio driver. When hostapd tries to set its own parameters, the driver fails the request. But in the case where all three interfaces worked, initialization sequence most probably was slightly different, so there was no conflict. Unfortunately, I cannot reproduce that successful case, but at that time, I carefully checked all the functionality to ensure that it really worked as expected.

I tried to change AP channel from Auto to a particular number, as suggested in FS#3114, but this didn't help.


The problem occurs in many stable OpenWRT releases. The latest are 19.07.3 and 19.07.7 (both are generic).


Steps to reproduce:

 
* Create at least two wireless interfaces: one client/STA, one or more master/AP.
* When client/STA is enabled, AP(s) is(are) not exposed.
29.04.20213766Base systemBug ReportVery LowMediumAP+STA (master+client) doesn't work in most casesopenwrt-19.07Unconfirmed Task Description

I have GL-Inet GL-AR150 (Atheros 933x, single radio) configured with three WiFi interfaces/networks: two APs (main+guest) and one client (WWAN). I would like to use them as a wireless repeater, but in most cases is able to use as pure AP or pure client only.

If client interface is disabled, both APs work perfectly. If the client is enabled, it successfully connects to the specified external AP and routing between LAN and WWAN works perfectly, but none of the APs are visible/accessible in most cases.

There was only a single case of dozens experiments when I saw all three interfaces working. In that case, both APs were visible and accessible, the client was connected to the external AP, and packet routing was established between LAN (RJ-45 and APs) and WWAN (the client). It means that this SoC is technically capable of running mixed mode interfaces on a single radio. Unfortunately, in that case I didn't think to save the logs.

In most cases, when AP networks are not exposed, system log contains repeated error messages from hostapd:

daemon.err hostapd: Failed to set beacon parameters
daemon.notice hostapd: handle_probe_req: send failed

I'm afraid that client initialization is performed first, and some beacon parameters are set for the radio driver. When hostapd tries to set its own parameters, the driver fails the request. But in the case where all three interfaces worked, initialization sequence most probably was slightly different, so there was no conflict. Unfortunately, I cannot reproduce that successful case, but at that time, I carefully checked all the functionality to ensure that it really worked as expected.

I tried to change AP channel from Auto to a particular number, as suggested in FS#3114, but this didn't help.


The problem occurs in many stable OpenWRT releases. The latest are 19.07.3 and 19.07.7 (both are generic).


Steps to reproduce:

 
* Create at least two wireless interfaces: one client/STA, one or more master/AP.
* When client/STA is enabled, AP(s) is(are) not exposed.
29.04.20213763Base systemBug ReportVery LowLowOpenwrt 19.07 Wifi MT76x2E unstableTrunkUnconfirmed Task Description

Device : Newifi D2 with MT7621,MT7603E (2.4 ghz wifi) and MT76x2E.
Version installed : Openwrt 19.07.07

On System log :
Thu Apr 29 05:58:09 2021 kern.info kernel: [27563.371343] ieee80211 phy1: Hardware restart was requested
Thu Apr 29 06:04:09 2021 kern.info kernel: [27923.427600] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
Thu Apr 29 06:04:09 2021 kern.info kernel: [27923.433086] mt76x2e 0000:01:00.0: Build: 1
Thu Apr 29 06:04:09 2021 kern.info kernel: [27923.437240] mt76x2e 0000:01:00.0: Build Time: 201507311614 Thu Apr 29 06:04:09 2021 kern.info kernel: [27923.465964] mt76x2e 0000:01:00.0: Firmware running!

Test Ping :
ping google.it
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=190 ttl=116 time=31.7 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=191 ttl=116 time=31.4 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=192 ttl=116 time=31.6 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=193 ttl=116 time=31.6 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=194 ttl=116 time=31.7 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=195 ttl=116 time=31.9 ms
64 bytes from par10s42-in-f3.1e100.net (216.58.214.163): icmp_seq=196 ttl=116 time=31.7 ms
From n-batnic (192.168.1.131) icmp_seq=198 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=199 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=200 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=201 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=202 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=203 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=204 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=205 Destination Host Unreachable
From n-batnic (192.168.1.131) icmp_seq=206 Destination Host Unreachable
64 bytes from mad01s26-in-f3.1e100.net (216.58.214.163): icmp_seq=207 ttl=116 time=31.8 ms
64 bytes from mad01s26-in-f163.1e100.net (216.58.214.163): icmp_seq=208 ttl=116 time=32.2 ms
64 bytes from mad01s26-in-f163.1e100.net (216.58.214.163): icmp_seq=209 ttl=116 time=31.7 ms
64 bytes from mad01s26-in-f163.1e100.net (216.58.214.163): icmp_seq=210 ttl=116 time=32.3 ms

Wifi 5ghz settings :
config wifi-device ‘radio1’ option type ‘mac80211’ option hwmode ‘11a’ option path ‘pci0000:00/0000:00:00.0/0000:01:00.0’ option htmode ‘VHT80’ option country ‘IT’ option channel ‘100’

With wifi 2.4ghz i don’t have problem.

Could you help me for to fix the problem?

Regards

29.04.20213762Base systemBug ReportVery LowCriticalWAN performance regression on MT7621 21.02-rc1 vs 19.07...TrunkUnconfirmed Task Description

There is an issue with Wan throughput on the MT7621 and OpenWrt 21.02-rc1 vs 19.07.7

The test setup is an Iperf3 server running locally on the wan side of the router (A NeWifi-D2) and running Iperf3 as client on the router. This is stock firmware with no changes to the network settings from stock.

19.07.7 - TX = 531Mbps RX = 629Mbps
21.02-Rc1 - TX = 792Mbps Rx = 523Mbps

So while it appears TX has improved, RX is suffering and it is noticeable with non synthetic transfers.

Noticably the RX test on 21.02-RC1 is reporting rampant Retransmits by the Iperf server. These are not present in 19.07.7 in either direction, OR in 21.02-RC1 when the router is sending, only when its receiving. I also ran mpstat with an interval of 3 seconds to see processor load during the test. In the result sets below, iperf3 test was started during interval 3.

The command line on the router is
TX =

iperf3 -c <server ip> -P 2

RX =

iperf3 -c <server ip> -P 2 -R

19.07.7 - TX

iperf3 -c 192.168.69.102 -P 2
Connecting to host 192.168.69.102, port 5201
[  5] local 192.168.69.127 port 50742 connected to 192.168.69.102 port 5201
[  7] local 192.168.69.127 port 50744 connected to 192.168.69.102 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.04   sec  28.7 MBytes   231 Mbits/sec    0    130 KBytes       
[  7]   0.00-1.04   sec  28.7 MBytes   231 Mbits/sec    0    123 KBytes       
[SUM]   0.00-1.04   sec  57.3 MBytes   462 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   1.04-2.00   sec  28.8 MBytes   251 Mbits/sec    0    130 KBytes       
[  7]   1.04-2.00   sec  28.8 MBytes   251 Mbits/sec    0    130 KBytes       
[SUM]   1.04-2.00   sec  57.5 MBytes   502 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   2.00-3.01   sec  30.0 MBytes   251 Mbits/sec    0    130 KBytes       
[  7]   2.00-3.01   sec  30.0 MBytes   251 Mbits/sec    0    140 KBytes       
[SUM]   2.00-3.01   sec  60.0 MBytes   502 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   3.01-4.00   sec  30.0 MBytes   252 Mbits/sec    0    130 KBytes       
[  7]   3.01-4.00   sec  30.0 MBytes   252 Mbits/sec    0    140 KBytes       
[SUM]   3.01-4.00   sec  60.0 MBytes   505 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   4.00-5.03   sec  31.2 MBytes   256 Mbits/sec    0    130 KBytes       
[  7]   4.00-5.03   sec  31.2 MBytes   256 Mbits/sec    0    140 KBytes       
[SUM]   4.00-5.03   sec  62.5 MBytes   511 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   5.03-6.01   sec  30.0 MBytes   257 Mbits/sec    0    130 KBytes       
[  7]   5.03-6.01   sec  30.0 MBytes   257 Mbits/sec    0    140 KBytes       
[SUM]   5.03-6.01   sec  60.0 MBytes   513 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   6.01-7.02   sec  31.2 MBytes   258 Mbits/sec    0    130 KBytes       
[  7]   6.01-7.02   sec  31.2 MBytes   258 Mbits/sec    0    140 KBytes       
[SUM]   6.01-7.02   sec  62.5 MBytes   517 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   7.02-8.01   sec  35.0 MBytes   298 Mbits/sec    0    130 KBytes       
[  7]   7.02-8.01   sec  35.0 MBytes   298 Mbits/sec    0    140 KBytes       
[SUM]   7.02-8.01   sec  70.0 MBytes   595 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   8.01-9.01   sec  36.2 MBytes   305 Mbits/sec    0    139 KBytes       
[  7]   8.01-9.01   sec  36.2 MBytes   305 Mbits/sec    0    140 KBytes       
[SUM]   8.01-9.01   sec  72.5 MBytes   611 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   9.01-10.03  sec  37.5 MBytes   306 Mbits/sec    0    139 KBytes       
[  7]   9.01-10.03  sec  37.5 MBytes   306 Mbits/sec    0    140 KBytes       
[SUM]   9.01-10.03  sec  75.0 MBytes   612 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.03  sec   319 MBytes   266 Mbits/sec    0             sender
[  5]   0.00-10.07  sec   319 MBytes   265 Mbits/sec                  receiver
[  7]   0.00-10.03  sec   319 MBytes   266 Mbits/sec    0             sender
[  7]   0.00-10.07  sec   319 MBytes   265 Mbits/sec                  receiver
[SUM]   0.00-10.03  sec   637 MBytes   533 Mbits/sec    0             sender
[SUM]   0.00-10.07  sec   637 MBytes   531 Mbits/sec                  receiver

iperf Done.


# mpstat 3 10
Linux 4.14.221 (OpenWrt) 	04/29/21 	_mips_	(4 CPU)

05:45:14     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:45:17     all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
05:45:20     all    0.66    0.00    0.17    0.00    0.00    0.00    0.00    0.00    0.00   99.17
05:45:23     all    0.08    0.00   18.11    0.00    0.00   10.38    0.00    0.00    0.00   71.43
05:45:26     all    1.16    0.00   22.92    0.00    0.00   13.62    0.00    0.00    0.00   62.29
05:45:29     all    0.33    0.00   24.50    0.00    0.00   14.62    0.00    0.00    0.00   60.55
05:45:32     all    0.58    0.00   14.04    0.00    0.00   10.38    0.00    0.00    0.00   75.00
05:45:35     all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
05:45:38     all    0.50    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00   99.17

19.07.7 - RX (Server Iperf3 Stats)

Accepted connection from 192.168.69.127, port 50746
[  5] local 192.168.69.102 port 5201 connected to 192.168.69.127 port 50748
[  8] local 192.168.69.102 port 5201 connected to 192.168.69.127 port 50750
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  38.9 MBytes   326 Mbits/sec    0    334 KBytes       
[  8]   0.00-1.00   sec  36.5 MBytes   306 Mbits/sec    0    266 KBytes       
[SUM]   0.00-1.00   sec  75.4 MBytes   633 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   1.00-2.00   sec  37.5 MBytes   314 Mbits/sec    0    334 KBytes       
[  8]   1.00-2.00   sec  37.9 MBytes   318 Mbits/sec    0    266 KBytes       
[SUM]   1.00-2.00   sec  75.4 MBytes   632 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   2.00-3.00   sec  37.4 MBytes   314 Mbits/sec    0    334 KBytes       
[  8]   2.00-3.00   sec  37.0 MBytes   310 Mbits/sec    0    266 KBytes       
[SUM]   2.00-3.00   sec  74.4 MBytes   624 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   3.00-4.00   sec  37.5 MBytes   314 Mbits/sec    0    334 KBytes       
[  8]   3.00-4.00   sec  37.5 MBytes   315 Mbits/sec    0    266 KBytes       
[SUM]   3.00-4.00   sec  75.0 MBytes   629 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   4.00-5.00   sec  37.5 MBytes   315 Mbits/sec    0    334 KBytes       
[  8]   4.00-5.00   sec  37.7 MBytes   316 Mbits/sec    0    266 KBytes       
[SUM]   4.00-5.00   sec  75.3 MBytes   631 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   5.00-6.00   sec  37.5 MBytes   314 Mbits/sec    0    334 KBytes       
[  8]   5.00-6.00   sec  37.5 MBytes   315 Mbits/sec    0    266 KBytes       
[SUM]   5.00-6.00   sec  75.0 MBytes   629 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   6.00-7.00   sec  37.2 MBytes   312 Mbits/sec    0    430 KBytes       
[  8]   6.00-7.00   sec  36.4 MBytes   305 Mbits/sec    0    322 KBytes       
[SUM]   6.00-7.00   sec  73.5 MBytes   617 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   7.00-8.00   sec  38.3 MBytes   321 Mbits/sec    0    430 KBytes       
[  8]   7.00-8.00   sec  37.9 MBytes   318 Mbits/sec    0    322 KBytes       
[SUM]   7.00-8.00   sec  76.2 MBytes   639 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   8.00-9.00   sec  37.1 MBytes   311 Mbits/sec    0    430 KBytes       
[  8]   8.00-9.00   sec  37.0 MBytes   311 Mbits/sec    0    322 KBytes       
[SUM]   8.00-9.00   sec  74.1 MBytes   622 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   9.00-10.00  sec  37.8 MBytes   317 Mbits/sec    0    430 KBytes       
[  8]   9.00-10.00  sec  37.8 MBytes   317 Mbits/sec    0    322 KBytes       
[SUM]   9.00-10.00  sec  75.7 MBytes   635 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]  10.00-10.04  sec   954 KBytes   214 Mbits/sec    0    430 KBytes       
[  8]  10.00-10.04  sec  1.55 MBytes   356 Mbits/sec    0    322 KBytes       
[SUM]  10.00-10.04  sec  2.49 MBytes   570 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.04  sec   378 MBytes   316 Mbits/sec    0             sender
[  8]   0.00-10.04  sec   375 MBytes   313 Mbits/sec    0             sender
[SUM]   0.00-10.04  sec   752 MBytes   629 Mbits/sec    0             sender

# mpstat 3 10 
Linux 4.14.221 (OpenWrt) 	04/29/21 	_mips_	(4 CPU)

05:46:28     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:46:31     all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
05:46:34     all    0.58    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00   99.09
05:46:37     all    0.42    0.00   13.95    0.00    0.00   14.37    0.00    0.00    0.00   71.26
05:46:40     all    0.58    0.00   14.37    0.00    0.00   27.57    0.00    0.00    0.00   57.48
05:46:43     all    1.00    0.00   17.77    0.00    0.00   26.58    0.00    0.00    0.00   54.65
05:46:46     all    0.33    0.00   12.46    0.00    0.00   15.20    0.00    0.00    0.00   72.01
05:46:49     all    0.50    0.00    0.33    0.00    0.00    0.00    0.00    0.00    0.00   99.17
05:46:52     all    0.00    0.00    0.00    0.00    0.00    0.17    0.00    0.00    0.00   99.83

21.02-RC1 - TX

# iperf3 -c 192.168.69.102 -P 2
Connecting to host 192.168.69.102, port 5201
[  5] local 192.168.69.128 port 54862 connected to 192.168.69.102 port 5201
[  7] local 192.168.69.128 port 54864 connected to 192.168.69.102 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.02   sec  48.7 MBytes   400 Mbits/sec    0    134 KBytes       
[  7]   0.00-1.02   sec  48.6 MBytes   400 Mbits/sec    0    134 KBytes       
[SUM]   0.00-1.02   sec  97.3 MBytes   799 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   1.02-2.02   sec  47.5 MBytes   401 Mbits/sec    0    134 KBytes       
[  7]   1.02-2.02   sec  47.5 MBytes   401 Mbits/sec    0    146 KBytes       
[SUM]   1.02-2.02   sec  95.0 MBytes   801 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   2.02-3.01   sec  47.5 MBytes   399 Mbits/sec    0    134 KBytes       
[  7]   2.02-3.01   sec  47.5 MBytes   399 Mbits/sec    0    146 KBytes       
[SUM]   2.02-3.01   sec  95.0 MBytes   799 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   3.01-4.03   sec  46.8 MBytes   388 Mbits/sec    0    214 KBytes       
[  7]   3.01-4.03   sec  45.7 MBytes   379 Mbits/sec    0    164 KBytes       
[SUM]   3.01-4.03   sec  92.5 MBytes   767 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   4.03-5.01   sec  46.2 MBytes   396 Mbits/sec    0    214 KBytes       
[  7]   4.03-5.01   sec  46.2 MBytes   396 Mbits/sec    0    164 KBytes       
[SUM]   4.03-5.01   sec  92.5 MBytes   792 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   5.01-6.01   sec  47.5 MBytes   397 Mbits/sec    0    214 KBytes       
[  7]   5.01-6.01   sec  47.5 MBytes   397 Mbits/sec    0    164 KBytes       
[SUM]   5.01-6.01   sec  95.0 MBytes   794 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   6.01-7.01   sec  47.5 MBytes   398 Mbits/sec    0    214 KBytes       
[  7]   6.01-7.01   sec  47.5 MBytes   398 Mbits/sec    0    164 KBytes       
[SUM]   6.01-7.01   sec  95.0 MBytes   796 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   7.01-8.01   sec  47.5 MBytes   397 Mbits/sec    0    226 KBytes       
[  7]   7.01-8.01   sec  47.5 MBytes   397 Mbits/sec    0    174 KBytes       
[SUM]   7.01-8.01   sec  95.0 MBytes   795 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   8.01-9.02   sec  47.5 MBytes   396 Mbits/sec    0    226 KBytes       
[  7]   8.01-9.02   sec  47.5 MBytes   396 Mbits/sec    0    180 KBytes       
[SUM]   8.01-9.02   sec  95.0 MBytes   792 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   9.02-10.00  sec  46.2 MBytes   395 Mbits/sec    0    226 KBytes       
[  7]   9.02-10.00  sec  46.2 MBytes   395 Mbits/sec    0    180 KBytes       
[SUM]   9.02-10.00  sec  92.5 MBytes   790 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   473 MBytes   397 Mbits/sec    0             sender
[  5]   0.00-10.01  sec   473 MBytes   396 Mbits/sec                  receiver
[  7]   0.00-10.00  sec   472 MBytes   396 Mbits/sec    0             sender
[  7]   0.00-10.01  sec   472 MBytes   396 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec   945 MBytes   792 Mbits/sec    0             sender
[SUM]   0.00-10.01  sec   945 MBytes   792 Mbits/sec                  receiver

iperf Done.

# mpstat 3 10
Linux 5.4.111 (OpenWrt) 	04/29/21 	_mips_	(4 CPU)

06:14:41     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
06:14:44     all    0.75    0.00    0.25    0.00    0.00    0.00    0.00    0.00    0.00   99.00
06:14:47     all    0.00    0.00    0.00    0.00    0.00    0.08    0.00    0.00    0.00   99.92
06:14:50     all    0.08    0.00   16.97    0.00    0.00   10.40    0.00    0.00    0.00   72.55
06:14:53     all    1.33    0.00   25.48    0.00    0.00   15.24    0.00    0.00    0.00   57.95
06:14:56     all    0.17    0.00   25.02    0.00    0.00   15.21    0.00    0.00    0.00   59.60
06:14:59     all    0.58    0.00   17.00    0.00    0.00    9.83    0.00    0.00    0.00   72.58
06:15:02     all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
06:15:05     all    0.83    0.00    0.25    0.00    0.00    0.00    0.00    0.00    0.00   98.92

21.02-RC1 - RX (Server Iperf3 stats)

Accepted connection from 192.168.69.128, port 54872
[  5] local 192.168.69.102 port 5201 connected to 192.168.69.128 port 54874
[  8] local 192.168.69.102 port 5201 connected to 192.168.69.128 port 54876
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  28.7 MBytes   241 Mbits/sec   20    342 KBytes       
[  8]   0.00-1.00   sec  34.5 MBytes   290 Mbits/sec    1    443 KBytes       
[SUM]   0.00-1.00   sec  63.3 MBytes   531 Mbits/sec   21             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   1.00-2.00   sec  28.8 MBytes   241 Mbits/sec    0    403 KBytes       
[  8]   1.00-2.00   sec  31.3 MBytes   262 Mbits/sec    4    362 KBytes       
[SUM]   1.00-2.00   sec  60.0 MBytes   504 Mbits/sec    4             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   2.00-3.00   sec  27.8 MBytes   234 Mbits/sec    7    339 KBytes       
[  8]   2.00-3.00   sec  35.5 MBytes   298 Mbits/sec    0    428 KBytes       
[SUM]   2.00-3.00   sec  63.4 MBytes   532 Mbits/sec    7             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   3.00-4.00   sec  27.9 MBytes   234 Mbits/sec    2    291 KBytes       
[  8]   3.00-4.00   sec  35.2 MBytes   296 Mbits/sec   17    356 KBytes       
[SUM]   3.00-4.00   sec  63.1 MBytes   530 Mbits/sec   19             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   4.00-5.00   sec  27.8 MBytes   234 Mbits/sec    0    356 KBytes       
[  8]   4.00-5.00   sec  34.4 MBytes   289 Mbits/sec    0    424 KBytes       
[SUM]   4.00-5.00   sec  62.3 MBytes   522 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   5.00-6.00   sec  25.2 MBytes   212 Mbits/sec    1    297 KBytes       
[  8]   5.00-6.00   sec  37.7 MBytes   316 Mbits/sec    0    486 KBytes       
[SUM]   5.00-6.00   sec  62.9 MBytes   528 Mbits/sec    1             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   6.00-7.00   sec  26.1 MBytes   219 Mbits/sec    0    359 KBytes       
[  8]   6.00-7.00   sec  36.5 MBytes   307 Mbits/sec    7    395 KBytes       
[SUM]   6.00-7.00   sec  62.6 MBytes   525 Mbits/sec    7             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   7.00-8.00   sec  30.7 MBytes   258 Mbits/sec    0    420 KBytes       
[  8]   7.00-8.00   sec  30.0 MBytes   252 Mbits/sec    4    321 KBytes       
[SUM]   7.00-8.00   sec  60.7 MBytes   509 Mbits/sec    4             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   8.00-9.00   sec  33.9 MBytes   284 Mbits/sec   10    232 KBytes       
[  8]   8.00-9.00   sec  27.7 MBytes   232 Mbits/sec    0    383 KBytes       
[SUM]   8.00-9.00   sec  61.5 MBytes   516 Mbits/sec   10             
- - - - - - - - - - - - - - - - - - - - - - - - -
[  5]   9.00-10.00  sec  25.4 MBytes   213 Mbits/sec    0    303 KBytes       
[  8]   9.00-10.00  sec  38.7 MBytes   324 Mbits/sec    0    451 KBytes       
[SUM]   9.00-10.00  sec  64.0 MBytes   537 Mbits/sec    0             
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.01  sec   282 MBytes   237 Mbits/sec   40             sender
[  8]   0.00-10.01  sec   342 MBytes   286 Mbits/sec   33             sender
[SUM]   0.00-10.01  sec   624 MBytes   523 Mbits/sec   73             sender

# mpstat 3 10
Linux 5.4.111 (OpenWrt) 	04/29/21 	_mips_	(4 CPU)

06:17:59     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
06:18:02     all    0.00    0.00    0.00    0.00    0.00    0.17    0.00    0.00    0.00   99.83
06:18:05     all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
06:18:08     all    1.33    0.00   16.81    0.00    0.00   31.86    0.00    0.00    0.00   50.00
06:18:11     all    0.83    0.00   22.55    0.00    0.00   44.43    0.00    0.00    0.00   32.20
06:18:14     all    1.66    0.00   23.13    0.00    0.00   43.68    0.00    0.00    0.00   31.53
06:18:17     all    0.50    0.00   12.51    0.00    0.00   24.85    0.00    0.00    0.00   62.14
06:18:20     all    0.67    0.00    0.17    0.00    0.00    0.08    0.00    0.00    0.00   99.09
06:18:23     all    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
29.04.20213760Base systemBug ReportVery LowCriticalWifi to WAN traffic causes eth0 to crash with a NETDEV ...openwrt-21.02Unconfirmed Task Description

I have been testing OpenWRT 21.02-RC1 stock released firmware image on the Newifi-D2 target (MT7621 based).

Sporadically while using the router, i experience the WAN interface crashing with NETDEV WATCHDOG errors.

I am using the released image for OpenWrt 21.02-rc1 for the Newifi-D2 target
I have also experienced this fault with a custom router build based on MT7621 for a different target, the fault appears general to MT7621 not this target.

I have loaded 19.07.7 stock firmware on this same hardware and the fault does not occur in that firmware version. A colleague has replicated this fault in 21.02-RC1 with the same type of target (physically different unit), but in a different environment with no shared network resources.

Other than setting up the wifi ssid and password and enabling the 5ghz radio, the network settings are stock.

I have worked out a 90% reliable test case to reproduce the fault:

Have a client device connected to the router on WiFi 5ghz
And a local Iperf3 server running on the wan side of the wired interface.

On the server run:

iperf3 -s

Note the servers IP address

On the client run:

iperf3 -c <serverIP> -P 50

Notes:
Iperf3 server needs to be local on a 1gbps wired link. With an internet based Iperf3 server (or one with a slower connection) the error is much harder to trigger, it will happen but its much more random.
The number of connections does not need to be 50, however, the lower the number of connections the less reliable the error triggers.
The WiFi client should be getting about 300-400mbps throughput over the wifi link when its working correctly.

On most runs, the iperf3 performance will drop to 0mbps, logread on the router then reveals:

Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.065748] ------------[ cut here ]------------
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.070403] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:448 0x8047e780
Thu Apr 29 03:58:44 2021 kern.info kernel: [  578.077443] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.084412] Modules linked in: pppoe ppp_async iptable_nat xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd gpio_button_hotplug usbcore nls_base usb_common
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.147503] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.4.111 #0
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.153490] Stack : 00000000 80840000 ffffffff 8007d6e0 00000000 00000000 00000000 00000000
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.161831]         00000000 00000000 00000000 00000000 00000000 00000001 8fc0fd50 8ba64c1c
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.170163]         8fc0fde8 00000000 00000000 00000000 00000038 805e1804 342e3520 3131312e
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.178486]         00000000 0000001c 00000000 0002402f 00000000 8fc0fd30 00000000 8047e780
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.186808]         00000009 00000001 00200000 00000122 00000003 80359e2c 00000004 80810004
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.195132]         ...
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.197567] Call Trace:
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.197583] [<8007d6e0>] 0x8007d6e0
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.203512] [<805e1804>] 0x805e1804
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.206990] [<8047e780>] 0x8047e780
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.210464] [<80359e2c>] 0x80359e2c
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.213941] [<8000b05c>] 0x8000b05c
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.217409] [<8000b064>] 0x8000b064
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.220879] [<805c6f9c>] 0x805c6f9c
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.224351] [<8007d8ac>] 0x8007d8ac
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.227829] [<8002bfe8>] 0x8002bfe8
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.231302] [<8047e780>] 0x8047e780
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.234775] [<8002c0c0>] 0x8002c0c0
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.238257] [<8047e780>] 0x8047e780
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.241731] [<800a9018>] 0x800a9018
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.245212] [<8047e484>] 0x8047e484
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.248688] [<800965d4>] 0x800965d4
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.252161] [<8009681c>] 0x8009681c
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.255640] [<805e7d1c>] 0x805e7d1c
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.259116] [<80030768>] 0x80030768
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.262588] [<802f8404>] 0x802f8404
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.266064] [<80006c28>] 0x80006c28
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.269533]
Thu Apr 29 03:58:44 2021 kern.warn kernel: [  578.271153] ---[ end trace eabfb050c5985bce ]---
Thu Apr 29 03:58:44 2021 kern.err kernel: [  578.275799] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
Thu Apr 29 03:58:44 2021 kern.info kernel: [  578.282602] mtk_soc_eth 1e100000.ethernet eth0: Link is Down
Thu Apr 29 03:58:44 2021 kern.info kernel: [  578.318310] mtk_soc_eth 1e100000.ethernet eth0: configuring for fixed/rgmii link mode
Thu Apr 29 03:58:44 2021 kern.info kernel: [  578.326251] mtk_soc_eth 1e100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

This only occurs on the first instance of the error, the error will repeatedly occur but the only evidence in the logs after the first error is:

Thu Apr 29 04:33:36 2021 kern.err kernel: [ 2670.043971] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
Thu Apr 29 04:33:36 2021 kern.info kernel: [ 2670.050555] mtk_soc_eth 1e100000.ethernet eth0: Link is Down
Thu Apr 29 04:33:36 2021 kern.info kernel: [ 2670.084619] mtk_soc_eth 1e100000.ethernet eth0: configuring for fixed/rgmii link mode
Thu Apr 29 04:33:36 2021 kern.info kernel: [ 2670.092556] mtk_soc_eth 1e100000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
28.04.20213759Base systemBug ReportVery LowHighIdle ssh Connection exits with: client_loop: send disco...openwrt-21.02Unconfirmed Task Description

Summary

  • Device problem occurs on: x86-64 based router
  • Affected Software version: 21.02.0-rc1
    • This bug does NOT happen when running 19.07.7

Steps to reproduce

SSH from one computer to another machine that is on the internet

machine 1 < —- > openwrt 21.02.0-rc1 ←— internet —→ machine 2

Run this command on machine 1: watch ‘sleep 3000;date’

After some time has passed (wait about 30 minutes, maybe a little less):
1) the ssh tunnel will exit when you press enter in the terminal.
2) The error message will be: “client_loop: send disconnect: Broken pipe”

 


25.04.20213752Base systemBug ReportVery LowLownetifd defaults an invalid bridge STP value for forward...TrunkUnconfirmed Task Description

netifd defaults the STP forward_delay lower than the minimum allowed by the protocol, causing the BPDU packets to be ignored by conforming implementations, risking bridge loops.

The relevant limits are set in IEEE 802.1D-1998 section 8.10.2 Table 8-3: the allowable forward_delay range is 4 - 30 seconds. netifd sets the initial default to 2 seconds.

I tested this with several of my Netgear managed switches; they ignore the invalid “2 second” STP packets. Correcting the forward_delay to within limits (4s) results in the router accepting the OpenWRT STP as the root bridge (since it has a lower bridge-id).

netifd should definitely not be defaulting to invalid values (even if it, and the kernel, allow the values to be set).

Here’s a patch to fix the default:

--- a/bridge.c                                                                  
+++ b/bridge.c                                                                  
@@ -875,7 +875,7 @@ bridge_apply_settings(struct bridge_state *bst, struct blob\
_attr **tb)                                                                     
                                                                                
        /* defaults */                                                          
        cfg->stp = false;                                                       
-       cfg->forward_delay = 2;                                                 
+       cfg->forward_delay = 4;                                                 
        cfg->robustness = 2;                                                    
        cfg->igmp_snoop = false;                                                

Specifically, the packet is invalid as it fails the Spanning Tree Algorithm in section A.9, step 17c.

NOTE: Since the 1998 version of the standard requires subscribing to IEEE, you can also find the limits in the “free to download” updated 802.1D-2004 standard, section 17.14, Table 17-1 for the RSTP (which has the same forward delay limits as STP).


On the subject of “additional possible fixes”.... (only suggestions)

The very low Forward Delay of 4 seconds still results in “non-conforming” behavior by OpenWRT, but at least no longer “breaking” behavior. Section 8.10.2 of 802.1D-1998 states:

A Bridge shall enforce the following relationships:
   2 × (Bridge_Forward_Delay – 1.0 seconds) >= Bridge_Max_Age

... so even if the default Forward Delay is increased to 4 seconds, the default Max Age should also also be reduced to 6 seconds (kernel currently defaults to 20 seconds).

Also the minimum value for Forward Delay of 4 seconds is calculated (in section B.4.5) based on a Hello Time of 1 second, so that value should also be set (kernel currently defaults to 2 seconds).

Neither of these updates are critical (they work at their current defaults), but would just create “sensible” timers for STP.


22.04.20213749Base systemBug ReportVery LowLowbusybox-ntp failing on specific ISP but ntpd works.openwrt-21.02Unconfirmed Task Description

- Device: glinet B1300 router
- Running 21.02

Attached are two pcap files you can open in wireshark.

This issue seems to only affect one Danish ISP, however I think it is worth reporting to see if it can be fixed.
The built in busybox-ntpd does not work (see packet in sysntpd.pcap)

However, if I install ntpdate instead then ntp is able to update (using the same ntp server).
You can see difference in the packets by comparing the two pcap files.

My best bet is that the ISP is blocking specific data in NTPv4 Packets that busybox-ntp is sending.

21.04.20213748Base systemBug ReportVery LowMediumMAC address of eth0 and eth1 are swapped on ath79 on Na...openwrt-19.07Unconfirmed Task Description

Tested on Nanostation M2, OpenWRT 19.07.

The problem does not occur on ar71xx and for this reason we are continuing to use ar71xx for this model, but would be nice to fix this before OpenWRT 21 if possible.

Steps to reproduce:

- note down the mac address of eth0 and eth1 of stock firmware
- flash the ath79 image of OpenWRT 19.07

Expected result:

- mac addresses of eth0 and eth1 are consistent with stock firmware

Actual result:

- mac addresses of eth0 and eth1 are swapped, that is: eth1 has the mac address of eth0 and eth0 has the mac address of eth 1

This causes problems to any system which relies on the mac address of one of these interfaces to recognize the device.

More information in this forum thread: https://forum.openwrt.org/t/mac-address-changed-after-sysupgrade-from-backfire-nanostation-m2/93530/5

Please let me know if you can confirm the issue and are willing to accept a patch.

20.04.20213746Base systemBug ReportVery LowLowx86_64 EFI image fails to boot when USB device is plugg...openwrt-21.02Unconfirmed Task Description

Snapshot OR 21.02.0-rc1-x86_64 will not boot EFI

System: AsRock J5005-ITX (EFI only boot), 4GB ram, Intel Dual 1000PT server adapter

 

Steps used to typically install snapshot:

Boot SystemRescueCD to prompt
issue dd if=openwrt-xxx of=/dev/sda
partitions are copied over, reboot
Error on Snapshot: “error: disk ‘hd0,gpt1’ not found

on RC1 file copies over as above but it does not boot in any fashion just returns to the bios screen.

It’s been a long time since I tested the EFI snapshots, but at one point they worked fine. Given that the EFI support was added to master, I decided to wait on 2021.02 for full implementation.

The original pull on github was https://github.com/openwrt/openwrt/pull/1968, but it has since been closed, and I saw there was some work on the EFI stack for dual booting. That image may in fact boot on a non-EFI system, but I do not have any way to test.

At this point I would say both snapshot and RC1 are broken for x86_64 EFI systems.

19.04.20213745Base systemBug ReportVery LowLowWireless 'isolate' option not working in brcmfmac drive...openwrt-21.02Unconfirmed Task Description

Device: BCM4356 WiFi chip + brcmfmac
OpenWRT Version: 21.02 (commit 50f2f25d58 [4 days ago])

I experienced the problem using OpenWrt 21.02 on a device using the brcmfmac driver for the BCM4356 chip.

I’ve only been able to test this on an InvizBox 2 (not supported by OpenWRT) but I suspect it to also be a problem for other devices using brcmfmac.

Steps to reproduce:

On a device running OpenWRT 21.02 and with a WiFi chip using the brcmfmac driver:

Set wireless.<wifi-iface>.isolate=’1’ on the WiFi interface that uses the brcmfmac driver.

Devices connected to the WiFi interface should be isolated from each other, but are not.

Notes / Potential fixes:

I was able to fix this issue by building with a specific patch for brcmfmac from the latest Cypress Linux WiFi Driver Release (FMAC)(https://community.cypress.com/t5/Wi-Fi-Bluetooth-for-Linux/Cypress-Linux-WiFi-Driver-Release-FMAC-2021-01-14/m-p/268899). The particular patch that fixed the issue can be found in the .zip file linked in the latest Cypress driver release. cypress-fmac-v5.4.18-2021_0114.zip > cypress-patch-v5.4.18-2021_0114.tar.gz > cypress-patch > 0004-brcmfmac-support-AP-isolation.patch.

The patch has not been accepted into linux-wireless yet. But there are details about it here: https://patchwork.kernel.org/project/linux-wireless/patch/20200901063237.15549-2-wright.feng@cypress.com/.

Let me know if you need any more information or there’s anything I can do to help sort this out. Thanks.

17.04.20213744Base systemBug ReportVery LowMediumstatic IPv6 routes to gateways within the ULA address r...TrunkUnconfirmed Task Description

Static IPv6 routes configured in `/etc/config/network` that use a gateway within the ula address range are not properly restored on startup.

I managed to reproduce the issue in 19.07.7 and in the latest snapshot (17-04-2021). To reproduce the issue, do the following:

Setup a new OpenWRT system, for example in a VM. Uplink connectivity is not required, which makes it easy to reproduce the bug in a VM. Then edit `/etc/config/network` and add an IPv6 route using a gateway within the ula range. For example the entries may look like this:

```
config globals ‘globals’

      option ula_prefix 'fd22:e91a:3889::/48'

config route6

      option target "2001:4860:4860::8844"
      option gateway "fd22:e91a:3889::43"
      option interface "lan"

```

Reboot the device and verify that the route is not present with `ip -6 route show`. Then modify the config a bit, for example replace the _43_ in the gateway address with _42_. Then execute `reload_config` and wait a few seconds. Then verify that the route is present with `ip -6 route show`. You may then reboot the device and the route will not be there anymore.

14.04.20213740Base systemBug ReportVery LowHighMT7688 wireless signal disappears under heavy loadTrunkUnconfirmed Task Description

Device: GL-MT300N-V2
CPU: MT7688
Openwrt Version: trunk(2021/4/14)

Steps:

1. install the firmware
2. modify /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option channel '11'
	option hwmode '11g'
	option path 'platform/10300000.wmac'
	option htmode 'HT40'
	option disabled '0'
	option noscan '1'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'none'

3. restart network
4. PC connect GL-MT300N-V2’s wifi
5. [Another Openwrt Router, with ‘iperf3 -s’][LAN]——–[WAN][GL-MT300N-V2][WIFI]——–[PC, with ‘iperf3 -c -R’]
6. Within 1 minutes, wifi signal disappears
7. no error appears in logread

Please fix it.

13.04.20213739Base systemBug ReportVery LowLowOpkg return err when removing a package required multip...TrunkUnconfirmed Task Description

This is still an issue (from barrier breaker era).

https://dev.archive.openwrt.org/ticket/18320

It is breaking packages CI
https://github.com/openwrt/packages/pull/15412

13.04.20213738Base systemBug ReportVery LowLowFritz 1200 no network on luci-21.02-snapshot-r15866-17a...openwrt-21.02Unconfirmed Task Description

- Device: AVM FRITZ!Repeater 1200

- Software versions: luci-21.02-snapshot-r15866-17a627ec82-ipq40xx-generic-avm_fritzrepeater-1200-squashfs-sysupgrade

- Steps to reproduce: there is no LAN connection after upload this firmware to Fritz 1200, after back to luci-19.07-snapshot-r11328-81266d9001-ipq40xx-generic-avm_fritzrepeater-1200-squashfs-sysupgrade, everything works: Lan connection return.

 


12.04.20213737Base systemBug ReportVery LowLowNew Warning with latest masterTrunkUnconfirmed Task Description

Supply the following if possible:
- ubuntu 20.04
- clone the latest master repository, and run quick image build procedure

Warnings indicating that ‘Makefile ‘package/boot/uboot-sunxi/Makefile’ has a dependency on ‘arm-trusted-firmware-sunxt’

This is a new warning. This occurs during the ./scripts/feeds install -a step and make menuconfig step.

Was not doing it a few days ago prior to update of master repository.

DL’d new master, now experiencing these warnings.

Thanks,


09.04.20213732Base systemBug ReportVery LowLowhostapd: VLAN-assignment via sae_password sometimes fai...TrunkUnconfirmed Task Description

Device: Ubiquiti UniFi AC LR (OpenWrt SNAPSHOT r16382-209c5918b5)

For some time I successfully run a per-device WPA2-PSK setup using the following options:

	option network 'dummy'
	option dynamic_vlan '2'
	option vlan_file '/root/ogb-hostapd-vlans-phy0'
	option wpa_psk_file '/root/ogb-hostapd-psks'
	option key 'invalid-fallback-psk-used-by-no-device-at-all'

This setup forces all devices to use a MAC-PSK combination from the wpa_psk_file, where they are reassigned to a working VLAN that is mapped to a specific bridge via the vlan_file. Meaning: If a device were to use the PSK from the key-option they would be bridged into br-dummy, a bridge that uses a VLAN not present on the upstream switchport.

To reiterate: This works absolutely perfectly and rock stable - until I switch a device over to WPA3. I comment out the MAC from the wpa_psk_file and add it via the sae_password option:

	list hostapd_bss_options 'sae_password=device-psk|mac=xx:xx:xx:xx:xx:xx|vlanid=8'

This works for some of the time only. Sometimes the device is assigned to the br-dummy bridge as if hostapd correctly uses the per-device-PSK, but ignores the vlanid-option. Usually a reconnect or two solves the problem. Using tcpdump I can clearly see the clients DHCP-requests in the br-dummy bridge when the issue occurs.

In the past I already tried to troubleshoot this issue by using the newest upstream hostapd but failed due to all the custom openwrt patches. I am really not a developer, but only a network engineer. Can someone please help me troubleshoot this? I would like to retry this with the newest hostapd before investing any time into troubleshooting something that might be already solved upstream (there were a couple of sae-patches).

08.04.20213730Base systemBug ReportVery LowLowresolve_conffiles reports spurious errorsopenwrt-19.07Unconfirmed Task Description
When I run upgrades

<code>
root@router:~# opkg update && opkg list-upgradable | awk '{print $1}' | xargs opkg upgrade

I usually end up with some messages like

Collected errors:
 * resolve_conffiles: Existing conffile /etc/config/luci_statistics is different from the conffile in the new package. The new conffile will be placed at /etc/config/luci_statistics-opkg.
 * resolve_conffiles: Existing conffile /etc/config/luci is different from the conffile in the new package. The new conffile will be placed at /etc/config/luci-opkg.
 * resolve_conffiles: Existing conffile /etc/config/ucitrack is different from the conffile in the new package. The new conffile will be placed at /etc/config/ucitrack-opkg.

Sometimes the conflicts are genuine – because I’ve configured the router – but most of them are because uci doesn’t force a canonical output format. For example

root@router:~# diff -u /etc/config/luci-opkg /etc/config/luci
--- /etc/config/luci-opkg	2021-03-27 02:44:43.000000000 -0400
+++ /etc/config/luci	2021-01-30 05:15:01.000000000 -0500
@@ -1,31 +1,39 @@
-config core main
-	option lang auto
-	option mediaurlbase /luci-static/bootstrap
-	option resourcebase /luci-static/resources
-	option ubuspath /ubus/
-	
-config extern flash_keep
-	option uci 		"/etc/config/"
-	option dropbear "/etc/dropbear/"
-	option openvpn	"/etc/openvpn/"
-	option passwd	"/etc/passwd"
-	option opkg		"/etc/opkg.conf"
-	option firewall	"/etc/firewall.user"
-	option uploads	"/lib/uci/upload/"
-	
-config internal languages
-	
-config internal sauth
-	option sessionpath "/tmp/luci-sessions"
-	option sessiontime 3600
-	
-config internal ccache
-	option enable 1
-		
-config internal themes
-
-config internal apply
-	option rollback 90
-	option holdoff 4
-	option timeout 5
-	option display 1.5
+
+config core 'main'
+	option lang 'auto'
+	option mediaurlbase '/luci-static/bootstrap'
+	option resourcebase '/luci-static/resources'
+	option ubuspath '/ubus/'
+
+config extern 'flash_keep'
+	option uci '/etc/config/'
+	option dropbear '/etc/dropbear/'
+	option openvpn '/etc/openvpn/'
+	option passwd '/etc/passwd'
+	option opkg '/etc/opkg.conf'
+	option firewall '/etc/firewall.user'
+	option uploads '/lib/uci/upload/'
+
+config internal 'languages'
+
+config internal 'sauth'
+	option sessionpath '/tmp/luci-sessions'
+	option sessiontime '3600'
+
+config internal 'ccache'
+	option enable '1'
+
+config internal 'themes'
+	option Bootstrap '/luci-static/bootstrap'
+
+config internal 'apply'
+	option rollback '90'
+	option holdoff '4'
+	option timeout '5'
+	option display '1.5'
+
+config internal 'diag'
+	option dns 'openwrt.org'
+	option ping 'openwrt.org'
+	option route 'openwrt.org'
+

Except for `luci.diag` and `luci.themes.Bootstrap`, these are identical config files, and I don’t think even configured luci.diag so that’s probably just from a previous change.

It can be hard to separate out what I’ve configured from what the packagers have changed, but it is much more tedious when I also need to separate out what’s spurious changes from the quotes and indentation changing.

It would save users a lot of time if either:

* `resolve_conffiles` called `uci` to check differences instead of comparing entire files, *or*
* `uci` had a canonical format that both it and `luci` agreed to stick to, strictly so that running `diff` (or whatever `resolve_conffiles` does) would only report genuine conflicts

Don’t get me wrong, I do like openwrt a lot. It’s way better than using an unfixable vendor firmware. The fact that I can upgrade packages on it at all is marvelous. Thank you for your work.


Model: TP-Link Archer C50 v4 https://openwrt.org/toh/tp-link/archer-c50

Build: OpenWrt 19.07.7 r11306-c4a6851c72 / LuCI openwrt-19.07 branch git-21.096.73306-254083c

Kernel: 4.14.221

Packages:

root@router:~# opkg list-installed
base-files - 204.2-r11306-c4a6851c72
busybox - 1.30.1-6
cgi-io - 19
collectd - 5.12.0-1
collectd-mod-conntrack - 5.12.0-1
collectd-mod-cpu - 5.12.0-1
collectd-mod-interface - 5.12.0-1
collectd-mod-iwinfo - 5.12.0-1
collectd-mod-load - 5.12.0-1
collectd-mod-memory - 5.12.0-1
collectd-mod-network - 5.12.0-1
collectd-mod-ping - 5.12.0-1
collectd-mod-rrdtool - 5.12.0-1
collectd-mod-uptime - 5.12.0-1
collectd-mod-wireless - 5.12.0-1
conntrack - 2018-05-01-88610abe-1
diffutils - 3.7-2
dnsmasq - 2.80-16.3
dropbear - 2019.78-2
firewall - 2019-11-22-8174814a-3
fstools - 2020-05-12-84269037-1
fwtool - 2
getrandom - 2019-06-16-4df34a4d-3
hostapd-common - 2019-08-08-ca8c2bd2-7
ip6tables - 1.8.3-1
iptables - 1.8.3-1
iptables-mod-conntrack-extra - 1.8.3-1
iptables-mod-ipopt - 1.8.3-1
iw - 5.0.1-1
iwinfo - 2019-10-16-07315b6f-1
jshn - 2020-05-25-66195aee-1
jsonfilter - 2018-02-04-c7e938d6-1
kernel - 4.14.221-1-d92769dc5268e102503ae83fe968a56c
kmod-cfg80211 - 4.14.221+4.19.161-1-1
kmod-gpio-button-hotplug - 4.14.221-3
kmod-ifb - 4.14.221-1
kmod-ip6tables - 4.14.221-1
kmod-ipt-conntrack - 4.14.221-1
kmod-ipt-conntrack-extra - 4.14.221-1
kmod-ipt-core - 4.14.221-1
kmod-ipt-ipopt - 4.14.221-1
kmod-ipt-nat - 4.14.221-1
kmod-ipt-offload - 4.14.221-1
kmod-ipt-raw - 4.14.221-1
kmod-leds-gpio - 4.14.221-1
kmod-lib-crc-ccitt - 4.14.221-1
kmod-mac80211 - 4.14.221+4.19.161-1-1
kmod-mt76-core - 4.14.221+2021-02-15-5c768dec-1
kmod-mt7603 - 4.14.221+2021-02-15-5c768dec-1
kmod-mt76x02-common - 4.14.221+2021-02-15-5c768dec-1
kmod-mt76x2 - 4.14.221+2021-02-15-5c768dec-1
kmod-mt76x2-common - 4.14.221+2021-02-15-5c768dec-1
kmod-nf-conntrack - 4.14.221-1
kmod-nf-conntrack-netlink - 4.14.221-1
kmod-nf-conntrack6 - 4.14.221-1
kmod-nf-flow - 4.14.221-1
kmod-nf-ipt - 4.14.221-1
kmod-nf-ipt6 - 4.14.221-1
kmod-nf-nat - 4.14.221-1
kmod-nf-reject - 4.14.221-1
kmod-nf-reject6 - 4.14.221-1
kmod-nfnetlink - 4.14.221-1
kmod-ppp - 4.14.221-1
kmod-pppoe - 4.14.221-1
kmod-pppox - 4.14.221-1
kmod-sched-cake - 4.14.221+2019-03-12-057c7388-1
kmod-sched-core - 4.14.221-1
kmod-slhc - 4.14.221-1
libblobmsg-json - 2020-05-25-66195aee-1
libc - 1.1.24-2
libcap - 2.27-1
libelf1 - 0.177-1
libgcc1 - 7.5.0-2
libip4tc2 - 1.8.3-1
libip6tc2 - 1.8.3-1
libiwinfo-lua - 2019-10-16-07315b6f-1
libiwinfo20181126 - 2019-10-16-07315b6f-1
libjson-c2 - 0.12.1-3.1
libjson-script - 2020-05-25-66195aee-1
libltdl7 - 2.4.6-2
liblua5.1.5 - 5.1.5-3
liblucihttp-lua - 2019-07-05-a34a17d5-1
liblucihttp0 - 2019-07-05-a34a17d5-1
libmbedtls12 - 2.16.10-1
libmnl0 - 1.0.4-2
libnetfilter-conntrack3 - 2018-05-01-3ccae9f5-2
libnetfilter-cthelper0 - 1.0.0-2
libnetfilter-cttimeout1 - 1.0.0-2
libnetfilter-queue1 - 2017-06-27-601abd1c-2
libnfnetlink0 - 1.0.1-3
libnl-tiny - 0.1-5
liboping - 1.10.0-2
libpthread - 1.1.24-2
librrd1 - 1.0.50-3
libubox20191228 - 2020-05-25-66195aee-1
libubus-lua - 2019-12-27-041c9d1c-1
libubus20191227 - 2019-12-27-041c9d1c-1
libuci20130104 - 2019-09-01-415f9e48-4
libuclient20160123 - 2020-06-17-51e16ebf-1
libustream-mbedtls20150806 - 2020-03-13-40b563b1-1
libxtables12 - 1.8.3-1
logd - 2019-06-16-4df34a4d-3
lua - 5.1.5-3
luci - git-21.096.73306-254083c-1
luci-app-firewall - git-21.096.73306-254083c-1
luci-app-openvpn - git-21.096.73306-254083c-1
luci-app-opkg - git-21.096.73306-254083c-1
luci-app-simple-adblock - git-21.050.37945-c33df8f-1
luci-app-sqm - 1.4.0-2
luci-app-statistics - git-21.096.73306-254083c-1
luci-base - git-21.096.73306-254083c-1
luci-compat - git-21.096.73306-254083c-1
luci-lib-ip - git-21.096.73306-254083c-1
luci-lib-iptparser - git-21.096.73306-254083c-1
luci-lib-jsonc - git-21.096.73306-254083c-1
luci-lib-nixio - git-21.096.73306-254083c-1
luci-mod-admin-full - git-21.096.73306-254083c-1
luci-mod-network - git-21.096.73306-254083c-1
luci-mod-status - git-21.096.73306-254083c-1
luci-mod-system - git-21.096.73306-254083c-1
luci-proto-ipv6 - git-21.096.73306-254083c-1
luci-proto-ppp - git-21.096.73306-254083c-1
luci-theme-bootstrap - git-21.096.73306-254083c-1
mtd - 24
netifd - 2021-01-09-753c351b-1
odhcp6c - 2021-01-09-64e1b4e7-16
odhcpd-ipv6only - 2020-05-03-49e4949c-3
openwrt-keyring - 2019-07-25-8080ef34-1
opkg - 2021-01-31-c5dccea9-1
ppp - 2.4.7.git-2019-05-25-3
ppp-mod-pppoe - 2.4.7.git-2019-05-25-3
procd - 2020-03-07-09b9bd82-1
rpcd - 2020-05-26-67c8a3fd-1
rpcd-mod-file - 2020-05-26-67c8a3fd-1
rpcd-mod-iwinfo - 2020-05-26-67c8a3fd-1
rpcd-mod-luci - 20201107
rpcd-mod-rrdns - 20170710
rrdtool1 - 1.0.50-3
simple-adblock - 1.8.4-10
sqm-scripts - 1.4.0-2
swconfig - 12
tc - 5.0.0-2.1
ubox - 2019-06-16-4df34a4d-3
ubus - 2019-12-27-041c9d1c-1
ubusd - 2019-12-27-041c9d1c-1
uci - 2019-09-01-415f9e48-4
uclient-fetch - 2020-06-17-51e16ebf-1
uhttpd - 2020-10-01-3abcc891-1
urandom-seed - 1.0-1
urngd - 2020-01-21-c7f7b6b6-1
usign - 2020-05-23-f1f65026-1
wireless-regdb - 2020.11.20-1
wpad-basic - 2019-08-08-ca8c2bd2-7
zlib - 1.2.11-3
07.04.20213729Base systemBug ReportVery LowHighRT2800 (MT7620) no multiple SSIDTrunkUnconfirmed Task Description

master branch

MT7620
Nexx WT3020 8M

config wifi-device ‘radio0’

option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/10180000.wmac'
option cell_density '0'
option htmode 'HT40'
option noscan '1'

config wifi-iface ‘wifinet0’

option device 'radio0'
option mode 'ap'
option encryption 'none'
option network 'lan2'
option ssid 'Public'

config wifi-iface ‘wifinet1’

option device 'radio0'
option mode 'ap'
option encryption 'none'
option network 'lan'
option ssid 'Private2'

only “Public” wifi shows

wlan0 Link encap:Ethernet HWaddr 38:xxxxxxxxxxx

        inet addr:192.168.182.1  Bcast:192.168.255.255  Mask:255.255.0.0
        inet6 addr: fe80::3a1c:4aff:fe06:c05b/64 Scope:Link
        UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
        RX packets:0 errors:0 dropped:0 overruns:0 frame:0
        TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000 
        RX bytes:0 (0.0 B)  TX bytes:1140 (1.1 KiB)
 


06.04.20213728Base systemBug ReportVery LowLowIPv6 Connectivity Lost When ISP Router is Restartedopenwrt-19.07Unconfirmed Task Description

I am running OpenWrt 19.07.7 on a TpLink Archer C7 (v5). The OpenWrt router is connected to a Router that is provided by my ISP. The ISP router connects to the Internet using DS-Lite.

    ------------     -----------     ----------     ------------
    | Local    |     | OpenWrt |     |  ISP   |     | Internet |
    | Network  |-----| Router  |-----| Router |-----|          |
    ------------     -----------     ----------     ------------

The OpenWrt router receives a delegated prefix using DHCPv6, which provides global addresses to the network connected to the OpenWrt router. This works perfectly fine, until the ISP router is restarted, which sometimes happens when it upgrades its firmware. In this situation, the IPv6 connectivity is lost and is not automatically restored. To get IPv6 connectivity, I have to restart the WAN6 interface, which estabilshes the IPv6 connection again. The IPv4 connectivity is restored automatically.

After the IPS router has been restarted, the OpenWrt router cannot ping IPv6 hosts via global addresses. Even the global address of the ISP router cannot be reached via ping. Pings via link-local addresses work fine.

When the IPv6 connection is gone, restarting the WAN6 interface, seems to change nothing on the side of the OpenWrt router. The output before and after the restart of ip -6 addr, ip -6 route, and ip6tables -L are identical (except for the IP address life-times). Also the information displayed by LuCI on the Interface page stays the same. However, the connectivity is restored after the interface is restarted.

My guess for explaining this behavior is as follows. When the ISP router is restarted, it receives the same IPv6 address lease and prefix from my ISP as earlier. (The IPv6 address lease is valid for a few days.) The ISP router, however, has “forgotten” that it had delegated a prefix to the OpenWrt router. Hence, the ISP router is not routing any traffic to the prefix the OpenWrt router is using. Since the IPv6 address of the ISP router does not change, the OpenWrt router does not detect this change. The RAs that the OpenWrt router receives are the same as before. When I restart the WAN6 interface, however, it asks for a new IPv6 address and a new IPv6 prefix, which in turn leads to the ISP router creating the proper route for the delegated prefix, which restores the IPv6 connectivity.

Unfortunately, I do not have access to the routing table of the ISP router, and hence, I cannot verify my hypothesis. (The reason for using OpenWrt is, that the ISP router is severely limited. I have to use the ISP router, however.)

Is there a way to force odhcp6c to probe whether the current delegated prefix is valid? Maybe sending some sort of renew/refresh message via DHCPv6? Is there a way to ask odhcp6c to regularly update/renew the delegated prefix, say every 5 minutes?

I currently have a cron job, which pings an IPv6 host on the internet and restarts the WAN6 interface when the ping fails. This workaround does the trick, but is rather ugly.

06.04.20213727Base systemBug ReportVery LowMediumdlink 860l-b1resetsopenwrt-19.07Unconfirmed Task Description

The log is spammed with resets (affecting wifi/network stability)

Model:D-Link DIR-860L B1
Architecture: MediaTek MT7621 ver:1 eco:3
Software: OpenWrt 19.07.7 r11306-c4a6851c72 / LuCI openwrt-19.07 branch git-21.086.32701-7456e2a

Errors in log:
Mon Apr 5 19:54:00 2021 kern.err kernel: [ 8536.871237] mt76x2e 0000:01:00.0: MCU message 31 (seq 8) timed out
Mon Apr 5 19:54:00 2021 kern.info kernel: [ 8536.932817] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
Mon Apr 5 19:54:00 2021 kern.info kernel: [ 8536.932836] mt76x2e 0000:01:00.0: Build: 1
Mon Apr 5 19:54:00 2021 kern.info kernel: [ 8536.932844] mt76x2e 0000:01:00.0: Build Time: 201507311614 Mon Apr 5 19:54:00 2021 kern.info kernel: [ 8536.951281] mt76x2e 0000:01:00.0: Firmware running!
Mon Apr 5 19:54:00 2021 kern.info kernel: [ 8536.961405] ieee80211 phy0: Hardware restart was requested
Mon Apr 5 20:28:47 2021 kern.err kernel: [10624.060218] mt76x2e 0000:01:00.0: MCU message 31 (seq 1) timed out
Mon Apr 5 20:28:47 2021 kern.info kernel: [10624.121807] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
Mon Apr 5 20:28:47 2021 kern.info kernel: [10624.121826] mt76x2e 0000:01:00.0: Build: 1
Mon Apr 5 20:28:47 2021 kern.info kernel: [10624.121834] mt76x2e 0000:01:00.0: Build Time: 201507311614 Mon Apr 5 20:28:47 2021 kern.info kernel: [10624.150387] ieee80211 phy0: Hardware restart was requested
Mon Apr 5 20:28:47 2021 kern.info kernel: [10624.140242] mt76x2e 0000:01:00.0: Firmware running!


Tue Apr 6 06:55:38 2021 daemon.warn hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: did not use HMAC-SHA1-AES with CCMP/GCMP
Tue Apr 6 06:55:38 2021 daemon.warn hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: did not use HMAC-SHA1-AES with CCMP/GCMP
Tue Apr 6 06:55:38 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Tue Apr 6 06:55:38 2021 daemon.info hostapd: wlan0: STA de:4f:76:41:03:f1 WPA: pairwise key handshake completed (RSN)
Tue Apr 6 06:55:51 2021 kern.err kernel: [48247.431859] mt76x2e 0000:01:00.0: MCU message 31 (seq 6) timed out
Tue Apr 6 06:55:51 2021 kern.info kernel: [48247.493433] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
Tue Apr 6 06:55:51 2021 kern.info kernel: [48247.493451] mt76x2e 0000:01:00.0: Build: 1
Tue Apr 6 06:55:51 2021 kern.info kernel: [48247.493458] mt76x2e 0000:01:00.0: Build Time: 201507311614 Tue Apr 6 06:55:51 2021 kern.info kernel: [48247.511878] mt76x2e 0000:01:00.0: Firmware running!
Tue Apr 6 06:55:51 2021 kern.info kernel: [48247.522018] ieee80211 phy0: Hardware restart was requested
Tue Apr 6 06:56:09 2021 kern.info kernel: [48265.553364] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
Tue Apr 6 06:56:09 2021 kern.info kernel: [48265.553384] mt76x2e 0000:01:00.0: Build: 1
Tue Apr 6 06:56:09 2021 kern.info kernel: [48265.553391] mt76x2e 0000:01:00.0: Build Time: 201507311614 Tue Apr 6 06:56:09 2021 kern.info kernel: [48265.571812] mt76x2e 0000:01:00.0: Firmware running!
Tue Apr 6 06:56:09 2021 kern.info kernel: [48265.581972] ieee80211 phy0: Hardware restart was requested


Tue Apr 6 08:23:29 2021 daemon.warn hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: did not use HMAC-SHA1-AES with CCMP/GCMP
Tue Apr 6 08:23:29 2021 daemon.warn hostapd: wlan1: STA xx:xx:xx:xx:xx:xx WPA: did not use HMAC-SHA1-AES with CCMP/GCMP
Tue Apr 6 08:23:29 2021 daemon.notice hostapd: wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
Tue Apr 6 08:23:29 2021 daemon.info hostapd: wlan0: STA xx:xx:xx:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Tue Apr 6 08:23:33 2021 kern.info kernel: [53509.809251] mt76x2e 0000:01:00.0: Firmware Version: 0.0.00
Tue Apr 6 08:23:33 2021 kern.info kernel: [53509.809270] mt76x2e 0000:01:00.0: Build: 1
Tue Apr 6 08:23:33 2021 kern.info kernel: [53509.809278] mt76x2e 0000:01:00.0: Build Time: 201507311614 Tue Apr 6 08:23:33 2021 kern.info kernel: [53509.827666] mt76x2e 0000:01:00.0: Firmware running!
Tue Apr 6 08:23:33 2021 kern.info kernel: [53509.837823] ieee80211 phy0: Hardware restart was requested


02.04.20213721Base systemBug ReportVery LowMediumcustom "CONFIG_VERSION_DIST" breaks building Edimax ima...TrunkUnconfirmed Task Description

Just ran a custom build for ath79 with setting

CONFIG_VERSION_DIST="Roederer"

finally fails in target/linux/install with

/mnt/hosts/strike/develop/sven/openwrt/freifunk/freifunk-berlin/openwrt/staging_dir/host/bin/edimax_fw_header -M F9J1108v1 -m BR-6679BAC -v Roedererr15865 -n "uImage" -i /mnt/hosts/strike/develop/sven/openwrt/freifunk/freifunk-berlin/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/loader-belkin_f9j1108-v2.uImage -o /mnt/hosts/strike/develop/sven/openwrt/freifunk/freifunk-berlin/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/tmp/roederer-2021.04-1faf8bcb-ath79-generic-belkin_f9j1108-v2-squashfs-factory.bin.uImage
[edimax_fw_header] *** error: 'Roedererr15865' is too long, max firware version length is 13
Makefile:87: recipe for target '/mnt/hosts/strike/develop/sven/openwrt/freifunk/freifunk-berlin/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/tmp/roederer-2021.04-1faf8bcb-ath79-generic-belkin_f9j1108-v2-squashfs-factory.bin' failed
make[5]: *** [/mnt/hosts/strike/develop/sven/openwrt/freifunk/freifunk-berlin/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/tmp/roederer-2021.04-1faf8bcb-ath79-generic-belkin_f9j1108-v2-squashfs-factory.bin] Error 255

So the VERSION_DIST gets suffixed by “r15865” which make it 14 bytes long. With the default “OpenWrt” it will be excatly 13 bytes.

Not sure what’s the best fix:

  • limiting the max length of the CONFIG-option
  • stripping something from the vesion-string provided to the edimax_fw_header command
  • chopping the extra bytes

This was actually seen in OpenWrt-21.02, but the Makefile seems identical to master.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ath79/image/generic.mk;h=f358d44064438c2aad4cf45840dee40f5381b2fe;hb=refs/heads/master#l55

30.03.20213712Base systemBug ReportVery LowLowLinksys E8450 mt7915e failureTrunkUnconfirmed Task Description

Supply the following if possible:
- Linksys E8450 / Belking AX3200
- Latest snapshot as of 29.03.2021
- Flash firmware, boot

Looking at `readlog` I see the following:

```
Sun Mar 28 10:16:29 2021 kern.debug kernel: [ 8.144261] ieee80211 phy0: Selected rate control algorithm ‘minstrel_ht’ Sun Mar 28 10:16:29 2021 kern.debug kernel: [ 8.155943] mt7915e 0000:01:00.0: assign IRQ: got 144
Sun Mar 28 10:16:29 2021 kern.debug kernel: [ 8.161082] pci 0000:00:00.0: enabling bus mastering
Sun Mar 28 10:16:29 2021 kern.info kernel: [ 8.166067] mt7915e 0000:01:00.0: enabling device (0000 → 0002)
Sun Mar 28 10:16:29 2021 kern.debug kernel: [ 8.172151] mt7915e 0000:01:00.0: enabling bus mastering
Sun Mar 28 10:16:29 2021 kern.info kernel: [ 8.209817] mt7622-wmac 18000000.wmac: HW/SW Version: 0x8a108a10, Build Time: 20190801210006a
Sun Mar 28 10:16:29 2021 kern.info kernel: [ 8.209817]
Sun Mar 28 10:16:29 2021 kern.info kernel: [ 8.286383] mt7622-wmac 18000000.wmac: N9 Firmware Version: 2.0, Build Time: 20200131180931
Sun Mar 28 10:16:29 2021 kern.err kernel: [ 12.176986] mt7915e 0000:01:00.0: Firmware is not ready for download
Sun Mar 28 10:16:29 2021 kern.warn kernel: [ 12.183510] mt7915e: probe of 0000:01:00.0 failed with error -5
```

 


29.03.20213710Base systemBug ReportVery LowLowatlantic.ko (Marvell/Aqtion/Aqantia AQC107/108) 10Gbit ...TrunkUnconfirmed Task Description

I have Several ASUS branded PCIe 10Gbit Cards based on the Aquantia Gen2 silicon, Some AQC107 based SFP+ modules and several ipq8074 boards with them. These work fine with the atlantic kernel driver which has been in mainline for some time.

Test build is x86_64 against the 21.02 tagged branch.

The 21.02 tagged branch (and the master, and 19.07) menuconfig for these cards do not appear despite the driver being present in the kernel source tree.

The lspci ID output of the card:

04:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-T/IEEE 802.3bz Ethernet Controller [AQtion] [1d6a:d107] (rev 02)
        Subsystem: ASUSTeK Computer Inc. XG-C100C [1043:8741]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at ed440000 (64-bit, non-prefetchable) [size=64K]
        Region 2: Memory at ed450000 (64-bit, non-prefetchable) [size=4K]
        Region 4: Memory at ed000000 (64-bit, non-prefetchable) [size=4M]
        Expansion ROM at ed400000 [disabled] [size=256K]
        Capabilities: [40] Express (v2) Endpoint, MSI 00
                DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 75.000W
                DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
                        RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
                        MaxPayload 256 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend-
                LnkCap: Port #0, Speed 8GT/s, Width x4, ASPM L0s L1, Exit Latency L0s unlimited, L1 unlimited
                        ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
                LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 8GT/s (ok), Width x4 (ok)
                        TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR-
                         10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
                         EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
                         FRS- TPHComp- ExtTPHComp-
                         AtomicOpsCap: 32bit- 64bit- 128bitCAS-
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled,
                         AtomicOpsCtl: ReqEn-
                LnkCap2: Supported Link Speeds: 2.5-8GT/s, Crosslink+ Retimer- 2Retimers- DRS-
                LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ EqualizationPhase1+
                         EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest-
                         Retimer- 2Retimers- CrosslinkRes: unsupported
        Capabilities: [80] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [90] MSI-X: Enable+ Count=32 Masked-
                Vector table: BAR=2 offset=00000000
                PBA: BAR=2 offset=00000200
        Capabilities: [a0] MSI: Enable- Count=1/32 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [c0] Vital Product Data
                Product Name: AQtion
                Read-only fields:
                        [PN] Part number: AquantiaPartNumber
                        [EC] Engineering changes: AquantiaEngineeringChangeLevel
                        [FG] Unknown: 41 71 75 61 6e 74 69 61 46 61 62 72 69 63 47 65 6f 67 72 61 70 68 79
                        [LC] Unknown: 41 71 75 61 6e 74 69 61 4c 6f 63 61 74 69 6f 6e
                        [MN] Manufacture ID: AquantiaManufacturingId
                        [PG] Unknown: 41 71 75 61 6e 74 69 61 50 63 69 47 65 6f 67 72 61 70 68 79
                        [SN] Serial number: AquantiaSerialNumber
                        [V0] Vendor specific: AquantiaVendorSpecificReadOnlyItem0
                        [V1] Vendor specific: AquantiaVendorSpecificReadOnlyItem1
                        [RV] Reserved: checksum good, 0 byte(s) reserved
                Read/write fields:
                        [YA] Asset tag: AquantiaAssetTagIdentifier
                        [V0] Vendor specific: AquantiaVendorSpecificWritableItem0
                        [V1] Vendor specific: AquantiaVendorSpecificWritableItem1
                        [Y0] System specific: AquantiaSystemSpecificWritableItem0
                        [Y1] System specific: AquantiaSystemSpecificWritableItem1
                        [RW] Read-write area: 9 byte(s) free
                End
        Capabilities: [100 v2] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr+ BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
                AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn-
                        MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap-
                HeaderLog: 00000000 00000000 00000000 00000000
        Capabilities: [150 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?>
        Capabilities: [180 v1] Secondary PCI Express
                LnkCtl3: LnkEquIntrruptEn- PerformEqu-
                LaneErrStat: 0
        Kernel driver in use: atlantic
        Kernel modules: atlantic


[aenertia@fedora build]$ lsmod |grep atlantic
atlantic              229376  0
macsec                 61440  1 atlantic

Within the make kernel_menuconfig selection it is shown as a Y default, tristate flag when the x86_64 target is selected but never appears to get built into the resultant image.

On my comparison systems running RHEL8.3 and Fedora Rawhide - the atlantic kernel module has a dependency on the macsec kernel module - this is mentioned the 5.4 kernel source in the openwrt build tree for 21.02 tag - but seems to be silently dropped/skipped.

I tried several manual .config edits in the kernel build tree to force inclusion of the atlantic and macsec modules without success in the resultant images.
I note that there is a main kmod-macsec config entry in the primary .config buildroot ; but enabling that results in an architecture invalid for target error during kernel compilation. Is there perhaps a double up of the macsec name inside the build tree?

tl;dr Summary of required actions:

*Expose the Atlantic module/option in the main menuconfig buildroot
*Confirm why the atlantic module is set to Y by default, but not resulting in a usable driver in the kernel
*Check that the macsec module which appears to be a dependency for the atlantic driver does not have a naming conflict and/or why selecting it in the main buildroot results in an invalid arch error for x86_64 build target.

Severity ; the atlantic module is increasingly commonly deployed both in server, enthusiast and OEM embedded appliances (ipq80xx is a common pairing) as well as NBaseT SFP+ modules (rebadged by several vendors i.e Mikrotik) to supply NBaseT 10Gbit functionality. It has not been working in the last 2 openwrt releases and should be fixed before 21.02 goes out the door.

 


28.03.20213709Base systemBug ReportVery LowMediumrc.common enabled logic incompleteAllUnconfirmed Task Description

rc.common@enabled checks ‘S’ only

this results in incorrect output on K only init scripts ( umount )

###### poc
$> service

Showing tasks 201 - 250 of 1419 Page 5 of 29<<First - 3 - 4 - 5 - 6 - 7 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing