Configuration réseau WIFI sous Virtualbox: No scan results, Access Point: Not-Associated et autres balivernes

nonsolum · Août 19, 2019, 2:50pm

J’ai utilisé deux technologies différentes pour mes deux connexions qui sont indépendantes l’une de l’autre :

1- Un pont réseau sous configuration réseau de VirualBox en pointant sur mon interface wi-fi (chipset PCI)

Cela donne

Voici un excellent topo :
Gestion réseau sur machine virtuelle.

2- Un accès directe sur une clef USB Wifi qui existe bien ; et j’ai paramétré en conséquence Virtualbox en déclarant cette clef USB (chipset Ralink 802.11)

Effectivement ça ne pouvait pas marcher ainsi.
(Je suis passé plusieurs fois dessus sans rien voir)
J’ai donc rectifié :

root@kali1:~# cat /etc/network/interfaces

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
root@kali1:~#

Puis j’ai relancé le service « networking » :

root@kali1:~# service networking restart
root@kali1:~#

Cette fois-ci plus d’erreur.
La commande s’est passée correctement.

Mais le reste des problèmes subsistent :

Problème n°1

root@kali1:~# iwconfig wlan0
wlan0     IEEE 802.11  ESSID: "Mon_ssid_WIFI »"  
      Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
      Retry short  long limit:2   RTS thr:off   Fragment thr:off
      Encryption key: Ma_clef_WPA
      Power Management:on
      
root@kali1:~#

J’ai toujours :
« … Access Point: Not-Associated … »

Problème n°2

root@kali1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:3b:56:19 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.28/24 brd 192.168.1.255 scope global dynamic eth0
       valid_lft 85294sec preferred_lft 85294sec
    inet6 fe80::a00:27ff:fe3b:5619/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:c0:ca:59:47:bd brd ff:ff:ff:ff:ff:ff
root@kali1:~#

J’ai toujours « …state DOWN… »

Je ne sais pas quoi penser de tout cela.

choops · Août 19, 2019, 9:17am

Le fait de simplement redémarrer le service networking peut ne pas suffir. Un down puis up de ton interface wifi peut la ramener à la vie:

ip link set wlan0 down
ip link set wlan0 up

Il faudra peut-être aussi repousser un petit scan des SSID accessibles, comme visiblement ça ne trouve pas :

iwlist wlan0 scan

mattotop · Août 19, 2019, 9:26am

Il y a un truc dont je ne suis pas sûr en relisant (c’est un peu long/touffu, et je découvre le fil de discussion):
Tu as bien d’un coté une carte wifi gérée par windows sur laquelle tu mets ton pont VB, et SEPAREMENT une clé ralink que tu veux utiliser dans ta VM ?
Ce sont bien 2 matos distincts ?

Parceque si ta clé est matériellement gèrée par windows, et que tu essayes ensuite de la controler >aussi< depuis ta VM, sans avoir la garantie que c’est impossible, ça me semble douteux que deux OS puissent piloter en même temps un même matériel.

Sinon, si ce sont bien deux matos distincts, il est possible que windows, même si tu lui dis de ne pas l’utiliser en désactivant juste le matériel détecté, prenne quand même la main dessus avant de la désactiver.
Dans ce cas (suggestion au feeling), il faut peut être, dans le gestionnaire de périphérique, aller carrément supprimer le pilote associé au matos, pour qu’il ne soit plus reconnu du tout par windows, et qu’il soit enfin dispo en matériel brut, non initialisé/géré par windows, pour ta VM.

En espérant avoir été compréhensible.

Acksop · Août 19, 2019, 7:03pm

Juste une question pour clarifier: veux -tu absolument configurer le wifi sur ta VM ou seule une connection cablée par pont suffirait ?

D’après ce que j’ai pu voir par le passé, la connection par pont d’une VM debian sous une virtualbox windows nécessite de donner l’adresse du réseau (network, brodcast,mask) et de spécifier en statique la passerelle qui est partagé avec ton pc Windows ainsi que l’adresse réseau de la machine virtuelle. Je me demande si ce n’est pas le coeur de ton problème avec la connection par pont WIFI que tu as faite.

Seulement j’ai remarqué qu’ifconfig n’existe plus sous Debian 10, par contre pour iwconfig, je ne saurais dire… Mais je ne me suis jamais penché sur ce problème, je n’utilisait pas de connection wifi sur mes VM, et je ne suis pas vraiment à jour avec les nouvelles commandes…

mattotop · Août 19, 2019, 10:59pm

Bah si:

mj@mercure:~$ sudo which ifconfig
/sbin/ifconfig

Simplement, il faut penser à passer en root avec su -

Acksop · Août 19, 2019, 11:39pm

Simplement, il faut penser à passer en root avec su -

Désolé de la bourde…
J’ai encore du mal à m’y faire, cette commande ne m’étais pas familière avant que je vienne sur le forum…

nonsolum · Août 20, 2019, 7:49am

Oui, bien sûr. Comme je l’ai indiqué précédemment il s’agit bien de deux « matos » différents.
Sinon ça ne pourrait pas marcher.
1- Un chipset WIFI sur la carte mère de mon portable :
Intel® Dual Band Wireless-AC 3168

Celui-ci me sert de pontage réseau.
A noter qu’il n’est pas vu par la VM Kali comme une interface WIFI mais comme une interface virtuelle Ethernet.
(c’est le principe même de l’accès réseau par pont pour les hyperviseurs tel que Virtualbox)
Donc pas de voisinage Wifi sur cette interface.
C’est ce pourquoi j’ai installé une clef Wifi sur un port USB.

2- Donc, une clef Wifi sur port USB.
802.11n USB Wireless LAN Card

Cette clef est sensé me donner un accès direct aux réseaux Wifi.
Et c’est cette interface Wifi qui me pose problème.

J’ai testé une désactivation sous l’hôte Windows de la clef WIFI (802.11n USB Wireless LAN Card)

Et lorsque je teste mon réseau :

root@kali1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:3b:56:19 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.28/24 brd 192.168.1.255 scope global dynamic eth0
       valid_lft 85981sec preferred_lft 85981sec
    inet6 fe80::a00:27ff:fe3b:5619/64 scope link 
       valid_lft forever preferred_lft forever
root@kali1:~#

La machine virtuel Kali ne détecte même pas mon interface Wifi qui devrait être en wlan0
Donc impasse de ce côté.

mattotop · Août 20, 2019, 9:28am

Je ne parlais pas de désactivation, mais de supprimer la gestion par un pilote windows, en allant dans le gestionnaire de périphérique (clic droit sur “ce pc”, “gèrer” et aller dans le composant correspondant), en sélectionnant la clé, en appuyant sur “suppr” (l’équivalent de l’action clic droit “désinstaller le périphérique”), pour qu’il n’y ai >aucun< pilote qui se gére la clé.

Juste désactiver la connexion n’empêche pas le pilote de commencer par prendre la main sur la clé avant de l’éteindre, je crois.

[edit: l’autodétection va peut être réinstaller le pilote, mais tant que la clé s’affiche comme “périphérique inconnu”, c’est que c’est bon.]

nonsolum · Août 20, 2019, 2:17pm

J’ai essayé, sans grande conviction, cette suggestion.
Ça ne marche pas.

C’est logique.
Virtualbox a besoin de connaître quel port USB est ouvert.
Et donc de pointer sur le périphérique ad hoc à savoir » Ralink 802.11 n WLAN » précisément le composant qu’on désinstalle.

https://zupimages.net/up/19/33/ad70.png[/img][/url)]

J’ai beau réinstaller après coup le périphérique, une fois la VM Kali en fonction.
Ça ne change rien. Je me retrouve au point de départ avec une interface wlan0 non configurée.

mattotop · Août 20, 2019, 2:23pm

Je l’ai pensé, mais je n’étais pas sur qu’il ne soit pas capable de délèguer un “unknown device” à la VM.
Désolé du test inutile.

Bon, toujours dans les trucs au feeling, est ce que ton paquet firmware-ralink est bien installé ?
Sait on jamais…

nonsolum · Août 21, 2019, 2:52pm

Oui effectivement, ça pourrait venir du pilote firmware ralik

Mais je n’y crois pas trop.
Car je n’ai rien eu à installer: ma distribution Kali a ce driver déjà de préinstallé.
De plus la commande “lsusb” renvoie bien le bon driver.

Merci à tous
Je vais poursuivre mes recherches

nonsolum · Août 21, 2019, 4:19pm

Je rajoute cela:

root@kali:~/rtl8812au#  apt-get install firmware-realtek
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
firmware-realtek est déjà la version la plus récente (20190717-1).
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  kali-desktop-common libdouble-conversion1 libgeos-3.7.1 libhttp-parser2.8
  libigdgmm5 python-mockito python-whoosh suckless-tools
Veuillez utiliser « apt autoremove » pour les supprimer.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 300 non mis à jour.
root@kali:~/rtl8812au#

Albert · Août 21, 2019, 4:11pm

