OPI Zero - Incoming SSH - Can't connect

awef · November 18, 2016

Is anyone else having issues getting incoming ssh to work with their OPI zero?

I've tried both:

Armbian_5.24_Orangepizero_Debian_jessie_3.4.113.img

and

Armbian_5.24_Orangepizero_Ubuntu_xenial_3.4.113.img

In both cases I was able to get a WiFi connection, and am able to get out to the internet to download new packages (apt-get).

However, I can't seem to get incoming ssh or ping to work. It's as if the device is invisible.

awef · November 18, 2016

Hmm... ssh on eth0 works fine, but not wlan0

Igor · November 18, 2016

Hardware wise it works, tested - connected via serial -> connect to router with network manager (nmtui-connect) -> ssh -> apt update / upgrade. It works normally.

You must have some configuration problem?

tkaiser · November 18, 2016

connect to router with network manager (nmtui-connect) -> ssh -> apt update / upgrade. It works normally.

If Wi-Fi has been brought up 'the conventional way' (fiddling around in /etc/network/interfaces and so on) then behaviour is not that much predictable regarding routing. In case both eth0 and wlan0 were connected to the same network (eg. 192.168.1.0/24) and eth0 is listed prior to wlan0 in interfaces file everything will fail after Ethernet cable will be unplugged. Maybe it's just that. Using network manager prevents that since there routing is also considered and adjusted on demand.

Edit: It's not really routing but more the 'which NICs are considered to reach network xy' problem.

awef · November 19, 2016

thanks for the pointers. I'll give it a shot a little later.

awef · November 19, 2016

Did brand new flash of Armbian_5.24_Orangepizero_Ubuntu_xenial_3.4.113.img

Used nmtui-connect to connect to Wifi

wlan0 up

wlan0 Link encap:Ethernet HWaddr 1c:93:63:d0:e6:17

inet addr:192.168.10.122 Bcast:192.168.10.255 Mask:255.255.255.0

inet6 addr: fe80::1e93:63ff:fed0:e617/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:172 errors:0 dropped:0 overruns:0 frame:0

TX packets:140 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:29254 (29.2 KB) TX bytes:15171 (15.1 KB)

Routing table looks good:

root@orangepizero:~# netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 wlan0

192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

Ping is good

root@orangepizero:~# ping 192.168.10.1

PING 192.168.10.1 (192.168.10.1) 56(84) bytes of data.

64 bytes from 192.168.10.1: icmp_seq=1 ttl=64 time=44.8 ms

SSHD running

root@orangepizero:~# netstat -an |grep LIS

tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN

tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN

tcp6 0 0 :::22 :::* LISTEN

DNS and internet good:

root@orangepizero:~# curl google.com

<TITLE>302 Moved</TITLE></HEAD><BODY>

<H1>302 Moved</H1>

The document has moved

<A HREF="http://www.google.co.kr/?gfe_rd=cr&ei=fO4vWJXtPMjC8gfxtY2wBw">here</A>.

</BODY></HTML>

Arp from another computer is good:

$ arp 192.168.10.122

? (192.168.10.122) at 1c:93:63:d0:e6:17 on en0 ifscope [ethernet]

Ping to router from another computer is good:

$ ping 192.168.10.1

PING 192.168.10.1 (192.168.10.1): 56 data bytes

64 bytes from 192.168.10.1: icmp_seq=0 ttl=64 time=4.758 ms

Ping to OPi Zero fails

$ ping 192.168.10.122

PING 192.168.10.122 (192.168.10.122): 56 data bytes

Request timeout for icmp_seq 0

Request timeout for icmp_seq 1

SSH to OPi zero fails

$ ssh root@192.168.10.122

Interestingly enough after imaging the SD card, each time my wlan0 mac address is different. Is this normal?

# wlan0 Link encap:Ethernet HWaddr 4c:3a:0e:8d:84:f0 Debian

# wlan0 Link encap:Ethernet HWaddr 0c:2a:42:8b:9a:98 Ubuntu Try 1

# wlan0 Link encap:Ethernet HWaddr 1c:93:63:d0:e6:17 Ubuntu Try 2

Connect ethernet, get NO DHCP

root@orangepizero:~# ifconfig

eth0 Link encap:Ethernet HWaddr 2e:2c:9f:81:79:89

inet6 addr: fe80::2c2c:9fff:fe81:7989/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:3 errors:0 dropped:0 overruns:0 frame:0

TX packets:4 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:628 (628.0 TX bytes:580 (580.0

Interrupt:114

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:16436 Metric:1

RX packets:64 errors:0 dropped:0 overruns:0 frame:0

TX packets:64 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:5530 (5.5 KB) TX bytes:5530 (5.5 KB)

wlan0 Link encap:Ethernet HWaddr 1c:93:63:d0:e6:17

inet addr:192.168.10.122 Bcast:192.168.10.255 Mask:255.255.255.0

inet6 addr: fe80::1e93:63ff:fed0:e617/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:244 errors:0 dropped:0 overruns:0 frame:0

TX packets:185 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:45849 (45.8 KB) TX bytes:18990 (18.9 KB)

root@orangepizero:~# netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 wlan0

192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

Looks like everything still going to wlan0

Try ssh again

$ ssh root@192.168.10.122

The authenticity of host '192.168.10.122 (192.168.10.122)' can't be established.

ECDSA key fingerprint is SHA256:GxAvZHUQMY7qQRwewozdSF9CVf/VFiCsTrsa2BVARlA.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '192.168.10.122' (ECDSA) to the list of known hosts.

root@192.168.10.122's password:

___ ____ _ _____

/ _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) |__ /___ _ __ ___

| | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | / // _ \ '__/ _ \

| |_| | | | (_| | | | | (_| | __/ | __/| | / /| __/ | | (_) |

\___/|_| \__,_|_| |_|\__, |\___| |_| |_| /____\___|_| \___/

|___/

Welcome to ARMBIAN Ubuntu 16.04.1 LTS 3.4.113-sun8i

System load: 0.00 Up time: 9 min

Memory usage: 6 % of 494Mb IP: 192.168.10.122

CPU temp: 37Â°C

Usage of /: 16% of 7.2G

Last login: Sat Nov 19 06:12:43 2016

Wow isn't that just a crazy thing? I can ssh to the opi zero wifi IP if my ethernet is plugged in.

awef · November 19, 2016

Reimage Armbian_5.24_Orangepizero_Ubuntu_xenial_3.4.113.img

root@orangepizero:~# nmtui-connect
root@orangepizero:~# ifconfig -a
eth0      Link encap:Ethernet HWaddr 2e:2c:9f:81:79:89
          inet6 addr: fe80::2c2c:9fff:fe81:7989/64 Scope:Link
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0

TX bytes:580 (580.0

          Interrupt:114

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:16436 Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:98 (98.0

TX bytes:98 (98.0

tunl0     Link encap:IPIP Tunnel HWaddr
          NOARP MTU:1480 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:0
          RX bytes:0 (0.0

TX bytes:0 (0.0

wlan0     Link encap:Ethernet HWaddr 7c:c2:4d:f8:71:bc # Wow yet another MAC?
          inet addr:192.168.10.123 Bcast:192.168.10.255 Mask:255.255.255.0
          inet6 addr: fe80::7ec2:4dff:fef8:71bc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:34 errors:0 dropped:0 overruns:0 frame:0
          TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:12223 (12.2 KB) TX bytes:5086 (5.0 KB)

$ ssh root@192.168.10.123
The authenticity of host '192.168.10.123 (192.168.10.123)' can't be established.
ECDSA key fingerprint is SHA256:fH/CYJODVoEXuDhCD4FoR8Z/LMT9T+ony4t/fwbiKLI.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.10.123' (ECDSA) to the list of known hosts.
root@192.168.10.123's password:
___                              ____ _ _____
/ _ \ _ __ __ _ _ __ __ _ ___ | _ \(_) |__ /___ _ __ ___
| | | | '__/ _` | '_ \ / _` |/ _ \ | |_) | | / // _ \ '__/ _ \
| |_| | | | (_| | | | | (_| | __/ | __/| | / /| __/ | | (_) |
\___/|_| \__,_|_| |_|\__, |\___| |_| |_| /____\___|_| \___/
                       |___/

Welcome to ARMBIAN Ubuntu 16.04.1 LTS 3.4.113-sun8i
System load: 0.80          Up time:       1 min
Memory usage: 7 % of 494Mb IP:            192.168.10.123
CPU temp:      36Â°C
Usage of /:    16% of 7.2G

Last login: Mon Nov 14 07:45:07 2016
root@orangepizero:~#

--

So looks like nmtui-connect worked once, and didn't work once. wlan0 MAC address continues to change after imaging. So interesting

awef · November 19, 2016

After another reboot, now the OPi zero again refuses ssh connections via wifi, but gets to the internet just fine.

Igor · November 19, 2016

Do few more things:

- get a new SD card, use Etcher to write (which do the check after write)

- use image from here ... perhaps our first released image has bugs you face? I was using self build image for test which is the same as beta download.

- disable power management on wireless chip: iwconfig wlan0 power off

awef · November 19, 2016

Is there a planned OPi Zero beta image coming down the pipe? or should I use an "alternate"?

awef · November 19, 2016

My goodness... Did I just miss the entire link? Or did it just appear? downloading now. Testing probably in a day.

awef · November 19, 2016

Downloaded beta: Armbian_5.24.161118_Orangepizero_Ubuntu_xenial_3.4.113.img

Imaged with etcher, verified

nmtui-connect

iwconfig wlan0 power off

Same issue, ssh to wlan0 does not connect. Adding a cable to eth0 later enables wlan0 IP to accept ssh.

tkaiser · November 19, 2016

Adding a cable to eth0 later enables wlan0 IP to accept ssh.

So the kernel prefers eth0 as a connection to the outside. Why not removing it from /etc/network/interfaces and managing both NICs with network-manager? The latter can deal with link state changes automagically and adjust these settings for you (in theory and in all tests done by me -- this was the first time Wi-Fi with Linux didn't feel braindamaged but as it should be: just like on OS X where configd does things like network-manager since ages)

Changing MAC addresses are an issue with our first image (no idea why Igor links to this and not to the beta images on the download page) and should have been fixed/workarounded by this commit (a permanent fix would be to use the SoC's SID instead, needs a driver adjustment)

Edit: sshd listening only on interfaces active at startup might also be an issue. A web search for 'sshd /etc/NetworkManager/dispatcher.d' might help here

arox · November 19, 2016

Downloaded beta: Armbian_5.24.161118_Orangepizero_Ubuntu_xenial_3.4.113.img

Imaged with etcher, verified

nmtui-connect

iwconfig wlan0 power off

Same issue, ssh to wlan0 does not connect. Adding a cable to eth0 later enables wlan0 IP to accept ssh.

It probably means that you have a route problem on your host with wlan0 (see tkaiser comment)

No use to test with ssh until you can ping (unless you use iptables filters)

Consider using :

- ip route to have a more precise indication of interfaces used

- ip monitor to trace changes ...

And always check your netmasks and arp tables when strange things occur ...

awef · November 19, 2016

Thanks tkaiser for the suggestion to remove items from network/interfaces. I'll give it a shot and see if that helps NetworkManager.

arox: thanks for the comment, I'll see what I can gather from ip *

awef · November 19, 2016

Folks, thanks all for hanging in there with me.

I got another device on the wifi network which had no problems being pinged (thanks arox for the idea)

So I suspected that perhaps it was my mac that wasn't responding to arp requests correctly.

After resetting my mac and reflashing the SD card (non beta) and using nmtui-connect, sshd responds normally as I would expect.

So as far as I can tell, the only bug I could find today was my mac not responding to arp

Now as far as why connecting wired ethernet to the OPi Zero makes any difference, I have no idea. That is totally beyond me. Any ideas? Could my mac have been so crazy to only answer arp requests from a wired OPi interface? That's just too crazy to believe.

tao · November 20, 2016

It sounds like you might have it behaving the way you want, so all is well. But, if it happens again I go with the suggestion already mentioned before and look at the entire arp cache (arp -a). If there's an unusual entry affecting behavior you might be able to delete it with arp -d. Also, I'm a strong opponent of network manager. Damn thing is a nuisance and keeps resetting things I manually set like resolv.conf.

awef · November 20, 2016

tao - Yeah on the OPi Zero size, it was unable to resolve arp for the Mac. Seems the problem has come up again, so I'm looking into it more.

awef · November 20, 2016

tao - well I guess that automation is always nice in some sense.. but sometimes less automation is nicer for those of us who "know exactly" what we want to do.

awef · November 20, 2016

After more checking, it's almost 99% sure that the Macbook is the problem.

Doing some packet dumps on both devices, I see that the OPi Zero is requesting ARPs, but the Mac refuses to answer

On the other hand, the Mac makes ARP requests and gets responses from the OPi Zero.

Disable/Renabling the WiFi on the Mac fixes this problem

OSX 10.11.6 (15G1108)

awef · November 20, 2016

Hmmm... but that still doesn't answer why connecting wired ethernet to the OPi Zero then allows the macbook to respond to arps... hmmm...

arox · November 20, 2016

Hmmm... but that still doesn't answer why connecting wired ethernet to the OPi Zero then allows the macbook to respond to arps... hmmm...

After more checking, it's almost 99% sure that the Macbook is the problem.

Doing some packet dumps on both devices, I see that the OPi Zero is requesting ARPs, but the Mac refuses to answer

On the other hand, the Mac makes ARP requests and gets responses from the OPi Zero.

Disable/Renabling the WiFi on the Mac fixes this problem

OSX 10.11.6 (15G1108)

I don't know how you are doing your tests. When you want to debug low-level network problems, it is often necessary to use a network protocol analyzer with probes inserted on the wires links. (You could use wireshark on a computer with 2 ethernet interfaces - but it is a time-consuming job and requires a good knowledge of network technology)

And don't forget that your AP is himself a bridge and may be a part if not the cause of the problem.

By the way, what is your wifi mac address ? Beware of bad choices in user (system) configured hardware addresses ...

tkaiser · November 20, 2016

Simple question: did you try out to follow the advice to delete all interfaces from interfaces file and let both eth0 and wlan0 being managed by network-manager? Yes or no?

tkaiser · November 20, 2016

When you want to debug low-level network problems

There's no need to debug anything, simply remove eth0 from a static config file and let network-manager do the job. BTW: the same question comes up here not the first time, see eg. https://forum.armbian.com/index.php/topic/591-wlan0-only-works-when-eth0-plugged-in/

arox · November 20, 2016

There's no need to debug anything, simply remove eth0 from a static config file and let network-manager do the job. BTW: the same question comes up here not the first time, see eg. https://forum.armbian.com/index.php/topic/591-wlan0-only-works-when-eth0-plugged-in/

Yes the link level problems seldom happens. Routing problems are the most frequents. In particular when using 2 interfaces on the same network. So either you follow tkaiser advice and stick to armbian recommendation not using old "/etc/network/interfaces" method, either you configure everything manually ...

tkaiser · November 20, 2016

Routing problems are the most frequents. In particular when using 2 interfaces on the same network. So either you follow tkaiser advice and stick to armbian recommendation not using old "/etc/network/interfaces" method, either you configure everything manually ...

It's known to NOT work correctly as long as eth0 is defined in /etc/network/interfaces so diagnosing instead of using the right approach is a great way to waste your own and others' time. Though you're able to do, just do some fancy post-up/pre-down scripting crap to reinvent the wheel.

Network-manager takes care of link state changes, informs the kernel which interfaces frames should use and even stuff like setting the regulatory domain works automatically in the background:

[   18.052493] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[   18.077436] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   21.067726] libphy: 1c30000.eth-0:00 - Link is Up - 1000/Full
[   21.067774] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   80.242340] RTL871X: rtw_set_802_11_connect(wlan0)  fw_state=0x00000008
[   80.889207] RTL871X: start auth
[   80.892550] RTL871X: auth success, start assoc
[   80.898434] RTL871X: assoc success
[   80.898772] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   80.898941] cfg80211: Calling CRDA for country: DE
[   80.904107] RTL871X: send eapol packet
[   80.912278] RTL871X: send eapol packet
[   80.928599] cfg80211: Regulatory domain changed to country: DE
[   80.928619] cfg80211:  DFS Master region ETSI
[   80.928627] cfg80211:   (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[   80.928640] cfg80211:   (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A,
2000 mBm)
[   80.928652] cfg80211:   (5150000 KHz - 5250000 KHz @ 80000 KHz), (N/A,
2000 mBm)
[   80.928663] cfg80211:   (5250000 KHz - 5350000 KHz @ 80000 KHz), (N/A,
2000 mBm)
[   80.928674] cfg80211:   (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A,
2698 mBm)
[   80.928685] cfg80211:   (57000000 KHz - 66000000 KHz @ 2160000 KHz),
(N/A, 4000 mBm)
[   81.478289] RTL871X: set pairwise key camid:4, addr:bc:05:43:be:c1:e7,
kid:0, type:AES
[   81.478710] RTL871X: set group key camid:5, addr:bc:05:43:be:c1:e7,
kid:1, type:AES
[   95.851698] libphy: 1c30000.eth-0:00 - Link is Down
[  168.667701] libphy: 1c30000.eth-0:00 - Link is Up - 1000/Full
[  168.667759] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

We should provide an empty interfaces file on all Wi-Fi equipped boards to prevent these problems.

awef · November 21, 2016

Ah okay, pardon me. I didn't realize I had to go and "empty out" /etc/network/interfaces.

I was under the impression that simply using nmtui-connect "first" was sufficient.

Let me try an empty interfaces (or something close to that) and see how it goes. (interfaces was never my favorite file anyways)

awef · November 21, 2016

Okay so FYI:

removed /etc/network/interfaces

used nmtui to disconnect/reconnect interfaces

reboot

sshd will not connect if only wlan0 online

Mac -> OPizero : ARP, respond, picked up by wireshark/tcpdump on both computers

OPIZero -> Mac : ARP, respond, wireshark shows ARP response from Mac -> Router; OPiZero does not get ARP response on tcpdump

With ethernet plugged in, SSH to wlan0 ip results in 2 ARP replies from OPiZero (#1 with eth0 mac, #2 with wlan0 mac); Mac then connects via OPiZero eth0 but with wlan0's IP address (of course Mac is just confused)

Anyways, summary:

removing /etc/network/interfaces is "not enough"

If wlan0 works with eth0 is connected, it's because eth0 replies to ARP requests for wlan0's IP address with eth0's MAC address

awef · November 21, 2016

well... a few reboots later (no additional file changes) and things are working nicely with "no /etc/network/interfaces" and whatever random is left of network manager

nmcli m # Monitoring - shows pretty responsive output to connect/disconnect hardwired eth0

But..

Yeah okay SSHD no longer connecting again with eth0 disconnected... erm after reboot now it works again...

awef · November 21, 2016

Anyways, my guess is that "you're right" that removing /etc/network/interfaces vastly improves reliability, even if I do have confusing issues.

I'm guessing that because ARP to wlan0-IP responds with 2 MACs (eth0 MAC, wlan0 MAC), now the macbook thinks that wlan0-IP is on the eth0-MAC.

Now this could be a "invalid case" because both eth0 and wlan0 are on the same subnet.

Anyways, back to the story. Now we disconnect eth0, and try again to connect to wlan0-IP. However wlan0-IP is associated with eth0-MAC, which of course is no longer available.

We now have to wait for wlan0-IP ARP cache to expire on the macbook before wlan0-IP will be associated at the next OPiZero ARP response with wlan0-MAC

One simple solution to all this is to say that ARP reply for wlan0-IP should be only wlan0-MAC (and not eth0-MAC), but... I can't remember off the top of my head right now whether that's correct either.

Sign In

OPI Zero - Incoming SSH - Can't connect

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Similar Content

Important Information