With these specific units, if I go with the bridge then I no longer have access to the control panel over any interface - it’s like it changes internal IP address and I can’t see what it is.
The reason I suggest to use bridge is it bonds the HaLow and ethernet interfaces into the same Layer 2 domain. This will help you not think about layer 3 routing, and in the case of some of our extender nodes, you won’t need to worry about NAT, which should make communication between attached end-point devices (laptops/phones), a bit more seamless as they will be in the same subnet/address space.
What’s happening when you select this, is the radio is actually losing its IP address. The device will be trying to act as a DHCP client and looking for a DHCP server where it can request a lease.
You will find, there are ways to access the device even when it doesn’t have an IPv4 address. All devices should have a unique IPv6 link local address (if IPv6 is enabled) based on the MAC address. At least for Windows endpoint devices, you can simply use that address to connect to the radio. Unfortunately there are some quirks around the web URI standard here which does complicate this on Linux/OSX.
If the device has an mdns service running, you can often still connect to the WebUI using the hostname in your browser despite the device not having an IPv4 address. Your browser/host will send an MDNS query, and if the device responds with an answer containing an IPv6 address, your browser can then establish the connection that way.
I’m thinking DHCP over LAN/WiFi to connect the EUD and then something else for the Halow side so they don’t fight with each other to establish link - but I’m unsure how to set that up.
It might need some thought around the network as a whole. I’ve been doing some reading on distributed dhcp servers and other methods of IP address allocation in MANETs. Nothing has really stood out yet as the “best solution”. But I have an idea:
You could configure every radio with it’s own unique static IP, and a DHCP server, but a wide subnet mask. This will mean you have multiple DHCP servers on the network (for automatically assigning addresses to the end devices attaching directly to the radios) but still give you access to every other device on the subnet. This is basically a naive distributed DHCP.
This will mean you can always access the radio device, but also let you bridge the interfaces so you don’t need to worry about layer 3 routing. However, it could get complicated in the sense that you need to then be setting unique IPv4 addresses for each device (and then I start leaning to IPv6).
You could modify it slightly, and perform some address collision detection before assigning an address, but this will require some software development, rather than just configuration.
I intend to set something up in a few days using our evaluation kits - which the Heltec devices are based on - so I can make a more concrete recommendation.
Does MM have a product that would fit in this space (small, low power requirements) that would be more successful than these Heltecs?
As we are strictly a chip company, we try to let our customers build the products! The HaLowLink1 was a bit of an exception to that. So unfortunately no, we don’t have a product that would be more suitable than the Heltecs.
I’m confident we can configure the Heltec devices in a way which suitable for your application.