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.
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
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
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
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.
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
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
On Tue, 06 Apr 2004 14:28:22 +0200, DAPL wrote:
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/
On Tue, 06 Apr 2004 14:28:22 +0200, DAPL <pasdespam@free.fr> wrote:
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/
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
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
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 !!.....
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
On Tue, 06 Apr 2004 17:29:03 +0200, DAPL wrote:
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/
On Tue, 06 Apr 2004 17:29:03 +0200, DAPL <pasdespam@free.fr> wrote:
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/
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 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.
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.
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.
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 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.
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.
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
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é.
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
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é.
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.
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é.
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 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"
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"
