Wireshark

Wireshark ve Wifi
Wifi infrastrucutre modda ise bana gelmeyen management paketlerini de dinleyebilir. Açıklaması şöyle

You can tell if you are in monitor mode because you will be capturing management frames. In infrastructure mode, you only see data that the AP is sending you.

Dissector Nedir
Açıklaması şöyle

Wireshark uses pieces of code it calls dissectors to analyze packets and provide the information given in the packet details. These get added to and updated regularly by the community and developers of Wireshark.

Help -> About Wireshark -> Folders sekmesine gelinir. "Personal Lua Plugins" satırında dissector olarak kullanılacak Lua betik dosyasının kopyalamaması gereken dizin belirtilir. Örneğin bende bu dizin şöyle

C:\Users\acelya\AppData\Roaming\Wireshark\plugins

Örnek

Bir seferinde bir dissector dosyasını değiştirmek gerekmişti. Nmea 0183 mesajını TCP üzerinden 9000 numaralı porta gönderip "pcapnp" formatında kaydetmiştim. Elimdeki dissector ise UDP ve başka bir port için çalışıyordu. Dosyanın sonundaki satır şöyleydi

-- Register the dissector
udp_table = DissectorTable.get("udp.port")
udp_table:add(5018,NMEAPROTO)
udp_table:add(2000,NMEAPROTO)

Bu satırı şöyle yaptım

-- Register the dissector
tcp_table = DissectorTable.get("tcp.port")
tcp_table:add(9000,NMEAPROTO)

Bu satırı şöyle yaptım

"Apply As Column" Popup
Filtreleme yapıldıktan sonra paketlerdeki belirli bir alanı sütun olarak görmek için kullanılır.

Statistics Menu
Kaç tane farklı sunucuya erişim yaptığımızı görmek için şöyle yaparız.

Statistics/Endpoints

veya şöyle yaparız.

Statistics/Conversations

IP Filtreleme
Sadece protokole göre şöyle yaparız.

smtp

Display filter ile şöyle yaparız.

(ip.addr==1.2.3.4) and (http or dns)

Display filter ile şöyle yaparız

ip.dst = 192.168.100.100 && udp.dstport = 3000

SNMP Filtreleme
Şöyle yaparız

snmp.value.ipv4 (or snmp.value.ipv6)

TCP Filtreleme
Capture filter ile şöyle yaparız.

src a.b.c.d and tcp port 20000

Capture filter ile şöyle yaparız.

tcp port smtp

Display filter ile şöyle yaparız.

tcp.port == 25

Display filter ile şöyle yaparız.

ip.dst==192.168.1.2 && (tcp.flags.reset==1 || tcp.flags.fin==1)

TCP Relative Sequence Number
Wireshark TCP'deki gerçek Sequence Number değerlerini göstermek yerine daha okunabilir bir sayı gösteriyor. Açıklaması şöyle

TCP Relative Sequence Numbers & TCP Window Scaling

By default Wireshark and TShark will keep track of all TCP sessions and convert all Sequence Numbers (SEQ numbers) and Acknowledge Numbers (ACK Numbers) into relative numbers. This means that instead of displaying the real/absolute SEQ and ACK numbers in the display, Wireshark will display a SEQ and ACK number relative to the first seen segment for that conversation.

This means that all SEQ and ACK numbers always start at 0 for the first packet seen in each conversation.

This makes the numbers much smaller and easier to read and compare than the real numbers which normally are initialized to randomly selected numbers in the range 0 - (2^32)-1 during the SYN phase.

This usability feature relies on features from TCP_Analyze_Sequence_Numbers so in order to use this feature you must also enable TCP_Analyze_Sequence_Numbers.

Using relative sequence numbers is a usability enhancement, making the numbers easier to read and compare. In order to compare a dissection with data from a less advanced analyzer that can not handle relative sequence numbers it might be required to temporarily disable this feature in Wireshark.

For Wireshark versions prior to 1.5: When the Relative Sequence Numbers preference is enabled Wireshark will also enable "Window Scaling".

For Wireshark 1.5 & newer: "Window Scaling" is a separate TCP preference enabled by default.

If "Window Scaling" is enabled, Wireshark will try to monitor the TCP Window Scaling option negotiated during the SYN phase and if such TCP Window Scaling has been detected, Wireshark will also scale the window field and translate it to the effective window size. This may affect what the dissected and reported window is and may make Wireshark to decode packets differently, but more accurately, than other tools.

To disable relative sequence numbers and instead display them as the real absolute numbers, go to the TCP preferences and untick the box for

relative sequence numbers.

TCP Retransmission
Tekrar gönderilen paketleri görmek için şöyle yaparız.

tcp.analysis.retransmission

Tekrar gönderilen paketler için Wirehark bazen Retransmission bazen de Fast Retransmission metnini gösterir.

Fast Retransmission
Eğer alan taraf paket sırasında atlama olduğunu saptarsa TCP Duplicate Ack göndererek hangi paketi alamadığını belirtir. Açıklaması şöyle

The use of TCP Fast Retransmission which is a mechanism by which a receiver can indicate that it has seen a gap in the received sequence numbers that implies the loss of one or more packets in transit. The repeated acknowledgements at the last known value before the gap signal which packets the sender should retransmit. This can occur without waiting for the acknowledgement timeout for the lost packet to hit on the transmitter - which, as the name implies, means recovering a lot faster.

It's also possible that the same symptom of gaps in sequence numbers might be seen in a situation where packets are being delivered out of order. As above, if the receiver sees (for example) a segment with sequence #5 followed by another with #7 before seeing sequence #6 then it might try to begin to trigger a fast retransmit. Upon seeing #6 arrive, though, it would stop sending the duplicate acknowledgements.

Bu yöntem paketin zaman aşımına uğramadan tekrar gönderilmesini sağlar. Açıklaması şöyle

The advantage of TCP Fast Retransmission is that it doesn't wait for the packet timeout to initiate a transmission and hence a faster retransmission of packet, as the name also suggests.

Paketlerin sıraları dışında gelmesi veya paket kaybı için açıklama şöyle

If you're seeing a few random duplicate ACK's but no (or few) actual retransmissions then it's likely packets arriving out of order. If you're seeing a lot more duplicate ACK's followed by actual retransmission then some amount of packet loss is taking place. Both situations are, unfortunately, entirely possible on the global Internet. If you're seeing other kinds of duplicate packets as CRC issues and generally slow performance then it might make sense to look at link issues on your own network.

3 tane TCP Duplicate Ack Negative Ack anlamına gelir. Açıklaması şöyle

if a TCP sender receives three duplicate acknowledgements with the same acknowledge number (that is, a total of four acknowledgements with the same acknowledgement number), the sender can be reasonably confident that the segment with the next higher sequence number was dropped

Yani aslında Negative ACK göndermekle aynı. 

Retransmission

Paket zaman aşımına uğramıştır ve tekrar gönderilir.