Доступ к беспроводному интерфейсу (802.11) на уровне MAC (Linux)

Я провел последние дни, читая страницы руководства, документацию и все остальное, что опубликовал Google, но я полагаю, что сейчас я сбит с толку еще больше, чем вначале.

Вот что я хочу сделать: я хочу отправлять и получать пакеты данных с помощью моего собственного протокола (ов) уровня 3 через беспроводной интерфейс (802.11) в системах Linux с C / C ++. Все идет нормально. Мне не нужны маяки, ассоциации или какие-либо вещи, связанные с AP / SSID. Однако для передачи данных я бы хотел, чтобы уровень MAC вел себя «как обычно», то есть одноадресные пакеты были ACK'd, повторными передачами, отсрочкой передачи и т. Д. Я также хотел бы пользоваться расширенными возможностями QoS (802.11e с 4 очередями и разные категории доступа). С другой стороны, беспорядочный режим не вызывает беспокойства, мне нужны только широковещательные пакеты и пакеты, отправленные на конкретную станцию.

Что было бы правильным путем? Большая часть документации по доступу к необработанным сокетам, похоже, сосредоточена на сниффинге сети, и это не помогает. Я уже некоторое время поигрался с режимом монитора, но из того, что я читал до сих пор, полученные пакеты не подтверждаются в режиме монитора и т. Д. Без режима монитора что бы быть альтернативой? Используете режим ad hoc и сокеты unix raw? Или надо с драйверами возиться?

Я не ищу полного решения, просто несколько хороших идей, с чего начать. Я прочитал справочные страницы для сокетов (2), сокетов (7) и пакетов (7), но это не помогло в отношении поведения уровня MAC в разных режимах.

Заранее спасибо.


person rocktale    schedule 08.02.2012    source источник
comment
Вы можете посмотреть и увидеть, существует ли программное обеспечение с открытым исходным кодом для генерации тестового трафика, т. Е. Смесь действительных и недействительных пакетов, чтобы увидеть, как оборудование на другом конце обрабатывает это. Предположительно, это будет иметь возможность как выполнять полные обычные операции, так и произвольные вариации (для внесения желаемых ошибок). Если таковой существует, вы могли бы либо использовать его, либо учиться на нем.   -  person Chris Stratton    schedule 07.05.2012


Ответы (5)


802.11 - это спецификация протокола уровня 2 (и 1). Он был разработан таким образом, чтобы протоколы более высокого уровня могли рассматривать его как сеть Ethernet. Обращение и поведение в целом одинаковы. Таким образом, для протокола уровня 3 вам не следует вообще беспокоиться о 802.11 и писать свой код так, как если бы вы ожидали, что он будет работать в сети Ethernet.

Чтобы он заработал, вы должны сначала подключиться к какой-либо беспроводной сети (которая концептуально эквивалентна подключению провода к карте Ethernet). Здесь вы можете выбрать одноранговую (также известную как IBSS) или инфраструктурную (также известную как BSS) сеть (или PBSS после утверждения 802.11ad;).

Работа с картами без какой-либо связи с сетью (просто выдача пакетов в эфир) не является хорошей идеей по нескольким причинам. Самое главное, что он очень зависит от оборудования и ненадежен. Вы все еще можете сделать это, используя интерфейс RF mon (режим монитора AKA) с одной стороны и инъекцию пакетов (с использованием заголовка радиотопа) с другой, но я не рекомендую этого делать. Даже если у вас есть набор одинаковых карточек, вы, скорее всего, в какой-то момент столкнетесь с трудным для объяснения и случайным поведением. Сетевые адаптеры 802.11 просто не предназначены для такого рода операций и сохраняют различные состояния внутри микропрограмм (читайте о картах FullMAC и SoftMAC). Даже карты SoftMAC существенно различаются. Например, теоретически в режиме монитора, как вы сказали, карта не должна принимать пакеты ACK. Однако есть карты, которые в любом случае будут получать фрейм ACK, потому что они основывают свое решение исключительно на том факте, что упомянутый фрейм адресован им. Некоторые карточки могут даже попытаться подтвердить все фреймы, которые они видят. То же самое произойдет и с повторными передачами: некоторые карты отправят внедренный пакет только один раз (так и должно работать). В других сетевых адаптерах повторные передачи обрабатываются оборудованием (и прошивкой), и драйвер не может их отключить, поэтому вы получите автоматическую повторную передачу даже с введенными данными.

Придерживаясь уровня 3 и используя существующие режимы (например, ad hoc), вы получите все необходимые возможности и многое другое (QoS и т. Д.). Кадр Ethernet, который вы отправляете на интерфейс, будет "переведен" ядром в формат 802.11 с сопоставлением QoS и т. Д.

Если вы хотите узнать о поведении MAC в различных режимах, вам придется прочитать код mac80211 или сам стандарт 802.11. http://linuxwireless.org wiki я помогу вам с некоторыми вещами, но хакеры ядра обычно слишком заняты, чтобы писать документацию. чем комментарии в коде;)

Сама реализация протокола L3 также может быть выполнена либо в режиме ядра, либо в пользовательском режиме (с использованием сырых сокетов). Как обычно, на стороне ядра будет труднее, но мощнее.

person moorray    schedule 13.05.2012

Поскольку вы хотите создать собственный протокол сетевого уровня (замену IP), ключевое слово будет: "raw ethernet socket". Так что игнорируйте материал "Raw IP socket".

