SSH and PING workarounds

snowbird · February 20, 2017, 9:24am

Here are some workarounds for using ssh and ping with the Dragonboard 410c.

First, some background. A computer and a Dragonboard 410c are on the same network (access point). A computer user attempts to access the Dragonboard using ssh - secure shell, a typical Linux admin program. The user has the IP address of the Dragonboard, however the physical MAC address is needed for the computer to communicate with the Dragonboard. To obtain the MAC address, the computer broadcasts an ARP (address resolution protocol) request. Currently, the Dragonboard 410c does not reply to broadcast requests. A method is needed to provide the Dragonboard’s MAC address to the computer to update its ARP lookup table, which maps IP addresses to MAC addresses.

Separate the computer and the 410c to different networks. In this case, routers typically respond to the ARP request instead of the 410c. Example – place 410c on a Wi-Fi access point, host computers on a separate Wi-Fi access point, and connect the access points.
Run a periodic bash script which pushes the ARP data from the 410c to the other computers on the network.
Manually update the computers ARP table. Painful, but it does work. Messy if the 410c is using DHCP and has a variable IP address.

Here is where this becomes complicated - different networks (routers, firewalls, access points, etc.) handle ARP differently. On some networks, the access point responds to the ARP request so that workarounds are not required. On others, I have tested #2 using PING and NMAP, with negative results. A firewall blocked it so that it did not enable communications.

I am working on code for #2 that sweeps through the local network addresses similar to NMAP. What I found was that if Dragonboard 410c attempts to query ARP rather than push ARP, the destination computer updates its table in process. That is, if the Dragonboard queries a computer for its MAC address, the computer sees the Dragonboard’s IP address and MAC address in the query and updates its table. After this has occurred, the computer is able to PING the Dragonboard 410c or SSH to it. Firewalls, access points, etc do not seem to block this.

Here is the format of the ARP command.

arping -w 10000 -c 1 192.168.1.5

The timeout is in milliseconds -> 10,000 msec. The IP address of the computer is 192.168.1.5.

If you are sweeping ip addresses in a bash script, you can use

arping -w $TIMEOUT -c 1 $network’.’$i

where your network can be determined using

network=$(/sbin/ifconfig wlan | grep inet | grep -v inet6 | awk ‘{print $2}’ | cut -d’:’ -f2 | cut -d’.’ -f1,2,3)

Sean

ldts · February 20, 2017, 9:24am

@snowbird.
Thank you very much for sharing this information!
It was greatly appreciated.

So it seems that we have a couple of workarounds to the current problem that you succinctly described in your entry. The underlying problem (very likely in the Linux kernel) might continue to be present for a little longer so while a solution is in the works, it does make sense that we publicly detail those two work-around.

Workaround 1:
This solution based on the post above, requires the user to copy the following script to the DragonBoard 410c file system and execute it with root permissions. This must be done after the board has established connection to the wifi network (notice that the script assumes that the gateway is at x.x.x.1)


#!/usr/bin/env bash
# ARPing splash by SN
# Network constants.  assume 1 is router and 255 is broadcast
# suggested use is, for Debian 5.11, 
#       sudo ./arping.sh &gt; arping.log &amp;
STARTADDR=2
STOPADDR=254
TIMEOUT=10000
# timeout is in microseconds - 10,000 is 10 msec
# x.x.x.1 is often the gateway, x.x.x.255 is broadcast
 
# Find network address
network=$(/sbin/ifconfig wlan | grep inet | grep -v inet6 | awk &#039;{print $2}&#039; | cut -d&#039;:&#039; -f2 | cut -d&#039;.&#039; -f1,2,3)
echo &#039;Network is &#039;$network&#039;.x&#039;

# Request IP address resolution for each host IP address between STARTADDR and STOPADDR
for ((i=$STARTADDR;i&lt;$STOPADDR;i++))
    do
        arping -w $TIMEOUT -c 1 $network&#039;.&#039;$i &amp;
    done
# arping for TIMEOUT sec max, one packet, to address: base address+last byte

Workaround 2
Another solution -this one in the form of a system service instead of a bash script- was in fact shared and documented by a Linaro employee a few months ago in this very detailed blog entry.

The only modification that maybe should be considered would be to start the service using the -PR option as follows:


#
# /etc/systemd/system/share-mac.service
#
# Running an nmap ping sweep will encourge other
# devices to cache this boards MAC address. This
# works around a problem where the Dragonboard
# 410c does not correctly respond to ARP
# requests.
#
# Note that although nmap&#039;s port scanning is
# disabled it remains possible that the host
# discovery protocol (which is not *actually*
# as simple as a ping sweep) may still trigger
# an IDS if run on a corporate network.
# Take care!
#

[Unit]
Description=Send our MAC address to other devices

[Service]
Type=simple
# Change the IP address and subnet as needed...
ExecStart=/usr/bin/nmap -sn -PR 192.168.1.0/24

So to sum up, with any of the two proposed workarounds, any user should be able to access their Debian based DragonBoard 410c systems reliably over WIFI using their favorite ssh client.

I hope this helps.

snowbird · February 20, 2017, 9:24am

I have reworked my scripts to use nmap as Daniel suggested. I know that a better solution is coming from Linaro - this is posted for learning purposes or if someone adds a second wifi adapter.

For the bash script, here are the changes to use nmap instead of manually looping and arping:

#!/usr/bin/env bash
# nmap arping workaround 
# rev 1.0 01/13/2016
# Network constants
# suggested use is, for Debian 5.11, 
#       sudo ./nmaparping.sh &gt; nmaparping.log
STARTADDR=2
STOPADDR=254
# x.x.x.1 is often the router/gateway, x.x.x.255 is broadcast
 
# Find network address
#   note, assumes there is only one wlan network 
#   if there are multiple wlan, the network address will be incorrect
network=$(/sbin/ifconfig wlan | grep inet | grep -v inet6 | awk &#039;{print $2}&#039; | cut -d&#039;:&#039; -f2 | cut -d&#039;.&#039; -f1,$

# Use nmap to push ARP data
#  The following command line forces nmap to do a ARP/Neighbor discovery (-PR) with 
#  no port scan (-sn).  It should be unobtrusive on most neworks.
#  For reference, on windows, arp -a will list current IP and MAC address pairs.
#  For linux, try    ip -s neigh list .  To install nmap on this computer, use
#  sudo apt-get install nmap
 
echo $network.$STARTADDR-$STOPADDR
nmap -sn -PR -n $network.$STARTADDR-$STOPADDR &gt;&gt; /opt/nmap4arp/nmap4arp.log

For the systemd service, you can add the name of a script:

[Unit]
Description=Use an nmap script to push MAC address to all local hosts

[Service]
Type=simple
# this bash script determines the network and uses nmap to scan it
ExecStart=/opt/nmap4arp/nmap4arp.sh

tfoote · February 20, 2017, 9:25am

Here’s a slightly simpler version using ip addr instead of ifconfig since ifconfig is not on debian by default. It will also use the netmask to determine the size of the network.

#!/bin/bash network=<code>ip addr show dev wlan0 | grep "inet " | awk '{print $2}'</code> nmap -sn -PR $network <code></code>

ldts · February 20, 2017, 9:26am

since the FAQ points to this discussion, I’ll just add a reference here to a debian package I wrote six months ago to be used as a workaround until the problem is resolved (I believe it might have been fixed on 16.04)

debian package