TCPDUMP(1)

명칭
tcpdump - 네트워크상의 트래픽 데이터의 덤프

서식
tcpdump [ -adeflnNOpqRStuvxX ] [ -c count ]
[ -C file_size ] [ -F file ]
[ -i interface ] [ -m module ] [ -r file ]
[ -s snaplen ] [ -T type ] [ -w file ]
[ -E algo:secret ] [ expression ]

해설

tcpdump 는, 옵션으로 지정된 네트워크 인터페이스상에서 취득 가능한 패킷의 헤더 중 expression 에 매치 하는 것을 출력 합니다. 패킷 데이터를 다음에 분석하기 (위해)때문에 파일에 보존하도록, -w 플래그로 실행할 수도 있습니다. 또, -r 플래그로, 네트워크 인터페이스로부터의 패킷이 아니고, 파일에 보존된 패킷으로부터 읽어들일 수가 있습니다. 모든 경우에, expression 에 매치 하는 패킷만, tcpdump 에 의해 처리됩니다.

tcpdump (은)는, -c 플래그로 실행하지 않는 경우, SIGINT 시그널 ( 예를 들면, 일반적인 수법으로서 세치기 캐릭터 라인인 control-C 의 입력)인가 SIGTERM 시그널 (일반적인 수법으로서 kill(1) 명령) 에 의해 세치기가 있을 때까지, 패킷을 계속 포착합니다. -c 플래그로 실행하는 경우는, SIGINT 시그널이나 SIGTERM 시그널로 끼어들어 되는지, 지정된 패킷수까지 처리합니다.

tcpdump 하지만 패킷의 포착을 종료했을 때, 이하의 합계를 표시합니다.

    packets ``received by filter'' (이 의미는, tcpdump (을)를 실행하고 있는 OS 에 의존하고, 아마 OS 의 배치 방법에도 의존하겠지요. filter 가 명령행으로 지정되었을 경우, 어느 OS 에서는 그것이 filter expression 에 의해 일치했는지 어떠했는지에 관련되지 않고, 패킷을 셉니다. 또 다른 OS 에서는, filter expression 에 의해 일치했을 경우만 tcpdump 에 의해 처리된 패킷만을 셉니다. )

    packets ``dropped by kernel'' (OS 가 어플리케이션에 그 정보를 보고하는 경우에는, 버퍼 스페이스의 부족에보다 , tcpdump 하지만 달리고 있는 OS 의 패킷 capther 제어 기구로부터, 떨어져 버린 패킷 의 수입니다. 그 이외의 경우에는, 0 이 표시됩니다. )

대체로의 BSD 와 같은 SIGINFO 시그널이 서포트되고 있다 플랫폼에서는, SIGINFO 시그널 (예를 들면, 일반적인 수법으로서 ``상태''캐릭터 라인인 control-T 의 입력) (을)를 수신했을 때, 그러한 합계를 표시해, 패킷의 포착을 계속해 실시합니다.

네트워크 인터페이스로부터 패킷을 읽으려면 , 권한을 필요로 합니다.

SunOS 3. x, 4. x 상의 NIT 없고 BPF 의 경우:
    /dev/nit 없고 /dev/bpf* 에의 읽기 액세스권이 필요합니다.

Solaris 상의 DLPI 의 경우:
    /dev/le 등의 네트워크 가상 디바이스에의 읽고 쓰기 액세스권이 필요합니다. 적어도 Solaris 의 몇개의 버젼상에서는, tcpdump 하지만 promiscuous-mode 로 포착하려면 , 이 조건만으로는 불충분합니다. 그러한 Solaris 의 버젼에서는, root 가 될 필요가 있습니다. 혹은 promiscuous-mode 로 포착하려면 root 에 setuid 되어 인스톨 되고 있는 경우만 tcpdump 의 실행이 가능하게 됩니다.

HP-UX 상의 DLPI 의 경우:
    사용자가 root 인지, tcpdump 하지만 root 에 setuid 되어 인스톨 되고 있는 경우만 실행 가능합니다.

IRIX 상의 snoop 의 경우:
    사용자가 root 인지, tcpdump 하지만 root 에 setuid 되어 인스톨 되고 있는 경우만 실행 가능합니다.

Linux 의 경우:
    사용자가 root 인지, tcpdump 하지만 root 에 setuid 되어 인스톨 되고 있는 경우만 실행 가능합니다.

Ultrix 및 Digital UNIX 의 경우:
    슈퍼 유저가, pfconfig(8) (을)를 이용해 promiscuous-mode 에서의 조작을 허가하고 있으면, 어느 유저도 tcpdump. (을)를 사용해, 네트워크 트래픽을 포착 가능하게 됩니다.

BSD 의 경우:
    /dev/bpf* 에의 읽기 액세스권이 필요합니다.

보존된 패킷 파일을 읽으려면 , 권한을 필요로 하지 않습니다.

옵션

-a  네트워크 주소와 브로드캐스트 어드레스를 이름으로 변환하려고 합니다.

-c  count 로 지정한 수의 패킷을 수신한 후에 종료합니다.

-C  보존 파일에 raw 패킷을 기입하기 전에, 현재의 파일이 file_size 보다 큰지 어떤지 (을)를 체크합니다. 만약 크면, 현재의 보존 파일을 닫아 새로운 것을 엽니다. 붙일 수 있는 파일명은, 최초의 보존 파일을 제외하다 2 번째 이후의 보존 파일로부터 -w 플래그로 지정된 파일명의 후에 각각 번호가 다합니다. 그 번호는, 2 로부터 시작되어 순서에 커집니다. file_size 의 단위는 100 만 바이트 (1,000,000 바이트. 1,048,576 바이트의 것은 아니다)입니다.

-d  해석된 패킷 매칭 코드를 읽기 쉬운 형태에 정형한 후, 표준 출력에 덤프 해 정지합니다.

-dd C 프로그램의 단편의 형태로 패킷 매칭 코드를 덤프 합니다.

-ddd
    (선두에 개수를 부가한) 십진수의 형태로 패킷 매칭 코드를 덤프 합니다.

-e  각 덤프행 마다, 링크 레벨의 헤더를 출력합니다.

-E  algo:secret 를, IPsec ESP 패킷의 해독에 사용합니다. 알고리즘은 des-cbc, 3des-cbc, blowfish-cbc, rc3-cbc, cast128-cbc, none 의 머지않아인가입니다. 디폴트는 des-cbc 입니다. 패킷 해독 능력은, tcpdump 가 암호 기능부로 컴파일 되었을 경우만 존재합니다. secret 는, ESP 비밀열쇠의 ASCII 텍스트입니다. 현상, 임의의 2 진수치를 사용할 수 없습니다. 본옵션은, RFC1827 ESP 가 아니고, RFC2406 ESP 를 가정합니다. 본옵션은, 디버그 전용이며, 진짜 「비밀」열쇠에 대한 사용은 권유받지 않습니다. IPset 비밀열쇠를 명령행에 두면(자), ps(1) 등에 의해 다른 사람으로 보여 버립니다.

-f  외부 호스트의 IP 주소에 대해서는, 심볼이 아니고 수치로 표시합니다. (본옵션은, Sun 의 yp 서버에 중대한 장해가 발생하는 것을 회피하는 와 (을)를 의도하고 있습니다. — 통상은, Sun 의 yp 서버는, 로컬에 존재하지 않는다 IP 주소를 계속 영구히 변환해 헹 합니다. )

-F  필터의 표현으로서 file 에 기술되어 있는 내용을 이용합니다. 명령행으로 지정된 추가 표현은, 무시됩니다.

-i  interface 로 지정된 인터페이스를 감시합니다. 지정되지 않는 경우에는, tcpdump 는 시스템 인터페이스 리스트 중(안)에서 가장 작은 번호의 가동중의 것을 검색해, 감시하는 인터페이스로서 설정 합니다 (루프백 인터페이스는 검색하지 않습니다). 이 동작은, 최초로 인터페이스가 선택된 시점에서 종료합니다.

    2.2 이후의 커널의 Linux 시스템에서는, interface 인수 ``any''를 지정해 전인터페이스로부터의 패킷을 포착 가능합니다. ``any''디바이스에서의 포착은, promiscuous-mode 는 아닌 것에 주의해 주세요.

-l  표준 출력을 행 버퍼링으로 합니다. 데이터를 포착하면서, 그 데이터를 보고 싶은 경우에는, 본옵션은 유효합니다. 예를 들면
    ``tcpdump -l | tee dat''나 ``tcpdump -l > dat & tail -f dat'' (와)과 같이 사용합니다.

-m  SMI MIB 모듈의 정의를, 파일 module 로부터 로드합니다. 복수의 MIB 모듈을 tcpdump 에 로드하기 위해서(때문에), 여러 차례 이 옵션을 사용할 수가 있습니다.

-n  주소 (IP 주소나 포트 번호등)를 이름으로 변환하지 않습니다.

-N  호스트명 가운데, 도메인명의 표시를 하지 않습니다. 예를 들면, 본옵션을 지정하면(자), ``nic.ddn.mil''와는 표시되지 않고, 대신에 ``nic''와만 표시해

-O  패킷 매칭 코드의 오프티마이자를 움직이지 않습니다. 본옵션은, 오프티마이자중의 버그를 의심하는 경우에게만 유효한 것입니다.

-p  네트워크 인터페이스를, promiscuous mode 로 설정하지 않습니다. 네트워크 인터페이스는, 어떠한 이유에 의해 promiscuous mode 로 설정 되는 일도 있기로 주의해 주세요. 그러므로 `-p' 옵션은, `ether host {local-hw-addr} or ether broadcast' 의 단축형으로서 사용할 수 없습니다.

-q  민첩하다 (조용한? ) 출력을 행합니다. 출력하는 행을 짧게 하기 위해서, 통상 출력 되는 프로토콜 정보의 일부는 출력되지 않습니다.

-R  ESP/AH 패킷이 낡은 사양 (RFC1825 로부터 RFC1829)에 따르고 있는 것과 가정합니다. 지정하면(자), tcpdump 는 릴레이 방지 필드를 표시하지 않습니다. ESP/AH 사양에는 프로토콜 버젼 필드가 없기 때문에, tcpdump 는 ESP/AH 프로토콜의 버젼을 추정할 수 없습니다.

-r  패킷을, file 로 지정한 파일 (-w 옵션으로 작성됩니다)인가 들 읽어들입니다. file 로서``-''가 지정되었을 경우는 표준 입력이 이용하고들

-S  TCP 순차 순서 번호를 상대 번호가 아니고, 절대 번호로 출력합니다.

-s  디폴트의 68 바이트 (SunOS 의 NIT 에서는 최소치는 실제로는 96)가 아니라, snaplen 만의 데이터를 각 패킷으로부터 취득합니다. 68 바이트라고 한다 데이터 길이는, IP, ICMP, TCP, UDP 의 패킷을 취득하는 분에는 충분합니다만, 네임서버나 NFS 의 패킷에 대해서는 프로토콜 정보를 절약할 수 있는 와 (이)가 있습니다 (이것에 대해서는, 이후의 설명을 참조해 주세요). snapshot가 한정된 양 밖에 취하지 못하고 잘라 채울 수 있었던 패킷은, 출력에 ``[|proto]''라고 하는 캐릭터 라인이 함께 에 표시됩니다. proto 는, 절약하고를 한 프로토콜 레벨의 이름 전입니다. 큰 snapshot를 취하는 경우에는, 그 만큼 패킷 처리때 간이 걸린다고 하는 것으로, 패킷 버퍼링용의 버퍼의 양이 줄어들면(자) 말하는 것에 주의해 주세요. 이것에 의해, 패킷이 소실인가 만약 키 응. snaplen 의 크기를, 필요한 프로토콜 정보를 취득할 수 있는 최소의 값에 세우도록 해 주세요. snaplen 를 0 으로 설정하면(자), 패킷 전체의 포착에 필요한 길이를 사용하는 것을 의미합니다.

-T  "expression" 에 의해 선택된 패킷을 강제적으로 type 로 지정된 타입이라고 해석합니다. 유효한 타입은, cnfp (Cisco NetFlow 프로토콜), rpc (리모트 프로듀서 콜) rtp (리얼타임 어플리케이션 프로토콜) rtcp (리얼타임 어플리케이션 제어 프로토콜) snmp (심플 네트워크 매니지먼트 프로토콜) vat (비주얼 오디오 툴) wb (디 파업 리뷰-테드 화이트 보드) 입니다.

-t  각 덤프행의 타임 스탬프를 출력하지 않습니다.

-tt 각 덤프행 마다 타임 스탬프를 인간이 읽기 쉬운 형태로 변환하지 않고 출력합니다.

-ttt
    직전의 덤프행과 현재의 덤프행의 차분 (마이크로 세컨드 단위)을 표시합니다.

-tttt
    각 덤프행으로, 디폴트 서식에서 타임 스탬프를 표시해, 그 전에 일자를 붙입니다.

-u  디코드되지 않은 NFS 조작을 출력합니다.

-v  (조금입니다만) 출력 정보를 늘립니다. 예를 들면, IP 패킷중의 TTL, 식별, 전체 길이, IP 패킷중의 옵션이 표시됩니다. 추가의 패킷의 완전성 확인이 유효하게 됩니다. 이것은 예를 들면 IP 및 ICMP 의 헤더의 체크 섬입니다.

-vv 한층 더 많은 정보를 출력합니다. 예를 들면, NFS 의 대답 패킷의 추가 필드나 완전하게 디코드된 SMB 패킷 (을)를 출력합니다.

-vvv
    좀 더 많은 정보를 출력합니다. 예를 들면, telnet SB ... SE 옵션이 완전하게 표시됩니다. -X 부착에서는, telnet 옵션이 16 진수로 표시됩니다.

-w  수신한 생 패킷을, 해석하거나 화면에 출력하거나 하지 않고 file 로 지정 한 파일에 출력합니다. 본옵션을 이용해 취득한 패킷은 -r 옵션을 이용하는 것으로 정보를 볼 수가 있습니다. file 로 지정 파일명이 ``-''의 경우에는, 표준 출력을 이용합니다.

-x  링크 레벨 헤더를 제외한 각 패킷의 내용을 16 진출력 합니다. 패킷 사이즈가 snaplen 바이트보다 작은 경우에는 패킷의 전부의 내용을, 그 이외의 경우에는, snaplen 바이트 분의 데이터를 패킷 마다 출력합니다.

-X  16 진출력시에, ASCII 도 또한 표시합니다. -x 도 또한 지정되면(자), 패킷이 16 진수와 ASCII 의 편성으로 표시됩니다. 신규 프로토콜을 해석하는데 매우 편리합니다. -x 하지만 지정되지 않으면 일부의 패킷의 일부가 16 진수와 ASCII 의 편성으로 표시됩니다.

