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.

OpenedIDCategoryTask TypePrioritySeveritySummaryReported In  descStatus
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..


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.

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.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.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”

 


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.

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.

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.

 


16.03.20213686Base systemBug ReportVery LowCriticalBelkin F9K1115 v2 - boot loop with 21.02 snapshotopenwrt-21.02Unconfirmed Task Description

Boot loop, no communication with the router after upgrade to 21.02 snapshot (tested r15866).

Upgrade from Belkin web UI (factory image) is not working.

Probably migration to the new ath79 architecture is not correct:
- https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=563ece8a85dad24e8c3ce55af51938a4d37405f0 - https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b403a6e1241c00f509b201ec2ac8ca5f29e1ffd1

15.05.20203099KernelBug ReportVery LowCriticalipq806x: kernel 5.4 crash related to CPU frequency scal...openwrt-21.02New Task Description

Linux kernel experiences an oops from time to time
- Device: TP-Link Archer C2600
- Kernel Version: 5.4.40
- OpenWRT Version: OpenWrt SNAPSHOT, r13224+16-2308644b0c
- Steps to reproduce: Simply wait. After an unknown amount of time the kernels crashes leading to a reboot.

 


02.01.20224217Base systemBug ReportVery LowLowImage check failes for ar71xx to ath79 on WNDR3700v4openwrt-19.07Unconfirmed Task Description

Image check fails if trying to upgrade from OpenWrt 19.07.8 r11364-ef56c85848 / LuCI openwrt-19.07 branch git-21.189.23240-7b931da to the new ath79 based builds.

Model: NETGEAR WNDR3700v4
Architecture: Atheros AR9344 rev 2

 

Reproducible with sysupgrade from either:

https://firmware-selector.openwrt.org/?version=21.02.0&target=ath79%2Fnand&id=netgear_wndr3700-v4 https://firmware-selector.openwrt.org/?version=21.02.1&target=ath79%2Fnand&id=netgear_wndr3700-v4

Error says:

Device wndr3700v4 not supported by this image Supported devices: netgear,wndr3700-v4 Invalid sysupgrade file. Image check failed.

16.10.20214088ToolchainBug ReportVery LowCriticalmake clean required for changes in $BUILDROOT/files/ to...openwrt-19.07Unconfirmed Task Description

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

 

It isn’t and shouldn’t need to be documented as it should automatically update files in files/ when make is ran.

I assume this is a hearing thing and some crazy people who don’t think expect `make clean` or something?

I don’t know why, but this shouldn’t be this way.

04.10.20214062Base systemBug ReportVery LowHighwireguard fails to route to non-VPN addresses at far-en...openwrt-19.07Unconfirmed Task Description

Hardware : Ubiquiti Routerstation Pro
Software : OpenWrt 19.07.6, r11278-8055e38794
Updated : 2021-10-03

Problem does not occur with an OpenVPN tunnel providing the same functionality.

Problem occurs with the following combination :

1 : Wireguard tunnel from RSPro gateway (device wgc21) to a CentOS 7 server (device wg21) which uses the 2 non-public DNS servers in the data centre that it’s located in.

2 : RSPro networking DNS settings are the 2 data centre server addresses.

3 : The RSPro has routes to those DNS servers via dev wgc21

4 : RSPro iptables MASQUERADEs packets going out interface wgc21

On the RSPro’s local network, doing “$ host foo.com” gets a REFUSED reply. Browsers report failure to resolve.

On a local machine, a Wireshark remote capture on the RSPro’s wgc21 interface shows the DNS request packets (with DST=data_centre_dns_server), and a remote capture on the server’s wg21 interface doesn’t show them.

ssh sessions from local machines via the RSPro to the server’s wg21 address succeed.

How to reproduce : As above.

Workaround :

RSPro networking DNS addresses changed to 2 addresses on the wg21 network, and on the remote server two iptables PREROUTING rules added that DNAT those 2 addresses to the data centre DNS addresses.

09.09.20214021PackagesBug ReportVery LowLowppp: uses weird defaults for "keepalive", inconsistent ...openwrt-19.07Unconfirmed Task Description

