> On 25 Jan 2022, at 14:17, Martin McCormick <marti...@suddenlink.net> wrote:
>
> This Pi is running Debian Stretch. I believe that's what version
> 9 is called. I have it capturing audio from a radio receiver and
> it's been doing that for several years now and it was doing that
> yesterday morning. Later in the day, I downloaded more audio
> and, after a long pause, I got the message from ssh that the
> Raspberry Pi wasn't there any longer so I retrieved the Pi from
> the room where it was and brought it to my Debian desktop system
> to work on it.
>
> I could login to the Pi which seemed to be up and running
> but the short story is that it couldn't talk to any address but
> our router. I couldn't even ping it's interface from the Pi,
> itself.
>
> If I was on the Raspberry Pi's console, everything looked
> normal as long as one wasn't using the TCP/IP interface. You
> could even do a ip addr or an ipconfig -a command and it would
> show that it had gotten the correct address from our dhcp server
> which is in the router. It would successfully ping the router
> but no other addresses, not even the address it uses on our
> network.
>
> I finally quit messing with it and went to bed but fired
> it up again today, January 25 and low and behold, it just came
> right up and is now back doing what it has been doing.
>
> Is it possible that it got a corrupted lease for dhcp
> from the router? Dhcp leases on our Netgear router are issued
> for not quite 24 hours so it may have gotten a bad lease, kept
> renewing it for the time it was powered up and then it got a new
> version of that lease today and all is well.
>
> It's the same IP address because I have put it in the
> router as a static IP address.
>
> The other thing that is weird is that the Raspberry Pi in
> question has both a wired Ethernet and a WiFi interface and both
> were misbehaving identically.
>
> Normally, the wired port is not used and the dhcp lease
> renewal process happens over WiFi.
>
> The results of ip addr always showed a correct subnet
> mask and the only rules in iptables are the 2 default rules. In
> other words, all looked normal except that it didn't work.
>
> While I had it on the work bench, so to speak, I ran fsck
> -fy on the SSD card since it has been a couple of years since I
> last did that and there was not a single squawk about anything.
>
> Thanks for any ideas about how things got wrong and then
> magically fixed themselves.
>
> When I turned it off last night, I gave it the halt -p
> command. The power supply has no switch so I unplugged it from
> power so it started fresh about 8 hours later.
>
> Martin WB5AGZ
>
Hi Martin,
Are your router logs accessible?
Is there anything of potential relevance in those or the pi logs around the
time it stopped/restarted 'connecting' (or even in the interim)?
Perhaps
cat /var/log/syslog{.n} | grep -i dhcp
might be a start, where {.n} indicates an optional eg. .1, .2 etc if syslog
itself no longer contains logs from the relevant time.
The router may have a web interface that includes a section for errors if you
can't get into it with ssh. Not sure how helpful that might be even if one
exists, but maybe worth a look.
Gareth
