История изменений
Исправление nickleiten, (текущая версия) :
Тут важно понимать сам стандарт 802.11 и реализацию «в железе». Для затравочки, большинство современных адаптеров (в простейшем случае) состоят из PHY + MAC/PCU частей и обвязки интерфейса подключения. Драйвер настраивает PHY (каналы, мощность и т.п.) и работает, как правило с MAC/PCU. Последняя - это аппаратная реализация простейших алгоритмов 802.11 (реакция на ACK, RTS/CTS, аггрегирование фреймов в DMA буфере). Плюс, начиная с 802.11n в стандарте стала обязательна функция WME/WMM (Wireless Multimedia Extencions), которая предполагает разделение трафика на 4 группы, плюс в драйверах есть группа для BEACONS (и всех служебных фреймов, у них другие параметры CCA, запрещено аггрегирование, ожидание ACK и т.д.).
В PCU передаются только DMA-запакованные фреймы в одну из цепочек WMM на передачу, и PCU сам решает как агрегировать фреймы в воздухе. Соответственно, посылая собственноручно сформированный служебный фрейм драйвер должен уметь оповестить (если это возможно) об этом PCU часть устройства, иначе она будет считать это простыми данными и слать их в эфир по логике обычных фреймов с данными.
В простейшем случае в конкретном драйвере конкретного чипа нужно добавить hook в цепочке tx, на правильную идентификацию этих служебных данных, чтоб устройство не пыталось быть «слишком умным». Как правило это поддерживают большинство устройств, но в драйвере это может быть и не реализовано. Потому вы и наблюдаете обычное аггрегирование RTS фреймов.
ЗЫ. На Qualcomm-Atheros, например, есть другая проблема - пересчёт поля duration блоком PCU, отключить который можно только исправив сам ath9k.
Исходная версия nickleiten, :
Тут важно понимать сам стандарт 802.11 и реализация «в железе». Для затравочки, большинство современных адаптеров (в простейшем случае) состоят из PHY + MAC/PCU частей и обвязки интерфейса подключения. Драйвер настраивает PHY (каналы, мощность и т.п.) и работает, как правило с MAC/PCU. Последняя - это аппаратная реализация простейших алгоритмов 802.11 (реакция на ACK, RTS/CTS, аггрегирование фреймов в DMA буфере). Плюс, начиная с 802.11n в стандарта стала обязательна функция WME/WMM (Wireless Multimedia Extencions), которая предполагает разделение трафика на 4 группы, плюс группа для BEACONS (и всех служебных фреймов, у них другие параметры CCA, запрещено аггрегирование, ожидание ACK и т.д.).
В PCU передаются только DMA-запакованные фреймы в одну из цепочек WMM на передачу, и PCU сам решает как агрегировать фреймы в воздухе. Соответственно, посылая собственноручно сформированный служебный фрейм драйвер должен уметь оповестить (если это возможно) об этом PCU часть устройства, иначе она будет считать это простыми данными и слать их в эфир по логике обычных фреймов с данными.
В простейшем случае в конкретном драйвере конкретного чипа нужно добавить hook в цепочке tx, на правильную идентификацию этих служебных данных, чтоб устройство не пыталось быть «слишком умным». Как правило это поддерживают большинство устройств, но в драйвере это может быть и не реализовано. Потому вы и наблюдаете обычное аггрегирование RTS фреймов.
ЗЫ. На Qualcomm-Atheros, например, есть другая проблема - пересчёт поля duration блоком PCU, отключить который можно только исправив сам ath9k.