Linux Command - tcpdump/ethereal/wireshark

show the packets with specified length
# tcpdump -nvi eth0 port ssh and greater 1500

//tcpdump filter which tcp header src port isn't 3389 and destination port isn't 3389 too.
tcpdump -n -N -i eth1 tcp[0:2] != 3389 and tcp[2:2] != 3389

tcpdump -n -N -i eth1 tcp[0:2] = 445 or tcp[2:2] = 445

tcpdump -n -N -i eth1 'tcp[0:2]!=161 and tcp[2:2]!=161 and tcp[0:2]!=445 and tcp[2:2]!=445 and tcp[0:2]!=139 and tcp[2:2]!=139'



//下面兩個例子都是要求tcpdump去capture src/dest port > 1024 並且不等於3389port的connection
tcpdump -n -N -i eth1 'tcp[0:2] & 0xfc00!=0 and tcp[2:2] & 0xfc00!=0 and tcp[0:2]!=3389 and tcp[2:2]!=3389'

tcpdump -n -N -i eth1 'tcp[0:2]>1024 and tcp[2:2]>1024 and tcp[0:2]!=3389 and tcp[2:2]!=3389'


將tcpdump 的內容寫到檔案，以供tcpreplay 或 ethereal 來寫
tcpdump -n -i br0 ip host 170.116.11.94 and port 80 -w file

看某一個特定subnet
tcpdump -n -i br0 ip net 192.168.200.0/24

TCP Flags
URG ACK PSH RST SYN FIN
## tcp[13]==17 --> FIN, ACK
## tcp[13]==2 --> SYN
## tcp[13]==18 --> SYN, ACK
## tcp[13]==4 --> RST
# tcpdump -n -i br0 host 192.168.200.1 and tcp[13]==17 or tcp[13]=2

將tcpdump 的內容寫到檔案，以供tcpreplay 或 ethereal 來寫
tcpdump -n -i br0 ip host 170.116.11.94 and port 80 -w file


關於tcpdump 抓檔時, 所設定的-s snaplength 過小時, tcpreplay 在replay traffic 時, 會有的處理方式
tcpdump -s snaplen

tcpreplay -u
can be
pad -- pad the end of the packet with zeros
trunc -- re-adjusting the length in the IP header

-u or untruncate
When a packet is truncated in the capture file because the snaplen was too small, this option will pad the end of the packet with zeros, or truncate (trunc) it by re-adjusting the length in the IP header. The trunc option will only alter IPv4 packets, all others will be sent unmodified.

tcpreplay -R
tcpreplay -r , ex.
# tcpreplay -r 30
tcpreplay -m 0.1

Some early experience
//使用前須先執行，經過測試好像不用執行這行指令也可以work的樣子，不是很確定
//將eth0 interface設定為promisc mode，亦即網路上所有流經本地端的封包，都會被parsing
#ifconfig eth0 promisc

//將interface eth的promisc mode disable
#ifconfig eth0 -promisc

//不要使用promiscuous mode的情形下來節取packet，尚在測試中，不是很確定
#tcpdump -p

//dump source ip address 為 143.158.11.94的packet
#tcpdump src host 143.158.11.94

//dump source ip address & destination ipaddress為143.158.11.96的packet
#tcpdump host 143.158.11.96

//dump source port & destination port為80的packet
#tcpdump port 80

//dump destination network為143.158.11.0/24 的packet
# tcpdump dst net 143.158.11.0/24

# tcpdump -nvi eth2 ip net 172.16.0.0/16

>> dump a network wioth specified netmask
#./tcpdump -i wan1 -s 0 net 198.145.245.0 mask 255.255.255.0 -w aaa.pcap
>> or like this format
#./tcpdump -i wan1 -s 0 net 198.145.245.0/24 -w aaa.pcap

promiscuous mode 是指 ethernet card 接收全部 packet 的一種模式，正常的情況, ethernet card 是用 mode 3.

ethernet card 的receive mode 有:

01h turn off receiver
02h receive only packes sent to this interface
03h mode 2 plus broadcast packets
04h mode 3 plus limited multicast packets
05h mode 3 plus all multicast packets
06h all packets(promiscuous mode)
07h raw mode for serial line only(v1.10+)

