On Dec 17, 2014, at 2:11 PM, Xiufeng Xie <xxi...@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.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
