I have a tun adapter (OS X) which looks like this:
tun11: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.12.0.2 --> 10.12.0.1 netmask 0xff000000
open (pid 4004)
I send a UDP packet to it:
echo "lol" | nc -4u 10.12.0.1 8000
and able to see it with tcpdump:
➜ build git:(master) ✗ sudo tcpdump -i tun11 -vv
tcpdump: listening on tun11, link-type NULL (BSD loopback), capture size 262144 bytes
14:39:16.669055 IP (tos 0x0, ttl 64, id 21714, offset 0, flags [none], proto UDP (17), length 32)
10.12.0.2.55707 > 10.12.0.1.irdmi: [udp sum ok] UDP, length 4
However I do not see anything when I use capture filter:
➜ build git:(master) ✗ sudo tcpdump -i tun11 udp -vv
tcpdump: listening on tun11, link-type NULL (BSD loopback), capture size 262144 bytes
Same syntax works fine with ethernet adapter:
➜ build git:(master) ✗ sudo tcpdump -i en0 udp -vv
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:42:15.010329 IP (tos 0x0, ttl 128, id 7539, offset 0, flags [none], proto UDP (17), length 291)
xxxx.54915 > 10.64.3.255.54915: [udp sum ok] UDP, length 263
I checked man pcap-filter and found an interesting sentence related to capture filters:
Note that this primitive does not chase the protocol header chain.
Is it related to my problem? Anyway, why capture filters (at least protocol part) do not work for loopback adapters and is there way to make them work?
Addition
Interesting, it works with tun device created by OpenVPN. But I do not understand what is the difference.
tun11: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.12.0.2 --> 10.12.0.1 netmask 0xff000000
open (pid 5792)
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 198.18.1.214 --> 198.18.1.213 netmask 0xffffffff
inet6 xxxx%utun0 prefixlen 64 optimistic scopeid 0xa
inet6 xxxx::1074 prefixlen 64 tentative
nd6 options=1<PERFORMNUD>
Related
I am trying to add a static ip address on raspberry-pi and can't get it working...
ifconfig on pi
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.68.104 netmask 255.255.255.0 broadcast 192.168.68.255
inet6 fe80::1e8e:49a0:5bf:ad41 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:c4:41:05 txqueuelen 1000 (Ethernet)
RX packets 210 bytes 49138 (47.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 189 bytes 28376 (27.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
gateway
192.168.xx.x
/etc/resolv.conf:
nameserver 62.179.104.xxx
nameserver 213.46.228.xxx
dhcpcd.conf settings:
interface wlan0
static ip_address=192.168.68.68/20
static routers=192.168.xx.x
static domain_name_servers=62.179.104.xxx 213.46.228.xxx
I have also tried static ip_address=192.168.68.68/24
reboot pi and hostname -I it still gives me the origin ip: 192.168.68.104
What am I doing wrong here? or Is there another way to set a static ip on raspberry pi?
First of all make sure the dhcpcd service is enabled and running:
sudo service dhcpcd status
If that is not the case:
sudo service dhcpcd start
sudo systemctl enable dhcpcd
Now you can edit the dhcpcd config (like you already did)
sudo nano /etc/dhcpcd.conf
If you have a network cable use: eth0 and on wifi: wlan (not wlan0)
interface eth0
static ip_address=192.168.0.4/24
static routers=192.168.0.1
static domain_name_servers=192.168.0.1
Configure this like you need.
After this reboot.
Good luck!
I have a VM running in Fusion that I want to hit by routing a specific endpoint address through the virtual ethernet interface (multicast DNS, in particular). First I was sending packets and inspecting with Wireshark noticing that nothing was getting through. Then I thought to check the routing table
$ netstat -rn | grep vmnet8
Destination Gateway Flags Refs Use Netif Expire
172.16.12/24 link#29 UC 2 0 vmnet8 !
172.16.12.255 ff:ff:ff:ff:ff:ff UHLWbI 0 35 vmnet8 !
But unlike other interfaces,
Destination Gateway Flags Refs Use Netif Expire
224.0.0.251 a1:10:5e:50:0:fb UHmLWI 0 732 en0
224.0.0.251 a1:10:5e:50:0:fb UHmLWI 0 0 en8
There was no multicast route. So I added it:
$ sudo route add -host 224.0.0.251 -interface vmnet8
add host 224.0.0.251: gateway vmnet8
And so it was true
$ netstat -rn | grep vmnet8
Destination Gateway Flags Refs Use Netif Expire
172.16.12/24 link#29 UC 2 0 vmnet8 !
172.16.12.255 ff:ff:ff:ff:ff:ff UHLWbI 0 35 vmnet8 !
224.0.0.251 a1:10:5e:50:0:fb UHmLS 0 13 vmnet8
I was also sure to check the interface flags to ensure it had been configured to support multicast
$ ifconfig vmnet8
vmnet8: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
ether 00:70:61:c0:11:08
inet 172.16.12.1 netmask 0xffffff00 broadcast 172.16.12.255
Still, no multicast packets I send are getting through. I noted that the other interface's multicast route have different flags than the default ones given to my added route. Namely UHmLWI vs UHmLS. The differences I can see are insignificant. From man netstat:
I RTF_IFSCOPE Route is associated with an interface scope
S RTF_STATIC Manually added
W RTF_WASCLONED Route was generated as a result of cloning
Then again, I'm not claiming to be a routing expert. Perhaps a multicast route entry must be made somehow differently?
You'll note that the Use column is non-zero, despite no packets showing in a sniffer.
I am clearing /etc/resolv.conf to disable network :
sudo mv /etc/resolv.conf /etc/resolv_backup.conf
sudo touch /etc/resolv.conf
Then to enable network:
sudo mv /etc/resolv_backup.conf /etc/resolv.conf
However the resource is busy and I cannot execute these commands.
I want to disable internet from within container and not using:
docker network disconnect [OPTIONS] NETWORK CONTAINER
which does this from server on which container is deployed.
I am using Alpine.
From inside of a container, you are typically forbidden from changing the state of the network:
$ docker run -it --rm alpine:latest /bin/sh
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
929: eth0#if930: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
/ # ip link set eth0 down
ip: ioctl 0x8914 failed: Operation not permitted
This is intentional, for security, to prevent applications from escaping the container sandbox. If you do not need security for your containers (and therefore something I recommend against doing), you can run your container with additional network capabilities:
$ docker run -it --rm --cap-add NET_ADMIN alpine:latest /bin/sh
/ # netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 172.17.0.1 0.0.0.0 UG 0 0 0 eth0
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
/ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
933: eth0#if934: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
valid_lft forever preferred_lft forever
/ # ip link set eth0 down
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable
When you try to bring the network back up, you'll need to also setup the default route again to be able to connect to external networks:
/ # ip link set eth0 up
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: Network unreachable
/ # netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
/ # route add default gw 172.17.0.1
/ # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=58 time=12.518 ms
64 bytes from 8.8.8.8: seq=1 ttl=58 time=11.481 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 11.481/11.999/12.518 ms
First of all, clearing resolv.conf is not the proper way to disable network for your container. That just avoids name resolution, but you still can use IP connectivity.
To disable the network you should use the proper script depending if you are using systemd or sysV. Something similar to this should work (it depends on your distro):
# /etc/init.d/networking stop
# systemctl stop networking
Hope this helps! :-)
This question already has answers here:
Given IP address and Netmask, how can I calculate the subnet range using bash?
(4 answers)
Closed 4 years ago.
I'm writing a bash function which adds ip routes such as the following:
ip route add table 128 to 192.168.1.0/24 dev eno1
To get the current netmask, I can do ip -f inet -o addr show dev eno1 which will give me a value such as 192.168.1.123/24, but this is not accepted by ip. The unmasked bits need to be zero, e.g. 192.168.1.0/24.
How do I most easily change the unmasked bits of the netmask to zero in bash?
As mentioned in the comments ipcalc or sipcalc will both do it for you.
e.g.
$ ipcalc 192.168.0.1/24
Address: 192.168.0.1 11000000.10101000.00000000. 00000001
Netmask: 255.255.255.0 = 24 11111111.11111111.11111111. 00000000
Wildcard: 0.0.0.255 00000000.00000000.00000000. 11111111
=>
Network: 192.168.0.0/24 11000000.10101000.00000000. 00000000
HostMin: 192.168.0.1 11000000.10101000.00000000. 00000001
HostMax: 192.168.0.254 11000000.10101000.00000000. 11111110
Broadcast: 192.168.0.255 11000000.10101000.00000000. 11111111
Hosts/Net: 254 Class C, Private Internet
or
$ sipcalc 192.168.0.1/24
-[ipv4 : 192.168.0.1/24] - 0
[CIDR]
Host address - 192.168.0.1
Host address (decimal) - 3232235521
Host address (hex) - C0A80001
Network address - 192.168.0.0
Network mask - 255.255.255.0
Network mask (bits) - 24
Network mask (hex) - FFFFFF00
Broadcast address - 192.168.0.255
Cisco wildcard - 0.0.0.255
Addresses in network - 256
Network range - 192.168.0.0 - 192.168.0.255
Usable range - 192.168.0.1 - 192.168.0.254
I've got a Linux VMware virtual machine (guest) configured with a NAT adapter on a 192.168.56.0 subnet. Its IP address is 192.168.56.128 and my Mac (host) got 192.168.56.1. Guest's default gateway is automatically set to 192.168.56.2 and is able to ping google. Host's Wi-Fi IP is 192.168.0.2,
I've configured my Wi-Fi router with following routing table to forward packets of 192.168.56.0 to 192.168.0.2 (my Mac)
pi#raspberrypi ~ $ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.4.1 0.0.0.0 UG 0 0 0 eth0
172.16.4.0 * 255.255.252.0 U 0 0 0 eth0
192.168.0.0 * 255.255.255.0 U 0 0 0 wlan0
192.168.56.0 192.168.0.2 255.255.255.255 UGH 0 0 0 wlan0
192.168.57.0 192.168.0.2 255.255.255.255 UGH 0 0 0 wlan0
But I'm unable to ping guest from any other device on the Wi-Fi network (192.168.0.0). So it's obvious that my Mac running OS X El Capitan is not forwarding the packets from 192.168.0.0 to 192.168.56.0
Not sure about your specific case. In my case I just had two ethernets on the same MacMini and one host being one of these ethernets. The only thing I had to do is sudo sysctl -w net.inet.ip.forwarding=1
https://roelant.net/2015/share-your-vpn-mac-el-capitan.html however noted another variable as well (sudo sysctl -w net.inet.ip.fw.enable=1) and went into a NAT scenario (which I did not need)