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
16.03.20192191Base systemBug ReportVery LowMediumTP-Link WBS210 Images brokenopenwrt-19.07Unconfirmed Task Description

I cannot install the 18.06.1 and 18.06.2 Images on my TP-Link WBS210. For the openwrt-18.06.x-ar71xx-generic-wbs210-v1-squashfs-sysupgrade.bin image I get the message:

“The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform.”

Up to version 18.06.0 everything worked fine.

28.03.20192208KernelBug ReportVery LowMediumUAS support for USB3.0 drivesopenwrt-19.07Unconfirmed Task Description

UAS module is loaded fine on Linksys WRT3200ACM with openwrt 18.06 but when plugging a USB 3.0 drive (for example a USB 3.0 external HDD) it does not load in the right way and device ends using driver usb-storage, which prevents of using device at full speed.

Steps to reproduce: Plug a USB 3.0 external HDD to USB 3.0 port of any openwrt 18.06 device and check speed when copying a file to the external HDD, it should be around 100+ MBps

Any needed additional info can be found at this forum question: https://forum.openwrt.org/t/usb3-0-hdd-issues/34031/13


07.10.20192537Base systemBug ReportVery LowMediumAth9k on Archer C7 v2: disassociated due to inactivityopenwrt-19.07Unconfirmed Task Description

Hello

Every few weeks I have to restart the 2.4 GHz radio or reboot my Archer C7 v2 router otherwise no client can connect to it.
All stations end up being “deauthenticated due to inactivity” and can’t reconnect.

Tested on OpenWRT 18.06.4. It is quite hard to reproduce for me as it doesn’t happen frequently.

Forum post: https://forum.openwrt.org/t/ath9k-on-archer-c7-v2-disassociated-due-to-inactivity/13328

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

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
29.01.20202781Base systemBug ReportLowMediumArcher C50 v4 Mac80211 Looses Internet Access after 20’...openwrt-19.07New 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`


06.03.20202885Base systemBug ReportVery LowMediumx86/x64 musl crash in 19.07.01openwrt-19.07Unconfirmed Task Description

Any program built statically with SDK 19.07.01 for x86/64 coredumps at musl init stage

Program received signal SIGSEGV, Segmentation fault.
static_init_tls (aux=0xffffd408) at src/env/__init_tls.c:92
92      src/env/__init_tls.c: No such file or directory.
(gdb) bt
#0  static_init_tls (aux=0xffffd408) at src/env/__init_tls.c:92
#1  0x08083ed2 in __init_libc (envp=0xffffd53c, pn=0xffffd69d "/home/k/openwrt/sdk-x86/build_dir/target-i386_pentium4_musl/ntfs-3g-2017.3.23-2-fuseint/src/ntfs-3g") at src/env/__libc_start_main.c:39
#2  0x08083fe0 in __libc_start_main (main=0x80490e8 <main>, argc=1, argv=0xffffd534) at src/env/__libc_start_main.c:79
#3  0x08049f19 in _start_c (p=0xffffd530) at crt/crt1.c:18
#4  0x08049ef0 in _start ()
24.03.20202925KernelBug ReportVery LowMediumsdc_busy timeout: before CMD<55> <- msdc_command_start(...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on:
Architecture: MediaTek MT7621 ver:1 eco:3
Model: MTC Wireless Router WR1201
Router brand: Strong 1200
- Software versions of OpenWrt/LEDE release, packages, etc.:
OpenWrt 19.07.0 r10860-a3ffeb413b / LuCI openwrt-19.07 branch git-20.006.26738-35aa527
Packages installed:
kmod-mmc 4.14.162-1
kmod-sdhci-mt7620 4.14.162-1
kmod-mt76-core 4.14.162+2020-01-04-8a785679-1
kmod-usb-core 4.14.162-1
kmod-usb3 4.14.162-1
Kernel 4.14.162
- Steps to reproduce

Problem is that microSD card is not recognized. After inserting the microsd card this is shown in logs. I try three vendors. example brand new SanDisk microSDHC 32 GB Ultra Class 10 UHS-I
[ 1763.831968] msdc0 → XXX sdc_busy timeout: before CMD<55> ← msdc_command_start() : L<860> PID<kworker/0:1><0×39>
[ 1763.852517] mmc0: error -145 whilst initialising SD card
[ 1764.131968] msdc0 → XXX sdc_busy timeout: before CMD<55> ← msdc_command_start() : L<860> PID<kworker/0:1><0×39>
[ 1764.152467] mmc0: error -145 whilst initialising SD card
[ 1764.431965] msdc0 → XXX sdc_busy timeout: before CMD<55> ← msdc_command_start() : L<860> PID<kworker/0:1><0×39>
[ 1764.452549] mmc0: error -145 whilst initialising SD card

 


01.04.20202956KernelBug ReportVery LowMediumtcp_bbr: suffering poor performance with samba4-serveropenwrt-19.07Unconfirmed Task Description

Environment: Newifi-D2(arch mipsel_24kc), OpenWrt 19.07.1/19.07.2/master branch with kernel 1.14.170+, samba-4.11, a usb-disk with ext4 file system.
(samba4 uses default settings)

I run samba-4.11 server in my router with usb-harddisk of 3T volumes. If the router enables tcp_bbr kernel module with default config file, then lan PCs copying files from the router is very slowly with speed of 4-10MB. The speed of writing files to router’s share is also a little slower.
Without tcp_bbr the speed is up to 40-60MB when copying files from the router.

I found the problem is caused by lack value of “net.core.default_qdisc=fq” in default bbr config file (/etc/sysctl.d/12-tcp-bbr.conf)
The default bbr config file is :
```
# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings

net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq #add this line then problem disappear.
```


03.04.20202957ToolchainBug ReportVery LowMediumopenwrt 19.07 x86_64 sdk toolchain segmentation fault i...openwrt-19.07Unconfirmed Task Description

Hi guys:

I found that the toolchain of openwrt 19.07 has some issues on x86_64 platform.

For example:
1. I use this sdk to build openwrt-shadowsocks 2. Install the compiled ipk, run the command `ss-local`, will report a `segmentation fault` error.

This error only occurs on openwrt 19.07 x86_64 platform. 19.07 toolchain on other platforms does not have this error, and the 18.06 version of the toolchain on the x86_64 platform also has no such errors.

04.04.20202961PackagesBug ReportVery LowMediumRsyslog doesn't create spool nor disk-assisted queue fi...openwrt-19.07Unconfirmed Task Description

- Device problem occurs on

TP-Link TL-WR1043ND v2
TP-LINK TD-W8970

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

openwrt-19.07 branch git-20.093.48508-e2aaef6
rsyslogd 8.39.0

- Steps to reproduce
The first issue is that rsyslog doesn’t write to or create directories/files inside the /var/log directory beside the log files.
needed to create a work directory for spool and disk-assisted queue files.
using

$CreateDirs on

and

$WorkDirectory /var/log/rsyslog

I get

Apr  2 10:35:34 OpenWrt : $WorkDirectory: /var/log/rsyslog can not be accessed, probably does not exist - directive ignored [v8.39.0 try http://www.rsyslog.com/e/2181 ]

I created the directory manually and the error was gone but the directory remained empty even after disconnecting the log server for 24hrs, no spool files were created nor disk-assisted queue files were created either and as a result when connecting the server back after 24hrs the in-memory queue got sent to the server which equals roughly to 10min worth of logs while the WorkDirectory /var/log/rsyslog remained empty.

04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:22:19 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:22:52 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:23:25 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:23:58 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:24:32 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:25:05 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:25:38 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:26:11 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:26:44 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:27:17 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:27:50 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:28:23 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:28:57 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:29:30 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Info	192.168.1.1	Apr  4 08:29:45 OpenWrt : -- MARK --
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:30:03 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:30:36 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:31:09 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:31:42 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Error	192.168.1.1	Apr  4 08:32:15 OpenWrt : cannot connect to 192.168.1.100:514: Host is unreachable [v8.39.0 try http://www.rsyslog.com/e/2027 ]
04-04-2020	10:32:45	Syslog.Info	192.168.1.1	Apr  4 08:32:45 OpenWrt : action 'action-13-builtin:omfwd' resumed (module 'builtin:omfwd') [v8.39.0 try http://www.rsyslog.com/e/2359 ]

even when using /var/log directly as a WorkDirectory the results remained the same.

The second issue is that for a work around I tried using the imfile module to access the log files directly without the need to disk-assisted queues but got this error

Apr  3 22:16:18 OpenWrt : could not load module 'imfile', errors: trying to load module /usr/lib/rsyslog/imfile.so: Error loading shared library /usr/lib/rsyslog/imfile.so: No such file or directory [v8.39.0 try http://www.rsyslog.com/e/2066 ]
11.04.20202993Base systemBug ReportVery LowMediumArcher C7 v2 5GHz radio doesn't receive DHCPACKopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:

Device problem occurs on

  • Archer C7 V2 (eu)

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

Affects versions:

  • 19.07.0
  • 19.07.2

Tested working

  • 18.06.2
  • 18.06.8

Steps to reproduce

  1. Clean flash of 19.x sysupgrade image
  2. Enable 5ghz AP with default settings
  3. Connect to 5ghz with client

Observed Behaviour:

  • Client can authenticate
  • DHCP handshake initiated but not completed

Other notes:

  • If client also connected by ethernet, DHCPACK is received and connection successful. Client continues to have network access over wifi for ~15 seconds after disconnecting ethernet, then disassociates. See log #2.
  • Noticed 5ghz AP non-functional while investigating different issue where all 2.4g clients dropped until radio restarted.
  • Hopefully this is helpful, I am not sure how to debug any deeper than this.

Log 1 - logread during client connection attempts

	Sat Apr 11 11:10:21 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc IEEE 802.11: authenticated
	Sat Apr 11 00:28:20 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:20 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:20 2020 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:20 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc IEEE 802.11: disassociated
	Sat Apr 11 00:28:21 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
	Sat Apr 11 00:28:22 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc IEEE 802.11: authenticated
	Sat Apr 11 00:28:22 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc IEEE 802.11: associated (aid 2)
	Sat Apr 11 00:28:22 2020 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:22 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc WPA: pairwise key handshake completed (RSN)
	Sat Apr 11 00:28:24 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:24 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:27 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:27 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:31 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:31 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:39 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:39 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:47 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:47 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:56 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:28:56 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:04 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:04 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:13 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:13 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:21 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:21 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:40 2020 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:40 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc IEEE 802.11: disassociated
	Sat Apr 11 00:29:41 2020 daemon.info hostapd: wlan1: STA 6c:40:08:9f:5b:bc IEEE 802.11: authenticated
	Sat Apr 11 00:29:41 2020 daemon.info hostapd: wlan1: STA 6c:40:08:9f:5b:bc IEEE 802.11: associated (aid 8)
	Sat Apr 11 00:29:41 2020 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:41 2020 daemon.info hostapd: wlan1: STA 6c:40:08:9f:5b:bc WPA: pairwise key handshake completed (RSN)
	Sat Apr 11 00:29:41 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
	Sat Apr 11 00:29:42 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:42 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:43 2020 daemon.info dnsmasq-dhcp[7552]: DHCPREQUEST(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc
	Sat Apr 11 00:29:43 2020 daemon.info dnsmasq-dhcp[7552]: DHCPACK(br-lan) 192.168.12.240 6c:40:08:9f:5b:bc Scotts-MBP 

Log 2 - logread during connection with ethernet & subsequent disconnect

	Sat Apr 11 11:11:26 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc IEEE 802.11: authenticated
	Sat Apr 11 11:11:26 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc IEEE 802.11: associated (aid 1)
	Sat Apr 11 11:11:26 2020 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 6c:40:08:9f:5b:bc
	Sat Apr 11 11:11:26 2020 daemon.info hostapd: wlan0: STA 6c:40:08:9f:5b:bc WPA: pairwise key handshake completed (RSN)
	Sat Apr 11 11:12:36 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 5c:f7:e6:8b:bc:84
	Sat Apr 11 11:12:36 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.154 5c:f7:e6:8b:bc:84
	Sat Apr 11 11:12:36 2020 daemon.info dnsmasq-dhcp[7552]: DHCPDISCOVER(br-lan) 5c:f7:e6:8b:bc:84
	Sat Apr 11 11:12:36 2020 daemon.info dnsmasq-dhcp[7552]: DHCPOFFER(br-lan) 192.168.12.154 5c:f7:e6:8b:bc:84
	Sat Apr 11 11:12:37 2020 daemon.info dnsmasq-dhcp[7552]: DHCPREQUEST(br-lan) 192.168.12.154 5c:f7:e6:8b:bc:84
	Sat Apr 11 11:12:37 2020 daemon.info dnsmasq-dhcp[7552]: DHCPACK(br-lan) 192.168.12.154 5c:f7:e6:8b:bc:84 Scotts-MBP
	Sat Apr 11 11:12:45 2020 daemon.info dnsmasq-dhcp[7552]: DHCPRELEASE(br-lan) 192.168.12.154 5c:f7:e6:8b:bc:84 
13.04.20203006PackagesBug ReportVery LowMediumdnsmasq-full fails to resolve Cloudflare domains if DNS...openwrt-19.07Unconfirmed Task Description

dnsmasq fails to resolve Cloudflare domains if DNSSEC is enabled.

# ping www.galeria.de
ping: bad address 'www.galeria.de'

# nslookup www.galeria.de
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find www.galeria.de: SERVFAIL
Name:      www.galeria.de
www.galeria.de  canonical name = www.galeria.de.cdn.cloudflare.net

/etc/config/dhcp

# cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option expandhosts '1'
        option nonegcache       0
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option domain 'fritz.box'
        option local '/box/'
        option nonegcache '0'
        option dnssec '1'
        option dnsseccheckunsigned '1'
        option logqueries '1'
        option logfacility '/tmp/dnsmasq.log'

config dhcp 'lan'
        option interface 'lan'
        option limit '150'
        option leasetime '12h'
        option dhcpv6 'server'
        option ra 'server'
        option start '2'
        option ra_management '1'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1

This is the generated dnsmasq configuration file

# cat /var/etc/dnsmasq.conf.cfg01411c
# auto-generated config file from /etc/config/dhcp
conf-file=/etc/dnsmasq.conf
dhcp-authoritative
domain-needed
log-queries=extra
localise-queries
read-ethers
enable-ubus
expand-hosts
bind-dynamic
local-service
log-facility=/tmp/dnsmasq.log
domain=fritz.box
server=/box/
dhcp-leasefile=/tmp/dhcp.leases
resolv-file=/tmp/resolv.conf.auto
stop-dns-rebind
rebind-localhost-ok
conf-file=/usr/share/dnsmasq/trust-anchors.conf
dnssec
dnssec-no-timecheck
dnssec-check-unsigned
dhcp-broadcast=tag:needs-broadcast
addn-hosts=/tmp/hosts
conf-dir=/tmp/dnsmasq.d
user=dnsmasq
group=dnsmasq

dhcp-ignore-names=tag:dhcp_bogus_hostname
conf-file=/usr/share/dnsmasq/dhcpbogushostname.conf

bogus-priv
conf-file=/usr/share/dnsmasq/rfc6761.conf
dhcp-range=set:lan,192.168.222.2,192.168.222.151,255.255.255.0,12h

For additional debugging I also compiled the dnsmasq package from https://github.com/openwrt/openwrt/tree/v19.07.2/package/network/services/dnsmasq on Linux (openSUSE Tumbleweed) and there dnsmasq works without problems.

# cat /etc/os-release | head -n2
NAME="openSUSE Tumbleweed"
# VERSION="20200410"
# sudo src/dnsmasq --version
Dnsmasq version 2.80  Copyright (c) 2000-2018 Simon Kelley
Compile time options: IPv6 GNU-getopt DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify dumpfile

This software comes with ABSOLUTELY NO WARRANTY.
Dnsmasq is free software, and you are welcome to redistribute it
under the terms of the GNU General Public License, version 2 or 3.

# nslookup www.galeria.de
Server:         127.0.0.1
Address:        127.0.0.1#53

Non-authoritative answer:
www.galeria.de  canonical name = www.galeria.de.cdn.cloudflare.net.
Name:   www.galeria.de.cdn.cloudflare.net
Address: 104.16.230.136
Name:   www.galeria.de.cdn.cloudflare.net
Address: 104.16.231.136

I use OpenWrt 19.07.2 r10947-65030d81f3 with dnsmasq-full - 2.80-16 on a Linksys 1900ACS router.

15.04.20203013KernelBug ReportVery LowMediumKernel Bugopenwrt-19.07Unconfirmed Task Description

Device: Mikrotik RB750Gr3
Software: OpenWrt 19.07.2 (with no default package updates yet)
Installed Packages: installed_packages.txt (attached)
How to reproduce: Unknown
Consequence: None. The device continues to operate normally.

I have removed personal information and some garbage from the log files.

Compass.

20.04.20203023Base systemBug ReportVery LowMediumWarning CPUopenwrt-19.07Unconfirmed Task Description

Device: Mikrotik RB750Gr3
Software: OpenWrt 19.07.2 (with no default package updates yet)
Installed Packages: installed_packages.txt (attached)
How to reproduce: Unknown
Consequence: None. The device continues to operate normally.

I have removed personal information and some garbage from the log files.

Compass.

22.04.20203034Base systemBug ReportVery LowMediumAMD Geode → OpenSSL no HW acceleration for CBC modeopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- System: PC Engines Alix Board 2d13
- Software: 19.07.2-x86-geode-combined-squashfs.img.gz

1. Install openssl utility along with library and optional libopenssl-afalg_sync engine (same problem with libopenssl-devcrypto)

2. HW accelerated encryption is available to kernel:

 cat /proc/crypto | grep geode
 driver       : ecb(geode-aes)
 driver       : cbc-aes-geode
 module       : geode_aes
 driver       : ecb-aes-geode
 module       : geode_aes
 driver       : geode-aes
 module       : geode_aes

3. But OpenSSL cannot use CBC mode and falls back to software encryption

 openssl speed -evp aes-128-cbc -engine afalg -elapsed
 dmesg output is full off:
 Error allocating fallback algo cbc(aes)

4. Using libopenssl-devcrypto instead of libopenssl-afalg_sync produces similar results but can employ ECB mode. AES-128-CBC is not available.


29.04.20203058Base systemBug ReportVery LowMediumPPPoE fails repeatedly; until rebootopenwrt-19.07Unconfirmed Task Description

I’m using the pre-built OpenWRT firmware for BT HomeHub 5a and am generally very happy with it. The problem that shows up is that every once in a while, the PPPoE connection goes down and stays down. I see in the log that the PPPoE is retried repeatedly but keeps failing. Disabling the corresponding interface and then re-enabling it (e.g. from LuCI) does not help (I do see that it takes the PPPoE and the DSL down and after a while the DSL comes back up but the PPPoE still keeps failing in the same way).

Rebooting fixes the issue, OTOH.

The system log repeats the following lines every 15 seconds or so:

Wed Apr 29 07:16:55 2020 daemon.notice netifd: Interface 'wan' is enabled
Wed Apr 29 07:16:55 2020 daemon.notice netifd: Interface 'wan' is setting up now
Wed Apr 29 07:16:55 2020 daemon.err insmod: module is already loaded - slhc
Wed Apr 29 07:16:55 2020 daemon.err insmod: module is already loaded - ppp_generic
Wed Apr 29 07:16:55 2020 daemon.err insmod: module is already loaded - pppox
Wed Apr 29 07:16:55 2020 daemon.err insmod: module is already loaded - pppoe
Wed Apr 29 07:16:55 2020 daemon.info pppd[13912]: Plugin rp-pppoe.so loaded.
Wed Apr 29 07:16:55 2020 daemon.info pppd[13912]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Wed Apr 29 07:16:55 2020 daemon.notice pppd[13912]: pppd 2.4.7 started by root, uid 0
Wed Apr 29 07:17:10 2020 daemon.warn pppd[13912]: Timeout waiting for PADO packets
Wed Apr 29 07:17:10 2020 daemon.err pppd[13912]: Unable to complete PPPoE Discovery
Wed Apr 29 07:17:10 2020 daemon.info pppd[13912]: Exit.
Wed Apr 29 07:17:10 2020 daemon.notice netifd: Interface 'wan' is now down
Wed Apr 29 07:17:10 2020 daemon.notice netifd: Interface 'wan' is disabled

I cannot reproduce it at will. The problem occurred more often (like once a week maybe) in the past and I thought it had magically been resolved since it hadn’t re-appeared for the last 2 months, but it happened again today.

root@router:~# opkg list_installed | grep ppp
kmod-ppp - 4.14.167-1
kmod-pppoa - 4.14.167-1
kmod-pppoe - 4.14.167-1
kmod-pppox - 4.14.167-1
luci-proto-ppp - git-20.029.45734-adbbd5c-1
ppp - 2.4.7.git-2019-05-25-2
ppp-mod-pppoa - 2.4.7.git-2019-05-25-2
ppp-mod-pppoe - 2.4.7.git-2019-05-25-2
root@router:~# 

I suspect the above info is not sufficient to find the problem, so at this point, I’m mostly looking for suggestions as to how to get more verbose logs, or commands to try and run parts individually

02.05.20203059Base systemBug ReportVery LowMediumDHCP options with spaces parsed incorrectlyopenwrt-19.07Unconfirmed Task Description

The following problem occurs on Archer C7 running 18.06, as well as an x86-64 VM running 19.07.02

I was attempting to PXE boot a Raspberry Pi, which requires setting DHCP option 43 to “Raspberry Pi Boot”. I tried to do this by including

config tag 'rpipxe'
	list dhcp_option '43,"Raspberry Pi Boot"'
	list dhcp_option '66,"192.168.1.180"'

in /etc/config/dhcp. However, the code in /etc/init.d/dnsmasq does not correctly parse DHCP options with spaces, leading to the following in the dnsmasq config file under /var/tmp

dhcp-option=tag:rpipxe,66,192.168.1.180
dhcp-option=tag:rpipxe,43,Raspberry
dhcp-option=tag:rpipxe,Pi
dhcp-option=tag:rpipxe,Boot

The attached patch to /etc/init.d/dnsmasq fixes the problem (but may not necessarily be the right fix).

09.05.20203080KernelBug ReportVery LowMediumramips/mt7621 Netgear R6220 WIFI 5 GHz issueopenwrt-19.07Unconfirmed Task Description

I am using a Netgear R6220 router. My router has one “bad erase block”

[    2.859177] Scanning device for bad blocks
[    2.952205] Bad eraseblock 361 at 0x000002d20000
[    3.116833] 6 fixed-partitions partitions found on MTD device MT7621-NAND

Every test is done with default settings. For me it is easier to debug this issue with openwrt in station mode, but it applies to AccessPoint/Master as well.

  • 2.4 GHz WIFI operation as expected
  • 5 GHz WIFI only affected
  • low throughput only in openwrt TX direction / openwrt RX direction OK
  • things got much worse with openwrt 19.07.02 → openwrt 18.06.08 was better
    This is why I suspect that it is related to FS#1926 - MTD partition offset not correctly mapped when bad eraseblocks present.
    This fix has been integrated in 19.07. I don’t want to revert this change, as this is the first version openwrt sets the correct MAC address.

Comarison of OpenWrt 18.06.08 and 19.07.02

  • OpenWrt 18.06.08: TX Power is set to 3dBm
  • OpenWrt 19.07.02: TX Power is set to 20dBm (default?)
  • In both cases/logs The “HT Mode is VHT80”
  • Changing the TX Power in 19.07.02 has no effect
    Resource is busy

My guess/conclusion is that

  • the calibration data is not taken into account (maybe it was never and openwrt 18.06 was just lucky)
  • The offset to read the calibration data has changed with openwrt 19.07.02. This is why things got worse (for me)

Attached is the mtd4.bin (factory). I don’t know if this helps for this issue.

OpenWrt 18.06.08

WIFI 5 GHz operation “normal”. Means I can use any channel in 5 GHz and get good performance/throughput.
Channel 36
TX ~80Mbit/s
RX ~95Mbit/s
Channel 124
TX ~80Mbit/s
RX ~95Mbit/s

iw --debug phy phy1 info
phy phy1
        max # scan SSIDs: 4
        max scan IEs length: 2247 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Available Antennas: TX 0x3 RX 0x3
        Configured Antennas: TX 0x3 RX 0x3
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point
        Band 2:
                Capabilities: 0x1ff
                        RX LDPC
                        HT20/HT40
                        SM Power Save disabled
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 4 usec (0x05)
                HT TX/RX MCS rate indexes supported: 0-15
                VHT Capabilities (0x018001b0):
                        Max MPDU length: 3895
                        Supported Channel Width: neither 160 nor 80+80
                        RX LDPC
                        short GI (80 MHz)
                        TX STBC
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT RX highest supported: 0 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT TX highest supported: 0 Mbps
                Frequencies:
                        * 5180 MHz [36] (3.0 dBm)
                        * 5200 MHz [40] (3.0 dBm)
                        * 5220 MHz [44] (3.0 dBm)
                        * 5240 MHz [48] (3.0 dBm)
                        * 5260 MHz [52] (3.0 dBm) (no IR, radar detection)
                        * 5280 MHz [56] (3.0 dBm) (no IR, radar detection)
                        * 5300 MHz [60] (3.0 dBm) (no IR, radar detection)
                        * 5320 MHz [64] (3.0 dBm) (no IR, radar detection)
                        * 5500 MHz [100] (3.0 dBm) (no IR, radar detection)
                        * 5520 MHz [104] (3.0 dBm) (no IR, radar detection)
                        * 5540 MHz [108] (3.0 dBm) (no IR, radar detection)
                        * 5560 MHz [112] (3.0 dBm) (no IR, radar detection)
                        * 5580 MHz [116] (3.0 dBm) (no IR, radar detection)
                        * 5600 MHz [120] (3.0 dBm) (no IR, radar detection)
                        * 5620 MHz [124] (3.0 dBm) (no IR, radar detection)
                        * 5640 MHz [128] (3.0 dBm) (no IR, radar detection)
                        * 5660 MHz [132] (3.0 dBm) (no IR, radar detection)
                        * 5680 MHz [136] (3.0 dBm) (no IR, radar detection)
                        * 5700 MHz [140] (3.0 dBm) (no IR, radar detection)
                        * 5745 MHz [149] (3.0 dBm) (no IR)
                        * 5765 MHz [153] (3.0 dBm) (no IR)
                        * 5785 MHz [157] (3.0 dBm) (no IR)
                        * 5805 MHz [161] (3.0 dBm) (no IR)
                        * 5825 MHz [165] (3.0 dBm) (no IR)
        valid interface combinations:
                 * #{ IBSS } <= 1, #{ managed, AP, mesh point } <= 8,
                   total <= 8, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }

        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
        Device supports VHT-IBSS.
root@OpenWrt:~# iw --debug wlan1 info
Interface wlan1
        ifindex 8
        wdev 0x100000002
        addr xx:xx:xx:xx:xx:xx
        ssid Africa_5GHz
        type managed
        wiphy 1
        channel 124 (5620 MHz), width: 80 MHz, center1: 5610 MHz
        txpower 3.00 dBm
wifi status
"radio1": {
                "up": true,
                "pending": false,
                "autostart": true,
                "disabled": false,
                "retry_setup_failed": false,
                "config": {
                        "hwmode": "11a",
                        "path": "pci0000:00\/0000:00:00.0\/0000:01:00.0",
                        **"htmode": "VHT80",**
                        "channel": "124",
                        "country": "00",
                        "legacy_rates": true,
                        "disabled": false

OpenWrt 19.07.02

Channel 36
TX ~1.25 Mbit/s
RX ~95 Mbit/s
Channel 124
TX ~1.25 Mbit/s
RX ~95 Mbit/s

root@OpenWrt:~# iw --debug phy1 info
Wiphy phy1
        max # scan SSIDs: 4
        max scan IEs length: 2247 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Available Antennas: TX 0x3 RX 0x3
        Configured Antennas: TX 0x3 RX 0x3
        Supported interface modes:
                 * IBSS
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point
        Band 2:
                Capabilities: 0x1ff
                        RX LDPC
                        HT20/HT40
                        SM Power Save disabled
                        RX Greenfield
                        RX HT20 SGI
                        RX HT40 SGI
                        TX STBC
                        RX STBC 1-stream
                        Max AMSDU length: 3839 bytes
                        No DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 4 usec (0x05)
                HT TX/RX MCS rate indexes supported: 0-15
                VHT Capabilities (0x318001b0):
                        Max MPDU length: 3895
                        Supported Channel Width: neither 160 nor 80+80
                        RX LDPC
                        short GI (80 MHz)
                        TX STBC
                        RX antenna pattern consistency
                        TX antenna pattern consistency
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT RX highest supported: 0 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: not supported
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT TX highest supported: 0 Mbps
                Frequencies:
                        * 5180 MHz [36] (20.0 dBm)
                        * 5200 MHz [40] (20.0 dBm)
                        * 5220 MHz [44] (20.0 dBm)
                        * 5240 MHz [48] (20.0 dBm)
                        * 5260 MHz [52] (20.0 dBm) (no IR, radar detection)
                        * 5280 MHz [56] (20.0 dBm) (no IR, radar detection)
                        * 5300 MHz [60] (20.0 dBm) (no IR, radar detection)
                        * 5320 MHz [64] (20.0 dBm) (no IR, radar detection)
                        * 5500 MHz [100] (20.0 dBm) (no IR, radar detection)
                        * 5520 MHz [104] (20.0 dBm) (no IR, radar detection)
                        * 5540 MHz [108] (20.0 dBm) (no IR, radar detection)
                        * 5560 MHz [112] (20.0 dBm) (no IR, radar detection)
                        * 5580 MHz [116] (20.0 dBm) (no IR, radar detection)
                        * 5600 MHz [120] (20.0 dBm) (no IR, radar detection)
                        * 5620 MHz [124] (20.0 dBm) (no IR, radar detection)
                        * 5640 MHz [128] (20.0 dBm) (no IR, radar detection)
                        * 5660 MHz [132] (20.0 dBm) (no IR, radar detection)
                        * 5680 MHz [136] (20.0 dBm) (no IR, radar detection)
                        * 5700 MHz [140] (20.0 dBm) (no IR, radar detection)
                        * 5745 MHz [149] (20.0 dBm) (no IR)
                        * 5765 MHz [153] (20.0 dBm) (no IR)
                        * 5785 MHz [157] (20.0 dBm) (no IR)
                        * 5805 MHz [161] (20.0 dBm) (no IR)
                        * 5825 MHz [165] (20.0 dBm) (no IR)
        valid interface combinations:
                 * #{ IBSS } <= 1, #{ managed, AP, mesh point } <= 8,
                   total <= 8, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }

        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
        Supported extended features:
                * [ VHT_IBSS ]: VHT-IBSS
                * [ RRM ]: RRM
                * [ CQM_RSSI_LIST ]: multiple CQM_RSSI_THOLD records
                * [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
                * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
root@OpenWrt:~# iw --debug wlan1 info
Interface wlan1
        ifindex 9
        wdev 0x100000003
        addr xx:xx:xx:xx:xx:xx
        ssid Africa_5GHz
        type managed
        wiphy 1
        channel 124 (5620 MHz), width: 80 MHz, center1: 5610 MHz
        txpower 20.00 dBm
        multicast TXQ:
                qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytestx-packets
                0       0       0       0       0       0       0       0      0
wifi status
"radio1": {
                "up": false,
                "pending": false,
                "autostart": false,
                "disabled": false,
                "retry_setup_failed": false,
                "config": {
                        "hwmode": "11a",
                        "path": "pci0000:00/0000:00:00.0/0000:01:00.0",
                        "htmode": "VHT80",
                        "channel": "124",
                        "country": "00",
                        "legacy_rates": false
11.05.20203090PackagesBug ReportVery LowMediumdnsmasq: daemon.err dnsmasq[6363]: failed to load name...openwrt-19.07Unconfirmed Task Description

Router model : Netgear WNDR3700v1

I upgraded to 19.0.7 yesterday. Since I have the follow issue :
all static leases can’t be resolved (25 hosts).

In system.log I found this logs each time I (re)start dnsmasq :
Mon May 11 05:47:28 2020 daemon.info dnsmasq[6363]: read /etc/hosts - 4 addresses
Mon May 11 05:47:28 2020 daemon.err dnsmasq[6363]: failed to load names from /tmp/hosts/dhcp.cfg01411c: Permission denied
Mon May 11 05:47:28 2020 daemon.info dnsmasq-dhcp[6363]: read /etc/ethers - 0 addresses

So I patched the init.d/dnsmasq adding this line :

 chmod og+r $HOSTFILE

after the line :

 mv -f $HOSTFILE_TMP $HOSTFILE

in function dnsmasq_start

This patch is operational with those logs :
Mon May 11 05:51:57 2020 daemon.info dnsmasq[6613]: read /etc/hosts - 4 addresses
Mon May 11 05:51:57 2020 daemon.info dnsmasq[6613]: read /tmp/hosts/dhcp.cfg01411c - 25 addresses
Mon May 11 05:51:57 2020 daemon.info dnsmasq-dhcp[6613]: read /etc/ethers - 0 addresses

Best regards.
Philippe

21.05.20203113KernelBug ReportVery LowMediumFailed to receive offered IP address for devices at ran...openwrt-19.07Unconfirmed Task Description

Hardware: TP-LINK Archer C9 V1
Version: OpenWrt 19.07.2 r10947-65030d81f3

The Archer C9 is the only device doing any NAT on the network and is the only DHCP service on the network. To get around the fact that BCM4360 has no drivers I installed a WiFi Dongle. The Archer C9 is the gateway to the internet.

Sometimes any device at random when connecting to the gateway will be unable to acquire an IP Address despite the fact that the system log clearly shows it offered an IP address to a device with the same mac address. There’s a definite working physical link between the device and gateway. Connecting to alternative ‘dumb APs’ on the same network as the gateway results in the same problem; Unable to acquire an IP address. Asking the device’s DHCP client to renew the address does not help.

I have always experienced this problem with this router when using any non stock firmware (I.E all builds of DD-WRT that I tried seemed to exhibit the same behavior) otherwise I would have said it was a problem specific to only this hardware. If left long enough (Several hours) eventually the device will receive it’s an IP address again. Stock firmware did not once exhibit this behavior in the 2 years+ I had it running.

Eventually I set the device’s IP address manually to the exact IP Address being offered by the DHCP server. The device was still unable to ping the gateway.
I then tried to set the device’s IP address to a random IP address (within the range of IP addresses the DHCP server could potentially serve) The device was still unable to ping the gateway. Finally I set the device IP address outside of the range being offered by the DHCP server and then it was able to communicate with the gateway.

I have attached the system log of when a device failed to acquire an IP address. I have replaced all mac addresses and IP addresses with randomly generated mac addresses and IP addresses. ‘1b:ac:8b:93:55:ba’ is the device struggling to acquire the IP address. It is a MacBook Pro. If memory serves correctly devices requesting an IP address in the same time period will also fail to acquire a IP address from the DHCP server, further testing is required for me to prove that though. Other services including NAT translation for pre-allocated devices appears to behave as expected. The gateway will function as expected in every other way. The log will show me successfully logging via my Android device during the time it was happening.

22.05.20203114Base systemBug ReportVery LowMediumWhen using CLIENT+AP with 5GHZ on same radio, AP doesn'...openwrt-19.07Unconfirmed Task Description

Workaround is to set the channel on the AP to an arbitrary channel other than ‘auto’. It’s still auto since it has to be the same channel as the client uses, but at least now it shows up.
Verified the issue on 19.07.3 with both Xiaomi MIR3G and Netgear WNDR3700v5, both MT7621 based.

 


22.05.20203115KernelBug ReportVery LowMediumPerformance/ping/network latency regression in OpenWrt ...openwrt-19.07Unconfirmed Task Description

Today I’ve upgraded from OpenWrt 19.07.1 to 19.07.3 and noticed that latency for my WDR3600 router has increased more than threefold.

In OpenWrt 19.07.1 ping from my PC to the router (connected via a 1Gb wired connection, less than a meter) took approximately 0.250ms

In OpenWrt 19.07.3 ping is now 0.860ms on average.

I haven’t changed any settings after upgrading to OpenWrt 19.07.3.

This is quite a serious performance regression.

When I was carrying out the tests I had zero load and zero Internet traffic, so the router CPU was completely idle.

# uptime 
 15:22:59 up  4:36,  load average: 0.00, 0.00, 0.00
24.05.20203121Base systemBug ReportVery LowMediumR7800 sysupgrade failsopenwrt-19.07Unconfirmed Task Description

On the Netgear R7800 the sysupgrade fails. Only tried with ‘Keep Settings’.

After reboot only the power light flashes white and it becomes unreachable.

This is the case with release 19. If it was the same with 18 I don’t remember.

The solution for now is upgrade via tftp with factory image but that makes restoring not easy because of lost settings and changed ip address.

24.05.20203122KernelBug ReportVery LowMediumKernel panic - Unable to mount root fs on R7800openwrt-19.07Unconfirmed Task Description

Device problem occurs after installing openwrt 19.07.2 / configuring : 3 vlans, 3 wifi networks, firewall rules, Changing DNS (diff for each vlan), installing luci tranlations

After that, it works several hours but Luci doesn’t answer anymore. At reboot, kernel panic, after resetting device reinstalling config via backup, the same... see Serial log below. thanks.

U-Boot 2012.07 [local,local] (Sep 03 2015 - 17:33:28)

U-boot 2012.07 dni1 V0.4 for DNI HW ID: 29764958 NOR flash 0MB; NAND flash 128MB; RAM 512MB; 1st Radio 4x4; 2nd Radio 4x4; Cascade
smem ram ptable found: ver: 0 len: 5
DRAM:  491 MiB
NAND:  SF: Unsupported manufacturer 00
ipq_spi: SPI Flash not found (bus/cs/speed/mode) = (0/0/48000000/0)
128 MiB
MMC:   
*** Warning - bad CRC, using default environment

PCI0 Link Intialized
PCI1 Link Intialized
In:    serial
Out:   serial
Err:   serial
 131072 bytes read: OK
MMC Device 0 not found
cdp: get part failed for 0:HLOS
Net:   MAC1 addr:cc:40:d0:56:e:7e
athrs17_reg_init: complete
athrs17_vlan_config ...done
S17c init  done
MAC2 addr:cc:40:d0:56:e:7d
eth0, eth1
Hit any key to stop autoboot:  0 
Mac2 unit failed
Mac1 unit failed

 nmrp server is stopped or failed !

Loading from device 0: nand0 (offset 0x1480000)

** check kernel image **
   Verifying Checksum ... OK

** check rootfs image **
   Verifying Checksum ... OK
MMC Device 0 not found

Loading from nand0, offset 0x1480000
   Image Name:   ARM OpenWrt Linux-4.14.171
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2200315 Bytes = 2.1 MiB
   Load Address: 42208000
   Entry Point:  42208000
Automatic boot of image at addr 0x44000000 ...
   Image Name:   ARM OpenWrt Linux-4.14.171
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2200315 Bytes = 2.1 MiB
   Load Address: 42208000
   Entry Point:  42208000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK
mtdparts variable not set, see 'help mtdparts'
no partitions defined

defaults:
mtdids  : nand0=msm_nand
mtdparts: none
info: "mtdparts" not set
Using machid 0x136c from environment

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14.171 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r10947-65030d81f3)) #0 SMP Thu Feb 27 21:05:12 2020
[    0.000000] CPU: ARMv7 Processor [512f04d0] revision 0 (ARMv7), cr=10c5787d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: Netgear Nighthawk X4S R7800
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] random: get_random_bytes called from 0xc09008dc with crng_init=0
[    0.000000] percpu: Embedded 15 pages/cpu s29388 r8192 d23860 u61440
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 121920
[    0.000000] Kernel command line: 
[    0.000000] Bootloader command line (ignored): console=ttyHSL1,115200n8
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 477376K/491520K available (4975K kernel code, 160K rwdata, 756K rodata, 1024K init, 235K bss, 14144K reserved, 0K cma-reserved, 0K highmem)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xde800000 - 0xff800000   ( 528 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xde000000   ( 480 MB)
[    0.000000]     pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
[    0.000000]     modules : 0xbf000000 - 0xbfe00000   (  14 MB)
[    0.000000]       .text : 0xc0208000 - 0xc07dbe98   (5968 kB)
[    0.000000]       .init : 0xc0900000 - 0xc0a00000   (1024 kB)
[    0.000000]       .data : 0xc0a00000 - 0xc0a28180   ( 161 kB)
[    0.000000]        .bss : 0xc0a2a000 - 0xc0a64e18   ( 236 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] clocksource: dg_timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 305801671480 ns
[    0.000008] sched_clock: 32 bits at 6MHz, resolution 160ns, wraps every 343597383600ns
[    0.000022] Switching to timer-based delay loop, resolution 160ns
[    0.000228] Calibrating delay loop (skipped), value calculated using timer frequency.. 12.50 BogoMIPS (lpj=62500)
[    0.000254] pid_max: default: 32768 minimum: 301
[    0.000379] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000397] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000971] CPU: Testing write buffer coherency: ok
[    0.001727] Setting up static identity map for 0x42300000 - 0x42300060
[    0.001884] Hierarchical SRCU implementation.
[    0.002625] smp: Bringing up secondary CPUs ...
[    0.004460] smp: Brought up 1 node, 2 CPUs
[    0.004476] SMP: Total of 2 processors activated (25.00 BogoMIPS).
[    0.004485] CPU: All CPU(s) started in SVC mode.
[    0.014749] VFP support v0.3: implementor 51 architecture 64 part 4d variant 2 rev 0
[    0.014919] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.014944] futex hash table entries: 512 (order: 3, 32768 bytes)
[    0.015058] pinctrl core: initialized pinctrl subsystem
[    0.016053] NET: Registered protocol family 16
[    0.016311] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.017655] cpuidle: using governor ladder
[    0.017720] cpuidle: using governor menu
[    0.040311] msm_bus_fabric_init_driver
[    0.041824] usbcore: registered new interface driver usbfs
[    0.041902] usbcore: registered new interface driver hub
[    0.041991] usbcore: registered new device driver usb
[    0.042048] pps_core: LinuxPPS API ver. 1 registered
[    0.042060] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.042094] PTP clock support registered
[    0.043798] clocksource: Switched to clocksource dg_timer
[    0.047040] NET: Registered protocol family 2
[    0.047634] TCP established hash table entries: 4096 (order: 2, 16384 bytes)
[    0.047676] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[    0.047731] TCP: Hash tables configured (established 4096 bind 4096)
[    0.047824] UDP hash table entries: 256 (order: 1, 8192 bytes)
[    0.047852] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
[    0.048029] NET: Registered protocol family 1
[    0.049217] No memory allocated for crashlog
[    0.049492] workingset: timestamp_bits=30 max_order=17 bucket_order=0
[    0.054651] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.054671] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    0.061244] io scheduler noop registered
[    0.061261] io scheduler deadline registered (default)
[    0.062935] qcom-pcie 1b500000.pci: 1b500000.pci supply vdda not found, using dummy regulator
[    0.063044] qcom-pcie 1b500000.pci: 1b500000.pci supply vdda_phy not found, using dummy regulator
[    0.063135] qcom-pcie 1b500000.pci: 1b500000.pci supply vdda_refclk not found, using dummy regulator
[    0.063921] OF: PCI: host bridge /soc/pci@1b500000 ranges:
[    0.063968] OF: PCI:    IO 0x0fe00000..0x0fefffff -> 0x0fe00000
[    0.063995] OF: PCI:   MEM 0x08000000..0x0fdfffff -> 0x08000000
[    0.164480] qcom-pcie 1b500000.pci: link up
[    0.164657] qcom-pcie 1b500000.pci: PCI host bridge to bus 0000:00
[    0.164682] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.164704] pci_bus 0000:00: root bus resource [io  0x0000-0xfffff] (bus address [0xfe00000-0xfefffff])
[    0.164719] pci_bus 0000:00: root bus resource [mem 0x08000000-0x0fdfffff]
[    0.165242] PCI: bus0: Fast back to back transfers disabled
[    0.167476] PCI: bus1: Fast back to back transfers disabled
[    0.167580] pci 0000:00:00.0: BAR 8: assigned [mem 0x08000000-0x081fffff]
[    0.167605] pci 0000:01:00.0: BAR 0: assigned [mem 0x08000000-0x081fffff 64bit]
[    0.167733] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
[    0.167758] pci 0000:00:00.0:   bridge window [mem 0x08000000-0x081fffff]
[    0.168292] pcieport 0000:00:00.0: AER enabled with IRQ 35
[    0.168814] qcom-pcie 1b700000.pci: 1b700000.pci supply vdda not found, using dummy regulator
[    0.168913] qcom-pcie 1b700000.pci: 1b700000.pci supply vdda_phy not found, using dummy regulator
[    0.169018] qcom-pcie 1b700000.pci: 1b700000.pci supply vdda_refclk not found, using dummy regulator
[    0.169773] OF: PCI: host bridge /soc/pci@1b700000 ranges:
[    0.169809] OF: PCI:    IO 0x31e00000..0x31efffff -> 0x31e00000
[    0.169832] OF: PCI:   MEM 0x2e000000..0x31dfffff -> 0x2e000000
[    0.279738] qcom-pcie 1b700000.pci: link up
[    0.279897] qcom-pcie 1b700000.pci: PCI host bridge to bus 0001:00
[    0.279918] pci_bus 0001:00: root bus resource [bus 00-ff]
[    0.279933] pci_bus 0001:00: root bus resource [mem 0x2e000000-0x31dfffff]
[    0.280399] PCI: bus0: Fast back to back transfers disabled
[    0.282745] PCI: bus1: Fast back to back transfers disabled
[    0.282832] pci 0001:00:00.0: BAR 8: assigned [mem 0x2e000000-0x2e1fffff]
[    0.282856] pci 0001:01:00.0: BAR 0: assigned [mem 0x2e000000-0x2e1fffff 64bit]
[    0.282989] pci 0001:00:00.0: PCI bridge to [bus 01-ff]
[    0.283009] pci 0001:00:00.0:   bridge window [mem 0x2e000000-0x2e1fffff]
[    0.283496] pcieport 0001:00:00.0: AER enabled with IRQ 68
[    0.285956] L2 @ QSB rate. Forcing new rate.
[    0.286169] L2 @ 384000 KHz
[    0.286343] CPU0 @ 800000 KHz
[    0.286356] CPU1 @ QSB rate. Forcing new rate.
[    0.286483] CPU1 @ 384000 KHz
[    0.290325] gsbi 16300000.gsbi: GSBI port protocol: 6 crci: 0
[    0.292267] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
[    0.294968] msm_serial 16340000.serial: msm_serial: detected port #0
[    0.295073] msm_serial 16340000.serial: uartclk = 7372800
[    0.295160] 16340000.serial: ttyMSM0 at MMIO 0x16340000 (irq = 101, base_baud = 460800) is a MSM
[    0.295199] msm_serial: console setup on port #0
[    1.015021] console [ttyMSM0] enabled
[    1.019730] msm_serial: driver initialized
[    1.028412] loop: module loaded
[    1.030466] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xa1
[    1.030500] nand: Micron MT29F1G08ABBEAH4
[    1.037054] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    1.040974] 8 fixed-partitions partitions found on MTD device qcom_nand.0
[    1.048424] Creating 8 MTD partitions on "qcom_nand.0":
[    1.055270] 0x000000000000-0x000000c80000 : "qcadata"
[    1.065253] random: fast init done
[    1.083023] 0x000000c80000-0x000001180000 : "APPSBL"
[    1.092491] 0x000001180000-0x000001200000 : "APPSBLENV"
[    1.094218] 0x000001200000-0x000001340000 : "art"
[    1.099432] 0x000001340000-0x000001480000 : "artbak"
[    1.104377] 0x000001480000-0x000001880000 : "kernel"
[    1.114194] 0x000001880000-0x000007900000 : "ubi"
[    1.282928] 0x000007900000-0x000008000000 : "reserve"
[    1.297225] libphy: GPIO Bitbanged MDIO: probed
[    1.318740] switch0: Atheros AR8337 rev. 2 switch registered on gpio-0
[    2.186120] ar8327: qca,phy-rgmii-en is not specified
[    2.186506] libphy: Fixed MDIO Bus: probed
[    2.192324] ipq806x-gmac-dwmac 37200000.ethernet: PTP uses main clock
[    2.194527] stmmac - user ID: 0x10, Synopsys ID: 0x37
[    2.200660] ipq806x-gmac-dwmac 37200000.ethernet: Ring mode enabled
[    2.205784] ipq806x-gmac-dwmac 37200000.ethernet: DMA HW capability register supported
[    2.211772] ipq806x-gmac-dwmac 37200000.ethernet: Enhanced/Alternate descriptors
[    2.219833] ipq806x-gmac-dwmac 37200000.ethernet: Enabled extended descriptors
[    2.227395] ipq806x-gmac-dwmac 37200000.ethernet: RX Checksum Offload Engine supported
[    2.234423] ipq806x-gmac-dwmac 37200000.ethernet: COE Type 2
[    2.242238] ipq806x-gmac-dwmac 37200000.ethernet: TX Checksum insertion supported
[    2.248135] ipq806x-gmac-dwmac 37200000.ethernet: Wake-Up On Lan supported
[    2.255513] ipq806x-gmac-dwmac 37200000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    2.263812] ipq806x-gmac-dwmac 37400000.ethernet: PTP uses main clock
[    2.271083] stmmac - user ID: 0x10, Synopsys ID: 0x37
[    2.277221] ipq806x-gmac-dwmac 37400000.ethernet: Ring mode enabled
[    2.282167] ipq806x-gmac-dwmac 37400000.ethernet: DMA HW capability register supported
[    2.288311] ipq806x-gmac-dwmac 37400000.ethernet: Enhanced/Alternate descriptors
[    2.296308] ipq806x-gmac-dwmac 37400000.ethernet: Enabled extended descriptors
[    2.303784] ipq806x-gmac-dwmac 37400000.ethernet: RX Checksum Offload Engine supported
[    2.310897] ipq806x-gmac-dwmac 37400000.ethernet: COE Type 2
[    2.318768] ipq806x-gmac-dwmac 37400000.ethernet: TX Checksum insertion supported
[    2.324610] ipq806x-gmac-dwmac 37400000.ethernet: Wake-Up On Lan supported
[    2.331910] ipq806x-gmac-dwmac 37400000.ethernet: Enable RX Mitigation via HW Watchdog Timer
[    2.339460] i2c /dev entries driver
[    2.348210] Calibration not found.
[    2.351669] Speed bin: 0
[    2.353948] PVS bin: 4
[    2.358048] cpuidle: enable-method property 'qcom,kpss-acc-v1' found operations
[    2.358880] cpuidle: enable-method property 'qcom,kpss-acc-v1' found operations
[    2.366693] sdhci: Secure Digital Host Controller Interface driver
[    2.373311] sdhci: Copyright(c) Pierre Ossman
[    2.379622] sdhci-pltfm: SDHCI platform and OF driver helper
[    2.385414] NET: Registered protocol family 10
[    2.391108] Segment Routing with IPv6
[    2.394044] NET: Registered protocol family 17
[    2.397865] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[    2.402664] 8021q: 802.1Q VLAN Support v1.8
[    2.415285] Registering SWP/SWPB emulation handler
[    2.431257] qcom_rpm 108000.rpm: RPM firmware 3.0.16777364
[    2.443350] s1a: supplied by regulator-dummy
[    2.443451] s1a: Bringing 0uV into 1050000-1050000uV
[    2.447028] s1b: supplied by regulator-dummy
[    2.451684] s1b: Bringing 0uV into 1050000-1050000uV
[    2.456229] s2a: supplied by regulator-dummy
[    2.460900] s2a: Bringing 0uV into 775000-775000uV
[    2.465384] s2b: supplied by regulator-dummy
[    2.469745] s2b: Bringing 0uV into 775000-775000uV
[    2.479070] UBI: auto-attach mtd6
[    2.479103] ubi0: attaching mtd6
[    2.528833] random: crng init done
[    3.188552] ubi0: scanning is finished
[    3.198077] ubi0: attached mtd6 (name "ubi", size 96 MiB)
[    3.198098] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
[    3.202445] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    3.209290] ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
[    3.216138] ubi0: good PEBs: 772, bad PEBs: 0, corrupted PEBs: 0
[    3.222844] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128
[    3.229157] ubi0: max/mean erase counter: 3/1, WL threshold: 4096, image sequence number: 1530044714
[    3.236185] ubi0: available PEBs: 748, total reserved PEBs: 24, PEBs reserved for bad PEB handling: 20
[    3.245511] hctosys: unable to open rtc devic�[    3.260030] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    3.260051] Please append a correct "root=" boot option; here are the available partitions:
[    3.266567] 1f00           12800 mtdblock0 
[    3.266571]  (driver?)
[    3.278805] 1f01            5120 mtdblock1 
[    3.278809]  (driver?)
[    3.285399] 1f02             512 mtdblock2 
[    3.285404]  (driver?)
[    3.291824] 1f03            1280 mtdblock3 
[    3.291827]  (driver?)
[    3.298335] 1f04            1280 mtdblock4 
[    3.298339]  (driver?)
[    3.304915] 1f05            4096 mtdblock5 
[    3.304920]  (driver?)
[    3.311355] 1f06           98816 mtdblock6 
[    3.311359]  (driver?)
[    3.317942] 1f07            7168 mtdblock7 
[    3.317947]  (driver?)
[    3.324439] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    3.326828] CPU1: stopping
[    3.335065] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.171 #0
[    3.337752] Hardware name: Generic DT based system
[    3.343928] Function entered at [<c030f1c4>] from [<c030b390>]
[    3.348608] Function entered at [<c030b390>] from [<c07c0664>]
[    3.354423] Function entered at [<c07c0664>] from [<c030e40c>]
[    3.360239] Function entered at [<c030e40c>] from [<c03014b8>]
[    3.366054] Function entered at [<c03014b8>] from [<c030bf8c>]
[    3.371870] Exception stack(0xdd461f80 to 0xdd461fc8)
[    3.377715] 1f80: 00000001 00000000 00000000 c0315100 ffffe000 c0a03cb8 c0a03c6c 00000000
[    3.382842] 1fa0: 00000000 512f04d0 00000000 00000000 dd461fc8 dd461fd0 c030854c c0308550
[    3.390977] 1fc0: 60000013 ffffffff
[    3.399125] Function entered at [<c030bf8c>] from [<c0308550>]
[    3.402425] Function entered at [<c0308550>] from [<c03589c8>]
[    3.408330] Function entered at [<c03589c8>] from [<c0358d10>]
[    3.414143] Function entered at [<c0358d10>] from [<423017cc>]
[    3.419963] Rebooting in 1 seconds..
31.05.20203139Base systemBug ReportVery LowMediumOpenWRT 19.07.03 - WiFi unstable - STA-OPMODE-SMPS-MODE...openwrt-19.07Unconfirmed Task Description

Hello there,
I just upgraded my perfectly working TP-Link TL-WDR4900 v1 from LEDE 17 to the latest OpenWRT firmware available: 19.07.03

Unfortunately now, some WiFi 2.4GHz clients got stuck on wifi, they cannot even ping the router, the only way to fix it is to manually disconnect and reconnect them.

This is the log from the router in that specific moment:
May 30 22:26:01 Router hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED 83:20:75:40:f3:a0 static
May 30 22:26:11 Router hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED 83:20:75:40:f3:a0 dynamic
May 30 22:38:59 Router hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED 83:20:75:40:f3:a0 static
May 30 22:38:59 Router hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED 83:20:75:40:f3:a0 dynamic
May 30 22:39:03 Router hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED 83:20:75:40:f3:a0 static
May 30 22:39:04 Router hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED 83:20:75:40:f3:a0 dynamic
May 30 22:39:12 Router hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED 83:20:75:40:f3:a0 static
May 30 22:39:13 Router hostapd: wlan1: STA-OPMODE-SMPS-MODE-CHANGED 83:20:75:40:f3:a0 dynamic

In order to reproduce the bug I have just to increase the traffic (download a big file on wifi)

01.06.20203142Base systemBug ReportVery LowMediumQEMU on arm64 cannot shut down OpenWRT 19.07openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on - arm64 QEMU Virtual Machine
- Software versions of OpenWrt/LEDE release, packages, etc. - 19.07.3
- Steps to reproduce -
Boot OpenWRT as per the instructions at OpenWRT QEMU Documentation on an arm64 virtual machine.

 

When hosted in a QEMU virtual machine on arm64 (aarch64), OpenWRT is unable to shut down.
QEMU supports two shutdown methods on arm64, ACPI and QEMU Guest Agent

ACPI on arm64 requires UEFI support, which is not enabled in the armvirt-64 kernel.

QEMU Guest Agent has a package for OpenWRT but the package is broken due to the base implementation of OpenWRT.
QEMU Guest Agent forks a process that calls /sbin/shutdown with several flags when ordered to shut down.
/sbin/shutdown does not exist in the base system.
The flags passed are not compatible with /sbin/poweroff.

This is solved with a simple script:
/sbin/shutdown:

#!/bin/sh
/sbin/poweroff

Ideally support for armvirt-64 should move to uefi, since that is the expected supported method of booting a arm64 virtual machine.
This would require the addition of CONFIG_EFI_STUB to the armvirt-64 kernel config.
It would also require changing the armvirt-64 packaging to include the kernel efi image in the root file system, and/or add a bootloader such as grub.

04.06.20203150PackagesBug ReportVery LowMediumPackages seem to be missing from downloads.openwrt.org ...openwrt-19.07Unconfirmed Task Description

Device: openwrtorg/rootfs:armvirt-32-19.07.2 Docker image
Version: OpenWrt 19.07

Hi- I hope everyone is doing well.

We’ve got some builds that use the openwrtorg/rootfs:armvirt-32-19.07.2 Docker image; they run around 1600 UTC each day as well as any time somebody amends a related pull request (normally between 0000 UTC to 1000 UTC, our working day for Perth, Australia).

Occasionally, we get failures due to packages missing in OpenWrt (curiously, it’s usually GCC)- more commonly during our morning.

I _think_ this may be a byproduct of the OpenWrt nightly builds happening and the packages being rebuilt, it may be that https://downloads.openwrt.org/releases/19.07.2/packages/arm_cortex-a15_neon-vfpv4/packages/ is the actual build output folder (and so during a build, the contents may change).

I’ve had a look at the timestamps at that URL, I’m not sure what timezone they’re in, but they’re mostly around the 0100 to 0500 range- if this is UTC and my suspicions are correct, then that would definitely cause an increase of this issue during our morning (which is what we see).

I don’t think it’s related to any Docker build cache funniness- we wipe that at 1900 UTC each day.

While you won’t reliably be able to reproduce, here’s a simple test case (requiring Docker for Mac/Windows, or Docker for Linux with docker buildx configured):

- docker run –rm -it openwrtorg/rootfs:armvirt-32-19.07.2 sh
- mkdir /var/lock
- opkg update && opkg install gcc

I’ve attached a log excerpts from our CI system of one such failure.

Thanks and regards,

Ed

25.08.20203306Base systemBug ReportVery LowMediumQMI & DHCP renewal issue.openwrt-19.07Unconfirmed Task Description

I’m facing a problem on two routers WG3526 (Modem EC-25) and D-Link DWR921 (Model Broadmobi BM806). My 4G provider is Free Mobile a French mobile provider.

Every 12 hours my ISP change the IP of the interface and the DHCP-Client still get the old IP Address even if “uqmi -d /dev/cdc-wdm0 –get-current-settings” display the new valid ip address.

  • “uqmi -d /dev/cdc-wdm0 –get-current-settings” give IP “B”.
  • “udhcpc” still attribute IP “A” to the wwan0 interface resulting in an nonoperational interface until I restart it (ubus call network.interface.wwan down / ubus call network.interface.wwan up).
  • After an interface restart “udhcpc” attribute IP “B” to the wwan0 interface.

This problem happen exactly every 12 hours the duration of the dhcp lease time on the interface wwan0.

I don’t know if it’s a bug in the firmware of both modems or a problem within OpenWRT.
I can provide more informations or context if needed. It’s also described on another bug in the comment section by @Dmitry. As it’s another bug not related to the original one a new bug is needed. Thread reference https://bugs.openwrt.org/index.php?do=details&task_id=1252.


Detailed description of the BUG

'uqmi -d /dev/cdc-wdm0 –get-current-settings' display the new IP address

uqmi -d /dev/cdc-wdm0 –get-current-settings {

      "pdp-type": "ipv4",
      "ip-family": "ipv4",
      "mtu": 1500,
      "ipv4": {
              "ip": "10.81.148.43",
              "dns1": "193.41.60.16",
              "dns2": "193.41.60.15",
              "gateway": "10.81.148.44",
              "subnet": "255.255.255.248"
      },
      "ipv6": {
      },
      "domain-names": {
      }
}

'ifconfig wwan0' is showing a different IP. I tryed to restart udhcpc manually but the interface still get the old IP until I restart network interface

ifconfig wwan0

        inet addr:10.95.107.241  P-t-P:10.95.107.241  Mask:255.255.255.252
        inet6 addr: fe80::e1b3:e56d:de16:ba57/64 Scope:Link
        UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
        RX packets:54582 errors:0 dropped:0 overruns:0 frame:0
        TX packets:64104 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000
        RX bytes:46222544 (44.0 MiB)  TX bytes:60349584 (57.5 MiB)

After a network stack restart, "ifconfig wwan0" display the proper IP address.

ifconfig wwan0
        inet addr:10.81.148.43  P-t-P:10.81.148.43  Mask:255.255.255.248
        inet6 addr: fe80::e1b3:e56d:de16:ba57/64 Scope:Link
        UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
        RX packets:54584 errors:0 dropped:0 overruns:0 frame:0
        TX packets:64112 errors:0 dropped:0 overruns:0 carrier:0
        collisions:0 txqueuelen:1000
        RX bytes:46223174 (44.0 MiB)  TX bytes:60351028 (57.5 MiB)

Problem happen again after 12 hours.


Details on the WG3526

root@nly-marconi:/etc/config# ubus call system board
{
	"kernel": "4.14.180",
	"hostname": "nly-marconi",
	"system": "MediaTek MT7621 ver:1 eco:3",
	"model": "ZBT-WG3526 (16M)",
	"board_name": "zbt-wg3526-16M",
	"release": {
		"distribution": "OpenWrt",
		"version": "19.07.3",
		"revision": "r11063-85e04e9f46",
		"target": "ramips/mt7621",
		"description": "OpenWrt 19.07.3 r11063-85e04e9f46"
	}
}
root@nly-marconi:~# uci show network.wwan
network.wwan=interface
network.wwan.proto='qmi'
network.wwan.device='/dev/cdc-wdm0'
network.wwan.apn='free'
network.wwan.auth='none'
network.wwan.pincode='my-pin-code-here'
network.wwan.modes='lte'
network.wwan.metric='20'
network.wwan.delegate='0'
network.wwan.force_link='0'


Details ont the Dlink router

root@lfgo-routeur:~# ubus call system board
{
	"kernel": "4.14.180",
	"hostname": "lfgo-routeur",
	"system": "MediaTek MT7620N ver:2 eco:6",
	"model": "D-Link DWR-921 C1",
	"board_name": "dlink,dwr-921-c1",
	"release": {
		"distribution": "OpenWrt",
		"version": "19.07.3",
		"revision": "r11063-85e04e9f46",
		"target": "ramips/mt7620",
		"description": "OpenWrt 19.07.3 r11063-85e04e9f46"
	}
}
root@lfgo-routeur:~# uci show network.wwan
network.wwan=interface
network.wwan.ifname='wwan0'
network.wwan.device='/dev/cdc-wdm0'
network.wwan.proto='qmi'
network.wwan.apn='free'
network.wwan.pincode='my-pin-code-here'
network.wwan.delay='10'
05.09.20203318KernelBug ReportVery LowMediumkmod-rtl8xxxu does not work with RTL8723BU moduleopenwrt-19.07Unconfirmed Task Description

RTL8723BU USB module ID 0bda:b720 does not work with kmod-rtl8xxxu driver and rtl8723bu-firmware
Bluetooth scanning does not see any device.
Module cannot be loaded.

[ 8893.763180] usb 1-1.4: This Realtek USB WiFi dongle (0x0bda:0xb720) is untested!
[ 8894.291851] usb 1-1.4: Firmware revision 35.0 (signature 0×5301)
[ 8894.564319] usb 1-1.4: Firmware failed to start
[ 8894.568980] rtl8xxxu: probe of 1-1.4:1.2 failed with error -11
[ 8894.575434] usbcore: registered new interface driver rtl8xxxu

22.09.20203356PackagesBug ReportVery LowMediumhttps-dns-proxy: Luci interface breaks the configuratio...openwrt-19.07Unconfirmed Task Description

When you edit `/etc/config/https-dns-proxy` and set a custom server, not known to Luci HTML interface, the Luci UI at /cgi-bin/luci/admin/services/https-dns-proxy will display “CIRA Canadian Shield (Family)” as the selected resolver. This, by itself is not a problem yet, as the Proxy will function as expected.

However, the moment one makes any changes in the UI, e.g. changing listen port, `/etc/config/https-dns-proxy` will get rewritten and an actual resolver for CIRA Canadian Shield (Family) will be used.

Luci interface for HTTPS DNS Proxy should:

1. Bare minimum: indicate a custom resolver is used, and not lose the resolver after making changes to listen port and other stuff.
1. Nice to have: Allow a user to define a custom resolver in the UI - by specifying `resolver_url`, `bootstrap_dns`, `user` and `group` properties

The problem applies on any device as it’s not device-specific.

Reproduction instruction:

1. Edit `/etc/config/https-dns-proxy` and make it look like this:

```
config main ‘config’

      option update_dnsmasq_config '-'

