RT-AC86U w. Merlin "disconnects" RT-N66R in media bridge mode

[StR]

I have RT-AC86U running Merlin 386.2_2 as my main router. I also have an old RT-N66R that I am using in a media bridge mode, - to connect a few devices in a different room - via Ethernet.
Every so often (from a few days to a few, 1-4, weeks), RT-N66R looses its connection to RT-AC86U. (Reboot of RT-N66R fixes that.) I do not see anything related to this in RT-N66R's logs, but in RT-AC86U's logs, I see the following:
xx:xx:xx:xx:xx:50 - is RT-N66R
xx:xx:xx:xx:xx:E1 - is a desktop ethernet-connected to RT-N66R

Nov 20 12:37:09 dnsmasq-dhcp[3100]: DHCPREQUEST(br0) 192.168.50.195 xx:xx:xx:xx:xx:e1
Nov 20 12:37:09 dnsmasq-dhcp[3100]: DHCPACK(br0) 192.168.50.195 xx:xx:xx:xx:xx:e1 powerhorse
Nov 20 12:37:09 kernel: xx:xx:xx:xx:xx:E1 not mesh client, can't update it's ip
Nov 20 12:37:09 kernel: xx:xx:xx:xx:xx:50 not mesh client, can't update it's ip
Nov 20 12:37:15 kernel: device br0 left promiscuous mode
Nov 20 12:37:16 kernel: device br0 entered promiscuous mode

I wonder if the problem is somehow in the fact that I AC86U tries to use those devices as a mesh device, cannot, and gives up to establish a proper connection?
(I also see occasional log entries with "kernel: xx:xx:xx:xx:xx:xx not mesh client, can't update it's ip" - for other devices, e.g. cell phones.)


Any idea what could the culprit? (Short of RT-N66R dying?)
I wonder if the problem is somehow in the fact that I AC86U tries to use those devices as a mesh device, cannot, and gives up on establishing a proper DHCP connection, leaving RT-N66R hanging in a weird connection state?
(I also see occasional log entries with "kernel: xx:xx:xx:xx:xx:xx not mesh client, can't update it's ip" - for other devices, e.g. cell phones.)
Is there any easy way to disable the mesh mode on AC86U - to see if this issue would go away?



Here is what happens immediately before those log entries, in case it might give an idea of what and why happens:

Nov 20 12:34:13 wlceventd: wlceventd_proc_event(508): eth6: Disassoc xx:xx:xx:xx:xx:54, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 20 12:34:13 wlceventd: wlceventd_proc_event(527): eth6: Auth xx:xx:xx:xx:xx:54, status: Successful (0), rssi:0
Nov 20 12:34:13 wlceventd: wlceventd_proc_event(537): eth6: ReAssoc xx:xx:xx:xx:xx:54, status: Successful (0), rssi:0
Nov 20 12:35:06 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind xx:xx:xx:xx:xx:E1, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Nov 20 12:35:06 wlceventd: wlceventd_proc_event(508): eth6: Disassoc xx:xx:xx:xx:xx:E1, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 20 12:35:07 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind xx:xx:xx:xx:xx:56, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Nov 20 12:35:07 wlceventd: wlceventd_proc_event(508): eth6: Disassoc xx:xx:xx:xx:xx:56, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 20 12:35:07 wlceventd: wlceventd_proc_event(491): eth6: Deauth_ind xx:xx:xx:xx:xx:50, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Nov 20 12:35:07 wlceventd: wlceventd_proc_event(508): eth6: Disassoc xx:xx:xx:xx:xx:50, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 20 12:36:38 wlceventd: wlceventd_proc_event(508): eth6: Disassoc xx:xx:xx:xx:xx:54, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Nov 20 12:37:04 wlceventd: wlceventd_proc_event(527): eth6: Auth xx:xx:xx:xx:xx:54, status: Successful (0), rssi:0
Nov 20 12:37:04 wlceventd: wlceventd_proc_event(556): eth6: Assoc xx:xx:xx:xx:xx:54, status: Successful (0), rssi:0
Nov 20 12:37:04 wlceventd: wlceventd_proc_event(527): eth6: Auth xx:xx:xx:xx:xx:E1, status: Successful (0), rssi:0
Nov 20 12:37:04 wlceventd: wlceventd_proc_event(556): eth6: Assoc xx:xx:xx:xx:xx:E1, status: Successful (0), rssi:0
Nov 20 12:37:07 wlceventd: wlceventd_proc_event(527): eth6: Auth xx:xx:xx:xx:xx:50, status: Successful (0), rssi:0
Nov 20 12:37:07 wlceventd: wlceventd_proc_event(556): eth6: Assoc xx:xx:xx:xx:xx:50, status: Successful (0), rssi:0
Nov 20 12:37:08 kernel: device br0 entered promiscuous mode
Nov 20 12:37:08 wlceventd: wlceventd_proc_event(527): eth6: Auth xx:xx:xx:xx:xx:56, status: Successful (0), rssi:0
Nov 20 12:37:08 wlceventd: wlceventd_proc_event(556): eth6: Assoc xx:xx:xx:xx:xx:56, status: Successful (0), rssi:0
Nov 20 12:37:09 dnsmasq-dhcp[3100]: DHCPREQUEST(br0) 192.168.50.195 xx:xx:xx:xx:xx:e1
Nov 20 12:37:09 dnsmasq-dhcp[3100]: DHCPACK(br0) 192.168.50.195 xx:xx:xx:xx:xx:e1 DESKTOPNAME
Nov 20 12:37:09 kernel: xx:xx:xx:xx:xx:E1 not mesh client, can't update it's ip
Nov 20 12:37:09 kernel: xx:xx:xx:xx:xx:50 not mesh client, can't update it's ip
Nov 20 12:37:15 kernel: device br0 left promiscuous mode
Nov 20 12:37:16 kernel: device br0 entered promiscuous mode

