Wireshark Does Not Recognize Kafka Protocol - networking

I am trying to analyze Kafka packages, but Wireshark is not recognizing Kafka protocol for some reason. Instead of something like this:
I get everything as plain TCP:
I made sure that the protocol is enabled and the correct port is set.
I also tried to use Analyze/Decode As... without any success.
I am using Wireshark v3.6.6
How can I make it work?

Related

collectd not sharing information to graphite for all data

I have a strange one.
A number of data items are being collected by collectd and appear correctly with
collectdctl -s /var/run/collectdctl listval|getval and so forth.
These are then rendered into graphite effectively for most items.
Recently, the collectd-graphite connection ceased to be operational
for several recently added items. While it appears in collectd and
is queryable via collectdctl, it remains not on the graphite page.
I am asking to find out how you would approach this.
Thanks for any comment.
There's probably a number of ways you can troubleshoot this, but I end up almost always resorting to tcpdump, sigh. First enable debug logging in collectd just to make sure it really doesn't spit out an error message (LogLevel "debug" https://collectd.org/wiki/index.php/Plugin:LogFile although often collectd is compiled with debug logging disabled).
Then run tcpdump on the graphite server using the -s0 -X flags to tcpdump so you get the packet contents. (You can also use a more sophisticated network sniffer that prints the tcp data stream.) Check whether you see the data items that are missing the packets and whether they look appropriate (see https://collectd.org/wiki/index.php/Plugin:Write_Graphite). Typically this step allows me to quickly determine whether the problem is the sending collectd or the receiving service.

sending HTTP requests obtained from WireShark

I have an app controlling my AVR on a local network and I'm trying to embed some of the functionality into another app written by myself. I've started up WireShark and started controlling the volume, which shows up as:
GET /ctrl-int/1/setproperty?dmcp.device-volume=-15.750000 HTTP/1.1
I'm not totally up on this type of http control but i'd like to know if this is enough data to be able to send the same request via a browser or terminal etc.
cheers
Without knowing the avr you can't realy tell. But you should be able to send the command via
avr-ip/ctrl-int/1/setproperty?dmcp.device-volume=-15.750000
in the browser or from you app. The ip should be in the wireshark logs as well.
If that works it was enough information.

How to write http layer sniffer

I want to write an application layer sniffer (SMTP/ftp/http).
Based on my searchs, first (and perhaps hardest!) step is to reassemble the tcp stream of the sniffed connections.
Indeed, what I need is something like the "follow TCP stream" option of wireshark, but I need a tool which do it on live interface and automatically. As I know, Tshark can extract TCP streams data from the saved pcap files automatically (link) but not from live interfaces. Can Tshark do it on live interfaces???
As I know, TCPflow can do exactly what I want, however, it can not handle IP defragmentation and SSL connections (I want to analyse the SSL content in the case I have the server private key).
Finally, I also try bro network monitor. Although it provides the list of TCP connections (conn.log), I was not able to get TCP connections contents.
Any suggestion about mentioned tools or any other useful tool is welcome.
Thanks in advance, Dan.
perl Net::Inspect library might help you. It also comes with a tcpudpflow which can write tcp and udp flows into separate files, similar to tcpflow. It works on pcap files or can do live captures. The library handles IP fragmenting. It also comes with a httpflow tool to extract HTTP requests and responses (including decompression, chunked encoding..). It does not currently handle SSL.
As the author of this library I don't think that extracting TCP flows is the hardest part, the HTTP parser (exluding decompression, including chunked mode) is nearly twice as big than IP and TCP combined.
This example works for reassembling application data of a single protocol:
tshark -Y "tcp.dstport == 80" -T fields -d tcp.port==80,echo -e echo.data
It captures live http data, reassembles it, and outputs it as raw hex.
I can add a small script to parse the hex into ascii if you like.
I want to analyse the SSL content in the case I have the server private key
TL;DR: This can't be done with a capturing tool alone.
Why not: Because each SSL session generates a new secret conversation key, and you can't decrypt the session without this key. Having the private server key is not enough. The idea behind this is that if someone captures your SSL traffic, saves it, and then a year later he "finds" the private server key, then he still won't be able to decrypt your traffic.

How to debug Websockets?

I want to monitor the websocket traffic (like to see what version of the protocol the client/server is using) for debugging purposes. How would I go about doing this? Wireshark seems too low level for such a task. Suggestions?
Wireshark sounds like what you want actually. There is very little framing or structure to WebSockets after the handshake (so you want low-level) and even if there was, wireshark would soon (or already) have the ability to parse it and show you the structure.
Personally, I often capture with tcpdump and then parse the data later using wireshark. This is especially nice when you may not be able wireshark on the device where you want to capture the data (i.e. a headless server). For example:
sudo tcpdump -w /tmp/capture_data -s 8192 port 8000
Alternately, if you have control over the WebSockets server (or proxy) you could always print out the send and receive data. Note that since websocket frames start with '\x00' will want to avoid printing that since in many languages '\x00' means the end of the string.
If you're looking for the actual data sent and received, the recent Chrome Canary and Chromium have now WebSocket message frame inspection feature.
You find details in this thread.
I think you should use Wireshark
Steps
Open wireshark
Go to capture and follow bellow path: capture > interfaces > start capture in your appropriate device.
Write rules in filter tcp.dstport == your_websoket_port
Hit apply
For simple thing, wireshark is too complex, i wanted to check only if the connection can be establish or not. Following Chrome plugin "Simple Web-socket (link : https://chrome.google.com/webstore/detail/simple-websocket-client/pfdhoblngboilpfeibdedpjgfnlcodoo?hl=en)" work like charm. See image.
https://lh3.googleusercontent.com/bEHoKg3ijfjaE8-RWTONDBZolc3tP2mLbyWanolCfLmpTHUyYPMSD5I4hKBfi81D2hVpVH_BfQ=w640-h400-e365

A Question regarding wget

when I type wget http://yahoo.com:80 on unix shell. Can some one explain me what exactly happens from entering the command to reaching the yahoo server. Thank you very much in advance.
RFC provide you with all the details you need and are not tied to a tool or OS.
Wget uses in your case HTTP, which bases on TCP, which in turn uses IP, then it depends on what you use, most of the time you will encounter Ethernet frames.
In order to understand what happens, I urge you to install Wireshark and have a look at the dissected frames, you will get an overview of what data belongs to which network layer. That is the most easy way to visualize and learn what happens. Beside this if you really like (irony) funny documents (/irony) have a look at the corresponding RFCs HTTP: 2616 for example, for the others have a look at the external links at the bottom of the wikipedia articles.
The program uses DNS to resolve the host name to an IP. The classic API call is gethostbyname although newer programs should use getaddrinfo to be IPv6 compatible.
Since you specify the port, the program can skip looking up the default port for http. But if you hadn't, it would try a getservbyname to look up the default port (then again, wget may just embed port 80).
The program uses the network API to connect to the remote host. This is done with socket and connect
The program writes an http request to the connection with a call to write
The program reads the http response with one or more calls to read.

Resources