Changes to DHCP module, etc

I’m about to submit the following changes to the CVS. The purpose of these is to allow a machine with no network connection to boot to the desktop without needing the user to press Escape, and also as a first step towards a more comprehensive network auto configuration system.

A summary:

Added a new switch “-p” to the DHCPExecute command. The effect of this is that if DHCP discovery times out, the interface is allocated an IP address of the form 169.254.×.y where x and y are taken from the interface’s MAC address, and the DHCP module ignores that interface thereafter.

Added a corresponding bit (bit 4) to the flags word r0 to SWI DHCP_Execute.

Changed the DHCP discovery timout from 10 minutes to 20 seconds.

Changed the InetSetup !Boot plugin to add the “-p” switch to the DHCPExecute command it writes to !Boot:Choices.Internet.Setup.

Changed InetSetup to required DHCP v 0.22.

Changed Freeway module to assign an IP address of the form 10.×.y.z (instead of 1.×.y.z), in the situations that it assigns an address.

It’s worth noting that when DHCP tries to assign the private address to the interface, it doesn’t currently remove any address already present. So if the *configure option “FreewayAutoAddress” is ON, the 10.×.y.z address assigned by Freeway will be the one used.

Who’s in charge of the default CMOS options? I recommend that this option be OFF by default :)

Who’s in charge of the default CMOS options?

This is set in the Kernel. Nobody really ‘owns’ the defaults – as in, ROOL don’t take charge of them – so it’s trivial to make this change. Having said that, I have no idea why Freeway behaves that way and why it’s currently the default. It gives me the feeling that there must be a good reason for it. My knowledge of IP and related RFCs is simply not up to guessing what that reason might be.

So, your suggestion seems sensible, the change is trivial but we can only guess at what unforeseen side-effects it might have. Are the obvious (good) side-effects enough to justify making this change? Probably.

Having said that, I have no idea why Freeway behaves that way and why it’s currently the default. It gives me the feeling that there must be a good reason for it. My knowledge of IP and related RFCs is simply not up to guessing what that reason might be.

Someone picked a widely used default. Without checking, does Freeway use multicast by any chance?
Until relatively recently the block wasn’t allocated and you will find things like Cisco documents stating that the address to use for a circuitless IP for multicast RP should be 1.1.1.1 or 2.2.2.2 or similar.
From all accounts IANA activated the correct routing “out there” and then checked for any traffic. Since there are a lot of switches from the above mentioned manufacturer (and others with the same recommendations) they found rather a lot of traffic.
Not good news for the Asia Pacific area that was allocated the block. IIRC¹.
Sometimes people do what everyone has done because they don’t read standards, sometimes it’s because they work for a big company.²

As it turns out, work got in the way and I didn’t get chance to check in these changes today. Will do it tomorrow.

A comment in the Freeway source suggests that the decision to use a 1.×.y.z IP address was made in about 1994…

Can I suggest some variations on what is proposed to try to limit the number of unforseen side-effects.

Is falling back to a 169.254.×.y address actually required? If you’re adding a new “-p” switch why not just specify the fallback static address to that? Obviously this requires a bit more plumbing in the network interface dialogue.

Also, it’s worth mentioning there are bits allocated in CMOS to determine if DHCP is to be used along with 4 bytes to hold a (single) static IP address. Perhaps these could be employed – please try to keep in mind discless boot.

I’ve probably missed something, but why is FreewayAutoAddress implicated here? Wont changing from a 1.×.×.x to a 10.×.×.x address break everything else using ShareFS where 1.×.×.x was the default?

Changed InetSetup to required DHCP v 0.22

I’ve had a quick try and the DHCP module doesn’t seem to fault extra switches, so this is unnecessary, since earlier versions will be unchanged behaviour. I’m currently picking through years of these kind of changes in the boot sequence, I don’t want any more adding thanks!

Is falling back to a 169.254.×.y address actually required? If you’re adding a new “-p” switch why not just specify the fallback static address to that? Obviously this requires a bit more plumbing in the network interface dialogue.

Static address fallback is a feature of DHCP on other client implementations (dare we mention MS?)

I’ve probably missed something, but why is FreewayAutoAddress implicated here? Wont changing from a 1.×.×.x to a 10.×.×.x address break everything else using ShareFS where 1.×.×.x was the default?

