Boot error when using Static IP on WiFi

Hi

I’m getting the following error message

Machine startup has not completed successfully: ‘IfConfig:ioctl (SIOCAIFADDR): File exists’

This happens if I configure WiFi with a static IP address rather than use DHCP. I can just click “Cancel” to continue to the desktop and the WiFi works just fine.

I originally upgraded my install and had this issue, so I did wrote the 5.30 image to a fresh card in case the upgrade had messed up but I have exactly the same problem with the fresh install.

Is this a known problem ? and is there a solution other than using DHCP which I generally avoid like the plague because I like my various machines to always be at the same IP addresses.

Other than that it’s a massive thumbs up for getting native WiFi working, it’s made using my PiTop a much more pleasurably experience.

thanks

is there a solution other than using DHCP which I generally avoid like the plague because I like my various machines to always be at the same IP addresses.

That’s what DHCP reservations are for – making the client machine have the same IP every time.

There is a tendency to think that “static” = “manually assigned”, whereas the truth is that DHCP assigned can be dynamic IP or static IP and the DHCP server only allows one MAC to own a specific IP (no clash of badly assigned IPs)
Meanwhile manually assigned does exactly what you tell it, mistakes in mask or duplicate IPs and all.

Just thinking – you aren’t trying to use the same manually assigned IP on both wired and wireless are you? That wouldn’t work.

Meanwhile manually assigned does exactly what you tell it, mistakes in mask or duplicate IPs and all.

I know you can do DHCP reservations but on a home network it’s quicker and easier just to assign a static IP address, also you don’t have the delay when booting up while all the DHCP malarkey happens. One of the many things I’ve always loved about Risc OS is it’s speed of startup.

Just thinking – you aren’t trying to use the same manually assigned IP on both wired and wireless are you? That wouldn’t work.

In answer to your second point, no I am not trying to use the same manually assigned IP on wired & wireless with the raspberrypi.

I actually do have my wired & wireless interfaces set to the same IP on my main laptop that runs Slackware as it means I can seemlessly go from the freedom of WiFi to the speed of Gigabit wired even mid file transfer without missing a beat when I need the extra speed, but that’s rather off-topic :-)

I know you can do DHCP reservations but on a home network it’s quicker and easier just to assign a static IP address

Is it, after you’ve gone in to edit the hosts file on each machine to include the new static address?

It takes about a minute to assign a reservation on my router, and that ensures that DNS lookups on the machine name work all across the network with no extra effort, too. Not that I statically assign much, because with the aforementioned DNS lookups, it doesn’t matter in a lot of cases.

also you don’t have the delay when booting up while all the DHCP malarkey happens.

Again, I can’t say that I’ve ever noticed that be an issue?

Is it, after you’ve gone in to edit the hosts file on each machine to include the new static address?

Why? If you include the static IP device in your DHCP allocations, it ought to be added to the router’s DNS automatically.

*ping raspberrypi.home PING raspberrypi.home (192.168.1.10): 56 data bytes 64 bytes from 192.168.1.10: icmp_seq=0 ttl=255 time=3.673 ms [...etc...

That being said, I tend to just remember the IP addresses of the things that I use often (.10 the older Pi (static), .14 the inkjet (DHCP), .30 the PC (static)…) as it’s less typing to write 192.168.1.10 than raspberrypi.home. ;)

It takes about a minute to assign a reservation on my router

You can do that when using static IP as well, helps keep the allocation “clear”.

Again, I can’t say that I’ve ever noticed that be an issue?

It was a big issue for me before I got myself a battery backup for the Livebox. A brownout would cause the thing to reset, but not the Pi. So not only would the Pi not notice the router vanishing and coming back ‘different’, but should there be a power cut long enough to shut down the Pi too, that would come back in about ten seconds. The router? You’d be looking at around two hundred seconds, RISC OS having long since given up on DHCP and assigned itself a dud (APIPA) address.

