What's new

[Release] Asuswrt-Merlin 384.9 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Is this DHCP issue related to the one discussed in this thread:
https://www.snbforums.com/threads/rt-ac68u-in-media-bridge-mode-responding-to-dhcp-requests.48259/
and this thread:
https://www.snbforums.com/threads/rt-ac68p-in-media-bridge-mode-dhcp-dnsmasq-problems.49576/?

Should I take this to mean this issue exists with Asus Official FW as well?
Yes; however I now believe this is not specifically an Asus issue and more of a transparent client bridge issue that can negatively affect stability. Short version, the Asus implementation of Media Bridge attempts to be a transparent bridge (ARP-NAT), where the clients connected beyond the MB appear to be on the same network and the MAC addresses appear as the original unique address of each device. With a single MB and a max of 4-8 clients depending on which router is in MB mode, this isn't an issue; once you add an AP or switch connected, which increases the number of clients, the ARP-NAT fails at some point resulting in DHCP not making it to the MB connected devices.

The stability I've had with DD-WRT is because Client Bridge in this firmware does not function as a transparent client bridge, meaning each device shares the MAC address of the MB or shows as <incomplete> alternatively from the primary router, which issues DHCP:
Code:
ASUSWRT-Merlin RT-AC86U 384.9-0 Sat Feb  2 18:20:05 UTC 2019
RootLess (192.168.50.96) at <incomplete>  on br0
Tesla_Model_3 (192.168.50.25) at xx:xx:xx:ba:d9:c3 [ether]  on br0
amazon-eac7b2661 (192.168.50.50) at 1c:87:2c:4a:d0:aa [ether]  on br0
penguin22-pc (192.168.50.26) at <incomplete>  on br0
Macbook2016-2 (192.168.50.125) at <incomplete>  on br0
? (192.168.50.241) at 1c:87:2c:4a:d0:aa [ether]  on br0
Wandas-iPad (192.168.50.93) at ac:3c:0b:20:cb:66 [ether]  on br0
BedroomEcho (192.168.50.23) at <incomplete>  on br0
SmartThings (192.168.50.8) at 1c:87:2c:4a:d0:aa [ether]  on br0
kindle-ccb98e01f (192.168.50.169) at <incomplete>  on br0
Marys-Galaxy-S8 (192.168.50.99) at 1c:87:2c:4a:d0:aa [ether]  on br0
DESKTOP-6RTJVKN (192.168.50.24) at <incomplete>  on br0
FireTVStick (192.168.50.16) at 00:bb:3a:49:d2:09 [ether]  on br0
amazon-d70ca7b8b (192.168.50.75) at <incomplete>  on br0
? (192.168.50.53) at <incomplete>  on br0
FireTV (192.168.50.13) at 1c:87:2c:4a:d0:aa [ether]  on br0
Davids-Galaxy-S9 (192.168.50.100) at 1c:87:2c:4a:d0:aa [ether]  on br0
LAPTOP-NPHEF1JD (192.168.50.178) at <incomplete>  on br0
AMUSPCTLSB1 (192.168.50.29) at 1c:87:2c:4a:d0:aa [ether]  on br0
SAMSUNG-SM-G920V (192.168.50.35) at <incomplete>  on br0
Google-Home-Mini (192.168.50.22) at <incomplete>  on br0
amazon-75d555366 (192.168.50.208) at fc:a1:83:fe:70:a1 [ether]  on br0
amazon-a000b2e69 (192.168.50.205) at <incomplete>  on br0
? (192.168.50.3) at 1c:87:2c:4a:d0:aa [ether]  on br0
? (192.168.50.36) at <incomplete>  on br0
LivingRoomEcho (192.168.50.19) at 1c:87:2c:4a:d0:aa [ether]  on br0
EchoShow (192.168.50.12) at 1c:87:2c:4a:d0:aa [ether]  on br0
RT-AC68P (192.168.50.4) at 1c:87:2c:4a:d0:aa [ether]  on br0
 
