Small wish - updated DHCP text message

When using DHCP with a non-present interface, it will sit there ad infinitum. This is a large® issue that may be better solved as part of TCP/IP bounty or the like.

However, what should be simple (famous last words) would be to update the “Connecting to DHCP server for interface xyz” message to read:

“Trying to connect to DHCP server for interface xyz. Press Esc key on keyboard to cancel.”

This gives the user clear instructions on how to proceed if the DHCP doesn’t happen/continue.

“Trying to connect to DHCP server for interface xyz. Press Esc key on keyboard to cancel.”

If they do press Escape, they are confronted with the error message Machine startup has not completed successfully: ‘Escape’. This would not sit kindly with an earlier message which invited them to press Escape.

Also, DHCP on RISC OS is notoriously slow: even on a good day you can be sat at the “Contacting DHCP server” message for up to 10 seconds. An impatient user might treat the message as an encouragement to press Escape when nothing is wrong.

I thought it timed out at about 40s?

Timeout only occurs if the network interface is present. Pi zero doesn’t have one, unless it is connected via USB. No USB, but networking configured (eg. from a previous session)? No timeout.

On ARMbook we solved this by not enabling networking by default, and instead supplying software to do in-desktop on-the-fly configuration. However, that solution in ARMbook-specific, and doesn’t help if a user turns on networking manually.

Stuart – I agree about 10s (so perhaps even add “(allow 15 seconds)” – but that’s getting hung up on niceties. If a user presses Escape, they know they’ve cancelled it, so they won’t be surprised. The alternative – never getting to a desktop, is pretty much worse for a Pi Zero user with ethernet enabled.

I thought it timed out at about 40s?

Actually the standards defined response timeout (and fail through to something else – APIPA, or backup IP) is a default at 62 seconds. It has to allow for 802.1x challenge-response timeout and repetition with a fail through to alternate authentication (MAC auth or similar) – not that RO handles that at all so it gets the dumb printer route: (802.1x challenge-response x 3 (default) and fail to MAC)

Mr R. I’d really prefer it if things like this were not made more non-standard.¹
If people want to improve the messaging then possibly add – “…if this slow, there may be a problem with your DHCP server”

There’s supposed to be a revised IP stack in the pipeline and a more modern DHCP implementation might work better.

If a user presses Escape, they know they’ve cancelled it, so they won’t be surprised.

Oh, yes they will, they’re users. Are you sure you’ve done IT support? :)

At work², swift IP pickup on RPi3 from MS DHCP implementation. Same unit on a separate network with IP from a bog basic ADSL router failed about 40% of the time.
I suppose I should add that things like PC’s fail, do APIPA and then retry for DHCP response after about 15 minutes. A more robust failure recovery.

¹ I get grumpy when people suggest non-standard networking. At work the lash-ups other people did always end up with me as a “fix it and it’s urgent, so next 30 minutes please” style job. Rarely do they get a 30-minute fix, but I’ve never had the fixed stuff go wrong again once it was done properly.

Edit – misunderstood your post about “non standard”, but another thread clarified.

My original suggested wording didn’t include a time at all – you can’t be wrong if you don’t make a suggestion!

I guess it depends if you feel it is needed. If you want to give a time, then it sounds like “Allow up to 1 minute for slow DHCP servers” would be appropriate part of the message.

However, if the word/character count could be reduced, whilst still telling the user what to do, that would probably be for the best.

How about…

Trying to connect to DHCP server for interface xyz. Press Esc key on keyboard to cancel, if this takes more than a minute.

misunderstood your post about “non standard”

T’were nothing really. Grumpy and terse then, mostly grumpy.
I’ve not done any work for nearly 6 months, 5 half days back and I’m doing grumpy. I need more beer.

A DHCP negotiation should take a second or two so really your expectations aren’t too far off the mark.

Surely the correct solution should be to test for an interface, and if not present, don’t try to initialise it. I appreciate this isn’t something that could be done in the context of a quick fix for now.

Surely the correct solution should be to test for an interface, and if not present, don’t try to initialise it.

Exactly that. Simply have the test routine pop up a message along the lines of “No fitted Network Interface detected – please check if present”

I appreciate this isn’t something that could be done in the context of a quick fix for now

There’s actually stuff in the !Boot.Resources.Configure.!InetSetup.AutoSense that checks for different interfaces so that’s the logical start point for any change.

Logically the autosense file set should test for available interfaces and then pop up a message and then ensure things like DHCP do not run.