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.