No one cares about "Switch leak" on many routers

Why do developers Openwrt close eye to the problem "Switch leak"? Some routers have this bug for several years and nobody cares. Although the bug report tickets are created. How can I trust the security of my network to Openwrt, when even such basic problems do not fix? For example, the stock firmware for my router Asus RT-N11P (MT7620N) not have this problem. As well as custom Padavan firmware. I do not understand how the developers could have missed it, so how not to notice it is difficult.

1 Like

I have not read about this do you have some links I can look at

Which tickets?

https://bugs.openwrt.org/index.php?do=details&task_id=612&pagenum=2

https://dev.archive.openwrt.org/ticket/6819

Having looked into this in the past, with consumer-grade switches, this likely can't be prevented as it appears to be a hardware issue. The firmware you mention likely "leaks" as well, though perhaps for a shorter period of time. Unless the switch chips either have NVRAM to retain configuration, or require a GPIO (or similar) to be changed from its power-on state to enable the switch chip's phys, these chips do come up in an active, preconfigured state that typically "leaks".

If this is a significant concern, then use of a router with two (or more) directly-connected phys would be a better option for you.

You might be able to reduce the impact of the power-on configuration of the switch chip by moving the initialization of the switch earlier in the boot process, or adding a pre-configuration step into the boot process. Note that configuration of the switch chip typically "wipes" the current configuration, so you should examine if that is acceptable to you and rewrite the driver if you so desire.

Of course, if you've examined the source code of the devices that you believe do not exhibit this behavior and see something that would be valuable, comments on the active ticket would be helpful, as would be pull requests.

Note that https://dev.archive.openwrt.org is long dead and generally inaccessible due to its untrusted certificate.