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
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.
Ben comme on dit de part chez moi, t'es pas dans la merde...
C'est aussi ce que je me disais ;-)))
M'enfin, c'est pas critique non plus, j'avais posé la question au cas où.
Merci quand même pour le temps passé.
DAPL
Vincent Bernat
OoO En ce début d'après-midi ensoleillé du mardi 06 avril 2004, vers 15:25, Jacques Caron disait:
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.
Pour IP, on peut alors sans doute baisser le MTU des interfaces. -- BOFH excuse #288: Hard drive sleeping. Let it wake up on it's own...
OoO En ce début d'après-midi ensoleillé du mardi 06 avril 2004, vers
15:25, Jacques Caron <jc@imfeurope.com> disait:
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.
Pour IP, on peut alors sans doute baisser le MTU des interfaces.
--
BOFH excuse #288:
Hard drive sleeping. Let it wake up on it's own...
OoO En ce début d'après-midi ensoleillé du mardi 06 avril 2004, vers 15:25, Jacques Caron disait:
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.
Pour IP, on peut alors sans doute baisser le MTU des interfaces. -- BOFH excuse #288: Hard drive sleeping. Let it wake up on it's own...
Jacques Caron
On Thu, 08 Apr 2004 10:43:05 +0200, Vincent Bernat wrote:
OoO En ce début d'après-midi ensoleillé du mardi 06 avril 2004, vers 15:25, Jacques Caron disait:
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.
Pour IP, on peut alors sans doute baisser le MTU des interfaces.
Je ne suis pas sûr de comprendre le rapport avec la choucroute?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Thu, 08 Apr 2004 10:43:05 +0200, Vincent Bernat <vince@khabale.org>
wrote:
OoO En ce début d'après-midi ensoleillé du mardi 06 avril 2004, vers
15:25, Jacques Caron <jc@imfeurope.com> disait:
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.
Pour IP, on peut alors sans doute baisser le MTU des interfaces.
Je ne suis pas sûr de comprendre le rapport avec la choucroute?
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Thu, 08 Apr 2004 10:43:05 +0200, Vincent Bernat wrote:
OoO En ce début d'après-midi ensoleillé du mardi 06 avril 2004, vers 15:25, Jacques Caron disait:
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.
Pour IP, on peut alors sans doute baisser le MTU des interfaces.
Je ne suis pas sûr de comprendre le rapport avec la choucroute?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Cedric Blancher
Le Thu, 08 Apr 2004 11:02:13 +0200, Jacques Caron a écrit :
Pour IP, on peut alors sans doute baisser le MTU des interfaces. Je ne suis pas sûr de comprendre le rapport avec la choucroute?
Le magret de canard.
Désolé, mais j'ai besoin de me détendre... ----> [ ]
-- BOFH excuse #433:
error: one bad user found in front of screen
Le Thu, 08 Apr 2004 11:02:13 +0200, Jacques Caron a écrit :
Pour IP, on peut alors sans doute baisser le MTU des interfaces.
Je ne suis pas sûr de comprendre le rapport avec la choucroute?
Le magret de canard.
Désolé, mais j'ai besoin de me détendre... ----> [ ]
Le Thu, 08 Apr 2004 11:02:13 +0200, Jacques Caron a écrit :
Pour IP, on peut alors sans doute baisser le MTU des interfaces. Je ne suis pas sûr de comprendre le rapport avec la choucroute?
Le magret de canard.
Désolé, mais j'ai besoin de me détendre... ----> [ ]
-- BOFH excuse #433:
error: one bad user found in front of screen
Vincent Bernat
OoO En cette fin de matinée radieuse du jeudi 08 avril 2004, vers 11:02, Jacques Caron disait:
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.
Pour IP, on peut alors sans doute baisser le MTU des interfaces.
Je ne suis pas sûr de comprendre le rapport avec la choucroute?
A priori, si le MTU est assez petit, la taille de la trame en 802.11 rentre dans celle du 802.3. Quand tu disais plus d'informations, tu ne parlais pas de la taille des trames ? -- panic("esp_handle: current_SC == penguin within interrupt!"); 2.2.16 /usr/src/linux/drivers/scsi/esp.c
OoO En cette fin de matinée radieuse du jeudi 08 avril 2004, vers
11:02, Jacques Caron <jc@imfeurope.com> disait:
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.
Pour IP, on peut alors sans doute baisser le MTU des interfaces.
Je ne suis pas sûr de comprendre le rapport avec la choucroute?
A priori, si le MTU est assez petit, la taille de la trame en 802.11
rentre dans celle du 802.3. Quand tu disais plus d'informations, tu ne
parlais pas de la taille des trames ?
--
panic("esp_handle: current_SC == penguin within interrupt!");
2.2.16 /usr/src/linux/drivers/scsi/esp.c
OoO En cette fin de matinée radieuse du jeudi 08 avril 2004, vers 11:02, Jacques Caron disait:
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.
Pour IP, on peut alors sans doute baisser le MTU des interfaces.
Je ne suis pas sûr de comprendre le rapport avec la choucroute?
A priori, si le MTU est assez petit, la taille de la trame en 802.11 rentre dans celle du 802.3. Quand tu disais plus d'informations, tu ne parlais pas de la taille des trames ? -- panic("esp_handle: current_SC == penguin within interrupt!"); 2.2.16 /usr/src/linux/drivers/scsi/esp.c
Jacques Caron
On Fri, 09 Apr 2004 01:55:54 +0200, Vincent Bernat wrote:
A priori, si le MTU est assez petit, la taille de la trame en 802.11 rentre dans celle du 802.3. Quand tu disais plus d'informations, tu ne parlais pas de la taille des trames ?
Les trames 802.11 sont plus longues que les trames 802.3, mais leur taille maximale est aussi plus importante, donc pas de problème pour faire passer une trame avec une MTU standard (1500 octets) en 802.11, quel que soit le cas de figure... Le problème avec ces informations supplémentaires, c'est qu'il faut que le driver ait ces informations à disposition, et qu'il soit capable de les ajouter aux headers. Certains drivers ne prévoient pas ce cas de figure.
Pour être précis, une trame 802.11 contient entre 2 et 4 adresses MAC au lieu de 2 pour une trame 802.3: en plus de la source et de la destination (de bout en bout) de la trame, il y a la station qui l'émet sur les ondes, et la station qui doit la recevoir (pas les mêmes en cas de bridging).
Pas mal de drivers de cartes considèrent que la station dans laquelle elle se trouve sont de bêtes clients, et que forcément dans ce cas la source de la trame et la station qui la met sur les ondes est toujours la même, et ne prévoient donc pas la possibilité d'indiquer deux adresses différentes. Résultat, le bridging ne marche pas dans ce cas.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
On Fri, 09 Apr 2004 01:55:54 +0200, Vincent Bernat <vince@khabale.org>
wrote:
A priori, si le MTU est assez petit, la taille de la trame en 802.11
rentre dans celle du 802.3. Quand tu disais plus d'informations, tu ne
parlais pas de la taille des trames ?
Les trames 802.11 sont plus longues que les trames 802.3, mais leur taille
maximale est aussi plus importante, donc pas de problème pour faire passer
une trame avec une MTU standard (1500 octets) en 802.11, quel que soit le
cas de figure... Le problème avec ces informations supplémentaires, c'est
qu'il faut que le driver ait ces informations à disposition, et qu'il soit
capable de les ajouter aux headers. Certains drivers ne prévoient pas ce
cas de figure.
Pour être précis, une trame 802.11 contient entre 2 et 4 adresses MAC au
lieu de 2 pour une trame 802.3: en plus de la source et de la destination
(de bout en bout) de la trame, il y a la station qui l'émet sur les ondes,
et la station qui doit la recevoir (pas les mêmes en cas de bridging).
Pas mal de drivers de cartes considèrent que la station dans laquelle elle
se trouve sont de bêtes clients, et que forcément dans ce cas la source de
la trame et la station qui la met sur les ondes est toujours la même, et
ne prévoient donc pas la possibilité d'indiquer deux adresses différentes.
Résultat, le bridging ne marche pas dans ce cas.
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
On Fri, 09 Apr 2004 01:55:54 +0200, Vincent Bernat wrote:
A priori, si le MTU est assez petit, la taille de la trame en 802.11 rentre dans celle du 802.3. Quand tu disais plus d'informations, tu ne parlais pas de la taille des trames ?
Les trames 802.11 sont plus longues que les trames 802.3, mais leur taille maximale est aussi plus importante, donc pas de problème pour faire passer une trame avec une MTU standard (1500 octets) en 802.11, quel que soit le cas de figure... Le problème avec ces informations supplémentaires, c'est qu'il faut que le driver ait ces informations à disposition, et qu'il soit capable de les ajouter aux headers. Certains drivers ne prévoient pas ce cas de figure.
Pour être précis, une trame 802.11 contient entre 2 et 4 adresses MAC au lieu de 2 pour une trame 802.3: en plus de la source et de la destination (de bout en bout) de la trame, il y a la station qui l'émet sur les ondes, et la station qui doit la recevoir (pas les mêmes en cas de bridging).
Pas mal de drivers de cartes considèrent que la station dans laquelle elle se trouve sont de bêtes clients, et que forcément dans ce cas la source de la trame et la station qui la met sur les ondes est toujours la même, et ne prévoient donc pas la possibilité d'indiquer deux adresses différentes. Résultat, le bridging ne marche pas dans ce cas.
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
