2016-07-02 6 views
0

Kürzlich musste ich Tests mit dem ausgezeichneten Google Packetdrill Tool schreiben. (https://github.com/google/packetdrill)Sind Packetdrill-Tests tragbar?

Zusammenfassend, es ist ein Werkzeug, das den TCP (oder IP oder UDP) Stapel unseres Computers nur durch Schreiben einiger Testfälle testen kann, die C-Befehle, erwartete ausgehende und eingehende Pakete kombiniert.

Aber ich kann nicht herausfinden, wie tragbar diese Tests sind. Wenn ich zum Beispiel die Tests im github-Verzeichnis durchführe, scheitern fast alle.

Lassen Sie sich dies nimmt eine fr-4pkt-sack-linux.pkt:

// Test fast retransmit with 4 packets outstanding, receiver sending SACKs. 
// In this variant the receiver supports SACK. 

// Establish a connection. 
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 

+0 bind(3, ..., ...) = 0 
+0 listen(3, 1) = 0 

+0 < S 0:0(0) win 32792 <mss 1460,sackOK,nop,nop,nop,wscale 10> 
+0 > S. 0:0(0) ack 1 <mss 1460> 

+.1 < . 1:1(0) ack 1 win 257 
+0 accept(3, ..., ...) = 4 

// Send 1 data segment and get an ACK, so cwnd is now 4. 
+0 write(4, ..., 1000) = 1000 
+0 > P. 1:1001(1000) ack 1 

Ich erhalte die folgende Fehlermeldung:

fr-4pkt-sack-linux.pkt:19: error handling packet: live packet field ipv4_total_length: expected: 1040 (0x410) vs actual: 297 (0x129) 
script packet: 0.100283 P. 1:1001(1000) ack 1 
actual packet: 0.100277 P. 1:258(257) ack 1 win 29200 

Es dass mein Computer, um anzuzeigen, scheint nur 257 Bytes sendet (das ist eine 64-Bit Ubuntu Gnome 16,04 ist) anstelle von 1000 für das erste Paket (das Fenster-Skalierungsargument wird einfach ignoriert).

Wenn ich andere Tests wie sack-shift-sacked-1-2-3-fack.pkt ausführen, scheint es anzuzeigen, dass das Argument Wscale von meinem Computer ignoriert wird.

Also, meine Fragen sind:

  • Ist das normal das wscale Argument zu ignorieren? Verhält sich mein Computer seltsam?
  • Wenn es normal ist (wie es eine bestimmte Linux-TCP-Funktion ist), wie können wir sicherstellen, dass die PacketDrill-Tests, die auf meinem Computer ausgeführt werden, auf einem anderen Computer ausgeführt werden?

Vielen Dank im Voraus

Antwort

1

Die Lösung war sehr einfach, aber ich werde dieses Thema für diejenigen halten, die in der gleichen Situation sind.

In der Tat habe ich einfach TCP-Windows-Skalierung über sysctl deaktiviert.

benutzte ich eine Konfigurationsdatei hier: http://cnp3book.info.ucl.ac.be/2nd/html/_downloads/sysctl-cnp3.conf

ich mit sysctl -w variable Variablen geändert, aber ich war nicht bewusst, dass diese Änderungen nach dem Neustart Computer persistent waren.

Also, machen Sie nicht den gleichen Fehler wie ich getan habe: Seien Sie vorsichtig, wenn Sie sysctl verwenden, kann es Ihren gesamten Computer brechen (wenn Sie vergessen, diese Einstellungen nach Ihren Tests zurückzusetzen).

Nach dem Zurücksetzen auf Standard funktioniert es jetzt einwandfrei. Die Portabilität von Packet-Drill-Tests scheint also in Ordnung zu sein (wenn es keine neue Haupt-TCP-Funktion gibt).