Hi Graig,
yes you are right about the second ip. Moreover the availability and validity will be ensured before running the command. Let me address your points one by one.
1.Yes i m serious bout selling this solution. No i m no expert in networking but i m trying my best to make it as secure as possible.
2.The conduit is running a linux OS not sure exactly which version. I m not alone in this project and i have another person working on the node red part as well. Teamviewer and VNC are excellent alternatives if they can be installed in this particular conduit OS.
- When the LoRa GW will connect to router, the router will assign an IP for that device (LoRa GW)
- Using Node-Red exec function we can extract the IP the router assigned;
exec command: ip -o -4 a | awk '$2 == "eth0" { gsub(//.*/, "", $4); print $4 }' - After we have the IP we can use another exec function to set this IP as static;
exec command: ifconfig eth0 192.168.1.9 netmask 255.255.255.0
Regards
Assuming that your end devices are also on the same local network segment which the network mask of 255.255.255.0 implies, then the router will assign addresses for ALL devices using DHCP. The DHCP service records the device MAC address and assigns an IP address for a period of time which is refreshed as it detects ongoing activity from the device.
So yet again, the answer is to configure the router not mess with static IP addresses.
If you are selling this, you cannot assume that all of your customers will be able to give you a spare IP address along with the DHCP assigned address.
In addition, having 2 IP addresses, only 1 of which you are actively using represents a further security issue unless you do even more unnecessary administration to lock all services down to just the 1 address. You are making lots of unnecessary work and leaving yourself open to configuration errors and your customers open to network issues.
Not really a good message to be taking to your customers for a new service.
Still, the choice is yours but I think that the community has given you lots of free input.
Let me address your points.
First of all i have my doubts on weather i need to explicitly need to configure the router to not mess with static IP addresses. I mean how do we force a static ip on windows computer? I have never had to set anything in the router to get a static IP on my windows OS, just used the out of the box functionality on the OS.
Secondly the customers wont have to do anything, like giving me a spare IP. The gateway will receive its IP through the DHCP service. Once this is done, we will try to force this IP to become static by using the execution flows, mentioned earlier.
Moreover regarding your thoughts on having two IP addresses and the unnecessary administration along with all the security risks that this creates, is something that i need to look at before deciding on going with this solution.
Yes the community has been really helpful and i received a fair amount of good points, but except from user krambrin, which suggests using MQTT , unfortunately didn't receive any other possible solution. Let me remind that my goal is to automate this workflow and not having unexperienced users trying to figure out. The message i m getting from the community is that i should abandon trying to automate this, and just go manual. I m hearing this message but i would like to research a little bit more before going with manual solution.
So let me say something more about the benefits you would get if you would use MQTT for communication in such a system architecture
-
Your gateway will get an ip from the DHCP server and you do not need to know this ip address at all
-
Node-RED will establish necessary MQTT connections with the MQTT broker somewhere via Internet using SSL/TLS secure communication on specific ports (this depends on which public broker you select to use). The MQTT connections will also automatically reconnect if there should a break
-
All commands & messages will be published to unique topics (like id's) specific to each gateway so you know how to address them with commands & from where messages are coming
-
At your server level, you can have a "master" Node-RED that talks to all your gateways via the same MQTT broker, also with secure communication, collects messages from their various topics and transfer commands sent to them from your gui
-
The data and commands can, if preferred, be visualized & handled directly from the WEB gui served by Node-RED or you can develop more advanced solutions involving storing messages in a database etc, etc. You just have to select in Node-RED where & what, there are so many nodes available for typical standard tasks
-
To remotely manage each Node-RED, you can as mentioned use Temviewer or VNC. Both supports a server side connection type so you do not need to know any ip address of gateways. You just register each so that that they get a unique id and then you can securely connect to them over internet
Most of this solution would be generic and easy to maintain. For each gateway,
- you need to use unique MQTT topics
- you need to register each gatewaty with VNC or Teamviewer to get unique connection id's
The rest I think, should be the same, maybe except for the lora stuff that could be different I guess, and then the configuration in Node-RED would have to be adjusted as well I believe
Maybe I missed something, at least this is a starting point for thoughts & further ideas
The next day the router may give the the orginal address to another device. then you will have two devices on the same address.
Krambriw,
this solution seems very good but also seems quite technical and a fair amount of knowledge to set it up and maintenance too. We would like something simpler. We might just go with manual port forwarding and limiting the access of the port, from a specific ip, which is where our server is. So this way we lock anyone else trying to abuse the port and we also don't need any vpn or something.
Krambriw,
MQTT uses Port 1883 and 8883 for SSL so the ports must be open on the Router in order to communicate.
Exactly the same way as any other device IF you follow our advice. Because the ROUTER controls it not the device which you leave with default settings!
I can't quite comprehend why you think that doing extra configuration on every device + the management overheads of manually maintaining IP addresses in use is simpler than configuring something in 1 place - once?!
If you are interested in your customers, you will want to do what is best for them, not for you. That is certainly what I would be expecting from you if you were trying to sell to me.
1 Like
I agree with you. The thing is that the end users will not have the knowledge of doing this. But i m coming to the conclusion that it might not be a good or even possible solution.
Really not hard to do and you could do it for them, all you need is the login to the router. You could easily pull together a set of instructions for common routers and by the time you'd done that, you would almost certainly know how to apply the information to routers you haven't seen before. In any case, you will most certainly find the instructions for any router on the Internet.
I agree that the necessary ports need to be open in order to communicate but the point I made is that this is "happening" by itself so to say. There is no need to setup any port forwarding since all necessary ports will be opened by the application in preparation to establish connection with the MQTT broker
I give you an example; I have the following setup with two computers connecting to the MQTT broker service CloudMQTT. I use TLSv1.2 with certificates for secure communication, in this case it is port 286XX that is used, so not necessarily 8883. I have not configured any kind of port forwarding in my router but the computers can anyway communicate with each other using MQTT messages via CloudMQTT
What is necessary though, is that the it-department allows and has not blocked this type of communication (if you are on a company network)
I can do it, so it must be easy!!
This is my Netgear router settings, and you can see I've set 3 devices to use certain local IP addresses.
1 Like
I dont think you get it still. You are talking about going into their firewall and doing port forwards etc - this is a far more complex thing to do than to assing a static IP address to the device through DHCP - to set a port forward on the firewall you must already have Admin access to the firewall - if these are small business with little knowledge as you seem to initimate - who is doing this port forward ? If you are logging in and doing it then it is a simple matter to set the DHCP assigned address for your conduit to be Static.
I am wondering if you do not understand what we mean.
DHCP works by a device (in this case your conduit) asking for an IP address through a broadcast mechanism - all devices see this broadcast , but only a DHCP server knows what to do with it.
The DHCP Server (Firewall in this case presumably) looks at the table to valid IP addresses it has available to hand out and then passes one out to the device - as part of this is also provides information such as valid DNS server and gateway on the network. Lastly it provides an EXPIRATION time when the address must be renewed by - it is upto the client device to make a new request before that time expires.
If the time expires - then that address is placed back into the pool and can be given out to any other piece of equipment on the network that requires it. So if you get the IP address and then assume it will always be static - it will not be - it can and will be assigned to another device.
However in the firewall handing out the IP addresses there is a mechanism within the DHCP server to tell it that an address is permanently assigned to a device (by relatiing the MAC address of the Device with the DHCP address) - this then stops the DHCP server assigning that address to anyone else
Craig
Are you hosting the LoRaWAN network stack? If so then you will make life a lot easier for yourself by configuring the LoRaWAN gateway to connect directly to the internet (e.g. with SIM card) rather than going through the clients local network. If the clients insist on connecting to the local network then the onus is really on them to sort out the routing to and from the internet (e.g. firewalls, static IPs, port forwarding). That cannot really be automated as it depends on their network configuration and hardware so will be different for every client. Best you can do is provide the requirements (e.g. your server IP, port numbers) to give to their network people.
EDIT:
After looking a bit more into it (for my own interest), I'm going to assume that in your test case you are using the Gateway embedded Lora Network server. This is your next issue, as clients may use different Lora gateways with different network providers (such as The Things Network - for which there is a handy Node Red connector for). Some clients may have multiple device types and only want to sent the data for some to your app. To sell your solution commercially I think you will need a better handle on how this all works and provide a consulting service to help get it all connected. Some clients may have this figured out and can configure it all themselves.
You would probably do better discussing this topic on a LoraWan forum as it really has nothing to do with Node Red.
Some other options:
-
If the router has the ability (probably does, just see if it's enabled), use UPnP (https://en.wikipedia.org/wiki/Universal_Plug_and_Play) to tell the router to forward the external port to your device without worrying about the IP. Programs like Skype do this. There are several npm packages out there that allow you to do this, e.g. https://www.npmjs.com/package/nat-upnp.
-
Probably the better option than any of this would just be to setup a VPN server on the server you speak of and connect to that. You can give your device a static IP on the VPN network and the client's router doesn't care. OpenVPN is relatively easy to setup.
HTH, Jake
2nd @krambriw's idea to connect to a MQTT broker too, this would be nice, simple, secure.
I think there might be a misunderstanding about what @krawbriw was proposing -- unless you're behind a router that does not NAT/masquerade internal IPs, a client (initiator of a connection) does not need to have any ports forwarded etc. Only the server. The MQTT broker is the server. The Node-RED gateway would be the client.
That's the fundamental issue here that he's trying to address -- the originally proposed setup has a Node-RED gateway as the server, so the port forwarding matters. If you connect to an external server instead and communicate through that, e.g. MQTT broker or a VPN server, then the port forwarding doesn't matter (again, unless you're behind a router that doesn't NAT).
