Peut-on répondre à une demande de sonde sur un canal différent?

19

Je surveille le trafic 802.11 sur mon réseau, et en particulier le sondage actif depuis mon smartphone. J'envoie des demandes de sonde pour certains SSID cachés, mais aussi une demande de sonde non dirigée, censée révéler des réseaux correspondant aux capacités annoncées par mon appareil.

Je suis en Europe, donc nous pouvons utiliser plus de canaux qu'aux États-Unis, je pense (non?) Et donc ils se chevauchent.

Comme prévu, le balayage s'effectue à tour de rôle sur différents canaux, mais ce qui me surprend, c'est ce comportement:

Une demande de sonde non dirigée envoyée sur le canal 5 est répondue par un AP sur le canal 6. Ce comportement est-il tout à fait normal, c'est-à-dire défini n'importe où dans les spécifications officielles?

EDIT: Voici le contenu de la demande et de la réponse de la sonde, je fonde mon hypothèse sur l'ensemble de paramètres DS: canal actuel. Photo sur i.imgur

La différence de temps entre les deux images est de 4 ms, et je n'ai observé aucune autre activité sur les vagues pendant cette période.

EDIT: Voici la commande que j'exécute avec airodump-ng 1.0 airodump-ng -c 6 mon0

et l'outil de capture montre les balises provenant des points d'accès sur les canaux 2 à 9. Pour moi, cela signifie que airodump accepte tous les paquets visibles sur une plage de fréquences, sans les rejeter selon le paramètre de canal actuel, est logique pour des raisons de performances.

Si le routeur a le même comportement pour répondre aux demandes de sonde ... c'est peut-être la raison. (Commencer à remettre en question la sélectivité des filtres de fréquence utilisés dans nos routeurs bien-aimés.)

EDIT 1:

Ce comportement est-il 1) reproductible, est-ce que quelqu'un avec un appareil qui fonctionne pourrait essayer de l'observer? 2) spécifié quelque part dans les références 802.11? Je ne pouvais pas le trouver moi-même.

EDIT 2:

Merci à tous ceux qui ont essayé de répéter cette configuration jusqu'à présent. Voici ma dernière tentative pour obtenir une explication à cela. Je dois continuer: P Voici l'ordre exact dans lequel j'ai fait les choses.

root@mymachine:~# iwconfig :: no mon interface, wlan0 is managed, not associated, and on channel 6: 2.437GHz
root@mymachine:~# airmon-ng start wlan0 6 :: mon0 created, set on channel 6: 2.437GHz

Ceci est confirmé plus tard par un autre iwconfig. (sur un sidenote, je peux changer le canal de wlan0, et mon0 reste indépendant.)

root@mymachine:~# airodump-ng mon0 --channel 6 -w out --output-format pcap :: start a capture on channel 6, write to a file. 

Observation: airodump-ng n'affiche aucun changement de canal, le coin supérieur gauche est fixé sur le numéro 6. Cependant, les balises observées sur les canaux 2 à 11 ... -> Apparemment aucune sélectivité et passage des arguments aux deux airmon-ng et airodump-ng semblent inutiles.

Observé avec:
CHIPSET Intel 4965 driver iwlwifi CHIPSET
Atheros AR 9271 driver ath9k

Capture d'écran: capture d'écran

olamotte
la source
Bonne question ... Pour info, aux États-Unis, les canaux 1, 6 et 11 802.11b / g sont les seuls canaux qui ne se chevauchent pas
Mike Pennington
@MikePennington merci pour la confirmation.
olamotte
2
Faites-vous spécifiquement que l'appareil envoie uniquement des sondes sur le canal 5? Sinon, un appareil sondera tous les canaux et écoutera les réponses sur ces canaux (moins de 100 ms). Je ne peux que penser que ce serait la raison pour laquelle vous obtenez des réponses sur le canal 6. (Cela se produira même si votre carte est configurée pour utiliser un canal spécifique, c'est juste comment le sondage fonctionne)
Artanix
@Artanix Je comprends que la carte envoie des requêtes de sonde sur chaque canal, mais elle le fait à son tour, et je les vois: je me demande si j'ai peut-être manqué des paquets lors de la capture. Je vais télécharger une capture d'écran Wireshark.
olamotte
Plutôt interessant. Le délai entre les chaînes n'est pas si grand, mais si cela se produit définitivement comme vous le suggérez. Ensuite, je dirais que vous avez répondu à votre propre question par "oui";) Je n'ai pas encore de carte sans fil qui fonctionne avec Wireshark, donc je ne peux pas me tester.
Artanix

Réponses:

6

