OpenWrt/LEDE Project

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

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

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

OpenedIDCategoryTask TypePrioritySeveritySummaryReported In  descStatus
14.11.20181951KernelBug ReportVery LowCriticalbrcm63xx: Livebox: 4.14 kernel boot stuck at "random: c...openwrt-19.07New Task Description

The kernel 4.14 is unable to boot on the Inventel Livebox 1 (BCM6348 board with a redboot bootloader).

Steps to reproduce:

  • Intall the latest trunk version (i.e. r8455-042d68a) kernel 4.14

Sympthoms:

  1. It won’t detect the BogoMips CPU speed
  2. It stucks at “random: fast init done”, and apparently no more kernel messages
  3. But after a minute it spits the last message random: crng init done

Boot log:

965543210120123456+678ESA: 30:78:30:30:3a:30
WEP KEY : FFFFFFFFFFFFFFFFFFFFFFFFFF
Auto-negotiation timed-out
10 MB Half-Duplex (assumed)
Ethernet eth0: MAC address 30:78:30:30:3a:30
IP: 10.7.58.112, Default server: 10.7.58.114
Hardware version 0x90, mask=0x7E
Hardware version 0x10 (masked) BLUE5G.9 DV4210
Factory Settings Recovery Switch OFF

RedBoot(tm) bootstrap and debug environment [ROM]
unlocked release, eCos 2.0b1 - built 23:01:33, Jan 11 2013

Platform: Blue_5g (MIPS32 4Kc) 
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.

RAM: 0x80000000-0x84000000, [0x80435e50-0x83fe2000] available
FLASH: 0xbe400000 - 0xbec00000, 128 blocks of 0x00010000 bytes each.
== Executing boot script in 20.000 seconds - enter ^C twice to abort
RedBoot> fis load -b 0x80a00000 -d kernel
 -- Redboot version without crypt_verify -- 
Image loaded from 0x80a00000-0x80f55b2e
RedBoot> exec -c "noinitrd" 0x80a00000
Now booting linux kernel:
 Base address 0x8000fc00 Entry 0x80a00000
 Cmdline : noinitrd
changing Kseg0 coherency algorithm to write back...
enabling icache and dcache...

[    0.000000] Linux version 4.14.80 (buildbot@buildslave) (gcc version 7.3.0 (OpenWrt GCC 7.3.0 r8455-042d68a195)) #0 Tue Nov 13 20:40:30 2018
[    0.000000] Detected Broadcom 0x6348 CPU revision b0
[    0.000000] CPU frequency is 300 MHz
[    0.000000] 64MB of RAM installed
[    0.000000] board_livebox: flash address is: 0x1fc00000, forcing to: 0x1e400000
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 00029107 (Broadcom BMIPS3300)
[    0.000000] board: board name: Livebox-blue-5g
[    0.000000] MIPS: machine is Inventel Livebox 1
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 04000000 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Primary instruction cache 16kB, VIPT, 2-way, linesize 16 bytes.
[    0.000000] Primary data cache 8kB, 2-way, VIPT, no aliases, linesize 16 bytes
[    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] random: get_random_bytes called from start_kernel+0x80/0x488 with crng_init=0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line: rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200
[    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Memory: 58160K/65536K available (4003K kernel code, 193K rwdata, 956K rodata, 1304K init, 209K bss, 7376K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 256
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 12741736309 ns
[    0.000031] sched_clock: 32 bits at 150MHz, resolution 6ns, wraps every 14316557820ns
[    1.037346] random: fast init done
[   53.974911] random: crng init done
 


23.03.20192202KernelBug ReportVery LowCriticalbrcm63xx: Hg556a: 4.14 kernel boot stuck at "random: cr...openwrt-19.07New Task Description

The kernel 4.14.107 is unable to boot on the Hg556a (BCM6358).

Steps to reproduce:

  Intall the latest trunk version kernel 4.14.107

Sympthoms:

  No Boot
  It stucks at “random: fast init done”, and apparently no more kernel messages
  But after a minute it spits the last message random: crng init done

Boot Log:

*** Press any key to stop auto run (1 seconds) ***
Auto run second count down: 0
boot kernel from be020100
Code Address: 0x80A00000, Entry Address: 0x80a00000
Decompression OK!
Entry at 0x80a00000
Closing network.
Starting program at 0x80a00000
[    0.000000] Linux version 4.14.107 (hg556a@localhost.localdomain) (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r9015-34696ce25e)) #0 Thu Mar 10 15:47:43 2019
[    0.000000] Detected Broadcom 0x6358 CPU revision a1
[    0.000000] CPU frequency is 300 MHz
[    0.000000] 64MB of RAM installed
[    0.000000] board_bcm963xx: Boot address 0xbe000000
[    0.000000] board_bcm963xx: CFE version: d081.5003
[    0.000000] bcm63xx_nvram: nvram checksum failed, contents may be invalid (expected 33313330, got 3c502ae7)
[    0.000000] bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 0002a010 (Broadcom BMIPS4350)
[    0.000000] board: board name: HW556_B
[    0.000000] MIPS: machine is Huawei EchoLife HG556a (version B)
[    0.000000] Determined physical RAM map:
[    0.000000]  memory: 04000000 @ 00000000 (usable)
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] Primary instruction cache 16kB, VIPT, 2-way, linesize 16 bytes.
[    0.000000] Primary data cache 16kB, 2-way, VIPT, cache aliases, linesize 16 bytes
[    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] random: get_random_bytes called from start_kernel+0x80/0x488 with crng_init=0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 16256
[    0.000000] Kernel command line: rootfstype=squashfs,jffs2 noinitrd console=ttyS0,115200
[    0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[    0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Memory: 54392K/65536K available (6369K kernel code, 343K rwdata, 2132K rodata, 1324K init, 256K bss, 11144K reserved, 0K cma-reserved)
[    0.000000] SLUB: HWalign=16, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 256
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 12741736309 ns
[    0.000026] sched_clock: 32 bits at 150MHz, resolution 6ns, wraps every 14316557820ns
[    1.034043] random: fast init done
[   53.820705] random: crng init done


05.02.20202812Base systemBug ReportVery LowCriticalXiaomi router 3g Openwrt V19 problem. Upload very low. openwrt-19.07Unconfirmed Task Description

Hello, I have xiaomi router 3g, I installed OpenWrt v18 and everything perfect, perfect speed, perfect management (although improvable) etc ...
The problem comes when upgrading to v19.07 and v19.07.1, the router’s upload speed low by half (wired 600mbs v18) v19 300mbs upload speed .... it looks like a bug and it happens to many people , is there any solution to this? Is it possible to improve the router driver and improve the upload and full management of v19? thanks.

13.02.20202832Base systemBug ReportVery LowCriticalD-link DIR-885L firmware doesn't match due to regional ...openwrt-19.07Unconfirmed Task Description

According to the hardware support list, D-link DIR-885L HW A1 is supported, therefore, I have acquired one in China, it clearly stated the HW revision is A1 but its WIFI is not supported with the original firmware 19.07.1

after I flashed the firmware in discovery mode , the wireless tab is not shown in the system. Checked wifi configuration and the file was empty. I found there’s another driver for A2 hardware in the product page, I downloaded it, put it in the designated directory, restarted the router and my wifi appears.

but the driver doesn’t work well. The 2.4g (radio0) can not be started most of the time, some time I alter the configuration of radio0 might bring it up, but even I’ve managed to find the SSID, I can’t connect it. always prompt wrong password.

the 5g (radio1) is better. if I fix the channel, restart the router every time I change the configuration (even change password), it usually make the router works.

I think the Device sold in China is different from other area, the default firmware (which supports A1) doesn’t support Chinese A1 hardware, the A2 firmware driver (BCM4366c) supports the Chinese A1 hardware but doesn’t work well since the driver was dated 2017.

with this BCM4366C driver provided in A2 firmware, I can only have 5G fix Channel WPA2 security wifi service, it’s usable, but all other function are not working, not even one.

I opened the router, tried to provide the chip information but the chips are covered by metal jacket and fixed to the mother board. I have manufacture’s original latest firmware, I think the proper driver may be extracted from it but I’m not capable to do it. I can provide the file as requested. Can’t post here, the file is too big.


01.04.20192216KernelBug ReportVery LowHighath79 - eth0 Spasmodic Link Speed After Driver Changes?...openwrt-19.07New Task Description

I’ve built the latest version of OpenWRT with stock packages and configuration, however, after random amounts of time, all clients lose connectivity because the eth0 link speed drops from the regular 100 Mbps Full Duplex to 10 Mbps Half Duplex, only to reconnect again after a couple of minutes (seconds to mintes, it depends), and do it again at another random time.

[18580.106696] eth0: link up (100Mbps/Full duplex)
[19014.825937] eth0: link up (10Mbps/Half duplex)
[19055.384105] eth0: link up (100Mbps/Full duplex)
[21927.853366] eth0: link up (10Mbps/Half duplex)
[22003.771999] eth0: link up (100Mbps/Full duplex)
[23743.685216] eth0: link down
[23744.723679] eth0: link up (100Mbps/Full duplex)
[23756.242265] eth0: link down
[23757.283590] eth0: link up (100Mbps/Full duplex)
[24075.522397] eth0: link up (10Mbps/Half duplex)
[24090.081802] eth0: link up (100Mbps/Full duplex)
[24100.481809] eth0: link up (10Mbps/Half duplex)
[24166.001178] eth0: link up (100Mbps/Full duplex)
[24500.880989] eth0: link up (10Mbps/Half duplex)

The logs aren’t very useful, it seems. Both syslog and dmesg show the same.

I suspect this started happening after this series of commits (ending with this one) where there were driver changes to the switch, as it didn’t happen before I recompiled a new build with all those newer changes:
https://github.com/openwrt/openwrt/commit/3d93b35f039de86830565420968715b300066475

29.09.20192523KernelBug ReportVery LowHighRB750 randomly reboots after kernel warningsopenwrt-19.07Unconfirmed Task Description

Mikrotik RB750Gr3
LuCI openwrt-19.07 branch (git-19.267.59428-7b36dae) / OpenWrt 19.07-SNAPSHOT r10532-cf3b50377e

Router randomly reboots (it may be stable for hours or can reboot in a minute after power up). Seems like kernel problem.

Here are some logs I managed to fetch before the reboots:

Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.010562] ------------[ cut here ]------------
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.015202] WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_output.c:2509 0x803cc8bc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.022158] invalid inflight: 1 state 1 cwnd 10 mss 1388
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.027441] Modules linked in: qcserial pppoe ppp_async option cdc_mbim usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT wireguard usbserial usbnet usblp ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.097872]  nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt cdc_wdm cdc_acm fuse ledtrig_usbport gpio_beeper input_core xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ip6_udp_tunnel udp_tunnel tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 uas usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd ehci_platform
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.169233]  sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common mii crc32c_generic
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.180291] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.14.143 #0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.186357] Stack : 00000000 00000000 00000000 81230398 00000000 00000000 00000000 00000000
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.194691]         00000000 00000000 00000000 00000000 00000000 00000001 8fc0dd30 ac07f596
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.203026]         8fc0ddc8 00000000 00000000 00004ea0 00000038 8049db58 00000007 00000000
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.211359]         00000000 80550000 0002c043 00000000 8fc0dd10 00000000 80570000 8050c6a0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.219690]         803cc8bc 000009cd 812303d8 81230398 00000000 802af9e8 00000008 805b0008
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.228022]         ...
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.230459] Call Trace:
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.230475] [<8049db58>] 0x8049db58
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.236372] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.239840] [<802af9e8>] 0x802af9e8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.243312] [<800101a0>] 0x800101a0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.246782] [<800101a8>] 0x800101a8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.250250] [<80486a9c>] 0x80486a9c
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.253722] [<800758a0>] 0x800758a0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.257243] [<80032588>] 0x80032588
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.260714] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.264185] [<80032610>] 0x80032610
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.267654] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.271126] [<803cf3d0>] 0x803cf3d0
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.274596] [<8009d750>] 0x8009d750
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.278064] [<803cf7a8>] 0x803cf7a8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.281537] [<8009dd80>] 0x8009dd80
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.285007] [<803cf770>] 0x803cf770
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.288474] [<8008c2cc>] 0x8008c2cc
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.291945] [<8008c588>] 0x8008c588
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.295413] [<8007cee8>] 0x8007cee8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.298883] [<804a49b8>] 0x804a49b8
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.302357] [<80036f14>] 0x80036f14
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.305827] [<8025d440>] 0x8025d440
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.309296] [<8000b488>] 0x8000b488
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.312764]
Sun Sep 29 20:08:08 2019 kern.warn kernel: [   92.314310] ---[ end trace a36c893f27b6a6f3 ]---
Sun Sep 29 18:56:25 2019 kern.alert kernel: [ 2442.525228] CPU 1 Unable to handle kernel paging request at virtual address 00000010, epc == 803be4a0, ra == 803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.535821] Oops[#1]:
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.538087] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G        W       4.14.143 #0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.545363] task: 8fc3be80 task.stack: 8fc5c000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.549869] $ 0   : 00000000 00000001 0000004a 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.555080] $ 4   : 8ea76f3c 00000001 0000d706 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.560290] $ 8   : 00034501 00000321 811d7440 00000322
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.565501] $12   : 8ea22180 8ea22180 8e9a8e00 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.570712] $16   : 8ea76e40 00001204 6375f4c6 ffffffff
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.575923] $20   : 00001204 00000001 00000000 00000002
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.581133] $24   : 00000000 8034b220
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.586344] $28   : 8fc5c000 8fc0bbb8 00000000 803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.591555] Hi    : 0000caa1
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.594419] Lo    : 47aec5c8
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.597285] epc   : 803be4a0 0x803be4a0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.601098] ra    : 803c4104 0x803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.604912] Status: 11007c03      KERNEL EXL IE
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.609082] Cause : 40800008 (ExcCode 02)
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.613066] BadVA : 00000010
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.615931] PrId  : 0001992f (MIPS 1004Kc)
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.620003] Modules linked in: qcserial pppoe ppp_async option cdc_mbim usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT wireguard usbserial usbnet usblp ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.690391]  nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt cdc_wdm cdc_acm fuse ledtrig_usbport gpio_beeper input_core xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ip6_udp_tunnel udp_tunnel tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 uas usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd ehci_platform
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.761710]  sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common mii crc32c_generic
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.772740] Process swapper/1 (pid: 0, threadinfo=8fc5c000, task=8fc3be80, tls=00000000)
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.780788] Stack : 00000204 8034def4 8ea76e40 00000000 8ea76e40 8ea76e40 00001204 803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.789123]         8f346480 8056ba00 00000000 8015000a 00018bc3 8fc0bc74 00000004 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.797457]         80550000 8ea76f3c 00000002 00000001 91946e37 00000000 00000018 91946e37
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.805791]         00000000 91946e37 00000000 00000001 80570000 8050c458 00000000 00000002
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.814125]         00018bc3 00000018 8ee92564 8e9a0600 00000000 00000000 00000001 00000000
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.822457]         ...
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.824891] Call Trace:
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.824903] [<8034def4>] 0x8034def4
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.830852] [<803c4104>] 0x803c4104
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.834335] [<8015000a>] 0x8015000a
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.837825] [<803c4efc>] 0x803c4efc
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.841318] [<803c6f34>] 0x803c6f34
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.844788] [<803a98a0>] 0x803a98a0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.848313] [<803d1bc0>] 0x803d1bc0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.851802] [<803d2f18>] 0x803d2f18
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.855307] [<8e86426c>] 0x8e86426c [nf_conntrack_ipv4@8e864000+0x1420]
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.861893] [<803a9da0>] 0x803a9da0
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.865406] [<803aa078>] 0x803aa078
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.868887] [<803a9940>] 0x803a9940
Sun Sep 29 18:56:25 2019 kern.warn kernel: [ 2442.872360] [<803a9c10>] 0x803a9c10
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.402270] ------------[ cut here ]------------
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.406908] WARNING: CPU: 1 PID: 0 at net/ipv4/tcp_output.c:2509 0x803cc8bc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.413864] invalid inflight: 1 state 1 cwnd 10 mss 1388
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.419148] Modules linked in: qcserial pppoe ppp_async option cdc_mbim usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT wireguard usbserial usbnet usblp ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.489628]  nf_conntrack_netlink nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conntrack iptable_raw iptable_mangle iptable_filter ip_tables crc_ccitt cdc_wdm cdc_acm fuse ledtrig_usbport gpio_beeper input_core xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ip6_udp_tunnel udp_tunnel tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 uas usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd ehci_platform
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.561103]  sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common mii crc32c_generic
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.572189] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.143 #0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.578264] Stack : 00000000 00000000 00000000 81222398 00000000 00000000 00000000 00000000
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.586600]         00000000 00000000 00000000 00000000 00000000 00000001 8fc0bd30 ac07f596
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.594938]         8fc0bdc8 00000000 00000000 00004f18 00000038 8049db58 00000007 00000000
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.603273]         00000000 80550000 0008bb1d 00000000 8fc0bd10 00000000 80570000 8050c6a0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.611605]         803cc8bc 000009cd 812223d8 81222398 00000000 802af9e8 00000004 805b0004
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.619937]         ...
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.622376] Call Trace:
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.622394] [<8049db58>] 0x8049db58
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.628288] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.631755] [<802af9e8>] 0x802af9e8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.635228] [<800101a0>] 0x800101a0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.638699] [<800101a8>] 0x800101a8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.642170] [<80486a9c>] 0x80486a9c
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.645638] [<800758a0>] 0x800758a0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.649107] [<80032588>] 0x80032588
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.652580] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.656052] [<80032610>] 0x80032610
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.659528] [<803cc8bc>] 0x803cc8bc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.663008] [<803cf3d0>] 0x803cf3d0
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.666478] [<8009d750>] 0x8009d750
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.669947] [<803cf7a8>] 0x803cf7a8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.673420] [<8009dd80>] 0x8009dd80
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.676890] [<803cf770>] 0x803cf770
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.680358] [<8008c2cc>] 0x8008c2cc
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.683829] [<80063018>] 0x80063018
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.687300] [<8008c588>] 0x8008c588
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.690768] [<8007cee8>] 0x8007cee8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.694244] [<804a49b8>] 0x804a49b8
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.697717] [<80036f14>] 0x80036f14
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.701185] [<8025d440>] 0x8025d440
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.704662] [<8000b488>] 0x8000b488
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.708131]
Sun Sep 29 18:19:29 2019 kern.warn kernel: [  226.709665] ---[ end trace 0dde230055179878 ]---
12.11.20192593Base systemBug ReportVery LowHighno AC wifi with ath10k on 19.07-rc1openwrt-19.07Waiting on reporter Task Description

