DHCP and gateway

On many OS, DHCP can guess the adress of the gateway (used also for DNS). Is it be possible to implement this under RISC OS?

DHCP can guess the adress of the gateway (used also for DNS)

Guess? In an enterprise environment the IT techs often use the .254 given in Cisco examples, I use .1 but an older install (not me) was x.×.17.172¹ obviously guessing would involve some mystical methods to pick out 192.168.2.172 as the gateway for 192.168.2.0/24

DHCP can pass the details of DNS and gateway as well as the IP and mask, some home routers have a link between the DHCP and DNS instances and thus the DHCP server element auto-populates the DNS so other machines can read the name <—> IP mapping and communicate by name without resorting to a broadcast query.

I’m currently using a BT homehub2 which does this and the beagleboard using current development ROM can be communicated with by name. So can the manually assigned addressing RiscPC – as I put in a reservation for the MAC against a specific IP and the DHCP side passed that to the DNS.

¹ The guy copied an example using a random address. Personally I think it was an example of how stupid you can be. It’s lots of fun (NOT) assigning IP’s and ensuring no one accidentally uses x.×.17.172 as a follow on to using x.×.17.171. So much easier to simply exclude .1 – .10 for your network kit and allow DHCP to assign all the rest.

DHCP can pass the details of DNS and gateway as well as the IP and mask

So could DHCP under RISC OS support that?

So could DHCP under RISC OS support that?

It does – RISC OS is the client and takes the information sent by the DHCP server where it is applicable (e.g. WINS server info would be a bit redundant for RO)

So I don’t have to fill routeur and dns information?

So I don’t have to fill routeur and dns information?

Correct.
Plus, with a decent router the internal DHCP server instance automatically updates its internal DNS so name resolve is done in the router DNS and you don’t need HOSTS file entries in each machine. Much less configuration work.
Normally the DHCP instance allows you to specify that a particular MAC will always be given a specific IP, so if you need a device to be on a specific IP you can do the configuration in the DHCP server and then back up that configuration. You now have the network configuration for all your machines backed up.

OK, I’ll try.

Plus, with a decent router the internal DHCP server instance

This assumes a decent router to start with. I don’t know how it worked, but I could VNC to “Azumi” but I couldn’t “ping azumi”. So I used to set a “static” IP address for each machine. It was DHCP, but certain devices had reserved addresses so I could just tap in the IP address (192.168.1.16 for the Pi) and forget about names.

I write that in the past tense because the new firmware… Let’s just say I could get a many-screenful rant out of how appallingly bad this forced upgrade is. It is so bad, I use the (same type) Livebox that I bought in a boot sale as my DLNA server because the new firmware broke it so it sorta maybe works if you’re lucky. I won’t let the media server Livebox anywhere near a phone line or it’ll get upgradedbroken.

So I don’t have to fill routeur and dns information?

Under some circumstances you do. As I understand it (and my understanding may be wrong) DHCP on RISC OS requests an IP address (whereas static IP requires the IP address to be specified within !Boot). The gateway address sometimes gets populated as well as a by product of this process. Sometimes it does not.

I have found that if you set DHCP and set gateway address manually, then reboot, then reset gateway address to blank and reboot, it is then happy from then on with the gateway address unspecified but known.

No doubt, one day someone will understand why this is or, if it is already understood, explain it to the poor users!

As I understand it (and my understanding may be wrong) DHCP on RISC OS requests an IP address (whereas static IP requires the IP address to be specified within !Boot).

It puts out a DHCP discover packet, gets an offer packet sends a request packet and gets an accept packet
(DORA)
The offer packet contains, at the least, the basics: offered IP, matching mask and the gateway IP. Decent server builds include name server facilities and the offer packet contains the details of these.

If you do a packet capture using wireshark or similar the packet content is pretty easy to read, if you accept the fact that the IP is back to front in human terms

No doubt, one day someone will understand why this is or, if it is already understood, explain it to the poor users!

That’s largely due to the Request element, only requesting a renewal of a known IP when it has prior knowledge of a used IP.

The Discover element is usually broadcast (the machine has no IP to send from) the Request element is frequently (but not always) unicast
A quick google search gives a number of links including this

No doubt, one day someone will understand why this is or, if it is already understood, explain it to the poor users!

