Following a RasPiOS upgrade yesterday, a Pi4 seems to be dropping
its wifi connection considerably more than usual. In the past, this
has been accompanied by signal strength readings below 70% on wavemon.
Now, the signal strength is over 80% and the machine is still dropping
the connection. Cellphones have no problem connecting.

So far, the remedy seems to be turning wifi off and then back on. Are
there any tricks that might help sort out what's wrong? There are many
wifi networks visible to the Pi, but I think mine is the strongest.

Thanks for reading,

bob prohaska
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2021-12-10, bob prohaska <bp@www.zefox.net> wrote:

Following a RasPiOS upgrade yesterday, a Pi4 seems to be dropping
its wifi connection considerably more than usual. In the past, this
has been accompanied by signal strength readings below 70% on wavemon.
Now, the signal strength is over 80% and the machine is still dropping
the connection. Cellphones have no problem connecting.

So far, the remedy seems to be turning wifi off and then back on. Are
there any tricks that might help sort out what's wrong? There are many
wifi networks visible to the Pi, but I think mine is the strongest.

The solution is use wired connection :-)

sorry I can't really help, I've never used wifi on my several Pi's. I've
seen several complaints about the reliability of the wifi. Have you
searched the Pi Forum for any hints?
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Am Freitag, 10. Dezember 2021, um 01:54:50 Uhr schrieb bob prohaska:

Following a RasPiOS upgrade yesterday, a Pi4 seems to be dropping
its wifi connection considerably more than usual. In the past, this
has been accompanied by signal strength readings below 70% on wavemon.
Now, the signal strength is over 80% and the machine is still dropping
the connection. Cellphones have no problem connecting.

Is it the same power?
This is the relevant size, maybe they updated the database for max
allowed power per country and this changed something.
Be aware that need to check the local rules of your residence for the
laws about max. power for WiFi on the different bands.

If there are other networks on the same channel or on the neighbor
channels, they will definitely interfere your connection. Try to use
the most clear channel, check both ends (Pi and your device location).
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Marco Moock <mo01@posteo.de> wrote:

Is it the same power?

Not sure I follow your question....

The cellphone is definitely connecting to the same access point as
the Pi, so the power seen by each would be the same, subject to the
difference caused by a few feet displacement.

Wavemon's "scan" command reports about 20 access points with mine
registering 87%, of what I don't know, and all the rest below 70%.

This is the relevant size, maybe they updated the database for max
allowed power per country and this changed something.
Be aware that need to check the local rules of your residence for the
laws about max. power for WiFi on the different bands.

The date command returns the correct timezone PST, locale reports
en_US so I think the country is correct.

If there are other networks on the same channel or on the neighbor
channels, they will definitely interfere your connection. Try to use
the most clear channel, check both ends (Pi and your device location).

It looks like there are two other APs using channel 1, but they're
both 20 dB down at the Pi4's end. My AP is an old D-Link DI524, it
does not seem to have any diagnostics on the Web interface to check interference.

I should perhaps reiterate that the problems emerged after a sudo
apt update of the Pi4, I haven't done anything to the AP in years.

Thanks for writing,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska wrote on 12/10/21 2:54 AM:

Following a RasPiOS upgrade yesterday, a Pi4 seems to be dropping
its wifi connection considerably more than usual. In the past, this
has been accompanied by signal strength readings below 70% on wavemon.
Now, the signal strength is over 80% and the machine is still dropping
the connection. Cellphones have no problem connecting.

So far, the remedy seems to be turning wifi off and then back on. Are
there any tricks that might help sort out what's wrong? There are many
wifi networks visible to the Pi, but I think mine is the strongest.

Thanks for reading,

bob prohaska

switch off wifi power management (iwconfig wlan0 power off)
if that doesnt help, use okder firmware.
Ihad to do both to stop loosing connection every n minutes....
although I think power-management was the culprit.

-rasp
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Ralph Spitzner <rasp@spitzner.org> wrote:

