Pico-W Access Point: Fix DHCP server for certain clients (dhcpcd)

[kripton]

See hathach/tinyusb#1712 and the initial trigger OpenLightingProject/rp2040-dmxsun#53:

The included DHCP server fails to process DHCP DISCOVER or REQUEST packages that don't contain the "DHCP MESSAGE TYPE" option as the first option in the package.
The initial report that triggered me was in OpenLightingProject/rp2040-dmxsun#53 and after some investigation, I found that the "dhcpcd" client (maybe others, too) don't send the MESSAGE TYPE as the first option (see Wireshark dump attached in the linked issue). This seems to be valid since the order of the options contained in the package shouldn't matter. However, tinyUSB's DHCP server expects the MESSAGE TYPE to be the first option.

This change uses the already existing function to extract the MESSAGE TYPE option from the options properly. It will also fail now, if the MESSAGE TYPE option doesn't exist at all, making the code safer than the current approach.

[kripton]

Oh, here are the wireshark dumps (zipped since GitHub doesn't allow them otherwise):
Pico-W-DHCP.zip

pico_w_AP_DHCP_Failed.pcapng shows the behaviour prior to the change. Transaction 0xa76ad45d is initiated by NetworkManager's internal DHCP client and is working as expected. Transaction 0xe4ab1f63 is initiated by dhcpcd as client and is not ACKed by the Pico W's DHCP server since the first option in the REQUEST package is the requested IP address. The second option is the DHCP Message Type. Transaction 0xd2704100 is again from NetworkManager and is ACKed to show that the DHCP server is able to serve multiple requests and the problem is not that only the first DHCP REQUEST is handled propery.

pico_w_AP_DHCP_Fixed.pcapng shows the behaviour WITH the changes from this PR. All DHCP REQUEST packages are handled properly.

[peterharperuk]

Looks good. We "borrowed" this from Micropython. So I guess I should return the favour and fix it there?

[kripton]

Sure, spread the word :) The code from the pico-examples and the one from tinyusb look similar but not identical. Don't know the origin but the more places have the fix the better. TinyUsb merged it by now.

[kripton]

Oh, wait a second. In the case where ptr is NULL, the pbuffer is not freed, leading to a possible DoS. I will fix this tomorrow

[peterharperuk]

Can you please also push to develop? (before I accidentally push to master again)

[kripton]

Oh, wait a second. In the case where ptr is NULL, the pbuffer is not freed, leading to a possible DoS. I will fix this tomorrow

I seem to have gotten confused. The "original" (as I saw it) dhserver.c from tinyUSB didn't include the goto ignore_request-lines. As such, I introduced a buffer exhaustion there by not freeing the pbuf.

In this version (copied from micropython) WITH the goto ignore_request-solution, it is all fine, no buffer problems.

I rebased on top of develop as requested 👍