Ce qui se passe, c'est que votre appareil sans fil, même lorsqu'il est réglé sur le canal 6 (2437), a également une faible probabilité de recevoir des trames des canaux voisins, tels que les canaux 5 et 7. et encore plus (avec moins de probabilité).

Cela dépend fortement de l'interface sans fil que vous utilisez. La pire radio que j'ai trouvée était un adaptateur USB basé sur AR9170, qui pouvait capter le trafic sur le canal 1 lorsqu'il était tourné pour le canal 6. Certaines autres interfaces (par exemple AR9280) n'ont pas ce problème, ou il est assez réduit.

PS: AR9271 n'est pas pris en charge par le pilote ath9k, mais par le pilote ath9k_htc. Étant donné que cette carte semble être le successeur naturel de l'AR9170, je ne suis pas surpris que vous rencontriez le même problème.

BatchyX
la source
C'est donc un problème de sélectivité: merci de partager votre expérience avec ce phénomène.
olamotte
J'ai finalement trouvé une explication dans un livre blanc de 2004 de Devin Akin intitulé "Protection Ripple in ERP 802.11 WLAN". Il est démontré la capacité d'un point d'accès sur le canal 1 à entendre des balises d'un point d'accès sur le canal 11. Voir page 5; cwnp.com/cmsAdmin/uploads/… Je ne comprends toujours pas pourquoi l'AP capterait un signal si loin dans la bande de fréquences ...
olamotte
@olamotte: C'est juste un décalage de fréquence de 50/2412 = 2% ...
BatchyX
@BachyX Et je suis d'accord avec vous, ces 50 MHz sont tolérables. Ma question concerne la décision d'écouter (interpréter / traiter) des signaux qui ne sont pas diffusés sur le canal sur lequel l'appareil est configuré pour fonctionner. La sélection automatique des canaux pour que l'AP fonctionne ne nécessite pas cette IMO.
olamotte
6

Les captures sans fil ne sont pas identiques à une capture filaire. Dans une capture filaire, vous choisissez simplement votre interface et commencez à capturer des images.

Avec une capture sans fil, vous sélectionnez votre adaptateur, mais vous devez également choisir si vous allez surveiller un canal ou balayer plusieurs (ou tous) les canaux. Il y a des avantages pour les deux et il faut comprendre quand les utiliser.

Dans votre exemple, puisque vous effectuez une capture sur deux canaux différents, soit vous utilisez deux périphériques de capture différents, soit vous capturez pendant le balayage des canaux, mais je suppose que vous balayez. Cela signifie qu'il s'arrête sur un canal pendant une certaine période de temps, capture le trafic et passe ensuite au suivant.

Voici donc comment je vois cela se jouer le plus probablement:

  1. Le périphérique de capture commence la surveillance sur le canal 5.
  2. Le périphérique client envoie une demande de sonde sur le canal 5.
  3. Le périphérique client passe au canal 6 et envoie une demande de sonde.
  4. Le périphérique de capture se déplace vers le canal 6 et commence la surveillance.
  5. AP envoie une réponse de sonde sur le canal 6.

Au final, votre capture récupère la demande de sonde sur le canal 5, mais ensuite la réponse de la sonde sur le canal 6.

Chaque outil de capture sans fil que j'ai utilisé vous permettra de sélectionner un seul canal à surveiller. Je soupçonne que si vous définissez cela sur le canal 5, vous obtiendrez les demandes de sonde sans réponse. Si vous le définissez sur le canal 6, vous verrez à la fois les demandes de sonde et les réponses.

YApprendre
la source
Je vais essayer de reproduire la configuration et voir ce qui se passe. J'utilisais airodump-ng avec son option de canal, pourrait-il y avoir une erreur silencieuse qui ne m'a pas dit cela. Je suis d'accord, je ne devrais pas voir les demandes de sonde sur d'autres canaux, mais comme les appareils sont vraiment proches les uns des autres (quelques pouces) dans mon bureau, je trouve cela étrange. Je vais vérifier. Pour l'instant, d'après votre réponse, je comprends que l'APS ne répond que sur son canal attribué et ne se fait pas de publicité sur les canaux à proximité. Merci.
olamotte
Il peut être possible d'avoir le scénario que vous fournissez (les canaux se chevauchent et certains trafics seront compréhensibles là où les sous-porteuses se chevauchent), cependant votre capture (si elle est sur un canal) ne doit pas indiquer qu'elle capture sur deux canaux.
Apprendre
J'ai fourni les paramètres airmon-ng que je tape ... Blâmer le logiciel semble un peu facile, et j'ai reformulé ma question initiale: ce comportement est-il 1) reproductible, est-ce que quelqu'un avec un appareil qui fonctionne pourrait essayer de l'observer 2) spécifié quelque part dans les références 802.11? Je ne pouvais pas le trouver moi-même.
olamotte