[Ninux-Wireless] Announcing the Wireless Battle Mesh v3.1416 (Florenville (BE), 3-4-5 Sep 2010)
Announcing the Wireless Battle Mesh v3.1416 (Florenville (BE), 3-4-5 Sep 2010) The Wireless Battle Mesh edition v3.1416 will be held during a 3-day camp in Florenville, near Orval (South of Belgium). The Wireless Battle Mesh version 3.1416 aims to test a network of 30 isolated routers with different routing protocols (OLSR, BATMAN, Babel), in a countryside environnement (cows, trees, pastures, and forests). Date Start: Friday 03 Sep @ 09:00 End: Sunday 05 Feb @ 20:00 Goals = * Setup of a testbed of 30 nodes, some of them on batteries in remote locations (solar and wind powered) * Data collection, statistics and reproductibility of the experience * Degustation of local beers We provide == * space for your tent * electricity * toilets and showers * internet connectivity Do not forget: == * Bring your laptop/computer * Bring your compatible router(s) with OpenWRT pre-installed * Bring your WiFi antenna(s) and connectors * Bring your tent and sleeping bag Fee === We ask for a participation fee of 15EUR for the 3 days, in order to cover the basic running costs of the event. This does not include food nor beverages. Location Henrion Benjamin rue de Barsinvaut 16 6820 Florenville Tel: +32-484-566109 Tel: +32-61-315211 Google Maps: http://ur1.ca/065p6 Lat/Long: 49.695821, 5.304556 Transport = Florenville is easily reachable by train (2h00 from Brussels) or by car (1h30 from Brussels, 1h30 from Luxembourg (.lu), more details at http://battlemesh.org/BattleMeshV3.1416#Transport Registration Please register with an email to b...@udev.org with: 1. Name, Surname, and Nickname 2. Address and country 3. Date of arrival and departure 4. Mean of transportation Web === * http://battlemesh.org/BattleMeshV3.1416 * http://www.olsr.org * http://www.pps.jussieu.fr/~jch/software/babel/ * http://en.wikipedia.org/wiki/B.A.T.M.A.N. Contact == Benjamin Henrion Email: b...@udev.org GSM: +32-484-566109 Tel: +32-61-315211 IRC: zoobab on Freenode ___ Battlemesh mailing list battlem...@ml.ninux.org http://ml.ninux.org/mailman/listinfo/battlemesh ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] ath5k
Ciao. On 08/02/2010 12:03 PM, Antonio Anselmi wrote: Il 02 agosto 2010 10.22, Antonio Anselmi tony.anse...@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 ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] ath5k
Il 05 agosto 2010 10:57, cl...@ninux.org ha scritto: Ciao. On 08/02/2010 12:03 PM, Antonio Anselmi wrote: Il 02 agosto 2010 10.22, Antonio Anselmi tony.anse...@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. (to be continued) Antonio ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] ath5k
Il 05 agosto 2010 12:16, Antonio Anselmi tony.anse...@gmail.com ha scritto:
Il 05 agosto 2010 10:57, cl...@ninux.org ha scritto:
Ciao.
On 08/02/2010 12:03 PM, Antonio Anselmi wrote:
Il 02 agosto 2010 10.22, Antonio Anselmi tony.anse...@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.0 +0200
+++ b/drivers/net/wireless/ath/regd.c 2010-08-05 22:05:36.0 +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_5850REG_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
Re: [Ninux-Wireless] ath5k
Francamente sono tentato di affondare il coltello nel codice... ma mi sembra un po' troppo esagerato liberare 5660-5700. come avrai capito è altrettanto facile portare tutto a 30dbm. Enrico ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
