Linksys WRT3200ACM goes completely down after a few hours requiring a full power cycle

jamesmacwhite · September 10, 2020, 7:07am

I'm trying to understand a weird behaviour that's started happening on my Linksys WRT3200ACM. Since yesterday, it has simply stop responding (ping would timeout) and my entire network would go down, this seemed to be happening every few hours. The red lines on this graph show when the router basically stopped working during the day, requiring me to power it off and on again

Maybe it's just coincidence, but each time it happened the duration between seems quite similar. I first thought, it might be the OpenWrt 19.07.4 update, but I ended up dual booting back to 19.07.3 and it still happened so it rules that out. Looking at recent configuration changes, the only thing I have done recently is create a new VLAN with one of the LAN ports to make it a WAN interface for another broadband line I'm having installed next week. In preparation, I have configured the VLAN and setup the network interface configuration with all the information I have in advance. I did have the modem plugged into the LAN2 port, although it doesn't have any upstream connection currently, so it's simply just LAN only right now. However in order to access the modem I needed to create another interface with a static address, so I could access it on the network, without being directly connected to it via an Ethernet cable.

VLAN 3 and 4 are WAN interfaces for other internet connections, VLAN 3 has a 4G modem/router attached, currently 4 has the modem plugged in, without any DSL line currently, so LAN only.

As mentioned, I configured the network interfaces ready:

The connection will use PPPoE and I've already got the username and password information, which I've provided, it will have been trying to connect but obviously with no upstream DSL line currently, it would just error.

When the router has gone down I've noticed the switch indicator light for LAN2 was going off and then coming back on, so whatever causes the complete network lost seems like it's related to the network interfaces.

To test, I've now disabled the eth0.4 (wanb) interfaces on boot to see if it happens again. I just find it strange, that this suddenly happens, but it could only be potentially this config change that's causing it. Do you think this is likely the issue? It just seems strange, but happy for any experts to weigh in on it!

trendy · September 10, 2020, 9:34am

Try a different power supply first. The one you have might be faulty and doesn't provide enough power to the device.

jamesmacwhite · September 10, 2020, 10:37am

Interesting idea. I'm using the original one provided by Linksys that came in the box and it was a new unit, but it is possible. Although, it didn't seem to lose power when it did die, although all network interfaces seemed to be toast, no DHCP or anything, but the LED lights were responsive so not sure it was a kernel panic or complete lock up.

Since either unplugging LAN2/disabling the network interfaces for it, I haven't experienced any issues since, the router hasn't died. So that's interesting.

I may have to look at this again, when my second line gets installed and the network interfaces can be properly enabled. Up until now they will have been sending random TX packets constantly throwing an error, perhaps the amount of these with no upstream DSL causes the issue. It's strange but seems to the only thing I can attribute the strange behaviour with the router just straight up dying. Now however, with interfaces disabled and LAN2 unplugged it seems OK.

Unless it is some power draw problem, that's caused by LAN2 being used.

jamesmacwhite · September 20, 2020, 6:59pm

Actually. It's not fixed and I think I've managed to at least capture something as to why it's happened. Looks like the CPU is halting and it's a general system crash, this causes the router to completely die, won't respond to ping or anything. I'm reverting back to OpenWrt 19.07.3 for now.

Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.903764] INFO: rcu_sched self-detected stall on CPU
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.908933] 	1-...: (1 GPs behind) idle=4c6/2/0 softirq=1024360/1024361 fqs=3000
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.913768] INFO: rcu_sched detected stalls on CPUs/tasks:
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.916446]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.921956]  (t=6002 jiffies g=478593 c=478592 q=2548)
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.923539] 	1-...: (1 GPs behind) idle=4c6/2/0 softirq=1024360/1024361 fqs=3000
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.936205]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.936206] NMI backtrace for cpu 1
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.936209] (detected by 0, t=6002 jiffies, g=478593, c=478592, q=2548)
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.937790] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.195 #0
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.954045] Hardware name: Marvell Armada 380/385 (Device Tree)
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.959992] Function entered at [<c010ebf8>] from [<c010a8b8>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.965849] Function entered at [<c010a8b8>] from [<c063f574>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.971706] Function entered at [<c063f574>] from [<c0644ce8>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.977563] Function entered at [<c0644ce8>] from [<c0644d74>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.983419] Function entered at [<c0644d74>] from [<c0176530>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.989276] Function entered at [<c0176530>] from [<c01758c4>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14199.995133] Function entered at [<c01758c4>] from [<c0178b54>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.000989] Function entered at [<c0178b54>] from [<c0187edc>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.006846] Function entered at [<c0187edc>] from [<c01791d4>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.012703] Function entered at [<c01791d4>] from [<c0179a48>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.018559] Function entered at [<c0179a48>] from [<c010e2e8>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.024416] Function entered at [<c010e2e8>] from [<c016aa18>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.030273] Function entered at [<c016aa18>] from [<c0165c48>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.036129] Function entered at [<c0165c48>] from [<c01661a8>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.041986] Function entered at [<c01661a8>] from [<c0101464>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.047842] Function entered at [<c0101464>] from [<c010b54c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.053699] Exception stack(0xdf4658b0 to 0xdf4658f8)
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.058772] 58a0:                                     dae5cc00 00000014 d3308b34 00000000
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.066986] 58c0: d7a28480 00000014 dae5cc00 00000000 00000014 000005c6 00000000 00000014
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.075199] 58e0: d3308b00 df465900 c057af14 c0524348 40000113 ffffffff
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.081841] Function entered at [<c010b54c>] from [<c0524348>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.087698] Function entered at [<c0524348>] from [<c057af14>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.093555] Function entered at [<c057af14>] from [<c057be94>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.099412] Function entered at [<c057be94>] from [<c057bbd0>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.105268] Function entered at [<c057bbd0>] from [<bf055a60>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.111153] Function entered at [<bf055a60>] from [<bf54da34>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.117010] Function entered at [<bf54da34>] from [<bf53b5cc>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.122867] Function entered at [<bf53b5cc>] from [<bf53e194>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.128724] Function entered at [<bf53e194>] from [<bf53e398>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.134580] Function entered at [<bf53e398>] from [<bf53e53c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.140437] Function entered at [<bf53e53c>] from [<c0539f7c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.146294] Function entered at [<c0539f7c>] from [<c055fc4c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.152150] Function entered at [<c055fc4c>] from [<c053a548>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.158007] Function entered at [<c053a548>] from [<c05dc280>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.163864] Function entered at [<c05dc280>] from [<c05de464>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.169721] Function entered at [<c05de464>] from [<c05dd9b0>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.175577] Function entered at [<c05dd9b0>] from [<c05df2d8>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.181433] Function entered at [<c05df2d8>] from [<c0538dc0>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.187290] Function entered at [<c0538dc0>] from [<c053afd0>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.193147] Function entered at [<c053afd0>] from [<c0620ec4>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.199004] Function entered at [<c0620ec4>] from [<c06213ac>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.204860] Function entered at [<c06213ac>] from [<c0621754>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.210717] Function entered at [<c0621754>] from [<c0538aa0>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.216573] Function entered at [<c0538aa0>] from [<c0539060>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.222430] Function entered at [<c0539060>] from [<c053b394>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.228286] Function entered at [<c053b394>] from [<c0101628>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.234142] Function entered at [<c0101628>] from [<c012d2a4>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.239999] Function entered at [<c012d2a4>] from [<c010d9f8>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.245856] Function entered at [<c010d9f8>] from [<c0101494>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.251712] Function entered at [<c0101494>] from [<c010b54c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.257569] Exception stack(0xdf465f80 to 0xdf465fc8)
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.262642] 5f80: 00000001 00000000 00000000 c01144a0 ffffe000 c0903cb8 c0903c6c 00000000
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.270856] 5fa0: 00000000 414fc091 00000000 00000000 df465fc8 df465fd0 c0107ea8 c0107eac
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.279068] 5fc0: 60000013 ffffffff
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.282569] Function entered at [<c010b54c>] from [<c0107eac>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.288426] Function entered at [<c0107eac>] from [<c015ced4>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.294283] Function entered at [<c015ced4>] from [<c015d1f0>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.300139] Function entered at [<c015d1f0>] from [<0010182c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14200.305998] Sending NMI from CPU 0 to CPUs 1:
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310768] NMI backtrace for cpu 1
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310769] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.195 #0
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310771] Hardware name: Marvell Armada 380/385 (Device Tree)
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310772] task: df43f480 task.stack: df464000
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310773] pc : [<c0524348>]    lr : [<c057af14>]    psr: 40000113
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310774] sp : df465900  ip : d3308b00  fp : 00000014
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310775] r10: 00000000  r9 : 000005c6  r8 : 00000014
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310776] r7 : 00000000  r6 : dae5cc00  r5 : 00000014  r4 : d7a28480
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310777] r3 : 00000000  r2 : d3308b34  r1 : 00000014  r0 : dae5cc00
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310778] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310779] Control: 10c5387d  Table: 1426804a  DAC: 00000051
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310780] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.195 #0
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310782] Hardware name: Marvell Armada 380/385 (Device Tree)
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310783] Function entered at [<c010ebf8>] from [<c010a8b8>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310784] Function entered at [<c010a8b8>] from [<c063f574>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310785] Function entered at [<c063f574>] from [<c0644cd0>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310786] Function entered at [<c0644cd0>] from [<c010dab4>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310787] Function entered at [<c010dab4>] from [<c0101494>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310788] Function entered at [<c0101494>] from [<c010b54c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310789] Exception stack(0xdf4658b0 to 0xdf4658f8)
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310790] 58a0:                                     dae5cc00 00000014 d3308b34 00000000
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310792] 58c0: d7a28480 00000014 dae5cc00 00000000 00000014 000005c6 00000000 00000014
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310793] 58e0: d3308b00 df465900 c057af14 c0524348 40000113 ffffffff
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310794] Function entered at [<c010b54c>] from [<c0524348>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310795] Function entered at [<c0524348>] from [<c057af14>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310796] Function entered at [<c057af14>] from [<c057be94>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310797] Function entered at [<c057be94>] from [<c057bbd0>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310798] Function entered at [<c057bbd0>] from [<bf055a60>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310799] Function entered at [<bf055a60>] from [<bf54da34>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310800] Function entered at [<bf54da34>] from [<bf53b5cc>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310801] Function entered at [<bf53b5cc>] from [<bf53e194>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310802] Function entered at [<bf53e194>] from [<bf53e398>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310803] Function entered at [<bf53e398>] from [<bf53e53c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310804] Function entered at [<bf53e53c>] from [<c0539f7c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310805] Function entered at [<c0539f7c>] from [<c055fc4c>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310806] Function entered at [<c055fc4c>] from [<c053a548>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310807] Function entered at [<c053a548>] from [<c05dc280>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310808] Function entered at [<c05dc280>] from [<c05de464>]
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310809] Function entered at [<c05de464>] fro
Sept 20 19:40:16 linksys-wrt3200acm kernel [14210.310811] Lost 22 message(s)!

trendy · September 20, 2020, 7:56pm

Did you change the power supply already or not?

jamesmacwhite · September 20, 2020, 8:11pm

No, as there hadn't really been any signs of sudden power loss as such. It hadn't happened again after reverting back to OpenWrt 19.07.3 which I had been running for a week or so, until I then tried booting OpenWrt 19.07.4 again earlier and then the same issue started happening within a few hours like before. In syslog I managed to capture what looks to be the reason why it is suddenly doesn't respond though, but what is causing it I have no idea. The device remained fully on and powered throughout, just going unresponsive, now I know it's because of the stall.

I'll have to stay on 19.07.3 again and see if it happens again. I thought it was coincidence that it looked like it was the upgrade, now I'm not sure, given it happened again after switching back the 19.07.4 partition.

kar200 · September 21, 2020, 5:19am

I am curious to know how you can spot this? I have the same device and although I don't have this problem at the moment I was wondering how you would know that it is a power supply issue?

jamesmacwhite · September 21, 2020, 7:22am

Power supplies when they go bad can cause weird issues, like constantly rebooting, if it's not longer providing a consistent amount of voltage and a list of weird things, but I'm not sure it is the power supply in my case, given I've now seen crash output. Looks to me like something kernel related is being triggered by something I have running.

I left it and it seems to "recover" and uptime was still counting up so it hadn't rebooted, but the router kept being completely unresponsive because of the various CPU stalls.

trendy · September 21, 2020, 9:16pm

I experienced the same problems, erratic behavior from the router and with a different power supply it went back to normal operation. The problem is that you cannot measure the power supply under stress easily. If you measure it with a multimeter it will show a healthy value on the output, but when power is consumed it might not keep the voltage steady.

jamesmacwhite · September 21, 2020, 9:30pm

I'll see if I can source a legit replacement power supply to test it and see if it helps. Won't hurt either way to rule it out, should be quiet cheap. Worst case scenario, I've got a spare power supply!

I've noticed that my desktop PC coming out of sleep seems to have directly triggered the erratic behaviour a few times now, but it's not something that can just be reproduced, as for the past 24 hours, it has been fine. So I'm wondering if it's a certain event that may trigger a power draw and then it all kicks off.

b3bis · December 14, 2020, 5:55am

I would like to know if you managed to solve the problem. I got a shinning new such router, flashed it with 19.07.5 and I am experiencing the same issue. I think it has something to do with my VLAN configuration (in addition to my TL-SG108E switch) but I could easily be wrong.

Any advice if you were successful in solving the problem would be highly welcomed.

jamesmacwhite · December 14, 2020, 6:20am

I don't know the exact cause, but I believe the crashes/non responsive nature is due to CPU stalls, I managed to capture some logs of a few:

I've caught the system load going insanely high after about 3-4 hours of up time, which is when the non responsive state starts and believe it to be the CPU stalling out. When this starts there is a small window where the router is responsive and you can get into SSH. When I do this, if I stop mwan3, it seems to stop the issue after a while and when the system load calms down, I can start it again and then everything is normal. If you can get past this weird 3-4 hour mark, the uptime is fine after that:

In terms of my configuration, I am using VLANs as well with mwan3. I have various different network interfaces, L2TP, Wireguard, DHCP etc.

I am unsure why the CPU stalls out, but it didn't start happening on 19.07 initially, until around 19.07.4, but after reverting back to 19.07.3, I did see the same behaviour, so I wonder if it is a combination of packages/configuration. The latest change network/VLAN wise is L2TP with a new VLAN, but I can't be sure that's it.

However, it is interesting you have experienced the same behaviour. VLAN configuration could be a clue. Please let me know your specific setup and maybe it will provide further clues.

I don't believe it to be a power supply issue.

b3bis · December 14, 2020, 6:26am

I neither believe it was a power related issue. For me I am almost (!) sure it is related to VLAN but I am not sure if our problems are the same. Though if I had to consider power supply issues I would first had to look for temperature issues for mine.

None the less, the reason that I say I think it is VLAN related it is that for my case, as it is right now, is that I can reproduce the problem by simply enabling STP. I know this can be an intensive process but I think I left it enough time to complete if that was the issue.

I had STP on, earlier while tinkering with some other things and had no problems, but I did not had all my VLANs set back then, so this could be a blend of settings.

jamesmacwhite · December 14, 2020, 6:29am

This is my VLAN config, ports 3 and 4 are for the additional network interfaces I have with mwan3, maybe it isn't the same issue exactly, but the common factor seems to be VLAN related. That would make sense as the only major change between 19.07 builds is VLAN related for me.

I haven't enabled STP, so possibly not quite the same, potentially though it is likely you are encountering CPU stalls like I am. Ideally if you can get the syslog info i.e. log to a file or remote source when the issue happens, you'll be able to capture a couple to confirm.

All CPU stalls appear to be related to CPU 1, which is where my main WAN port is tagged on by default. All my other VLANs are on CPU 0 which is interesting.

b3bis · December 14, 2020, 6:36am

I am really new to OpenWRT to be honest so I have to see have I will go about setting up that but let me also give you my setup for reference (especially if anybody else wants to have a look):

jamesmacwhite · December 14, 2020, 6:40am

Thanks for sharing, so similar to me you have tagged all other VLANs on CPU 0 and left CPU 1 with the default WAN. All my CPU stalls are being triggered on CPU 1 by the looks of it from the stacktrace output.

In terms of logging, you can change these here:

I have logs go to an external log aggregator service and also write the system log a persistent destination provided by a USB stick, so they aren't lost of a reboot, that's the easiest way to capture persistent logs, doing either of the two.

94121-usr · December 14, 2020, 6:58am

This may be related to your issue.
I have a WRT1900ACSv2 and a WRT3200ACM (both purchased refurbished).
I have some common problems with VLANS and assigned ports.

if I plug in a device to unused port/VLAN, the port light comes on, but no connection. This is intermittent.
if I re-assign the ports to a different VLAN, LUCI will not take and reverts to the original config. This is intermittent, also.
to re-assign ports and VLANS, I must reset to default and reconfigure from scratch.

