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

**URL:** <https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924>\
**Category:** Support Debian\
**Created:** [Août 18, 2019, 8:36 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924 "2019-08-18T08:36:37Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![nonsolum](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@nonsolum](https://www.debian-fr.org/u/nonsolum)\
**Post date:** [Août 18, 2019, 8:36 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/1 "2019-08-18T08:36:37Z")

</div>

Bonjour à tous,

Tout d’abord ma configuration :

```plaintext
root@kali1:~# uname -a
Linux kali1 4.19.0-kali5-amd64 #1 SMP Debian 4.19.37-6kali1 (2019-07-22) x86_64 GNU/Linux
root@kali1:~#

```

Oui, je sais : le forum Debian ne fait pas de support pour Kali.  
(il y a un [site](https://www.kali-linux.fr/) francophone Kali spécialisé à cet effet)  
Mais, à proprement dit, il ne s’agit pas d’un problème Kali mais d’un problème système : driver Wifi ou configuration Wifi.

Ma distribution Kali/Debian est installée en machine virtuelle (VM) avec pour hyperviseur Virtualbox sous Windows 10.  
Ma configuration Virtualbox est ainsi faite :

1- Une interface réseau « accès par pont » pontée sur mon interface hôte windows PCI Wifi.

[![](https://www.debian-fr.org/uploads/default/original/2X/e/e8718d0839590633d2725d293851e934c8c661e7.png)](http://zupimages.net/viewer.php?id=19/33/k5sl.png)

2- Un périphérique USB Wifi

[![](https://www.debian-fr.org/uploads/default/original/2X/9/9471c361775137adfb3a4c65b77e909409fd3079.png)](http://zupimages.net/viewer.php?id=19/33/ad70.png)

Ainsi j’ai deux connexions réseau :  
un accès par pont  
un accès direct par une clef USB Wifi

Voici ce que j’ai pu obtenir dans l’ordre :

**Etape 1**

Je démarre tout d’abord ma machine virtuelle :

- Je vois alors, au cours de l’Instanciation de la VM, la connexion réseau USB de ma machine hôte Windows disparaître
- Logique ? phénomène probablement dû au fait que c’est ma VM qui prend le relai et initialise sa propre interface ?

**Etape 2**

J’ouvre une session root (par défaut sur Kali) et lance un terminal administrateur :

Je vérifie si ma clef USB Wifi est bien prise en charge

```plaintext
root@kali1:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@kali1:~#

```

Effectivement, ça semble être le cas.

**Etape 3**

Je vais à la recherche des SSID des réseaux Wifi du voisinage :

```plaintext
root@kali1:~# iwlist wlan0 scan
wlan0 No scan results
root@kali1:~#

```

Là, problème : la commande est sans résultat.  
**`Pas de réseaux WIFI.`**  
Qu’est-ce à dire ?

**Etape 4**

Je vais un peu plus loin et affiche la configuration réseau :

```plaintext
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 80509sec preferred_lft 80509sec
    inet6 fe80::a00:27ff:fe3b:5619/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:c0:ca:59:47:bd brd ff:ff:ff:ff:ff:ff
root@kali1:~#

```

Bien.  
L’interface wlan0 de la clef Wifi est décelée.  
**Mais, problème, j’ai « …`noop state DOWN`… »**

**Etape 5**

Je tente alors :

```plaintext
root@kali1:~# ip link set dev wlan0 up
root@kali1:~#

```

Pas de retour. Que faut-il en penser ?

**Etape 6**

Je vérifie si le fichier de configuration, que j’avais renseigné dans une session antérieure, est correct:  
(je ne suis pas sûr, d’ailleurs, que ce soit le bon fichier de configuration)

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

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

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

```

**Etape 7**

Je teste une relance du service « `networking` »

```plaintext
root@kali1:~# service networking restart
Job for networking.service failed because the control process exited with error code.
See "systemctl status networking.service" and "journalctl -xe" for details.
root@kali1:~#

```

**Problème : la commande renvoie une erreur.**  
Certainement à cause de l’interface wlan0.  
Bête et discipliné, je vais donc à la recherche des logs :  
Tout d’abord :

```plaintext
root@kali1:~# systemctl status networking.service
● networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2019-08-17 19:22:56 CEST; 1h 20min ago
     Docs: man:interfaces(5)
  Process: 1724 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
 Main PID: 1724 (code=exited, status=1/FAILURE)

août 17 19:22:56 kali1 systemd[1]: Starting Raise network interfaces...
août 17 19:22:56 kali1 ifup[1724]: ifup: unknown interface wlan0
août 17 19:22:56 kali1 systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILU
août 17 19:22:56 kali1 systemd[1]: networking.service: Failed with result 'exit-code'.
août 17 19:22:56 kali1 systemd[1]: Failed to start Raise network interfaces.
root@kali1:~#

```

Ensuite :

```plaintext
root@kali1:~# journalctl -xe
août 17 20:43:21 kali1 systemd[1]: Starting Hostname Service...
-- Subject: L'unité (unit) systemd-hostnamed.service a commencé à démarrer
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- L'unité (unit) systemd-hostnamed.service a commencé à démarrer.
août 17 20:43:21 kali1 gnome-shell[1204]: loading user theme: /usr/share//themes/Kali-X/gnome-shell/gno
août 17 20:43:21 kali1 dbus-daemon[388]: [system] Successfully activated service 'org.freedesktop.hostn
août 17 20:43:21 kali1 systemd[1]: Started Hostname Service.
-- Subject: L'unité (unit) systemd-hostnamed.service a terminé son démarrage
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- L'unité (unit) systemd-hostnamed.service a terminé son démarrage, avec le résultat done.
août 17 20:43:51 kali1 systemd[1]: systemd-hostnamed.service: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- The unit systemd-hostnamed.service has successfully entered the 'dead' state.
août 17 20:45:01 kali1 CRON[1823]: pam_unix(cron:session): session opened for user root by (uid=0)
août 17 20:45:01 kali1 CRON[1824]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
août 17 20:45:01 kali1 CRON[1823]: pam_unix(cron:session): session closed for user root
root@kali1:~#

```

Ça ne me paraît pas très explicite.  
Mais quelqu’un aurait une idée ?

**Etape 8**

Je poursuis la configuration de mon interface Wifi

```plaintext
root@kali1:~# iwconfig wlan0 essid "mon_ssid_wifi" key "ma_clef_WPA" power on
root@kali1:~#

```

J’obtiens alors:

```plaintext
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:~# 

```

**Problème: «&nbsp;…`Access Point: Not-Associated`…&nbsp;»**  
Et puis un «&nbsp;`ip a`&nbsp;» me donne la même chose.

**Etape 9**

Je décide d’arrêter ma machine virtuelle Kali (shutdown).  
Et là surprise :  
Lors du processus d’arrêt de la VM, j’ai soudainement

[![](https://www.debian-fr.org/uploads/default/original/2X/9/9a0ac5cdcc54eeb97e3585c9cb446a540923307c.png)](http://zupimages.net/viewer.php?id=19/33/mf6v.png)

Je clique sur « `OK` » et je finis alors sur un état du système dit « Avortée »

[![](https://www.debian-fr.org/uploads/default/original/2X/a/ac6f1900fc40f984666e705207e10ea10c59060f.png)](http://zupimages.net/viewer.php?id=19/33/z28p.png)

A noter que je peux ensuite redémarrer, malgré tout, la VM sans problème.  
A noter également que cette erreur inopinée lors du shutdown n’est pas systématique.  
Mais je ne saurais dire en quelles circonstances exactes cela se produit.

Voilà mes mésaventures.  
J’espère avoir été suffisamment clair et explicite.

Merci pour votre attention.  
Je resterai attentif à vos suggestions

---

<div class="post-metadata">

**Author:** ![Albert](https://www.debian-fr.org/user_avatar/www.debian-fr.org/albert/32/8474_2.png) [@Albert](https://www.debian-fr.org/u/Albert)\
**Post date:** [Août 18, 2019, 10:18 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/2 "2019-08-18T10:18:45Z")

</div>

Bonjour,  
Je ne suis un spécialiste, mais je ne vois pas comment ta VM fait le lien «réseau» avec la clé USB Wi-Fi ( elle existe vraiment ?) de ton ordinateur. Ou bien je n’ai rien compris, ou j’essaierai de faire un «pont» réseau sur l’interface wifi voir si ça fonctionne.

---

<div class="post-metadata">

**Author:** ![choops](https://www.debian-fr.org/user_avatar/www.debian-fr.org/choops/32/8109_2.png) [@choops](https://www.debian-fr.org/u/choops)\
**Post date:** [Août 18, 2019, 11:27 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/3 "2019-08-18T11:27:58Z")

</div>

Salut

> [@nonsolum](#):
>
> ‹&nbsp;`etc/network/interfaces`&nbsp;›:
> 
> ```auto
> [...]
> auto wlan0
> allow-hotplug wlan0
> iface eth0 inet dhcp
> 
> ```

Ta faute est là : la ligne ‹&nbsp;`iface`&nbsp;› comprend ‹&nbsp;`eth0`&nbsp;› là où il devrait y avoir ‹&nbsp;`wlan0`&nbsp;›.

---

<div class="post-metadata">

**Author:** ![nonsolum](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@nonsolum](https://www.debian-fr.org/u/nonsolum)\
**Post date:** [Août 19, 2019, 9:01 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/4 "2019-08-19T09:01:50Z")

</div>

> [@Albert](#):
>
> je ne vois pas comment ta VM fait le lien «réseau» avec la clé USB Wi-Fi ( elle existe vraiment ?) de ton ordinateur

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

[![](https://www.debian-fr.org/uploads/default/original/2X/a/abfb3c24345a98b9047c76a7a3357b7a85c4d229.png)](http://zupimages.net/viewer.php?id=19/33/2bqe.png)

Voici un excellent topo :  
[Gestion réseau sur machine virtuelle.](https://chrtophe.developpez.com/tutoriels/gestion-reseau-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)

> [@choops](#):
>
> Ta faute est là : la ligne ‘ `iface` ’ comprend ‘ `eth0` ’ là où il devrait y avoir ‘ `wlan0` ’.

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

```plaintext
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 » :

```plaintext
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

```plaintext
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

```plaintext
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.

---

<div class="post-metadata">

**Author:** ![choops](https://www.debian-fr.org/user_avatar/www.debian-fr.org/choops/32/8109_2.png) [@choops](https://www.debian-fr.org/u/choops)\
**Post date:** [Août 19, 2019, 9:17 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/5 "2019-08-19T09:17:02Z")

</div>

> [@nonsolum](#):
>
> `Puis j’ai relancé le service « networking » :`
> 
> ```auto
> root@kali1:~# service networking restart
> root@kali1:~# 
> 
> ```

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:

```auto
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 :

```auto
iwlist wlan0 scan

```

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Août 19, 2019, 9:26 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/6 "2019-08-19T09:26:50Z")

</div>

> [@nonsolum](#):
>
> 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)

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.

---

<div class="post-metadata">

**Author:** ![Acksop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/acksop/32/8207_2.png) [@Acksop](https://www.debian-fr.org/u/Acksop)\
**Post date:** [Août 19, 2019, 6:51 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/7 "2019-08-19T18:51:27Z")

</div>

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](https://wiki.debian.org/fr/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…

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Août 19, 2019, 10:59 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/8 "2019-08-19T22:59:14Z")

</div>

> [@Acksop](#):
>
> `ifconfig` n’existe plus sous Debian 10

Bah si:

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

```

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

---

<div class="post-metadata">

**Author:** ![Acksop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/acksop/32/8207_2.png) [@Acksop](https://www.debian-fr.org/u/Acksop)\
**Post date:** [Août 19, 2019, 11:38 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/9 "2019-08-19T23:38:46Z")

</div>

> 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…

---

<div class="post-metadata">

**Author:** ![nonsolum](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@nonsolum](https://www.debian-fr.org/u/nonsolum)\
**Post date:** [Août 20, 2019, 7:44 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/10 "2019-08-20T07:44:21Z")

</div>

> [@mattotop](#):
>
> 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 ?

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(R) 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.**

> [@mattotop](#):
>
> 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.

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

[![](https://www.debian-fr.org/uploads/default/original/2X/f/ffdf546b05b16cd05313d33149c1e3e18fac0be3.png)](http://zupimages.net/viewer.php?id=19/34/7eo3.png)

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é.

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Août 20, 2019, 9:26 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/11 "2019-08-20T09:26:36Z")

</div>

> [@nonsolum](#):
>
> J’ai testé une désactivation

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 «&nbsp;ce pc&nbsp;», «&nbsp;gèrer&nbsp;» et aller dans le composant correspondant), en sélectionnant la clé, en appuyant sur «&nbsp;suppr&nbsp;» (l’équivalent de l’action clic droit «&nbsp;désinstaller le périphérique&nbsp;»), 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 «&nbsp;périphérique inconnu&nbsp;», c’est que c’est bon.]

---

<div class="post-metadata">

**Author:** ![nonsolum](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@nonsolum](https://www.debian-fr.org/u/nonsolum)\
**Post date:** [Août 20, 2019, 2:12 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/12 "2019-08-20T14:12:41Z")

</div>

> [@mattotop](#):
>
> Je ne parlais pas de désactivation, mais de supprimer la gestion par un pilote windows

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://www.debian-fr.org/uploads/default/original/2X/9/9471c361775137adfb3a4c65b77e909409fd3079.png)](http://zupimages.net/viewer.php?id=19/33/ad70.png)[https://zupimages.net/up/19/33/ad70.png[/img][/url](https://zupimages.net/up/19/33/ad70.png%5b/img%5d%5b/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.

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Août 20, 2019, 2:23 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/13 "2019-08-20T14:23:41Z")

</div>

> [@nonsolum](#):
>
> Virtualbox a besoin de connaître quel port USB est ouvert.

Je l’ai pensé, mais je n’étais pas sur qu’il ne soit pas capable de délèguer un «&nbsp;unknown device&nbsp;» à 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…

---

<div class="post-metadata">

**Author:** ![nonsolum](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@nonsolum](https://www.debian-fr.org/u/nonsolum)\
**Post date:** [Août 21, 2019, 2:52 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/14 "2019-08-21T14:52:50Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nonsolum](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@nonsolum](https://www.debian-fr.org/u/nonsolum)\
**Post date:** [Août 21, 2019, 3:57 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/15 "2019-08-21T15:57:09Z")

</div>

Je rajoute cela:

```nohighlight
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#

```

---

<div class="post-metadata">

**Author:** ![Albert](https://www.debian-fr.org/user_avatar/www.debian-fr.org/albert/32/8474_2.png) [@Albert](https://www.debian-fr.org/u/Albert)\
**Post date:** [Août 21, 2019, 4:11 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/16 "2019-08-21T16:11:01Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![grandtoubab](https://www.debian-fr.org/user_avatar/www.debian-fr.org/grandtoubab/32/4505_2.png) [@grandtoubab](https://www.debian-fr.org/u/grandtoubab)\
**Post date:** [Août 21, 2019, 5:18 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/17 "2019-08-21T17:18:05Z")

</div>

```auto
300 non mis à jour

```

ouarf!

```auto
sudo apt full-upgrade

```

---

<div class="post-metadata">

**Author:** ![mattotop](https://www.debian-fr.org/user_avatar/www.debian-fr.org/mattotop/32/3942_2.png) [@mattotop](https://www.debian-fr.org/u/mattotop)\
**Post date:** [Août 21, 2019, 9:41 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/18 "2019-08-21T21:41:47Z")

</div>

> [@grandtoubab](#):
>
> sudo apt full-upgrade

Tu m’étonnes…

> [@nonsolum](#):
>
> firmware-realtek

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 ? 😄

---

<div class="post-metadata">

**Author:** ![nonsolum](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@nonsolum](https://www.debian-fr.org/u/nonsolum)\
**Post date:** [Août 22, 2019, 8:39 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/19 "2019-08-22T08:39:29Z")

</div>

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](https://www.amazon.fr/ALFA-Network-AWUS036NH-150Mbit-adaptateur/dp/B00358XUC4/ref=as_li_ss_tl?_encoding=UTF8&pd_rd_i=B00358XUC4&pd_rd_r=46c82158-1011-11e9-9bbb-0f2d88eeddf9&pd_rd_w=oSrnI&pd_rd_wg=Ijut7&pf_rd_p=5d361e0c-9e85-4b01-8261-3ff932bec9c8&pf_rd_r=T6DMGXYC2X9CFCR2RT7K&psc=1&refRID=T6DMGXYC2X9CFCR2RT7K&linkCode=sl1&tag=kage03-21&linkId=8413dd034f6c1127ebffd43e54141c2c&language=fr_FR)

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](https://www.amazon.fr/Alfa-AWUS036ACH-AC1200-Adaptateur-Dual/dp/B00VEEBOPG/ref=as_li_ss_tl?ie=UTF8&qid=1547431492&sr=8-1&keywords=AWUS036ACH&linkCode=sl1&tag=kage03-21&linkId=3685b3ca80180c25713c48bb02e9dc8f&language=fr_FR)

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

---

<div class="post-metadata">

**Author:** ![nonsolum](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/n/3be4f8/32.png) [@nonsolum](https://www.debian-fr.org/u/nonsolum)\
**Post date:** [Août 29, 2019, 2:24 UTC](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924/20 "2019-08-29T14:24:39Z")

</div>

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](https://www.amazon.fr/ALFA-Network-AWUS036NH-150Mbit-adaptateur/dp/B00358XUC4/ref=as_li_ss_tl?_encoding=UTF8&pd_rd_i=B00358XUC4&pd_rd_r=46c82158-1011-11e9-9bbb-0f2d88eeddf9&pd_rd_w=oSrnI&pd_rd_wg=Ijut7&pf_rd_p=5d361e0c-9e85-4b01-8261-3ff932bec9c8&pf_rd_r=T6DMGXYC2X9CFCR2RT7K&psc=1&refRID=T6DMGXYC2X9CFCR2RT7K&linkCode=sl1&tag=kage03-21&linkId=8413dd034f6c1127ebffd43e54141c2c&language=fr_FR)

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](https://www.amazon.fr/Alfa-AWUS036ACH-AC1200-Adaptateur-Dual/dp/B00VEEBOPG/ref=as_li_ss_tl?ie=UTF8&qid=1547431492&sr=8-1&keywords=AWUS036ACH&linkCode=sl1&tag=kage03-21&linkId=3685b3ca80180c25713c48bb02e9dc8f&language=fr_FR)  
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 :

[![](https://www.debian-fr.org/uploads/default/original/2X/6/6c858cf26cb417591440ae4f69abef1746beafb1.png)](http://zupimages.net/viewer.php?id=19/35/zxsv.png)

**É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 »](https://github.com/aircrack-ng/rtl8812au) correspondant à mon matériel Alfa AWUS036ACH

**Étape 3**

- Configuration du fichier /etc/network/interfaces

**Explications :**

1. Abandon de la configuration client DHCP pour une IP fixe

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.**

1. Paramétrage des liaisons [« wpasupplicant »](https://wiki.debian-fr.xyz/Interfaces_et_wpasupplicant)

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 :

[![](https://www.debian-fr.org/uploads/default/original/2X/9/9a0ac5cdcc54eeb97e3585c9cb446a540923307c.png)](http://zupimages.net/viewer.php?id=19/33/mf6v.png)

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.

[Page suivante](https://www.debian-fr.org/t/configuration-reseau-wifi-sous-virtualbox-no-scan-results-access-point-not-associated-et-autres-balivernes/79924.md?page=2)