Controller IP auto-discovery for EthernetGW

[nneeoo]

Hi.

I have been working with Ethernet Gateway and modified it to obtain IP address using DHCP. I would also like the Controller to run with dynamically assigned address. I was thinking it might be a nice feature, to enhance the MySensors protocol (the internal msg) section to be able to broadcast a "controller discovery" packet and let the controller reply with its IP address.

My idea is that the GW may have some controller IP hard-coded, but in the setup() it will try to find a controller using the discovery. The discovery could be also triggered by some button later.

What do you think?

[John]

@nneeoo said:

but in the setup() it will try to find a controller using the discovery

You want the gateway to connect to the controller? It would be better, like you said to let the gateway to broadcast a packet. When the controller receives this it can connect to the gateway. It then does not matter if the controller has a fixed ip or not because a broadcast is on network level.

It would be a good idea, it depends on if udp broadcasts are possible on the selected shield.

[Zen]

I already modified the sketch to do a udp multicast broadcast on setup, this will allow you to listen on the broadcast address and get the gateways ip, after it has aquired a dhcp issued address.

[John]

@Zen
This is in the default library? (will soon start with ethernet support).

[Zen]

@John
no its not in the library, it even requires you to add a function to the EthernetUdp.cpp file in your arduino libraries, to support multicast.

At least thats my findings.

I also found a couple of issues with this, thats the main reason why I only do one broadcast on setup.

I cant make it broadcast once per 10 seconds (simply because the gateway goes to sleep) the millis() does not update

Second, I did manage to get it to broadcast continously but I found that it doubled the message each time,.

[John]

@Zen
Ok clear, it would be nice if it could be added to the default libraries, maybe via a pull request via github (if mysensors is on github).

[Zen]

@John
I would be happy to share my code with you, infact the sketch modifications can be found on http://wiki.zennet.dk

My udp broadcast listener is just a simple test code build in c#. its less then 15 lines of code, and it Works well.

[John]

@Zen

I personally use the serial gateway, but will add ethernet support in pidome soon. This would be a nice feature to have if it was in the default mysensors lib, unfortunately i personally do not have the time to dive into the mysensors libs

[daulagari]

What about UPnP?

[Zen]

@daulagari
Never really fooled around with that, and in my oppinion it is a not a so smart Network feature, I dont want any application to cause my router to open a port into my Network, even tho it simplifies Things from a user perspective, I just dont care for it.

But that dont mean you can't implement it

There is also limited Space left in the chip after the mysensors library and Ethernet library is loaded in, so I am not even sure you have Space enough to implement a UPnP protocol.

[daulagari]

@Zen : Agreed UPnP is overkill (but would be cool), your approach is much simpler and therefore better but what would be good is to standardize on something so Controller can add support for it.

[Zen]

@daulagari
I am all for a standard way of doing this, but as present Ethernet Library implementation we have to alter our libraries to support multicast broadcasts, and therefore it is not possible to do a standardized implementation, since it wont be compatible with the current Ethernet Libraray.

We have to wait for the library to include this functionality, or come up with a way to do this without multicast and still keep it small.

[nneeoo]

@Zen
Multicast and broadcast are two different things. You can broadcast a packet by sending it to a broadcast IP address of the network you are on.

So if you are on network 192.168.1.0/24, the broadcast address will be 192.168.1.255. Then the controller listening on a socket with IP address from that network should get it.

I think it can be achieved by simply sending a special (new) internal message from GW to the broadcast IP address using UDP (we should use some specific port all the time). The Controller will get it and respond to with the same type of internal message that can contain its IP address (or GW can extract the IP from response).

The first step from my point of view is adding a new internal message type. I will try out my ideas during the weekend and if working create a pull request on Github. I wanted to get some feedback, since I think it might be an interesting Feature, rather than hard-coding everything into GW.

[Zen]

@nneeoo
I am well aware of this, but it requires you to actually know the broadcast address of your segment.

In multicast you choose the multicast address you want to use, and this is regardless of your segment, which actually makes it abit easier.

[John]

@Zen
Use the mask to determine the broadcast ip.

Instead of multicast use anycast, this way you do not have to keep track of interested parties.

UPNP is also a possibility, it does not automatically implies router configuration options. Only implementing presence would suffice. All though space on the chips should then be looked at.

[JUSTATHOUGHT]
UPNP could also cover a bigger range of possible options where not only specific mysensor controllers can jump in to, but also other applications. UPNP enabled devices could see a MySensors gateway (it is even possible you will see it in your windows network discovery). I'm not saying to implement an UPNP subset, but broaden the gateway visibility.

I for example are going to implement UPNP for media discovery, or even other possible devices support so adding components/devices can be easier, having MySensors doing UPNP would let it appear on the list.
[/JUSTATHOUGHT]

[Zen]

@John
But in anycase, I have only 1190 bytes left, and this is with debugging disabled.

I was hoping I could get a simplified serial library going to show the ip on a lcd aswell, but I am guessing this is more or less a no go.

[John]

@Zen
Oh.. Dealbreaker, A bigger reason to do anycast (if going for the *cast route), It ain't possible to squeeze a broadcast calculator in it if the multicast code would be removed?

[Zen]

@John
well I am not all that familiar with anycast, is that the same as the segment's broadcast address ?

[John]

@Zen
anycast is almost like broadcast, but with some restrictions. The most important one is broadcast (old convention method) does not care who where anycast does. More info here (too much to post): http://en.wikipedia.org/wiki/Anycast

[nneeoo]

If anyone is interested in trying out the implementation using UDP packets sent to the subnet broadcast address, check out my pull request https://github.com/mysensors/Arduino/pull/66