0

I am new to tcpdump tool and I am working in the analysis of network packets, I have analysed the IPv4 Ip packtes generated in case of wifi. But Now I am running my android phone in sim's 3g network which is generated the IPv6 packets ,completely different form IPv4 format. I am confused about the IPv6 packets structure,

Again, I have gone through the IPv6 header format, and my phone's packets given below, These two format does not match. I am totally confused about IPv6 header.

My mobiles's local ip is 100.87.163.16 ,my question is how to detect the received packets and sending packets. Also I want to find out the header length , payload length, source and destination ip address in IPv4 format. I am looking for your valuable suggestions.

Thanks.

10:59:06.365651 00:00:32:06:af:56 (oui Unknown) > 45:00:00:a8:35:49 (oui Unknown), ethertype Unknown (0xd83a), length 168: 

0x0000:  c40e 6457 a310 01bb e6c0 f6b1 b5ed ec6b  �.dW�..������k
0x0010:  23f8 8018 015e dfc7 0000 0101 080a 17c2  #�...^��.......�
0x0020:  6af1 0014 f0c3 1703 0300 6f00 0000 0000  j�..��....o.....
0x0030:  0000 0208 7db4 d0c1 846d ca75 323c e6cb  ....}���.m�u2<��
0x0040:  1636 be16 942f 51ea 1caf 1c09 c085 3dbc  .6�../Q�.�..�.=�
0x0050:  7642                                     vB
Mohd Irfan
  • 16
  • 2
  • The packet you show does not have an IPv6 ethertype and its not an IPv6 packet. Besides, what you ask is impossible. If it would be an IPv6 packet then you can't get the addresses in IPv4 format. Such a thing doesn't exist. If it is an IPv6 packet you get IPv6 addresses. – Sander Steffann Jul 07 '15 at 07:18
  • If this is not IPv6 why this is in packets as : This is IPv6 00:00:32:06:af:56 in thie given packets 10:59:06.365651 00:00:32:06:af:56 (oui Unknown) > 45:00:00:a8:35:49 (oui Unknown), ethertype Unknown (0xd83a), length 168: – Mohd Irfan Jul 07 '15 at 09:23
  • That's a MAC address, not an IPv6 address – Sander Steffann Jul 07 '15 at 09:53
  • shark reader is showing this packets as **raw packet** and no output is showing, – Mohd Irfan Jul 08 '15 at 07:09
  • Yes, because they have an unknown ethertype. Type code D83A does not exist as far as I know. This might be some proprietary or experimental protocol. Or a broken device sending invalid data. – Sander Steffann Jul 08 '15 at 07:45
  • In the first line you're showing there is an IPv4 address (100.87.163.16) why are you saying it is an IPv6 packet? – rodolk Jul 09 '15 at 01:53
  • @rodolk This is ip of my device and got it from settings. – Mohd Irfan Jul 09 '15 at 04:58

1 Answers1

0

OK, let's reconstruct the full raw packet contents.

The driver supplied an ARPHRD_ value that got mapped to DLT_EN10MB (probably an inappropriate ARPHRD_ value; this is a known botch in some Android mobile phone interfaces, probably done to cope with inadequacies in the DHCP implementation, and later versions of libpcap work around it), so the packet was interpreted as if it were an Ethernet packet, when it probably was, in fact, not an Ethernet packet.

So tcpdump printed the packet as if the first 6 bytes were a destination MAC address, the next 6 bytes were a source MAC address, and the next 2 bytes were the type/length field.

Thus, the packet began with:

45 00 00 a8 35 49 00 00 32 06 af 56 d8 3a

and that really looks like an IPv4 packet with no link-layer header - which is exactly what the mobile phone interfaces in question provide as packets.

libpcap 1.6.2 and later have the libpcap workaround; if you use a version of tcpdump that uses a later libpcap, that will probably show the packets correctly. (If they don't, perhaps the hack libpcap uses to detect the bad ARPHRD_ values need to check for more interface names; please report this to tcpdump-workers@lists.tcpdump.org or on the GitHub issues list for libpcap. (Report this as a libpcap issue, not a tcpdump issue, as that's what it is.))