KOEI's Diary |

libpcap linux에서 timeout 되게 패치하기
개발이야기 | 2007/03/25 20:39

근래에 계속 하고 있는 프로젝트에서 결국 tcpdump를 사용하게 되었는데,
Failover 처리를 하다보니 캡쳐하다 특정 시간만큼 패킷이 없을 경우 timeout을 처리해야할 필요성이 생겼다. tcpdump 소스에서 관련 부분을 보면
- tcpdump.c -

885 *ebuf = '\0';
886 pd = pcap_open_live(device, snaplen, !pflag, 1000, ebuf);
887 if (pd == NULL)

4번째 인자가 to_ms, timeout과 관련된 인자로 설정이 되어있어서, 잘 되는구나 하고 진행을 했으나, 리눅스에서는 timeout이 동작하지 않아서 소스를 들여다 봤다.
pcap.c에서 보니 죄다 function pointer로 위임해놨군. 으움 실제 빌드를 돌려보고 실제로 컴파일되는 녀석을 찾아보니 이놈이다. pcap-linux.c 그중에 일부를 보면
- pcap-linux.c -

236 pcap_t *
237 pcap_open_live(const char *device, int snaplen, int promisc, int to_ms,
238 char *ebuf)
239 {
...
267 /* Initialize some components of the pcap structure. */
268
269 memset(handle, 0, sizeof(*handle));
270 handle->snapshot    = snaplen;
271 handle->md.timeout    = to_ms;
...
492 /* Receive a single packet from the kernel */
493
494 bp = handle->buffer + handle->offset;
495 do {
496 /*
497    * Has "pcap_breakloop()" been called?
498    */
499 if (handle->break_loop) {
500 /*
501    * Yes - clear the flag that indicates that it
502    * has, and return -2 as an indication that we
503    * were told to break out of the loop.
504    */
505 handle->break_loop = 0;
506 return -2;
507 }
508 fromlen = sizeof(from);
509 packet_len = recvfrom(
510 handle->fd, bp + offset,
511 handle->bufsize - offset, MSG_TRUNC,
512 (struct sockaddr *) &from, &fromlen);
513 } while (packet_len == -1 && errno == EINTR);

디버거를 돌릴 생각을 못하고 recvfrom 전후로 출력만을 넣어본 결과 blocking이 된다는 사실을 확인. 일단 늘 그렇듯이 당황. nonblocking으로 바꾸면.. 상상하기도 싫고..... 잠시 마음의 여유를 가지고 시간이 별로 없어서 다른 방법을 찾아보지 않고 소스를 고쳐보기로 했다.
(얼마전에 했었던 C++로 작업된 프로젝트 삽질 이후에 또 삽질을.... 이번에는 C다. -ㅅ-)

이런 패턴을 어디서 많이 보던건데..... 아하!
IRC서버소스에서 sleep이 없을 때 select를 쓴다.. 이건 상관없잖아!!
ACE에서 recv에서 timeout을 지원하지 않을 때 어떻게 하더라. multiplexer의 timeout을 이용하면. That's right~
그래서 붙이려다가 이왕이면 select말고 다른거 한번 써보자. 해서 epoll로 살포시 붙여봤다. 작업하면서 소스보기 번거로우니 쓰지 않는 파일이나 화면에 출력결과를 보여주는 루틴등은 싸악 날려주고 -ㅅ- 오옹 보다보니 리눅스에서 어떻게 캡쳐를 하면 되는지도 나온다. 여러 인터페이스(각각 fd로 나오니까)에서 캡쳐하는걸 하나의 epoll로 처리해도 괜찮겠다는 생각이 들기 시작.. 그러나 그런게 중요한건 아니니..

#include <sys/epoll.h>

.... 중략 ....

#define EPOLL_EVENTS_COUNT 16
static int epollfd = -1;
static struct epoll_event ev, * epoll_events = NULL;

.... 중략 ....

pcap_t *
pcap_open_live(const char *device, int snaplen, int promisc, int to_ms
char *ebuf)
{
.... 중략 ....

handle->selectable_fd = handle->fd;
do {
if ( -1 == epollfd)
epollfd = epoll_create(EPOLL_EVENTS);
if ( -1 == epollfd )
break;
if ( NULL == epoll_events )
epoll_events = (struct epoll_event *)malloc(sizeof(*epoll_events) * EPOLL_EVENTS);
ev.events = EPOLLIN;
ev.data.fd = handle->selectable_fd;
if ( -1 == epoll_ctl(epollfd, EPOLL_CTL_ADD, handle->selectable_fd, &ev) )
break;

handle->read_op = pcap_read_linux;
   handle->inject_op = pcap_inject_linux;
   handle->setfilter_op = pcap_setfilter_linux;
   handle->setdirection_op = pcap_setdirection_linux;
   handle->set_datalink_op = NULL; /* can't change data link type */
   handle->getnonblock_op = pcap_getnonblock_fd;
   handle->setnonblock_op = pcap_setnonblock_fd;
   handle->stats_op = pcap_stats_linux;
   handle->close_op = pcap_close_linux;

   return handle;
} while(0);

   fprintf(stderr, "epoll setting error\n");
   pcap_close_linux(handle);
free(handle);
return NULL;
}
....
static int
pcap_read_packet(pcap_t *handle, pcap_handler callback, u_char *userdata)
{
u_char *bp;
int offset;
#ifdef HAVE_PF_PACKET_SOCKETS
struct sockaddr_ll from;
struct sll_header *hdrp;
#else
struct sockaddr from;
#endif
socklen_t fromlen;
int packet_len, caplen;
struct pcap_pkthdr pcap_header;

int n ; /* epoll returned count */

.... 중략 ....

/* Receive a single packet from the kernel */

bp = handle->buffer + handle->offset;
do {
/*
* Has "pcap_breakloop()" been called?
*/
if (handle->break_loop) {
/*
* Yes - clear the flag that indicates that it
* has, and return -2 as an indication that we
* were told to break out of the loop.
*/
handle->break_loop = 0;
return -2;
}
fromlen = sizeof(from);

n = epoll_wait(epollfd, epoll_events, EPOLL_EVENTS, handle->md.timeout);
if (0 >= n)
{
break ;
}
for ( int i = 0 ; i < n ; ++i )
{
if ( epoll_events[i] == handle->selectable_fd )
{

   packet_len = recvfrom(
   handle->fd, bp + offset,
   handle->bufsize - offset, MSG_TRUNC,
(struct sockaddr *) &from, &fromlen);
}
} while (packet_len == -1 && errno == EINTR);

if ( n == 0 || ( n < 0 && errno == EINTR ) )
{
/* callback function must check packet_header, buffer_pointer is NULL. if they are NULL, it is timeout */
callback(userdata, NULL, NULL);
return 0;
}

.... 중략 ....

static void pcap_close_linux( pcap_t *handle )
{
struct pcap *p, *prevp;
struct ifreq ifr;

.... 중략 ....

if (handle->md.device != NULL)
free(handle->md.device);
handle->md.device = NULL;
if (handle->selectable_fd > 0 ) /* 여긴 대충 대충 -ㅅ- */
{
close(epollfd);
}
pcap_close_common(handle);

요렇게 간단하게 몇 부분을 고치니 timeout을 callback에서 packet_header와 capture buffer가 NULL임을 확인하는 것으로 timeout 체킹이 가능해졌다. 다만 50라인 정도 작업하는데 3시간 정도를 쓰다니 -_+
요튼 소기의 목적을 달성하고 timeout을 이용한 다른 코드를 tcpdump에 붙이기 성공.
작업하면서 뻘짓한 것은 tcpdump 소스를 보면서 print-*.c 얘네들을 지우면서 소스를 파악할 때까지는 분위기가 좋았다. libpcap 소스를 보면서 먼저 문서화된 것을 보지 않아서 인터페이스를 파악하는데 삽질한 것(Ruby/Pcap만으로 이미 난 대부분을 알고 있어라는 자만심에)에서 시간을 많이 뺏겼다. 언제나 그렇듯이 소스보다는 문서를, 문서보다는 예제를 먼저 보자라는 생각을 빼먹는다.

작업하면서 printf에서 사용하는 formatted string에서 잼있는 것을 발견. (나만 몰랐는지도)

sprintf(buffer, "%s%0*d", orig_name, max_chars, cnt);

%*d라고 적으면 두개의 인자를 받고 앞의 인자가 *로 자리수를 받고 뒤의 인자가 값이 된다.

여튼 즐거운 working sunday..... ㅠ.ㅠ

태그 : libpcap, tcpdump, 개발, 삽질

트랙백0 | 댓글2

이 글의 관련글(트랙백) 주소 :: http://koei.fiaa.net/trackback/488

rath 2007/04/02 03:56 L R X
오랜만에 놀러왔는데, 열정 가득한 포스팅이 ㄷㄷㄷ하게 올라왔네요~ >.<

KOEI 2007/04/03 11:14 L X

흐흐 부끄럽사와요. 래쓰횽이야 말로 요사이 무지 달리시더라는. 건강 조심하세용~
일하다가 삽질한거 정리해놓으면 나중에 볼때 좋아서연..
래쓰횽 보고 시퍼요 ㅠ.ㅠ

오픈아이디로 글쓰기 [로그인][오픈아이디란?]

이름/비밀번호로 글쓰기

아이디 :
비밀번호 :
홈페이지 :
	비밀글로 등록
내용 :

요사이 개발자로써의 목표는 "새로운 것을 접할 때 빠른 결과와 좋은 성능을 보장하는 개발하기"였다. 실제 여러가지 실제적인 상황을 보다보면 대부분 아는 것보다 모르는 것이 많은 것이 당연한데, 늘 그러한 일을 할 때면 밑바닥부터 모든 것을 만들겠다는 아집에 많은 시간을 쓰는 경우가 많았다. (알고보면 모든 것을 밑바닥부터 만들는 경우는 없는 것과 마찬가지이다.)

해야할 일은 TCP로 돌아다니는 패킷을 캡쳐 => 캡쳐된 패킷을 스트림으로 전환 => 특정 프로토콜에 맞게 파싱

장님 코끼리 만지기 식으로 도입한 프로세스
1. 고객에게 정보 수집
2. 먼저 빠르게 사용할 수 있는 라이브러리를 찾기.(libpcap)
3. lightweight framework language( Ruby, Python과 같은 유연하고 제네릭한 언어)에서 해당 라이브러리 찾기 (pcapy, Pcap/Ruby)
그중 Pcap/Ruby에서 아주 쓰기 편하고 이쁜 라이브러리를 기반으로 구현을 해서 나머지 기능을 모두 기 능 구현을 했었다.
4. 그 외에 세부적으로 필요한 기능상의 내용은 TCP가 어떻게 돌아가는지는 오픈소스 구현물 tcpflow, wireshare, 그리고 관련 자료 wikipedia, the TCP Guide를 참조해서 Ruby로 만든 프로그램에 적용하는 식으로 개발을 했었다.

3주 정도의 기간에 결과물을 대략 산출해내는데 성공했으나 - 아직 진행중 - , 몇 가지 문제점 및 개선방안을 발견할 수 있었다. 결국 실용주의 프로그래머에서 본 내용을 다시 한번 뼈저리게 느끼게 된다.

수행하면서 좋았던 점
1. 1주일 이터레이션 : 피곤하고 많은 시간을 뺏긴다고 생각했으나, 가야할 방향을 알려주는 나침반 역할을 수행했다.
2. Lightweight framework language 활용 : ruby,python과 같은 유연하고 쉬운 언어를 통한 접근은 새로운 기능을 사용하는데 있어서 지렛대 역할을 수행했다. 또한 어떤 부분이 성능이 필요한지, 아닌지에 따라서 사용 여부를 판단할 수 있었다.

개선해야할 점 및 반성점
1. 기존에 있던 구현물을 최대한 활용하기(Unix 철학처럼 simple is best를 최대한 활용하라.)
기능을 구현하는데 있어서 라이브러리보다 더 좋은 수단은 이미 구현된 프로그램이다. 그것을 최대한 재활용할 수 있는 방법을 먼저 강구했었으면 더 빠르게 그리고 안정적으로 구현이 가능했을 것이다. tcpdump를 이용해서 파일을 주기별로 만든 다음에 그걸 파싱하는 프로그램을 작성한다던지 하는 등의 개발방법론을 적용했다면 더 빠르게 개발이 가능했었을 것이다.
2. 고객 그리고 같이 일하는 사람들의 얘기를 좀 더 주의깊게 들으라. 해당 문제를 좀 더 쉽게 단순화시킬 가능성이 높아진다. 받은 데이터를 기존에 같이 일할 때처럼 csv파일과 같은 형태로 만들기 위해 모두 파싱을 하느라 3-4일 정도의 기간을 소요했는데, 오프셋으로도 처리가 가능했었다. 기존에 같이 일할 때 방법만을 생각하고 개발하느라 그러한 문제점이 발생했었는데 생각해보니 지나가는 말로 이 안건을 개발하면서 관련 얘기를 들었던거 같다.
3. 그중에서도 실시간성을 어떻게 감안하느냐에 따라서 concurrent 모델 혹은 배치작업(분리된 프로세스)로 처리하는 것이 월등히 좋은 성능을 발휘할 수 있다. 실시간의 DB 트랜젝션 그리고 실시간의 raw data를 파싱하는 작업등은 시간에 민감한 다른 작업에 지대한 영향을 줄 수 있다. 다량의 로그데이터를 처리하거나 실시간성이 중요한 패킷캡쳐등을 할 때 작업을 분리해 배치처리를 하는 방향으로 모델을 작성했었어도 나쁘지 않은거 같다.

프로세스 수정안
1. 고객에게 여러가지 제반사항에 관한 정보를 수집하기.
2. 같이 개발할 사람들과 협업할 부분에 대한 정보를 얻기
3. 모델을 쉽게 재구성하기
4. 해당 기능과 같은 혹은 비슷한 프로그램을 찾기
5. 실행해보기(기능, 성능체크)
6. 역할에 맞게 최소한의 수정 (라이센스 정책을 어기지 않게 모델을 구성하는데 참조)
7. 그 외의 부분은 상황에 따라 lightweight framework language와 기존의 언어로 빠르게 구현