NetBurner Community Forum

Announcement time! We're working on a DHCP server utility that will run in the main network stack. This will give users the ability to make a Netburner module into a DHCP server. We currently have the system operational with the following features:

1. The server handles all DHCP client request types
2. The server can hand out 1 address. It does no lease management or validation.

As we're fleshing out the rest of the features, we're wondering what use cases people would like to suggest. The current list of features that remain to be implemented are:

1. Add lease management/expiration handling.
2. Mac whitelist/blacklist IP pools.
3. Static leases.
4. Interface granularity/limit scoping.

Are there any others that people would need that are not listed?

-Dan

Dan,

One other case to consider is conflict management with multiple DHCP servers on the network. It DOES happen. I know some DHCP servers will check to see if there is another DHCP server active and if it detects an active server then it won't hand out addresses, so maybe an option to enable/disable that behavior. Of course, it's always the wrong DHCP server that wins out it seems.

Scott

Scott,

This is something that has been discussed. Do to your concern, I think that this check will be added, but it will only be a start-up check. Once we are running, if another DHCP server comes online, well... that's someone else's issue.

Also, after a quick discussion, it looks like we'll be adding the ability to configure NTP clients over DHCP (it's in the options the server can dish out). This way, if you end up using one of our NTP servers in an offline situation, client devices could automagically configure all their network settings over DHCP.

The list of DHCP options that are always handled are:

• message type
• server ID
• lease time

The list of DHCP options that can be handled are:

• router
• subnet_mask
• dns_server
• log_server
• domain_name
• ntp_server
• tftp_server
• bootfile
• smtp_server

-Dan

Well, the server components are complete, just need to construct that function calls that make it simple to add the DHCP server to an application (and also include the check to see if another server is already up). I'll need to check to see what the changes are, but I looks like we can start beta testing in a few days. If anyone is interested in doing so, feel free to message me/submit a support request. It will likely have a few rough spots due to the sheer number dhcp clients out in the wild.

-Dan

Dan, this is great news!

Couple questions...

#1) Will it be able to hand out more than 1 address ?
#2) will this then allow the Wi-Fi module to act as an AP ?

Yes, the server will be able to hand out more than one address. The server is broken up into the message processing server and the separate lease allocator(s). The standard allocator can only allocate IPs in a continuous block (i.e. 192.168.1.10 - 192.168.1.200). It's also entirely feasible to create a custom allocator to hand out addresses in an entirely arbitrary fashion ("oh, the third moon of Saturn is in line with Mecury? Well, then, you get 192.168.200.5"). The server can have multiple lease allocators, and will try each in order until its out of them to try, or one of them has handled the event.

As for giving Wifi that ability to act as an AP: yes, this will allow us to enable that feature with the wifi modules.

-Dan

That is the best news I heard in a long time!!!

If you would please update this post as soon as we can get our hands on it.

Server's ready. Now on to integrating AP mode.

AP's running, starting on the in field update capability.

I too have been working on building a DHCP server. Started it a year ago, finally got it finished up. While this isn't integrated into the network stack like the official Netburner one is, it does have the following features:
- Will scan the network for devices by pinging them and checking the ARP table. IPs found to be in use are not available for DHCP to hand out.
- Can function with more than one DHCP server on a network - if a client accepts an IP from another DHCP server, we update the pool with that client assigned to the IP they accepted.
- The pool is saved to flash, so a reboot of the system doesn't clear the pool. The devices that were on the network before will still get assigned the same IPs.
- Clients not seen for twice the lease time get removed from the pool, freeing the IP to be assigned to another client.
- A webpage to see IPs, MACs, and ping times.

This is intended to be used on a typical 24 bit subnet (255.255.255.0) as the pool only stores .1 through .254. It has two tasks, a high priority task to respond to DHCP requests, and a low priority task to scan the network for devices.

Note that NNDK 2.6.7 has a tiny bug in the way it handles incoming UDP packets on port 67 (DHCP) which causes it not to pass them through to the user app. A fixed udp.cpp file is included, which will probably be included in future NNDK releases.