Hi,
Thanks for your suggestions. I have figured out the solution. The problem
is not caused by tcpdump, libpcap or Android. I found the phone actually
has two LTE interfaces "lte_rmnet0" and "lte_rmnet1", which is
unanticipated. I was always looking at the first interface "lte_rmnet0"
because I never considered there can be another one. However, all the LTE
traffic goes through "lte_rmnet1". That is why I always get 0 packets. If I
set the interface to "lte-rmnet1", tcpdump works well with LTE ipv6 packets.
Best Regards,
Xiufeng
On Thu, Dec 18, 2014 at 3:42 PM, Michael Richardson
wrote:
>
>
> Guy Harris wrote:
> > 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.
>
> yes, I agree...
>
> >> 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.
>
> I was trying to get tcpdump in the Android AOSP tree updated in the spring,
> but I ran out of time...
>
> --
> ] Never tell me the odds! | ipv6 mesh
> networks [
> ] Michael Richardson, Sandelman Software Works| network
> architect [
> ] m...@sandelman.ca http://www.sandelman.ca/| ruby on
> rails[
>
>
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
