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
15.01.20202740Base systemBug ReportVery LowMedium19.07 ath79 uclient-fetch defaults fail in IPv4-only en...openwrt-19.07Waiting on reporter Task Description

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

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

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

Here’s a quick run to illustrate:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It can be reproduced:

% mkdir /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
% cd /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
% wget https://downloads.openwrt.org/releases/19.07.0/targets/ar71xx/mikrotik/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64.tar.xz
% tar xf openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64.tar.xz
% cd openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64
% make image PROFILE=nand-large
...
1671656 bytes (1.7 MB, 1.6 MiB) copied, 0.00693055 s, 241 MB/s
Can't get lstat from kernel file!: No such file or directory
make[3]: *** [Makefile:71: /tmp/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/openwrt-imagebuilder-19.07.0-ar71xx-mikrotik.Linux-x86_64/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/tmp/openwrt-19.07.0-ar71xx-mikrotik-nand-large-squashfs-sysupgrade.bin] Error 255
make[2]: *** [Makefile:169: build_image] Error 2
make[1]: *** [Makefile:120: _call_image] Error 2
make: *** [Makefile:197: image] Error 2
zsh: exit 2     make image PROFILE=nand-large
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

08.06.20203161Base systemBug ReportVery LowMedium[opkg | logd] installation collision syslog-ngopenwrt-19.07Unconfirmed Task Description
{”kernel”:”4.14.180”,”hostname”:”OpenWrt”,”system”:”ARMv7 Processor rev 1 (v7l)”,”model”:”Turris Omnia”,”board_name”:”cznic,turris-omnia”,”release”:{”distribution”:”OpenWrt”,”version”:”19.07.3”,”revision”:”r11063-85e04e9f46”,”target”:”mvebu/cortexa9”,”description”:”OpenWrt 19.07.3 r11063-85e04e9f46”}}
—-
opkg install syslog-ng
Collected errors:
 * check_data_file_clashes: Package syslog-ng wants to install file /sbin/logread
	But that file is already provided by package  * logd
 * opkg_install_cmd: Cannot install package syslog-ng.
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.

 


13.10.20203383WebsiteBug ReportVery LowMediumluci management webside - network - interface proto MAP...openwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on mt7621
- Software versions of OpenWrt 19.07.03 19.07.04
- Steps to reproduce
first: select map-e support on menuconfig Network→map
select luci support on menuconfig Luci
second: update firmware, and then loggin to 192.168.1.1, network - interface - proto MAP/LW4over6
and error occur when click config apply

 
19.10.20203394PackagesBug ReportVery LowMediumb2sum missing.openwrt-19.07Unconfirmed Task Description

b2sum is a faster and more secure successor to checksums like md5sum and is part of coreutils for years now, yet still missing in latest OpenWRT coreutils packages.

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

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

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

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

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

Here is what conntrack -L says:

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

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

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

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

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

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

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

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

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

Trunk and 19.07.
18.06 is unaffected.

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

Steps to reproduce:

Steps based on fresh install of OpenWrt:

Replace odhcpd-ipv6only by odhcpd

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

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

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

uci commit dhcp

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

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

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

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

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

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

GL-B1300
19.07-SNAPSHOT

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

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

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

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

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


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

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

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

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

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

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

please provide steps to collect log

in dmesg only:

(wlan0) entered blocking state
(wlan0) entered disabled state
   
15.12.20192676Base systemBug ReportVery LowLowUnexpected realpath behaviouropenwrt-19.07Unconfirmed Task Description

There is a problem with creating chrooted SFTP access using OpenSSH package. However, it seems that the problem isn’t with the package, rather with realpath function of OpenWRT. The whole description of the problem was already provided in forum, here I only copy the part of the log file:

Nov 29 10:06:27 OpenWrt internal-sftp[12557]: realpath "."
Nov 29 10:06:27 OpenWrt internal-sftp[12557]: debug3: request 46352: sent status 2
Nov 29 10:06:27 OpenWrt internal-sftp[12557]: sent status No such file

Tested on both 18.06.5 and 19.07.0-rc1 with the same result.

18.12.20192685Base systemBug ReportVery LowLowColdplug too soon; hotplug.d scripts not run for some e...openwrt-19.07Unconfirmed Task Description

OpenWrt 19.07.0-rc2, latest openwrt-packages.

Occurs on at least ath79 but looking at the code this is not device-specific.

1. Have USB devices for which you have hotplug scripts (e.g. from p910d and sane-backends)
2. Boot (or reboot) with usb devices already plugged in.
3. Observe that the actions in the hotplug script (e.g. setting permissions / group ownership that don’t belong in the base system (i.e. hotplug.json)) as it’d be bloat to detect product:vendor ip pairs and take appropriate action for all the various packages and devices hotplug handles – if hotplug.json could have hotplug.json.d or somesuch it would alleviate most of this pain.

Looking at the procd code coldplug (udevtrigger) is called during ‘early’ init, which means that hotplug.d scripts are not yet present. Because /etc/init.d/boot (or any other initscript) no longer does a later call to udevtrigger, the events get missed).

If udevtrigger were called during regular init this wouldn’t be an issue (but probably the coldplug is needed earlier *as well* for devices needed to boot the system.

See also #1903 and #996 (they are likely the same root cause).

Showing tasks 51 - 100 of 1127 Page 2 of 23 - 1 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing