Co schází v madwifi-ng pro plnou podporu DFS a TPC?

11.9.2006 16:31 | Linux

Chtěl bych navrhnout našemu sdružením podpořit finančně projekt madwifi-ng, tak aby kompletně vyřešil problém s DFS a TPC, posílal jsem mail hlavnímu vývojáři, ten ale neví co vše schází, já to taky nevím. Nevíte tedy někdo ze zkušenějších lidí v oblasti wifi co je třeba dodělat v aktuální verzi madwifi-ng abychom se nemuseli bát ČTU?

       

Komentáře

[Opičák]

No já to klidně taky finančně podpořím, ale musí se najít někdo, kdo změří/prokáže, že ty nové funkce opravdu fungují jak mají podle toho jak si vymyslelo ČTÚ. Jinak to nemá žádný smysl.

[Thunder.m]

Toto mi přišlo mailem od jednoho člověka, který psal kdysi do madwifi o DFS.

Hello Mirek,


>> Hi, i would like to send donation (about 100 - 1000 euro) on madwifi 
>> project to fully implement DFS and TPC futures, but i dont know what is 
>> missing, or what is not working corectly and i dont know specifications 
>> of DFS and TPC futures. Can you tell me what is missing, or what need to 
>> be done to fully support those futures?


Well, a simple question, but a difficult answer.

An 802.11h compliant client has to implement
  - Dynamic Frequency Control
  - TPC (Power Control)
  - Radar Detction

The behaviour of a client differs from that of an AP. And the Network
has to be managed on 5 GHz (not "AD-HOC" -> a card in this regulatory
domain must not allow to be set to AD-HOC mode).

DFC: When an AP is powered on, it has to choose a channel (randomly - for
e.g. not starting every time with "1"). It should chect for radar.
The time before he uses this channel (transmitting, broadcasting it's SSID)
is specified.
The AP has to scan ervery 24h for N seconds for a new channel (and
no radar should be detected - it has to wait 1 min, if i remember correctly). 
Ideally it should find a channel which currently is not in use.
Problem: The specification insisists in waiting if there's radar. Thus a
Link which is up 24h/day, has a downtime by spec of 365 minutes a year(!).

RD: if radar is detected, the AP should "shut down" the channel immediately.
Thus it has to find a new channel. The channel where radar is detected,
should be marked persistantely for no-use for n hours (i think it was
1 hour). Persistantly means, the mark should be honourd even after reboot /
powercycle.
Problem: DOS Attack. If every channel is marked, the Link is dead.

A client searches for / follows the AP.
Ideally the client does not probe actively (MAC layer protocol), this means,
it is silent until it has seen "his" AP.
Imagine you have a link, not with AP and client, but with two APs and WDS.
And both APs have to do RadioRetection. Well, how they'll find each other?
How they both signalize that they've detected radar?
RD of a client: i do not remember exactly. I think it's a should, but not
a must. If a client detects RD and the AP honours: -> possible DOS attack
by a random client..

TPC: A client should to TPC. If not, the EIRP should be, if i remember
correctly, 3dB lesser than regulatory maximum. 
But TPC should not be difficult to implement. 1W EIRP in Europe on 5GHz
is interesting, because it's better than 100mW on 2.4GHz (even when considering
FreeSpaceLoss).

For our link we've built, we first thought to use two WRAP Boards running linux.
But imhow, MadWifi does not match the requirements. Finaly, i decided
to buy a licensed 802.11h AP, and use the WRAP board as client.
With the half the max. EIRP (TPC for a client conforming to the spec);
RD is tested (but i do not know if it response "in time", due to the spec,
and there's a potential problem because it do not know if the client could
tell the AP that he had to shut down the channel. Fortunately, it did not
happen since the few weeks the link is already up).

As far as i think, a madwifi card could not be used as 802.11h AP, because
too much is missing.

For all those things (TPC, DFC, RD and some more) there are detailed
requirements in the spec. A fully compliant driver has to be conform to
them.

The regulations are a pain. Unfortunately, here in europe the 5GHz band
is in military use. And they are pedantic with everything.. 
Furthermore, this band is in use for Plane->Airport radar (the main reason
why RD is specified); thus it's understandable, why they insist on this
mechanism.


The spec we're talking about is 
  http://webapp.etsi.org/action/OP/OP20050729/en_301893v010301o.pdf
Our authority (BeNetzA (previously RegTP)) refers to this spec
(which is nerby still a draft) for further details.


I think the development should go in these steps:
  - implement all the 802.11h client specs
    - ideally: certify them with a decent card (for e.g. atheros wistron cm9,
      which is widely in use)
  - implement the 802.11h AP specs
    - certify this one too
  - think about WDS


Btw, A great problem i personaly had, was that it's not easy to make
messurements in this band. I configured the card to use n mW, and tried
to interprete the result with a wlan sniffer. A card which may be certified
for madwifi should be calibrated to the power settings as well.


And now, is it what you liked to hear?  ;) 

Regards,
  - Thomas

[Dan]

CTU nevymyslelo nic, je to vyplod od ETSI...

[Opičák]

Ať je to výplod od koho chce, ČTÚ je tu v republice ten orgán, který to tu řídí a který si určuje pravidla a který je může měnit. Takže tu není o čem debatovat.

[T.Dulík]

Aktuální stav toho, co chybí v Madwifi pro plnou podporu 802.11h: http://dev.lintrack.org/ticket/52