Problems with DHCP on the Pi

I posted this in one of the Raspberry Pi threads with no response so I’m posting here as it’s definitely reproducible and definitely a problem IMO.

I have an issue with DHCP and I’m not sure whether is a bug with the RISC OS distribution for Pi or with the DHCP client in general or whether it’s a compatibility issue with my DHCP server which is a Windows 2000 Server running DHCP services amongst other network services. The DHCP server has been running for over 10 years now and the Pi/RISC OS combination is the first device I’ve come across that has an issue with the network config and in that time I’ve connected all manner of devices and operating systems to the network.

The issue is that the RISC OS DHCP client requests and receives an IP address successfully but the gateway, DNS servers and all the other domain information that is being sent by the DHCP server is being ignored. This means that I have to manually set the gateway and DNS data before I can access the network where it should be done automatically.

I’ve looked at the boot scripts and played around with REinit’ing several modules and manually running DHCPExecute and I can confirm that the gateway and DNS hosts strings that should be populated on return of DHCPExecute are empty.

Once I’ve manually configured the Networking config leaving the IP address to be assigned via DHCP but setting the gateway and DNS hosts by hand, it can access both the local network and Internet fully and can use ShareFS to access other RISC OS machines that I have running RISC OS 3.11.

Paul

I’m doing some work on the DHCP module at the moment, although nothing to do with the processing of info from the server, yet. So hopefully I can take a look at this soon.

Have you got other RISC OS devices on your network using DHCP? What version of the DHCP module are you using?

*H. DHCP and *DHCPInfo both report the DHCP module as being 0.21 (05 Aug 2004).

Sadly my other RISC OS machines are OS 3.11 so even with the Universal Boot installed they don’t actually support DHCP which makes ruling RISC OS in or out difficult. This is my first up to date RISC OS machine in years as I skipped the RISC PC, Iyonix and ARMini etc. and I’m returning to the fold so to speak ATM so whilst I’m reasonably familiar with RISC OS in general usage, my knowledge of RISC OS >= 4 is more limited.

Having said that, the devices that connect to the network usually are quite diverse encompassing Windows (NT – Win7), Linux (Ubuntu/Debian/Maemo), Android (various updates), OS X and iOS (various versions), Symbian and Amiga OS 3 plus games machines like PS3, X-Box 360, Wii and some more esoteric devices like NAS drives (with unknown Linux distro’s), Blu-ray players and an Internet ready TV.

Quite a shopping list really.

Almost all are using DHCP with the exception of three Windows servers, one NAS drive, my Amiga and my RISC OS 3.11 machines. All DHCP assignments for all those systems work just fine.

Paul

I’d recommend trying again once Rik’s changes are committed – while there are no specific changes regarding how DHCP offers are processed, there is effectively a change in how they are requested and as such, the windows DHCP server may respond in a different manner with the new version.

That’s supposition, of course, but it’s at least worth waiting before digging any further…

@Tony, Sounds good.

Just to be completely clear about what I’m seeing, when DHCPExecute runs against a Windows DHCP server, Inet$Gateway and Inet$Resolvers are being returned as blank strings.

@Paul,

Understood. Out of interest, have any of your other windows machines ever had DHCP enabled? If so, this might be relevant:

http://support.microsoft.com/kb/263217

No, my network config has been fixed as it is now for years hence I’m still running Windows 2000 DHCP services. There’s no need for any Windows device to run ICS and even then what I’m seeing would only apply if the RISC OS machine were receiving DHCP information from two different DHCP servers which it isn’t.

As I understand it in the MS support case, the settings would be different but still set according to the second DHCP server rather than being not set at all.

Just to confirm this behaviour, *DHCPInfo returns the correct IP address for my networks DHCP server.

Just to confirm this behaviour, *DHCPInfo returns the correct IP address for my networks DHCP server.

Paul, from your answers you seem to have a grasp of the response you expect from the server, so if you can load a copy of wireshark on a PC and, using a mini-hub as a form of tap, connect the PC into the link between the RISC OS machine and the server to capture the traffic.
Note: In a normal switch you can often mirror a port (Cisco call it SPAN) to get the tap off effect.

A display filter of DHCP (it is case sensitive) will allow you see and then check the content of every DHCP related packet. Check the content of each element of the DORA sequence.

Steve, my switches aren’t clever enough to do port mirroring so I’ll need to see if I can locate a hub in the loft and try that. I’ve got Wireshark installed on a couple of machines and am familiar with how it works so I’ll see if I can provide more info for everyone.

Paul

Steve, my switches aren’t clever enough to do port mirroring

If you’re anywhere near Coventry I have a few old AT 8350GB and 8326 switches.
www.alliedtelesis.com/media/datasheets/guides/8350gb_ig_b.pdf

I’ve just turned the loft upside down… No hub to be found. I was sure I had one tucked away somewhere too.

If you’re anywhere near Coventry

I’m in Hinckley… Not far at all :D

Paul

Binley Woods (east side of Coventry)
steven dot pampling at btinternet dot com

Done a little more digging. A lot of the work interpreting DHCP replies is actually done by the Internet module, not DHCP itself, which really just handles server discovery and message passing.

As such this is probably going to take a bit of solving. I’ll see if I can set up a Windows server for testing. I also note that there’s a comment in the internet module sources:

The Microsoft DHCP server (at least as far as NT4/SP3 goes) does NOT send BOOTP-style clients any options other than those it thinks might be useful to a Microsoft Windows client. Typically this excludes some of the most useful data usually returned via the BOOTP/DHCP protocol. Its one saving grace in this respect is that it DOES actually honour the DHCP Parameter List Request option when it finds it in request packets and does respond with the requested options.

