IP Address of the gateway

[chirpstack]

IP Address of the gateway

[brocaar]

Thanks for your feedback! I'll look into this later. Could you tell me your use case for this? E.g. would it make sense to send this in each stats package, or would it be enough when the ip of a new or timeout gateway would be broadcasted?

[siscia]

Hi,
sorry for the delay.

Complex gateway may require to log into the machine itself or to send command to the gateway.
We have gateway able to run web servers, so accept external command and communicate to the mote.

In order to do so I need to know the IP.

What is necessary is to know the most up to date IP, it shouldn't change though.

What you think?

[brocaar]

Initially I was positive, but I've had a second thought as this might be a little bit tricky. The problem is that there are different deployment options. One might put the gw bridge on the gateway itself, so that from the gateway to the mqtt broker, the transport can be secured by TLS, or one might run the gw bridge on a server and let the gw forward udp packet to it.

In the first scenario (which I think is the best as it means nobody can tamper with your date), the IP would always be 127.0.0.1, so not really what you're looking for.

[htdvisser]

Here's what I implemented for TTN's fork: https://github.com/TheThingsNetwork/lora-gateway-bridge/commit/f3f0eda9e0197a8ce4e175d9115dc1e01fd7723f

Basically we just append the IP address of the gateway to each status message. Might be a simple solution for your use case, @siscia.

[brocaar]

@htdvisser but that only works when the bridge is not running on the gateway itself. I know some people prefer to run the bridge on the gateway itself, so that the transport to the server can be secured by using MQTT over TLS.

[htdvisser]

True, and my solution also doesn't work for NAT, but it's a start ;)

Our idea is to let gateways determine their own IP address(es) and publish them in the status messages. Simple, but works :)

[siscia]

This is an "interface" deal, we all know that interface are very hard to change once they are released. In my opinion is really important to think very carefully about it and release something when we are sure of the result.

However, I don't see many other option other than having the gateway determinate its own IP address.

Another idea could be to support as first class feature the gateway receiving messages, but for a variety of reason, it does not seems like a good idea.

Re-thinking about the problem, however, makes me wonder, if we need the gateway to communicate its IP address at all. Let me explain.

In complex network we may want to communicate with the gateway for whatever reason.
This imply that once the gateway receive a message, it is able to start some action. In this case I would definitely need custom software, an actuator, on my gateway.
At this point the actuator will need to at least receive messages in some way, and make actions.
Now, why we don't let the actuator brodcast how to communicate with itself?

In this way we keep the bridge simple and with only one responsability.
We don't put more weight on the MQTT messages (I do agree that this kind of weight is negligible) and custom need will be approached with custom software.

[brocaar]

What about the idea to add a small service on the gateway which updates a dns entry related to the gateway mac? So it becomes resolvable under [gwmac].yourdomain.com? This will not be in the domain of the gw bridge, but it might be a nice solution maybe?

Thinks to take into account: your registrar needs of course to have an api + you want your gateway to only update its own dns entry.

[siscia]

In my opinion we should take the simplest (less complex) route.

The choice that we were able to come up with are basically two.

Communicate the IP of the gateway or update the DNS entry.

To update the DNS you need to know the IP and you are working with DNS, which are distributed system, slow to update and cames with a fairly share of complexity.

[siscia]

What I ended up doing was another little service. The gateway communicates with this other service and we publish the IP via MQTT