DHCP support

[phil-opp]

Is DHCP support planned? And is there a way to implement DHCP on top of smoltcp, i.e. without writing own UDP packet construction code?

[whitequark]

Is DHCP support planned?

Definitely.

And is there a way to implement DHCP on top of smoltcp, i.e. without writing own UDP packet construction code?

I'm still thinking about the best way to implement protocols like DHCP. In a nutshell, I'd like them to be runnable on top of smoltcp, but also on top of regular std::net::UdpSockets. I'm thinking a state machine without IO plus an adapter to IO might be right here, but I still need to experiment a bit.

[whitequark]

OK here's the plan.

1. DHCP gets a wire::dhcp module, just like all the other wire modules. For options you can take a look at how TCP options are implemented. This is very straightforward since TCP and DHCP are nearly identical in the general format of their packets.
2. We add smoltcp::io, which has the trait UdpIoAdapter described below. Then we impl UdpIoAdapter for UdpSocket as well as impl UdpIoAdapter for std::io::UdpSocket. If @batonius wants to run DHCP in a separate daemon then he can also impl UdpIoAdapter for RedoxUdpSocket or however that works.

trait UdpIoAdapter {
  type Error;
  // still not sure about the signature of `send`
  fn send(&mut self, size: usize, endpoint: IpEndpoint) -> Result<&mut [u8], Self::Error>;
  fn recv(&mut self) -> Result<(&[u8], IpEndpoint), Self::Error>
}

3. We add smoltcp::proto, which has the struct Dhcp in it. This struct contains a state machine that can be polled with a &mut UdpIoAdapter every time the adapter readiness changes or a timer is hit, and which exposes functions to get e.g. the current acquired address. Most importantly the struct does not hold any pointers to the EthernetInterface or any sockets, and so it does not prevent us from manipulating those.

I think you can start with implementing (1), and then I'll look at how (2) works best. The logic of (3) is mostly glue so it's best done last.

[phil-opp]

Ok, I'm starting to work on (1).

[dhslichter]

@whitequark @sbourdeauducq when do you anticipate DHCP support being implemented?

[whitequark]

@dhslichter No ETA currently.

[whitequark]

@batonius How do you feel about the plan outlined above?

[batonius]

Looks good to me. Right now dhcpd is implemented on top of std::net::UdpSocket, so being able to use it with the state machine directly would be great.

[phil-opp]

This was implemented in #186, so I think we can close this issue.