- Archer C7, Netgear R7800
- 19.07-RC1 default
- install image, configure wifi, try to connect, in my case i’m getting 300Mbps rate, others report as low as up to 54 (legacy only)

 

R7800 report: https://forum.openwrt.org/t/openwrt-19-07-0-first-release-candidate/48040/33

Archer C7 v2 report: https://forum.openwrt.org/t/openwrt-19-07-rc1-archer-c7-v2-5g-wifi-died-after-trying-to-change-channels/48182/7

the situation is the same with intree 4.9.200 driver or any of the latest backports installed on client PC

18.11.20192614KernelBug ReportVery LowHighath10k 5 GHz connectivity issues for some client device...openwrt-19.07Researching Task Description

* - Device problem occurs on TP-Link Archer C2600.

* - Software version of OpenWrt 19.07-rc1 and older 19.07.

* - From the first version, which I tested after the release of 19.07, I have a problem with 5GHz radio / Wi-Fi. On two devices: LG OLED B8 55 “OTT and Cyfrowy Polsat STB OTT does not work internet. Both devices connect to the network, but do not have access to the Internet. In the connection diagnostics on the TV, the message pops up that it is a DNS error. On 2.4 GHz Wi-Fi everything is fine.

* - I have reverted to the 18.06 to fix the problem for now.


01.12.20192647Base systemBug ReportVery LowHighEA6350v3 (IPQ4018) memory usage climbs until processes ...openwrt-19.07Unconfirmed Task Description

Device is Linksys EA6350v3

Issue occurs on 19.07 rc1, 19.07 rc2 and snapshot r11595 (snapshot version is by memory, but pretty sure that’s what I had on it).

Information for this bug report is based on 19.07 rc2 with the following packages installed for future potential use, but most not in use:
luci-app-sqm luci-proto-wireguard luci-app-wireguard ca-bundle curl https_dns_proxy luci-app-https_dns_proxy luci-app-statistics luci-app-samba kmod-usb-printer p910nd luci-app-p910nd diffutils minidlna luci-app-minidlna

Note: sqm, wireguard, https_dns_proxy, samba, usb printer, p910nd server, and minidlna are NOT in use. These are just the typical packages I add to my
router for future use.

Steps to reproduce:
Problem occurs after router runs for a few hours. EA6350v3 is set up as a wired access point for an EdgeRouter X (also on 19.07 rc2). The Edgerouter provides sqm and DNS and DHCP for LAN, guest and IOT VLANs. There are ~3 “Guest” 2.4 G wifi clients (a smart switch, an IP camera, a DEEBOT vacuum); the IOT VLAN is mapped to a physical port with an Ooma Telo plugged in (I know - I need to map the guest devices to IOT wifi someday...). The LAN is mapped to a physical port with a Roku 3 plugged in and to normal wifi. There are another ~4 or 5 5GHz wifi clients on the LAN wifi (a laptop, a couple Amazon Echo’s, a Google Home Mini, a Samsung Orbit Android phone) and a 2.4G LG Android phone on the 2.4 GHz wifi. CPU loading is quite low.

