WL1.1 drops, and upon restart attempt, all LAN interfaces lose internet connectivity (when WL1.1 is enabled and mapped to VLAN )

[AnotherEndUser]

Firmware 2021.7 K26ARM USB AIO-64K on Asus RT-AC56U
Used / Total NVRAM: 37.68 KB / 64.00 KB (58.88%) / -->26.32 Free
Config:
(WL0 2.4g) is an SSID for IOTs, mapped to first VLAN ( BR1 )
(WL1 / 5G) is the primary SSID mapped to LAN (BR0)
(WL1.1 / 5G) is for Guest wireless, mapped to second VLAN (BR2)
Upon first configuring, everything works without issue until at some point WL1.1 will drop. Status shows as down from admin console. At this point wired LAN, WL0 and WL1 devices still have internet connectivity. If an attempt is made to disable / re-enable WL1.1 / restart services, internet connectivity then ceases from all remaining LAN interfaces (wired LAN, WL0 and WL1)
WAN0 connectivity is still up, as evidenced by continuing log entries of external WAN traffic being dropped by firewall.
Additionally in the log is a recurring Stubby error of “No valid transports” It is more than DNS that is broken though. Attempts to directly ping external IP ( i.e. 1.1.1.1 ) results in “Destination unreachable” error.
If the router power-cycled or restarted ( with WL1.1 enabled) the issue persists.
If the WL1.1 interface is disabled and the router is restarted, connectivity is again functional for other LAN interfaces. If WL1.1 is re-enabled, issue will repeat once wl1.1 again drops.
Note that prior to this FW version, the router was on 2021.5 with the above configuration ( without the issue).

To confirm, in testing, NVRAM was cleared, router powered off, and configuration was redone from scratch. Immediately reproducible.
Also to confirm, the initial flash to 2021.7 was properly done per FreshTomato instructions.
Thank you in advance for your time and any suggestions on this issue.

[M_ars]

Hi

can you describe a little more your setup?

Do you use CTF ?

Do you use EMF ? More / other functions ?

if you have time you could test a daily build 01-12-2021 (only VPN images)

https://bitbucket.org/M_ars/freshtomato-arm/downloads/

[AnotherEndUser]

Hi @M_ars ,
Thank you for the reply.
CTF is not in use. That setting is disabled.
I am not familiar offhand with any “EMF” setting(s). ( I searched to try to get info.) Are you referring to modifying settings to reduce EMF, such as reduced wireless power or wireless scheduling? If so, the answer is no. Full power and no schedule. Most settings of the router, especially relating to wireless, are default.

The router in question is in active use, so would probably have to wait until a weekend to try flashing to the beta build version you linked.

[AnotherEndUser]

@M_ars - Before attempting to flash to the daily build, a quesiton: Does the VPN version of the firmware really have this much less functionality?
I found the attached feature matrix on Linksysinfo, but not sure if it is applicable or outdated. Thank you.

‌

[M_ars]

see also

https://wiki.freshtomato.org/doku.php/feature_matrix

but - yes, should be correct. VPN vs AIO depends on your use-case.

Right now i can only provide VPN images. You can use the build from 09-12-2021

[Hogwild]

I'm not sure if this is related to an issue I’ve experienced or not.

In my case, I have an Asus RT-AC1900O running FT2021.7 (K26ARM USB VPN-64K).

I haven’t pinpointed exactly what causes the instability, but I do know that

I can’t add any Virtual Wireless networks, without eventually having somewhat similar instability.

If you have further suggestions for testing, I’d appreciate it.

‌

‌

[AnotherEndUser]

@Hogwild - I originally posted this issue and the suggestion was to test with beta firmware and see if the issue could be recreated with the alternate version. I haven’t had the opportunity to flash yet. If you can though, I believe this would be the file needed.
https://bitbucket.org/M_ars/freshtomato-arm/downloads/freshtomato-RT-AC1900P-ARM_NG-2021.7-09122021-VPN-64K.trx

[Hogwild]

AnotherEndUser. Thanks, but I’m confused. The date on that file you linked

to is earlier than the release date of 2021.7 . So, how can that fix the problem?

Unfortunately, I can’t test that right now, because I’m having ongoing ISP

problems. I thought for sure those problems were fixed today, but the

symptoms started again tonight. I might be able to test that in a week or

two, if you can explain to me how it’s later than 2021.7 .

‌

‌

[AnotherEndUser]

@ @Hogwild - the dates for the files here are named in international format ( DAY-Month-Year ) instead of U.S. date format Month-Day-Year. ( The British started that in the early days. )
As such, the file you are looking at …..09122021 was created on December 09, 2021. I believe that update has a fix related to VLAN issues.

[Hogwild]

Thanks again. Is the a list of changes for that release? Is that beta or ??

[AnotherEndUser]

@Hogwild - It is an incremental build that incorporates committed fixes that will go into the next major release.
It may not all make sense if you are not a programmer, but suffice to say that there are changes to resolve VLAN-related issues.
Here is a link to additional information:
https://bitbucket.org/pedro311/freshtomato-arm/commits/9e0e1e8413971a36f4b76bb0f75ba6da3835b985
I am not a developer, so can’t really give you any more information on it. You can flash with the incremental build to test against your issues, and revert to the previous version if needed.

[M_ars]

Hi

is it working with latest FT release / images ?

BR

[thekingofspain]

I believe have the same problem in both 2021.07 and 20121.08. When adding a VLAN the WLAN stops working. I assumed this was an issue with DNS (Stuby). The fix for me was to physically power down and up the router as reseting services and even soft reboots did not correct the issue for me. Note my vlans are bridged and are just for making a named AP be based on frequency and floor to help debug .

Router AP VLAN

Router 1 Wifi24 Wif24_F1

Router 2 WiFi24 Wif24_F2

This is on a pair of R6700v3's

[Hogwild]

m_ars:

No, not yet. I can’t afford to have downtime that often. And from what

I’ve read, 2021.8 doesn’t sound like the esseitnail functions are as stable as I’d

like for everyday use. Maybe when I have time. Did newer builds solve

the above problems for you?

[AnotherEndUser]

Update: Able to recreate issue after flashing to 2021.8, but found additional error and was able to workaround so far.
I flashed from 2021.7 to 2021.8 ( properly with NVRAM clear / power off / flash / settings from scratch)
Configured as:
(WL0 2.4g) is an SSID for IOTs, mapped to first VLAN ( BR1 )
(WL1 / 5G) is the primary SSID mapped to LAN (BR0)
(WL1.1 / 5G) is for Guest wireless, mapped to second VLAN (BR2)
This configuration on the newer 2021.8 firmware worked significantly longer than on 2021.7, however eventually the wireless 1.1 dropped. One new thing I noticed in troubleshooting however was an error notification found on the Virtual Wireless config page. “WL Driver reports…..” ( an alternate MAC address - *See attached screenshot)
I use MAC address cloning to change MACs to random. Oddly though, the error notes that the WL driver reports a MAC address (starts with 02: ) that in no way resembles the actual, or even the randomly specified address.
After changing the MAC for WL 1.1 to the “expected 02:……..” address, everything again worked. Continuing to test to see if there is any recurrence.

On an unrelated note, I did discover a new USB storage bug with the 2021.8 firmware. ( attaching USB thumb drive causes router to crash / reboot / hang ) I will create a separate issue post with details on that.
Regards.

‌

[AnotherEndUser]

Update in conjunction with above post. I changed the MAC address to an arbitrary one to test. After running since last post there was another recurrence of the issue with WL1.1 dropping. I again changed it back to the 02:….. that was listed as the expected “reports” address in the above screenshot and functionality was restored. Seems to be an inherent issue with the WL driver and alternate/ clone MAC addressing.

‌

[AnotherEndUser]

Another update → This is still an issue, but some improvement since flashing to 2021.8. Specifically, although interface WL1.1 drops, the other interfaces now stay up - unlike before, and the frequency of the WL1.1 drop has reduced ( approx 2 days). Once it drops, a MAC address change and subsequent service restart resolves the issue. The screenshoted error above ( from December 27, 2021 ) doesn’t appear with every WL1.1. drop, although MAC address change/ service restart is still the workaround.
Regards.

[Hogwild]

Thanks, that’s helpful. I have my Mom’s RT-AC68U here for a few weeks, and will test 2021.8 on that. I can’t afford downtime on my regular router.

[AnotherEndUser]

I believe i have worked around this issue, after having made two configuration changes. I will detail both but believe that the issue has to do with setting alternate MAC addresses for the LAN / VLANs.
1. Originally I was using completely arbitrary, randomized MACS for each VLAN’d WLs. About 3 weeks ago I tried setting the first 3 octets ( the OUI ) of the MACs to be actual manufacturer-registered. I then randomized the remaining octets. Since doing so there have been no further issue.
I came across this article which in a roundabout way led me to believe the MAC addresses were related to the problem. ( See the linked RFC page in the post below too. )
https://networkengineering.stackexchange.com/questions/62684/why-the-first-octet-of-a-mac-address-always-end-with-a-binary-0
Having at one point received the attached screenshotted error solidified my theory. ( The one thing that still puzzles me though is that the issue only started happening after upgrading firmware to 2021.8 - I never had any such issue on earlier versions. )

2. The second change I made at the same time was actually unintentional. In process of deleting and re-adding the WL1.1 configuration, I inadvertently clicked the WL1.3 tab and making the VLAN that was originally configured as 1.1 now be 1.3 ( leaving 1.1 blank). I am not suggesting this had any effect whatsoever - but documenting it since it was a configuration change.

Thanks to everyone that replied, and regards.

‌

[M_ars]

Hi

About 3 weeks ago I tried setting the first 3 octets ( the OUI ) of the MACs to be actual manufacturer-registered. I then randomized the remaining octets. Since doing so there have been no further issue.

ahh, thx for feedback - that is good to know. The FT default mac config will work without problems.

I personally always leave the first 3 octets alone if i need to adjust the addr

Next FT release will have a correct “working” default button → GUI default and initial mac are the same now!

see https://bitbucket.org/pedro311/freshtomato-arm/commits/10d01fb4e1536dfade9b532a5d6376b93bed0986

BR

‌

[pedro]

@M_ars : so close this one?

[M_ars]

maybe wait a little bit for feedback.

(→ Basically i think can be closed and a note at the wiki would/will be good and help other FT user)

[AnotherEndUser]

Yes, I agree this can be closed as an issue, and that the information could be useful in the Wiki in case any other users ever happened upon a similar config / scenario. Thanks to all that responded.