I cant seem to connect to the internet with my beaglebone black (Debian 10 buster) via a ethernet cable which is connected to my laptop.
It was working yesterday but for some reason it decided to just stop working. Here is my putty setup:
When i try to ping 8.8.8.8 i receive the following error:
debian#beaglebone:/var/lib/cloud9$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 169.254.193.76 icmp_seq=1 Destination Host Unreachable
From 169.254.193.76 icmp_seq=2 Destination Host Unreachable
From 169.254.193.76 icmp_seq=3 Destination Host Unreachable
From 169.254.193.76 icmp_seq=4 Destination Host Unreachable
I tried setting a static ip for the beaglebone black by adding the following to /etc/network/interfaces:
iface eth0 inet static
address 192.168.1.102
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 8.8.8.8
dns-nameservers 8.8.4.4
But still no luck.
Does anybody know how i can fix my network issue? Thank you.
Related
my openwrt-x86 has been running for a while inside exsi virtual environment(it's a VM,eth0 eth1 is virtual NIC of exsi),and one day I tried to add a pass through port(eth2 physical) into this openwrt as a lan port so I can access the lan managed by this openwrt by physically connect a wire into eth2, but I found that I can got ip address and dhcp normally,but cannnot connect other ipaddress in the same lan except the openwrt itself and wan network.
my config file of openwrt was
root#OpenWrt:/etc/config# cat network
config interface 'loopback'
option device 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config globals 'globals'
option ula_prefix 'fdc8:982a:611a::/48'
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth0'
list ports 'eth2'
option ipv6 '0'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ip6assign '60'
option ipaddr '10.0.0.1'
option netmask '255.255.0.0'
config interface 'wan'
option device 'eth1'
option proto 'dhcp'
option metric '5'
config interface 'wan6'
option device 'eth1'
option proto 'dhcpv6'
for example I got 10.0.0.10 dhcp ipaddr by physically connected to eth2,then my wan network still fine I can go google,but when I tried ping 10.0.0.151(a vm that in openwrt's lan) and got icmp not reachable
[root#master1 ~]# ping 10.0.0.151
PING 10.0.0.151 (10.0.0.151) 56(84) bytes of data.
From 10.0.0.10 icmp_seq=1 Destination Host Unreachable
From 10.0.0.10 icmp_seq=2 Destination Host Unreachable
From 10.0.0.10 icmp_seq=3 Destination Host Unreachable
From 10.0.0.10 icmp_seq=4 Destination Host Unreachable
From 10.0.0.10 icmp_seq=5 Destination Host Unreachable
From 10.0.0.10 icmp_seq=6 Destination Host Unreachable
and the route table on 10.0.0.10 seems fine
[root#master1 ~]# ip route
default via 10.0.0.1 dev ens192 proto dhcp src 10.0.0.10 metric 100
10.0.0.0/16 dev ens192 proto kernel scope link src 10.0.0.10 metric 100
solved,due to Exsi set internal switch NIC
Promiscuous Mode =false
Forged Transmits =false
by default,so vm in virtual lan cannot receive ARP response delivered,enable them to make it works
I ran the raspbian image with the following command:
qemu-system-arm -kernel kernel-qemu-4.19.50-buster -cpu arm1176 -m 256 -M versatilepb -dtb versatile-pb.dtb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -drive "file=2020-02-13-raspbian-buster-lite.img,index=0,media=disk,format=raw" -net user,hostfwd=tcp::5022-:22 -net nic -net user,smb=/dev/shm/
Booting the image completed successfully.
Withing guest machine I get the following routing table:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 202 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
Now when pinging the gateway at 10.0.2.2 works fine, but when pinging the host machine or the host gateway at 10.0.0.138 I get:
pi#raspberrypi:~$ ping 10.0.0.138
PING 10.0.0.138 (10.0.0.138) 56(84) bytes of data.
64 bytes from 10.0.0.138: icmp_seq=1 ttl=255 time=1.19 ms
64 bytes from 10.0.0.138: icmp_seq=1 ttl=255 time=1.23 ms (DUP!)
I verified that 10.0.0.138 isn't defined as broadcast address, and there are no IP duplications. Any idea how to debug from here? Thanks
As Peter Maydell suggested, merging the two options into one "-net user,smb=/dev/shm/,hostfwd=tcp::5022-:22" solved the case.
This is because QEMU creates a new 'user' network backend for each use of '-net user' on the command line, so in the original commandline there were two backends, each of which was responding to ping packets.
There is a computer with Ubuntu 18.04 it is located behind the NAT router and receives the address in the subnet 192.168.1.0/24. For example 192.168.1.11
I connect from this computer to the VPN server using the IPSec IKEv2 protocol but neither systemctl start strongswan nor ipsec start do not raise the connection, I'm can connect in only one way:
sudo charon-cmd --cert ca-cert.pem --host vpn_domain_or_IP --identity your_username
After connecting I get the address from the NAT subnet on the VPN server 10.10.10.0/24 for example 10.10.10.11 VPN works and all traffic goes through the tunnel. But the connection to the local network completely disappears, requests from subnet 192.168.1.0/24 to address 192.168.1.11 and from my computer to any of the subnet addresses 192.168.1.0/24 do not pass
Output ip a:
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 18:d6:c7:14:ff:04 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.11/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 562sec preferred_lft 562sec
15: ipsec0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN group default qlen 500
link/none
inet 10.10.10.11/32 scope global ipsec0
valid_lft forever preferred_lft forever
inet6 fe80::5b2:78:42:d7/64 scope link stable-privacy
valid_lft forever preferred_lft forever
Ping
:~# ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=0.071 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from 192.168.1.11: icmp_seq=3 ttl=64 time=0.069 ms
64 bytes from 192.168.1.11: icmp_seq=4 ttl=64 time=0.072 ms
64 bytes from 192.168.1.11: icmp_seq=5 ttl=64 time=0.067 ms
^C
--- 192.168.1.11 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4075ms
rtt min/avg/max/mdev = 0.067/0.069/0.072/0.010 ms
:~# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5105ms
All configurations are identical to this resource.
The referred resource has leftsubnet=0.0.0.0/0 set. That causes the VPN connection to default to route everything through the VPN. So simplest is if You can change that. I also want to do this (so add all public-ranges in that list and omit private ranges, maybe besides a special private range to reach the servers LAN). Otherwise You have to manage Your local routing on connecting client "manually". (If both sides use strongwan it should be possible to narrow it on eighter side without breaking the SA completely, but not certain whether specifying multiple subnets works with IKEv1 between strongswan client and server or whether You would need to define multiple SAs then.)
Regarding "only way to establish connection"... I'm wondering whether that means You really have the example confiuration (ike2-rw in ipsec.conf) and started daemon and it is not working - but the example is working on server. I had problems with the Strongswan on Ubuntu 18.04 server side (the VPN gateway), it was connecting but connection came not up. The client I did not try. But I found the Ubuntu 18.04 package is broken (or was back then, a few monmth ago) and upgraded my Ubuntu. With 19.04 it works like a charm. (What is Your journal for the strongswan service saying and syslog - or better the /var/log/charon.log when You try to bring up the client as per documentation?)
I have two PC in same subnet and connected via switch. When I do arp -a the other IP address is shown but I cant ping the other PC.
It is shown in arp, but maybe it is cached, and currently not reachable. Try the following command, which outputs its current cache state:
ip neigh
For example, on my personal laptop, I have a wireless adapter (wlan0) and a wired one (eth0), both connected to the same network (my home router). With arp -a it displays
? (192.168.1.1) en xx:xx:xx:xx:xx:xx [ether] en wlan0
? (192.168.1.1) en xx:xx:xx:xx:xx:xx [ether] en eth0
and with ip neigh it shows
192.168.1.1 dev wlan0 lladdr xx:xx:xx:xx:xx:xx STALE
192.168.1.1 dev eth0 lladdr xx:xx:xx:xx:xx:xx REACHABLE
As seen with ip neigh, the wireless one is in the STALE state, cause it is not being used, but arp -a does not displays it.
Already tried:
Connect the BBB with USB to iMac
Share internet with the board from System Preferences->Sharing
ssh to the board and then try to udhcp -i usb0
This is what it says:
udhcpc (v1.20.2) started
Gets stuck and I get and error: Write failed: Broken pipe
ssh exits
Any clues?
After some try-and-erroring, here's what worked for me:
1. Watch this video: http://www.youtube.com/watch?v=Cf9hnscbSK8
2. If your BBB was shipped after November 2013, instead of screen /dev/tty.usb*B 115200 use screen /dev/tty.usb* 115200 and actually you need to go to the /dev directory and check which of the tty.usbXXX is available for your BBB and screen it. In my case it was tty.usb131 for example
3. You continue the steps just like in the video until opkg update which would be the thing you need to do over the internet
And that it's all about it.
Your SSH session is getting stuck because you're connected to usb0 and the udhcpc command changed the IP address for it! At this point there's nothing listening on the other end of your ssh session, so your local computer's ssh client eventually fails with the broken pipe error and exits.
An obvious workaround is to connect via tty.usbserial instead of ssh to the IP address. You'd think the usb port's assigned IP shouldn't be changing though. Read on to understand what's happening.
Most people using a BBB for the first time attach them directly to their Internet connected computer using the supplied USB cable. It's exactly what the BBBs designers intended for you to do, and they've done a fantastic job with the BBBs startup web page.
That host computer shares it connection differently though depending on whether it's Windows, OS X or Linux, and how you do it varies depending on the version of the OS you're running.
Derek Molloy (Exploring BeagleBone) and Jason Kridner (Youtube OS X Beaglebone video) provide some fairly detailed instructions to use host based Internet sharing with your BBB. The Linux and Windows instructions are still good, but they need to update the OS X info for Yosemite - Apple switched their NAT and firewall software to pf from ipfw and natd. If you try running udhcpc like Jason did in his vid it doesn't work the same way as his did.
So back to your BBB SSH problem with OS X Yosemite. Here's how to see what's going on: Connect to the BBB using a serial/FTDI cable, then check the ip config of usb0 for the beaglebone.
beaglebone:~# ifconfig -a usb0
usb0 Link encap:Ethernet HWaddr 0e:be:ff:00:ff:00 inet addr:192.168.7.2
Bcast:192.168.7.3 Mask:255.255.255.252
confirm you can ping the host that's sharing it's Internet connection
beaglebone:~# ping 192.168.7.1
PING 192.168.7.1 (192.168.7.1) 56(84) bytes of data.
64 bytes from 192.168.7.1: icmp_req=1 ttl=64 time=0.681 ms
64 bytes from 192.168.7.1: icmp_req=2 ttl=64 time=0.533 ms
^C
try reaching an Internet IP (google dns)
beaglebone:~# ping 8.8.8.8
connect: Network is unreachable
check routes and confirm there's no default route out, which is why the ping above failed (a USB connected BBB has a 192.168.7.0/30 network setup by default, so it can only reach 192.168.7.0, .1, .2 and .3 addresses).
beaglebone:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.7.0 0.0.0.0 255.255.255.252 U 0 0 0 usb0
so if you run udhcpc it will add the missing route for you. you could also just add the route directly, but you need to setup dns as well, and with OS X Internet sharing it won't work without also changing the BBB's IP address - see links at end of this post)
beaglebone:~# udhcpc -i usb0
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
and here is where udhcpc changes the IP instead of just re-using 192.168.7.2. The new IP is compatible with the IP range used by OS X Internet Sharing, so that may be why the DHCP server is returning it.
Sending select for 192.168.2.34...
Lease of 192.168.2.34 obtained, lease time 85536
udhcpc then throws an error because there's no default route to delete
/etc/udhcpc/default.script: Resetting default routes
SIOCDELRT: No such process
udhcpc then adds the default route - note carefully it's an OS X Internet Sharing 192.168.2 address, not the original 192.168.7.
/etc/udhcpc/default.script: Adding DNS 192.168.2.1
everything worked, so you can see the new route and successfully ping an external IP now
beaglebone:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 usb0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 usb0
beaglebone:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=53 time=4.08 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=53 time=3.59 ms
^C
There are a couple of blog posts that show how to set this up permanently:
Sharing OS X Internet Connection over USB to BeagleBone Black
and
Changing usb0 IP address on the BeagleBone Black