The Dragonboard 410c is a great platform but currently there is a problem with the wireless driver that makes it very hard to run it headless and connect to services running on the board via wifi.
At present the board does not respond correctly to broadcast packets. This results in a number of issues but by far the most significant is that the board cannot reply to ARP requests and this prevents other devices from opening connections to it. From the client machines point of view it knows the board is there, and it can look it up using DNS, but it can’t take the final steps needed to communicate with the board.
In the example below we have a client machine, birch.lan, unable to access dragonboard.lan, because it cannot find the right MAC address.
birch# arp -e Address HWtype HWaddress router.lan ether 40:ba:fa:xx:xx:xx dragonboard.lan (incomplete) wychelm.lan ether fc:aa:14:xx:xx:xx
If only we could get the MAC address into birch’s ARP cache then there would be no problem doing basic network activity like connecting an SSH server. Thankfully there is a fairly easy way to automate this…
Get the Dragonboard to do a nmap ping-sweep of the subnet.
To be clear this is a hack of such huge proportions that it deserves more than just those four letters! It is a bodge, a sticking plaster, a nasty solution stuck together with sticky tape and glue, it does not make me feel warm and snuggly inside… however… it does work.
Not only does it work but it can also be trivially hooked up to systemd so that the device can periodically shout out its presence.
Firstly we need to create a simple service to launch the ping sweep (actually it will be much more like an arping sweep):
# # /etc/systemd/system/share-mac.service # # Running an nmap ARP ping sweep will encourage 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'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 range as needed... ExecStart=/usr/bin/nmap -PR -sn -n -e wlan0 192.168.1.1-254
The above service runs just once and it would be enough to get the board noticed after it boots but eventually the other devices would evict the ‘410c from their ARP caches and it would fall off the network again. To solve this we can use a systemd timer to ensure we always keep poking the other devices:
# # /etc/systemd/system/share-mac.timer # [Unit] Description=Repeatedly send out our MAC address [Timer] OnBootSec=30 OnUnitActiveSec=3m Unit=share-mac.service [Install] WantedBy=multi-user.target
Finally we need to run a few commands on the ‘410c to install nmap and ensure systemd runs the above files:
apt-get update apt-get install nmap systemctl enable share-mac.timer systemctl start share-mac.timer
With these changes in place the ‘410c should announce its existence to all hosts on the network shortly (~30 seconds) after booting and it will repeat the sweep every 5 minutes to ensure the ARP caches stay nice and hot going forward.
The results of the above scripts showed up straight away in birch.lan‘s ARP cache:
birch# arp -e Address HWtype HWaddress router.lan ether 40:b0:fa:xx:xx:xx dragonboard.lan ether 02:00:7d:xx:xx:xx wychelm.lan ether fc:aa:14:xx:xx:xx
Share and enjoy!
Update #1 (2016-01-15): Updated the nmap command with -PR (ensure pure ARP ping sweep), -n (no reverse DNS lookup) and -e wlan0 (only deploy workaround on a specific network interface). Reduced the interval between sweeps from 5 mins to 3 mins to better handle congested networks (10 minutes ARP cache timeouts are common). Thanks to snowbird and ldts-jro for their feedback with this.