Raspberry Pi 3B+ with Bullseye has no eth0 interface at all - linux

I'm trying to connect my Raspberry Pi 3B+ to my network. But neither do the LAN-LEDs light up nor does the Pi even know what eth0 is. I also have no en<x><MAC>.
ifconfig outputs the following (ifconfig -a does the same):
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 1000 (Local Loopback)
RX packets 10 bytes 1564 (1.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10 bytes 1564 (1.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether MY-MAC-ADDRESS 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
/etc/network/interfaces is as follows:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*
/etc/network/interfaces.d/ is empty.
Like I said, it doesn't know what eth0 is at all:
~$ ifup eth0
ifup: unknown interface eth0
~$ sudo dhclient eth0
Cannot find device "eth0"
The network cable works, tested it on other PCs and tried many different ones...

I believe there was a bug introduced in Bulleye.
If /boot/cmdline.txt does not have "net.ifnames=0", then add that to the end of the root= line. Then reboot.

Related

Xdebug in docker container fails to connect to PhpStorm on Qubes OS

Xdebug within a Docker container does not connect to PhpStorm on my system.
I am trying to setup Xdebug with PhpStorm for a Docker environment on Linux (qubes-os / Fedora 30). Xdebug is enabled, and I can access error messages. In PhpStorm I always updated DBGp Proxy setting with the respective IPs I gave Xdebug as remote host. I tried many versions of Xdebug setups but all failed.
My current best guess is that something with the internal IP management is messed up. This could be due to qubes-os, but I'm not really convinced since it's a normal Fedora and I have never had issues like that before...
My Xdebug conf
zend_extension=xdebug.so
[Xdebug]
xdebug.idekey=PHPSTORM
xdebug.remote_enable=true
xdebug.remote_port=5902
xdebug.remote_host=host.docker.internal
xdebug.remote_log=/tmp/xdebug-remote.log
(I'm aware that host.docker.internal does not work for Linux. I'm using it anyway for easier debugging by setting an IP to this variable in the /etc/hosts file of the docker container)
My phpinfo()
xdebug support enabled
Version 2.6.1
IDE Key PHPSTORM
xdebug.remote_enable On On
xdebug.remote_handler dbgp dbgp
xdebug.remote_host host.docker.internal host.docker.internal
xdebug.remote_log /tmp/xdebug-remote.log /tmp/xdebug-remote.log
xdebug.remote_mode req req
xdebug.remote_port 5902 5902
xdebug.remote_timeout 200 200
My web-log tells me, that my requests are coming from
172.18.0.1 - - [31/Oct/2019:09:58:22 +0000] "GET / HTTP/1.1" 200 47698 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36"
my ifconfig output host machine
br-8d5002ad7a3a: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.18.0.1 netmask 255.255.0.0 broadcast 172.18.255.255
inet6 fe80::42:17ff:feaa:e865 prefixlen 64 scopeid 0x20<link>
ether 02:42:17:aa:e8:65 txqueuelen 0 (Ethernet)
RX packets 5 bytes 513 (513.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11 bytes 866 (866.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fe80::42:99ff:fe38:e669 prefixlen 64 scopeid 0x20<link>
ether 02:42:99:38:e6:69 txqueuelen 0 (Ethernet)
RX packets 4055 bytes 233615 (228.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4367 bytes 55073512 (52.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.137.0.17 netmask 255.255.255.255 broadcast 10.255.255.255
inet6 fe80::216:3eff:fe5e:6c00 prefixlen 64 scopeid 0x20<link>
ether 00:16:3e:5e:6c:00 txqueuelen 1000 (Ethernet)
RX packets 555370 bytes 785064402 (748.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 208464 bytes 13235820 (12.6 MiB)
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 1000 (Local Loopback)
RX packets 107 bytes 227427 (222.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 107 bytes 227427 (222.0 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
veth0271483: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::183d:fdff:fe2b:f8ce prefixlen 64 scopeid 0x20<link>
ether 1a:3d:fd:2b:f8:ce txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 16 bytes 1379 (1.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
veth25193ce: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::603c:beff:fe87:6283 prefixlen 64 scopeid 0x20<link>
ether 62:3c:be:87:62:83 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 16 bytes 1379 (1.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vetha36c6d7: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::789d:60ff:fe15:8eb4 prefixlen 64 scopeid 0x20<link>
ether 7a:9d:60:15:8e:b4 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 16 bytes 1379 (1.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethc039300: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::a0a9:4eff:fe3d:8338 prefixlen 64 scopeid 0x20<link>
ether a2:a9:4e:3d:83:38 txqueuelen 0 (Ethernet)
RX packets 5 bytes 513 (513.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 11 bytes 866 (866.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethe777af4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::c07e:11ff:fe1a:9f6b prefixlen 64 scopeid 0x20<link>
ether c2:7e:11:1a:9f:6b txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 16 bytes 1379 (1.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
my ifconfig output on the docker container
eth0 Link encap:Ethernet HWaddr 02:42:AC:12:00:05
inet addr:172.18.0.5 Bcast:172.18.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1260 (1.2 KiB) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
My netstat -ltn from my host machine
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:10137 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:6942 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:5902 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:63342 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:20080 0.0.0.0:* LISTEN
tcp6 0 0 ::1:631 :::* LISTEN
tcp6 0 0 :::9000 :::* LISTEN
tcp6 0 0 :::3306 :::* LISTEN
tcp6 0 0 :::80 :::* LISTEN
tcp6 0 0 :::81 :::* LISTEN
tcp6 0 0 :::8082 :::* LISTEN
My netstat -ltn from the docker container
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.11:34183 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN
When using xdebug.remote_connect_back=1 I get
I: Checking remote connect back address.
I: Checking header 'HTTP_X_FORWARDED_FOR'.
I: Checking header 'REMOTE_ADDR'.
I: Remote address found, connecting to 172.18.0.1:5902.
E: Time-out connecting to client (Waited: 200 ms). :-(
Log closed at 2019-10-31 09:32:55
Also when I run netstat -nr | grep '^0\.0\.0\.0' | awk '{print $2}' within the docker container I get 172.18.0.1
Thus I would conclude that xdebug.remote_host = 172.18.0.1
But when I use the IP added by docker to the container's /etc/hosts (the IP changes to 172.17-18.0.1-4, right now it's 172.18.0.4) and look into the Xdebug logs I get
W: Creating socket for 'host.docker.internal:5902', poll success, but error: Operation in progress (29).
E: Could not connect to client. :-(
So since these IPs were somewhat inconclusive, I simply tried every IP that I encountered on my way as my xdebug.remot_host for the docker container. And I either one of the above failure logs from xdebug
Additionally the results of telnet and ping:
telnet 172.18.0.1 5902:
telnet: can't connect to remote host (172.18.0.1): Operation timed out
bash-4.4# telnet 172.18.0.4
telnet: can't connect to remote host (172.18.0.4): Connection refused
bash-4.4# ping 172.18.0.1:
5 packets transmitted, 0 packets received, 100% packet loss
bash-4.4# ping 172.18.0.4
PING 172.18.0.4 (172.18.0.4): 56 data bytes
5 packets transmitted, 5 packets received, 0% packet loss
Conclusion: I'm lost. I basically tried every possible IP address. Please help me understand what I need to do in order to debug my PHP code. Thanks!
If you are on a local machine and have a docker container there it's enough to set xdebug.remote_host=host.docker.internal and add host.docker.internal to /etc/hosts.
I do this in the entry sh script: netstat -nr | grep '^0\.0\.0\.0' | awk '{print $2" host.docker.internal"}' >> /etc/hosts
How to check that data is sent:
you can enable xdebug.remote_log=/var/log/xdebug_remote_log.log
I prefer to listen to ports on a host nc -l 5902 or nc -l 0.0.0.0 5902. Send text via telnet from docker telnet host.docker.internal 5902 and type something. You should see it in nc on the host
If your docker is on a remote host then you have to allow ssh GatewayPorts yes to listen 0.0.0.0:5904 or forward traffic to 127.0.0.0:5905. Look here
on the remote host run once: socat TCP-LISTEN:5904,fork TCP:127.0.0.1:5905
to get response on the local machine run: ssh -R 5905:localhost:5904
You can check the connection with nc and telnet.
TLDR: Specify in your docker container xdebug.remote_connect_back=0 and xdebug.remote_host=172.17.0.1 and it should work. Remember: Xdebug needs to connect from your webserver (inside Docker) to your IDE listening on port 9000.
You didn't show Docker's ifconfig, so I might have gotten the IP address above wrong. But, the important thing is that the IP address you specify in xdebug.remote_host is the one where your IDE listens. And that IP address needs to be reachable from Docker. You can test that by running "telnet IpAddress 9000" from within your Docker container, to see whether you got the right IP addess of your host.
But some other points:
On your docker container, your netstat shows:
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN
Do you have a DBGp Proxy running there? You shouldn't need to do that. The proxy only makes things more complicated for your situation.
I see in your host's netstat:
tcp6 0 0 :::9000 :::* LISTEN
Are you using an IDE that only listens on IPv6? You might want to see if you can change that to run with IPv4.

Set eth0 as DHCP in raspberry pi

I want to set eth0 of RPI (Raspbian Stretch) to be DHCP, my goal is that when I will connect any device that communicates using TCP/IP protocol, that device will receive an IP address.
I have found many guides that all lead to making eth0 ip address static, which is not my intention.
Currently a device is connected through eth0 , ifconfig says it has some IP but pinging the hostname of the device gets no reply. wlan0 is connected via wifi.
Here is some info :
pi#raspberrypi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.31.197 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::ad5a:8219:4c27:b59b prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:f3:f2:87 txqueuelen 1000 (Ethernet)
RX packets 81 bytes 26568 (25.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 46 bytes 10544 (10.2 KiB)
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 1000 (Local Loopback)
RX packets 31 bytes 3472 (3.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 31 bytes 3472 (3.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.0.71 netmask 255.255.255.0 broadcast 192.168.0.255
inet6 fd01::60ff:8818:5965:dc58 prefixlen 64 scopeid 0x0<global>
inet6 fe80::473d:110e:5474:8000 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:a6:a7:d2 txqueuelen 1000 (Ethernet)
RX packets 955 bytes 74427 (72.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 184 bytes 22096 (21.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
pi#raspberrypi:~ $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
Any advice to how to achieve my goal will be happily received.
Have you tried this: https://wiki.debian.org/NetworkConfiguration#Using_DHCP_to_automatically_configure_the_interface
i.e. just add this to /etc/network/interfaces:
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
if you're really pedantic you could create a file like /etc/network/interfaces.d/eth0-dhcp and paste these lines into it - the end result will be the same.
If you simply want to connect two devices (without routing/forwarding/etc), i.e. for a standalone test network, this should work:
Figure out what IP range you want to use, and what IP you want your
DHCP server to have (let's call it IP_DHCP)
Install isc-dhcp server
Set static IP address for eth0 (e.g. set it to the IP_DHCP you
chose earlier)
Configure /etc/dhcp/dhcpd.conf for the desired network range (man
dhcpd has a decent reference), make it authoritative (unless there
are other DHCP servers).
Run service isc-dhcpd-server start
Example of a configuration:
sudo apt-get install isc-dhcp-server
sudo nano /etc/conf/dhcpd.conf
Uncomment #authoritative to make it authoritative
Add along the following lines(customize based on what you decided in step 1), where routers is IP_DHCP:
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.1 10.0.0.100;
option subnet-mask 255.255.255.0;
option broadcast-address 10.0.0.255;
option routers 10.0.0.1;
}
Save buffer and close
sudo service isc-dhcpd-server start
Good luck!
P.S. if you are getting connect:network not found issues, then you likely have an issue in your routing tables (route) setup.
Something along the lines of
sudo route add default gw 10.0.0.1
where the IP address is your eth0 will likely allow communication.
NetWork Manager (nmcli) might be running on the device and has been configured to work with a static IP.
The following commands can help you check if your device is managed by nmcli:
nmcli d
nmcli con show
Run the following command and replace 'Wired connection 1' with the name of your connection.
nmcli con show 'Wired connection 1' | grep 'ipv4.method'
ipv4.method will show "auto" if set to DHCP or "manual" if set to static.
http://www.intellamech.com/RaspberryPi-projects/rpi_nmcli.html

Issues with Network Configuration to run a lwIP Echo Server on Linux

I am interested in programming with the lwIP IP Stack. In order to experiment, I've been trying to run the echo server which is included in the example applications. However, I am having difficulty setting up the internal networking configuration to communicate with the server, and I'd like to find what I'm doing wrong. Here's what I've done so far.
So first, I'm successfully starting the echo server using sudo and setting it to listen on 172.16.0.2 with 172.16.0.1 as gateway:
>>sudo ./echop -i 172.16.0.2 -m 255.255.0.0 -g 172.16.0.1
[sudo] password for user:
Host at 172.16.0.2 mask 255.255.0.0 gateway 172.16.0.1
TCP/IP initialized.
SNMP private MIB start, detecting sensors.
Applications started.
The program successfully enables the tap0 interface and starts the gateway:
>>ifconfig
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.15 netmask 255.255.255.0 broadcast 10.0.2.255
inet6 fe80::a00:27ff:fe4c:f329 prefixlen 64 scopeid 0x20<link>
ether 08:00:27:4c:f3:29 txqueuelen 1000 (Ethernet)
RX packets 10860 bytes 10827195 (10.8 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8571 bytes 904790 (904.7 KB)
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 1 (Local Loopback)
RX packets 811 bytes 93113 (93.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 811 bytes 93113 (93.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 172.16.0.1 netmask 255.255.0.0 broadcast 172.16.255.255
inet6 fe80::49f:4fff:fe82:d8fb prefixlen 64 scopeid 0x20<link>
ether 06:9f:4f:82:d8:fb txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 129 bytes 14904 (14.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I can successfully ping the gateway:
>>ping -c 5 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=0.076 ms
64 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=0.097 ms
64 bytes from 172.16.0.1: icmp_seq=4 ttl=64 time=0.037 ms
64 bytes from 172.16.0.1: icmp_seq=5 ttl=64 time=0.039 ms
--- 172.16.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4086ms
rtt min/avg/max/mdev = 0.028/0.055/0.097/0.027 ms
However if I try to reach the actual echo server, the route is not found:
>>ping -c 5 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
From 172.16.0.1 icmp_seq=1 Destination Host Unreachable
From 172.16.0.1 icmp_seq=2 Destination Host Unreachable
From 172.16.0.1 icmp_seq=3 Destination Host Unreachable
From 172.16.0.1 icmp_seq=4 Destination Host Unreachable
From 172.16.0.1 icmp_seq=5 Destination Host Unreachable
It does seems as if the route has been added if I list the current routes:
>>route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 100 0 0 enp0s3
10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 tap0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tap0
To make sure, I've tried to add an explicit route to the echo server, but the route still cannot be found:
>>sudo route add 172.16.0.2 dev tap0 gw 172.16.0.1
>>route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 100 0 0 enp0s3
10.0.2.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 tap0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 tap0
172.16.0.2 172.16.0.1 255.255.255.255 UGH 0 0 0 tap0
>>ping -c 5 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
From 172.16.0.1 icmp_seq=1 Destination Host Unreachable
From 172.16.0.1 icmp_seq=2 Destination Host Unreachable
From 172.16.0.1 icmp_seq=3 Destination Host Unreachable
From 172.16.0.1 icmp_seq=4 Destination Host Unreachable
From 172.16.0.1 icmp_seq=5 Destination Host Unreachable
--- 172.16.0.2 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4094ms
pipe 4
I would like help on configuring my interfaces/routes so that I can experiment with the lwIP (1.30) echo server, which is configured on port 7. Using version 1.30 as I'm using it with older devices.
OS info:
>>uname -a
Linux ReSyst 4.8.0-59-generic #64-Ubuntu SMP Thu Jun 29 19:38:34 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Thanks

How to connect USB wireless interface to a Docker container on Mac OS X?

I have a Linux Docker container which needs a wireless interface to work. On Linux (running it at a Linux host) I have no problem with that.
Running Docker container with arguments --privileged and --net=host I can access the host wireless interfaces, and I can manage them without any issue. The problem is when I run the same Linux Docker container on a Mac OS X host. I can't see the wireless interface inside the Docker container.
This is the output of ifconfig at Mac OS X v10.12 (Sierra) host:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=b<RXCSUM,TXCSUM,VLAN_HWTAGGING>
ether 00:0c:29:fe:78:07
inet6 fe80::8ff:62ac:e141:5aa9%en0 prefixlen 64 secured scopeid 0x4
inet 192.168.0.153 netmask 0xffffff00 broadcast 192.168.0.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex>)
status: active
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:c0:ca:5a:00:f2
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (<unknown type>)
status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
inet6 fe80::7a12:53b9:61c3:3c7%utun0 prefixlen 64 scopeid 0x6
nd6 options=201<PERFORMNUD,DAD>
The "en1" interface is the wireless usb device. Now the ifconfig output inside the container run with the parameters described:
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
ether 02:42:67:b5:aa:36 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
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.65.2 netmask 255.255.255.248 broadcast 192.168.65.7
inet6 fe80::b564:23a5:1418:8f2a prefixlen 64 scopeid 0x20<link>
ether c0:ff:ee:c0:ff:ee txqueuelen 1000 (Ethernet)
RX packets 22 bytes 2418 (2.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 33 bytes 3100 (3.0 KiB)
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 1 (Local Loopback)
RX packets 3 bytes 54 (54.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3 bytes 54 (54.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
I guess the container's eth0 is "mapped" to the en0 interface and is working, and I have Internet access inside the container. But, why am I not seeing en1 mapped to any device on container?
How do I achieve this on Mac OS X? If I remove the --net=host from the command line to launch Docker, the interface docker0 disappears inside the container... is the difference, but wireless interface doesn't appear in any case.

why is wlan0 interface visible from xterm but not from running program?

I'm running on an embedded linux buildroot OS and have installed a custom WiFi driver which starts in "wireless extensions mode". I can see that driver from an xterm window (whether I'm running as root or a normal user) with the following commands:
cat /proc/net/dev
cat /proc/net/wireless
ifconfig -a
The wlan0 interface looks like this when printed via ifconfig -a:
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 169.254.185.103 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::24b:5bfc:8a9e:b148 prefixlen 64 scopeid 0x20<link>
ether 00:23:a7:40:22:f1 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 40 overruns 0 carrier 0 collisions 0
But, when I run from my application, I can see all the interfaces on my system EXCEPT wlan0. wlan0 is completely filtered out when viewed by my application. I've tried these things from code within my application:
system("cat /proc/net/dev");
system("cat /proc/net/wireless");
system("ifconfig -a");
FILE* fopen("/proc/net/dev", "r"); fgets(...
I've run my application as both root and as a normal user and see the same results. I've changed the ownership of my program to root:root and installed it as root with the s bit and that didn't help. So, it doesn't seem to be a security issue...?
Any ideas?

Resources