Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • État Fermée
  • Pourcentage achevé
    100%
  • Type Anomalie
  • Catégorie LAN → WiFi
  • Assignée à Personne
  • Système d'exploitation
  • Sévérité Haute
  • Priorité Très Basse
  • Basée sur la version 1.1.3
  • Due pour la version Non décidée
  • Échéance Non décidée
  • Votes
  • Privée

FS#8678 - hostapd-0.7.3 : Mauvais "Probe Response frame" de l'AP

Bonjour! :)

Suite à mon commentaire :
http://bugs.freeplayer.org/task/4311#comment38558

Il ne faut pas tenir compte des spécifications IEEE 802.11n/D7.0, 11.14.3.2 dans hostapd : un AP qui fait du 40 MHz doit scanner les réseaux présents sur N +/- et ne pas s’activer si un autre AP est présent. Sinon quand hostapd démarre, il scanne les réseaux voisins et n’active jamais le HT40 (voir “Probe Response frame” dans le commentaire) car hostpad détecte (à tort) que le canal secondaire est déjà pris :

Démarrage daemon hostapd...
>Configuration file: /etc/hostapd/hostapd.conf
>20/40 MHz operation not permitted on channel pri=6 sec=2 based on overlapping BSSes
>Using interface wlan0 with hwaddr 44:1d:61:db:5f:76 and ssid ‘Nexus6’

Il faut patcher hostapd pour ne pas activer se mécanisme, qui semble trop restrictif, je n’ai pas de voisin sur le “primary channel” ‘6’ ou sur le “secondary channel” ‘2’...

Mon patch IEEE_802.11n_D7.0.patch :

# cat IEEE_802.11n_D7.0.patch
— ../src.orig/ap/hw_features.c 2011-10-31 02:53:02.329856225 +0100
+++ ../src/ap/hw_features.c 2011-10-31 02:52:56.213933114 +0100
@@ -442,15 +442,15 @@

              oper40 = ieee80211n_check_40mhz_2g4(iface, scan_res);
      wpa_scan_results_free(scan_res);


- if (!oper40) {
- wpa_printf(MSG_INFO, “20/40 MHz operation not permitted on "
- “channel pri=%d sec=%d based on overlapping BSSes”,
- iface→conf→channel,
- iface→conf→channel +
- iface→conf→secondary_channel * 4);
- iface→conf→secondary_channel = 0;
- iface→conf→ht_capab &= ~HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET;
- }
+ if (!oper40) {
+
wpa_printf(MSG_INFO, “20/40 MHz operation not permitted on "
+ “channel pri=%d sec=%d based on overlapping BSSes”,
+
iface→conf→channel,
+ iface→conf→channel +
+
iface→conf→secondary_channel * 4);
+ iface→conf→secondary_channel = 0;
+
iface→conf→ht_capab &= ~HT_CAP_INFO_SUPP_CHANNEL_WIDTH_SET;
+ //}

      hostapd_setup_interface_complete(iface, 0);

}

Ma config hostapd.conf :
##### IEEE 802.11n related configuration ######################################
ieee80211n=1
ht_capab=[HT40-][GF][SHORT-GI-20][SHORT-GI-40][RX-STBC12][MAX-AMSDU-3839][DSSS_CCK-40]

Résultat hostapd est bien en HT20/HT40, primary channel ‘6’ et secondary channel offset ‘below’ :

#iw dev wlan9 scan
BSS 52:bc:d4:b2:4b:d9 (on wlan9)

      TSF: 25497984 usec (0d, 00:00:25)
      freq: 2437
      beacon interval: 100
      capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431)
      signal: -64.00 dBm
      last seen: 5136 ms ago
      Information elements from Probe Response frame:
      SSID: Nexus6
      Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 
      DS Parameter set: channel 6
      ERP: <no flags>
      Extended supported rates: 24.0 36.0 48.0 54.0 
      RSN:     * Version: 1
               * Group cipher: CCMP
               * Pairwise ciphers: CCMP
               * Authentication suites: PSK
               * Capabilities: (0x0000)
      HT capabilities:
              Capabilities: 0x127e
                      HT20/HT40
                      SM Power Save disabled
                      RX Greenfield
                      RX HT20 SGI
                      RX HT40 SGI
                      RX STBC 2-streams
                      Max AMSDU length: 3839 bytes
                      DSSS/CCK HT40
              Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
              Minimum RX AMPDU time spacing: 8 usec (0x06)
              HT TX/RX MCS rate indexes supported: 0-15
      HT operation:
               * primary channel: 6
               * secondary channel offset: below
               * STA channel width: any
               * RIFS: 0
               * HT protection: no
               * non-GF present: 0
               * OBSS non-GF present: 0
               * dual beacon: 0
               * dual CTS protection: 0
               * STBC beacon: 0
               * L-SIG TXOP Prot: 0
               * PCO active: 0
               * PCO phase: 0

