Bridge ethernet/wifi

Le Wed, 08 Sep 2004 03:44:56 +0200 après l'an de grâce, inspiré(e)
"[ATR]Dj-Death" <djdeath@gmx.fr> écrivait la plume légère :

J'ai exactement la même configuration que celle de l'article, à une
exception près, l'une de mes interfaces n'est pas une carte ethernet,
mais une carte wifi. Je me demande d'ailleur si c'est là mon problème.
J'essaie de faire la même chose que toi et j'ai aussi des difficultés

(peut être différentes)

J'utilise wlan-ng (car j'ai une clef usb comme carte wifi)
Voilà ce que j'obtiens :
Aug 18 17:07:10 osmonda kernel: br0: port 2(eth0) entering learning
state
Aug 18 17:07:10 osmonda kernel: br0: port 1(wlan0) entering
learning state
Aug 18 17:07:20 osmonda kernel: br0: no IPv6 routers
present
Aug 18 17:07:21 osmonda kernel: eth0: no IPv6 routers present
Aug 18 17:07:25 osmonda kernel: br0: topology change detected,
propgating
Aug 18 17:07:25 osmonda kernel: br0: port 2(eth0) entering
forwarding state
Aug 18 17:07:25 osmonda kernel: br0: topology change detected,
propgating
Aug 18 17:07:25 osmonda kernel: br0: port 1(wlan0) entering
forwarding state
Aug 18 17:07:34 osmonda kernel: wlan0: received packet with own address
as sour ce address
Aug 18 17:07:36 osmonda kernel: wlan0: received packet with own address
as source address

là je vois bien que ma carte wifi a un premier problème (elle n'arrive
pas à forwarder les paquets dont elle s'amgine être l'émetteur je
suppose)


Aug 18 17:19:23 osmonda kernel: wlan0: received packet with own address
as sour ce address
Aug 18 17:19:28 osmonda kernel: wlan0: received packet with own address
as sour ce address
Aug 18 17:19:28 osmonda kernel: skb_p80211_to_ether: OTHER frame too
large (1508 > 1500)
Aug 18 17:19:28 osmonda kernel: skb_p80211_to_ether: SNAP frame too
large (1508

1500)
Aug 18 17:19:29 osmonda kernel: skb_p80211_to_ether: OTHER frame too

large (1508 > 1500)
Aug 18 17:19:38 osmonda last message repeated 4 times
Aug 18 17:19:43 osmonda kernel: wlan0: received packet with own address
as sour ce address
Aug 18 17:19:50 osmonda kernel: skb_p80211_to_ether: SNAP frame too
large (1508

1500)
Aug 18 17:19:50 osmonda kernel: skb_p80211_to_ether: OTHER frame too

large (1508 > 1500)

Je soupçonne dans mon cas un problème de MTU en plus.

As tu des messages similaires dans /var/log/syslog
(je suis aussi sous debian) ?

--
There are few virtues that the Poles do not possess -- and there are few
mistakes they have ever avoided.
-- Winston Churchill, Parliament, August, 1945

k a écrit :

Le Wed, 08 Sep 2004 03:44:56 +0200 après l'an de grâce, inspiré(e)
"[ATR]Dj-Death" <djdeath@gmx.fr> écrivait la plume légère :

J'ai exactement la même configuration que celle de l'article, à une
exception près, l'une de mes interfaces n'est pas une carte ethernet,
mais une carte wifi. Je me demande d'ailleur si c'est là mon problème.

Concernant le DHCP et le wifi, il n'y a aucun problème de principe.

J'essaie de faire la même chose que toi et j'ai aussi des difficultés
(peut être différentes)

J'utilise wlan-ng (car j'ai une clef usb comme carte wifi)
Voilà ce que j'obtiens :

[...snip log...]

là je vois bien que ma carte wifi a un premier problème (elle n'arrive
pas à forwarder les paquets dont elle s'amgine être l'émetteur je
suppose)

Voir après...

