Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Unable to ssh into bone over USB after connecting wirelessly. #422

Open
AhmedSamara opened this issue Dec 2, 2015 · 6 comments
Open

Unable to ssh into bone over USB after connecting wirelessly. #422

AhmedSamara opened this issue Dec 2, 2015 · 6 comments
Assignees
@dfarrell07
Labels
field:CS prio:high type:bug type:Problem-Statement type:quesiton

Comments

@AhmedSamara
Copy link
Member

@dfarrell07 this is an interesting one.

So I haven't been able to ssh into beaglebones on my own laptop for a while, but today after I was able to recreate the same problem on someone elses laptop, I realized that the common factor was this happened after the first time they connected wirelessly (after connecting to the IEEEbot network wirelessly).

Previously the symptom was that when I tried to SSH it would just hang up, but now when I try I get the error:

ssh: connect to host 192.168.7.2 port 22: No route to host

There have been times when I've fixed it a multitude of different ways, so it might be a different issue every time. These methods have included:

  • rebooting computer with beaglebone plugged in, allowed SSH.
  • Deleting contents of ~/.ssh/known_hosts
  • Going into network manager and turning on USB ethernet.

When I plug in a Beaglebone over USB, I can view it as a mass storage device (common to issue every time), and detect that it's connected, but still can't ssh.
I also can not ping it, or view it in the web browser. I've tried checking my network interfaces, my USB port seems to be configured to do DHCP

image

Here is the output of ifconfig -a
(The BeagleBone is enp0s26u1u2)

enp0s26u1u2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.7.1  netmask 255.255.255.0  broadcast 192.168.7.255
        inet6 fe80::564a:16ff:fec0:a363  prefixlen 64  scopeid 0x20<link>
        ether 54:4a:16:c0:a3:63  txqueuelen 1000  (Ethernet)
        RX packets 44  bytes 7858 (7.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25  bytes 5566 (5.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether f0:de:f1:94:17:70  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 4661  bytes 457791 (447.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4661  bytes 457791 (447.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:f8:46:d2  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0-nic: flags=4098<BROADCAST,MULTICAST>  mtu 1500
        ether 52:54:00:f8:46:d2  txqueuelen 500  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0b1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.139.71.147  netmask 255.255.248.0  broadcast 10.139.71.255
        inet6 fe80::62d8:19ff:fe2c:fb77  prefixlen 64  scopeid 0x20<link>
        ether 60:d8:19:2c:fb:77  txqueuelen 1000  (Ethernet)
        RX packets 219834  bytes 35578385 (33.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13807  bytes 2420104 (2.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
@mynameis7
Copy link
Contributor

I plugged in the beaglebone over ethernet on my computer and I still cannot connect to it.

@PaladinEng
Copy link
Contributor

Try ssh into beaglebone.local or 10.0.0.1, or 10.0.0.2

Sent from my iPhone

On Dec 2, 2015, at 12:49 AM, Ahmed Samara [email protected] wrote:

@dfarrell07 this is an interesting one.

So I haven't been able to ssh into beaglebones on my own laptop for a while, but today after I was able to recreate the same problem on someone elses laptop, I realized that the common factor was this happened after the first time they connected wirelessly (after connecting to the IEEEbot network wirelessly).

Previously the symptom was that when I tried to SSH it would just hang up, but now when I try I get the error:

ssh: connect to host 192.168.7.2 port 22: No route to host
There have been times when I've fixed it a multitude of different ways, so it might be a different issue every time. These methods have included:

rebooting computer with beaglebone plugged in, allowed SSH.
Deleting contents of ~/.ssh/known_hosts
Going into network manager and turning on USB ethernet.
When I plug in a Beaglebone over USB, I can view it as a mass storage device (common to issue every time), and detect that it's connected, but still can't ssh.

I also can not ping it, or view it in the web browser. I've tried checking my network interfaces, my USB port seems to be configured to do DHCP

Here is the output of ifconfig -a

(The BeagleBone is enp0s26u1u2)

enp0s26u1u2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.7.1 netmask 255.255.255.0 broadcast 192.168.7.255
inet6 fe80::564a:16ff:fec0:a363 prefixlen 64 scopeid 0x20
ether 54:4a:16:c0:a3:63 txqueuelen 1000 (Ethernet)
RX packets 44 bytes 7858 (7.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 25 bytes 5566 (5.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

enp3s0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether f0:de:f1:94:17:70 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10
loop txqueuelen 0 (Local Loopback)
RX packets 4661 bytes 457791 (447.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4661 bytes 457791 (447.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 52:54:00:f8:46:d2 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0-nic: flags=4098<BROADCAST,MULTICAST> mtu 1500
ether 52:54:00:f8:46:d2 txqueuelen 500 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlp2s0b1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.139.71.147 netmask 255.255.248.0 broadcast 10.139.71.255
inet6 fe80::62d8:19ff:fe2c:fb77 prefixlen 64 scopeid 0x20
ether 60:d8:19:2c:fb:77 txqueuelen 1000 (Ethernet)
RX packets 219834 bytes 35578385 (33.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 13807 bytes 2420104 (2.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
—
Reply to this email directly or view it on GitHub.

@AhmedSamara
Copy link
Member Author

a313938

Looking at this commit, udhcp was removed at one point, and then put back because it caused USB connections to break, so Andy apparently ran into this problem over the summer while I was gone.

Apparently, not purging udhcp caused USB connectivity to break, but now USB connectivity is breaking despite the purge.
@dfarrell07 , do you know anything that could be causing this?

@tabarrett
Copy link

Yeah took me about an hour to connect to the bone through just repeated restarts and changing cables, pinging it, etc. Its frustrating for Beginners, I think its part of why alot of us are using other micro-controllers to test things.

@AhmedSamara
Copy link
Member Author

Going in from the server using beaglebone.local and stuff didn't work either.

Still no idea what the problem is.

@AhmedSamara
Copy link
Member Author

A few other senior design groups reported having this problem too.
Maybe it's a debian issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dfarrell07 dfarrell07

Labels
field:CS prio:high type:bug type:Problem-Statement type:quesiton
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@dfarrell07 @PaladinEng @AhmedSamara @mynameis7 @tabarrett