[Ninux-Wireless] ath5k

[Antonio Anselmi]

Il 05 agosto 2010 12:16, Antonio Anselmi <tony.anselmi a gmail.com> ha scritto:
> Il 05 agosto 2010 10:57,  <clauz a ninux.org> ha scritto:
>> Ciao.
>>
>> On 08/02/2010 12:03 PM, Antonio Anselmi wrote:
>>> Il 02 agosto 2010 10.22, Antonio Anselmi <tony.anselmi a gmail.com> ha scritto:
>>>> A parte che la frase "ai canali che si possonon usare" e' sibillina
>>>> per via di quel "non"... :)  il problema che ho e' far lavorare una
>>>> NanoStation5 sui canali LEGALI che vanno da 100 a 140.
>>>>
>>>> I problemi che incontro sono diversi:
>>>>
>>>> 1) garantire il rispetto di DSF e TPC come da normativa ETSI
>>>> 2)  Madwifi non riesce ad associarsi ad un AP (Loco5) operante sul
>>>> canale 136, ne' usando il countricode 0 ne' l'860 (il 380 per l'italia
>>>> vede solo i canali bassi perche' Madwifi e' vecchio e superato).
>>>>
>>>> Lorenzo mi ha suggerito di usare ath5k, dicendo che funziona tutto...
>>>> ma ora si aggiungono le seguenti complicanze:
>>>>
>>>> 4) dalla home di openwrt.org:
>>>> "Known Issues: Currently 5 GHz channels do not work with mac80211
>>>> based drivers due to DFS regulatory issues."
>>>> e questo - se non superato" - toglie qualsiasi chance di usare ath5k per 802.11a
>>>>
>>>> 5) QUALORA il 4) fosse superato, ergo sia possibile usare ath5k sui
>>>> canali 100-140 (...e francamente lo ignoro), credo sia preferibile
>>>> usare una immagine derivata da backfire 10.03 piuttosto che da
>>>> kamikaze 8.09.2.
>>>
>>> UPDATE
>>> ... rispondo a me stesso :) ma credo sia utile comunque alla lista
>>
>> Infatti! Grazie!
>>
>>>
>>> dato che Robin2 lavora con ath9k sulle M2 e M5 e che e' compilato sul
>>> branch backfire, e' ragionevole supporre che i problemi dei canali a
>>> 5GHz siano superati sul branch (rimangono sul tagged 10.03)... almeno
>>> per quanto concerne ath9k.
>>> Resta ora da compilare l'ultima revisione r22454 del branch
>>> configurata per ath5k.
>>>
>>> Qualcuno ha gia' provato?
>>> (to be continued)
>>
>> Ha funzionato?
>>
>> Clauz
>
> preciso che i test riguardano compilazioni su branch backfire r22498
> (il piu' aggiornato al momento in cui scrivo).
>
> Ho abbandonato i test su ath5k dato che il chipset montato sulla NS5
> (AR2313) o il bus AHB (o entrambi) non e' (al momento ?)  supportato.
> Per quanto riguarda ath9k (test su NanoStation M5 AR71xx):
>
> - i canali 100-140 sono disponibili con il countrycode 380 ad
> eccezione dei canali 120,124 e 128 che sono disabilitati
> - i canali 100-140 sono settati come: passive-scanning, no IBSS, radar detection
>
> quindi sul range in questione non e' possibile andare in ad-hoc e
> credo che quanto sopra (proveniente da crda) sia conseguente al
> regolamento DFS.
>
> Ad ogni modo - e se scrivo stronzate mi corregerete - a parer mio
> credo che l'ottemperanza alle specifiche DFS debba essere rispettata
> SOLO in caso in modalita' master (AP) in quanto in modalita' managed
> (STA) la radio tenta di associarsi ...e non si annuncia quindi come
> AP.

ho patchato regd.c di compat-wireless cosi' da poter andare in ad-hoc
sui canali DFS, pur mantenendo il radar-dectec:

--- a/drivers/net/wireless/ath/regd.c	2010-08-03 19:13:57.000000000 +0200
+++ b/drivers/net/wireless/ath/regd.c	2010-08-05 22:05:36.000000000 +0200
@@ -42,8 +42,7 @@
 /* We allow IBSS on these on a case by case basis by regulatory domain */
 #define ATH9K_5GHZ_5150_5350	REG_RULE(5150-10, 5350+10, 40, 0, 30,\
 				NL80211_RRF_PASSIVE_SCAN | NL80211_RRF_NO_IBSS)
-#define ATH9K_5GHZ_5470_5850	REG_RULE(5470-10, 5850+10, 40, 0, 30,\
-				NL80211_RRF_PASSIVE_SCAN | NL80211_RRF_NO_IBSS)
+#define ATH9K_5GHZ_5470_5850    REG_RULE(5470-10, 5850+10, 40, 0, 30, 0)
 #define ATH9K_5GHZ_5725_5850	REG_RULE(5725-10, 5850+10, 40, 0, 30,\
 				NL80211_RRF_PASSIVE_SCAN | NL80211_RRF_NO_IBSS)

@@ -164,7 +163,7 @@
 /* Frequency is one where radar detection is required */
 static bool ath_is_radar_freq(u16 center_freq)
 {
-	return (center_freq >= 5260 && center_freq <= 5700);
+	return 0;
 }

 /
e questo e' il risultato da iw phy0 info:

	Frequencies:
			* 5180 MHz [36] (17.0 dBm)
			* 5200 MHz [40] (17.0 dBm)
			* 5220 MHz [44] (17.0 dBm)
			* 5240 MHz [48] (17.0 dBm)
			* 5260 MHz [52] (20.0 dBm) (radar detection)
			* 5280 MHz [56] (20.0 dBm) (radar detection)
			* 5300 MHz [60] (20.0 dBm) (radar detection)
			* 5320 MHz [64] (20.0 dBm) (radar detection)
			* 5500 MHz [100] (20.0 dBm) (radar detection)
			* 5520 MHz [104] (20.0 dBm) (radar detection)
			* 5540 MHz [108] (20.0 dBm) (radar detection)
			* 5560 MHz [112] (20.0 dBm) (radar detection)
			* 5580 MHz [116] (20.0 dBm) (radar detection)
			* 5600 MHz [120] (disabled)
			* 5620 MHz [124] (disabled)
			* 5640 MHz [128] (disabled)
			* 5660 MHz [132] (20.0 dBm) (radar detection)
			* 5680 MHz [136] (20.0 dBm) (radar detection)
			* 5700 MHz [140] (20.0 dBm) (radar detection)
			* 5745 MHz [149] (30.0 dBm)
			* 5765 MHz [153] (30.0 dBm)
			* 5785 MHz [157] (30.0 dBm)
			* 5805 MHz [161] (30.0 dBm)
			* 5825 MHz [165] (30.0 dBm)

e la NanoStation-M5 esegue correttamente olsrd sul canale 136 su waln0
in ad-hoc, domani approfondiro' i test con una seconda M5 (Bullet ?)
per le prove olsrd.

Francamente sono tentato di "affondare" il coltello nel codice... ma
mi sembra un po' troppo esagerato liberare 5660-5700.

Antonio