config https-dns-proxy

      option listen_addr '127.0.0.1'
      option listen_port '5054'
      option user 'nobody'
      option group 'nogroup'
      option bootstrap_dns '1.1.1.1,1.0.0.1,2606:4700:4700::1111,2606:4700:4700::1001'
      option resolver_url 'https://1.1.1.1/dns-query'

```
2. Go to http://192.168.10.1/cgi-bin/luci/admin/services/https-dns-proxy and observe “CIRA Canadian Shield (Family)” as the selected resolver.
3. Change listen port and click Save & Apply.
4. Observe `/etc/config/https-dns-proxy` lose `resolver_url` setting.

30.09.20203366Base systemBug ReportVery LowMediumrouter keeps running out of memory, have to power cycle...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
netgear r6350
- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01
I installed ocserv too but I don’t think its the problem
- Steps to reproduce
Just let router run, maybe will stay up for a week and then at some point gui tells me can’t fork, I can’t login to router with ssh and I have to power cycle it.

I added swap space on a USB stick to try to keep it from locking up.
I’ve ssh’ed into and run the following to try to figure out what’s going on.

I expected to find a process growing but nothing looks obvious to me. I just see free memory keep going down, and I see a bit of swap space used.

Any suggestions on what else I could do to figure out what’s going on with the memory usage?

looking at meminfo it shows about ~100M used but the numbers don’t seem to add up to that.

while sleep 60
do
  date
  uptime
  top -b -n 1 | head -n 10
  ps w | awk '$3 > 4000'
  free -m
  cat /proc/meminfo
  printf "\n"
done

Here’s what 10 days looks like:

Wed Sep 30 00:56:16 EDT 2020
 00:56:16 up 10 days,  2:38,  load average: 0.00, 0.02, 0.00
Mem: 100276K used, 23496K free, 1076K shrd, 1832K buff, 4600K cached
CPU:   0% usr   0% sys   0% nic 100% idle   0% io   0% irq   0% sirq
Load average: 0.01 0.02 0.00 2/71 27832
  PID  PPID USER     STAT   VSZ %VSZ %CPU COMMAND
27831  7096 root     R     1224   1%   0% top -b -n 1
 2175  2174 root     S     4912   4%   0% ocserv-sm
 2174     1 root     S     4740   4%   0% ocserv-main
  931     1 root     S     2324   2%   0% /sbin/rpcd -s /var/run/ubus.sock -t 30
 2001     1 root     S     1784   1%   0% /usr/sbin/hostapd -s -P /var/run/wifi-phy0.pid -B /var/run/hostapd-phy0.conf
 1077     1 root     S     1748   1%   0% /sbin/netifd
  PID USER       VSZ STAT COMMAND
 2174 root      4740 S    ocserv-main
 2175 root      4912 S    ocserv-sm
              total        used        free      shared  buff/cache   available
Mem:         123772       93796       23544        1076        6432        2604
Swap:        262140        1024      261116
MemTotal:         123772 kB
MemFree:           23500 kB
MemAvailable:       2560 kB
Buffers:            1832 kB
Cached:             4600 kB
SwapCached:          232 kB
Active:             5184 kB
Inactive:           3364 kB
Active(anon):       1120 kB
Inactive(anon):     2072 kB
Active(file):       4064 kB
Inactive(file):     1292 kB
Unevictable:           0 kB
Mlocked:               0 kB
HighTotal:             0 kB
HighFree:              0 kB
LowTotal:         123772 kB
LowFree:           23500 kB
SwapTotal:        262140 kB
SwapFree:         261116 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:          1960 kB
Mapped:             2136 kB
Shmem:              1076 kB
Slab:              11756 kB
SReclaimable:       1912 kB
SUnreclaim:         9844 kB
KernelStack:         624 kB
PageTables:          308 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      324024 kB
Committed_AS:       6680 kB
VmallocTotal:    1040376 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
11.10.20203379Base systemBug ReportVery LowMediumMissing switch0 LEDs in board definitionopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on: TP-Link WDR3600
- Software versions of OpenWrt/LEDE release, packages, etc.: OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01

LEDs of switch0 are missing in board definition thus missing in LuCi web interface on ath79 target.

 


Showing tasks 51 - 100 of 1029 Page 2 of 21 - 1 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing