[Wifi] Bridge avec Linux

Le
DAPL
Bonjour,


Je possède un PDA wifi et une carte wifi usb Netgear branchée sur mon
PC, lui-même étant sur le LAN.
Sous Windows XP, il m'était très facile de connecter le PDA au réseau en
faisant un pont mac entre les deux cartes du PC (selectionner les deux
cartes puis click-droit ==> etablir un pont). Ca fonctionne très bien
(en mode Ad-Hoc) et le PDA se comporte du coup comme n'importe quelle
machine du réseau (dhcp, web, firewall, etc).
Etant désormais très rarement sous Windows, et n'ayant pas d'autre
machine à dispo, je souhaitais retrouver cette fonctionnalité sous Linux
(j'utilise actuellement la Mdk updatée en 10.0).
J'ai donc vérifié que le bridge était activé (il l'est en module avec le
noyau d'origine 2.6.3-4mdk), récupéré les outils wifi (iwconfig) et les
bridge-utils. Ma carte wifi usb (Atmel) est très bien reconnue par Linux.
Lorsque je veux utiliser le wifi, je branche la carte usb, je fais un
modprobe bridge et je lance un script qui contient:
#!/bin/sh

iwconfig wlan0 mode ad-hoc
iwconfig wlan0 essid "pocketdapl"
iwconfig wlan0 channel 10
iwconfig wlan0 enc xxxxxxxxxxxxx
ifconfig wlan0 0.0.0.0
ifconfig eth0 0.0.0.0
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 wlan0
ifconfig br0 192.168.x.x netmask 255.255.255.0 up
echo 0 > /proc/sys/net/ipv4/ip_forward
route add -net 0.0.0.0 gw 192.168.x.x dev br0

Le PC est toujours connecté au réseau, mais le PDA non. Néanmoins, il
récupère bien une adresse DHCP !!
Tout se comporte comme si j'étais filtré au-dessus de la couche mac !!
Le fait de mettre 1 dans /proc/sys/net/ipv4/ip_forward ne change rien,
d'autant qu'il n'y a aucun firewall activé sur le PC.

Où regarder ??
Si quelqu'un reussit à faire fonctionner deux équipements wifi en ad-hoc
avec l'un d'eux comme pont pour accéder à un réseau filaire, je suis
preneur de la solution.



Merci.



DAPL.
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
db
Le #1034210
DAPL wrote:

Bonjour,


Je possède un PDA wifi et une carte wifi usb Netgear branchée sur mon
PC, lui-même étant sur le LAN.
Sous Windows XP, il m'était très facile de connecter le PDA au réseau en
faisant un pont mac entre les deux cartes du PC (selectionner les deux
cartes puis click-droit ==> etablir un pont). Ca fonctionne très bien
(en mode Ad-Hoc) et le PDA se comporte du coup comme n'importe quelle
machine du réseau (dhcp, web, firewall, etc...).
Etant désormais très rarement sous Windows, et n'ayant pas d'autre
machine à dispo, je souhaitais retrouver cette fonctionnalité sous Linux
(j'utilise actuellement la Mdk updatée en 10.0).
J'ai donc vérifié que le bridge était activé (il l'est en module avec le
noyau d'origine 2.6.3-4mdk), récupéré les outils wifi (iwconfig) et les
bridge-utils. Ma carte wifi usb (Atmel) est très bien reconnue par Linux.
Lorsque je veux utiliser le wifi, je branche la carte usb, je fais un
modprobe bridge et je lance un script qui contient:
#!/bin/sh

iwconfig wlan0 mode ad-hoc
iwconfig wlan0 essid "pocketdapl"
iwconfig wlan0 channel 10
iwconfig wlan0 enc xxxxxxxxxxxxx
ifconfig wlan0 0.0.0.0
ifconfig eth0 0.0.0.0
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 wlan0
ifconfig br0 192.168.x.x netmask 255.255.255.0 up
echo 0 > /proc/sys/net/ipv4/ip_forward
route add -net 0.0.0.0 gw 192.168.x.x dev br0


Euh j'espère que ce dernier 192.168.X.x est différent du 192.168.x.x
de la commande ifconfig br0 ?

Le PC est toujours connecté au réseau, mais le PDA non. Néanmoins, il
récupère bien une adresse DHCP !!
Tout se comporte comme si j'étais filtré au-dessus de la couche mac !!
Le fait de mettre 1 dans /proc/sys/net/ipv4/ip_forward ne change rien,
d'autant qu'il n'y a aucun firewall activé sur le PC.

Où regarder ??
Si quelqu'un reussit à faire fonctionner deux équipements wifi en ad-hoc
avec l'un d'eux comme pont pour accéder à un réseau filaire, je suis
preneur de la solution.


Ca fonctionne ici et dans énormément d'ailleurs depuis 2 ans (je sais, ce
n'est pas une preuve).
En mode infra il est vrai mais bon en mode adhoc, mis à part les soucis
d'administration et l'absence de synchro automatique sur un canal cela
dvrait donner les mêmes résulats.

Dans le cadre d'un diagnostic il faudrait commencer par virer le @!$*/ de
chiffrement WEP2 à la mords-moi le noeud (on se demande bien qui a pu
inventer une telle connerie mais passons ce n'est pas le sujet).

A priori ce n'est pas cela étant donné que vous récupérez une adresse IP
mais au moins on y voit plus clair.
Ensuite vérifier que vous êtes bien associé en jetant un oeil dans le pseudo
système /proc (j'ignore ce que vous utilisez comme pilote WiFi, s'il
s'agissait de hostap ce serait dans /proc/net/hostap).
Là encore, a priori, pas de souci côté wlan0 étant donné que vous récupérez
bien une adresse IP mais étant donné que vous ne précisez pas qui est le
serveur DHCP un doute subsiste sur eth0.

Si votre serveur DHCP n'est pas sur une machine du réseau différente du pont
Linux, procédez au test suivant sinon passez à la dernière étape.
Depuis une machine du réseau faites un ping sur votre PDA et
vérifier l'adresse MAC de ce dernier figure dans le cache ARP de ladite
machine.
Si ce n'est pas le cas votre pilote ne transmet pas correctement les
trames d'une interface à l'autre. Il faudra en passer par du routage
et un relais DHCP si votre serveur DHCP n'est pas sur le linux.

Dernière étape : la trace.
A l'aide d'un tcpdump vérifiez la bonne transmission côté wlan0 puis si
c'est ok vérifier la même chose côté eth0.

Si un paquet émanant du PDA se retrouve bien côté eth0 mais n'obtient jamais
de réponse (alors que la machine ciblée fonctionne bien) il y a un pb de
pilote.

db

Jacques Caron
Le #1034205
On Tue, 06 Apr 2004 14:28:22 +0200, DAPL
Le PC est toujours connecté au réseau, mais le PDA non. Néanmoins, il
récupère bien une adresse DHCP !!


Où est le serveur DHCP? Sur le PC qui fait pont, ou sur une autre machine
du LAN?

Tout se comporte comme si j'étais filtré au-dessus de la couche mac !!


Ca fait tout de suite penser à un problème de firewall, mais tu dis plus
loin que ce n'est pas le cas. Que dit un petit tcpdump ou ethereal quand
le PDA essaie de "parler"? Que donne un ping du PDA vers le PC, et
vice-versa? Que donne un ping du PDA vers une autre machine du réseau, et
vice-versa? Que donne la table ARP sur la PDA?

Le fait de mettre 1 dans /proc/sys/net/ipv4/ip_forward ne change rien,


Ca ne me paraît pas utile, tu fais du bridging et pas du routage...

Si quelqu'un reussit à faire fonctionner deux équipements wifi en ad-hoc
avec l'un d'eux comme pont pour accéder à un réseau filaire, je suis
preneur de la solution.


Wi-Fi et bridging ne font pas toujours bon ménage, parce que le format des
trames 802.11 exige plus d'informations qu'en 802.3, et tous les drivers
ne supportent pas tous les cas de figure, parce qu'ils sont "prévus" pour
jouer le rôle de client et pas celui d'AP (bridge entre filaire et
sans-fil). Il faudrait lire en détail la man page et/ou le source du
driver en question pour voir si ce cas de figure est prévu ou pas.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

DAPL
Le #1034034
Bonjour,

Où est le serveur DHCP? Sur le PC qui fait pont, ou sur une autre
machine du LAN?



Le serveur DHCP se trouve sur le LAN


Ca fait tout de suite penser à un problème de firewall, mais tu dis plus
loin que ce n'est pas le cas. Que dit un petit tcpdump ou ethereal quand
le PDA essaie de "parler"? Que donne un ping du PDA vers le PC, et
vice-versa? Que donne un ping du PDA vers une autre machine du réseau,
et vice-versa? Que donne la table ARP sur la PDA?


Le firewall du PC n'est pas activé, c'est sûr.
Un ping du PDA vers le PC n'abouti pas, et vers une machine du LAN
encore moins. Je n'ai pas accès à la table ARP du PDA.
Au niveau des traces réseaux, on voit bien le PDA causer sur la patte
wifi du PC, mais celui-ci renvoie de trames ARP demandant qui possède
l'adresse IP correspondant à celle utilisée par le PDA. Il ne réussit
donc pas à lui répondre.

Wi-Fi et bridging ne font pas toujours bon ménage, parce que le format
des trames 802.11 exige plus d'informations qu'en 802.3, et tous les
drivers ne supportent pas tous les cas de figure, parce qu'ils sont
"prévus" pour jouer le rôle de client et pas celui d'AP (bridge entre
filaire et sans-fil). Il faudrait lire en détail la man page et/ou le
source du driver en question pour voir si ce cas de figure est prévu ou
pas.

Jacques.


Merci de ces infos, je vais regarder de ce côté.

En attendant, j'ai résolu le souci en utilisant une machine XP en libre
service à proximité de mon bureau !!.....


DAPL

Jacques Caron
Le #1033851
On Tue, 06 Apr 2004 17:29:03 +0200, DAPL
Au niveau des traces réseaux, on voit bien le PDA causer sur la patte
wifi du PC, mais celui-ci renvoie de trames ARP demandant qui possède
l'adresse IP correspondant à celle utilisée par le PDA. Il ne réussit
donc pas à lui répondre.


Mmmm... C'est bizarre cette histoire... Normalement il devrait apprendre
automatiquement la correspondance MAC-IP à la réception d'un paquet du
PDA. D'ailleurs celui-ci devrait avoir fait une requête ARP avant de
pouvoir pinguer, il y arrive (et reçoit une réponse)?

On dirait un peu que le PC reçoit bien au niveau 2, mais qu'il y a un
problème pour passer au niveau 3...

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Cedric Blancher
Le #1033850
Le Tue, 06 Apr 2004 15:25:17 +0200, Jacques Caron a écrit :
Wi-Fi et bridging ne font pas toujours bon ménage, parce que le format des
trames 802.11 exige plus d'informations qu'en 802.3, et tous les drivers
ne supportent pas tous les cas de figure, parce qu'ils sont "prévus" pour
jouer le rôle de client et pas celui d'AP (bridge entre filaire et
sans-fil). Il faudrait lire en détail la man page et/ou le source du
driver en question pour voir si ce cas de figure est prévu ou pas.


J'ai testé le mode AP bridgé avec les drivers hostap[1] et prism54[2],
et ça ne posait pas de problème.


[1] http://hostap.epitest.fi/
[2] http://prism54.org/

--
BOFH excuse #263:

It's stuck in the Web.

Jacques Caron
Le #1033849
On Tue, 06 Apr 2004 20:39:26 +0200, Cedric Blancher

J'ai testé le mode AP bridgé avec les drivers hostap[1] et prism54[2],
et ça ne posait pas de problème.


Et le mode ad-hoc bridgé? :-)

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

