Send UDP packets through no IP assigned bridge interface in Ubuntu Linux - linux

I have two network interfaces (e.g. eth0 and eth1) configured as two ends of a bridge in Ubuntu Linux 14.04. They are not assigned with any IP addresses. eth0 is physically connected to a subnet. I want to send UDP packets through eth0 to a subnet connected machine. I create a UDP socket and check that it can successfully bind to eth0 (i.e. setsockopt(socket, SOL_SOCKET, SO_BINDTODEVICE, eth0, strlen(eth0)), and executing sendto() reports success as well. However, the designated target machine cannot receive anything from eth0!!
Is there any Ubuntu tools/commands to trace where the UDP packets go (actually, I did try to use Wireshark. But, Wireshark cannot detect any network interface to capture!)?
And, is there any workarounds, under the situation that eth0 and eth1 must be set as a interconnected bridge with no IP addresses, to make use of eth0 to send UDP packets to other machine with designated IP address and port?

Related

Does routing affect a socket with a bound source address?

Let's say I have two network interfaces:
eth0 with address 10.0.0.1
eth1 with address 192.168.0.1
Using route or ip route add I have set it to route:
All addresses to eth0
1.2.3.4 only to eth1
So packets to 1.2.3.4 should be routed to eth1, and everything else to eth0.
I then create a UDP socket and use bind() to set its local address to 192.168.0.1. Then I send a packet to 1.2.3.4.
Will it be be sent over eth1 per the routing table or eth0 because it is bound to that IP address? I tried, and it seems to be sent on eth1.
Is there a way I can force a socket to use eth0, which has a valid route to the destination, but not the most specific rule? I know about SO_BINDTODEVICE, but prefer to avoid using interface names in C code.
For sockets if you want the the Kernel and its routing table to pick the best interface for you using any available port you don't have to call bind() before sending datagram socket.
If you do bind a socket, it will be bound to a network device with that specific IP address. But does it make sense if packet can't reach destination address from that network device?

Linux NIC driver: what's the UDP packet from 0.0.0.0 to 255.255.255.255?

I am playing with rhel6 and rhel 7 NIC driver.
The interesting thing is, when I do "ifup eth0" (eth0 is the NIC associated with my driver), I found Linux will try to send two special UDP packets, with source address of 0.0.0.0 and destination address of 255.255.255.255.
Can someone help me to understand what's the purpose of those UDP packets?
This is a DHCP Discovery request. The interface is attempting to acquire an IP address from your DHCP server.

Linux sends a packet from a source IP of one interface but a source MAC of another

My Linux (Debian) server has eth0 and eth1, and both are on the same subnet.
It receives packets from both interfaces, but it only replies from eth0.
Packets that are sent to eth1 are replied from eth0, and the reply has eth0's src mac and eth1's src IP.
I verified this by sending a ping to eth1 while running tcpdump on the Linux server.
This is a problem because:
Since no packets are sent with a source mac of eth1 (with the exception of the initial arp), the switch forgets the eth1 mac. Then, every packet with the destination mac of eth1 that is received by the switch is broadcasted across the network, flooding it which makes us sad.
I want:
My Linux server to send packets out from both eth0 and eth1. I think the nicest solution is that for each packet we get, we reply from the same interface. Another way to put it is that I want to bind each interface to its IP and MAC - so that it will only send packets from these addresses.
More details:
My Linux server is an ISCSI Target communicating with an ESX which is an ISCSI Initiator - though a Cisco switch. The switch forgets MACs after 5 minutes, and the ESX probably remembers them for 20 minutes (as discussed here and here). So while the ESX remembers the mac of the Linux, the ESX keeps sending ISCSI requests which flood the network, while my server sends ISCSI replies through only one of the interfaces.
This isn't what you asked for, but if you just set up a cron job on the box that did
ping -c 1 -I eth1 <address of eth1's default gateway>
every minute, then you would have at least one packet per minute leaving eth1 with eth1's MAC address on it. -I tells ping to bind to a specific interface, so it won't use eth0 even if that's the preferred route.

Send all traffic to network interface and receive from other

i'm triying to imagine how to do:
(with Linux Debian based distro)
I have PC with 4 NIC:
eth0 = Internet Access (connect to router WAN)
eth1 = Local lan
eth2 = OUT NIC
eth3 = IN NIC
I need to send all traffic from eth1 (local lan) to eth2, receive the same traffic from eth3 and route to eth0.
The idea is send all eth1 traffic to external device over eth2, the external device inspect the packets and send to PC again on eth3, then my PC Linux route traffic to eth0
Is posible to do that ?
You're running linux on a PC? We need to know the version first off. Second you are looking into IProutes if you want to redirect traffic from one NIC to another.

How to route TCP/IP responses through a different interface?

I have two machines each with two valid network interfaces, an Ethernet interface eth0 and a tun/tap interface gr0. The goal is to start a TCP connection on machine A using interface gr0 but then have the responses (ACKs, etc) from machine B come back over the Ethernet interface, eth0. So, machine A sends out a SYN on gr0 and machine B receives the SYN on its own gr0 but then sends its SYN/ACK back through eth0. The tun/tap device is a GNU Radio wireless link and we just want the responses to come through the Ethernet.
What's the easiest way to accomplish this? I need to research more on TCP/IP, but I was initially thinking that source-spoofing outgoing packets would tell the receiver to respond to the spoofed address (which should get routed to eth0). This would involve routing the IPs from the tun/tap interfaces through gr0 and leave the other traffic to eth0.
We are using Linux and a Python solution would be preferable.
Thanks for looking!
You could add an additional address to the lo interface on each system and use these new addresses as the TCP connection endpoints. You can then use static routes to direct which path each machine takes to get to the other machine's lo address.
For example:
Machine A:
ip addr add 1.1.1.1/32 dev lo
ip route add 2.2.2.2/32 dev eth0 via <eth0 default gateway>
Machine B:
ip addr add 2.2.2.2/32 dev lo
ip route add 1.1.1.1/32 dev gr0
Then bind to 1.1.1.1 on machine A and connect to 2.2.2.2.
You may be interested in enabling logging of martian packets net.ipv4.conf.all.log_martians, and disable reverse path filtering net.ipv4.conf.<interface>.rp_filter on the affected interfaces.
This sysctl vars are accesible via the sysctl utility and/or the /proc filesystem.

Resources