UDP Server Bound to a TAP interface fails to receive data #1
Comments
|
Please use -e on the command line. This provide more information. Also use ./configure --enable-thread-debug to configure.h though direct edits will work. I've fixed the -B bind to device in 2.1.4-rc dated July 24 so you should use that. It seems to work with a 0.0.0.0 address as well a specified one. Then append % for the bind to device. Not sure how to test the tap interfaces. Can you explain further the setup? |
|
Thanks, I will test it out. The TAP device is created using the net-setup script that I attached to the discussion on the SourceForge project. It creates 2 TAP interfaces as zeth0 and zeth1 with routing. My application is a radio simulator and bridges packets received from the wired interface as zeth0 to zeth1. So I have iperf client driving the wired side, and want Iperf server on the wireless side. This binding was not working. If it works for me, I think you can say that Iperf2 will work in a network emulation (as opposed to simulation) environment, with multiple instances of an application running, with presumably multiple TAP interfaces created to represent virtual Ethernet interfaces. That is sort of a big win for Iperf - to support that type of environment. I can send you my binary application which runs under Ubuntu and CentOS 64-bit to test out along with the script if this does not work for me. It is a bridge application at the moment, packets received over zeth0 get transmitted out of zeth1, but with the IP header content different such as the IPs and MACs to match the convention of the zeth1 network. I will be back in touch once I get a chance to test things out, probably Sunday sometime. |
|
A Tap interface is a virtual Layer 2 Ethernet interface created as an entry point for a network stack. In this case, it is created on the LInux host device via the attached script Here you run "net-setup.sh start", then use ifconfig to verify the existence of the virtual Ethernet interfaces zeth0 and zeth1, as well as look at the routing established to the 2 interfaces. A TAP interface is a layer 2 interface that includes a MAC address, and behaves similar to a real Ethernet interface such as eth0 and eth1. A closely related cousin is a TUN interface, which does not include Layer 2 routing. https://www.kernel.org/doc/Documentation/networking/tuntap.txt |
|
I can run the net-setup.sh start script. What iperf commands are you using to test this? How are these packets actually routed? [root@ryzen3950 Downloads]# brctl show [root@ryzen3950 Downloads]# route [root@ryzen3950 Downloads]# ip route show |
|
Thanks for the response Robert. I added "ifconfig zeth0 up" and "ifconfig zeth1 up" to the setup scripts. Attached is the revision. I am also attaching the radio simulator application, zephyr.exe, which is a Linux binary that should run in a terminal. Iperf Commands: Transmitter: iperf -c 192.0.1.1 -u -i1 -b5M -l188 -p49169 -t5 Receiver: iperf -e -s -u -B0.0.0.0%zeth1 -p49169 The virtual TAP interfaces zeth0 and zeth1 are the virtual Ethernet interfaces of interest. The interface zeth1 shows as RX packets the count of packets received by the interface. IPerf receiver output |
|
Good reference on TUN/TAP interfaces. Here I am assuming that a UDP socket can be opened for read and write on the existing TAP interface. I have done so with a raw socket in previous work, so I assume a standard UDP socket will work as well. https://backreference.org/2010/03/26/tuntap-interface-tutorial/ The attached application shows a UDP socket on a TUN/TAP interfaces, so it seems like it should work. |
|
Can you show the packets going out? You don't need the routing table if you specify the output interface. I don't see any packets being sent. Also, the linkdown state is still set. [root@ryzen3950 rjmcmahon]# tcpdump -i zeth0 iperf -c 138.0.0.254%zeth0 -u -i1 -b5M -l188 -p49169 -t5 -e -B 192.0.1.2 Client connecting to 138.0.0.254, UDP port 49169 with pid 26515 via zeth0 (1 flows)
|
|
The client is on 192.0.1.1, which is zeth0, whereas the output, or the UDP server is on 138.0.0.254 on interface zeth1. The revised scripts I attached should set those interfaces up. If not, you can do so manually via "ifconfig zeth0 up" and "ifconfig zeth1 up". I can view the output on the 138.0.0.0/24 network in two ways. One is the wireshark capture attached which shows the packets appearing on the zeth1 interface. Secondly, "ifconfig" shows rx packets on zeth1 when I drive data via Iperf client into 192.0.1.1. So I am confident the packets are hitting the TAP interface. To get the packets to bridge from zeth0 to zeth1, you have to run the zephyr.exe application after running the setup scripts to verify the TAP interfaces are correct. This application acts like a simulated radio, where Iperf data driven into zeth0 will be transmitted out zeth1 with a different IP header. The zephyr.exe application will only pass UDP traffic through the interfaces. NOTE: the link status will only show up as UP after the zephyr.exe application is run to create a listener for the two interfaces. |
|
A pure UDP socket does not seem to work, I am going to test with a raw socket. If you can give me some idea in the code where the read routine is for the listen socket, I will convert the UDP socket into a raw socket, and then remove the IP header and presumably pass on the UDP payload to the same processing routine. If there is any general architecture documentation, that would be appreciated. |
|
A raw socket running as root works to read and write from the TAP interface. A parallel discussion is occurring on SourceForge on this topic in terms of how to integrate this functionality in Iperf. |
I need to have Iperf2 handle a simple IPv4 data stream on a single Linux workstation, where various TAP interfaces are present to represent virtual Ethernet interfaces. I have routing setup such that on the tx side, Iperf2 works well and targets in my case, the zeth0 TAP interface. The following command is used to transmit the data:
iperf -c 192.0.1.1 -u -i1 -b5M -l188 -p49169 -t5
I am unable to get Iperf2 on the listen side to see any of the data, which is written by an application to a virtual TAP interface as zeth1.
I have changed the source code such that when the following arguments are used, it attempts to bind the listen socket to the zeth1 interface. The address I will be using is not a real multicast.
-s -u -B0.0.0.0%zeth1 -p49169
I have tried both the ANY IP address, as well as a targeted one as 138.0.0.254, which is assigned to the outgoing TAP interface.
Wireshark traces on zeth1 show the presence of the data, with the destination port matching the assignment as 49169, a destination IP as 138.0.0.254, and a broadcast destination MAC address.
Within config.h, I have HAVE_THREAD_DEBUG defined so that the output provides additional information. A running log of the program is as follows.
I have breakpoints set for the various recvfrom() calls that never get triggered.
The custom code added result in the following text in the output:
Listen socket 3 successfully bound to interface 'zeth1'
Listen socket 3 bound to port 49169
Listen socket 3 bound to address 138.0.0.254
Are there any recommendations on what is happening and how to bind the listener to a particular virtual device? I would prefer to bind to both a destination device as well as a destination or source IP if possible.
Routing table and ifconfig dumps are as follows:
The text was updated successfully, but these errors were encountered: