DHCP Not Getting an Address about dcload-ip

[darcagn]

@johnkiddjr
What type of device is your Dreamcast plugged into?
I and several other users had a similar problem before, and I determined that the Dreamcast was sending the DHCPDISCOVER packet before my switch could bring the link up. In PR #13 I added a sleep function to add a 241ms delay before sending the packet, which seemed to be a successful quick fix for everyone. It still didn't work with my Aruba enterprise switch until I enabled "portfast" for the port though.

Therefore, my suggestions to troubleshoot:

• Try adding even more delay to target-src/dcload/rtl8139.c by copy/pasting the following text after line 846: for (i=0; i<cnt; i++) (void)*a05f688c;. Each copy/paste gets you another 241ms of delay.
• If using a fancy enterprise switch that does checks on the link before beginning to forward packets, disable that feature (called "portfast" on some switches).
• If using a fancy enterprise switch, try connecting a basic dumb switch between your Dreamcast and your switch. This will allow your usual switch to bring up the link to the dumb switch beforehand.

Let me know how it goes, if one of those is confirmed to fix the issue for you then I might be able to come up with a smarter way to fix this issue rather than a crude delay hack.

[johnkiddjr]

Adding a dumb switch between the Mikrotik and the DreamCast works, I'm able to get DHCP that way (I used a NetGear GS108).

Adding 1 additional loop to add 241ms of delay worked as well. I had a couple failures, but I think "make clean" didn't remove the old elf file on those failures. After I manually removed the files and ran make again it worked every time.

[darcagn]

@johnkiddjr So, I ended up not having to leave town, so that means I was able to work on this with an actual fix.

I'm more than happy to test any changes too.

Would you mind testing the version I have forked here? https://github.com/darcagn/dcload-ip

This new version re-starts the DHCP handshake after 1sec elapses. After this, it increases the interval to the next handshake from 3, 6, 9, 12, 15,... until it reaches 30 seconds and then continuously retries every 30 seconds. After the 2nd retry, it shows a "DHCP Attempts" counter and "Next attempt" countdown in the bottom left.

Here's a video demonstration of it operating on a switch disconnected from the DHCP server. After the 6th attempt, I connect the DHCP server back up, and when the countdown reaches zero, it successfully negotiates an IP address, which it would not do before in the current build.

2023-06-22.00-44-25.mp4

[johnkiddjr]

This works perfectly! I tried it 8 times and it grabbed an IP each time without fail.

[sizious]

Thank you very much for reporting. Currently I don’t have my hardware so I won’t be able to debug this, but I’ll try my best to manage some time to look into this issue.

[johnkiddjr]

Sounds good, thank you!

I can test changes for you as well if you need it.

I also have Wireshark captures I can share if that will help you as well (for privacy reasons I'd prefer to send them directly to you rather than post them here). I made these captures directly on the switch the Dreamcast is connected to, filtered by switch port only.

I made 2 captures:

1. Phantasy Start Online Ver 2 - Working DHCP packet capture, Discover and Offer + more captured
2. Current code, no changes - DHCP Discover Sent, no response

[johnkiddjr]

@darcagn It's connected to a Mikrotik CRS112-8G-4S. I couldn't find a Mikrotik equivalent to "portfast" but I do have spanning tree disabled, so it shouldn't need it anyway. I tried the DHCP disc again (I turned off spanning tree for a different reason this morning) and it still doesn't work.

I'll try a dumb switch tomorrow morning.

I'm actually all out of CDs to test with though, can I use a static IP disc to load a modified dcload-ip or does that cause the universe to implode like it sounds like it would? If I can load it that way I can test the changes to the delay as well, otherwise it'll be this weekend since I'll have to order a new spool off Amazon.

Thanks!

[darcagn]

can I use a static IP disc to load a modified dcload-ip or does that cause the universe to implode like it sounds like it would? If I can load it that way I can test the changes to the delay as well, otherwise it'll be this weekend since I'll have to order a new spool off Amazon.

Yes, you can use dcload-ip to load a new instance of dcload-ip, just make sure you pass the -n argument to dc-tool-ip so that it doesn't attach the console.

[darcagn]

Thanks for your thoroughness in testing things out, John. Adding more delay should be a quick fix for this problem, but better solutions would be to somehow verify the link is truly ready before sending the DHCPDISCOVER packet (if that's possible?) or retry sending DHCPDISCOVER after some interval if it isn't acknowledged. I'm not sure what a typical DHCP implementation would do, I'll have to investigate when I get time since the original author of this DHCP code is no longer around.

[johnkiddjr]

No problem. I'm more than happy to test any changes too.

My thought on a fix was putting DHCP into a loop and if it doesn't get a response within 5~ish seconds, to try again (showing retry count on screen so the user knows it's doing something) and after maybe 5 tries display DHCP FAILURE.

[darcagn]

I submitted a PR #16 to increase the delay and adjust where it occurs in the code so it only applies to DHCP-configured dcload-ip, so as not to bother static IP and ARP users.

I was hoping to work on a more proper fix for the issue but just received an last minute surprise call to leave town for a week or so and will be away from my network to work on this.

[sizious]

Thank you so much @darcagn for your contribution, as you can saw I'm pretty much offline these days!

[sizious]

And thank you @johnkiddjr for reporting and testing the fix that @darcagn provided!