Less of a problem now I have a battery to keep the Livebox running, but I’m not about to go reconfiguring what works…

You can do that when using static IP as well

I repeat “static IP != manually assigned”
t’other way around works, but it’s not a two-way relationship.

it ought to be added to the router’s DNS automatically.

That kind of thing isn’t even a given on a full DHCP server.
You can configure the feature on many DHCP servers such that the DNS entry is updated when the DHCP reservation is used but let’s be honest, if you’re doing the reservation in DHCP then manually configuring the client you’re doing all the work and throwing away the benefits. Madness.

RISC OS having long since given up on DHCP and assigned itself a dud (APIPA) address.

Which, if the stack is properly built, will be replaced by a DHCP address when the stack next checks for the presence of a DHCP address server after a short period – 5 minutes IIRC – (which is 1.5 times your slow recovery router)

Is it, after you’ve gone in to edit the hosts file on each machine to include the new static address?

I don’t bother with the hosts files, I can remember the IP addresses I’ve assigned to various bits of kit that are on my home network, like Rick I just use the actual address. My network is 192.168.0.X so for my server it’s .100 , for my printer its .200 , for my piTop it’s .128 , wife’s laptop .11 , my laptop .10 etc etc I’ve got them all memorized and the muscle memory types the 192.168.0. part automatically.

Anyway I’m not about to change to using DHCP as “manually assigned” IP addressing works just fine for me, so back to my original question is that error message a known problem and is there a way to fix the issue ?

If you’ve manually allocated the IP to the machine, have you also reserved the same address in the router so that it can’t issue it to another machine randomly connecting on DHCP, like a neighbour’s PC?

If you’ve manually allocated the IP to the machine, have you also reserved the same address in the router

As I said earlier:

let’s be honest, if you’re doing the reservation in DHCP then manually configuring the client you’re doing all the work and throwing away the benefits. Madness.

Hmmm.

so that it can’t issue it to another machine randomly connecting on DHCP, like a neighbour’s PC?

If a neighbour’s devices are connecting randomly, the security of the wireless on the router is seriously bad and needs sorting.

If a neighbour’s devices are connecting randomly, the security of the wireless on the router is seriously bad and needs sorting.

True, but it could also be a trusted visitor who doesn’t have a pre-defined IP allocated, or with a phone/device that uses MAC randomisation.

I always set aside a DHCP range for non-fixed devices and make sure that all fixed IP allocations are from outside of that range, but still all done from within DHCP.

I always set aside a DHCP range for non-fixed devices and make sure that all fixed IP allocations are from outside of that range, but still all done from within DHCP.

A perfectly valid method of ensuring the dynamic allocations don’t clash with manually assigned ones – however, it’s still a case of putting in effort without the benefits.

Believe me, I’ve played with all sorts of mixes on a rather extensive network, joined with three others in the county locality and another in an adjoining county.
Manually assigned IPs are nothing but trouble sooner or later.

My “fixed IP allocations” are purely allocated by DHCP, not manually assigned in the device settings, in case that wasn’t clear from what I wrote above. I allow DHCP to allocated non-fixed IPs from the range 101-150, and pre-allocate by MAC addresses in DHCP from outside that range if that makes more sense. If this isn’t the best way, then what would improve it? I’ve also been doing networking going all the way back to CCP/M and thin co-ax, although I admit not to your level, Steve.

Ahem !

So regardless of the benefits/disadvantages of manually assigned IP addresses, the bottom line is nobody knows why I get the error I mentioned in my original post nor does anyone know how to fix the problem to stop the error message.

Enabling DHCP is NOT a suitable answer, if you insist it is then the option for manually assigned IP addresses needs to be removed from network config as it’s broken.

Marvin – since you haven’t received a satisfactory answer thus far, have you tried the RISC OS Developments TCP/IP with Wifi/NetManager? I believe static IP should work with that as John (one of the developers) uses a lot of static IP. I will admit I’ve not tested it – to me Wifi is a natural fit with DHCP for flexibility – but I recall it being discussed during development.

You’d probably need to create a profile with a static IP (etc) allocated to the wifi network, but I think it should be OK. If not, then please let me know so that I can get it sorted.

Enabling DHCP is NOT a suitable answer, if you insist it is then the option for manually assigned IP addresses needs to be removed from network config as it’s broken

You can certainly use static addresses if you want, the thread seems to have veered off as they often do, rather than just clicking the 1 radio icon and giving a solution. All the business happens in !Boot.Choices.Internet.Startup so I’ll post one which uses static IP address and static gateway (minus the big comment block at the top):

|
| Host name
|
Set Inet$HostName RISCOSpi
Set Inet$EtherDevice WLanBWFM
Set Inet$EtherIPAddr 10.0.99.99
Set Inet$EtherIPMask default
|
| Interface: BCM43 WiFi
|
RMEnsure WLanBWFM 0.05 RMLoad System:Modules.Network.WLanBWFM
IfConfig -e wbw0 10.0.0.99 netmask default
CheckError
Set Inet$EtherTypeA <Inet$EtherType>
|
| Loopback
|
IfConfig -e lo0 127.0.0.1
CheckError
Set Inet$EtherType <Inet$EtherTypeA>
Unset Inet$EtherTypeA
|
| Routing
|
Route -e add default 10.0.99.100
CheckError
Run Choices:Internet.Routes
CheckError
Set Inet$IsGateway ""
Set Inet$RouteDOptions ""

How does that compare with yours? I wouldn’t propose ever editing this file by hand, that’s what InetSetup is for, but this is where the work is done so it’s useful to be able to compare a working one as that might point where the duplicate address is coming from.

You can certainly use static addresses if you want

You certainly can as I have it set up here as a test on a Pi4B.

Marvin – since you haven’t received a satisfactory answer thus far, have you tried the RISC OS Developments TCP/IP with Wifi/NetManager? I believe static IP should work with that as John (one of the developers) uses a lot of static IP. I will admit I’ve not tested it – to me Wifi is a natural fit with DHCP for flexibility – but I recall it being discussed during development.

Thank you Andrew, no I haven’t tried that, when I get some time spare I’ll have a play with that.

You can certainly use static addresses if you want, the thread seems to have veered off as they often do, rather than just clicking the 1 radio icon and giving a solution. All the business happens in !Boot.Choices.Internet.Startup

Thank you Sprow, when a get some free time I’ll give that a go as well.

How does that compare with yours? I wouldn’t propose ever editing this file by hand, that’s what InetSetup is for, but this is where the work is done so it’s useful to be able to compare a working one as that might point where the duplicate address is coming from.

Using !Boot network config I changed options until my Startup file matched the one Sprow originally posted and the error disappears but I can now only access my local network.

In addition to the sections configured the same as Sprow I also usually have “Name resolver” and “Access” sections filled in. I doubted “Access” being a problem so I re-enabled that and still no error message.

But when I tick “Try name server too” and fill in primary & secondary name servers it all still works, then I had a realisation that I had also filled in “Local Domain” with an IP address. Comparing that to Sprow’s “Host name” section I have an additional line “Set Inet$LocalDomain” filled in.

If I remove that line the error returns. Somehow that was missing from my original “Startup” file.

Luckily I made backups of all the network config files before starting messing otherwise I’d possibly missed that line and would have had a working network (without getting a error message) after setting everything back to how I thought I’d had it originally and been baffled.

@Andrew, yes switching to ROD TCP/IP stack does also solve the problem.

A massive thanks to both Andrew Rawnsley and Robert Sprowson for your time and help.

Using !Boot network config I changed options until my Startup file matched the one Sprow originally posted and the error disappears but I can now only access my local network.

That would most likely be either be a mismatch of the subnet mask on your device and the router, or a mismatch of the gateway IP on your device and the router.