DAPL
Le #1530000
On dirait un peu que le PC reçoit bien au niveau 2, mais qu'il y a un
problème pour passer au niveau 3...


C'est exactement cela, car DHCP, ARP ok mais les trames IP ne passent pas.


DAPL

Cedric Blancher
Le #1529996
Le Wed, 07 Apr 2004 09:38:16 +0200, DAPL a écrit :
C'est exactement cela, car DHCP, ARP ok mais les trames IP ne passent pas.


Tu es _vraiment_ sûr que tu n'as pas de firewalling en place au niveau du
bridge en FORWARD ? Parce que le 2.6 inclue le support bridge/firewall,
donc les règles de FORWARD s'appliquent aussi au trafic commuté.

--
(...) mais le niveau des eaux a été l'oeuvre de grandes vallée dut aux
glissements de terrains etc. ainsi les montagnes ont été élevées par
l'abaissement du terrain dut aux masses d'eau etc.
-+- binji in http://neuneu.mine.nu : Et Dieu créa le neuneu.

DAPL
Le #1529993
Tu es _vraiment_ sûr que tu n'as pas de firewalling en place au niveau du
bridge en FORWARD ? Parce que le 2.6 inclue le support bridge/firewall,
donc les règles de FORWARD s'appliquent aussi au trafic commuté.



Oui, j'en suis sûr.
iptables -L -n renvoie:
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Et Shorewall n'est pas installé.

D'ailleurs, j'avais exactement le même comportement avec une autre
machine, également sous Mdk, mais 9.1 (noyau 2.4), sans firewall
non-plus d'ailleurs.

Je me demande si la piste du driver n'est pas la bonne, mais il n'y a
pas d'autre driver pour les cartes à base de chipset Atmel.

DAPL

Cedric Blancher
Le #1034946
Le Wed, 07 Apr 2004 11:17:15 +0200, DAPL a écrit :
Je me demande si la piste du driver n'est pas la bonne, mais il n'y a
pas d'autre driver pour les cartes à base de chipset Atmel.


Effectivement, ça parait probable. Rien dans les logs kernel ?

--
It looks as if noone with a 64 bit machine has gotten bitten by this yet
Well, in order to get bitten by this you have to have a 2-terabyte IDE

disk, so we don't have to worry about it for another few months..
-+- Linus in Guide du linuxien pervers - J'ai déjà entendu ça quelque part"

Publicité
Poster une réponse
Anonyme