The case of the slow-to-get-going Ethernet port – Reupen’s blogThe case of the slow-to-get-going Ethernet port<br>22 February 2026 • 4 min read • Tags: #hardware

I have an Asus GT-BE19000 router. When I bought it, I installed the latest<br>firmware version available at the time (which was version 3.0.0.6.102_37899),<br>set the router up and left things in a place where everything was working fine.

A short while later, firmware version 3.0.0.6.102_39110 was released. I<br>typically like to update things and so I installed the update on my router. I<br>soon, however, noticed that I had an odd problem with certain Ethernet ports on<br>the router. Devices connected to the affected ports would take 30 and 60 seconds<br>to get IPv6 and IPv4 addresses respectively via DHCP(v6). Additionally, devices<br>connected to those ports would tend to lose their IPv6 addresses.

I suspected that the problem was related to the firmware update and so I tried<br>downgrading to the old version. The problem indeed went away. I left the router<br>on the old version, hoping that the problem would resolve itself in the next<br>firmware update.

I installed the next update hopefully when it came it a short while later.<br>Sadly, though, the Ether-snail problem was still there. I submitted some<br>feedback via the feedback form in the router’s web interface and downgraded to<br>the old firmware version again. I later tried each subsequent update up to the<br>current version (3.0.0.6.102_39244), but the problem persisted in all of them.

It was starting to feel like this wasn’t a problem that was going to resolve<br>itself. Resetting the router to its default settings didn’t help, and I hadn’t<br>come across any chatter about the problem online. So, I decided to open a<br>support ticket with Asus.

The support section of their UK website had changed since the last time I used<br>it. It offered two contact options: phone support or use a ‘virtual assistant’.<br>I, however, just wanted to open a ticket like I had previously done for other<br>products. Seeing only those two options left me somewhat nonplussed.

I decided to try the ‘virtual assistant’. I selected ‘Technical Support’ from<br>the list of enquiry types the assistant offered. I then had to select from a<br>list of product categories. There was, however, no option for networking<br>products. I selected a different category, hoping I would still get routed<br>somewhere useful. But instead the assistant refused to do anything else,<br>seemingly because support was closed as it was outside office hours.

Having hit a dead end, I tried the phone call option. That one had an option for<br>networking products. After selecting that, it similarly told me that support was<br>closed (‘It’s not service time now’ to use the exact wording). But it also<br>provided a link to contact them by ‘mail’ – a link that takes you to the form to<br>open a support ticket that I was originally looking for.

Once I had got past that hurdle of opening a ticket, the service was actually<br>pretty decent. By that, I mean, the UK support person collected some more<br>details from me, forwarded the problem to their Taiwan office who then tried to<br>reproduce the problem.

The reply from the Taiwan office was that they weren’t able to reproduce the<br>problem and that they wanted me to do some more tests and provide some more<br>details. I haven’t had another reply from them as they’re on holiday for the<br>Lunar New Year. But<br>the fact that they weren’t able to reproduce the problem made me think that<br>there was something specific to my set-up that was a factor.

As I’d already ruled out the router settings, I started to suspect that the<br>problem was related to something connected to the router. I quickly discovered<br>that that was in fact the case – the problem only happened when a machine<br>running<br>TrueNAS Community Edition<br>was connected to one of the router’s Ethernet ports. (If you’re unfamiliar with<br>TrueNAS, it’s a NAS-oriented operating system, now based on Debian but<br>previously based on FreeBSD.)

I had<br>set up a network bridge in TrueNAS<br>(with just one physical network interface added to it) so that I could share the<br>physical network connection with a virtual machine I had set up within TrueNAS.<br>With a bit of testing, I found that my Ethernet problem occurred only when that<br>bridge existed.

That it was taking 30 or 60 seconds to get an IP address and the problem was<br>related to a bridge was the detail needed to get a probable cause out of the<br>internet (or a chatbot, or whatever). That probable cause was the<br>Spanning Tree Protocol (STP),<br>which it turns out TrueNAS enables by default on bridges. There were no options<br>related to STP to be found in the TrueNAS web interface. But a web search<br>brought up an<br>old forum post that mentioned that STP can be disabled via the TrueNAS CLI.

The post was almost four years old, so I didn’t know if it was still relevant.<br>Hoping it was, I SSHed into TrueNAS and ran:

sudo midclt call interface.update INTERFACE_NAME '{"stp": false}'<br>(replacing INTERFACE_NAME with the name of the...