OTBR Integration and multiple Border Routers

[regal sail]

I originally had the OTBR add-on setup as a separate container and when I set that up I also setup the OTBR integration.

I have since removed the OTBR add-on and created two ESP32 border routers but I am not clear what I need to do with the integration.

My first issue is https://github.com/home-assistant/core/issues/160865 (if you have two instances there is simply no way of telling which is which is you ever did need to delete one).

Just wanted to check that this integration essentially adds the "reset border router" and "change channel" options to the menu in the Thread screen? It isn't needed, it just enables that functionality? If I want that functionality on both border routers I need multiple instance of the integration each pointing at the relevant endpoint?

[worn onyx]

the esp-thread-br code has a hardcoded hostname, so if you run two of them they'll fight each-other over the hostname on mdns. I recommend you compile different firmware for each, modified to use different hostnames

that should resolve the issue

the otbr integration provides the reset border router and change channel options, yes, but the main thing it does it lets home assistant retrieve the thread network information (TLV) from the border router so you can send it to your phone to commission matter/thread devices.

[regal sail]

so it is absolutely needed but if you have two border routers on the same network then it only needs one setup to get the TLV right?

[regal sail]

I did but called then esp-ot-br-1 and esp-ot-br-2 which didn't help as mDNS appends a dash number suffix when there is conflict so in HA I now actually see esp-ot-br-2 (which I think is the one I created with -1 and esp-ot-br-3 which I have never set).

I am going to rename them based on MAC address or something but mDNS is a bit of a pain as if it changes IP (my issues started when I moved one from where I flashed it to another port where it was going to live and the IP address changed)

[worn onyx]

changing ip shouldn't matter if you're using mdns? But yeah, mac-based hostname makes sense. No idea why they don't do that by default tbh.

[harsh spear]

@regal sail You can suggest a code change to handle this specific case via a PR.

[regal sail]

but it does as you end up with cached mDNS entries that might not time out so I had

enp1s0.10 IPv6 esp-ot-br-3
  _meshcop._udp        local
  hostname = [esp-ot-br-3.local]
  address = [10.10.10.165]

and also

enp1s0.10 IPv4 esp-ot-br-3
  _meshcop._udp        local
  hostname = [esp-ot-br-3.local]
  address = [10.10.10.163]

but also

enp1s0.10 IPv6 esp-ot-br-2
  _meshcop._udp        local
  hostname = [esp-ot-br-2.local]
  address = [10.10.10.79]

appearing in avahi-browse -r _meshcop._udp even though the .163 address should have timed out it was still hanging around. This is why I think I ended up with -3 in the first place

I have spent a while cleaning things down and restarting stuff and I now have

enp1s0.10 IPv4 esp-ot-br-2
  _meshcop._udp        local
  hostname = [esp-ot-br-2.local]
  address = [10.10.10.163]

and

enp1s0.10 IPv4 esp-ot-br-3
  _meshcop._udp        local
  hostname = [esp-ot-br-3.local]
  address = [10.10.10.79]