Last edited:
Yes; however I now believe this is not specifically an Asus issue and more of a transparent client bridge issue that can negatively affect stability. Short version, the Asus implementation of Media Bridge attempts to be a transparent bridge (ARP-NAT), where the clients connected beyond the MB appear to be on the same network and the MAC addresses appear as the original unique address of each device. With a single MB and a max of 4-8 clients depending on which router is in MB mode, this isn't an issue; once you add an AP or switch connected, which increases the number of clients, the ARP-NAT fails at some point resulting in DHCP not making it to the MB connected devices.

The stability I've had with DD-WRT is because Client Bridge in this firmware does not function as a transparent client bridge, meaning each device shares the MAC address of the MB or shows as <incomplete> alternatively from the primary router, which issues DHCP:
Code:
ASUSWRT-Merlin RT-AC86U 384.9-0 Sat Feb  2 18:20:05 UTC 2019
P365admin1@RT-AC86U:/tmp/home/root# arp -a
RootLess (192.168.50.96) at <incomplete>  on br0
Tesla_Model_3 (192.168.50.25) at 04:4e:af:ba:d9:c3 [ether]  on br0
amazon-eac7b2661 (192.168.50.50) at 1c:87:2c:4a:d0:aa [ether]  on br0
penguin22-pc (192.168.50.26) at <incomplete>  on br0
Macbook2016-2 (192.168.50.125) at <incomplete>  on br0
? (192.168.50.241) at 1c:87:2c:4a:d0:aa [ether]  on br0
Wandas-iPad (192.168.50.93) at ac:3c:0b:20:cb:66 [ether]  on br0
BedroomEcho (192.168.50.23) at <incomplete>  on br0
SmartThings (192.168.50.8) at 1c:87:2c:4a:d0:aa [ether]  on br0
kindle-ccb98e01f (192.168.50.169) at <incomplete>  on br0
Marys-Galaxy-S8 (192.168.50.99) at 1c:87:2c:4a:d0:aa [ether]  on br0
DESKTOP-6RTJVKN (192.168.50.24) at <incomplete>  on br0
FireTVStick (192.168.50.16) at 00:bb:3a:49:d2:09 [ether]  on br0
amazon-d70ca7b8b (192.168.50.75) at <incomplete>  on br0
? (192.168.50.53) at <incomplete>  on br0
FireTV (192.168.50.13) at 1c:87:2c:4a:d0:aa [ether]  on br0
Davids-Galaxy-S9 (192.168.50.100) at 1c:87:2c:4a:d0:aa [ether]  on br0
LAPTOP-NPHEF1JD (192.168.50.178) at <incomplete>  on br0
AMUSPCTLSB1 (192.168.50.29) at 1c:87:2c:4a:d0:aa [ether]  on br0
SAMSUNG-SM-G920V (192.168.50.35) at <incomplete>  on br0
Google-Home-Mini (192.168.50.22) at <incomplete>  on br0
amazon-75d555366 (192.168.50.208) at fc:a1:83:fe:70:a1 [ether]  on br0
amazon-a000b2e69 (192.168.50.205) at <incomplete>  on br0
? (192.168.50.3) at 1c:87:2c:4a:d0:aa [ether]  on br0
? (192.168.50.36) at <incomplete>  on br0
LivingRoomEcho (192.168.50.19) at 1c:87:2c:4a:d0:aa [ether]  on br0
EchoShow (192.168.50.12) at 1c:87:2c:4a:d0:aa [ether]  on br0
RT-AC68P (192.168.50.4) at 1c:87:2c:4a:d0:aa [ether]  on br0
Tesla_Model_3 :D
 
Last edited:
Hello,
Where is aimesh option? I don't find it.
Capture d'écran-1.jpg
 
When I updated my AC88U to 384.9 LAN ports 5-8 stopped functioning. Devices attached to these ports lost the ability to get IP addresses, etc. I had to unplug the router (rather than restart it in the GUI) to get them to function again.

I realize ports 5-8 are a separate switch inside the router and that the loss of functionality with the firmware update may be coincidental, but this is the first time this has occurred - firmware update or not.
 
When I updated my AC88U to 384.9 LAN ports 5-8 stopped functioning. Devices attached to these ports lost the ability to get IP addresses, etc. I had to unplug the router (rather than restart it in the GUI) to get them to function again.