Aug 18 17:19:23 osmonda kernel: wlan0: received packet with own address
as sour ce address
Aug 18 17:19:28 osmonda kernel: wlan0: received packet with own address
as sour ce address
Aug 18 17:19:28 osmonda kernel: skb_p80211_to_ether: OTHER frame too
large (1508 > 1500)
Aug 18 17:19:28 osmonda kernel: skb_p80211_to_ether: SNAP frame too
large (1508 > 1500)

Je soupçonne dans mon cas un problème de MTU en plus.

En fait les deux problèmes sont liés. C'est un problème de MTU et de
longueur de trame MAC. Pour ethernet le MTU est de 1500 octets et pour le wifi
c'est 2312 octets... il est donc possible que une trame soit trop grande
de plus l'entête 802.11 (wifi) est aussi plus longue (28 octets) que
celle de ethernet (18 octets). Il y a alors deux problèmes possibles :
- soit les données sont trop courtes
- soit les informations de l'entête sont coupées.

Le premier cas est assez problématique car il ne peut être facilement
détecter avec des protocoles de niveau 3 (le PMTU sur IP est pas trop
fonctionnel pour un bridge). La solution est de descendre le MTU du wifi
au plus à 1500 (pour l'aligner à celui d'ethernet).

Le deuxième cas est beaucoup plus subtile... en fit en wifi on indique
non seulement la destination et source réelles mais les point de passage
wifi. C'est au pilote de savoir si savoir différencier les paquets émis
par un hôte externe vers le point d'accès ou vers des hôtes derrières le
point d'accès, c'est le mode ESS. Normalement, c'est fait par les
drivers linux si on précise le bon paramètre de configuration :

APBRIDGEDEVICE=eth0

