tcpdump - Bizarre output over 3G/mobile data on Android

Question 1

So, here's what solved the problem.

Looks like when we explicitly specify the interface name (cdma_rmnet4 in my case) or do not specify any interface (in this case it automatically assumes the interface to be cdma_rmnet4), it gives the same garbled output.

But when we capture it with “-i any” flag, it does capture on some “LINUX_SLL” interface, which gives the correct output. I googled it and found out that LINUX_SLL is Linux cooked mode capture by libpcap to capture from the "any" device and to capture on some devices where the native link layer header isn't available or can't be used, which is the case with 3G/mobile packets.

Question 2

If by "Currently, I only see "EN10MB (Ethernet)" option under the list of Data link types (tcpdump -L)." you mean that, when you run tcpdump -L, that means that, on the interface on which you're capturing, the only link-layer header type it claims that it can supply are Ethernet headers.

If that's what it's supplying, tcpdump should be reporting the right packet data.

If that's not what it's supplying, then the driver or networking stack on the version of the Linux kernel your mobile phone/tablet is running is broken - it's supplying the wrong ARPHRD_ value to libpcap, which is then passing that lie on to tcpdump or whatever other program is using libpcap.

The best way to fix this would be to fix the driver or whatever is supplying ARPHRD_ETHER. Unfortunately, a quick look at the 3.11 kernel's include/uapi/linux/if_arp.h doesn't show an ARPHRD_ value that appears to be intended for this.

Note, however, that this is NOT necessarily LINKTYPE_GPRS_LLC! That LINKTYPE_ value is for GPRS LLC frames, as described in 3GPP TS 04.64; those can encapsulate Subnetwork Dependent Convergence Protocol frames, which can encapsulate IP frames (at least according to the Wireshark dissector for GPRS LLC frames), but Android might be using some completely different link-layer headers. GPRS is NOT a 3G service; I think 3G data uses a different link layer.

Tcpdump does not know how to dissect GPRS LLC frames, so, IF that's what the driver is supplying, that wouldn't help without changes to tcpdump to understand GPRS LLC and the Subnetwork Dependent Convergence Protocol.

A quick look at tcpdump's output, and at this similar Wireshark question, suggests that the link-layer type might be LINKTYPE_RAW - the first octet of an Ethernet frame is the first octet of the destination address, so it appears that the first octet of those frames is 0x45, which is also the value that the first octet of an IPv4 frame without options would have (IP version 4, header length 5 32-bit words or 20 bytes).

Try, as an experiment, a version of tcpdump that treats DLT_EN10MB as if it were DLT_RAW; if that works with the 3G interface, then either the drivers or networking stack need to be changed to supply ARPHRD_NONE to libpcap or libpcap needs to look at the device name and, for the Android device or devices in question, map ARPHRD_ETHER to DLT_RAW rather than DLT_EN10MB. What's the name of the device on which you're capturing, i.e., the argument to the -i flag? If you didn't pass an argument to -i, what is the output of ifconfig -a on Android?