I am trying to debug a problem with an X11 Sever and XDCMP. I have captured the traffic with tcpdump and loaded into wireshark.
I am new to wireshark and found this on the web Tracking XWindow Protocol Which seems to indicate that there is a dissector for X11 but I don't get my X11 traffic decoded.I was hoping to get the X11 protocol as per an xtrace ( Note I cannot use xtrace as XDMCP is involved ) I am using wireshark 1.10.6
Which seems to indicate that there is a dissector for X11
There is.
but I don't get my X11 traffic decoded.
If you captured X traffic, there might be a bug or some other issue. Please file a bug on the Wireshark Bugzilla, and attach a network trace to the bug, so we can try to debug it.
Was not aware that the correct way to drive wireshark is to select the traffic then right click on the mouse, select decode as, then X11.
Related
I installed Wireshark on macOS High Sierra and captured some network trafic while making HTTP calls to a local server using CURL.
The traffic captured in wireshark only showed TCP packets. When looking at the data whitin the TCP packets I could see the HTTP packets, but these were not recognized by Wireshark as the packet protocol.
Any way to make it properly parse the HTTP packets?
Here's an example capture:
One guess I had was that Wireshark only recognises a packet as HTTP if it's on port 80. If this is so, is there any way to change this setting?
P.S. No HTTPS involved here, just plane old HTTP from a client to a REST API.
Ok, figured out the issue.
My server was exposed on port 5000 (which is the default Flask port).
Turns out that port 5000 is conventionally used for IPA packets, which is a GSM over IP protocol. Wireshark aparently used the port number to determine the type of packet, and so it misclasified it as an IPA packet.
Once I moved my server to another port (e.g. 5001) - the problem was gone.
P.S. See https://osqa-ask.wireshark.org/questions/9240/data-which-has-been-sent-over-tcpip-has-been-recognized-by-wireshark-as-ipa-protocol for more details.
To supplement #MartanRubin's answer, it's also possible to indicate to WireShark that port 5000 is not GSM over IP. In Edit → Preferences → Protocols → GSM over IP remove port 5000 from the "TCP port(s)" field:
To persist the preference you also need to add 5000 to HTTP protocol "TCP port(s)" field. Then they survive restart (tested in a custom profile). Note however, that when you open GSM over IP protocol's preferences, 5000 is still there, but doesn't have effect. But when I save it (click OK button), my /home/user/.config/wireshark/profiles/CustomProfile/decode_as_entries gets messed up again, and I need to repeat the process on both protocol's "TCP port(s)" field. A counter-intuitive UI, I would say.
I'm using the Scapy library for Python 2.6 on Windows 7 in order to see if I can spoof my IP address (for non-malicious purposes, I'm curious how it works).
When I use the sr1() function, it sends the packet, but it gets nothing in return. I have to interrupt it manually using CTRL+C in order for it to stop receiving packets that are not an answer.
I've tried to use both Python-Scapy or the like-How can I create an HTTP GET request at the packet level and Scapy: no reply on raw ICMP packet, with no luck.
I have tried tracking it in Wireshark, but nothing showed up.
I know Scapy is not made for Windows, so that could be the issue. If so, I can get a Linux environment instead.
NOTE: Note that I am running this through the console version of Scapy, but I found the exact same results running it through Python scripts.
IP(dst="www.google.com")/TCP(dport=80,flags="S")
This TCP packet's sport will automatically set to be 20 (www-data) in Scapy.
And what is worse, www.google.com does not reply from the sport=20 (www-data)
try
IP(dst="www.google.com")/TCP(sport=65000,dport=80,flags="S")
I want to capture and analyze TCP communication data between two applications running on local host, which is running Windows 7 OS. I try to use Wireshark, but Wireshark could not capture the data, it seems just monitor the data in/out the network interface.
Could you introduce some useful tools to monitor the local TCP data easily.
The reason wireshark doesn't work is because sniffers rely on the network driver stack, and Windows don't expose localhost calls through it.
You should use Socket Sniffer, which looks at Winsock calls and monitors network sockets; the download link is at the bottom of the page.
There are limitations in Windows that prevent libpcap and Microsoft Network Monitor from sniffing localhost/loopback. But you can sniff localhost if you use Raw Sockets.
There is a free tool called RawCap that can sniff localhost and save the captured packets in a PCAP file. This allows you to inspect the traffic in Wireshark later on.
You can download RawCap from here:
http://www.netresec.com/?page=RawCap
I have to make a windows based application for which captures network traffic per application where some of running application uses same port number for sending and receiving the packets.
I have used winpcap and successfully captured and filtered them port wise and destination wise but I dont know how to capture them application wise that means how to know application information from ip packets.
Is only winpcap can solve the problem or some other api's or library shoud be used.
Can we get the application information from which packet is generated from packet header?
**
Can anyone give me example that uses iphlpapi and winpcap in vc++ for capturing network traffic per application.
**
I don't think this is possible with winpcap.
Take a look at Windows Filtering Platform. It's not advanced at all.If you look in the samples you can find one which does exactly what you want.
winpcap doesn't have a good way to tell what process is sending what data.
But windows does.
try using
netstat -a -o
netstat is a program that tells you what ports are being used on your terminal.
-a switch says, "show me all the ports"
-o switch says, "show me the pid of the processes using this port"
you can't see what port your processes are sending on, but you can see what ports are receving on for udp packets.
for tcp packets you'll see all the info you could want, includeing the remote connections ip address.
Is it possible to track XWindow protocol with a tool? I thought wireshark would be a good framework to host such an idea but there seems no support. What should be done to achieve this goal?
Wireshark does have the ability to dissect the X-Window protocol.
However: You first have to be able to capture the actual X-Window traffic between an X-client (app) and an X-Server before Wireshark can dissect it.
X-Windows traffic between an app (X-Windows client) and an X-Windows Server both running on your local machine probably uses "Unix Domain sockets" to do direct interprocess communication (IPC) between the client and the server. There's no underlying network protocol used and thus the traffic is (AFAIK) not capturable for dissection by Wireshark).
It's been a while since I've dealt with X but I think basically what is needed is that an X-Server be running on a box such that the server is listening for (and willing to accept) network connections. If an Xclient app on a remote node (or local node ?) then connects to the XServer over the network, you will then be able to capture that traffic for dissection by Wireshark.
X is complicated; If you're not familiar with the details of running X, you'll need to do some reading or ask for additional info. I've long since blanked out details related to X.
It is possible in principle to capture X-Window protocol that goes through Unix socket using strace. Then it is possible to wrap this packet for Wireshark using text2pcap.
Example:
capture X-window protocol frames that goes to X-server with pid 1998 on unix socket with file descriptor 41:
bash$ sudo strace -e trace=read,write -e read=41 -p 1998 2>&1 | grep '^[ ]|' >/tmp/xdata.log
prepare the captured data for wireshark:
bash$ text2pcap -T 1234,6000 /tmp/xdata.log /tmp/xdata.dump
Now one can use wireshark on /tmp/xdata.dump.
Back in the '80s, there was an open source Xwindow proxy program that would be placed between the Server and the client. It was written in 'C' and easily modifiable to count types of messages, or volume of data passing in each direction. It also recognized malformed Xprotocol that would result when folks used the wrong functions in interrupt handlers.
I can't remember the name, but maybe searching on "Xwindow proxy" might help...
I'm not sure what the XWindow protocol is, but you could make a Lua Dissector for Wireshark:
http://wiki.wireshark.org/Lua