192.168.×.y and 10.×.y.z (and 172.16.×.y) are not routed on the internet. Although 1.×.y.z was not internet assigned when Freeway was designed it is now and home routers will pass the packets through to the internet.
This may lead to problems for users when responses to the packets arrive.
Maybe not critical right now, but best not to plan on not having to change.

I think the Freeway change will only break ShareFS if there’s a network relying on the Freeway auto assigned addresses, where some machines are running the old version and some the new. However as Steve says, assigning a 1.×.y.z address is just plain wrong.

Point taken on the DHCP module requirement for InetSetup, I can reverse that.

Also I’m aware of the CMOS bytes allocated for an IP address. Storing a fallback address there seems like a good idea, I suggested it in the other thread on this subject (in community support).

I hope to get more time to work on this after I get back from holiday in a week. The current implementation is not perfect, but it does solve the initial problem which was requiring the user to press escape during the boot sequence if no DHCP server was available.

For example, DHCP could be extended in future to use a fallback address on the command line or if there isn’t one specified, use the current scheme of generating a private address.

Changed Freeway module to assign an IP address of the form 10.×.y.z (instead of 1.×.y.z), in the situations that it assigns an address.

Thanks for filling me in, it sounds like it’s not directly related to the title of the thread. The change seems very sensible – don’t want ShareFS packets leaking out of a private network!

Also I’m aware of the CMOS bytes allocated for an IP address. Storing a fallback address there seems like a good idea, I suggested it in the other thread on this subject

I think that’s what those allocations were intemded for, though probably in a set top box scenario. I had a quick look at InetSetup and it looks like it shades out the “from CMOS” radio button if it contains all zero (which it will be default) – but I don’t see any easy way to make it nonzero – otherwise it does look generally supported. There’s a ReadCMOSIP utility in !Internet for example.

Yes, InetSetup could use some more work, certainly!

Have made the following changes to InetSetup but not going to check it in yet as there will be more to come:

Bug fixes:

Rmensure DHCP module if an interface is using DHCP, whether or not it’s the primary interface.

Don’t rmensure DHCP if interface is turned off.

Faded netmask box if DHCP or BOOTP are in use.

Nastyness fix: In response to the “restart now” button, call TaskManager_Shutdown instead of OS_Reset. This gives the user a chance to realise that they have an unsaved document, or something in the RAM disc.

The only trouble is that the TaskManager doesn’t appear to support the flag bit that means “restart after shutdown”, so I’ve modified the TaskManager too. My solution is, if bit 5 of r0 is set when TaskManager_Shutdown is called, 1 second after displaying the “It is safe to turn off your computer” screen, OS_Reset is called.

This means that the function of bit 5 depends on bit 0 (don’t display post-shutdown screen) being not set. Which seems sensible, as if bit 0 is set, the command prompt is entered after a shutdown.

Have checked in a new version of DHCP, 0.23. There was a stupid bug in 0.22 which caused it to data abort when run on the RPi. In fact I’m surprised it worked at all :)

I’ve also made it so that when DHCP applies a private IP address to an interface, it deletes any existing address of that interface. This means that, in the context of a network-less boot, any address set by Freeway will get deleted and the 169.254 address from DHCP will be the one used.

However if Freeway is setting an address at boot (ie FreewayAutoAddress is On), for technical reasons, DHCP will take twice as long to time out – 40 seconds instead of 20.

I’ve also checked in the new InetSetup as the changes to DHCP are pointless without InetSetup adding the -p switch to the command in the obey file it creates.

I’m now on holiday for a week, I hope I’ve left everything in a state where it’s working and useful. Will do more work in this area when I’m back!

A few of points I didn’t have time to address:

Ideally the default CMOS file for Raspberry Pi (and probably all distributions) needs to have FreewayAutoAddress configured to Off.

If a Boot:Choices.Internet.Startup file is present in the default disc image, and DHCP is on by default, the -p switch needs to be added to the DHCPExecute command in this file.

InetSetup was calling OS_FSControl 23 (shutdown) when the user selected “Reboot now”. As v0.44 calls TaskManager_Shutdown, this is no longer required. But I noticed that if you do call this SWI on the Pi, it corrupts the files that InetSetup has recently written to the disc. Perhaps a bug that someone needs to look at?

InetSetup currently doesn’t set bit 5 in the flags to TaskManager_Shutdown, as OS_Reset currently causes a data abort on the Pi. Once OS_Reset is fixed, this feature can be implemented.

I haven’t yet checked in the version of TaskManager that supports bit 5 anyway.