Memory usage starts out rather high (~100MB, climbs and climbs, eventually drops, climbs again, repeats. Eventually (a day or two) processes start getting killed to free up memory and things start dying. I have an EA8500 setup almost identically as a second AP in the house, and it’s memory usage sits around 50 MB versus 100MB to 200+MB for the EA6350v3. Something’s just not right...

The final message in the logs that repeats until processes begin to get killed is:

kern.warn kernel: [15897.905286] ath10k_ahb a000000.wifi: failed to increase tx pending count: -16, dropping

But the weird memory usage pattern precedes this message in the logs.

I’ve attached memory usage graphs and system and kernel logs from 19.07 rc2 to illustrate the problem. rc1 and snapshot behaved the same. This post also has logs showing processes getting killed if that helps diagnose: https://forum.openwrt.org/t/ipq4018-linksys-ea6350v3-wifi-dead-after-24-48-hrs/49080/3?u=eginnc

12.12.20192670KernelBug ReportVery LowHigh[ATH79] unstable USB on WR1043 v2openwrt-19.07Unconfirmed Task Description

Hi there!

I recently upgraded my TP-Link TL-WR1043 v2 device to the ath79 targeted 19.07-rc2 release using my custom build, which I have compiled with the image builder.

make image PROFILE=tplink_tl-wr1043nd-v2 PACKAGES="block-mount curl diffutils ethtool iperf3 iwinfo htop kmod-fs-ext4 kmod-usb-storage luci mailsend-nossl minidlna nfs-kernel-server ppp-mod-pppoe shadow-su transmission-daemon-mbedtls transmission-web vsftpd zram-swap -ip6tables -kmod-ip6tables -kmod-ipv6 -kmod-nf-conntrack6 -kmod-nf-ipt6 -libopenssl1.1 -odhcp6c -odhcpd-ipv6only -luci-proto-ipv6 -libip6tc2"

I just recently rolled back to an EXT4 partition, because of it's smaller memory footprint. (just mounting a ~50GB f2fs partition consumes around 10MBs of memory)
So in the very first attempt I wanted to copy back everything to my Transcend 790K. But after the first 500-1000 MBs(mix of archives, image, text and video files), the transaction speed has fallen down couple of times. I thought maybe the passive FTP connection was the problem, because after a few automatic reconnect attempts, the speed of the copy has been normalized again and in the end the device was connected. Later I found that the USB devices was reseted.
I had another try with a Sandisk Ultra Fit drive (SDCZ-43), but the result and the configuration was pretty sam. ~50GB EXT4 partition without journal and without barrier.
I force upgraded the machine to the ar71xx target and Filezilla so far copied back 16GBs without any problem.
Target ATH79 seem to be has so many problems with the USB subsystem, please see my other bugreport for the WDR4300 as well: FS#2567 - [ATH79] USB speed degradation on WDR4300.

Let me know if I can help the bughunting any way,
thanks and regards!

09.01.20202719Base systemBug ReportVery LowHighBuffalo WBMR-HP-G300H: DSL does not connect at all with...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: Buffalo WBMR-HP-G300H
- Software versions of OpenWrt/LEDE release, packages, etc.: OpenWRT 19.07, kmod-ltq-adsl-ar9-fw-a 0.1-1, which shows up as 4.4.4.0.0.1 in dsl_control status.
- Steps to reproduce:

1. Get an ADSL line from Rostelecom.
2. Upgrade the router to OpenWRT 19.07.
3. Reboot.

Result: DSL does not connect. In /etc/init.d/dsl_control status, it goes through all phases, then briefly shows as “Up”, but then the “dsl0” interface is not created, and the following lines are logged in dmesg:

 [   56.597766] [DSL_BSP_Showtime 914]: Datarate US intl = 1024000, fast = 0
 [   56.603091] [DSL_BSP_Showtime 934]: no hookup from ATM driver to set cell rate

The error does not exist with the 4.5.4.9.1.1 firmware obtained from unofficial sources. The bug has been submitted through the affected ADSL line with the unofficial firmware.

Status:

# /etc/init.d/dsl_control status
ATU-C Vendor ID: Broadcom 161.149
ATU-C System Vendor ID: 00,00,00,00,00,00,00,00
Chipset: Ifx-AR9
Firmware Version: 4.5.4.9.1.1
API Version: 3.24.4.4
XTSE Capabilities: 0×4, 0×0, 0×0, 0×0, 0×0, 0×0, 0×0, 0×0 Annex: A
Line Mode: G.992.1 (ADSL)
Profile:
Line State: UP [0×801: showtime_tc_sync]
Forward Error Correction Seconds (FECS): Near: 413342 / Far: 0
Errored seconds (ES): Near: 0 / Far: 0
Severely Errored Seconds (SES): Near: 0 / Far: 0
Loss of Signal Seconds (LOSS): Near: 0 / Far: 0
Unavailable Seconds (UAS): Near: 253 / Far: 253
Header Error Code Errors (HEC): Near: 0 / Far: 0
Non Pre-emtive CRC errors (CRC_P): Near: / Far:
Pre-emtive CRC errors (CRCP_P): Near: / Far:
Power Management Mode: L0 - Synchronized
Latency [Interleave Delay]: 8.0 ms [Interleave] 8.0 ms [Interleave]
Data Rate: Down: 9.952 Mb/s / Up: 1.024 Mb/s
Line Attenuation (LATN): Down: 32.2 dB / Up: 19.5 dB
Signal Attenuation (SATN): Down: 32.6 dB / Up: 19.5 dB
Noise Margin (SNR): Down: 6.1 dB / Up: 13.0 dB
Aggregate Transmit Power (ACTATP): Down: 20.0 dB / Up: 12.3 dB
Max. Attainable Data Rate (ATTNDR): Down: 8.848 Mb/s / Up: 1.204 Mb/s
Line Uptime Seconds: 1164
Line Uptime: 19m 24s

(yes, very bad line)

Config:

config atm-bridge ‘atm’

option vpi '1'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
option vci '50'
option unit '0'
option atmdev '0'

config dsl ‘dsl’

option annex 'a'
option firmware '/lib/firmware/dsl_ar9_firmware_adsl_a-04.05.04.09.01.01.bin'

config interface ‘wan’

option ifname 'dsl0'
option proto 'pppoe'
option ipv6 '1'
option username 'censored'
list dns '8.8.8.8'
list dns '8.8.4.4'
option peerdns '0'
option keepalive '60 5'
option password 'censored'
12.01.20202730KernelBug ReportVery LowHighTL-WR841N v8 ath79 Link Unstableopenwrt-19.07New Task Description

Probably related to https://bugs.openwrt.org/index.php?do=details&task_id=2216 which was reported almost a year ago. The bug is still not fixed though.

Are there any plans to fix it or will 18.06 be the last stable version for this and probably other devices?

[8451.981464] eth1: link up (100Mbps/Full duplex)
[37071.909045] eth1: link down
[37072.988861] eth1: link up (100Mbps/Full duplex)
[48492.291332] eth1: link up (10Mbps/Half duplex)
[48632.691559] eth1: link up (100Mbps/Full duplex)
[55697.449886] eth1: link down
[55698.491082] eth1: link up (100Mbps/Full duplex)
[62395.095374] eth1: link up (10Mbps/Half duplex)
[62507.411488] eth1: link up (100Mbps/Full duplex)
[62726.853998] eth1: link up (10Mbps/Half duplex)
[62732.053093] eth1: link up (100Mbps/Full duplex)
[71071.460663] eth1: link down
[71072.618285] eth1: link up (100Mbps/Full duplex)
[73435.556373] eth1: link down
[73436.597169] eth1: link up (100Mbps/Full duplex)
[73547.879987] eth1: link up (10Mbps/Half duplex)
[73558.277169] eth1: link up (100Mbps/Full duplex)
[74438.121970] eth1: link down
[74439.162824] eth1: link up (100Mbps/Full duplex)
[75341.889076] eth1: link up (10Mbps/Half duplex)
[75352.290230] eth1: link up (100Mbps/Full duplex)
[76274.772404] eth1: link down
[76275.813134] eth1: link up (100Mbps/Full duplex)

13.01.20202733Base systemBug ReportVery LowHighAth79 firmware accident enter to failsafe mode when reb...openwrt-19.07Unconfirmed Task Description

Sometime when reboot/reflash router, I see serial console messages:

[    5.868712] init: - preinit -
[    5.960699] random: procd: uninitialized urandom read (4 bytes read)
[    6.909058] random: jshn: uninitialized urandom read (4 bytes read)
[    7.327749] random: jshn: uninitialized urandom read (4 bytes read)
[    7.567130] random: jshn: uninitialized urandom read (4 bytes read)
[    7.638687] random: jshn: uninitialized urandom read (4 bytes read)
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[    9.860896] eth0: link up (1000Mbps/Full duplex)
- failsafe button rfkill was pressed -
- failsafe -
[   12.309911] urandom_read: 3 callbacks suppressed
[   12.309921] random: dropbearkey: uninitialized urandom read (32 bytes read)
Generating 1024 [   12.323834] random: dropbearkey: uninitialized urandom read (32 bytes read)
bit rsa key, this may take a while...
Public key portion is:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCKZVT/UJoTHz2CkNHrYmfzzBDfa/6Yd6+LJVcrURD15lbN3ch7AG/tc/ZolkeOrqkKD6dM2h4TsYv4+)
Fingerprint: sha1!! b9:a4:d3:94:71:b3:34:ae:a3:85:c8:e9:a7:c8:63:fd:74:52:5e:ad


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

ash: can't access tty; job control turned off
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 19.07-SNAPSHOT, r10868-08d9828b76
 -----------------------------------------------------
================= FAILSAFE MODE active ================

I noticed when wifi on/off switch on router is on, sometime it accident enter failsafe mode. If switch to off, it’s not happen.
Issue happens with 841n v8/v9/v10 & 841hp v3 (same hardware as v9/10) model.


30.01.20202783Base systemBug ReportVery LowHighTP-Link Archer A7 v5 can't be flashet via tftpopenwrt-19.07Unconfirmed Task Description

Device: TP-Link Archer A7 (RU) Ver 5.0
Software: OpenWRT 19.07.0

I just bought this router. And I trying to flash it with openwrt-19.07.0-ath79-generic-tplink_archer-a7-v5-squashfs-factory.bin trough tftp.
In wireshark I clearly see that file was downloaded. But router didn’t flashed.
I tried to flash snapshot image wtih same result.
I checked sha256 sums and it matches.

When I reproduced same steps with original TP-Link update image it worked well. Seems like something prevents router from flashing OpenWRT image.

30.01.20202785Base systemBug ReportVery LowHighkernel loading during netboot fails on mikrotik devicesopenwrt-19.07Unconfirmed Task Description

Devices tested:

  • Mikrotik rb433
  • Mikrotik rb435g

Software version: Using the v19.07.1 tag.

Issue: There are a few packages, whose are leading the ramdisk “unbbotable”, more precise the device is not able to load the kernel. First this happened by kmod-scsi-core , I thought it must be some kernel-related issue. Afterthat I realised that either I enable the aforementioned kernel-module, or the libraries called libpcre and libpci, the boot procedure will stop at:

Gateway: 192.168.1.254
transfer started ................................... transfer ok, time=2.61s
setting up elf image... OK
jumping to kernel code OpenWrt kernel loader for AR7XXX/AR9XXX
Copyright (C) 2011 Gabor Juhos juhosg@openwrt.org Decompressing kernel... done!
Starting kernel at 80060000...

Compiling these packages only as a module results a nice bootable image. Firstly I thought that maybe my ramdisk is too large, but it is about only 4,5 MB - previously using older trunk I was able to boot up images over 5 MByte.
I have pasted the config file to the ticket. If you switch libpcre and libpci to M instead of * it will boot.

This issue was not there before, using the image built from 18.06.

31.01.20202791Base systemBug ReportVery LowHighIPv6 router advertisments lost after upgrade to 19.07openwrt-19.07Unconfirmed Task Description

I’ve just upgraded my linksys wrt-1200ac from 18.06.4 to 19.07.0

I’ve got a more-or-less out-of-the-box configuration with wired and wireless clients all connected to the ‘br-lan’ bridge. My ISP provides native IPv6. I’ve got odhcpd-ip6only installed, and a mixture of clients, some using SLAAC and some using DHCPv6.

