Перейти к содержимому
Калькуляторы

Probe response - правильно ли я понимаю спек?

Ситуация такая: ТД в beacon-е шлет HT capabilities , как и предписывается стандартом N. То же самое происходит в Probe response, когда приходит Probe request от N-карточки. А вот когда приходит Probe request от G-карточки, то в ответе HT capabilities отсутствуют.

Правильно ли я понимаю, что это не есть правильное поведение и HT capabilities должны быть частью Probe response в любом случае, ибо сказано:

 

The HT Capabilities element is present when

dot11HighThroughputOptionImplemented attribute is TRUE.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ситуация такая: ТД в beacon-е шлет HT capabilities , как и предписывается стандартом N. То же самое происходит в Probe response, когда приходит Probe request от N-карточки. А вот когда приходит Probe request от G-карточки, то в ответе HT capabilities отсутствуют.

Правильно ли я понимаю, что это не есть правильное поведение и HT capabilities должны быть частью Probe response в любом случае, ибо сказано:

 

The HT Capabilities element is present when

dot11HighThroughputOptionImplemented attribute is TRUE.

При работе с G карточкой Ваша ТД переключается на другой стандарт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При работе с G карточкой Ваша ТД переключается на другой стандарт.
Страсти какие. А если у меня две карточки? Одна G, другая - N?

По-моему, путаете ;)

 

Вообще, откуда вопрос возник:

клиент (RaLink 2780, ЕМНИП) подключается то как G, то как - N. Посмотрели сниффер - сам клиент по разному шлет пробы: иногда с НТ, иногда - без. Почему - другой вопрос. Вот и думаю я: а правильно ли то, что ТД отвечает клиенту тем же, что он у нее спросил?

Изменено пользователем -Ars-

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При работе с G карточкой Ваша ТД переключается на другой стандарт.
Страсти какие. А если у меня две карточки? Одна G, другая - N?

По-моему, путаете ;)

С каждой картой работает в своем стандарте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С каждой картой работает в своем стандарте.

Я понимаю :) Но вопрос был не в том. Вопрос был в том, должен ли Probe response (т.е. еще до association request) содержать все, что ТД умеет, или только ответ на то, что содержится в probe request клиента?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кажется, я все-таки неправильно понимаю спек. ТД должна отвечать тем, что содержится в probe request от клиента. Короче, баг у ралинка ;)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Этот баг у большинства оборудования B/G/N - клиенты не поддерживающие N к такой точке не могут присоединится.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Короче, баг у ралинка ;)
А может быть и нет...
тот баг у большинства оборудования B/G/N - клиенты не поддерживающие N к такой точке не могут присоединится.
Это баг у производителей точек, их заказчики не допинали на тему совместимости ;)

 

А я в полной растеряности. Точки с карточкой от RaLink отвечают всем спектром поддерживаемых фич. Точки с карточкой от Atheros отвечают в соответствии с тем, что было в Probe request.

Еще забавнее: клиенты с чипом от RaLink мультикастом шлют НТ, в юникасте - не шлют, а в Association request шлют, как получится.

 

Блин, а как же всё-таки должно быть? :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.