Newsgroup: it.comp.os.linux.sys
Titolo: Riassemblamento di pacchetti UDP

Ho un problema.... una macchina Linux deve ricevere dei pacchetti UDP da
un sistema di monitoring. Per come è fatto il software lui richiede che
tutti i dati siano inclusi in un solo pacchetto UDP; se non ci stanno è
possibile per il sender mandare più pacchetti, ma questi devono arrivare
integri.
 
Ora ho il problema che da qualche mese, in seguito a qualche cambiamento
che non sono riuscito a tracciare, i pacchetti UDP inviati da una
macchina remota vengono frammentati a 1464 bytes, quindi alla
destinazione arrivano due frammenti al posto di un unico pacchetto.
Il problema è che la macchina (e non so perché) non riassembla i
pacchetti con il risultato che una parte dei dati vengono persi.
 
Ho una macchina Linux che può essere interposta tra sorgente e
destinazione, quindi stavo pensando di fare un reassembling dei
pacchetti su questa macchina.
Qualcuno mi sa dare un'indicazione su qualche programma che consenta di
fare quanto richiesto? L'ideale sarebbe qualche modulo di iptables se ne
esistono (a memoria non mi soggiunge nulla).
 
TNX
 
 
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

 pacchetti su questa macchina.
 
Questa soluzione io personalmente la vedo come un bagno di sangue. Se ti 
riesce, hai tutta la mia stima, intendiamoci. :)
 
 
Piuttosto, anche per UDP è possibile settare alla sorgente il bit DF 
(don't fragment), proprio non è possibile in alcun modo forzarglielo?
 
Lungo il percorso cosa attraversi? Il geografico, o tutti apparati 
locali che puoi verificare?
 
 
Hint: occhio a vpn (ipsec o pptp) e a vlan 802.11q, in alcuni casi e con 
alcuni apparati è necessario giocare con gli MSS limit proprio perchè 
(con alcuni firewall) il pacchetto cresce sensibilmente creando il 
fenomeno che hai descritto. Ad esempio una sessione VNC in una PPTP con 
alcuni firewall non restituisce le schermate perchè lo stream viene 
frammentato di pochissimo. Magari non è il tuo caso eh.
 
Hai provato a mettere l'MSS limit della scheda di rete sorgente 
direttamente a 1350? Io ho notato spesso problemi quando si sfora di 
pochissimo, ma non se il pacchetto viene frammentato con dimensioni più 
voluminose.
 
Sono tentativi, intendiamoci, ma visto il breve tempo che va via per 
farli, magari un pensierino io lo farei.

[cut]
 
perdonate la castroneria, dalle 18,00 vado in risparmio energetico.
 
ovviamente MSS si riferisce alla sola alla parte dati di un segmento TCP :)
 

 esistono (a memoria non mi soggiunge nulla).
 
 
AFAIR già la stessa presenza di conntrack causa il riassemblaggio dei
frammenti prima che il pacchetto venga analizzato.[1]
 
Ammetto di non aver mai, tuttavia, provato a vedere se questo aiuta o
meno a risolvere il genere di problema che hai tu...
 
 
[1] D'altra parte, se così non fosse sarebbe una bella pigna: i
frammenti successivi al primo non contengono alcun header di layer 4,
sicchè anche solo capire cosa sono sarebbe piuttosto problematico, in un
ruleset...
 
 

 TNX
 
A rischio di dire una stupidata ...
Mi sembra che si stia guardando nel punto sbagliato. Se un pacchetto 
viene frammentato è lo stato ip, in modo del tutto trasparente al 
protocollo di trasporto, che si deve preoccupare di riassemblare il 
tutto. Ed è sempre l'ip che non considera giunto a destinazione il 
pacchetto finché non è arrivato l'ultimo frammento. Quindi se il 
messaggio originale può essere contenuto in un unico datagram anche se 
dovesse venire frammentato prima di essere passato all'applicazione, 
deve essere riasemblato dallo stato sottostante (ip).
Sembra quindi che il problema non sia che qualcuno lungo la tratta 
spezza il pacchetto in frammenti ma che qualcuno alteri il pacchetto in 
modo da far arrivare il frammento come se fosse l'intero.
 
-- 
************** (.)_(.) *******************
Un amico è uno che sa tutto di te e,
nonostante questo, gli piaci
(E. Hobbard)
http://www.youtube.com/user/Nameci65
 
 
 

 ruleset...
 
Il che, caro Skull, mi fa venire in mente un'altra opzione che non avevo
ancora considerato.... in effetti io vedo i pacchetti frammentati
utilizzando tshark e quindi le libpcap che intercettano il traffico
PRIMA di iptables. I pacchetti di tutti e 4 i router arrivano sulla 9995
ma poi ci sono 4 regole di REDIRECT che reindirizzano i pacchetti in
base all'IP sorgente verso 4 porte distinte (9001-9004) dove ascoltano 4
sonde netflow diverse.
Non avevo considerato che potrebbe essere proprio iptables a scartare i
frammenti che arrivano fuori ordine ritenendoli invalidi essendo privi
di header UDP. Non è un'ipotesi balzana e probabilmente è più sensata di
quella di un problema di riassemblaggio dei frammenti che dovrebbe
avvenire a livello IP.
 
Devo allestire un ambiente di test. Devo verificare se è possibile fare
il redirect unicamente in funzione di header di livello 3, ovvero IP
sorgente e numero di protocollo (tanto sono sicuro che non arrivino
altri pacchetti UDP da quei router e non c'è comunque problema per
eventuali improbabilissimi spoofing). Vediamo.
 
Se vi vengono in mente altre ipotesi sono tutt'orecchi.


 Se vi vengono in mente altre ipotesi sono tutt'orecchi.
 
tra sorgente e destinatario non puoi tunnellizzare in alcun modo? Sto 
inventando, ma un tunnel IPSec o SSL potrebbe far "digerire" il traffico 
diversamente..

 Se vi vengono in mente altre ipotesi sono tutt'orecchi.
 
Così, per ragionare:
 
E perchè iptables dovrebbe farlo solo su uno dei 4 flussi ?
 
E se disabiliti il FW e lasci attivi solo i redirect che ti dice ?
Teoricamente eliminando le regole su established/invalid/related e 
mettendo tutto in allow non dovrebbero esserci pacchetti scartati se la 
causa è iptables.
 
Solo per ragionare, mica pretendo di dare soluzioni.
 

 [...]
 
 
Ciao  Manlio
 
 

 userspace per poi reinviarli già riassemblati al collector.
 
Devi leggere i frammenti raw in ingresso e assemblarli tu. Potresti farlo 
con qualche riga di python (from scapy.all import *).
 
Ciao
 
 
Fabio

 I pacchetti vengono riassemblati da netfilter.
 
Oh!
Due post in due giorni!
 
Che ti accade, passa poco?!? ;-)
 

 Solo per ragionare, mica pretendo di dare soluzioni.
 
Peccato :D
Sicuramente un motivo c'è, il problema è solo trovarlo e risolverlo.


 con qualche riga di python (from scapy.all import *).
 
Provo a dargli un occhio.


 usato dal sistema di monitoring.
 
Netflow semplice.


 dove sbattere il naso.
 
Ok: tu dici che i pacchetti arrivano frammentati.
Ma come partono ?
Hai verificato che in origine siano corretti e che si frammentino solo 
durante il trasporto ?
 

 
http://www.zipman.it/ot/15m.cap
 
 
In effetti sembra tutto ok. Per lo meno: il dissector CFLOW non si lamenta
e non sembrano esserci errori a livello di header.
 
Ciao
 
 
Fabio

 Che ti accade, passa poco?!? ;-)
 
Pochissimo: siamo a quattro in tre giorni :-)

 durante il trasporto ?
 
Non posso verificare la partenza, ma si tratta di 4 router Cisco
identici a coppie con le medesime configurazioni (medesimo MTU) e stessa
versione di firmware, quindi non vedo perché dovrebbero essere generati
in modo differente (nulla è impossibile, ma mi pare improbabile).


 e non sembrano esserci errori a livello di header.
 
Martedì, quando sono dal cliente, provo a verificare se nfdump mi da gli
stessi risultati di ntop... provo ad aggiungere una regola di netfilter
con target TEE per duplicare i pacchetti e poi vediamo.


 restio (perl addicted) ma prima o poi mi ci devo mettere.
 
 
Se preferisci il C fammelo sapere che ti incollo qualche decina di righe :P
 
 
 

 una parte...
 
Sembra proprio come se:
"Random Sampled NetFlow provides NetFlow data for a subset of traffic in
a Cisco router by processing only one randomly selected packet out of n
sequential packets (n is a user-configurable parameter). Packets are
sampled as they arrive (before any NetFlow cache entries are made for
those packets)"
 
Qui il resto della faccenda:
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/nfstatsa.html
 
 
sampling di saluti
-- 
Dignità e moneta:
http://dottormistero.blogspot.it/2013/04/dignita-e-moneta.html
 

 those packets)"
 
Non lo escludo aprioristicamente ed indagherï¿œ piï¿œ a fondo, ma chi
gestisce i router mi ha giurato che la configurazione ï¿œ identica in
tutti e 4 i router, e sull'unico router a cui ho avuto accesso di
straforo durante una sessione teamviewer (purtroppo non era quello
incriminato) la configurazione dell'export netflow mi risulta essere
corretta:
 
interface Tunnel1
...
 bandwidth 4000
...
 ip flow ingress
 
interface FastEthernet0
...
 ip flow ingress
 
interface FastEthernet0.2
...
 ip flow ingress
 
ip flow-cache timeout active 1
ip flow-export source Loopback0
ip flow-export version 5
ip flow-export destination 10.124.64.199 9995
