pcap 구조 pcap_drlen vs caplen

pcap 구조 pcap_drlen vs caplen

리눅스에서 libpcap을 사용하여 패킷을 스니핑합니다. 각 패킷에서 얻는 헤더는 다음과 같습니다.

struct pcap_pkthdr {
        struct timeval ts;      /* time stamp */
        bpf_u_int32 caplen;     /* length of portion present */
        bpf_u_int32 len;        /* length this packet (off wire) */
};

캐플렌은 우리가 포착한 데이터의 길이이고, 렌은 유선상의 패킷 길이라고 알고 있습니다.어떤 경우에는(예: pcap 장치를 열 때 스냅렌을 너무 낮게 설정할 때) 패킷의 일부만 캡처할 수도 있습니다. 이 길이는 'caplen'이 되고 'len'은 원래 길이입니다.따라서 캐플렌은 len과 같거나 작아야 하지만 len보다 크면 안 됩니다.

그것이 적절한 이해입니까?일부 기계에서 caplen > len이 보입니다.

최소한 pcap man 페이지를 기준으로 당신의 이해가 맞습니다.

caplen은 캡처에서 사용할 수 있는 데이터의 양입니다.len은 패킷의 실제 길이였습니다.

저는 당신에게 caplen > len을 줄 수 있는 어떤 경우도 알지 못합니다.저는 스냅렌이 충분히 높기 때문에 보통 동등한 것 같습니다.

네 당신의 이해가 맞습니다.caplen보다 항상 작습니다.Len. 때로는 전체 패킷을 캡처할 필요가 없습니다.

하지만 기회가 주어지면 왜 전체 패킷을 포착하지 않는 겁니까?
왜냐하면 네트워크 트래픽이 많은 상황에서는 별로 좋지 않을 것이기 때문입니다.

유선상에 나타나는 패킷 전체를 캡처하지 않으면 실제로 소중한 데이터를 잃는 것이 아닌가요?
아니요. 실제로 목적에 따라 다르므로 프로토콜과 대상 애플리케이션에 따라 패킷을 분류하려면 약 14바이트(이더넷) + 20바이트(Ip) + 20바이트(Tcp)만 있으면 되므로 프로토콜에 따라 패킷을 분류하는 데는 54바이트의 데이터만 필요합니다.따라서 처리 크기를 줄이는 데 많은 부하와 시간이 절약됩니다.pcappkthdr->len로.pcappkthdr->caplen:)

에 대한 당신의 질문에 관하여.snaplen보다 위대함len때때로:
패킷의 헤더가 손상된 경우(헤더 길이 값이 어떻게든 엉망이 된 경우) 캡처된 길이는 패킷의 실제 길이보다 큽니다.

caplen > len이면 버그입니다. libpcap의 어떤 버전을 사용하고 있습니까?

언급URL : https://stackoverflow.com/questions/1491660/pcap-struct-pcap-pkthdr-len-vs-caplen