To get around this problem, I use a smart switch (GS108Ev3) and a VLAN trunk. I don't actually change the VLAN/ports, there are just more ports.

b3bis · December 14, 2020, 6:58am

Yeah actually that was my thought too, so I created a flash disk, had to do some troubleshooting till I remembered that probably an embedded system does not support vfat ( XD ) and was not mounting it but now I think it will log it there. Let's see. I think I could try to force it but I am not sure I can do with the downtime at the moment.

b3bis · December 14, 2020, 7:01am

I also had the thought of buying a second TL-SG108E just to go in front of the router, but buying a 200€ router to then need to buy a new switch just to use 1 port on the router seems in a way counter productive to me, if I have to do all that I may as well return the router.

b3bis · December 14, 2020, 8:03am

So I forced a hang with the 'enabling STP on br-lan' option. This is the log I got, nothing special here:

Mon Dec 14 09:01:47 2020 authpriv.info dropbear[6578]: Exit (root): Exited normally
Mon Dec 14 09:02:19 2020 daemon.notice netifd: Interface 'lan' is now down
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.322083] br-lan: port 1(eth0.1) entered disabled state
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.330209] device eth0.1 left promiscuous mode
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.334838] device eth0 left promiscuous mode
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.339291] br-lan: port 1(eth0.1) entered disabled state
Mon Dec 14 09:02:19 2020 daemon.info dnsmasq[7812]: read /etc/hosts - 4 addresses
Mon Dec 14 09:02:19 2020 daemon.info dnsmasq[7812]: read /tmp/hosts/odhcpd - 0 addresses
Mon Dec 14 09:02:19 2020 daemon.info dnsmasq[7812]: read /tmp/hosts/dhcp.cfg01411c - 9 addresses
Mon Dec 14 09:02:19 2020 daemon.info dnsmasq-dhcp[7812]: read /etc/ethers - 0 addresses
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.381057] IPv6: ADDRCONF(NETDEV_UP): eth0.1: link is not ready
Mon Dec 14 09:02:19 2020 daemon.notice netifd: Interface 'lan' is disabled
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.514399] br-lan: port 1(eth0.1) entered blocking state
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.519831] br-lan: port 1(eth0.1) entered disabled state
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.525442] device eth0.1 entered promiscuous mode
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.530256] device eth0 entered promiscuous mode
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.536848] br-lan: port 1(eth0.1) entered blocking state
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.542302] br-lan: port 1(eth0.1) entered listening state
Mon Dec 14 09:02:19 2020 kern.info kernel: [ 5499.547898] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
Mon Dec 14 09:02:19 2020 daemon.notice netifd: Interface 'lan' is enabled
Mon Dec 14 09:02:19 2020 daemon.notice netifd: Interface 'lan' is setting up now
Mon Dec 14 09:02:19 2020 daemon.notice netifd: Interface 'lan' is now up
Mon Dec 14 09:02:19 2020 daemon.notice netifd: bridge 'br-lan' link is down
Mon Dec 14 09:02:19 2020 daemon.notice netifd: Interface 'lan' has link connectivity loss
Mon Dec 14 09:02:19 2020 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Mon Dec 14 09:02:20 2020 daemon.err odhcpd[1837]: Failed to send to ff02::1%lan@br-lan (Address not available)
Mon Dec 14 09:02:20 2020 daemon.info dnsmasq[7812]: read /etc/hosts - 4 addresses
Mon Dec 14 09:02:20 2020 daemon.info dnsmasq[7812]: read /tmp/hosts/odhcpd - 0 addresses
Mon Dec 14 09:02:20 2020 daemon.info dnsmasq[7812]: read /tmp/hosts/dhcp.cfg01411c - 9 addresses
Mon Dec 14 09:02:20 2020 daemon.info dnsmasq-dhcp[7812]: read /etc/ethers - 0 addresses
Mon Dec 14 09:02:21 2020 kern.info kernel: [ 5501.611288] br-lan: port 1(eth0.1) entered learning state
Mon Dec 14 09:02:23 2020 kern.info kernel: [ 5503.701994] br-lan: port 1(eth0.1) entered forwarding state
Mon Dec 14 09:02:23 2020 kern.info kernel: [ 5503.707593] br-lan: topology change detected, propagating
Mon Dec 14 09:02:23 2020 kern.info kernel: [ 5503.713143] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
Mon Dec 14 09:02:23 2020 daemon.notice netifd: bridge 'br-lan' link is up
Mon Dec 14 09:02:23 2020 daemon.notice netifd: Interface 'lan' has link connectivity
Mon Dec 14 09:02:24 2020 daemon.err odhcpd[1837]: Failed to send to ff02::1%lan@br-lan (Address not available)
Mon Dec 14 09:02:25 2020 daemon.info dnsmasq[7812]: read /etc/hosts - 4 addresses
Mon Dec 14 09:02:25 2020 daemon.info dnsmasq[7812]: read /tmp/hosts/odhcpd - 0 addresses
Mon Dec 14 09:02:25 2020 daemon.info dnsmasq[7812]: read /tmp/hosts/dhcp.cfg01411c - 9 addresses
Mon Dec 14 09:02:25 2020 daemon.info dnsmasq-dhcp[7812]: read /etc/ethers - 0 addresses
Mon Dec 14 09:03:44 2020 daemon.info dnsmasq-dhcp[7812]: DHCPREQUEST(br-lan) 172.16.0.245 30:fd:**:**:**:**
Mon Dec 14 09:03:44 2020 daemon.info dnsmasq-dhcp[7812]: DHCPACK(br-lan) 172.16.0.245 30:fd:**:**:**:** Google-Home-Mini
Mon Dec 14 09:03:49 2020 daemon.notice netifd: Interface 'lan' is now down
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.442282] br-lan: port 1(eth0.1) entered disabled state
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.450613] device eth0.1 left promiscuous mode
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.455191] device eth0 left promiscuous mode
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.459651] br-lan: port 1(eth0.1) entered disabled state
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.473242] IPv6: ADDRCONF(NETDEV_UP): eth0.1: link is not ready
Mon Dec 14 09:03:49 2020 daemon.notice netifd: Interface 'lan' is disabled
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.613881] br-lan: port 1(eth0.1) entered blocking state
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.619317] br-lan: port 1(eth0.1) entered disabled state
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.624913] device eth0.1 entered promiscuous mode
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.629731] device eth0 entered promiscuous mode
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.635303] br-lan: port 1(eth0.1) entered blocking state
Mon Dec 14 09:03:49 2020 kern.info kernel: [ 5589.640736] br-lan: port 1(eth0.1) entered forwarding state
Mon Dec 14 09:03:49 2020 daemon.notice netifd: Interface 'lan' is enabled
Mon Dec 14 09:03:49 2020 daemon.notice netifd: Interface 'lan' is setting up now
Mon Dec 14 09:03:49 2020 daemon.notice netifd: Interface 'lan' is now up
Mon Dec 14 09:03:49 2020 user.notice firewall: Reloading firewall due to ifup of lan (br-lan)
Mon Dec 14 09:03:50 2020 daemon.err odhcpd[1837]: Failed to send to ff02::1%lan@br-lan (Address not available)
Mon Dec 14 09:03:50 2020 daemon.info dnsmasq[7812]: read /etc/hosts - 4 addresses
Mon Dec 14 09:03:50 2020 daemon.info dnsmasq[7812]: read /tmp/hosts/odhcpd - 0 addresses
Mon Dec 14 09:03:50 2020 daemon.info dnsmasq[7812]: read /tmp/hosts/dhcp.cfg01411c - 9 addresses
Mon Dec 14 09:03:50 2020 daemon.info dnsmasq-dhcp[7812]: read /etc/ethers - 0 addresses
Mon Dec 14 09:04:41 2020 daemon.info dnsmasq-dhcp[7812]: DHCPDISCOVER(br-lan) c0:ee:fb:**:**:**
Mon Dec 14 09:04:41 2020 daemon.info dnsmasq-dhcp[7812]: DHCPOFFER(br-lan) 172.16.0.206 c0:ee:**:**:**:**
Mon Dec 14 09:04:41 2020 daemon.info dnsmasq-dhcp[7812]: DHCPREQUEST(br-lan) 172.16.0.206 c0:ee:**:**:**:**
Mon Dec 14 09:04:41 2020 daemon.info dnsmasq-dhcp[7812]: DHCPACK(br-lan) 172.16.0.206 c0:ee:**:**:**:** Unknown

Nothing at all. But nothing was working either.