410c/Ubuntu: Can't SSH in


#1

I’ve seen a few other threads on this - is there a solution coming? I’m using what I think is the latest: Release 15.06. Also I did sudo apt-get update and upgrade.

I am able to connect WIFI (but have to enter passwd each time which is another issue). The interface comes up, DHCP works, and Openssh server is running because I can ssh to localhost.

But from another machine on the subnet - no luck. So then I can’t really run headless, which I gotta be able to do so this is hurdle. I saw one post that you can ping out to the machine you want to ssh from - dont want to do such things - would like it to just work normally - anyone know more about this and when/how it will work?

thanks
Matt


#2

Hi Matt,

If you want to run headless, we have found that ssh’ing will work if you set up 410C to run its own Wifi hotspot (using hostapd and isc-dhcp-server). I can post scripts for setting this if you’re interested.

In the meantime, the only way we’ve found to ssh to the 410C from another machine on the network is to ping that machine from the 410C.

Best,
Patryk


#3

Actually I have the scripts handy. Here they are:


#!/bin/bash
# hotspot_410c_configure.sh
# PREP 410C FOR HOTSPOT MODE. RUN THIS ONCE.
sudo apt-get -y install iw hostapd isc-dhcp-server
cd /etc/dhcp

alreadyConfigured=<code>grep "ignore client-updates" dhcpd.conf | wc -l</code>

if [ $alreadyConfigured -eq 1 ]; then
echo "dhcpd.conf appears already set up, not setting up again"
else
cat >> dhcpd.conf << EOF
ignore client-updates;
subnet 192.168.1.0 netmask 255.255.255.0 {
 range 192.168.1.10 192.168.1.250;
 option routers 192.168.1.69;
 option domain-name-servers 192.168.1.69;
}
EOF
fi

And then to turn on hotspot mode, run the following script. The WPA/password settings are currently commented out. You can uncomment them if you wish to have a password.


#!/bin/bash
# hotspot_410c_launch.sh
# SCRIPT THAT STARTS HOTSPOT MODE

# Wait until wlan interface shows up
MYWLAN=""
while [ "$MYWLAN" == "" ]
do
    echo -n "Waiting for wlan.txt"
    date
    sleep 2
    MYWLAN=<code>ifconfig | grep ^wlan | cut -d ' ' -f 1</code>
done

cd /etc/default
sed -i -r "s/INTERFACES=.*$/INTERFACES=\"$MYWLAN\"/" isc-dhcp-server

cd /etc/hostapd
cat > hostapd.conf << EOF
interface=$MYWLAN
driver=nl80211
ssid=My410C
hw_mode=g
channel=1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
# wpa=2
# wpa_passphrase=MySecretPassword
EOF

cd /etc/default
cat > hostapd << EOF
DAEMON_CONF="/etc/hostapd/hostapd.conf"
EOF

sudo service NetworkManager stop
sudo ifconfig $MYWLAN 192.168.1.69
sudo service isc-dhcp-server start
sudo hostapd /etc/hostapd/hostapd.conf &

Best,
Patryk


Brain Corporation: Computer vision and machine learning for robotics.


#4

Uh oh, the shell script code got mangled by the forum software… I see some &quot entities appearing… Backticks in the shell scripts got replaced…


#5

OK – To avoid the issues with the forum mangling, I’ve posted the hotspot shell scripts here:

http://pakl.net/hotspot_410c_configure.sh
http://pakl.net/hotspot_410c_launch.sh

Best,
Patryk

Brain Corporation: Computer vision and machine learning for robotics.


#6

Thanks for the quick reply and scripts - might try that - however I dont wish to run a hotspot - I just want it to work normally like everything else, and get an address from my DHCP server which I can administer to be the same address each time, and behave just like all other machines on the subnet in that regard. I suspect most everyone will want this as well.

I’m going to try now to use a USB-ethernet adapter to see if I can ssh-in that way through a wired interface.


#7

hi @matthewgrob, i confirm this is an issue. we’ve got several reports of it, actually, and the following [1] discussion has started on the upstream wcn driver mailing list

It looks like this is the default behavior in the firmware to filter multicast traffic which would prevent your PC to acquire the MAC address of the board (without a prior ping from the board). We are looking at how we could fix that in the wcn36xx driver used on linux.

