OPI Zero - Incoming SSH - Can't connect

[tkaiser]

It's known to NOT work correctly as long as eth0 is defined in /etc/network/interfaces

 

Just tried it out and I was wrong. Works also flawlessly with eth0 active in /etc/network/interfaces, still removing eth0 from there seems to be an improvement to me since network-manager can then manage the device (adjusting routing -- in my case I also just test the 2 NICs connected to same collission domain case).

macbookpro-tk:~ tk$ sw_vers 
ProductName:	Mac OS X
ProductVersion:	10.10.5
BuildVersion:	14F2009

macbookpro-tk:~ tk$ arp -a
fritz.box (192.168.83.1) at bc:5:43:be:c1:e1 on en0 ifscope [ethernet]
orangepipcplus.fritz.box (192.168.83.135) at d6:6:6c:2f:a1:85 on en0 ifscope [ethernet]
orangepipcplus.fritz.box (192.168.83.183) at d6:6:6c:2f:a1:84 on en0 ifscope [ethernet]
? (192.168.83.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]

And this is device's view (disconnected Ethernet, then logged in through wlan0): http://sprunge.us/JUiM

[Johhny Blue]

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.

[tkaiser]

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.

[haiqu]

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.

[tkaiser]

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!

[chrisd]

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

[awef]

@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

[tkaiser]

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 )