WiFi dropping on Pi4, what to do?

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?

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

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

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

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

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

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

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

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

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.

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

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

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.

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.

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

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.

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

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.

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

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

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

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

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

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.