Today's pointless tinkering - Static IP addresses all round

Today’s fun and games. Setting any networked device which is ‘permanent’ (ie does not leave the house) with a static IP address. Why bother? DHCP does work very well but just occasionally there are IP conflicts and something stops working. Plus I like to decide what device sits where on the network.

Is it necessary? Not really but for example my Chromecast Audio has decided it wants to be xxx.xxx.xxx.20 when I have something there already so it keeps dropping out. It also means logging on to web controls for things like Ropieee and ROCK is pretty straightforward because I know the IP address.

Would I suggest rushing out and doing the same - not unless you’re 100% confident of what you’re doing!

Why am I even telling you this. Because working through a dozen or so devices just to do a fairly pointless task is what I’ve been driven to!! :rofl:

1 Like

I just use DHCP reservation using my router

7 Likes

I’ve heard that static addressing sounds better :wink:

6 Likes

Yes building up to that. Knew it could be done but just digging into the deeper recesses of my router to set it all up.

Just need to clear the range I want to use.

@mikeb - I was going to post something along those lines as a wind-up but couldn’t face the inevitable grief from those tht don’t understand my dry, dark Yorkshire sense of humour :rofl:

lol… Honestly though, use DHCP with router reservations for stuff you don’t want moving around. Generally, start DHCP at like .20, and reserve the .01-19 space for static addresses.

2 Likes

Yep - just wading through it all now. I am setting the DNS range to start at .100 and then using the router to use set IP addresses based on the MAC address of the device to assign the ‘static’ address that way rather than setting the device to be static if that makes sense!

2 Likes

Having to access quite a few devices via a web interface or mounting network shares via Linux using fixed is a good thing. Nothing worse than entering in the ip to find its changed and you have to find all over again and edit configs and links. Not all devices get easily discovered by friendly names especially os on RPI.

How you fix them though is import and not by turning off DHCP. Where possible it should be configured at router level not by turnig off DHCP. My router has the option to fix any devices ip in its software. I leave DHCP on for everything and then when it’s been added and DHCP has done it’s things and its added to the ARP table I switch it to being fixed in the routers config . It’s simple and effective and I get the best of both worlds. Also Unifi management software is so nice to use.

I have even set the netmask of my network to /26 so it stops at .62. This shortens time for my android remote to find Roon core. (after Wireshark told me that the remote issued ARP requests to all IPs (!) in the subnet when looking for core. On a /24 that is 254!) I can’t believe I have 17 active IP adresses in my home network

1 Like

Yes this is what I have now done. DHCP is still active but all my devices are set at router level to have always pick up the same address. Agree it is a more elegant solution.

1 Like

Peanuts I have 31 with 29 on at the moment.

Yeah, that’s not how it works. ARP sends to the broadcast address of the subnet and only active devices on the subnet respond. You could set your house up with an 8 bit mask and the response would be no slower.

What I saw was the Android device querying every single IP in the range, active or not. Setting a smaller netmask actually shortened the time it took for the remote to connect with core. I’ve got newer Android devices today so I don’t know if these behave the same or use a proper ARP query.

Sounds like it was doing an IP scan and not an ARP.

devices use Layer 2 addresses to communicate (MAC), the way the L2 addresses are exchanged is for the sender (assuming its target IP/MAC is not already in the ARP table) to send an ARP request to the broadcast address of the subnet. If the IP (L3) address is active, it will respond with its MAC (L2) address and then we’re off to the races.

Yes, much like an IP scan, but why would the IP stack of a Android TAB do that? I do not have the Wireshark pcap file anymore so I can’t check, but I think I saw a lot of “who has …” in the trace. Also for IPs not in use. I’ll check again to see if I can spot something similar.

The TAB I use today (SM-T365 Galaxy Tab Active, 5.1.1) does this the correct way. There is only one ARP brodcast from Roon Core after the remote has sent a couple of multicast messages. The response is IP/MAC of the remote and we’re basically up and running.

I thought we were supposed to remove the static?

2 Likes