Folks,
I have a Ubuntu machine connected to the Internet through wireless (wlan0), and I am sharing this connection to my Ethernet port (eth1). Then, I have this Ethernet port connected to a switch, and two windows machine connected to the same switch. So the two windows machines have a static IP from the LAN generated from the route generated from wlan0 to eth1, so that I can communicate with all 3 computers at the same time (this works since I can ssh and remote access all 3 computers).
My problem is that I when I run my LCM program (with TTL = 1) on my windows PC, I cannot receive the messages on my Ubuntu machine (meaning that the message should pass through the Ethernet). How can I make sure the UDP messages can be routed back into my Ubuntu machine from the windows machines while the wireless network is running?
This was my solution to the problem (right there on the LCM website):
sudo ifconfig eth1 multicast
sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1
Now all my UDP packets are routed only through eth1. And my shared network (from wlan0) is still intact after this. So all computers have internet at the same time. So great!
Related
I have a Raspberry Pi 3B+ which I have to admit has only recently shown this problem.
I booted up the Pi normally and tried to SSH into it since I have a static IP set for it. This was unsuccesful, so I connected my monitor and keyboard, and run ifconfig to see the current IP address. After checking to see if my laptop is connected to the same WiFi network as the Pi, I tried SSH-ing into the Pi with no success: sh: connect to host xxx.xxx.xxx.xxx port 22: Connection timed out or Reply from xxx.xxx.xxx.xxx: Destination host unreachable..
My Pi has the SSH interface option enabled and can use it's internet connectivity as I could PING www.google.com with success and can also run sudo apt update && sudo apt upgrade.
I tried rebooting thinking this is a power issue, using a different socket / charger, restarting dhcpcd.service. No success, so I got curious.
I have connected a WiFi dongle onto the Pi, enabling the wlan1 interface which immediately discovered and connected to the WiFi network (it is an open network) and was assigned an IP. SSH=ing into this IP was successful. How can I fix my wlan0 interface? I do not want to rely on an external dongle. Connecting an ethernet cable and SSH-ing using the eth0 interface works as well.
I ended up reflashing my RaspberryPi with a fresh install
I know VirtualBox can configure bridge adpater and open promisc options, it will get all packets that the host machine gets.
But if I want do some specific test, like run DPDK in VirtualBox. How can I replay pcap file to virtual machine's nic so the DPDK program can receive those packets?
In KVM-QEMU each virtual (not SRIOV/VF) port of quest has an equivalent port representation on host os. This is same interface you add to host Bridge.
To identify the port representation, use brctl show to identify the host NIC.
To send packets to interface, use tcpreplay/pktgen/ping/arping.
To observe packets on the host for traffic coming from guest port, tcpdump -eni [interface on host] -Q in
When VPN is active, all the traffic seems to be tunneled through csctun0.
Using a VirtualBox I am able to set up a "network bridge" to eth0, which seems to completely ignore the manipulations made by Cisco's software. The VirtualBox directly connects to my local network and accesses local network devices and the internet directly.
I want to achieve the same with Docker containers, but the Docker's bridge seems to work differently.
What is necessary to let a Docker container bypass Cisco's tunnel like a VirtualBox does?
Edit:
As suggested by #NetworkMeister I tried to use "macvlan" and followed the instructions on http://hicu.be/docker-networking-macvlan-bridge-mode-configuration but fail when I trying to send pings to the local gateway:
# docker exec -ti container0 ping -c 4 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: Destination Host Unreachable
64 bytes from 10.0.0.1: Destination Host Unreachable
64 bytes from 10.0.0.1: Destination Host Unreachable
64 bytes from 10.0.0.1: Destination Host Unreachable
--- 10.0.0.1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss
Docker's default bridge network allows you to NAT your containers into the physical network.
To achieve what you know as "bridged network" from VirtualBox, use Pipework or, if you are cutting edge, you can try the docker macvlan driver which is, for now, experimental.
One (ugly) solution would be to run your docker container with --net=host. That way your docker container doesn't have a network interface and has the same network access as any of your physical machine, it should work.
Running a Centos 5.11 machine with two network cards.
One is facing the internal network (private IP), the other the Internet (public IP).
Because we had some issues lately with it (ARP collision - but that's not the point here!), I started verifying its config. And I find out the broadcast set for the public IP is wrong.
IP is xxx.xxx.xxx.25
Subnet is 255.255.255.240
So basically we should have:
Network xxx.xxx.xxx.16
First IP xxx.xxx.xxx.17
Last IP xxx.xxx.xxx.30
Broadcast xxx.xxx.xxx.31
But the broadcast is automatically set to last host xxx.xxx.xxx.30
If I change it using command line, it is reseted back to the same IP once I do a service network restart...
I had to edit /etc/sysconfig/network-scripts/ifcfg-eth0 for the broadcast to stick to what I wanted.
How do I set an IP address for a TUN interface on OSX? I cannot figure out how to set up an ip address for my interface without specifying a destination IP. I don't want to do that- I'm want to more or less build a tunnel to an arbitrary address at a later point in time. Prior questions which are unhelpful:
There's a question that has an unclear answer, so I tried following the reference.
This question sets a point to point ip address for a tun device, so it has a destination, which is exactly what I don't want.
On the page for osxtuntap it says:
ifconfig tap0 10.1.2.3 up
I cannot make this work on OSX 10.6 for a TUN interface:
$ sudo ifconfig tun0 10.1.2.3 up
ifconfig: ioctl (SIOCAIFADDR): Destination address required
Adding a netmask doesn't help- OSX seems to demand a destination address:
$ ifconfig tun0 10.0.0.1/24 netmask 255.255.255.0
ifconfig: ioctl (SIOCAIFADDR): Destination address required
For linux, I get how it works. According to this page, you open() the interface, and use the ip command, and do this, and I've done this before with zero issues:
$ ip link set tun0 up
$ ip addr add 10.0.0.1/24 dev tun0
All I want to do is the same thing that I can do in linux.
EDIT:
I'm writing a little UDP tunnel app. Like so:
tun1 -> udp app #1 -> udp tunnel -> udp app #2 -> tun2
If the udp apps are on different computers (let's say local and remote), I'd like to associate their respective tun devices with an ip address, so I can send a packet from local to remote via the tunnel by sending the packet to the ip address of the tun device on the remove machine.
To borrow more from the linux tutorial, the author sets up a tun device on local and remote, associates ips, and runs a simple tunneling app, and then pings the other end of the tunnel:
[remote]# ip link set tun3 up
[remote]# ip addr add 192.168.0.2/24 dev tun3
[remote]$ ./simpletun -i tun3 -s
# server blocks waiting for the client to connect
[local]# ip link set tun11 up
[local]# ip addr add 192.168.0.1/24 dev tun11
[local]$ ./simpletun -i tun11 -c 10.2.3.4
# nothing happens, but the peers are now connected
[local]$ ping 192.168.0.2
By default, tun devices operate in the layer 3 mode, aka point to point. You're asking for layer 2 mode which more closely resembles a generic Ethernet device. Linux calls these tap devices. In OpenBSD you can switch a tun device into layer 2 mode with "ifconfig tun0 link0". The Macintosh tuntaposx driver mimics Linux' device schism; open a tap device instead.
You might want to review https://community.openvpn.net/openvpn/wiki/BridgingAndRouting to determine if you really want tap devices. They add a little overhead. If you just need two boxes to pass IP packets between each other and no bridging or broadcasting to a larger subnet, point to point should be sufficient.
For example, if you have two machines, one we label "local" with a LAN IP address like 192.168.0.12 and another we label "remote" with a LAN IP address like 192.168.1.14, you can assign tunnel IP addresses thusly:
ifconfig tun0 inet 10.0.0.1 10.0.0.2 up
on the local system, and:
ifconfig tun0 inet 10.0.0.2 10.0.0.1 up
on the remote system. Note the reversed perspective on the remote machine. Do not set your point to point addresses to anything on an existing subnet; it will not route properly.
I can't stress this enough: read and re-read the manual pages ("man ifconfig" and "man tun", probably others) until they make sense. My ifconfig examples above may differ slightly from your operating system.
And for another perspective you might look into GRE tunnels as their functionality mirrors what you describe for your program. However, GRE is likely not viable in today's TCP-centric networks nor is it a good idea due to major security issues.
If your goal is to circumvent an overbearing firewall, be aware that many such firewalls block UDP (and especially GRE) packets. In such a case, try SSH interface tunneling to set up tun/tap interfaces and forward packets. You get encryption and optionally compression as well. :)