bob prohaska wrote on 12/10/21 2:54 AM:

Following a RasPiOS upgrade yesterday, a Pi4 seems to be dropping
its wifi connection considerably more than usual. In the past, this
has been accompanied by signal strength readings below 70% on wavemon.
Now, the signal strength is over 80% and the machine is still dropping
the connection. Cellphones have no problem connecting.

So far, the remedy seems to be turning wifi off and then back on. Are
there any tricks that might help sort out what's wrong? There are many
wifi networks visible to the Pi, but I think mine is the strongest.

Thanks for reading,

bob prohaska

switch off wifi power management (iwconfig wlan0 power off)
if that doesnt help, use okder firmware.
Ihad to do both to stop loosing connection every n minutes....
although I think power-management was the culprit.

Trying it now....

Wouldn't power management interfere with all connections equally? There
are usually about a dozen ssh connections open, typically only one or two
drop. The rest stay up for days/weeks.

Thanks for writing!

bob prohaska
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2021-12-12, bob prohaska <bp@www.zefox.net> wrote:

Ralph Spitzner <rasp@spitzner.org> wrote:

bob prohaska wrote on 12/10/21 2:54 AM:

Following a RasPiOS upgrade yesterday, a Pi4 seems to be dropping
its wifi connection considerably more than usual. In the past, this
has been accompanied by signal strength readings below 70% on wavemon.
Now, the signal strength is over 80% and the machine is still dropping
the connection. Cellphones have no problem connecting.

So far, the remedy seems to be turning wifi off and then back on. Are
there any tricks that might help sort out what's wrong? There are many
wifi networks visible to the Pi, but I think mine is the strongest.

Thanks for reading,

bob prohaska

switch off wifi power management (iwconfig wlan0 power off)
if that doesnt help, use okder firmware.
Ihad to do both to stop loosing connection every n minutes....
although I think power-management was the culprit.

Trying it now....

Wouldn't power management interfere with all connections equally? There
are usually about a dozen ssh connections open, typically only one or two drop. The rest stay up for days/weeks.

Surely if you are saying you wifi connection goes down then ALL tcp/ip
traffic over the wifi does down as well?

Something does not sound right in the two desciptions of your problem
given above
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 12/12/2021 19:44, Jim Jackson wrote:

On 2021-12-12, bob prohaska <bp@www.zefox.net> wrote:

Wouldn't power management interfere with all connections equally? There
are usually about a dozen ssh connections open, typically only one or two
drop. The rest stay up for days/weeks.

Surely if you are saying you wifi connection goes down then ALL tcp/ip traffic over the wifi does down as well?

Something does not sound right in the two desciptions of your problem
given above

I can have connections freeze and drop with wifi, but some stay up. In
my case I am fairly sure the problem is the central heating boiler
spark igniter, which throws broadband hash all over the place. I can ask
the wifi to connect to another access point without losing TCP
connections however, so *temporary* loss of the physical layer may or
may not lead to a logical connection drop.

Keepalives are not continuous things.

--
No Apple devices were knowingly used in the preparation of this post.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Jim Jackson <jj@franjam.org.uk> wrote:

On 2021-12-12, bob prohaska <bp@www.zefox.net> wrote:

Ralph Spitzner <rasp@spitzner.org> wrote:

bob prohaska wrote on 12/10/21 2:54 AM:

[snip]

So far, the remedy seems to be turning wifi off and then back on. Are
there any tricks that might help sort out what's wrong? There are many >>>> wifi networks visible to the Pi, but I think mine is the strongest.

switch off wifi power management (iwconfig wlan0 power off)
if that doesnt help, use okder firmware.
Ihad to do both to stop loosing connection every n minutes....
although I think power-management was the culprit.

Trying it now....

Out of six ssh sessions over wifi opened yesterday three are still up.

Surely if you are saying you wifi connection goes down then ALL tcp/ip traffic over the wifi does down as well?

Something does not sound right in the two desciptions of your problem
given above

I'm on a Pi4 running RasPiOS as I write this. The Pi4 is connected to my
single WiFi access point. There are six ssh connections to other hosts,
plus one ping session to the access point. Three of the ssh connections
dropped overnight, the other three are still up. Ping times look normal
for about the past twelve hours.

Wavemon presently reports a signal level of -58dBm with a link quality
of 73-74%. That's somewhat low, if I tilt the Pi just slightly it comes
up to near 90%.

One obvious question is where the disconnects originate: Wifi, router
or remote (but still physically local) host. I don't know how to resolve
that puzzle and was hoping to learn of some diagnostics that might help.
The remote hosts are FreeBSD of various versions and vintages. I have also
had difficulties with the Pi4 dropping its WiFi connection entirely, but
that's what gets restored by turning WiFi off and back on. The ssh failures
are more subtle.

Thanks for reading,

bob prohaska
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska wrote:

The Pi4 is connected to my
single WiFi access point. There are six ssh connections to other hosts,
plus one ping session to the access point. Three of the ssh connections dropped overnight, the other three are still up.

Is it possible some of the SSH sessions use keep-alives while the others do not?
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Andy Burns <usenet@andyburns.uk> wrote:

bob prohaska wrote:

The Pi4 is connected to my
single WiFi access point. There are six ssh connections to other hosts, plus one ping session to the access point. Three of the ssh connections dropped overnight, the other three are still up.

Is it possible some of the SSH sessions use keep-alives while the others do not?

Also is it worth stepping up the ssh debugging by using -v, -vv or
-vvv? That might tell you what ssh itself thinks is the reason for dropped connections.

--
Chris Green
·
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Chris Green <cl@isbd.net> wrote:

Andy Burns <usenet@andyburns.uk> wrote:

bob prohaska wrote:

The Pi4 is connected to my
single WiFi access point. There are six ssh connections to other hosts,
plus one ping session to the access point. Three of the ssh connections
dropped overnight, the other three are still up.

Is it possible some of the SSH sessions use keep-alives while the others do not?

Not sure. I haven't done anything beyond using ping to see if it keeps things up. Near as I can tell it doesn't help much, if at all. If what you mean by
a keep-alive is different, please tell me what to check for.

Also is it worth stepping up the ssh debugging by using -v, -vv or
-vvv? That might tell you what ssh itself thinks is the reason for dropped connections.

Yes! Can I simply use something like
ssh -vv user@host ?
Where will I find the extra output?

As an aside, I brought all the ssh sessions back up several hours ago.
They're all still up.....

Thanks for writing!

bob prohaska
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> wrote:

Chris Green <cl@isbd.net> wrote:

Also is it worth stepping up the ssh debugging by using -v, -vv or
-vvv? That might tell you what ssh itself thinks is the reason for dropped connections.

Yes! Can I simply use something like
ssh -vv user@host ?
Where will I find the extra output?

On standard output (or maybe standard error), ... thinks, I'll try it:-

ssh -vvv backup 2>log

Works beautifully! Loads of debug information is sent to 'log' while
your connection works as usual.

As an aside, I brought all the ssh sessions back up several hours ago. They're all still up.....

Sort of sods law that isn't it! :-)

--
Chris Green
·
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 2021-12-13, bob prohaska <bp@www.zefox.net> wrote:

Chris Green <cl@isbd.net> wrote:

Andy Burns <usenet@andyburns.uk> wrote:

bob prohaska wrote:

The Pi4 is connected to my
single WiFi access point. There are six ssh connections to other hosts, >>> > plus one ping session to the access point. Three of the ssh connections >>> > dropped overnight, the other three are still up.

Is it possible some of the SSH sessions use keep-alives while the others do not?

Not sure. I haven't done anything beyond using ping to see if it keeps things up. Near as I can tell it doesn't help much, if at all. If what you mean by
a keep-alive is different, please tell me what to check for.

