[winpcap] pacchetti out of order

[Q_Q]

Sto facendo un programma per sniffare il traffico su una porta, va tutto bene fino ad un certo punto dove il programma impazzisce...
Con wireshark ho visto che succede quando arrivano dei pacchetti out of order, come li metto in ordine ?

[gugoXX]

Il traffico su rete puo' essere out-of-order, tranne che per le punto-punto, anche se neppure li' e' garantito.
Per rimettere a posto devi guardare il pacchetto di trasporto, dove c'e' l'ordine di sequenza.
Se stai usando TCP guarda su Wiki.

[Teo@Unix]

Originariamente inviato da Q_Q

Sto facendo un programma per sniffare il traffico su una porta, va tutto bene fino ad un certo punto dove il programma impazzisce...
Con wireshark ho visto che succede quando arrivano dei pacchetti out of order, come li metto in ordine ?

TCP riordina i pacchetti che riceve grazie al campo "sequence number". Questo campo non riferisce come erroneamente si può pensare al numero del pacchetto ma al numero del primo byte di dati trasportati.
Un numero di sequenza è sempre uguale al precedente + byte di dati trasportati nell'ultimo pacchetto.

Data la possibilità di ritardi dovuti ad altri strati puoi riordinare i pacchetti come fa TCP, ovvero crei un buffer di carico dove "parcheggiare" temporaneamente i pacchetti. All'arrivo di un pacchetto TCP devi controllare se è quello che completa la sequenza, a quel punto processi quello poi la coda nel buffer.

Se ti può essere di spunto puoi dare un occhio a questo prototipo di sniffer che avevo realizzato per linux, sta di fatto che la libreria pcap differisce solo di alcune funzioni tra le due architetture...

però in questo non avevo implementato nessuna funzione di riordino...

[Q_Q]

Originariamente inviato da Teo@Unix

Un numero di sequenza è sempre uguale al precedente + byte di dati trasportati nell'ultimo pacchetto.

Quindi tipo se ho seq 1234 e 10 di dati il prossimo seq è 1244 ?

Originariamente inviato da Teo@Unix

un buffer di carico dove "parcheggiare" temporaneamente i pacchetti. All'arrivo di un pacchetto TCP devi controllare se è quello che completa la sequenza, a quel punto processi quello poi la coda nel buffer.

Originariamente inviato da Wikipedia

# ACK (1 bit) – indicates that the Acknowledgment field is significant. All packets after the initial SYN packet sent by the client should have this flag set.
# PSH (1 bit) – Push function. Asks to push the buffered data to the receiving application.

Quindi per ogni pacchetto:
leggo il seq
controllo che sia in ordine giusto

Se è in ordine
a) se il flag ha PSH è un pacchetto completo quindi posso lavorarci sopra
b) se non ha il flag PSH lo metto in un buffer finchè non becco un PSH

Se è fuori tempo
a) è un retransmission quindi lo scarto
b) se è out of order memorizzo il seq e i dati, poi ogni pacchetto che arriva controllo se posso inserirlo nel buffer

giusto ?

[Teo@Unix]

Quindi tipo se ho seq 1234 e 10 di dati il prossimo seq è 1244 ?

esatto. Puoi rendertene conto ulteriormente con wireshark.

Quindi per ogni pacchetto:
leggo il seq
controllo che sia in ordine giusto

Se è in ordine
a) se il flag ha PSH è un pacchetto completo quindi posso lavorarci sopra
b) se non ha il flag PSH lo metto in un buffer finchè non becco un PSH

Se è fuori tempo
a) è un retransmission quindi lo scarto
b) se è out of order memorizzo il seq e i dati, poi ogni pacchetto che arriva controllo se posso inserirlo nel buffer

giusto ?

il flag PSH non significa necessariamente che è un pacchetto completo. TCP lavora come se ci fosse un "flusso di dati" non bada molto al fatto che poi questo sia difatti inviato tramite pacchetti.
PSH ha il compito di segnalare al modulo TCP ricevente di informare l'applicazione del fatto che una sequenza è stata inviata completamente, ad esempio tutti i pacchetti relativi ad una pagina web sono nel buffer, allora il modulo TCP processserà il tutto. Si può dire che è un flag di ottimizzazione.
Il fatto di mettere in un buffer finche non trovi un PSH non credo vada bene, prova ad analizzare qualche sessione con uno sniffer, in alcuni casi questo flag non lo trovi. Però insomma dipende da quello che vuoi fare... per uno sniffer io lo ignorerei...

se è un retransmission è probabile che sia un tuo pacchetto...
ma non è sempre detto.

se ne arriva uno che ha seq number che non ti aspetti (superiore al tuo ultimo ack number) lo parcheggi in attesa del mancante questo ok.
Questo lo puoi fare con un puntatore al pacchetto direi...

[Q_Q]

Originariamente inviato da Teo@Unix

Il fatto di mettere in un buffer finche non trovi un PSH non credo vada bene, prova ad analizzare qualche sessione con uno sniffer, in alcuni casi questo flag non lo trovi. Però insomma dipende da quello che vuoi fare... per uno sniffer io lo ignorerei...

Guardando con wireshark il psh c'è sempre se il pacchetto di dati è meno di 1360, quando è uguale a 1360 è sempre ack.
Processando i pacchetti quando becco il psh infatti riesco a decodificare i dati senza problemi

[Teo@Unix]

ok, ma questo può variare a seconda delle implementazioni.
Questa è ad esempio una discussione dove si ipotizza l'assenza del flag push. TCP deve comunque garantire il funzionamento della connessione senza stalli. Di certo questa non sarà ottimizzata...

Potresti inserire anche una procedura che indica cosa fare nel caso il flag push non sia implementato.

