5

I am opening a TAP device using

p->fd = open("/dev/net/tun", O_RDWR);

// skipping error handling code

ifr.ifr_flags = IFF_TAP | IFF_ONE_QUEUE | IFF_NO_PI;
strncpy(ifr.ifr_name, p->name, IFNAMSIZ-1);
result = ioctl(p->fd, TUNSETIFF, &ifr);

// skipping error handling and setting ipv4 address & netmask code

ifr.ifr_flags = (IFF_UP | IFF_RUNNING);
result = ioctl(dummySock, SIOCSIFFLAGS, &ifr);

The problem I am facing is when an application (say mozilla) wants to send out a packet via the tap device, it needs to get the dst mac address. So the kernel sends out an ARP request. The application I am writing forwards the arp request (via a raw socket on a physical eth device) and gets an arp reply. This arp reply is forwarded back to the tap device, but the kernel refuses to accept this. If I add an arp entry manually, no arp request is generated and there is two way ip packet exchange (mozilla is happy).

Wireshark is able to receive the packet and finds no errors. Same is the case with ICMPv6 packets (neighbor solicitation & advertisement). Any application listening on the device gets the packet intact. But the kernel does not process it for ARP/ICMP.

My question is, why doesn't the kernel accept the arp reply/ICMPv6 msgs? Is there some ioctl call that we need to call?

Edit:

Here is the details of packet captured (tshark output) at the tap device "ethgress"

  9  16.548328    fc00:1::2 -> ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation
 10  17.243247  fc00:1::100 -> fc00:1::2    ICMPv6 86 Neighbor Advertisement
 11  17.548652    fc00:1::2 -> ff02::1:ff00:1 ICMPv6 86 Neighbor Solicitation
 12  17.668736  fc00:1::100 -> fc00:1::2    ICMPv6 86 Neighbor Advertisement

This is the ifconfig output for "ethgress"

ethgress  Link encap:Ethernet  HWaddr 00:01:02:03:04:05
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:83 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:10000
          RX bytes:0 (0.0 b)  TX bytes:7062 (6.8 KiB)

As can be seen, the kernel is refusing the accept the ICMPv6 packets as received. But the tx packets are incremented.

The tap device "ethgress" is configured with IPv6 address fc00:1::2 and it an application wants to communicate to fc00:1::1. fc00:1::1 is at the same interface as fc00:1:100 which is responding with the neighbor advertisement (the target ip is fc00:1::1 in that packet) with proper mac address. Tcpdump is able to capture it and wireshark/tshark is able to decode it without and says its a properly formed packet. But Rx counters are not incremented by the kernel, nor does it update its arp cache. Same is the case with ARP packets.

Edit 2:

The network looks like this. There are two external boxes which are configured to be redundant. Only one of them will be active. They are connected to a pc via a physical NIC each. The application I am writing runs on this pc and opens a raw socket on each of the NICs. It also opens a TAP device. The NICs are not configured with an IP address. The TAP device is configured with both IPv4 and IPv6 address. A standard application, say mozilla, opens a socket via the tap device and wants to connect to the active box. For that the kernel generates an ARP request/Neighbor solicitation message on the tap device. The application reads this message and forwards it to both the NICs. The active box responds to the ARP request with an ARP reply which the application reads and writes it to the TAP device. This arp reply packet is captured by tcpdump, but the kernel doesn't update its arp cache. The mac address of both NICs and the TAP device are the same.

Other parameters asked for.

cat /proc/sys/net/ipv4/conf/all/log_martians
0
cat /proc/sys/net/ipv4/conf/all/rp_filter
1
cat /proc/sys/net/ipv4/conf/all/arp_filter
0
aufather
  • 651
  • 2
  • 7
  • 9
  • It would help if you posted the relevant Wireshark capture. – Ambroz Bizjak Nov 11 '11 at 13:23
  • 1
    If the ARP request is sent through the *physical* device, then how is the reply supposed to reach the TAP device? Sounds more like a high-level network configuration problem to me... – Kerrek SB Nov 11 '11 at 13:24
  • I have updated the question with tshark output at the tap device. The application I am writing, does a mux between two eth interfaces to a tap device. The application at the tap device automatically generates an arp request and I forward it to both eth interfaces, but only one will reply (don't know which one). The application maintains which is the active eth interface based on the arp reply. It doesn't modify any of the packets and forwards packets between the tap device and active eth interface (based on arp reply) transparently. – aufather Nov 11 '11 at 13:45
  • What are your settings for `log_martians`, `rp_filter` and `arp_filter`? What does your network look like? – ninjalj Nov 11 '11 at 19:23
  • @ninjalj I dont know what those parameters are. AFAIK, I have not fiddled with those parameters. After googling a bit, Got the values for those parameters. Sorry for the 2 day delay, I didn't have internet access over the weekend. – aufather Nov 14 '11 at 06:38
  • wouldn't setting up a bridge (via bridge-utils, add eth* and tap to the bridge) work for you? – ninjalj Nov 14 '11 at 07:41
  • Also, setting log_martians to 1 may make Linux spit out why it rejects some packets. – ninjalj Nov 14 '11 at 07:42
  • Any update on how to solve this? I'm having a similar issue with ICMPv6. – Pepedou Dec 16 '15 at 18:27
  • Any update? Same thing here. I've just implemented my own arp responder. – Christian Stewart Jun 17 '16 at 22:50

1 Answers1

0

This question is very old now.

(You also have the difference between TUN and TAP devices https://security.stackexchange.com/questions/46442/openvpn-tap-vs-tun-mode )

If your device is indeed a TAP device that includes ARP, hardware addressing etc: Your traffic-dump does not include the ethernet frame. Two important details for these ARP and ICMPv6 packets are the HW dst and src addresses. The RP filter is a part of this, but probably does not allow ALL possible combinations to pass.

For a TUN device: there should be no need for ARP etc, this device is "blind" IP device

Stian Skjelstad
  • 2,277
  • 1
  • 9
  • 19