5

I need to know how to connect to a beaglebone (or beagleboard) with SSH when I plug it into a new network with an ethernet cable like this:

    $ ssh root@beaglebone.local

So far I've only been able to access it like this, if I know the IP address:

    $ ssh root@<ip_address>

But I don't always know the IP address of the board on new networks so I'm hoping to access it with with a name like: beaglebone.local.

Right now when I try to do this I get this error: 

    "ssh: Could not resolve hostname beaglebone.local: nodename nor servname provided, or not known"

I checked the hostname and hosts files, and added "127.0.0.1 beaglebone" to the hosts on the beaglebone, but not sure what else I can do? 

    # cat /etc/hostname 
    beaglebone 

    # cat /etc/hosts 
    127.0.0.1        localhost.localdomain                localhost 
    127.0.0.1        beaglebone
ow3n
  • 5,974
  • 4
  • 53
  • 51

4 Answers4

5

I had a similar issue running my beaglebone on Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.04.22.img.xz. In this distribution, "beaglebone.local" should appear on the network after the system boots.

About 50% of the time after reboot, "beaglebone.local" would not appear on the network (although the bone would be available by IP address). When this happened, "systemctl status avahi-daemon.service" showed that the avahi-daemon failed with "exit code 255". Interestingly, a subsequent "systemctl start avaihi-daemon.service" would always be successful and "beaglebone.local" would appear on the network.

Also "journalctl | grep avahi" returned a single message stating something like "Daemon already runnin gon PID NNN".

So, I "fixed" the problem by adding the line "ExecStartPre=/bin/rm -f /var/run/avahi-daemon/pid" to the [Service] section of /lib/systemd/system/avahi-daemon.service. With this addition, "beaglebone.local" now appears on the network 100% of reboots.

I say "fixed" (i.e., in quotes) because I have not been able to track down the root cause that is leaving around the stray avahi pid file(s) and thus don't have a true fix.

-- Frank

Frank Halasz
  • 66
  • 1
0

I hate answering my own questions. The following hack will work until a better way emerges:

This shell script (where xxx.xxx.xxx is the first three numbers in your computer's IP) will find your beaglebone or beagleboard (that is plugged-into ethernet on a new network with DHCP) by looping through all the ip address on the subnet and attempting to login to each as root. If it finds one then try your password. If it doesn't work just hit enter until the loop starts again. If it doesn't find the board then something else is probably wrong.

for ip in $(seq 1 254); do ssh root@xxx.xxx.xxx.$ip -o ConnectTimeout=5; [ $? -eq 0 ] && echo "xxx.xxx.xxx.$ip UP" || : ; done

UPDATE 1

Today I plugged-in the beaglebone and saw Bonjour recognize that it joined the network. So I tried it and it worked. No idea why it decided to all of the sudden but it did. Strange, but true.

ow3n
  • 5,974
  • 4
  • 53
  • 51
  • An easier way, if you know the mac-address of your beagle-board's ethernet port: `nmap -sP ; arp -an | grep ` – Mike Pennington May 16 '12 at 02:57
  • 1
    That's a great idea. Didn't work for me though. Alternately, pinging the broadcast address and then running arp will give you a list, then you can find your MAC. # ping 192.168.1.255 # arp -an – ow3n May 16 '12 at 15:48
  • 1
    You can also use nmap -F xxx.xxx.xxx.1/24 and look for ports that are open. Usually could9 at port 3000 is a good indications. I understand this is not a solution to relay on at all times. – Seeker May 28 '12 at 20:59
0

For 'beaglebone.local' to work, your host machine must recognize Zeroconf. The BeagleBone uses Avahi to tell other systems on the LAN that it is there and serving up applications and that it should be called a 'beaglebone'. If there are more than one, the second one is generally called 'beaglebone-2.local'.

Jadon
  • 51
  • 3
0

I had this issue quite often with Mac OS X 10.7. But unlike Frank Halasz "systemctl status avahi-daemon.service" shown no failure. And in fact the problem was on the Mac side. Restarting Bonjour with the following commands fixed the issue.

$ sudo launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
$ sudo launchctl load -F /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
MathieuLescure
  • 694
  • 6
  • 15