When a wireless client that is configured for SLAAC (e.g. an android phone) connects, it sends an IPv6 router solicitation to ff02::1 and receives a router advertisement on its fe80::<something> address. That still works fine. But the client never receives any further router adverts, so the route times out after 1800 seconds and IPv6 connectivity is lost.

This is *only* going wrong with wireless clients: tcpdump on a wired client shows router adverts arriving on ff02::1 every few minutes. But tcpdump on a wireless client shows no router adverts after the initial one.

I’ve retested with 18.06.4 and the problem does not exist in that version.

16.02.20202835Base systemBug ReportVery LowHighMT7621: Clients disconnects.openwrt-19.07Unconfirmed Task Description

Hi! I have MT7621 and when to router connected more than 10 peoples router start disconnecting some peoples(have two networks guest and main on 2,4).

There is my settings:
config wifi-iface ‘default_radio0’ option device ‘radio0’ option network ‘lan’ option mode ‘ap’ option wpa_disable_eapol_key_retries ‘1’ option key ‘WIFIPASS’ option ssid ‘WIFINAME’ option encryption ‘psk2+ccmp’ option disassoc_low_ack ‘0’ (guest network have same settings)

Other info:
Newifi-D2
MediaTek MT7621 ver:1 eco:3
OpenWrt 19.07.1 r10911-c155900f66 / LuCI openwrt-19.07 branch git-20.045.27998-49999e9

I also noticed that before the client is disconnected from the network, it will lose the Internet.

 

Issue on github: https://github.com/openwrt/mt76/issues/358

Many peoples with Newifi3 D2 have same problem(in github links and more details).

PLEASE, FIX IT!

18.02.20202844Base systemBug ReportVery LowHighath10k on archer C7 v2: high latencyopenwrt-19.07Unconfirmed Task Description

On my Archer C7 v2, since the upgrade from 18.06 to 19.07, I sometimes get very high latency on my 5 GHz wifi network:

This is when pinging a wireless client from the router itself.

ping 192.168.12.167
PING 192.168.12.167 (192.168.12.167): 56 data bytes
64 bytes from 192.168.12.167: seq=0 ttl=64 time=1.334 ms
64 bytes from 192.168.12.167: seq=1 ttl=64 time=2.002 ms
64 bytes from 192.168.12.167: seq=2 ttl=64 time=1004.448 ms
64 bytes from 192.168.12.167: seq=3 ttl=64 time=4.342 ms
64 bytes from 192.168.12.167: seq=4 ttl=64 time=1.072 ms
64 bytes from 192.168.12.167: seq=5 ttl=64 time=2.074 ms
64 bytes from 192.168.12.167: seq=6 ttl=64 time=2.505 ms
64 bytes from 192.168.12.167: seq=7 ttl=64 time=1.059 ms
64 bytes from 192.168.12.167: seq=8 ttl=64 time=1.746 ms
64 bytes from 192.168.12.167: seq=9 ttl=64 time=1.176 ms
64 bytes from 192.168.12.167: seq=10 ttl=64 time=1.086 ms
64 bytes from 192.168.12.167: seq=11 ttl=64 time=1.072 ms
64 bytes from 192.168.12.167: seq=12 ttl=64 time=815.290 ms
64 bytes from 192.168.12.167: seq=13 ttl=64 time=1004.417 ms
64 bytes from 192.168.12.167: seq=14 ttl=64 time=4.294 ms
64 bytes from 192.168.12.167: seq=15 ttl=64 time=4.520 ms
64 bytes from 192.168.12.167: seq=16 ttl=64 time=1003.250 ms
64 bytes from 192.168.12.167: seq=17 ttl=64 time=3.125 ms
64 bytes from 192.168.12.167: seq=18 ttl=64 time=1.019 ms
64 bytes from 192.168.12.167: seq=19 ttl=64 time=2.066 ms
^C
--- 192.168.12.167 ping statistics ---
20 packets transmitted, 20 packets received, 0% packet loss
round-trip min/avg/max = 1.019/193.094/1004.448 ms

The upgrade to 19.07.1 didn’t solve the issue. What (temporarily) seem to work is to restart the wlan0 interface. After a few hours the problem comes back. The client is very close to the AP (less than 3 meters, although there is a floor between). Signal quality is reported as very good.

Station 54:60:09:d3:e4:d6 (on wlan0)
        inactive time:  540 ms
        rx bytes:       1082546
        rx packets:     6294
        tx bytes:       15523400
        tx packets:     11636
        tx retries:     0
        tx failed:      1
        rx drop misc:   0
        signal:         -66 [-76, -68, -71] dBm
        signal avg:     -62 [-72, -64, -67] dBm
        tx bitrate:     390.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 1
        rx bitrate:     390.0 MBit/s VHT-MCS 8 80MHz short GI VHT-NSS 1
        rx duration:    422088 us
        last ack signal:-95 dBm
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       long
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        short slot time:yes
        connected time: 447 seconds

I am using stock 19.07.1 firmware. I also tried changing the regulatory domain from CA to US but it didn’t help.
I will now try with the non-ct driver and firmware to see if it helps, as it worked fine on 18.06 which didn’t include the -ct firmware by default.

cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option hwmode '11a'
        option path 'pci0000:00/0000:00:00.0'
        option htmode 'VHT80'
        option noscan '1'
        option country 'US'
        option channel '149'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option key 'removed'
        option network 'lan'
        option mode 'ap'
        option ssid 'myssid5'
        option encryption 'psk2+ccmp'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/ahb/ahb:apb/18100000.wmac'
        option noscan '1'
#       option country 'CA'
        option htmode 'HT40'
        option require_mode 'g'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'myssid'
        option encryption 'psk2+ccmp'
        option key 'removed'
        option ieee80211w '1'
22.02.20202848Base systemBug ReportVery LowHighmulticast ff02::2 not responding since 19.07openwrt-19.07Unconfirmed Task Description

cannot do multicast in nanostation m5 xw (and maybe applies for other devices with eth0.1 and eth0.2 simulating eth0 and eth1)

multicast is a core feature for running some routing protocols as bmx6 per cable)

  iface="my ethernet"
  ping6 ff02::2%$iface

did tests with several platforms

- 18.06.4 ar71xx custom firmware → works
- 18.06.7 ar71xx openwrt.org → works
- 19.07.1 ar71xx custom firmware → does not work
- 19.07.1 ar71xx openwrt.org → does not work
- 19.07.1 ath79 openwrt.org → does not work
- snapshot ar71xx openwrt.org → does not work

  1. 0a21d2eb80787083852d92f1519f268df4873c07873ea6e4c1ba17af791fd801 3904.0 KB Mon Jun 17 14:08:48 2019

- snapshot ath79 openwrt.org → does not work

  1. e6831b128017c83082110191a4cbdf37994beb7e2dae651b5b36b854b4674805 4096.3 KB Thu Feb 20 09:43:23 2020
  2. OpenWrt SNAPSHOT, r12252-060b58fd6e

when I was figuring out what was happening, I did bmx6 routing (multicast) through br-lan in 3 devices, and I looked results with `tcpdump -i br-lan`. From the other devices I see that the multicast traffic from the affected device arrives (multicast packets go out), but when I see `tcpdump -i br-lan` in the affected device I only see his own multicast traffic (it’s not entering anything else)

hence, looks like 19.07.1 introduced something that it does not allow this

09.02.2017488Base systemBug ReportVery LowMediumdynamic VLAN doesn't work on ath10kopenwrt-19.07Unconfirmed Task Description

Dynamic vlan config on ath10k seems not to work. Same config on ath9k works fine.

Config:

config wifi-device  radio0
        option type     mac80211
        option channel  36
        option hwmode   11a
        option path     'pci0000:01/0000:01:00.0'
        option htmode   VHT80
[...]

config wifi-iface
        option device   radio0
        option network  vlan1
        option mode     ap
[...]
        option dynamic_vlan     '1'
        option 'vlan_tagged_interface' 'eth1'
        option 'vlan_bridge' 'br-vlan'
        option 'vlan_naming' '0'

Log:

Thu Feb  9 15:54:37 2017 daemon.err hostapd: WPA initialization for VLAN 1 failed (-1)
Thu Feb  9 15:54:37 2017 daemon.err hostapd: WPA deinit of wlan0.1 failed
Thu Feb  9 15:54:37 2017 daemon.debug hostapd: wlan0: STA ac:22:0b:a1:c7:6b IEEE 802.11: could not add dynamic VLAN interface for vlan=1
25.10.20192567KernelBug ReportVery LowMedium[ATH79] USB speed degradation on WDR4300openwrt-19.07Assigned Task Description

Hello!

I experience huge speed loss on the lastest build (Thu Oct 24 21:58:18 2019) using the ath79 snapshot image builder. I had the same problem on the ~2 weeks earlier build as well, just wanted to have a try on the up to date version now.
Built configuration on both 18.04.6 and 19.07:
PROFILE=tplink_tl-wdr4300-v1 PACKAGES=”block-mount diffutils f2fs-tools kmod-fs-f2fs kmod-mtd-rw kmod-usb-storage luci mailsend-nossl minidlna nfs-kernel-server ppp-mod-pppoe shadow-su transmission-daemon-mbedtls transmission-remote-mbedtls vsftpd usbreset zram-swap -ip6tables -kmod-ip6tables -kmod-ipv6 -kmod-nf-conntrack6 -kmod-nf-ipt6 -libopenssl1.1 -odhcp6c -odhcpd-ipv6only -luci-proto-ipv6 -libip6tc2”

Drive: Kingston DT G3 32GB (old one, better quality with Intel MLC flash)
Firewall: w and w/o flow offload on 19.07
Model: TP-Link WDR4300 v1

File read speeds:
18.06.4 orig vstpd 542M 75s 7,2MB/s
18.06.4 pepe2k vstpd 542M 64s 7,2MB/s
19.07 pepe2k vstpd 542M 543s 1,0MB/s
19.07 pepe2k dd+nc 256M 321s 0,8MB/s

- During the measurement, no root overlay was in use, just a general filesystem was attached
- lower speeds are really close to USB 1.x standard
- measurements took on fresh installations
- the degradation exists if only one drive is attached
- the degradation exists on both filesystem and block level.

I’m using pepe2k’s uboot image (CPU clocked to 600MHz). However I didn’t revert the uboot partition now, I did for a few weeks, nothing has changed.

Let me know if I can help the troubleshooting anyway. Dmesg logs are attached for all mentioned configurations (18.06.4 orig, 18.06.4 pepe2k, 19.07 pepe2k).

Best regards

23.11.20192623Base systemBug ReportVery LowMediumJumbo Frames not possible on Archer C7 v5openwrt-19.07Unconfirmed Task Description

ip link set mtu 9000 dev eth0
RTNETLINK answers: Invalid argument

swconfig dev eth0 show

no sign of jumbo frames.

Only a payload of 1474 can be transmitted over a mtu 9000 core network, effectively.

Related issue:
https://dev.archive.openwrt.org/ticket/18296

25.11.20192628KernelBug ReportVery LowMediumKernel warning: eth0 (mtk_soc_eth): transmit queue 0 ti...openwrt-19.07Unconfirmed Task Description

