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
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.))
Related
I am working on a Wifi Display Sink application in android and am facing an issue where the source is not sending the UDP server-port number in the RTSP SETUP message.
The SETUP RESPONSE is as below
'RTSP/1.0 200 OK
cseq: 2
date: Tue, 11 Aug 2015 15:12:38 +0000
server: Mine/1.0
session: 1719935144;timeout=60
transport: RTP/AVP/UDP;unicast;client_port=15550-15551;
'
NOTE:
I have figured out the server-port number using tcpdump in the source device. It is 16660. It doesnot look like any specifically assigned port number as well.Seems like a random port number hardcoded into the source device for Wifi Display Application.
Is there any other way to know the server-port number to which I should listen to for incoming UDP packets?
You should be listening on port 15550 and 15551 and the incoming UDP packets will contain their source port.
I want to discover all Android devices IP and Port in same wifi network using ZeroMQ?
My app basically connect all device in same wifi network (no internet needed) and message to each other. Once ip and port I know I am send message successfully but how to know all device internet Protocol (ip) Using ZeroMQ?
Principle
Part A)
Every IEEE 802.x CSMA/CD network "collision domain" ( wifi AP/SSID is such one ) has to be managed so as to work well. Thus the Address Resolution Protocol [ARP] will help you in the task to find all ISO-OSI-Layer-3 IP Addresses. Wifi Access Point [AP] host, to which all live devices register and handshake with, is the choice to start with.
HG520i> ip arp status
received 54205 badtype 0 bogus addr 0 reqst in 12105 replies 196 reqst out 14301
cache hit 63152696 (24%), cache miss 19455672 (23%)
IP-addr Type Time Addr stat iface
192.168.0.230 10 Mb Ethernet 290 00:15:af:e6:b1:79 41 enif0
192.168.0.62 10 Mb Ethernet 300 00:0c:29:98:d4:3b 41 enif0
192.168.0.55 10 Mb Ethernet 300 00:27:0e:07:c5:9e 41 enif0
192.168.0.255 10 Mb Ethernet 0 ff:ff:ff:ff:ff:ff 43 NULL
num of arp entries= 4
Part B)
Scanning all the ports on all the known IP hosts is a dumb brute force approach to the second issue.
Scanning just a subset of "reasonable" ones would save you both the time and efforts on peer-recognitions.
Using some smarter, active "visibility self-advertisement policy" will save you even more.
Solution
Decide on multi-party system architecture, whether an individual passive scan, a central/distributed proxy-assisted scan or an active self-advertisement policy will be used to build and maintain live records in a neighbouring hosts register.
ZeroMQ per-se brings you a lot of power for the smart solutions, while the dumb-force solutions would have to wait till fully fledged ZeroMQ services will be ready. Low level L2/L3-inspections will have to bring their fruit before ZeroMQ can first .bind()/.connect()
Needless to say, that uncoordinated CSMA/CD networks do not guarantee that all the L2-visible hosts will have "compatible" L3-ip-adddress ( will belong to / have the same L3-ip-network address ).
Thus you never know about all IP addresses without a truly low-level sniffer.
I am capturing packets over 3G on Android and I get an output that is bizarre. I see mac addresses instead of IP addresses and have no clue how to decode it. I see the IP addresses when I run the same capture over WIFI. It appears as if the link type needs to be changed for 3G interface.
Currently, I only see "EN10MB (Ethernet)" option under the list of Data link types (tcpdump -L). I see different link types on tcpdump website (http://www.tcpdump.org/linktypes.html) and I think probably I somehow need to recompile the source, so that I get "LINKTYPE_GPRS_LLC" under Data link types to get the right capture.
Does anyone know how to do this? I have the source for libpcap (v0.9.8) and tcpdump (v3.9.8) (one that comes along with AOSP 4.2.1 source).
Thanks and I really look forward to hear from you guys.
Here is a sample output that I get for a capture over 3G interface:
ping google.com
tcpdump -vvvs 0
22:11:51.450906 40:00:40:11:12:18 (oui Unknown) > 45:00:00:38:66:22 (oui Unknown), ethertype Unknown (0x1528), length 56:
0x0000: 4a4b 4201 2107 bad2 0035 0024 5a5e 140c JKB.!.��.5.$Z^..
0x0010: 0100 0001 0000 0000 0000 0667 6f6f 676c ...........googl
0x0020: 6503 636f 6d00 0001 0001 e.com.....
22:11:52.363748 00:00:fd:11:0c:9c (oui Unknown) > 45:00:00:e8:ed:ed (oui Unknown), ethertype Unknown (0x4201), length 232:
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.
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?
i have a big problem and i doubt about my intellect... I connected my android tablet (intenso tab814) to a RS232 converter (USR-TCP232-E) via a router (TL-WR740-N) and i send 7 hexadezimal bytes in a block, kinda 03 20 05... with further numbers. My problem is, if i let my tablet send, the converter receives the data, but does not submit it to a listening program on an pc behind the converter complete. There are often complete blocks missing (bnot single Bytes, but the whole command line i send), but if i send my data via tablet to another PC, and let HIM do the sending work to the converter every single byte arrives. It may be a bit dazzling, but i dont know, where this problem could belong to. My App sends every block correctly (the pc is able to receive)
The converters yellow RJ45 port-LED blinks, but i does not give the data to the listening pc.
For better understand:
Tablet(selfpogrammed app) sends data -> router -> converter (everytime blinks) seldom gives the command -> PC(selfwritten listening programm(not written by me, but by the one, i am the follower of, not familiar with language.)
But if i:
Tablet(same app) -> router -> PC (receives all the data) -> router -> converter always give the data to the listening progamm ->pc
What is the matter here? Why does the converter gives the data from app -> pc to listening pc, but not from app to listenign pc?
Tablet is connected via W-Lan to router, the pc's via RJ45-cable, the converter either. Using TCP/IP converter as server.
PLS HELP Q_Q
EDIT:
configuration:
Baud Rate: 115200bits/second
Data Size: 8 bits/characterParity: None NoneOddEvenMarkSpace
Stop Bits: 1bit(s)
Flow Control: None
Local Telnet Port Number: 2001
Remote Telnet Port Number: N/A
Telnet Mode: TCP Server
Telnet Server IP: N/A . . .
Telnet Timeout: 0seconds seconds (< 256, 0 for no timeout)
UART packet Time: 10ms ms (< 256)
UART packet length: 200
EDIT:
forgot sth to mention. the converter is via RS232 to an USB converter from RS232 to USB connected. Its receiving lamp does not blink, when the listening programm does not show my commands, but if the programm spits my lines out, the USB-part blinks too. So the converter receives, but does not give it to the USB. But only if i use my tablet. Same interval all the time.
Was my own fault, forgot to use a bufferedoutputstream, now it works.
Anyone have idea how can find available IP addresses in a network using any protocol?
UDP broadcasting is one way. But in this case every one should have a listener app?
Please suggest if have any other way?
You could send ICMP pings to the broadcast network address. For example, if your interface IP is in the 192.168.0.0/24 network, you would send pings to 192.168.0.255 -
[22:45:54 jmac:~]$ ping 192.168.0.255
PING 192.168.0.255 (192.168.0.255): 56 data bytes
64 bytes from 192.168.0.12: icmp_seq=0 ttl=64 time=0.159 ms
64 bytes from 192.168.0.1: icmp_seq=0 ttl=64 time=99.708 ms
64 bytes from 192.168.0.12: icmp_seq=1 ttl=64 time=0.147 ms
However to send ICMP ping from an application, you'll need to open raw sockets & thus you'll need root permissions. The ping program on most OSes are setuid root programs, so they can be invoked by any user.