[RPi3] SSH not working via wifi

[A350XWB]

Edit: One clarification as things seem to get confused easily: This thread is about not being able to connect to SSH at all. If you experience unstable wifi and occasional SSH connection timeouts, please follow this thread which offers working solutions: viewtopic.php?f=28&t=44044&start=425#p919376

Hi everyone,

yesterday I received my new Raspberry Pi and with the help of this forum I managed to get wifi running smoothly. The missing channels 12 and 13 were no issue for me, I just had to disable the wifi power savings mode in order to have a stable connection.

However, I still have issues with SSH. I would like to access the Pi from my Windows PC via PuTTY. When I connect the Pi via ethernet cable, everything works fine. But when I connect the Pi via wifi, after entering username and password nothing happens (see attached image).

This is what the SSH server on the Pi says:

Code: Select all

Mar  4 09:16:59 rpi sshd[1368]: Accepted password for pi from 192.168.178.38 port 49886 ssh2
Mar  4 09:16:59 rpi sshd[1368]: pam_unix(sshd:session): session opened for user pi by (uid=0)

This is from the PuTTY log file:

Code: Select all

Event Log: Sent password
Event Log: Access granted
Event Log: Opening session as main channel
Event Log: Opened main channel                           
Event Log: Allocated pty (ospeed 38400bps, ispeed 38400bps)

Any ideas as to what might cause the problem?

[Man in a van]

Look over here, this may help

viewtopic.php?f=28&t=44044&start=425

atb

ronnie

[A350XWB]

I went through this thread earlier and followed the instructions. Since I did this wifi itself is running smoothly and the connection is very stable. I can ping the Pi with good timings, I can open websites on the Pi and so on.

My problem is that despite there being a wifi connection I can't connect via SSH from my PC unless I plug in the ethernet cable.

[mccarthy]

Hi there I've recently received my Pi3 and installed the newest Jessie image and ran into the same issues mentioned above. Putty simply does nothing, all I get is a black screen. JuiceSSH halts after "Authentication succeeded" and shoots a timeout error at me after a few minutes.
Thanks in advance.

[A350XWB]

I'm glad that I'm not the only one with this problem.

I can rule out a client issue as the problem exists with Putty on my PC as well as on the SSH client on my Android device.
Also I think it is very unlikely that my router somehow blocks the SSH connection since it works via ethernet.
Everything points to a software issue on the Pi.

Any suggestions for further diagnosis?

[mccarthy]

So far I've tried reinstalling OpenSSH, but same issue. Maybe there's a switch in the ssh config that prevents us from getting a connection.
I've also used an USB wifi adapter, but same thing there. I can't believe that we're the only ones.

[FTrevorGowen]

I've been unable to reproduce the problem - but have noted something else "slightly odd" (see later):
I started by booting up with both wired LAN and wifi active. SSH'd in O.K. (from my Ubuntu netbook) via PuTTY to the wired IP address and also via "terminal-based" SSH to the wifi address. Exited both, unplugged the wired LAN and then tried the wifi via PuTTY - again logged in O.K. Shutdown and re-booted w/o wired LAN and was still able to SSH via PuTTY through the WiFi connection.
What was "slightly odd"? Ans. Although ifconfig (on the P3B) reported different (local) IP addresses (used above) only that associated with the (MAC addr. of?) the wired connection was shown by the router (ie. it did not associated the Pi's hostname with a wireless connection). Hmmm ...
Trev.

[mccarthy]

Thank you for your answer. I've taken a look at the router configuration, but nothing suspicious.
Maybe I'll start from scratch with downloading a fresh full Jessie image (I used the lite one) and giving another try.

[chrisoh]

I've managed to reproduce this on a Pi 3 too.
Clean Jessie install (4th Mar) updated today, only added WiFi details. Cannot SSH over WiFi from Android or Mac clients.
Tried adding the wireless-power off to interfaces, to no avail.
Pi auth logs look like OPs.

Following is ssh -vvv output following authentication, possibly someone who is more familiar with it can chime in??

Code: Select all

...
debug1: Authentication succeeded (password).
Authenticated to 192.168.0.20 ([192.168.0.20]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: client_session2_setup: id 0
debug2: fd 3 setting TCP_NODELAY
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM_PROGRAM
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env TMPDIR
debug3: Ignored env Apple_PubSub_Socket_Render
debug3: Ignored env TERM_PROGRAM_VERSION
debug3: Ignored env TERM_SESSION_ID
debug3: Ignored env USER
debug3: Ignored env COMMAND_MODE
debug3: Ignored env SSH_AUTH_SOCK
debug3: Ignored env __CF_USER_TEXT_ENCODING
debug3: Ignored env Apple_Ubiquity_Message
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = en_GB.UTF-8
debug2: channel 0: request env confirm 0
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env SECURITYSESSIONID
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
debug2: client_check_window_change: changed
debug2: channel 0: request window-change confirm 0
Write failed: Broken pipe

[Mike Lake]

Same problem on RPi 3 under Rasbian.

WiFi works fine using on-board WiFi (not USB WiFi).

SSH login to PuTTY on Windows PC via Ethernet is fine.

SSH login to PuTTY on Windows PC via WiFi fails as follows:

Accepts "pi" user
Displays the correct IP address for the RPi.
Requests the password.
After entering the password the screen remains blank.

[pepedog]

In /boot/cmdline.txt add ipv6.disable=1
reboot and try again

Same problem in archlinuxarm exists

[Mike Lake]

I added:

ipv6.disable=1

to the end of cmdline.txt, shutdown, removed the Ethernet cable, rebooted, checked that WiFi was working and then ran PuTTY on the PC.

Unfortunately the problem is the same. SSH via is Ethernet OK, SSH via WiFi will not accept password.

[FTrevorGowen]

It's just occurred to me that, AFAICT, that the common factor with non-working SSH appears to be when PuTTY is running on a Windows PC. (I was not able to reproduce the issue with PuTTY on a netbook using Ubuntu Linux). If that's true then is there a "problem" at the "Windows end" too? (Possibly ipv6 related?)
Trev.

[Mike Lake]

I never tried SSH with a USB wifi dongle on an earlier RPi linked to PuTTY on a Windows PC.

Someone must have done so.

If it worked via a USB wifi dongle then the problem is new and RPi3-related.

[chrisoh]

It's just occurred to me that, AFAICT, that the common factor with non-working SSH appears to be when PuTTY is running on a Windows PC. (I was not able to reproduce the issue with PuTTY on a netbook using Ubuntu Linux). If that's true then is there a "problem" at the "Windows end" too? (Possibly ipv6 related?)
Trev.

Except I'm using OSX and Android here... it's a problem on the Pi 3.

Side note, maybe it's related, but is anyone having NTP update issues? Tried changing to a few different pool servers at /etc/ntp.conf and it's not updating.

[dchao99]

Yep, something is not right!
I've disabled the power management on the broadcom brcm43430 chip, and ping started working for a while. Until I plugged in a external USB SSD, and I get some very large ping delays and lost packets again.
All this goes away if I switch to the wired Ethernet or put the same image into RPi2.

[FTrevorGowen]

O.K. Now I've managed to (sort of) reproduce the issue with PuTTY SSH from my Ubuntu netbook. First a note about my setup - my monitor and keyboard/mouse can be switched between the netbook and P3B via a USB switch and monitor input select (Netbook VGA, P3B HDMI/DVI). I booted the P3B w/o wired LAN and, according to ifconfig, had a working WiFi connection but also noted unusual periodic ACTivity led flashes (~1Hz bursts). NB. the P2B is setup to boot to the "command-lne" not the desktop. Could not SSH in via PuTTY from the netbook. Started the P3B pinging the router. Could then SSH in!

Code: Select all

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Wed Mar  9 12:48:13 2016
pi@raspiP3B16Gb:~ $ uname -a
Linux raspiP3B16Gb 4.1.18-v7+ #846 SMP Thu Feb 25 14:22:53 GMT 2016 armv7l GNU/Linux
pi@raspiP3B16Gb:~ $ ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:b8:08:04
          inet6 addr: fe80::6c43:c85a:cc9f:7770/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:200 errors:0 dropped:0 overruns:0 frame:0
          TX packets:200 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16656 (16.2 KiB)  TX bytes:16656 (16.2 KiB)

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:ed:5d:51
          inet addr:192.168.23.55  Bcast:192.168.23.255  Mask:255.255.255.0
          inet6 addr: fe80::ba27:ebff:feed:5d51/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:420 errors:0 dropped:27 overruns:0 frame:0
          TX packets:344 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:44206 (43.1 KiB)  TX bytes:46965 (45.8 KiB)

Have not disabled powersave etc.
Trev.

[chrisoh]

Just did some sanity testing (Mac/Android -> Pi3) with my usual USB WiFi dongles which work on all my previous Pi's...

SSH works using USB WiFi dongle plugged into the Pi 3 (e.g. Ralink RT5370)
SSH does not work with the Pi 3 onboard WiFi Broadcom BCM43438

However, if I create a hotspot using my smartphone and connect Mac/Android and Pi3 to it, I can SSH into the Pi 3 WiFi chip just fine.

So, I'm seeing an incompatibility between the Broadcom BCM43438 WiFi+BT chip and my router, which is a bit strange seeing as 'normal' internet use on the Pi 3 works fine.

Anyone else have a better insight into it?

[Mike Lake]

Watch out for red herrings!

After almost 40 years testing software and tying bugs down before reporting them to development teams, I think we are there.

Linking RPi 3 to a Windows PC (and some other devices) using SSH and PuTTY:

Works with Ethernet.
Works with a USB wifi dongle.
Does not work with the on-board wifi - it fails at the password entry stage.

That seems sufficient. There is a problem.

[chrisoh]

Linking RPi 3 to a Windows PC (and some other devices) using SSH and PuTTY:

Works with Ethernet.
Works with a USB wifi dongle.
Does not work with the on-board wifi - it fails at the password entry stage.

That seems sufficient. There is a problem.

Can you try the same setup but using a different router or your smartphone WiFi hotspot?

[Mike Lake]

Sorry - no second router and no smartphone <g>

[mccarthy]

Hey there!
I've tried it with Ubuntu Mate on the RPI3 and it worked like a charm over wifi so there must be something wrong with the config on Raspbian.
Greetings

[chrisoh]

Sorry - no second router and no smartphone <g>

Ok, hopefully someone else can give it a go, another test would help ascertain what is going on...

Hey there!
I've tried it with Ubuntu Mate on the RPI3 and it worked like a charm over wifi so there must be something wrong with the config on Raspian.
Greetings

Thanks for your input but it's a clean install with no configuration changes, so no, it's not 'something wrong with the config'. If you'd read the thread posts, you would be aware that I established that SSHing using the onboard WiFi indeed works when using a smartphone hotspot, but not over a wireless router, using the exact same setup. If others confirm this, it would explain why some people are reporting problems with SSH when connected via the Pi 3's new onboard WiFi, and others are not.

Maybe one of the RPF devs could chime in on whether they're aware that the BCM43438 specifically has dropped and/or is not supporting some legacy wireless protocol of some kind?

[mccarthy]

I've read your post very well
but why does it work with Mate and not with Raspbian (bytheway for me neither)?

[chrisoh]

I've read your post very well
but why does it work with Mate and not with Raspbian (bytheway for me neither)?

I don't know what your setup is but I imagine if you're experiencing what is described above, it's due to some kernal/driver difference at play between the installs. If you install the latest Raspbian and cannot SSH into it using the onboard WiFi, try a different WiFi access point and post back your results, please.