et ne pas faire de bridging avec brctl... (sauf si on veut bridger plus
d'une interface ethernet)

En jouant sur les deux pararamètres (MTU et conf) doit marcher, mais il
se peut qu'un seul des deux pose un problème.

As tu des messages similaires dans /var/log/syslog
(je suis aussi sous debian) ?

--
Julien

On Wed, 08 Sep 2004 11:47:54 +0200, k wrote:

As tu des messages similaires dans /var/log/syslog
(je suis aussi sous debian) ?

Non, aucun message d'erreur dans /var/log/syslog

On Wed, 08 Sep 2004 15:39:29 +0000, Julien Salgado wrote:

En fait les deux problèmes sont liés. C'est un problème de MTU et de
longueur de trame MAC. Pour ethernet le MTU est de 1500 octets et pour le wifi
c'est 2312 octets... il est donc possible que une trame soit trop grande
de plus l'entête 802.11 (wifi) est aussi plus longue (28 octets) que
celle de ethernet (18 octets). Il y a alors deux problèmes possibles :
- soit les données sont trop courtes
- soit les informations de l'entête sont coupées.

Le premier cas est assez problématique car il ne peut être facilement
détecter avec des protocoles de niveau 3 (le PMTU sur IP est pas trop
fonctionnel pour un bridge). La solution est de descendre le MTU du wifi
au plus à 1500 (pour l'aligner à celui d'ethernet).

Le deuxième cas est beaucoup plus subtile... en fit en wifi on indique
non seulement la destination et source réelles mais les point de passage
wifi. C'est au pilote de savoir si savoir différencier les paquets émis
par un hôte externe vers le point d'accès ou vers des hôtes derrières le
point d'accès, c'est le mode ESS. Normalement, c'est fait par les
drivers linux si on précise le bon paramètre de configuration :

APBRIDGEDEVICE=eth0

et ne pas faire de bridging avec brctl... (sauf si on veut bridger plus
d'une interface ethernet)

En jouant sur les deux pararamètres (MTU et conf) doit marcher, mais il
se peut qu'un seul des deux pose un problème.

As tu des messages similaires dans /var/log/syslog
(je suis aussi sous debian) ?

Merci beaucoup d'avoir répondu. Tu as bien éclairé ma lanterne.
J'ai vérifier le mtu de mes cartes wifi, et les interfaces fonctionnent
toutes avec un mtu de 1500, tout comme mes cartes ethernet. (Je suppose
qu'il s'agit d'une configuration par défaut pour permettre ce genre de
config.)

En ce qui concerne le 2ème point, j'utilise mes cartes en mode Ad-Hoc. En
fait la plupart du temps seule 2 machines fonctionnent avec une carte
wifi. Il s'agit de deux machines assez éloignées que je peux
difficilement relier avec un cable (murs, etc...). Peut être le problème
vient il de là.

Le Thu, 09 Sep 2004 04:05:51 +0200 après l'an de grâce, inspiré(e)
"[ATR]Dj-Death" <djdeath@gmx.fr> écrivait la plume légère :

On Wed, 08 Sep 2004 11:47:54 +0200, k wrote:

As tu des messages similaires dans /var/log/syslog
(je suis aussi sous debian) ?

Non, aucun message d'erreur dans /var/log/syslog
et dans /var/log/messages ?

--
<Electro> my computer was once one of the building blocks of a great
pyramid

Le Thu, 09 Sep 2004 04:11:50 +0200 après l'an de grâce, inspiré(e)
"[ATR]Dj-Death" <djdeath@gmx.fr> écrivait la plume légère :

On Wed, 08 Sep 2004 15:39:29 +0000, Julien Salgado wrote:

En fait les deux problèmes sont liés. C'est un problème de MTU et de
longueur de trame MAC. Pour ethernet le MTU est de 1500 octets et
pour le wifi c'est 2312 octets... il est donc possible que une trame
soit trop grande de plus l'entête 802.11 (wifi) est aussi plus
longue (28 octets) que celle de ethernet (18 octets). Il y a alors
deux problèmes possibles :- soit les données sont trop courtes
- soit les informations de l'entête sont coupées.

Le premier cas est assez problématique car il ne peut être
facilement détecter avec des protocoles de niveau 3 (le PMTU sur IP
est pas trop fonctionnel pour un bridge). La solution est de
descendre le MTU du wifi au plus à 1500 (pour l'aligner à celui
d'ethernet).
Réglé les interfaces étaient à 1500 donc j'ai passé l'AP à 1450

(pour l'overhead + une marge d'erreur ;)

Mais j'ai toujours les mêmes problèmes.

Le deuxième cas est beaucoup plus subtile... en fit en wifi on
indique non seulement la destination et source réelles mais les
point de passage wifi. C'est au pilote de savoir si savoir
différencier les paquets émis par un hôte externe vers le point
d'accès ou vers des hôtes derrières le point d'accès, c'est le mode
ESS. Normalement, c'est fait par les drivers linux si on précise le
bon paramètre de configuration :

APBRIDGEDEVICE=eth0
Je ne suis pas un AP. Je suppose qu'un AP derrière un AP pose de nouveau

problème (comment construire des switchs wifi ? )

Je pense que mon problème vient du fait que j'utilise un driver hors
kernel (linux wlan ng) qui gère mal les adresses mac (et qui de toute
façon est pourri, j'ai pas pu faire marcher une carte wifi PCI sur ma
dec alpha :( )

je pensais peut être ruser en faisant un sous réseau en 10/24 sur le
tronçon derrière la carte ethernet (tronçon local) et en
faisant de l'ipforwarding avec iptables via la carte wifi vers 10/16
et là la GW elle même reforward vers le grand ternet (en fait il y a un
deuxième FW dans la réalité).

C'est peut être pas élégant (rajout de règle spéciale pour les adresses
de broadcast) mais ça risque de marcher.

En tout cas je voulais faire joujou avec le bridging ethernet je
suis un peu déçu :-(

--
Life is like an egg stain on your chin -- you can lick it, but it still
won't go away.

k a écrit :

APBRIDGEDEVICE=eth0
Je ne suis pas un AP. Je suppose qu'un AP derrière un AP pose de nouveau

problème (comment construire des switchs wifi ? )

Il y a tout ce qui faut dans les partie MAC des trames (surtout les
options) pour gérer (en théorie) de la commutation en série pour le wifi
(je ne l'ai pas testé). C'est domage... car ça marche.

Je pense que mon problème vient du fait que j'utilise un driver hors
kernel (linux wlan ng) qui gère mal les adresses mac (et qui de toute
façon est pourri, j'ai pas pu faire marcher une carte wifi PCI sur ma
dec alpha :( )

C'est sur que ça doit être le pilote, un alpha n'est pas pourri ;)
Mais je pencherai au hasard sur un problème d'endianess lors de la
construction des trammes MAC...

je pensais peut être ruser en faisant un sous réseau en 10/24 sur le
tronçon derrière la carte ethernet (tronçon local) et en
faisant de l'ipforwarding avec iptables via la carte wifi vers 10/16
et là la GW elle même reforward vers le grand ternet (en fait il y a un
deuxième FW dans la réalité).

L'autre solution c'est de faire du proxy arp. J'avais une doc pour en
faire avec du wifi.

C'est peut être pas élégant (rajout de règle spéciale pour les adresses
de broadcast) mais ça risque de marcher.

Par contre pour le broadcast il faut faire attention car il n'est pas
routé (pour éviter les boucles, c'est un problème classique de routage
en multicast), le plus simple étant de mettre en place un relais DHCP
vers le serveur existant ou de mettre le serveur DHCP sur cette machine.

En tout cas je voulais faire joujou avec le bridging ethernet je
suis un peu déçu :-(

Le bridging ethernet pur marche très bien, on peut en plus le combiner
avec ebtables pour faire un switch filtrant...

--
Julien

Je pense que mon problème vient du fait que j'utilise un driver hors
kernel (linux wlan ng) qui gère mal les adresses mac (et qui de toute
façon est pourri, j'ai pas pu faire marcher une carte wifi PCI sur ma
dec alpha :( )
ndiswrapper utilise les driver wintel ... c'est tres peu portable sur une

autre archiecture ... C'est meme la limite de ce genre de solutions :elles
sont tres peu portables, alors que si le driver etait opensource, on
trouverait bien quelqu'un pour s'y mettre

Par exemple, je crois que les carte pci wifi a base de chipset prism2 sont
les mieux supportes, probablement aussi dans le monde hors Intel

// The driver should be portable to different host CPUs. I have tested it on
// ix86 and PowerPC platforms. In addition, I have received reports of it
// working on Alpha and Arm.

j'utilise une carte pci dans laquel on enfiche une carte wifi prism2 ...
dans mon cas il s'agit d'une netgear prism2-compatible avec un port pcmcia
et un chipset dedié dans laquelle est enfiche une conceptronic, le tout
reconnu comme :

scanpci
pci bus 0x0000 cardnum 0x0a function 0x00: vendor 0x1638 device 0x1100
Standard Microsystems Corp [SMC] SMC2602W EZConnect / Addtron AWA-100

( ce qui est marrant car j'ai eu un addtron awa100 et la carte wifi qui
etait dedans est au format PCMCIA II alors que l'adaptateur netgear est de
type I)

modules :
orinoco_plx 0
orinoco 1 orinoco_plx
hermes 2 orinoco_plx,orinoco


dmesg | grep eth3
eth3: Station identity 001f:0003:0000:0008
eth3: Looks like an Intersil firmware version 0.8.3
eth3: Ad-hoc demo mode supported
eth3: IEEE standard IBSS ad-hoc mode supported
eth3: WEP supported, 104-bit key
eth3: MAC address 00:50:C2:01:94:46
eth3: Station name "Prism I"
eth3: ready


iwconfig eth3
eth3 IEEE 802.11-DS ESSID:"charly_ad_hoc" Nickname:"Prism I"
Mode:Ad-Hoc Frequency:2.422GHz Cell: 00:00:00:00:00:00
Bit Rate:11Mb/s Tx-Power dBm Sensitivity:1/3
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:7061-7373-776F-7264-0000-0000-00
Security mode:open
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0


ifconfig eth3
eth3 Lien encap:Ethernet HWaddr 00:50:C2:01:94:46
BROADCAST MULTICAST MTU:1500 Metric:1
...



de toute facon le mode ad-hoc ne convient pas a l'ip_forward ou au
bridging ... il ta faut monter un poste en Host-AP.