-1

I'm working on a custom yocto Linux for a Raspberry PI 3 and try to get the WIFI connection working with SSH. However when trying to connect from my PC (Ubuntu 19.10, SSH OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c 28 May 2019) to the PI on which Dropbear v2019.78 runs, the connection attempt times out. But only when I try this via SSH, and via wlan0. Other TCP/IP traffic works, and also using the same participants but with eth0. As this is for a robot, I would prefer to not use a tether though...

To try & debug this, I

  • enabled a serial console so I can work on the PI
  • disabled eth0
  • started a tcpdump on the PI (ip.host == 192.168.0.105)
  • started a tcpdump on the PC (ip.host == 192.168.0.106)
  • used a dirt-simple TCP/IP socket example written in Python (taken from https://realpython.com/python-sockets/#echo-server) to verify I can in fact communicate. The transmission is successful. I am aware that the example is lacking (no proper protocol etc), but that's not the point of it. It just works enough. The PI runs the server listening on port 2222.
  • attempted a SSH connection, it timed out.

I filtered the resulting PCAP down to contain just TCP, as there is other information (e.g. Dropbox discovery) that I don't think matters and might potentially be information leaking. On the host side (enp4s0-tcp-and-pi.pcap) I also filtered with ip.host == 192.168.0.105 to only contain any traffic to the PI.

Another note on my setup here: I use a TP-Link router which LAN ports the PC is connected to, and who provides the 2.4GHz WIFI for the PI. So both are part of the same subnet, and no special routing or anything is configured.

Also I stopped the dropbear daemon and adapted my Python code to use port 22. It works.

I'm only broadly aware of the inner workings of TCP, so I can't really make much sense of the things I see here. Any insights are more than welcome.

https://www.dropbox.com/s/5o4rqr5zdws2wq7/wlan0-tcp-only.pcap?dl=0

https://www.dropbox.com/s/amypjtk1nvja4qb/enp4s0-tcp-and-pi.pcap?dl=0

Output of ssh -vvv root@192.168.0.102 (different IP due to DHCP):

14:27 $ ssh -vvv root@192.168.0.102
OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/deets/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.0.102 is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.102 [192.168.0.102] port 22.
debug1: connect to address 192.168.0.102 port 22: Connection timed out
ssh: connect to host 192.168.0.102 port 22: Connection timed out

Originally asked on SO: https://stackoverflow.com/questions/61576538/ssh-connection-not-established-but-standard-tcp-ip-connection-works?noredirect=1#comment108936218_61576538

deets
  • 1
  • 3
  • Have you tried to connect using `ssh -vvv` and then checked `/var/log/auth.log`? I would set `LogLevel VERBOSE` in `/etc/ssh/sshd_config`. – Fabian May 06 '20 at 14:01
  • @Fabian I augmented my question, however I do not see anything enlightening :( – deets May 07 '20 at 12:59

1 Answers1

0

Looking at the PCAP traces, the Pi actually sends an answer to the connection request (marked SYN, ACK, e.g. packet nr. 14 in wlan0-tcp-only.pcap), which does not show up in the client-side trace. So, the problem is on the way from the Pi back to your PC.

I can't pinpoint the exact problem from the given information, but here are some things to check:

  • Check the firewall on the PC that it does not filter the traffic
  • Put the Pi closer to the WIFI access point / router
Bernhard
  • 911
  • 5
  • 13
  • Thanks. The thing that I do not understand here: the python socket connection works just fine. Including one over port 22. I would expect some general rule to kick in (and if so, still wonder where it comes from), but this is baffling to me. – deets May 07 '20 at 12:55
  • I ran the python connection via port 22, see this pcap: https://www.dropbox.com/s/suq4o05q3vchuqt/wlan0-python-port22-ip192-168-0-102.pcap?dl=0 – deets May 07 '20 at 13:06
  • Agreed that this is strange, the python connection is looking fine as you described. You don't have something like [OpenSnitch](https://github.com/evilsocket/opensnitch) on the Ubuntu client that could block the traffic based on the application? As this is wifi, can you do a monitor mode trace that includes wifi (layer2) information? – Bernhard May 07 '20 at 13:30
  • My ubuntu is out-of-the-box. It might in theory have iptables set up, but as WIFI and LAN are on the same network, and the PC has only a LAN-port (no WIFI adapter), I fail to see how it would discriminate here. Which also answers your question (I guess): would your suggestion basically mean wifi sniffing? I ordered aircrack-ng-capable adapters, but Amazon is taking it's sweet time. Or can I achieve this differently somehow? I could bring a mac Notebook into the same network, if it helps. – deets May 07 '20 at 14:24
  • OK so I misunderstood you, i thought the Ubuntu was also connected via wifi. I still stick to the statement that this is a network-or-client-side problem (not the RPi), so it is probably not wifi-related. I'm out of ideas what to check next, sorry. Just for the record: a Mac could do monitor mode on the Wifi. – Bernhard May 07 '20 at 14:43
  • Great, thanks. I'll keep investigating with your hypothesis in mind. – deets May 07 '20 at 14:45
  • Ok, it seems this is router-based. I decided to re-configure another wifi router available in the houshold that so far was only using the 5GHz band (2.4GHz in a Berlin city flat thick as syrup already). What shall I say - it works. Weirdest thing ever. I will grant you the bonus, because bouncing this off you was helpful! – deets May 07 '20 at 17:04
  • weird indeed. Thanks for the bounty. – Bernhard May 07 '20 at 18:15