Turris Build issueshttps://gitlab.nic.cz/turris/os/build/-/issues2024-03-04T14:05:24+01:00https://gitlab.nic.cz/turris/os/build/-/issues/427PPtP VPN seems broken2024-03-04T14:05:24+01:00Michal HruseckyPPtP VPN seems brokenhttps://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/20https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/20Turris OS 7.0https://gitlab.nic.cz/turris/os/build/-/issues/429Firewall status in LuCI is empty2024-03-04T10:12:20+01:00Michal HruseckyFirewall status in LuCI is emptyAs reported on our forum, firewall statu in LuCI might be empty. This might be some mixup between iptables and nftables firewall, we need to check, but we need to reproduce first.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/27As reported on our forum, firewall statu in LuCI might be empty. This might be some mixup between iptables and nftables firewall, we need to check, but we need to reproduce first.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/27Turris OS 7.0Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/431SDIO WiFi crashing kernel on Turris OS 7.02024-03-04T10:12:33+01:00Michal HruseckySDIO WiFi crashing kernel on Turris OS 7.0We have a report of SDIO WiFi crashing the kernel on Turris OS 7.0, we need to investigate. Firstly, try to repoproduce it, but updating driver to a newer version might be a good idea as well and might be enough.
https://forum.turris.cz...We have a report of SDIO WiFi crashing the kernel on Turris OS 7.0, we need to investigate. Firstly, try to repoproduce it, but updating driver to a newer version might be a good idea as well and might be enough.
https://forum.turris.cz/t/turris-os-7-0-is-in-rc/19755/12Turris OS 7.0https://gitlab.nic.cz/turris/os/build/-/issues/426[TOS 7.x] ssh-copy-id not working when I want to deploy my keys to turris2024-02-21T15:57:51+01:00Štěpán Henek[TOS 7.x] ssh-copy-id not working when I want to deploy my keys to turrisThe key is appended to `/etc/dropbear/authorized_keys` instead of `/root/.ssh/authorized_keys`.
We are not using dropbear on turris, so it is not possible to log in using the key afterwards.The key is appended to `/etc/dropbear/authorized_keys` instead of `/root/.ssh/authorized_keys`.
We are not using dropbear on turris, so it is not possible to log in using the key afterwards.https://gitlab.nic.cz/turris/os/build/-/issues/425[Kernel] [TOS 7.x] DVBSky T330 device with kmod-dvb-usb-dvbsky module causes ...2024-01-05T10:19:22+01:00Štěpán Henek[Kernel] [TOS 7.x] DVBSky T330 device with kmod-dvb-usb-dvbsky module causes kernel panic whenever the dongle is inserted / present at startupIt is present in current TOS 6.X as well. Tested on both omnia and mox.
The dongle is working normally on my local PC and was working in the older version of TOS 6.X.
I can borrow you the dongle if it is necessary.
```
[ 106.984551] u...It is present in current TOS 6.X as well. Tested on both omnia and mox.
The dongle is working normally on my local PC and was working in the older version of TOS 6.X.
I can borrow you the dongle if it is necessary.
```
[ 106.984551] usb 2-1: new high-speed USB device number 2 using xhci-hcd
[ 107.394524] usb 2-1: dvb_usb_v2: found a 'DVBSky T330' in warm state
[ 107.401080] usb 2-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[ 107.410445] dvbdev: DVB: registering new adapter (DVBSky T330)
[ 107.417501] usb 2-1: dvb_usb_v2: MAC address: 00:cc:10:a5:33:0c
[ 107.438110] i2c i2c-9: Added multiplexed i2c bus 10
[ 107.443036] si2168 9-0064: Silicon Labs Si2168-B40 successfully identified
[ 107.449946] si2168 9-0064: firmware version: B 4.0.2
[ 107.463455] 8<--- cut here ---
[ 107.466585] Unable to handle kernel NULL pointer dereference at virtual address 00000008
[ 107.474724] pgd = d61e8870
[ 107.477440] [00000008] *pgd=00000000
[ 107.481043] Internal error: Oops: 5 [#1] SMP ARM
[ 107.485671] Modules linked in: ath9k ath9k_common qcserial pppoe ppp_async iptable_nat dvb_usb_dvbsky ath9k_hw ath10k_pci ath10k_core ath xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT usb_wwan pppox ppp_gee
[ 107.485836] iptable_filter ipt_ECN ip_tables ebtables ebt_vlan ebt_stp ebt_redirect ebt_pkttype ebt_mark_m ebt_mark ebt_limit ebt_among ebt_802_3 dvb_core crc_ccitt compat br_netfilter at24 sch_tbf sch_ingress sch_htb sch_hfsc em_u32 l
[ 107.660709] CPU: 0 PID: 424 Comm: kworker/0:3 Not tainted 5.15.142 #0
[ 107.667168] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 107.673102] Workqueue: usb_hub_wq hub_event
[ 107.677304] PC is at dvb_module_release+0x10/0x24 [dvb_core]
[ 107.682997] LR is at dvbsky_frontend_detach+0x24/0x34 [dvb_usb_dvbsky]
[ 107.689543] pc : [<bf2622c4>] lr : [<bf3dd2d8>] psr: a0000013
[ 107.695824] sp : c1243b30 ip : 00000000 fp : 000005b8
[ 107.701060] r10: c400f218 r9 : fffffdc0 r8 : c400f240
[ 107.706295] r7 : fffffdc0 r6 : c400f000 r5 : c400f7d0 r4 : c4f04400
[ 107.712837] r3 : 00000000 r2 : 000005b8 r1 : 80080004 r0 : c4f04400
[ 107.719379] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 107.726532] Control: 10c5387d Table: 052b004a DAC: 00000051
[ 107.732289] Register r0 information: slab kmalloc-512 start c4f04400 pointer offset 0 size 512
[ 107.740932] Register r1 information: non-paged memory
[ 107.745996] Register r2 information: non-paged memory
[ 107.751058] Register r3 information: NULL pointer
[ 107.755772] Register r4 information: slab kmalloc-512 start c4f04400 pointer offset 0 size 512
[ 107.764410] Register r5 information: slab kmalloc-4k start c400f000 pointer offset 2000 size 4096
[ 107.773310] Register r6 information: slab kmalloc-4k start c400f000 pointer offset 0 size 4096
[ 107.781948] Register r7 information: non-paged memory
[ 107.787010] Register r8 information: slab kmalloc-4k start c400f000 pointer offset 576 size 4096
[ 107.795821] Register r9 information: non-paged memory
[ 107.800883] Register r10 information: slab kmalloc-4k start c400f000 pointer offset 536 size 4096
[ 107.809782] Register r11 information: non-paged memory
[ 107.814932] Register r12 information: NULL pointer
[ 107.819733] Process kworker/0:3 (pid: 424, stack limit = 0xc9f2e57a)
[ 107.826103] Stack: (0xc1243b30 to 0xc1244000)
[ 107.830469] 3b20: c3e62f00 bf3dd2d8 c400f7d0 bf49a2a8
[ 107.838668] 3b40: 00000000 c400f000 c400f7d0 ffffffed 00000000 00000000 fffffdc0 c400f000
[ 107.846866] 3b60: c400f2f8 bf49a5b0 bf3e03e8 00000000 00000000 00000000 c400f000 00000001
[ 107.855063] 3b80: c4f05400 bf49d3e0 bf49b4c0 bf49b5d0 00000000 00000000 c43210b0 d293dc98
[ 107.863261] 3ba0: c0cc1088 c4f05420 bf3df08c bf3e0038 c4f05400 c5697400 bf3e0000 ffffffed
[ 107.871458] 3bc0: c4f05650 c07a30bc c4f05420 00000000 bf3e0038 c4f05420 00000011 c0f99e9c
[ 107.879654] 3be0: 00000000 c06a8298 c0fe15ac bf3e0038 c0fe159c c06a8708 00000001 bf3e0038
[ 107.887851] 3c00: c1243c4c c4f05420 00000000 c06a8c6c 00000000 c1243c4c c06a8bd8 00000000
[ 107.896048] 3c20: 00000000 c06a63bc 00000000 c12bd76c c3f30c38 d293dc98 c4f05420 00000001
[ 107.904244] 3c40: c4f05464 c06a8a20 c5894400 c4f05420 00000001 d293dc98 c0f99d60 c4f05420
[ 107.912442] 3c60: c4f05420 c0f99ed4 c0f90870 c06a7450 c4f05420 00000000 c5697480 c06a4ccc
[ 107.920639] 3c80: c5601800 c5697400 c5601800 c4f05e00 00000007 0000017d eedd6ae0 c4f05e00
[ 107.928836] 3ca0: 00000008 d293dc98 00000008 c4f05400 c4f05650 c0c9a248 c5697480 c0c9a268
[ 107.937033] 3cc0: c4f05650 00000000 c4f05650 c07a1cb0 00000001 00000000 00000000 00000000
[ 107.945231] 3ce0: 00001388 d293dc98 c0cdd2d4 c5781c44 00000001 c101c000 c5697480 c5781c44
[ 107.953429] 3d00: c5697404 c4f0560c c0f99e9c c0f99ed4 c0f9a364 c07a054c c4f05600 00000001
[ 107.961626] 3d20: c5781c40 00000001 00000001 00000004 c4f0564c c0c9a210 c0cc1088 c5697400
[ 107.969822] 3d40: 00000001 c5697400 c5697480 00000011 c0f99d6c c11fbefc 00000000 c07ac830
[ 107.978019] 3d60: c5697480 c0f9a524 c5697400 c07a2464 c5697480 00000000 c0f9a524 c06a8298
[ 107.986217] 3d80: c0fe15ac c0f9a524 c0fe159c c06a8708 00000001 c0f9a524 c1243de4 c5697480
[ 107.994414] 3da0: 00000000 c06a8c6c 00000000 c1243de4 c06a8bd8 00000000 00000000 c06a63bc
[ 108.002610] 3dc0: 00000000 c12bd76c c12b86b8 d293dc98 c5697480 00000001 c56974c4 c06a8a20
[ 108.010807] 3de0: c5781bc0 c5697480 00000001 d293dc98 c0f99d60 c5697480 c5697480 c0f99ed4
[ 108.019005] 3e00: c0f90870 c06a7450 c5697480 00000000 c1ae2880 c06a4ccc c0f90398 c57818c6
[ 108.027202] 3e20: 0000003a c0f903c8 00000001 393831c8 3932313a c05a6600 a0000013 d293dc98
[ 108.035398] 3e40: 0000000c c5697400 c57818c0 c5697480 00000000 c1ae2800 00000001 c11fbefc
[ 108.043595] 3e60: 00000000 c0798fc8 c5697400 c0fe27f8 00000000 00000000 c1ae2800 00000001
[ 108.051792] 3e80: c11fbefc c079a3f0 00000000 00000001 00000000 00000000 000003e8 00000000
[ 108.059989] 3ea0: eedd45c0 c11fbe00 c11fbe85 c101c000 c11fbe34 c11fbe38 c11cbf34 c101c030
[ 108.068186] 3ec0: 00000001 c11cbe00 c1ae2800 c11fbe40 c569763c c1ae28c4 c11cbf34 c11fbc20
[ 108.076384] 3ee0: c1ae2800 c0f99e34 c11cbf34 00000064 00010101 c0e58ec0 00000000 c10cf690
[ 108.084582] 3f00: c1243f4c d293dc98 c4015db8 c11fbefc c194d700 eedd3ac0 eedd9500 00000000
[ 108.092779] 3f20: 00000000 eedd9505 c194d740 c0148290 c1242000 eedd3ac0 00000008 c194d700
[ 108.100976] 3f40: c194d718 eedd3ac0 00000008 eedd3ad8 c0f03d00 eedd3c80 c1242000 c014856c
[ 108.109173] 3f60: c0f0f2bc c0fa9db8 c1071ecc c195dd40 c109a700 c0148508 c194d700 c1242000
[ 108.117370] 3f80: c1071ecc c109a720 00000000 c014fd3c c195dd40 c014fbf4 00000000 00000000
[ 108.125567] 3fa0: 00000000 00000000 00000000 c0100134 00000000 00000000 00000000 00000000
[ 108.133764] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 108.141962] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 108.150172] [<bf2622c4>] (dvb_module_release [dvb_core]) from [<bf3dd2d8>] (dvbsky_frontend_detach+0x24/0x34 [dvb_usb_dvbsky])
[ 108.161631] [<bf3dd2d8>] (dvbsky_frontend_detach [dvb_usb_dvbsky]) from [<bf49a2a8>] (dvb_usb_data_complete_204+0x10c/0x138 [dvb_usb_v2])
[ 108.174021] [<bf49a2a8>] (dvb_usb_data_complete_204 [dvb_usb_v2]) from [<bf49a5b0>] (dvb_usbv2_probe+0x14c/0xb94 [dvb_usb_v2])
[ 108.185446] [<bf49a5b0>] (dvb_usbv2_probe [dvb_usb_v2]) from [<c07a30bc>] (usb_probe_interface+0x98/0x1bc)
[ 108.195130] [<c07a30bc>] (usb_probe_interface) from [<c06a8298>] (really_probe.part.0+0x9c/0x324)
[ 108.204030] [<c06a8298>] (really_probe.part.0) from [<c06a8708>] (driver_probe_device+0x38/0x11c)
[ 108.212927] [<c06a8708>] (driver_probe_device) from [<c06a8c6c>] (__device_attach_driver+0x94/0x108)
[ 108.222084] [<c06a8c6c>] (__device_attach_driver) from [<c06a63bc>] (bus_for_each_drv+0x80/0xd0)
[ 108.230894] [<c06a63bc>] (bus_for_each_drv) from [<c06a8a20>] (__device_attach+0x10c/0x190)
[ 108.239268] [<c06a8a20>] (__device_attach) from [<c06a7450>] (bus_probe_device+0x84/0x8c)
[ 108.247469] [<c06a7450>] (bus_probe_device) from [<c06a4ccc>] (device_add+0x3a0/0x890)
[ 108.255407] [<c06a4ccc>] (device_add) from [<c07a1cb0>] (usb_set_configuration+0x470/0x880)
[ 108.263781] [<c07a1cb0>] (usb_set_configuration) from [<c07ac830>] (usb_generic_driver_probe+0x50/0x8c)
[ 108.273203] [<c07ac830>] (usb_generic_driver_probe) from [<c07a2464>] (usb_probe_device+0x28/0x80)
[ 108.282186] [<c07a2464>] (usb_probe_device) from [<c06a8298>] (really_probe.part.0+0x9c/0x324)
[ 108.290821] [<c06a8298>] (really_probe.part.0) from [<c06a8708>] (driver_probe_device+0x38/0x11c)
[ 108.299717] [<c06a8708>] (driver_probe_device) from [<c06a8c6c>] (__device_attach_driver+0x94/0x108)
[ 108.308876] [<c06a8c6c>] (__device_attach_driver) from [<c06a63bc>] (bus_for_each_drv+0x80/0xd0)
[ 108.317685] [<c06a63bc>] (bus_for_each_drv) from [<c06a8a20>] (__device_attach+0x10c/0x190)
[ 108.326059] [<c06a8a20>] (__device_attach) from [<c06a7450>] (bus_probe_device+0x84/0x8c)
[ 108.334258] [<c06a7450>] (bus_probe_device) from [<c06a4ccc>] (device_add+0x3a0/0x890)
[ 108.342197] [<c06a4ccc>] (device_add) from [<c0798fc8>] (usb_new_device+0x178/0x310)
[ 108.349963] [<c0798fc8>] (usb_new_device) from [<c079a3f0>] (hub_event+0xfec/0x13bc)
[ 108.357729] [<c079a3f0>] (hub_event) from [<c0148290>] (process_one_work+0x20c/0x484)
[ 108.365589] [<c0148290>] (process_one_work) from [<c014856c>] (worker_thread+0x64/0x5b0)
[ 108.373703] [<c014856c>] (worker_thread) from [<c014fd3c>] (kthread+0x148/0x164)
[ 108.381125] [<c014fd3c>] (kthread) from [<c0100134>] (ret_from_fork+0x14/0x20)
[ 108.388367] Exception stack(0xc1243fb0 to 0xc1243ff8)
[ 108.393430] 3fa0: 00000000 00000000 00000000 00000000
[ 108.401628] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 108.409825] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 108.416457] Code: e92d4010 e2504000 08bd8010 e5943058 (e5930008)
[ 108.422700] ---[ end trace f8567559f26cdd8c ]---
[ 108.427405] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[ 108.427418] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[ 108.427426] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[ 108.427440] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[ 108.427446] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[ 108.427453] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[ 108.427459] ath10k_pci 0000:02:00.0: SWBA overrun on vdev 0, skipped old beacon
[ 108.479251] Kernel panic - not syncing: Fatal exception
[ 108.484496] CPU1: stopping
[ 108.487212] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G D 5.15.142 #0
[ 108.494716] Hardware name: Marvell Armada 380/385 (Device Tree)
[ 108.500651] [<c010e9b0>] (unwind_backtrace) from [<c010a69c>] (show_stack+0x10/0x14)
[ 108.508423] [<c010a69c>] (show_stack) from [<c05f3bbc>] (dump_stack_lvl+0x40/0x4c)
[ 108.516015] [<c05f3bbc>] (dump_stack_lvl) from [<c010cbc4>] (do_handle_IPI+0xf8/0x12c)
[ 108.523953] [<c010cbc4>] (do_handle_IPI) from [<c010cc10>] (ipi_handler+0x18/0x20)
[ 108.531542] [<c010cc10>] (ipi_handler) from [<c018484c>] (handle_percpu_devid_irq+0x78/0x13c)
[ 108.540091] [<c018484c>] (handle_percpu_devid_irq) from [<c017e760>] (handle_domain_irq+0x5c/0x78)
[ 108.549077] [<c017e760>] (handle_domain_irq) from [<c01012e4>] (gic_handle_irq+0x7c/0x90)
[ 108.557279] [<c01012e4>] (gic_handle_irq) from [<c0100b7c>] (__irq_svc+0x5c/0x78)
[ 108.564781] Exception stack(0xc1083f60 to 0xc1083fa8)
[ 108.569845] 3f60: 00077fa8 00000000 00000001 c0117c20 c1082000 c0f04f54 00000001 c0f04f98
[ 108.578042] 3f80: 00000000 c0e580a8 00000000 c1083fb8 c107c03c c1083fb0 c01076d0 c01076d4
[ 108.586238] 3fa0: 60000013 ffffffff
[ 108.589733] [<c0100b7c>] (__irq_svc) from [<c01076d4>] (arch_cpu_idle+0x38/0x3c)
[ 108.597152] [<c01076d4>] (arch_cpu_idle) from [<c015f540>] (do_idle+0x1ec/0x258)
[ 108.604573] [<c015f540>] (do_idle) from [<c015f8e0>] (cpu_startup_entry+0x18/0x1c)
[ 108.612164] [<c015f8e0>] (cpu_startup_entry) from [<00101770>] (0x101770)
[ 108.618976] Rebooting in 3 seconds..
```Marek BehunMarek Behunhttps://gitlab.nic.cz/turris/os/build/-/issues/402bash -c exit on Turris 1.x fails with "parse_and_execute: bad jump: 8388608"2023-03-20T10:36:46+01:00Michal Vasilekbash -c exit on Turris 1.x fails with "parse_and_execute: bad jump: 8388608"This issue only happens on Turris 1.x, so it's probably an issue in bash on ppc CPUs. The reports are all from Turris OS 6.x, so this was most likely not an issue in Turris OS 5.x, so it happened somewhere between bash 5.0 and 5.1.
```
r...This issue only happens on Turris 1.x, so it's probably an issue in bash on ppc CPUs. The reports are all from Turris OS 6.x, so this was most likely not an issue in Turris OS 5.x, so it happened somewhere between bash 5.0 and 5.1.
```
root@turris:/# bash -c exit
parse_and_execute: bad jump: 8388608
Aborting...Aborted
```
```
root@turris:/# echo exit > test
root@turris:/# bash ./test
reader_loop: bad jump: 8388608
Aborting...Aborted
```
This may be an upstream OpenWrt issue, but there are no reports about it and it should be tested on OpenWrt.https://gitlab.nic.cz/turris/os/build/-/issues/401TOS 6.0+ Consider creating named bridge for br-lan in initial configuration2023-01-18T16:52:24+01:00Martin MatějekTOS 6.0+ Consider creating named bridge for br-lan in initial configuration## Summary
Initial network config after the first boot includes definition of LAN bridge as anonymous section.
It would be nice if we could have named section for LAN bridge from the beginning - it is easier to work with it from foris-...## Summary
Initial network config after the first boot includes definition of LAN bridge as anonymous section.
It would be nice if we could have named section for LAN bridge from the beginning - it is easier to work with it from foris-controller.
## Details
Initial network config after the first boot includes definition of LAN bridge as anonymous section.
**/etc/config/network**
```
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
```
But after passing through guide there will be two definitions for `br-lan` bridge:
```
config device <--- initial config
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
[...]
config device 'br_lan' <--- br-lan #2
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
```
This is because migration from TOS 5.x to TOS 6.0+ should make transition from one expected configuration to another expected configuration.
I.e. there shouldn't be any discrepancies in configuration and therefore it shouldn't be needed to check `/etc/config/network` that carefully afterwards.
However this assumption works fine only in case of migration from TOS 5.x to TOS 6.0+.
On the other hand, on clean install from medkit, there will eventually be two configuration sections for the same bridge.
So we could:
* (a) Either create the initial configuration the way we want it to be (i.e. the proposal in summary)
* (b) Or adjust foris-controller to check for any conflicting config section on every update.https://gitlab.nic.cz/turris/os/build/-/issues/400TOS 6.0+ Initial network config should use OpenWrt 21.02 syntax2023-01-24T12:34:14+01:00Martin MatějekTOS 6.0+ Initial network config should use OpenWrt 21.02 syntax## Summary
Initial network configuration after first boot results in the mix of old style (OpenWrt 19.07 and older) and new style (OpenWrt 21.02) config.
There is old style `interface` config alongside the new style configuration split...## Summary
Initial network configuration after first boot results in the mix of old style (OpenWrt 19.07 and older) and new style (OpenWrt 21.02) config.
There is old style `interface` config alongside the new style configuration split into `interface` and `device`.
Turris OS based on OpenWrt 21.02 should create initial configuration that uses OpenWrt 21.02 configuration syntax, not the deprecated one.
## Details
Reproducible on Mox ABC with TOS 6.2.1.
I believe that this patch is somehow involved: https://gitlab.nic.cz/turris/os/build/-/blob/hbk/patches/openwrt/wip/0004-mvebu-initial-support-for-MOX-on-5.4-kernel.patch
But I haven't dug deep enough, so I could be wrong about that.
Initial network configuration after first boot (factory reset, reflash from medkit, ...) looks like this.
<details>
<summary>
**/etc/config/network**
</summary>
```
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix '<some prefix>'
config device <--- actual configuration of br-lan bridge
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'wan'
option ifname 'eth0'
option proto 'none'
config interface 'lan'
option type 'bridge' <--- this should not be there, just in device section
option macaddr 'AA:BB:CC:11:22:33'
option ifname 'lan1 lan2 lan3 lan4' <--- deprecated “option ifname”
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option _turris_mode 'managed'
option ip6assign '60'
# it doesn't refer to device 'br-lan' at all
```
</details>
Which network interfaces will be used for bridge `br-lan` depends on the last configuration section that defines either `list ports` or `option ifname`.
<details>
<summary>
So this example config
</summary>
```
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config interface 'lan'
option type 'bridge'
option macaddr 'AA:BB:CC:11:22:33'
option ifname 'lan1 lan3'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option _turris_mode 'managed'
option ip6assign '60'
```
</details>
will result in following network setup:
```sh
root@turris:/# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.d858d700b6ad no lan3
lan1
```
These two conflicting definitions of bridge ports might cause issues later:
* (a) If only one config section of these two is updated (by hand, Luci), the second config section might still override it
* (b) Could cause confusion while reading the TOS diagnostics (e.g. "Why is that config still there?")
* (c) We have to clean the network config on every update from reforis to make sure we have a valid config and don't have the conflicting definitions.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/379TOS 6 hostapd is running even though wifi is not configured or disabled2022-10-20T18:24:16+02:00Martin MatějekTOS 6 hostapd is running even though wifi is not configured or disabledIt is not a high severity bug and as far as I am aware, it doesn't break anything.
I just find it unusual to see that hostapd on TOS 6.0 is started regardless of wireless interfaces configuration, i.e. wifi disabled or not configured.
...It is not a high severity bug and as far as I am aware, it doesn't break anything.
I just find it unusual to see that hostapd on TOS 6.0 is started regardless of wireless interfaces configuration, i.e. wifi disabled or not configured.
On TOS 5.4.4
<details>
<summary>/etc/config/wireless</summary>
```
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option macaddr '<REDACTED>'
option htmode 'VHT80'
option disabled '1'
option country 'CZ'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'Turris'
option encryption 'none'
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option macaddr '<REDACTED>'
option htmode 'HT20'
option disabled '1'
option country 'CZ'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'Turris'
option encryption 'none'
```
</details>
```sh
root@omnia:~# pgrep -fa hostapd
root@omnia:~# <-- no output, no hostapd is running
```
On TOS 6.0
<details>
<summary>/etc/config/wireless</summary>
```
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option macaddr '<REDACTED>'
option htmode 'VHT80'
option disabled '1'
option country 'CZ'
config wifi-iface 'default_radio0'
option device 'radio0'
option network 'lan'
option mode 'ap'
option ssid 'Turris'
option encryption 'none'
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option macaddr '<REDACTED>'
option htmode 'HT20'
option disabled '1'
option country 'CZ'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'Turris'
option encryption 'none'
```
</details>
```sh
root@omnia:/# pgrep -fa hostapd
2259 /usr/sbin/hostapd -s -g /var/run/hostapd/global
```
Hostapd is running either when the previous config from TOS 5.x is used, default config on TOS 6.0 (after wifi reset) is used or wifi is configured, but explicitly disabled.
Something is starting hostapd regardless of the wifi configuration. But at least no wifi Access Point is visible and transmitting - or at least it doesn't happen on my omnia.
---
Feel free to move this issue elsewhere if it doesn't fit turris/os/build.https://gitlab.nic.cz/turris/os/build/-/issues/365gcc 7.4.0 package produces incorrect binaries after SPE float support merge2022-12-15T15:18:57+01:00Simon Borekgcc 7.4.0 package produces incorrect binaries after SPE float support mergeRegression connected to https://gitlab.nic.cz/turris/os/build/-/merge_requests/544
Musl incompatible long double size (128bit, should be 64), incorrect dynamic linker symlink name (missing '-sf' suffix). Uses mpc8540 as default CPU targ...Regression connected to https://gitlab.nic.cz/turris/os/build/-/merge_requests/544
Musl incompatible long double size (128bit, should be 64), incorrect dynamic linker symlink name (missing '-sf' suffix). Uses mpc8540 as default CPU target - should be mpc8548.
Integration of patches used for host gcc 8.4.0 cross-compiler build needed.
(`--enable-obsolete` flag addition will be needed on package update to 8.4.0 - the reason gcc package build currently fails in HBD)Turris OS 6.1.0https://gitlab.nic.cz/turris/os/build/-/issues/364Turris 1.x: freeradius3 package build fails after SPE float support merge2022-08-12T11:38:21+02:00Simon BorekTurris 1.x: freeradius3 package build fails after SPE float support mergeRegression connected to https://gitlab.nic.cz/turris/os/build/-/merge_requests/544
Build fails with `powerpc-openwrt-linux-muslspe-gcc: error: unrecognized command line option '-mfloat'; did you mean '-mfloat128'?`.Regression connected to https://gitlab.nic.cz/turris/os/build/-/merge_requests/544
Build fails with `powerpc-openwrt-linux-muslspe-gcc: error: unrecognized command line option '-mfloat'; did you mean '-mfloat128'?`.Turris OS 6.1.0https://gitlab.nic.cz/turris/os/build/-/issues/342new_release.sh helper considers -v option as illegal2024-02-21T15:43:54+01:00Simon Boreknew_release.sh helper considers -v option as illegal## From new_release.sh help:
```
Usage: ./helpers/new_release.sh [OPTION].. [MODE [BRANCH]]
Turris OS new releases managing tool.
Options:
-v Run script with verbose output
-h Print this help text
Modes:
verify
Run script in...## From new_release.sh help:
```
Usage: ./helpers/new_release.sh [OPTION].. [MODE [BRANCH]]
Turris OS new releases managing tool.
Options:
-v Run script with verbose output
-h Print this help text
Modes:
verify
Run script in verify mode where BRANCH (in default hbk) is checked
for possible release problems. This is default.
...
```
## Expected behaviour:
`./helpers/new_release.sh -v verify` or `./helpers/new_release.sh -v` runs the script in "verify" mode with verbose output.
## Actual behaviour:
The script writes `Illegal option '-v'` to stdout and exits with code 1.
Happens in all branches.https://gitlab.nic.cz/turris/os/build/-/issues/339Suricata is able to eat up whole /tmp space2022-04-06T09:48:30+02:00Karel KociSuricata is able to eat up whole /tmp spaceThe suricata logs to `/var/log/surricata/suricata.log` and that log is not rotated thus it eventually eats up all space in `/tmp`.
In my case it is due to error such as:
```
7/3/2022 -- 13:54:53 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(1...The suricata logs to `/var/log/surricata/suricata.log` and that log is not rotated thus it eventually eats up all space in `/tmp`.
In my case it is due to error such as:
```
7/3/2022 -- 13:54:53 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn't set fanout mode, error Invalid argument
```https://gitlab.nic.cz/turris/os/build/-/issues/334DHCP doesn't assign IPv4 addressed to LAN clients after reboot on Turris 1.x,...2023-01-11T17:11:34+01:00Simon BorekDHCP doesn't assign IPv4 addressed to LAN clients after reboot on Turris 1.x, TOS 5.3.6 ... sometimesinstance of https://gitlab.nic.cz/turris/os/build/-/issues/252
I found no reliable way how to reproduce and no reliable way how to persistently fix the issue when it occurs.
The next reasonable step seems to be finding out, if the issu...instance of https://gitlab.nic.cz/turris/os/build/-/issues/252
I found no reliable way how to reproduce and no reliable way how to persistently fix the issue when it occurs.
The next reasonable step seems to be finding out, if the issue still occurs on TOS 6.0 and look for possible fixes in the context of 6.0 version.
Summary of the information I found follows.
# How to reproduce
Turris 1.x, TOS 5.3.6, default configuration, WiFi set up through Reforis at 2.4 GHz with WPA2, DHCP client on WAN, static IP with DHCP server on LAN
1) switch WiFi to 5 GHz in LuCi, save and apply; or do whatever, then rollback to the snapshot of the initial configuration
2) reboot by disconnecting and reconnecting the power supply or by issuing `reboot` command
* alternatively do whatever, then 2.
I spent a huge amount of time trying to figure out a reliable reproduction method without real success, I originally encountered the problem by just plugging in the router in the morning and connecting a wireless client.
# Expected behavior
* clients connected to LAN (by wire or wirelessly) get proper IPv4 network configuration through DHCP
# Actual behavior
* clients connected to LAN (by wire or wirelessly) obtain no IPv4 configuration, only IPv6 connectivity works
* router itself has IPv4 address assigned and is capable of IPv4 internet communication
* `dnsmasq` on the router is running, but there are no mentions of it in the log obtained by `logread`
* problems usually persist even after router reboot
# How to fix the ocurring problem
* until router reboot:
* SSH using router's IPv6 address, `service restart dnsmasq`
* log output after:
```
...
Mar 9 10:56:15 turris dnsmasq[2095]: started, version 2.80 DNS disabled
Mar 9 10:59:36 turris dnsmasq[2095]: overflow: 2 log entries lost
Mar 9 10:00:01 turris crond[5238]: (root) CMD (/usr/bin/notifier)
Mar 9 10:00:01 turris crond[5239]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:00:01 turris crond[5237]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:00:01 turris crond[5236]: (root) CMDOUT (There is no message to send.)
Mar 9 10:00:01 turris crond[5236]: (root) CMDEND (/usr/bin/notifier)
Mar 9 10:00:39 turris dnsmasq: DNS rebinding protection is active, will discard upstream RFC1918 responses!
Mar 9 10:00:39 turris dnsmasq: Allowing 127.0.0.0/8 responses
Mar 9 11:00:42 turris dnsmasq[5386]: started, version 2.80 DNS disabled
Mar 9 11:00:42 turris dnsmasq[5386]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth nettlehash DNSSEC no-ID loop-detect inotify dumpfile
Mar 9 11:00:42 turris dnsmasq-dhcp[5386]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h
Mar 9 11:00:42 turris dnsmasq-dhcp[5386]: read /etc/ethers - 0 addresses
Mar 9 10:01:01 turris crond[5428]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:01:01 turris crond[5427]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
Mar 9 11:01:08 turris dnsmasq-dhcp[5386]: DHCPDISCOVER(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:01:08 turris dnsmasq-dhcp[5386]: DHCPOFFER(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:01:08 turris dnsmasq-dhcp[5386]: DHCPREQUEST(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:01:08 turris dnsmasq-dhcp[5386]: DHCPACK(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 10:01:09 turris /dhcp_host_domain_ng.py: Refresh unbound leases
...
```
* persistently:
* fix sometimes persisted over reboot, if the reboot is accompanied by restart of the whole local network providing Turris 1.x with internet connectivity (Turris Omnia, TOS 5.3.5 stable), but sometimes, after another Turris 1.x reboot the DHCP server is broken again ... no reliable method to fix persistently known to me at this time
* log output after successful reboot to working state (including the dnsmasq output that is not present on erroneous autostart):
```
...
Mar 9 11:41:11 turris kernel: [ 23.402529] br-lan: port 6(wlan0) entered blocking state
Mar 9 11:41:11 turris kernel: [ 23.407857] br-lan: port 6(wlan0) entered forwarding state
Mar 9 11:41:11 turris kernel: [ 23.420864] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
Mar 9 10:41:11 turris firewall: Reloading firewall due to ifup of wan (eth2)
Mar 9 11:40:57 turris dnsmasq[2095]: started, version 2.80 DNS disabled
Mar 9 11:41:12 turris dnsmasq[2095]: overflow: 2 log entries lost
Mar 9 11:41:12 turris dnsmasq[4728]: started, version 2.80 DNS disabled
Mar 9 11:41:12 turris dnsmasq[4728]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth nettlehash DNSSEC no-ID loop-detect inotify dumpfile
Mar 9 11:41:12 turris dnsmasq-dhcp[4728]: DHCP, IP range 192.168.1.100 -- 192.168.1.249, lease time 12h
Mar 9 11:41:12 turris dnsmasq-dhcp[4728]: read /etc/ethers - 0 addresses
Mar 9 11:41:12 turris dnsmasq-dhcp[4728]: read /etc/ethers - 0 addresses
Mar 9 10:41:16 turris firewall: Reloading firewall due to ifup of wan6 (eth2)
Mar 9 11:41:18 turris dnsmasq-dhcp[4728]: DHCPDISCOVER(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:41:18 turris dnsmasq-dhcp[4728]: DHCPOFFER(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:41:18 turris dnsmasq-dhcp[4728]: DHCPREQUEST(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 11:41:18 turris dnsmasq-dhcp[4728]: DHCPACK(br-lan) 192.168.1.203 70:cd:0d:97:7f:6b
Mar 9 10:41:18 turris /dhcp_host_domain_ng.py: Refresh unbound leases
Mar 9 10:42:01 turris crond[5029]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:42:01 turris crond[5028]: (root) CMDEND (/usr/bin/rainbow_button_sync.sh)
Mar 9 10:42:37 turris firewall: Reloading firewall due to ifupdate of wan6 (eth2)
...
```
## Contents of router's /etc/config/dhcp at the time of occuring problem:
```
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option filterwin2k '0'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option nonegcache '0'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
option nonwildcard '1'
option localservice '1'
option port '0'
config dhcp 'lan'
option interface 'lan'
option start '100'
option limit '150'
option leasetime '12h'
option dhcpv6 'server'
option ra 'server'
list dhcp_option '6,192.168.1.1'
config dhcp 'wan'
option interface 'wan'
option ignore '1'
config odhcpd 'odhcpd'
option maindhcp '0'
option leasefile '/tmp/hosts/odhcpd'
option leasetrigger '/usr/sbin/odhcpd-update'
option loglevel '4'
```https://gitlab.nic.cz/turris/os/build/-/issues/327Rescue mode can't read the medkit with a space in the name2024-03-12T14:01:26+01:00Aleksandr GumroianRescue mode can't read the medkit with a space in the nameI'm not sure where this issue should be placed, but I've encountered an issue during the "Re-flash router from flash drive".
As soon as you have a medkit, which name includes a space in the name, the rescue mode on my Omnia can't recogn...I'm not sure where this issue should be placed, but I've encountered an issue during the "Re-flash router from flash drive".
As soon as you have a medkit, which name includes a space in the name, the rescue mode on my Omnia can't recognize it.
For example, when I download medkits from different branches (HBL/HBS, etc.) from the [repo](https://repo.turris.cz), they have the very same name `omnia-medkit-latest.tar.gz` but my OS will add a suffix to the name `omnia-medkit-latest (1).tar.gz` in case the file was already downloaded earlier.
![image](/uploads/981b29c51a9d7908e8c9ece3872d8fa7/image.png)
From my terminal with a connected device, I see that the rescue mode is waiting for `omnia-medkit-*` on USB, but can't see the medkit with ` (1)` and it's not obvious.
I hope it does make sense, thanks!Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/315OpenVPN 2.4 and OpenVPN 2.5 incompatibility2024-03-11T10:15:41+01:00Josef SchlehoferOpenVPN 2.4 and OpenVPN 2.5 incompatibilityI generated user client configuration on OpenVPN 2.4 (HBK) in reForis and now, I tried to use it on OpenVPN 2.5 server using OpenWrt daily snapshots and it seems that it does not work.
Output:
```
Dec 27 11:26:49 turris openvpn(xxx)[135...I generated user client configuration on OpenVPN 2.4 (HBK) in reForis and now, I tried to use it on OpenVPN 2.5 server using OpenWrt daily snapshots and it seems that it does not work.
Output:
```
Dec 27 11:26:49 turris openvpn(xxx)[13564]: --cipher is not set. Previous OpenVPN version defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--da.
Dec 27 11:26:49 turris openvpn(xxx)[13564]: OpenVPN 2.5.5 aarch64-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Dec 27 11:26:49 turris openvpn(xxx)[13564]: library versions: OpenSSL 1.1.1l 24 Aug 2021, LZO 2.10
Dec 27 11:26:49 turris openvpn(xxx)[13564]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Dec 27 11:26:49 turris openvpn(xxx)[13564]: OpenSSL: error:0909006C:PEM routines:get_name:no start line
Dec 27 11:26:49 turris openvpn(xxx)[13564]: OpenSSL: error:140AD009:SSL routines:SSL_CTX_use_certificate_file:PEM lib
Dec 27 11:26:49 turris openvpn(xxx)[13564]: Cannot load inline certificate file
Dec 27 11:26:49 turris openvpn(xxx)[13564]: Exiting due to fatal error
```Turris OS 7.0https://gitlab.nic.cz/turris/os/build/-/issues/309SNMP identifier is generated with every bootup2021-11-16T16:08:16+01:00Karel KociSNMP identifier is generated with every bootupThe identifier is reportedly not being persistent between reboots.
This was reported by user.The identifier is reportedly not being persistent between reboots.
This was reported by user.Michal HruseckyMichal Hruseckyhttps://gitlab.nic.cz/turris/os/build/-/issues/308Updater changed LAN IP address to default2021-11-12T21:45:39+01:00Stepan RechnerUpdater changed LAN IP address to defaultIt has happened (as reported to support), that after a software update, the LAN address of a device was changed to the default value `192.168.1.1`. Looks like a rare issue that is not easy to reproduce.
Internal links:
* [ticket](https:...It has happened (as reported to support), that after a software update, the LAN address of a device was changed to the default value `192.168.1.1`. Looks like a rare issue that is not easy to reproduce.
Internal links:
* [ticket](https://rt.nic.cz/Ticket/Display.html?id=1321107) with description (_Po 08.lis.2021 10:20:07_) and [diagnostics](https://rt.nic.cz/Ticket/Attachment/14254033/21056836/reporty.zip) - it happened with TOS 5.3 update on one Shield, once with another Shield in the past.
* [discussion in Mattermost](https://mattermost.nic.cz/turris/pl/azb8p39g7jbu5g5yiifkjaae4o)https://gitlab.nic.cz/turris/os/build/-/issues/266turris omnia 5GHz wifi, country set to germany: channel 144 kills wifi02023-05-15T04:37:57+02:00n nturris omnia 5GHz wifi, country set to germany: channel 144 kills wifi0To reproduce:
Turris Omnia Indiegogo edition, flashed with latest medkit (5.2 from HBS).
Minimalist setup as router, country **Germany** after the wizard basically only wifi was configured.
5GHz wifi on wlan0, mode ac, **channel 140**...To reproduce:
Turris Omnia Indiegogo edition, flashed with latest medkit (5.2 from HBS).
Minimalist setup as router, country **Germany** after the wizard basically only wifi was configured.
5GHz wifi on wlan0, mode ac, **channel 140** 80MHz channel width.
Effect: wifi0 doesn't come back up again, chassis led is off. reboot doesn't help. Once in this mode it's easiest to turn wifi0 off, switch it to 2.4GHz, turn it back on and go from there.
To fix: Switch to another channel with no overlap with channel 144, e.g. 136, 149 or 153. Changing the channel width to 20MHz obviously works too, but doesn't seem like a good fix.
Expected behaviour: a warning regarding this (probably country specific) issue + switching to a closeby working channel like 136 or 149
relevant excerpt from /var/log/messages:
```
May 31 02:13:54 turris kernel: [ 1873.286161] ath10k_pci 0000:02:00.0: pdev param 0 not supported by firmware
May 31 02:13:54 turris kernel: [ 1873.307231] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
May 31 02:13:54 turris kernel: [ 1873.330053] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
May 31 02:13:54 turris kernel: [ 1873.337351] br-lan: port 6(wlan0) entered blocking state
May 31 02:13:54 turris kernel: [ 1873.342766] br-lan: port 6(wlan0) entered disabled state
May 31 02:13:54 turris kernel: [ 1873.348247] device wlan0 entered promiscuous mode
May 31 00:13:54 turris hostapd: wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
May 31 00:13:54 turris hostapd: wlan1: interface state COUNTRY_UPDATE->ENABLED
May 31 00:13:54 turris hostapd: wlan1: AP-ENABLED
May 31 00:13:54 turris hostapd: **Channel 144 (secondary) not allowed for AP mode, flags: 0x109 RADAR**
May 31 00:13:54 turris hostapd: wlan0: IEEE 802.11 Configured channel (140) not found from the channel list of current mode (2) IEEE 802.11a
May 31 00:13:54 turris hostapd: wlan0: IEEE 802.11 Hardware does not support configured channel
May 31 00:13:54 turris hostapd: Could not select hw_mode and channel. (-3)
May 31 00:13:54 turris hostapd: wlan0: interface state COUNTRY_UPDATE->DISABLED
May 31 00:13:54 turris hostapd: wlan0: AP-DISABLED
May 31 00:13:54 turris hostapd: wlan0: Unable to setup interface.
May 31 00:13:54 turris hostapd: wlan0: interface state DISABLED->DISABLED
May 31 00:13:54 turris hostapd: wlan0: AP-DISABLED
May 31 00:13:54 turris hostapd: wlan0: CTRL-EVENT-TERMINATING
May 31 00:13:54 turris hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
```Turris OS 6.0https://gitlab.nic.cz/turris/os/build/-/issues/264Throughput issue of WAN->LAN TCP routing (with NAT) on Turris MOX2021-06-03T21:13:14+02:00Martin DeckyThroughput issue of WAN->LAN TCP routing (with NAT) on Turris MOXI am experiencing a strange throughput (performance) issue on my Turris MOX when downloading via TCP (e.g. HTTP, HTTPS) from the Internet. The issue affects many but not all hosts. Here is the network setup where I can deterministically ...I am experiencing a strange throughput (performance) issue on my Turris MOX when downloading via TCP (e.g. HTTP, HTTPS) from the Internet. The issue affects many but not all hosts. Here is the network setup where I can deterministically reproduce the issue:
`[Host A] <---> (Internet) <---> WAN [Turris MOX] LAN <---> [Host B]`
All traffic is IPv4, the MTU is 1500 bytes everywhere, I don't observe any IP packet fragmentation. The connectivity of Host A is 200 Mbps symmetric (WEDOS). The WAN connectivity of the Turris MOX is 300 Mbps symmetric (viaGIA). The Gbit LAN port of the Turris MOX is connected directly to Host B via a short patch cable.
In isolation, the throughput of all the links has been verified both locally and by connecting to a 3rd Host C on the Internet (1 Gbps connectivity, Casablanca) and it is trivial to achieve the nominal speed of download/upload. The issue is not observed when Host C replaces Host A in the setup (but again, the problem is not unique to Host A).
Host A runs the following command:
`nc -4 -k -l -p 4000 < /dev/zero`
Host B runs the following command:
`nc -4 89.221.222.131 4000 > /dev/null`
In other words, Host B connects via TCP (and through NAT routing on Turris MOX) to Host A and Host A sends a stream of zero bytes to Host B via this TCP connection. **The observed download speed fluctuates between 4 Mbps to 8 Mbps instead of being close to the ideal 200 Mbps.**
Further observations:
- Running the receiving command (i.e. `nc 89.221.222.131 4000 > /dev/null`) directly on the Turris MOX yields successfully the ideal download speed of 200 Mbps.
- Running a "relay" on the Turris MOX (i.e. `nc 89.221.222.131 4000 | nc -l -p 4000`) and connecting to this relay directly on Host B (i.e. `nc -4 192.168.168.1 4000 > /dev/null`) also yields a solid download speed of 120 Mbps. This demonstrates that the individual links of the Turris MOX are not saturated.
- Even more strangely and surprisingly, when running the original benchmark between Host A and Host B, it is possible to improve the speed of the A -> B transfer close to 200 Mbps **just by running another TCP transfer between the Turris MOX and Host B at the same time** (i.e. `nc -l -p 4000 < /dev/zero` on the Turris MOX and `nc -4 192.168.168.1 4000 > /dev/null` on Host B)! This "disturbing" TCP connection not only improves the performance of the original TCP connection, but the download speeds appear to be strangely correlated, again close to 200 Mbps. This suggests that the issue might have something to do with interrupt processing on the Turris MOX or something.
Turris MOX: MOX Start (1024 MB, WAN port) + MOX C (LAN ports)
Turris OS: 5.1.10 with kernel 4.14.222 (the same behavior is observed on 5.2.0 with kernel 4.14.229), no non-standard configuration
If you need more information of any kind, I would be happy to provide them.Marek BehunMarek Behun