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?