Partage de connexion internet via wifi

Ce ne sont pas des interfaces virtuelles (elles sont bien réelles) ni des alias (elles ont des adresses mac différentes, un +1 au dernier octet). Il s’agit bien d’une nouvelle interface avec le même chip. Les contraintes existent: les interfaces doivent utiliser le même canal, mais pour le reste j’ai l’impression que c’est libre ou presque. Avec les cartes atheros, les interfaces ath0, ath1 se crée par par exemple
wlanconfig ath0 create wlandev wifi0 wlanmode ap
(configuration ath0)
wlanconfig ath1 create wlandev wifi0 wlanmode ap
(configration ath1)
mais nécessite les drivers madwifi.
Je ne sais pas quelles sont les possibilités des différentes cartes sur ce point mais c’est visiblement intéressants.

Par contre, ce sont les multiples points d’accès crées qu’on appelle (bizarrement) virtuels. Voir par exemple zeroshell.net/fr/wireless-access-point/

edit: Je viens de voir que certaines cartes ont un mode repéteur (voir iwconfig). J’ai l’impression qu’il y a beaucoup de variétés d’une carte à l’autre.
redit: de ce que je viens de voir, on dirait que seul les cartes atheros/madwifi supporte les points d’accès multiples. Ils font donc en général deux cartes WIFI.

Mise à jour de mon script pour Wheezy.

pour-les-scripts-c-est-ici-t3548-300.html#p415449

Testeurs bienvenus.

(il faut toujours 2 interfaces wifi)

franb, je pense que tu n’es plus à jour! avec iw, on parle bien d’interfaces virtuelles (vif)
Elles sont associées à une interface physique, mais sont relativement indépendantes. Je n’ai pas trouvé de contraintes particulières, comme par exemple utiliser le même canal. Le driver doit utiliser la pile mac80211, et évidement implémenter les modes que l’on veut utiliser.

wireless.kernel.org/en/users/Doc … on/iw/vif/
Il ne faut plus utiliser le déprécié iwconfig.

[quote=“piratebab”]franb, je pense que tu n’es plus à jour! avec iw, on parle bien d’interfaces virtuelles (vif)
Elles sont associées à une interface physique, mais sont relativement indépendantes. Je n’ai pas trouvé de contraintes particulières, comme par exemple utiliser le même canal. Le driver doit utiliser la pile mac80211, et évidement implémenter les modes que l’on veut utiliser.[/quote]
Exact, je date! Mais je suis sceptique sur la possibilité de tout faire, voià ce que je viens de tester sur une carte atheros (module ath9k, wheezy). Prometteur mais pas gagné!

iw phy phy0 interface add wlan1 type managed ifconfig -a Interface rename4 crée et non wlan1, on fait avec iwlist scan iw rename4 connect FreeWifi ifconfig rename4 up Même adresse MAC, damned je suis un ane, on change l’adresse MAC ifconfig -a ifconfig rename4 hw ether 9c:b7:0d:72:76:bf ifconfig rename4 up Ça pingue toujours sur l’atre interface iw rename4 connect FreeWifiSur l’autre interface:[quote]64 bytes from 192.168.1.251: icmp_req=253 ttl=64 time=3.99 ms
64 bytes from 192.168.1.251: icmp_req=254 ttl=64 time=1.43 ms
64 bytes from 192.168.1.251: icmp_req=255 ttl=64 time=52.7 ms
64 bytes from 192.168.1.251: icmp_req=256 ttl=64 time=1.30 ms
From 169.254.7.227 icmp_seq=257 Destination Host Unreachable
From 169.254.7.227 icmp_seq=258 Destination Host Unreachable
From 169.254.7.227 icmp_seq=259 Destination Host Unreachable
From 169.254.7.227 icmp_seq=260 Destination Host Unreachable
From 169.254.7.227 icmp_seq=261 Destination Host Unreachable
[/quote]
On reconnecte, ça reprend.

iw rename4 scan Ça scanne, OK

iwconfig rename6 essid FreeWifi
(le changement de numéro est du aux essais multiples…) ou iw rename6 connect FreeWifi
Là comportement curieux et variable:
Une fois j’ai eu l’IP sur rename6 mais wlan0 est tombé en vrac, nécessité de recharger le module, les autres fois ça fige le ping sur la carte wlan0 (ça je n’avais jamais eu). Ainsi à cet instant précis: le ping est de nouveau gelé après une vingtaine de paquets (temps de l’écho pas loin de 100ms pour un temps usuel de 2-3ms max). Le temps d’écrire c’est ligne j’ai eu 4 pings:

64 bytes from 192.168.1.251: icmp_req=667 ttl=64 time=49.9 ms
64 bytes from 192.168.1.251: icmp_req=708 ttl=64 time=11.4 ms
64 bytes from 192.168.1.251: icmp_req=762 ttl=64 time=14.6 ms
64 bytes from 192.168.1.251: icmp_req=767 ttl=64 time=53.7 ms

Il a fallu que je vire le module de la carte et le recharge pour pouvoir reprendre la communication. Apparemment tous les drivers n’ont pas cette capacité, mais ath9k si. Ça signifie que je vais pouvoir faire qque chose de ma carte.

Bon, j’ai appris un truc là, j’en étais resté à iwconfig effectivement.

Après renseignements intenses, il y a plusieurs choses:

  1. Le terme virtuel est effectivement correct, pas bien choisi à mon gout mais bon, c’est par opposition aux interfaces physiques.

  2. Les interfaces virtuelles n’utilisent qu’un seul canal car une seul interface physique. Cela explique sans doute les merdouilles que j’ai eu. Il ne faut donc pas essayer de faire plusieurs canaux, les effets ont l’air curieux.

  3. Le gag de la même adresse MAC est un classique.

  4. L’étape suivante est le support de plusieurs interfaces physiques donc de plusieurs fréquences

Il semble que le support ait été supprimé en 2011:

[quote]6a6767b046e2d336e2af06cb605106ed44a852b6 10-Aug-2011 Mohammed Shafi Shajakhan ath9k: remove obselete comments

the comments are obselete as the virtual wiphy support was removed from
the driver

Signed-off-by: Mohammed Shafi Shajakhan mohammed@qca.qualcomm.com
Signed-off-by: John W. Linville linville@tuxdriver.com[/quote]
mais ça date, donc depuis il faut voir…

si tu as des infos plus récentes que le wiki debian, je suis preneur, car ce iw n’est pas encore très bien documenté sur le web.
Généralement, pour ce type d’info je regarde les doc de BackTrack, mais là je n’ai rien trouvé.
Et je suis comme toi, je n’arrive pas à me défaire du réflexe iwconfig (pourtant iw c’est plus court à taper …)

Je n’ai pas réussi à trouver une seule référence aux «virtuals wiphy» dans les changelog du noyaux (j’ai chargé tous les 3.x puis ai fait du grep). Je crains qu’il n’y ait pas du neuf là dessus, ça doit être encore à coté du noyau…

Je ne pense pas que ce soit dans le noyau. Je vois ça au niveau driver (ceux qui utilisent la nouvelle pile) et de iw.

Quand je dis noyau, je dis driver du noyau. Les fonctionnalités sont souvent sous forme de patch.[quote]The ath9k virtual wiphy stuff was not copied over to ath9k_htc to avoid code complexity during bring up. If the ath9k virtual wiphy stuff is removed from ath9k then even more code sharing is possible however at the moment it remains unclear what the future holds for the ath9k virtual wiphy stuff. [/quote]

si c’est toujours “unclear” pour les devs, ça n’est pas prêt de l’être pour les utilisateurs! :017