Wireshark Basics Setup

git clone https://aur.archlinux.org/wireshark-git.git cd wireshark-git makepkg -si

Wireshark is a very well know software with which you can capture and analyze network traffic. I personally only use it to analyze traffic and use tcpdump to capture, as cli is always more reliable because less lines of code. If you really want to capture traffic with Wireshark you will need CAP_NET_ADMIN and CAP_NET_RAW privileges, of course you have these also if you run it as root but I highly recommend you never to run Wireshark as root. One of the most important things when starting to capture is to have Wireshark profile configured depending on what you capture. Create new profile by right clicking bottom right corner => New… You can also import this profile(it contains basic settings).

After you import it you can switch to it by left-clicking bottom-right corner and selecting profile You can then customize current profile with some coloring rules ( View => Coloring Rules ) There are already some existing rules which are pretty good and I don’t recommend changing Click the “+” sign and choose a name for the rule and a filter. Filter must be a valid Wireshark filter which is applied and all packets which match it will be marked with colors specified for that color rule. If you left click on the rule which you created you will see at the bottom of window “Foreground” and “Background” which you can customize as you wish for packets which match that rule

Notice that the order of rules also matters because if I create new rule (Example: TCP_SYN) with filter “tcp.flags.syn==1” which means all packets which have TCP flag SYN set and I add it on the top of a default color rules such as (Bad TCP) , it will color all TCP_SYN packets with that color ( also the ones which are “bad” meaning retransmitted. In Wireshark, everything that’s with Black Background represents errors and “Bad TCP” represents TCP errors which should be easily seen and this rule or any other default rule should not be overwritten. I shall show difference in the following two images:

As you can see in these two images above, rules order is very important and again, I do not recommend changing/overwriting default rules

TCP connection process

TCP is a stateful type of connection, which means the status of certain flags is very important as it is a session oriented type of connection which ensures all data is successfully sent and received. It is formed of three main stages: Three way handshake - in which client sets TCP.SYN flag to 1 and sends this frame to server. Server sends frame which has TCP.SYN and TCP.ACK flags set to 1 ( It acknowledges SYN from server and it also sends a SYN saying it’s ready for data transmission); Client sends ACK frame for the last frame from server. (time elapsed between SYN frame from client and SYN frame from server is also known as a “round-trip” which is almost equivalent ~ to latency value between the two)

Actual data exchange - After step a) socket state turns to ESTABLISHED and client and server start exchanging data Graceful disconnection - either one of client or server can send a frame which has TCP.FIN flag set to 1 which means that it sent/received all data it was needed and will close its port ( usually the client ). Server/client respond with a frame that has TCP.FIN and TCP.ACK flags set to 1 meaning it acknowledges first FIN and it also will close its port. And this is a graceful disconnection

TCP connection troubleshoot

TCP Resets

TCP resets represent frames in which source machine tells destination machine that its port is not available. This frame is sent as a response to a previous frame and its like an inverted ACK. For each TCP frame with payload there must be an acknowledgment frame from destination in order for the sender of the payload to know that destination successfully received all data. If destination is not available for some reason (its port has closed, etc) a RESET frame will be generated and sent.

TCP Retransmissions

Whenever a TCP frame is sent by a source to a destination, source expects an ACK from destination in order to be certain that information was received. When a session is already established be it an https session or TCP session etc., source does not wait for destination to reply to each packet before sending another one, but when it comes to handshakes which are necessary for sessions to be established, source waits for ACK for each packet as it needs information within reply to send the next packet In such a case, let’s say source sends a packet (ex. Client Hello) and awaits for Server Hello frame. It waits a certain amount of time (usually 3-4 x “round-trip”) and if no answer is received it resends same frame and this can be seen as “[TCP Retransmission]” and marked with black background in Wireshark as it is a TCP error. (If round-trip is let’s say 85ms, retransmission time-out a.k.a. RTO might be around 300ms).

If retransmission is needed during a TCP handshake it means that the round-trip is not yet determined and timeout in this case depends on TCP stack and it usually is around 500ms. TCP Retransmissions are of multiple types (spurious, fast retransmissions) but they all follow rules above

Common Wireshark filters

These are the basics I could think of about Wireshark, if you want to learn about encryption and more exactly how you can decrypt traffic which you can view in wireshark as most of it is encrypted, check this