Fix DHCP server for certain clients (dhcpcd)
We use the Micropython dhcp server in our examples. An issue has been identified. You should consider taking the fix? See https://github.com/raspberrypi/pico-examples/pull/288
See https://github.com/hathach/tinyusb/pull/1712 and the initial trigger https://github.com/OpenLightingProject/rp2040-dmxsun/issues/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 https://github.com/OpenLightingProject/rp2040-dmxsun/issues/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.
shared/netutils/dhcpserver: Use server IP as default DNS.
Summary
The DHCP server was hardcoding 192.168.4.1 as the DNS address sent to clients. This only works when the server happens to be at that address - any other configuration (e.g. USB NCM at 192.168.7.1) results in clients getting an unreachable DNS server.
Changed the default to use the server's own IP address, matching how the router/gateway option is already handled.
Testing
Tested as part of the USB NCM branch on STM32 NUCLEO_F429ZI - DHCP clients received the correct DNS server address matching the interface IP. Separated out into this standalone PR since it's a useful fix independent of NCM.
Generative AI
I used generative AI tools when creating this PR, but a human has checked the code and is responsible for the description above.