LAN issue

I think I would try a static address before trying anything else.

Alan

I lost access again, this evening, but it pinged repeatedly without fail..

Then I changed the DHCP available range, from x.x.x.100 - x.x.x.253 to x.x.x.150 - x.x.x.253. Rebooted the router, and the website began working again, and responded instantly.

I'll try giving it a static IP next.

Sounds like an address conflict somewhere. Was the Pi previously being given an address between 100 and 150 but now gets one that's above 150? Are you sure that there's nothing to which you've given a static address which is within the previous DHCP available range but now isn't?

agree, have you got multiple devices providing DHCP?

The wrong device may be replying to your pings, check arp tables to see if the expected MAC addr is being used for the IP that should be web serving ...

As said, it has been a regular problem, and for years. Inacessible, slow to respond, or sometimes works just fine. It was appearing at 102, until I changed the DHCP range yesterday, to above 150, which moved the Pi to one in the 250+ range, and it began responding instantly.

This morning it has moved to 229, I can ping it at that address OK, but it is again inacessible.

No, I have the new main router in the loft, doing the DHCP. That wire feeds a second router in the living room. The main one also feeds a wifi repeater, out in the garden. both the latter, have DHCP disabled.

Even before these last two were installed, there were issues accessing the Pi.

Apart from the Pi, I have numerous other devices on the LAN, both wired, and wifi. Nothing else seems to have an issue, apart from the Pi, which is wired LAN.

Many routers will allow you to lock a MAC address to an IP address so that DHCP always gives a particular device the same IP address. Not only does that prevent the address from moving around, but the router will also know not to allocate anything else to that address. This is better than simply setting a static address because you don't need to remember to avoid conflicts yourself - it gets done for you. A slow response on a first ping of a group is not unusual for a device that is only used occasionally. Intermediate switches may need to update their MAC tables so that they know which port leads to the destination. This information times out if a particular address is not accessed for a while. John

Ethernet Port Sleep Mode? Wed Apr 10, 2019

Paul

In the real world the address won't move around for any particular device on the LAN, the router will always assign the same address when the device asks for it. The only time that addresses will change is if you have so many devices the router runs out of addresses and has to re-use one.

If the Pi is getting different addresses from the same router on the same LAN (except when the DHCP address range was changed) then there is something funny going on, probably in the Pi.

I have seen some routers that move addresses around every day without there being too many devices for the size of the address allocation. They are clearly broken, but they are out there! John

Pi's can run wired and WiFi simultaneously. I sometimes make the mistake of thinking my Pi connection is wired when it is wireless.

If you have a WiFi mesh/fast repeater you might get loops. I had that and had to be careful to use a switch with loop detection, or to be more precise make sure my WiFi access points were wired directly to each other, rather than via a switch without loop detection.

Yup the interactions with various caches and moving IP addresses can be subtle at times.

Some background for context (apologies to them that already know this stuff!)

For one machine to talk to another on the LAN, it needs to know the

So if all you have is its IP address, you are not yet in a position to talk to it. That is where the Address Resolution Protocol (ARP) comes in. It will send a broadcast ARP Request out tpo every device on the LAN that contains the IP address of the device that it wants to talk to. All devices will here it, and the one which has that IP bound to it or has a route to the device, will respond with an ARP reply message that will contain the MAC address. The machine that made the request can then place the MAC address in its ARP cache for future use so that it does not need to go through that process each time.

This is why if you ping an address that has not been spoken to for some time, the first ping can have a longer return time - because that APR message exchange has to happen between the ping (ICMP Echo Request) packet going out, and the ICMP Echo reply coming back.

On windows you can inspect the content of the ARP cache from the command line with:

arp -a

One notable time this can bite you is when swapping about IP addresses on routers, access points, and gateways etc. The PC can end up trying to talk to the wrong physical device because it has an out of date ARP entry in its cache. You can delete an address from the cache with:

apr -d n.n.n.n

where n.n.n.n is the IP address to delete, or delete all addresses with:

arp -d *

(you can get similar problems with cached IP addresses returned from Domain Name System (DNS) lookups. If you make a DNS update to point some service (i.e. a web site) at a new host, but your machine has the last DNS lookup cached, it may not be aware of the change. You can fix that with "ipconfig /flushdns")

None of the many I have used over the past mumble years have done that. I've used standard BT ones, Draytek, Asus and many others.

I don't remember the make, but the effect was real enough. I packet dumped the DHCP transactions and found that some devices would request a renewal with their current address but be allocated a different address. Other devices on the network were not affected. Replacing the router solved the problem. John

Can the O/P check the uptime of the pi, the router and any devices between them, has any of them rebooted more recently than expected

Have you got a linux host (other than the pi) where you could run arpwatch for a while?

I have just done exactly that. The router only allows IP's to be fixed in the DHCP range of addresses, rather than the reserved area. As the issues comes and goes, it might take a few days to confirm if that worked, but at the moment, it seems reliable.

I don't think it could be that, becuase it was succesfully transmitting data to the Met Office, every few minutes, even when I couldn't connect to the Pi's website.