the ssh protocol allows for "keepalive" packets to be periodically sent
between the ssh client and ssh server - this is neccessary because some
NAT routers close tcp connections that have had no traffic for some
period.

Put

ServerAliveInterval 60

in your .ssh/config file

see man ssh_config for the full details.

Also is it worth stepping up the ssh debugging by using -v, -vv or
-vvv? That might tell you what ssh itself thinks is the reason for dropped >> connections.

Yes! Can I simply use something like
ssh -vv user@host ?
Where will I find the extra output?

As an aside, I brought all the ssh sessions back up several hours ago. They're all still up.....

Thanks for writing!

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Chris Green <cl@isbd.net> wrote:

bob prohaska <bp@www.zefox.net> wrote:

Chris Green <cl@isbd.net> wrote:

Also is it worth stepping up the ssh debugging by using -v, -vv or
-vvv? That might tell you what ssh itself thinks is the reason for dropped >> > connections.

Yes! Can I simply use something like
ssh -vv user@host ?
Where will I find the extra output?

On standard output (or maybe standard error), ... thinks, I'll try it:-

ssh -vvv backup 2>log

Works beautifully! Loads of debug information is sent to 'log' while
your connection works as usual.

As an aside, I brought all the ssh sessions back up several hours ago.
They're all still up.....

Sort of sods law that isn't it! :-)

Overnight two connections went down. The only message is of the form:

packet_write_wait: Connection to 50.1.20.24 port 22: Broken pipe

That's what I've been seeing all along, -v or no -v 8-)

Can anybody hazard a guess which end initiated the disconnect?
From the wording, it looks like the Pi discovered that the link
was already gone, said so and exited.

Thanks for reading,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 14/12/2021 21:17, bob prohaska wrote:

Overnight two connections went down. The only message is of the form:

packet_write_wait: Connection to 50.1.20.24 port 22: Broken pipe

That's what I've been seeing all along, -v or no -v8-)

Can anybody hazard a guess which end initiated the disconnect?

Mmm. Interesting philosophical concept, if I take an axe to a cable,
please tell me which end of it 'initiated the disconnect'?

From the wording, it looks like the Pi discovered that the link
was already gone, said so and exited.

That's better. The *link was already gone*.



--
“It is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Tue, 14 Dec 2021 21:17:43 -0000 (UTC), bob prohaska wrote:

Overnight two connections went down. The only message is of the form:

packet_write_wait: Connection to 50.1.20.24 port 22: Broken pipe

That's what I've been seeing all along, -v or no -v 8-)

Can anybody hazard a guess which end initiated the disconnect?
From the wording, it looks like the Pi discovered that the link was
already gone, said so and exited.

You can only know that if you're using 'keep alive' messages of some
type, and SSH connections typically don't do that, unlike, say the now- obsolete X.25.

IIRC X.25 was very telephone-like, with a central 'exchange' node, which regularly checked all open connections and, if one half of a connection
died, both the initiator and the recipient of a connection got notified
of the faiure.

I think that equivalent checks for an SSH session have to be handled at application level: One end needs to send periodic test messages and
report errors if it doesn't get a 'test received' response. The other end
wound need to be expecting 'testing' messages and to report errors if
they don't arrive when expected.

HTH

Thanks for reading,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

bob prohaska <bp@www.zefox.net> writes:

Overnight two connections went down. The only message is of the form:

packet_write_wait: Connection to 50.1.20.24 port 22: Broken pipe

That's what I've been seeing all along, -v or no -v 8-)

So did you use -v or -vvv? And maybe use -E to specify the log file.

Can anybody hazard a guess which end initiated the disconnect?

ssh client in Debian (and so probably in Raspbian or whatsit now) sends
TCP keepalives by default. If the connection to the other end is down
then the ssh connection also goes down. You might try using
-o 'TCPKeepAlive=no' with ssh to see if it helps.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)