Home / server / Questions / 343215
In Process
Amit S
Asked: 2011-12-22 10:17:04 +0800 CST

Communication problems on secondary interface tap0

  • 772

I am using UDP over ipv6 as communication stack.

I have network client running on secondary virtual interface tap0. It generates messages for server which is supposed to run on the same interface but different link-scope ipv6 address. I can see proper messages generated by the client on the wireshark.
For now I don't have the server code ready but I am using netcat as a replacement for server to test receive the messages, which I have done as follows:

nc -l -6 -vvv -u fe80::d4b2:dcff:fe59:6d2%tap0 61616

fe80::d4b2:dcff:fe59:6d2 is the server side link-scope ipv6 address. Wireshark traces on tap0 clearly shows the packets generated are for above mentioned ipv6 address and port but the netcat is NOT able to receive any packets. ifconfig shows that I have the above IP assigned to tap0. Moreover, if I execute the following command, I am able to receive the packets at the netcat(server).

nc -6 -vvv -u fe80::d4b2:dcff:fe59:6d2%tap0 61616 < raw_message_file

Strangely, the sending of the above netcat "raw_message_file" is not captured by the wireshark running on tap0. Following ping is also not captured by the wireshark.

ping6 -I tap0 fe80::d4b2:dcff:fe59:6d2

How could be possible that even when explicitly specifying the interface for netcat and ping, the packet are not received/sent on that interface?

PS1: Virtual interface tap0 is opened by the client code. After some time it sends the message to the server which is supposed to be listening on that interface with some different but fixed IPv6.
PS2: I think my description is bit confusing; please ask questions, if you have any?

EDIT: tcpdump on localhost showed that the netcat and ping are going through the localhost interface. My question is, why?

networking netcat wireshark ipv6 interface

1 Answers

  1. Looks like you may be a little confused about how IPv6 works.

    Let's clarify a few things first: You do not run a client or a server "on" a network interface, it is confusing specially when you are talking about tun or tap devices, which break some of our conventions. Also, you do not "open" a tap device (except if you are writing a tun/tap helper, which doesn't seem to be the case here), instead, you bind an address to a socket and the operating system will later determine how to route your outgoing packets to the network interfaces, and how to deliver incoming packets from them to your local process. Keep this in mind, it is the operating system that does this, not your program.

    When your process binds a socket to a link-local IPv6 address, it is just telling the OS what is the address that packets will be sent from, and that packets from the network will be captured and relayed to your process. The ...%tap0 suffix of the link-local address is part of the address, it is just a hint to the OS since all link-local addresses share a single global address space across all networks, it doesn't mean that the process is in any way bound or locked to that specific device.

    If you are sending packets to your own computer, sure it will not pass through the tap interface at all. Perhaps this is your answer: The only packets that should fly through the tap interface are those going to whatever is on the other side of your tunnel, it doesn't make sense to send anything there that is going to your own machine. Those packets are instead delivered through the lo interface. Attach wireshark to the lo interface and you should see the packets that you are missing.

    When you assign an address to an interface, the operating system knows that that address now belongs to your computer, and that anything sent to that address (including anything sent from local process themselves) should be routed to this computer. Anything going out from physical or logical interfaces like eth0 or tap0 are really being sent away from your computer, if something has to stay in the system, it has to take a U-turn on the lo interface so that the packet comes back to the bottom of the stack and up to the receiving processes.

    Where does the OS keep track of this? In the routing table. Try this:

    ip -6 route list table all root fe80::/10

    You should see one or more routes to fe80::/64, one for each physical or logical IPv6-enabled network interface in your system, and also some local link-local addresses for each of the assigned IPv6 addresses. You will notice that the local addresses are set to use dev lo, which is how the OS knows that anything going to these addresses are not to be sent out.

    • 1