Traffic Shaping (simulieren Sie Paketverzögerung und -verlust) unter Linux Wi-FI Access Point

568
user9773452

Ich habe eine Pi 3 B + -Einstellung als WLAN-Zugangspunkt und möchte Paketverzögerungen und Paketverluste für verbundene Geräte simulieren, die über den AP kommunizieren. Ich dachte, ich könnte dies erreichen, indem ich tc und iptables verwende, um Paket-Jitter und -Verlust für angeschlossene Geräte zu verursachen, die über den AP kommunizieren. Diese Pakete sind jedoch nicht betroffen. Die einzigen Pakete, die betroffen sind, sind Pakete von einem verbundenen Gerät, dessen Ziel-IP der AP ist, oder AP-Pakete, deren Ziel, dessen Ziel-IP ein verbundenes Gerät ist. Jede Einsicht in die Auswirkungen auf angeschlossene Geräte, die über den AP kommunizieren, wäre sehr zu begrüßen. Ich kann auch die Software oder Konfiguration der an den AP angeschlossenen Geräte nicht ändern. Ich habe ähnliche Befehle wie die folgenden auf dem AP ohne Erfolg versucht.

tc qdisc change dev wlan0 root netem verzögerung 100ms 10ms

tc qdisc change dev wlan0 root netem loss 0.1

iptables -D INPUT -m Statistik -mode zufällige Wahrscheinlichkeit 0,2 -j DROP

iptables -D OUTPUT -m Statistik -mode zufällige Wahrscheinlichkeit 0,2 -j DROP

iptables -D FORWARD -m Statistik -mode zufällige Wahrscheinlichkeit 0,2 -j DROP

1

1 Antwort auf die Frage

1
Chromatix

Sie sollten netem zu diesem Zweck verwenden können, ohne iptables zu verwenden. Sie können die Verzögerung und den Verlust, die Sie benötigen, in einer einzigen Netem-Instanz kombinieren.

Jeder qdisc verarbeitet jedoch standardmäßig nur ausgehenden Datenverkehr auf seiner Schnittstelle. Eingehender Verkehr beinhaltet einen anderen Pfad, und Sie müssen einen separaten Qdisc auf diesen Pfad setzen, um ihn zu beeinflussen. Sie können entweder eine zweite Netem-Instanz an die Ethernet-Schnittstelle anschließen oder den Wifi-Eingangsverkehr anweisen, ein virtuelles Zwischengerät zu passieren. Letzteres erfordert:

ifconfig ifb0 up tc qdisc add dev wlan0 handle ffff: ingress tc filter add dev wlan0 parent ffff: protocol all u32 match u32 0 0 action mirred egress redirect dev ifb0 tc qdisc add dev ifb0 root netem ...

Ein Grund, warum iptables für Sie möglicherweise nicht funktioniert, besteht darin, dass der überbrückte Datenverkehr aus Effizienzgründen standardmäßig nicht durchgelassen wird. Dies gilt nur für gerouteten Datenverkehr. Es gibt eine Kernelkonfigurationsoption zum Kompilieren, um auch überbrückten Datenverkehr über iptables zu senden. Dies ist jedoch in Ihrem Fall nicht erforderlich.

Ich habe dies aber mit dem follow-Befehl ohne Erfolg versucht, da der tc-Filterbefehl nicht funktionierte. Irgendwelche anderen Ideen wären sehr dankbar # modprobe ifb # ip link set dev ifb0 up # tc qdisc add dev eth0 ingress # tc filter add dev eth0 übergeordnetes ffff: \ protocol ip u32 match u32 0 0 flowid 1: 1 action mirred ausgang umleiten dev ifb0 # tc qdisc add dev ifb0 root netem delay 750ms user9773452 vor 5 Jahren 0
@ user9773452 Wie genau funktionierte der tc-Filterbefehl "nicht"? Gab es eine Fehlermeldung? Chromatix vor 5 Jahren 0
Es war ein Fehler bei der Analyse user9773452 vor 5 Jahren 0
@ user9773452 Versuchen Sie in diesem Fall die Version in meiner bearbeiteten Antwort. Chromatix vor 5 Jahren 0
Die Befehle funktionieren jetzt, aber nur Pakete, die betroffen sind, sind Pakete von einem verbundenen Gerät, dessen Ziel-IP der AP oder AP-Pakete ist und dessen Ziel, dessen Ziel-IP ein verbundenes Gerät ist. user9773452 vor 5 Jahren 0
@ user9773452 Das ist komisch. *Sehr seltsam. Aber als Workaround können Sie eth0 genauso behandeln. Sie können den eth0-Ingress-Verkehr an dasselbe ifb0-Gerät leiten, sodass Sie diesen ebenfalls nicht duplizieren müssen. Chromatix vor 5 Jahren 0

Verwandte Probleme