expression
    덤프 하는 패킷을 선택합니다. expression 가 지정되지 않는 경우에는, 네트워크상의 모든 패킷이 덤프 대상이 됩니다. 그 이외의 장소 합에는, expression 의 조건이 실로 되는 패킷만 덤프 합니다.

    expression 는, 1 개(살) 이상의 원시적 (으)로부터 성립됩니다. 원시적은 통상 1 개(살) 이상의 한정자가 붙었다 id (이름 혹은 번호)(으)로부터 성립됩니다. 한정자는, 3 종류 있습니다.

    형   한정자는 id 명이나 번호가 참조하는 것의 종류를 가리킵니다. 형태에는 host, net, port (이)가 있습니다. 예를 들면, `host foo', `net 128.3', `port 20'와 같이 이용합니다. 형태 한정자가 지정되지 않는 경우에는, host 하지만 지정된 것으로 간주해집니다.

    방향  한정자는, 패킷이 id 에 나갈 방향인가, id (으)로부터 올 방향인가, 혹은 그 양쪽 모두일까하고 말하는, 특정의 전송 방향을 지정합니다. 지정 가능한 방향은, src, dst, src or dst, src and dst 의 4 개(살)입니다. 예를 들면, `src foo', `dst net 128.3', `src or dst port ftp-data'와 같이 지정합니다. 만약 방향 한정자가 지정되지 않는 경우에는, src or dst 하지만 지정된 것으로 간주합니다. `null'링크 레이어 (즉, slip 등 포인트·트·포인트·프로토콜) 그럼, 필요한 방향을 지정하는데 inbound (이)나 outbound 한정자를 고용할 수가 있습니다.

    프로토콜
        한정자는, 특정의 프로토콜에 일치하는 패킷에만 제한합니다. 프로토콜로서 지정 가능한 것은, ether, fddi, tr, ip, ip6, arp, rarp, decnet, lat, sca, moprc, mopdl, iso, esis, isis, icmp, icmp6, tcp , udp 입니다. 예를 들면 `ether src foo', `arp net 128.3', `tcp port 21'와 같이 사용 합니다. 만약 프로토콜 한정자가 지정되지 않는 경우에는, 상기의 프로토콜의 쳐, 형태에 모순되지 않는 모든 것이 지정된 것으로 간주합니다. 예를 들면 `src foo'는,`(ip or arp or rarp) src foo' (이것이 올바른 형식 나오는거야 있고 일을 제외해)와 `net bar'는 `(ip or arp or rarp) net bar'와 동의로 , 또 `port 53'는 `(tcp or udp) port 53'와 동의입니다.

    [`fddi'는 실제로는 `ether'의 별명이 되어 있습니다. 해석에서는 이것들을 「특정의 네트워크 인터페이스로 사용되는 데이터 링크 레벨」을 의미하는 것 (으)로서와 같이 취급합니다. FDDI 헤더는 이더넷(ethernet)를 닮은 시점과 종점 주소를 포함해, 그리고 자주 이더넷(ethernet)를 닮은 패킷형을 포함하므로, 이더넷(ethernet)의 필드와 같이 FDDI 의 필드를 필터링 할 수 있습니다. FDDI 헤더는 다른 필드도 포함합니다만, 필터 표현 중(안)에서 명시적으로 그것들을 지정할 수 없습니다.

    같이 `tr'는 `ether'의 별명입니다. 직전의 단락에 있어서의 FDDI 헤더에 관한 기술은, Token Ring 헤더에도 적용됩니다. ]

    상기에 추가해, 몇개의 특별한 「원시적」키워드가 있습니다. 이러한 키워드는 gateway, broadcast, less, greater (와)과 산술 연산 표현 입니다. 이러한 뒤로 패턴이 계속되는 일은 없습니다. 원시적 키워드에 대해서는 후술 합니다.

    보다 복잡한 필터의 표현은, 원시적의 결합에 and, or, not (을)를 이용하는 것으로 실현됩니다. 예를 들면, `host foo and not port ftp and not port ftp-data' 입니다. 타입량을 줄이기 위해서(때문에), 동일한 한정자 리스트는, 생략 하는 것이 가능합니다. 예를 들면, `tcp dst port ftp or ftp-data or domain'는, `tcp dst port ftp or tcp dst port ftp-data or tcp dst port domain' (와)과 같은 의미입니다.

    용서되는 원시적은, 이하와 같습니다.

    dst host host
        IPv4/v6 패킷의 종점 필드가 host 로 지정했지만 경우에, 진이 됩니다. host 는, 호스트명 혹은 IP 주소입니다.

    src host host
        IPv4/v6 패킷의 시점 필드가 host 로 지정했지만 경우에, 진이 됩니다.

    host host
        IPv4/v6 패킷의 시점 필드 혹은 종점 필드가 host 로 지정했지만 경우에, 진이 됩니다. 상기의 host 원시적의 표현에는, ip, arp, rarp, ip6 를 이하와 같이 부가하는 것이 가능합니다.
        ip host host
        그렇다고 하는 표기는,
        ether proto \ip and host host
        (와)과 같은 의미입니다. host 가 복수의 IP 주소를 가지는 호스트명이었을 경우, 각각의 주소 에 붙어 조합을 검사합니다.

    ether dst ehost
        이더넷(ethernet) 패킷의 종점 주소가 ehost 였던 경우에, 진이 됩니다. ehost (은)는, /etc/ethers 에 기술된 이름 혹은 이더넷 어드레스의 값이 이용됩니다 (이더넷 어드레스의 형식에 대해서는, ethers(3N) (을)를 참조).

    ether src ehost
        이더넷(ethernet) 패킷의 시점 주소가 ehost 였던 경우에, 진이 됩니다.

    ether host ehost
        이더넷(ethernet) 패킷의 시점 주소 혹은 종점 주소가 ehost 였다 경우에, 진이 됩니다.

    gateway host
        패킷이 host 로 지정한 주소의 머신을 게이트웨이로 하고 있는 경우에 진이 됩니다. 바꿔 말하면(자), 시점 혹은 종점의 이더넷 어드레스가 host 이며, 시점과 종점의 어느 쪽의 IP 주소도 host 가 아니다 그렇다고 하는 것입니다. host 머신의 host-name-to-IP-address (이름 해석) 제어 기구 (hosts 파일, DNS, NIS 등) (와)과 머신의 host-name-to-Ethernet-address (이더넷(ethernet) 주소 해결) 제어 기구 (/etc/ethers 등) (으)로부터 찾아낼 수 있는 이름일 필요가 있습니다. (동일한 기술은,
        ether host ehost and not host host
        입니다. 이 경우 host / ehost 의 어느 쪽에도 이름 혹은 값을 이용하는 것이 가능하게 됩니다. ) 이 구문은, 현재로서는, IPv6 가 유효한 구성에서는 동작하지 않습니다.

    dst net net
        패킷의 종점 IPv4/v6 주소가, net 로 지정된 네트워크에 속하는 것인 경우에, 진이 됩니다. net 는, 주소치 혹은 /etc/networks 로 정의된 네트워크명의 어느쪽이든을 지정 가능합니다 (자세하게는, networks(4) (을)를 참조).

    src net net
        패킷의 시점 IPv4/v6 주소가, net 로 지정된 네트워크에 속하는 것인 경우에, 진이 됩니다.

    net net
        시점 IPv4/v6 주소 혹은 종점 IPv4/v6 주소가 net 로 지정되었다 네트워크에 속하는 것인 경우에, 진이 됩니다.

    net net mask netmask
        IP 주소가, 지정된 net 및 netmask 의 값으로 정해진다 네트워크에 속하는 것인 경우에, 진이 됩니다. src 나 dst 를 지정하는 일도 가능합니다. 이 구문은 IPv6 net 에서는 정당하지 않은 것에 주의해 주세요.

    net net/len
        IPv4/v6 주소가, 지정된 len 의 bit length의 넷 마스크로 net 에 속하는 네트워크 의 경우에, 진이 됩니다. src 나 dst 를 지정하는 일도 가능합니다.

    dst port port
        패킷이 ip/tcp, ip/udp, ip6/tcp, ip6/udp 의 언젠가여, 종점 포트 번호가 port 의 경우에, 진이 됩니다. port 로 지정되는 포트 번호는, 값 혹은 /etc/services 로 정의 되고 있는 서비스명으로 지정 가능합니다 ( tcp(4P) (이)나 udp(4P) (을)를 참조). 포트 번호가 서비스명에서 지정되었을 경우, 포트 번호와 프로토콜의 양쪽 모두가 체크 대상이 됩니다. 포트 번호나, 애매한 서비스명이 지정되었을 경우에는, 포트 번호만이 체크 대상이 됩니다(예를 들면, dst port 513 는, tcp/login 와 udp/who 의 양쪽 모두를 출력해, port domain 는, tcp/domain (와)과 udp/domain 의 양쪽 모두를 출력합니다).

    src port port
        패킷이 port 로 지정한 시점 포트 번호를 보관 유지하고 있는 경우에 진이 됩니다.

    port port
        패킷의 시점 포트 번호 혹은 종점 포토 번호가 port 의 경우에, 진이 됩니다. 상기의 포트 번호의 지정에 대해서는, 모두 키워드 tcp 만약 구는 udp 를 이용해, 어느 정도 후보를 좁히는 것이 가능합니다. 예를 들면,
        tcp src port port
        (와)과 지정했을 경우에는, tcp 패킷만이 조건 일치의 평가 대상이 됩니다.

    less length
        패킷이 length 로 지정한 길이 이하의 경우, 진이 됩니다. 이것은,
        len <= length
        의 지정과 등가입니다.

    greater length
        패킷이 length 로 지정한 길이 이상의 경우, 진이 됩니다. 이것은,
        len >= length
        (와)과 등가입니다.

    ip proto protocol
        패킷이 protocol 로 지정한 프로토콜형의 IP 패킷 ( 자세한 것은 ip(4P) (을)를 참조)의 경우에, 진이 됩니다. protocol 는, 숫자 혹은 icmp, icmp6, igmp, igrp, pim, ah, esp, vrrp, udp, tcp 의 몇개의 이름이 지정 가능합니다. tcp, udp, icmp 의 각 식별자는 키워드에서도여, backslash (\)(C-shell 에서는 \\)를 용 있어 이스케이프 해야 하는 것에 주의해 주세요. 이 원시적은 프로토콜 헤더 체인을 추적하지 않는 것에 주의해 주세요.

    ip6 proto protocol
        패킷이 프로토콜형 protocol 의 IPv6 패킷인 경우에, 진이 됩니다. 이 원시적은 프로토콜 헤더 체인을 추적하지 않는 것에 주의해 주세요.

    ip6 protochain protocol
        패킷이 IPv6 패킷이며, 프로토콜 헤더 체인중에 타입 protocol 의 프로토콜 헤더가 포함되는 경우에, 진이 됩니다. 예를 들면
        ip6 protochain 6
        (은)는, TCP 프로토콜 헤더가 프로토콜 헤더 체인중에 포함된다 임의의 패킷에 매치 합니다. 패킷중에는, IPv6 헤더와 TCP 헤더의 사이에, 예를 들면, 인증헤더, 루팅 헤더, 호프 마다의 옵션 헤더가 포함될 수 있습니다. 이 원시적이 출력하는 BPF 코드는, 복잡하고 tcpdump 중의 BPF 최적화 코드에서는 최적화할 수 없습니다. 따라서, 이 동작은 조금 늦습니다.

    ip protochain protocol
        ip6 protochain protocol 와 같아, IPv4 의 것입니다.

    ether broadcast
        패킷이 이더넷(ethernet) 브로드캐스트 패킷의 경우에, 진이 됩니다. ether 키워드는, 생략 가능합니다.

    ip broadcast
        패킷이 IP 브로드캐스트 패킷의 경우에, 진이 됩니다. 올 1 으로 올 0 의 두 개의 형식의 브로드캐스트 어드레스를 검사해, 그리고 로컬 subnet mask를 조사합니다.

    ether multicast
        패킷이 이더넷(ethernet) 멀티 캐스트 패킷의 경우에, 진이 됩니다. ether 키워드는, 생략 가능합니다. 덧붙여 이 지정은, `ether[0] & 1 ! = 0'의 단축계입니다.

    ip multicast
        패킷이 IP 멀티 캐스트 패킷의 경우에, 진이 됩니다.

    ip6 multicast
        패킷이 IPv6 멀티 캐스트 패킷의 경우에, 진이 됩니다.

    ether proto protocol
        패킷이 protocol 로 지정한 ether 형의 경우에, 실로 됩니다. protocol 는, 숫자 혹은 ip, ip6, arp, rarp, atalk, aarp, decnet, sca, lat, mopdl, moprc, iso, stp, ipx, netbeui 의 몇개의 이름을 지정 가능합니다. 이러한 식별자는 키워드이기도 해, backslash (\)로 이스케이프 해 없으면 안 되는 것에 주의해 주세요.

        [FDDI (예를 들면 `fddi protocol arp')나 Token Ring ( 예를 들면 `tr protocol arp') , 이러한 대부분의 프로토콜의 경우, 프로토콜의 식별은 IEEE802. 2 의 논리 링크제 (LLC) 헤더에 의해 행해집니다. 통상 이것은 FDDI 헤더나 Token Ring 헤더 위의 층에 있습니다.

        FDDI 또는 Token Ring 의 대부분의 프로토콜 식별 (을)를 필터링 할 때, tcpdump 는 Ethernet 를 캡슐화하기 위해서 LLC 헤더의 프로토콜 ID 범위만, 이른바 SNAP 포맷이다 관리 조직 식별자 (OUI)의 0x000000 의 범위만을 체크합니다. 패킷이 SNAP 포맷이다 OUI 의 0x000000 에 있을까 어떤가는 체크하지 않습니다.

        예외는 이하와 같습니다. iso 는 LLC 헤더의 DSAP (Destination Service Access Point) (와)과 SSAP (Source Service Access Point)의 범위도 체크합니다. stp 및 netbeui 는, LLC 헤더의 DSAP 를 체크합니다. atalk 는, SNAP 포맷인 OUI 의 0x080007 라고 Appletalk etype 에 대해서 체크합니다.

        Ethernet 의 경우, tcpdump 는, 이러한 프로토콜의 대부분에 대해서 Ethernet 형의 범위를 체크합니다. 예외는 이하와 같습니다. iso, sap 및 netbeui 에서는 FDDI 및 Token Ring 의 경우와 같게 802.3 프레임을 체크해, 다음에 LLC 헤더를 체크합니다. atalk 에서는 FDDI 및 Token Ring 의 경우와 같게 Ethernet 프레임내의 Appletalk etype 및 SNAP 포맷 패킷의 양쪽 모두에 대해서 체크합니다. aarp 에서는 Ethernet 프레임 또는 802.3 SNAP 프레임이다 OUI 의 0x000000 와 Appletalk ARP etype 에 대해서 체크합니다. 그리고, ipx 에서는, Ethernet 프레임내의 IPX etype, LCC 헤더내의 IPX DSAP, LCC 헤더가 IPX 로 캡슐화 되어 있지 않은 802.2 및 SNAP 프레임내의 IPX etype 를 체크합니다. ]

    decnet src host
        DECNET 패킷의 시점 주소가 host 의 경우에, 진이 됩니다. 이것은 ``10. 123''라고 하는 형식의 주소에서도 DECNET 의 호스트명에서도 상관하지 않습니다. [DECNET 의 호스트명은 DECNET 를 움직이도록(듯이) 설정되고
         Ultrix 시스템만으로 서포트됩니다. ]

    decnet dst host
        DECNET 패킷의 종점 주소가 host 의 경우에, 진이 됩니다.

    decnet host host
        DECNET 패킷의 시점 혹은 종점 주소가 host 의 경우에, 진이 됩니다.

    ip, ip6, arp, rarp, atalk, aarp, decnet, iso, stp, ipx, netbeui
        ether proto p
        의 단축형입니다. p 의 부분에는, 상기의 몇개의 프로토콜명이 들어갑니다.

    lat, moprc, mopdl
        ether proto p
        의 단축형입니다. p 의 부분에는, 상기의 몇개의 프로토콜명이 들어갑니다. tcpdump 는 현재 이러한 프로토콜을 해석할 수 없는 것에 주의해 주세요.

    vlan [vlan_id]
        패킷이 IEEE 802.1Q VLAN 패킷의 경우, 실로 됩니다. [vlan_id] 가 지정되었을 경우, 패킷이 지정된 vlan_id 를 가지는 경우만, 실로 됩니다. expression 중의 최초의 vlan 키워드가, 패킷이 VLAN 패킷인 것을 가정해, 나머지의 expression 의 디코드용 오프셋(offset)를 변경해 버리는 것에 주의해 주세요.

    tcp, udp, icmp
        ip proto p or ip6 proto p
        의 단축형입니다. p 의 부분에는, 상기의 몇개의 프로토콜명이 들어갑니다.

    iso proto protocol
        패킷이 프로토콜형 protocol 의 OSI 패킷의 경우, 실로 됩니다. protocol 는 수치 혹은 clnp, esis, isis (이)라는 이름의 머지않아인가입니다.

    clnp, esis, isis
        iso proto p
        의 단축형입니다. p 의 부분에는, 상기의 몇개의 프로토콜명이 들어갑니다. tcpdump 는 이러한 프로토콜을 완전하게는 해석할 수 없는 것에 주의해 주세요.

    expr relop expr
        relop는,>, <, >=, <=, =, ! = 의 언젠가여, expr 의 부분에 (은)는, (표준 C 언어의 구문으로 표현된) 정수 정수나 통상의 2항연산자 [+, -, *, /, &, |], length 연산자, 그리고 특수한 패킷 데이터에의 액세스 연산자 등인가 들 되는 산술 표현이 들어가, 그 관계가 성립하는 경우에, 진이 됩니다. 패킷 내부의 데이터에 액세스 하기 위해서는, 이하의 구문을 이용합니다.
        proto [ expr : size ]
        proto는, ether, fddi, tr, ip, arp, rarp, tcp, udp, icmp, ip6 의 언젠가여, 인덱스 조작을 실시하는 프로토콜층을 지시 합니다. tcp, udp 및 다른 상위층 프로토콜형은, IPv4 에만 적용되어 IPv6 에는 적용되지 않는 것에 주의해 주세요 (이것은 장래 수정됩니다). 지시한 프로토콜층으로부터의 상대 바이트 오프셋(offset)는, expr 로 지정합니다. size 는 생략 가능해, 취득하는 필드의 데이터 길이를 나타냅니다. 데이터 길이로서는, 1,2,4 의 어느쪽이든을 지정하는 것이 가능하고, 디폴트에서는 1 이 지정된 것으로 간주해집니다. 키워드 len 로 나타나는 데이터 길이 연산자는, 패킷장을 줍니다. 예를 들면, `ether[0] & 1 ! = 0'는, 모든 멀티 캐스트 패킷을 포착합니다. `ip[0] & 0xf ! = 5'라고 하는 표현은, 모든 옵션 첨부 IP패킷을 포착 일을 의미합니다. `ip[6:2] & 0x1fff = 0'라고 하는 표현은, fragment의 것 있고 데이터 그램 패킷, 혹은 fragment화 된 데이터 그램 중 최초의 fragment를 포착합니다. 이 검사는, tcp 및 udp 의 인덱스 조작에 대해서는, 암묵중 에 적용됩니다. 예를 들면, tcp[0] 는 항상 TCP 헤더의 선두 바이트를 가리켜, 결코 각 fragment의 선두 바이트를 가리키는 것이 아닙니다. 몇개의 오프셋(offset)와 필드치는, 수치는 아니고 정수로서 표기할 수 있습니다. 다음의 프로토콜 헤더 필드 오프셋(offset)가 이용 가능합니다. icmptype (ICMP 타입 필드), icmpcode (ICMP 코드 필드) 및 tcpflags (TCP 플래그 필드) 다음의 ICMP 타입 필드치가 이용 가능합니다. icmp-echoreply, icmp-unreach, icmp-sourcequench, icmp-redirect, icmp-echo, icmp-routeradvert, icmp-routersolicit, icmp-timxceed, icmp-paramprob, icmp-tstamp, icmp-tstampreply, icmp-ireq, icmp-ireqreply, icmp-maskreq, icmp-maskreply 다음의 TCP 플래그 필드치가 이용 가능합니다. tcp-fin, tcp-syn, tcp-rst, tcp-push, tcp-push, tcp-ack, tcp-urg

    원시적은, 이하와 같이 조합하는 것이 가능합니다.

        괄호로 괄일련의 원시적이나 연산자 (괄호는 쉘의 특수 캐릭터이므로 이스케이프 할 필요가 있습니다).

        부정 (`! ' or `not').

        논리적 (`&&' or `and').

        논리합 (`||' or `or').

    부정은, 가장 높은 연산 우선도를 가집니다. 논리합과 논리적은, 같은 연산 우선도를 가져, 왼쪽에서 오른쪽에 평가됩니다. 논리적의 경우에는, 단지 식별자를 늘어놓는 것이 아니라, 명시적으로 and 를 사용해야 하는 것에 주의해 주세요.

    키워드없이 식별자가 주어지고 있는 경우에는, 가장 최근 이용된 키워드가 부가되고 있는 것과 가정됩니다. 예를 들면,
    not host vs and ace
    (은)는,
    not host vs and host ace
    의 단축형입니다만,
    not ( host vs or ace )
    (와)과 혼동 해 버리기 십상인 것으로 조심합시다.

    인수 expression 는, 단일의 인수라고 해도 복수의 인수라고 해도, 어느 쪽인지 편리한 (분)편으로, tcpdump 에 건네줄 수가 있습니다. 일반적으로, 인수가 쉘의 메타캐라크타를 포함한 경우, 그 인수를 쿼트 된 단일의 인수로서 프로그램에 건네주는 (분)편이 용이합니다. 복수의 인수는, 해석되기 전에 스페이스에서 연결됩니다.

사용예

sundown 에 도달한다, 혹은 거기로부터 송신되는 패킷의 모든 것을 표시하는 경우에는, 이하와 같이 실행합니다.
    tcpdump host sundown

helios 와 hot 혹은 ace 의 사이의 트래픽을 표시한다 경우에는, 이하와 같이 실행합니다.
    tcpdump host helios and \( hot or ace \)

ace 와 helios 이외의 호스트와의 사이에 거래되는 모든 IP 패킷을 표시하는 경우에는, 이하와 같이 실행합니다.
    tcpdump ip host ace and not helios

로컬인 호스트와 Berkeley 의 호스트와의 사이에 거래되는 모든 트래픽을 표시하는 경우에는, 이하와 같이 실행합니다.
    tcpdump net ucb-ether

인터넷 게이트웨이 snup 를 통과하는 모든 ftp 트래픽을 표시하는 경우에는, 이하와 같이 실행합니다 (쉘이 괄호를 잘못해 해석하지 않게, 필터를 표현하는 인수가 쿼트야 라고 있는 것에 주의해 주세요).
    tcpdump 'gateway snup and (port ftp or ftp-data)'

시점 주소와 종점 주소의 양쪽 모두가 로컬 네트워크내의 호스트 의 것이 아닌 트래픽에 대해 표시하는 경우에는, 이하와 같이 실행 섬 (실행하는 호스트가 다른 네트워크에 대한 게이트웨이의 경우, 그 호스트 하지만 속하는 로컬 네트워크에서는, 이 명령은 성공하지 않을 것입니다).
    tcpdump ip and not net localnet

로컬 네트워크외의 호스트와의 통신에 대해, TCP 에 의한 각 통신 단위 의 스타트 패킷과 엔드 패킷 (SYN 와 FIN 패킷)을 표시하려면 , 이 아래와 같이 실행합니다.
    tcpdump 'tcp[tcpflags] & (tcp-syn|tcp-fin) ! = 0 and not src and dst net localnet'

게이트웨이 snup 가 중계되는 IP 패킷 가운데, 576 바이트보다 큰 걸 (을)를 표시하려면 , 이하와 같이 실행합니다.
    tcpdump 'gateway snup and ip[2:2] > 576'

이더넷(ethernet)상에서 브로드캐스트 혹은 멀티 캐스트를 경유해 보내진다 것 이외의 IP 브로드캐스트 혹은 멀티 캐스트 패킷을 표시하려면 , 이하와 같이 실행합니다.
    tcpdump 'ether[0] & 1 = 0 and ip[16] >= 224'

echo 요구/응답 이외 (즉 ping 패킷 이외)의 모든 ICMP 패킷을 표시하려면 , 이하와 같이 실행합니다.
    tcpdump 'icmp[icmptype] ! = icmp-echo and icmp[icmptype] ! = icmp-echoreply'

출력 형식

tcpdump 의 출력은, 프로토콜 의존입니다. 이하의 설명에서는, 간단한 파라미터의 기술과 대체로의 포맷의 설명을 행합니다. 링크 레벨 헤더

만약 '-e'옵션이 지정되면(자), 링크 레벨 헤더가 출력됩니다. 이더넷(ethernet)에 대해서는, 시점과 종점의 주소, 프로토콜, 그리고 패킷장이 출력됩니다.

FDDI 네트워크에 대해서는, '-e'옵션이 지정되면(자) tcpdump (은)는, 「프레임 제어」필드, 발신기지와 종점 주소, 그리고 패킷장을 출력합니다. 「프레임 제어」필드는 패킷의 나머지의 부분의 해석을 결정 합니다. (IP 데이터 그램을 포함하는 것 같은) 통상의 패킷은 `async'패킷으로, 0 에서 7 의 사이의 우선 순위를 가집니다. 예를 들면, `async4'입니다. 이러한 패킷은 IEEE802. 2 의 논리 링크제 (LLC) 패킷을 포함하면(자) 가정됩니다. LLC 헤더는, 그것이 ISO 데이터 그램이 아닌 경우 나 이른바 SNAP 패킷의 것과 나무에는 출력됩니다.

Token Ring 네트워크에서는, '-e'옵션을 지정하면(자), tcpdump 는, 액세스 제어」와「프레임 제어」의 필드, 시점과 종점의 주소, 패킷장을 표시합니다. FDDI 네트워크에서는, 패킷은 LLC 패킷을 포함하면(자) 가정됩니다. 옵션 '-e'의 지정의 유무에 관계없이, 시점 경로 제어된 패킷에 대해서는, 시점 경로 제어 정보가 표시됩니다.

(주의: 이하의 기술은, 이용자가 RFC1144 에 기술되고 있는 SLIP 압축 알고리즘에 대한 지식이 있는 전제로 쓰고 있습니다. )

SLIP 에 의한 링크에 대해서는, 방향 지시자 (``I''가 입력 방향, ``O'' 하지만 출력 방향), 패킷형, 그리고 압축 정보가 출력됩니다. 패킷형은, 최초로 출력됩니다. 패킷형에는 ip, utcp, 그리고 ctcp 의 3 개가 있습니다. ip 형 패킷의 경우, 상기 이상의 링크 정보는 표시되지 않습니다. TCP 패킷의 경우에는, connection 식별자가 패킷형에 이어 출력됩니다. 패킷이 압축되고 있는 경우, encode 된 헤더가 출력됩니다. 특수한 경우는 *S+n 나 *SA+n 와 같이 출력됩니다. 여기 그리고 n 는, 순차 순서 번호 (혹은 순차 순서 번호 및 ack)가 변경된 회 수입니다. 특수한 경우가 아니면, 0 회 이상의 변경에 대해 출력됩니다. 변경은, U (긴급 (urgent) 포인터), W (윈도우), A (ack), S (순차 순서 번호), 그리고 I (패킷 ID)로 나타나 변동량 (+n or -n) 혹은 새로운 값 (=n)이 계속됩니다. 마지막으로, 패킷내의 데이터의 총량 및 압축 헤더장이 출력됩니다.

예를 들면, 이하의 행은, 출력 방향의 압축 TCP 패킷을, 암묵의 connection 식별자 (와)과 함께 표시하고 있습니다. ack 는 6 바뀌어, 순차 순서 번호는 49 바뀌어, 패킷 ID 는 6 변합니다. 3 바이트의 데이터와 6 바이트의 압축 헤더가 존재합니다.
    O ctcp * A+6 S+49 I+6 3 (6)
ARP/RARP 패킷

arp/rarp 패킷의 출력은, 요구형과 그 인수를 나타내고 있고 이하에, 호스트 rtsg 로부터 호스트 csam 에의 `rlogin'개시시의 패킷의 실례를 나타냅니다.

    arp who-has csam tell rtsg
    arp reply csam is-at CSAM

1행째는, 호스트 rtsg 가, 호스트 csam 의 이더넷 어드레스를 문의한다 목적으로 arp 패킷을 송신하고 있는 것을 의미합니다. 호스트 csam 는, 자기 자신 의 이더넷 어드레스를 대답하고 있습니다 (이 예에서는, 이서네트 어드레스 (은)는 대문자로, 인터넷 주소부는 소문자로 표기하고 있습니다).

tcpdump -n 로서 기동했을 경우에는, 조금 장황하게 됩니다.

    arp who-has 128.3. 254.6 tell 128.3. 254.68
    arp reply 128.3. 254.6 is-at 02:07:01:00:01:c4

tcpdump -e 로서 기동했을 경우에는, 최초의 패킷은 브로드캐스트 패킷이며, 다음의 패킷은 point-to-point의 패킷인 것이 압니다.

    RTSG Broadcast 0806  64: arp who-has csam tell rtsg
    CSAM RTSG 0806  64: arp reply csam is-at CSAM

최초의 패킷에 대해서는, 시점의 이더넷 어드레스는 RTSG 이며, 종점은 이더넷(ethernet) 브로드캐스트 어드레스, 형태 필드에는 16 진수의 값 0806 (ETHER_ARP 를 의미합니다)이 격납되고 있어 총패킷장은 64 바이트이다 (이)라고 표시하고 있습니다. TCP 패킷

(주의:이하의 기술은, RFC793 에 기술되고 있는 TCP 프로토콜에 대한 지식 (이)가 있는 것을 전제로 기술되고 있습니다. 이 지식이 없는 경우, 본기술과 tcpdump 의 모두 당신에게는 도움이 되지 않을 것입니다. )

TCP 프로토콜행의 일반적인 형식은, 이하와 같습니다.

    src > dst: flags data-seqno ack window urgent options

src 와 dst 는, 각각 시점과 종점의 IP 주소와 포트 번호입니다. flags 의 부분에는, S (SYN), F (FIN), P (PUSH), R (RST) 의 편성, 혹은 단순한 `. ' (플래그 없음)가 들어갑니다. data-seqno 는, 이 패킷내의 데이터가 순차 순서 공간의 어느 부분에 맞는지를 나타냅니다 (이하의 예를 참조해 주세요). ack 는, 본connection상을 역방향으로 다음에 흐르는 데이터 패킷의 순차 순서 번호입니다. window 는, 본connection의 역방향의 패킷을 격납하는 버퍼 사이즈 입니다. urg 는, 패킷중에 `urgent' (긴급) 데이터가 격납되고 있는 것을 계시 options 는, 예를 들면 <mss 1024> 과 같이, 앵글 브랙킷 (대소 기호)으로 괄 tcp 옵션입니다.

src, dst, 그리고 flags 는, 항상 표시됩니다. 다른 필드는, 패킷의 TCP 헤더에 의존해, 표시할 수 있는 경우만 표시됩니다.

이하의 예는, 호스트 rtsg 로부터 호스트 csam 에의 rlogin 개요시의 순차 순서의 일부입니다.

    rtsg. 1023 > csam.login: S 768512:768512(0) win 4096 <mss 1024>
    csam.login > rtsg. 1023: S 947648:947648(0) ack 768513 win 4096 <mss 1024>
    rtsg. 1023 > csam.login: .  ack 1 win 4096
    rtsg. 1023 > csam.login: P 1:2(1) ack 1 win 4096
    csam.login > rtsg. 1023: .  ack 2 win 4096
    rtsg. 1023 > csam.login: P 2:21(19) ack 1 win 4096
    csam.login > rtsg. 1023: P 1:2(1) ack 21 win 4077
    csam.login > rtsg. 1023: P 2:3(1) ack 21 win 4077 urg 1
    csam.login > rtsg. 1023: P 3:4(1) ack 21 win 4077 urg 1

최초의 행은, 호스트 rtsg 의 TCP 포트 1023 번으로부터 호스트 csam 의 login 포트에 대해서 패킷을 송신하고 있는 것을 의미합니다. S 는, 패킷의 SYN 플래그가 설정되어 있는 것을 의미합니다. 패킷의 순차 순서 번호는 768512 번이며, 데이터는 포함하지 않습니다. (표기는 `first:last(nbytes)'여, 이것은 「순차 순서 번호 first 인가 들 last 까지의 last 를 포함하지 않는 nbytes 의 유저 데이터라고 한다 일」을 의미하고 있습니다. ) 이 패킷중에 ack 는 없고, 유효한 수신 윈도우의 크기는 4096 바이트로 있어, 1024 바이트의 최대 세그먼트(segment) 사이즈 요구를 행하는 옵션이 부가되고 (이)라고 있습니다.

csam 는, rtsg 로부터 보내진 패킷 과 유사한 패킷을 돌려 보냅니다만, rtsg 가 보낸 SYN 에 대한 ack 가 포함되는 곳(중)이 달라 `. '는, S (SYN), F (FIN), P (PUSH), R (RST)의 어느 플래그도 서지 않은 것을 의미합니다. 패킷은 데이터를 포함하지 않기 때문에, 데이터 순차 순서 번호는 들어가지 않습니다. ack 순차 순서 번호가 작은 정수 (1)인 것에 주의해 주세요. tcpdump 는, 처음으로 TCP 의 「통신」을 검출하면(자), 패킷으로부터 취득했다 순차 순서 번호를 표시합니다. 통신의 그 후의 패킷에 대해서는, 현재의 패킷 순차 순서 번호와 이 최초의 순차 순서 번호의 사이의 차이를 표시합니다. 이것은, 최초로 취득한 이후의 순차 순서 번호는, 통신 데이터 스트림 의 상대 위치로서 해석할 수 있는 것을 의미합니다 (최초의 각방향의 데이터 바이트 (은)는 1 입니다). `-S'는, 본기능을 무효로 해, 원의 순차 순서 번호를 표시합니다.

6 행 째로는, rtsg 는 csam 에 19 바이트의 데이터를 송신하고 있습니다 (rtsg → csam 의 방향의 통신에 있어서의, 2 바이트째부터 20 바이트째까지의 데이터). PUSH 플래그가 이 패킷에서는 설정되어 있습니다. 7 행 째로는, csam 는 rtsg 로부터 20 바이트까지의 데이터를 받은 취지의 리스폰스를 rtsg 에 돌려주고 있습니다. csam 의 수신 윈도우가 19바이트 작고 연이라든지들 , 이러한 데이터의 대부분은, 소켓 버퍼안에 존재한다 것이 밝혀집니다. csam 는, rtsg 에 1 바이트의 데이터를 송신하고 있습니다. 8 행 째와 9 행 찬미하고는, csam 는 긴급 (urgent)으로 PUSH 플래그의 설정되었다 2 바이트 데이터를 송신하고 있습니다.

snapshot가 너무 작아 tcpdump 가 TCP 헤더 전체를 잡지 않았던 경우, 가능한 한의 헤더를 해석해,``[|tcp]''를 표시해 나머지를 해석할 수 없었던 것을 나타냅니다. (단인가 지나는 또는 헤더를 넘어 버린다고 한) 부정한 옵션을 헤더가 가지는 경우에는, tcpdump 는 ``[bad opt]''를 표시해 나머지의 옵션을 해석하지 않습니다 (어디에서 개시하면(자) 좋은 것인지 모르기 때문입니다). 헤더장에 의해 옵션이 존재하는 것을 알지만, IP 데이터 그램장이 옵션이 거기에 있기 위해서(때문에) 충분한 길이가 아닌 경우에, tcpdump 는 ``[bad hdr length]''를 표시합니다. 특정 플래그의 편성 (SYN-ACK, URG-ACK 등 )에 의한 TCP 패킷의 포착

TCP 헤더의 제어 비트 섹션에는, 다음의 8 비트가 있습니다:

    CWR | ECE | URG | ACK | PSH | RST | SYN | FIN

TCP 접속의 확립에 사용되는 패킷을 보고 싶은 것으로 합시다. 신규 접속을 초기화할 때, TCP 는 3 웨이한드시크프로트콜을 사용하는 것을 생각해 내 주세요. TCP 제어 비트에 관한 접속의 차례는 다음과 같이 됩니다.

    1) 호출측이 SYN 를 송신
    2) 수신자가 SYN, ACK 로 응답
    3) 호출측이 ACK 를 송신

여기서, SYN 비트를 가지는 패킷을 포착하고 싶다고 합니다 ( 제 1 스텝). 스텝 2 의 패킷 (SYN-ACK)은 불필요해, 최초의 SYN 만이 갖고 싶은 것에 주의해 주세요. 필요한 것은, tcpdump 의 올바른 필터식입니다.

옵션 없음의 TCP 헤더의 구조를 생각해 내 주세요:

 0                            15                              31
-----------------------------------------------------------------
|          시점 포트           |       종점 포토              |
-----------------------------------------------------------------
|                        순차 순서 번호                         |
-----------------------------------------------------------------
|                         확인 응답 번호                          |
-----------------------------------------------------------------
|  HL   | 예약  |C|E|U|A|P|R|S|F|        윈도우 사이즈       |
-----------------------------------------------------------------
|         TCP 체크 섬      |          긴급 포인터         |
-----------------------------------------------------------------

TCP 헤더는, 옵션이 없으면 통상, 20 8중창의 데이터를 가집니다. 그림의 최초의 행은 8중창 0 에서 3 을 나타내, 다음의 행은 8중창 4 에서 7 을 나타내는 등이 됩니다.

0 으로부터 세기 시작하면(자), 필요한 TCP 제어 비트는 8중창 13 에 있습니다:

 0             7|             15|             23|             31
----------------|---------------|---------------|----------------
|  HL   | 예약  |C|E|U|A|P|R|S|F|        윈도우 사이즈       |
----------------|---------------|---------------|----------------
|               |13 8중창눈|               |               |

제 13 8중창을 좀 더 잘 봅시다:

                |               |
                |---------------|
                |C|E|U|A|P|R|S|F|
                |---------------|
                |7   5   3     0|

이것들은 우리가 흥미가 있는 TCP 제어 비트입니다. 이 8중창의 비트를, 금방 다른 곳으로, 0 에서 7 으로 번호 붙이고 합니다. PSH 비트는 제 3 비트이며, URG 비트는 제 5 비트입니다.

최초의 SYN 만을 가지는 패킷을 갖고 싶은 것에 주의해 주세요. SYN 비트가 세트 된 TCP 데이터 그램이 도착하면(자), 제 13 8중창에 뭐가 일어날까 봅시다:

                |C|E|U|A|P|R|S|F|
                |---------------|
                |0 0 0 0 0 0 1 0|
                |---------------|
                |7 6 5 4 3 2 1 0|

제어 비트 섹션을 보면(자), 비트 번호 1 (SYN)만이 세트 되고 있습니다.

8중창 번호 13 이, 네트워크 바이트순서로, 8 비트 부호 없음 정수로 가정합니다. 이 8중창의 2 진수치는

    00000010

되어, 10 진수에서의 표현은 다음과 같이 됩니다:

   7     6     5     4     3     2     1     0
0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 0*2 + 1*2 + 0*2  =  2

SYN 마셔 세트 되고 있는 경우에 대해 이해했으므로, 이것으로 거의 끝입니다. TCP 헤더의 제 13 8중창의 값은, 네트워크 바이트순서의 8 비트 부호 없음 정수로서 해석하면(자), 정확하게 2 가 됩니다.

이 관계는 다음과 같이 표현 가능합니다:
    tcp[13] == 2

이 식을 tcpdump 의 필터로서 사용해, SYN 패킷만을 가지는 패킷을 포착 가능합니다:
    tcpdump -i xl0 tcp[13] == 2

이 식은 「TCP 데이터 그램의 제 13 8중창은 10 진수 2 를 가진다」 이렇게 말하고 있어 확실히 우리가 바라는 것입니다.

다음에, SYN 패킷이 필요하지만, ACK 나 다른 TCP 제어 비트에 대해서는 꼭 좋은 경우를 생각합니다. SYN-ACK 가 설정된 TCP 데이터 그램이 도착했을 때에 8중창 13 이 어떻게 되어 있을까를 봅시다:

     |C|E|U|A|P|R|S|F|
     |---------------|
     |0 0 0 1 0 0 1 0|
     |---------------|
     |7 6 5 4 3 2 1 0|

이번은, 제 13 8중창의 제 1 비트와 제 4 비트가 세트 되고 있습니다. 제 13 8중창의 2 진수치는

         00010010

되어, 10 진수에서는 다음과 같이 됩니다:

   7     6     5     4     3     2     1     0
0*2 + 0*2 + 0*2 + 1*2 + 0*2 + 0*2 + 1*2 + 0*2   = 18

이번은, tcpdump 필터식에 'tcp[13] == 18'를 사용할 수 없습니다. 이 식은, SYN-ACK 가 세트 되고 있는 패킷만을 선택해, SYN 마셔 세트 되고 있는 패킷을 선택하지 않기 때문입니다. ACK 나 다른 제어 비트가 세트 되고 있든지 있지 않든지 상관없는 것을 생각해 내 주세요.

이 목적을 달성하기 위해서, 제 13 8중창과 다른 값과의 논리 AND 를 취해, SYN 비트를 얻는 것이 필요합니다. 우리를 갖고 싶은 것은 어떤 경우라도 SYN 가 세트 되고 있으면 좋기 때문에, 제 13 8중창과 SYN 의 2 진수치와의 논리 AND 를 취합니다:

          00010010 SYN-ACK              00000010 SYN
     AND  00000010 (SYN 를 갖고 싶다)  AND  00000010 (SYN 를 갖고 싶다)
          --------                      --------
     =    00000010                 =    00000010

이 AND 조작은, ACK 나 다른 TCP 프로토콜 비트가 세트 되고 있든지 있지 않든지, 결과는 같습니다. AND 용의 값의 10 진수 표현과 이 조작의 결과의 10 진수치는, 모두 2 (2 진수치 00000010)이며, SYN 가 세트 되고 있는 패킷에는 다음의 관계가 성립합니다:

    ( ( 제 13 8중창의 값 ) AND ( 2 ) ) == ( 2 )

여기서, tcpdump 필터식은 다음과 같이 되는 것을 압니다:
         tcpdump -i xl0 'tcp[13] & 2 == 2'

싱글 쿼트 혹은 backslash를 사용해, AND (&') 특수 캐릭터를 쉘로부터 숨길 필요가 있는 것에 주의해 주세요. UDP 패킷

UDP 포맷은, 이하의 rwho 패킷으로 예시합니다.

    actinide.who > broadcast.who: udp 84

이것은, 호스트 actinide 의 who 포트가 UDP 데이터 그램을 인터넷 브로드캐스트 어드레스인 호스트 broadcast 의 who 포트에 대해서 송신하고 있는 것을 의미합니다. 본패킷은, 84 바이트의 유저 데이터를 포함합니다.

몇개의 UDP 서비스는(시점 혹은 종점의 포트 번호로부터) 종 종류의 판단이 가능해, 한층 더 상위 레벨의 프로토콜 정보가 출력됩니다. 도메인 네임 서비스 요구 (RFC1034/1035), 그리고, Sun RPC 호출 (RFC1050)(을)를 이용한 NFS 서비스등이 이 조건에 해당합니다. UDP 네임서버 요구

(주의:이하의 기술은, RFC1035 에 기술되고 있다 도메인 서비스 프로토콜의 지식이 있는 것을 전제로 쓰여져 있습니다. 만약 와 등의 지식이 없는 경우에는, 이하의 기술은 미지의 언어로 쓰여져 있을까 것듯 (으)로 보이겠지요. )

네임서버 요구는, 이하와 같은 표시가 됩니다.

    src > dst: id op?  flags qtype qclass name (len)

    h2opolo. 1538 > helios.domain: 3+ A?  ucbvax.berkeley.edu.  (37)

호스트 h2opolo 는, helios 상의 도메인 서버에 대해서 ucbvax.berkeley.edu 의 호스트명에 대응하는 주소 레코드 (qtype=A) (을)를 문의하고 있습니다. 문의의 ID 는 `3'여,`+'는재귀 요구플래그가 설정되어 있는 것을 의미합니다. 문의의 길이는 37 바이트이며, 이 안에 UDP 및 IP 의 프로토콜 헤더의 길이는 포함하지 않습니다. 질문 조작은 보통 조작 (Query) (이어)여, op 필드는 생략 됩니다. op 가 다른 언젠가에서 만났을 경우, 그 op 는 `3'와 `+'의 사이에 표시됩니다. 이것과 같게, qclass 는 보통 것 (C_IN)이며, 생략 됩니다. 다른 qclass 가 들어갔을 경우, `A'의 직후에 표시됩니다.

소수의 변칙적인 패킷은 검사되어 열쇠 외모로 둘러싸인 부가 필드에 그 결과가 표시됩니다. 문의에 대답이 있었을 때, 권위 레코드 혹은 추가 레코드의 섹션 ancount, nscount, arcount 중 한쪽이,`[na]', `[nn]', `[nau]'와 같은 형식에서 표시됩니다. n 는, 각각의 개수입니다. 응답 비트중 한쪽이 설정되어 있는 (AA, RA, rcode 의 어느쪽이든) 경우, 혹은 「0 이 아니면 안된다」비트가 2 바이트째와 3 바이트째로 설정되어 있고 경우에는,`[b2&3=x]'가 출력됩니다. x 는, 헤더의 2 바이트 눈 및 3 바이트째의 값을 16 진으로 나타낸 것입니다. UDP 네임서버 응답

네임서버 응답의 형식은, 이하와 같습니다.

    src > dst:  id op rcode flags a/n/au type class data (len)

    helios.domain > h2opolo. 1538: 3 3/3/7 A 128.32. 137.3 (273)
    helios.domain > h2opolo. 1537: 2 NXDomain* 0/1/0 (97)

최초의 예는, h2opolo 로부터의 질문 ID 3 의 요구에 대해, helios 가 3 개의 앤서 레코드, 3 개의 네임서버 레코드, 그리고 7 개(살)의 추가 레코드를 가지고 있는 패킷으로 대답하고 있다고 하는 것입니다. 최초의 앤서 레코드는, 타입 A (주소)이며, 그 데이터는 IP 주소 128.32. 137.3 입니다. UDP 와 IP 의 헤더를 제외한 총사이즈는 273 바이트입니다. A 레코드의 클래스 (C_IN)와 같게, op (Query) 및 응답 코드 (NoError)(은)는, 생략 됩니다.

2 개째의 예는, helios 가 질문 ID 2 의 요구에 대해, 존재하지 않는다 도메인 (NXDomain)이라고 하는 대답 코드와 함께, 0 개의 앤서 레코드, 1 개(살) 의 네임서버 레코드, 그리고 0 개의 권위 레코드를 포함했다 리스폰스를 돌려주고 있습니다. `*'는, authoritative answer 비트가 설정되고 (이)라고 있는 것을 나타냅니다. 앤서 레코드가 없기 때문에, 형태, 클래스, 데이터는 출력되지 않습니다.

출력될 가능성이 있는 다른 플래그 캐릭터는,`-' (재귀 이용, RA, 가 설정되어 있지 않다) 및 `|' (메세지 잘라서 버려 TC, 가 설정되어 있다)입니다. `question'섹션에 포함되는 엔트리가 정확히 1 개(살)이 아닌 경우에는, `[nq]'가 출력됩니다.

네임서버 요구 및 응답은, 커지는 경향에 있어, 디폴트의 snaplen 의 값인 68 바이트의 길이는, 패킷을 포착해 그 내용을 표시하기에는 충분하지 않을지도 모르는 것에 주의해 주세요. 만약 네임서버 트래픽의 조사를 진지하게 행하려고 한다면, -s 옵션을 이용해, snaplen 를 늘려 (이)라고 주세요. 자신의 경험상, `-s 128'로 충분히 쓸모가 있습니다. SMB/CIFS 의 디코드

현재의 tcpdump 는, UDP/137, UDP/138, TCP/139 상의 데이터용으로, 매우 많은 SMB/CIFS/NBT 디코드를 포함합니다. IPX 및 NetBEUI SMB 데이터의 원시적인 디코드도, 얼마 정도는 실장되고 있습니다. 디폴트에서는, 최소한의 디코드를 해 보다 상세한 디코드는 -v 를 지정하면(자) 행해집니다. -v 를 사용하면(자), 단일의 SMB 패킷이 1 페이지 이상을 차지해 버리기 때문에, 피투성이의 상세 모든 것이 정말로 갖고 싶은 경우에만 -v 를 사용 해야 할것을 주의해 주세요. UNICODE 캐릭터 라인을 포함한 SMB 세션을 디코드하는 경우, 환경 변수 USE_UNICODE 를 1 으로 설정하면(자) 좋을지도 모릅니다. UNICODE 캐릭터 라인을 자동 검출하는 패치를 환영합니다. SMB 패킷 서식의 정보와 모든 필드의 의미에 대해서는, www.cifs.org 또는 좋아하는 samba.org 미러 사이트의 pub/samba/specs/ 디렉토리를 봐 주세요. SMB 패치는 Andrew Tridgell (tridge@samba.org)가 썼습니다. NFS 요구와 응답

Sun NFS (Network File System) 요구 및 응답은, 이하와 같이 표시됩니다.

    src.xid > dst.nfs: len op args
    src.nfs > dst.xid: reply stat len op results

    sushi. 6709 > wrl.nfs: 112 readlink fh 21,24/10. 73165
    wrl.nfs > sushi. 6709: reply ok 40 readlink "../var"
    sushi. 201b > wrl.nfs:
    	144 lookup fh 9,74/4096. 6878 "xcolors"
    wrl.nfs > sushi. 201b:
    	reply ok 128 lookup fh 9,74/4134. 3150

최초의 행에서는, 호스트 sushi 가 ID6709 의 트랜잭션(transaction)를 wrl 에 송신합니다 (시점 호스트에 계속되는 숫자는 트랜잭션(transaction) ID (이어)여, 시점 포트 번호로 없는일로 주의해 주세요). 요구 사이즈는, UDP 및 IP 헤더의 사이즈를 제외해 112 바이트입니다. 조작은, 파일 핸들 (fh) 21,24/10. 731657119 에 대한 readlink (기호 연결 읽기)입니다. (이 예의 같게 운이 좋다면, 파일 핸들은 디바이스의 메이저, 마이너 번호의 페어와 거기에 계속되는 inode 번호와 세대 번호라고 해석하는 것이로 옵니다. ) wrl 는 링크의 내용과 함께 `ok'라고 대답하고 있습니다.

3 행 찬미하고는, sushi 는 wrl 에 대해, 파일 핸들 9,74/4096. 6878 의 디렉토리안의 `xcolors'파일의 검색을 요구해 지금 (은)는, NFS 의 프로토콜 사양과 함께 읽으면, 그것 자신을 보면 아는 듯 에 의도해 작성되고 있습니다.

-v (verbose, 장황) 플래그가 있는 경우, 추가 정보가 출력됩니다. 예를 들면

    sushi. 1372a > wrl.nfs:
    	148 read fh 21,11/12. 195 8192 bytes @ 24576
    wrl.nfs > sushi. 1372a:
    	reply ok 1472 read REG 100664 ids 417/0 sz 29388

(-v 는 IP 헤더의 TTL 와 ID 와 길이와 fragmentation 필드도 출력해 가, 이 예에서는 생략 하고 있습니다. ) 최초의 행에서는, sushi 는 wrl 에 대해서 파일 21,11/12. 195 의 오프셋(offset) 24576 바이트째인가 들 8192 바이트를 읽도록(듯이) 요구하고 있습니다. wrl 는 `ok'라고 대답하고 있고 바이트 밖에 없습니다 (그 외의 데이터는 계속하는 fragment중에 계속됩니다 하지만, 이러한 fragment는 NFS 헤더도 UDP 헤더마저도 가지지 않기 때문에, 사원 필터링의 표현에 따라서는 출력되지 않을 것입니다). -v 플래그가 의 것으로 몇개의 파일 속성 (파일 데이터에 추가되어 돌려주어져 온다)이 출력됩니다. 그것들은 파일의 형태 (보통 파일이라면 ``REG''), (8 진수 표현의) 파일 모드, uid 와 gid, 그리고 파일의 크기입니다.

-v 플래그가 2 회 이상 지정되면(자), 한층 더 자세한 정보가 출력됩니다.

NFS 요구는 매우 큰 데이터가 되기 (위해)때문에, snaplen 를 크게 해 없으면 자세한 출력은 얻을 수 없습니다. NFS 트래픽을 감시하려면 , `-s 192'와 지정해 봐 주세요.

NFS 응답 패킷은 RPC 조작인 것을 명시적으로는 가리키지 않습니다. 그 대 원 , tcpdump 은 「최근의」요구를 추적해, 트랜잭션(transaction) ID 를 이용하고 (이)라고 응답과 조합합니다. 응답이 대응하는 요구의 바로 후에 계속되지 않으면 해 석 할 수 없습니다. AFS 의 요구와 응답

Transarc AFS (Andrew File System)의 요구와 응답은 다음과 같이 표시됩니다:

    src.sport > dst.dport: rx packet-type
    src.sport > dst.dport: rx packet-type service call call-name args
    src.sport > dst.dport: rx packet-type service reply call-name args

    elvis. 7001 > pike.afsfs:
    	rx data fs call rename old fid 536876964/1/1 ".newsrc.new"
    	new fid 536876964/1/1 ".newsrc"
    pike.afsfs > elvis. 7001: rx data fs reply rename

최초의 행에서는, 호스트 elvis 가 RX 패킷을 pike 에 보내고 있습니다. 이것은, fs (파일 서버) 서비스에의 RX 데이터 패킷이며, RPC 호출의 개시입니다. 이 RPC 호출은 rename (개명)이며, 낡은 디렉토리 파일 ID 536876964/1/1 와 낡은 파일명 `.newsrc.new', 새로운 디렉토리 파일 ID 536876964/1/1 와 새로운 파일명 `.newsrc'로 호출하고 있습니다. 호스트 pike 는, RPC 응답을 rename 호출에 대해서 돌려줍니다 (데이터 패킷이며, 중단( abort) 패킷은 아니기 때문에, 이것은 성공했습니다).

일반적으로는, AFS RPC 의 RPC 호출명만은 최저한 디코드됩니다. 대부분의 AFS RPC 는, 적은 구와도 얼마인가의 인수가 디코드됩니다 (일반적으로는 「흥미가 있다」인수뿐이어, 흥미에 대해서는 있는 정의에 의합니다).

서식은, 자명이 되는 것을 의도하고 있습니다만, AFS 및 RX 의 동작에 친밀감이 없는 분들에게 있어서는 유용하지 않을지도 모릅니다.

-v (장황) 플래그를 2 번 지정하면(자), 확인 응답 패킷과 추가의 헤더 정보를 표시합니다. 이것은, RX 호출 ID, 호출 번호, 순차 순서 번호, 시리얼 번호, RX 패킷 플래그라고 한 것입니다.

-v 플래그를 2 번 지정하면(자), 추가 정보가 표시됩니다. 이것은, RX 호출 ID, 호출 번호, RX 패킷 플래그라고 한 것입니다. MTU 네고시에이션 정보도, RX 확인 응답 패킷으로부터 표시됩니다.

-v 플래그를 3 번 지정하면(자), 보안 인덱스와 서비스 ID 를 표시합니다.

중단( abort) 패킷에 대해서는, 에러 코드가 표시됩니다. 다만, Ubik 신호 패킷은 예외입니다 (Ubik 프로토콜에서는, 중단( abort) 패킷은, 긍정 투표에 사용되기 때문입니다).

AFS 요구는 매우 크고, snaplen 를 늘리지 않으면 많은 인수가 표시되지 않는 것에 주의해 주세요. AFS 트래픽을 보려면 `-s 256'를 시험해 보세요.

AFS 응답 패킷은, 명시적으로는 RPC 조작을 식별하지 않습니다. 대신에 tcpdump 가 「최근의」요구의 추적을 실시해, 응답에 대응하는 요구의 매칭을, 호출 번호와 서비스 ID 를 사용해 실시합니다. 응답 패킷이 대응하는 요구 패킷에 근처 없으면 파스 할 수 없을지도 모릅니다. KIP Appletalk (DDP in UDP)

UDP 데이터 그램으로 캡슐화된 Appletalk DDP 패킷은, 캡슐화 (을)를 풀려 DDP 패킷으로서 덤프 됩니다 (모든 UDP 헤더 정보는 파기 됩니다). 파일 /etc/atalk.names 하지만, Appletalk 네트워크 및 노드 번호를 이름으로 변환하는데 이용하고 본파일의 내용은, 이하와 같이 기술됩니다.

    number	name
    1. 254		ether
    16.1		icsd-net
    1.254. 110	ace

최초의 2 행은, Appletalk 네트워크명을 결정하고 있습니다. 3 행 째는, 특정의 호스트의 이름을 결정하고 있습니다 (호스트는, 3 8중창눈의 유무로 네트워크와 구별됩니다. 네트워크 번호는, 2 8중창의 숫자 (으)로부터, 호스트 번호는 3 8중창의 숫자로부터 구성될 필요가 있습니다. ) 숫자와 이름은, 공백 캐릭터 혹은 탭 캐릭터로 단락지어집니다. 이 /etc/atalk.names 파일은, 공행 혹은,`#'캐릭터로 시작되는 코멘트행을 포함해도 가마 없습니다.

Appletalk 주소는, 이하와 같이 표시됩니다.

    net.host.port
    144. 1.209. 2 > icsd-net. 112.220
    office. 2 > icsd-net. 112.220
    jssmag. 149.235 > icsd-net. 2

(만약, 이 /etc/atalk.names 하지만 없는지, 이 파일안에 호스트 번호 및 네트워크 번호의 엔트리가 존재하지 않는 경우에는, 주소는 숫자로 표시됩니다. ) 최초의 예는, 네트워크 144.1 안의 노드 209 의 NBP (DDP port 2)가, 네트워크 icsd 의 노드 112 의 호스트의 포트 220 을 열고 있는 누군가에게 데이터를 송신하고 있습니다. 다음의 행은, 1 행 째와 거의 같은 예입니다만, 시점의 노드명이 기존이다 (`office') 그런데 다릅니다. 3 행 째의 예는, 네트워크 jssmag 의 노드 149 의 포트 235 로부터, icsd-net 의 NBP 포트에 브로드캐스트로 데이터 송신을 하고 있습니다 (브로드캐스트 어드레스 (255)는, 호스트 번호없이 네트워크 번호만 하지만 표시되고 있는 (곳)중에 압니다. 이것으로부터, /etc/atalk.names 에서는 노드명과 네트워크명을 구별하는 (분)편이 좋은 것이 밝혀집니다).

NBP (name binding protocol) 및 ATP (Appletalk transaction protocol) 패킷에서는, 그 내용은 해석됩니다. 다른 프로토콜은, 프로토콜명 (혹은, 프로토콜이 등록되지 않은 장소 합에는, 프로토콜 번호) 및 패킷 사이즈를 덤프 합니다. NBP 패킷 는, 이하와 같은 형식에서 표시됩니다.

    icsd-net. 112.220 > jssmag. 2: nbp-lkup 190: "=:LaserWriter@*"
    jssmag. 209.2 > icsd-net. 112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250
    techpit. 2 > icsd-net. 112.220: nbp-reply 190: "techpit:LaserWriter@*" 186

최초의 행은, 레이저 라이터의 이름 검색 요구이며, 네트워크 icsd 의 호스트 112 로부터 보내져 네트워크 jssmag 로 브로드캐스트 되고 있습니다. 검색을 위한 nbp 의 ID 는 190 입니다. 다음의 행은 jssmag. 209 로부터의, 이 요구의 응답 (같은 ID 를 가지는 것에 주의해 하야 있고)로, 포트 250 에 등록된 RM1140 라는 이름의 레이저 라이터가 있다고 답 네라고 있습니다. 3 행 째는, 같은 요구에 대한 다른 호스트로부터의 응답으로, 호스트 techpit 가, 포트 186 에 등록된 레이저 라이터 "techpit" 를 가지고 있고 라고 대답하고 있습니다. ATP 패킷 의 형식은, 이하와 같이 표시됩니다.

    jssmag. 209.165 > helios. 132: atp-req  12266<0-7> 0xae030001
    helios. 132 > jssmag. 209.165: atp-resp 12266:0 (512) 0xae040000
    helios. 132 > jssmag. 209.165: atp-resp 12266:1 (512) 0xae040000
    helios. 132 > jssmag. 209.165: atp-resp 12266:2 (512) 0xae040000
    helios. 132 > jssmag. 209.165: atp-resp 12266:3 (512) 0xae040000
    helios. 132 > jssmag. 209.165: atp-resp 12266:4 (512) 0xae040000
    helios. 132 > jssmag. 209.165: atp-resp 12266:5 (512) 0xae040000
    helios. 132 > jssmag. 209.165: atp-resp 12266:6 (512) 0xae040000
    helios. 132 > jssmag. 209.165: atp-resp*12266:7 (512) 0xae040000
    jssmag. 209.165 > helios. 132: atp-req  12266<3,5> 0xae030001
    helios. 132 > jssmag. 209.165: atp-resp 12266:3 (512) 0xae040000
    helios. 132 > jssmag. 209.165: atp-resp 12266:5 (512) 0xae040000
    jssmag. 209.165 > helios. 132: atp-rel  12266<0-7> 0xae030001
    jssmag. 209.133 > helios. 132: atp-req* 12267<0-7> 0xae030002

jssmag. 209 는, 호스트 helios 에 대해 최대 8개 ('<0-7>')까지의 패킷을 요구하는 것으로, 트랜잭션(transaction) ID 12266 을 개시합니다. 행의 마지막 16 진수는, 요구안의 「유저 데이터」의 필드의 값입니다.

helios 는, 8 개의 512 바이트의 패킷으로 응답하고 있습니다. 트랜잭션(transaction) ID 의 후에 이어지는 「:수」는, 패킷 순차 순서 번호를, 괄호중의 수치는 ATP 헤더 (을)를 제외한 패킷중의 데이터량을 나타내고 있습니다. 패킷 순차 순서 7 의 `*'는, EOM 비트가 설정되어 있는 것을 나타내고 있습니다.

jssmag. 209 는, 패킷 순차 순서 번호 3 으로 5 의 패킷의 재발송 요구를 하고 있습니다. helios 는 그것들을 재발송해, 그 후 jssmag. 209 는 트랜잭션(transaction)를 해방합니다. 마지막 행으로, jssmag. 209 는 다음의 요구를 개시합니다. 이 요구의 표시 그리고 부가되고 있는 `*'는, XO (`exactly once')가 설정되어 있지 않은 것을 나타냅니다. IP fragmentation

fragment가 있는 인터넷 데이터 그램은, 이하와 같이 표시됩니다.

    (frag id:size@offset+)
    (frag id:size@offset)

(최초의 형식에서는, 아직 fragment가 있는 것을 나타내, 2 번째의 형식은, 이것이 마지막 fragment인 것을 나타내고 있습니다. )

id 는, fragment ID 입니다. size 는, fragment 사이즈를 바이트 단위로 나타낸 것입니다. 다만 IP 헤더 사이즈는 포함하지 않습니다. offset 는, 원의 데이터 그램에서의 본fragment의 오프셋(offset)를 바이트 단위로 나타낸 것입니다.

fragment 정보는, 각 fragment 마다 표시됩니다. 최초의 fragment에는, 상위 레벨의 프로토콜 헤더가 포함되므로, 플래그정 보가 프로토콜 정보의 뒤에 표시됩니다. 2 번째 이후의 fragment에 대해 (은)는, 상위 레벨의 프로토콜 헤더를 포함하지 않기 때문에, 플래그 정보는 시점야 종점 주소의 뒤로 표시됩니다. 예를 들면, 이것은 arizona.edu 로부터 lbl-rtsg.arpa 에의 CSNET 접속에서의 ftp 의 모습의 일부분입니다만, 아무래도 576 바이트 이상의 데이터 그램을 취급할 수 없어 입니다.

    arizona.ftp-data > rtsg. 1170: .  1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)
    arizona > rtsg: (frag 595a:204@328)
    rtsg. 1170 > arizona.ftp-data: .  ack 1536 win 2560

주의 해야 할것이 몇개인가 있습니다. 우선 최초로, 2 행 째는 포트 번호를 포함하지 않습니다. 이것은, TCP 프로토콜 정보는, 최초의 fragment 에 모두 들어가 있어 후의 fragment를 출력할 때에는 포트 번호나 순차 순서 번호를 알 방법이 없기 때문입니다. 다음에, 최초의 행의 TCP 순차 순서 정보는, 패킷이 308 바이트의 유저 데이터 (을)를 가지고 있어와 같이 표시됩니다만, 실제로는 512 바이트의 유저 데이터를 가지고 있습니다 (308 바이트가 최초의 플래그분으로, 204 바이트가 2 번째의 플래그분에 ). 순차 순서 스페이스의 구멍을 찾거나 패킷의 ack 의 대응이 올바르다 인지를 이 데이터로 보려고는 안됩니다.

fragment 불가 플래그가 설정된 패킷은, 마지막 부분에 (DF) 와 표를 붙일 수 있습니다. 타임 스탬프

디폴트에서는, 모든 출력행은 최초로 타임 스탬프가 출력됩니다. 타임 스탬프는, 이하의 형식에서, 현재의 클락 타임을 표시합니다
    hh:mm:ss.frac
그리고, 클락의 정밀도는, 커널 클락의 정밀도에 의존합니다. 타임 스탬프는, 커널이 최초로 패킷을 찾아낸 시간을 반영합니다. 이더넷(ethernet) 인터페이스가 케이블로부터 패킷을 꺼내 커널이 「신규 패킷」세치기를 받아들일 때까지의 타임 러그 등은 보정되지 않습니다

관련 항목
bpf(4), pcap(3)

저자
원래의 저자는 다음과 같습니다:

Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.

현재는 tcpdump.org 로 관리되고 있습니다.

현재의 버젼은 http 로 다음의 곳부터 취득 가능합니다:

    http://www.tcpdump.org/

원래의 배포는 익명 ftp 로 다음의 곳부터 취득 가능합니다:
    ftp://ftp.ee.lbl.gov/tcpdump.tar.Z

IPv6/IPsec 서포트는 WIDE/KAME 프로젝트가 추가했습니다. 본프로그램은, 특정의 구성에 대해서는, Eric Young 의 SSLeay 프로그램 라이브러리를 사용합니다.

버그
문제, 버그, 희망의 기능확장등에 대해서는 다음의 곳에 보내 주세요:

    tcpdump-workers@tcpdump.org

원시 코드의 기증등에 대해서는 다음의 곳에 보내 주세요:

    patches@tcpdump.org

NIT 에서는, 밖에 나가는 트래픽을 관찰할 수 없습니다. BPF 라면 가능합니다. 후자를 고용하는 것을 추천 합니다.

2.0[. x] 커널의 Linux 시스템에 대해:

    루프백 디바이스상의 패킷은 2 번 관측됩니다.

    커널내에서의 패킷 필터링은 불가능하고, 전패킷이 커널로부터 카피되어 유저 모드로 필터 됩니다.

    snapshot의 길이 부분이 아니고, 패킷 전체가, 커널로부터 카피됩니다 (2.0[. x] 의 패킷 포착 기구는, 패킷의 일부를 유저 랜드에 카피하도록(듯이) 의뢰받으면(자), 패킷의 올바른 길이를 보고하지 않습니다. 이 때문에, 대부분의 IP 패킷이 tcpdump 그리고 에러가 되어 버립니다).

2.2 이후의 커널에 업그레이드 하는 것을 추천합니다.

IP fragment를 재구성하는지, 혹은 적어도 상위 프로토콜의 바로잡아 있고 데이터 사이즈를 계산하도록(듯이) 설계 다시 할 필요가 있습니다.

네임서버에 대한 역당겨에 대해서는, 올바르고 덤프 되지 않습니다. 실제의 요구가 아니고, (empty) 퀘스쳔 섹션이, 앤서 섹션에 출력됩니다. 역당겨에 대해서는 그 자체가 버그이다고 믿어 tcpdump 는 아니고 역인 나무를 요구한다 프로그램을 수정해야 하는 것이라고 생각하는 사람들도 있습니다.

서머타임이라는 변경때에 패킷 트레이스를 실시하면, 타임 스탬프는 변경 후의 시각과는 어긋나 버립니다 (시간 변화는 무시됩니다).

FDDI 헤더 및 Token Ring 헤더를 조작하는 것 같은 필터의 표현에 대해서는, 모든 FDDI 패킷 및 Token Ring 패킷은 SNAP 로 캡슐화된 Ethernet 패킷이라고 가정합니다. 이것은, IP, ARP, DECNET 국면 4 에 대해서는 올바릅니다만, ISO 의 CLNS 등의 프로토콜에 대해서는 올바르지는 않습니다. 따라서, 필터 표현에 올바르고 매치 하지 않는 것 같은 패킷을 우연히 받아들여 버리는 일이 있습니다.

Token Ring 헤더 이외의 필드에 대한 필터식은, 시점 경로 제어된 Token Ring 패킷을 올바르게 취급하지 않는 것이 있습니다.

ip6 proto (은)는 헤더 체인을 추적해야 합니다만, 현재로서는은 그렇게 되고 있지 않습니다. 이 때문에 ip6 protochain 하지만 제공되고 있습니다.

예를 들면 tcp[0] 라고 하는 트랜스폴트층 헤더에 대한 연산은, IPv6 패킷에 대해서는 동작하지 않습니다. IPv4 패킷만을 봅니다.