I realize ports 5-8 are a separate switch inside the router and that the loss of functionality with the firmware update may be coincidental, but this is the first time this has occurred - firmware update or not.

It has happened before to other users, the switch seems to fail properly initializing. An electrical reset will bring it back.
 
Oh that's a shame ... :(

in case you wonder why so many would rather enjoy merlin+apps than asus+aimesh

https://www.smallnetbuilder.com/wireless/wireless-reviews/33208-asus-aimesh-reviewed

bottom line is that the data show that AiMesh, at least in its current form, isn't up to managing STAs and backhaul connections when both use the same pair of radios in each mesh node. And worse, AiMesh doesn't use Ethernet backhaul effectively ... it will give you worse performance than manually converting the routers to Access Points and configuring them yourself.

Paulo, try not to turn this specific issue support thread into further aimesh discussions as it's been discussed ad nauseum on many older threads on this forum, simply do a search to enlighten yourself further - thanks.
 
Yes; however I now believe this is not specifically an Asus issue and more of a transparent client bridge issue that can negatively affect stability. Short version, the Asus implementation of Media Bridge attempts to be a transparent bridge (ARP-NAT), where the clients connected beyond the MB appear to be on the same network and the MAC addresses appear as the original unique address of each device. With a single MB and a max of 4-8 clients depending on which router is in MB mode, this isn't an issue; once you add an AP or switch connected, which increases the number of clients, the ARP-NAT fails at some point resulting in DHCP not making it to the MB connected devices.

The stability I've had with DD-WRT is because Client Bridge in this firmware does not function as a transparent client bridge, meaning each device shares the MAC address of the MB or shows as <incomplete> alternatively from the primary router, which issues DHCP:
I have not used DD-WRT in recent years, but I recall having had issues using its Client Bridge mode because of the MAC addresses of the Bridge's clients get replaced ("NATted") with the Bridge's MAC address -- I just couldn't get more than one active client connected and reachable at any given time.

My understanding is with Transparent Bridging there is no NATting of the MAC addresses of the Bridge's clients, so the problem with Asus Media Bridge is probably because the Bridge's DHCP server is somehow active even though it should not be as surmised in those two referenced threads.
 
Today detected a Samsung Galaxy Note phone in my household kept on switching between 2.4GHz (eth5) and 5GHz (eth6).

Feb 12 06:34:52 WLCEVENTD: eth6: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:34:54 WLCEVENTD: eth5: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:04 WLCEVENTD: eth5: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:04 WLCEVENTD: eth6: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:12 WLCEVENTD: eth6: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:19 WLCEVENTD: eth5: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:29 WLCEVENTD: eth5: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:29 WLCEVENTD: eth6: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:38 WLCEVENTD: eth6: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:38 WLCEVENTD: eth5: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:54 WLCEVENTD: eth5: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:54 WLCEVENTD: eth6: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:36:03 WLCEVENTD: eth6: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:36:09 WLCEVENTD: eth5: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:36:19 WLCEVENTD: eth5: Disassoc EC:1F:72:XX:XX:XX
.
.
.

And found this discussion from Google search:
https://forums.androidcentral.com/s...-s5-switches-5ghz-2-4ghz-every-5-seconds.html

Anyone using Samsung phone experiencing the same problem?

(As I mentioned, the WLCEVENTD highlighted existing WiFi problem with certain device, which might remain undetected without the log showing the issue.)
 
Today detected a Samsung Galaxy Note phone in my household kept on switching between 2.4GHz (eth5) and 5GHz (eth6).

Feb 12 06:34:52 WLCEVENTD: eth6: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:34:54 WLCEVENTD: eth5: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:04 WLCEVENTD: eth5: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:04 WLCEVENTD: eth6: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:12 WLCEVENTD: eth6: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:19 WLCEVENTD: eth5: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:29 WLCEVENTD: eth5: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:29 WLCEVENTD: eth6: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:38 WLCEVENTD: eth6: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:38 WLCEVENTD: eth5: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:35:54 WLCEVENTD: eth5: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:35:54 WLCEVENTD: eth6: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:36:03 WLCEVENTD: eth6: Disassoc EC:1F:72:XX:XX:XX
Feb 12 06:36:09 WLCEVENTD: eth5: Assoc EC:1F:72:XX:XX:XX
Feb 12 06:36:19 WLCEVENTD: eth5: Disassoc EC:1F:72:XX:XX:XX
.
.
.