Model ZBT-WG3526 (16M)
Architecture - MediaTek MT7621 ver:1 eco:3
Firmware version - OpenWrt 19.07-SNAPSHOT r10731-e68d589e7b / LuCI openwrt-19.07 branch git-19.326.61751-179c5e8
Kernel version- 4.14.155

 Mon Nov 25 10:11:25 2019 kern.info kernel: [  106.762093] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Mon Nov 25 10:11:25 2019 kern.info kernel: [  106.770348] br-VLAN8: port 2(wlan1) entered blocking state
Mon Nov 25 10:11:25 2019 kern.info kernel: [  106.775981] br-VLAN8: port 2(wlan1) entered forwarding state
Mon Nov 25 10:11:25 2019 kern.info kernel: [  106.784594] br-VLAN6: port 3(wlan1-1) entered blocking state
Mon Nov 25 10:11:25 2019 kern.info kernel: [  106.790393] br-VLAN6: port 3(wlan1-1) entered disabled state
Mon Nov 25 10:11:25 2019 kern.info kernel: [  106.796955] device wlan1-1 entered promiscuous mode
Mon Nov 25 10:11:25 2019 kern.info kernel: [  106.803794] IPv6: ADDRCONF(NETDEV_UP): wlan1-1: link is not ready
Mon Nov 25 10:11:25 2019 kern.info kernel: [  106.810026] br-VLAN6: port 3(wlan1-1) entered blocking state
Mon Nov 25 10:11:25 2019 kern.info kernel: [  106.815820] br-VLAN6: port 3(wlan1-1) entered forwarding state
Mon Nov 25 10:11:25 2019 kern.info kernel: [  107.343567] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1-1: link becomes ready
Mon Nov 25 11:10:20 2019 kern.info kernel: [ 3641.266434] nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based  firewall rule not found. Use the iptables CT target to attach helpers instead.
Mon Nov 25 11:37:14 2019 kern.info kernel: [ 5255.651116] TCP: request_sock_TCP: Possible SYN flooding on port 88. Sending cookies.  Check SNMP counters.
Mon Nov 25 11:41:29 2019 kern.warn kernel: [ 5510.958004] ------------[ cut here ]------------
Mon Nov 25 11:41:29 2019 kern.warn kernel: [ 5510.962647] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:320 0x8038e1c0
Mon Nov 25 11:41:29 2019 kern.info kernel: [ 5510.969709] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
Mon Nov 25 11:41:29 2019 kern.warn kernel: [ 5510.976660] Modules linked in: qcserial pppoe ppp_async option cdc_mbim usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE huawei_cdc_ncm cfg80211 cdc_ncm cdc_ether 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 wireguard usbserial usbnet usblp ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_tftp nf_nat_snmp_basic nf_nat_sip nf_nat_redirect nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4 nf_nat_ipv4
Mon Nov 25 11:41:29 2019 kern.warn kernel: [ 5511.047339]  nf_nat_h323 nf_nat_amanda nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_tftp nf_conntrack_snmp nf_conntrack_sip nf_conntrack_rtcache nf_conntrack_proto_gre nf_conntrack_irc nf_conntrack_h323 nf_conntrack_broadcast ts_kmp nf_conntrack_amanda nf_conntrack iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables crc_ccitt compat cdc_wdm cdc_acm fuse ledtrig_usbport xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT
Mon Nov 25 11:41:29 2019 kern.warn kernel: [ 5511.118581]  x_tables nf_reject_ipv6 ip6_udp_tunnel udp_tunnel tun vfat fat nls_utf8 nls_iso8859_1 nls_cp437 uas mmc_block usb_storage mtk_sd mmc_core leds_gpio xhci_plat_hcd xhci_pci xhci_mtk xhci_hcd ahci libahci libata ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common mii crc32c_generic
Mon Nov 25 11:41:29 2019 kern.warn kernel: [ 5511.149081] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.155 #0
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.155177] Stack : 00000000 00000000 00000000 8fe6d540 00000000 00000000 00000000 00000000
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.163556]         00000000 00000000 00000000 00000000 00000000 00000001 8fc0bd60 ac07f582
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.171942]         8fc0bdf8 00000000 00000000 000093c8 00000038 8049e458 00000008 00000000
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.180305]         00000000 80550000 00024659 00000000 8fc0bd40 00000000 00000000 8050c830
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.188647]         8038e1c0 00000140 00000001 8fe6d540 00000000 802b02b8 00000004 805b0004
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.196980]         ...
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.199415] Call Trace:
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.199535] [<8049e458>] 0x8049e458
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.205440] [<8038e1c0>] 0x8038e1c0
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.208923] [<802b02b8>] 0x802b02b8
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.212412] [<800101a0>] 0x800101a0
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.215881] [<800101a8>] 0x800101a8
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.219354] [<804873a4>] 0x804873a4
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.222825] [<800759a0>] 0x800759a0
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.226315] [<800325b8>] 0x800325b8
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.229802] [<8038e1c0>] 0x8038e1c0
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.233316] [<80032640>] 0x80032640
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.236785] [<800d20e8>] 0x800d20e8
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.240287] [<8038e1c0>] 0x8038e1c0
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.243757] [<8009d860>] 0x8009d860
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.247237] [<8038e014>] 0x8038e014
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.250711] [<8008c3dc>] 0x8008c3dc
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.254181] [<80063108>] 0x80063108
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.257662] [<8008c698>] 0x8008c698
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.261136] [<8007cfe8>] 0x8007cfe8
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.264627] [<804a5240>] 0x804a5240
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.268102] [<80036f74>] 0x80036f74
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.271573] [<8025daf0>] 0x8025daf0
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.275054] [<8000b488>] 0x8000b488
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.278548]
Mon Nov 25 11:41:30 2019 kern.warn kernel: [ 5511.280144] ---[ end trace f0b0ca1dd55db7a7 ]---
Mon Nov 25 11:41:30 2019 kern.err kernel: [ 5511.284782] mtk_soc_eth 1e100000.ethernet eth0: transmit timed out
Mon Nov 25 11:41:30 2019 kern.info kernel: [ 5511.291016] mtk_soc_eth 1e100000.ethernet eth0: dma_cfg:80000065
Mon Nov 25 11:41:30 2019 kern.info kernel: [ 5511.297053] mtk_soc_eth 1e100000.ethernet eth0: tx_ring=0, base=0dc00000, max=0, ctx=1789, dtx=1789, fdx=1788, next=1789
Mon Nov 25 11:41:30 2019 kern.info kernel: [ 5511.307977] mtk_soc_eth 1e100000.ethernet eth0: rx_ring=0, base=0db60000, max=0, calc=893, drx=894
Mon Nov 25 11:41:30 2019 kern.info kernel: [ 5511.321091] mtk_soc_eth 1e100000.ethernet: 0x100 = 0x6060000c, 0x10c = 0x80818
Mon Nov 25 11:41:30 2019 kern.info kernel: [ 5511.334877] mtk_soc_eth 1e100000.ethernet: PPE started

25.11.20192631Base systemBug ReportVery LowMediumsysntp often fails when using DHCP provided serveropenwrt-19.07Unconfirmed Task Description

I’m managing a network with 25 openwrt WLAN access points (mostly TL-WR1043ND v1, a few v2 and a few zbt-2626) and since updating to 19.07 some devices often have an incorrect time. All are configured to get their NTP server from DHCP and this happen on all models.

When this happen ntpd is simply not running and starting it restore the correct time right away. It is hard to says if ntpd crash or if it never started in the first place. Last time I checked all affected devices had been restarted recently so I would first suspect some race condition during boot.

29.11.20192641KernelBug ReportVery LowMediumDevice file for USB does not appear /dev/ttyUSB*openwrt-19.07Waiting on reporter Task Description

With new version 19.07.0rc I could not make my USB cellular (3g) modem dongle to work due to it simply no any serial device like /dev/ttyUSB* file appear with insertion.
In kernel log it appears report about new device insertion and nothing happenings after.
I made several attempts, with ‘modeswitch’ or without and several other ‘mods’ the result is the same no any /dev/ttyUSB*
With other version it was not such problem it appeared exactly three /dev/ttyUSB0 /dev/ttyUSB1 /dev/ttyUSB2 es well as on my Ubuntu 19.04 And Ubuntu 16.04 Ubuntu 18.04

Both router and dongle are USB-2
Actually router is Asus RT-N16
and modem dongle is Alcatel One Touch X090S

P.S. I need this one to be solved to report other bugs. :)

10.12.20192667Base systemBug ReportVery LowMediumLantiq specific, "dsl interfae" VDSL driver, unhelpful ...openwrt-19.07Unconfirmed Task Description

Probably, FAO "John Crispin" Lantiq maintainer, apparently!,

On OpenWRT 19.07.0rc2, both on TP-LINK TD-W8980 and also BT-Homehub-v5-type-A [lantiq xrx200 devices] ...

I am finding a consistent frustrating limitation, that the default config, and LuCI web interface, does not provide any way to expose the MTU capability of the built-in VDSL driver, which allows for full 1500 MTU to be carried on PPPoE on VDSL, as is commonplace in provided routers.

Specifically, the VDSL device "dsl0" (and, in my case, VLAN 101, "dsl0.101"), has an unhelpful default MTU restriction to 1500, such that PPPoE (as is common in UK!) does not work at the normally expected 1500MTU, requiring workarounds 1492MTU MSS-clamping hacks. Turns out this is fixable at the configuration-level, but not via anything exposed in web-interface (as underlying DSL MTU is wrong from the start...).

Example below, extra /etc/config/network lines to support the standard MTU:-

config interface 'wan'

      option ifname 'dsl0.101'
      option proto 'pppoe'
      option password 'PASSWORD'
      option ipv6 'auto'
      option username 'USERNAME'
      option mtu '1500'           #exposed via web, still needs setting, to try to negotiate that MTU 1500 inside PPPoE...

config device 'wan_dev'

      option name 'dsl0'
      option macaddr 'e8:11:22:33:44:4b'
      option mtu '1508'           #This line Had to be added manually

config device 'wan_dev2' # Extra section added, if not done,

      option name 'dsl0.101'             #  MTU wrong for the dsl 0.101 link!
      option macaddr 'e8:11:22:33:44:4b' #  As in this case having to use VLAN101
      option mtu '1508'                  #  As per UK Openreach VDSL configuration...

In my view, at the very least, the 'internal' DSL driver, should be allowing a larger mtu like 1508, 'by default'. Possibly, if this is done at driver level, the PPPoE MTU won't need to be specified at all.

The PPPoE over VDSL configuration, also needed to be told to attempt 1500 MTU, which I understand relies upon rfc4638 PPP extension, in order to have fully functional 1500MTU connection. Not having this has caused connectivity issues requiring MSS clamping etc. and is, in short, undesirable!.

It think, the PPPoE over PTM over VDSL should, additionally, attempt this 1500-MTU 'by default' unless the MTU is reduced manually in the configuration.

I understand this should be passed to Lantiq maintainer, "John Crispin" apparently!, according to IRC-discussions!.

With many thanks,

25.12.20192694Base systemBug ReportVery LowMediumClearfog Pro: Default LAN / WAN Interface assignment is...openwrt-19.07Unconfirmed Task Description

On my Clearfog Pro Rev 2.0 the interfaces map as follows:

eth0: switch
eth1: SFP
eth2: standalone ethernet

This does not match the current description in /etc/board.d/02_network:

# eth0 is standalone ethernet
# eth1 is switch (-pro) or standalone ethernet (-base)
# eth2 is SFP
ucidef_set_interfaces_lan_wan "eth1" "eth0 eth2"

While I don’t agree with the lan/wan decision made here, at least the comment should match reality.
So I suggest changing it to:

# eth2 is standalone ethernet
# eth0 is switch (-pro) or standalone ethernet (-base)
# eth1 is SFP
ucidef_set_interfaces_lan_wan "eth0 eth1" "eth2"

Please also see the attached patch file, which also changes the switch configuration accordingly.

28.12.20192702KernelBug ReportVery LowMediumPerformance degradation after kernel.warn ath10k_core@8...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:

- Device problem occurs on
Archer C7v2

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

[---] PACKAGES INSTALLED
echo [INFO] Downloading package information ...
opkg update
#
echo [INFO] Removing packages ...
opkg remove wpad-basic
#
echo [INFO] Installing packages ...
opkg install bash
opkg install block-mount
opkg install curl
opkg install e2fsprogs
opkg install htop
# opkg install igmpproxy
opkg install kmod-br-netfilter
opkg install kmod-fs-ext4
opkg install kmod-fs-msdos
opkg install kmod-fs-ntfs
opkg install kmod-scsi-core
opkg install kmod-usb-storage
opkg install libncurses
opkg install libpcre
opkg install lua luafilesystem
opkg install luci-mod-rpc
opkg install luci-proto-relay
opkg install mailsend
opkg install nano
opkg install relayd
opkg install rpcd
opkg install terminfo
opkg install tcpdump
opkg install uhttpd-mod-ubus
opkg install vsftpd
opkg install wget
opkg install wpad
#
# batman-adv
opkg install kmod-batman-adv
opkg install batctl-full
[---]

- Steps to reproduce
Today worked on batman-adv via ad-hoc between two devices. Device A has LAN to bat0, batman-adv works over ad-hoc wifi, Device B has bat0 to LAN. (Device B has only one wired client behind)
Both devices (Archer C7v2 with OpenWrt 19.07-rc.2) had multiple crashes of the below printed type resulting in only 10 MBit/s download speed on the computer attached via LAN to Device B. Before the kernel.warn log line appeared on one of the APs, the speed was full 100 MBit/s. As soon I reboot the “kernel.warn”ing AP, the speed is 100 MBit again. bat0 is bridged to eth0.101 on both ends.

 
Sat Dec 28 14:50:04 2019 daemon.notice hostapd: wlan0-1: AP-ENABLED
Sat Dec 28 14:50:05 2019 kern.info kernel: [ 2416.392454] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Dec 28 14:50:05 2019 daemon.notice wpa_supplicant[16106]: Successfully initialized wpa_supplicant
Sat Dec 28 14:50:06 2019 kern.info kernel: [ 2417.755684] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Dec 28 14:50:06 2019 daemon.notice wpa_supplicant[16106]: Note: nl80211 driver interface is not designed to be used with ap_scan=2; this can result in connection failures
Sat Dec 28 14:50:06 2019 daemon.notice wpa_supplicant[16176]: wlan0: Trying to associate with SSID 'Permakultur'
Sat Dec 28 14:50:06 2019 kern.info kernel: [ 2417.950938] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2417.991646] ------------[ cut here ]------------
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2417.996394] WARNING: CPU: 0 PID: 16176 at /builder/shared-workdir/build/build_dir/target-mips_24kc_musl/linux-ath79_generic/ath10k-ct-2019-09-09-5e8cd86f/ath10k-4.19/mac.c:6598 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.016231] Modules linked in: ath9k ath9k_common pppoe ppp_async batman_adv ath9k_hw ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT 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 libcrc32c iptable_mangle iptable_filter ip_tables crc_ccitt compat br_netfilter ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos vfat fat ntfs nls_utf8 nls_iso8859_1 nls_cp437
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.088204]  usb_storage sd_mod scsi_mod ext4 mbcache jbd2 crc16 crc32c_generic crypto_hash ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.103218] CPU: 0 PID: 16176 Comm: wpa_supplicant Tainted: G        W       4.14.156 #0
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.111503] Stack : 000000f8 800b2a94 80500000 804af544 00000000 00000000 00000000 00000000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.120128]         00000000 00000000 00000000 00000000 00000000 00000001 853c59d8 ebe9a33e
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.128783]         853c5a70 00000000 00000000 00009378 00000038 80447958 00000008 00000000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.137442]         000001c9 6e8dd5be 000001c8 00000000 853c59b8 80000000 00000000 8704e480
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.146036]         8700bd24 000019c6 86310d28 87428800 00000003 8027f944 00000000 80630000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.154570]         ...
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.157183] Call Trace:
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.157198] [<800b2a94>] 0x800b2a94
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.163293] [<80500000>] 0x80500000
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.166873] [<80447958>] 0x80447958
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.170485] [<8700bd24>] 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.176813] [<8027f944>] 0x8027f944
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.180352] [<8006a56c>] 0x8006a56c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.184017] [<8006a574>] 0x8006a574
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.187559] [<80084c20>] 0x80084c20
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.191102] [<8700bd24>] 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.197583] [<80084d08>] 0x80084d08
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.201136] [<80318194>] 0x80318194
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.204714] [<8700bd24>] 0x8700bd24 [ath10k_core@87000000+0x5d210]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.211078] [<87795f70>] 0x87795f70 [mac80211@87780000+0x6c280]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.217204] [<8772d0d0>] 0x8772d0d0 [cfg80211@87700000+0x363f0]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.223313] [<8772941c>] 0x8772941c [cfg80211@87700000+0x363f0]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.229530] [<8771ddc0>] 0x8771ddc0 [cfg80211@87700000+0x363f0]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.235711] [<80134f00>] 0x80134f00
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.239316] [<80350498>] 0x80350498
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.243000] [<803501ac>] 0x803501ac
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.246630] [<8034eb44>] 0x8034eb44
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.250375] [<8034f410>] 0x8034f410
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.253980] [<8034c9bc>] 0x8034c9bc
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.257540] [<8034e208>] 0x8034e208
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.261197] [<8034e6e4>] 0x8034e6e4
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.264845] [<802f7c1c>] 0x802f7c1c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.268386] [<8034bcf8>] 0x8034bcf8
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.271988] [<8034e308>] 0x8034e308
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.275625] [<802f7e7c>] 0x802f7e7c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.279170] [<800ac680>] 0x800ac680
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.282723] [<802f5f34>] 0x802f5f34
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.286301] [<802f6718>] 0x802f6718
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.289840] [<8034bdec>] 0x8034bdec
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.293390] [<802f681c>] 0x802f681c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.297024] [<8013fd78>] 0x8013fd78
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.300656] [<802fd5c0>] 0x802fd5c0
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.304252] [<802f8704>] 0x802f8704
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.307808] [<802f6718>] 0x802f6718
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.311405] [<8006f72c>] 0x8006f72c
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.314981] [<802f84a4>] 0x802f84a4
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.318624]
Sat Dec 28 14:50:06 2019 kern.warn kernel: [ 2418.320140] ---[ end trace b03503722668fd71 ]---
Sat Dec 28 14:50:07 2019 kern.info kernel: [ 2418.329016] wlan0: Selected IBSS BSSID [MAC] based on configured SSID
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0-1' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0-2' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0-3' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Network device 'wlan0' link is up
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' is enabled
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' has link connectivity
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' is setting up now
Sat Dec 28 14:50:07 2019 kern.info kernel: [ 2418.899578] batman_adv: bat0: Adding interface: wlan0
Sat Dec 28 14:50:07 2019 kern.info kernel: [ 2418.904876] batman_adv: bat0: Interface activated: wlan0
Sat Dec 28 14:50:07 2019 daemon.notice netifd: Interface 'nwi_mesh0' is now up
Sat Dec 28 14:50:08 2019 daemon.notice wpa_supplicant[16176]: wlan0: Associated with [MAC]


29.12.20192709Base systemBug ReportVery LowMediumUnable to connect wifi on mvebu platform with esp8266openwrt-19.07Unconfirmed Task Description

- Device problem occurs on mvebu platform - Linksys wrt3200acm Marvell 88W8964 802.11bgn wifi while trying to connect by esp8266
- Software versions OpenWrt 19.07

esp8266 is not getting dhcp address and even when trying to communicate with static IP it is not possible to acquire connection. esp8266 is unable to get access to the router. Same problem exists in openwrt 18.06

 


14.01.20202734Base systemBug ReportVery LowMediumOpkg update fails although router has enough memoryopenwrt-19.07Unconfirmed Task Description

19.07.0 running on WNDR3700v2, 32MB of memory. The machine is certainly not short on memory:

                total        used        free      shared  buff/cache   available
  Mem:          59560       26912       24108         956        8540       16564
  Swap:             0           0           0

Running “opkg update” a first time works fine. However, if I run “opkg update” a second time, it reports:

  Collected errors:
   * pkg_hash_add_from_file: Failed to open /var/opkg-lists/openwrt_routing: Out of memory.

After doing “rm /var/opkg-lists/openwrt_*”, everything works fine again.

15.01.20202740Base systemBug ReportVery LowMedium19.07 ath79 uclient-fetch defaults fail in IPv4-only en...openwrt-19.07Waiting on reporter Task Description

I have a TP-Link Archer C7 v2.0, that’s currently running the ath79 19.07. When trying to install other packages after the initial upgrade, ‘opkg update’ failed on each repository with a ‘wget’ error. I can work around this with the following commands:

mv /bin/uclient-fetch /bin/uclientfetch
echo '#!/bin/sh' > /bin/uclient-fetch
echo 'exec /bin/uclientfetch -4 !*' >> /bin/uclient-fetch
chmod 755 /bin/uclient-fetch

so I presume that it’s trying to operate in IPv6 mode first and failing. After running the commands above, subsequent ‘opkg update’ commands work without error.

Here’s a quick run to illustrate:

root@grdl:~# uclientfetch 'http://www.google.com/' 
Downloading 'http://www.google.com/'
Failed to establish connection
root@grdl:~# uclientfetch -4 'http://www.google.com/' 
Downloading 'http://www.google.com/'
Connecting to 172.217.3.100:80
Writing to 'index.html'

Download completed (11751 bytes)
root@grdl:~# uname -a
Linux grdl 4.14.162 #0 Mon Jan 6 16:47:09 2020 mips GNU/Linux
18.01.20202748Base systemBug ReportVery LowMediumPrinter no more receiving IP address since 19.07.0openwrt-19.07Waiting on reporter Task Description

Dear community,
Previously I had OpenWRT 18.06.5 in use and my printer (HP LaserJet Pro 400 M475dw) was connecting fine over 2.4 GHz WiFi and obtained an IP address of defined DHCP static leases.
I went to 19.07.0 by starting from scratch on the same Netgear R7800 hardware. Everything works fine except for the mentioned printer.
It connects to WiFi and is shown in the list of associated stations, but it doesn’t receive an IP. The syslog prints following two lines about every minute:
Sat Jan 18 13:12:19 2020 daemon.info dnsmasq-dhcp[20788]: DHCPDISCOVER(wlan1) 34:23:87:xx:xx:xx
Sat Jan 18 13:12:19 2020 daemon.info dnsmasq-dhcp[20788]: DHCPOFFER(wlan1) 192.168.1.128 34:23:87:xx:xx:xx

