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

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.

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:

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.

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.