And found this discussion from Google search:
https://forums.androidcentral.com/s...-s5-switches-5ghz-2-4ghz-every-5-seconds.html

Anyone using Samsung phone experiencing the same problem?

(As I mentioned, the WLCEVENTD highlighted existing WiFi problem with certain device, which might remain undetected without the log showing the issue.)
I get those from an iPhone, Apple watch, Pixel 2 XL, LG Watch Sport, Nexus 6, Huawei watch 1, Nexus 7, Kindle paperwhite, TP Link smart lights, Google Home Mini, Google Home Max, literally every wifi device I have connected to my network. all are 5G except the three TP Link bulbs, and none of them are switching networks.

Most of these event wireless client events are wakeup (Assoc) to see if they have commands, then sleep (Disassoc). I see those when devices leave home and later return. It is the wireless daemon logging events. Yes new in syslog, but I like the info rather than it being hidden behind the manufacturer "hidden" curtain
 
I'd be interested in hearing from anyone who has used 384.9_0 in Media Bridge mode.
I loaded 384.9 in MB mode last week, but after about 12 hours, DHCP stopped functioning for clients connected through the MB (using an AP connected through one of the LAN ports to extend wireless on unique channels). This was consistent with all versions prior and is reportedly an issue with how the MAC address table is built and communicated to and from the router. Effectively, the MB doesn't pass the DHCP address from the router, which is issuing them (visible through trace logs) to the client requesting the IP. The frustrating part is that the client in many cases is still within the client lease time frame, though it loses it's IP and fails to obtain it from the router. The most problematic devices are those that either move in and out of range (e.g. mobile phones and tablets), those that are shut down or put to sleep (laptops and desktops), and anything Amazon :).
 
I will report back later after testing it out; I've decided to reload 384.9 on the AC68P I'm using as a DD-WRT client bridge and will try out WDS. I'm only running on 2.4 GHz on a single 20 MHz channel and won't be connecting any wireless devices on the MB, so may be able to negate the performance hit that typically would occur. I'm curious to see if there is better stability than MB mode with WDS, while also acting as a transparent bridge and allowing the LAN connected AP to function with clients on a single subnet... worst case, I've become really good at loading different firmware and reconfiguring settings ;).
 
I loaded 384.9 in MB mode last week, but after about 12 hours, DHCP stopped functioning for clients connected through the MB (using an AP connected through one of the LAN ports to extend wireless on unique channels). This was consistent with all versions prior and is reportedly an issue with how the MAC address table is built and communicated to and from the router. Effectively, the MB doesn't pass the DHCP address from the router, which is issuing them (visible through trace logs) to the client requesting the IP. The frustrating part is that the client in many cases is still within the client lease time frame, though it loses it's IP and fails to obtain it from the router. The most problematic devices are those that either move in and out of range (e.g. mobile phones and tablets), those that are shut down or put to sleep (laptops and desktops), and anything Amazon :).
I upgraded my RT-AC68P from stock FW (380_7743) to Merlin 384.9_0 (with nvram reset and all) and had the same experience of loss connectivity after ~12 hours, in my case the Bridge's client is a desktop that was put to sleep.

Also an oddity I found is I got a bunch of repeated log messages "kernel: Interface wl0.1 doesn't exist" even though I don't have any Virtual LAN configured.
 
I've been a longtime user of Tomato and switched a couple of releases ago to Merlin after experiencing some wifi weirdness on my RT-AC68U. I'm at 384.9 now and everything has worked smoothly for the last few releases I've flashed. I don't really use AiCloud or Protection and installed entware, Transmission and configured openVPN server.

Just wanted to say thanks and keep up the good work!
 
Also an oddity I found is I got a bunch of repeated log messages "kernel: Interface wl0.1 doesn't exist" even though I don't have any Virtual LAN configured.

This is a Guest network on the 2.4 GHz band.
 

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top