Enable DHCP server only when there is no other in the network

[patrickelectric]

Does this mean that blueOS would act as a DHCP server on the default eth0 network? If that is the case, then that worries me a little bit, since we usually have an existing device there that does that already, and having two DHCP servers is usually not a great experience.
Or does it only kick in if it did not already get a DHCP lease from an existing DHCP server?

Originally posted by @goasChris in #2988 (comment)

[goasChris]

I'll most likely be testing this tomorrow, and it might be perfectly fine already. Not too familiar with the cableguy "module"/code

[goasChris]

In testing, this did not cause any apparant issues for us. The DHCP server is enabled by default now, even on an upgraded system. It is however targeting a range that we don't use. Might cause trouble for people who happen to use the 192.168.2.0/24 subnet (with an existing DHCP server)

[goasChris]

In testing, this did not cause any apparant issues for us. The DHCP server is enabled by default now, even on an upgraded system. It is however targeting a range that we don't use. Might cause trouble for people who happen to use the 192.168.2.0/24 subnet (with an existing DHCP server)

I was DEAD wrong. It did break our system, hehe. Just didnt notice it until we rebooted the existing DHCP server. The blueOS one took over, and moved the clients over to a different IP range. I should have expected this, and tested further.

In the PR #3154 it removes the DHCP authoritative flag. I'm not sure if this is enough. If I reboot the old DHCP server, and its gone for say 5 min, what would happen? Would the blueOS DHCP server not take over still (cus its now the only one in the network, for a limited time).

I'm not saying that this isn't valid. Obviously there are good cases to be made on the blueOS side for having DHCP server enabled by default. I guess I'm hoping to nudge the direction a bit. Would it be acceptable to check at boom time whether there is another DHCP server there, and if yes, then disable it?

cc @Williangalvani

[Williangalvani]

I was DEAD wrong. It did break our system, hehe. Just didnt notice it until we rebooted the existing DHCP server. The blueOS one took over, and moved the clients over to a different IP range. I should have expected this, and tested further.

What time frame are we talking about? I'd expect the clients to only request a new IP after the TTL expires, which should allow you to reboot your dhcp server without issues...

We could maybe do both? set it no non-authoritative and check at boot time if we can reach a dhcp server

[goasChris]

I was DEAD wrong. It did break our system, hehe. Just didnt notice it until we rebooted the existing DHCP server. The blueOS one took over, and moved the clients over to a different IP range. I should have expected this, and tested further.

What time frame are we talking about? I'd expect the clients to only request a new IP after the TTL expires, which should allow you to reboot your dhcp server without issues...

We could maybe do both? set it no non-authoritative and check at boot time if we can reach a dhcp server

Yeah, I can see that. We have a very low TTL set on our DHCP servers, because we swap out robots fairly frequently, and we would prefer it to always show up on the same address, so it's currently set to 2-5 min. I know our use case is very abnormal, and I understand that you can't torpedo the feature based on this.

If checking at boot time if there is an active DHCP server, that would be absolutely lovely for us of course. Unsure how much extra work this would be. If it is not feasible, then we would definitely also be happy if there was a simple way/method of disabling the DHCP server feature. Could be as simple as checking for the existence of a dummy file (which we of course then would ship all of our systems with).

[Williangalvani]

@goasChris you should be able to use the same config on all vehicles. just make sure you dont have any "server" entries on the interface at http://vehicle.local/tools/file-browser/configs/cable-guy/settings.json

[goasChris]

I see, thank you Will. Was hoping to automate this, so that our base blueos/raspian image came with this out of the box, but I don't think that its a simple task. I think I might end up maintaining an alteration to the DHCP server on our fork. Only other option I can think of would be to do more madness in the blueos_startup_update hehe.

[Williangalvani]

This PR did not seem to solve the issue for me, so I'll work on actually checking for other dhcpservers