Jump to content
  • 0

OPI Zero - Incoming SSH - Can't connect


awef
 Share

Question

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.

Link to comment
Share on other sites

Recommended Posts

  • 0

For info, I am using the latest beta image and experiencing the same flaky behaviour with wifi.

 

Sometime is works - nearly always with ethernet plugged in and other time I can see it has grabbed an IP from my router but I can't ping or ssh.

 

I do not have a debug connector so can't give more info.

 

Hopefully it will be resolved when a full release comes.

 

J.

Link to comment
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0

For info, I am using the latest beta image and experiencing the same flaky behaviour with wifi.

 

As already mentioned in this thread the 'environment' might be responsible though. It's not only your SBC that joins with two interfaces one network but this 'single network' is in reality two different ones (WiFi and Ethernet) that are or should be bridged.

 

In other words: Either try to setup two different networks (Wi-Fi being physically separated from Ethernet which means no router who enables both and should bridge frames in between) or become an network expert, choose your sniffer of choice and check what's up at network layer 2 (there live frames not packets).

 

I would prefer the first variant.

Link to comment
Share on other sites

  • 0

Just got my two OPi-Zero boards in the mail today.

 

I have similar issue here on Windows 7 so I don't think your Mac is the problem. Using the latest Xenial beta image I can ping the OPi-Zero via the router but any attempt at an ssh connection is refused. In Raspbian on the RPi I can change the IP address of the ethernet connection by editing config.txt but since Armbian doesn't have a FAT32 partition or similar setup method this isn't possible. Thus the only way to run headless is via wifi, which ain't working.

 

Bummer.

Link to comment
Share on other sites

  • 0

Bummer says it all. What an attitude. I get sooooo sick of this! Unbelievable!

 

When ping works but SSH through Ethernet not then most probably the board is stuck in u-boot! You won't believe it but we test the stuff we provide. So if you want to do more than just complaining then grab a serial console and provide the boot log so we can reproduce the issue IF there is one and it's not just the usual issue called insufficient power supply (Zero uses Micro USB which is known to cause problems) or broken burning process or SD card.

 

Why do you hijack a thread about Wi-Fi related problems when you've not been able to even configure WI-Fi since your installation does not even boot?!

 

I'm out from now on!

Link to comment
Share on other sites

  • 0

When you have 2 nics in the same network, you need to setup source level routing. What you want is that everything which comes on eth0, should be answered on eth0. And everything which comes on wlan0 should be responded from wlan0. (Which is actually the default in Solaris, I don't know why this is not the default in Linux)

 

Easiest way is to define the routes in two tables, see here:

http://serverfault.com/questions/336021/two-network-interfaces-and-two-ip-addresses-on-the-same-subnet-in-linux

Link to comment
Share on other sites

  • 0

@tkaiser - Thanks a lot for your help.  Despite hijackers, I think things work as designed.

@chrisd - Thanks for that interesting source level routing link.  Coincidentally, I did spend a lot of time in Solaris, so I suppose I simply took some things for granted

 

As for the rest of you playing with 2 NICs in 1 subnet, the short answer is - Pick 1, Stop switching, wait a few minutes (really... wait!) , it will probably work.

 

Long story, the default config can easily make it look like both IPs for eth0 and wlan0 are on eth0.  Thus when you finally disconnect eth0, all your wlan0 packets are sent to eth0 and fail (due to ARP responses for wlan0's IP pointing to eth0's MAC)

 

The fix: Update config to stop sending ARP responses for wlan0's IP with eth0's MAC.  Just because it's the same "board" doesn't mean it should ARP reply that way - How?... perhaps it's something like what @chrisd wrote.  

 

 

(I'll be damned.... damn near at the top of @chrisd's link)

Step 1: Enable ARP filtering on all interfaces:

# sysctl -w net.ipv4.conf.all.arp_filter=1
# echo "net.ipv4.conf.all.arp_filter = 1" >> /etc/sysctl.conf

From the file networking/ip-sysctl.txt in the Linux kernel docs:

arp_filter - BOOLEAN
1 - Allows you to have multiple network interfaces on the same
subnet, and have the ARPs for each interface be answered
based on whether or not the kernel would route a packet from
the ARP'd IP out that interface (therefore you must use source
based routing for this to work). In other words it allows control
of which cards (usually 1) will respond to an arp request.

0 - (default) The kernel can respond to arp requests with addresses
from other interfaces. This may seem wrong but it usually makes
sense, because it increases the chance of successful communication.
IP addresses are owned by the complete host on Linux, not by
particular interfaces. Only for more complex setups like load-
balancing, does this behaviour cause problems.

arp_filter for the interface will be enabled if at least one of
conf/{all,interface}/arp_filter is set to TRUE,
it will be disabled otherwise

Link to comment
Share on other sites

  • 0

As for the rest of you playing with 2 NICs in 1 subnet, the short answer is - Pick 1, Stop switching, wait a few minutes (really... wait!) , it will probably work.

 

Well, I would talk about collission domains here (and behaviour of the 2nd device that might play an important role -- router/AP) but that doesn't matter a lot. Also it should be noted that Allwinner's legacy kernel for H3 devices is known to be broken here and there (eg. multicast handling -- you can't use that thing to get AppleTalk up and running).

 

Anyway: thanks for sharing the insighst and please feel free to add stuff to https://github.com/igorpecovnik/lib/issues/558 (I get a little frustrated that all issues that are labeled with 'discussion' end up orphaned pretty soon ;) )

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...