Clearly not yet then. The posted link does not contain the word gateway so is not relevant. I don’t think anyone is suggesting that there is a problem with the DHCP process providing an IP address for the machine, it is the gateway IP address associated with the router that is not being returned (so that a DNS address can be found), or asked for, or whatever.

Back to the original post:

On many OS, DHCP can guess the adress of the gateway (used also for DNS). Is it be possible to implement this under RISC OS?

I just tried with a standard Orange France Livebox 2 (Sagem, with the crappy new firmware). I was using a fixed IP setup, so I did this:

1. Open !Boot → Network → Internet (the others (AUN and Access) are disabled)
2. Under Interfaces, the IP address is set to be obtained via DHCP.
3. Under Routing, the Gateway field is blank. The two checkboxes are not ticked. The Routes file is not used.
4. Under Host names, the Host name is set as “RaspberryPi”. Everything else is blank, the checkbox is not ticked.

Save all of that, reboot.

There is a slight pause at startup while the DHCP stuff talks to the Livebox.
The result?

*Show Inet*
Inet$BootFile : 
Inet$BootServer : 192.168.1.1            <---
Inet$EtherDevice : EtherUSB
Inet$EtherIPAddr : 192.168.1.10          <---
Inet$EtherIPMask : 255.255.255.0         <---
Inet$EtherType : ej0
Inet$Gateway : 192.168.1.1               <---
Inet$HostName : RaspberryPi
Inet$IsGateway : 
Inet$LocalDomain : home                  <---
Inet$MimeMappings : InetDBase:MimeMap
Inet$Path : SDFS::RISCOSpi.$.!BOOT.Resources.!Internet.
Inet$ResolverDelay : 5
Inet$ResolverRetries : 3
Inet$Resolvers : 192.168.1.1 192.168.1.1 <---
Inet$RouteDOptions : 
Inet$Started : Yes
Inet$Startup : Choices:Internet.Startup
InetDBase$Path : SDFS::RISCOSpi.$.!BOOT.Resources.!Internet.files.
InetSetup$Dir : SDFS::RISCOSpi.$.!BOOT.Resources.Configure.!InetSetup

The highlighted options are set by the DHCP service.

I note the following in the Startup script:

IF "<Wimp$State>" = "commands" THEN Echo Contacting DHCP server for Ethernet over USB interface
DHCPExecute -e -b -w -p ej0
CheckError
If "<Inet$Gateway>" <> "" Then do /Inet:bin.route -e add default <Inet$Gateway>
CheckError

So it may be that some equipment just doesn’t (correctly?) allocate gateway addresses with the DHCP.

I note also that the previous Livebox firmware took account of the “Host name” provided in the settings and automatically called this device “RaspberryPi”.
<rant>I would imagine the new firmware would so likewise, only it is quite happy to inform me that no devices are connected (anywhere, at all), which that is quite obviously rubbish. Oh, and I’m really pleased that I had set up a NAT for some of the ports I use, because turning them on and off is a tickbox job. Adding new ports? Forget it – that’s just all kinds of broken. This new firmware must have been put together by a “stagiaire”…</rant>

The posted link does not contain the word gateway so is not relevant.

The posted link shows a very much simplified version of what is available. Many more options than just the client’s IP address can be carried in the messages – and I think normally would be. The gateway is but one of them.

For a more detailed but still approachable explanation, try the Wikipedia entry.

If you want the comprehensive explanation, you’ll need to consult the RFC. But I expect you don’t need that.

So it may be that some equipment just doesn’t (correctly?) allocate gateway addresses with the DHCP.

That may be so, but these lines are there because it is not mandatory for a DHCP request to return with a non-empty gateway address. If no gateway address is returned, no default route is added – it is as simple as that.

In the long history of RISC OS 5 DHCP, I cannot remember even one router that didn’t return the correct gateway address if configured to do so. So I am not sure what this thread is all about. “It just works”.

So I am not sure what this thread is all about. “It just works”.

Mmm, would seem to be my experience here, yes…

[I only get rid of DHCP because ages ago (pre-Vonets), it was a long pause at startup…]

Once it works, it works. If you don’t go through the steps I mention, it says there is no DNS server. It is clearly a bug but easy to work around. Shame no-one has understood this.

