Support for captive URLs

[ivmarkov]

No description provided.

[AnthonyGrondin]

Thank you for taking care of this. Is there an API provided for creating the structs which have #[non_exhaustive] added.

Rust currently doesn't support building them using struct expressions, and will throw the following error:

error[E0639]: cannot create non-exhaustive struct using struct expression
  --> my-app/src/wifi/dhcp.rs:46:34
   |
46 |               let server_options = ServerOptions {
   |  __________________________________^
47 | |                 ip,
48 | |                 gateways: &[ip],
49 | |                 subnet: Some(edge_dhcp::Ipv4Addr::new(255, 255, 255, 0)),
...  |
52 | |                 captive_url: None,
53 | |             };
   | |_____________^

[ivmarkov]

ServerOptions::new(...)?

As in

ServerOptions {
   foo: 1,
   bar: 42,
   ...ServerOptions::new(...)
}

?

[ivmarkov]

Actually... I'm not sure that works with non_exhaustive... :(

You might have to do let mut options = ServerOptions::new(...)
and then go down to mutable setting of all fields.

I get it that non_exhaustive can be annoying, but if I don't introduce it now, it means each time a new field is added to ServerOptions (or the others), we have to treat this as a backward-incompatible change.

[AnthonyGrondin]

Yeah, it would be simple if Rust allowed ..Default::defaul() for non_exhaustive elements.
My use case is running as a DHCP server on an esp32s3, so I don't have the infrastructure to test the client part of it.

I can confirm that the server side works and responds with a captive portal URL when a client sends a DHCP request with option 114:

[ivmarkov]

My use case is running as a DHCP server on an esp32s3, so I don't have the infrastructure to test the client part of it.

Oh well.
I think I'm the only one using the DHCP client ATM (I have an embedded-Linux usecase, where I prefer the whole networking to be part of my Rust firmware rather than launching the BusyBox udhcpc / udhcps as external processes).

(Only external networking executable is wpa_supplicant but I guess that's a necessary evil, and even that one is controlled via its unix sockets API.)

I can confirm that the server side works and responds with a captive portal URL when a client sends a DHCP request with option 114

I'll merge as-is then, and test the client later.