Он остается только в режиме монитора или случайного режима, когда запущенный процесс удерживает его в этом режиме.
Хотя это справедливо большую часть времени, когда мы бежим (на El Capitan):
# sudo tcpdump -p -I -i enX -y IEEE802_11
Интерфейс может зависнуть в режиме монитора после выхода из tcpdump (где X
- беспроводная сетевая карта, которая поддерживает режим монитора).
Обратите внимание, что я говорю "может". Это не ошибка. Несколько раз он возвращался в нормальный режим. В большинстве случаев это не так.
Выполнение этой команды впоследствии исправило ее (это мой ответ на ваш вопрос):
# sudo tcpdump -I -i enX -p
Это привело нас к мысли, что что-то не так с tcpdump или Mac OS X и с тем, как они взаимодействуют друг с другом (проблема также может быть в libpcap, который находится между ними).
Мы приступили к чтению исходного кода libpcap и обнаружили множество драгоценных камней в радости режима монитора в Mac OS X, который, в свою очередь, указал нам на тот факт, что выбор определенного режима DLT (с использованием флага -y на tcpdump) заставить Mac OS X перевести интерфейс в режим монитора (без дополнительной работы libpcap). Кроме того, в отличие от других систем, в libpcap не выполняется никакой специальной очистки состояния режима монитора при работе в Mac OS X.
В нашем случае крайне важно, чтобы мы могли получать кадры управления 802.11 (тестовые запросы), сохраняя при этом связь и связь с базовой станцией.
В итоге мы создали программу, которая напрямую взаимодействовала с libpcap и просто запросила режим монитора pcap_set_rfmon(pcap, 1)
(без выбора режима DLT), прежде чем активировать захват на интерфейсе.
При выходе программа просто закрывает дескриптор захвата, и все возвращается в норму (исчезает глаз Саурона), и сетевая карта все еще связана с сетью. Доступ в интернет работает на протяжении всего исполнения.