[tcpdump-workers] Cross-compiling tcpdump with ipv6 enabled

Guy Harris guy at alum.mit.edu
Thu Dec 18 16:01:22 EST 2014


On Dec 17, 2014, at 2:11 PM, Xiufeng Xie <xxie28 at wisc.edu> wrote:

>  Currently I need to capture ipv6 packets on Android phone. On my PC,
> tcpdump works well with ipv6 traffic, so I also want to try it on the
> phone.
> 
>  However, when I cross-compile tcpdump for ARM platform with ipv6 enabled,
> it is forced to give the warning about buggy getaddrinfo() function and
> then exit.

	https://www.gnu.org/software/autoconf/manual/autoconf.html#Runtime

"Sometimes you need to find out how a system performs at runtime, such as whether a given function has a certain capability or bug. If you can, make such checks when your program runs instead of when it is configured. You can check for things like the machine's endianness when your program initializes itself.

If you really need to test for a runtime behavior while configuring, you can write a test program to determine the result, and compile and run it using AC_RUN_IFELSE. Avoid running test programs if possible, because this prevents people from configuring your package for cross-compiling.

There's nothing we can do, when cross-compiling, to determine whether getaddrinfo() is buggy or not.  What we *could* do is, when cross-compiling, assume it's *not* buggy; this has the advantage of allowing IPv6 support when cross-compiling, with the disadvantage that, if the target platform has a buggy getaddrinfo(), it builds anyway, and you're stuck with the buggy behavior.

I would vote for assuming that there aren't many buggy implementations these days, especially when cross-compiling (which would probably be for a Linux or *BSD target, current versions of which probably have non-buggy getaddrinfo()), assuming a *non*-buggy getaddrinfo() when cross compiling, and playing The World's Smallest Violin if somebody ends up getting hosed by getaddrinfo() on a target platform for which they're cross-compiling.

> I comment out this test to complete compiling (with ipv6
> enabled). The resulting binary works well when monitoring ipv4 packets on
> my phone, but still captures 0 packets on the Verizon ipv6 lTE network.

Try writing a small test program, using libpcap, that doesn't set any capture filter and that just counts packets.

If that doesn't capture any packets on Verizon's LTE network, then the problem is either with libpcap or with the Android networking stack.


More information about the tcpdump-workers mailing list