I have a weather station. The station is located at the back, of the
back garden, which then forwards its data to a display, located in the
house, which it does wirelessly. That part works fine.

The display, then connects by USB, to forward data to a Raspberry Pi.
The Pi runs some software, which turns the data, into webpages, it also
stores the recorded data on a memory card, and also updates the Met
Office with my live data. All normally works just fine, if it's left
alone to get on with it.... The problem is that the webpage in the Pi,
becomes inaccessible, or difficult to access. The weather station
continues to send data, the Pi continues to record the data, just the
webpage fails, and no data sent to the Met Office.

Similar to this has happened before, on previous routers - Last week, I
moved from copper, to fibre, which involved a replacement main router,
the router to which the Pi is directly connected. I set the new router
up, the weather page appeared as normal, after which access to the page gradually became more difficult, slow, then eventually was completely
lost. Access to the pages were then missing for two days. I tried
rebooting the Pi, changed the LAN cable, moved it to a different router
port, nothing made much difference, but I was able to ping it. The first
ping slow, but subsequent pings much faster. Then the web page became accessible, at first sluggish to load, and speeding up, the more
frequently I loaded it. The Pi is on a DHCP allocated address.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/11/2024 21:02, pinnerite wrote:

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

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Andy Burns wrote:

Roger Mills wrote:

Sounds like an address conflict somewhere.

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 ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roger Mills wrote:

Sounds like an address conflict somewhere.

agree, have you got multiple devices providing DHCP?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/11/2024 22:33, Roger Mills wrote:

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?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/11/2024 07:48, Andy Burns wrote:

agree, have you got multiple devices providing DHCP?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John R Walliker <jrwalliker@gmail.com> wrote:

On 26/11/2024 08:55, Harry Bloomfield Esq wrote:

On 25/11/2024 22:33, Roger Mills wrote:

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?

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.

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.

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.

--
Chris Green
·

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 11/26/2024 3:55 AM, Harry Bloomfield Esq wrote:

On 25/11/2024 22:33, Roger Mills wrote:

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?

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.

Ethernet Port Sleep Mode?
Wed Apr 10, 2019

https://forums.raspberrypi.com/viewtopic.php?t=237842

It could be related to that.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/26/24 09:07, Harry Bloomfield Esq wrote:

On 26/11/2024 07:48, Andy Burns wrote:

agree, have you got multiple devices providing DHCP?

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John R Walliker <jrwalliker@gmail.com> wrote:

On 26/11/2024 09:31, Chris Green wrote:

John R Walliker <jrwalliker@gmail.com> wrote:

On 26/11/2024 08:55, Harry Bloomfield Esq wrote:

On 25/11/2024 22:33, Roger Mills wrote:

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? >>>

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.

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.

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.

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

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.

--
Chris Green
·

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/11/2024 08:00, Andy Burns wrote:

Andy Burns wrote:

Roger Mills wrote:

Sounds like an address conflict somewhere.

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 ...

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
*hardware* address (i.e. the MAC address) of the device it wants to talk
to, or failing that, the MAC address of an intermediate device that can
talk to it.

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")


--
Cheers,

John.

/=================================================================\
| Internode Ltd - http://www.internode.co.uk | |-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk | \=================================================================/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

John Rumm wrote:

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

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/11/2024 09:23, Paul wrote:

Ethernet Port Sleep Mode?
Wed Apr 10, 2019

https://forums.raspberrypi.com/viewtopic.php?t=237842

It could be related to that.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/11/2024 09:13, John R Walliker wrote:

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)