DHCP request not acked
cuvoodoo opened this issue · 10 comments
after the DHCP offer from the RP2040 over USB, the computer (USB host) requests the offered IP.
but the RP2040 does not ACK this request.
thus the DCHP negotiation does not complete and the IP is not assigned to the interface (at least nor under Linuc Arch using dhcpcd).
see attached trace where DHCP client repeats the unanswered request.
Okay, that's strange, works on my machine. Will do a wireshark trace this evening an compare with yours.
In the meantime, is there anything strange in the kernel logs? USB device resetting or similar?
Just checked, I can definitely see a DHCP ACK here:
Did you build the source code yourself or did you use some UF2-file from the GitHub actions?
The DHCP server is part of the lwIP-stack, it's not written by me. I might be able to add or active some debugging options but I didn't yet dig into it.
I had the same problem with a UF2-file from the GitHub actions (https://github.com/OpenLightingProject/rp2040-dmxsun/suites/6080805161/artifacts/210508458)
I used the UF2 artifact from https://github.com/OpenLightingProject/rp2040-dmxsun/actions/runs/2561833425 , and compiled master myself. the behaviour is the same.
there is no USB issue:
Aug 17 16:15:12 diode kernel: usb 1-1.3.1.2: new full-speed USB device number 84 using xhci_hcd
Aug 17 16:15:12 diode kernel: usb 1-1.3.1.2: New USB device found, idVendor=1209, idProduct=aceb, bcdDevice= 1.00
Aug 17 16:15:12 diode kernel: usb 1-1.3.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 17 16:15:12 diode kernel: usb 1-1.3.1.2: Product: rp2040-dmxsun http://169.254.59.1/
Aug 17 16:15:12 diode kernel: usb 1-1.3.1.2: Manufacturer: OpenLightingProject
Aug 17 16:15:12 diode kernel: usb 1-1.3.1.2: SerialNumber: RP2040_e6605481db933b36
Aug 17 16:15:12 diode kernel: hid-generic 0003:1209:ACEB.0015: hiddev99,hidraw3: USB HID v1.11 Device [OpenLightingProject rp2040-dmxsun http://169.254.59.1/] on usb-0000:05:00.3-1.3.1.2/input0
Aug 17 16:15:12 diode kernel: cdc_acm 1-1.3.1.2:1.1: ttyACM0: USB ACM device
Aug 17 16:15:12 diode kernel: cdc_ncm 1-1.3.1.2:1.3: MAC-Address: 02:02:84:6a:96:00
Aug 17 16:15:12 diode kernel: cdc_ncm 1-1.3.1.2:1.3 usb0: register 'cdc_ncm' at usb-0000:05:00.3-1.3.1.2, CDC NCM, 02:02:84:6a:96:00
Aug 17 16:15:12 diode dhcpcd[142366]: usb0: waiting for carrier
Aug 17 16:15:12 diode dhcpcd[142366]: usb0: carrier acquired
Aug 17 16:15:12 diode kernel: IPv6: ADDRCONF(NETDEV_CHANGE): usb0: link becomes ready
Aug 17 16:15:12 diode dhcpcd[142366]: usb0: IAID 84:6a:96:00
Aug 17 16:15:14 diode dhcpcd[142366]: usb0: soliciting a DHCP lease
Aug 17 16:15:14 diode dhcpcd[142366]: usb0: offered 169.254.59.2 from 169.254.59.1
nothing further
the request is also not acked when I trigger the DHCP client manually.
I attach a PCAP for detailed view. Maybe some bit fields are different.
dmxsun_dhcp.pcapng.gz
Thanks for the pcap-file, that will help a lot. Unfortunately, I didn't yet find the time to investigate the root cause :/
I did some investigation today. First thought: Only "a limited amount" of requests can be served. Proofed wrong.
Then I tried dhcpcd as DHCP client and I can reproduce the failing behaviour of not getting the DHCP ACK. However, when I use NetworkManager's internal DHCP client afterwards on the same connection (= without disconnecting the board), it serves the DHCP ACK just fine. However, still no explanation why this happens. The DHCP server code is not written by me but I will try to debug it to see where it fails.
I think I found the root cause: tinyUSB's DHCP server expects the MESSAGETYPE option in DISCOVER or REQUEST packages to be the first option in the packet. Some clients seem to not to adhere to this expectations. The trace you attached and the "dhcpcd" I tried send the requested IP option first.
Pull-request for tinyUSB has been created, but it might take some time until the fix makes it into tinyUSB and from there into the pico-sdk. I might try to hack something together so the builds created by the GitHub actions behave correctly.
In the meantime, here's an UF2-file that includes the fix: rp2040-dmxsun.zip.
Might be a DEBUG build containing some more logging statements than required but it would be nice if you could confirm that this fixes the issue. Thanks!
Fix has been merged upstream. I now need to check if I can update to the latest upstream master of tinyUSB or if there are incompatibilities that I need to fix. Thus, leaving this open
Alright, I'm working on a way to fix this locally without waiting for the upstream version of tinyUSB to tickle down into the pico-sdk.