1 votes

Mise en forme du trafic (simulation de délai et de perte de paquets) sur un point d'accès Wi-Fi Linux

J'ai mis en place un point d'accès Wi-Fi avec un Pi 3 B+ et j'aimerais simuler des retards de paquets et des pertes de paquets pour les appareils connectés communiquant à travers l'AP. Je pensais pouvoir y parvenir en utilisant tc et iptables pour provoquer des variations et des pertes de paquets pour les appareils connectés communiquant à travers l'AP, mais ces paquets ne sont pas affectés. Les seuls paquets qui sont affectés sont ceux d'un appareil connecté dont l'adresse IP de destination est l'AP ou les paquets de l'AP dont l'adresse IP de destination est un appareil connecté. Toute suggestion sur la manière d'affecter les appareils connectés communiquant à travers l'AP serait grandement appréciée. De plus, je ne peux pas modifier le logiciel ou la configuration des appareils connectés à l'AP. J'ai essayé des commandes similaires à celles ci-dessous sur l'AP sans succès.

tc qdisc change dev wlan0 root netem delay 100ms 10ms

tc qdisc change dev wlan0 root netem loss 0.1

iptables -D INPUT -m statistic --mode random --probability 0.2 -j DROP

iptables -D OUTPUT -m statistic --mode random --probability 0.2 -j DROP

iptables -D FORWARD -m statistic --mode random --probability 0.2 -j DROP

1voto

Chromatix Points 358

Vous devriez pouvoir utiliser netem à cette fin, sans avoir besoin d'iptables. Vous pouvez combiner le retard et la perte dont vous avez besoin dans une seule instance de netem.

Cependant, chaque qdisc ne gère que le trafic sortant sur son interface par défaut. Le trafic entrant emprunte un chemin différent, et vous devez placer un qdisc séparé sur ce chemin pour les influencer. Vous pourriez attacher une deuxième instance de netem à l'interface Ethernet, ou faire passer le trafic d'entrée Wifi par un dispositif intermédiaire virtuel. Ce dernier nécessite :

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 ...

Une raison pour laquelle iptables ne fonctionne peut-être pas pour vous est que, par défaut, le trafic en pontage ne passe pas par celui-ci pour des raisons d'efficacité, seul le trafic routé le fait. Il existe une option de configuration du noyau au moment de la compilation pour faire passer le trafic en pontage à travers iptables également, mais je ne pense pas que ce soit nécessaire dans votre cas.

0 votes

J'ai essayé ceci mais avec la commande suivante sans succès car la commande tc filter ne fonctionnait pas. Toute autre idée serait grandement appréciée # modprobe ifb # ip link set dev ifb0 up # tc qdisc add dev eth0 ingress # tc filter add dev eth0 parent ffff: \ protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0 # tc qdisc add dev ifb0 root netem delay 750ms

0 votes

@user9773452 Comment exactement la commande de filtre tc "ne fonctionnait-elle pas"? Y avait-il un message d'erreur?

0 votes

C'était une erreur d'analyse.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X