Au vu de ce mesage, si vous n’y comprenez toujours rien, on me téléphone...
http://bugs.freeplayer.org/task/6178

/Nexus6

– Merci d’être avec nous!

Fermée par  mbizon
03.11.2011 09:40
Raison de la fermeture :  Impossible à reproduire
Admin
mbizon a commenté le 31.10.2011 11:03

Est ce que vous avez une idée de la raison pour laquelle cette recommendation existe dans la spec ?

Nexus6 a commenté le 02.11.2011 07:48

Bonjour!

Oui, cela permet d’éviter les collisions de canaux entre les APs en mode HT20/HT40 en 2.4GHz et en 5GHz
http://standards.ieee.org/getieee802/download/802.11n-2009.pdf (Voir section 11.14.3.2 Scanning requirements for a 20/40 MHz BSS)

Les règles de la section section 11.14.3.2 sont mal implémentées, elles sont trop restrictives actuellement hostapd...
J’ai fait quelques tests, je monte un AP sur tous les canaux de 1 à 11, à chaque fois j’ai en réponse :
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2437,2417>

Test en HT40+ :
Neighboring BSS: 76:d9:ac:11:16:84 freq=2447 pri=8 sec=12
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2412,2432>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2417,2437>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2422,2442>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2427,2447>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2432,2452>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2437,2457>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2442,2462>

Test en HT40- :
Neighboring BSS: 76:d9:ac:11:16:84 freq=2447 pri=8 sec=12
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2432,2412>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2437,2417>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2442,2422>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2447,2427>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2452,2432>
40 MHz pri/sec mismatch with BSS 76:d9:ac:11:16:84 <2447,2467> (chan=8+) vs. <2462,2442>
12 -
13 -

C’est une freebox V5 canal 8/above (en 40MHz elle!) :
CH 8 ][ Elapsed: 12 s ][ 2011-11-01 16:47 ][ fixed channel mon0: -1
BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
76:D9:AC:11:16:86 -70 25 134 0 0 8 54e OPN FreeWifi
76:D9:AC:11:16:85 -70 25 134 0 0 8 54e WPA2 CCMP PSK <length: 0>
76:D9:AC:11:16:84 -69 23 134 0 0 8 54e WPA2 CCMP PSK <length: 0>
76:D9:AC:11:16:87 -70 25 134 0 0 8 54e WPA TKIP MGT freephonie

Test avec le patch :
Démarrage daemon hostapd...
Configuration file: /etc/hostapd/hostapd.conf
Received scan results (20 BSSes)
40 MHz affected channel range: [2402,2452] MHz Tested BSS 00:24:d4:ca:7c:48 <2437,2437> (pri=6- sec=0) vs. <2437,2417>
Neighboring BSS: 00:24:d4:ca:7c:48 freq=2437 pri=6 sec=0
Tested BSS 00:24:d4:ca:7c:49 <2437,2437> (pri=6- sec=0) vs. <2437,2417>
Neighboring BSS: 00:24:d4:ca:7c:49 freq=2437 pri=6 sec=0
Tested BSS 00:17:33:ce:30:8c <2412,2412> (pri=0- sec=0) vs. <2437,2417>
Neighboring BSS: 00:17:33:ce:30:8c freq=2412 pri=0 sec=0
Tested BSS 8a:17:33:ce:30:8d <2412,2412> (pri=0- sec=0) vs. <2437,2417>
Neighboring BSS: 8a:17:33:ce:30:8d freq=2412 pri=0 sec=0
Tested BSS 00:24:d4:9c:96:98 <2412,2412> (pri=1- sec=0) vs. <2437,2417>
Neighboring BSS: 00:24:d4:9c:96:98 freq=2412 pri=1 sec=0
Tested BSS 00:14:7f:ab:45:87 <2437,2437> (pri=0- sec=0) vs. <2437,2417>
Neighboring BSS: 00:14:7f:ab:45:87 freq=2437 pri=0 sec=0
Tested BSS 76:d9:ac:11:16:84 <2447,2467> (pri=8+ sec=12) vs. <2437,2417>
Tested BSS 76:d9:ac:11:16:85 <2447,2467> (pri=8+ sec=12) vs. <2437,2417>
Tested BSS 76:d9:ac:11:16:86 <2447,2467> (pri=8+ sec=12) vs. <2437,2417>
Tested BSS 76:d9:ac:11:16:87 <2447,2467> (pri=8+ sec=12) vs. <2437,2417>
Tested BSS b2:5d:9e:21:9b:d4 <2462,2482> (pri=11+ sec=15) vs. <2437,2417>
Tested BSS b2:5d:9e:21:9b:d5 <2462,2482> (pri=11+ sec=15) vs. <2437,2417>
Tested BSS b2:5d:9e:21:9b:d6 <2462,2482> (pri=11+ sec=15) vs. <2437,2417>
Tested BSS b2:5d:9e:21:9b:d7 <2462,2482> (pri=11+ sec=15) vs. <2437,2417>
Tested BSS 00:24:d4:9c:96:99 <2412,2412> (pri=1- sec=0) vs. <2437,2417>
Neighboring BSS: 00:24:d4:9c:96:99 freq=2412 pri=1 sec=0
Tested BSS 02:1f:9f:ae:1d:b4 <2412,2412> (pri=0- sec=0) vs. <2437,2417>
Neighboring BSS: 02:1f:9f:ae:1d:b4 freq=2412 pri=0 sec=0
Tested BSS 00:1f:9f:ae:1d:b3 <2412,2412> (pri=0- sec=0) vs. <2437,2417>
Neighboring BSS: 00:1f:9f:ae:1d:b3 freq=2412 pri=0 sec=0
Tested BSS ee:9f:ef:35:46:dc <2462,2482> (pri=11+ sec=15) vs. <2437,2417>
Tested BSS ee:9f:ef:35:46:dd <2462,2482> (pri=11+ sec=15) vs. <2437,2417>
Tested BSS ee:9f:ef:35:46:de <2462,2482> (pri=11+ sec=15) vs. <2437,2417>
20/40 MHz permitted on channel pri=6+ sec=5-2
Completing interface initialization
Mode: IEEE 802.11g Channel: 6 Frequency: 2437 MHz

Le patch qui corrige le test des BSSes voisins sur les plages des canaux en HT20/HT40, IEEE_802.11n_D7.0_11.14.3.2.patch :
http://pastebin.com/zErANFfV

Je soumets le patch au Monsieur! Non je le garde pour moi! :)

/Nexus6

– !

Admin
mbizon a commenté le 02.11.2011 13:51

Le comportement est normal et votre patch est incorrect.

Avec une BSS existante sur le channel 8, il est impossible d’avoir une autre BSS en 40mhz sur la bande 2.4

Meme en utilisant le chan le plus bas, primary 1 et secondary 5, on déborde jusqu’au channel 8 inclus.

Nexus6 a commenté le 02.11.2011 15:01

Bonjour,

C’est bizarre, si c’est bien le comportement correcte d’un AP en 802.11n, il suffit d’avoir un seul AP box V5 en 40MHz (j’en ai deux visibles en 40MHz primaire 8+ et 11+) qui pollue le 2.4GHz pour qu’un AP box V6 ne monte pas en 40MHz! Si le premier arrivée, est bien le premier servi en 802.11n, je ne trouve pas ce comportement correcte...

Pourriez-vous m’expliquer svp, le débordement suivant (je suis pri=6+ sec=5/2) :
Tested BSS 76:d9:ac:11:16:84 <2447,2467> (pri=8+ sec=12) vs. <2437,2417>
Les fréquences n’ont pas l’aire de déborder entre elles !?

Je suis dans environnement Wi-Fi que je trouve “calme”, si vous prenez un carré de 100m dans Paris, il y a 500 APs... beaucoup de monde risque d’être déçu par le 802.11n!

/Nexus6

– !

Admin
mbizon a commenté le 02.11.2011 16:31

Vous avez bien compris, et la Freebox V5 ne fait pas bien son boulot car elle devrait passer en 20Mhz si un AP apparait après démarrage. Le 40Mhz sur la bande 2.4 a été très controversé lorsqu’il a été proposé, et n’est passé que par la promesse de règles de coexistence stricte.

Sachez qu’en G pur, et c’est plutôt méconnu, les canaux sont espacés de 5Mhz bien que le spectre soit de 20Mhz. Ce qui veut dire qu’en utilisant le canal 3, vous “perturbez” les canaux 1, 2, 4 et 5.

Si vous êtes dans un environnement contrôlé et que vous désirez utiliser 4 AP, il faut donc les placer sur les canaux 1, 5, 9 et 13.
cf http://en.wikipedia.org/wiki/List_of_WLAN_channels

Nexus6 a commenté le 03.11.2011 07:34

Bonjour,

Merci pour ces infos!
J’ai bien compris qu’entre 2,4GHz et 2,5GHz il y a 100Mhz et que 14 canaux de 20MHz se chevauchent obligatoirement dans cette bande G.

Mon patch est correcte dans un environnement non contrôlé et perturbé! :)

/Nexus6

Chargement...

Activer les raccourcis clavier

Liste des tâches

Détails de la tâche

Édition de la tâche