GNUton 388.2 - ZenWifi XT8 - avahi name conflicts

[davidski]

I'm running three ZenWifi XT8s (HW Rev 1.0), all interconnected over Ethernet. The primary node is running GNUton's 388.2 fork, while the two mesh nodes are running the latest ASUS stock firmware. The main node and one mesh works fine, but the third device (running in mesh) has been nothing but problems. Every time I bring that on the network, I start getting name conflicts out of avhai-daemon on the main node and the whole network locks up. I've set, via `nvram set lan_hostname`, unique hostnames on the main and the working mesh node and tried editing the avhai config file on the main node, followed by a mdns restart.

Doing a reset on the nonworking node either brings the node online and starts the hostname issues (not able to get into the problematic node via ssh to do any hostname resetting), or the node fails to come up at all (either goes flashing blue or goes solid red). Any thoughts on what this problem is and how to go about fixing it? I've been pulling my hair out on this. I really need this node in order to get stable 5Ghz coverage in my location.

 

[ColinTaylor]

Errors messages?

 

[davidski]

Just generic avahi-daemon messages such as the following (router) is the name of the primary (working) node:

Oct 15 09:08:59 avahi-daemon[17771]: Host name conflict, retrying with router-2
Oct 15 09:08:59 avahi-daemon[17771]: Host name conflict, retrying with router-3
Oct 15 09:09:00 avahi-daemon[17771]: Host name conflict, retrying with router-4
Oct 15 09:09:01 avahi-daemon[17771]: Host name conflict, retrying with router-5
Oct 15 09:09:02 avahi-daemon[17771]: Host name conflict, retrying with router-6
Oct 15 09:09:03 avahi-daemon[17771]: Host name conflict, retrying with router-7
Oct 15 09:09:04 avahi-daemon[17771]: Host name conflict, retrying with router-8
Oct 15 09:09:05 avahi-daemon[17771]: Host name conflict, retrying with router-9
Oct 15 09:09:06 avahi-daemon[17771]: Host name conflict, retrying with router-10

I've also done a manual firmware restoration on this bad node, using firmware ZENWIFI_XT8_3.0.0.4_388_23285, to no effect.

 

[ColinTaylor]

... and tried editing the avhai config file on the main node, followed by a mdns restart.

That will have no effect becuase restarting mdns will wipe out any changes you made to the config file.

Have you tried turning off avahi completely and then factory resetting the node and re-adding it?

service stop_mdns

 

[davidski]

Have you tried turning off avahi completely and then factory resetting the node and re-adding it?

service stop_mdns

That's a great idea. I've just done that and have been able to get the node online. It's not yet a "solved" moment as I've managed to get to this state before, with the resolution/connectivity issue only popping up later. Resolution shouldn't be an issue (at least with the primary), but I'll run this for a day and see how stable the network is.

Apart from Time Machine, which I'm not using off of the Zens (but am running other MDNS stuff, via Synology and other serviecs), are there downsides to leaving avhai stopped?

 

[davidski]

Well, that didn't last long. Disconnects have returned and the problem node went into RED LED state after a little bit of time. Logs (sligtly redaced) are not very helpful:

Oct 15 11:44:24 wlceventd: wlceventd_proc_event(511): eth4: Disassoc 9C:50:D1:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 11:44:24 wlceventd: wlceventd_proc_event(511): eth4: Disassoc 9C:50:D1:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 11:44:24 wlceventd: wlceventd_proc_event(511): eth4: Disassoc 9C:50:D1:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 11:44:26 wlceventd: wlceventd_proc_event(511): eth4: Disassoc 9C:50:D1:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 11:44:26 wlceventd: wlceventd_proc_event(511): eth4: Disassoc 9C:50:D1:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 11:44:31 wlceventd: wlceventd_proc_event(540): eth6: ReAssoc A4:83:E7:XX:XX:XX, status: Successful (0), rssi:-80
Oct 15 11:45:05 dropbear[7276]: Password auth succeeded for 'XXXXXX' from 192.168.50.11:57588
Oct 15 11:45:12 wlceventd: wlceventd_proc_event(511): eth4: Disassoc F8:C3:CC:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 11:45:12 wlceventd: wlceventd_proc_event(511): eth4: Disassoc F8:C3:CC:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Oct 15 11:46:53 kernel: _enet_arl_write_ext:L3203 Error - can't find the requested ARL entry

I've seen mentions of that "ARL entry" in at least one other thread of mysterious XT8 errors, but no clear identification of what the problem may be.

 

[ColinTaylor]

Apart from Time Machine, which I'm not using off of the Zens (but am running other MDNS stuff, via Synology and other serviecs), are there downsides to leaving avhai stopped?

Time machine and iTunes server are the only things I can think of that would use avahi on the router. Nothing else on your LAN would need it to be running.

Well, that didn't last long. Disconnects have returned and the problem node went into RED LED state after a little bit of time. Logs (sligtly redaced) are not very helpful:

So the problem seems unrelated to avahi. Have you tried using stock firmware on the primary router instead of GNUton?

 

[davidski]

So the problem seems unrelated to avahi. Have you tried using stock firmware on the primary router instead of GNUton?

Agreed. I'm trying to avoid going back to stock as I'm dependent on some of the features in the Merlin/GNUton train - specifically the ability to add CNAMEs persistently to dnsmasq. It's so odd that one mesh node works while the other doesn't that I was hoping someone might have an idea on how to troubleshoot this further. We've eliminated avahi, so that's progress at least!

 

[ColinTaylor]

Are they all identical hardware revisions? Perhaps swap them around, making the troublesome node the primary router running GNUton. Obviously you'd have to manually configure the new router and not upload any previous "save settings" file.

 

[davidski]

I believe they're all the v1 hardware class, though I'd want to verify that and the manufacture date. I know two of them came in a set and one was a later purchase. I'll have to give that a try!