[Edited to clean up accidental double pasting of the logs]

 

[heysoundude]

this is interesting, the log message "not mesh client" - I would suppose that's an Asus logic switch for traffic priority, but I'm probably mistaken.
I can only assume that would come from upstream (Asus) rather than Merlin, so I would actually cross-post this on the stock firmware forum to see what the Asus ppl have to say about it.
I would like to think that the router itself would be able to include the devices connected to the "wireless switch(media bridge)" in its DHCP pool...but I've never tried (or needed to) Media Bridge.
so are there two issues here that you've bumped up against?

 

[StR]

so are there two issues here that you've bumped up against?

I am not quite sure what "two issues" you asked about.

(Are you referring to my posting a few months ago about the scanner-computer connection being lost over time in this setup, and requiring a refresh from the computer side?)

 

[Tech9]

RT-N66R looses its connection to RT-AC86U.

Try older Asuswrt-Merlin 380.66_x firmware for RT-N66U. I found with trial and error every firmware after this release has unstable media bridge mode. Newer Asuswrt base does what you have described - works for a while and then cuts off. Reboot fixes it only temporary. On 380.66_x it's stable. Same thing on similar hardware RT-AC66U MIPS router.

 

[StR]

Thank you, @Tech9! That's helpful! (That info should be in the pinned threads. But, I am guessing, not that many people are using it as a media bridge...)
I hope to have time to play with this in about 2-3 weeks.

Do you remember if there were any critical issues fixed/changed between 380.66_6 and 380.70?
I don't remember, as it's been a while. (I see the changelog, but it has lots of entries over a period of 10 months, so it requires a careful look.)

 

[Tech9]

Try it and see if it works. I remember spending quite some time in experiments. Asus bugged something and never fixed it. This is a media bridge and it doesn't matter what firmware you run on it - no routing there. John's fork may also work, but it has to be loaded using the restoration tool - very slow on N66U. Flash in GUI 380.66_x, reset the router to factory defaults, set it to media bridge and test again.

 

[heysoundude]

I am not quite sure what "two issues" you asked about.

(Are you referring to my posting a few months ago about the scanner-computer connection being lost over time in this setup, and requiring a refresh from the computer side?)

No.
Issue #1 - the determination by the AC86 that your n66 isn't a mesh node. Does that logic preclude the n66 from receiving an IP address?
Issue #2 - is there a problem with Media bridge mode on the n66 that prevents it/connected devices from obtaining an IP from upstream?
@Tech9 suggests that there's a firmware issue on the n66, and I wouldn't be surprised if you found a bug in the firmware for the AC86 (I rather doubt Media Bridge mode is considered to be important by Asus any longer because AiMesh puts wifi everywhere easily, and everything is wifi enabled...)

 

[Tech9]

@Tech9 suggests that there's a firmware issue on the n66

I believe so. I was about to use one of those as Wi-Fi bridge to my VoIP. Only 380.66_x was stable and it was connecting to non-Asus AP's and my ISP modem/router. The issue must be in N66U firmware. Well, it never worked well as VoIP bridge and was replaced later with a different hardware.