[1] http://lists.infradead.org/pipermail/wcn36xx/2015-July/001491.html


#8

From the thread it appears that there are options that can be configured by the wcn36xx driver. Is that the path to fixing this?

Thanks.


#9

Any updates on this? Running headless is an absolute requirement when you are working on robotics & IoT.


#10

hi, no update, i am sorry. not because we ignored the problem, but because we still haven’t found the solution…

i don’t understand the remark about headless. the problem would be the same with headless or non headless systems, actually.

a workaround is to ping your PC from the board at least once. then you can ssh into from the board from the PC.


#11

I think he means that since he is using it headless, the ONLY way to access the device is via SSH, whereas setting it up with a monitor and keyboard to use as a workstation isn’t really affected by this bug as severely, since outbound network requests work regardless.


#12

Apologize for the late reply. @doitright is correct, the ONLY way I can, want & need to access the device is either via SSH or adb (i.e. no TV/Keyboard/Mouse) (see https://www.96boards.org/forums/topic/adb-daemon-on-410c-linux/).

Thanks


#13

Is there any update on this? I’m using the latest release (v80) and having this issue. Looks this is not only for SSH, but the board is blocking incoming traffic in general.


#14

hi,

i am sorry , but still no update.

yes, all incoming traffic doesn’t work. The problem is that the firmware blocks ARP requests. So nobody on the network can get the board MAC address, and so nobody can engage with the board, whatever the service is. If the board sends a ping requests to another system, then that system would gain knowledge about the board IP/MAC in that process… and further incoming traffic (from that system) will be possible.


#15

This seriously is a pain, but thanks to the discussion here,
I use a very simple script that I run to keep accessibility to the board:

#!/bin/bash
while true
do
wget -q -O - checkip.dyndns.org|sed -e 's/.*Current IP Address: //' -e 's/<.*$//' > ~/myip &&
date
cat ~/myip &&
if [[ $(cat ~/myip) != $(cat ~/oldip) ]]
then
ping -c 3 my.pc.domain.de &&
cat ~/myip | sendEmail -s smtp.gmx.net -xu 123456789 -xp secretpassword -f my.adress@gmx.de -t work.adress@work.de -u currentip 
cp myip oldip
fi
sleep 600 
done

#16

That script seems excessively complicated for just the purpose of maintaining a working inbound route.

Try instead just pinging your router once every 10 minutes like this;

#!/bin/bash
GWIP=ip route show | grep default | cut -d\ -f3
while ( true ); do
ping -c1 $GWIP
sleep 600
done

The part of that that mangled into code tags is within a pair of backticks, which inconveniently, are the “code” delimiters for this forum software.

But ping is pretty light, especially operating on a local network, so you might even prefer dropping the sleep lower than that.

As for sending an email with your IP address… your db’s ip address shouldn’t change on account of this glitch. If it does, then your ROUTER is misconfigured. A much better option would be to assign a hostname to the db’s MAC address in your router’s DNS settings, and use that instead of the super messy email approach. I.e., OpenWRT and similar use dnsmasq for DHCP and DNS, so it automatically sets up a DNS entry for every IP address it hands out. As long as EITHER (a) your device provides a non-duplicated hostname, or (b) you assign a hostname to the MAC address, then you have a DNS record available from the router for that device.


#17

Oh, yes. I should have mentioned that this script serves two purposes indeed.
I connect remotely via internet from work to home (the DB rests at home).
While the IP of my work machine is static, the one of the Dragonboard (of its router) is dynamic (a private DSL provider with 24h cut off). So this is the simple/cheap way of knowing a remote machine’s IP using very basic hardware/setups.


#18

Wouldn’t a dynamic dns be a better solution for that?


#19

BTW, not that it solves your problem, but I do not see any issues of this kind while using a USB to Network dongle (trendnet TU3-ETG).


#20

I’ve been trying to connect to a headless '410c and got bored having to go in with the UART in order to ensure the Dragonboard got to make the first move…

I wanted a configure-and-forget solution so I have configured systemd to automatically do ping sweeps of my LAN every five minutes. See http://www.redfelineninja.org.uk/daniel/?p=421 for a details.

I don’t pretend this is anything other than a hack but it does eliminate the most serious side effects of the problems @ndec mentions above.