the-tcpdump-group/tcpdumpTCPdump 네트워크 디섹터
보안 문제를 신고하려면 [email protected]로 이메일을 보내 주십시오.
버그 및 기타 문제를 보고하거나, 패치를 기여하거나, 기능을 요청하거나, 일반적인 피드백을 제공하려면 tcpdump 소스 트리 루트에 있는 기여 지침을 참조하십시오.
익명 Git은 다음을 통해 이용할 수 있습니다
https://github.com/the-tcpdump-group/tcpdump.git
이 디렉터리에는 네트워크 모니터링 및 데이터 수집 도구인 tcpdump의 소스 코드가 포함되어 있습니다.
지난 몇 년 동안 tcpdump는 인터넷 커뮤니티의 훌륭한 기여 덕분에 꾸준히 개선되어 왔습니다(변경 로그를 살펴보십시오). 모든 기여에 감사드립니다.
많은 운영 체제에서 tcpdump는 네이티브 패키지 또는 포트로 제공되므로 업데이트 설치와 장기 유지 관리가 간단합니다. 그러나 네이티브 패키지는 때때로 몇 버전 뒤처져 있으며, 더 최신 스냅샷을 사용해 보려면 소스 코드에서 tcpdump를 컴파일해야 합니다.
tcpdump는 최소한 다음 플랫폼에서 컴파일되고 작동합니다:
과거에 tcpdump가 확실히 또는 아마도 작동했던 플랫폼은 다음과 같습니다:
tcpdump는 사용자 수준 패킷 캡처를 위한 시스템 독립적 인터페이스인 libpcap을 사용합니다. 운영 체제가 libpcap을 제공하지 않거나, libpcap 1.0 이상의 API를 지원하지 않는 libpcap을 제공하는 경우, tcpdump를 빌드하기 전에 먼저 libpcap을 가져와 빌드해야 합니다.
libpcap이 빌드되면(설치하거나 ../libpcap에 있는지 확인),
설치 노트의 절차에 따라 tcpdump를 빌드할 수 있습니다.
이 프로그램은 SMI의 "etherfind"를 느슨하게 기반으로 하지만 etherfind 코드는 전혀 남아 있지 않습니다. 원래 Van Jacobson이 TCP 및 인터넷 게이트웨이 성능을 조사하고 개선하기 위한 진행 중인 연구 프로젝트의 일환으로 작성했습니다. 원래 Sun의 etherfind에서 가져온 프로그램의 일부는 나중에 LBL의 Steven McCanne이 다시 작성했습니다. tcpdump에 독점 코드의 흔적이 남지 않도록 하기 위해 Steve는 tcpdump나 etherfind의 소스에 접근하지 않은 채 매뉴얼 항목에 주어진 명세로부터 이 부분들을 작성했습니다.
formerly from Lawrence Berkeley National Laboratory
Network Research Group <[email protected]>
ftp://ftp.ee.lbl.gov/old/tcpdump.tar.Z (3.4)
Richard Stevens는 자신의 저서 *"TCP/IP Illustrated, Volume 1"*에서 인터넷 프로토콜을 훌륭하게 다룹니다. tcpdump와 그 출력을 해석하는 방법에 대해 더 배우고 싶다면 이 책을 구해 보십시오.
tcpdump 사용자에게 유용할 수 있는 또 다른 도구는 tcpslice입니다. 이 프로그램은 tcpdump 바이너리 추적 파일의 일부를 추출하는 데 사용할 수 있습니다.
This directory also contains some short awk programs intended as
examples of ways to reduce tcpdump data when you're tracking
particular network problems:
send-ack.awk
Simplifies the tcpdump trace for an ftp (or other unidirectional
tcp transfer). Since we assume that one host only sends and
the other only acks, all address information is left off and
we just note if the packet is a "send" or an "ack".
There is one output line per line of the original trace.
Field 1 is the packet time in decimal seconds, relative
to the start of the conversation. Field 2 is delta-time
from last packet. Field 3 is packet type/direction.
"Send" means data going from sender to receiver, "ack"
means an ack going from the receiver to the sender. A
preceding "*" indicates that the data is a retransmission.
A preceding "-" indicates a hole in the sequence space
(i.e., missing packet(s)), a "#" means an odd-size (not max
seg size) packet. Field 4 has the packet flags
(same format as raw trace). Field 5 is the sequence
number (start seq. num for sender, next expected seq number
for acks). The number in parens following an ack is
the delta-time from the first send of the packet to the
ack. A number in parens following a send is the
delta-time from the first send of the packet to the
current send (on duplicate packets only). Duplicate
sends or acks have a number in square brackets showing
the number of duplicates so far.
Here is a short sample from near the start of an ftp:
3.00 0.20 send . 512
3.20 0.20 ack . 1024 (0.20)
3.20 0.00 send P 1024
3.40 0.20 ack . 1536 (0.20)
3.80 0.40 * send . 0 (3.80) [2]
3.82 0.02 * ack . 1536 (0.62) [2]
Three seconds into the conversation, bytes 512 through 1023
were sent. 200ms later they were acked. Shortly thereafter
bytes 1024-1535 were sent and again acked after 200ms.
Then, for no apparent reason, 0-511 is retransmitted, 3.8
seconds after its initial send (the round trip time for this
ftp was 1sec, +-500ms). Since the receiver is expecting
1536, 1536 is re-acked when 0 arrives.
packetdat.awk
Computes chunk summary data for an ftp (or similar
unidirectional tcp transfer). [A "chunk" refers to
a chunk of the sequence space -- essentially the packet
sequence number divided by the max segment size.]
A summary line is printed showing the number of chunks,
the number of packets it took to send that many chunks
(if there are no lost or duplicated packets, the number
of packets should equal the number of chunks) and the
number of acks.
Following the summary line is one line of information
per chunk. The line contains eight fields:
1 - the chunk number
2 - the start sequence number for this chunk
3 - time of first send
4 - time of last send
5 - time of first ack
6 - time of last ack
7 - number of times chunk was sent
8 - number of times chunk was acked
(all times are in decimal seconds, relative to the start
of the conversation.)
As an example, here is the first part of the output for
an ftp trace:
# 134 chunks. 536 packets sent. 508 acks.
1 1 0.00 5.80 0.20 0.20 4 1
2 513 0.28 6.20 0.40 0.40 4 1
3 1025 1.16 6.32 1.20 1.20 4 1
4 1561 1.86 15.00 2.00 2.00 6 1
5 2049 2.16 15.44 2.20 2.20 5 1
6 2585 2.64 16.44 2.80 2.80 5 1
7 3073 3.00 16.66 3.20 3.20 4 1
8 3609 3.20 17.24 3.40 5.82 4 11
9 4097 6.02 6.58 6.20 6.80 2 5
This says that 134 chunks were transferred (about 70K
since the average packet size was 512 bytes). It took
536 packets to transfer the data (i.e., on the average
each chunk was transmitted four times). Looking at,
say, chunk 4, we see it represents the 512 bytes of
sequence space from 1561 to 2048. It was first sent
1.86 seconds into the conversation. It was last
sent 15 seconds into the conversation and was sent
a total of 6 times (i.e., it was retransmitted every
2 seconds on the average). It was acked once, 140ms
after it first arrived.
stime.awk
atime.awk
Output one line per send or ack, respectively, in the form
<time> <seq. number>
where <time> is the time in seconds since the start of the
transfer and <seq. number> is the sequence number being sent
or acked. I typically plot this data looking for suspicious
patterns.
The problem I was looking at was the bulk-data-transfer
throughput of medium delay network paths (1-6 sec. round trip
time) under typical DARPA Internet conditions. The trace of the
ftp transfer of a large file was used as the raw data source.
The method was:
- On a local host (but not the Sun running tcpdump), connect to
the remote ftp.