[RPi3] SSH not working via wifi

[geerlingguy]

Just adding another bit of input here ('me too'):

• Apple AirPort Extreme (6th gen, A1521, latest firmware)
• Strong WiFi signal
• Onboard Ethernet works (DHCP or static) for normal activity, and for SSH
• Onboard WiFi works (DCHP or static) for normal activity, and for SSH—however, when wired Ethernet is disconnected, SSH is flaky at best. Lots of "Broken pipe" and "Operation timed out"
• USB WiFi works (DHCP or static) for normal activity, and for SSH

WiFi only on the Pi itself works great; but SSH to the Pi through WiFi only is what is flaky. So for headless use, built-in WiFi is a bit useless for me right now. I have four other WiFi routers I could test with, but don't have time yet to pull them out and set them up.

[chrisoh]

WiFi only on the Pi itself works great; but SSH to the Pi through WiFi only is what is flaky. So for headless use, built-in WiFi is a bit useless for me right now. I have four other WiFi routers I could test with, but don't have time yet to pull them out and set them up.

Read the first post in the thread, it's a different problem you're experiencing

[geerlingguy]

Gah! You're absolutely correct, and I did read that post, just got confused

That makes sense, because the exact same behavior results from not disabling power management on Tenda/Edimax/etc. USB WiFi adapters. Thanks!

[SR-71]

As suggested upthread I did update / upgrade / rpi-update but no luck: the SSH is not surviving to ethernet cable detaching.

So, I setup a small netcat based telnet server and verified that really , when I detach the cable, only SSH seems to be impacted: the crude telnet server is still working.

I even used rpi-config in order to disable the whole GUI, still no joy, SSH blocks detaching the cable.

[The_PI_Guy]

Everything was working great untill suddenly it kept saying ssh_exchange_identification: read: Connection reset by peer. Now I can't connect at all. I have tried all my usualy tricks and nothing works. Please help

[SR-71]

I found a workaround: just connect to RPI3 using the link local IPv6 address.
You find that address with ifconfig.
Irrispective of the wired ethernet status, it always works.
Of course that makes sense only on a bridged network: I didn't test using a global IPv6 address.

[Gr8mate]

Any solution to this problem yet?

I have exactly the same problem.
Using Putty.
Raspbian on PI3 - ok on eth0
Inbuilt Wi-Fi and no go.
Clean build - except added B/Tooth keyboard using internal B/Tooth.
Tried everything mentioned in this forum - including all updates etc.
Tried port 80, and 55555 (from another forum)
Netgear DG834GV router - opened port 22 and added SSH.
Pings ok - maybe slow

BTW connects using SAMBA fine- transfers files etc.

I'd rather SSH than use the b/tooth keyboard.

Thanks to everyone for input and help.

Edit:
Just tried with an Apple Air router - connects immediately, no adjustments or opening of ports at all.

So it is to do with the Netgear router, or the way it is setup. Not the WI-fi going to sleep.
But why? Never had any issues with anything else and SAMBA connects though this router and the internal WI-Fi.

[tesche]

anyone care for another "me too" post?

I mean the real "ssh over wlan" problem, not the "disable wlan powersaving" one.

I got my pi3 last weekend and it took me three hours of frustrating attempts and googling until I found this thread and realized that I'm not alone. well, sadly that's only a small comfort. in my case the router is a rather old "fritzbox 3030 wlan", which has, not surprisingly, not shown any problems before.

what I find curious is that not only the passwort or key exchange seem to succeed, but the session is even logged in utmp. there just is never any prompt, and I can't abort it with ^C. other wlan traffic (web, apt-get) is just fine, so I'm really wondering what it chokes on?

[cheez]

..

[chrisoh]

Frustrating this hasn't been addressed by RPF yet.

...the router is a rather old "fritzbox 3030 wlan", which has, not surprisingly, not shown any problems before...

Same with a netgear router here, has worked and works fine with all other devices and no special config at all, but SSH on the Pi3 WiFi fails.
A small update/offshoot to this problem, which I see SR-17 mentioned above, is that SSH seems to work if you use IPv6 instead of IPv4. I started a thread over here so as to highlight/clarify the issue. Hopefully it'll help move this issue along.

[JimmyN]

EDIT: Never mind I was testing using the wrong IP address.

Have you tried, as a test, disabling IPv6? Maybe that's why I haven't had any trouble with Putty, I do have IPv6 disabled, so I'm IPv4 only.

[Fabio292]

I confirm the IPv6 workaround:

Router NETGEAR DG834G v3
ssh via eth OK
ssh via built-in wifi through IPv4 NOT OK (same result via putty or ubuntu terminal)
ssh via built-in wifi through IPv6 OK (straightforward with putty. With Ubuntu terminal you have to use this command)

Code: Select all

ssh -6 [email protected]%interface

Where 'interface' is the name of the network interface you are using on the pc (e.g. wlan0 or eth0)

So IMHO there is a little bug in the wifi module firmware, though it's not a blocking bug.

[A350XWB]

The IPv6 workaround works for me, too.

[raspi3beginner]

Same for me IPv6 works IPv4 not.

ps: the reason that it seem to work in case both interfaces (i.e. eth0 and wlan0) are up is simply based on the fact that outgoing packets are sent via eth0 regardless of incoming interface at least if both interfaces have ipv4 adress in the same subnet...

[lbog]

An IPv4 workaround, that works for me:

Code: Select all

/sbin/iptables -t mangle -I PREROUTING 1 -i wlan0 -p tcp --dport 22 -j TOS --set-tos 0x00
/sbin/iptables -t mangle -I POSTROUTING 1 -o wlan0 -p tcp --sport 22 -j TOS --set-tos 0x00

[SR-71]

An IPv4 workaround, that works for me:

Code: Select all

/sbin/iptables -t mangle -I PREROUTING 1 -i wlan0 -p tcp --dport 22 -j TOS --set-tos 0x00
/sbin/iptables -t mangle -I POSTROUTING 1 -o wlan0 -p tcp --sport 22 -j TOS --set-tos 0x00

So, apparently the problem is triggered by the SSH client behavior: it is changing ToS value from 0x00 it uses before the authentication to 0x10 when the real sessions starts after authentication (this is done since ages in order to minimize the latency).

It seems that the Raspberry wireless driver is not able to forward IPv4 packets with ToS != 0.

[lbog]

It seems that the Raspberry wireless driver is not able to forward IPv4 packets with ToS != 0.

No, it is not the Raspberry wireless driver, it is your ssh-Client or your WLAN-Router (for ssh over PI3 Wifi onboard) that is not able to forward IPv4 packets with ToS != 0.

EDIT

ToS 0x58 with the "right" ssh-Client or the "right" WLAN-Router:

Code: Select all

:~ $ sudo tcpdump -c10 -vvveni wlan0 port 22
tcpdump: listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes

22:23:55.006446 00:1b:77:40:ca:3b > b8:27:eb:a8:6a:64, ethertype IPv4 (0x0800), length 66: (tos 0x58, ttl 77, id 11305, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.178.21.53656 > 192.168.178.43.22: Flags [S], cksum 0xf886 (correct), seq 1024263723, win 28280, options [mss 1414,nop,nop,sackOK,nop,wscale 8], length 0

22:23:55.006618 b8:27:eb:a8:6a:64 > 00:1b:77:40:ca:3b, ethertype IPv4 (0x0800), length 66: (tos 0x58, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.178.43.322> 192.168.178.21.53656: Flags [S.], cksum 0xf99e (correct), seq 3560254242, ack 1024263724, win 28280, options [mss 1414,nop,nop,sackOK,nop,wscale 7], length 0

[SR-71]

It seems that the Raspberry wireless driver is not able to forward IPv4 packets with ToS != 0.

No, it is not the Raspberry wireless driver, it is your ssh-Client or your WLAN-Router (for ssh over PI3 Wifi onboard) hat is not able to forward IPv4 packets with ToS != 0.

[/code]

When I connect to other systems , both on the same Wireless LAN and remote ones, I can see from traces that my SSH client is generating packets with ToS == 0x10: such packets are forwarded without any issue.

EDIT: I applied the workaround suggested in order to zero the ToS field (and it is working as per traces taken both on RPI3 and my Linux laptop), but no joy, it is locking exactly as before.

[lbog]

..., but no joy, it is locking exactly as before.

Try additionally with

Code: Select all

IPQoS cs1 cs1

in the

Code: Select all

/etc/ssh/sshd_config

[SR-71]

..., but no joy, it is locking exactly as before.

Try additionally with

Code: Select all

IPQoS cs1 cs1

in the

Code: Select all

/etc/ssh/sshd_config

Using

Code: Select all

IPQoS cs1 cs1

locked even IPv6 !
I had to reconnect the ethernet cable in order to regain the control...

BUT,

Code: Select all

IPQoS cs0 cs0

did the trick !!
Many thanks for the help !

EDIT: with those setting the iptables mangling are not anymore needed.
In any case, you are right, it is something bound to my wireless LAN and maybe to sshd found in RPI3 (OpenSSH_6.7p1) , as using OpenSSH 6.6 and older, I have absolutely no problems (I have several Odroid, Arietta, an old RPI with TPLink USB wireless adapter, plus W$ and Linux running on Intel and this is the first time I see such kind of issues) .
Out of curiosity next week I will do some test at work where I have several different APs. At home I have an old Juniper SSG20.

[SR-71]

It seems that the Raspberry wireless driver is not able to forward IPv4 packets with ToS != 0.

No, it is not the Raspberry wireless driver, it is your ssh-Client or your WLAN-Router (for ssh over PI3 Wifi onboard) that is not able to forward IPv4 packets with ToS != 0.

I just took a trace using the same Linux laptop as client, and the same wireless network: I just change the target system (AcmeSystems Arietta).

RPI3 runs OpenSSH_6.7p1 Raspbian-5+deb8u1, OpenSSL 1.0.1k 8 Jan 2015
Arietta runs OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015

I get connected flawlessly to the Arietta and I see in the trace ToS == 0x10 in both directions.
Even playing with several ToS in Arietta's sshd_config file, everything works.

So, that should proof that my wireless router is able to forward such ToS coloured packets and maybe the RPI3 SSH implementation is causing the issue.

[chrisoh]

Just to catch up, /etc/ssh/sshd_config should be:

Code: Select all

Host *
IPQoS cs0 cs0

Correct? As that doesn't seem to work here...

I'm confused as to what's exactly at fault now. Out of all the people reporting this, all the dongles, routers etc, the Pi 3 WiFi is the common denominator. How does changing the Pi SSH config remedy that?

[SR-71]

Just to catch up, /etc/ssh/sshd_config should be:

Code: Select all

Host *
IPQoS cs0 cs0

Correct? As that doesn't seem to work here...

I'm confused as to what's exactly at fault now. Out of all the people reporting this, all the dongles, routers etc, the Pi 3 WiFi is the common denominator. How does changing the Pi SSH config remedy that?

In my environment I just added

Code: Select all

IPQoS cs0 cs0

to /etc/ssh/sshd_config.

Next you have to restart the daemon:

Code: Select all

sudo service ssh restart

[chrisoh]

Yup, no joy with that.
Might this be of relevance: https://bugs.debian.org/cgi-bin/bugrepo ... bug=650512 ?

[SR-71]

Yup, no joy with that.
Might this be of relevance: https://bugs.debian.org/cgi-bin/bugrepo ... bug=650512 ?

I don't think so, that bug is referring to a very old release of OpenSSH.

Where are you running the SSH client ?
If you are on a *nix platform, try to start the client as follows:

ssh -oIPQoS=0x00 [email protected]

always keeping the configuration on the RPI ssh daemon as above.