AutoIP and WaitForActiveNetwork

[KE5FX]

Just noticed that WaitForActiveNetwork always times out on my Win10 PC, which is using a secondary NIC that has nothing else connected but the MODM7AE70. Is this a valid way to fix that in \nburn\nbrtos\source\dhcpc.cpp?



There doesn't seem to be a dedicated "AutoIP" mode; on my machine it's always "DHCP" even though technically AutoIP isn't DHCP.

[TomNB]

Why not turn off DHCP? Also, what tools version?

[TomNB]

Or, comment out the call to wait for active network. I would try to avoid changing system code if possible.

[KE5FX]

Well, yeah, I could turn off DHCP (how/why would I want to do that?), but would it still be able to come up with an AutoIP address if I did that?

I'm suggesting that you change the system code to fix what looks like a bug. But I don't know enough about the system to know if my hack will have undesirable side effects. I'm running 3.5.2, but didn't see anything about it in the change notes for 3.5.3.

Point being, right now the WaitForActiveNetwork() function always times out in this situation, even though it only takes a few seconds to get an AutoIP address. As an extreme example, if you call WaitForActiveNetwork(3600) and run the code on a board that needs to use an AutoIP address since there is no DHCP server available to it, it will block for an hour even though it could return successfully in five or six seconds if it were to check cur_auto as well as cur_addr.

[TomNB]

Hello KE5FX,

Thank you for the additional information. I think I might still be a bit confused, so I'll post what I think I am hearing and please correct me if I'm wrong.

A device will have the following addresses, in addition to any IPv6 addresses assigned by network routers:
- IPv4 DHCP or static
- IPv4 AutoIP
- IPv6 link local

A device can be addressed by all 3 at any time.

Regarding the comment: "Well, yeah, I could turn off DHCP (how/why would I want to do that?)", and that waiting for a DHCP address is a system code bug, it seems like what you are presenting is that the Wait function, intended to wait for the configured device configuration to be achieved, should not wait the 10 seconds by default for DHCP. If we comment that out it will have a negative effect on applications that are counting on a valid DHCP address before they start making network calls.

In your specific case, if you set the mode from DHCP to static, and left the static at the default of 0.0.0.0, you would still have an AutoIP and link local address you can use and there would be no delay due to DHCP. If your comment about why you would want to do that is that you don't want to change the setting from DHCP to static, I do not have a solution for that.

If someone uses only AutoIP, the discover server will not be accessible either, so use the localdiscover utility instead. I have attached a screen shot of my device with ending mac address of EE.

Screenshot 2024-11-26 143035.png (42.25 KiB) Viewed 3002 times

Additionally, providing that BOTH the PC and device are configured for the same local network (in this case PC is using an AutoIP address as well), you can use the LocalName option. In this case I used mydevice.local. That way you don't need to remember the IP address.

Screenshot 2024-11-26 142424.png (68.83 KiB) Viewed 3002 times

Please let me know if that helps in this case or if I missed something in the question.

[KE5FX]

I'm not saying to comment anything out, but to add the code highlighted in yellow.

There is no need to change the mode, or to expect the end user to do so. Seems that you can just update the function as shown, to make WaitForActiveNetwork() recognize that it doesn't need to keep spinning if the board gets an AutoIP assignment.

Again: right now, if you tell WaitForActiveNetwork to spin for an hour waiting for the board to receive a valid IP address, that is exactly what it will do when all else fails and the board ends up with an AutoIP address. That can't possibly have been the intent, right?

But maybe adding the section in yellow is a bad idea for another reason, and if so that would be good to know. (E.g., are you saying that it could cause the function to return prematurely when a tentative AutoIP address is about to be replaced by an address issued by a real DHCP server?)

[TomNB]

It sounds like you don't care if you get a dhcp or autoip address, which may be fine for you. But if I design my system to wait for a DHCP address, it is because I want a DHCP address. AutoIP is not addressable in some host systems, so it is useless to proceed and make call that need an dhcp address fail. I don't know how to explain it more than I did previously. No system change is necessary based on how addressing should work. If you don't need DHCP and autoip will work, then don't configure your system to use dhcp. If you can use either and don't want to wait for dhcp, then put in a small timeout. You have complete control. If you still desire to make it work differently for you, your covered as well. Use the override method for that file and you can put in your custom code. So no road blocks of any kind here. You will always have an autoip address, so ignoring the dhcp timeout is an undesirable thing.

https://www.netburner.com/NBDocs/Develo ... ctory.html

[KE5FX]

You will always have an autoip address, so ignoring the dhcp timeout is an undesirable thing.

Thanks, I think that answers the question. What I found confusing was that I don't 'always' have an AutoIP address -- it takes 6 or 7 seconds before the code that I added actually triggers, so I wasn't sure at that point if it had given up on getting a real DHCP address, or if it could still reasonably expect to receive one if a DHCP server is present.

I normally wouldn't use AutoIP at all, or care about it, except that the only available RJ45 jack (within reach of the cable I had in my hand, anyway) was the unused secondary NIC in my PC. At that point I was wondering why it had to wait 15 seconds when it was clearly getting an address before that. The safe thing to do here sounds like 'nothing', as you suggest.

[TomNB]

The NetBurner device will know what AutoIP address it wants immediately since it is based on the MAC address. It will then immediately do a ping to verify no one else is using that same address. This should only take about a second unless someone else has that address.

Now if you have a direct connection from your PC, and the PC has to fall back from DHCP to AutoIP, that will take 7 to 15 seconds in my experience. So if your time test is dependent on the PC, you can't assume the PC immediately has AutoIP available because it definitely will not be. So the NetBurner could be ready in 1 second with it's AutoIP, but the PC will not be able to talk to it until is does whatever it does to start using it's AutoIP address.