2012-04-13 12 views
0

Ich habe ein Problem mit tcp_fin() Funktion. Es sollte eingehende TCP-Segmente mit FIN-Flag verarbeiten, aber wenn ich tracepoint oder nur printk am Anfang dieser Funktion hinzufüge, wird dieser Tracepoint-Handler nie (oder keine Nachrichten von printk) aufrufen.Schließen von TCP-Socket und tcp_fin() in Linux-Kernel/

Meine Aktionen:

  1. Tracepoint oder printk-tcp_fin()
  2. Build-& Boot neuen Kernel
  3. Run etwas wie folgt hinzufügen:

    #!/bin/bash 
    
    nflows=50 
    
    on_int() 
    { 
        echo "$nflows skeeped" 
        exit 0 
    } 
    
    trap 'on_int' INT 
    
    while [ $nflows -ne 0 ] 
    do 
        iperf -n 5M -c X.X.X.X 
        nflows=$(($nflows - 1)) 
        echo "======================" 
        echo $nflows 
        echo "======================" 
    done 
    

Und als Ergebnis Ich möchte ld, um Anrufe von tcp_fin() zu beobachten, aber nichts passiert.

+0

Sind Sie sicher, dass die Verbindungen ordnungsgemäß eingerichtet und abgebaut sind (d. H. Sie sind nicht mit RST beendet oder sogar nie richtig eingerichtet) – nos

+0

@nos Ja, es ist ordnungsgemäß eingerichtet und sollte nicht zurückgesetzt werden. Iperf sollte die Verbindung am Ende schließen, also werden wir 50 FIN-markierte Segmente haben, aber keine solche Spur beobachtet. –

+0

Ich würde das aber mit wireshark verifizieren. Außerdem, welche Protokollstufe hat Ihr printk verwendet - nur für den Fall, dass Ihr syslog keine Protokolle dieses Levels anzeigt. – nos

Antwort

0

Wie ich vor ein paar Tagen schrieb tcp_fin() bearbeitet eingehende FIN-Segment, aber im Gegensatz zu RFC-793 endete nicht jede Verbindung durch zwei FIN-Segmente (A-> B, B-> A). In einigen Fällen haben wir nur ausgehende FIN und nicht mehr.