What I’ve tried so far:
- enable/disable static leases: same behavior
- enable/disable KRACK countermeasures: same behavior
- require/optional/disable 802.11w Management Frame Protection: with require and even with optional the printer would not connect to WiFi at all
- factory reset printer and try again: no difference

Additional info:
- I have no WPA3 packets installed or activated - just default firmware image obtained from OpenWRT. Only additional packet is luci-ssl (+dependencies)
- all other devices that connect to 2.4 GHz or 5 GHz get their IP addresses. Those are mobile phones, laptops, tablets, TV’s, Chromecast, vacuum robot...
- As well no problem with physically connected devices like NAS, VoIP phone base, home automation system
- Printer display shows WiFi is connected but IP is set to 169.254.60.37
- It doesn’t look like a WiFi issue, more like something is different with the DHCP server between 18.06.5 and 19.07.0

18.01.20202750Base systemBug ReportVery LowMediumWireless on Netgear WNDR3700v2 not workingopenwrt-19.07Unconfirmed Task Description

After upgrading my Netgear WNDR3700 v2 to 19.07 (ath79 target), the WiFi cards aren’t detected.

Here are the outputs of dmesg, logread, lsmod | grep ath, ls /sys/bus/pci/*, lspci -vnn; at the recommendation of PaulFertser in #openwrt, I tried echo -n 168c ff1d > /sys/bus/pci/drivers/ath9k/new_id, which resulted in some error messages in dmesg, but the WiFi interfaces still aren’t detected (wifi config produces an empty file).

With ar71xx target, wifi works; the cards seem to have a different http://p.0au.de/3393221e/, too. dmesg, logread, ls /sys/bus/pci/*.

21.01.20202759PackagesBug ReportVery LowMediumodhcpd IPv6 NDP + macOS don't play togetheropenwrt-19.07Unconfirmed Task Description

My device: TP-Link Archer C7 v2.0 (JP)
My software stack: OpenWrt 19.07

My router uses odhcpd’s relay mode to relay IPv6 neighbor discovery protocol and router advertisements from the uplink router.

My linux-based system connected to the router is able to get IPv6 connectivity through the router without problems.

However, my macOS-based system doesn’t get IPv6 connectivity. It gets a global IPv6 prefix, which suggests that it’s able to receive RA packets, but my router is also unable to ping6 the macOS system by it’s globally unique address, and doing ip -6 neigh on the router makes it clear that the router doesn’t know the MAC address of the macOS system, and all of it’s probes to find it, end up failing.

Inspecting the ICMPv6 traffic in the LAN shows that my macOS system doesn’t respond to the neighbor solicitation packets send by the router. Here’s an example of such a packet:

02:28:50.006540 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fd26:e9f1:e833::1 > ff02::1:ff65:88f8: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has 2404:7a80:9621:7100:404:978a:5765:88f8

  source link-address option (1), length 8 (1): 18:a6:f7:8d:c0:d3

Here, fd26:e9f1:e833::1 is the ULA of the LAN interface of the router.

According to Apple discussion board ( https://discussions.apple.com/thread/8620806 ) macOS seems to have a behaviour such that it ignores neighbor solicitation packets unless the source address of the packet is a link-local address.

Indeed, commenting out option ula_prefix in /etc/config/network makes odhcpd to use link-local addresses, and that makes macOS to respond to neighbor solicitation queries, and in my system, demonstrably restores IPv6 connectivity.

Since macOS is a very common operating system, it would be benefical if odhcpd’s default behaviour were to use LLA in NDP packets. The current situation of not being able to set ULA prefix without losing connectivity is unfortunate. (And I think that ULA prefix is set by default in OpenWRT, which makes macOS not play together with it by default.)

For reference, here’s a forum thread I documented my forays into inspecting this problem: https://forum.openwrt.org/t/how-to-send-icmp6-neighbor-solicitation-with-a-link-local-source-address/53220

Could the default source address of odhcpd’s NDP/RA packets be changed to LLA?

24.01.20202774ToolchainBug ReportVery LowMediumimagebuilder breaks in long pwdopenwrt-19.07Unconfirmed Task Description

I have a directory where I keep imagebuilder. I can sucessfully build custom images there for d-link/dir-825, xiaomi/mini, tp-link/wr842nd_v1 and linksys/wrt1900ac. But trying to create default image for ar71xx/mikrotik gives error:

...
Successfully writed 13 blocks and 1757184 bytes
Each block contain 64 chanks + 0 bytes tail hole.
Each chunk(2112 bytes) consists: data part(2048 bytes) + oob part(64 bytes).
mv: cannot stat '/mydir/openwrt/imagebuilder/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin.new': No such file or directory
make[3]: *** [Makefile:71: /mydir/openwrt/imagebuilder/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin] Error 1
make[2]: *** [Makefile:169: build_image] Error 2
make[1]: *** [Makefile:120: _call_image] Error 2
make: *** [Makefile:197: image] Error 2

It can be reproduced:

% mkdir /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
% cd /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
% wget https://downloads.openwrt.org/releases/19.07.0/targets/ar71xx/mikrotik/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64.tar.xz
% tar xf openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64.tar.xz
% cd openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64
% make image PROFILE=nand-large
...
1671656 bytes (1.7 MB, 1.6 MiB) copied, 0.00693055 s, 241 MB/s
Can't get lstat from kernel file!: No such file or directory
make[3]: *** [Makefile:71: /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin] Error 255
make[2]: *** [Makefile:169: build_image] Error 2
make[1]: *** [Makefile:120: _call_image] Error 2
make: *** [Makefile:197: image] Error 2
zsh: exit 2     make image PROFILE=nand-large
25.01.20202775KernelBug ReportVery LowMediumUpgrade to 19.07 breaks wireless on AR9 SoC (dwc2 USB i...openwrt-19.07Unconfirmed Task Description

Upgrading Lantiq xway AR9 board (zyxel_p-2601hn) to version 19.07 will break wireless radio due to dwc2 USB driver HANG! issue in kernel 4.19.

Wifi works fine on 18.06 (kernel 4.9).

[    3.989707] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found, using dummy regulator
[    3.996765] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found, using dummy regulator
[    4.005083] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset GRSTCTL=80000001
[    4.147874] dwc2 1e101000.usb: DWC OTG Controller
[    4.151186] dwc2 1e101000.usb: new USB bus registered, assigned bus number 1
[    4.158253] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[    4.163552] dwc2 1e101000.usb: startup error -517
[    4.168125] dwc2 1e101000.usb: USB bus 1 deregistered
[    4.173284] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
29.01.20202781Base systemBug ReportVery LowMediumArcher C50 v4 Mac80211 Looses Internet Access after 20’...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

 

Problem Device:
TP-Link Archer C50 (Canadian) v4 + v4.2

Software version:
openwrt 19.07 r10860, default packages versions.

Steps to reproduce:
Setup wireless like below. I’ve intentionally left encryption set to “none” for both radio’s for quick testing but i’ve tested with WPA2 CCMP encryption with no change in results.

config wifi-device ‘radio0’ option type ‘mac80211’ option channel ‘11’ option hwmode ‘11g’ option path ‘platform/10300000.wmac’ option htmode ‘HT20’ option legacy_rates ‘0’ option country ‘CA’

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

config wifi-device ‘radio1’ option type ‘mac80211’ option hwmode ‘11a’ option path ‘pci0000:00/0000:00:00.0/0000:01:00.0’ option htmode ‘VHT80’ option channel ‘112’ option legacy_rates ‘0’ option country ‘CA’

config wifi-iface ‘default_radio1’ option device ‘radio1’ option network ‘lan’ option mode ‘ap’ option ssid ‘OpenWrt’ option encryption ‘none’

Alternative Settings:

htmode ‘HT40’ No change in results
channel ‘1’, ‘6’, ‘11’ No change in results
disassoc_low_ack ‘0’ No change in results

04.02.20202806Base systemBug ReportVery LowMediumDHCP enabled even though not present in config fileopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on : Mikrotik RBM33G
- Software versions of OpenWrt/LEDE release, packages, etc: OpenWrt 19.07, synced this morning, fully up-to-date
- Steps to reproduce: no idea
My “Lan” /etc/config/network:
config interface ‘lan’

      option type 'bridge'
      option ifname 'eth0.1'
      option proto 'static'
      option netmask '255.255.255.0'
      option gateway '10.0.0.254'
      option ipaddr '10.0.0.35'
      list dns '10.0.0.5'
      list dns '10.10.0.5'
      option ip6assign '60'

My “Lan in /etc/config/dhcp:
config dhcp ‘lan’

      option interface 'lan'
      option ignore '1'

My ip addr list:
25: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000

  link/ether cc:2d:e0:5a:b8:5b brd ff:ff:ff:ff:ff:ff
  inet 10.0.0.35/24 brd 10.0.0.255 scope global br-lan
     valid_lft forever preferred_lft forever
  inet 10.0.0.124/24 brd 10.0.0.255 scope global secondary br-lan
     valid_lft forever preferred_lft forever
  inet6 2a02:1802:a6:0:8a00:dfc6:fd71:a219/64 scope global dynamic
     valid_lft 2591708sec preferred_lft 604508sec
  inet6 fe80::6617:aede:f2cc:dd4/64 scope link
     valid_lft forever preferred_lft forever
  inet6 fe80::ce2d:e0ff:fe5a:b85b/64 scope link
     valid_lft forever preferred_lft forever

DHCP lease info from DHCP server:
LAN 10.0.0.124 cc:2d:e0:5a:b8:5b 2020/02/04 10:23:54 2020/02/04 18:23:54 ethernet
LAN 10.0.0.125 cc:2d:e0:5a:b8:5b 2020/02/04 10:23:56 2020/02/04 18:23:56 ethernet
... it does not listen to 10.0.0.125, though.

The device also sends traps to the trap server using 10.0.0.124, which is not registered in DNS (the reason why I detected it)

Maybe a bug in the config scripts somewhere?

04.02.20202807Base systemBug ReportVery LowMedium(Wavlink WL-WN575A3) Signal strength LEDs don't work - ...openwrt-19.07Unconfirmed Task Description

Wavlink WL-WN575A3, Openwrt 19.07
Clean install set signal LEDs to rssi trigger but any of 3 LEDs don’t light due to missing rssileds package in default set of packages. After manual rssileds package install all 3 signal LEDs works as expected.

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

Default configuration for PPPoE client is not properly set.

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

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

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

07.02.20202820Base systemBug ReportVery LowMediumath79 19.07.x always creates an interface with 192.168....openwrt-19.07Unconfirmed Task Description

Hi!

I have a TP-Link Archer-C7-V2 device. I installed via tftp the factory.bin file for 19.07.1, and changed the br-lan IP address to 192.168.0.1. After installing some packages and rebooting, the lan side switch interface was given the address 192.168.1.1, despite the WAN interface getting 192.168.1.11 from an upstream router via DHCP. This does not happen with ar71xx 19.07.1. I’ve remained on the ar71xx version.

I’ve attached the output from several show interface config commands for both ath79 and ar71xx. Since I rsync the entire router filesystem to my Linux system, I’ve also included a recursive diff of the ‘rom’ directories for both ath79 and ar71xx if that helps. In the diff output, for smaller size and better clarity, I removed the diff output for ‘.control’ files in opkg/info that only differed in kernel dependency and/or installed size.

08.02.20202822Base systemBug ReportVery LowMediumsysupgrade does not work with coreutils sha256sumopenwrt-19.07Unconfirmed Task Description

When running sysupgrade backup, checksum generation fails as per below if having installed coreutils version of sha256sum as it doesn’t recognize the -s flag.

OpenWrt 19.07-SNAPSHOT r10906-3212290a3b

# sha256sum –version
sha256sum (GNU coreutils) 8.30

# sysupgrade -b /root/backup-${HOSTNAME}-$(date +%F).tar.gz
sha256sum: invalid option – ‘s’ Try ‘sha256sum –help’ for more information.
[...]
sha256sum: invalid option – ‘s’ Try ‘sha256sum –help’ for more information.
Saving config files...

15.02.20202834Base systemBug ReportVery LowMediumXiaomi 3G restartsopenwrt-19.07Unconfirmed Task Description

Xiaomi Mi Router 3G
MediaTek MT7621 ver:1 eco:3
OpenWrt 19.07.0 r10860-a3ffeb413b / LuCI openwrt-19.07 branch git-20.006.26738-35aa527
4.14.162

I have script that heavily uses ipset in cron. It runs every hour. Router reboots every 1~2 days with errors.

Sat Feb 15 12:00:00 2020 cron.info crond[1212]: USER root pid 9019 cmd /etc/anti-rkn/update-rkn-ip.sh
Sat Feb 15 12:00:03 2020 kern.alert kernel: [215985.710616] CPU 3 Unable to handle kernel paging request at virtual address 07406000, epc == 8010ef74, ra == 8010ee58
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.721315] Oops[#1]:
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.723668] CPU: 3 PID: 9028 Comm: ipset Not tainted 4.14.162 #0
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.729733] task: 8fcf2ca0 task.stack: 8dc22000
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.734325] $ 0   : 00000000 00000001 00000000 81243690
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.739624] $ 4   : 8054a1e8 00000001 00000001 07406000
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.744920] $ 8   : 000d3937 000d3936 00000000 00000001
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.750217] $12   : 000d3923 8df80280 8df80280 00000000
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.755514] $16   : 8fc02e00 01088020 8df80000 8d5e3880
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.760814] $20   : 00000008 8dcb8e98 00000038 00000000
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.766112] $24   : 00000000 77e75860
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.771410] $28   : 8dc22000 8dc23a28 8e125800 8010ee58
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.776710] Hi    : 00000000
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.779660] Lo    : 0000000a
Sat Feb 15 12:00:03 2020 kern.warn kernel: [215985.782611] epc   : 8010ef74 0x8010ef74
packet_write_wait: Connection to 192.168.1.1 port 22: Broken pipe
 

The script

start=`date +%s`

# create temporary sets
ipset create _tmp1 hash:net
ipset create _tmp2 hash:net

# load new content to ipset
curl -s https://antifilter.download/list/subnet.lst | awk '{print "add _tmp1 "$1;} END {print FNR > "/tmp/rkn_nets"}' | ipset -! restore
curl -s https://antifilter.download/list/ipsum.lst| awk '{print "add _tmp2 "$1;} END {print FNR > "/tmp/rkn_ipsum"}' | ipset -! restore

# swap content
ipset swap vpn_subnets _tmp1
ipset swap vpn_ipsum _tmp2

# delete temporary sets
ipset destroy _tmp1
ipset destroy _tmp2

end=`date +%s`


09.10.20192541KernelBug ReportMediumLowHardware offloading causes some flows to fail to be NAT...openwrt-19.07New Task Description

Just after a reboot, some flows are not NATed: packets from a machine in the LAN are sent to the WAN port with a private source IP address.

This is on a Linksys RE6500 (ramips mt7621) running openwrt 19.07-SNAPSHOT r10578-b3d70f628.
It is configured with flow_offloading and flow_offloading_hw.

Here is a tcpdump capture showing the problem on the WAN port (172.23.184.0/24 is my LAN address space):

root@openwrt:~# tcpdump -n -i eth0.20 net 172.23.184.0/24
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0.20, link-type EN10MB (Ethernet), capture size 262144 bytes
18:51:21.756552 IP 172.23.184.119.51001 > 91.224.XX.YY.52001: UDP, length 112
18:51:22.651556 IP 172.23.184.119.51001 > 91.224.XX.YY.52001: UDP, length 148
18:51:26.681032 IP 172.23.184.119.51001 > 91.224.XX.YY.52001: UDP, length 768
18:51:27.771654 IP 172.23.184.119.51001 > 91.224.XX.YY.52001: UDP, length 148

Here is what conntrack -L says:

udp      17 55 src=172.23.184.119 dst=91.224.XX.YY sport=51001 dport=52001 packets=93 bytes=20412 [UNREPLIED] src=91.224.XX.YY dst=172.23.184.119 sport=52001 dport=51001 packets=0 bytes=0 mark=0 use=1

Notice the second dst= that shows the private IP address of the LAN machine.

After restarting the firewall, the flow is correctly NAT-ed and conntrack -L shows the correct entry (193.33.ZZ.WW is my public IP address):

udp      17 175 src=172.23.184.119 dst=91.224.XX.YY sport=51001 dport=52001 packets=4 bytes=704 [UNREPLIED] src=91.224.XX.YY dst=193.33.ZZ.WW sport=52001 dport=51001 packets=0 bytes=0 mark=0 use=1

Note: when I only enable flow_offloading, the issue does not appear anymore, so this really seems to be an issue with the hw offloading integration in the firewall.

16.11.20192607PackagesBug ReportVery LowLowodhcpd: assigns IPv4 address outside of interface subne...openwrt-19.07Unconfirmed Task Description

When a static IPv4 lease is set up for a MAC address, odhcpd assigns that address even if it is outside the configured subnet of the relevant interface.

This is a problem if one wants to set a static lease for a host that may connect to one of multiple interfaces. It is also not possible to set separate static leases for each interface, as only the last one is used.

Software versions of OpenWrt/LEDE release, packages, etc:

Trunk and 19.07.
18.06 is unaffected.

It looks like this was introduced with https://git.openwrt.org/?p=project/odhcpd.git;a=commit;h=ca8ba91c757b1559bc6391707547d54477c8315a.

Steps to reproduce:

Steps based on fresh install of OpenWrt:

Replace odhcpd-ipv6only by odhcpd

Enable odhcpd for IPv4 and set static lease with IPv4 address outside the default lan subnet:

uci set dhcp.odhcp.maindhcp=1
uci set dhcp.lan.dhcpv4="server"

uci add dhcp host
uci set dhcp.@host[-1].mac="11:22:33:44:55:66"
uci set dhcp.@host[-1].ip="192.168.2.100"

uci commit dhcp

Expected result: IP address from 192.168.1.0/24 is assigned to host 11:22:33:44:55:66
Actual result: IP address 192.168.2.100 is assigned to host 11:22:33:44:55:66

17.11.20192608Base systemBug ReportVery LowLowsysntpd cannot acquire time on IPv6 only networkopenwrt-19.07Unconfirmed Task Description

I’ve encountered an issue with ntpd in OpenWrt where it cannot acquire the time on an IPv6 only network, it seems that the issue lies in dns resolution by ntpd as specifying an IPv6 address instead of a domain works as expected.

By the way, I believe only 2.pool.ntp.org returns IPv6 addresses in case anyone tries to reproduce my issue.

Possibly relevant: https://dev.archive.openwrt.org/attachment/ticket/12167/0001-busybox-make-ntpd-prefer-IPv6-addresses.patch

28.11.20192640Base systemBug ReportVery LowLowFailed to sync jffs2 overlayopenwrt-19.07Unconfirmed Task Description

GL-B1300
19.07-SNAPSHOT

Every time I run a sys upgrade I get “failed to sync jffs2 overlay” message in the log (log is configured during the setup by a custom script under /etc/uci-defaults). The error happens during execution of the command: “cp -a /tmp/root/upper/* / 2>/dev/null” in “libfstools/overlay.c”. By the time the copy command runs, the files under /etc/uci-defaults are already deleted and it looks like the “deletion marker” files cannot be copied in this case.

I re-run the command myself after a successful upgrade and got the following logs.

cp -a /tmp/root/upper/* /root/test/
cp: can’t create ‘/root/test/etc/uci-defaults/luci-sqm’: Operation not permitted
cp: can’t create ‘/root/test/etc/uci-defaults/ddns’: Operation not permitted
cp: can’t create ‘/root/test/etc/uci-defaults/bcp38’: Operation not permitted

ls -la /tmp/root/upper/etc/uci-defaults/
c——— 1 root root 0, 0 Nov 26 16:48 bcp38
c——— 1 root root 0, 0 Nov 26 16:48 ddns
c——— 1 root root 0, 0 Nov 26 16:48 luci-sqm

More details: https://forum.openwrt.org/t/getting-error-failed-to-sync-jffs2-overlay/47742


01.12.20192644Base systemBug ReportVery LowLowdnsmasq-full: Cannot satisfy dependenciesopenwrt-19.07Unconfirmed Task Description

Environment:
arch: mips
model: TP-link WDR4300
Openwrt: 19.07.0-rc1

Description:
I probably overlooked but hit the following issue where unable to install dnsmasq-full. Actually downloading only already gives the following warning and wonder if I can/should force-install:

# opkg install dnsmasq-full --download-only
Downloading http://downloads.openwrt.org/releases/19.07.0-rc1/packages/mips_24kc/base/dnsmasq-full_2.80-14_mips_24kc.ipk
Collected errors:
 * satisfy_dependencies_for: Cannot satisfy the following dependencies for dnsmasq-full:
 * 	kernel (= 4.14.151-1-342af9e4f67b3447c53216ab8e3b12a1)
 * opkg_install_cmd: Cannot install package dnsmasq-full.
03.12.20192650Base systemBug ReportVery LowLowr7800 19.07-rc2 unable to change channel for ACopenwrt-19.07Waiting on reporter Task Description

- Device problem occurs on - Linux r7800 4.14.156 #0 SMP Sat Nov 30 15:52:33 2019 armv7l GNU/Linux
- Software versions of OpenWrt/LEDE release - 19.07-rc2

in Luci when change channel number change actually never gets committed, when do manually in /etc/config/wireless and then reboot router comes up with 5GHz network disabled, after changing back to default channel 36 5GHz network is usable again.

please provide steps to collect log

in dmesg only:

(wlan0) entered blocking state
(wlan0) entered disabled state
   
04.12.20192651KernelBug ReportVery LowLowOut of memory errors with 5 GHz Wi-Fi enabledopenwrt-19.07Waiting on reporter Task Description

- Device problem occurs on Archer C60 V2
- Software versions: Powered by LuCI Master (git-19.337.71995-796301a) / OpenWrt SNAPSHOT r11618-416d2cc71e

I’ve installed via TFTP “openwrt-19.07.0-rc2-ath79-generic-tplink_archer-c60-v2-squashfs-factory.bin” but because of some “out of memory” errors, i’ve upgraded to “openwrt-ath79-generic-tplink_archer-c60-v2-squashfs-sysupgrade.bin” in the hope of solving.
The problems continued, so i wrote to forum (https://forum.openwrt.org/t/tp-link-archer-c60-v2-19-07-0-rc2-ath79-snapshot-out-of-memory/49725) and i saw that other users had the same problem that they solved by disabling 5 Ghz.
Disabling the 5Ghz actually “out of memory” problems disappear. I was also able to install additional packages without problem.

 


Showing tasks 1 - 50 of 1003 Page 1 of 211 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing