DHCP custom option

[mcspr]

@bwjohns4
re comments in #8571

[d-a-v]

To the risk of being pedantic, If there a way to retrieve user option from flash ?

[mcspr]

Sure, but what is the use-case anyway?
Playing around with the code here... We could have static opts as static vars, sure, but then we can't have anything dynamic that way. e.g. based on the netif IP, or some other service info we would want to add.

Suppose, we have #8451 with a pointer attached to the instance instead

    dhcpSoftAP.custom_offer_options = [](auto& options, const DhcpServer& server) {
        options.add(/* code = */ 43, /* data = */ {0xca, 0xfe, 0xca, 0xfe, 0xfe});

        char clientId[32];
        ... somehow generate it from server._netif data ...
        options.add(93, reinterpret_cast<const uint8_t*>(&clientId[0]), len);
    };

Where auto& options is the magic handler with size + code checks from above.

[d-a-v]

My fingers always hurt when storing an array in a source code, which is copied on boot from flash to ram, then by code from ram to ram. Data are there three times, so this was my question. Of course some dhcp configuration blocks are dynamic, so it should not be prevented to deal with them.
I was thinking of something like memcpy_P(optptr, &option.data.begin(), option.data.length()) instead of this loop

        for (auto it = option.data.begin(); it != option.data.end(); ++it) {
            *optptr++ = *it;

But yes, dhcp data blocks are often dynamic and among the static ones not many are long enough to get a real ram gain.
So yes, it was a pedantic question 😛

[mcspr]

With the above, add() could accept u8 pointer then and do memcpy.
Let me fight the clang-format out first... It does some weird stuff with the built-in options when processing them as function arguments.

[mcspr]

Updated. Since it is also a showcase of the existing options helpers, size of changes... increased (sry).
Arrays could be anywhere. Initializer list, stack, heap, etc.

Overloading add() was sure fun, but idk how obvious it is without code completion and syntax helpers. add_<type> might be more self-explanatory.

[d-a-v]

Nice one !

[blue-wind-25]

Hello,

In 'LwipDhcpServer.cpp' line 444 I found:
std::memcpy((u8_t*)q->payload, reinterpret_cast<u8_t*>(&m), q->len);

shouldn't that be:
std::memcpy((u8_t*)q->payload, (u8_t*)m, q->len);

(use 'm' instead of '&m')?

Also, in 'ESP8266WiFiAP.cpp', the call to wifi_softap_dhcps_stop() in ESP8266WiFiAPClass::softAPConfig() has been removed. Shouldn't that be kept there so that the DHCPS from the SDK is kept turned off?

In previous cores, I can use custom IP such as '192.168.0.XXX' using DHCP in access point mode, but if wifi_softap_dhcps_stop() is removed then that custom IP will not work.

Could you verify those two? Thank you!

[mcspr]

shouldn't that be:
std::memcpy((u8_t*)q->payload, (u8_t*)m, q->len);

it should. just a bad c/p

Also, in 'ESP8266WiFiAP.cpp', the call to wifi_softap_dhcps_stop() in ESP8266WiFiAPClass::softAPConfig() has been removed. Shouldn't that be kept there so that the DHCPS from the SDK is kept turned off?

probably? iirc, there's no difference between server.end() and wifi_softap_dhcps_stop() besides wifi_softap_dhcps_status() getting changed. it ends up calling dhcps_stop() which is proxied to server.end() anyway, while also doing some extraneous checks we don't really care about
yeah, it also should. on a second look, it won't set our network info without it