Just to be completely clear about what I’m seeing, when DHCPExecute runs against a Windows DHCP server, Inet$Gateway and Inet$Resolvers are being returned as blank strings.

Also – blank strings, rather than the variables not being set at all?

Ok, I did a bit of packet sniffing on my switches figuring at least some of the DHCP process is broadcast. It turns out it’s entirely done via a broadcast mechanism so I now know why the data is not being set.

It’s not being requested, simple as that. What I’ve found concurs with the information above so it seems that the parameter list needs to be extended to include asking for the gateway and DNS servers at the very least to ensure that RISC OS works correctly when the DHCP server is a Windows based system.

I’ve saved a filtered Wireshark packet capture showing the full conversation for the Raspberry Pi (0.0.0.0) issued with an IP address of 10.1.1.15.

After that there are two entries where another machine on the network re-affirms its current settings even though its lease expires at 1:17am tomorrow. This shows that it actively asks for more info and receives it from the DHCP server.

Wireshark DHCP packet capture from Pi

Paul

@Steve Thanks for the offer. Based on what Rik and I have found, I don’t think it’ll be necessary now :D

Paul

@Paul.
Shucks – too many doorstops and footrests.

@Rik, I assume blank strings yes. Looking at the startup script, it looks at the variables and if they’re blank it sets them to the manually configured settings instead.

Paul

I’ve saved a filtered Wireshark packet capture showing the full conversation for the Raspberry Pi (0.0.0.0) issued with an IP address of 10.1.1.15.

After that there are two entries where another machine on the network re-affirms its current settings even though its lease expires at 1:17am tomorrow. This shows that it actively asks for more info and receives it from the DHCP server.

Wireshark DHCP packet capture from Pi

On a skim through I note you are using a 10.×.y.z address with a /24 (old class C) mask and also that the Pi seems to be using a MAC address traditionally associated with MS NLB virtual interfaces.

I have seen quite a few implementations of IP stacks that have a bit of a paddy about foreign masks.
i.e. give a machine a 192.168.×.y address with anything other than a /24 mask and the stack ignores the mask data, tries to assign a 192.168.×.y/24 and gets a NAK back from the server.
Others (Motorola PDAs being one) took the IP added the wrong mask and simply didn’t work.

IIRC the MAC on the Pi is the same situation as on the beagle and is a random value each boot time, which is a pain in most DHCP networks other than a small home network. DHCP assignments tend to be sticky with regard to the assignment to a MAC.

Anyone tested this with a pre-assigned MAC to ensure no strange effects?
(u-boot option etheraddr=00:00:a4:01:e2:00 for yours – 00-00-a4 is Acorn, 01-e2 is your user id in hex, and 00 starts you off with another 254 possible machines)
I haven’t checked whether the RO HAL reads this, theoretically, assigned MAC through into use in the stack. Maybe at the weekend.

On a skim through I note you are using a 10.×.y.z address with a /24 (old class C) mask and also that the Pi seems to be using a MAC address traditionally associated with MS NLB virtual interfaces.

Yes, I actually have a separate 10.10.1.z network too which runs a DMZ. The 10.1.1.z network is firewalled off from the 10.10.1.z network which is in turn firewalled off from the Internet in general.

Unknown guest users (and wireless users) are restricted to the 10.10.1.z IP range and trusted machines (wired network) which at this stage includes the Pi are on the 10.1.1.z IP range.

I used to subnet the 10.1.1.x network with 255.255.255.224 and I kept all the RISC OS and Amiga’s on a different subnet to the rest of the network as they all required manual IP configs and didn’t really need full Internet access and I wanted to keep them reasonably separate. I changed this only a couple of weeks ago to 255.255.255.0 so I could leave the Pi on DHCP and access the RISC OS machines over ShareFS and I added a range of IP’s that the DHCP server will not provide which covers all the old RISC OS machines and Amiga’s.

Paul

IIRC the MAC on the Pi is the same situation as on the beagle and is a random value each boot time

I believe this is a temporary situation. I gather the GPU does contain a unique pre-assigned MAC address – work is ongoing to fetch that across to the ARM side.

I believe this is a temporary situation. I gather the GPU does contain a unique pre-assigned MAC address – work is ongoing to fetch that across to the ARM side.

Just on the Pi, or across all dev board varieties (Pandora, Panda, Beagle, OMAP5, etc) ?

I was talking about the Raspberry Pi there – it has a rather odd architecture where the GPU is the main part of the chip with full access to all hardware, and the ARM CPU is tacked on the side and is somewhat of a second-class citizen. The MAC address is one of the things that we can only get hold of in conjunction with changes to the firmware for the GPU (which itself also still under development).

I’m not aware that the OMAP3 or OMAP4 have anything like a MAC address, or even a unique ID that could be used to seed one either, so they’re stuck with a random MAC address – unless anyone knows better?

Just on the Pi, or across all dev board varieties (Pandora, Panda, Beagle, OMAP5, etc) ?

The RPi is a completely different chipset to the other boards you list. The problem with MAC addresses is specific to the RPi and work is on-going to solve it. For the other platforms, YMMV. However, I’m not aware of any of them having the same sort of issue.

A stupid question. The LAN is SMSC9512 and EtherUSB is working? Why can the MAC not set on the same way as on the BeaglexM and Panda? Sorry I don’t read all posts and my Pi is on the way (I hope).