so now the host names have actually swapped (the IPs are the same as .79 is the same device is both but -2 earlier and -3 now

[regal sail]

Not sure how it is configured but could this not have a device under it so that it looks like a bluetooth proxy?
(but suspect as this is add service rather than entity it isn't that straight forward).

[regal sail]

@harsh spear Whether this is a good idea or not but a simple change is
https://github.com/home-assistant/core/blob/1f8a98609cc108c8a8cf318fb4ba2e3d0d6a3070/homeassistant/components/otbr/config_flow.py#L181
change to

title=f"Open Thread Border Router ({url})",

displays the URL in the same (I used a slightly different format when testing)

This doesn't solve the mDNS issues where these names can change but that is a bigger issue that I think would need to be solved by tracking the advertised mDNS entries agaist the broder router IDs (in which case the above might be better off showig the border router ID but that won't mean anything to most people and I don't think you can actually see this in HA unless you start grep'ing the config entries? Looks like the Bluetooth component does this to track if someone changes USB port etc.

All this is only issues were people have more than one OTBR but I thik that will start to become common as people start using Thread a lot more.

[worn onyx]

this is only an issue when having multiple devices that try to use the same mdns name - i don't expect to see this on production devices.

would be nice if the esp-thread-br example code could switch to a mac address based hostname to avoid conflicts tho

[regal sail]

It is also an issue when there are multiple interfaces. I think it started going wrong when WiFi and ethernet were both connected with different IPs but the same hostname .

[worn onyx]

That's a network configuration issue. You should not have mdns relay between two networks when you have a machine connected to both with multiple network interfaces

since the relay will forward mdns packets from the machine back to itself, causing it to think its name is already taken

hmm, i guess it can also happen with two interfaces on the same network without an mdns relay

[regal sail]

I did create a discussion (https://github.com/espressif/esp-thread-br/discussions/167) but nothing so far. I am going to fork and adjust the code and possibly submit a PR but the choice of -1 / -2 as a suffix wasn't a great idea

[worn onyx]

Appending -1 to the hostname and incrementing the number on collisions is specified in the mdns specs, i think. That's implemented in most mdns libraries.

[regal sail]

But it isn't the relay is it? this is the mdns broadcast saying I want this hostname, is it taken? Not sure exactly what happened but I guess the WiFi could have grabbed -1 before the LAN got it and was told it already existed so changed the hostname .

If people do use two of these with the default firmware then it will potentially flip flop between devices but as you say I think that is an issue with the fornware

[worn onyx]

https://www.rfc-editor.org/rfc/rfc6762#section-9 describes the recommended conflict resolution, and https://www.rfc-editor.org/rfc/rfc6762#section-14 discusses systems with multiple network interfaces

it does actually provide a suggested method to avoid problems when a machine sees its own mdns announcements on a different interface, but that often breaks if an mdns proxy is involved since the mdns proxy might not pass through the required flags

but in general the assumption is that if a machine has multiple network interfaces, they're on separate networks, and mdns is a link-local protocol (proxies/relays aren't part of the spec) so there's no worries about collisions...

[regal sail]

I will do some more reading and digging into the Espressif firmware.

I guess most of the issues are my fault but the fact I added the OTBR integrations via mdns name and then they changed is the bit that caught me out in HA. It left me with mdns names I hadn't specified and routers I couldn't control (set channel etc.) as that was relying on the mdns hostname.

I wonder whether this is just an advice / docs thing and I should have assigned a static IP and used IP for that OTBR integration not the mdns hostname?

[worn onyx]

no, you shouldn't have needed to do that. mdns hostnames should be fine

the esp-thread-br code is just an example, and it's not really intended for production use, so it has shortcuts like a hardcoded hostname

you either should use different hardcoded hostnames for each thread br, or the thread br code should be adjusted to automatically generate hostnames that are unlikely to conflict, e.g. by using (part of) the mac address in the hostname

the annoying thing is that since they got this wrong in their example code, it's possible that there might be some production devices based on the espressif example code which also get it wrong :/

[regal sail]

probably not real issues but I can see several scenarios where mDNS names might cause confusion. AIUI it is the mDNS service names that are important not the hostnames and if someone forgets to set a reserved / static IP and restarts their OTBR it can change IP and lead to a cached mDNS entry saying the requested hostname is in use and applying an extension. The OTBR integration appears to want the mdns hostname when setting up but as that is not guaranteed, you can end up with the integration trying to access a hostname that either doesn't exist or is not the one you thought it was. Add in mDNS repeaters and the prevalent bad mDNS implementations then things can easily end up in a confusing state.

Given each border router has a unique ID (and I believe this is the unique identifier for HA) then the mDNS stuff should be almost an aside. Like the bluetooth code, that checks if it has moved and updates details on the fly. OTBR integration could do similar and track the OTBR id and store current details but possibly overkill.