Author Topic: DHCP protocol  (Read 334 times)

Uncle Buzz

  • Jr. Member
  • **
  • Posts: 96
  • Country: fr
DHCP protocol
« on: August 02, 2018, 07:07:10 AM »
Hi,

I need some help to figure out how to build a sort of DHCP protocol for moteino.

I want to use some not permanently linked nodes. They will be powered only when needed and will be used on different gateways depending of the situation.

So at startup, the node won't know its network, nor its nodeID nor any other detail (exact frequency value...)

Below is how I intend to build the system, please feel free to advise me about guessed problems of such configuration, or better way to do it.

Situation :
  • I could have undefined number of nodes per gateway (1-50, probably <10 most of the time)
  • I could have undefined number of gateways in same area (1-10, probably <3 most of the time)
  • a new node without a previous valid configuration shouldn't be started with more than one running gateway because we can't decide on which gateway it will be affected, but the system should deal with this case

The protocol will be the same as TCP/IP DHCP protocol :
  • DHCPDISCOVER (node): broadcast request on DHCP network (new node or no DHCPACK received after a DHCPREQUEST request)
  • DHCPOFFER (server): configuration proposal from the DHCP server depending of free leases
  • DHCPREQUEST (node): specific configuration request based on last used configuration or from DHCPOFFER proposal
  • DHCPACK (server): validation of the proposed configuration

I will have only one gateway per networkID.
For each gateway, I need 2 radios (on same node, or one gateway and a second node as a dedicated DHCP server to listen on DHCP network while the gateway communicate on its own network)
In my case, gateways will be permanently powered so there's no lowpower consideration for them.
the DHCP servers will be on a specific networkID (255 ?), so any DHCP request will be broadcasted on this network and be received by all DHCP servers.

At this point, I wonder which configuration could be better (if any):
  • 1st : any DHCP server use 1 different ID, the node will broadcast the DHCPDISCOVER request, then DHCPREQUEST will be sent to the first DHCP server responding
  • 2nd : all the DHCP servers use same ID, the node will broadcast any request, DHCPREQUEST with bad configuration will be ignored by servers, so only one could reply
  • 3th : all the DHCP servers use same ID, the node will send any request to this address, DHCPREQUEST with bad configuration will be ignored by servers, so only one could reply

First question, in case of more than 1 running gateway, with same code, all servers will try to answer to a DHCPDISCOVER request at same time, it will cause collisions and probably not a readable answer... How to deal with that ? A specific delay based on node ID (if all servers have a specific ID) before answering ? It will produce a prioritisation list of servers and possibly a long delay for an ID like 250. A random delay, so there will be good probabilities than one server will reply before others (depending of how many servers are running), at first or even at later tries.

2nd question, is there a difference between broadcasting the request, or sending the request on a shared address since only one server will have a compatible configuration with the DHCPREQUEST and will reply ? What's the best way to achieve this ? Using a specific address is one more parameter to configure in each DHCP servers (but each one should be set anyway)

So, in an ideal world, the node will send a DHCPDISCOVER request, will receive at least one readable answer with an DHCP offer (and will ignore others), will send a DHCPREQUEST for a specific configuration, and the only server with compatible configuration (because it's the one who sent the DHCPOFFER) will reply with DHCPACK if everything is ok.
Then the radio of the node will be set with the new configuration and will communicate with its gateway.

With only one running gateway, it should works. If there are more than one gateway, but if the node was on one of them last time, it should received a DHCPACK from the DHCP server with the correct configuration on the DHCPREQUEST sent.
If it doesn't receive any positive answer, a DHCPDISCOVER request will be sent, and this is the only "correct" way to be in the situation where a DHCPDISCOVER request could be sent with more than one running gateway (and will produce an unpredictable behavior).
If the looked gateway is not running, but there are more than one running gateway, this is not the right way to start the node.

Thks for reading !

Uncle Buzz

  • Jr. Member
  • **
  • Posts: 96
  • Country: fr
Re: DHCP protocol
« Reply #1 on: August 03, 2018, 03:48:21 AM »
Another way to delayed answer from the DHCP sever could be to use RSSI value to build a delay, so will reply first the servers who are nearest the node (if distance between the servers is sufficient to have significant difference between RSSI)

LukaQ

  • Sr. Member
  • ****
  • Posts: 283
  • Country: si
Re: DHCP protocol
« Reply #2 on: August 03, 2018, 04:09:21 AM »
you could have mac address for each node, since you will have to program them at least once. This way you could have gateway assign ID to MAC. This way you would have same ID on that gateway

I just don't know how you will get past
Code: [Select]
any other detail (exact frequency value...)
node and gateway do need to have the same freq.

Uncle Buzz

  • Jr. Member
  • **
  • Posts: 96
  • Country: fr
Re: DHCP protocol
« Reply #3 on: August 03, 2018, 04:25:04 AM »
I will use the UID from flash to identify each node, and build a lease list in DHCP server to track nodes, like a TCP/IP DHCP server.

I need dynamic things because one node could work one day with one gateway, and next day with another one, so I can't put static configuration inside nodes.
The gateways can have different frequencies (inside same bande of course) because the only one frequency to know at startup is the one from DHCP servers, then the DHCP servers wil tell the node the frequency of the gateway it has to contact.

LukaQ

  • Sr. Member
  • ****
  • Posts: 283
  • Country: si
Re: DHCP protocol
« Reply #4 on: August 03, 2018, 07:41:32 AM »
Can you explain to me, why do you need this, what is the end application. I get it, why you would move nodes and they would need to contact gateway that is in range, something like garage remote, but something as temperature sensor or like it, no, I don't see why would you need to move.

Also, how often will you check, that node is still in range of that gateway and if not, use DHCP again?

Uncle Buzz

  • Jr. Member
  • **
  • Posts: 96
  • Country: fr
Re: DHCP protocol
« Reply #5 on: August 03, 2018, 08:15:18 AM »
Think about some short sequence of measurement, where you don't want (or can't) put a node for years on lowpower mode. By example for something like a datalogger, you want to supervise some values for 1h, 1 day, 1 week... if you need to do same things many times, you don't want to reconfigure each time your nodes.
Your example with a garage remote is also a good example, if you want to control many garage, without the same configuration for each one because of external constraints...
You could use a tablet or other mobile device connected to one node to communicate with your nodes networks, if you don't want to reconfigure each time the network you could use such a dynamic way to connect to your network, only when you need.

There could be many reasons to need such a system.

If the node lost the connection with the gateway, the first case is when we move it, and probably we don't need it anymore, so we can shutdown the node. I though add an auto shutdown mode if there are no connection, but it will depends of the application.

syrinxtech

  • Sr. Member
  • ****
  • Posts: 306
  • Country: us
    • Syrinx Technologies
Re: DHCP protocol
« Reply #6 on: August 13, 2018, 07:56:33 AM »
I'm about halfway finished writing my version of DHCP for Moteino's, namly DMCP.  The server is an ESP32 and the client's are currently Moteino's sitting in freezers/fridges sending back temp, humidity and voltage.  The Moteino's are controlled by a TPL5110 waking up the device every 15 minutes.  I'm using a combination of EEPROM on the ESP32 to store the node database and EEPROM on the Moteino to store the assigned information.  I've got several more utility routines to write and then I can start some load testing.

The application?  For me it was thinking about a commercial application where the nodes could all be configured with the same minimal configuration.  The nodes are configured with a frequency, encryption key and network ID.  They initially send out the address request using node 1.  The server responds back with a permanent node ID and the client changes their node ID.  Timers are kept by the server to time-out nodes that don't respond in a given period of time.  In my application there is only one gateway since the number of nodes supported will be less than 50.