你可能執行類似 tcpdump 的網路監聽程式, 才會有上述的 error mesg

網卡可以置一種模式叫混雜模式（promiscuous），在這種模式下工作的網卡能夠接收到一切通過它的數據，而不管實際上數 據的目的地址是不是他。這實際上就是我們SNIFF工作的基本原理：讓網卡接收一切他所能接收的數據。

Q. How to set network card in the promiscuous mode?
A.
# ifconfig eth0 promisc
// Be sure to replace "eth0" with your own network interface in case it's "wlan0" or something else.
// To remove promiscuous mode, type:
# ifconfig eth0 -promisc

ethereal/wireshark Analyzes => Display Filters can input the filtering rule to search the specified packets
e.g.
* tcp.flags.reset == 1
* tcp.len >= 1500
* frame.number==24333 (each packet is called a frame in the ethereal/wireshark, so we can use frame as the display filter component
* tcp.analysis.flags (use wireshark tcp analysis result)
* tcp.analysis.lost_segment
* tcp.analysis.retransmission
* tcp.analysis.fast_retransmission
* cdp.checksum_bad==1 || edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1


Advanced wireshark search tips
include:
Display filter:
e.g.
frame contains fe:3d:dd:36
or other display filtering rules
Hex value:
fe:3d:dd:36 or fe3ddd36
String:
"babala" (guessing usage...)

ipv6 filtering rules in the wireshark
icmpv6
ipv6.src
ipv6.dst

ipv6.addr == ff02::1:2


We can setup the coloring rule in the wireshark to separate the different packets type in the following method.
Select View -> Coloring Rules
Setup the coloring rules to display different color according the filtering rules.

wireshark will sniff all the packets destinated the Network Card buffer. And print the packets in the raw socket format.

We can disable the TCP checksum verification by the following steps:
1. Select Edit->Preferences
2. Select protocols -> TCP from the left frame of current window
3. Disable the option of "Validate the TCP checksum if possible"
Then the checksum error of TCP packets will be ignored by the wireshark.

TCP principle
* TCP often send an ACK packet while received a data packet, the acknowlegement number is the received packet sequence number plus received packet payload length.

* Sometimes TCP will send an Cumulative ACK if a preACK is not yet sent out because the data of sender is quickly enough (often less than 500 ms)
(According the RFC documents: TCP ACK generation[RFC 1122, RFC 2581])

* TCP will send a duplicated-ACK while it receive a miss-order packet (miss one packet and receive the afterward packet, wireshark call "TCP Previous segment lost").

* After receive a out-of-order packet (missing the previous packets, wireshark label "TCP Previous segment lost"), the wireshark will label all the following received packet "TCP Retransmission" until the packet sequence of previous received out-of-order packet.

* In wireshark, after receiving a packet labeled "TCP Previous segment lost", packet "MPacket". And then immediately (<0.001) TCP Out-Of-Order" and not call it "TCP Retransmission". Because just invert these two packet receiving time, the tcp sequence order will be correct.

Some different tcp analysis in the wireshark
Dup ACK (Due to miss a packet of a next sequence number, this is labeled a "TCP Previous segment lost" in the wireshark)
Retransmission (Due to happen the specified RTT timeout and no ack received)
Fast Retransmission (Due to receive 3 ack packet with the same acknowledgement number) TCP Previous segment lost (Due to miss a packet which should in the next order, but receive a wrong order packet)


Refer the Fast Retransmission description as following:
http://en.wikipedia.org/wiki/Fast_retransmit

Fast Retransmit is an enhancement to TCP which reduces the time a sender waits before retransmitting a lost segment.
A TCP sender uses timers to recognize lost segments. If an acknowledgement is not received for a particular segment within a specified time (a function of the estimated Round-trip delay time), the sender will assume the segment was lost in the network, and will retransmit the segment.
The fast retransmit enhancement works as follows: 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, and will not arrive out of order. The sender will then retransmit the packet that was presumed dropped before waiting for its timeout.