Network and Pi

It is likely that Pi computers will sometimes have a network cable plugged in and sometimes not (they are quite portable things after all). If they are set up to have DHCP networking (a reasonable choice or compromise) but find themselves with no network cable would it be possible to have a tidier response than an indefinite time waiting (waiting for DHCP server)? Pressing Escape can lead to other things in the boot sequence not happening (I think) and is not a tidy response. Perhaps finding no DHCP/ no network time/ no other RTC source should also lead to a request for user to input the time and date?

Perhaps finding no DHCP/ no network time/ no other RTC source should also lead to a request for user to input the time and date?

I firmly believe that it should attempt to detect a local clock, otherwise find and use a network time source, otherwise ask the user, in decreasing priority order.

worked out how to share network connections on an ancient old XP laptop

Is any extra software needed to do this? The Bristol user group had a good go at doing something similar last night (thanks, Chris and Que) but couldn’t get Windows to share the pub’s Wi-Fi via ethernet. I’m probably going to buy a wireless ethernet bridge, in anticipation of having my own Raspberry Pi.

Dave, is there a reason why you listed them in that order? The crystals in most consumer electronics rarely seem to be carefully calibrated, and even if they have, there is usually a strong temperature-dependent effect. Errors of 20 ppm or more are not uncommon – that corresponds to an error of one minute per month.

By contrast, NTP time is ultimately derived from atomic clocks, so you’re not going to beat its accuracy. Local RTC chips only really come into their own when you’re operating offline – but it’s relatively uncommon to remain offline for a month or more.

Dave, is there a reason why you listed them in that order?

I take it that, if a local clock is present, the user wants to use it (in the case of the RPi, for example, s/he has paid extra for it), and has his/her own arrangements to synchronise it.

I understand all about accuracy, believe me!

Isn’t that what the option to disable NTP is for? I’d have thought that the most common use case would be for the RTC to be used as a backup for when the user is working offline – other cases (like testing that software works if the clock is wound forward to an significant rollover time) are much more specialist.

Plus, is it safe in general to assume that the mere presence of an RTC means that the user wants to use it? Risc PC, Iyonix and emulator users have no choice in the matter. Beagleboards all have an RTC, but only had the option of a battery backup for it from rev C3 onwards (the battery isn’t fitted as standard due to air cargo restrictions on the metals it contains). Raspberry Pi is an oddity in this respect, in having the RTC on an expansion board.

What happens if a user deliberately wants the clock on a different time zone – or deliberately wrong for experimental or other purposes? (This is occasionally done where I work.)

Crashing over it and setting someone else’s idea of the correct time is a bit… well… Microsoft.

What happens if a user deliberately wants the clock on a different time zone

Well they could disable NTP support from the configuration plugin if they don’t want their local time to be changed.

Or they could plug the RPi into a network that redirects the NTP DNS entry to a local NTP server that has been suitably altered (Or to a non-existing domain). Which is what we tend to do when testing these things.

Is it safe in general to assume that the mere presence of an RTC means that the user wants to use it?

Possibly not.. If the RTC isn’t battery backed (or the battery is flat) then the time it contains may not be valid.

Although if its the only time source available then you might as well use it.

For those without an RTC can we do what the RPi does under Linux and save the current time at shutdown and restore it at startup? This would at least allow file time stamps and such like to remain valid if the RPi is rebooted and no longer on the network (I can’t seem to get NetTime working on my RPi so every reboot resets the time to 1970, which I’m sure is confusing make!)

What about something like this.

Initially set the time to either build date of the ROM or what the RTC reports (subject to sanity check).

When Boot starts, check this is later than last shutdown time, reset if needed. (Last shutdown time, plus 1 minute?)

When Internet is available, do a net time.

At end of boot, if time hasn’t been set by RTC or Net, open the set clock panel.

later than last shutdown time,

currently this is not recorded nor any file changed that could be examined. But it is on the list.

XP network connection sharing – it’s actually relatively simple, once you figure out where the settings are. Right-click the network connection you want to share, select ‘properties’, then the ‘advanced’ tab, check the ‘allow other computers to share this connection’ box, then select the connection you want them to be able to access it from from the drop-down box. Apply the settings and you’re done :)

As for DHCP:
I went and dug into the code. If I’ve read it right, it seems there’s a couple of things that could do with changing.

1. The DHCPDISCOVER timeout T2 (it does follow the RFC for retries, as it turns out) is 10 minutes. This is fairly mental, considering almost any other OS (linux, OS X, windows) gives up after 30 seconds at most.

2. The process after exhausting the retries and hitting the T2 timeout is simply to start again. So in effect, even though there’s a timeout set, DHCP will hang indefinitely if no server sends back a DHCPOFFER reply. So this isn’t just a problem if there’s no network cable plugged in, it’s also a problem if either the DHCP server fails, or there are connectivity issues.

That gives two options of a fix for when the T2 timeout is hit and no DHCPOFFER has been received:

1. Take down the interface. The code is already there to do this, the comments suggest it may have unknown consequences, but this seems to apply to when it happens when a renewal of a DHCP lease fails. On boot may be another issue.

