2012-02-19 9 views
7

Quando si utilizza pcap_open_live ad annusare da un'interfaccia, ho visto un sacco di esempi con vari numeri come SNAPLEN valore, che vanno da BUFSIZ (<stdio.h>) a "numeri magici".ottimale SNAPLEN per PCAP catturare vivo

Non avrebbe più senso impostare come SNAPLEN l'MTU dell'interfaccia da cui si acquisisce? In questo modo, potremmo inserire più pacchetti contemporaneamente nel buffer PCAP. È sicuro assumere che la MRU sia uguale alla MTU?

In caso contrario, esiste un modo non esotico per impostare il valore SNAPLEN?

Grazie

risposta

6

Il MTU è il più grande payload dimensioni che potrebbe essere consegnato al livello di collegamento; non include alcun header di livello link, quindi, per esempio, su Ethernet sarebbe 1500, non 1514 o 1518, e non sarebbe abbastanza grande da catturare un pacchetto Ethernet di dimensioni complete.

Inoltre, non include intestazioni di metadati come l'intestazione del radiotap per le informazioni radio 802.11.

E se l'adattatore sta eseguendo qualsiasi tipo di frammentazione/segmentazione/riassemblaggio, i pacchetti consegnati all'adattatore o ricevuti dall'adattatore potrebbero non essere ancora frammentati o segmentati, o potrebbero essere stati rimontati e, come tali, potrebbe essere molto più grande del MTU.

Come per il montaggio di più pacchetti nel buffer PCAP, ciò si applica solo ai meccanismi di cattura TPACKET_V1 e TPACKET_V2 mappati in memoria in Linux, che hanno slot di pacchetti a dimensione fissa; altri meccanismi di cattura non riservano uno slot di dimensioni massime per ogni pacchetto, quindi una lunghezza più breve dello snapshot non avrà importanza. Per TPACKET_V1 e TPACKET_V2, una lunghezza di snapshot inferiore potrebbe fare la differenza, sebbene, almeno per Ethernet, libpcap 1.2.1 tenti, nel miglior modo possibile, di scegliere una dimensione di buffer buffer appropriata per Ethernet. (TPACKET_V3 non sembra avere gli slot per pacchetto a dimensione fissa, nel qual caso non avrebbe questo problema, ma è apparso solo nei kernel rilasciati ufficialmente di recente, e non esiste ancora un supporto per esso in libpcap.)

+0

OK, quindi devo "indovinare" una dimensione massima probabile per il traffico che sto per monitorare. – ziu

+2

* Se * stai usando Linux con una versione moderna di libpcap, e la versione non è 1.2.1 o successiva o non stai acquisendo su Ethernet (o stai catturando su Ethernet con frammentazione/segmentazione/riassemblaggio offloading) , * e * non vuoi allocare un enorme buffer di memoria condivisa (usando 'pcap_create()'/'pcap_set_buffer_size()'/'pcap_activate()'), e vuoi evitare le gocce di pacchetti, dovrai indovina una probabile dimensione massima per i pacchetti consegnati a libpcap. –

+0

Ok, il mio problema è duplice dal momento che non analizzo ogni pacchetto prima di ottenere quello nuovo, quindi devo buffer anche a livello di applicazione utente. Ecco perché sto cercando di tagliare l'utilizzo della memoria. – ziu