Chris, I never had to do the steps you mentioned. It just worked. The one thing you have to do is fill in the host name.

If you don’t go through the steps I mention, it says there is no DNS server.

Oh, I understood. I did specify that the router hosting the DHCP server and DNS needed to be reasonable quality.
I’ve dealt with a fair few bits of network kit and I’ve yet to find a client implementation that ignored a DHCP returned gateway¹.

A Pi straight from the box, powered up with a network connection registered the defined name in the DHCP and hence in the DNS. This didn’t surprise me, I expected it to behave like the beagleboard.

As Steffen says “It just worked”

One thing to note is that, like the setup Rick quoted, the FQDN for a device called PiBoard is PiBoard.home so a ping to “PiBoard” will fail while ping PiBoard.home will work.

Proper registration of the name in DHCP was the problem in an earlier RO5, fixed somewhere in 5.19 if I recall correctly.

¹ Even the terminally crappy networking in over expensive medical equipment manages to do it right

Proper registration of the name in DHCP was the problem in an earlier RO5, fixed somewhere in 5.19 if I recall correctly.

I’m convinced the problem was still there in RC12a, I’ll check again…

Under Host names, the Host name is set as “RaspberryPi”.

At one time it was set to ‘.nom’ if I recall correctly.

I have started up a fresh RC12a SD card image and, although supposedly already set up (as supplied) for networking using DHCP, it gives the error ‘no domain name servers configured’ when first booted. It is not a problem with the host name as that is correctly set all through.

If I type a gateway address into the routing box (Configure/Network/Internet/Routing – Gateway address), reboot, ignore the error ‘machine start up has not completed successfully route add net default gateway 192.168.1.1 file exists’ (special award for obscurity for that error message) by pressing Cancel, erase the gateway address that I entered leaving the field blank, reboot again and it starts up correctly with internet access working correctly.

This just needs to be documented. Clearly the gateway address is put somewhere as a result of this process so that the system is happy. This process is repeatable – every time I start with a fresh RC12a SD card image I have to go through the same process to get networking working.

I did specify that the router hosting the DHCP server and DNS needed to be reasonable quality.

I have a TP-LINK 150M Wireless Lite N ADSL2+ Modem Router Model No: TD-W8950ND – this should be good quality. My network (not precisely up to date but correct in the relevant bits) is here with the Pi connected via WiFi using a Netgear WNCE3001.

Oh well, back to the fixed IP setup.
Why?
The Pi is so damn quick at booting, if the things are plugged in at the same time (as they are, dual output USB plug), the WiFi is not up and synced in when the Pi asks for the DHCP stuff, hence cold-boot always fails, a warm reboot is okay.

Hehe…
;-)

That looks like the solution – it waits for a DHCP address until the WiFi (which has also just been turned on) has linked to the ADSL modem (which gives out the DHCP addresses and is on all the time) and has a green light (well within the 45s boot delay after which it fails the network start up) but seems that it just gets its IP address and not the DNS address on a cold boot. AIUI providing the gateway address along with the allocated DHCP address is non-mandatory. On a warm boot it all goes OK.

It’s a pity RISC OS doesn’t ask again for the DNS address automatically a bit later on but it seems it needs a full reboot to do that. Many thanks for diagnosing this.

It’s a pity RISC OS doesn’t ask again for the DNS address automatically a bit later on but it seems it needs a full reboot to do that.

Yes indeed. It would be great if the machine had an option to “try again” after the desktop has started up, at least before throwing in the towel. There may however be some sort of complicated reason why it cannot do this – certainly invoking the command manually went through the motions (blinking lights on the Vonets) but nothing changed, configuration-wise.

I might write in a small program to bounce a packet of the Livebox, and if no reply, to keep trying once per second for up to 30 seconds.

Of a little more concern to me is this. I will come straight out and say that I don’t really understand the low level networking stuff – but with the comment saying this: “/* OK - the server has accepted our DHCPREQUEST and we can now tidy up the conversation and forget about it (for dynamic leases we need to remember it for future renegotiation, but we don't do those yet) */” – aren’t the leases all dynamic? (the D in DHCP) If so, what happens in ~24 hours when the given lease expires?

If so, what happens in ~24 hours when the given lease expires?

Don’t know but every other week (approx.) I have to turn off the ADSL router and turn it on again to renew things.