From openwrt-bugs at lists.openwrt.org Sat Aug 1 08:55:14 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 01 Aug 2020 12:55:14 +0000 Subject: [FS#3259] tplink 710n/v1 unstable AG71xx MII link on ath79 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3259 - tplink 710n/v1 unstable AG71xx MII link on ath79 User who did this - pmgp (mgondium) ---------- @ Franco Castillo I'm running trunk on a few routers that have no link problems whatsoever (archer C6, 1043NDv1, 2543ND), and the difference to those who have problems (710Nv1, 841NDv9, and your C60) is that the ethernet is external (Gbit). The problem ones have it internal to the SoC (100Mbit), so it's probably the driver. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3259#comment8610 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 1 09:32:06 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 01 Aug 2020 13:32:06 +0000 Subject: [FS#3262] pcduino(sunxi/cortexa8) kernel panic on openwrt snapshots 20 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - leigingban (leigingban) Attached to Project - OpenWrt/LEDE Project Summary - pcduino(sunxi/cortexa8) kernel panic on openwrt snapshots 20 Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - Critical Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Supply the following if possible: - Device problem occurs on pcduino [target/linux/sunxi/cortexa8] - Software versions of OpenWrt/LEDE release, packages, etc. - Steps to reproduce ****************************************************************** U-Boot SPL 2020.04 (Jul 31 2020 - 21:50:38 +0000) DRAM: 1024 MiB CPU: 1008000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2020.04 (Jul 31 2020 - 21:50:38 +0000) Allwinner Technology CPU: Allwinner A10 (SUN4I) Model: LinkSprite pcDuino I2C: ready DRAM: 1 GiB MMC: mmc at 1c0f000: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: eth0: ethernet at 1c0b000 starting USB... Bus usb at 1c14000: USB EHCI 1.00 Bus usb at 1c14400: USB OHCI 1.0 Bus usb at 1c1c000: USB EHCI 1.00 Bus usb at 1c1c400: USB OHCI 1.0 scanning bus usb at 1c14000 for devices... 1 USB Device(s) found scanning bus usb at 1c14400 for devices... 1 USB Device(s) found scanning bus usb at 1c1c000 for devices... 1 USB Device(s) found scanning bus usb at 1c1c400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot.scr 377 bytes read in 1 ms (368.2 KiB/s) ## Executing script at 43100000 3308120 bytes read in 265 ms (11.9 MiB/s) 22889 bytes read in 5 ms (4.4 MiB/s) ## Booting kernel from Legacy Image at 42000000 ... Image Name: ARM OpenWrt Linux-5.4.52 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3308056 Bytes = 3.2 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. Loading Kernel Image Using Device Tree in place at 43000000, end 43008968 Starting kernel ... ****************************************************************** kernel panic More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3262 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 2 07:45:13 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 02 Aug 2020 11:45:13 +0000 Subject: [FS#3263] struct blob_buf must be static when used as a local otherwise a runtime error occurs In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Chris Martin (stuffa) Attached to Project - OpenWrt/LEDE Project Summary - struct blob_buf must be static when used as a local otherwise a runtime error occurs Task Type - Bug Report Category - Other Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Very Low Reported Version - openwrt-19.07 Due in Version - Undecided Due Date - Undecided Details - Supply the following if possible: - Device problem occurs on: rPi3B+. I expect that the problem occurs on other devices. I just happen to be developing in rPi3B+ - Software versions of OpenWrt/LEDE release, packages, etc. Release 19.07 trunc - Steps to reproduce void my_function() { struct blob_buf b; // NOTE this is a local variable blob_buf_init(&b, 0); blobmsg_add_string(&b, "key", "value"); blob_buf_free(&b); } The above will compile, but will crash when run However by making the struct static it runs OK. This looks to be a compiler problem. possibly only for ARM More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3263 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 2 10:31:11 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 02 Aug 2020 14:31:11 +0000 Subject: [FS#3263] struct blob_buf must be static when used as a local otherwise a runtime error occurs In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3263 - struct blob_buf must be static when used as a local otherwise a runtime error occurs User who did this - john (john) ---------- struct blob_buf b = {}; or memset the struct to 0 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3263#comment8611 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 2 10:31:21 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 02 Aug 2020 14:31:21 +0000 Subject: [FS#3263] struct blob_buf must be static when used as a local otherwise a runtime error occurs In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3263 - struct blob_buf must be static when used as a local otherwise a runtime error occurs User who did this - john (john) Reason for closing: Not a bug More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3263 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 2 14:46:15 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 02 Aug 2020 18:46:15 +0000 Subject: [FS#3264] R7800 router crashes when Macbook Air joins the network In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Roland (RolandS) Attached to Project - OpenWrt/LEDE Project Summary - R7800 router crashes when Macbook Air joins the network Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Critical Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Supply the following if possible: - Device problem occurs on: Netgear R7800 Router, Macbook Air 11" Mid-2013, Macbook Air 13" 2017 - Software versions of OpenWrt/LEDE release: LuCI branch git-20.201.65700-7edd635 - Steps to reproduce: I join the device to the network with either ethernet or wifi and the router would shortly crash. I simply reboot the router and connect the macbook via ethernet or wifi after the router is up. I would then run a speedtest (it's not related to any particular activity, but I just use speedtest.net as a control) - Attempts at trying to remedy issue: I tried disabling IPv6 on the router and macbooks. I signed out of icloud. I updated Macbooks to MacOS Catalina. I tried flashing router to latest stable release 19.07.3. The network only dies when these Macbook Airs connect to the network, all other devices don't have any issues. Prior to this router, I had a Netgear AC1900 (R7000) running DD-WRT which never had this issue. External logs captured before crash: 8/2/2020 14:14 Alert 192.168.1.1 [ 189.332615] 8 From openwrt-bugs at lists.openwrt.org Sun Aug 2 22:50:08 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 02:50:08 +0000 Subject: [FS#3259] tplink 710n/v1 unstable AG71xx MII link on ath79 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3259 - tplink 710n/v1 unstable AG71xx MII link on ath79 User who did this - Franco Castillo (francocastillo) ---------- Are you saying the problem is caused by connecting to a 1Gbps device? Because that is my case. I have the WAN interface connected to the cable modem which is 1 Gbps. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3259#comment8612 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 00:45:47 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 04:45:47 +0000 Subject: [FS#3265] AP crashed when enabling multicast_snooping In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Erik Larsson (whooo) Attached to Project - OpenWrt/LEDE Project Summary - AP crashed when enabling multicast_snooping Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Device: EnGenius EAP1300 OpenWRT release/revision: r14017-c90db26e05 To reproduce I just do: echo 1 > /sys/class/net/br-vlan10/bridge/multicast_snooping More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3265 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 01:05:48 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 05:05:48 +0000 Subject: [FS#3265] AP crashed when enabling multicast_snooping In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3265 - AP crashed when enabling multicast_snooping User who did this - Erik Larsson (whooo) ---------- Forgot to add some output from the kernel log: [ 2346.354659] rcu: INFO: rcu_sched self-detected stall on CPU [ 2346.355038] rcu: #0112-....: (2105 ticks this GP) idle=45a/1/0x40000002 softirq=6045/6046 fqs=1049 [ 2346.359303] #011(t=2100 jiffies g=34437 q=3) [ 2346.368277] NMI backtrace for cpu 2 [ 2346.372231] CPU: 2 PID: 1338 Comm: ash Not tainted 5.4.52 #0 [ 2346.375480] Hardware name: Generic DT based system [ 2346.381571] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 2346.386116] [] (show_stack) from [] (dump_stack+0x94/0xa8) [ 2346.394032] [] (dump_stack) from [] (nmi_cpu_backtrace+0x90/0xc4) [ 2346.401084] [] (nmi_cpu_backtrace) from [] (nmi_trigger_cpumask_backtrace+0x124/0x138) [ 2346.409004] [] (nmi_trigger_cpumask_backtrace) from [] (rcu_dump_cpu_stacks+0xa4/0xcc) [ 2346.418549] [] (rcu_dump_cpu_stacks) from [] (rcu_sched_clock_irq+0x62c/0x808) [ 2346.428178] [] (rcu_sched_clock_irq) from [] (update_process_times+0x30/0x60) [ 2346.437125] [] (update_process_times) from [] (tick_sched_timer+0x4c/0xa8) [ 2346.446059] [] (tick_sched_timer) from [] (__hrtimer_run_queues+0x154/0x200) [ 2346.454552] [] (__hrtimer_run_queues) from [] (hrtimer_interrupt+0x118/0x2a0) [ 2346.463494] [] (hrtimer_interrupt) from [] (arch_timer_handler_virt+0x28/0x30) [ 2346.472277] [] (arch_timer_handler_virt) from [] (handle_percpu_devid_irq+0x78/0x138) [ 2346.481121] [] (handle_percpu_devid_irq) from [] (generic_handle_irq+0x24/0x34) [ 2346.490726] [] (generic_handle_irq) from [] (__handle_domain_irq+0x5c/0xb4) [ 2346.499617] [] (__handle_domain_irq) from [] (gic_handle_irq+0x4c/0x90) [ 2346.508290] [] (gic_handle_irq) from [] (__irq_svc+0x6c/0x90) [ 2346.516490] Exception stack(0xcbe35ae0 to 0xcbe35b28) [ 2346.524221] 5ae0: cf200e34 00000000 0000000d 0000000c ce30d780 c0c04e48 00000000 cf200e34 [ 2346.529280] 5b00: cf200cc0 ce065e08 cbe35b90 c0c05f3c c0c03d00 cbe35b30 c085f7dc c088b59c [ 2346.537345] 5b20: 80000013 ffffffff [ 2346.545603] [] (__irq_svc) from [] (_raw_spin_lock+0x2c/0x40) [ 2346.548933] [] (_raw_spin_lock) from [] (br_multicast_add_group+0x34/0x17c) [ 2346.556576] [] (br_multicast_add_group) from [] (br_multicast_rcv+0xad8/0xedc) [ 2346.565068] [] (br_multicast_rcv) from [] (br_dev_xmit+0x170/0x3c0) [ 2346.574096] [] (br_dev_xmit) from [] (dev_hard_start_xmit+0x8c/0x11c) [ 2346.582009] [] (dev_hard_start_xmit) from [] (__dev_queue_xmit+0x718/0x880) [ 2346.590342] [] (__dev_queue_xmit) from [] (ip6_finish_output2+0x1a4/0x460) [ 2346.598837] [] (ip6_finish_output2) from [] (ip6_output+0x5c/0xd0) [ 2346.607513] [] (ip6_output) from [] (igmp6_send+0x29c/0x2a4) [ 2346.615407] [] (igmp6_send) from [] (igmp6_join_group.part.7+0x20/0xd4) [ 2346.622955] [] (igmp6_join_group.part.7) from [] (igmp6_group_added+0xf0/0xf8) [ 2346.631042] [] (igmp6_group_added) from [] (__ipv6_dev_mc_inc+0x200/0x2c8) [ 2346.640081] [] (__ipv6_dev_mc_inc) from [] (br_multicast_open+0xcc/0x110) [ 2346.648675] [] (br_multicast_open) from [] (br_multicast_toggle+0x74/0xac) [ 2346.657250] [] (br_multicast_toggle) from [] (store_bridge_parm+0x70/0xd4) [ 2346.665778] [] (store_bridge_parm) from [] (kernfs_fop_write+0x108/0x220) [ 2346.674357] [] (kernfs_fop_write) from [] (__vfs_write+0x1c/0x1a4) [ 2346.682908] [] (__vfs_write) from [] (vfs_write+0xa4/0x188) [ 2346.690714] [] (vfs_write) from [] (ksys_write+0x48/0xb4) [ 2346.697920] [] (ksys_write) from [] (ret_fast_syscall+0x0/0x54) [ 2346.705117] Exception stack(0xcbe35fa8 to 0xcbe35ff0) [ 2346.712638] 5fa0: 00000000 00000000 00000001 b6f243e0 00000002 00000000 [ 2346.717897] 5fc0: 00000000 00000000 00000000 00000004 00000002 00000020 00084bfc 00084bfc [ 2346.726004] 5fe0: bec13928 bec13918 b6ef8020 b6ef74f0 This output is forwarded to a syslog server as I don't have serial access, so might not be 100% complete. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3265#comment8613 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 01:28:32 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 05:28:32 +0000 Subject: [FS#3266] Multicast does not work over bridge with AP/VLAN interfaces In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Erik Larsson (whooo) Attached to Project - OpenWrt/LEDE Project Summary - Multicast does not work over bridge with AP/VLAN interfaces Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Devices: MikroTik RouterBOARD wAP G-5HacT2HnD with OpenWRT r13630-635f111148 EnGenius EAP1300 with OpenWRT r14017-c90db26e05 I have a wifi setup with EAP and dynamic vlan assigment from a radius server. Clients can connect and both unicast and broadcast (DHCP) works fine, but multicast does not, so IPv6 SLAAC does not work for example. On the APs I can see the multicast packets being sent out on the the AP/VLAN interfaces (tcpdump -n -i wlan1.10 multicast), but none of the three clients (linux laptop and two iOS devices) receives them. I have tried enabling multicast_to_unicast, multicast_snooping and hairpin_mode by hand in sysfs, doesn't make any difference, also tried disabling multicast_router. It sometimes works on the MikroTik device, but mostly does not. My wireless config (it's the same on both devices for both radios): config wifi-iface 'myssid_5' option mode 'ap' option ssid 'myssid' option hidden '1' option encryption 'wpa3-mixed' option auth_server 'authserver' option auth_secret 'secret' option dynamic_vlan '2' option vlan_tagged_interface 'eth0' option max_inactivity '1800' option device 'radio0' option mobility_domain 'f1f1' option nasid 'mynasid' option pmk_r1_push '1' option ieee80211r '1' option rsn_preauth '0' option isolate '1' option vlan_bridge 'br-vlan' option vlan_naming '0' option ieee80211w '1' list r0kh '....' list r0kh '....' list r0kh '....' list r0kh '....' list r1kh '....' list r1kh '....' list r1kh '....' list r1kh '....' More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3266 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 03:32:25 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 07:32:25 +0000 Subject: [FS#2990] invalid config-settings for linux5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2990 - invalid config-settings for linux5.4 User who did this - Tony Ambardar (guidosarducci) ---------- The fixes in this PR are relevant: https://github.com/openwrt/openwrt/pull/3257. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2990#comment8614 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 03:32:35 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 07:32:35 +0000 Subject: [FS#2476] Module error in kernel 4.19 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2476 - Module error in kernel 4.19 User who did this - Tony Ambardar (guidosarducci) ---------- The fixes in this PR are relevant: https://github.com/openwrt/openwrt/pull/3257. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2476#comment8615 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 04:57:59 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 08:57:59 +0000 Subject: [FS#3249] Devel/perf failed to compile In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#3249 - Devel/perf failed to compile User who did this: Petr ?tetiar (ynezz) Status: Unconfirmed -> Waiting on reporter More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3249 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 04:58:01 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 08:58:01 +0000 Subject: [FS#3249] Devel/perf failed to compile In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. Petr ?tetiar has taken ownership of the following task: FS#3249 - Devel/perf failed to compile More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3249 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 04:58:20 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 08:58:20 +0000 Subject: [FS#3249] Devel/perf failed to compile In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3249 - Devel/perf failed to compile User who did this - Petr ?tetiar (ynezz) ---------- Out of curiosity I've just tried to build perf on x86/64, mvebu/cortexa9 and sunxi/a53 (which is aarch64 as well) and it builds fine. So unable to reproduce the issue. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3249#comment8616 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 05:00:56 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 09:00:56 +0000 Subject: [FS#3249] Devel/perf failed to compile In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3249 - Devel/perf failed to compile User who did this - Petr ?tetiar (ynezz) ---------- So it must be something related to your specific config, you need to share output of `scripts/diffconfig.sh` as well. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3249#comment8617 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 05:30:44 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 09:30:44 +0000 Subject: [FS#3099] TP-Link C2600 Kernel 5.4 crashes while accessing invalid memory address In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3099 - TP-Link C2600 Kernel 5.4 crashes while accessing invalid memory address User who did this - Alexander Lochmann (flipreverse) ---------- Update: Uptime went up to ~9 days. I switched back to ondemand governor, and experienced a crash within 12 hours..... ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3099#comment8618 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 13:45:49 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 17:45:49 +0000 Subject: [FS#3259] tplink 710n/v1 unstable AG71xx MII link on ath79 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3259 - tplink 710n/v1 unstable AG71xx MII link on ath79 User who did this - pmgp (mgondium) ---------- No, I'm saying that I only see this problem on devices that use the SoC internal PHY, the others have an external switch (and are, coincidentally or not, gigabit). ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3259#comment8619 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 15:15:14 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 19:15:14 +0000 Subject: [FS#3267] mesh_param net setting from mac80211.sh In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Craig Matsuura (thelinuxdude) Attached to Project - OpenWrt/LEDE Project Summary - mesh_param net setting from mac80211.sh Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Very Low Reported Version - openwrt-18.06 Due in Version - Undecided Due Date - Undecided Details - I tried this on 17.01 and 18.06 with mtk7612 and it did not set the values. If I had set the values with the iw command it works. I believe the radio is not in a state that is ready for those commands in the mac80211.sh script. You can see the value is being passed in an failing. Mon Aug 3 18:40:26 2020 user.notice mac80211: Failed command: iw dev wlan0 set mesh_param mesh_hwmp_rootmode 1 Mon Aug 3 18:40:26 2020 user.notice mac80211: Failed command: iw dev wlan0 set mesh_param mesh_gate_announcements 1 Confirmed using iw dev wlan0 get mesh_param mesh_hwmp_rootmode Supply the following if possible: - Device problem occurs on: MT7612 (5GHz) - Software versions of OpenWrt/LEDE release, packages, etc.: 17.1, 18.06 - Steps to reproduce: Set values in the /etc/config/wireless config wifi-device 'radio1' option type 'mac80211' option path 'pci0000:00/0000:00:00.0/0000:01:00.0' option hwmode '11ac' option disabled '0' option country 'US' option txpower '23' option greenfield '0' config wifi-iface option device 'radio1' option network 'lan' option mode 'mesh' option mesh_id 'my_mesh_id' option encryption 'psk2+ccmp' option key 'password_mesh' option short_preamble '1' option disabled '0' option mesh_hwmp_rootmode '1' option mesh_gate_announcements '1' More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3267 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 15:19:38 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 19:19:38 +0000 Subject: [FS#3268] 802.11s mesh warn when using 802.11s over 5GHz mtk7612. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Craig Matsuura (thelinuxdude) Attached to Project - OpenWrt/LEDE Project Summary - 802.11s mesh warn when using 802.11s over 5GHz mtk7612. Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - I see the same warn when using 802.11s over 5GHz mtk7612. It appears a skb buffer is full? We have encryption enabled and working. This happens at time, would like to help find a solution? This is the section of code that is generating the error. Is there anything I can try to help debug? I'm on a 18.04 build, have seen this on 17.01? ccmp_encrypt_skb: if (WARN_ON(skb_tailroom(skb) < tail || skb_headroom(skb) < IEEE80211_CCMP_HDR_LEN)) return -1; [ 234.629726] ????[ cut here ]???? [ 234.639113] WARNING: CPU: 0 PID: 0 at backports-2017-11-01/net/mac80211/wpa.c:431 ieee80211_crypto_ccmp_encrypt+0xe0/0x248 [mac80211] [ 234.663087] Modules linked in: rt2800soc rt2800pci rt2800mmio rt2800lib pppoe ppp_async rt2x00soc rt2x00pci rt2x00mmio rt2x00lib pppox ppp_generic nf_conntrack_ipv6 mt76x2e mt76x2_common mt76x02_lib mt7603e mt76 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat_ftp nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_netlink nf_conntrack_ftp nf_conntrack iptable_mangle iptable_filter ip_tables crc_itu_t crc_ccitt compat arptable_filter arpt_mangle arp_tables xt_set ip_set_list_set ip_set_hash_netiface [ 234.804092] ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables tun eeprom_93cx6 leds_gpio gpio_button_hotplug [ 234.879023] CPU: 0 PID: 0 Comm: swapper Tainted: G W 4.14.131 #0 [ 234.893240] Stack : 80483660 80373fe4 00000000 00000000 803d882c 83807bf4 80427ccc 804278e7 [ 234.909918] 803d4b48 00000000 80483660 000001af 00000123 00000001 83807ba8 a434d50c [ 234.926591] 00000000 00000000 80480000 00000000 0000011e 00000000 33312e34 30232031 [ 234.943258] 6e757420 00000000 3fff0000 70656520 00000000 00000000 83288754 832d9e40 [ 234.959924] 00000009 000001af 00000123 83807dc0 00000000 801da924 00000000 80480000 [ 234.976589] ... [ 234.981465] Call Trace: [ 234.986351] [] show_stack+0x74/0x104 [ 234.995229] [] __warn+0x110/0x118 [ 235.003575] [] warn_slowpath_null+0x1c/0x30 [ 235.013783] [] ieee80211_crypto_ccmp_encrypt+0xe0/0x248 [mac80211] [ 235.027964] [] ieee80211_probereq_get+0x6d8/0x1668 [mac80211] [ 235.041219] ?[ end trace c50314b568e42025 ]?Supply the following if possible: More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3268 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 15:47:10 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 19:47:10 +0000 Subject: [FS#3099] TP-Link C2600 Kernel 5.4 crashes while accessing invalid memory address (Attachment added) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3099 - TP-Link C2600 Kernel 5.4 crashes while accessing invalid memory address User who did this - Filip Matijevi? (filippz) ---------- Had no crashes to report for a while - they are typical after a week or so for me, and since I had one power failure and a couple of user initiated reboots I couldn't catch any logs but I have finally caught one to report (files attached). I'll try performance setting for both cores and report back if I experience any crashes. ---------- One or more files have been attached. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3099#comment8620 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 15:58:52 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 19:58:52 +0000 Subject: [FS#3099] TP-Link C2600 Kernel 5.4 crashes while accessing invalid memory address In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3099 - TP-Link C2600 Kernel 5.4 crashes while accessing invalid memory address User who did this - John T (jonozzz) ---------- Filip, your call stacks look a little different, so it might be a different issue. I'm almost at 30 days uptime with the governor set to "performance". ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3099#comment8621 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 16:23:46 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 20:23:46 +0000 Subject: [FS#3269] Compiling the kernel requires entering the CGROUP_HUGETLB option. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - wevsty (wevsty) Attached to Project - OpenWrt/LEDE Project Summary - Compiling the kernel requires entering the CGROUP_HUGETLB option. Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - ? Priority - ?? Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - When I try to compile the openwrt master branch of NanoPi R2S, it waits for user input to pause the kernel compilation. Compile environment: Ubuntu 20.04 LTS Board: NanoPi R2S OpenWrt source code: snapshot 1deaf695ec02d765c9ae28b1bac264798ca54a05 Replicating the bug only requires? 1. make menuconfig and select compile NanoPi R2S. 2. make V=99 Will Show reference HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --syncconfig Kconfig net/sched/Kconfig:45: warning: menuconfig statement without prompt .config:4276:warning: symbol value 'm' invalid for NF_NAT_REDIRECT .config:6714:warning: override: USB_DWC3_HOST changes choice state * * Restart config... * * * Control Group support * Control Group support (CGROUPS) [Y/n/?] y Memory controller (MEMCG) [Y/n/?] y Swap controller (MEMCG_SWAP) [Y/n/?] y Swap controller enabled by default (MEMCG_SWAP_ENABLED) [N/y/?] n IO controller (BLK_CGROUP) [Y/n/?] y PIDs controller (CGROUP_PIDS) [Y/n/?] y RDMA controller (CGROUP_RDMA) [Y/n/?] y Freezer controller (CGROUP_FREEZER) [N/y/?] n HugeTLB controller (CGROUP_HUGETLB) [N/y/?] (NEW) I think the problem is caused by the commit d1a8217d87bffa33fd7d4562b3ed2f797c14beaf. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3269 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 16:28:22 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 20:28:22 +0000 Subject: [FS#3259] tplink 710n/v1 unstable AG71xx MII link on ath79 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3259 - tplink 710n/v1 unstable AG71xx MII link on ath79 User who did this - Franco Castillo (francocastillo) ---------- And how do I know if my router's switch is internal or external? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3259#comment8622 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 16:50:16 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 20:50:16 +0000 Subject: [FS#3259] tplink 710n/v1 unstable AG71xx MII link on ath79 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3259 - tplink 710n/v1 unstable AG71xx MII link on ath79 User who did this - pmgp (mgondium) ---------- When you have the same reference for the cpu and the switch: https://openwrt.org/toh/hwdata/tp-link/tp-link_archer_c60_v2 CPU:Qualcomm Atheros QCA9561 Switch:Qualcomm Atheros QCA9561 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3259#comment8623 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 17:01:36 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 21:01:36 +0000 Subject: [FS#3259] tplink 710n/v1 unstable AG71xx MII link on ath79 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3259 - tplink 710n/v1 unstable AG71xx MII link on ath79 User who did this - Franco Castillo (francocastillo) ---------- Yes, I am intuiting that it was internal by the same name. So is it a driver problem? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3259#comment8624 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 18:10:34 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 22:10:34 +0000 Subject: [FS#2231] fstools: PREINIT calling of block extroot doesn't acknowledge non-MTD rootfs overlays In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2231 - fstools: PREINIT calling of block extroot doesn't acknowledge non-MTD rootfs overlays User who did this - Qi Liu (visualage) ---------- Is it reasonable to use libfstools to search for rootfs_data volume and mount it, just like what mount_root.c does? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2231#comment8625 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 3 18:31:13 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 03 Aug 2020 22:31:13 +0000 Subject: [FS#3268] 802.11s mesh warn when using 802.11s over 5GHz mtk7612. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3268 - 802.11s mesh warn when using 802.11s over 5GHz mtk7612. User who did this - Adrian Schmutzler (adrianschmutzler) ---------- Duplicate of closed #1372. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3268#comment8626 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 4 03:53:43 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 04 Aug 2020 07:53:43 +0000 Subject: [FS#3099] TP-Link C2600 Kernel 5.4 crashes while accessing invalid memory address In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3099 - TP-Link C2600 Kernel 5.4 crashes while accessing invalid memory address User who did this - Filip Matijevi? (filippz) ---------- I've just had another reboot and it seems that crashlog doesn't get overwritten on subsequent crashes - I'll do a hard reboot and wait. I'm not able to say if it's the same problem here as my crashlogs are not consistent (for example: [[https://pastebin.com/raw/fhD5vVLQ|https://pastebin.com/raw/fhD5vVLQ]]) In any changing governor for me did the opposite for stability - I'm wondering if making CPU to run at 100% frequency causes overheating issue making it more unstable in my case. I'll try with the same governor once more to see if that's the case. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3099#comment8627 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 4 10:37:38 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 04 Aug 2020 14:37:38 +0000 Subject: [FS#3270] gcc: package seems incompatible with linker provided by binutils In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - MikePetullo (MikePetullo) Attached to Project - OpenWrt/LEDE Project Summary - gcc: package seems incompatible with linker provided by binutils Task Type - Bug Report Category - Packages Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - I use the gcc package to compile C code on my OpenWrt installation. Something has broken the toolchain, and it appears to be related to the binutils package that OpenWrt base provides. I receive errors such as these when I compile: root at OpenWrt # gcc hello.c /usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libssp_nonshared.a(__stack_chk_fail_local.o): unable to initialize decompress status for section .debug_info /usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libssp_nonshared.a(__stack_chk_fail_local.o): unable to initialize decompress status for section .debug_info /usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libgcc.a(_muldi3.o): unable to initialize decompress status for section .debug_info /usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libgcc.a(_muldi3.o): unable to initialize decompress status for section .debug_info /usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libgcc.a(_muldi3.o): unable to initialize decompress status for section .debug_info /usr/bin/ld: /usr/lib/gcc/x86_64-openwrt-linux-musl/7.4.0/libgcc.a(_muldi3.o): unable to initialize decompress status for section .debug_info I was able to overcome this problem by updating binutils. I copied the version information and patches for binutils 2.32 from toolchain/binutils/ into package/devel/binutils/, and I built a newer version of the binutils package. Whereas the toolchain version of binutils provides the option to build a recent release, the package version is still 2.27. See also https://github.com/openwrt/packages/issues/13019. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3270 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 4 13:49:30 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 04 Aug 2020 17:49:30 +0000 Subject: [FS#3268] 802.11s mesh warn when using 802.11s over 5GHz mtk7612. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3268 - 802.11s mesh warn when using 802.11s over 5GHz mtk7612. User who did this - Craig Matsuura (thelinuxdude) ---------- That is on #1372 with an athk. Since I can duplicate fairly easily thoughts on what I can try to change maybe the buffer size? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3268#comment8628 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 4 14:08:20 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 04 Aug 2020 18:08:20 +0000 Subject: [FS#2231] fstools: PREINIT calling of block extroot doesn't acknowledge non-MTD rootfs overlays (Attachment added) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2231 - fstools: PREINIT calling of block extroot doesn't acknowledge non-MTD rootfs overlays User who did this - Qi Liu (visualage) ---------- I made a patch to openwrt to support extroot on non-MTD rootfs_data volumes. It uses libfstools in block.c to support other squashfs volumes, such as /dev/sd* or /dev/mmc*. The patch itself contains a patch to fstools project that can be applied to that codebase directly. I tested the build locally on a x86-64 virtualbox environment. It should work on any other environments as long as mount_root works since they use the same underlying library. ---------- One or more files have been attached. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2231#comment8629 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 4 14:34:33 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 04 Aug 2020 18:34:33 +0000 Subject: [FS#3271] WAN-eth1 restarts constantly and stops completely after a while. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Franco Castillo (francocastillo) Attached to Project - OpenWrt/LEDE Project Summary - WAN-eth1 restarts constantly and stops completely after a while. Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - I have a TP-link Archer C60 v1 that has a serious problem of constant disconnections every few minutes (approx 4 to 1 hour). It seems to be random, or something I'm not seeing. [[https://deviwiki.com/wiki/TP-LINK_Archer_C60_v1.x|Device info]]. Report in the OpenWrt forum [[https://forum.openwrt.org/t/archer-c60-wan-disconnects/68896|here]] and [[https://forum.openwrt.org/t/udhcpc-does-not-work-correctly/69774/1|here]]. The problem happens with official or own compilations. root at archer_c60:~# dmesg [ 0.000000] Linux version 5.4.52 (franco at ubuntu) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r14025-009e62c92c)) #0 Mon Aug 3 21:34:34 2020 [ 0.000000] printk: bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 00019750 (MIPS 74Kc) [ 0.000000] MIPS: machine is TP-Link Archer C60 v1 [ 0.000000] SoC: Qualcomm Atheros QCA956X ver 1 rev 0 [ 0.000000] Initrd not found or empty - disabling initrd [ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x0000000003ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000003ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff] [ 0.000000] On node 0 totalpages: 16384 [ 0.000000] Normal zone: 144 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 16384 pages, LIFO batch:3 [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16240 [ 0.000000] Kernel command line: console=ttyS0,115200n8 rootfstype=squashfs,jffs2 [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear) [ 0.000000] Writing ErrCtl register=00000000 [ 0.000000] Readback ErrCtl register=00000000 [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Memory: 57348K/65536K available (4786K kernel code, 186K rwdata, 1112K rodata, 1204K init, 196K bss, 8188K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS: 51 [ 0.000000] random: get_random_bytes called from start_kernel+0x32c/0x518 with crng_init=0 [ 0.000000] CPU clock: 775.000 MHz [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 4932285024 ns [ 0.000006] sched_clock: 32 bits at 387MHz, resolution 2ns, wraps every 5541893118ns [ 0.008216] Calibrating delay loop... 385.02 BogoMIPS (lpj=770048) [ 0.046713] pid_max: default: 32768 minimum: 301 [ 0.051703] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.059420] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.071423] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.081738] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [ 0.089029] pinctrl core: initialized pinctrl subsystem [ 0.095494] NET: Registered protocol family 16 [ 0.129728] clocksource: Switched to clocksource MIPS [ 0.136186] NET: Registered protocol family 2 [ 0.141534] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) [ 0.150415] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.158508] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.165952] TCP: Hash tables configured (established 1024 bind 1024) [ 0.172784] UDP hash table entries: 256 (order: 0, 4096 bytes, linear) [ 0.179723] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) [ 0.187384] NET: Registered protocol family 1 [ 0.192033] PCI: CLS 0 bytes, default 32 [ 0.199601] workingset: timestamp_bits=14 max_order=14 bucket_order=0 [ 0.212506] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.218699] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [ 0.242820] pinctrl-single 1804002c.pinmux: 544 pins, size 68 [ 0.249924] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled [ 0.257292] printk: console [ttyS0] disabled [ 0.261885] 18020000.uart: ttyS0 at MMIO 0x18020000 (irq = 9, base_baud = 1562500) is a 16550A [ 0.270991] printk: console [ttyS0] enabled [ 0.280058] printk: bootconsole [early0] disabled [ 0.299004] spi-nor spi0.0: gd25q64 (8192 Kbytes) [ 0.303934] 5 fixed-partitions partitions found on MTD device spi0.0 [ 0.310502] Creating 5 MTD partitions on "spi0.0": [ 0.315464] 0x000000000000-0x000000010000 : "u-boot" [ 0.321473] 0x000000010000-0x000000020000 : "mac" [ 0.327179] 0x000000020000-0x0000007e0000 : "firmware" [ 0.336503] 2 uimage-fw partitions found on MTD device firmware [ 0.342670] Creating 2 MTD partitions on "firmware": [ 0.347820] 0x000000000000-0x0000001e8769 : "kernel" [ 0.353783] 0x0000001e8769-0x0000007c0000 : "rootfs" [ 0.359694] mtd: device 4 (rootfs) set to be root filesystem [ 0.367266] 1 squashfs-split partitions found on MTD device rootfs [ 0.373704] 0x000000720000-0x0000007c0000 : "rootfs_data" [ 0.380120] 0x0000007e0000-0x0000007f0000 : "tplink" [ 0.386169] 0x0000007f0000-0x000000800000 : "art" [ 0.393638] libphy: Fixed MDIO Bus: probed [ 0.730817] ag71xx 19000000.eth: Could not connect to PHY device. Deferring probe. [ 1.133724] random: fast init done [ 1.370090] libphy: ag71xx_mdio: probed [ 1.374808] libphy: ar8xxx-mdio: probed [ 1.383022] switch0: Atheros AR8229 rev. 1 switch registered on mdio.0 [ 1.443277] ag71xx 1a000000.eth: connected to PHY at fixed-0:00 [uid=00000000, driver=Generic PHY] [ 1.453133] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii [ 1.459652] i2c /dev entries driver [ 1.465629] NET: Registered protocol family 10 [ 1.475565] Segment Routing with IPv6 [ 1.479506] NET: Registered protocol family 17 [ 1.484184] 8021q: 802.1Q VLAN Support v1.8 [ 1.489239] PCI host bridge /ahb/pcie-controller at 18250000 ranges: [ 1.495606] MEM 0x0000000012000000..0x0000000013ffffff [ 1.501011] IO 0x0000000000000000..0x0000000000000000 [ 1.506568] PCI host bridge to bus 0000:00 [ 1.510837] pci_bus 0000:00: root bus resource [mem 0x12000000-0x13ffffff] [ 1.517948] pci_bus 0000:00: root bus resource [io 0x0000] [ 1.523714] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] [ 1.530731] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] [ 1.538945] pci 0000:00:00.0: [168c:0056] type 00 class 0x028000 [ 1.545205] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit] [ 1.552347] pci 0000:00:00.0: PME# supported from D0 D3hot [ 1.558929] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00 [ 1.565815] pci 0000:00:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit] [ 1.893261] ag71xx 19000000.eth: connected to PHY at mdio.0:1f:04 [uid=004dd042, driver=Generic PHY] [ 1.903527] eth1: Atheros AG71xx at 0xb9000000, irq 4, mode: mii [ 1.916678] VFS: Mounted root (squashfs filesystem) readonly on device 31:4. [ 1.930630] Freeing unused kernel memory: 1204K [ 1.935329] This architecture does not have kernel memory protection. [ 1.941979] Run /sbin/init as init process [ 2.603251] init: Console is alive [ 2.607070] init: - watchdog - [ 3.857698] kmodloader: loading kernel modules from /etc/modules-boot.d/* [ 3.901414] kmodloader: done loading kernel modules from /etc/modules-boot.d/* [ 3.919321] init: - preinit - [ 4.761647] random: jshn: uninitialized urandom read (4 bytes read) [ 4.866893] random: jshn: uninitialized urandom read (4 bytes read) [ 5.008869] random: jshn: uninitialized urandom read (4 bytes read) [ 5.761280] eth0: link up (1000Mbps/Full duplex) [ 5.769806] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 5.781838] IPv6: ADDRCONF(NETDEV_CHANGE): eth0.1: link becomes ready [ 5.821133] urandom_read: 4 callbacks suppressed [ 5.821140] random: procd: uninitialized urandom read (4 bytes read) [ 10.086330] jffs2: notice: (527) jffs2_build_xattr_subsystem: complete building xattr subsystem, 21 of xdatum (9 unchecked, 1 orphan) and 32 of xref (1 dead, 0 orphan) found. [ 10.104253] mount_root: switching to jffs2 overlay [ 10.139301] overlayfs: upper fs does not support tmpfile. [ 10.151067] urandom-seed: Seeding with /etc/urandom.seed [ 10.238894] eth0: link down [ 10.259802] procd: - early - [ 10.262927] procd: - watchdog - [ 10.866830] procd: - watchdog - [ 10.870377] procd: - ubus - [ 10.915048] random: ubusd: uninitialized urandom read (4 bytes read) [ 10.924763] random: ubusd: uninitialized urandom read (4 bytes read) [ 10.932683] procd: - init - [ 11.661864] kmodloader: loading kernel modules from /etc/modules.d/* [ 11.758839] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver [ 11.875205] Mirror/redirect action on [ 11.900395] u32 classifier [ 11.903248] input device check on [ 11.907032] Actions configured [ 11.942370] Loading modules backported from Linux version v5.8-rc2-0-g48778464bb7d [ 11.950239] Backport generated by backports.git v5.8-rc2-1-0-g7a69429b [ 12.015183] wireguard: WireGuard 1.0.20200729 loaded. See www.wireguard.com for information. [ 12.023954] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved. [ 12.125541] urngd: v1.0.2 started. [ 12.154690] xt_time: kernel timezone is -0000 [ 12.432978] ath10k 5.4 driver, optimized for CT firmware, probing pci device: 0x56. [ 12.441047] ath10k_mac_create, priv_size: 804 hw: (ptrval) hw->priv: (ptrval) [ 12.454450] random: crng init done [ 12.470492] ath10k_pci 0000:00:00.0: enabling device (0000 -> 0002) [ 12.477291] ath10k_pci 0000:00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0 [ 14.858841] ath10k_pci 0000:00:00.0: qca9888 hw2.0 target 0x01000000 chip_id 0x00000000 sub 0000:0000 [ 14.868416] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0 [ 14.888430] ath10k_pci 0000:00:00.0: firmware ver 10.4b-ct-9888-fW-013-d81f62d97 api 5 features mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT crc32 937128b4 [ 15.223010] ath10k_pci 0000:00:00.0: failed to fetch board data for bus=pci,bmi-chip-id=0,bmi-board-id=20 from ath10k/QCA9888/hw2.0/board-2.bin [ 15.237129] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id 0:20 crc32 8971a1b4 [ 17.273475] ath10k_pci 0000:00:00.0: unsupported HTC service id: 1536 [ 17.283350] ath10k_pci 0000:00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 [ 17.291138] ath10k_pci 0000:00:00.0: msdu-desc: 2500 skid: 32 [ 17.321246] ath10k_pci 0000:00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' [ 17.332536] ath10k_pci 0000:00:00.0: wmi print 'free: 114524 iram: 12628 sram: 29508' [ 17.566737] ath10k_pci 0000:00:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 32 raw 0 hwcrypto 1 [ 17.648824] ath: EEPROM regdomain sanitized [ 17.648834] ath: EEPROM regdomain: 0x64 [ 17.648837] ath: EEPROM indicates we should expect a direct regpair map [ 17.648854] ath: Country alpha2 being used: 00 [ 17.648857] ath: Regpair used: 0x64 [ 17.732561] ath: EEPROM regdomain sanitized [ 17.732571] ath: EEPROM regdomain: 0x64 [ 17.732574] ath: EEPROM indicates we should expect a direct regpair map [ 17.732593] ath: Country alpha2 being used: 00 [ 17.732596] ath: Regpair used: 0x64 [ 17.744788] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [ 17.746726] ieee80211 phy1: Atheros AR9561 Rev:0 mem=0xb8100000, irq=2 [ 17.784311] kmodloader: done loading kernel modules from /etc/modules.d/* [ 29.726074] eth0: link up (1000Mbps/Full duplex) [ 29.744030] br-lan: port 1(eth0.1) entered blocking state [ 29.749664] br-lan: port 1(eth0.1) entered disabled state [ 29.755551] device eth0.1 entered promiscuous mode [ 29.760547] device eth0 entered promiscuous mode [ 29.773858] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 29.845863] br-lan: port 1(eth0.1) entered blocking state [ 29.851467] br-lan: port 1(eth0.1) entered forwarding state [ 30.753814] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready [ 32.003594] eth1: link up (100Mbps/Full duplex) [ 32.028748] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 32.790926] ath: EEPROM regdomain: 0x8020 [ 32.795121] ath: EEPROM indicates we should expect a country code [ 32.801425] ath: doing EEPROM country->regdmn map search [ 32.806913] ath: country maps to regdmn code: 0x3b [ 32.811867] ath: Country alpha2 being used: AR [ 32.816462] ath: Regpair used: 0x3b [ 32.820066] ath: regdomain 0x8020 dynamically updated by user [ 32.826071] ath: EEPROM regdomain: 0x8020 [ 32.830223] ath: EEPROM indicates we should expect a country code [ 32.836514] ath: doing EEPROM country->regdmn map search [ 32.841998] ath: country maps to regdmn code: 0x3b [ 32.846944] ath: Country alpha2 being used: AR [ 32.851530] ath: Regpair used: 0x3b [ 32.855135] ath: regdomain 0x8020 dynamically updated by user [ 35.621539] br-lan: port 2(2G_ap) entered blocking state [ 35.627088] br-lan: port 2(2G_ap) entered disabled state [ 35.632889] device 2G_ap entered promiscuous mode [ 36.767071] IPv6: ADDRCONF(NETDEV_CHANGE): 2G_ap: link becomes ready [ 36.773915] br-lan: port 2(2G_ap) entered blocking state [ 36.779457] br-lan: port 2(2G_ap) entered forwarding state [ 39.593566] ath10k_pci 0000:00:00.0: unsupported HTC service id: 1536 [ 39.600391] ath10k_pci 0000:00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 [ 39.608239] ath10k_pci 0000:00:00.0: msdu-desc: 2500 skid: 32 [ 39.638423] ath10k_pci 0000:00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' [ 39.649793] ath10k_pci 0000:00:00.0: wmi print 'free: 114524 iram: 12628 sram: 29508' [ 39.962495] ath10k_pci 0000:00:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4 [ 40.056094] br-lan: port 3(5G_ap) entered blocking state [ 40.061668] br-lan: port 3(5G_ap) entered disabled state [ 40.067470] device 5G_ap entered promiscuous mode [ 40.592976] ath10k_pci 0000:00:00.0: NOTE: Firmware DBGLOG output disabled in debug_mask: 0x10000000 [ 42.454916] IPv6: ADDRCONF(NETDEV_CHANGE): 5G_ap: link becomes ready [ 42.461871] br-lan: port 3(5G_ap) entered blocking state [ 42.467408] br-lan: port 3(5G_ap) entered forwarding state [ 71.382406] ath10k_pci 0000:00:00.0: Invalid VHT mcs 15 peer stats [ 341.666028] eth1: link down [ 344.483336] eth1: link up (100Mbps/Full duplex) [ 344.491658] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 578.229353] ath10k_pci 0000:00:00.0: htt tx: fixing invalid VHT TX rate code 0xff [ 592.368021] eth1: link down [ 594.703887] eth1: link up (100Mbps/Full duplex) [ 594.714352] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 731.949888] eth1: link down [ 734.221962] eth1: link up (100Mbps/Full duplex) [ 734.227213] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 820.236857] eth1: link down [ 822.605965] eth1: link up (100Mbps/Full duplex) [ 822.610905] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 826.702190] eth1: link down [ 829.102014] eth1: link up (100Mbps/Full duplex) [ 829.107387] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 1649.347796] eth1: link down [ 1651.621462] eth1: link up (100Mbps/Full duplex) [ 1651.626465] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 1841.056988] eth1: link down [ 1843.456817] eth1: link up (100Mbps/Full duplex) [ 1843.461740] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 2180.413149] eth1: link down [ 2182.718570] eth1: link up (100Mbps/Full duplex) [ 2182.724457] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 2198.078586] eth1: link down [ 2200.350082] eth1: link up (100Mbps/Full duplex) [ 2200.355326] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 2767.640586] eth1: link down [ 2769.913486] eth1: link up (100Mbps/Full duplex) [ 2769.918880] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 3632.176061] eth1: link down [ 3634.929548] eth1: link up (100Mbps/Full duplex) [ 3634.947194] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 4204.358095] eth1: link down [ 4206.821967] eth1: link up (100Mbps/Full duplex) [ 4206.826885] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 4285.669868] eth1: link down [ 4288.549039] eth1: link up (100Mbps/Full duplex) [ 4288.553962] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 4437.028463] eth1: link down [ 4439.299787] eth1: link up (100Mbps/Full duplex) [ 4439.305020] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 5146.874710] eth1: link down [ 5149.368670] eth1: link up (100Mbps/Full duplex) [ 5149.374116] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 5381.813951] eth1: link down [ 5384.055038] eth1: link up (100Mbps/Full duplex) [ 5384.059934] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 5642.100393] eth1: link down [ 5644.373038] eth1: link up (100Mbps/Full duplex) [ 5644.378482] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 7494.721193] eth1: link down [ 7497.344721] eth1: link up (100Mbps/Full duplex) [ 7497.349853] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 7498.367589] eth1: link down [ 7501.023786] eth1: link up (100Mbps/Full duplex) [ 7501.033810] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 7768.284460] eth1: link down [ 7770.555910] eth1: link up (100Mbps/Full duplex) [ 7770.560802] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 8019.384339] eth1: link down [ 8021.625385] eth1: link up (100Mbps/Full duplex) [ 8021.630736] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 8403.572058] eth1: link down [ 8405.813090] eth1: link up (100Mbps/Full duplex) [ 8405.818007] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 8527.667165] eth1: link down [ 8529.907650] eth1: link up (100Mbps/Full duplex) [ 8529.914523] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 8880.112215] eth1: link down [ 8882.383496] eth1: link up (100Mbps/Full duplex) [ 8882.388796] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 9199.819312] eth1: link down [ 9202.091975] eth1: link up (100Mbps/Full duplex) [ 9202.096881] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 9356.713628] eth1: link down [ 9358.954413] eth1: link up (100Mbps/Full duplex) [ 9358.959717] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 9633.414597] eth1: link down [ 9635.687330] eth1: link up (100Mbps/Full duplex) [ 9635.692245] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 9684.873413] eth1: link down [ 9687.110800] eth1: link up (100Mbps/Full duplex) [ 9687.116036] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [10674.234523] eth1: link down [10676.505354] eth1: link up (100Mbps/Full duplex) [10676.510427] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [10983.699927] eth1: link down [10985.941798] eth1: link up (100Mbps/Full duplex) [10985.946692] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [11115.987273] eth1: link down [11118.227019] eth1: link up (100Mbps/Full duplex) [11118.231935] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [11258.511665] eth1: link down [11260.752903] eth1: link up (100Mbps/Full duplex) [11260.757818] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [12051.270601] eth1: link down [12053.542580] eth1: link up (100Mbps/Full duplex) [12053.547634] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [12224.548043] eth1: link down [12226.820838] eth1: link up (100Mbps/Full duplex) [12226.826133] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [13093.116349] eth1: link down [13095.388099] eth1: link up (100Mbps/Full duplex) [13095.393036] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [13237.723403] eth1: link down [13239.994531] eth1: link up (100Mbps/Full duplex) [13239.999449] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [13480.631361] eth1: link down [13482.903933] eth1: link up (100Mbps/Full duplex) [13482.908827] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [14079.986670] eth1: link down [14082.865153] eth1: link up (100Mbps/Full duplex) [14082.875799] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [14136.142960] eth1: link down [14138.480152] eth1: link up (100Mbps/Full duplex) [14138.485048] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [14326.892801] eth1: link down [14329.165044] eth1: link up (100Mbps/Full duplex) [14329.170437] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [15205.698224] eth1: link down [15208.034072] eth1: link up (100Mbps/Full duplex) [15208.038993] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [16868.939213] eth1: link down [16871.691530] eth1: link up (100Mbps/Full duplex) [16871.696502] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [17219.845264] eth1: link down [17222.085945] eth1: link up (100Mbps/Full duplex) [17222.091188] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [17266.116135] eth1: link down [17268.358170] eth1: link up (100Mbps/Full duplex) [17268.363287] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [18608.757159] eth1: link down [18610.998442] eth1: link up (100Mbps/Full duplex) [18611.003804] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [18764.595469] eth1: link down [18766.836763] eth1: link up (100Mbps/Full duplex) [18766.841656] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [20083.683566] eth1: link down [20085.924491] eth1: link up (100Mbps/Full duplex) [20085.929635] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [20258.977467] eth1: link down [20261.250149] eth1: link up (100Mbps/Full duplex) [20261.255096] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [20799.867102] eth1: link down [20800.905538] eth1: link up (100Mbps/Full duplex) [20801.403850] eth1: link down [20803.739123] eth1: link up (100Mbps/Full duplex) [20803.744597] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [20860.057661] eth1: link down [20862.298378] eth1: link up (100Mbps/Full duplex) [20862.303274] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [21054.806768] eth1: link down [21057.335858] eth1: link up (100Mbps/Full duplex) [21057.340763] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [21401.394255] eth1: link down [21403.667456] eth1: link up (100Mbps/Full duplex) [21403.673375] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [21526.544502] eth1: link down [21528.785624] eth1: link up (100Mbps/Full duplex) [21528.790873] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [22750.558286] eth1: link down [22752.991528] eth1: link up (100Mbps/Full duplex) [22752.996798] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [23049.946588] eth1: link down [23052.667230] eth1: link up (100Mbps/Full duplex) [23052.672628] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [23937.424784] eth1: link down [23939.918740] eth1: link up (100Mbps/Full duplex) [23939.923699] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [24151.883187] eth1: link down [24154.155689] eth1: link up (100Mbps/Full duplex) [24154.160921] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [24189.994240] eth1: link down [24192.267137] eth1: link up (100Mbps/Full duplex) [24192.272514] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [24815.876173] eth1: link down [24818.146255] eth1: link up (100Mbps/Full duplex) [24818.151147] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [24919.520764] eth1: link down [24921.760804] eth1: link up (100Mbps/Full duplex) [24921.765696] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [25562.774798] eth1: link down [25565.047734] eth1: link up (100Mbps/Full duplex) [25565.053118] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [25785.204201] eth1: link down [25787.476678] eth1: link up (100Mbps/Full duplex) [25787.481822] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [26773.733380] eth1: link down [26776.714562] eth1: link up (100Mbps/Full duplex) [26776.730903] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [26790.085415] eth1: link down [26792.678448] eth1: link up (100Mbps/Full duplex) [26792.697842] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [27487.164577] eth1: link down [27489.660947] eth1: link up (100Mbps/Full duplex) [27489.668112] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [28290.895944] eth1: link down [28293.425287] eth1: link up (100Mbps/Full duplex) [28293.437604] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [28658.059181] eth1: link down [28660.812898] eth1: link up (100Mbps/Full duplex) [28660.826712] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [28743.785857] eth1: link down [28746.187045] eth1: link up (100Mbps/Full duplex) [28746.191940] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [28782.025579] eth1: link down [28784.266545] eth1: link up (100Mbps/Full duplex) [28784.271471] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [30246.613459] eth1: link down [30249.014683] eth1: link up (100Mbps/Full duplex) [30249.019603] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [32144.537910] eth1: link down [32147.131202] eth1: link up (100Mbps/Full duplex) [32147.149670] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [38872.203135] eth1: link down [38873.247956] eth1: link up (100Mbps/Full duplex) [38873.695232] eth1: link down [38876.139641] eth1: link up (100Mbps/Full duplex) [38876.144565] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [39186.470864] eth1: link down [39189.224149] eth1: link up (100Mbps/Full duplex) [39189.238760] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [40019.293485] eth1: link down [40022.302813] eth1: link up (100Mbps/Full duplex) [40022.317265] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [41084.176732] eth1: link down [41087.250081] eth1: link up (100Mbps/Full duplex) [41087.260597] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [43065.688340] eth1: link down [43066.762455] eth1: link up (100Mbps/Full duplex) [43066.780405] eth1: link down [43068.953581] eth1: link up (100Mbps/Full duplex) [43068.964050] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [45176.735987] eth1: link down [45177.813318] eth1: link up (100Mbps/Full duplex) [45177.929459] eth1: link down [45180.003569] eth1: link up (100Mbps/Full duplex) [45180.015357] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [47273.319242] eth1: link down [47275.708534] eth1: link up (100Mbps/Full duplex) [47275.718181] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [47301.574020] eth1: link down [47304.040059] eth1: link up (100Mbps/Full duplex) [47304.045503] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [47480.355611] eth1: link down [47481.427781] eth1: link up (100Mbps/Full duplex) [47481.447013] eth1: link down [47483.556901] eth1: link up (100Mbps/Full duplex) [47483.567363] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [53730.071248] eth1: link down [53731.096636] eth1: link up (100Mbps/Full duplex) [53732.239828] eth1: link down [53734.649205] eth1: link up (100Mbps/Full duplex) [53734.654139] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [54051.443072] ath10k_pci 0000:00:00.0: Cannot communicate with firmware, previous wmi cmds: 36967:13437256 36967:13437239 36965:13436981 40859:13436981, jiffies: 13438016, attempting to fake crash and restart firmware, dev-flags: 0x42 [54051.464514] ath10k_pci 0000:00:00.0: failed to send wmi nop: -143 [54051.470856] ath10k_pci 0000:00:00.0: could not request stats (type -268435456 ret -143 specifier 1) [54051.589474] ath10k_pci 0000:00:00.0: firmware crashed! (guid n/a) [54051.595832] ath10k_pci 0000:00:00.0: qca9888 hw2.0 target 0x01000000 chip_id 0x00000000 sub 0000:0000 [54051.605430] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0 [54051.625558] ath10k_pci 0000:00:00.0: firmware ver 10.4b-ct-9888-fW-013-d81f62d97 api 5 features mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT crc32 937128b4 [54051.655549] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id 0:20 crc32 8971a1b4 [54051.663289] ath10k_pci 0000:00:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file max-sta 32 raw 0 hwcrypto 1 [54051.684158] ath10k_pci 0000:00:00.0: failed to get memcpy hi address for firmware address 4: -16 [54051.693254] ath10k_pci 0000:00:00.0: failed to read firmware dump area: -16 [54051.700454] ath10k_pci 0000:00:00.0: in crash-regs-harder [54052.859201] ath10k_pci 0000:00:00.0: in crash-regs-harder, firmware did not provide indicator: 0x2 [54052.868542] ath10k_pci 0000:00:00.0: Copy Engine register dump: [54052.874710] ath10k_pci 0000:00:00.0: [00]: 0x0004a000 5 5 3 3 [54052.881383] ath10k_pci 0000:00:00.0: [01]: 0x0004a400 21 21 91 92 [54052.888060] ath10k_pci 0000:00:00.0: [02]: 0x0004a800 63 63 62 63 [54052.894737] ath10k_pci 0000:00:00.0: [03]: 0x0004ac00 20 16 20 16 [54052.901405] ath10k_pci 0000:00:00.0: [04]: 0x0004b000 4791 4791 57 17 [54052.908248] ath10k_pci 0000:00:00.0: [05]: 0x0004b400 19 19 50 51 [54052.914919] ath10k_pci 0000:00:00.0: [06]: 0x0004b800 25 25 25 25 [54052.921580] ath10k_pci 0000:00:00.0: [07]: 0x0004bc00 0 1 0 1 [54052.928247] ath10k_pci 0000:00:00.0: [08]: 0x0004c000 0 0 127 0 [54052.934918] ath10k_pci 0000:00:00.0: [09]: 0x0004c400 0 0 0 0 [54052.941579] ath10k_pci 0000:00:00.0: [10]: 0x0004c800 0 0 0 0 [54052.948244] ath10k_pci 0000:00:00.0: [11]: 0x0004cc00 0 0 0 0 [54052.955045] ath10k_pci 0000:00:00.0: failed to get memcpy hi address for firmware address 8: -28 [54052.964224] ath10k_pci 0000:00:00.0: failed to dump debug log area: -28 [54054.231779] ath10k_pci 0000:00:00.0: failed to send pdev bss chan info request: -143 [54054.283727] ath10k_pci 0000:00:00.0: failed to set beacon mode for vdev 0: -143 [54054.291449] ath10k_pci 0000:00:00.0: failed to set dtim period for vdev 0: -143 [54054.299559] ath10k_pci 0000:00:00.0: failed to recalculate rts/cts prot for vdev 0: -143 [54054.308003] ath10k_pci 0000:00:00.0: failed to set cts protection for vdev 0: -143 [54054.315853] ath10k_pci 0000:00:00.0: failed to set preamble for vdev 0: -143 [54054.323152] ath10k_pci 0000:00:00.0: failed to set mgmt tx rate -143 [54057.534308] ath10k_pci 0000:00:00.0: removing peer, cleanup-all, deleting: peer e80ddcc2 vdev: 0 addr: 50:c7:bf:75:81:af [54057.545794] ath10k_pci 0000:00:00.0: failed to read hi_board_data address: -28 [54057.710699] ieee80211 phy0: Hardware restart was requested [54059.808138] ath10k_pci 0000:00:00.0: unsupported HTC service id: 1536 [54059.815390] ath10k_pci 0000:00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96 [54059.823264] ath10k_pci 0000:00:00.0: msdu-desc: 2500 skid: 32 [54059.853446] ath10k_pci 0000:00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186 msdu-desc: 2500 sw-crypt: 0 ct-sta: 0' [54059.864797] ath10k_pci 0000:00:00.0: wmi print 'free: 114524 iram: 12628 sram: 29508' [54060.177482] ath10k_pci 0000:00:00.0: Firmware lacks feature flag indicating a retry limit of > 2 is OK, requested limit: 4 [54060.387955] ath10k_pci 0000:00:00.0: device successfully recovered [56380.150084] eth1: link down [56382.455362] eth1: link up (100Mbps/Full duplex) [56382.460915] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [57573.479020] eth1: link down [57575.848305] eth1: link up (100Mbps/Full duplex) [57575.857942] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [62279.278882] eth1: link down [62282.093972] eth1: link up (100Mbps/Full duplex) [62282.106792] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [62566.921643] eth1: link down [62569.642374] eth1: link up (100Mbps/Full duplex) [62569.647702] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [64258.228833] eth1: link down [64260.469184] eth1: link up (100Mbps/Full duplex) [64260.475349] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [64432.498472] eth1: link down [64434.770921] eth1: link up (100Mbps/Full duplex) [64434.776356] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [64681.582940] eth1: link down [64683.855712] eth1: link up (100Mbps/Full duplex) [64683.860607] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [67376.940335] eth1: link down [67379.277635] eth1: link up (100Mbps/Full duplex) [67379.294109] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [68199.649623] eth1: link down [68201.958955] eth1: link up (100Mbps/Full duplex) [68201.969490] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [68440.734545] eth1: link down [68443.103654] eth1: link up (100Mbps/Full duplex) [68443.110942] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [68926.670978] eth1: link down [68928.765150] eth1: link up (100Mbps/Full duplex) [68928.783506] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [69076.342428] eth1: link down [69078.711358] eth1: link up (100Mbps/Full duplex) [69078.716498] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [69122.741131] eth1: link down [69125.815266] eth1: link up (100Mbps/Full duplex) [69125.822898] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [69135.124950] eth1: link down [69137.334553] eth1: link up (100Mbps/Full duplex) [69137.340172] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [69379.154014] eth1: link down [69381.426908] eth1: link up (100Mbps/Full duplex) [69381.432153] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready root at archer_c60:~# logread | grep udhcpc Tue Aug 4 14:00:10 2020 daemon.notice netifd: wan (11433): udhcpc: received SIGTERM Tue Aug 4 14:00:10 2020 daemon.notice netifd: wan (11433): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 14:00:10 2020 daemon.notice netifd: wan (11433): udhcpc: sending release Tue Aug 4 14:00:10 2020 daemon.notice netifd: wan (11433): udhcpc: entering released state Tue Aug 4 14:00:12 2020 daemon.notice netifd: wan (12732): udhcpc: started, v1.31.1 Tue Aug 4 14:00:12 2020 daemon.notice netifd: wan (12732): udhcpc: sending discover Tue Aug 4 14:00:15 2020 daemon.notice netifd: wan (12732): udhcpc: sending discover Tue Aug 4 14:00:15 2020 daemon.notice netifd: wan (12732): udhcpc: sending select for 190.244.135.61 Tue Aug 4 14:00:15 2020 daemon.notice netifd: wan (12732): udhcpc: lease of 190.244.135.61 obtained, lease time 11197 Tue Aug 4 14:04:19 2020 daemon.notice netifd: wan (12732): udhcpc: received SIGTERM Tue Aug 4 14:04:19 2020 daemon.notice netifd: wan (12732): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 14:04:19 2020 daemon.notice netifd: wan (12732): udhcpc: sending release Tue Aug 4 14:04:19 2020 daemon.notice netifd: wan (12732): udhcpc: entering released state Tue Aug 4 14:04:21 2020 daemon.notice netifd: wan (13989): udhcpc: started, v1.31.1 Tue Aug 4 14:04:21 2020 daemon.notice netifd: wan (13989): udhcpc: sending discover Tue Aug 4 14:04:21 2020 daemon.notice netifd: wan (13989): udhcpc: sending select for 190.244.135.61 Tue Aug 4 14:04:21 2020 daemon.notice netifd: wan (13989): udhcpc: lease of 190.244.135.61 obtained, lease time 10951 Tue Aug 4 14:49:14 2020 daemon.notice netifd: wan (13989): udhcpc: received SIGTERM Tue Aug 4 14:49:14 2020 daemon.notice netifd: wan (13989): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 14:49:14 2020 daemon.notice netifd: wan (13989): udhcpc: sending release Tue Aug 4 14:49:14 2020 daemon.notice netifd: wan (13989): udhcpc: entering released state Tue Aug 4 14:49:17 2020 daemon.notice netifd: wan (15789): udhcpc: started, v1.31.1 Tue Aug 4 14:49:17 2020 daemon.notice netifd: wan (15789): udhcpc: sending discover Tue Aug 4 14:49:17 2020 daemon.notice netifd: wan (15789): udhcpc: sending select for 190.244.135.61 Tue Aug 4 14:49:17 2020 daemon.notice netifd: wan (15789): udhcpc: lease of 190.244.135.61 obtained, lease time 19655 Tue Aug 4 15:02:57 2020 daemon.notice netifd: wan (15789): udhcpc: received SIGTERM Tue Aug 4 15:02:57 2020 daemon.notice netifd: wan (15789): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 15:02:57 2020 daemon.notice netifd: wan (15789): udhcpc: sending release Tue Aug 4 15:02:57 2020 daemon.notice netifd: wan (15789): udhcpc: entering released state Tue Aug 4 15:03:00 2020 daemon.notice netifd: wan (17240): udhcpc: started, v1.31.1 Tue Aug 4 15:03:00 2020 daemon.notice netifd: wan (17240): udhcpc: sending discover Tue Aug 4 15:03:00 2020 daemon.notice netifd: wan (17240): udhcpc: sending select for 190.244.135.61 Tue Aug 4 15:03:00 2020 daemon.notice netifd: wan (17240): udhcpc: lease of 190.244.135.61 obtained, lease time 18833 Tue Aug 4 15:06:58 2020 daemon.notice netifd: wan (17240): udhcpc: received SIGTERM Tue Aug 4 15:06:58 2020 daemon.notice netifd: wan (17240): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 15:06:58 2020 daemon.notice netifd: wan (17240): udhcpc: sending release Tue Aug 4 15:06:58 2020 daemon.notice netifd: wan (17240): udhcpc: entering released state Tue Aug 4 15:07:01 2020 daemon.notice netifd: wan (18540): udhcpc: started, v1.31.1 Tue Aug 4 15:07:01 2020 daemon.notice netifd: wan (18540): udhcpc: sending discover Tue Aug 4 15:07:01 2020 daemon.notice netifd: wan (18540): udhcpc: sending select for 190.244.135.61 Tue Aug 4 15:07:01 2020 daemon.notice netifd: wan (18540): udhcpc: lease of 190.244.135.61 obtained, lease time 18592 Tue Aug 4 15:15:04 2020 daemon.notice netifd: wan (18540): udhcpc: received SIGTERM Tue Aug 4 15:15:04 2020 daemon.notice netifd: wan (18540): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 15:15:04 2020 daemon.notice netifd: wan (18540): udhcpc: sending release Tue Aug 4 15:15:04 2020 daemon.notice netifd: wan (18540): udhcpc: entering released state Tue Aug 4 15:15:07 2020 daemon.notice netifd: wan (20037): udhcpc: started, v1.31.1 Tue Aug 4 15:15:07 2020 daemon.notice netifd: wan (20037): udhcpc: sending discover Tue Aug 4 15:15:10 2020 daemon.notice netifd: wan (20037): udhcpc: sending discover Tue Aug 4 15:15:10 2020 daemon.notice netifd: wan (20037): udhcpc: sending select for 190.244.135.61 Tue Aug 4 15:15:10 2020 daemon.notice netifd: wan (20037): udhcpc: lease of 190.244.135.61 obtained, lease time 600 Tue Aug 4 15:17:34 2020 daemon.notice netifd: wan (20037): udhcpc: received SIGTERM Tue Aug 4 15:17:34 2020 daemon.notice netifd: wan (20037): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 15:17:34 2020 daemon.notice netifd: wan (20037): udhcpc: sending release Tue Aug 4 15:17:34 2020 daemon.notice netifd: wan (20037): udhcpc: entering released state Tue Aug 4 15:17:36 2020 daemon.notice netifd: wan (21065): udhcpc: started, v1.31.1 Tue Aug 4 15:17:36 2020 daemon.notice netifd: wan (21065): udhcpc: sending discover Tue Aug 4 15:17:37 2020 daemon.notice netifd: wan (21065): udhcpc: sending select for 190.244.135.61 Tue Aug 4 15:17:37 2020 daemon.notice netifd: wan (21065): udhcpc: lease of 190.244.135.61 obtained, lease time 453 Tue Aug 4 15:18:21 2020 daemon.notice netifd: wan (21065): udhcpc: received SIGTERM Tue Aug 4 15:18:21 2020 daemon.notice netifd: wan (21065): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 15:18:21 2020 daemon.notice netifd: wan (21065): udhcpc: sending release Tue Aug 4 15:18:21 2020 daemon.notice netifd: wan (21065): udhcpc: entering released state Tue Aug 4 15:18:23 2020 daemon.notice netifd: wan (21840): udhcpc: started, v1.31.1 Tue Aug 4 15:18:23 2020 daemon.notice netifd: wan (21840): udhcpc: sending discover Tue Aug 4 15:18:23 2020 daemon.notice netifd: wan (21840): udhcpc: sending select for 190.244.135.61 Tue Aug 4 15:18:23 2020 daemon.notice netifd: wan (21840): udhcpc: lease of 190.244.135.61 obtained, lease time 406 Tue Aug 4 15:18:33 2020 daemon.notice netifd: wan (21840): udhcpc: received SIGTERM Tue Aug 4 15:18:33 2020 daemon.notice netifd: wan (21840): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 15:18:33 2020 daemon.notice netifd: wan (21840): udhcpc: sending release Tue Aug 4 15:18:33 2020 daemon.notice netifd: wan (21840): udhcpc: entering released state Tue Aug 4 15:18:35 2020 daemon.notice netifd: wan (22614): udhcpc: started, v1.31.1 Tue Aug 4 15:18:35 2020 daemon.notice netifd: wan (22614): udhcpc: sending discover Tue Aug 4 15:18:35 2020 daemon.notice netifd: wan (22614): udhcpc: sending select for 190.244.135.61 Tue Aug 4 15:18:35 2020 daemon.notice netifd: wan (22614): udhcpc: lease of 190.244.135.61 obtained, lease time 395 Tue Aug 4 15:21:52 2020 daemon.notice netifd: wan (22614): udhcpc: sending renew to 172.20.2.226 Tue Aug 4 15:21:52 2020 daemon.notice netifd: wan (22614): udhcpc: lease of 190.244.135.61 obtained, lease time 21600 Tue Aug 4 15:22:37 2020 daemon.notice netifd: wan (22614): udhcpc: received SIGTERM Tue Aug 4 15:22:37 2020 daemon.notice netifd: wan (22614): udhcpc: unicasting a release of 190.244.135.61 to 172.20.2.226 Tue Aug 4 15:22:37 2020 daemon.notice netifd: wan (22614): udhcpc: sending release Tue Aug 4 15:22:37 2020 daemon.notice netifd: wan (22614): udhcpc: entering released state Tue Aug 4 15:22:39 2020 daemon.notice netifd: wan (23460): udhcpc: started, v1.31.1 Tue Aug 4 15:22:39 2020 daemon.notice netifd: wan (23460): udhcpc: sending discover Tue Aug 4 15:22:39 2020 daemon.notice netifd: wan (23460): udhcpc: sending select for 190.244.135.61 Tue Aug 4 15:22:39 2020 daemon.notice netifd: wan (23460): udhcpc: lease of 190.244.135.61 obtained, lease time 21553 root at archer_c60:~# opkg list-installed 6to4 - 13 ath10k-firmware-qca9888-ct - 2020-04-24-2 base-files - 225-r14025-009e62c92c busybox - 1.31.1-1 cgi-io - 19 ddns-scripts - 2.7.8-21 dnsmasq - 2.82-3 dropbear - 2020.80-1 firewall - 2020-07-25-e9b90dfa-1 fstools - 2020-06-17-d34ea8eb-1 fwtool - 2019-11-12-8f7fe925-1 getrandom - 2019-12-31-0e34af14-4 hostapd-common - 2020-06-08-5a8b3662-3 htop - 2.2.0-3 ip-tiny - 5.7.0-2 ip6tables - 1.8.4-1 iperf3 - 3.7-1 iptables - 1.8.4-1 iptables-mod-conntrack-extra - 1.8.4-1 iptables-mod-ipopt - 1.8.4-1 iw - 5.4-1 iwinfo - 2020-06-03-2faa20e5-1 jshn - 2020-07-11-f4e9bf73-1 jsonfilter - 2018-02-04-c7e938d6-1 kernel - 5.4.52-1-a3b0c799c80449fa80b53cf0e54c74e1 kmod-ath - 5.4.52+5.8-rc2-1-1 kmod-ath10k-ct-smallbuffers - 5.4.52+2020-06-30-edfbf916-1 kmod-ath9k - 5.4.52+5.8-rc2-1-1 kmod-ath9k-common - 5.4.52+5.8-rc2-1-1 kmod-cfg80211 - 5.4.52+5.8-rc2-1-1 kmod-gpio-button-hotplug - 5.4.52-3 kmod-hwmon-core - 5.4.52-1 kmod-ifb - 5.4.52-1 kmod-ip6tables - 5.4.52-1 kmod-ipt-conntrack - 5.4.52-1 kmod-ipt-conntrack-extra - 5.4.52-1 kmod-ipt-core - 5.4.52-1 kmod-ipt-ipopt - 5.4.52-1 kmod-ipt-nat - 5.4.52-1 kmod-ipt-offload - 5.4.52-1 kmod-ipt-raw - 5.4.52-1 kmod-iptunnel - 5.4.52-1 kmod-iptunnel4 - 5.4.52-1 kmod-ledtrig-default-on - 5.4.52-1 kmod-ledtrig-heartbeat - 5.4.52-1 kmod-ledtrig-netdev - 5.4.52-1 kmod-ledtrig-timer - 5.4.52-1 kmod-mac80211 - 5.4.52+5.8-rc2-1-1 kmod-nf-conntrack - 5.4.52-1 kmod-nf-conntrack6 - 5.4.52-1 kmod-nf-flow - 5.4.52-1 kmod-nf-ipt - 5.4.52-1 kmod-nf-ipt6 - 5.4.52-1 kmod-nf-nat - 5.4.52-1 kmod-nf-reject - 5.4.52-1 kmod-nf-reject6 - 5.4.52-1 kmod-sched-cake - 5.4.52-1 kmod-sched-cake-virtual - 5.4.52+2020-07-24-48979385-1 kmod-sched-core - 5.4.52-1 kmod-sit - 5.4.52-1 kmod-udptunnel4 - 5.4.52-1 kmod-udptunnel6 - 5.4.52-1 kmod-wireguard - 5.4.52+1.0.20200729-1 libblobmsg-json - 2020-07-11-f4e9bf73-1 libc - 1.1.24-2 libelf1 - 0.179-1 libgcc1 - 8.4.0-2 libip4tc2 - 1.8.4-1 libip6tc2 - 1.8.4-1 libiwinfo-lua - 2020-06-03-2faa20e5-1 libiwinfo20200105 - 2020-06-03-2faa20e5-1 libjson-c5 - 0.14-1 libjson-script - 2020-07-11-f4e9bf73-1 liblua5.1.5 - 5.1.5-7 liblucihttp-lua - 2019-07-05-a34a17d5-1 liblucihttp0 - 2019-07-05-a34a17d5-1 libmbedtls12 - 2.16.6-1 libncurses6 - 6.2-1 libnl-tiny - 2019-10-29-0219008c-1 libopenssl1.1 - 1.1.1g-1 libpcre - 8.44-2 libpthread - 1.1.24-2 librt - 1.1.24-2 libubox20191228 - 2020-07-11-f4e9bf73-1 libubus-lua - 2020-02-05-171469e3-1 libubus20191227 - 2020-02-05-171469e3-1 libuci20130104 - 2020-04-24-ec8d3233-3 libuclient20160123 - 2020-06-17-c6609861-1 libustream-mbedtls20200215 - 2020-03-13-5e1bc342-1 libxtables12 - 1.8.4-1 logd - 2019-12-31-0e34af14-4 lua - 5.1.5-7 luci - git-20.216.62430-9acc7d8 luci-app-ddns - git-20.216.62430-9acc7d8 luci-app-firewall - git-20.216.62430-9acc7d8 luci-app-opkg - git-20.216.62430-9acc7d8 luci-app-sqm - 1.4.0 luci-app-wireguard - git-20.216.62430-9acc7d8 luci-base - git-20.216.62430-9acc7d8 luci-compat - git-20.216.62430-9acc7d8 luci-i18n-base-en - git-20.216.62430-9acc7d8 luci-i18n-base-es - git-20.216.62430-9acc7d8 luci-i18n-ddns-en - git-20.216.62430-9acc7d8 luci-i18n-ddns-es - git-20.216.62430-9acc7d8 luci-i18n-firewall-en - git-20.216.62430-9acc7d8 luci-i18n-firewall-es - git-20.216.62430-9acc7d8 luci-i18n-opkg-en - git-20.216.62430-9acc7d8 luci-i18n-opkg-es - git-20.216.62430-9acc7d8 luci-i18n-sqm-en - git-20.216.62430-9acc7d8 luci-i18n-sqm-es - git-20.216.62430-9acc7d8 luci-i18n-wireguard-en - git-20.216.62430-9acc7d8 luci-i18n-wireguard-es - git-20.216.62430-9acc7d8 luci-lib-base - git-20.216.62430-9acc7d8 luci-lib-ip - git-20.216.62430-9acc7d8 luci-lib-ipkg - git-20.216.62430-9acc7d8 luci-lib-jsonc - git-20.216.62430-9acc7d8 luci-lib-nixio - git-20.216.62430-9acc7d8 luci-mod-admin-full - git-20.216.62430-9acc7d8 luci-mod-network - git-20.216.62430-9acc7d8 luci-mod-status - git-20.216.62430-9acc7d8 luci-mod-system - git-20.216.62430-9acc7d8 luci-proto-ipv6 - git-20.216.62430-9acc7d8 luci-proto-ppp - git-20.216.62430-9acc7d8 luci-proto-wireguard - git-20.216.62430-9acc7d8 luci-ssl - git-20.216.62430-9acc7d8 luci-theme-argon - 2.2.1 luci-theme-bootstrap - git-20.216.62430-9acc7d8 luci-theme-openwrt-2020 - git-20.216.62430-9acc7d8 mtd - 25 nano - 5.0-1 netifd - 2020-06-06-51e9fb81-1 odhcp6c - 2020-03-28-f575351c-16 odhcpd - 2020-06-21-5da52992-4 openwrt-keyring - 2019-07-25-8080ef34-1 opkg - 2020-05-07-f2166a89-1 procd - 2020-07-30-2ae5cbcf-1 px5g-mbedtls - 9 rpcd - 2020-05-26-078bb57e-1 rpcd-mod-file - 2020-05-26-078bb57e-1 rpcd-mod-iwinfo - 2020-05-26-078bb57e-1 rpcd-mod-luci - 20191114 rpcd-mod-rrdns - 20170710 sqm-scripts - 1.4.0-8 swconfig - 12 tc - 5.7.0-2 terminfo - 6.2-1 uboot-envtools - 2020.04-1 ubox - 2019-12-31-0e34af14-4 ubus - 2020-02-05-171469e3-1 ubusd - 2020-02-05-171469e3-1 uci - 2020-04-24-ec8d3233-3 uclient-fetch - 2020-06-17-c6609861-1 uhttpd - 2020-06-03-939c281c-1 uhttpd-mod-ubus - 2020-06-03-939c281c-1 urandom-seed - 2 urngd - 2020-01-21-c7f7b6b6-1 usign - 2020-05-23-f1f65026-1 wget - 1.20.3-4 wireguard-tools - 1.0.20200513-1 wireless-regdb - 2020.04.29-1 wpad-basic - 2020-06-08-5a8b3662-3 zlib - 1.2.11-3 Supply the following if possible: - Device problem occurs on - Software versions of OpenWrt/LEDE release, packages, etc. - Steps to reproduce More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3271 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 4 18:41:03 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 04 Aug 2020 22:41:03 +0000 Subject: [FS#3006] dnsmasq-full fails to resolve Cloudflare domains if DNSSEC is enabled In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3006 - dnsmasq-full fails to resolve Cloudflare domains if DNSSEC is enabled User who did this - Bj?rn Voigt (bjoernv) ---------- Upgrading to OpenWRT 19.07.3 did not fix the problem. ("fix DNSSEC+NTP chicken-and-egg workaround in dnsmasq" was mentioned in the OpenWRT 19.07.3 release notes.) ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3006#comment8630 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 04:09:26 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 08:09:26 +0000 Subject: [FS#3272] jffs2 will erase on every reboot the rootfs_data partition In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Polynomdivision (PolynomialDivision) Attached to Project - OpenWrt/LEDE Project Summary - jffs2 will erase on every reboot the rootfs_data partition Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - I wanted to add support fpr the Nanobeam AC Gen2. https://github.com/openwrt/openwrt/pull/3266 Everything works with trunk compiled with 4.19. Switching to 5.4 seems to not correctly unlock the flash. OpenWrt finds "End of filesystem marker found at 0x0" after a reboot and erases the flash again. **First Boot** Kernel command line: console=ttyS0,115200 rootfstype=squashfs,jffs2 jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. mount_root: jffs2 not ready yet, using temporary tmpfs overlay jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 jffs2_build_filesystem(): unlocking the mtd device... jffs2_build_filesystem(): erasing all blocks after the end marker... jffs2: Newly-erased block contained word 0x0 at offset 0x00420000 jffs2: Newly-erased block contained word 0xdeadc0de at offset 0x00410000 jffs2: Newly-erased block contained word 0xdeadc0de at offset 0x003f0000 jffs2: Newly-erased block contained word 0xb3aedd63 at offset 0x003e0000 jffs2: Newly-erased block contained word 0xd31704ef at offset 0x003d0000 jffs2: Newly-erased block contained word 0x756c245f at offset 0x003c0000 jffs2: Newly-erased block contained word 0x672c1aa9 at offset 0x003b0000 jffs2: Newly-erased block contained word 0xb59345ff at offset 0x003a0000 jffs2: Newly-erased block contained word 0x45e1dc8b at offset 0x00390000 jffs2: Newly-erased block contained word 0x9e92aeea at offset 0x00380000 jffs2: Newly-erased block contained word 0xf9d35c83 at offset 0x00370000 jffs2: Newly-erased block contained word 0xc2075909 at offset 0x00360000 jffs2: Newly-erased block contained word 0x87facdde at offset 0x00350000 jffs2: Newly-erased block contained word 0x65c65c73 at offset 0x00340000 jffs2: notice: (1466) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. mount_root: failed to sync jffs2 overlay [[https://gist.githubusercontent.com/PolynomialDivision/1779cfd7126d9f5841063816b93d1324/raw/cd0e8d9fb1f955f9ee9ed8fd438ab2e307bad848/jffs2-firstboot|Full Log]] **Reboot** Kernel command line: console=ttyS0,115200 rootfstype=squashfs,jffs2 jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00340000: 0x65c6 instead jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00360024: 0x02b5 instead ... jffs2: Further such events for this erase block will not be printed jffs2: Old JFFS2 bitmask found at 0x00369840 jffs2: You cannot use older JFFS2 filesystems with newer kernels jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00370000: 0xf9d3 instead ... jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00390024: 0x3669 instead jffs2: Further such events for this erase block will not be printed jffs2: Old JFFS2 bitmask found at 0x00395294 jffs2: You cannot use older JFFS2 filesystems with newer kernels jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003a0000: 0xb593 instead ... jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x003e0024: 0x79a9 instead jffs2: Further such events for this erase block will not be printed jffs2: Empty flash at 0x003e1e98 ends at 0x003e2000 jffs2: Empty flash at 0x003e2004 ends at 0x003e4000 jffs2_scan_eraseblock(): End of filesystem marker found at 0x3f0000 jffs2_build_filesystem(): unlocking the mtd device... jffs2_build_filesystem(): erasing all blocks after the end marker... jffs2: Newly-erased block contained word 0x0 at offset 0x00420000 jffs2: Newly-erased block contained word 0xdeadc0de at offset 0x00410000 jffs2: Newly-erased block contained word 0xdeadc0de at offset 0x003f0000 jffs2: Newly-erased block contained word 0xb3aedd63 at offset 0x003e0000 jffs2: Newly-erased block contained word 0xd31704ef at offset 0x003d0000 jffs2: Newly-erased block contained word 0x756c245f at offset 0x003c0000 jffs2: Newly-erased block contained word 0x672c1aa9 at offset 0x003b0000 jffs2: Newly-erased block contained word 0xb59345ff at offset 0x003a0000 jffs2: Newly-erased block contained word 0x45e1dc8b at offset 0x00390000 jffs2: Newly-erased block contained word 0x9e92aeea at offset 0x00380000 jffs2: Newly-erased block contained word 0xf9d35c83 at offset 0x00370000 jffs2: Newly-erased block contained word 0xc2075909 at offset 0x00360000 jffs2: Newly-erased block contained word 0x87facdde at offset 0x00350000 jffs2: Newly-erased block contained word 0x65c65c73 at offset 0x00340000 jffs2: notice: (500) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. mount_root: switching to jffs2 overlay [[https://gist.githubusercontent.com/PolynomialDivision/47fc64fe5a9739576bec6faefa6cf459/raw/03ecbb18c5992a4d2891e4368fef49b7bbd857b9/jffs2-reboot|Full Log]] **Probably Related Issues** - [[https://lists.openwrt.org/pipermail/openwrt-devel/2016-February/014119.html|Patch for disabling software protection]] - [[https://elixir.bootlin.com/linux/v5.4.51/source/drivers/mtd/spi-nor/spi-nor.c|SPI Nor Driver]] - [[https://dev.archive.openwrt.org/ticket/20982|jffs2-error / nanostation M5 xw / r47658] **Some Infos** - NOR - Flash Chip Supports 4K erases in addition to 64K - Layout AirOS 8.7 WA# cat /proc/mtd dev: size erasesize name mtd0: 00040000 00010000 "u-boot" mtd1: 00010000 00010000 "u-boot-env" mtd2: 00100000 00010000 "kernel" mtd3: 00e60000 00010000 "rootfs" mtd4: 00040000 00010000 "cfg" mtd5: 00010000 00010000 "EEPROM" **MTD 4.19** dev: size erasesize name mtd0: 00040000 00010000 "u-boot" mtd1: 00010000 00010000 "u-boot-env" mtd2: 00f60000 00010000 "firmware" mtd3: 001c0000 00010000 "kernel" mtd4: 00da0000 00010000 "rootfs" mtd5: 00b30000 00010000 "rootfs_data" mtd6: 00040000 00010000 "cfg" mtd7: 00010000 00010000 "art" **MTD 5.4** TODO More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3272 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 04:17:54 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 08:17:54 +0000 Subject: [FS#3272] jffs2 will erase on every reboot the rootfs_data partition In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3272 - jffs2 will erase on every reboot the rootfs_data partition User who did this - Polynomdivision (PolynomialDivision) ---------- Sry, I did not know that I can not edit the task anymore after publishing it. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3272#comment8631 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 05:09:50 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 09:09:50 +0000 Subject: [FS#3272] jffs2 will erase on every reboot the rootfs_data partition In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3272 - jffs2 will erase on every reboot the rootfs_data partition User who did this - Polynomdivision (PolynomialDivision) ---------- I just went from 4.19 to 5.4 without doing "-n" option of a sysupgrade, and it seems to work fine. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3272#comment8632 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 05:23:22 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 09:23:22 +0000 Subject: [FS#3272] jffs2 will erase on every reboot the rootfs_data partition In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3272 - jffs2 will erase on every reboot the rootfs_data partition User who did this - Polynomdivision (PolynomialDivision) ---------- 4.14 works also fine. (19.07) ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3272#comment8633 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 05:43:34 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 09:43:34 +0000 Subject: [FS#3272] jffs2 will erase on every reboot the rootfs_data partition In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3272 - jffs2 will erase on every reboot the rootfs_data partition User who did this - Polynomdivision (PolynomialDivision) ---------- I compiled 5.4 image and flashed the factory with the fwupdate.real (AirOS) procedure u can find here : https://openwrt.org/toh/ubiquiti/common Afterwards I did a sysupgrade with the sysupgrade-image to be sure. After setting a root password and doing a reboot, I was not able to login anymore (probably corruption of the data partition). So I compiled 4.19 image. AirOs 8.7 -> 4.19 factory -> sysupgrade This worked. Now I did 4.19 -> 5.4 without "-n" option, so I saved the config files. For now everything works fine. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3272#comment8634 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:01:27 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:01:27 +0000 Subject: [FS#3272] jffs2 will erase on every reboot the rootfs_data partition In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3272 - jffs2 will erase on every reboot the rootfs_data partition User who did this - Polynomdivision (PolynomialDivision) ---------- On the OpenWrt Page of the Lightbeam AC Gen2 some similar issue is described: The Lightbeam has the same flash: mx25l12805d and a similar soc: Atheros AR9342-BL1A "The above upgrade procedure left the filesystem in a slightly damaged state (i.e. changes are lost after reboot). This is indicated by kernel messages (dmesg) related to jffs2_scan_eraseblock. Another firmware upgrade fixes this." But this happens only after dd the image directly from airos to the device. https://openwrt.org/toh/ubiquiti/litebeam_5ac_gen2 I believe the Lightbeam AC Gen2 will have the same problems I have with 5.4 kernel. Can someone test that on a lightbeam ac gen2? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3272#comment8635 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:03:38 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:03:38 +0000 Subject: [FS#3272] jffs2 will erase on every reboot the rootfs_data partition In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3272 - jffs2 will erase on every reboot the rootfs_data partition User who did this - Polynomdivision (PolynomialDivision) ---------- This issue could be related since it is the same flash chip: mx25l12805d https://bugs.openwrt.org/index.php?do=details&task_id=1547 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3272#comment8636 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:14:18 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:14:18 +0000 Subject: [FS#2900] ath79 nand trunk bootloop In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#2900 - ath79 nand trunk bootloop User who did this - Petr ?tetiar (ynezz) Reason for closing: Fixed Additional comments about closing: Requested More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2900 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:14:28 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:14:28 +0000 Subject: [FS#2870] Device keeping settings on ZBT-WG3526 (16M) and OpenWrt Trunk [ramips_mt7621] In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#2870 - Device keeping settings on ZBT-WG3526 (16M) and OpenWrt Trunk [ramips_mt7621] User who did this - Petr ?tetiar (ynezz) Reason for closing: Fixed Additional comments about closing: Requested More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2870 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:14:38 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:14:38 +0000 Subject: [FS#3228] ath10k_pci 0000:00:00.0: firmware crashed In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3228 - ath10k_pci 0000:00:00.0: firmware crashed User who did this - Petr ?tetiar (ynezz) Reason for closing: Different project Additional comments about closing: Requested More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3228 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:14:49 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:14:49 +0000 Subject: [FS#3189] WAN interface does not reconnect a lost PPPoE link In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3189 - WAN interface does not reconnect a lost PPPoE link User who did this - Petr ?tetiar (ynezz) Reason for closing: Fixed Additional comments about closing: Requested More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3189 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:15:02 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:15:02 +0000 Subject: [FS#3220] X86 kernel has no emmc support, cause it can't boot from emmc enabled devices In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3220 - X86 kernel has no emmc support, cause it can't boot from emmc enabled devices User who did this - Petr ?tetiar (ynezz) Reason for closing: Invalid report Additional comments about closing: Requested More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3220 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:15:50 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:15:50 +0000 Subject: [FS#1372] 802.11s Mesh with SAE / using wpad-mesh crashing randomly In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been re-opened: FS#1372 - 802.11s Mesh with SAE / using wpad-mesh crashing randomly User who did this - Petr ?tetiar (ynezz) More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=1372 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:16:38 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:16:38 +0000 Subject: [FS#3107] [netifd] wan Command failed: Permission denied | repeated ppp module loads In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3107 - [netifd] wan Command failed: Permission denied | repeated ppp module loads User who did this - Petr ?tetiar (ynezz) Reason for closing: Not a bug Additional comments about closing: Requested More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3107 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:18:58 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:18:58 +0000 Subject: [FS#3105] f1020300.watchdog: driver supplied timeout In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3105 - f1020300.watchdog: driver supplied timeout User who did this - Petr ?tetiar (ynezz) Reason for closing: Deferred Additional comments about closing: Requested More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3105 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 06:20:33 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 05 Aug 2020 10:20:33 +0000 Subject: [FS#1372] 802.11s Mesh with SAE / using wpad-mesh crashing randomly In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#1372 - 802.11s Mesh with SAE / using wpad-mesh crashing randomly User who did this - Petr ?tetiar (ynezz) Reason for closing: Won't fix Additional comments about closing: I've re-opened it by accident. If you're able to reproduce this on 19.07 or ideally on snapshot version, then please ask for re-open. It's unlikely, that this is going fixed in 18.06. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=1372 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 5 22:34:34 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 06 Aug 2020 02:34:34 +0000 Subject: [FS#3273] VLAN isolation failed on ipq40xx (GL-B1300) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - rts (rts) Attached to Project - OpenWrt/LEDE Project Summary - VLAN isolation failed on ipq40xx (GL-B1300) Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - High Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - ipq40xx GL-B1300 OpenWrt snapshot It seems that recent snapshots broke vlan isolation, I guess https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9da2b567605b0964d921b9ca4f0c9886db4f636d should be responsible. More information on https://forum.openwrt.org/t/vlan-isolation-failed-on-ipq40xx-gl-b1300 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3273 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 6 06:15:25 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 06 Aug 2020 10:15:25 +0000 Subject: [FS#612] WAN to LAN leakage on MT7620 devices In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#612 - WAN to LAN leakage on MT7620 devices User who did this - Mikael Brostr?m (sweroam-mibr) ---------- I have this issue also, and also a other problem. the default port-map like llllw or wllll etc will create leak between lan ports also. causing loops, err-disabled or spanning-tree issues. I use some port as trunk ports later in openwrt... i wrote a test patch to the driver that does the following config instead of dts wllll or llllw etc..: enable_vlan=1 port0=vlan0 port1=vlan1 port2=vlan2 port3=vlan3 port4=vlan4 port5=vlan5 port6=vlan6 port7=vlan7 .... portX=vlanX .... this is the result that openwrt gets before the switch is initialized.. result: / # swconfig dev switch0 show|grep -e link -e pvid -e vlan enable_vlan: 1 pvid: 0 link: port:0 link:down pvid: 1 link: port:1 link:down pvid: 2 link: port:2 link:down pvid: 3 link: port:3 link:down pvid: 4 link: port:4 link:down pvid: 5 link: port:5 link:down pvid: 6 link: port:6 link:up speed:1000baseT full-duplex pvid: 7 link: port:7 link:down it works well to prevent leak between all ports on init (fixes: lan to wan lek, lan to lan leak) i then let openwrt initialize the switch using my configuration.. with correct cpu port and config. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=612#comment8638 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 6 08:09:01 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 06 Aug 2020 12:09:01 +0000 Subject: [FS#3274] An error is reported at each start-up phase In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - KLGIT886 (KLGIT886) Attached to Project - OpenWrt/LEDE Project Summary - An error is reported at each start-up phase Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - High Priority - Very Low Reported Version - All Due in Version - Undecided Due Date - Undecided Details - 1.Error log? [ 63.368179] i915 0000:00:02.0: Failed to load DMC firmware i915/glk_dmc_ver1_04.bin. Disabling runtime power management. [ 63.379745] i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 2.Problem?Sometimes the power is suddenly cut off and the machine crashes 3.System information? Intel(R) Celeron(R) J4105 CPU @ 1.50GHz : 4 Core 4 Thread OpenWrt R20.7.20 / LuCI Master (git-20.191.45716-b73d3a4) 4.I tried to use the graphics driver to the kernel.The mistake did not disappear.In addition, I swiped in the latest firmware compiled by others.The problem remains I tried to upgrade the kernel to 5.4.56, which did not solve the problem.Please help me More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3274 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 6 10:16:10 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 06 Aug 2020 14:16:10 +0000 Subject: [FS#3275] MT7621 - Clients disconnecting / deauthenticated due to inactivity In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Kamil Darczynski (Camis) Attached to Project - OpenWrt/LEDE Project Summary - MT7621 - Clients disconnecting / deauthenticated due to inactivity Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Model Netgear R6220 Architecture MediaTek MT7621 OpenWrt 19.07.3 r11063-85e04e9f46 Wed Aug 5 13:20:29 2020 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 90:78:**** Wed Aug 5 13:20:29 2020 daemon.info hostapd: wlan0: STA 90:78:**** RADIUS: starting accounting session ACBA497F6AD16C46 Wed Aug 5 13:20:29 2020 daemon.info hostapd: wlan0: STA 90:78:**** WPA: pairwise key handshake completed (RSN) Wed Aug 5 13:20:29 2020 daemon.info hostapd: wlan1: STA 90:78:**** IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) Wed Aug 5 13:20:35 2020 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED 90:78:**** Wed Aug 5 13:20:35 2020 daemon.info hostapd: wlan0: STA 90:78:**** IEEE 802.11: disassociated Wed Aug 5 13:20:35 2020 daemon.notice hostapd: wlan1: STA-OPMODE-N_SS-CHANGED 90:78:**** 1 Wed Aug 5 13:20:35 2020 daemon.info hostapd: wlan1: STA 90:78:**** IEEE 802.11: associated (aid 1) Wed Aug 5 13:20:35 2020 daemon.notice hostapd: wlan1: AP-STA-CONNECTED 90:78:**** Wed Aug 5 13:20:35 2020 daemon.info hostapd: wlan1: STA 90:78:**** RADIUS: starting accounting session B30F2D4C310A41EA Wed Aug 5 13:20:35 2020 daemon.info hostapd: wlan1: STA 90:78:**** WPA: pairwise key handshake completed (RSN) Wed Aug 5 13:20:36 2020 daemon.info hostapd: wlan0: STA 90:78:**** IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) config wifi-device 'radio0' option type 'mac80211' option hwmode '11g' option path 'pci0000:00/0000:00:01.0/0000:02:00.0' option htmode 'HT20' option country 'PL' option channel '11' option legacy_rates '0' config wifi-iface 'default_radio0' option device 'radio0' option network 'lan' option mode 'ap' option ssid '*****' option key '**********' option ft_over_ds '1' option ieee80211w '1' option ft_psk_generate_local '1' option ieee80211r '1' option mobility_domain '27DB' option encryption 'sae' option disassoc_low_ack '0' config wifi-device 'radio1' option type 'mac80211' option hwmode '11a' option path 'pci0000:00/0000:00:00.0/0000:01:00.0' option htmode 'VHT80' option country 'PL' option channel '128' option legacy_rates '0' config wifi-iface 'wifinet3' option ssid '*****-IoT' option encryption 'psk2+ccmp' option device 'radio0' option mode 'ap' option ieee80211w '1' option key '**********' option ft_over_ds '1' option ft_psk_generate_local '1' option ieee80211r '1' option mobility_domain '285D' option disassoc_low_ack '0' config wifi-iface 'wifinet4' option ssid '*****_5GHz' option device 'radio1' option ieee80211r '1' option ft_over_ds '1' option key '**********' option network 'lan' option mode 'ap' option ieee80211w '1' option ft_psk_generate_local '1' option mobility_domain '27DB' option encryption 'sae' option disassoc_low_ack '0' config wifi-iface 'wifinet6' option ssid '*****_5GHz-IoT' option encryption 'psk2+ccmp' option device 'radio1' option ieee80211r '1' option ft_over_ds '1' option key '**********' option mode 'ap' option ieee80211w '1' option ft_psk_generate_local '1' option mobility_domain '285D' option disassoc_low_ack '0' config wifi-iface 'wifinet5' option ssid '*****-Guest' option encryption 'psk2+ccmp' option device 'radio0' option mode 'ap' option ieee80211w '1' option ft_over_ds '1' option mobility_domain '28B1' option ft_psk_generate_local '1' option ieee80211r '1' option network 'lan' option key '**********' option disassoc_low_ack '0' config wifi-iface 'wifinet7' option ssid '*****_5GHz-Guest' option encryption 'psk2+ccmp' option device 'radio1' option mode 'ap' option ieee80211w '1' option ft_over_ds '1' option ft_psk_generate_local '1' option ieee80211r '1' option mobility_domain '28B1' option network 'lan' option key '**********' option disassoc_low_ack '0' More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3275 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 6 18:22:30 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 06 Aug 2020 22:22:30 +0000 Subject: [FS#2231] fstools: PREINIT calling of block extroot doesn't acknowledge non-MTD rootfs overlays (Attachment added) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2231 - fstools: PREINIT calling of block extroot doesn't acknowledge non-MTD rootfs overlays User who did this - Qi Liu (visualage) ---------- This is the fstools patch. The openwrt patch is just to make sure block-mount depends on libfstools when packaging. Rafal, would you please take a look? ---------- One or more files have been attached. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2231#comment8639 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 6 21:47:16 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 07 Aug 2020 01:47:16 +0000 Subject: [FS#3276] toolchain/binutils 2.34 fails to build for malta target (mipsel64) (Attachment added) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Tony Ambardar (guidosarducci) Attached to Project - OpenWrt/LEDE Project Summary - toolchain/binutils 2.34 fails to build for malta target (mipsel64) Task Type - Bug Report Category - Toolchain Status - Unconfirmed Assigned To - Operating System - All Severity - Critical Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Attempting to build images for malta/mipsel64 on current master fails during compile of binutils toolchain. This has occurred since recent OpenWRT commit 54124e1e1c ("toolchain: binutils: Use version 2.34 by default"). A log file of the build is attached, and a telltale error seems to be: make[7]: *** No rule to make target 'elf64ltsmip.o', needed by 'ld-new'. Stop. This build failure is blocking further testing of malta mips64 platforms with kernel 5.4. One or more files have been attached. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3276 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 6 23:13:37 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 07 Aug 2020 03:13:37 +0000 Subject: [FS#3277] malta/mipseb64: In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Tony Ambardar (guidosarducci) Attached to Project - OpenWrt/LEDE Project Summary - malta/mipseb64: Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Critical Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - On current master, the image for target malta (mipseb64) errors during startup of the init process, resulting in a boot loop. Two points to note: - the problem is not seen with the previous 4.19 kernel - the malta/mipsel64 image fails to build, so the same init error cannot be verified for the alternate endian platform The specific error is a SIGSEGV fault: [ 1.061776] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 1.091522] Freeing unused kernel memory: 21544K [ 1.091778] This architecture does not have kernel memory protection. [ 1.092156] Run /init as init process [ 1.137374] random: fast init done [ 1.197756] init: Console is alive [ 1.284807] kmodloader: loading kernel modules from /etc/modules-boot.d/* [ 1.294466] kmodloader: done loading kernel modules from /etc/modules-boot.d/* [ 1.309498] init: - preinit - [ 1.321863] do_page_fault(): sending SIGSEGV to init for invalid read access from 0000000000000360 [ 1.322458] epc = 0000000000000360 in init[aaaba5c000+4000] [ 1.323185] ra = 000000fffd40d5e0 in [ 1.325513] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.326546] Rebooting in 1 seconds.. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3277 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 7 00:27:43 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 07 Aug 2020 04:27:43 +0000 Subject: [FS#3278] malta: memory allocation failure during boot In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Tony Ambardar (guidosarducci) Attached to Project - OpenWrt/LEDE Project Summary - malta: memory allocation failure during boot Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - The problem is observed on all booting malta subtargets, built from current master and using the default 5.4 kernel and config options. During boot the built-in SCSI CDROM support will fail ("out of memory") during its probe. Sample log file: [ 1.009668] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 [ 1.023561] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 [ 1.037871] kworker/u2:3: page allocation failure: order:0, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0 [ 1.038594] CPU: 0 PID: 90 Comm: kworker/u2:3 Not tainted 5.4.52 #0 [ 1.039141] Workqueue: events_unbound async_run_entry_fn [ 1.039481] Stack : 0000000000000000 0000000000000001 d443da66b6c08100 d443da66b6c08100 [ 1.039936] 0000000000000000 900000009fb2f4d0 ffffffffffffff64 ffffffff804b8360 [ 1.040330] 000000000000009c 3a206576656e7473 5f756e626f756e64 206173796e635f72 [ 1.040802] ffffffffffffffff 0000000000000010 0000000000000000 0000000000000000 [ 1.041179] 0000000000000000 0000000000000000 ffffffff808b0000 ffffffff80890000 [ 1.041582] 0000000000000240 0000000000000240 900000009fb2f818 0000000000000000 [ 1.041983] 0000000000000003 ffffffff804b74f0 0000000000000000 ffffffff81dc0000 [ 1.042380] 900000009fb2c000 900000009fb2f4d0 0000000000000cc1 ffffffff806d8104 [ 1.042776] 0000000000000000 6e626f756e640000 0000000000000000 d443da66b6c08100 [ 1.043174] 0000000000000001 ffffffff8010b0e4 0000000000000001 ffffffff806d8104 [ 1.043592] ... [ 1.043881] Call Trace: [ 1.044100] [] show_stack+0x34/0x108 [ 1.044780] [] dump_stack+0x9c/0xd8 [ 1.045218] [] warn_alloc+0xcc/0x148 [ 1.045619] [] __alloc_pages_slowpath+0xcd0/0xdb8 [ 1.045964] [] __alloc_pages_nodemask+0x290/0x2d0 [ 1.046319] [] new_slab+0x33c/0xd18 [ 1.046644] [] ___slab_alloc.isra.92.constprop.97+0x2cc/0x4d0 [ 1.047023] [] __slab_alloc.isra.93.constprop.96+0x20/0x48 [ 1.047426] [] kmem_cache_alloc+0x1e8/0x2b0 [ 1.047838] [] sr_probe+0x1e4/0x6f0 [ 1.048127] [] really_probe+0xf8/0x350 [ 1.048409] [] bus_for_each_drv+0x70/0xb0 [ 1.048711] [] __device_attach+0xe0/0x120 [ 1.049004] [] bus_probe_device+0xa0/0xc0 [ 1.049296] [] device_add+0x410/0x638 [ 1.049577] [] scsi_sysfs_add_sdev+0x60/0x280 [ 1.049893] [] scsi_probe_and_add_lun+0x96c/0xce8 [ 1.050212] [] __scsi_add_device+0x120/0x178 [ 1.050661] [] ata_scsi_scan_host+0xb8/0x2c0 [ 1.051134] [] async_run_entry_fn+0x50/0x130 [ 1.051576] [] process_one_work+0x250/0x4a8 [ 1.051869] [] worker_thread+0x16c/0x610 [ 1.052158] [] kthread+0x138/0x140 [ 1.052447] [] ret_from_kernel_thread+0x14/0x1c [ 1.053276] Mem-Info: [ 1.053604] active_anon:0 inactive_anon:6244 isolated_anon:0 [ 1.053604] active_file:0 inactive_file:0 isolated_file:0 [ 1.053604] unevictable:0 dirty:0 writeback:0 unstable:0 [ 1.053604] slab_reclaimable:185 slab_unreclaimable:1174 [ 1.053604] mapped:0 shmem:6244 pagetables:0 bounce:0 [ 1.053604] free:104901 free_pcp:33 free_cma:0 [ 1.054876] Node 0 active_anon:0kB inactive_anon:24976kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:24976kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [ 1.055882] DMA free:0kB min:0kB low:0kB high:0kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:16384kB managed:0kB mlocked:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [ 1.056908] lowmem_reserve[]: 0 441 441 441 [ 1.057166] DMA32 free:419604kB min:2688kB low:3360kB high:4032kB active_anon:0kB inactive_anon:24976kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:507900kB managed:451736kB mlocked:0kB kernel_stack:512kB pagetables:0kB bounce:0kB free_pcp:132kB local_pcp:132kB free_cma:0kB [ 1.058190] lowmem_reserve[]: 0 0 0 0 [ 1.058405] DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 0kB [ 1.058943] DMA32: 3*4kB (UME) 1*8kB (U) 7*16kB (UE) 9*32kB (UE) 4*64kB (UME) 3*128kB (UME) 1*256kB (U) 1*512kB (M) 2*1024kB (UE) 1*2048kB (E) 101*4096kB (M) = 419620kB [ 1.059733] 6244 total pagecache pages [ 1.059978] 0 pages in swap cache [ 1.060136] Swap cache stats: add 0, delete 0, find 0/0 [ 1.060397] Free swap = 0kB [ 1.060553] Total swap = 0kB [ 1.060757] 131071 pages RAM [ 1.060912] 0 pages HighMem/MovableOnly [ 1.061161] 18137 pages reserved [ 1.061524] sr 1:0:0:0: [sr0] out of memory. [ 1.061776] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 1.091522] Freeing unused kernel memory: 21544K Based on the log, the //sr_probe// function fails to allocate memory from the low 16MB DMA_ZONE, which is exhausted. While on 32-bit targets the bootup continues and login is possible, there may still be related or follow-on memory problems. For example, malta/mipseb64 shows the same memory allocation failure, and then a subsequent SIGSEGV during //init// startup leads to a boot loop. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3278 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 7 15:04:28 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 07 Aug 2020 19:04:28 +0000 Subject: [FS#2689] netifd /etc/config/wireless wifi-iface requires a key option even when wpa_psk_file is provided In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2689 - netifd /etc/config/wireless wifi-iface requires a key option even when wpa_psk_file is provided User who did this - Jo-Philipp Wich (jow-) ---------- Fixed with https://git.openwrt.org/321503dbf3 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2689#comment8640 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 7 15:04:32 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 07 Aug 2020 19:04:32 +0000 Subject: [FS#2689] netifd /etc/config/wireless wifi-iface requires a key option even when wpa_psk_file is provided In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#2689 - netifd /etc/config/wireless wifi-iface requires a key option even when wpa_psk_file is provided User who did this - Jo-Philipp Wich (jow-) Reason for closing: Fixed More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2689 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 7 17:45:20 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 07 Aug 2020 21:45:20 +0000 Subject: [FS#3018] /usr/sbin/wpad does not match process path (/proc/exe) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3018 - /usr/sbin/wpad does not match process path (/proc/exe) User who did this - Adrian Schmutzler (adrianschmutzler) Reason for closing: Fixed Additional comments about closing: Fixed in https://github.com/openwrt/openwrt/commit/8b3e170526cf0f1d9b15a6dd7787789d15e52cd4 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3018 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 8 09:06:10 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 08 Aug 2020 13:06:10 +0000 Subject: [FS#3279] mac80211 doesn't see AR9820 minipci adapter at mt7621 board In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Aleksey Tregubov (AelxG) Attached to Project - OpenWrt/LEDE Project Summary - mac80211 doesn't see AR9820 minipci adapter at mt7621 board Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Device: Unielec 7621-06 mt7621 with 64M Flash with Atheros AR9820 mini pcie adapter Software: trunk After sysupgrade -n with trunk image kernel does not recognize Atheros adapter: root at router:~# lspci -k 00:00.0 PCI bridge: Device 0e8d:0801 (rev 01) 00:01.0 PCI bridge: Device 0e8d:0801 (rev 01) 01:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) Subsystem: ASMedia Technology Inc. Device 1060 Kernel driver in use: ahci 02:00.0 Ethernet controller: Qualcomm Atheros AR5008 Wireless Network Adapter (rev 01) There is no interesting at dmesg output ex?epts this: [ 1.028161] mt7621-pci 1e140000.pcie: Parsing DT failed [ 1.140760] mt7621-pci 1e140000.pcie: Error applying setting, reverse things back Also there is no any messages about enabling pci002:00.0 device. If mac80211 removed (with depended packets) adapter initialized correctly: root at router:~# lspci -k 00:00.0 PCI bridge: Device 0e8d:0801 (rev 01) 00:01.0 PCI bridge: Device 0e8d:0801 (rev 01) 01:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) Subsystem: ASMedia Technology Inc. Device 1060 Kernel driver in use: ahci 02:00.0 Ethernet controller: Qualcomm Atheros AR982X Wireless Network Adapter (rev 01) Image built by myself, downloaded snapshot from openwrt.org does not run at all. The same card at the same device works perfectly with 19.07.3: root at router:~# lspci -k 00:00.0 PCI bridge: Device 0e8d:0801 (rev 01) 00:01.0 PCI bridge: Device 0e8d:0801 (rev 01) 01:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) Subsystem: ASMedia Technology Inc. Device 1060 Kernel driver in use: ahci 02:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) (rev 01) Subsystem: Qualcomm Atheros Device 3099 Kernel driver in use: ath9k More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3279 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 8 16:30:53 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 08 Aug 2020 20:30:53 +0000 Subject: [FS#3226] GL-AR300M: Frequent WAN (eth1) link down / link up In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3226 - GL-AR300M: Frequent WAN (eth1) link down / link up User who did this - Thiago H Ribeiro (Dynamo) ---------- I am having the same issue on a DIR-878 (ramips) I don't know how to build the firmware but I'm an experienced Linux user, gonna research the documentation. I want to link my troubleshooting history if it's any assistance to anyone searching this issue in the future: [[https://forum.openwrt.org/t/pppoe-disconnects-all-the-time/71165|Forum thread]] ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3226#comment8641 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 8 21:30:26 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 09 Aug 2020 01:30:26 +0000 Subject: [FS#3280] Wan interface and sometimes lan interfaces randomly go up/down at the link layer In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Thiago H Ribeiro (Dynamo) Attached to Project - OpenWrt/LEDE Project Summary - Wan interface and sometimes lan interfaces randomly go up/down at the link layer Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Critical Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - - Versions where bug is present: OpenWRT snapshots, tested with r13938 and r18039. - Affected device: D-Link DIR-878 and likely others from its family. - What does it do and shouldn't do: the ethernet interfaces randomly get switched on/off, dropping the link and resetting the connection. Troubleshooting has already been thoroughly conducted to rule out other causes, see below. This is critical severity because makes OpenWRT unusable in these devices. - Steps to reproduce: -- flash the snapshot image on a D-Link DIR-878; -- configure the WAN (tested with PPPoE and DHCP protocols) and LAN interfaces (tested with Static and DHCP protocols) - using all interfaces will increase the likelihood that at least one of them will present the behaviour; -- wait an indefinite but reasonable (< 2h for all instances so far) amount of time; -- the interface will randomly be put down and then up a couple seconds later, and it will be randomly looping up/down states at random amounts of time. - Troubleshooting already conducted: full and detailed troubleshooting history is present at [[https://forum.openwrt.org/t/pppoe-disconnects-all-the-time/71165|this]] forum thread. Please let me know if I can provide further information. - Additional info: [[https://forum.openwrt.org/t/pppoe-disconnects-all-the-time/71165/18|some]] [[https://forum.openwrt.org/t/dir-882-possible-wi-fi-issues-with-new-mt76-drivers/71292|people]] are having WiFi issues with MT7621 family devices that might be related to this one if they share a common cause, such as a possible race condition in the drivers; More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3280 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 9 02:28:48 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 09 Aug 2020 06:28:48 +0000 Subject: [FS#3277] malta/mipseb64: In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3277 - malta/mipseb64: User who did this - Tony Ambardar (guidosarducci) ---------- I've confirmed this problem also occurs on malta/mipsel64, once the binutils build failure on that platform is fixed by [[https://github.com/openwrt/openwrt/pull/3288|PR#3288]] Reproducing the issue is trivial using QEMU (image built from defaults):./scripts/qemustart malta be64 -cpu MIPS64R2-generic This bug could use input from a developer familiar with procd init. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3277#comment8642 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 9 14:58:12 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 09 Aug 2020 18:58:12 +0000 Subject: [FS#3280] Wan interface and sometimes lan interfaces randomly go up/down at the link layer In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3280 - Wan interface and sometimes lan interfaces randomly go up/down at the link layer User who did this - Thiago H Ribeiro (Dynamo) ---------- The Archer C60 device appears to also be affected: https://bugs.openwrt.org/index.php?do=details&task_id=3271 https://forum.openwrt.org/t/archer-c60-wan-disconnects/68896 https://forum.openwrt.org/t/udhcpc-does-not-work-correctly/69774 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3280#comment8643 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 9 20:30:39 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 10 Aug 2020 00:30:39 +0000 Subject: [FS#3271] WAN-eth1 restarts constantly and stops completely after a while. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3271 - WAN-eth1 restarts constantly and stops completely after a while. User who did this - Thiago H Ribeiro (Dynamo) ---------- Probably related to https://bugs.openwrt.org/index.php?do=details&task_id=3280&openedfrom=-1+week ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3271#comment8644 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 9 20:52:54 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 10 Aug 2020 00:52:54 +0000 Subject: [FS#3280] Wan interface and sometimes lan interfaces randomly go up/down at the link layer In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3280 - Wan interface and sometimes lan interfaces randomly go up/down at the link layer User who did this - Franco Castillo (francocastillo) ---------- Yes, that's why I had to go back to 19.07.3 that this problem does not happen. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3280#comment8645 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 10 01:39:08 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 10 Aug 2020 05:39:08 +0000 Subject: [FS#3269] Compiling the kernel requires entering the CGROUP_HUGETLB option. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3269 - Compiling the kernel requires entering the CGROUP_HUGETLB option. User who did this - wevsty (wevsty) ---------- It's been fixed. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3269#comment8646 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 10 05:59:07 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 10 Aug 2020 09:59:07 +0000 Subject: [FS#3279] mac80211 doesn't see AR9820 minipci adapter at mt7621 board In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3279 - mac80211 doesn't see AR9820 minipci adapter at mt7621 board User who did this - Aleksey Tregubov (AelxG) ---------- Sorry, adapter is __**9280**__, not 9820. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3279#comment8647 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 10 23:29:14 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 11 Aug 2020 03:29:14 +0000 Subject: [FS#3278] malta: memory allocation failure during boot In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3278 - malta: memory allocation failure during boot User who did this - Yousong Zhou (yousong) Reason for closing: Fixed Additional comments about closing: Worked around by not including cdrom support in the kernel build. Ref: https://github.com/openwrt/openwrt/pull/3289 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3278 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 11 02:53:51 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 11 Aug 2020 06:53:51 +0000 Subject: [FS#3226] GL-AR300M: Frequent WAN (eth1) link down / link up In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3226 - GL-AR300M: Frequent WAN (eth1) link down / link up User who did this - Reiner Otto (reinerotto) ---------- Same bug on ZBT WE826 (MT7620A) WAN-connection via eth0.2 going up and down. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3226#comment8648 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 11 11:19:25 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 11 Aug 2020 15:19:25 +0000 Subject: [FS#3281] dnsmasq: option nonwildcard=0 and localservice=1 can not work together In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - rts (rts) Attached to Project - OpenWrt/LEDE Project Summary - dnsmasq: option nonwildcard=0 and localservice=1 can not work together Task Type - Bug Report Category - Packages Status - Unconfirmed Assigned To - Operating System - All Severity - High Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Latest snapshot OpenWrt It can be reproduced on many platform, you can just verify with Virtualbox and x86 images. First restore to factory, then set 'option nonwildcard=0', reboot, ssh to OpenWrt, run 'nslookup he.net', you will get ';; connection timed out; no servers could be reached' error, manually restarting dnsmasq service or setting 'option localservice=0' could fix it. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3281 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 11 23:20:33 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 03:20:33 +0000 Subject: [FS#3276] toolchain/binutils 2.34 fails to build for malta target (mipsel64) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3276 - toolchain/binutils 2.34 fails to build for malta target (mipsel64) User who did this - Tony Ambardar (guidosarducci) ---------- Fixed by https://github.com/openwrt/openwrt/pull/3288. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3276#comment8649 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 12 00:33:59 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 04:33:59 +0000 Subject: [FS#3276] toolchain/binutils 2.34 fails to build for malta target (mipsel64) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3276 - toolchain/binutils 2.34 fails to build for malta target (mipsel64) User who did this - Yousong Zhou (yousong) Reason for closing: Fixed More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3276 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 12 04:45:13 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 08:45:13 +0000 Subject: [FS#3277] malta/mipseb64: In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3277 - malta/mipseb64: User who did this - Tony Ambardar (guidosarducci) ---------- Still seeing the same error after updating to current openwrt commit b59a98b009b9. Enabling debug of procd init shows a little more information. ./scripts/qemustart malta be64 -append "init_debug=4" [...] [ 1.264652] ata2.00: ATAPI: QEMU DVD-ROM, 2.5+, max UDMA/100 [ 1.276184] scsi 1:0:0:0: CD-ROM QEMU QEMU DVD-ROM 2.5+ PQ: 0 ANSI: 5 [ 1.311226] Freeing unused kernel memory: 21628K [ 1.311469] This architecture does not have kernel memory protection. [ 1.311787] Run /init as init process [ 1.418543] init: Console is alive [ 1.436103] init: Ping [ 1.447138] init: Ping [ 1.457733] init: Ping [ 1.468352] init: Ping [ 1.478950] init: Ping [ 1.489642] init: Ping [ 1.500256] init: Ping [ 1.506097] kmodloader: loading kernel modules from /etc/modules-boot.d/* [ 1.511427] init: Ping [ 1.516345] kmodloader: done loading kernel modules from /etc/modules-boot.d/* [ 1.522048] init: Ping [ 1.525605] init: - preinit - [ 1.529807] init: Launched preinit instance, pid=505 [ 1.535329] do_page_fault(): sending SIGSEGV to init for invalid read access from 0000000000000360 [ 1.535755] epc = 0000000000000360 in init[aaab9d8000+4000] [ 1.536552] ra = 000000fffc2f05f0 in [ 1.538997] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.540118] Rebooting in 1 seconds.. Looking at the [[https://lxr.openwrt.org/source/procd/initd/init.c|procd code]], the main init seems to start OK, then forks kmodloader which also completes without error. The subsequent code does: uloop_init(); preinit(); uloop_run(); Looking at the [[https://lxr.openwrt.org/source/procd/initd/preinit.c#L125|preinit() code]], it appears to fork plugd: /sbin/procd -h /etc/hotplug-preinit.json and then fork a preinit instance: /bin/sh /etc/preinit before printing a DEBUG message and returning. The above seems to have worked. The kernel panic is immediately after, and the logged "exitcode=0x0000000b" is: EAGAIN 11 Resource temporarily unavailable Perhaps there's an issue with one of the forked process, or during uloop_run(). ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3277#comment8650 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 12 04:49:31 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 08:49:31 +0000 Subject: [FS#3277] malta/mipseb64: In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3277 - malta/mipseb64: User who did this - Yousong Zhou (yousong) ---------- Likely the 0xb exitcode is for SIGSEGV. See /bin/kill -L ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3277#comment8651 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 12 05:40:57 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 09:40:57 +0000 Subject: [FS#3277] malta/mipseb64: In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3277 - malta/mipseb64: User who did this - Tony Ambardar (guidosarducci) ---------- As another experiment I configured init as /bin/sh to test some basic functions: qemu-system-mips64 -M malta -kernel bpf-openwrt-malta-be64-vmlinux.elf \ -drive file=bpf-openwrt-malta-be64-rootfs-ext4.img,index=0,media=disk \ -nographic -m 512 -append "root=/dev/sda rootfstype=ext4 init=/bin/sh" [...] [ 0.724245] Freeing unused kernel memory: 252K [ 0.724501] This architecture does not have kernel memory protection. [ 0.724920] Run /bin/sh as init process BusyBox v1.31.1 () built-in shell (ash) /bin/sh: can't access tty; job control turned off [ 22.326975] random: fast init done / # / # echo * bin dev etc init lib lib64 lost+found mnt overlay proc rom root sbin sys tmp usr var www / # / # ls [ 35.314543] do_page_fault(): sending SIGSEGV to ls for invalid read access from 0000000000000360 [ 35.314858] epc = 0000000000000360 in busybox[120000000+82000] [ 35.315434] ra = 000000fffeb105f0 in Segmentation fault / # While shell builtins appear to work, commands that require fork/exec are yielding the same SIGSEGV fault. Looks like something very wrong with this system. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3277#comment8652 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 12 13:11:25 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 17:11:25 +0000 Subject: [FS#2887] ath79 port for TP-Link TL-WA830RE v1 doesn't detect LAN connectivity In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2887 - ath79 port for TP-Link TL-WA830RE v1 doesn't detect LAN connectivity User who did this - Kiste (kiste) ---------- That brings the switch back and the link status is accessible via swconfig but I don't know how to connect that status to the network interface. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2887#comment8653 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 12 13:26:49 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 17:26:49 +0000 Subject: [FS#2887] ath79 port for TP-Link TL-WA830RE v1 doesn't detect LAN connectivity In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2887 - ath79 port for TP-Link TL-WA830RE v1 doesn't detect LAN connectivity User who did this - Adrian Schmutzler (adrianschmutzler) ---------- I don't understand the latter part of that sentence. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2887#comment8654 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 12 13:28:19 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 17:28:19 +0000 Subject: [FS#2887] ath79 port for TP-Link TL-WA830RE v1 doesn't detect LAN connectivity In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2887 - ath79 port for TP-Link TL-WA830RE v1 doesn't detect LAN connectivity User who did this - Kiste (kiste) ---------- swconfig shows if the cable is disconnected or not, dmesg doesn't. Sorry, wasn't very clear. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2887#comment8655 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 12 13:45:20 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 17:45:20 +0000 Subject: [FS#3136] Alignment exceptions on ipq806x (r7800) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3136 - Alignment exceptions on ipq806x (r7800) User who did this - ?lvaro Fern?ndez Rojas (Noltari) Reason for closing: Duplicate Additional comments about closing: Duplicates FS#2778. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3136 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 12 14:53:50 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 12 Aug 2020 18:53:50 +0000 Subject: [FS#910] Raspberry Pi 3 keeps attempting to change CPU frequency and failing In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#910 - Raspberry Pi 3 keeps attempting to change CPU frequency and failing User who did this - Chuck (nathhad) ---------- Digging up this older bug report to leave a partial solution that may be useful to others, but this is still an active issue for me with Raspberry Pi 3 Model B Rev 1.2 running GoldenOrb_2020-05-16 (OpenWrt 18.06.7). I've seen in other places on Raspberry Pi references that this tends to be tied to something related to USB. For whatever reason, eliminating CPU frequency switching by any of several possible means does solve the problem. You can either set the frequency manually to a single frequency in /boot/config.txt, or (as I've chosen to do) you can change the governor after boot using /etc/rc.local to one of the two governors that only uses a single frequency (either performance or powersave). In my case, I've locked mine to powersave, since my Pi is rarely heavily loaded. In /etc/rc.local, add the line: echo powersave > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor Or, of course, use performance if you need full speed. If you need something in between, it's relatively easy to set a fixed frequency anywhere from 100 to 1200 (on the 3B) in config.txt, as well, and there is ample info on how to do that on the Pi forums (including tons of fairly advanced info in the Advanced users > Overclocking thread, which is 46 pages long and includes participation from one of the main board engineers for the Pi). ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=910#comment8656 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 13 06:32:56 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 13 Aug 2020 10:32:56 +0000 Subject: [FS#3195] ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3195 - ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 User who did this - Aleksey Tregubov (AelxG) ---------- Have the same problen on uinelec 7621-06. Snapshot images https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/ does not work at all. But custom build from master works but with some limitaions, for example, there is DT parsing error at kernel log, exactly the same as here: https://bugs.openwrt.org/index.php?do=details&task_id=3093 but without solution. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3195#comment8657 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 13 14:25:59 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 13 Aug 2020 18:25:59 +0000 Subject: [FS#3282] [bug/crypto] rockchip: nanopi r2s crypto performance issue In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - CN_SZTL (CN_SZTL) Attached to Project - OpenWrt/LEDE Project Summary - [bug/crypto] rockchip: nanopi r2s crypto performance issue Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - High Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Hello everyone. I found a serious crypto performance problem with NanoPi R2S. Some proxy softwares, like shadowsocks-libev, can only reach to low speed (about ~13 MB/s with aes-128-gcm). On this board, I don't think it's normal. Otherwise, all the chippers perform terriblly, not just aes-128-gcm. I tried run commands like openssl speed -evp aes-128-gcm, and the scores were good, but when running other softwares like trojan which using openssl to crypt / decrypt, the speed totally doesn't match the score. I've ever tried to enable the kernel crypto modules, but it seemded to be useless. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3282 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 13 17:30:53 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 13 Aug 2020 21:30:53 +0000 Subject: [FS#3195] ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3195 - ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 User who did this - camel (camel) ---------- yes, waiting now since 6 months if anyone can commit the patch to master that i can begin testing ;-( ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3195#comment8658 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 13 23:28:03 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 14 Aug 2020 03:28:03 +0000 Subject: [FS#3283] LUCI unavailable when WAN MAC specified In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Robert LeBlanc (rldleblanc) Attached to Project - OpenWrt/LEDE Project Summary - LUCI unavailable when WAN MAC specified Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Running 'OpenWrt 19.07.3 r11063-85e04e9f46' on a Linksys WRT32ACM v1 if you set the WAN MAC to something other than what it really is, you can not access LUCI using the internal router IP (192.168.1.1) when the WAN is plugged in. If unplug the WAN, access to 192.168.1.1 is restored. This does not impact the IPv6 access via `openwrt.lan`. Repeatedly plugging and unplugging the WAN makes the problem appear and go away. I tried all kinds of Firewall rules and port forwards, rebooted and reset many times. I reverted the WAN MAC back to the actual hardware address and it works just fine. It appears that eth1.2 gets the new MAC, but the underlying eth1 still has the burned in MAC and I think that the card drops the packets (VLAN interfaces should have the same MAC as the parent). I'm now noticing that the MAC lines up with the wlan0 interface that was down and that could also contribute to the problem. Supply the following if possible: - Device problem occurs on - Software versions of OpenWrt/LEDE release, packages, etc. - Steps to reproduce 1: lo: mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth1: mtu 1500 qdisc mq state UP qlen 532 link/ether 24:f5:a2:2f:39:d8 brd ff:ff:ff:ff:ff:ff inet6 fe80::26f5:a2ff:fe2f:39d8/64 scope link valid_lft forever preferred_lft forever 3: eth0: mtu 1500 qdisc mq state UP qlen 532 link/ether 26:f5:a2:2f:39:d8 brd ff:ff:ff:ff:ff:ff inet6 fe80::24f5:a2ff:fe2f:39d8/64 scope link valid_lft forever preferred_lft forever 5: wlan0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 24:f5:a2:2f:39:da brd ff:ff:ff:ff:ff:ff 6: wlan1: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 24:f5:a2:2f:39:d9 brd ff:ff:ff:ff:ff:ff 7: mlan0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 24:f5:a2:2f:39:db brd ff:ff:ff:ff:ff:ff 8: br-lan: mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 26:f5:a2:2f:39:d8 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan valid_lft forever preferred_lft forever inet6 2600:6c52:6300:74d6::1/64 scope global dynamic valid_lft 600870sec preferred_lft 600870sec inet6 fdaa:bf91:a905::1/60 scope global valid_lft forever preferred_lft forever inet6 fe80::24f5:a2ff:fe2f:39d8/64 scope link valid_lft forever preferred_lft forever 9: eth0.1 at eth0: mtu 1500 qdisc noqueue master br-lan state UP qlen 1000 link/ether 26:f5:a2:2f:39:d8 brd ff:ff:ff:ff:ff:ff 11: eth1.2 at eth1: mtu 1500 qdisc noqueue state UP qlen 1000 link/ether 24:f5:a2:2f:39:da brd ff:ff:ff:ff:ff:ff inet xx.xx.xx.xx/24 brd 24.176.239.255 scope global eth1.2 valid_lft forever preferred_lft forever inet6 2600:6c52:7008:400:d99f:4eea:b0fd:a61/128 scope global dynamic valid_lft 600870sec preferred_lft 600870sec inet6 fe80::26f5:a2ff:fe2f:39da/64 scope link valid_lft forever preferred_lft forever More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3283 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 13 23:35:59 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 14 Aug 2020 03:35:59 +0000 Subject: [FS#3283] LUCI unavailable when WAN MAC specified In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3283 - LUCI unavailable when WAN MAC specified User who did this - Robert LeBlanc (rldleblanc) ---------- It appears that setting the MAC to not match the wlan interfaces works even though the MAC does not match the parent adapter. I guess it's up to you if you want to make them match or not. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3283#comment8659 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 14 07:08:42 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 14 Aug 2020 11:08:42 +0000 Subject: [FS#2428] ath79: sysupgrade will brick devices with RedBoot bootloader In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2428 - ath79: sysupgrade will brick devices with RedBoot bootloader User who did this - tmn505 (tmn505) ---------- For anyone involved, this patch fixes the bug: [[https://patchwork.ozlabs.org/project/openwrt/patch/20200805211354.3922-1-git at johnthomson.fastmail.com.au|kernel: fix mtd partition erase From openwrt-bugs at lists.openwrt.org Fri Aug 14 09:13:49 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 14 Aug 2020 13:13:49 +0000 Subject: [FS#2887] ath79 port for TP-Link TL-WA830RE v1 doesn't detect LAN connectivity In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2887 - ath79 port for TP-Link TL-WA830RE v1 doesn't detect LAN connectivity User who did this - Adrian Schmutzler (adrianschmutzler) ---------- https://patchwork.ozlabs.org/project/openwrt/patch/20200814130929.13772-1-freifunk at adrianschmutzler.de/ ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2887#comment8661 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 14 10:42:50 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 14 Aug 2020 14:42:50 +0000 Subject: [FS#3277] malta/mipseb64: In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3277 - malta/mipseb64: User who did this - Tony Ambardar (guidosarducci) ---------- BTW, I realized the "exitcode" refers to a status returned by wait() which, in the case of signal termination, encodes the signal in the low byte. So yes, 0x0b is SIGSEGV. I also keep coming back to the fact the invalid read access address and the epc are the same. It seems like there's a crazy jump being made into inaccessible memory, from somewhere well away (ra=000000fffc2f05f0) from the init code. While booting with "init=/bin/sh" a few times, I could manually mount /proc and look at the self memory map. The previous ra seems very close to the [vvar]/[vdso] regions, which could make sense given a long jump, and gives me some ideas/clues to follow up on. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3277#comment8662 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 14 12:18:41 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 14 Aug 2020 16:18:41 +0000 Subject: [FS#3277] malta/mipseb64: In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3277 - malta/mipseb64: User who did this - Yousong Zhou (yousong) Reason for closing: Fixed Additional comments about closing: Fixed by http://github.com/openwrt/openwrt/commit/2932b4d05e1d212259c2903fd9cebcee5616680b More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3277 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 15 00:40:09 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 15 Aug 2020 04:40:09 +0000 Subject: [FS#3284] firewall3 parses boolean options as false In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - RemiNV (RemiNV) Attached to Project - OpenWrt/LEDE Project Summary - firewall3 parses boolean options as false Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - fw3 does not parse boolean options properly: { "bool_attr": "true" } is fine, but { "bool_attr": true } (no quotes) is parsed as false. Repro steps: Assuming there is a "wanclient" DHCPv6 client logical interface, based on a eth0.2 switch VLAN interface: ubus call network.interface notify_proto '{ "action": 0, "link-up": true, "interface": "wanclient", "ifname": "eth0.2", "data": { "firewall": [ { "type": "nat", "target": "SNAT", "family": "inet", "proto": "icmp", "connlimit_ports": true, "snat_ip": "192.168.42.42", "snat_port": "63345-63346" }]}}' iptables -t nat -S POSTROUTING Shows the following iptables SNAT rule: -A POSTROUTING -o eth0.2 -p icmp -m comment --comment "!fw3: ubus:wanclient[dhcpv6] nat 0" -j SNAT --to-source 192.168.42.42:63345-63346 Notice that it does not specify connlimit options, even though '"connlimit_ports": true' was specified in the ubus call. However if the same is done with '"connlimit_ports": "true"' (note the quotes around "true"): ubus call network.interface notify_proto '{ "action": 0, "link-up": true, "interface": "wanclient", "ifname": "eth0.2", "data": { "firewall": [ { "type": "nat", "target": "SNAT", "family": "inet", "proto": "icmp", "connlimit_ports": "true", "snat_ip": "192.168.42.42", "snat_port": "63345-63346" }]}}' The correct iptables rule is added: -A POSTROUTING -o eth0.2 -p icmp -m connlimit --connlimit-upto 2 --connlimit-mask 32 --connlimit-daddr -m comment --comment "!fw3: ubus:wanclient[dhcpv6] nat 0" -j SNAT --to-source 192.168.42.42:63345-63346 This seems to be a bug in firewall3/options.c: in fw3_parse_blob_options, boolean options as parsed as string options (with blobmsg_get_string), which seems to return an empty string for an actual boolean option (true without quotes). I have a patch and will try to send it. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3284 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 15 00:55:14 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 15 Aug 2020 04:55:14 +0000 Subject: [FS#3284] firewall3 parses boolean options as false In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3284 - firewall3 parses boolean options as false User who did this - RemiNV (RemiNV) ---------- Sent a patch in https://patchwork.ozlabs.org/project/openwrt/patch/20200815045027.919125-1-remi.nguyenvan+openwrt at gmail.com/ ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3284#comment8663 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 15 00:59:35 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 15 Aug 2020 04:59:35 +0000 Subject: [FS#3284] firewall3 parses boolean options as false In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3284 - firewall3 parses boolean options as false User who did this - RemiNV (RemiNV) ---------- Note that because of this bug, the map-e protocol (implemented in package/network/ipv6/map/files/map.sh) does not function properly, as the "connlimit_ports" option does not get applied, so the first iptables rule catches all connections and runs out of ports. People have been resorting to really hacky workarounds to get it to work, such as: https://gist.github.com/anonymous/0fdec75fa20a7f1ce4806391d6b0429b ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3284#comment8664 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 15 08:32:09 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 15 Aug 2020 12:32:09 +0000 Subject: [FS#3285] Can't change MTU on IPQ806x devices In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - jacekowski (jacekowski) Attached to Project - OpenWrt/LEDE Project Summary - Can't change MTU on IPQ806x devices Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - High Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - - I've personally tested it on ZyXEL NBG6817 - Any version with https://patchwork.kernel.org/patch/11283121/ patch applied - To reproduce: # ifdown wan # ifconfig (wan_interface) MTU 1499 (or 1501 or anything other than 1500) This bug is caused by txfifosz being 0 on IPQ806x devices (and possibly more) unless tx-fifo-depth is specified in device tree, potential fix would be to specify tx-fifo-depth in device tree for all affected devices, or, check if txfifosz == 0 and then allow MTU change. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3285 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 15 13:02:46 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 15 Aug 2020 17:02:46 +0000 Subject: [FS#3286] SD card freezing for a while on Raspberry Pi 3 Model B Rev 1.2 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - ?ukasz Kalam?acki (kantacki) Attached to Project - OpenWrt/LEDE Project Summary - SD card freezing for a while on Raspberry Pi 3 Model B Rev 1.2 Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Supply the following if possible: - Device problem occurs on Raspberry Pi 3 Model B Rev 1.2 - OpenWrt 19.07.3 and occurs in the Linux kernel module. - Steps to reproduce: Run RPI3B and wait for a while and monitor kernel logs and you will get the following: [ 33.111038] mmc0: timeout waiting for hardware interrupt. [ 33.118228] [019e2838] FCM> 34f29528 34f29628 [ 33.124313] [019e2839] IRQ> 0 0 [ 33.129082] [019e283d] TSK< 34f29528 0 [ 33.134397] [019e284b] TSK> 34f29528 0 [ 33.139625] [819e286f] REQ< 8b8baa0 10801 [ 33.145087] [819e2872] CMD< d 70000 [ 33.149984] [819e2879] FCM< 8b8baa0 8b8bb40 [ 33.155539] [819e287c] RSP 900 0 [ 33.160141] [819e2882] FCM> 8b8baa0 0 [ 33.165110] [819e2883] CMD d 0 [ 33.169506] [819e2884] REQ> 8b8baa0 0 [ 33.174403] [819e288a] TSK< 8b8baa0 0 [ 33.179286] [819e288e] TSK> 8b8baa0 0 [ 33.184103] [819e2895] PRD< 34f28668 0 [ 33.188995] [819e2895] PRD1 38ecf080 0 [ 33.193843] [819e289a] PRD2 1 0 [ 33.198009] [819e28a2] PRD3 35799808 0 [ 33.202727] [819e28a2] PDM> 34f28668 0 [ 33.207372] [819e28a2] REQ< 34f28528 10801 [ 33.212369] [819e28a3] CMD< 19 ed74f8 [ 33.216877] [819e28a5] CMDD 8 200 [ 33.220985] [819e28a6] SDMA 34f28668 38ecf080 [ 33.226169] [819e28a7] FCM< 34f28528 34f285e8 [ 33.231353] [819e28a8] RSP 900 0 [ 33.235491] [819e28a8] FCM> 34f28528 0 [ 33.240065] [819e28a9] CMD 19 200 [ 33.244277] [819e28a9] REQ> 34f28528 0 [ 33.248840] [419e2a08] DMA< 34f28668 1 [ 33.253393] [419e2a09] DMA 99 10807 [ 33.257763] [419e2a0b] FDA< 34f28528 0 [ 33.262313] [419e2a0c] TCM< 34f28668 0 [ 33.266850] [419e2a0c] CMD< c 0 [ 33.270772] [419e2a0d] TCM> 34f28668 0 [ 33.275345] [419e2a0d] FDA> 34f28528 34f28628 [ 33.280535] [419e2a0e] DMA> 0 0 [ 33.284488] [419e2ba1] IRQ< 400 0 [ 33.288616] [419e2ba1] IRQB 34f28628 400 [ 33.293372] [419e2ba2] FCM< 34f28528 34f28628 [ 33.298582] [419e2ba3] RSP c00 0 [ 33.302733] [419e2ba4] FCM> 34f28528 34f28628 [ 33.307964] [419e2ba5] IRQ> 0 0 [ 33.311953] [419e2ba6] TSK< 34f28528 0 [ 33.316559] [419e2bab] TSK> 34f28528 0 [ 33.321148] [819e2bb3] REQ< 8b8baa0 10801 [ 33.326005] [819e2bb4] CMD< d 70000 [ 33.330327] [819e2bb6] FCM< 8b8baa0 8b8bb40 [ 33.335370] [819e2bb9] RSP 900 0 [ 33.339530] [819e2bbc] FCM> 8b8baa0 0 [ 33.344048] [819e2bbc] CMD d 0 [ 33.348026] [819e2bbc] REQ> 8b8baa0 0 [ 33.352541] [819e2bc0] TSK< 8b8baa0 0 [ 33.357057] [819e2bc3] TSK> 8b8baa0 0 [ 33.361557] [819e2e8c] PRD< 34f29e68 0 [ 33.366146] [819e2e8d] PRD1 38ecf080 0 [ 33.370729] [819e2e95] PRD2 1 0 [ 33.374677] [819e2e9b] PRD3 35799908 0 [ 33.379255] [819e2e9b] PDM> 34f29e68 0 [ 33.383827] [819e2e9c] REQ< 34f29d28 10801 [ 33.388754] [819e2e9d] CMD< 19 ed74f8 [ 33.393230] [819e2ea3] CMDD 8 200 [ 33.397331] [819e2ea4] SDMA 34f29e68 38ecf080 [ 33.402510] [819e2ea6] FCM< 34f29d28 34f29de8 [ 33.407688] [819e2ea8] RSP 900 0 [ 33.411822] [819e2ea8] FCM> 34f29d28 0 [ 33.416391] [819e2ea9] CMD 19 200 [ 33.420602] [819e2eaa] REQ> 34f29d28 0 [ 33.425167] [c19e301d] DMA< 34f29e68 0 [ 33.429721] [c19e301e] DMA 99 10801 [ 33.434091] [c19e3020] FDA< 34f29d28 0 [ 33.438645] [c19e3021] TCM< 34f29e68 0 [ 33.443191] [c19e3022] CMD< c 0 [ 33.447122] [c19e3024] TCM> 34f29e68 0 [ 33.451699] [c19e3024] FDA> 34f29d28 34f29e28 [ 33.456901] [c19e3024] DMA> 0 0 [ 33.460859] [019e31ce] IRQ< 400 0 [ 33.464998] [019e31cf] IRQB 34f29e28 400 [ 33.469768] [019e31cf] FCM< 34f29d28 34f29e28 [ 33.474990] [019e31d1] RSP c00 0 [ 33.479151] [019e31d2] FCM> 34f29d28 34f29e28 [ 33.484390] [019e31d3] IRQ> 0 0 [ 33.488390] [019e31d5] TSK< 34f29d28 0 [ 33.493002] [019e31dc] TSK> 34f29d28 0 [ 33.497594] [819e32e0] REQ< 8b8baa0 10801 [ 33.502455] [819e32e1] CMD< d 70000 [ 33.506784] [819e32e8] FCM< 8b8baa0 8b8bb40 [ 33.511835] [819e32eb] RSP 900 0 [ 33.515996] [819e32ef] FCM> 8b8baa0 0 [ 33.520519] [819e32ef] CMD d 0 [ 33.524507] [819e32f0] REQ> 8b8baa0 0 [ 33.529031] [819e32f6] TSK< 8b8baa0 0 [ 33.533550] [819e32fa] TSK> 8b8baa0 0 [ 33.538055] [819e3300] PRD< 34f29268 0 [ 33.542652] [819e3301] PRD1 38ecf080 0 [ 33.547242] [819e3305] PRD2 1 0 [ 33.551195] [819e330d] PRD3 35799a08 0 [ 33.555775] [819e330e] PDM> 34f29268 0 [ 33.560348] [819e330e] REQ< 34f29128 10801 [ 33.565277] [819e330f] CMD< 19 ed1908 [ 33.569749] [819e3311] CMDD 8 200 [ 33.573851] [819e3311] SDMA 34f29268 38ecf080 [ 33.579028] [819e3312] FCM< 34f29128 34f291e8 [ 33.584206] [819e3314] RSP 900 0 [ 33.588340] [819e3314] FCM> 34f29128 0 [ 33.592908] [819e3314] CMD 19 200 [ 33.597114] [819e3315] REQ> 34f29128 0 [ 33.601673] [819e349f] DMA< 34f29268 0 [ 33.606221] [819e34a0] DMA 99 10801 [ 33.610586] [819e34a3] FDA< 34f29128 0 [ 33.615133] [819e34a4] TCM< 34f29268 0 [ 33.619669] [819e34a5] CMD< c 0 [ 33.623592] [819e34a7] TCM> 34f29268 0 [ 33.628162] [819e34a7] FDA> 34f29128 34f29228 [ 33.633350] [819e34a8] DMA> 0 0 [ 33.637300] [819e3634] IRQ< 400 0 [ 33.641430] [819e3635] IRQB 34f29228 400 [ 33.646187] [819e3636] FCM< 34f29128 34f29228 [ 33.651399] [819e3639] RSP c00 0 [ 33.655551] [819e363a] FCM> 34f29128 34f29228 [ 33.660784] [819e363b] IRQ> 0 0 [ 33.664774] [819e363d] TSK< 34f29128 0 [ 33.669384] [819e364b] TSK> 34f29128 0 [ 33.673974] [819e365b] REQ< 8b8baa0 10801 [ 33.678826] [819e365c] CMD< d 70000 [ 33.683144] [819e3660] FCM< 8b8baa0 8b8bb40 [ 33.688189] [819e3662] RSP 900 0 [ 33.692344] [819e3665] FCM> 8b8baa0 0 [ 33.696861] [819e3666] CMD d 0 [ 33.700842] [819e3666] REQ> 8b8baa0 0 [ 33.705359] [819e366e] TSK< 8b8baa0 0 [ 33.709874] [819e3672] TSK> 8b8baa0 0 [ 33.714371] [819e3679] PRD< 34c12a68 0 [ 33.718959] [819e367a] PRD1 38ecf080 0 [ 33.723544] [819e3685] PRD2 13 0 [ 33.727580] [819e3696] PRD3 34d1d008 0 [ 33.732157] [819e3697] PDM> 34c12a68 0 [ 33.736729] [819e3698] REQ< 34c12928 10801 [ 33.741657] [819e3698] CMD< 17 a8 [ 33.745770] [819e369a] FCM< 34c12928 34c129a8 [ 33.750957] [819e369d] RSP 900 0 [ 33.755072] [819e369d] CMD< 12 1f9de [ 33.759452] [819e369f] CMDD a8 200 [ 33.763662] [819e36a0] SDMA 34c12a68 38ecf080 [ 33.768864] [819e36a1] FCM< 34c12928 34c129e8 [ 33.774069] [819e36a2] RSP 900 0 [ 33.778200] [819e36a3] FCM> 34c12928 0 [ 33.782770] [819e36a3] FCM> 34c12928 0 [ 33.787318] [819e36a4] CMD 12 200 [ 33.791510] [819e36a4] REQ> 34c12928 0 [ 33.796060] [019e47c5] DMA< 34c12a68 1 [ 33.800620] [019e47c7] DMA 52 10834 [ 33.805014] [019e47d6] FDA< 34c12928 0 [ 33.809588] [019e47d7] TCM< 34c12a68 0 [ 33.814157] [019e47d8] WTC< 10804 0 [ 33.818459] [019e47d9] WTC> 10804 0 [ 33.822746] [019e47d9] TCM> 34c12a68 0 [ 33.827306] [019e47d9] FDA> 34c12928 0 [ 33.831851] [019e47d9] DMA> 0 0 [ 33.835764] [019e47db] TSK< 34c12928 0 [ 33.840297] [019e47f0] TSK> 34c12928 0 [ 33.844803] [819e481f] PRD< 34f2a668 0 [ 33.849313] [819e481f] PRD1 38ecf080 0 [ 33.853819] [819e4823] PRD2 1 0 [ 33.857684] [819e482a] PRD3 360b5d08 0 [ 33.862173] [819e482a] PDM> 34f2a668 0 [ 33.866642] [819e482b] REQ< 34f2a528 10801 [ 33.871469] [819e482d] CMD< 19 ed1910 [ 33.875876] [819e4834] CMDD 8 200 [ 33.879921] [819e4835] SDMA 34f2a668 38ecf080 [ 33.885051] [819e4838] FCM< 34f2a528 34f2a5e8 [ 33.890187] [819e4839] RSP 900 0 [ 33.894262] [819e483a] FCM> 34f2a528 0 [ 33.898781] [819e483b] CMD 19 200 [ 33.902953] [819e483b] REQ> 34f2a528 0 [ 33.907486] [019e490c] DMA< 34f2a668 1 [ 33.912034] [019e490d] DMA 99 10807 [ 33.916400] [019e490e] FDA< 34f2a528 0 [ 33.920963] [019e490f] TCM< 34f2a668 0 [ 33.925521] [019e490f] CMD< c 0 [ 33.929444] [019e4911] TCM> 34f2a668 0 [ 33.934012] [019e4912] FDA> 34f2a528 34f2a628 [ 33.939210] [019e4912] DMA> 0 0 [ 33.943171] [019e4aa2] IRQ< 400 0 [ 33.947306] [019e4aa3] IRQB 34f2a628 400 [ 33.952072] [019e4aa3] FCM< 34f2a528 34f2a628 [ 33.957293] [019e4aa5] RSP c00 0 [ 33.961452] [019e4aa6] FCM> 34f2a528 34f2a628 [ 33.966692] [019e4aa7] IRQ> 0 0 [ 33.970687] [019e4aaa] TSK< 34f2a528 0 [ 33.975301] [019e4abd] TSK> 34f2a528 0 [ 33.979897] [819e4adb] REQ< 8b8baa0 10801 [ 33.984758] [819e4add] CMD< d 70000 [ 33.989086] [819e4ae1] FCM< 8b8baa0 8b8bb40 [ 33.994136] [819e4ae4] RSP 900 0 [ 33.998297] [819e4ae8] FCM> 8b8baa0 0 [ 34.002817] [819e4ae9] CMD d 0 [ 34.006806] [819e4ae9] REQ> 8b8baa0 0 [ 34.011328] [819e4af7] TSK< 8b8baa0 0 [ 34.015849] [819e4afd] TSK> 8b8baa0 0 [ 34.020356] [819e4b08] PRD< 34f2aa68 0 [ 34.024954] [819e4b09] PRD1 38ecf080 0 [ 34.029540] [819e4b0d] PRD2 1 0 [ 34.033491] [819e4b13] PRD3 382b2608 0 [ 34.038076] [819e4b14] PDM> 34f2aa68 0 [ 34.042657] [819e4b15] REQ< 34f2a928 10801 [ 34.047594] [819e4b15] CMD< 19 ed74f8 [ 34.052075] [819e4b17] CMDD 8 200 [ 34.056183] [819e4b18] SDMA 34f2aa68 38ecf080 [ 34.061370] [819e4b1a] FCM< 34f2a928 34f2a9e8 [ 34.066554] [819e4b1b] RSP 900 0 [ 34.070691] [819e4b1b] FCM> 34f2a928 0 [ 34.075269] [819e4b1c] CMD 19 200 [ 34.079484] [819e4b1c] REQ> 34f2a928 0 [ 34.084047] [419e4c97] DMA< 34f2aa68 0 [ 34.088602] [419e4c98] DMA 99 10801 [ 34.092973] [419e4c9a] FDA< 34f2a928 0 [ 34.097521] [419e4c9c] TCM< 34f2aa68 0 [ 34.102060] [419e4c9d] CMD< c 0 [ 34.105989] [419e4ca0] TCM> 34f2aa68 0 [ 34.110563] [419e4ca1] FDA> 34f2a928 34f2aa28 [ 34.115763] [419e4ca1] DMA> 0 0 [ 34.119720] [819e4e32] IRQ< 400 0 [ 34.123855] [819e4e33] IRQB 34f2aa28 400 [ 34.128622] [819e4e34] FCM< 34f2a928 34f2aa28 [ 34.133841] [819e4e36] RSP c00 0 [ 34.138000] [819e4e37] FCM> 34f2a928 34f2aa28 [ 34.143241] [819e4e37] IRQ> 0 0 [ 34.147238] [819e4e3b] TSK< 34f2a928 0 [ 34.151853] [819e4e4d] TSK> 34f2a928 0 [ 34.156450] [819e5abf] REQ< 8b8baa0 10801 [ 34.161314] [819e5ac0] CMD< d 70000 [ 34.165644] [819e5acc] FCM< 8b8baa0 8b8bb40 [ 34.170694] [819e5acf] RSP 900 0 [ 34.174862] [819e5ad3] FCM> 8b8baa0 0 [ 34.179390] [819e5ad4] CMD d 0 [ 34.183382] [819e5ad5] REQ> 8b8baa0 0 [ 34.187913] [819e5adf] TSK< 8b8baa0 0 [ 34.192441] [819e5ae6] TSK> 8b8baa0 0 [ 34.196952] [819e5af7] PRD< 383a6668 0 [ 34.201552] [819e5af8] PRD1 38ecf080 0 [ 34.206140] [819e5b03] PRD2 2 0 [ 34.210099] [819e5b0b] PRD3 360b5d08 0 [ 34.214684] [819e5b0b] PDM> 383a6668 0 [ 34.219259] [819e5b0c] REQ< 383a6528 10801 [ 34.224191] [819e5b0c] CMD< 17 8c [ 34.228310] [819e5b0e] FCM< 383a6528 383a65a8 [ 34.233500] [819e5b10] RSP 900 0 [ 34.237620] [819e5b11] CMD< 12 21982 [ 34.242005] [819e5b13] CMDD 8c 200 [ 34.246220] [819e5b14] SDMA 383a6668 38ecf080 [ 34.251421] [819e5b16] FCM< 383a6528 383a65e8 [ 34.256619] [819e5b17] RSP 900 0 [ 34.260748] [819e5b18] FCM> 383a6528 0 [ 34.265319] [819e5b18] FCM> 383a6528 0 [ 34.269870] [819e5b18] CMD 12 200 [ 34.274060] [819e5b19] REQ> 383a6528 0 [ 34.278607] [823adfd1] TIM< 0 0 [ 34.282555] mmc0: sbc op 23 arg 0x8c flags 0x15 - resp 00000900 00000000 00000000 00000000, err 0 [ 34.293364] mmc0: cmd op 18 arg 0x21982 flags 0xb5 - resp 00000900 00000000 00000000 00000000, err 0 [ 34.304769] mmc0: data blocks 8c blksz 200 - err 0 [ 34.310795] mmc0: stop op 12 arg 0x0 flags 0x95 - resp 00000000 00000000 00000000 00000000, err 0 [ 34.322319] mmc0: =========== REGISTER DUMP =========== [ 34.328983] mmc0: SDCMD 0x00004052 [ 34.333872] mmc0: SDARG 0x00021982 [ 34.338742] mmc0: SDTOUT 0x017d7840 [ 34.343607] mmc0: SDCDIV 0x00000003 [ 34.348472] mmc0: SDRSP0 0x00000900 [ 34.353319] mmc0: SDRSP1 0x00001269 [ 34.358154] mmc0: SDRSP2 0x7fffffff [ 34.362970] mmc0: SDRSP3 0x00024007 [ 34.367774] mmc0: SDHSTS 0x00000080 [ 34.372593] mmc0: SDVDD 0x00000001 [ 34.377403] mmc0: SDEDM 0x00010801 [ 34.382197] mmc0: SDHCFG 0x0000040e [ 34.386978] mmc0: SDHBCT 0x00000200 [ 34.391676] mmc0: SDHBLC 0x00000006 [ 34.396280] mmc0: =========================================== [ 34.403337] mmcblk0: error -110 transferring data, sector 137602, nr 140, cmd response 0x900, card status 0xb00 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3286 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 15 15:31:55 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 15 Aug 2020 19:31:55 +0000 Subject: [FS#3285] Can't change MTU on IPQ806x devices In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3285 - Can't change MTU on IPQ806x devices User who did this - S?awomir Gajowniczek (kebe) ---------- Same here. Archer C2600 (ipq8064) ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3285#comment8665 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 15 18:11:44 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 15 Aug 2020 22:11:44 +0000 Subject: [FS#1449] mt7621 - zbt3526 - mtk_soc_eth -> port 3 link up & down all the time :( In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1449 - mt7621 - zbt3526 - mtk_soc_eth -> port 3 link up & down all the time :( User who did this - Andrey Romanov (andalerom) ---------- Same problem. v19.07.3. "port 4 link down/up", WAN port, 100mbit. Seems switching from port 4 to 1 helped. (same cable) ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=1449#comment8666 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 15 21:30:13 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 16 Aug 2020 01:30:13 +0000 Subject: [FS#3287] Can't save changes to interface with type MAP in LuCI In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - RemiNV (RemiNV) Attached to Project - OpenWrt/LEDE Project Summary - Can't save changes to interface with type MAP in LuCI Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Observed on LuCI openwrt-19.07 branch (git-20.136.49537-fb2f363) / OpenWrt 19.07.3 r11063-85e04e9f46, on Chrome browser Repro steps: - Install packages map, luci-proto-ipv6 - Add interface with protocol type "MAP / LW4over6" - Try to edit the interface options in LuCI, and click save Expected: Changes are saved and dialog is dismissed Actual: "Save" button gets greyed out but dialog stays there. Chrome console says: form.js?v=git-20.136.49537-fb2f363:formatted:1399 Uncaught TypeError: elem.isChecked is not a function at ClassConstructor.formvalue (form.js?v=git-20.136.49537-fb2f363:formatted:1399) at ClassConstructor.parse (form.js?v=git-20.136.49537-fb2f363:formatted:1410) at ClassConstructor.parse (form.js?v=git-20.136.49537-fb2f363:formatted:386) at ClassConstructor.parse (form.js?v=git-20.136.49537-fb2f363:formatted:237) at ClassConstructor.save (form.js?v=git-20.136.49537-fb2f363:formatted:242) at ClassConstructor.handleModalSave (form.js?v=git-20.136.49537-fb2f363:formatted:1043) at ClassConstructor.super (luci.js?v=git-20.136.49537-fb2f363:22) at ClassConstructor.handleModalSave (form.js?v=git-20.136.49537-fb2f363:formatted:1107) at ClassConstructor.eval (ui.js?v=git-20.136.49537-fb2f363:300) It appears that LuCI is confused by the fact that there are two controls for the "type" option: - The "Bridge interfaces" checkbox (actually hidden for MAP, but still there, and documented in "Options valid for all protocol types" here: https://openwrt.org/docs/guide-user/base-system/basic-networking) - The MAP type option (MAP-E, MAP-T, LW4over6) It does not seem correct to have "type" be both a common option for all protocols, and have a different option with the same name for MAP: this makes the configuration ambiguous (which is why LuCI gets confused). I think renaming "type" to "maptype" (for example) for MAP would be the best solution. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3287 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 15 21:53:03 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 16 Aug 2020 01:53:03 +0000 Subject: [FS#3287] Can't save changes to interface with type MAP in LuCI In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3287 - Can't save changes to interface with type MAP in LuCI User who did this - RemiNV (RemiNV) ---------- Proposed patches in: https://github.com/openwrt/openwrt/pull/3314 and: https://github.com/openwrt/luci/commit/9282df68942d104f56d7e440293783413f0a7cf9 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3287#comment8667 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 16 02:21:25 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 16 Aug 2020 06:21:25 +0000 Subject: [FS#3288] rockchip: FriendlyARM NanoPi R2S Kernel Crash In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - rts (rts) Attached to Project - OpenWrt/LEDE Project Summary - rockchip: FriendlyARM NanoPi R2S Kernel Crash Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.292714] ------------[ cut here ]------------ Fri Aug 14 21:56:19 2020 kern.info kernel: [187716.293203] NETDEV WATCHDOG: eth1 (r8152): transmit queue 0 timed out Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.293915] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:448 dev_watchdog+0x2f4/0x300 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.294655] Modules linked in: xt_connlimit pppoe ppp_async nf_conncount iptable_nat xt_state xt_nat xt_helper xt_conntrack xt_connmark xt_connbytes xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack_rtcache nf_conntrack_netlink nf_conntrack ipt_REJECT xt_time xt_tcpudp xt_tcpmss xt_statistic xt_recent xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_ecn xt_dscp xt_comment xt_TCPMSS xt_LOG xt_HL xt_DSCP xt_CLASSIFY wireguard usbnet slhc sch_cake r8152 nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 macvlan iptable_raw iptable_mangle iptable_filter ipt_ECN ip_tables fou crc_ccitt arptable_filter arpt_mangle arp_tables sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.294941] ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ip_gre gre ifb l2tp_eth sit l2tp_netlink l2tp_core udp_tunnel ip6_udp_tunnel xfrm4_tunnel ipcomp esp4 ah4 ipip tunnel4 ip_tunnel tun xfrm_user xfrm_ipcomp af_key xfrm_algo sha1_generic md5 hmac echainiv des_generic libdes deflate cbc authenc crypto_acompress gpio_button_hotplug Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.306829] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.4.52 #0 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.307365] Hardware name: FriendlyARM NanoPi R2S (DT) Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.307838] pstate: 20000005 (nzCv daif -PAN -UAO) Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.308282] pc : dev_watchdog+0x2f4/0x300 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.308652] lr : dev_watchdog+0x2f4/0x300 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.309024] sp : ffff800010013da0 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.309332] x29: ffff800010013da0 x28: ffff00003cd2aa80 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.309818] x27: 0000000000000004 x26: 0000000000000140 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.310305] x25: 00000000ffffffff x24: 0000000000000002 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.310793] x23: ffff00003c05b45c x22: ffff00003c05b000 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.311281] x21: ffff00003c05b480 x20: ffff800010bf6000 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.311765] x19: 0000000000000000 x18: 0000000000000000 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.312249] x17: 0000000000000000 x16: 0000000000000000 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.312733] x15: 0000000000000000 x14: ffff800010c85fc2 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.313221] x13: 0000000000000000 x12: ffff800010c85000 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.313709] x11: ffff800010c0a000 x10: 0000000000000010 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.314195] x9 : 0000000000000000 x8 : 756575712074696d Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.314682] x7 : 736e617274203a29 x6 : ffff00003f59f710 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.315168] x5 : ffff00003f59f710 x4 : 0000000000000004 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.315652] x3 : 0000000000000000 x2 : 0000000000000004 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.316137] x1 : ffff00003d8d9780 x0 : 0000000000000039 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.316628] Call trace: Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.316869] dev_watchdog+0x2f4/0x300 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.317215] call_timer_fn.isra.35+0x20/0x78 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.317610] run_timer_softirq+0x378/0x388 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.317992] __do_softirq+0x124/0x240 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.318336] irq_exit+0xb8/0xc8 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.318635] __handle_domain_irq+0x64/0xb8 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.319012] gic_handle_irq+0x50/0xa0 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.319355] el1_irq+0xb8/0x180 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.319655] arch_cpu_idle+0x10/0x18 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.319991] do_idle+0x214/0x218 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.320296] cpu_startup_entry+0x20/0x40 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.320666] secondary_start_kernel+0x164/0x178 Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.321085] ---[ end trace ce8469331d000ac7 ]--- Fri Aug 14 21:56:19 2020 kern.warn kernel: [187716.321668] r8152 4-1:1.0 eth1: Tx timeout Fri Aug 14 21:56:21 2020 kern.warn kernel: [187718.373248] r8152 4-1:1.0 eth1: Tx status -2 Fri Aug 14 21:56:21 2020 kern.warn kernel: [187718.374175] r8152 4-1:1.0 eth1: Tx status -2 Fri Aug 14 21:56:21 2020 kern.warn kernel: [187718.374767] r8152 4-1:1.0 eth1: Tx status -2 Fri Aug 14 21:56:21 2020 kern.warn kernel: [187718.376062] r8152 4-1:1.0 eth1: Tx status -2 Fri Aug 14 21:56:21 2020 kern.info kernel: [187718.941274] usb 4-1: reset SuperSpeed Gen 1 USB device number 2 using xhci-hcd More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3288 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 16 08:12:41 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 16 Aug 2020 12:12:41 +0000 Subject: [FS#3260] reduced upload speeds with enabled LAN 'flow control rx/tx' In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3260 - reduced upload speeds with enabled LAN 'flow control rx/tx' User who did this - Andy Walsh (Andy2244) ---------- seems fixed in latest master kernel 5.4.57 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3260#comment8668 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 16 17:36:34 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 16 Aug 2020 21:36:34 +0000 Subject: [FS#2455] Compile Error on Arch Linux with gcc 9.2 selected toolchain In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2455 - Compile Error on Arch Linux with gcc 9.2 selected toolchain User who did this - jacob (janeman) ---------- Awesome ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2455#comment8669 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 16 23:47:46 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 17 Aug 2020 03:47:46 +0000 Subject: [FS#3289] MT6720a Slowness in 2.4Ghz band (Attachment added) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - ajaikumarnadar (ajaikumarnadar) Attached to Project - OpenWrt/LEDE Project Summary - MT6720a Slowness in 2.4Ghz band Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Very Low Reported Version - All Due in Version - Undecided Due Date - Undecided Details - Device: MI R3 https://openwrt.org/toh/xiaomi/mir3 I am using a Openwrt fork, X-WRT in my MI R3. Whenever i use 2.4Ghz band connection, I am getting really slow speeds... I.e if i have bandwidth of 10 mbps upload and download speed then i am only half the speed. However, I have fixed the download speed by changing the 2.4ghz channel to 13 but still there are some packet losses which can be seen and still the upload speed doesn't cross 5mbps... I have attached speedtest screenshot for your reference. This speedtest has been done while no one was using my bandwidth and that too in the morning. One or more files have been attached. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3289 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 17 04:03:07 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 17 Aug 2020 08:03:07 +0000 Subject: [FS#2330] Samba - smb.conf templating allows arbitrary injections of samba configurations In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2330 - Samba - smb.conf templating allows arbitrary injections of samba configurations User who did this - telia (telia) ---------- Real world privilege escalation exploit for Technicolor routers, based on OpenWrt Chaos Calmer 15.05.1 https://github.com/full-disclosure/FDEU-CVE-2020-1FC5 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2330#comment8670 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 17 04:08:38 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 17 Aug 2020 08:08:38 +0000 Subject: [FS#2330] Samba - smb.conf templating allows arbitrary injections of samba configurations In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2330 - Samba - smb.conf templating allows arbitrary injections of samba configurations User who did this - telia (telia) ---------- Vulnerable code is: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/services/samba36/files/samba.init;h=1c5bb3b3c43eacc6ee3a181a16b63c906365b81b;hb=refs/heads/openwrt-18.06#l32 32 sed -e "s#|NAME|#$name#g" \ 33 -e "s#|WORKGROUP|#$workgroup#g" \ 34 -e "s#|DESCRIPTION|#$description#g" \ 35 -e "s#|INTERFACES|#$interfaces#g" \ 36 -e "s#|CHARSET|#$charset#g" \ 37 /etc/samba/smb.conf.template > /var/etc/smb.conf Any variables passed into sed like $name, $workgroup and others must be sanitized and all control symbols such "#" replaced or properly escaped ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2330#comment8671 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 17 14:17:15 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 17 Aug 2020 18:17:15 +0000 Subject: [FS#3290] hostapd always sets ap_isolate to 1 no matter what the wireless config is set to In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - PhobosK (PhobosK) Attached to Project - OpenWrt/LEDE Project Summary - hostapd always sets ap_isolate to 1 no matter what the wireless config is set to Task Type - Bug Report Category - Packages Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - openwrt-19.07 Due in Version - Undecided Due Date - Undecided Details - I have two devices that show the same problem - both TP-Link, but different models. The problem is that the devices/clients connected to any of the wlans are always isolated no matter what the config "isolate clients" is set to. These devices cannot ping and see each other but they can be pinged and they can ping devices from/to devices in lan. Further more the generated **/var/run/hostapd-phy0.conf** and **/var/run/hostapd-phy1.conf** always have the //**ap_isolate=1**// The tested devices are: root at OpenWrt:~# ubus call system board { "kernel": "4.14.180", "hostname": "OpenWrt", "system": "Qualcomm Atheros QCA9558 ver 1 rev 0", "model": "TP-Link Archer C7 v2", "board_name": "tplink,archer-c7-v2", "release": { "distribution": "OpenWrt", "version": "19.07.3", "revision": "r11063-85e04e9f46", "target": "ath79/generic", "description": "OpenWrt 19.07.3 r11063-85e04e9f46" } } root at OpenWrt:~# ubus call system board { "kernel": "4.14.180", "hostname": "OpenWrt", "system": "Atheros AR9344 rev 2", "model": "TP-Link TL-WDR4300 v1", "board_name": "tplink,tl-wdr4300-v1", "release": { "distribution": "OpenWrt", "version": "19.07.3", "revision": "r11063-85e04e9f46", "target": "ath79/generic", "description": "OpenWrt 19.07.3 r11063-85e04e9f46" } } No packages have been updated manually on both devices. Both devices has defaults sets coming with the default factory OpenWrt 19.07.3 image. Both devices were set for their //Network -> Wireless -> wlan0 (and wlan1) -> Interface configuration -> Advanced settings -> Isolate clients// **//UNCHECKED//** Here is the config of one of the devices (///etc/config/wireless//) and the respective generated ///var/run/hostapd-phy0.conf// config wifi-device 'radio0' option type 'mac80211' option hwmode '11g' option path 'platform/ahb/18100000.wmac' option channel 'auto' option country 'BG' option htmode 'HT20' config wifi-iface 'default_radio0' option device 'radio0' option network 'lan' option mode 'ap' option key 'XXXXXX' option ssid 'YYYYYYYY' option encryption 'psk2' Even when option isolate '0' is added manually using uci not luci, and restarting the device the respective hostapd-phy0.conf remains with **ap_isolate=1** driver=nl80211 logger_syslog=127 logger_syslog_level=2 logger_stdout=127 logger_stdout_level=2 country_code=BG ieee80211d=1 hw_mode=g beacon_int=100 channel=acs_survey ieee80211n=1 ht_coex=0 ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40] interface=wlan0 ctrl_interface=/var/run/hostapd ap_isolate=1 bss_load_update_period=60 chan_util_avg_period=600 disassoc_low_ack=1 preamble=1 wmm_enabled=1 ignore_broadcast_ssid=0 uapsd_advertisement_enabled=1 utf8_ssid=1 multi_ap=0 wpa_passphrase=XXXXXX auth_algs=1 wpa=2 wpa_pairwise=CCMP ssid=YYYYYYYY bridge=br-lan wpa_disable_eapol_key_retries=0 wpa_key_mgmt=WPA-PSK okc=0 disable_pmksa_caching=1 bssid=xx:xx:xx:xx:xx:xx My guess is that hostapd/wpad doesn't set properly the ap_isolate according to the config. Please let me know if you need further info. Thanks More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3290 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 17 23:46:24 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 18 Aug 2020 03:46:24 +0000 Subject: [FS#3291] procd gives warning when called outside an init script In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - aaronjg (aaronjg) Attached to Project - OpenWrt/LEDE Project Summary - procd gives warning when called outside an init script Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - The documentation here: https://openwrt.org/docs/guide-developer/procd-init-scripts suggests that you can use procd outside of init scripts.: >>> Note You can also send signals to named procd services from outside initscripts. Simply load the procd functions and send the signal as before. >>> #!/bin/sh . /lib/functions/procd.sh procd_send_signal service_name [instance_name] [signal] However, when you import the procd like this, the script shows an error when it calls 'basename' trying to obtain the procd lock. # cat /tmp/test.sh #!/bin/sh set -x . /lib/functions/procd.sh # /tmp/test.sh 2>&1|grep basename -C2 + readlink + local 'basescript=' + basename BusyBox v1.30.1 () multi-call binary. Usage: basename FILE [SUFFIX] Strip directory path and .SUFFIX from FILE ` Either procd.sh should be updated so that it can be called outside of init scripts without printing warnings, or the documentation should be updated to reflect that procd should not be called outside init scripts. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3291 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 18 12:38:06 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 18 Aug 2020 16:38:06 +0000 Subject: [FS#3292] How to download Alexa app In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3292 - How to download Alexa app User who did this - Adrian Schmutzler (adrianschmutzler) Reason for closing: Invalid report Additional comments about closing: Spam. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3292 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 18 13:04:48 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 18 Aug 2020 17:04:48 +0000 Subject: [FS#3269] Compiling the kernel requires entering the CGROUP_HUGETLB option. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3269 - Compiling the kernel requires entering the CGROUP_HUGETLB option. User who did this - Ted Hess (thess) Reason for closing: Fixed More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3269 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 18 13:04:58 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 18 Aug 2020 17:04:58 +0000 Subject: [FS#3260] reduced upload speeds with enabled LAN 'flow control rx/tx' In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3260 - reduced upload speeds with enabled LAN 'flow control rx/tx' User who did this - Ted Hess (thess) Reason for closing: Fixed More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3260 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 18 13:47:13 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 18 Aug 2020 17:47:13 +0000 Subject: [FS#3218] hostapd log_level ingored In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3218 - hostapd log_level ingored User who did this - coelner (coelner) ---------- thanks for the hint with the hostapd_cli and for confirming the bug ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3218#comment8672 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 18 14:02:44 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 18 Aug 2020 18:02:44 +0000 Subject: [FS#2537] Ath9k on Archer C7 v2: disassociated due to inactivity In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2537 - Ath9k on Archer C7 v2: disassociated due to inactivity User who did this - coelner (coelner) ---------- I confirm this too. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2537#comment8673 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 18 14:06:53 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 18 Aug 2020 18:06:53 +0000 Subject: [FS#3293] ath10k_pci firmware crash on openwrt-19.07 branch (git-20.221.53167-304ad04) (Attachment added) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Tomas Gayoso (real-t0mg) Attached to Project - OpenWrt/LEDE Project Summary - ath10k_pci firmware crash on openwrt-19.07 branch (git-20.221.53167-304ad04) Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Running OpenWRT 19.07 on TP-LINK Archer C7 v5 with Candela Technologies firmware ath10k-firmware-qca988x-ct - 2019-10-03-d622d160-1 causes AP to crash, stalling all connections. This is specially troublesome using a Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac PCIe Wireless Network Adapter as client (as per this bug report I filed here: [[https://github.com/rtlwifi-linux/rtk_wifi_driver_rtl8822ce/issues/3|External Link]] ). Please refer to attached dmesg buffer. Let me know what additional info I may provide for completeness. I'm willing to test and can compile OpenWRT from scracth. One or more files have been attached. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3293 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 18 18:22:29 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 18 Aug 2020 22:22:29 +0000 Subject: [FS#3293] ath10k_pci firmware crash on openwrt-19.07 branch (git-20.221.53167-304ad04) (Attachment added) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3293 - ath10k_pci firmware crash on openwrt-19.07 branch (git-20.221.53167-304ad04) User who did this - Tomas Gayoso (real-t0mg) ---------- Just did a fresh rebuild and reboot and it the ath10k_CT crashed after 3 minutes while loading the wifi link with a 200 mbit download from a LAN webserver. Appendi dmesg output to see if it helps. ---------- One or more files have been attached. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3293#comment8674 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 19 16:12:02 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 19 Aug 2020 20:12:02 +0000 Subject: [FS#3294] CPE510/520 sysupgrade-image on server/website seems to be incorrect/not functional In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Hartmut Wahl (frufo) Attached to Project - OpenWrt/LEDE Project Summary - CPE510/520 sysupgrade-image on server/website seems to be incorrect/not functional Task Type - Bug Report Category - Website Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - openwrt-19.07 Due in Version - Undecided Due Date - Undecided Details - Dear openwrt Team, I am unsure whether it is a bug in the web managment or in the base/build system/buils management. However, while the linked factory images for the cpe510/520 device on the device website: https://openwrt.org/toh/tp-link/cpe510 seem to be valid images (size 4MB), there seems to be something wrong with the linked sysupgrade images, e.g: http://downloads.openwrt.org/releases/19.07.3/targets/ar71xx/generic/openwrt-19.07.3-ar71xx-generic-cpe510-520-v1-squashfs-sysupgrade.bin they are almost 8MB in size and seem to be rather ELF-binaries than flash-images or am I mistaken? Flashing in my case from: LEDE Reboot 17.01.4 consequently fails with the error message: The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. I did not dare to try the factory-image instead as according to posts in the forum this is not advisable (risk of bricking the device). Thank you very much Frufo More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3294 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 19 17:24:02 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 19 Aug 2020 21:24:02 +0000 Subject: [FS#3294] CPE510/520 sysupgrade-image on server/website seems to be incorrect/not functional In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3294 - CPE510/520 sysupgrade-image on server/website seems to be incorrect/not functional User who did this - Matthias Schiffer (NeoRaider) ---------- Unlike the factory image, the sysupgrade image is a raw flash image. It starts with the kernel, which happens to be in ELF format on this platform. The size difference between the images is also expected. We had to change the flash layout for CPE210/CPE510/... with OpenWrt 18.06.0, requiring some adjustments to the sysupgrade code that checks image validity as well. The validation code update was backported to LEDE 17.01.5. You have two options for the update: 1. First upgrade to 17.01.5, then to a newer OpenWrt release 2. Use sysugrade -F to skip the validation (somewhat more dangerous) In both cases, the sysupgrade image is the correct one - the factory image has different format that is only understood by TP-Link's stock firmware. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3294#comment8675 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 19 17:24:50 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Wed, 19 Aug 2020 21:24:50 +0000 Subject: [FS#3294] CPE510/520 sysupgrade-image on server/website seems to be incorrect/not functional In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3294 - CPE510/520 sysupgrade-image on server/website seems to be incorrect/not functional User who did this - Matthias Schiffer (NeoRaider) Reason for closing: Not a bug More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3294 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Wed Aug 19 20:45:03 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 20 Aug 2020 00:45:03 +0000 Subject: [FS#3295] Adresses not configured on interface but visible via ubus In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Leon George (yogo1212) Attached to Project - OpenWrt/LEDE Project Summary - Adresses not configured on interface but visible via ubus Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - On an ipq40xx/compex-wpj428, sometimes the addresses aren't configured on the wan bridge. netifd shows that it knows about addresses that should be configured but they aren't. "ip l set br-wan down" + up didn't change that. "ubus call network.interface.wan down" + up however, did lead to a change. $ ip a show br-wan 6: br-wan: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 04:f0:21:4e:21:05 brd ff:ff:ff:ff:ff:ff inet6 fe80::6f0:21ff:fe4e:2105/64 scope link valid_lft forever preferred_lft forever $ ubus call network.interface.wan status {} { "up": true, "pending": false, "available": true, "autostart": true, "dynamic": false, "uptime": 91629, "l3_device": "br-wan", "proto": "dhcp", "device": "br-wan", "ip4table": 1, "ip6table": 1, "metric": 0, "dns_metric": 0, "delegation": true, "ipv4-address": [ { "address": "192.168.0.34", "mask": 24 } ], "ipv6-address": [ ], "ipv6-prefix": [ ], "ipv6-prefix-assignment": [ ], "route": [ { "target": "0.0.0.0", "mask": 0, "nexthop": "192.168.0.1", "source": "192.168.0.34/32" } ], "dns-server": [ "192.168.0.1", "192.168.0.1" ], "dns-search": [ ], "neighbors": [ ], "inactive": { "ipv4-address": [ ], "ipv6-address": [ ], "route": [ ], "dns-server": [ ], "dns-search": [ ], "neighbors": [ ] }, "data": { "hostname": "test", "leasetime": 3600, "ntpserver": "212.6.108.160" } } More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3295 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 20 06:59:53 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 20 Aug 2020 10:59:53 +0000 Subject: [FS#2790] Router LEDs on Asus RT-N11P not work properly In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2790 - Router LEDs on Asus RT-N11P not work properly User who did this - Anton (Shazam007) ---------- This is a common problem if the firmware for your router is based on the firmware for another router. This is definitely a problem in GPIOs. just need to calibrate them for RT-N11P. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2790#comment8676 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 20 08:26:36 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 20 Aug 2020 12:26:36 +0000 Subject: [FS#3295] Adresses not configured on interface but visible via ubus In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3295 - Adresses not configured on interface but visible via ubus User who did this - Baptiste Jonglez (bjonglez) ---------- Possibly something else is messing with the interfaces? Do you have anything in /etc/rc.local or specific packages like mwan3? Which exact version of OpenWrt are you running, and can you reproduce in trunk / 19.07? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3295#comment8677 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 20 09:37:25 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 20 Aug 2020 13:37:25 +0000 Subject: [FS#3296] TP-Link RE450 v3: QCA9880 (5 GHz-Wifi) is only detected sporadically In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Alfred Reichenberger (Alfredoredo) Attached to Project - OpenWrt/LEDE Project Summary - TP-Link RE450 v3: QCA9880 (5 GHz-Wifi) is only detected sporadically Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - - Device: TP-Link RE450 v3 - OpenWRT-version: OpenWRT SNAPSHOT r14198-da98603597 (snapshot from 8/19/2020) - Installed packages: Just the base install + LuCI - Steps to reproduce: * Install OpenWRT via stock firmware web interface * 'iw list' shows 2 physical interfaces: 2.4 GHz (phy1) and 5 GHz (phy0) * Reboot * 'iw list' now only shows the 2.4 GHz-wifi * 5 GHz-wifi is only redetected after power-cycling, simple reboot doesn't work - Logs: * dmesg with both interfaces: [ 0.000000] Linux version 5.4.58 (builder at buildhost) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r14198-da98603597)) #0 Tue Aug 18 16:14:54 2020 [ 0.000000] printk: bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 00019750 (MIPS 74Kc) [ 0.000000] MIPS: machine is TP-Link RE450 v3 [ 0.000000] SoC: Qualcomm Atheros QCA956X ver 1 rev 0 [ 0.000000] Initrd not found or empty - disabling initrd [ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x0000000003ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000003ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000003ffffff] [ 0.000000] On node 0 totalpages: 16384 [ 0.000000] Normal zone: 144 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 16384 pages, LIFO batch:3 [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16240 [ 0.000000] Kernel command line: console=ttyS0,115200n8 rootfstype=squashfs,jffs2 [ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes, linear) [ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes, linear) [ 0.000000] Writing ErrCtl register=00000000 [ 0.000000] Readback ErrCtl register=00000000 [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Memory: 56888K/65536K available (5134K kernel code, 190K rwdata, 1176K rodata, 1236K init, 205K bss, 8648K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS: 51 [ 0.000000] random: get_random_bytes called from start_kernel+0x32c/0x520 with crng_init=0 [ 0.000000] CPU clock: 775.000 MHz [ 0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 4932285024 ns [ 0.000007] sched_clock: 32 bits at 387MHz, resolution 2ns, wraps every 5541893118ns [ 0.008231] Calibrating delay loop... 385.02 BogoMIPS (lpj=770048) [ 0.046722] pid_max: default: 32768 minimum: 301 [ 0.051722] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.059438] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.071600] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns [ 0.081924] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [ 0.089218] pinctrl core: initialized pinctrl subsystem [ 0.097103] NET: Registered protocol family 16 [ 0.131044] clocksource: Switched to clocksource MIPS [ 0.137499] NET: Registered protocol family 2 [ 0.142953] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes, linear) [ 0.151841] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.159940] TCP bind hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.167381] TCP: Hash tables configured (established 1024 bind 1024) [ 0.174204] UDP hash table entries: 256 (order: 0, 4096 bytes, linear) [ 0.181148] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) [ 0.188827] NET: Registered protocol family 1 [ 0.193482] PCI: CLS 0 bytes, default 32 [ 0.201049] workingset: timestamp_bits=14 max_order=14 bucket_order=0 [ 0.214066] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.220256] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [ 0.243018] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) [ 0.254285] pinctrl-single 1804002c.pinmux: 544 pins, size 68 [ 0.261343] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled [ 0.270150] printk: console [ttyS0] disabled [ 0.274741] 18020000.uart: ttyS0 at MMIO 0x18020000 (irq = 9, base_baud = 1562500) is a 16550A [ 0.283847] printk: console [ttyS0] enabled [ 0.292909] printk: bootconsole [early0] disabled [ 0.320880] spi-nor spi0.0: s25fl064k (8192 Kbytes) [ 0.325996] 7 fixed-partitions partitions found on MTD device spi0.0 [ 0.332567] Creating 7 MTD partitions on "spi0.0": [ 0.337536] 0x000000000000-0x000000020000 : "u-boot" [ 0.343635] 0x000000020000-0x000000022000 : "info" [ 0.349457] 0x000000022000-0x000000024000 : "partition-table" [ 0.356285] 0x000000024000-0x00000002e000 : "info2" [ 0.362222] 0x00000002e000-0x000000050000 : "config" [ 0.368262] 0x000000050000-0x0000007f0000 : "firmware" [ 0.379175] 2 tplink-fw partitions found on MTD device firmware [ 0.385326] Creating 2 MTD partitions on "firmware": [ 0.390466] 0x000000000000-0x000000209c24 : "kernel" [ 0.396459] 0x000000209c24-0x0000007a0000 : "rootfs" [ 0.402434] mtd: device 7 (rootfs) set to be root filesystem [ 0.409991] 1 squashfs-split partitions found on MTD device rootfs [ 0.416454] 0x000000490000-0x0000007a0000 : "rootfs_data" [ 0.422923] 0x0000007f0000-0x000000800000 : "art" [ 0.429578] libphy: GPIO Bitbanged MDIO: probed [ 0.439954] libphy: Fixed MDIO Bus: probed [ 0.772835] ag71xx 19000000.eth: connected to PHY at gpio-0:04 [uid=004dd074, driver=Atheros 8031 ethernet] [ 0.783492] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: sgmii [ 0.790217] i2c /dev entries driver [ 0.796315] NET: Registered protocol family 10 [ 0.806499] Segment Routing with IPv6 [ 0.810436] NET: Registered protocol family 17 [ 0.815112] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. [ 0.828504] 8021q: 802.1Q VLAN Support v1.8 [ 0.833637] PCI host bridge /ahb/pcie-controller at 18250000 ranges: [ 0.840001] MEM 0x0000000012000000..0x0000000013ffffff [ 0.845403] IO 0x0000000000000000..0x0000000000000000 [ 0.850951] PCI host bridge to bus 0000:00 [ 0.855222] pci_bus 0000:00: root bus resource [mem 0x12000000-0x13ffffff] [ 0.862326] pci_bus 0000:00: root bus resource [io 0x0000] [ 0.868086] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] [ 0.875103] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] [ 0.883320] pci 0000:00:00.0: [168c:003c] type 00 class 0x028000 [ 0.889579] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x001fffff 64bit] [ 0.896644] pci 0000:00:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref] [ 0.903638] pci 0000:00:00.0: supports D1 D2 [ 0.909008] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00 [ 0.915890] pci 0000:00:00.0: BAR 0: assigned [mem 0x12000000-0x121fffff 64bit] [ 0.923468] pci 0000:00:00.0: BAR 6: assigned [mem 0x12200000-0x1220ffff pref] [ 0.931847] hctosys: unable to open rtc device (rtc0) [ 0.941503] VFS: Mounted root (squashfs filesystem) readonly on device 31:7. [ 0.955778] Freeing unused kernel memory: 1236K [ 0.960477] This architecture does not have kernel memory protection. [ 0.967127] Run /sbin/init as init process [ 1.199054] random: fast init done [ 1.566294] init: Console is alive [ 1.570122] init: - watchdog - [ 2.588796] kmodloader: loading kernel modules from /etc/modules-boot.d/* [ 2.798646] kmodloader: done loading kernel modules from /etc/modules-boot.d/* [ 2.816569] init: - preinit - [ 3.672705] random: jshn: uninitialized urandom read (4 bytes read) [ 3.775161] random: jshn: uninitialized urandom read (4 bytes read) [ 3.821070] random: jshn: uninitialized urandom read (4 bytes read) [ 8.283883] jffs2: notice: (549) jffs2_build_xattr_subsystem: complete building xattr subsystem, 37 of xdatum (29 unchecked, 6 orphan) and 54 of xref (6 dead, 0 orphan) found. [ 8.303296] mount_root: switching to jffs2 overlay [ 8.327567] overlayfs: upper fs does not support tmpfile. [ 8.342994] urandom-seed: Seeding with /etc/urandom.seed [ 8.432323] procd: - early - [ 8.435456] procd: - watchdog - [ 9.067071] procd: - watchdog - [ 9.070585] procd: - ubus - [ 9.152818] urandom_read: 5 callbacks suppressed [ 9.152825] random: ubusd: uninitialized urandom read (4 bytes read) [ 9.230475] random: ubusd: uninitialized urandom read (4 bytes read) [ 9.238452] procd: - init - [ 10.042593] kmodloader: loading kernel modules from /etc/modules.d/* [ 10.300426] Loading modules backported from Linux version v5.8-0-gbcf876870b95 [ 10.307932] Backport generated by backports.git v5.8-1-0-g79400d9e [ 10.367861] xt_time: kernel timezone is -0000 [ 10.384141] urngd: v1.0.2 started. [ 10.549643] PPP generic driver version 2.4.2 [ 10.563949] NET: Registered protocol family 24 [ 10.642376] ath10k 5.4 driver, optimized for CT firmware, probing pci device: 0x3c. [ 10.650448] ath10k_mac_create, priv_size: 804 hw: (ptrval) hw->priv: (ptrval) [ 10.680568] random: crng init done [ 10.685632] ath10k_pci 0000:00:00.0: enabling device (0000 -> 0002) [ 10.692309] ath10k_pci 0000:00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0 reset_mode 0 [ 14.049037] ath10k_pci 0000:00:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043202ff sub 0000:0000 [ 14.058609] ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1 testmode 0 [ 14.071077] ath10k_pci 0000:00:00.0: firmware ver 10.1-ct-8x-__fW-022-538f0906 api 2 features wmi-10.x,has-wmi-mgmt-tx,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 e1c91a74 [ 14.309918] ath10k_pci 0000:00:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 15.285846] ath10k_pci 0000:00:00.0: unsupported HTC service id: 1536 [ 15.292959] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [ 15.309879] ath10k_pci 0000:00:00.0: wmi print 'P 128 V 8 T 410' [ 15.316163] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0' [ 15.324452] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 20984 iram: 25656' [ 15.386995] ath10k_pci 0000:00:00.0: htt-ver 2.1 wmi-op 2 htt-op 2 cal file max-sta 128 raw 0 hwcrypto 1 [ 15.397150] ath10k_pci 0000:00:00.0: NOTE: Firmware DBGLOG output disabled in debug_mask: 0x10000000 [ 15.504539] ath: EEPROM regdomain sanitized [ 15.504549] ath: EEPROM regdomain: 0x64 [ 15.504552] ath: EEPROM indicates we should expect a direct regpair map [ 15.504570] ath: Country alpha2 being used: 00 [ 15.504573] ath: Regpair used: 0x64 [ 15.585882] ath: EEPROM regdomain sanitized [ 15.585893] ath: EEPROM regdomain: 0x64 [ 15.585897] ath: EEPROM indicates we should expect a direct regpair map [ 15.585916] ath: Country alpha2 being used: 00 [ 15.585919] ath: Regpair used: 0x64 [ 15.598233] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [ 15.600158] ieee80211 phy1: Atheros AR9561 Rev:0 mem=0xb8100000, irq=2 [ 15.627498] kmodloader: done loading kernel modules from /etc/modules.d/* [ 26.247323] br-lan: port 1(eth0) entered blocking state [ 26.252771] br-lan: port 1(eth0) entered disabled state [ 26.258462] device eth0 entered promiscuous mode [ 30.947562] ath10k_pci 0000:00:00.0: unsupported HTC service id: 1536 [ 30.954344] ath10k_pci 0000:00:00.0: 10.1 wmi init: vdevs: 16 peers: 127 tid: 256 [ 30.971271] ath10k_pci 0000:00:00.0: wmi print 'P 128 V 8 T 410' [ 30.977555] ath10k_pci 0000:00:00.0: wmi print 'msdu-desc: 1424 sw-crypt: 0 ct-sta: 0' [ 30.985854] ath10k_pci 0000:00:00.0: wmi print 'alloc rem: 20984 iram: 25656' [ 31.048771] ath10k_pci 0000:00:00.0: pdev param 0 not supported by firmware [ 31.079988] br-lan: port 2(wlan0) entered blocking state [ 31.085532] br-lan: port 2(wlan0) entered disabled state [ 31.091324] device wlan0 entered promiscuous mode [ 31.211412] br-lan: port 3(wlan1-1) entered blocking state [ 31.217133] br-lan: port 3(wlan1-1) entered disabled state [ 31.223228] device wlan1-1 entered promiscuous mode [ 31.228434] br-lan: port 3(wlan1-1) entered blocking state [ 31.234131] br-lan: port 3(wlan1-1) entered forwarding state [ 31.241283] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready [ 31.347526] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 31.354300] br-lan: port 2(wlan0) entered blocking state [ 31.359835] br-lan: port 2(wlan0) entered forwarding state [ 32.095174] br-lan: port 3(wlan1-1) entered disabled state [ 34.157207] wlan1: authenticate with c8:0e:14:fc:02:ed [ 34.176691] wlan1: send auth to c8:0e:14:fc:02:ed (try 1/3) [ 34.185984] wlan1: authenticated [ 34.191228] wlan1: associate with c8:0e:14:fc:02:ed (try 1/3) [ 34.203447] wlan1: RX AssocResp from c8:0e:14:fc:02:ed (capab=0x31 status=0 aid=6) [ 34.211556] wlan1: associated [ 34.226587] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready [ 34.245010] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1-1: link becomes ready [ 34.252015] br-lan: port 3(wlan1-1) entered blocking state [ 34.257731] br-lan: port 3(wlan1-1) entered forwarding state * iw list of both interfaces: Wiphy phy1 max # scan SSIDs: 4 max scan IEs length: 2257 bytes max # sched scan SSIDs: 0 max # match sets: 0 max # scan plans: 1 max scan plan interval: -1 max scan plan iterations: 0 Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Device supports AP-side u-APSD. Device supports T-DLS. Available Antennas: TX 0x7 RX 0x7 Configured Antennas: TX 0x7 RX 0x7 Supported interface modes: * IBSS * managed * AP * AP/VLAN * monitor * mesh point * P2P-client * P2P-GO * outside context of a BSS Band 1: Capabilities: 0x11ee HT20/HT40 SM Power Save disabled RX HT20 SGI RX HT40 SGI TX STBC RX STBC 1-stream Max AMSDU length: 3839 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 8 usec (0x06) HT TX/RX MCS rate indexes supported: 0-23 Frequencies: * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) (no IR) * 2472 MHz [13] (20.0 dBm) (no IR) * 2484 MHz [14] (20.0 dBm) (no IR) valid interface combinations: * #{ managed } From openwrt-bugs at lists.openwrt.org Thu Aug 20 15:15:32 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 20 Aug 2020 19:15:32 +0000 Subject: [FS#3297] DNSSEC + dnsmasq broken on trunk In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - pmgp (mgondium) Attached to Project - OpenWrt/LEDE Project Summary - DNSSEC + dnsmasq broken on trunk Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - High Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Commit https://github.com/openwrt/openwrt/commit/064dc1e81bc85f6ef8becc38854292853a59d2c2 breaks dnssec on dnsmasq, including the ntp fix. git revert 064dc1e81bc85f6ef8becc38854292853a59d2c2 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3297 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 21 04:12:40 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 21 Aug 2020 08:12:40 +0000 Subject: [FS#3298] Edimax 3G-6200n z OpenWrt 19.07.2 lost settings after reboot or turnoff. It don't create JFFS In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - olekstomek (olekstomek) Attached to Project - OpenWrt/LEDE Project Summary - Edimax 3G-6200n z OpenWrt 19.07.2 lost settings after reboot or turnoff. It don't create JFFS Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Critical Priority - Very Low Reported Version - openwrt-19.07 Due in Version - Undecided Due Date - Undecided Details - [[https://openwrt.org/toh/hwdata/edimax/edimax_3g-6200n|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 at 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 at 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 at 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 at OpenWrt:~# free total used free shared buff/cache available Mem: 28276 15632 3496 368 9148 10236 Swap: 0 0 0 root at OpenWrt:~# More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3298 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 21 06:07:51 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 21 Aug 2020 10:07:51 +0000 Subject: [FS#3216] Enable by default ed25519 on dropbear In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3216 - Enable by default ed25519 on dropbear User who did this - rugk (rugk) ---------- I agree, please enable it. (Is there some feature to vote here??) It has also been discussed in the forum: https://forum.openwrt.org/t/dropbear-and-ed25519-keys/23539/6?u=rugk ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3216#comment8678 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 21 06:14:16 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 21 Aug 2020 10:14:16 +0000 Subject: [FS#3241] temporary flash failure on ipq40xx device (wpj428) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3241 - temporary flash failure on ipq40xx device (wpj428) User who did this - Leon George (yogo1212) ---------- Compiled another firmware. Same error, different block: Fri Aug 21 08:33:23 2020 daemon.err node-comm[4034]: Error loading shared library libevmqtt.so: I/O error (needed by /usr/bin/node-comm-mqtt) Fri Aug 21 08:33:23 2020 kern.err kernel: [451294.748866] SQUASHFS error: Unable to read fragment cache entry [3edbca] Fri Aug 21 08:33:23 2020 kern.err kernel: [451294.755269] SQUASHFS error: Unable to read page, block 3edbca, size 1522c ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3241#comment8679 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 21 08:59:37 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 21 Aug 2020 14:59:37 +0200 Subject: [FS#3297] DNSSEC + dnsmasq broken on trunk In-Reply-To: References: Message-ID: > Op 20 aug. 2020, om 21:15 heeft OpenWrt Bugs het volgende geschreven: > > THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. > > A new Flyspray task has been opened. Details are below. > > User who did this - pmgp (mgondium) > > Attached to Project - OpenWrt/LEDE Project > Summary - DNSSEC + dnsmasq broken on trunk > Task Type - Bug Report > Category - Base system > Status - Unconfirmed > Assigned To - > Operating System - All > Severity - High > Priority - Very Low > Reported Version - Trunk > Due in Version - Undecided > Due Date - Undecided > Details - > Commit https://github.com/openwrt/openwrt/commit/064dc1e81bc85f6ef8becc38854292853a59d2c2 breaks dnssec on dnsmasq, including the ntp fix. It commit makes sure that the installed dnsmasq has support for DNSSEC compiled in when its runtime config requests that. Are you sure you're running dnsmasq with DNSSEC compiled in ? (sse with run: dnsmasq --version) > > > > git revert 064dc1e81bc85f6ef8becc38854292853a59d2c2 > > > > > More information can be found at the following URL: > https://bugs.openwrt.org/index.php?do=details&task_id=3297 > > You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. > > _______________________________________________ > openwrt-bugs mailing list > openwrt-bugs at lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-bugs From openwrt-bugs at lists.openwrt.org Fri Aug 21 10:00:02 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 21 Aug 2020 14:00:02 +0000 Subject: [FS#3226] GL-AR300M: Frequent WAN (eth1) link down / link up In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3226 - GL-AR300M: Frequent WAN (eth1) link down / link up User who did this - LinuxKernel1 (LinuxKernel1) ---------- Had the same problem on WA850RE & WA860RE (OpenWrt 19.07-SNAPSHOT, r11151-afaa978b74). git revert 3d93b35f03 --no-edit and git revert 443fc9ac35 --no-edit fixed the issue for me. The link problems were easy to reproduce...just had to generate some higher load (e.g. a download via wifi with about 50 Mbit/s). Any more information needed to solve this? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3226#comment8680 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 21 10:00:31 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 21 Aug 2020 14:00:31 +0000 Subject: [FS#2216] ath79 - eth0 Spasmodic Link Speed After Driver Changes? - 841NDv9 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2216 - ath79 - eth0 Spasmodic Link Speed After Driver Changes? - 841NDv9 User who did this - LinuxKernel1 (LinuxKernel1) ---------- Had the same problem on WA850RE & WA860RE (OpenWrt 19.07-SNAPSHOT, r11151-afaa978b74). git revert 3d93b35f03 --no-edit and git revert 443fc9ac35 --no-edit fixed the issue for me. The link problems were easy to reproduce...just had to generate some higher load (e.g. a download via wifi with about 50 Mbit/s). Any more information needed to solve this? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2216#comment8681 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 21 15:36:58 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 21 Aug 2020 19:36:58 +0000 Subject: [FS#3299] busybox: Alternatives gets overwrited when busybox updates In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - howl (howl) Attached to Project - OpenWrt/LEDE Project Summary - busybox: Alternatives gets overwrited when busybox updates Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Critical Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - This is device independent and I think it affects all versions but I have seen this over 19.07. If you have binary programs that conflicts with busybox ones, opkg sets them to be used instead when they are installed. I discovered this because mwan3 got broke and investigating the error it dropped the problems seems to be that the ip binary from busybox doesn't support some features mwan3 needs. I could find that I had ip installed as is a dependency of mwan3 so I just remembered that busybox was updated recently. Just by reinstalling ip the issue was solved. I don't know how this could be managed, perhaps just when a package that has alternatives is installed update them and when the package is being upgraded ignore updating the alternatives. I set this critical just because it could be very difficult to see where the problem is for many people (I surprised myself how it could take so many time to advert the real issue when I found it, it's simple, but if you don't notice busybox upgrading could be cumbersome to see), and, this could break things, like for example mwan3 or any other program that rely using alternative binaries and not the busybox ones. Of course fell free to set the severity you think could be more accurate. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3299 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 21 17:53:26 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 21 Aug 2020 21:53:26 +0000 Subject: [FS#3299] busybox: Alternatives gets overwrited when busybox updates In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3299 - busybox: Alternatives gets overwrited when busybox updates User who did this - Jo-Philipp Wich (jow-) ---------- Well either a package is an alternative for another or it is not. If mwan3 really needs functionality not provided by busybox IP, it should not depend on the abstract `ip` but on something like `ip-full` instead. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3299#comment8682 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 22 04:30:36 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 22 Aug 2020 08:30:36 +0000 Subject: [FS#2109] Asus RT-AC51U - LEDs not working at all In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2109 - Asus RT-AC51U - LEDs not working at all User who did this - darkpenguin (dark-penguin) ---------- The problem is that no LEDs other than "power" work. This includes USB, WiFi-2.4G, WiFi-5G, and even the port activity LEDs which I thought were managed automatically by the switch hardware?.. I can confirm this on 18.06.8 and 19.07.3 . In the PR that added support for this router ( https://github.com/openwrt/openwrt/pull/3017 ), there was some discussion about WiFi LEDs not working, but nothing about USB or port activity LEDs. There was a fix for 2.4 GHz WiFi LED, but it's not in 19.07.3: https://github.com/openwrt/openwrt/commit/a1f0fd8cba4d9233b76542fbf54be01e2cc9d5c0 In case you need more information/people, there are two discussions about this on the forum: https://forum.openwrt.org/t/asus-rt-ac51u-problem-with-leds/28549 https://forum.openwrt.org/t/router-leds-problem-on-asus-rt-ac51u/52770/11 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2109#comment8683 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 22 09:59:03 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 22 Aug 2020 13:59:03 +0000 Subject: [FS#3296] TP-Link RE450 v3: QCA9880 (5 GHz-Wifi) is only detected sporadically In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3296 - TP-Link RE450 v3: QCA9880 (5 GHz-Wifi) is only detected sporadically User who did this - Alfred Reichenberger (Alfredoredo) ---------- Maybe I should be a bit more precise about this behavior: OpenWRT only recognizes the QCA9880 802.11nac on a cold boot, i.e. when I'm plugging the RE450 to a power outlet. When rebooting the device (either by typing 'reboot' in a SSH-session or via LuCI) the QCA9880 802.11nac-wifi is not detected anymore. The only way to get it detected and working again is to remove the device from power, wait a bit (I don't know an exact time, I just noticed that unplugging and directly replugging doesn't work) and plug it back into the power outlet. So QCA9880 (5 GHz-Wifi) is not detected sporadically as I stated in the original report but it's rather only detected on a cold boot. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3296#comment8684 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 22 12:48:05 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 22 Aug 2020 16:48:05 +0000 Subject: [FS#3300] Qualcomm, MediaTek Wi-Fi Chips Vulnerable to Kr00k-Like Attacks In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Internet (Internet) Attached to Project - OpenWrt/LEDE Project Summary - Qualcomm, MediaTek Wi-Fi Chips Vulnerable to Kr00k-Like Attacks Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - Critical Priority - Very Low Reported Version - All Due in Version - Undecided Due Date - Undecided Details - I don't know if openwrt is/was affected https://www.securityweek.com/qualcomm-mediatek-wi-fi-chips-vulnerable-kr00k-attacks More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3300 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 22 14:04:50 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 22 Aug 2020 18:04:50 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Baptiste Jonglez (bjonglez) ---------- I had a look at the 18.06.4 imagebuilder (before the new size check) to see why it was working. It should have failed similarly, because the checksum from the old package in dl/ will likely be different from what is in the new package index. It turns out that the imagebuild doesn't seem to care at all about package checksums... It will happily use the old package from dl/ even though the checksum is wrong compared to what is in the package index. We could "fix" the issue by telling the imagebuilder to *also* ignore package size, but security-wise we should definitely be verifying checksums here... Once checksums are verified properly, fixing this issue would require to delete/re-download packages that failed the checksum. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8685 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 23 06:18:09 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 23 Aug 2020 10:18:09 +0000 Subject: [FS#3195] ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3195 - ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 User who did this - Rascal6 (Rascal6) ---------- hi all https://github.com/openwrt/openwrt/pull/3334 I have tested. Everything works with this patch ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3195#comment8686 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 23 06:39:07 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 23 Aug 2020 10:39:07 +0000 Subject: [FS#3191] L2TP 19.07.3 interface is not showing In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3191 - L2TP 19.07.3 interface is not showing User who did this - James White (jamesmacwhite) ---------- I was recently deploying AAISP L2TP as well, make sure you've allocated your IPs on the AAISP end as this was the reason why my L2TP interface was not visible and coming up properly. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3191#comment8687 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 23 06:46:34 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 23 Aug 2020 10:46:34 +0000 Subject: [FS#3299] busybox: Alternatives gets overwrited when busybox updates In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3299 - busybox: Alternatives gets overwrited when busybox updates User who did this - Hannu Nyman (hnyman) ---------- > If mwan3 really needs functionality not provided by busybox IP, it should not depend on the abstract `ip` but on something like `ip-full` instead. Note that that argument about "ip" may partially be a fallout of the (three years old) change, where busybox started to provide "ip". Earlier "ip" provide was just for ip-tiny, ip-full, but not busybox. In the forum discussion also "sort" and adblock has been mentioned as problematic. So the problem is not related just to "ip" app. As far as I understand, the "alternatives" provides a precedence definition mechanism, which should lead to the more preferred app getting precendence. Possibly there is bad handling of "alternatives" precedence with "opkg upgrade" (which command I dislike in any case...). I feel that trying to provide full "upgrade anything" capability is contrdictory to the aim of keeping OpenWrt and opkg simple, but sadly there seems to be more and more people who try to upgrade anything. (Busybox is roughly the most dangerous item to be upgraded, as it is so core.) One possible generic solution might be the busybox build config option "always install to /sbin, /bin and avoid /usr". That should keep the busybox stuff late on the path, preventing their usage if there is a better app typically in /usr, earlier in the path. https://github.com/openwrt/openwrt/blob/master/package/utils/busybox/config/Config.in#L194 config BUSYBOX_CONFIG_INSTALL_NO_USR bool "Don't use /usr" default BUSYBOX_DEFAULT_INSTALL_NO_USR help Disable use of /usr. "busybox --install" and "make install" will install applets only to /bin and /sbin, never to /usr/bin or /usr/sbin. I wonder if that has ever been evaluated by OpenWrt? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3299#comment8688 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 23 16:11:03 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 23 Aug 2020 20:11:03 +0000 Subject: [FS#3290] hostapd always sets ap_isolate to 1 no matter what the wireless config is set to In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3290 - hostapd always sets ap_isolate to 1 no matter what the wireless config is set to User who did this - odmdas (odmdas) ---------- Hi, PhobosK. According to [0], ap_isolate=1 is always present in hostapd config file. Hope this topic is helpful... [0] https://forum.openwrt.org/t/clients-in-same-wlan-cant-reach-each-other/2501/22 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3290#comment8689 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 23 20:20:15 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 00:20:15 +0000 Subject: [FS#3195] ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3195 - ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 User who did this - camel (camel) ---------- @Rascal6 - thx for verifying .. @Petr ?tetiar when can this patch be added to master or which are the next steps to add/commit to master trunk ? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3195#comment8690 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 04:22:05 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 08:22:05 +0000 Subject: [FS#3229] Hardware flow offloading not working on MT7621 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3229 - Hardware flow offloading not working on MT7621 User who did this - UAb5eSMn (UAb5eSMn) ---------- The commit message of https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=734a8c46e7037075d712e3d3844467672d0f91c9 (ramips: remove legacy ethernet driver components for mt7621): The mt7621 subtarget has been switched to DSA quite a while ago and seems to run sufficiently fine. Build with older kernels than 5.4 has been disabled directly during the kernel bump, so our local ethernet driver is unused in master since then. Therefore, let's remove the mt7621-specific parts of "our" ethernet driver, so we don't have to maintain them and it's obvious to everybody that they are not used anymore. This also drops the offloading components as this was specifically implemented to depend on mt7621. Will offloading not be supported anymore, or was this code replaced by something generic? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3229#comment8691 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 05:31:55 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 09:31:55 +0000 Subject: [FS#2867] proto_add_host_dependency inject wrong route to wrong gateway In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2867 - proto_add_host_dependency inject wrong route to wrong gateway User who did this - Etienne CHAMPETIER (champtar) ---------- Just hit the same issue default via 192.168.14.1 dev wanmaison1 proto static metric 10 default via 192.168.21.1 dev wancamp1 proto static metric 20 default via 192.168.20.1 dev wancave proto static metric 60 ... 1.2.3.4 via 192.168.21.1 dev wancamp1 proto static metric 20 where 1.2.3.4 is the vpn endpoint The only way to find the correct interfaces is to use `ip r get` or equivalent netlink call before setting up the vpn ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2867#comment8692 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 05:36:02 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 09:36:02 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Baptiste Jonglez (bjonglez) ---------- The lack of checksum verification was a bug, it was fixed in opkg in https://git.openwrt.org/c09fe2098718807d and this fix got applied in 18.06.7 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8693 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 05:37:36 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 09:37:36 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Baptiste Jonglez (bjonglez) ---------- Brian, your approach looks good, this should be a Makefile step that is run just after "opkg update". A similar approach could be implemented directly in opkg. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8694 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 06:01:12 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 10:01:12 +0000 Subject: [FS#998] packages: "make packages/X/check" should print warnings without needing the verbose mode In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#998 - packages: "make packages/X/check" should print warnings without needing the verbose mode User who did this - harry john (harryjohn21) ---------- This problem is new and should be taken care of ASAP. I will send this to the staff member and see if anything can be done. By the way, have a look at [[https://auroravista.tech/services/digital-marketing/|Best digital marketing agency]] ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=998#comment8695 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 07:15:40 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 11:15:40 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Brian J. Murrell (brianjmurrell) ---------- But one thing I wonder is why do so many checksums change so often? I see literally the same package name/version/release/etc. deleted and then re-downloaded using my script above. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8696 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 07:25:57 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 11:25:57 +0000 Subject: [FS#3301] Some packages are missing in 19.07.1 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - lowsfer (lowsfer) Attached to Project - OpenWrt/LEDE Project Summary - Some packages are missing in 19.07.1 Task Type - Bug Report Category - Packages Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - openwrt-19.07 Due in Version - Undecided Due Date - Undecided Details - One example is iptables-mod-tproxy. It is available in 19.07.0, but not in 19.07.1. This causes dependency issue when installing some packages. How to reproduce: # opkg install shadowsocks-libev-ss-rules Installing shadowsocks-libev-ss-rules (3.2.5-5) to root... Downloading http://downloads.openwrt.org/releases/19.07.1/packages/aarch64_cortex-a53/packages/shadowsocks-libev-ss-rules_3.2.5-5_aarch64_cortex-a53.ipk Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for shadowsocks-libev-ss-rules: * iptables-mod-tproxy * opkg_install_cmd: Cannot install package shadowsocks-libev-ss-rules. I reproduced it on aarch64_coretex_a53, but I see it's missing for other platforms like a72 and x86_64, too. It was reported here: https://github.com/openwrt/packages/issues/11457 But was closed and the maintainer said it belongs here. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3301 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 08:00:17 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 12:00:17 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Jo-Philipp Wich (jow-) ---------- Because the repos are continuously rebuilt and packages currently aren't reproducible (mtimes in tarballs change). ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8697 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 08:07:33 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 12:07:33 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Brian J. Murrell (brianjmurrell) ---------- > Because the repos are continuously rebuilt And packages that have not changed in any way are included in the rebuild? > and packages currently aren't reproducible I'm not parsing what this means. I'm not sure what it means for a package to be "reproducible". ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8698 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 08:18:27 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 12:18:27 +0000 Subject: [FS#3302] ip-tiny symlink overwritten by busybox In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Brian J. Murrell (brianjmurrell) Attached to Project - OpenWrt/LEDE Project Summary - ip-tiny symlink overwritten by busybox Task Type - Bug Report Category - Packages Status - Unconfirmed Assigned To - Operating System - All Severity - Critical Priority - Very Low Reported Version - openwrt-19.07 Due in Version - Undecided Due Date - Undecided Details - Supply the following if possible: - Device problem occurs on ALL/NA - Software versions of OpenWrt/LEDE release, packages, etc. 19.07.3 latest - Steps to reproduce Unknown Recently I discovered that the "ip-tiny" "ip" symlink had been overwritten by the busybox symlink and of course things broke due to the restricted features of the busybox ip. Is this supposed to happen even with ALTERNATIVES? I assumed the whole point of ALTERNATIVES was to ensure that the highest priority alternative was always the current symlink. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3302 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 09:23:46 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 13:23:46 +0000 Subject: [FS#3301] Some packages are missing in 19.07.1 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3301 - Some packages are missing in 19.07.1 User who did this - Baptiste Jonglez (bjonglez) ---------- The package exists as expected, here for a few targets: https://downloads.openwrt.org/releases/19.07.1/targets/sunxi/cortexa53/packages/ https://downloads.openwrt.org/releases/19.07.1/targets/x86/64/packages/ It's not as the same place as other packages because it's tightly coupled with the kernel. You are possibly missing the core packages feed in your opkg configuration (in /etc/opkg/): src/gz openwrt_core http://downloads.openwrt.org/releases/19.07.1/targets/YOURTARGET/YOURSUBTARGET/packages Btw you should always use the latest 19.07.X release in any case. Please provide the content of all files in /etc/opkg/ and try with 19.07.3. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3301#comment8699 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 09:23:52 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 13:23:52 +0000 Subject: [FS#3301] Some packages are missing in 19.07.1 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#3301 - Some packages are missing in 19.07.1 User who did this: Baptiste Jonglez (bjonglez) Status: Unconfirmed -> Waiting on reporter More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3301 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 09:24:40 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 13:24:40 +0000 Subject: [FS#3301] Cannot satisfy dependency on iptables-mod-tproxy In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#3301 - Cannot satisfy dependency on iptables-mod-tproxy User who did this: Baptiste Jonglez (bjonglez) Summary: Some packages are missing in 19.07.1 -> Cannot satisfy dependency on iptables-mod-tproxy More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3301 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 09:35:53 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 13:35:53 +0000 Subject: [FS#3303] ntfs drive not mounting In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Ahmar Aftab (ahmar16) Attached to Project - OpenWrt/LEDE Project Summary - ntfs drive not mounting Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - High Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Supply the following if possible: - Device problem occurs on - Software versions of OpenWrt/LEDE release, packages, etc. - Steps to reproduce This problem is occurring on a BT HomeHub 5A. I have two of these and the problem happens on both of them. I am currently using V5.X and the issue is only here but it is working in v19.07.3. The issue is that I am not able to auto-mount my NTFS drive with bootup through fstab. The error is as follows: Sun Aug 23 21:56:03 2020 kern.notice kernel: [ 11.711119] scsi 0:0:0:0: Direct-Access Seagate Expansion 0608 PQ: 0 ANSI: 6 Sun Aug 23 21:56:03 2020 kern.notice kernel: [ 11.725022] sd 0:0:0:0: [sda] 976773167 512-byte logical blocks: (500 GB/466 GiB) Sun Aug 23 21:56:03 2020 kern.notice kernel: [ 11.733044] sd 0:0:0:0: [sda] Write Protect is off Sun Aug 23 21:56:03 2020 kern.debug kernel: [ 11.736665] sd 0:0:0:0: [sda] Mode Sense: 4f 00 00 00 Sun Aug 23 21:56:03 2020 kern.notice kernel: [ 11.738710] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sun Aug 23 21:56:03 2020 kern.warn kernel: [ 11.739527] overlayfs: upper fs does not support xattr, falling back to index=off and metacopy=off. Sun Aug 23 21:56:03 2020 kern.info kernel: [ 12.012011] sda: sda1 Sun Aug 23 21:56:03 2020 kern.notice kernel: [ 12.020464] sd 0:0:0:0: [sda] Attached SCSI disk Sun Aug 23 21:56:10 2020 daemon.err block: No "mount.ntfs" utility available Sun Aug 23 21:56:10 2020 daemon.err block: mounting /dev/sda1 (ntfs) as /tmp/data-hdd failed (25) - Not a tty Although I can mount the drive manually through ntfs-3g and the package is already installed but somehow the system thinks it is not available. For now the workaround is to manually mount the drive when the boot ends. Please fix this issue thanks. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3303 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 09:45:24 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 13:45:24 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Jo-Philipp Wich (jow-) ---------- > And packages that have not changed in any way are included in the rebuild? Yes > I'm not sure what it means for a package to be "reproducible". Two different compilation runs of the same sources at two different times or on two different systems do no result in bit-identical files. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8700 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 09:47:00 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 13:47:00 +0000 Subject: [FS#3302] ip-tiny symlink overwritten by busybox In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3302 - ip-tiny symlink overwritten by busybox User who did this - Jo-Philipp Wich (jow-) ---------- FS#3299 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3302#comment8701 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 09:47:07 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 13:47:07 +0000 Subject: [FS#3302] ip-tiny symlink overwritten by busybox In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3302 - ip-tiny symlink overwritten by busybox User who did this - Jo-Philipp Wich (jow-) Reason for closing: Duplicate More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3302 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 10:12:29 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 14:12:29 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Brian J. Murrell (brianjmurrell) ---------- So why do packages that have not changed in any way get rebuilt? That seems like unnecessary churn. Is it a goal to get packages reproducible? What variants are causing them not to be? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8702 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 10:20:44 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 14:20:44 +0000 Subject: [FS#3299] busybox: Alternatives gets overwrited when busybox updates In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3299 - busybox: Alternatives gets overwrited when busybox updates User who did this - Brian J. Murrell (brianjmurrell) ---------- I don't think $PATH location for alternatives is a good solution. People might have perfectly valid reasons for preferring one */bin* directory over another. What I am failing to understand is why this problem is even happening with ALTERNATIVES: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/utils/busybox/Makefile;h=62af99d3ae15f4b2aca76111124fc114fdee2b7b;hb=HEAD#l51 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/utils/iproute2/Makefile;h=1c8e3e66d6174d1da78d82dc19aa6ec72acbb073;hb=HEAD#l40 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/utils/iproute2/Makefile;h=1c8e3e66d6174d1da78d82dc19aa6ec72acbb073;hb=HEAD#l49 [links from #1895 where this was explained to me previously] ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3299#comment8703 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 10:23:41 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 14:23:41 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Jo-Philipp Wich (jow-) ---------- > So why do packages that have not changed in any way get rebuilt? That seems like unnecessary churn. Because there is no reliable way to only rebuild single packages yet and because it would imply moving parts of the buildroot logic to repository download servers. In short, it is complex and has not been implemented so far. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8704 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 11:47:01 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 15:47:01 +0000 Subject: [FS#3195] ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3195 - ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 User who did this - Rascal6 (Rascal6) ---------- @camel Please check now ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3195#comment8705 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 12:06:36 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 16:06:36 +0000 Subject: [FS#3143] ramips/mt7621/zbt-wg3526-16 boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3143 - ramips/mt7621/zbt-wg3526-16 boot failure with kernel 5.4 User who did this - Adrian Schmutzler (adrianschmutzler) Reason for closing: Fixed Additional comments about closing: fixed in https://github.com/openwrt/openwrt/commit/b2f19d3ef707c60c46a75a1fe2c38365474a5921 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3143 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 14:19:46 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 18:19:46 +0000 Subject: [FS#3304] MVEBU - sysupgrade may not correctly detect device from bootcmd In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - GANDALF (erdoukki) Attached to Project - OpenWrt/LEDE Project Summary - MVEBU - sysupgrade may not correctly detect device from bootcmd Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - forum topic : https://forum.openwrt.org/t/solved-19-07-xx-own-build-unflashable/72297 Solution : https://forum.openwrt.org/t/solved-19-07-xx-own-build-unflashable/72297/8 Sysupgrade do not correctly detect the device from some bootcmd uboot command line ... I suppose, rootfs is not correctly detected ? /proc/cmdline okay : console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p2 rw rootwait net.ifnames=0 biosdevname=0 /proc/cmdline which make an error : console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p2 rw ip=0.0.0.0:0.0.0.0:10.4.50.254:255.255.255.0:marvell:eth0:none nfsroot=0.0.0.0:/dev/mmcblk0p2 when error happend, the message is : root at NAS:~# sysupgrade -v -T openwrt-19.07.3-mvebu-cortexa53-globalscale_espressobin-v7-emmc-ext4-sdcard.img.gz Image not in /tmp, copying... Unable to determine upgrade device Image check failed. root at NAS:~# More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3304 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 14:24:20 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 18:24:20 +0000 Subject: [FS#2636] Turris Onmia: sysupgrade is broken In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2636 - Turris Onmia: sysupgrade is broken User who did this - GANDALF (erdoukki) ---------- FS3304 related ? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2636#comment8706 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 14:26:37 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 18:26:37 +0000 Subject: [FS#3304] MVEBU - sysupgrade may not correctly detect device from bootcmd In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3304 - MVEBU - sysupgrade may not correctly detect device from bootcmd User who did this - GANDALF (erdoukki) ---------- also from 19.07.3 and 19.07-master ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3304#comment8707 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 24 19:05:23 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 24 Aug 2020 23:05:23 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Baptiste Jonglez (bjonglez) ---------- I just sent a patch series to opkg that fixes the issue: https://patchwork.ozlabs.org/project/openwrt/list/?series=197459 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8708 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 25 07:30:23 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 25 Aug 2020 11:30:23 +0000 Subject: [FS#3195] ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3195 - ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 User who did this - Aleksey Tregubov (AelxG) ---------- @Rascal6, not at all, 5 minutes ago just tested again, still crashes. Please note that a have another device, Unielec 7621-06. But platform the same, mt7621. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3195#comment8709 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 25 09:49:53 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 25 Aug 2020 13:49:53 +0000 Subject: [FS#3195] ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3195 - ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 User who did this - Rascal6 (Rascal6) ---------- Need to flash without saving settings ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3195#comment8710 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 25 09:51:46 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 25 Aug 2020 13:51:46 +0000 Subject: [FS#2690] Imagebuilder: "opkg_install_pkg: Package size mismatch" error In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#2690 - Imagebuilder: "opkg_install_pkg: Package size mismatch" error User who did this - Paul Oranje (por) ---------- The patch would be most appreciated. My IB recipes clean out the caches before building an image and seeing everything being downloaded again and again feels lavish. So +1. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=2690#comment8711 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 25 11:16:21 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 25 Aug 2020 15:16:21 +0000 Subject: [FS#3147] 802.11w settings on LUCI WIFI page doesn't work properly and causes serious connection problems In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3147 - 802.11w settings on LUCI WIFI page doesn't work properly and causes serious connection problems User who did this - Mark A. Ziesemer (ziesemer) ---------- See also: https://community.intel.com/t5/Wireless/WPA2-Enterprise-unable-to-connect-in-Windows-10-version-2004/m-p/1187887#M29624 I have spent significant time recently trying to troubleshoot this, and just managed to find this ticket with some different keywords ("wpad intel radius"). Assuming this is the same issue - I've not been able to reproduce this outside of an Intel wireless adapter (including 8265 or 9260), and not outside of Windows 10 - specifically, version 2004 (works in 1909). As of yesterday, I was finally able to reproduce the configurations on an enterprise wireless access point, and was able to determine that this does not appear to be reproducible outside of using OpenWrt. In some network traces I've completed with Intel, an OTA trace shows multiple rounds of the EAPOL 4-way handshake being attempted. OpenWrt sends message 1, the client responds with message 2, but OpenWrt never sends the 3rd message. It's as if OpenWrt does not properly receive or handle message 2, and repeats sending message 1. The client then re-sends message 2, but OpenWrt never sends message 3. This happens a total of 4 times, before OpenWrt then sends a deauthentication. I had tried changing the 802.11w settings via Luci, but did not yet confirm if the settings were actually taking - which given the description here, might be the issue. Will investigate further and report back! ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3147#comment8712 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 25 11:45:55 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 25 Aug 2020 15:45:55 +0000 Subject: [FS#3305] Request for LXC support in MVEBU In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - GANDALF (erdoukki) Attached to Project - OpenWrt/LEDE Project Summary - Request for LXC support in MVEBU Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - can the kernel needed flags for lxc support being added to the official releases, please ? I have made a forum topic for this request and followed the tests in it ! https://forum.openwrt.org/t/request-for-lxc-support-in-mvebu/58767 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3305 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 25 11:48:23 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 25 Aug 2020 15:48:23 +0000 Subject: [FS#3305] Request for LXC support in MVEBU In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3305 - Request for LXC support in MVEBU User who did this - GANDALF (erdoukki) ---------- I have tested with those flags : ``` CONFIG_KERNEL_LXC_MISC=y CONFIG_LXC_KERNEL_OPTIONS=y CONFIG_LXC_BUSYBOX_OPTIONS=y CONFIG_LXC_SECCOMP=y CONFIG_LXC_NETWORKING=y ``` ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3305#comment8713 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 25 12:16:56 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 25 Aug 2020 16:16:56 +0000 Subject: [FS#1252] No IP Assigned to Interface with QMI on Quectel EC-25A In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1252 - No IP Assigned to Interface with QMI on Quectel EC-25A User who did this - MiNuS (bgiboudeau) ---------- I have __exactly__ the same problem as @Dmitry. 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" give me the new ip address. Every 12 hours: - "uqmi -d /dev/cdc-wdm0 ?get-current-settings" give IP "B". - "udhcpc" still attribute IP "A" to the wwan0 interface. The result is an inoperationnal interface until I restart the interface. I don't know if it's a bug in the firmware of the modem or a problem within OpenWRT. The script provided by @Frans is a workaround but fixing the issue would be way better. I can provide more details if needed and this problem happen __with my two 4G__ routers one with __EC-25__ and another one with __BroadMobi BM806__. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=1252#comment8714 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 25 14:13:48 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 25 Aug 2020 18:13:48 +0000 Subject: [FS#3306] QMI & DHCP renewal issue. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - MiNuS (bgiboudeau) Attached to Project - OpenWrt/LEDE Project Summary - QMI & DHCP renewal issue. Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Very Low Reported Version - openwrt-19.07 Due in Version - Undecided Due Date - Undecided Details - 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 at 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 at 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 at 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 at 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' More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3306 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Tue Aug 25 15:11:35 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Tue, 25 Aug 2020 19:11:35 +0000 Subject: [FS#3195] ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3195 - ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 User who did this - UAb5eSMn (UAb5eSMn) ---------- The patsh should be in todays snapshot image (a69949a13f8cf3eca0fccda0d826928034877c9b). Yesterday it was at commit f75c70aecaca0d296207ad15e11cf1363b6bdcaf, so the patch (b2f19d3ef707c60c46a75a1fe2c38365474a5921) wasn't in the snapshot yet. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3195#comment8715 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 27 19:53:14 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 27 Aug 2020 23:53:14 +0000 Subject: [FS#3307] WRT3200ACM forgotted in a commit to assign the default reg domain In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - howl (howl) Attached to Project - OpenWrt/LEDE Project Summary - WRT3200ACM forgotted in a commit to assign the default reg domain Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=d0e8b8310f7079ccf250f7eddbdf8b9d319c274d This commit forgot the linksys,wrt3200acm|\ before the linksys,wrt32x|\ People that have read me and more people about the crappy thing done by marvel locking the reg domain should know about I don't think this is the way to go, but, just my 2 cents for the other team. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3307 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Thu Aug 27 19:54:53 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Thu, 27 Aug 2020 23:54:53 +0000 Subject: [FS#3307] WRT3200ACM forgotted in a commit to assign the default reg domain In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3307 - WRT3200ACM forgotted in a commit to assign the default reg domain User who did this - howl (howl) ---------- Forget to mention that of course $(strings /dev/mtd3|sed -ne 's/^cert_region=//p') works in WRT3200ACM returning the corresponding value. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3307#comment8716 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 28 04:30:21 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 28 Aug 2020 08:30:21 +0000 Subject: [FS#3181] unable to build 19.07.3 for clearfog pro In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3181 - unable to build 19.07.3 for clearfog pro User who did this - Baptiste Jonglez (bjonglez) ---------- There was a patch sent to fix this issue for uboot-zynq: https://patchwork.ozlabs.org/project/openwrt/patch/20200802233442.1621160-1-luaraneda at gmail.com/ It probably needs to be fixed for all u-boot packages, and backported to stable releases. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3181#comment8717 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 28 06:12:20 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 28 Aug 2020 10:12:20 +0000 Subject: [FS#3195] ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3195 - ramips/mt7621/zbt3526 -> boot failure with kernel 5.4 User who did this - camel (camel) ---------- confirmed, patch is working. pls close ticket great job, thx ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3195#comment8718 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 28 06:27:28 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 28 Aug 2020 10:27:28 +0000 Subject: [FS#3308] ssmtp package missing In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - camel (camel) Attached to Project - OpenWrt/LEDE Project Summary - ssmtp package missing Task Type - Bug Report Category - Packages Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - in current trunk of today ....package: ssmtp missing ? opkg install libopenssl ssmtp Package libopenssl1.1 (1.1.1g-1) installed in root is up to date. Unknown package 'ssmtp'. Collected errors: * opkg_install_cmd: Cannot install package ssmtp. maybe build error ? as it was not possible to test trunk image since 5 months cause of 5.4 kernel - i can't tell whne it was built last time ... for sure around 2020-01 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3308 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 28 06:51:00 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 28 Aug 2020 10:51:00 +0000 Subject: [FS#3308] ssmtp package missing In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3308 - ssmtp package missing User who did this - Baptiste Jonglez (bjonglez) Reason for closing: Different project Additional comments about closing: It's a package feed thing. Looks like it got removed: https://github.com/openwrt/packages/pull/12752 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3308 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 28 07:54:22 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 28 Aug 2020 11:54:22 +0000 Subject: [FS#3309] MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - rogerpueyo (rogerpueyo) Attached to Project - OpenWrt/LEDE Project Summary - MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Baja Priority - Normal Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Hi, Given the way the wired network is setup in the MikroTik LHG HB platform DTS file (qca9533_mikrotik_routerboard-lhg-hb): ð1 { gmac-config { device = ; }; }; the link speed for the MikroTik LHG 2 is not properly reported at eth0. Instead, it appears as fixed at 1000 Mbps, while swconfig reports the actual speed for port #1: root at OpenWrt:~# dmesg | grep eth [ 4.335676] ag71xx 1a000000.eth: invalid MAC address, using random address [ 5.098696] ag71xx 1a000000.eth: connected to PHY at fixed-0:00 [uid=00000000, driver=Generic PHY] [ 5.108652] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii [ 5.826229] eth0: link up (1000Mbps/Full duplex) [ 5.838081] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 9.991422] eth0: link down [ 56.170746] eth0: link up (1000Mbps/Full duplex) [ 56.176251] br-lan: port 1(eth0) entered blocking state [ 56.181725] br-lan: port 1(eth0) entered disabled state [ 56.187503] device eth0 entered promiscuous mode [ 56.211269] br-lan: port 1(eth0) entered blocking state [ 56.216705] br-lan: port 1(eth0) entered forwarding state root at OpenWrt:~# swconfig dev switch0 show Global attributes: enable_vlan: 0 ar8xxx_mib_poll_interval: 500 ar8xxx_mib_type: 0 enable_mirror_rx: 0 enable_mirror_tx: 0 mirror_monitor_port: 0 mirror_source_port: 0 arl_table: address resolution table Port 0: MAC de:ad:be:ef:00:00 Port 0: MAC de:ad:be:ef:00:01 Port 1: MAC de:ad:be:ef:00:02 Port 0: mib: MIB counters RxGoodByte : 61472 (60.0 KiB) TxByte : 64515 (63.0 KiB) pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: mib: MIB counters RxGoodByte : 64795 (63.2 KiB) TxByte : 54979 (53.6 KiB) pvid: 0 link: port:1 link:up speed:10baseT half-duplex auto Port 2: mib: No MIB data pvid: 0 link: port:2 link:down Port 3: mib: No MIB data pvid: 0 link: port:3 link:down Port 4: mib: No MIB data pvid: 0 link: port:4 link:down Using the following network setup, which is also found in other devices (e.g., MikroTik SXT Lite 5): ð0 { status = "okay"; phy-handle = ; gmac-config { device = ; switch-phy-swap = ; }; }; ð1 { status = "okay"; compatible = "syscon", "simple-mfd"; }; eth0 reports the actual link speed: [ 5.087144] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode: mii [ 7.827418] eth0: link up (100Mbps/Full duplex) [ 7.832171] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 9.943393] eth0: link down [ 44.416376] br-lan: port 1(eth0) entered blocking state [ 44.421841] br-lan: port 1(eth0) entered disabled state [ 44.427598] device eth0 entered promiscuous mode [ 48.497213] eth0: link up (100Mbps/Full duplex) [ 48.502152] br-lan: port 1(eth0) entered blocking state [ 48.507613] br-lan: port 1(eth0) entered forwarding state [ 111.983480] eth0: link down [ 111.987076] br-lan: port 1(eth0) entered disabled state [ 114.033204] eth0: link up (10Mbps/Half duplex) [ 114.038061] br-lan: port 1(eth0) entered blocking state [ 114.043522] br-lan: port 1(eth0) entered forwarding state [ 117.103480] eth0: link down [ 117.107070] br-lan: port 1(eth0) entered disabled state [ 118.129228] eth0: link up (100Mbps/Full duplex) [ 118.134175] br-lan: port 1(eth0) entered blocking state [ 118.139631] br-lan: port 1(eth0) entered forwarding state [ 120.176348] eth0: link down [ 120.180095] br-lan: port 1(eth0) entered disabled state [ 122.225217] eth0: link up (100Mbps/Full duplex) [ 122.230159] br-lan: port 1(eth0) entered blocking state [ 122.235615] br-lan: port 1(eth0) entered forwarding state as the switch is not used: root at OpenWrt:~# swconfig dev switch0 show Global attributes: enable_vlan: 0 ar8xxx_mib_poll_interval: 500 ar8xxx_mib_type: 0 enable_mirror_rx: 0 enable_mirror_tx: 0 mirror_monitor_port: 0 mirror_source_port: 0 arl_table: address resolution table Port 0: mib: No MIB data pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: mib: No MIB data pvid: 0 link: port:1 link:down Port 2: mib: No MIB data pvid: 0 link: port:2 link:down Port 3: mib: No MIB data pvid: 0 link: port:3 link:down Port 4: mib: No MIB data pvid: 0 link: port:4 link:down More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3309 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 28 08:00:53 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 28 Aug 2020 12:00:53 +0000 Subject: [FS#3309] MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3309 - MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) User who did this - rogerpueyo (rogerpueyo) ---------- Pull request submitted at GitHub: https://github.com/openwrt/openwrt/pull/3361 ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3309#comment8719 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Fri Aug 28 13:17:37 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Fri, 28 Aug 2020 17:17:37 +0000 Subject: [FS#3309] MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3309 - MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) User who did this - Franco Castillo (francocastillo) ---------- It will be related to [[https://bugs.openwrt.org/index.php?do=details&task_id=3271]]? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3309#comment8720 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 29 05:09:47 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 29 Aug 2020 09:09:47 +0000 Subject: [FS#3135] bcm47xx: WGT634U missing ethernet interface In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3135 - bcm47xx: WGT634U missing ethernet interface User who did this - Russell Senior (russell) ---------- This is the commit where the switch problem begins: commit 5c98041d5a054bfe68070bbfa6fdeab63e6586fc (HEAD) Author: Rafa? Mi?ecki Date: Tue Mar 10 13:26:57 2020 +0100 bcm47xx: switch to kernel 4.19 Ethernet, switch, LEDs, buttons, USB, sysupgrade & LuCI were successfully tested on BCM4706. Signed-off-by: Rafa? Mi?ecki ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3135#comment8721 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 29 17:44:35 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sat, 29 Aug 2020 21:44:35 +0000 Subject: [FS#3310] Image Builder error =?utf-8?Q?=E2=80=9Cfollowing?= packages conflict with =?utf-8?Q?busybox=E2=80=9D?= In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Sinan ?etinkaya (sinancetinkaya) Attached to Project - OpenWrt/LEDE Project Summary - Image Builder error ?following packages conflict with busybox? Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - Supply the following if possible: - Device problem occurs on unielec_u7621-06-16m - Software versions of OpenWrt/LEDE release, packages, etc. latest snapshots - Steps to reproduce sinan at sinan-VirtualBox:~$ make image PROFILE=unielec_u7621-06-16m PACKAGES="luci block-mount kmod-fs-ext4 wpad-mini nano htop kmod-mt76 kmod-mt76-core kmod-mt76x2 luci-app-sqm sqm-scripts kmod-usb-storage-uas kmod-usb3" ...................... ...................... ...................... Collected errors: * check_conflicts_for: The following packages conflict with busybox: * check_conflicts_for: busybox-selinux * * opkg_install_cmd: Cannot install package busybox. Makefile:154: recipe for target 'package_install' failed make[2]: *** [package_install] Error 255 Makefile:112: recipe for target '_call_image' failed make[1]: *** [_call_image] Error 2 Makefile:207: recipe for target 'image' failed make: *** [image] Error 2 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3310 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sat Aug 29 20:22:50 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 30 Aug 2020 00:22:50 +0000 Subject: [FS#3311] vlan(NETWORK -> SWITCH) menu missing on luci -> mt7621(ZBT3526) - trunk In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - camel (camel) Attached to Project - OpenWrt/LEDE Project Summary - vlan(NETWORK -> SWITCH) menu missing on luci -> mt7621(ZBT3526) - trunk Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - vlan menu missing on luci -> mt7621(ZBT3526) - trunk that was on 2020-01 working ? why is it now gone ? also in /etc/config, there are no entries for vlan i compared to the old version from 20020-01 .. and there is 1 file missing: (or more ?) # cat /lib/network/switch.sh #!/bin/sh # Copyright (C) 2009 OpenWrt.org setup_switch_dev() { local name config_get name "$1" name name="${name:-$1}" [ -d "/sys/class/net/$name" ] && ip link set dev "$name" up swconfig dev "$name" load network } setup_switch() { config_load network config_foreach setup_switch_dev switch } More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3311 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 30 18:20:09 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 30 Aug 2020 22:20:09 +0000 Subject: [FS#3223] stubby package missing for ar71xx - mips_24kc In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3223 - stubby package missing for ar71xx - mips_24kc User who did this - odmdas (odmdas) ---------- Hi, Vincent. Stubby package is now available. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3223#comment8722 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 30 18:59:49 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Sun, 30 Aug 2020 22:59:49 +0000 Subject: [FS#3312] static route being added to wrong table if ip4table is used In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Peter (petzah) Attached to Project - OpenWrt/LEDE Project Summary - static route being added to wrong table if ip4table is used Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - I have a separate route table called 'lan': root at btkrgn:~# cat /etc/iproute2/rt_tables # # reserved values # 128 prelocal 255 local 254 main 253 default 0 unspec # # local # #1 inr.ruhep 40 lan Then I have an interface configured with ip4table: config interface 'ni' option type 'bridge' option delegate '0' option ifname 'eth0.22 vx22' option proto 'static' option ipaddr '192.168.22.248' option ip4table 'lan' option netmask '255.255.255.0' And I also have static route with explicitly defined table 'main': config route option interface 'ni' option target '192.168.22.0' option netmask '255.255.255.0' option gateway '192.168.22.253' option table 'main' option metric '100' I expected that this static route will be in the 'main' table however it is being added to 'lan' table: root at btkrgn:~# ip route show table lan 192.168.22.0/24 dev br-ni proto static scope link 192.168.22.0/24 via 192.168.22.253 dev br-ni proto static metric 100 More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3312 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Sun Aug 30 20:00:10 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 00:00:10 +0000 Subject: [FS#3223] stubby package missing for ar71xx - mips_24kc In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3223 - stubby package missing for ar71xx - mips_24kc User who did this - Baptiste Jonglez (bjonglez) Reason for closing: Works for me Additional comments about closing: Note: stubby is not part of openwrt, it's in the package feed More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3223 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 04:06:34 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 08:06:34 +0000 Subject: [FS#3306] QMI & DHCP renewal issue. In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3306 - QMI & DHCP renewal issue. User who did this - MiNuS (bgiboudeau) ---------- ======Additionnal informations.====== I used MWAN3 to monitor the interface the past few days and the script try to restart the interface when it went down. Sometime it stay blocked on the "pin-verify" but it's another story. ====Below the log showing the timing of the problem (exactly every 12 hours the dhcp lease time)==== Fri Aug 28 22:23:32 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0 Fri Aug 28 22:23:34 CEST 2020 - Action:ifdown - Interface:wwan - Device: Fri Aug 28 22:23:40 CEST 2020 - Action:disconnected - Interface:wwan - Device:wwan0 Fri Aug 28 22:23:42 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0 Fri Aug 28 22:23:43 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0 Sat Aug 29 10:23:28 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0 Sat Aug 29 10:23:30 CEST 2020 - Action:ifdown - Interface:wwan - Device: Sat Aug 29 10:23:37 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0 Sat Aug 29 10:23:38 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0 Sat Aug 29 22:23:31 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0 Sat Aug 29 22:23:34 CEST 2020 - Action:ifdown - Interface:wwan - Device: Sat Aug 29 22:23:40 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0 Sat Aug 29 22:23:41 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0 Sun Aug 30 10:23:32 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0 Sun Aug 30 10:23:34 CEST 2020 - Action:ifdown - Interface:wwan - Device: Sun Aug 30 10:23:42 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0 Sun Aug 30 10:23:43 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0 Sun Aug 30 22:23:30 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0 Sun Aug 30 22:23:32 CEST 2020 - Action:ifdown - Interface:wwan - Device: Sun Aug 30 22:23:39 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0 Sun Aug 30 22:23:40 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0 ====Below another exemple showing the result of the bug.==== My script (see below) log stats of interface before and after interface restart. It also compare the DHCP lease obtained and the UQMI parameters. Sun Aug 30 22:23:30 CEST 2020 - Action:ifdown - Interface:wwan - Device:wwan0 calling: ubus call network.interface.wwan down { "pdp-type": "ipv4", "ip-family": "ipv4", "mtu": 1500, "ipv4": { "ip": "10.92.174.236", "dns1": "212.27.40.240", "dns2": "212.27.40.241", "gateway": "10.92.174.237", "subnet": "255.255.255.248" }, "ipv6": { }, "domain-names": { } } wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.41.208.219 P-t-P:10.41.208.219 Mask:255.255.255.248 inet6 addr: fe80::b6a7:6397:3697:50fa/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:69814179 errors:0 dropped:0 overruns:0 frame:0 TX packets:28061149 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:87843195331 (81.8 GiB) TX bytes:5812847812 (5.4 GiB) Sun Aug 30 22:23:32 CEST 2020 - Action:ifdown - Interface:wwan - Device: calling: ubus call network.interface.wwan down "Out of call" wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:69814179 errors:0 dropped:0 overruns:0 frame:0 TX packets:28061150 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:87843195331 (81.8 GiB) TX bytes:5812847876 (5.4 GiB) calling: ubus call network.interface.wwan up "Out of call" wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1 RX packets:69814179 errors:0 dropped:0 overruns:0 frame:0 TX packets:28061150 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:87843195331 (81.8 GiB) TX bytes:5812847876 (5.4 GiB) calling: ubus call network.interface.wwan up { "pdp-type": "ipv4", "ip-family": "ipv4", "mtu": 1500, "ipv4": { "ip": "10.92.174.236", "dns1": "212.27.40.240", "dns2": "212.27.40.241", "gateway": "10.92.174.237", "subnet": "255.255.255.248" }, "ipv6": { }, "domain-names": { } } wwan0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.92.174.236 P-t-P:10.92.174.236 Mask:255.255.255.248 inet6 addr: fe80::b6a7:6397:3697:50fa/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:69814181 errors:0 dropped:0 overruns:0 frame:0 TX packets:28061156 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:87843195969 (81.8 GiB) TX bytes:5812848916 (5.4 GiB) Sun Aug 30 22:23:39 CEST 2020 - Action:connected - Interface:wwan - Device:wwan0 Sun Aug 30 22:23:40 CEST 2020 - Action:ifup - Interface:wwan - Device:wwan0 ====Below the script used to monitor the interface in MWAN3.==== #!/bin/sh # # This file is interpreted as shell script. # Put your custom mwan3 action here, they will # be executed with each netifd hotplug interface event # on interfaces for which mwan3 is enabled. # # There are three main environment variables that are passed to this script. # # $ACTION # Is called by netifd and mwan3track # Is called by netifd and mwan3track # Is only called by mwan3track if tracking was successful # Is only called by mwan3track if tracking has failed # $INTERFACE Name of the interface which went up or down (e.g. "wan" or "wwan") # $DEVICE Physical device name which interface went up or down (e.g. "eth0" or "wwan0") Date=`date` echo "$Date - Action:$ACTION - Interface:$INTERFACE - Device:$DEVICE" >> /tmp/interface.log if [ $ACTION = "ifdown" ] then if [ $INTERFACE = "wwan" ] then echo "calling: ubus call network.interface.wwan down" >> /tmp/interface.log uqmi -d /dev/cdc-wdm0 --get-current-settings >> /tmp/interface.log ifconfig wwan0 >> /tmp/interface.log ubus call network.interface.wwan down sleep 3 echo "calling: ubus call network.interface.wwan up" >> /tmp/interface.log uqmi -d /dev/cdc-wdm0 --get-current-settings >> /tmp/interface.log ubus call network.interface.wwan up ifconfig wwan0 >> /tmp/interface.log fi fi ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3306#comment8723 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 06:04:11 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 10:04:11 +0000 Subject: [FS#1610] sysupgrade Image metadata not found In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#1610 - sysupgrade Image metadata not found User who did this - Glen Huang (hgl) ---------- I'm also having this issue. Built a x86 image, but sysupgrade complained "Image metadata not found". @J I failed to find the append-metadata" Makefile option, is it something in menuconfig? This issue is about x86, and there seems to be no such option when you select the x86 architecture. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=1610#comment8724 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 06:36:04 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 10:36:04 +0000 Subject: [FS#3309] MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3309 - MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) User who did this - rogerpueyo (rogerpueyo) ---------- Sorry, I have no clue. I haven't experienced such behaviour with the MikroTik LHG 2, and the patch on GitHub will only affect this device. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3309#comment8725 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 06:53:36 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 10:53:36 +0000 Subject: [FS#3313] ath79/mikrotik: initramfs image is missing the nand-utils In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - rogerpueyo (rogerpueyo) Attached to Project - OpenWrt/LEDE Project Summary - ath79/mikrotik: initramfs image is missing the nand-utils Task Type - Build Failure Category - Packages Status - Unconfirmed Assigned To - Operating System - All Severity - Alta Priority - Normal Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - The initramfs-kernel.bin image for the ath79/mikrotik mikrotik,routerboard-sxt-5nd-r2 device (SXT Lite 5) is missing the **nand-utils** package. Therefore, when booting via TFTP (e.g., to install OpenWrt for the first time), the sysupgrade image can not be flashed: [...] successful boot from TFTP, sysupgrade image uploaded via SCP root at OpenWrt:/# cat /tmp/sysinfo/board_name mikrotik,routerboard-sxt-5nd-r2 root at OpenWrt:/# ls -la /usr/sbin/nand* ls: /usr/sbin/nand*: No such file or directory root at OpenWrt:/# sysupgrade -v -n /tmp/openwrt-ath79-mikrotik-mikrotik_routerboar d-sxt-5nd-r2-squashfs-sysupgrade.bin Commencing upgrade. Closing all shell sessions. Watchdog handover: fd=3 - watchdog - killall: telnetd: no process killed Sending TERM to remaining processes ... hostapd wpa_supplicant netifd odhcpd ntpd dnsmasq ubusd urngd logd Sending KILL to remaining processes ... Performing system upgrade... Unlocking kernel ... Erasing kernel ... /lib/upgrade/do_stage2: line 25: nandwrite: not found tar: write error: Broken pipe removing ubiblock0_1 [ 301.377800] block ubiblock0_1: released Volume ID 0, size 19 LEBs (2451456 bytes, 2.3 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "none", alignment 1 Volume ID 1, size 21 LEBs (2709504 bytes, 2.5 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs", alignment 1 Set volume size to 119734272 Volume ID 2, size 928 LEBs (119734272 bytes, 114.1 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs_data", alignment 1 sysupgrade successful umount: can't unmount /dev: Resource busy umount: can't unmount /tmp: Resource busy [ 303.837785] reboot: Restarting systemt ? so the device can't boot, as nothing has been written to NAND. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3313 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 07:02:13 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 11:02:13 +0000 Subject: [FS#3313] ath79/mikrotik: initramfs image is missing the nand-utils In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3313 - ath79/mikrotik: initramfs image is missing the nand-utils User who did this - rogerpueyo (rogerpueyo) ---------- However, locally-built initramfs images, generated by only selecting these options: Target System (Atheros ATH79 (DTS)) ---> Subtarget (MikroTik devices) ---> Target Profile (MikroTik RouterBOARD SXT 5nD r2 (SXT Lite5)) ---> **do include** the nand-utils package: root at OpenWrt:/# ls -la /usr/sbin/n* -rwxr-xr-x 1 root root 20501 Aug 31 09:19 /usr/sbin/nanddump -rwxr-xr-x 1 root root 8213 Aug 31 09:19 /usr/sbin/nandtest -rwxr-xr-x 1 root root 24597 Aug 31 09:19 /usr/sbin/nandwrite lrwxrwxrwx 1 root root 17 Aug 31 09:19 /usr/sbin/ntpd -> ../../bin/busybox -rwxr-xr-x 1 root root 45 Aug 31 09:19 /usr/sbin/ntpd-hotplug root at OpenWrt:/# sysupgrade -v -n /tmp/openwrt-ath79-mikrotik-mikrotik_routerboar d-sxt-5nd-r2-squashfs-sysupgrade.bin Commencing upgrade. Closing all shell sessions. Watchdog handover: fd=3 - watchdog - killall: telnetd: no process killed Sending TERM to remaining processes ... hostapd wpa_supplicant netifd odhcpd ntpd dnsmasq ubusd urngd logd Sending KILL to remaining processes ... Performing system upgrade... Unlocking kernel ... Erasing kernel ... Writing data to block 0 at offset 0x0 Writing data to block 1 at offset 0x20000 Writing data to block 2 at offset 0x40000 Writing data to block 3 at offset 0x60000 Writing data to block 4 at offset 0x80000 Writing data to block 5 at offset 0xa0000 Writing data to block 6 at offset 0xc0000 Writing data to block 7 at offset 0xe0000 Writing data to block 8 at offset 0x100000 Writing data to block 9 at offset 0x120000 Writing data to block 10 at offset 0x140000 Writing data to block 11 at offset 0x160000 Writing data to block 12 at offset 0x180000 Writing data to block 13 at offset 0x1a0000 Writing data to block 14 at offset 0x1c0000 Writing data to block 15 at offset 0x1e0000 Writing data to block 16 at offset 0x200000 Writing data to block 17 at offset 0x220000 Writing data to block 18 at offset 0x240000 [ 69.068982] ubi0: attaching mtd2 [ 69.725009] ubi0: scanning is finished [ 69.728911] ubi0: empty MTD device detected [ 69.756713] ubi0: attached mtd2 (name "ubi", size 124 MiB) [ 69.762455] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes [ 69.769575] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512 [ 69.776505] ubi0: VID header offset: 512 (aligned 512), data offset: 2048 [ 69.783520] ubi0: good PEBs: 991, bad PEBs: 1, corrupted PEBs: 0 [ 69.789730] ubi0: user volume: 0, internal volumes: 1, max. volumes count: 128 [ 69.797197] ubi0: max/mean erase counter: 0/0, WL threshold: 4096, image sequence number: 121828761 [ 69.806548] ubi0: available PEBs: 968, total reserved PEBs: 23, PEBs reserved for bad PEB handling: 19 [ 69.816209] ubi0: background thread "ubi_bgt0d" started, PID 1694 UBI device number 0, total 991 LEBs (127862784 bytes, 121.9 MiB), available 968 LEBs (124895232 bytes, 119.1 MiB), LEB size 129024 bytes (126.0 KiB) Volume ID 0, size 19 LEBs (2451456 bytes, 2.3 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "none", alignment 1 Volume ID 1, size 21 LEBs (2709504 bytes, 2.5 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs", alignment 1 Set volume size to 119734272 Volume ID 2, size 928 LEBs (119734272 bytes, 114.1 MiB), LEB size 129024 bytes (126.0 KiB), dynamic, name "rootfs_data", alignment 1 sysupgrade successful umount: can't unmount /dev: Resource busy umount: can't unmount /tmp: Resource busy [ 74.130939] reboot: Restarting systemt ? so there might be some problem with the builds system. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3313#comment8726 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 09:33:26 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 13:33:26 +0000 Subject: [FS#3314] ath79/mikrotik: SXT Lite 5 image missing RouterBoard platform drivers In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3314 - ath79/mikrotik: SXT Lite 5 image missing RouterBoard platform drivers User who did this - rogerpueyo (rogerpueyo) ---------- - The RouterBoot platform driver **is** actually loaded (and outputs error, as shown in dmesg above). - Wrong partitions configuration in DTS file cause overlap: partition at 10000 { label = "bootloader2"; reg = ; read-only; }; [[https://github.com/openwrt/openwrt/pull/3370|Pull request submitted to GitHub]]. ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3314#comment8727 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 12:09:28 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 16:09:28 +0000 Subject: [FS#3312] static route being added to wrong table if ip4table is used In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3312 - static route being added to wrong table if ip4table is used User who did this - Peter (petzah) ---------- I think that this commit is relevant: commit 4452867c4b34cb0d9dc7fe9dc42ecc86af887176 Author: Steven Barth Date: Fri Jun 20 19:50:13 2014 +0200 interface: don't store table id in route if the default table is used Use system_is_default_rt_table() to test whether the resolved routing table is the default one, in this case do not apply the table attribute to the route object. This is needed for backwards compatibility - only routes using a non-default table shall report it in the ifstatus output. Signed-off-by: Jo-Philipp Wich diff --git a/interface-ip.c b/interface-ip.c index 715e498..587826a 100644 --- a/interface-ip.c +++ b/interface-ip.c @@ -365,6 +365,10 @@ interface_ip_add_route(struct interface *iface, struct blob_attr *attr, bool v6) goto error; } + /* only set the table flag if not using the main (default) table */ + if (system_is_default_rt_table(route->table)) + route->table = 0; + if (route->table) route->flags |= DEVROUTE_TABLE; } ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3312#comment8728 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 12:53:38 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 16:53:38 +0000 Subject: [FS#3315] TP-Link CPE210v1 - regular network disconnects - daemon.err uwsgi In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - xaibempp at sharklasers.com (xaibempp) Attached to Project - OpenWrt/LEDE Project Summary - TP-Link CPE210v1 - regular network disconnects - daemon.err uwsgi Task Type - Bug Report Category - Base system Status - Unconfirmed Assigned To - Operating System - All Severity - Medium Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - I have build a Image for TP-Link CPE210v1. OpenWrt SNAPSHOT r14184-eadb1a9437 I have issues with connection drop. The connection(routing?) suddenly dropps and then i have to reboot the device to fix this. The wifi connection itself seems to be fine at this moment (i can see in luci that its connected). I think this is related to this issue: Mon Aug 31 16:27:43 2020 daemon.err uwsgi[1135]: *** has_emperor mode detected (fd: 7) *** Mon Aug 31 16:27:43 2020 daemon.err uwsgi[1135]: [uWSGI] getting INI configuration from /etc/uwsgi/vassals/luci-webui.ini Mon Aug 31 16:27:43 2020 daemon.err uwsgi[1135]: Mon Aug 31 16:27:43 2020 - [emperor] vassal /etc/uwsgi/vassals/luci-webui.ini has been spawned Mon Aug 31 16:27:43 2020 daemon.info uwsgi-luci: *** big endian arch detected *** Mon Aug 31 16:27:43 2020 daemon.info uwsgi-luci: spawned uWSGI master process (pid: 3293) Mon Aug 31 16:27:43 2020 daemon.err uwsgi[1135]: Mon Aug 31 16:27:43 2020 - [emperor] vassal /etc/uwsgi/vassals/luci-webui.ini is ready to accept requests Mon Aug 31 16:27:43 2020 daemon.err uwsgi[1135]: Mon Aug 31 16:27:43 2020 - [emperor] vassal /etc/uwsgi/vassals/luci-webui.ini is now loyal Mon Aug 31 16:27:47 2020 daemon.info uwsgi-luci: luci: accepted login on / for root from ******** Mon Aug 31 16:27:53 2020 daemon.err uwsgi[1135]: *** has_emperor mode detected (fd: 8) *** Mon Aug 31 16:27:53 2020 daemon.err uwsgi[1135]: [uWSGI] getting INI configuration from /etc/uwsgi/vassals/luci-cgi_io.ini Mon Aug 31 16:27:53 2020 daemon.err uwsgi[1135]: Mon Aug 31 16:27:53 2020 - [emperor] vassal /etc/uwsgi/vassals/luci-cgi_io.ini has been spawned Mon Aug 31 16:27:53 2020 daemon.err uwsgi[1135]: Mon Aug 31 16:27:53 2020 - [emperor] vassal /etc/uwsgi/vassals/luci-cgi_io.ini is ready to accept requests More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3315 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 13:07:28 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 17:07:28 +0000 Subject: [FS#3298] Edimax 3G-6200n z OpenWrt 19.07.2 lost settings after reboot or turnoff. It don't create JFFS In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#3298 - Edimax 3G-6200n z OpenWrt 19.07.2 lost settings after reboot or turnoff. It don't create JFFS User who did this - xaibempp at sharklasers.com (xaibempp) ---------- Is there a reason why you dont use the latest openwrt version? Since May2020 there is the 19.07.3 release. Your issue report is from Aug2020. Does 19.07.3 work? Does the 18.06.8 work without issues? ---------- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3298#comment8729 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 13:10:49 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 17:10:49 +0000 Subject: [FS#3316] TP-Link CPE210v1 - kernel issue - kernel trace included into bugreport In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - xaibempp at sharklasers.com (xaibempp) Attached to Project - OpenWrt/LEDE Project Summary - TP-Link CPE210v1 - kernel issue - kernel trace included into bugreport Task Type - Bug Report Category - Kernel Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Very Low Reported Version - Trunk Due in Version - Undecided Due Date - Undecided Details - I have build a Image for TP-Link CPE210v1. OpenWrt SNAPSHOT r14184-eadb1a9437 I can see in dmesg output in luci at every boot following trace: [ 1.145135] ------------[ cut here ]------------ [ 1.149922] WARNING: CPU: 0 PID: 1 at drivers/reset/core.c:556 __reset_control_get_internal+0x15c/0x190 [ 1.159456] Modules linked in: [ 1.162577] CPU: 0 PID: 1 Comm: swapper Not tainted 5.4.52 #0 [ 1.168411] Stack : 80640000 805ed468 00000000 00000000 805ec638 83c2795c 83c282fc 80623ce3 [ 1.176914] 8058e9ac 00000001 807832d8 00000001 00000000 00000001 83c27910 39024192 [ 1.185410] 00000000 00000000 807b0000 00000055 61696e74 00000000 2e342e35 32202330 [ 1.193903] random: fast init done [ 1.197360] 00000055 a3248495 00000000 00027b11 00000000 00000009 00000000 802e6d08 [ 1.205852] 00000009 00000001 00000000 83c7da10 00000000 802fe010 00000000 80780000 [ 1.214344] ... [ 1.216836] Call Trace: [ 1.219344] [] show_stack+0x30/0x100 [ 1.223873] [] __warn+0xc0/0x10c [ 1.228051] [] warn_slowpath_fmt+0x5c/0xac [ 1.233111] [] __reset_control_get_internal+0x15c/0x190 [ 1.239315] [] __of_reset_control_get+0x140/0x1fc [ 1.244991] [] __devm_reset_control_get+0x70/0x108 [ 1.250776] [] ag71xx_mdio_probe+0xbc/0x208 [ 1.255942] [] platform_drv_probe+0x40/0x94 [ 1.261087] [] really_probe+0x104/0x358 [ 1.265883] [] bus_for_each_drv+0x70/0xb0 [ 1.270854] [] __device_attach+0xdc/0x118 [ 1.275827] [] bus_probe_device+0x9c/0xb8 [ 1.280797] [] device_add+0x3e4/0x608 [ 1.285413] [] of_platform_device_create_pdata+0xa8/0x150 [ 1.291789] [] of_platform_bus_create+0x134/0x224 [ 1.297465] [] of_platform_populate+0x78/0xec [ 1.302794] [] ag71xx_probe+0x6e4/0x98c [ 1.307586] [] platform_drv_probe+0x40/0x94 [ 1.312733] [] really_probe+0x104/0x358 [ 1.317531] [] device_driver_attach+0x70/0x98 [ 1.322852] [] __driver_attach+0x60/0x100 [ 1.327816] [] bus_for_each_dev+0x68/0xa4 [ 1.332788] [] bus_add_driver+0x1f0/0x200 [ 1.337752] [] driver_register+0x84/0x148 [ 1.342741] [] ag71xx_module_init+0x2c/0x50 [ 1.347889] [] do_one_initcall+0x7c/0x1dc [ 1.352877] [] kernel_init_freeable+0x158/0x23c [ 1.358391] [] kernel_init+0x10/0xf0 [ 1.362922] [] ret_from_kernel_thread+0x14/0x1c [ 1.368431] ---[ end trace c9bd124b3a38de6d ]--- More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3316 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above. From openwrt-bugs at lists.openwrt.org Mon Aug 31 13:31:57 2020 From: openwrt-bugs at lists.openwrt.org (OpenWrt Bugs) Date: Mon, 31 Aug 2020 17:31:57 +0000 Subject: [FS#3309] MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) In-Reply-To: References: Message-ID: THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task is now closed: FS#3309 - MikroTik LHG 2: eth0 Link speed not properly reported (fixed at 1000 Mbps) User who did this - Adrian Schmutzler (adrianschmutzler) Reason for closing: Fixed Additional comments about closing: Fix merged. More information can be found at the following URL: https://bugs.openwrt.org/index.php?do=details&task_id=3309 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.