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.

Opened  descIDCategoryTask TypePrioritySeveritySummaryReported InStatus
14.05.20213811PackagesBug ReportVery LowHighminiupnpd odd behaviour however enabling log_output wor...AllUnconfirmed Task Description

- Device problem occurs on

Fritzbox 7530 ipq40xx / arm_cortex-a7_neon-vfpv4

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

miniupnpd_2.2.1-1_arm_cortex-a7_neon-vfpv4.ipk

I have a issue with miniupnpd 2.2.1-1 i have tested both OpenWrt 19.07.7 to 21.02.0-rc1 r16046-59980f7aaf via ipq40xx.

When restarting miniupnpd it doesn’t seems to work or opening any ports but gives messages like so:
Fri May 14 09:19:28 2021 daemon.notice miniupnpd[8632]: HTTP listening on port 5000
Fri May 14 09:19:28 2021 daemon.warn miniupnpd[8632]: no HTTP IPv6 address, disabling IPv6
Fri May 14 09:19:28 2021 daemon.notice miniupnpd[8632]: Listening for NAT-PMP/PCP traffic on port 5351

Now however if i enable the debug mode “option log_output ‘1’” and restart miniupnpd is works without issue,

No idea if it affects any other targets but for the fritzbox 7530

13.05.20213810ToolchainBug ReportVery LowMediumBuild of x86_64 target fails on x86_64 host (libtool er...openwrt-19.07Unconfirmed Task Description

I’m building openwrt 19.08.7 x86_64 target on an x86_64 linux box, and building fails in libpcre, with a libtool complaining that it tried to relink libpcreposix.la, and for that it found /usr/lib64/libc.so with an invalid ELF header. The complaint is true somewhat, because indeed /usr/lib64/libc.so is not an ELF on my system, but obviously it should not even be trying to pick a local system library at the first place.

There is a very old similar bugreport (solved long ago) – https://dev.archive.openwrt.org/ticket/8399

Note: 32-bit x86 builds complete successfully on this same box.

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


12.05.20213802KernelBug ReportVery LowLowDFS channel change causes 5GHz WiFi to failopenwrt-19.07Unconfirmed Task Description

My TP-Link AC1750 Archer C7 v5 just detected another WiFi on the same 5GHz channel. Thus it tried to switch to a different channel, which apparently succeeded. Afterwards the kernel experienced a bug causing the 5GHz WiFi to fail indefinitely.

I’ve attached a list of installed packages and the relevant syslog:
Lines 1 - 7 show the change to a different channel
Lines 8 - 10 show a device disconnecting and reconnecting (probably because of the channel switch)
Lines 11 - 82 are SWBA overrun warnings
Lines 90 - 190 are kernel traces
Lines 255 - 261 show a device connecting to the 2.4GHz WiFi, because the 5GHz is no longer available
Lines 271 - 278 show other devices being disassociated as they are also unable to connect again

 


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.20213765KernelBug ReportVery LowHighRT5592 initializes but does not function when enabledopenwrt-21.02Unconfirmed Task Description

this issue is also present on master branch

board is EPG600 (not added yet)
this probably also affects ESR600 which is the same hardware
and other boards with RT5592

5 GHz wireless initializes and SSID can be seen on scan
however, clients cannot connect and traffic fails

init:

...
...
[   12.654377] rt2800pci 0000:01:00.0: card - bus=0x1, slot = 0x0 irq=4
[   12.668538] rt2800pci 0000:01:00.0: loaded eeprom from mtd device "factory"
[   12.675676] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5592, rev 0222 detected
[   12.683626] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 000f detected
[   12.711360] urngd: jent-rng init failed, err: 2
[   12.737471] rt2800_wmac 10180000.wmac: loaded eeprom from mtd device "rf"
[   12.744489] ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 6352, rev 0500 detected
[   12.752435] ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 7620 detected
...
...

iw list (phy0):

Wiphy phy0
        wiphy index: 0
        max # scan SSIDs: 4
        max scan IEs length: 2261 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        Retry short long limit: 2
        Coverage class: 0 (up to 0m)
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point
        Band 2:
                Capabilities: 0x2fe
                        HT20/HT40
                        SM Power Save disabled
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        TX STBC
                        RX STBC 2-streams
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 2 usec (0x04)
                HT TX/RX MCS rate indexes supported: 0-15, 32
                Frequencies:
                        * 5180 MHz [36] (20.0 dBm)
                        * 5190 MHz [38] (20.0 dBm)
                        * 5200 MHz [40] (20.0 dBm)
                        * 5210 MHz [42] (20.0 dBm)
                        * 5220 MHz [44] (20.0 dBm)
                        * 5230 MHz [46] (20.0 dBm)
                        * 5240 MHz [48] (20.0 dBm)
                        * 5250 MHz [50] (20.0 dBm) (no IR, radar detection)
                        * 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
                        * 5270 MHz [54] (20.0 dBm) (no IR, radar detection)
                        * 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
                        * 5290 MHz [58] (20.0 dBm) (no IR, radar detection)
                        * 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
                        * 5310 MHz [62] (20.0 dBm) (no IR, radar detection)
                        * 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
                        * 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
                        * 5510 MHz [102] (20.0 dBm) (no IR, radar detection)
                        * 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
                        * 5530 MHz [106] (20.0 dBm) (no IR, radar detection)
                        * 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
                        * 5550 MHz [110] (20.0 dBm) (no IR, radar detection)
                        * 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
                        * 5570 MHz [114] (20.0 dBm) (no IR, radar detection)
                        * 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
                        * 5590 MHz [118] (20.0 dBm) (no IR, radar detection)
                        * 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
                        * 5610 MHz [122] (20.0 dBm) (no IR, radar detection)
                        * 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
                        * 5630 MHz [126] (20.0 dBm) (no IR, radar detection)
                        * 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
                        * 5650 MHz [130] (20.0 dBm) (no IR, radar detection)
                        * 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
                        * 5670 MHz [134] (20.0 dBm) (no IR, radar detection)
                        * 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
                        * 5690 MHz [138] (20.0 dBm) (no IR, radar detection)
                        * 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
                        * 5745 MHz [149] (20.0 dBm) (no IR)
                        * 5755 MHz [151] (20.0 dBm) (no IR)
                        * 5765 MHz [153] (20.0 dBm) (no IR)
                        * 5775 MHz [155] (20.0 dBm) (no IR)
                        * 5785 MHz [157] (20.0 dBm) (no IR)
                        * 5795 MHz [159] (20.0 dBm) (no IR)
                        * 5805 MHz [161] (20.0 dBm) (no IR)
                        * 5825 MHz [165] (20.0 dBm) (no IR)
                        * 4920 MHz [184] (disabled)
                        * 4940 MHz [188] (disabled)
                        * 4960 MHz [192] (disabled)
                        * 4980 MHz [196] (disabled)
        valid interface combinations:
                 * #{ managed, AP, mesh point } <= 8,
                   total <= 8, #channels <= 1
        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Supported extended features:
                * [ RRM ]: RRM
                * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
                * [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
                * [ SCAN_RANDOM_SN ]: use random sequence numbers in scans
                * [ SCAN_MIN_PREQ_CONTENT ]: use probe request with only rate IEs in scans
                * [ CONTROL_PORT_NO_PREAUTH ]: disable pre-auth over nl80211 control port support
                * [ DEL_IBSS_STA ]: deletion of IBSS station support
                * [ SCAN_FREQ_KHZ ]: scan on kHz frequency support
                * [ CONTROL_PORT_OVER_NL80211_TX_STATUS ]: tx status for nl80211 control port support

errors:

[  248.431432] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin'
[  248.452925] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.40
[  248.515819] br-lan: port 2(wlan0) entered blocking state
[  248.521308] br-lan: port 2(wlan0) entered disabled state
[  248.526882] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0024, type=4
[  248.540458] device wlan0 entered promiscuous mode
[  248.545362] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0072, type=4
[  248.563127] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0024, type=4
[  248.580316] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[  248.587159] br-lan: port 2(wlan0) entered blocking state
[  248.592642] br-lan: port 2(wlan0) entered forwarding state
[  248.603260] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0055, type=4
[  248.623801] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0024, type=4
[  248.644220] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0072, type=4
[  248.664762] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0024, type=4
[  248.705661] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0055, type=4
[  248.726199] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0024, type=4
[  248.746620] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0072, type=4
[  249.076237] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4003 max 3840
[  249.893479] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  250.648599] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  250.661836] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  250.681991] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  251.065181] rt2x00lib_rxdone_read_signal: 94 callbacks suppressed
[  251.065206] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0016, type=4
[  251.084627] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0000, type=4
[  251.097831] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x0120, type=4
[  251.131983] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  251.151566] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  251.199122] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0072, type=4
[  251.349860] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0077, type=4
[  251.522683] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 3904 max 3840
[  251.549260] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  251.561657] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  251.581250] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  251.783651] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  251.795947] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x0120, type=4
[  251.833765] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  251.846411] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0000, type=4
[  251.862441] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  251.960289] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0022, type=4
[  251.973491] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0000, type=4
[  252.013308] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  252.032827] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  252.080332] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0072, type=4
[  252.393129] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 3904 max 3840
[  252.977643] rt2x00lib_rxdone_read_signal: 5 callbacks suppressed
[  252.977668] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0077, type=4
[  253.367744] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0040, type=4
[  253.383966] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0001, type=4
[  253.399972] rt2x00lib_rxdone: 17 callbacks suppressed
[  253.399994] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  253.423120] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  253.435617] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0000, type=4
[  253.451641] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  253.478082] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  253.490376] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x0120, type=4
[  253.527646] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  253.540122] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0027, type=4
[  253.556142] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  253.582589] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  253.602113] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  253.651031] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0072, type=4
[  253.688334] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4074 max 3840
[  253.700828] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0000, type=4
[  253.716857] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  253.785936] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0077, type=4
[  253.851589] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x0120, type=4
[  254.864343] rt2x00lib_rxdone_read_signal: 27 callbacks suppressed
[  254.864369] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0072, type=4
[  254.913025] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0002, signal=0x006b, type=4
[  254.929122] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0010, type=4
[  255.079618] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0024, type=4
[  255.102729] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0000, type=4
[  255.132881] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0010, type=4
[  255.220453] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0002, signal=0x0078, type=4
[  255.236459] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0001, signal=0x0120, type=4
[  255.252539] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0002, signal=0x0078, type=4
[  255.268678] ieee80211 phy0: rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0077, type=4
[  255.362987] rt2x00lib_rxdone: 75 callbacks suppressed
[  255.363009] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  255.386251] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  255.412947] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  255.432490] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  255.508218] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4074 max 3840
[  255.520688] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  255.540132] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 3890 max 3840
[  255.580842] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  255.588533] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 4095 max 3840
[  255.605518] ieee80211 phy0: rt2x00lib_rxdone: Error - Wrong frame size 0 max 3840
[  256.759235] rt2x00lib_rxdone_read_signal: 87 callbacks suppressed
...
...
...

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.

15.04.20213741ToolchainBug ReportVery LowLowBus error on musl tzset TrunkUnconfirmed Task Description

toolchain/musl/patches/110-read_timezone_from_fs.patch - Adds support for reading timezone from /etc/TZ.
It does mmap of the file. There is a possible race condition here. If /etc/TZ is truncated between mmap and read, read can cause bus error (SIGBUS).

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,


10.04.20213734KernelBug ReportVery LowHighHuge memory leak on kernel 5.10 with vsftpd, minidlnaTrunkUnconfirmed Task Description

Device: Xiaomi Mi Router 3G
Linux version 5.10.28 (root@Vladdrako-PC) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 10.2.0 r16692-ec5eadde66) 10.2.0, GNU ld (GNU Binutils) 2.35.1) #0 SMP Sat Apr 10 04:38:37 2021
When minidlna tried to scan my HDDs, after a minute I have 0 RAM. Same with vsftpd when I accessing files on HDDs. Kernel 5.4 works fine.

root@MI-R3G:~# free
              total        used        free      shared  buff/cache   available
Mem:         250096       98148       77212         568       74736       85924
Swap:        250092       33432      216660
root@MI-R3G:~# free
              total        used        free      shared  buff/cache   available
Mem:         250096       96076       69912         568       84108       88024
Swap:        250092       33432      216660
root@MI-R3G:~# free
              total        used        free      shared  buff/cache   available
Mem:         250096      203124       27908         404       19064        3400
Swap:        250092      113380      136712

root@MI-R3G:~# lsusb -v -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-mtk/1p, 5000M
    ID 1d6b:0003
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci-mtk/2p, 480M
    ID 1d6b:0002
    |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
        ID 05e3:0610
        |__ Port 1: Dev 3, If 0, Class=, Driver=usb-storage, 480M
            ID 152d:0579
        |__ Port 2: Dev 4, If 0, Class=, Driver=usb-storage, 480M
            ID 152d:0579
        |__ Port 3: Dev 5, If 0, Class=, Driver=usb-storage, 480M
            ID 8564:1000
        |__ Port 4: Dev 7, If 0, Class=, Driver=usbfs, 1.5M
            ID 0d9f:0004
root@MI-R3G:~# lsusb
Bus 001 Device 004: ID 152d:0579 JMICRON JMS579
Bus 001 Device 007: ID 0d9f:0004 POWERCOM Co.,LTD HID UPS Battery
Bus 002 Device 001: ID 1d6b:0003 Linux 5.10.28 xhci-hcd xHCI Host Controller
Bus 001 Device 003: ID 152d:0579 JMICRON JMS579
Bus 001 Device 005: ID 8564:1000 JetFlash Mass Storage Device
Bus 001 Device 002: ID 05e3:0610 GenesysLogic USB2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux 5.10.28 xhci-hcd xHCI Host Controller
09.04.20213733KernelBug ReportVery LowHighpacket loss, link loss, bad rx status / Multihomed box ...openwrt-19.07Unconfirmed Task Description

- Device problem occurs on

Turris Omnia 2020

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

OpenWrt 19.07.7 a5672f6b96f393145070ad17c8eb1d15ef49ad2e

- Problem description:

Network setup is multihomed with configured onboard WAN (eth2) device and Huawei E3372 (eth3) device and both distinct gateways and metrics.
As soon I start pinging from eth3 beyond its gateway I observe packet loss, link loss and bad rx status crc error on eth2.


- Configuration:

Onboard WAN device eth2:

# dmesg  | grep eth2
[    4.473584] mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:01:14:fc
[   17.582029] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
[   17.591455] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
[   21.831900] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx

Huawei E3372 USB-Modem with recent firmware (22.328.62.00.1217) in HiLink mode

# lsusb | grep Huawei
Bus 004 Device 002: ID 12d1:14dc Huawei Technologies Co., Ltd. E33372 LTE/UMTS/GSM HiLink Modem/Networkcard

System with kmod-usb-net-cdc-ether registers successfully new network device eth3

# dmesg  | grep "CDC Ethernet Device"
[   12.553958] cdc_ether 4-1:1.0 eth3: register 'cdc_ether' at usb-f10f8000.usb3-1, CDC Ethernet Device, 0c:5b:8f:27:9a:64

Network configuration for eth2 and eth3

# ip addr show eth2
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 532
    link/ether d8:58:d7:01:14:fc brd ff:ff:ff:ff:ff:ff
    inet xxx.xxx.xxx.xxx/29 brd xxx.xxx.xxx.xxx scope global eth2
       valid_lft forever preferred_lft forever
# ip addr show eth3
14: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether 0c:5b:8f:27:9a:64 brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.100/24 brd 192.168.8.255 scope global eth3
       valid_lft forever preferred_lft forever
# route -n | egrep "Destination|eth"
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         xxx.xxx.xxx.xxx 0.0.0.0         UG    10     0        0 eth2
0.0.0.0         192.168.8.1     0.0.0.0         UG    20     0        0 eth3
192.168.8.0     0.0.0.0         255.255.255.0   U     20     0        0 eth3
xxx.xxx.xxx.xxx 0.0.0.0         255.255.255.248 U     10     0        0 eth2

- Steps to reproduce

1. Produce traffic originating from eth3 with destination beyond its gateway:
(pinging the gateway from eth3 will not produce the error)

# ping -I eth3 -i 0.5 -q 1.1.1.1

2. From different terminal window start pinging from eth2 and observe packet loss

# ping -I eth2 -c 20 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from xxx.xxx.xxx.xxx eth2: 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=119 time=2.13 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=119 time=2.15 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=119 time=2.12 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=119 time=2.12 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=119 time=2.11 ms
64 bytes from 8.8.8.8: icmp_req=13 ttl=119 time=2.13 ms
64 bytes from 8.8.8.8: icmp_req=14 ttl=119 time=2.17 ms
64 bytes from 8.8.8.8: icmp_req=15 ttl=119 time=2.13 ms
64 bytes from 8.8.8.8: icmp_req=16 ttl=119 time=2.10 ms
64 bytes from 8.8.8.8: icmp_req=17 ttl=119 time=2.11 ms
64 bytes from 8.8.8.8: icmp_req=18 ttl=119 time=2.12 ms
64 bytes from 8.8.8.8: icmp_req=19 ttl=119 time=2.11 ms
64 bytes from 8.8.8.8: icmp_req=20 ttl=119 time=2.10 ms

--- 8.8.8.8 ping statistics ---
20 packets transmitted, 13 received, 35% packet loss, time 19364ms
rtt min/avg/max/mdev = 2.104/2.129/2.177/0.040 ms

3. Check kernel ring buffer for related entries

# dmesg
[  540.372989] mvneta f1034000.ethernet eth2: Link is Down
[  542.449648] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx
[  605.886917] mvneta f1034000.ethernet eth2: Link is Down
[  607.963595] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control rx/tx
[ 1164.426903] device eth2 entered promiscuous mode
[ 1166.118663] device eth2 left promiscuous mode
[ 1175.666308] device eth2 entered promiscuous mode
[ 1194.086756] mvneta f1034000.ethernet eth2: bad rx status 0c410000 (crc error), size=391
[ 1195.740476] mvneta f1034000.ethernet eth2: bad rx status 0c410000 (crc error), size=94
[ 1196.963670] mvneta f1034000.ethernet eth2: bad rx status 0c410000 (crc error), size=82
[ 1197.536843] mvneta f1034000.ethernet eth2: bad rx status 0c410000 (crc error), size=157
[ 1199.641764] mvneta f1034000.ethernet eth2: bad rx status 0c410000 (crc error), size=81
[ 1204.552005] mvneta f1034000.ethernet eth2: bad rx status 0c410000 (crc error), size=298
[ 1204.683304] mvneta f1034000.ethernet eth2: bad rx status 0c410000 (crc error), size=156
[ 1237.241446] device eth2 left promiscuous mode
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


04.04.20213722KernelBug ReportVery LowLowSoftware flow offloading breaks ECMP routingopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

 x86_64 Router

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

 OpenWrt 19.07.7 r11306-c4a6851c72, Linux 4.14.221 #0 SMP Mon Feb 15 15:22:37 2021 x86_64 GNU/Linux

- Steps to reproduce

Hey guys,

I met this issue when I was using ECMP (Equal Cost Multi-Path) routing with software flow offload enabled.

Suppose we have topology:

LAN 1 (192.168.1.0/24) ←—> (eth1: 192.168.1.1/24) OpenWRT (eth2: 192.168.2.1/24) ←—> (192.168.2.51-53/24) Other routers ←—> (192.168.150.0/24) LAN 2

1. Add ECMP routes:

$ ip route add 192.168.150.0/24 nexthop via 192.168.2.51 dev eth2 \
                                nexthop via 192.168.2.52 dev eth2 \
                                nexthop via 192.168.2.53 dev eth2

$ ip route
192.168.150.0/24 
	nexthop via 192.168.2.51 dev eth2 weight 1 
	nexthop via 192.168.2.52 dev eth2 weight 1 
	nexthop via 192.168.2.53 dev eth2 weight 1 

2. Setting multipatch hash policy:

sysctl net.ipv4.fib_multipath_hash_policy=1

3. Initiate TCP connections from LAN 1 (192.168.1.0/24) to LAN 2 (192.168.150.0/24) should succeed. Connections are balanced over 3 next hop routers (192.168.2.51-53).
4. Enable software flow offloading on LuCI.
5. Open a TCP connection from LAN 1 (192.168.1.0/24) to LAN 2 (192.168.150.0/24) will likely be broken because each packet for a single TCP connection could use a different next hop router to get to the destination.

I’m not sure if this is an OpenWRT issue or upstream kernel issue. Any help would be greatly appreciated.

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

02.04.20213719DocumentationBug ReportVery LowLowOpenwrt image builder instructions for FILES_REMOVE par...openwrt-19.07Unconfirmed Task Description

I’m attempting to use the x86 image builder for 19.07.7
https://downloads.openwrt.org/releases/19.07.7/targets/x86/64/openwrt-imagebuilder-19.07.7-x86-64.Linux-x86_64.tar.xz

There are some instructions in the documentation at:
https://openwrt.org/docs/guide-user/additional-software/imagebuilder

They say to patch the makefile:

 ifneq ($(USER_FILES),)
 	$(MAKE) copy_files
 endif
+
+ifneq ($(FILES_REMOVE),)
+	@echo
+	@echo Remove useless files
+
+	while read filename; do				\
+	    rm -rfv "$(TARGET_DIR)$$filename";	\
+	done < $(FILES_REMOVE);
+endif
+
 	$(MAKE) package_postinst
 	$(MAKE) build_image

But the Makefile layout seems to have changed since the instructions were written so it isn’t clear where to add this.

This is a really handy feature, so I hope the developers will eventually include this to avoid the need to patch the makefile.


01.04.20213717KernelBug ReportVery LowCriticalWRT1900ACS LAN Switch speed on kernel 5.4TrunkUnconfirmed Task Description

Dear, I ‘ve found an issue with DSA and kernel 5.4.
I’m on 21.02 SNAPSHOT.
My upload speed on WAN is only 10 mbps when a device with LAN connection is linked to 10mbps.
When a device 100mbps is connected to switch all speed is 100mbps not 1 gbps
It seems that the upload speed follow the lowest lan speed...

First test is with 10mbps connection on LAN3. –> Test was done from LAN1 to router.
Second test is with a LAN2 device conneted with 100mbps. –> Test was done from LAN1 to router

PS C:\Users\Andrea\Downloads\iperf-3.1.3-win64> .\iperf3.exe -c 192.168.181.1
Connecting to host 192.168.181.1, port 5201
[  4] local 192.168.181.159 port 50593 connected to 192.168.181.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.01   sec   384 KBytes  3.12 Mbits/sec
[  4]   1.01-2.01   sec   640 KBytes  5.26 Mbits/sec
[  4]   2.01-3.01   sec  1.12 MBytes  9.35 Mbits/sec
[  4]   3.01-4.01   sec  1.12 MBytes  9.52 Mbits/sec
[  4]   4.01-5.01   sec  1.12 MBytes  9.41 Mbits/sec
[  4]   5.01-6.00   sec  1.12 MBytes  9.50 Mbits/sec
[  4]   6.00-7.00   sec  1.12 MBytes  9.46 Mbits/sec
[  4]   7.00-8.00   sec  1.12 MBytes  9.41 Mbits/sec
[  4]   8.00-9.01   sec  1.12 MBytes  9.40 Mbits/sec
[  4]   9.01-10.01  sec  1.12 MBytes  9.44 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.01  sec  10.0 MBytes  8.38 Mbits/sec                  sender
[  4]   0.00-10.01  sec  9.81 MBytes  8.23 Mbits/sec                  receiver

iperf Done.
PS C:\Users\Andrea\Downloads\iperf-3.1.3-win64> .\iperf3.exe -c 192.168.181.1 -R
Connecting to host 192.168.181.1, port 5201
Reverse mode, remote host 192.168.181.1 is sending
[  4] local 192.168.181.159 port 50611 connected to 192.168.181.1 port 5201
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  95.6 MBytes   802 Mbits/sec
[  4]   1.00-2.00   sec  97.9 MBytes   821 Mbits/sec
[  4]   2.00-3.00   sec   101 MBytes   847 Mbits/sec
[  4]   3.00-4.00   sec   101 MBytes   850 Mbits/sec
[  4]   4.00-5.00   sec   105 MBytes   884 Mbits/sec
[  4]   5.00-6.00   sec  92.3 MBytes   774 Mbits/sec
[  4]   6.00-7.00   sec   105 MBytes   877 Mbits/sec
[  4]   7.00-8.00   sec   102 MBytes   849 Mbits/sec
[  4]   8.00-9.00   sec  99.4 MBytes   836 Mbits/sec
[  4]   9.00-10.00  sec   107 MBytes   894 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1006 MBytes   844 Mbits/sec   23             sender
[  4]   0.00-10.00  sec  1006 MBytes   844 Mbits/sec                  receiver

This new test is with latest 19.07 (previous kernel no dsa)

BusyBox v1.30.1 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 19.07-SNAPSHOT, r11328-81266d9001
 -----------------------------------------------------
root@WRT1900ACS:~# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.181.159, port 48454
[  5] local 192.168.181.1 port 5201 connected to 192.168.181.159 port 48456
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   108 MBytes   905 Mbits/sec                  
[  5]   1.00-2.00   sec   109 MBytes   915 Mbits/sec                  
[  5]   2.00-3.00   sec   109 MBytes   914 Mbits/sec                  
[  5]   3.00-4.00   sec   107 MBytes   900 Mbits/sec                  
[  5]   4.00-5.00   sec   108 MBytes   907 Mbits/sec                  
[  5]   5.00-6.00   sec   109 MBytes   912 Mbits/sec                  
[  5]   6.00-7.00   sec   107 MBytes   896 Mbits/sec                  
[  5]   7.00-8.00   sec   109 MBytes   917 Mbits/sec                  
[  5]   8.00-9.00   sec   108 MBytes   905 Mbits/sec                  
[  5]   9.00-10.00  sec   108 MBytes   903 Mbits/sec                  
[  5]  10.00-10.00  sec   293 KBytes   892 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  1.06 GBytes   907 Mbits/sec 

I also noticed that with the latest version the switch LEDs flash all together and not only follow where there is communication, but I don’t think this is a problem.

Is this speed issue a bug or I do something wrong? I don’t make any changes to network config from standard. Only changed IP from 192.168.1.1 to 192.168.181.1.

31.03.20213714PackagesBug ReportVery LowHighSlow download speed using Kmod-usb-net-RTL8152openwrt-19.07Unconfirmed Task Description

Problem occurs with TP-Link u300 USB gigalan device chipset RTL8152 connected to usb 2.0 (not tested on 3.0)
too slow download speed on trunk compiled version and 19.07.7 stable to. Upload speed working as expected.
Working fine on 19.07.3

OpenWrt Version 19.07.7 / Trunk

- Steps to reproduce

install last trunk or 19.07.7 problem occurs, going back to 19.07.3 solves the problem
Package Kmod-usb-net-RTL8152

 


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
```

 


Showing tasks 301 - 350 of 1427 Page 7 of 29<<First - 5 - 6 - 7 - 8 - 9 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing