Формирование трафика (имитация задержки и потери пакетов) в точке доступа Wi-Fi Linux

625
user9773452

Я настроил Pi 3 B + в качестве точки доступа Wi-Fi и хотел бы имитировать задержки пакетов и потерю пакетов для подключенных устройств, осуществляющих связь через точку доступа. Я думал, что смогу добиться этого, используя tc и iptables, чтобы вызвать дрожание и потерю пакетов для подключенных устройств, осуществляющих связь через точку доступа, но эти пакеты не затрагиваются. Единственные затронутые пакеты - это пакеты от подключенного устройства, чей IP-адрес назначения является AP, или пакеты AP, чей IP-адрес назначения является подключенным устройством. Любая идея о том, как повлиять на подключенные устройства, взаимодействующие через точку доступа, будет принята с благодарностью. Также я не могу изменить программное обеспечение или конфигурацию на устройствах, подключенных к точке доступа. Я попробовал команды, подобные приведенным ниже на AP, но безуспешно.

tc qdisc change dev wlan0 корневая задержка netem 100 мс 10 мс

tc qdisc change dev wlan0 потеря корневого элемента 0.1

iptables -D INPUT -m статистика - режим случайного выбора - вероятность 0,2 -j DROP

iptables -D OUTPUT -m статистика - режим случайной выборки - вероятность 0,2 -j DROP

iptables -D FORWARD -m статистика - режим случайного выбора - вероятность 0,2 -j DROP

1

1 ответ на вопрос

1
Chromatix

Вы должны быть в состоянии использовать netem для этой цели, не требуя iptables. Вы можете объединить задержку и потерю, которые вам требуются, в одном экземпляре netem.

Однако каждый qdisc по умолчанию обрабатывает только исходящий трафик на своем интерфейсе. Входящий трафик включает в себя другой путь, и вы должны поместить отдельный qdisc на этот путь, чтобы повлиять на них. Вы можете либо присоединить второй экземпляр netem к интерфейсу Ethernet, либо направить входящий трафик Wifi для прохождения через виртуальное промежуточное устройство. Последнее требует:

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

Одна из причин, по которой iptables может не работать, заключается в том, что по умолчанию мостовой трафик не проходит через него по соображениям эффективности, а только маршрутизируемый трафик. Существует опция конфигурации ядра во время компиляции для отправки мостового трафика также через iptables, но я не думаю, что это необходимо в вашем случае.

Я пробовал это, но с последующей командой без успеха, так как команда tc filter не работала. Любые другие идеи будут высоко оценены # modprobe ifb # ip link set dev ifb0 up # tc qdisc добавить dev eth0 вход # tc фильтр добавить dev eth0 родительский ffff: \ protocol ip u32 match u32 0 0 flowid 1: 1 действие зеркальное отражение выходной редирект dev ifb0 # tc qdisc добавить dev ifb0 задержка корня netem 750 мс user9773452 5 лет назад 0
@ user9773452 Как именно команда tc filter "не работает"? Было ли сообщение об ошибке? Chromatix 5 лет назад 0
Это была ошибка синтаксического анализа user9773452 5 лет назад 0
@ user9773452 В этом случае попробуйте версию в моем отредактированном ответе. Chromatix 5 лет назад 0
Команды теперь работают, но только пакеты, на которые влияют, являются пакетами от подключенного устройства, IP-адрес назначения которого является AP, или пакеты AP, чей IP-адрес назначения является подключенным устройством. user9773452 5 лет назад 0
@ user9773452 Это странно. *Очень странно. Но в качестве обходного пути вы могли бы дать eth0 такое же лечение. Вы можете направить входящий трафик eth0 на одно и то же устройство ifb0, поэтому вам не нужно дублировать его. Chromatix 5 лет назад 0

Похожие вопросы