Bonjour,
Je suis curieux : est-ce que cette installation (VM, dongle wifi) a déjà fonctionné chez toi par le passé ?
Je ne connais pas Kali, peut-être pourrais-tu essayer de créer une VM avec une distribution qui gère nativement tous, ou la plupart, des matériels. Peut-être y verrais-tu plus clair.
Enfin je dis ça, mais je n’ai pas de solution. En revanche ce concept me plait beaucoup sur une VM.

grandtoubab · Août 21, 2019, 5:18pm

300 non mis à jour

ouarf!

sudo apt full-upgrade

mattotop · Août 21, 2019, 9:41pm

Tu m’étonnes…

C’était juste pour me faire du mal que tu as choisi de tester les firmware-realtek plutôt que firmware-ralink, ou bien c’est parce que tu as confondu ?

nonsolum · Août 22, 2019, 8:39am

J’ai fait le ménage:

root@kali:~# apt-get install firmware-realtek
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
firmware-realtek est déjà la version la plus récente (20190717-1).
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
root@kali:~#

Apparemment il s’agit bien d’une realtek

ALFA Network AWUS036NH Carte réseau WLAN 150 Mbit/s - Cartes réseau (sans Fil, USB, WLAN, Wi-FI 4 (802.11n), 150 Mbit/s)

Que l’on trouve notamment chez Amazone:

ALFA Network AWUS036NH

Mais, j’ai aussi:

root@kali:~# apt-get install firmware-ralink
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
firmware-ralink est déjà la version la plus récente (20190717-1).
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
root@kali:~#

Donc peu importe realtek et ralink; j’ai les drivers d’installés les plus récents.

Je vais d’ailleurs tester une autre clef USB:

Alfa AWUS036ACH AC1200 Adaptateur USB Dual Band

Je veux voir d’où vient le problème

nonsolum · Août 31, 2019, 10:38am

Me revoilà pour vous annoncer :
AFFAIRE RÉSOLUE

Tout d’abord une mise au point :
La clef USB que j’ai testée en premier lieu
ALFA Network AWUS036NH

est en réalité une Ralink et non une Realtek comme mentionnée par erreur.

Par contre la clef, que j’ai testée ensuite et que je compte adopter définitivement,
Alfa AWUS036ACH
est bien une Realtek

Et c’est cette dernière que j’ai configurée de la manière qui suit.
A noter que j’ai fait ces tests sous une nouvelle machine virtuelle Kali « propre »

Étape 1

Sous Virtualbox configuration du port USB où<se trouve la clef WIFI :

Étape 2

Ouverture d’une session de ma machine virtuelle et ouverture d’un terminal en privilèges root.
Installation du driver « rtl8812au-5.3.4 » correspondant à mon matériel Alfa AWUS036ACH

Étape 3

Configuration du fichier /etc/network/interfaces

root@kali3:~# cat /etc/network/interfaces
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback

auto eth0:1
allow-hotplug eth0:1
iface eth0:1 inet dhcp

auto wlan0:1
iface wlan0:1 inet static
address 192.168.1.40
netmask 255.255.255.0
wpa-ssid "mo essid "
wpa-psk “ma clef WPA en clair”
root@kali3:~#

Explications :

Abandon de la configuration client DHCP pour une IP fixe

…auto wlan0:1
iface wlan0:1 inet static
address 192.168.1.40
netmask 255.255.255.0…

En effet il semblerait que le serveur DHCP de ma Livebox ne trouve pas la VM kali.
Même après coup par un « dhclient -r wlan0 »
Question à approfondir.

Paramétrage des liaisons « wpasupplicant »

wpa-ssid "mo essid "
wpa-psk “ma clef WPA en clair”

Ceci, lors de mes premiers tests, m’avait complètement échappé.
Je ne connaissais d’ailleurs pas la syntaxe.

A noter qu’il faut, par ce procédé, mettre en clair la clef WPA(2).
Ceci est un trou manifeste de sécurité.
Il suffit d’un « cat /etc/network/interfaces » pour afficher la clef avec les privilèges d’un simple user si je ne m’abuse.
Ce problème de sécurité n’a pas grande importance sous Kali.
Kali est un outil Pentest utilisé avec des privilèges root et qui n’est pas une distribution Linux destinée à un usage courant.
Si c’était une machine en production je ne ferais pas ça.

Question à approfondir.

Étape 4

Prise en compte de la nouvelle configuration du fichier « interfaces »
root@kali3:~# service networking restart
root@kali3:~#

Étape 5
Vérifications.

root@kali3:~# iwconfig wlan0
wlan0     IEEE 802.11an  ESSID:"Mon essid"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:5.22 GHz  Access Point: A4:3E:51:38:CC:00   
          Bit Rate:300 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=99/100  Signal level=-57 dBm  Noise level=0 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0
root@kali3:~# 


root@kali3:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:68:10:ff brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.45/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
       valid_lft 86149sec preferred_lft 86149sec
    inet6 fe80::a00:27ff:fe68:10ff/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether f2:ad:34:2c:11:34 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.40/24 brd 192.168.1.255 scope global wlan0:1
       valid_lft forever preferred_lft forever
root@kali3:~#

Étape 6

Arrêt de la machine
j’ai toujours ce problème :

J’ai essayé cela

root@kali3:~# rfkill list
0: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
root@kali3:~# 

root@kali3:~# rfkill block  0
root@kali3:~#

root@kali3:~# rfkill list
0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
root@kali3:~#

Mais c’est sans effet.
Question à approfondir.

Tout est maintenant OK et ça fonctionne.
(mises à part « mes questions à approfondir » qui ne sont pas bloquantes)

A noter que j’ai testé une distribution Debian classique avec la même procédure avec succès.

Merci à tous pour votre patience et vos contributions.

Albert · Août 29, 2019, 5:12pm

Bonjour,
Pour la clé WPA, la solution ne serait-elle pas ici ?

mattotop · Août 29, 2019, 5:48pm

Non, en fait, c’est l’inverse, c’est ta kali qui demande une adresse au dhcp et ne reçoit aucune réponse, mais c’est un détail.

Parce que c’est une méthode possible mais tu peux passer ton mot de passe en crypté:
https://debian-facile.org/doc:reseau:wpasupplicant#ajouter-un-profil-wifi

Mais wpa-supplicant est une manière de gèrer ton wifi qui n’est pas la mieux intégrée à la mécanique debian actuelle, par défaut, c’est plutôt le network manager qui marche le mieux en “tout automatique dhcp toussa”.

Et l’ip statique, c’est trés bien aprés tout.

Ben ça, c’est un probléme qui apparait dans une fenètre windows, non ?
Ca vient peut être d’une mauvaise “fermeture” de l’usb à l’extinction de la kali ou un truc comme ça.
Aucune idée.

PS: Un XP en VM, je me demande à quels abandonwares tu t’adonnes avec.

nonsolum · Août 31, 2019, 10:38am

Oui, je connais le dialogue serveur/client DHCP

DHCPDISCOVER (pour localiser les serveurs DHCP disponibles)
DHCPOFFER (réponse du serveur à un paquet DHCPDISCOVER, qui contient les premiers paramètres)
DHCPREQUEST (requête diverse du client pour par exemple prolonger son bail)
DHCPACK (réponse du serveur qui contient des paramètres et l’adresse IP du client)

Peut-être est-ce effectivement la requête DHCPDISCOVER qui n’arrive pas à joindre le serveur DHCP?
Je l’ignore.
Je constate simplement que lorsque j’attribue une IP fixe à ma VM Kali et que je tente un ping « IP WIFI de la VM » depuis ma machine hôte, j’obtiens bien une réponse de la VM.
(et réciproquement)

Merci Albert c’est exactement ce que je recherchais.
Je suis passé à côté. Comme quoi Google n’est pas infaillible.
J’ai donc procédé suivant les indications de la page Web.

root@kali3:~# wpa_passphrase "mon_essid" "ma clef_wpa_en_clair"
network={
	ssid="mon_essid"
	#psk="ma clef_wpa_en_clair"
	psk=code_de_la_clef_wpa_renvoyé_par_commande_wpa_passphrase
}
root@kali3:~#

Puis :

root@kali3:~# cat /etc/network/interfaces

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto eth0:1
allow-hotplug eth0:1
iface eth0:1 inet dhcp

auto wlan0:1
iface wlan0:1 inet static
address 192.168.1.40
netmask 255.255.255.0
wpa-conf managed
wpa-ap-scan 1
wpa-scan-ssid 1
wpa-ssid "mon_essid"
wpa-key-mgmt WPA-PSK
wpa-psk  "code_de_la_clef_wpa_renvoyé_par_commande_wpa_passphrase"
root@kali3:~#

Et tout est OK maintenant pour la question sécuritaire.

Effectivement cette erreur s’affiche sous Windows.
Lors de shutdown probablement au moment où la machine virtuelle passe la main à Windows pour reprendre en charge le clef USB.

J’ai résolu le problème en désactivant, sous l’interface Virtualbox, le contrôleur USB avant de faire mon shutdown.

Bonne soirée à tous.