Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I created a TUN device(nat64) and created a route so that all the required packets are forwarded to the TUN device from an eth device. But, I see that many packets are not received by the TUN device.

Explaining the long story, I am trying to implement a simple NAT64 application using TUN device to filter required traffic. 2001:abcd:1::1 is the Gateway IP. All IPv6 packets received by the gateway and destined to 2001:abcd:1:ffff::/64 need to be translated to IPv4. I wrote a program which reads from the TUN device and does all the required translations from IPv6 to IPv4.

I created a route to 'nat64' TUN device for 2001:abcd:1:ffff::/64. It works fine if I try ping6 or traffic at low rates. When I tried to send packets at a higher rate, many packets have not reached the TUN device. Out of 4M UDP packets that I transmitted at 200K/sec, only 2.9M packets have been routed to TUN device.

I verified this from the statistics in ifconfig and also using counters while read()ing from the TUN device. Also checked tcpdump to verify that all the packets have reached eth0. Used ostinato tool to send the UDP packets.

Below is the configuration-

> $ip -6 route  
> 2001:abcd:1:ffff::/64 dev nat64 metric 1024 mtu 1500 advmss 1440 hoplimit 0
> eth0 Link encap:Ethernet HWaddr 08:AC:A5:10:01:52 inet6 addr:
> 2001:abcd:1::1/128 Scope:Global inet6 addr: fe80::aac:a5ff:fe10:152/64
> packets:182256365 errors:0 dropped:0 overruns:0 frame:0 TX
> packets:91927 errors:0 dropped:0 overruns:0 carrier:0 collisions:0
> txqueuelen:0 RX bytes:8762429793 (8.1 GiB) TX bytes:10618282 (10.1
> MiB)
> nat64 Link encap:UNSPEC HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP POINTOPOINT RUNNING
> NOARP MULTICAST MTU:1500 Metric:1 RX packets:49370386 errors:0
> dropped:0 overruns:0 frame:0 TX packets:49379475 errors:0 dropped:31
> overruns:12933189 carrier:0 collisions:0 txqueuelen:500 RX
> bytes:1394031492 (1.2 GiB) TX bytes:2378651480 (2.2 GiB)
> $tcpdump -ni nat64 > /dev/null 
> tcpdump: WARNING: arptype 65534 not
> supported by libpcap - falling back to cooked socket tcpdump: WARNING:
> nat64: no IPv4 address assigned tcpdump: verbose output suppressed,
> use -v or -vv for full protocol decode listening on nat64, link-type
> LINUX_SLL (Linux cooked), capture size 65535 bytes ^C2961568 packets
> captured 2961568 packets received by filter 0 packets dropped by
> kernel
> $tcpdump -ni eth0 > /dev/null 
> tcpdump: WARNING: eth0: no IPv4 address
> assigned tcpdump: verbose output suppressed, use -v or -vv for full
> protocol decode listening on eth0, link-type EN10MB (Ethernet),
> capture size 65535 bytes ^C4000482 packets captured 4000482 packets
> received by filter 0 packets dropped by kernel

What could be the reason for so many packets missing between eth0 and TUN device?

share|improve this question
I wonder if this is related to Why are incoming packets on a TAP interface seen with tcpdump but not with iptables? I never got to the bottom of that problem. On an unrelated note: please re-do your copy-paste of the shell session and do not use the “quote” tool — use the “code” tool instead. The quote tool screws up line breaks. – Gilles Feb 8 '13 at 0:40
Check the packet counts of iptables -vL to see where they go. – ott-- Feb 8 '13 at 10:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.