BBB network adapter connection failed, can't access board via ssh

I’ve come across an issue with a BBB where I can no longer ssh onto the board from terminal on my host computer. My host computer is running Ubuntu 18.04. I was running 16.04, and had no issues. One of my projects required me to update to 18.04, but I’m not saying the cause of the issue is related to the update, just information. I attempt to ssh to ip address and I just get a timeout error. I get an unreachable error when I ping the board. I have no issue using minicom to access the board, but when I’m on the board I try to ping my host computer,, and I get the same unreachable error.

Something else that I’m seeing is while the BBB is connected to the computer, I repeatedly get a error pop up. “Connection failed Activation of network connection failed”.

Auto Generated Inline Image 1.png

I have limited knowledge, but this makes it sound like there’s an issue with my network adapter. Which, from my understanding, is whats suppose to generate the usb network ip address to allow the host and board to communicate.

I’ve tested this on a regular BBB and a wireless BBB and I get the same issue on both.

Any suggestions?

I want to add that I just tried it on windows 10 and I’m having the same issue.

FYI: on Windows, the USB network uses 192.168.7.x

  The behavior you describe sounds more like faulty drivers on the host
side. Have you tried connecting an Ethernet (CAT-5/6) cable between the
board and your router, and then attempting to connect to the board using
the IP the router assigned to it? (Or, if the router is modern enough, use
hostname beaglebone or beaglebone.local [some systems will append the
.local automatically]).

I guess you should change the static IP of your Ubuntu Host computer to or (by going to network connections and assigning manual static ip).

Then, I think it would successfully give the ping response to ping or

Sagar Patel


yes sir, I’m aware of the changes for windows to .7.x. I verified the communication is still an issue with the difference.

with the non-wifi board yes I can communicate with the board via the ethernet cable. That works just fine, the issue really ends up being related to the usb communication. In the end I’ll be using the USB as primary communications with the board. Using the wifi is not an option.

I agree the behavior does sound like faulty drivers. However, what makes it strange is the fact I’ve used both windows and linux to attempt to connect to the board, which kinda makes me feel its hardware related.

I attempted to connect on a co-workers computer as well. and nothing. We see the BBB in file exployer, but I wasn’t really expecting to being able to communicate with the BBB on my co-workers computer as I didn’t think he had the drivers.

with that said, I tried looking for driver information for linux, but nothing was listed on, as it appears that it should need specific drivers. is there something i should look for, or I can updated related to drivers on the linux side?

I’m going to go back to my windows boot and delete and resinstall the windows drivers in a bit. to see if that does anything.

Who does the output of ‘ip a’ show on your host Ubuntu computer with the BB plugged in?
Also, when you plug the BB into the host, check the output of ‘dmesg’ to see if there are any errors reported for the USB device or the usb ethernet interface.



~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 70:5a:0f:91:02:b4 brd ff:ff:ff:ff:ff:ff
4: wlp1s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether a4:34:d9:54:a9:25 brd ff:ff:ff:ff:ff:ff
5: enx503f5602c060: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 50:3f:56:02:c0:60 brd ff:ff:ff:ff:ff:ff
inet brd scope global dynamic noprefixroute enx503f5602c060
valid_lft 604455sec preferred_lft 604455sec
inet6 fe80::534d:3bc8:b294:728f/64 scope link noprefixroute
valid_lft forever preferred_lft forever
7: enxa0f6fd648818: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether a0:f6:fd:64:88:18 brd ff:ff:ff:ff:ff:ff
inet6 fe80::c029:c2b8:bd50:cd98/64 scope link noprefixroute
valid_lft forever preferred_lft forever

DMESG results after plugging usb in and waiting for board to boot.

~$ dmesg

[ 487.911459] xhci_hcd 0000:00:14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[ 535.166910] usb 1-1: new high-speed USB device number 17 using xhci_hcd
[ 535.319879] usb 1-1: New USB device found, idVendor=1d6b, idProduct=0104
[ 535.319884] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 535.319887] usb 1-1: Product: BeagleBoneBlack
[ 535.319890] usb 1-1: Manufacturer:
[ 535.319893] usb 1-1: SerialNumber: 1116BBBK13C3
[ 535.322775] rndis_host 1-1:1.0 eth0: register ‘rndis_host’ at usb-0000:00:14.0-1, RNDIS device, a0:f6:fd:64:88:18
[ 535.323716] cdc_acm 1-1:1.2: ttyACM0: USB ACM device
[ 535.360310] rndis_host 1-1:1.0 enxa0f6fd648818: renamed from eth0
[ 535.409694] IPv6: ADDRCONF(NETDEV_UP): enxa0f6fd648818: link is not ready

sudo dhclient enxa0f6fd648818

Then run ip a again to see if got an ip..