[Q_Q]

Non è che c'è un modo per prendere direttamente i pacchetti tcp già processati (qindi senza beccarsi out of order, resend, ecc...)

[gugoXX]

Originariamente inviato da Q_Q

Non è che c'è un modo per prendere direttamente i pacchetti tcp già processati (qindi senza beccarsi out of order, resend, ecc...)

Poiche' come detto:

Un numero di sequenza è sempre uguale al precedente + byte di dati trasportati nell'ultimo pacchetto.

Allora non appena processi il pacchetto puoi gia' metterlo alla posizione giusta del buffer definitivo, senza preoccuparti del suo ordine.
Non appena riceverai l'ultimo pacchetto, quale che sia, avrai gia' direttamente finito.

[Teo@Unix]

Originariamente inviato da Q_Q

Non è che c'è un modo per prendere direttamente i pacchetti tcp già processati (qindi senza beccarsi out of order, resend, ecc...)

bè... non possiamo di certo andare a rompere le scatole al modulo TCP di windows.... non abbiamo accesso a quel buffer...
lo sniffer lavora solo sul driver della scheda è tutto un'altro approccio ....
per quello che avevo detto che il flag PSH non ci interessa necessariamente tanto è destinato al livello applicativo.... dobbiamo limitarci a "stare a guardare", tutto ciò che possiamo fare è riordinare i pacchetti...

Allora non appena processi il pacchetto puoi gia' metterlo alla posizione giusta del buffer definitivo, senza preoccuparti del suo ordine.

e se trovi duplicati li scarti...

e si fa molto facilmente con poche righe di codice... all'incirca:

...
char*packet
...
struct ether_header eth;
struct ip_header ip;
struct tcp_header tcp;

eth = (struct ether_header*)packet;
ip = (struct ip_eather*)eth+eth_len;
tcp = (struct tcp_eather*)ip+ip_len;
if(tcp->sequence_number<=prew_seqn)
    // scarti (non ti interessa per ricostruire le info. trasmesse)
prew_seqn = tcp->sequence_number;
// processi il pacchetto

se ci sono ritrasmissioni ritardi ecc.... non ti interessa ci pensa già il modulo TCP. "Tu stati alla finestra".

spero di aver centrato la tua domanda...

[Q_Q]

Originariamente inviato da Teo@Unix

bè... non possiamo di certo andare a rompere le scatole al modulo TCP di windows.... non abbiamo accesso a quel buffer...

ho provato ad injectare una dll nel programma che devo sniffare ma leggendo da recv ricevo roba che in wireshark non si vedee, quando ricevo i dati come in wireshare il buffer è sempre 65536 byte anche se ci sono meno dati

Originariamente inviato da Teo@Unix

se ci sono ritrasmissioni ritardi ecc.... non ti interessa ci pensa già il modulo TCP. "Tu stati alla finestra".

ho fatto
seq corrente > seq precedente + len precedente -> metto il seq e i dati in memoria

seq corrente = seq precedente + len precedente -> processo i dati poi controllo se c'è qualche pacchetto in memoria, se c'è controllo il seq e se corrisponde a quello che dovrebbe esserci dopo lo processo poi lo elimino dalla memoria

seq corrente < seq precedente -> scarto

[Teo@Unix]

Originariamente inviato da Q_Q

ho provato ad injectare una dll nel programma che devo sniffare ma leggendo da recv ricevo roba che in wireshark non si vedee, quando ricevo i dati come in wireshare il buffer è sempre 65536 byte anche se ci sono meno dati

mizze non è troppo per uno sniffer? Può anche essere che venga intercettato da software anti-virus.... ora....
in teoria dovresti leggere il secondo argomento di WSArecv() ... credo.... quando questa ritorna ovviamente....

ho fatto
seq corrente > seq precedente + len precedente -> metto il seq e i dati in memoria

seq corrente = seq precedente + len precedente -> processo i dati poi controllo se c'è qualche pacchetto in memoria, se c'è controllo il seq e se corrisponde a quello che dovrebbe esserci dopo lo processo poi lo elimino dalla memoria

seq corrente < seq precedente -> scarto

se questi passaggi ti sono chiari non dovrebbero esserci altri problemi.

[cionci]

Il flag push serve per far "sbloccare" la recv al ricevente anche se il buffer di ricezione non è pieno. Quindi in teoria ogni recv corrisponde al momento in cui la recv ritorna i dati letti.

La ricostruzione dello stream in ricezione è veramente semplice. Tu hai un buffer circolare pari a circa, per sicurezza, 100 x MTU (questi che uso dopo non sono gli indici del buffer circolare, quelli li devi gestire separatamente).
Ricevi il SEQ della del SYN e setti:


start = SYN.SEQ + 1
end = SYN.SEQ + SYN.LENGHT + 1 (se il SYN contiene anche dati, altrimenti SYN.LENGHT = 0)
last_ack = start - 1

Appena riceve un paccketto vai a mettere i dati in (PACKET.SEQ - start)
Appena spedisce un ack fai in modo di settare last_ack = PACKET.ACK
Ad ogni istante tu puoi usare tutti i dati da start a last_ack: togli i dati dal buffer circolare e metti start = last_ack + 1

Se vuoi sfruttare anche il flag push, setta last_push = PACKET.SEQ + PACKET.LENGHT. Questo magari ti può tornare utile per interpretare più facilmente i dati.
Con il push i dati buoni sono quindi quelli compresi fra start e last_push, ma solo se last_push è <= last_ack.
In teoria per fare i confronti dovresti gestire anche il wrap around del sequence number (cioè quando arriva a MAX_SEQ e poi ripassa dallo 0).