2. Apply an RFC-compliant 169.254.xxx.xxx address (with the third and fourth octets randomised), with either an infinite lease time or a sensible lease if you want the interface to try again at some point in the future.

That would give a DHCP client that can be left enabled and will work sensible in almost any situation.

I don’t have CVS access (or a build environment, for that matter) to try and test this, but I’ve hopefully enlisted someone who does to try the changes for me…

Sounds sensible to knock T2 down to 30 seconds and go with option 2, maybe with an infinite lease (to stop your desktop being blocked for 30 seconds after a ‘random’ interval when you don’t have a network).

Working on it at the moment :0)

As it stands, we’ve got the interface being disabled after 30 seconds with no reply, but still having to hit escape to skip the process for some reason. Having to do this long-distance doesn’t help speed the process, but we’ll get there…

I don’t think you’d get interruption to the desktop, as once the boot phase is over, the DHCP module will no longer be running in “blocking” mode.

I suppose the question is – if DHCP fails to get an address at boot (when entered with “*DHCPExecute -b”), should it:

1: fake a lease (possibly infinite) for a private IP.
2: forget about the interface but assign a private IP anyway.
3: forget about the interface and mark it as down.

I think it should be configurable between the following choices:

1. Disable networking (if lease has expired), keep trying for new lease periodically.

2. Disable network adaptor (for machines usually not connected to a network, there could be an obey file to re-enable it if a cable were plugged in)

3. Keep using the previous address, (trying for a new lease regularly.)

4. Use configured static IP.

5. Use a microsoft style 169 autoconf

So far, I’ve added a new switch to DHCPExecute: “-p”. The intention is that eventually this will cause a private address to be assigned if no DHCP server is available.

For now, the behaviour is that when the DHCP request times out, the DHCP module forgets about that interface. Another DHCPExecute command could be issued at some future time, to attempt to context the server again.

The practical upshot of this is that if Boot:Choices.Internet.Startup is changed to include the -p switch to DHCPExecute, you no longer need to press Esc to abort the DHCP phase of the Boot sequence – it times out after about 30 secs.

Interestingly, it seems that someone (the Internet module?) assigns an IP address of the form 1.107.a.b in these circumstances (where a and b are the last 2 bytes of the MAC address).

Which leads to the question – should the Internet module be changed to assign a valid private IP, and leave the behaviour of DHCP as I described above? Or should the DHCP module be responsible for managing an interface?

The latter approach is probably more flexible, but also more work :)

Which leads to the question

Is it possible for the DHCP option to have all the manual IP addresses set as well but just have the option as ‘full DHCP’ (with no static addresses set, as now) or ‘try to get DHCP but if it fails after 30s use the static addresses specified’ (with static addresses set)? From the user point of view, the choice between static and DHCP can sometimes be dictated by what it is connected to. For example you may have a few DHCP networks and one that you know either can or must accommodate a static address. The you wouldn’t have to keep changing the set up as you carry the Pi around. Also gets over the current need to press ‘Escape’.

I think that could be accomplished without needing to change DHCP itself, but I’ll investigate. Certainly a choice of fall back to a static IP or pseudo-random private IP seems sensible.

I would suggest the following sequence:

1. Attempt DHCP.
2. If DHCPDISCOVER (i.e. a request for an available DHCP server) fails, send a DHCP request with the last known IP address held.
3. If still no response, consider DHCP failed. Then progress to:
4. If it exists, assign static IP and routing details specified by user config.
5. If that doesn’t exist, auto-config a link-local (169.254.xxx.xxx) address.

All of this should happen in around 30 seconds, to retain reasonable boot times.

(5) has an RFC all of its own and requires a little more work, as it’s designed not just for when the host is the only machine to deal with, but also when the host is on a network with no DHCP server, so it has to play nicely with any other machines that might be in a similar situation and even potentially a network comprising of some link-local addresses and some in normal address space.

Perhaps some of this should be configured using “key=value” pairs in the extended CMOS file.

For the record, the culprit that is setting the non-private IP address is the Freeway module. Luckily there’s a *configure option: FreewayAutoAddress which needs to be forced to off if DHCP is in use. This can be done by the !Boot plugin I imagine.

I haven’t been keeping up to date with the pseudo-CMOS situation, so I’m not sure how this will work on the Pi (and other machines with no CMOS).

The CMOS read/write calls should be transparently converted into SD card reads/writes now, both on beagleboard derivatives and (as of a couple of days ago) Raspberry Pi. The only noticeable difference should be that the user may be prompted to switch cards if the one they booted from isn’t inserted.

Talking of CMOS, the !Boot network plugin seems to have the facility to read an IP address from CMOS (bytes 108, 109, 110 and 0). I can’t quite work out under what circumstances this is used, but is there any reason why the DHCP module can’t read this stored address and apply it to the interface if DHCP fails?

Off the top of my head, how about two new flags for the DHCPExecute command, that only have an effect if no address can be obtained from a server:

-p : assign a link-local IP in the range 169.254.xxx.xxx

-c : assign the IP stored in CMOS

To be honest, I won’t be able to spend too much more time on this for a couple of weeks so we’ll try and get the ‘-p’ flag implemented which should be good enough to solve the inital problem, I think.