Вот с чего начать:

int sockfd = socket( PF_PACKET, SOCK_RAW, htons(XXX) ); 

Правильная страница руководства: packet (7).

Найдите дополнительную информацию, выполнив поиск в Google по ключевому слову. Один довольно полный пример здесь.

Изменить: ссылка на этот пример в настоящее время не работает: другие примеры

person SKi    schedule 12.05.2012
comment
Ссылка в качестве примера больше не активна. Не могли бы вы поделиться обновленной ссылкой (или дать ссылку на то, что искать, чтобы ее получить)? - person Ashray Malhotra; 31.08.2017

Возможно, вам нужно что-то вроде libpcap.

Libpcap позволяет читать / вводить необработанные пакеты из / в сетевой интерфейс.

person Paulo Scardine    schedule 07.05.2012

Во-первых, есть кое-что, о чем вы должны знать при попытке передать необработанные кадры 802.12 - драйвер устройства должен поддерживать внедрение пакетов.

Вы упомянули режим монитора, который на высоком уровне является эквивалентом возможности впрыска, который не является «режимом», а именно возможностью / функцией. Я говорю это потому, что некоторые драйверы устройств 892.11 в Linux:

  1. Поддержка режима монитора и инъекции кадра
  2. Поддержка режима монитора и не вставки кадров
  3. Ни поддержки

Я не знаю какого-либо простого способа проверить, поддерживает ли драйвер инъекцию кадра, кроме попытки инъекции кадра и обнюхивания воздуха на другом устройстве, чтобы убедиться, что он был замечен.

Режим монитора обычно легко проверить, используя sudo wlan0 set monitor и просмотрев код возврата и / или вывод.

Прошло несколько лет с тех пор, как я работал над этим, но в то время очень немногие устройства поддерживали режим монитора и внедрение кадров «из коробки». Многие поддерживали только режим монитора с модифицированной версией поставщика или драйвера ядра.

Убедитесь, что на вашем устройстве есть драйвер, полностью поддерживающий оба варианта. Такого рода задачи (мониторинг кадров и внедрение) обычны для тестировщиков проникновения, которые склонны использовать Kali Linux, который на самом деле представляет собой просто дистрибутив Ubuntu с кучей «взломанных» инструментов и (модифицированных) драйверов устройств 802.11, предварительно загруженных и находящихся в его репозиториях. Часто вы можете сэкономить время на поиске хорошо поддерживаемой карты, используя поисковую систему, чтобы найти устройство и драйвер, рекомендуемые для пользователей Kali.

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

На ваш главный вопрос о том, как это сделать, ответ почти наверняка будет libpcap, если вы пишете свое приложение. в C / C ++, поскольку libpcap предоставляет не только API захвата пакетов, но также API внедрения пакетов

Если вы делаете это на Python, scapy - отличный вариант. Преимущество Python / scapy в том, что

  1. Код на Python писать намного быстрее, чем на C
  2. scapy предоставляет значительное количество классов, которые можно использовать для интуитивно понятного создания кадра слой за слоем.
  3. Поскольку слои реализованы как классы, вы также можете расширять и «регистрировать» существующие классы, чтобы упростить создание определенных кадров (или синтаксический анализ при получении).

Вы можете сделать это на прямом C, используя API сокетов UNIX напрямую с необработанными сокетами, но вам придется иметь дело с вещами, которые libpcap существует для абстрагирования от вас, например, с базовыми системными вызовами, которые могут потребоваться при передаче сырых кадров, помимо стандартные звонки socket(), send(), recv(). Я предполагаю, что есть несколько ioctl вызовов, которые могут вам понадобиться, по крайней мере, специфичных для подсистемы / инфраструктуры ядра 802.11x, и эти ioctl() вызовы и их значения могут быть не полностью переносимы между различными основными версиями ядра. Должен признать, что в итоге я не использовал подход на чистом C (без libpcap), поэтому я не уверен на 100% в этой потенциальной проблеме. Это то, на что вам следует обратить внимание, если вы планируете делать это без libpcap. Я не рекомендую это, если у вас нет действительно веской причины

person adam    schedule 25.10.2020

Похоже, вы смешиваете медиа и транспортные слои.

802.11 - это то, что обычно называют «канальным», «физическим» или «медиа» уровнем, то есть он имеет дело только с передачей необработанных дейтаграмм.

Такие концепции, как ACK, повторные передачи, откат (управление потоком), применяются к «транспортному» уровню, и эти конкретные термины прочно связаны с TCP / IP.

Реализовать собственный полный транспортный уровень с нуля очень сложно и почти наверняка не то, что вы хотите делать. Если вместо этого вы хотите использовать существующий стек TCP / IP поверх своей собственной интерпретации 802.11, тогда вы, вероятно, захотите создать виртуальный сетевой интерфейс. Это будет действовать как посредник между TCP / IP и медиа-уровнем.

Надеюсь, это даст вам лучший контекст и ключевые слова для поиска.

person Seth Noble    schedule 07.05.2012
comment
OP не смешивает слои. Есть подтверждения и ретрансляции 802.11, см. Www.sss-mag.com/pdf/802_11tut.pdf - person abb; 07.05.2012
comment
Моя беда, я видел ACK, повторные передачи и откаты и связал все это с транспортным уровнем. - person Seth Noble; 07.05.2012