Raw IP Networking FAQ --------------------- 버전 1.3 최근 수정일: 1999년 11월 11일 18:18:19 이 FAQ의 원본은 현재 http://www.whitefang.com/rin/ 에 있다. 이 웹페이지에는 또한 이 FAQ의 HTML버전도 함께 있다. 공식적인 미러링을 원한다면 내게 연락을 하라. 번역: 김성윤(kinux@kldp.org, http://kinux.sarang.net) (역주: 첫번째 한글 번역판은 버젼 0.6이고 안창선님(http://kldp.org/~kabin)님에 의해 작성되었다. 첫번째 번역판의 저작권은 안창선님에게 있다.) 저작권 --------- 나, Thamer Al-Herbish는 이 FAQ에 모아 진 것에 대한 저작권을 보유한다. 또한 개개의 기고내용은 기부자의 지적 재산이다. 나는 이 FAQ에 담긴 모든 정보의 합법성에 대한 책임을 진다. 이 FAQ에는 오류 또는 부정확한 부분이 있을 수 있으며, 이것에 대한 사용에 의해 위험부담은 여러분이 가져야 한다. 비록 많은 노력을 기울여 정확성을 기하고자 하였지만, 기고자나 이 FAQ를 유지하는 사람은 FAQ의 부정확성에 의해 발생하는 직 간접적인 어떠한 책임도 지지 않는다. 이 문서를 변형하지 않는 조건에서 이 문서의 배포는 자유로우며, 이 문서를 공개적인 서버에 저장할 경우 업데이트가 잘 되도록 하라. 소개 ------------ 아래의 FAQ는 raw IP 또는 raw소켓, BPF와 DLPI와 같은 네트웍 모니터링 API를 포함한 저수준 IP 네트워킹에 관한 질문에 대한 답변을 담고 있다. 추가와 공헌 --------------------------- 수정될 부분이나 추가될 부분, 또는 새로 답변된 관련 내용을 발견하면 다음으로 메일을 주기 바란다. Thamer Al-Herbish 여러분이 기고하여 새로 만들어진 FAQ에 자신의 Email을 삽입하길 원하는지 그렇지 않은지를 알려주기 바란다. 또한 이 FAQ에서 발견하지 못한 관련 내용을 Usenet에 포스팅 하여 얻게 되는 답변과 해당 질문을 내게 다시 알려주면 그것또한 이 FAQ에 포함 하도록 하겠다. raw socket 버그에 대해 한달에 한번 email을 확인하게 되는데, 그래서 해당 시스템에 버그가 존재한다면 확인할 수가 없다. 메일을 보내기 전에 나의 예제 소스코드를 가지고 체크해주기 바란다. 그것이 명확한 버그라면 메일 주기 바란다. John W. Temples 의 상당한 비평과 수정 조언에 감사를 표한다. 이 FAQ를 만드는데 대한 공헌자들은 이 FAQ의 끝부분에 그 명단을 추가하여 그 공적을 기렸다. 마지막으로, Raw IP Networking 메일링 리스트가 진행중이다. rawip-subscribe@whitefang.com에 빈 메시지를 보냄으로서 참여할 수 있다. 주의 ------ 이 FAQ의 내용은 유닉스 환경과 관련된 정보를 다룬다. 목차 ----------------- 1) 일반 질문들: 1.1) 나의 네트웍을 모니터링할 수 있는 툴이나 sniffer는 어떤게 있는가? 1.2) 패킷을 캡춰할 수 있는 도구는 어떤게 있는가? 1.3) 패킷을 캡춰하는데 사용할 수 있는 portable API가 있는가? 1.4) 패킷 캡춰 기능을 가진 프로그램은 어떻게 동작하는가? 1.5) 네트웍을 sniffing할때 패킷 손실을 최소화 하는 방법은? 1.6) 패킷 캡춰 도구는 어떤때 사용되는가? 1.7) 네트웍과 격리되어 캡쳐된 패킷을 교체할수 있는가? 1.8) 네트웍에 raw packet을 보낼 portable API가 있는가? 1.9) raw IP 억세스를 위한 C 가 아닌 고급 언어 API 가 있는가? 2) RAW socket 질문들: 2.1) RAW socket이란 무엇인가? 2.2) 어떻게 raw socket을 사용하는가? 2.2.1) raw socket을 통해 TCP/IP패킷을 보내는 방법은? 2.2.2) TCP/IP 패킷을 만드는 방법은? 2.2.3) raw socket을 통해 패킷을 Listen하는 방법은? 2.3) raw socket을 사용할때 경계해야할 버그는 무엇이 있는가? 2.3.1) IP 헤더 길이/옵셋 호스트/네트웍 바이트 순서 (feature/bug?) 2.3.2) Solaris 2.4/2.5 checksum weirdness에서의 전송 헤더. 2.3.3) Solaris 2.x와 Irix 6.x에 의한 추가적인 IP 패킷 처리 2.4) raw socket이 일반적으로 무엇을 위해 사용되는가? 3) libpcap (Portable Packet Capturing Library) 3.1) 패킷 캣춰를 위한 운영체제 고유의 API대신 왜 libpcap을 사용해야 하는가? 3.2) 알아야할 libpcap의 불이익에는 어떤게 있는가? 3.3) libpcap 소스코드의 예를 찾을 수 있는 곳은? 4) 공헌자 명단 1) 일반 질문들: --------------------- 1.1) 나의 네트웍을 모니터링할 수 있는 툴이나 sniffer는 어떤게 있는가? 운영체제에 따라 다음과 같은 가능한 툴들이 있다. tcpdump: 대부분의 BSD 호환 기계에서 사용가능하며, ftp://ftp.ee.lbl.gov/tcpdump.tar.Z 에 libpcap(아래를 보라)와 다양한 여러 툴들이 있다. 특히 이러한 툴은 libpcap덕분에 여러 플렛폼에 포팅되어 있다. ipgrab: 많은 시스템에 호환된다. 이것은 캡쳐된 패킷의 link, transport, network 레벨 정보를 보여준다. http://www.xnet.com/~cathmike/MSB/Software/ Ethereal: GTK+를 이용한 GUI 네트웍 패킷 분석기이다. 많은 시스템을 지원하고, http://ethereal.zing.org 에서 구할수 있다. tcptrace: http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html 실제 sniffer는 아니지만, 알려진 많은 sniffer에 의해 생성된 로그파일로부터 일반적인 포맷의 출력물 또는 상세정보들을 만들어 낸다. 이러한 정보에는 진단정보도 포함한다. tcpflow: http://www.circlemud.org/~jelson/software/tcpflow/ tcpflow는 TCP 연결흐름의 부분에서 전송되는 데이타를 캡쳐하고, 프로토콜 분석이나 디버깅하기 쉽게 데이타를 저장하는 프로그램이다. snoop: Solaris, IRIX. etherfind: SunOS. Packetman: SunOS, DEC-MIPS, SGI, DEC-Alpha, 그리고 Solaris. ftp://ftp.cs.curtin.edu.au:/pub/netman/ 에서 구할 수 있다. SniffIt: Linux, SunOS, Solaris, FreeBSD, 그리고 IRIX. http://reptile.rug.ac.be/~coder/sniffit/sniffit.html 에서 구할 수 있다. nettl/ntfmt: HP/UX 1.2) 패킷을 캡춰할 수 있는 도구(facility)는 어떤게 있는가? 운영체제에 따라 여러가지가 있으며, 다양한 버전이 있다.: BPF: Berkeley Packet Filter. 일반적으로 BSD 변형제품에서 발견된다. DLPI: Data Link Provider Interface. Solaris, HP-UX, SCO Openserver. NIT: Network Interface Tap. SunOS. SNOOP: (???). IRIX. SNIT: STREAMS Network Interface Tap. (??) SOCK_PACKET: Linux. LSF: 리눅스 소켓 필터. 이것은 Linux 2.1.75 이상에서 가능하다. drain: OS에 의해 버려지는 패킷을 snoop하는데 사용된다. IRIX. 1.3) 패킷을 캡춰하는데 사용할 수 있는 portable API가 있는가? 있다. ftp://ftp.ee.lbl.gov/libpcap.tar.Z에서 OS에 따른 패킷 캡춰 API를 포함하는 single API를 제공한다. 물론 기본 API들을 배우는 것이 이 라이브러리가 몇몇 흥미있는 부분을 감추어 버리게 되는 경우가 있다는 점에서 가장 좋은 것이 될 수 있다. 상이한 Libpcap버전으로 인해 후위(backward) 호환을 해치는 경우가 있다는 것에 주의하라. 1.4) 패킷 캡춰 프로그램이 동작하는 방법은? 정확한 상세사항은 운영체제에 따라 다르다. 그러나 여러 프로그램들에서 일반적으로 동작하는 방법에 대한 것을 설명하겠다. 사용자 프로세스는 어떤 장치를 열거나 회선 밖에서 패킷을 읽을 수 있는 디스크립터를 주는 시스템 호출을 만든다. 그러면 커널은 패킷을 프로세스에 곧장 보내게된다. 그러나 이것은 느린 시스템이나 로드가 많이 걸려 있는 네트웍에서는 제대로 작동하지 않는다. 사용자 프로세스는 네트웍에 패킷이 나타나는 빠르기 만큼 빠르게 그 패킷을 읽어야 한다. 그것이 버퍼렁과 패킷 필터링이 시작되는 지점이다. 커널은 X 바이트의 패킷 데이터까지 버퍼링 할 수 있으며, 그 패킷을 사용자의 요청에 따라 하나씩 전달한다. 만약 그 양이 어떤 한계를 넘게 되면(자원은 한정되어 있다) 패킷은 버려지고(drop) 버퍼에 남지 않게 된다. 패킷 필터는 프로세스가 원하는 패킷을 지시할 수 있도록 허용한다. 일반적인 방법은 그 패킷에서 수행될 루틴을 위한 opcode 셋을 가지고 그것으로부터 값을 읽고 그것이 원하는지 그렇지 않은지를 결정하는 것이다. 이들 opcode는 보통 매우 단순한 operation을 수행하며, 강력한 필터링 기능을 수행한다. BPF 필터와 그리고 버퍼들; 이것은 버퍼가 오직 그 프로세스가 관심있는 패킷만 포함하기 때문에 가장 바람직하다. 그것은 그 필터가 패킷의 상실을 일으키는 버퍼 오버플로잉을 막기위해 버퍼링되는 패킷의 양을 줄이기를 바란다. NIT, 불행히도 does not do this; 그것은 사용자 프로세스가 그 퍼러링된 데이터로부터 읽기를 시작할때인 버퍼링 후의 필터에 적용된다. 다른 패킷 캡춰 도구를 통한 여러분의 이용도는 매우 광범위할 것이다. 1.5) 네트웍을 sniffing할때 패킷 상실을 제한하는 방법은? 만약 여러분이 패킷 상실에 많은 경험을 가지고 있다면, 필터를 사용한 패킷이 읽어들여지는 범위를 제한하기를 원할 수 있다. 이것은 필터링이 버퍼링 전에 수행될 경우에만 제대로 작동한다. 패킷 캡춰 도구가 NIT와 같이 깨져서(broken) 여전히 제대로 작동하지 않을 경우, 사용자 프로세스에서 더 빨리 읽어야 할 것이며, 그들을 다른 프로세스로 전송해야 한다. 기본적으로 사용자 공간(user space)에서 추가적인 버퍼링을 시도하라. 성능을 증진시키는 또 다른 방법은, 커다란 버퍼를 사용하는 것이다. SNOOP를 사용하는 Irix에서의 man 페이지는 SO_RCVBUF를 사용할 것을 권한다. BPF를 가진 BSD에서 BIOCSBLEN ioctl 호출을 사용하여 버퍼 크기를 증가시킬 수 있다. 솔라리스에서는 bufmod와 pfmod를 사용하여 버퍼의 크기와 필터를 각각 변경할 수 있다. 기억할 것은 여러분의 프로세스가 로드가 걸려서 incoming 패킷의 동향에 관심을 적게 쓰면 쓸 수록 커널에 의해 더 빨리 버려진다(drop)는 것이다. 1.6) 패킷 캡춰가 어떤곳에 사용되는가? ---------------------------------------------- (Question suggested by Michael T. Stolarchuk along with some suggestions for the answer.) 네트웍의 셋업의 verify와 같은 네트웍 진단과 같은 곳에 사용되는데 그 예에는 호스트로부터 보내진 ARP메시지들을 보고해 주는 arp와 같은 툴 들이 있다. end to end 세션의 재 구성. tcpshow는 이러한 일을 한다. 그러나 더 똑똑한 예는 네트웍 연결에서 tab을 유지하려는 보안 툴의 배치이다. 네트웍 로드를 모니터링한다. 아마 실제적으로 가장 많이 사용되는 부분일 것이다. 많은 상용제품들이 이것을 수행하는 특수한 하드웨어를 사용한다. 1.7) 네트웍과 격리되어 캡쳐된 패킷을 교체할수 있는가? 없다. 패킷 캡쳐는 패킷의 복사본을 만드는 것이다. 그리고 시스템의 TCP/IP 스텍으로부터 그것들을 제거하지는 않는다. 만일 TCP/IP 스텍에 도달하는 패킷을 막기위해서는 방화벽 을 사용할 필요가 있다. (그것은 패킷 필터링을 할 수가 있다.) 방화벽에 의한 패킷 캡쳐와 패킷 필터링을 혼돈하지 마라. 그것은 다른 목적으로 제공된다. 1.8) 네트웍에 raw packet을 보낼 portable API가 있는가? 있다. route 가 Libnet에 대해 언급했는데, 이것은 저수준 패킷 작성, 핸들링을 위한 API를 제공한다. 그것은 libpcap에 대해 찬사를 보내는데, 그 프로젝트 웹페이지는 아래에서 볼수 있다. http://www.packetfactory.net/libnet/ 1.9) raw IP 억세스를 위한 C 가 아닌 고급 언어 API 가 있는가? raw socket 억세스를 위해 PERL 모듈이 사용가능하다. http://quake.skif.net/RawIP/ Python 라이브러리 "py-libpap" 은 다음에서 구할 수 있다. ftp://ftp.python.org/pub/python/contrib/Network/ 2) RAW socket 질문들: ------------------------ 2.1) RAW socket이란 무엇인가? BSD 소켓 API를 통해 우리는 raw socket을 열고 TCP/IP 스택에서 layer를 통과한다. 주의할 것은 만약 OS가 올바르게 BSD 체계를 지원하지 않으며, 이것이 작동되도록 하는데 상당한 어려움을 겪을 것이다. 아래에 몇몇 버그 또는 여러분을 놀라게할 만한 것을 보여준다. 거의 모든 제정신의 시스템에서는 오직 root 사용자만이 raw 소켓을 열 수 있다. 2.2) raw socket을 사용하는 방법? 2.2.1) raw socket을 통해 TCP/IP 패킷을 전송하는 방법? 무엇을 전송할 것이냐에 따라 다르지만, 처음에 socket을 열고 그것의 type을 지정한다. sockd = socket(AF_INET,SOCK_RAW,); 그리고 IPPROTO_RAW을 포함한 어떠한 프로토콜도 선택할 수 있다. 그 프로토콜 번호는 IP 헤더에 그대로 들어간다. IPPROTO_RAW 는 IP 헤더에 0 을 넣게된다. 대부분의 시스템은 IP_HDRINCL이라는 여러분 자신의 IP을 패킷을 나머지와 함께 포함할 수 있도록 해주는 소켓 옵션을 가지고 있다. 만약 여러분의 시스템이 이 옵션을 가지고 있지 않다면, 여러분 자신의 IP 헤더를 포함할 수 없을 것이다. 만약 그렇다면 여러분은 다음과 같은 방법으로 가능하게 할 수 있다. char on = 1; setsockopt(sockd,IPPROTO_IP,IP_HDRINCL,&on,sizeof(on)); 물론, 만약 IP 헤더를 포함하길 원하지 않는다면, 항상 그 socket을 생성할때 프로토콜을 지정할 수 있으며 전송계층 헤더를 그것안에 포함 시킬 수 있다. 그러고나서 그 패킷을 만들고 일반적인 sendto()같은 함수를 호출 할 수 있다. 2.2.2) TCP/IP 패킷을 만드는 방법은? http://www.whitefang.com/rin/ 에 가면 예제가 있다. 이 예제는 관련된 상세 사항을 기술하고 있따. 또한 몇몇 아래에 언급된 버그에 관해서도 기술하고 있다. 간단하게 말해서, 여러분은 메모리 내에서 패킷을 작성하고 소켓에 넘겨준다. 그러면 그 소켓을 그것을 밖으로 쏴보내거나 더 많은 패킷을 기다리던지 할 것이다. 2.2.3) raw socket을 통해 패킷을 listen하는 방법은? 전통적으로 BSD socket API는 들어오는 패킷을 raw socket을 통해 listen하는 것을 허용하지 않았다. 비록 Linux (2.0.30 이 내가본 최신 버전이다)는 이것을 허용하지만, 그것은 Linux 자신이 구현한 TCP/IP 스택을 사용해야만 가능하다. 전통적인 BSD 체계는 어떤 카테고리(아래에 있다)에 매치되는 몇몇 패킷을 여러분이 습득하는 것을 허용한다. 이러한 이유의 배후에는 논리적인 이유가 있다. 예를 들어 TCP 패킷들은 항상 커널에 의해 다루어진다. 만약 포트가 열리면 SYN-ACK를 전송하고 연결을 설립하거나 또는 뒤로 RST를 보낸다. 다른말로 하면, 몇몇 타입의 ICMP(아래에 관련 리스트를 좀 적었다.)은 커널이 핸들링 하지 못한다. ICMP echo reply와 같은것은 매치되는 raw socket으로 전송된다. 왜냐하면 사용자 프로그램이 그것을 수신하게 되는 것을 의미하기 때문이다. 해결책은 만약 그것이 UDP또는 TCP 패킷일 경우에 특정 포트에 방화벽을 설치하는 것이다. 그리고 패킷 캡쳐 API를(위에 나열되어 있는 것들) 가지고 그것을 sniff한다. 이것은 TCP/IP 스택이 패킷을 핸들링 하는 것을 막아준다. 그러므로 그것은 무시되고 여러분은 간섭 없이 자신을 위해 그것을 핸들링 할 수 있게 된다. 만약 방화벽을 만들지 않고, 자신에게 reply하면 여러분은 여러분의 운영체제로부터 추가적인 응답을 받게 될 것이다. 여기에 유즈넷의 Richard Stevens이 쓴 raw BSD socket의 체계에 관한 간단한 설명이 있다. From (Sun Jul 6 12:07:07 1997) : "BSD raw sockets의 체계는: - TCP 와 UDP: 커널만이 이것을 받는다. - ICMP: 각각의 ICMP는 커널이 그것에 대한 응답(ICMP 각각의 요청, timestamp요청, mask 요청과 같은 것에 대한)으로 reply하는 것을 제외한 각각의 매치되는 raw 소켓을 통과 시킨다. - IGMP: 이들 모두는 모든 매치되는 raw socket으로 통과된다. - 커널이 다루지 않는 모드 다른 프로토콜(OSPF, etc.): 모두 매치되는 raw socket으로 전달된다. BSD4.4의 TCP/IP 스택의 icmp_input()루틴을 살펴본 결과 아래의 ICMP 형들은 매치되는 raw socket으로 통과되는 것으로 보여진다. Echo Reply: (0) Router Advertisement (9) Time Stamp Reply (13) Mask Reply (18) 2.3) raw socket을 사용할때 알아두어야 할 버그는 어떤게 있는가? 2.3.1) IP 헤더 길이/옵셋 호스트/네트웍 바이트 순서 (feature/bug?) 4.4BSD로부터온 시스템은 ip 헤더의 멤버인 ip_len과 ip_off이 network 바이트 순서가 아닌 host 바이트 순서로 셋팅되어 있어야 하는데 그렇지 않은 버그를 가지고 있다. 몇몇 시스템은 버그가 고쳐졌다. 내가 버그가 고쳐진 것을 확인한 시스템은 OpenBSD 2.1이다. 2.3.2) Solaris 2.4/2.5 checksum weirdness에서의 전송 헤더. 이 버그에 대한 이전 workaound는 정확하지 않았다. Michael Masino 는 이것에 관한 좀더 정확한 workaround를 내게 보내주었다. 아래 내용은 그 메일을 압축한 것이다.(Thu, 19 Feb 1998): "나는 솔라리스 2.5가 데이터를 raw socket을 통해 전송할때 TCP또는 UDP checksum을 계산하려고 하는 것을 발견하였습니다. 나는 또한 만약 내가 올바른 checksum을 그 필드에 삽입하면 그 전송된 패킷이 데이터 checksum과 같은 길이의 checksum을 갖고 있었습니다. 만약 내가 한 byte를 그 데이터에 덧붙이면 그 checksum은 1씩 증가되었습니다. 그러나 만약 내가 그 checksum을 0으로 셋팅하면 그 전송된 패킷은 올바른 checksum + checksum 길이에 해당하는 TCP checksum을 갖게 되었습니다. 올바른 checksum을 전송하기 위해 그 아래 줄은 여러분은 checksum된 데이터의 길이로 채워야 합니다. FAQ에서 언급된것은 그것을 sizeof(struct tcphdr)로 설정하기 위함이며 만약 여러분이 패킷안에 데이터를 가지고 있으면 제대로 작동하지 않을 것입니다. 여러분은 따라서 TCP 헤더의 길이(유사 헤더가 아닌) 와 데이터 양의 길이를 채워 넣어야 합니다." 나는 아직 SUN에서 이것을 known bug로서 설명한, 또한 그것이 언제 수정되었는지를 알리는 official 문서를 발견하지는 못했다. 나는 그것이 Solaris 2.6 에서는 발생하지 않는다는 보고서는 가지고 있다. 2.3.3) Solaris 2.x와 Irix 6.x에 의한 추가적인 IP 패킷 처리 ---------------------------------------------------------------- (Bug report from Lamont Granquist ) "Irix 6.x와 Solaris 2.x(2.5.1 과 2.6) 에서의 SOCK_RAW는 IP 패킷이 전송되기 전에 몇몇 원치 않는 처리를 한다. 특히, 그것은 IP_DF(조각내지 마라)플레그를 켜게 하고, 다른 IP id번호와 다른 TCP seq번호와 ack번호를 할당하며, 그 checksum을 재계산한다. 나는 IP_DF 플래그를 포함하기 위한 코드 예제를 해킹하려고 했는데 여전이 IP/seq/ack번호를 할당하고 checksum을 재계산한다" 2.4) 일반적으로 raw socket은 어디에 사용되는가? -------------------------------------------- 다양한 유닉스 유틸리티들이 raw socket을 사용한다. 거기에는 traceroute, ping, arp 및 많은 인터넷 보안툴 들이 raw socket을 사용한다. 그러나 오랫동안 raw socket은 버그가 있으며, portable하지 않고 사용에 제한이 있는 것으로 판명되어 왔다. 3) libpcap (Portable Packet Capturing Library) ------------------------------------------------ 3.1) 패킷 캡춰를 위해 운영체제 고유의 API대신 왜 libpcap을 사용해야 하는가? libpcap은 어플리케이션이 패킷 캡춰를 portable하게 할 수 있도록 하기 위해 만들어 졌다. 그것의 시스템 독립성과 다양한 운영체제 지원으로 인해 여러분은 패킷 캡춰 어플리케이션은 다양한 시스템에서 사용될 수 있도록 좀더 portable하게 만들어 질 수 있다. 3.2) 알아야할 libpcap의 불이익에는 어떤게 있는가? 그렇다. libpcap은 BSD에서 파생된 시스템에서 발견되는 BPF를 사용할때 오직 kernel 패킷 필터링 기능만을 사용한다. 이것은 BPF를 사용하지 않는 다른 운영체제에서 사용되는 어떠한 패킷 필터도 사용자 공간에서 수행될 것이며, 따라서 속도화 효율성 몇에서 불이익이 있다. 따라서 로드가 걸려 있는 네트웍을 sniff할때 패킷 로스가 증가되기 때문에 이것은 여러분이 원하는 것은 아닐 것이다. DEC의 OSF/1은 BPF-스타일의 필터를 지원하기 위해 확장된 API를 가지고 있다. libpcap은 이것을 이용한다. 나중에, Libpcap은 BPF 스타일의 필터들을 다른 패킷 캡춰 도구로 translate 할 것이다. 그러나 이것은 아직 버전 0.3에서 구현되지 않았다. 질문 1.4를 참고하면 어떻게 패킷 필터들이 여러분의 네트웍을 신뢰성있게 모니터링 할지에 대한 도움을 얻을 수 있을 것이다. 3.3) libpcap 소스코드의 예를 찾을 수 있는 곳은? LBNL의 ftp사이트에 관련된 많은 소스코드가 있다. ftp://ftp.ee.lbl.gov/ 는 libpcap을 사용한다. 좀더 자세히 말하면 ftp://ftp.ee.lbl.gov/tcpdump.tar.Z 가 아마 libpcap의 커다란 확장의 예시를 보여 줄 것이다. 4) 공헌자 리스트 ------------------------ Thamer Al-Herbish W. Richard Stevens John W. Temples (III) Michael Masino Lamont Granquist Michael T. Stolarchuk Mike Borella route Derrick J Brashear