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

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

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

07.02.20202818Base systemBug ReportVery LowLowCurrent time displayed incorrectly in v.19.07 system ta...openwrt-19.07Unconfirmed Task Description

- Device problem occurs on
Aerohive HiveAP-121

- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 19.07.1 r10911-c155900f66 / LuCI openwrt-19.07 branch git-20.029.45734-adbbd5c

- Steps to reproduce
This is evident when you have two AP (exact same hardware) side by side running v.19.07.1 and v.18.06.5

The issue:
After upgrading firmware from 18.06.5 to 19.07.1 we noticed that the current time reported incorrectly on the ‘System’ tab in GUI.

Please note, current time IS reported correctly in the ‘Status’ tab on both versions.

Please note, GUI is accessed using a desktop version of Debian GNU/Linux 10 (buster), with Firefox ESR 68.4.1esr (64-bit).

Please note, Firefox configuration has been modified - hardened to prevent remote sites code loaded to the browser to detect local time zone.

Using the same browser with the exact same configuration shows current time been displayed correctly in firmware v.18.06.5 and displayed incorrectly only on the system tab in firmware version 19.07.1.

Please see screenshots attached.

Development team - thank you for your efforts in writing this code and making it available free of charge. You guys are awesome! :)

Damien.


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

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

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

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

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

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

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

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

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


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`


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

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

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

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

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

 

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

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

PLEASE, FIX IT!

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

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

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

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

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

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

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

cat /etc/config/wireless

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

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

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

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'myssid'
        option encryption 'psk2+ccmp'
        option key 'removed'
        option ieee80211w '1'
25.02.20202856Base systemBug ReportVery LowHighWifi "dies" (hostapd drops all clients) on some ar71xx ...openwrt-19.07New Task Description

This issue is very strange, i don’t even know if it’s just faulty hardware but i have it happening on multiple devices now

Most affected hardware

  • Nanobridge M5 , in this case transmitting enough data can trigger it almost instantly
  • TL-WR841ND , in this case i had it happen like 3-4 times a year
  • CPE 210 v3 , in this case it happens like each week

For the last one, which is running 19.07 i found on the system log

Tue Feb 25 07:38:58 2020 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED [redacted mac1]
Tue Feb 25 07:38:58 2020 daemon.info hostapd: wlan0: STA [redacted mac1] IEEE 802.11: disassociated due to inactivity
Tue Feb 25 07:38:59 2020 daemon.info hostapd: wlan0: STA [redacted mac1] IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Feb 25 07:41:32 2020 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED [redacted mac2]
Tue Feb 25 07:41:32 2020 daemon.info hostapd: wlan0: STA [redacted mac2] IEEE 802.11: disassociated due to inactivity
Tue Feb 25 07:41:33 2020 daemon.info hostapd: wlan0: STA [redacted mac2] IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Tue Feb 25 07:42:49 2020 daemon.notice hostapd: wlan0: AP-STA-POLL-OK [redacted mac3]
Tue Feb 25 07:49:55 2020 daemon.notice hostapd: wlan0: AP-STA-POLL-OK [redacted mac3]
Tue Feb 25 07:55:02 2020 daemon.notice hostapd: wlan0: AP-STA-POLL-OK [redacted mac3]
Tue Feb 25 08:00:15 2020 daemon.notice hostapd: wlan0: AP-STA-POLL-OK [redacted mac3]
Tue Feb 25 08:05:25 2020 daemon.notice hostapd: wlan0: AP-STA-POLL-OK [redacted mac3]
Tue Feb 25 08:10:44 2020 daemon.notice hostapd: wlan0: AP-STA-POLL-OK [redacted mac3]
Tue Feb 25 08:16:00 2020 daemon.notice hostapd: wlan0: AP-STA-POLL-OK [redacted mac3]
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 ()
13.03.20202901Base systemBug ReportVery LowHighFlow offload not working properly in case of IPv6 (NAT6...openwrt-19.07Unconfirmed Task Description

Linksys WRT32X with NAT6 configuration.

On latest 19.07 branch r10959

With the flow_offload feature turned on, nat6 is not working properly.
The first (or several) TCP packets seemed to be fine but later packets were not properly transmitted. The connection was soon closed.

(In case of accessing ipv6.google.com, the browser would freeze. And the curl would freeze after receiving a portion of the HTML content.)

In the meantime, ICMPv6 worked normally.

After removing the FLOWOFFLOAD ip6tables record, everything is fine.
After inserting the `-m conntrack –cstate RELATED,ESTABLISHED -j ACCEPT` before the FLOWOFFLOAD everything is also fine.

IPv4 part looked normal even if flow_offload is on.

NAT6 worked on older versions like 18.04 branch with flow_offload enabled.

16.03.20202904Base systemBug ReportVery LowLowusb-storage fails to load in pre-initopenwrt-19.07Unconfirmed Task Description

As per forum post:

https://forum.openwrt.org/t/usb-storage-fail-to-load-in-preinit/54903

Basically, installed openwrt, added external root, all looks correctly configured, but after reboot external root fails to mount.
searching in the logs we can see that usb-storage is only loaded after pre-init, but it is listed in /etc/modprobe-boot.d/ ... checking /rom/etc/modules-boot.d/ it is not there.

Either something is missing in the https://openwrt.org/docs/guide-user/additional-software/extroot_configuration to add the usb-storage to the pre-init, or something is broken that makes pre-init fail to load usb-storage when it should.

The same setup worked fine with a older openwrt version (15.01 IIRC)

Supply the following if possible:
- Device problem occurs on
asus wl-500w

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

- Steps to reproduce
Install openwrt
add external root
manually mount to confirm setup
reboot
external root not mounted nor switched to, logs show that usb-storage is only loaded after normal root is mounted
manual mount still works

 


17.03.20202906Base systemBug ReportVery LowHighAdding v4 Static routes without selecting 'Advanced' Ta...openwrt-19.07Unconfirmed Task Description

Using Openwrt 19.07.2 release;
On TP-Link c2600 & N750(wdr4300 v1.4)

Observed behavior:

Adding a static v4 route i.e 172.16.253.0 via 172.16.253.254 in the Luci Static route page succesfully adds the route, and by default appears to select the local route table. However viewing the routes list in status or via ip r s on cli does not show the entry.

Work-Around:

Ensure that a different table is selected in the 'Advanced tab' then go back in and add it to the correct appropriate route table.



Expected behaviour:

Adding a static route add's it to the system route table irrespective of needing to switch into advanced tab and select a non-default route table first.


21.03.20202912Base systemBug ReportVery LowHighPhicomm K3 (bcm53xx) wifi channel can't be set to auto ...openwrt-19.07Unconfirmed Task Description

Device:Phicomm K3 (bcm53xx)
BUG:wifi channel can’t set to auto mode
Description:Wifi channel can’t set to auto mode in Network - Wireless.
When wireless channel sets to auto mode, wireless settings will change from AP to Cilent even I don’t do that.

22.03.20202919Base systemBug ReportVery LowLow18.06 to 19.07 upgrade fails [Netgear WNDR4300 v1]openwrt-19.07Unconfirmed Task Description

> If your device is not supported by the image You may encounter the error “Device not supported by this image” or “Image check failed”. In that case, please report the issue so that it can be fixed for the next 19.07.X minor release.

https://openwrt.org/docs/guide-user/installation/ar71xx.to.ath79


Tried to upgrade from

openwrt-18.06 branch (git-19.020.41695-6f6641d) / OpenWrt 18.06.2 r7676-cddd7b4c77

[to]

http://downloads.openwrt.org/releases/19.07.2/targets/ar71xx/nand/openwrt-19.07.2-ar71xx-nand-wndr4300-squashfs-sysupgrade.tar

I alternately receive the error “The connection was reset” or “Device not supported by this image”


> for LuCI: check “Force upgrade”

This option was not available

> for command-line sysupgrade: use sysupgrade -F -n <your-device-19.07-image-sysupgrade.bin>

This option succeeded and the new build is working normally, thanks

note: Once this issue is resolved, would it be feasible to host upgrade images on a free service like GitHub, so checks for new version could be performed through the web interface (similar to GL.Inet routers)

26.03.20202931Base systemBug ReportVery LowHighloading package information never arrivedopenwrt-19.07Unconfirmed Task Description

using fresh install

from Luci interface goto menu
system/software
the loading package information never arrived

pushing the update list button
the loading package information never arrived

using the console
opk update, list... are working well


07.04.20202977Base systemBug ReportVery LowHighParameters sendopts seems to be bad formated in the cal...openwrt-19.07Unconfirmed Task Description

The options parameters sendopts define in /etc/config/network seems to be badly formated in the call of the command odhcp6c

In /etc/config/network:

 

option sendopts “11:00 15:456544 16:1234”

is parsed like this (show via ps|grep odhcp6c)
-x11 00 -x15 456544 -x16 1234

The syntax given by the help of odhcp6c is different:

-x <opt>:<val> Add option opt (with value val) in sent packets (cumulative)

		Examples of IPv6 address, string and base-16 encoded options:
		-x dns:2001:2001::1,2001:2001::2 - option 23
		-x 15:office - option 15 (userclass)
		-x 0x1f4:ABBA - option 500
		-x 202:'"file"' - option 202

It appears than the : is replace by a space in the call of the command.
Regarding the help of the command, it should be :
-x 11:00 -x 15:456544 -x 16:1234

Thanks
Regards

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

21.04.20203031Base systemBug ReportVery LowHighBusybox force reinstalled when there are no opkg listsopenwrt-19.07Unconfirmed Task Description

Device problem occurs on: Turris Omnia, mvebu
Software version: OpenWrt 19.07.

Steps to reproduce:

I noticed this bug, when I forget to do before force-reinstalling busybox

opkg update

If there isn’t anything in folder /var/opkg-lists

root@turris:/# ls -la /var/opkg-lists
ls: /var/opkg-lists: No such file or directory

It is possible to remove busybox, which should not happen.

root@turris:/# opkg install busybox --force-reinstall
Removing package busybox from root...
Installing busybox (1.30.1-5.18) to root...
Collected errors:
 * opkg_download_pkg: Package busybox is not available from any configured src.
 * opkg_install_pkg: Failed to download busybox. Perhaps you need to run 'opkg update'?
 * opkg_install_cmd: Cannot install package busybox.

And then the device ends up being in a non-specific state when you can not do anything and you need to flash firmware it once again.

If you do

opkg update

before force-reinstalling busybox, it refuses to do it which is correct.

root@turris:~# opkg install busybox --force-reinstall
Refusing to remove essential package busybox.
        Removing an essential package may lead to an unusable system, but if
        you enjoy that kind of pain, you can force opkg to proceed against
        its will with the option: --force-removal-of-essential-packages
No packages removed.
Package busybox (1.30.1-5.18) installed in root is up to date.
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).

11.05.20203092Base systemBug ReportVery LowHighXiaomi Router 3G random rebootsopenwrt-19.07Unconfirmed Task Description

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

 

Hello,

I have a Xiaomi 3G router. Since the day I bought it I installed Openwrt and to tell you the truth, with version 18.06 I didn’t have any problem.

A few weeks ago I updated to the new version (19.07) using LuCI and it restarts me randomly.

I tried restoring the router, reinstalling the update and it keeps randomly rebooting. Right now I have it without any additional packages installed and it still keeps rebooting randomly.

I have noticed, that almost every time I see a reboot and look at the log file the first thing that appears is this, that is, the first line after the reboot is:

Mon May 11 22:16:59 2020 daemon.info dnsmasq[1148]: exiting on receipt of SIGTERM
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: started, version 2.80 cachesize 150
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: DNS service limited to local subnets
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify dumpfile
Mon May 11 22:16:59 2020 daemon.info dnsmasq-dhcp[2722]: DHCP, IP range 192.168.2.100 -- 192.168.2.249, lease time 12h
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain test
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain onion
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain localhost
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain local
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain invalid
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain bind
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain lan
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: reading /tmp/resolv.conf.auto
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain test
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain onion
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain localhost
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain local
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain invalid
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain bind
Mon May 11 22:16:59 2020 daemon.info dnsmasq[2722]: using local addresses only for domain lan

Please, I need help since I can’t work if it constantly resets. If you need any more information, please do not hesitate to ask me.

16.05.20203100Base systemBug ReportVery LowLowminiupnpd.conf generated by /etc/init.d/miniupnpd uses ...openwrt-19.07Unconfirmed Task Description

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

  • OpenWrt 19.07.2, r10947-65030d81f3
  • miniupnpd - 2.1.20191006-4

I have both native IPv6 (wan_6 virtual interface from pppoe) and 6to4. I need 6to4 to connect to other 6to4 peers which is faster than native IPv6 (and sometimes native IPv6 cannot reach 6to4). /var/etc/miniupnpd.conf generated by /etc/init.d/miniupnpd uses 6to4 instead of native IPv6, the file contains the following lines

ext_ifname=pppoe-wan
ext_ifname6=6to4-wan6

I think it’s better to use native IPv6 interface by default.
Additionally, is it possible to add ipv6_disable option to the config? Buggy UPnP clients sometimes put IPv6 address in a IPv4 port mapping request, I’d like to check if disabling IPv6 UPnP would fix it, this problem is mentioned in https://github.com/miniupnp/miniupnp/issues/408

18.05.20203109Base systemBug ReportVery LowCriticalUBIFS failure/crash on BT HomeHub 2B: __nand_correct_da...openwrt-19.07Unconfirmed Task Description

Device: BT HomeHub Version 2B (Lantiq XWAY)

Software: 19.07.3 downloaded from:

https://downloads.openwrt.org/releases/19.07.3/targets/lantiq/xway/openwrt-19.07.3-lantiq-xway-bt_homehub-v2b-squashfs-sysupgrade.bin

After an hour or so of usage, the router reboots itself with a corrupted filesystem. I’ve attached the log to this bug report. The log contains:

__nand_correct_data: uncorrectable ECC error

so I think there might be a link with the similar problem that the BT HomeHub Version 5A had a long time ago, as per:

https://bugs.openwrt.org/index.php?do=details&task_id=245 (”Lede won’t boot on HHB5”)

and

http://openwrt.ebilan.co.uk/viewtopic.php?f=7&t=133#p1022 (post by Mathias Kresin / mkresin who fixed the problem with the Home Hub 5A)

This bug may also be related to:

https://bugs.openwrt.org/index.php?do=details&task_id=1842

(I think that this bug may affect every release since 18.06.0)

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.

 


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.

29.05.20203134Base systemBuild FailureVery LowHighCan't build netifdopenwrt-19.07Unconfirmed Task Description

Environment: x86_64
Arch Linux
Description: Can’t build current openwrt-19.07. (Arch Linux, tried both GCC 10.1.0 and 8.4.0. Getting two build errors:

CFLAGS="-Os -pipe -mno-branch-likely -mips32r2 -mtune=74kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -mips16 -minterlin
k-mips16 -iremap/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944:netifd-2019-08-05-5e02f944 -Wformat -Werror=format-security -fstack-protector -D_F
ORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include/libnl-tiny -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mips
el_74kc_musl/usr/include -flto  -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/includ
e -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/usr/include -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/include/fo
rtify -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/include " CXXFLAGS="-Os -pipe -mno-branch-likely -mips32r2 -mtune=74kc -fno-caller-saves -fno-plt -fho
nour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -mips16 -minterlink-mips16 -iremap/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-
2019-08-05-5e02f944:netifd-2019-08-05-5e02f944 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -I/home/legogris/dev/openwrt-fresh/staging_dir/tar
get-mipsel_74kc_musl/usr/include/libnl-tiny -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include -flto  -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mips
el_74kc_musl/usr/include -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/include -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/usr/
include -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/include/fortify -I/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/
include " LDFLAGS="-L/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/lib -L/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/lib -L/home/legogris/de
v/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/usr/lib -L/home/legogris/dev/openwrt-fresh/staging_dir/toolchain-mipsel_74kc_gcc-7.5.0_musl/lib -znow -zrelro -flto -fuse-linke
r-plugin " make  -C /home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/. AR="mipsel-openwrt-linux-musl-gcc-ar" AS="mipsel-openwrt-linux-musl-gcc -c -
Os -pipe -mno-branch-likely -mips32r2 -mtune=74kc -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -iremap/home/legogris/dev/o
penwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944:netifd-2019-08-05-5e02f944 -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,re
lro -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include/libnl-tiny -I/home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/usr/include -flto" LD=m
ipsel-openwrt-linux-musl-ld NM="mipsel-openwrt-linux-musl-gcc-nm" CC="mipsel-openwrt-linux-musl-gcc" GCC="mipsel-openwrt-linux-musl-gcc" CXX="mipsel-openwrt-linux-musl-g++" RANLIB="mipsel-open
wrt-linux-musl-gcc-ranlib" STRIP=mipsel-openwrt-linux-musl-strip OBJCOPY=mipsel-openwrt-linux-musl-objcopy OBJDUMP=mipsel-openwrt-linux-musl-objdump SIZE=mipsel-openwrt-linux-musl-size CROSS="
mipsel-openwrt-linux-musl-" ARCH="mipsel" CMAKE_COMMAND='/home/legogris/dev/openwrt-fresh/staging_dir/host/bin/cmake' CMAKE_DISABLE_cmake_check_build_system=1 ;
make[4]: Entering directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[5]: Entering directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[6]: Entering directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[6]: Leaving directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[6]: Entering directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
[  4%] Building C object CMakeFiles/netifd.dir/main.c.o
In file included from /home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/netifd.h:29:0,
                 from /home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/main.c:22:
/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/utils.h:116:51: error: 'struct uci_blob_param_list' declared inside parameter list will not be vis
ible outside of this definition or declaration [-Werror]
 const char * uci_get_validate_string(const struct uci_blob_param_list *p, int i);
                                                   ^~~~~~~~~~~~~~~~~~~
cc1: error: unrecognized command line option '-Wno-unknown-warning-option' [-Werror]
cc1: all warnings being treated as errors
make[6]: *** [CMakeFiles/netifd.dir/build.make:63: CMakeFiles/netifd.dir/main.c.o] Error 1
make[6]: Leaving directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[5]: *** [CMakeFiles/Makefile2:76: CMakeFiles/netifd.dir/all] Error 2
make[5]: Leaving directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[4]: *** [Makefile:130: all] Error 2
make[4]: Leaving directory '/home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944'
make[3]: *** [Makefile:49: /home/legogris/dev/openwrt-fresh/build_dir/target-mipsel_74kc_musl/netifd-2019-08-05-5e02f944/.built] Error 2
make[3]: Leaving directory '/home/legogris/dev/openwrt-fresh/package/network/config/netifd'
time: package/network/config/netifd/compile#0.33#0.08#0.39
make[2]: *** [package/Makefile:113: package/network/config/netifd/compile] Error 2
make[2]: Leaving directory '/home/legogris/dev/openwrt-fresh'
make[1]: *** [package/Makefile:107: /home/legogris/dev/openwrt-fresh/staging_dir/target-mipsel_74kc_musl/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/legogris/dev/openwrt-fresh'
make: *** [/home/legogris/dev/openwrt-fresh/include/toplevel.mk:227: world] Error 2
make -j1 V=s  20,02s user 4,25s system 102% cpu 23,565 total
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.

03.06.20203147Base systemBug ReportVery LowHigh802.11w settings on LUCI WIFI page doesn't work properl...openwrt-19.07Unconfirmed Task Description

Host device

Device problem occurs on: Phicomm PSG1218A (MTK7620, 64M, 8MB, 802.11AC+N)
Software versions of OpenWrt/LEDE release: OpenWRT 19.07.3 Stable (r11063-85e04e9f46 / LuCI openwrt-19.07 branch git-20.136.49537-fb2f363)
Package: wpad-openssl OR hostapd-openssl

External server/service

RADIUS server: Windows Server 2019 NPAS, worked fine with WPA2-EAP

Client

Client WIFI chip and driver: Intel Dual Band Wireless-AC 8265 running newest driver version 20.70.16.4 (driver date: 01/01/2020)

Steps to reproduce:

1. initialize default settings, then remove wpad-basic and install wpad-openssl OR hostapd-openssl to enable WPA3 AP mode
2. leave 802.11w to default setting which is “Required” 3. set country setting, ssid, and etc. as required such as radius for EAP
4 if use WPA2-PSK or WPA2-EAP with default settings, everything works fine.

5. switch WIFI (AC/N) to WPA2-PSK/WPA3-SAE mixed mode (sae+ccmp or something like that) OR WPA2-EAP/WPA3-EAP mixed mode (wpa3-mixed+ccmp or something like that)
6. apply settings wait until effective or reboot to take effect

6.1 __ssid won't come up on 802.11g/n interface__ if in PSK/SAE mixed mode.

7. Client (Intel 8265) won’t be able to connect to SSID,

7.1 if ssid would come up (802.11a/ac), it would be seen on client scan, but the client (Intel 8265) won't be able to connect to SSID, reports "Can't connect", in EAP mode, router side log "Deauthenticated due to local request" after "EAP-SUCCESS"

8. switch 802.11w to other settings, including “Optional”, problem remains, router config file /etc/config/wireless would list “option ieee80211w ‘1’” 9. switch 802.11w to other settings, including “Optional”, problem still remains, router config file /etc/config/wireless will be missing the “option ieee80211w” completely, and it seems wpad or hostapd would assume “optional” (code ‘1’) as default value instead of the documented “disabled” (code ‘0’).

Steps to workaround:

Manually set “option ieee80211w ‘0’” in /etc/config/wireless to disable 802.11w and don’t update settings through LUCI on the problematic ssid, restart wifi. Everything would work.

13.06.20203178Base systemBug ReportVery LowLowOpenWrt Radio 5.8Ghz PS4 slim openwrt-19.07Unconfirmed Task Description

I have a connection problem between PS4 slim in the 5.8 Ghz band
I am using a TpLink C59 OpenWrt router 19.07.3 r11063-85e04e9f46
All the devices work well in the 5.8GHz band but the PS4 does not link in the 5.8Hz band instead the PS4 works well in the 2.8Ghz band. I have this problem since I migrated to 19.07 with the previous version 18.06 the PS4 worked fine in band 5.8 Ghz
With all three versions of 19.07 the problem is the same.
I am using the Ar71xx driver but the problem repeats with Ath79
The PS4 works OK with other Access Points in band 5.8 Ghz
The failure also occurs without encryption and with a fixed IP.
From another device the ping fails when I ping against the PS4 in band 5.8 Ghz
Using the 2.4 GHz radio all OK
Someone had a similar problem.
Very good OpenWrt
Greetings and thanks


14.06.20203181Base systemBug ReportVery LowHighunable to build 19.07.3 for clearfog proopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on
Clearfog pro

- Software versions of OpenWrt/LEDE release, packages, etc.
tag 19.07.3
- Steps to reproduce
make fails:

export CROSS="arm-openwrt-linux-muslgnueabi-"  NO_RENAME=1 ; NM="arm-openwrt-linux-muslgnueabi-nm" STRIP="/home/oli/openwrt/staging_dir/host/bin/sstrip" STRIP_KMOD="/home/oli/openwrt/scripts/strip-kmod.sh" PATCHELF="/home/oli/openwrt/staging_dir/host/bin/patchelf" /home/oli/openwrt/scripts/rstrip.sh /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools
rstrip.sh: /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/usr/sbin/fw_printenv: executable
(cd /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/CONTROL; ( echo "$CONTROL"; printf "Description: "; echo "$DESCRIPTION" | sed -e 's,^[[:space:]]*, ,g'; ) > control; chmod 644 control; ( echo "#!/bin/sh"; echo "[ \"\${IPKG_NO_SCRIPT}\" = \"1\" ] && exit 0"; echo "[ -x "\${IPKG_INSTROOT}/lib/functions.sh" ] || exit 0"; echo ". \${IPKG_INSTROOT}/lib/functions.sh"; echo "default_postinst \$0 \$@"; ) > postinst; ( echo "#!/bin/sh"; echo "[ -x "\${IPKG_INSTROOT}/lib/functions.sh" ] || exit 0"; echo ". \${IPKG_INSTROOT}/lib/functions.sh"; echo "default_prerm \$0 \$@"; ) > prerm; chmod 0755 postinst prerm; echo "$V_Package_uboot_envtools_conffiles" > conffiles;  )
install -d -m0755 /home/oli/openwrt/bin/targets/mvebu/cortexa9/packages
/home/oli/openwrt/scripts/ipkg-build -c -o 0 -g 0 /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools /home/oli/openwrt/bin/targets/mvebu/cortexa9/packages
/home/oli/openwrt/staging_dir/host/bin/find: '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/etc/config/ubootenv': No such file or directory
/home/oli/openwrt/staging_dir/host/bin/find: '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools/etc/fw_env.config': No such file or directory
Packaged contents of /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-2018.03/ipkg-arm_cortex-a9_vfpv3-d16/uboot-envtools into /home/oli/openwrt/bin/targets/mvebu/cortexa9/packages/uboot-envtools_2018.03-3_arm_cortex-a9_vfpv3-d16.ipk
echo "uboot-envtools" >> /home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/pkginfo/uboot-envtools.default.install
make[3]: Leaving directory '/home/oli/openwrt/package/boot/uboot-envtools'
time: package/boot/uboot-envtools/compile#1.27#0.68#1.71
make[3]: Entering directory '/home/oli/openwrt/package/boot/uboot-mvebu'
rm -f /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03/.built
touch /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03/.built_check
make  -C /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03 CROSS_COMPILE=arm-openwrt-linux-muslgnueabi- DTC="/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linux-4.14.180/scripts/dtc/dtc" HOSTCC="gcc" HOSTCFLAGS="-O2 -I/home/oli/openwrt/staging_dir/host/include -I/home/oli/openwrt/staging_dir/hostpkg/include -I/home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/host/include -I/home/oli/openwrt/staging_dir/host/include -I/home/oli/openwrt/staging_dir/hostpkg/include -I/home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/host/include -std=gnu11" HOSTLDFLAGS="-L/home/oli/openwrt/staging_dir/host/lib -L/home/oli/openwrt/staging_dir/hostpkg/lib -L/home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/host/lib"
make[4]: Entering directory '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03'
  CHK     include/config/uboot.release
  CHK     include/generated/version_autogenerated.h
  CHK     include/generated/timestamp_autogenerated.h
  CC      lib/asm-offsets.s
  CHK     include/generated/generic-asm-offsets.h
  UPD     include/generated/generic-asm-offsets.h
  CC      arch/arm/lib/asm-offsets.s
  CHK     include/generated/asm-offsets.h
  UPD     include/generated/asm-offsets.h
  HOSTLD  scripts/dtc/dtc
/usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x10): multiple definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
make[6]: *** [scripts/Makefile.host:108: scripts/dtc/dtc] Error 1
make[5]: *** [scripts/Makefile.build:425: scripts/dtc] Error 2
make[4]: *** [Makefile:491: scripts] Error 2
make[4]: Leaving directory '/home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03'
make[3]: *** [Makefile:53: /home/oli/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/u-boot-clearfog/u-boot-2018.03/.built] Error 2
make[3]: Leaving directory '/home/oli/openwrt/package/boot/uboot-mvebu'
time: package/boot/uboot-mvebu/clearfog/compile#0.32#0.20#0.51
make[2]: *** [package/Makefile:113: package/boot/uboot-mvebu/compile] Error 2
make[2]: Leaving directory '/home/oli/openwrt'
make[1]: *** [package/Makefile:107: /home/oli/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/oli/openwrt'
make: *** [/home/oli/openwrt/include/toplevel.mk:227: world] Fehler 2
15.06.20203187Base systemBug ReportVery LowLowLinkSys 1900ACS - WLAN 5GHz - 802.11AC with 802.11N at...openwrt-19.07Unconfirmed Task Description

I was upgraded to my LinkSys WRT-1900ACS from LEDE 17.01.6 to OpenWRT 19.07.3.

With LEDE 17.01.6 I can set up 5GHz WLAN to use N and AC at the same time with two different SSID and with this setup some old devices can connect to this 5GHz WLAN with 802.11n correctly while my notebook can connect to 802.11AC on 5GHz network too (I used two different SSID setup both setting used 5GHz network).

After I upgraded to OpenWrt I found there is no option to set up both 802.11N and 802.11AC with 5GHz at the same time and my old WiFi devices need to use 2.4GHz network only.

With the OpenWrt 19.07.3 the ‘require_mode’ option can set globally so need to decide to use AC or N only for all 5GHz SSID.

Is there any way to set 5GHz with both N and AC at the same time or there is no option by technical reason?

21.06.20203196Base systemBug ReportVery LowLowOpenWRT on Freescale's P2020RDBopenwrt-19.07Unconfirmed Task Description

I’m trying to run OpenWRT on a P2020RDB board, I managed to fetch the release mpc85xx initramfs.bin from here (I failed to get the snapshot one for Freescale over here as I received a 403 error), and then I pulled it into uboot using tftpboot, and placed it at address “0×1000000“, and ran “bootm 0×1000000” the kernel starts and then I get a call trace and some stuff get dumped:

XTM-330_P2020(FAILSAFE) => bootm 0x1000000                                                                                                                      [165/195]
WARNING: adjusting available memory to 30000000                                                                                                                          
## Booting kernel from FIT Image at 01000000 ...                                                                                                                         
   Using 'config@1' configuration                                                                                                                                        
   Trying 'kernel@1' kernel subimage                                                                                                                                     
     Description:  POWERPC OpenWrt Linux-4.14.180                                                                                                                        
     Type:         Kernel Image                                                                                                                                          
     Compression:  gzip compressed                                                                                                                                       
     Data Start:   0x010000ec                                                                                                                                            
     Data Size:    5128735 Bytes = 4.9 MiB                                                                                                                               
     Architecture: PowerPC                                                                                                                                               
     OS:           Linux                                                                                                                                                 
     Load Address: 0x00000000
     Entry Point:  0x00000000
     Hash algo:    crc32
     Hash value:   7754597c
     Hash algo:    sha1
     Hash value:   bd433c824dc74e015b759f3ab53ffe996b130f2e
   Verifying Hash Integrity ... crc32+ sha1+ OK
## Flattened Device Tree from FIT Image at 01000000
   Using 'config@1' configuration
   Trying 'fdt@1' FDT blob subimage
     Description:  POWERPC OpenWrt p2020rdb device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x014e4448
     Data Size:    12550 Bytes = 12.3 KiB
     Architecture: PowerPC
     Hash algo:    crc32
     Hash value:   0d1ae91a
     Hash algo:    sha1
     Hash value:   fdbac0f412982769bdef3ba414fc6716b8a855d4
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x14e4448 
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 00ff9000, end 00fff105 ... OK
[    0.000000] Memory CAM mapping: 256/256/256 Mb, residual: 256Mb
[    0.000000] Linux version 4.14.180 (builder@buildhost) (gcc version 7.5.0 (OpenWrt GCC 7.5.0 r11063-85e04e9f46)) #0 SMP Sat May 16 18:32:20 2020
[    0.000000] Using P2020 RDB machine description
[    0.000000] bootconsole [udbg0] enabled
[    0.000000] CPU maps initialized for 1 thread per core
[    0.000000] -----------------------------------------------------
[    0.000000] phys_mem_size     = 0x30000000
[    0.000000] dcache_bsize      = 0x20
[    0.000000] icache_bsize      = 0x20
[    0.000000] cpu_features      = 0x0000000012100460
[    0.000000]   possible        = 0x0000000012120460
[    0.000000]   always          = 0x0000000000100000
[    0.000000] cpu_user_features = 0x84e08000 0x08000000
[    0.000000] mmu_features      = 0x00020010
[    0.000000] -----------------------------------------------------
mpc85xx_rdb_setup_arch()
[    0.000000] mpc85xx_qe_init: Could not find Quicc Engine node
[    0.000000] MPC85xx RDB board from Freescale Semiconductor
[    0.000000] barrier-nospec: using isync; sync as speculation barrier
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000002fffffff]
[    0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts
[    0.000000] percpu: Embedded 12 pages/cpu s18380 r8192 d22580 u49152
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 195072
[    0.000000] Kernel command line: root=/dev/sda1 rw rootdelay=30 console=ttyS0,115200 ramdisk_size=600000
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 705444K/786432K available (4400K kernel code, 176K rwdata, 548K rodata, 2620K init, 216K bss, 80988K reserved, 0K cma-reserved)
[    0.000000] Kernel virtual memory layout:
[    0.000000]   * 0xfffdf000..0xfffff000  : fixmap
[    0.000000]   * 0xfdffe000..0xfe000000  : early ioremap
[    0.000000]   * 0xf1000000..0xfdffe000  : vmalloc & ioremap
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16
[    0.000000] mpic: Setting up MPIC " OpenPIC  " version 1.2 at ffe40000, max 2 CPUs
[    0.000000] mpic: ISU size: 256, shift: 8, mask: ff
[    0.000000] mpic: Initializing for 256 sources
[    0.000000] mpc85xx_rdb_pic_init: Could not find qe-ic node
[    0.000010] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0xf6018975a, max_idle_ns: 440795204712 ns
[    0.010162] clocksource: timebase mult[f000003] shift[24] registered
[    0.016543] pid_max: default: 32768 minimum: 301
[    0.021182] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.027710] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.035198] mpic: requesting IPIs...
[    0.039003] Hierarchical SRCU implementation.
[    0.043596] smp: Bringing up secondary CPUs ...
[    0.048509] smp: Brought up 1 node, 2 CPUs
[    0.052518] Using shared cache scheduler topology
[    0.058928] random: get_random_u32 called from 0xc0201c80 with crng_init=0
[    0.065843] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.075502] futex hash table entries: 512 (order: 2, 16384 bytes)
[    0.081889] NET: Registered protocol family 16
[    0.094212] Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->0
[    0.102052] PCI host bridge /pcie@ffe0a000 (primary) ranges:
[    0.107677]  MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000 
[    0.114869]   IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
[    0.121993] /pcie@ffe0a000: PCICSRBAR @ 0xfff00000
[    0.126746] setup_pci_atmu: end of DRAM 30000000
[    0.131344] /pcie@ffe0a000: Setting PCI inbound window greater than memory size
[    0.146042] PCI: Probing PCI hardware
[    0.149766] fsl-pci ffe0a000.pcie: PCI host bridge to bus a000:00
[    0.155778] pci_bus a000:00: root bus resource [io  0x0000-0xffff]
[    0.161927] pci_bus a000:00: root bus resource [mem 0x80000000-0x9fffffff]
[    0.168774] pci_bus a000:00: root bus resource [bus 00-ff]
[    0.174535] pci a000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[    0.182529] pci a000:00:00.0: PCI bridge to [bus 01-ff]
[    0.187722] PCI: Cannot allocate resource region 0 of device a000:00:00.0, will remap
[    0.195494] pci a000:00:00.0: BAR 0: no space for [mem size 0x00100000]
[    0.202057] pci a000:00:00.0: BAR 0: failed to assign [mem size 0x00100000]
[    0.208993] pci a000:00:00.0: PCI bridge to [bus 01]
[    0.213933] pci a000:00:00.0:   bridge window [io  0x0000-0xffff]
[    0.220002] pci a000:00:00.0:   bridge window [mem 0x80000000-0x9fffffff]
[    0.226764] pci_bus a000:00: Some PCI device resources are unassigned, try booting with pci=realloc
[    0.235925] /soc@ffe00000/timer@41100: cannot get timer frequency.
[    0.242059] /soc@ffe00000/timer@42100: cannot get timer frequency.
[    0.254462] clocksource: Switched to clocksource timebase
[    0.260493] NET: Registered protocol family 2
[    0.265162] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.272178] TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
[    0.278670] TCP: Hash tables configured (established 8192 bind 8192)
[    0.285022] UDP hash table entries: 512 (order: 2, 16384 bytes)
[    0.290884] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
[    0.297300] NET: Registered protocol family 1
[    2.607509] Crashlog allocated RAM at address 0x3f00000
[    2.612901] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[    2.622935] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    2.628700] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc.
[    2.639761] io scheduler noop registered
[    2.643605] io scheduler deadline registered (default)
[    2.649567] pcieport a000:00:00.0: enabling device (0106 -> 0107)
[    2.655875] pcieport a000:00:00.0: AER enabled with IRQ 24
[    2.661445] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled
rserial8250.0: ttyS0 at MMIO 0xffe04500 (irq = 42, base_baud = 33333333) is a 16550A
[    2.681148] console [ttyS0] enabled
[    2.681148] console [ttyS0] enabled
[    2.688069] bootconsole [udbg0] disabled
[    2.688069] bootconsole [udbg0] disabled
[    2.696040] serial8250.0: ttyS1 at MMIO 0xffe04600 (irq = 42, base_baud = 33333333) is a 16550A
[    2.705190] console [ttyS0] disabled
[    2.708811] console [ttyS0] enabled
[    2.712565] ffe04600.serial: ttyS1 at MMIO 0xffe04600 (irq = 42, base_baud = 33333333) is a 16550
[    2.722481] Disabling lock debugging due to kernel taint
[    2.722487] fsl-lbc ffe05000.localbus: Chip select error: LTESR 0x00080000
[    2.734643] Machine check in kernel mode.
[    2.738637] Caused by (from MCSR=10008): 
[    2.738640] Bus - Read Data Bus Error
[    2.746282] Oops: Machine check, sig: 7 [#1]
[    2.750535] BE SMP NR_CPUS=2 P2020 RDB
[    2.754272] Modules linked in:
[    2.757319] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G   M            4.14.180 #0
[    2.764610] task: ef448000 task.stack: ef450000
[    2.769125] NIP:  c02995d0 LR: c028f240 CTR: c02995b0
[    2.774161] REGS: effe3f10 TRAP: 0204   Tainted: G   M             (4.14.180)
[    2.781276] MSR:  00029000 <CE,EE,ME>  CR: 24000282  XER: 00000000
[    2.787449] DEAR: f1200000 ESR: 00800000 
[    2.787449] GPR00: c028f524 ef451c20 ef448000 ef451c34 ef49c91c 00000020 ef451cc8 ef451cc8 
[    2.787449] GPR08: 00000002 00000002 f1200000 00000002 24000282 00000000 c049ae20 c049a00c 
[    2.787449] GPR16: c049ad84 c049adc0 c049add8 ef48f158 00000000 c049ad50 ef49c910 01000000 
[    2.787449] GPR24: c049a000 00000000 00000000 00000000 00000000 00000022 00000002 ef49c91c 
[    2.824804] Call Trace:
[    2.827240] [ef451c20] [ef451cd0] 0xef451cd0 (unreliable)
[    2.832625] [ef451c60] [c028f524] 0xc028f524
[    2.836882] [ef451c80] [c028e3dc] 0xc028e3dc
[    2.841138] [ef451cc0] [c02991a8] 0xc02991a8
[    2.845394] [ef451d40] [c028e2b8] 0xc028e2b8
[    2.849651] [ef451d60] [c029993c] 0xc029993c
[    2.853907] [ef451de0] [c0273138] 0xc0273138
[    2.858164] [ef451df0] [c02715b8] 0xc02715b8
[    2.862420] [ef451e20] [c02717f4] 0xc02717f4
[    2.866676] [ef451e40] [c026f634] 0xc026f634
[    2.870933] [ef451e70] [c0270a88] 0xc0270a88
[    2.875189] [ef451e90] [c0272158] 0xc0272158
[    2.879446] [ef451ea0] [c0003140] 0xc0003140
[    2.883702] [ef451f00] [c04d8b40] 0xc04d8b40
[    2.887959] [ef451f30] [c00032d0] 0xc00032d0
[    2.892215] [ef451f40] [c00103b0] 0xc00103b0
[    2.896470] Instruction dump:
[    2.899427] 48000008 0fe00000 7c0004ac 4e800020 81240018 8144000c 2f890001 40be000c 
[    2.907163] 7d2a28ae 48000028 2f890002 40be000c <7d2a2a2e> 48000018 2f890004 409e000c 
[    2.915079] ---[ end trace c9ea2fa8a0ac4ace ]---
[    2.920341] 
[    3.911837] Kernel panic - not syncing: Fatal exception
[    3.917450] Rebooting in 1 seconds..

Is there something wrong I’m doing? Or is this a bug upstream?

27.06.20203207Base systemBug ReportVery LowHighSetting MTU on Bridged interfaces does not set MTU on m...openwrt-19.07Unconfirmed Task Description

- Device problem occurs on - x86
- Software versions of OpenWrt/LEDE release, packages, etc. - 19.07.3

 

I think it’s a bug/overlooked use case, but when you have interfaces bridged in the UCI config, the MTU setting does not get applied to the member interfaces (physical or VLAN).

config interface 'lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.1.1'
        option type 'bridge'
        option mtu '9000'
        option ifname 'eth1 eth4.10'

When I boot using this config I have connectivity issues with devices using Jumbo frames. ifconfig confirms that MTUs on the members interfaces are still at default 1500.

eth1      Link encap:Ethernet  HWaddr 0C:C4:7A:AB:39:3D
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Memory:df440000-df45ffff

eth4      Link encap:Ethernet  HWaddr 3C:FD:FE:BB:01:50
          inet6 addr: fe80::3efd:feff:febb:150/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500 Metric:1
          RX packets:50176 errors:0 dropped:1 overruns:0 frame:0
          TX packets:37468 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:15692679 (14.9 MiB)  TX bytes:29263711 (27.9 MiB)

eth4.10   Link encap:Ethernet  HWaddr 3C:FD:FE:BB:01:50
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:36728 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20850 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9314410 (8.8 MiB)  TX bytes:26473088 (25.2 MiB)

I have to manually use the ifconfig tool to set the MTU (i.e. ifconfig eth4.10 mtu 9000) to get the network back up and running correctly.

Obviously these commands could be scritped, however it was my understanding the UCI network config should be doing this .

08.07.20203218Base systemBug ReportVery LowLowhostapd log_level ingoredopenwrt-19.07Unconfirmed Task Description

Model: TP-Link Archer C7 v2
Architecture: Qualcomm Atheros QCA9558 ver 1 rev 0
Firmware Version :OpenWrt 19.07.2 r10947-65030d81f3 / LuCI openwrt-19.07 branch git-20.155.55664-f35803e
Kernel Version: 4.14.171

root@router:/tmp/run# uci show wireless | grep log
wireless.radio0.log_level='3'
wireless.radio1.log_level='3'
root@router:/tmp/run# cat hostapd-phy* | grep log
logger_syslog=127
logger_syslog_level=3
logger_stdout=127
logger_stdout_level=3
logger_syslog=127
logger_syslog_level=3
logger_stdout=127
logger_stdout_level=3
root@router:/tmp/run# hostapd_cli -i wlan0 log_level
Current level: INFO
Timestamp: 0
root@router:/tmp/run# hostapd_cli -i wlan1 log_level
Current level: INFO
Timestamp: 0
root@router:/tmp/run# hostapd_cli -i wlan1-1 log_level
Current level: INFO
Timestamp: 0
root@router:/tmp/run# hostapd_cli -i wlan1-1 log_level 2
FAIL
root@router:/tmp/run# opkg list-installed | grep hostapd
hostapd-common - 2019-08-08-ca8c2bd2-4
hostapd-utils - 2019-08-08-ca8c2bd2-4
root@router:/tmp/run# opkg list-installed | grep wpad
wpad - 2019-08-08-ca8c2bd2-4

Hello, I have a problem with the loglevel of hostapd. However the loglevel get ignored by the daemon and even the direct manipulation over hostapd_cli failed. Because of this the syslog get spammed by all the info messages.
It is predefined here: https://github.com/openwrt/openwrt/blob/openwrt-19.07/package/network/services/hostapd/Config.in But I don’t know why it is unchangeable at all

11.07.20203224Base systemBug ReportVery LowLowA VLAN goes out when a new VLAN is addedopenwrt-19.07Unconfirmed Task Description

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

 

Hostname OpenWrt
Model Linksys WRT1900ACS
Architecture ARMv7 Processor rev 1 (v7l)
Firmware Version OpenWrt 19.07.3 r11063-85e04e9f46 / LuCI openwrt-19.07 branch git-20.136.49537-fb2f363
Kernel Version 4.14.180

At the outset, there are two VLANs pre-existing: 1 (LAN) and 2 (WAN)
In LuCi, create the following VLANs: 10, 20, 21, 2200, 2204, 2208, 3000.

At that point, I created a new VLAN on the Network/Switch page in LuCi. The new VLAN had an initial default VID of 10, which I changed to 11. I set the tagging to my need (Tagged on CPU and LAN port 3, off on all other ports) without touching the other nine VLANs.

As soon as I hit Save & apply, VLAN 10 stopped working entirely.

Examining the configuration files, I find these two stanzas:

config switch_vlan

option device 'switch0'
option vlan '3'
option ports '5t 1t'
option vid '10'

. . .

config switch_vlan

option device 'switch0'
option vlan '10'
option ports '5t 1t'
option vid '11'

This leads me to the hypothesis that the “vlan” option of 10 is colliding with the “vid” option of 10 on another VLAN, though it seems like these should be separate, unrelated concepts.

My workaround was to redo my VLAN scheme so that former VLANs 10, 11, 20 and 21 are now 1000, 1100, 2000 and 2100 respectively, which was enough to prevent this collision, and it all works, but it seems like it should not have had the collision in the first place.

28.07.20203253Base systemBug ReportVery LowCriticalLinksys WRT3200 ipv4 connection speed problems openwrt-19.07Unconfirmed Task Description

I’m using Linksys wrt3200 as router behind cable modem with a dslite configuration and Devolo 1200+ DinRail connected to one of the LAN ports.

Previuos configuration was provider cable modem connected to Devolo and it was working fine (up to 50-100 mbit up and download to all DLAN devices.

After swiching to Linksys and OpenWRT I noticed that download speed for IPv4 dropped to 2-3 MBit for all devices. Upload and IPv6 work fine.

Thought it was dslite problem but provider router works fine and if I connect to Linksys directly via WLAN the download speed is as expected...

Repatched with Linksys stock firmware without changing anything else stable up and download speeds in expected range for ip4/ip6.

Patched openwrt back - ipv4 download drop to 2Mbit, back to stock back to normal speed...

Assume it’s potentially an MTU setting for LAN interface but all values I tried did not change much...

Would appreciate any help. Would be pity to fall back to stock but if it’s the only option...

 


21.08.20203298Base systemBug ReportVery LowCriticalEdimax 3G-6200n z OpenWrt 19.07.2 lost settings after r...openwrt-19.07Unconfirmed Task Description

Edimax 3G-6200n OpenWrt 19.07.2, r10947-65030d81f3

Steps:
1. Download the latest version OpenWrt 19.07.2 to Edimax 3G-6200n.
2. Set e.g. the password to the router and/or turn on the WiFi.
3. Reboot the router with the reboot option in OpenWrt.
4. The router has no settings previously saved - the status is as right after installing fresh OpenWRT - no password, no WiFi enabled, default settings.

Problem with JFFS.

root@OpenWrt:~# mount
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
tmpfs on /tmp/root type tmpfs (rw,noatime,mode=755)
overlayfs:/tmp/root on / type overlay (rw,noatime,lowerdir=/,upperdir=/tmp/root/upper,workdir=/tmp/root/work)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.0M      3.0M         0 100% /rom
tmpfs                    13.8M    284.0K     13.5M   2% /tmp
tmpfs                    13.8M     60.0K     13.7M   0% /tmp/root
overlayfs:/tmp/root      13.8M     60.0K     13.7M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev

root@OpenWrt:~# free
              total        used        free      shared  buff/cache   available
Mem:          28276       14008        5224         344        9044       11872
Swap:             0           0           0
#here I added the password and turned on the WiFi network - the free RAM decreased
root@OpenWrt:~# free
              total        used        free      shared  buff/cache   available
Mem:          28276       15632        3496         368        9148       10236
Swap:             0           0           0
root@OpenWrt:~#
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'
06.09.20203327Base systemBug ReportVery LowLowEthernet LED assignments incorrect on Linkysys WRT32Xopenwrt-19.07Unconfirmed Task Description

Device: Linksys WRT32X
OpenWRT version: OpenWrt 19.07.3 r11063-85e04e9f46

The LAN/WAN link LEDs seem to be incorrectly assigned in OpenWRT (offset by 1):

- LAN Port 1 link results in no LED lighting
- LAN Ports 2-4 light LAN link LEDs 1-3 respectively
- WAN port lights LAN LED 4

The WAN LED is assigned to the correct (and default) interface (eth1) in LUCI. The rest of the LEDs are not configurable, leading me to believe the issue is with indexing of the LEDs themselves, as opposed to LED-Port assignment.

09.09.20203330Base systemBug ReportVery LowLowds-lite: too low default MTUopenwrt-19.07Unconfirmed Task Description

Supply the following if possible:
- Device problem occurs on TP-Link Archer C7 v5
- Software versions of OpenWrt/LEDE release, packages, etc.

OpenWrt 19.07.3 r11063-85e04e9f46 / LuCI openwrt-19.07 branch git-20.136.49537-fb2f363
ds-lite 7-4

- Steps to reproduce: install system, install ds-lite, the mtu for all dslite connections will be [1280|https://github.com/openwrt/openwrt/blob/master/package/network/ipv6/ds-lite/files/dslite.sh#L66] by default.

Because of it, if a VPN with ipv6 is used over ipv4, it’s completely broken.

tun0 w/ ipv6 -> [vpn client -> [dslite with mtu 1280] -> vpn server] -> private network

As far as I see, it should be relatively easy to make default MTU autoconfigurable with parent’s MTU-x (where 30 is 30, if I’m right)

14.09.20203338Base systemBug ReportVery LowHighTL-WR841N v13 (ramips) unstable Ethernet and WiFi in 19...openwrt-19.07Unconfirmed Task Description

I am using default build of OpenWRT 19.07.4 for TL-WR841N v13 without any additional packages. I have Ethernet PPPoE from provider, some ethernet and WiFi WPA2 clients. WiFi and Ethernet are unstable: they can disappear for 30-60 seconds without any serious reason. On 18.06.8 there wasn’t those problems. I attached system log. Thanks for help.

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
04.10.20203368Base systemBug ReportVery LowLowsysupgrade using CLI require downloading image from htt...openwrt-19.07Unconfirmed Task Description

Hi,

I would like to submit a feature/enhancement request more than a bug request.

Supply the following if possible:
- Device problem occurs on
tested on xiaomi mi wifi 3G v1 (https://openwrt.org/toh/hwdata/xiaomi/xiaomi_miwifi_3g)
but probably occuring for all devices
- Software versions of OpenWrt/LEDE release, packages, etc.
OpenWrt 19.07.4
- Steps to reproduce
1/ upgrade to last stable firmware, so currently 19.07.4
2/ try to download the sysupgrade image
cd /tmp; wget –no-check-certificate “https://downloads.openwrt.org/releases/19.07.4/targets/ramips/mt7621/openwrt-19.07.4-ramips-mt7621-xiaomi_mir3g-squashfs-sysupgrade.bin” wget: SSL support not available, please install one of the libustream-.*[ssl|tls] packages as well as the ca-bundle and ca-certificates packages.

Since a few month, upgrade images have to be downloaded with https, because http requests are now redirected to https.
I also think that redirecting to https, can be a good idea.

Extract of https://openwrt.org/docs/guide-user/installation/sysupgrade.cli :
Download and check the firmware checksum with:
cd /tmp;wget $DOWNLOAD_LINK;wget $SHA256SUMS;sha256sum -c sha256sums 2>/dev/null|grep OK

When applied to my device and last stable release :
cd /tmp; wget –no-check-certificate “https://downloads.openwrt.org/releases/19.07.4/targets/ramips/mt7621/openwrt-19.07.4-ramips-mt7621-xiaomi_mir3g-squashfs-sysupgrade.bin” wget: SSL support not available, please install one of the libustream-.*[ssl|tls] packages as well as the ca-bundle and ca-certificates packages.

As discussed in forum (https://forum.openwrt.org/t/problem-downloading-openwrt-release-to-router-using-wget/63805), there are alternatives.

But, it’s a pain (at least not user friendly) to install a package, in order to download a new image to flash.
Can you add an ssl package to the default packages list ?

Another option is to permit download on http, but may not be the best idea.

I agree about the fact, that adding a package to all images is not so easy and maybe impossible due to space disk considerations.

As an openwrt user, I appreciate all the work, you are doing. Thank you for that project.

Regards,
Serge

09.10.20203372Base systemBug ReportVery LowCriticalAfter flashing 19.07.4 on Kingston MLWG2, no network ar...openwrt-19.07Unconfirmed Task Description

Just flashed 19.07.4 on Kingston MLWG2.

Followed online procedure found (copy image to SD card, touch special file, login via telnet on stock firmware, write image, reboot device) to flash OpenWRT.

After flash, device “seems” stuck dead (all leds are on, wired network irresponsive, no WiFi AP detected).

I have opened the device, soldered the serial console pins and accessere via serial console.

Device is actually booting perfectly, but both wired and wifi are not accessible.

1. I have WiFi enabled by setting “disabled = 0” in /etc/config/wireless to OpenWrt AP

2. I have Wired enabled by adding “option iface “eth0”” to the “lan” interface in /etc/config/network

3. Device now works great

Without these two changes, the device is as good as dead.

This is a peculiar device: only 1 ethernet port and 2.4Ghz Wifi. My guess something is wrong in the vlan/bridge/switch settings?

I hope a fix can be commited somehow so that future users do not end up with a dead-like device.

 


Showing tasks 101 - 150 of 1029 Page 3 of 21 - 1 - 2 - 3 - 4 - 5 - Last >>

Available keyboard shortcuts

Tasklist

Task Details

Task Editing