By default, luci PPPoE (and probably other PPP-based) interface page doesn’t set any value for `network.<iface>.keepalive`, so in the absence of that /lib/netifd/proto/ppp.sh
sets values lcp-echo-interval=1 and lcp-echo-failure=5. First, every 1 second is too frequent (which can lead to connectivity issues, as said in FS#2819), next, they don’t correspond to the defaults displayed in luci (`0` for “LCP echo failure threshold” and `5` for “LCP echo interval”), and worse of all, they are impossible to be disabled by using luci, as any attempt to set “LCP echo failure threshold” to 0 makes luci to just delete network.<iface>.keepalive with the aforementioned consequences. The only workaround is to set “keepalive” through uci command line.

06.09.20214011Base systemBug ReportVery LowHighTCP queries to dnsmasq can cause OOM and DoS attackopenwrt-19.07Unconfirmed Task Description

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

Use a tool like netcat to open many (i.e 20+) TCP connections to port 53, simulating TCP dns queries
Observe how dnsmasq forks for each connection
Observe how at some point enough dnsmasq children are running that the kernel starts OOMing

This is a quick/easy demonstration on how simply an OpenWRT router can be DoS attacked.

There is a hard coded MAX_PROCS which defaults to 20. This clearly is too high for resource constrained systems like OpenWRT routers.

There is a discussion of this problem on the dnsmasq ML @ https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q1/014907.html which includes a patch to make MAX_PROCS a run-time tunable. This could be used by OpenWRT to scale up/down the MAX_PROCS value based on the size of system it’s running on.

It could/should be user-overridable in case he/she knows better what the value should be than any attempt by OpenWRT to scale on a given router.

 


05.09.20214007Base systemBug ReportVery LowLowOpenWRT and Netac Z9 portable SSD: disk need manual rec...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on Newifi D2 and Netac Z9 128GB USB3.2 portable SSD
- Software versions of OpenWrt/LEDE release, packages, etc. OpenWRT snapshot 19.07.08 (LuCI Master (git-21.226.86205-376af36) / OpenWrt SNAPSHOT r17471-b6cbbbb6ef )
- Steps to reproduce

Install:
root@OpenWrt:~# opkg list-installed | grep usb
kmod-usb-core - 5.4.143-1
kmod-usb-ehci - 5.4.143-1
kmod-usb-ledtrig-usbport - 5.4.143-1
kmod-usb-ohci - 5.4.143-1
kmod-usb-ohci-pci - 5.4.143-1
kmod-usb-storage - 5.4.143-1
kmod-usb-storage-extras - 5.4.143-1
kmod-usb-storage-uas - 5.4.143-1
kmod-usb-uhci - 5.4.143-1
kmod-usb-xhci-hcd - 5.4.143-1
kmod-usb-xhci-mtk - 5.4.143-1
kmod-usb2 - 5.4.143-1
kmod-usb2-pci - 5.4.143-1
libusb-1.0-0 - 1.0.24-4
libusb-compat4 - 0.1.7-2
usb-modeswitch - 2017-12-19-f40f84c2-2
reboot.

Connect portable SSD to USB port. SSD is working fine.
[ 62.313822] sd 0:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119 GiB)
[ 62.321654] sd 0:0:0:0: [sda] Write Protect is off
[ 62.326429] sd 0:0:0:0: [sda] Mode Sense: 47 00 00 08
[ 62.326752] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA
[ 62.343033] sda: sda1 sda2 sda3
[ 62.350420] sd 0:0:0:0: [sda] Attached SCSI disk
[ 63.881045] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts:

Reboot device
SSD is found, but not respondig till manual reconnection.

root@OpenWrt:~# dmesg | grep sd
[ 16.043325] sd 0:0:0:0: [sda] Unit Not Ready [ 16.047611] sd 0:0:0:0: [sda] Sense Key : 0×5 [current]
[ 16.053015] sd 0:0:0:0: [sda] ASC=0×20 ASCQ=0×0 [ 16.059685] sd 0:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=0×00 driverbyte=0×08 [ 16.068317] sd 0:0:0:0: [sda] Sense Key : 0×5 [current]
[ 16.073712] sd 0:0:0:0: [sda] ASC=0×20 ASCQ=0×0 [ 16.078380] sd 0:0:0:0: [sda] 0 512-byte logical blocks: (0 B/0 B) [ 16.084586] sd 0:0:0:0: [sda] 0-byte physical blocks
[ 16.090260] sd 0:0:0:0: [sda] Write Protect is off
[ 16.095083] sd 0:0:0:0: [sda] Mode Sense: 00 00 00 00
[ 16.095607] sd 0:0:0:0: [sda] Asking for cache data failed
[ 16.101184] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 16.110377] sd 0:0:0:0: [sda] Unit Not Ready
[ 16.114695] sd 0:0:0:0: [sda] Sense Key : 0×5 [current]
[ 16.120068] sd 0:0:0:0: [sda] ASC=0×20 ASCQ=0×0 [ 16.126769] sd 0:0:0:0: [sda] Read Capacity(10) failed: Result: hostbyte=0×00 driverbyte=0×08 [ 16.135355] sd 0:0:0:0: [sda] Sense Key : 0×5 [current]
[ 16.140717] sd 0:0:0:0: [sda] ASC=0×20 ASCQ=0×0 [ 16.146232] sd 0:0:0:0: [sda] Attached SCSI disk
[ 17.279150] usbcore: registered new interface driver ums-isd200
[ 17.302647] usbcore: registered new interface driver ums-sddr09
[ 17.310530] usbcore: registered new interface driver ums-sddr55

Only /dev/sda now is present and this device is not block device and cant be mounted.
After physical reconnection of SSD it is working again, /dev/sda1, /dev/sda2 etc. are visible and mounted properly.
Any ideas how to fix it?

10.08.20213972KernelBug ReportVery LowMediumdevolo WiFi pro 1200e: 803x_aneg_done: SGMII link is no...openwrt-19.07Unconfirmed Task Description

My devolo WiFi pro 1200e with uptodate 19.07 has sometimes connectivity issues on the ethernet ports.
Usually the device works just fine (only a Wifi-Repeater and Wifi-to-eth-bridge).
Sometimes it is not possible to use one or both eth ports.

The logread just spams the following line every seconds:

kern.warn kernel: 803x_aneg_done: SGMII link is not ok

Since this was the first message in the log, I dont know if there are previous errors which help find the problem.
Restarting the network does not help, only rebooting over ssh solves the issue.

01.08.20213960Base systemBug ReportVery LowLowXiaomi MiWifi Nano 3C/ R3C/ R3L dts mismatch causes the...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
Xiaomi MiWifi R3L
- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt v19.07.7
- Steps to reproduce
1) From the Wiki at https://openwrt.org/toh/xiaomi/mir3c flash the sysupgrade image: http://downloads.openwrt.org/releases/19.07.7/targets/ramips/mt76x8/openwrt-19.07.7-ramips-mt76x8-miwifi-nano-squashfs-sysupgrade.bin 2) Device does not boot anymore

The problem is the dts MIWIFI-NANO.dts defines a incompatible layout of the flash, which ends up flashing OpenWrt to the wrong part of the flash.
The OEM partition layout is:

[    1.510000] 0x000000000000-0x000001000000 : "ALL"
[    1.510000] 0x000000000000-0x000000030000 : "Bootloader"
[    1.520000] 0x000000030000-0x000000040000 : "Config"
[    1.530000] 0x000000040000-0x000000050000 : "Bdata"
[    1.530000] 0x000000050000-0x000000060000 : "Factory"
[    1.540000] 0x000000060000-0x000000070000 : "crash"
[    1.550000] 0x000000070000-0x000000080000 : "cfg_bak"
[    1.550000] 0x000000080000-0x000000140000 : "overlay"
[    1.560000] 0x000000140000-0x0000008a0000 : "OS1"
[    1.610000] 0x0000002a0000-0x0000008a0000 : "rootfs"
[    1.610000] 0x0000008a0000-0x000001000000 : "OS2"

with emphasis on OS1 and OS2.

However MIWIFI-NANO.dts defines firmware partition as:

                        partition@50000 {
                                compatible = "denx,uimage";
                                label = "firmware";
                                reg = <0x50000 0xfb0000>;

                        };

The bootloader will boot either OS1 or OS2 → we get an unbootable device.

Now we have two similar devices, MiWifi Nano R1 and R3L/R3C with different partition layout but the wiki proposes to flash the same image: https://openwrt.org/toh/xiaomi/mir3c https://openwrt.org/toh/xiaomi/miwifi_nano I personally still use my R3L so I would propose we add a new device type that could cover R3L.


28.07.20213954KernelBuild FailureVery LowVery LowSATA Port Multiplier supportopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:

Impossible to see all my hard drive (I only see 4):

  • Marvell Technology Group Ltd. 88SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller (rev 11)

Could you enable this option during kernel compilation please:

CONFIG_SATA_PMP=y

like in this target : mvebu: enable SATA port multiplier support

Thanks in advance, I’m stuck in mounting my router because of this

Cordially

 


21.07.20213946PackagesBug ReportVery LowCritical lldpd needs update to fix CVE-2020-27827openwrt-19.07Unconfirmed Task Description

the current verion 1.0.3 on 19.07 needs a update to fix CVE-2020-27827

read https://github.com/lldpd/lldpd/releases

10.07.20213925Base systemBug ReportVery LowCriticalwgt634u: jffs2 Filesystem overwrites the bootloader par...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on WGT643u
- Software versions of OpenWrt/LEDE OpenWrt 19.07
Steps to reproduce:
- after fresh install I installed some bigger packages then the system hangs
- a reboot with power off/on not working
- The serial/UART/Terminal of the box shows the bootloader stops because the param partition at the end of the flash was overwritten and the checksum was wrong

It seems the partition size of the jffs2 partition is wrong.

Linux side:
root@OpenWrt:/# cat /proc/partitions
major minor #blocks name

                                                                              
31        0        640 mtdblock0                                              
31        1       7424 mtdblock1                                              
31        2          2 mtdblock2                                              
31        3       1324 mtdblock3                                              
31        4       6097 mtdblock4                                              
31        5       3456 mtdblock5                                              
31        6        128 mtdblock6 -->param partition

root@OpenWrt:/# cat /proc/mtd
dev: size erasesize name
mtd0: 000a0000 00020000 “boot”
mtd1: 00740000 00020000 “firmware”
mtd2: 00000928 00000928 “loader”
mtd3: 0014b2bc 00020000 “linux”
mtd4: 005f4400 00020000 “rootfs”
mtd5: 00360000 00020000 “rootfs_data”
mtd6: 00020000 00020000 “nvram” –>bootloader param partition == 131072 bytes (Bootloader says 8KB...)

root@OpenWrt:/# mount
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /tmp/root type tmpfs (rw,noatime,mode=755)
overlayfs:/tmp/root on / type overlay (rw,noatime,lowerdir=/,upperdir=/tmp/root/upper,workdir=/tmp/root/wo)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)

UART/Terminal shows after boot:
[ 127.964107] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0×00000000: 0x0c3b instead
[ 128.053636] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0×00000004: 0x58cd instead
[ 128.063208] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0×00000008: 0x54cc instead
[ 128.193636] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0x0000000c: 0×6859 instead
[ 128.203202] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0×00000010: 0x916a instead
[ 128.283363] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0×00000014: 0x9d93 instead
[ 128.303639] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0×00000018: 0x6b25 instead
[ 128.313209] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0x0000001c: 0x54bb instead
[ 128.413768] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0×00000020: 0xeacc instead
[ 128.423620] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0×1985 not found at 0×00000024: 0x8dc5 instead
[ 128.433144] jffs2: Further such events for this erase block will not be printed
[ 128.829317] jffs2: Empty flash at 0×00010004 ends at 0×00011000
[ 128.884133] jffs2: Empty flash at 0×00011004 ends at 0×00012000
[ 128.891154] jffs2: Empty flash at 0×00012004 ends at 0×00014000
[ 128.999749] jffs2_scan_eraseblock(): End of filesystem marker found at 0×20000
[ 129.133686] jffs2: Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
[ 129.142209] jffs2: empty_blocks 26, bad_blocks 0, c→nr_blocks 27

                                            

root@OpenWrt:/# reboot
root@OpenWrt:/# ^C

See on the UART/Terminal while power on and press CTRL-C long:

                                                                              

CFE version 1.0.34 for BCM95365R (32bit,SP,LE)
Build Date: Tue Feb 24 03:21:41 CST 2004 (root@jackylinux)
Copyright (C) 2000,2001,2002 Broadcom Corporation.

                                                                              

Add MAC client version(DNI).
Initializing Arena.
Initializing Devices.
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller
CPU type 0×29007: 200MHz
Total memory: 0×2000000 bytes (32MB)

                                                                              

Total memory used by CFE: 0x81BB1280 - 0×82000000 (4517248)
Initialized Data: 0x81BB1280 - 0x81BB3E90 (11280)
BSS Area: 0x81BB3E90 - 0x81BB45D0 (1856)
Local Heap: 0x81BB45D0 - 0x81FB45D0 (4194304)
Stack Area: 0x81FB45D0 - 0x81FB65D0 (8192)
Text (code) segment: 0x81FB65E0 - 0x81FFFFB0 (301520)
Boot area (physical): 0x01B70000 - 0x01BB0000
Relocation Factor: I:E23B65E0 - D:01BB0280

                                                                              

configure vlans
*
* VLAN Driver initial
***
Process LAN port(2-5) vlan Architecture...
SUCCESS: trying to create VLAN 0 for switch
SUCCESS: trying to add LAN port

                                                                              

Process WAN port(2-5) vlan Architecture...
SUCCESS: trying to create VLAN 0 for switch
SUCCESS: trying to add WAN port
SUCCESS: enable ports success
configure vlans...done
Automatic startup canceled via Ctrl-C

                           

CFE> show devices
Device Name Description
——————- ———————————————————
uart0 NS16550 UART at 0×18000300
uart1 NS16550 UART at 0×18000400
flash0.boot New CFI flash at 1C000000 offset 00000000 size 384KB
flash0.config New CFI flash at 1C000000 offset 00060000 size 128KB
flash0.os New CFI flash at 1C000000 offset 00080000 size 7672KB
flash0.nvram New CFI flash at 1C000000 offset 007FE000 size 8KB —–>param partition for bootloader

please fix the jffs2 partition size!

05.07.20213914Base systemBug ReportVery LowLowFailsafe button is inverted under TP-Link TL-WR842N/ND ...openwrt-19.07Unconfirmed Task Description

My 2 routers (TL-WR842v1, TL-WR842v2) were modded to have 64MB of RAM.
I also have TL-WR842v3 for reference.

This is great time to move from 17.01 to 19.07 (”refs/heads/openwrt-19.07” branch).
My build configuration is very simple: stock .config + Luci.
Config files are differ only on this line:

CONFIG_TARGET_ath79_generic_DEVICE_tplink_tl-wr842n-v1=y
CONFIG_TARGET_ath79_generic_DEVICE_tplink_tl-wr842n-v2=y
CONFIG_TARGET_ath79_generic_DEVICE_tplink_tl-wr842n-v3=y

Builds were made on ec76c365c1d60bf6a4f69b1ab3ce132f97f34dbb checkout (2021-06-14 - Koen Vandeputte - gitignore: add .ccache folder).

Boxes with hardware revisions v1 and v3 are working just fine.
But v2 almost always boots into failsafe mode :(
If I hold “wifi on/off” button v2 boots normal.
My wild guess: GPIO configuration is broken.

After ‘git bisect’ session I’ve found that following commit makes big difference:
2021-02-26 - Koen Vandeputte - kernel: bump 4.14 to 4.14.222 (b4a4d04b919b4a18a03e52a9e6bc18ddd924f554)
I’m not skilled enough to dig into kernel bisecting territory.

Before above commit router almost always boots normal.
After it router almost always boots into failsafe mode. But if I reboot it using reboot@SSH command it will boot just fine. So, power cycle ⇒ failsafe, reboot command ⇒ boots normal.

Looks like some sort of hardware initialization is made “too late” in boot process and querying GPIO state gives wrong readings.
That explains proper behavior after soft reboot.

19.06.20213888Base systemBug ReportVery LowLowArcher C7 v2: since moving to ath79, intermittent wifi ...openwrt-19.07Unconfirmed Task Description

As the summary says - since I upgraded from 19.07.1 to 19.07.7, and from ar71xx to ath79, I have sometimes (averaging once every few days now) experienced my wifi connection misbehaving (over the 5GHz; I haven’t tried staying on the 2.4 long enough to determine if it affects that too) from my laptop, the main client. When it occurs, sometimes there’s a period of high latency to LAN and WAN first, then either it recovers or my ability to talk to other hosts over the LAN or WAN dies like all my traffic is blackholing, but without my wireless disconnecting - I did not think to attempt pinging/other connection to the router, I will next time.

This state persists until I manually trigger a disconnect and reconnect on my client - I tried leaving it for a minute or two, it doesn’t seem to disconnect on its own or recover. So far, it’s worked normally again every time immediately after reconnecting.

I also didn’t have the only other convenient wifi client I use handy when this happened last (my Android phone); I’ll see if it’s affected at the same time next time this occurs, though since I’ve not noticed any issues with it, either it behaves differently or isn’t affected at all.

The laptop is Win10 x64, the wireless is Intel’s Wireless-AC 8265, driver version 20.70.21.2, and the driver hasn’t been updated since January, so it seems less likely to be at fault.

If you look at Sat Jun 19 06:44:09 in the log attached, you can see where I manually disconnected and reconnected - I’m reasonably confident I only did that once, but memory is inherently unreliable, so who knows.

If there’s any other debugging information I could usefully provide, please let me know.

09.06.20213862Base systemBug ReportVery LowLow[ATH79][19.07.7] unstable USB on Archer C7 v1/v2/v4openwrt-19.07Unconfirmed Task Description

Hi!

I have some problems with multiple host and usb devices, while using 19.07 release. I tried 19.07, 19.07.1, 19.07.3 and 19.07.7.
I tried three Archer C7 versions over the time, and different USB devices and even different overlay filesystems, but the symptoms are the same.
With overlayfs the devices losts it's USB storage after ~1-2 days, however without overlay it works up to 4 days. Unfortunately SSH or web access is mostly not possible after the device looses the USB device(9 out of 10).
I opened previously bug report for 1043v2, this device batch (MIPS and TP-Link) seem to be affected.

[263194.198081] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[263199.378038] usb 2-1: device descriptor read/64, error -145
[263214.737906] usb 2-1: device descriptor read/64, error -145
[263215.007920] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[263215.167912] usb 2-1: device descriptor read/64, error -71
[263215.447908] usb 2-1: device descriptor read/64, error -71
[263215.717902] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[263216.167896] usb 2-1: device not accepting address 2, error -71
[263216.317897] usb 2-1: reset high-speed USB device number 2 using ehci-platform
[263216.767886] usb 2-1: device not accepting address 2, error -71
[263216.774186] usb 2-1: USB disconnect, device number 2
[263216.807934] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[263216.816500] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 04 2b 26 b8 00 00 20 00
[263216.824449] print_req_error: I/O error, dev sda, sector 69936824
[263216.833972] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00
[263216.842578] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 04 2b 26 d8 00 00 20 00
[263216.850508] print_req_error: I/O error, dev sda, sector 69936856
[263217.035893] blk_partition_remap: fail for partition 3
[263217.084319] blk_partition_remap: fail for partition 3
[263217.089747] usb 2-1: new high-speed USB device number 3 using ehci-platform
[263217.220988] blk_partition_remap: fail for partition 3
[263217.226496] blk_partition_remap: fail for partition 3
[263217.335635] blk_partition_remap: fail for partition 3
[263217.378953] usb 2-1: device descriptor read/64, error -71
[263217.403255] blk_partition_remap: fail for partition 3
[263217.716297] usb 2-1: device descriptor read/64, error -71
[263217.766228] blk_partition_remap: fail for partition 3
[263217.900631] blk_partition_remap: fail for partition 3
[263217.939582] blk_partition_remap: fail for partition 3
[263217.945175] blk_partition_remap: fail for partition 3
[263217.987923] usb 2-1: new high-speed USB device number 4 using ehci-platform
[263218.157896] usb 2-1: device descriptor read/64, error -71
[263218.437883] usb 2-1: device descriptor read/64, error -71
[263218.558126] usb usb2-port1: attempt power cycle
[263219.267879] usb 2-1: new high-speed USB device number 5 using ehci-platform
[263219.717866] usb 2-1: device not accepting address 5, error -71
[263219.867910] usb 2-1: new high-speed USB device number 6 using ehci-platform
[263220.317873] usb 2-1: device not accepting address 6, error -71
[263220.324047] usb usb2-port1: unable to enumerate USB device
[304298.508857] blk_partition_remap: fail for partition 3
28.05.20213833Base systemBug ReportVery LowVery Lowrun ash's script over ssh often not executedopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
NAME=”OpenWrt” VERSION=”19.07.7” ID=”openwrt” ID_LIKE=”lede openwrt” PRETTY_NAME=”OpenWrt 19.07.7” VERSION_ID=”19.07.7” HOME_URL=”https://openwrt.org/” BUG_URL=”https://bugs.openwrt.org/” SUPPORT_URL=”https://forum.openwrt.org/” BUILD_ID=”r11306-c4a6851c72” OPENWRT_BOARD=”x86/64” OPENWRT_ARCH=”x86_64” OPENWRT_TAINTS=”” OPENWRT_DEVICE_MANUFACTURER=”OpenWrt” OPENWRT_DEVICE_MANUFACTURER_URL=”https://openwrt.org/” OPENWRT_DEVICE_PRODUCT=”Generic” OPENWRT_DEVICE_REVISION=”v0” OPENWRT_RELEASE=”OpenWrt 19.07.7 r11306-c4a6851c72” - Software versions of OpenWrt/LEDE release, packages, etc.

- Steps to reproduce
1:create file ‘/root/test’ with content:EOF set -x
echo tag1
sleep 100 &
echo tag2
EOF

2:run commandline:
ssh localhost ‘ash /root/test’

3:the output of this commandline is out of order
!!!!!AND!!!!!
the script command ‘sleep 100 &’ is often not executed

27.05.20213831PackagesBug ReportVery LowLowWPS push_button method works even when it's not specifi...openwrt-19.07Unconfirmed Task Description

System information:

root@OpenWrt:~# ubus call system board
{
	"kernel": "4.14.221",
	"hostname": "OpenWrt",
	"system": "MediaTek MT7621 ver:1 eco:3",
	"release": {
		"distribution": "OpenWrt",
		"version": "19.07.7",
		"revision": "r11306-c4a6851c72",
		"target": "ramips/mt7621",
		"description": "OpenWrt 19.07.7 r11306-c4a6851c72"
	}
}
root@OpenWrt:~# uci show wireless.default_radio0
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='OpenWrt'
wireless.default_radio0.key='********'
wireless.default_radio0.encryption='psk-mixed'
wireless.default_radio0.wps_label='1'
root@OpenWrt:~# cat /var/run/hostapd-phy0.conf 
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
hw_mode=g
beacon_int=100
channel=11



ieee80211n=1
ht_coex=0
ht_capab=[SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1]

interface=wlan0
ctrl_interface=/var/run/hostapd
ap_isolate=1
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
wpa_passphrase=********
auth_algs=1
wpa=3
wpa_pairwise=CCMP
eap_server=1
wps_state=2
device_type=6-0050F204-1
device_name=OpenWrt AP
manufacturer=www.openwrt.org
config_methods=label
wps_independent=1
ssid=OpenWrt
bridge=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=80:3f:5d:61:91:4b

Steps to reproduce:

  1. Install OpenWRT release 19.07.7 with full wpad and hostapd-utils for WPS support
  2. Enable label WPS configuration method:
    uci set wireless.default_radio0.wps_label=1; uci commit wireless; reload_config
  3. Push WPS button

Expected result: nothing happens.
Actual result: WPS PBC starts.

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

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

 

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

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

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


20.05.20213819Base systemBug ReportVery LowMediumopenwrt-keyring 2021-02-20-49283916-2 update conflicts ...openwrt-19.07Unconfirmed Task Description
# opkg upgrade openwrt-keyring
Upgrading openwrt-keyring on root from 2019-07-25-8080ef34-1 to 2021-02-20-49283916-2...
Collected errors:
 * check_data_file_clashes: Package openwrt-keyring wants to install file /etc/opkg/keys/f94b9dd6febac963
	But that file is already provided by package  * base-files
Downloading http://downloads.openwrt.org/releases/19.07.7/packages/mips_24kc/base/openwrt-keyring_2021-02-20-49283916-2_mips_24kc.ipk
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.

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

 


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

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


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

 


23.03.20213703Base systemBug ReportVery LowMediumCan't active Wirelessopenwrt-19.07Unconfirmed Task Description

- Device problem occurs on
Plusnet HomeHub
- Software versions of OpenWrt/LEDE release, packages, etc.
openwrt-19.07.7-lantiq-xrx200-bt_homehub-v5a-squashfs-sysupgrade.bin
- Steps to reproduce
Fresh installation, attempting to create a WAP, radio devices are always shown as inactive (see screenshot).

Have tried opkg update and logread reveals not very much:

Tue Mar 23 12:01:14 2021 daemon.info dnsmasq[1637]: read /etc/hosts - 4 addresses
Tue Mar 23 12:01:14 2021 daemon.info dnsmasq[1637]: read /tmp/hosts/odhcpd - 1 addresses
Tue Mar 23 12:01:14 2021 daemon.info dnsmasq[1637]: read /tmp/hosts/dhcp.cfg01411c - 2 addresses
Tue Mar 23 12:01:14 2021 daemon.info dnsmasq-dhcp[1637]: read /etc/ethers - 0 addresses
Tue Mar 23 12:01:15 2021 daemon.info dnsmasq-dhcp[1637]: DHCPREQUEST(br-lan) 192.168.0.109 50:dc:e7:2c:46:79
Tue Mar 23 12:01:15 2021 daemon.info dnsmasq-dhcp[1637]: DHCPACK(br-lan) 192.168.0.109 50:dc:e7:2c:46:79
Tue Mar 23 12:13:32 2021 authpriv.info dropbear[1901]: Child connection from 192.168.0.10:62496
Tue Mar 23 12:13:33 2021 authpriv.notice dropbear[1901]: Auth succeeded with blank password for ‘root’ from 192.168.0.10:62496




23.03.20213702KernelBug ReportVery LowVery LowRansmit queue 0 timed out on Netgear R6220openwrt-19.07Unconfirmed Task Description

Device: Netgear R6220
OpenWRT version: 19.07.7 r11306-c4a6851c72
User installed packages: mwan3
Steps to reproduce: unknown, spotted error stack in kernel logs, so I share them.

[22934.015218] ------------[ cut here ]------------
[22934.024448] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:320 0x8038d700
[22934.038516] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[22934.052393] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat ledtrig_usbport xt_set ip_set_list_set ip_set_hash_netportnet
[22934.193603]  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 leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd gpio_button_hotplug usbcore nls_base usb_common
[22934.277184] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.221 #0
[22934.289304] Stack : 00000000 00000000 00000000 87f65240 00000000 00000000 00000000 00000000
[22934.305940]         00000000 00000000 00000000 00000000 00000000 00000001 87c09d60 5326163c
[22934.322575]         87c09df8 00000000 00000000 00006358 00000038 8049e2b8 00000008 00000000
[22934.339205]         00000000 80550000 00043ac0 00000000 87c09d40 00000000 00000000 8050d500
[22934.355830]         8038d700 00000140 00000000 87f65240 00000000 802ae4c0 00000000 806b0000
[22934.372460]         ...
[22934.377324] Call Trace:
[22934.377402] [<8049e2b8>] 0x8049e2b8
[22934.389221] [<8038d700>] 0x8038d700
[22934.396160] [<802ae4c0>] 0x802ae4c0
[22934.403094] [<8000c1a0>] 0x8000c1a0
[22934.410030] [<8000c1a8>] 0x8000c1a8
[22934.416965] [<804870f4>] 0x804870f4
[22934.423891] [<80071e00>] 0x80071e00
[22934.430856] [<8002e798>] 0x8002e798
[22934.437794] [<8038d700>] 0x8038d700
[22934.444739] [<8002e820>] 0x8002e820
[22934.451679] [<8038d700>] 0x8038d700
[22934.458605] [<80099da0>] 0x80099da0
[22934.465544] [<8038d554>] 0x8038d554
[22934.472472] [<80088948>] 0x80088948
[22934.479418] [<80088c04>] 0x80088c04
[22934.486354] [<800794a8>] 0x800794a8
[22934.493285] [<804a50b8>] 0x804a50b8
[22934.500218] [<80033164>] 0x80033164
[22934.507148] [<8025b710>] 0x8025b710
[22934.514086] [<80007488>] 0x80007488
[22934.521012] 
[22934.524149] ---[ end trace f60c0fe92d06a467 ]---
[22934.533372] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
[22934.545708] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
[22934.557699] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=070d0000, max=0, ctx=183, dtx=183, fdx=182, next=183
[22934.578691] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=06060000, max=0, calc=1456, drx=1502
[22934.601287] mtk_soc_eth 1e100000.ethernet: 0x100 = 0x45600f0c, 0x10c = 0x80818
[22934.615760] mtk_soc_eth 1e100000.ethernet: reset pse
[22934.631131] mtk_soc_eth 1e100000.ethernet: PPE started
19.03.20213691Base systemBug ReportVery LowLowopkg_download_pkg: Package luci is not available from a...openwrt-19.07Unconfirmed Task Description

Software versions: openwrt-19.07.7-brcm63xx-generic-HG553-squashfs-cfe.bin
Device: Huawei EchoLife HG553

I flashed OpenWrt from vertion 18.06 to 19.07.7 while keeping the configuration.
LuCI stopped working.
When I tried to reinstall it, I saw this message:

# opkg install luci
Collected errors:
 * opkg_download_pkg: Package luci is not available from any configured src.
 * opkg_install_pkg: Failed to download luci. Perhaps you need to run 'opkg update'?
 * opkg_install_cmd: Cannot install package luci.

After flashing to 19.07.7 with clean configuration the problem was gone.

But it is still easily reproducible with:

# opkg update
# opkg install --force-reinstall luci
Removing package luci from root...
[...]
Collected errors:
 * opkg_download_pkg: Package luci is not available from any configured src.
 * opkg_install_pkg: Failed to download luci. Perhaps you need to run 'opkg update'?
 * opkg_install_cmd: Cannot install package luci.

and luci package stays broken after this (which should not happen).

16.03.20213685Base systemBug ReportVery LowLowaudio buzzy with 19.07.07openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on

TP-Link TL-WDR3600 v1
USB SoundBlaster
external sd on /mnt/sda1

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

OpenWrt 19.07.7 r11306-c4a6851c72 / LuCI openwrt-19.07 branch git-21.044.30835-34e0d65
# uname -a
Linux b2 4.14.221 #0 Mon Feb 15 15:22:37 2021 mips GNU/Linux
# opkg list | grep -e alsa -e audio -e mpd
alsa-lib - 1.1.8-1
alsa-utils - 1.1.7-1
kmod-usb-audio - 4.14.221-1
libmpdclient - 2.18-1
mpd-mini - 0.21.25-1

# alsactl init
Found hardware: “USB-Audio” “USB Mixer” “USB041e:3249” “” “” Hardware is initialized using a generic method

- Steps to reproduce

alsactl init
alsactl restore ...
start mpd
play song

in addition to the sound there is a choppy buzz. Workaround is to repeat the above.

Setup was fine before upgrade from (19.07.5)

15.03.20213683Base systemBug ReportVery LowLowjsonfilter yields unreliable resultsopenwrt-19.07Unconfirmed Task Description

- Device is an Arcadyan VGV7510KW22 (o2 Box 6431)
- Box software version is OpenWrt 19.07-SNAPSHOT, r11318-c64742a96e
- Problem shows up in package wireguard_tool which provides script wireguard_watchdog” which uses jsonfilter.
- Short steps to reproduce:

* Use attached file jinp1 as input and run this command:

  jsonfilter -a -e '@[@.proto="wireguard"].interface'  <jout1
  => nothing is output (empty output), which is incorrect

* Now use attached file jinp2, which is jinp1 with lines slighty reordered:

  jsonfilter -a -e '@[@.proto="wireguard"].interface'  <jout2
  => "wgvpn" is output, which is correct, this time.

- Background: Script wireguard_watchdog tries to identify the WireGuard network interfaces.

To this end it runs these commands:
<code>ubus -S call network.interface dump | jsonfilter -e '@.interface[@.up=true]' | jsonfilter -a -e '@[@.proto="wireguard"].interface'</code>
The second jsonfilter call in this line erroneously does not show a result.
 The attached files jinp1, jinp2 contain example input for the 2nd jsonfilter call


09.03.20213675Base systemBug ReportVery LowMediumgetaddrinfo prefers IPv6 and fails when there is no IPv...openwrt-19.07Unconfirmed Task Description

As stated in the summary, getaddrinfo prefers IPv6 and fails when there is no IPv6 connectivity which causes issues with some functionalities.
For instance, I opened this thread on the forum about collectd network plugin complaining of “getaddrinfo failed: System error” when using a hostname that is resolvable only in IPv4 or an IPv4 address.
IPv6 is deactivated on my entire network (on the router and on the hosts) and this seems to cause that error message.
This is happening on a Linksys WRT1900ACS with OpenWrt 19.07.2 and on a TP-Link Archer C7 v5 with OpenWrt 19.07.7
Apparently, the issue is still relevant even when you do not disable IPv6 specifically. vgaetera (on the forum) tested OpenWrt 19.07.7 x86_64 as a KVM/QEMU guest with mostly default configuration. So, IPv6 is enabled but IPv6 connectivity is missing and the issue persists.

I am not sure if it is also related to getaddrinfo but another issue is when I flash a device with OpenWRT and there is no IPv6 connectivity, I can’t use opkg at all. First I have to manually download full wget and install it and then opkg starts working.

For more details and troubleshooting about this getaddrinfo issue, check : https://forum.openwrt.org/t/collectd-network-plugin-getaddrinfo-failed-system-error/90546

Showing tasks 151 - 200 of 1430 Page 4 of 29<<First - 2 - 3 - 4 - 5 - 6 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing