IPV4/IPV6 cohabitation?

Support Debian
#21

Hum, le problème a l’air d’être au niveau du pont hercule. Je viens de vérifier avec une deuxième machine en WIFI et, outre les mêmes phénomènes, je constate que visiblement le requêtes arp passent de portos à hercule, les réponses de hercule à portos, mais le requêtes arp ne passent pas de hercule à portos.

Tu aboutis à ces tables arp:

Cerbere:

ddress HWtype HWaddress Flags Mask Iface alfortville-5-82-66-248 ether 00:07:cb:48:38:55 C eth1 192.168.1.238 ether 9c:b7:0d:72:76:be C br0 192.168.1.236 ether e8:40:f2:37:1b:20 C br0 192.168.1.65 (incomplete) br0 192.168.1.148 ether 70:1a:04:51:23:f8 C br0 hercule.rebelles ether 00:01:c0:07:6d:62 C br0
hercule

hercule:/home/francois# arp Address HWtype HWaddress Flags Mask Iface 192.168.1.148 ether 70:1a:04:51:23:f8 C br0 192.168.1.238 ether 9c:b7:0d:72:76:be C br0 cerbere.rebelles ether 00:01:c0:04:11:f6 C br0
portos

oot@portos:/home/francois# arp Address HWtype HWaddress Flags Mask Iface 192.168.1.148 (incomplete) wlan0 cerbere.rebelles ether 00:01:c0:04:11:f6 C wlan0 192.168.1.138 (incomplete) wlan0 hercule.rebelles ether 00:01:c0:07:6d:62 C wlan0

Portos=138, l’autre machine=148. Le problème est donc plus lié au pont et n’a sans doute pas gd chose à voir avec l’IPV6. La carte est une Ralink avec comme module rt2800usb… Elle a longtemps été chancelante…

Virer le pont est enquiquinant, cette carte est minable et n’a que cette possibilité comme intérêt, l’autre point d’accès est un (vieux) Fonera plus performant mais non ponté (ce qui est normal) et sans IPV6. Note que je peux peut être rentrer dessus et modifier la programmation de la carte. Je vais voir si ça se fait…

#22

C’est juste pour tester si wlan0, toujours en mode point d’accès, fonctionne normalement lorsqu’elle n’est pas pontée. Parce que c’est quand même étonnant qu’elle ne puisse pas émettre de paquets en multicast ou broadcast, et je me demande si le pontage n’y est pas pour quelque chose. Je pense notamment au fait que le pontage conduit wlan0 à émettre des paquets avec une adresse MAC source différente de sa propre adresse MAC, ce que certaines interfaces wifi n’aiment pas trop. Si tel est le cas (mais cela n’expliquerait pas que seuls les paquets broadcast et multicast sont affectés), alors un contournement pourrait consister à remplacr l’adresse MAC source de ces paquets par l’adresse MAC de l’interface avec une règle ebtables.

#23

Je vais voir ça. Si c’est le cas, tupenses à une règle genre

-t nat -A POSTROUTING -o wlan0 -d 01:00:00:00:00:00/01:00:00:00:00:00 -j snat --to-src MAC_wlan0_herculepour le multicast et également pour le broadcast qui serait ff:ff:ff:ff:ff:ff/ff:ff:ff:ff:ff:ff qui est dans la plage.

Si je comprends bien Mac_entree «matche» A/B ssi (B & Mac_entree) = A

(& = & bit à bit) C’est une déduction, je n’ai vu ça nulle part…

#24

Oui, quelque chose dans le genre. Tu peux même utiliser le raccourci “Multicast” à la place de 01:00:00:00:00:00/01:00:00:00:00:00.
Inutile d’ajouter des règles spéciales pour les adresses MAC multicast IPv6 et broadcast qui ne sont jamais que des cas particuliers d’adresses multicast (dans tous les cas, le bit multicast=1).

#25

Oui, c’est le principe d’un masque, identique au masque de sous-réseau ou de préfixe commun en IPv4 et IPv6. Il y a une variation possible qui consiste à appliquer aussi le masque B à A, ou à s’assurer que A&B==A, sinon la correspondance ne pourrait jamais être positive.

Ma formule préférée, c’est (X^A)&B==0 (avec ^ = OU exclusif/XOR bit à bit).
Le XOR calcule les bits qui diffèrent entre X et A, et le AND élimine les bits qui sont en dehors du masque B. Si le résultat a tous les bits à 0, alors il y a correspondance.

#26

Oui, j’avais compris pour multicast/broadcast mais je n’étais pas sûr de la signification de A/B. Je n’ai vu que le man d’ebtables et la liste des adresses multicast connues, même si lça semblait logique.

Bon, c’est un échec notoire même si on détache wlan0 du pont. Les paquets ne passent pas que wlan0 soit dans le pont ou pas et qu’il y ait la règle ou non.
Il faudrait que j’essaye avec un autre noyau…

#27

J’ai quand même peine à croire que l’adaptateur wifi, le pilote ou le firmware soit moisi au point de ne pas être capable d’émettre de paquets en broadcast ou multicast, sans que ça se soit vu (n’importe quelle requête ARP ou DHCP est émise en broadcast). Ou alors c’est un bug spécifique au fonctionnement en mode point d’accès.

#28

Je pense que c’est ce dernier point. Voilà en gros les commandes faites sur hercule

rctl delif br0 wlan0 ifconfig wlan0 inet6 add 2a01:a:b:c:d:e:fe04:10/64 tcpdump -i wlan0 2>&1 | tee /tmp/tracewlan0 ndisc6 -r 100 2a01:a:b:c:d:e:fe04:13 wlan0 rdisc6 -r 100 wlan0 brctl addif br0 wlan0 brctl show apt-get install ebtables ebtables -t nat -A POSTROUTING -o wlan0 -d 01:00:00:00:00:00/01:00:00:00:00:00 -j snat --to-src 00:0d:f0:63:0d:5a tcpdump -i wlan0 arp tcpdump -i br0 arp ebtables -t nat -D POSTROUTING -o wlan0 -d 01:00:00:00:00:00/01:00:00:00:00:00 -j snat --to-src 00:0d:f0:63:0d:5a sleep 10 ; kill $(cat /var/run/hostapd.pid) ; ifdown br0 ;ifup br0 ebtables -t nat -A POSTROUTING -o wlan0 -d 01:00:00:00:00:00/01:00:00:00:00:00 -j snat --to-src 00:0d:f0:63:0d:5a ebtables -t nat -D POSTROUTING -o wlan0 -d 01:00:00:00:00:00/01:00:00:00:00:00 -j snat --to-src 00:0d:f0:63:0d:5a brctl delif br0 wlan0 ifconfig wlan0 inet6 add 2a01:a:b:c:d:e:fe04:10/64 ifconfig wlan0 192.168.0.1 ndisc6 -r 100 2a01:a:b:c:d:e:fe04:13 wlan0 rdisc6 -r 100 wlan0 rdisc6 -r 100 br0 ifconfig kill $(cat /var/run/hostapd.pid) rmmod rt2800usb modprobe rt2800usb apwifi brctl addif br0 wlan0 brctl show ifconfig route -n
J’ai mis longtemps à faire fonctionner le point d’accès. La carte ne fonctionne comme point d’accès que depuis le noyau 3.5.4. Elle ne nécessite pas de firmware. C’est une

148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter vue comme une carte USB.

#29

Pourtant il existe un firmware rt2870.bin pour RT2870/RT3070, disponible dans le paquet firmware-ralink (non-free).

#30

Exact, il y est francois@hercule:~$ locate rt2870.bin /lib/firmware/rt2870.bin /var/lib/firmware/rt2870.bin francois@hercule:~$ mais son chargement est silencieux ou il n’est pas utilisé:

francois@hercule:/var/log$ dmesg |grep irmw [ 0.080785] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 0.281537] [Firmware Bug]: ACPI: No _BQC method, cannot determine initial brightness [ 6.061287] af9013: firmware version 4.95.0.0 [4564839.275248] dvb-usb: found a 'AVerMedia AVerTV DVB-T Volar X' in cold state, will try to load a firmware [4564839.349317] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [4564839.418606] af9013: firmware version 4.95.0.0 [17500407.916082] dvb-usb: found a 'AVerMedia AVerTV DVB-T Volar X' in cold state, will try to load a firmware [17500408.041680] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [17500408.112166] af9013: firmware version 4.95.0.0 francois@hercule:/var/log$ francois@hercule:/var/log$ dmesg |grep rt28 [ 7.001188] Registered led device: rt2800usb-phy0::radio [ 7.001266] Registered led device: rt2800usb-phy0::assoc [ 7.001348] Registered led device: rt2800usb-phy0::quality [ 7.001433] usbcore: registered new interface driver rt2800usb [23530487.684968] usbcore: deregistering interface driver rt2800usb [23530493.951205] Registered led device: rt2800usb-phy1::radio [23530493.951372] Registered led device: rt2800usb-phy1::assoc [23530493.951538] Registered led device: rt2800usb-phy1::quality [23530493.954402] usbcore: registered new interface driver rt2800usb [23530548.588472] usbcore: deregistering interface driver rt2800usb [23530551.615026] Registered led device: rt2800usb-phy2::radio [23530551.615222] Registered led device: rt2800usb-phy2::assoc [23530551.615409] Registered led device: rt2800usb-phy2::quality [23530551.615742] usbcore: registered new interface driver rt2800usb francois@hercule:/var/log$ Le firmware est peut être pour la version PCI

#31

Je ne pense pas car son nom est contenu dans les sources du module rt2800usb, et il est listé par modinfo

Comme tu dis le chargement de ce firmware est peut-être silencieux. J’ai le cas avec le firmware du module tg3. Un moyen de vérifier consiste à renommer le firmware, recharger le module et regarder si cela provoque une erreur dans les logs du noyau.

PS : J’ai testé rapidement un adaptateur wifi Prism54 USB en mode AP avec hostapd, les broadcast (ARP) et multicast IPv6 (link local) passent bien dans les deux sens. Il faut encore que je teste en bridge et en ajoutant du chiffrement.

#32

Humhercule:/var/lib/firmware# dmesg | tail [23644127.904897] Registered led device: rt2800usb-phy3::assoc [23644127.905056] Registered led device: rt2800usb-phy3::quality [23644127.905396] usbcore: registered new interface driver rt2800usb [23644181.727807] usbcore: deregistering interface driver rt2800usb [23644211.708099] usb 1-7: reset high-speed USB device number 3 using ehci_hcd [23644211.866550] ieee80211 phy4: Selected rate control algorithm 'minstrel_ht' [23644211.870471] Registered led device: rt2800usb-phy4::radio [23644211.870648] Registered led device: rt2800usb-phy4::assoc [23644211.870819] Registered led device: rt2800usb-phy4::quality [23644211.871140] usbcore: registered new interface driver rt2800usb hercule:/var/lib/firmware# ls /lib/rt* ls: impossible d'acc�der � /lib/rt*: Aucun fichier ou dossier de ce type hercule:/var/lib/firmware# ls /var/lib/firmware/rt* ls: impossible d'acc�der � /var/lib/firmware/rt*: Aucun fichier ou dossier de ce type hercule:/var/lib/firmware# ls /lib/firmware/rt* ls: impossible d'acc�der � /lib/firmware/rt*: Aucun fichier ou dossier de ce type hercule:/var/lib/firmware# hercule:/var/lib/firmware# find /lib -name rt*bin /lib/firmware/RTL8192SU/rtl8192sfw.bin hercule:/var/lib/firmware# hercule:/var/lib/firmware# rmmod rt2800usb rt2800lib rt2x00usb rt2x00lib hercule:/var/lib/firmware# lsmod | grep rt parport 27018 1 lp hercule:/var/lib/firmware# modprobe rt2800usb hercule:/var/lib/firmware# lsmod | grep rt rt2800usb 17531 0 rt2800lib 43043 1 rt2800usb rt2x00usb 13344 1 rt2800usb rt2x00lib 29060 3 rt2800usb,rt2800lib,rt2x00usb parport 27018 1 lp crc_ccitt 12331 1 rt2800lib mac80211 280021 3 rt2800lib,rt2x00usb,rt2x00lib cfg80211 117885 2 rt2x00lib,mac80211 usbcore 103667 9 rt2800usb,rt2x00usb,usb_storage,uas,dvb_usb_af9015,dvb_usb,usbhid,uhci_hcd,ehci_hcd hercule:/var/lib/firmware# dmesg | tail -n 20 [23644127.744095] usb 1-7: reset high-speed USB device number 3 using ehci_hcd [23644127.902596] ieee80211 phy3: Selected rate control algorithm 'minstrel_ht' [23644127.904723] Registered led device: rt2800usb-phy3::radio [23644127.904897] Registered led device: rt2800usb-phy3::assoc [23644127.905056] Registered led device: rt2800usb-phy3::quality [23644127.905396] usbcore: registered new interface driver rt2800usb [23644181.727807] usbcore: deregistering interface driver rt2800usb [23644211.708099] usb 1-7: reset high-speed USB device number 3 using ehci_hcd [23644211.866550] ieee80211 phy4: Selected rate control algorithm 'minstrel_ht' [23644211.870471] Registered led device: rt2800usb-phy4::radio [23644211.870648] Registered led device: rt2800usb-phy4::assoc [23644211.870819] Registered led device: rt2800usb-phy4::quality [23644211.871140] usbcore: registered new interface driver rt2800usb [23644324.284459] usbcore: deregistering interface driver rt2800usb [23644343.168106] usb 1-7: reset high-speed USB device number 3 using ehci_hcd [23644343.326571] ieee80211 phy5: Selected rate control algorithm 'minstrel_ht' [23644343.330394] Registered led device: rt2800usb-phy5::radio [23644343.330585] Registered led device: rt2800usb-phy5::assoc [23644343.330753] Registered led device: rt2800usb-phy5::quality [23644343.331075] usbcore: registered new interface driver rt2800usb hercule:/var/lib/firmware# et pourtant

filename: /lib/modules/3.5.4-fb-aufs/kernel/drivers/net/wireless/rt2x00/rt2800usb.ko license: GPL firmware: rt2870.bin description: Ralink RT2800 USB Wireless LAN driver. version: 2.3.0 Peut être que parmi toutes les 265 cartes gérées par ce module, celle ci n’a pas besoin du firmware, mais c’est curieux.

#33

Bon, j’ai réglé mon problème en «craquant» la fonera que j’ai (une version 1.0), j’ai obtenu un accès ssh (pas tout noté, mais c’est permanent). Ensuite j’ai modifié la configuration en mettant eth0 et ath1 dans un pont, en virant les services qui écoutait (interfaces web diverses). Modification du fichier hostapd.conf (rajout d’une ligne «bridge br0»).
Plus qu’un seul point d’accès, moins de pollution «WIFI» et maintenant l’IPV6 passe. L’amusant est que la fonera n’a pas l’ipv6, mais cela n’est pas nécessaire pour que le pont fonctionne.

Reste donc à comprendre le problème sur hercule. Mais maintenant j’ai tout mon temps pour les tests…

#34

Normal puisqu’un pont travaille uniquement sur la couche ethernet et n’a pas besoin de connaître les protocoles transportés au-dessus (sauf pour quelques subtilités style IGMP pour la gestion intelligente des groupes multicast). Par contre pas de filtrage possible avec ip6tables du coup.

J’ai ajouté le chiffrement WPA2 et le bridge sur mon point d’accès de test (Debian Squeeze noyau 2.6.32 686) et tout passe bien aussi (broadcast, multicast, DHCP IPv4, autoconf IPv6), j’envoie ce message depuis un poste connecté dessus. Donc il doit y avoir un bug dans le pilote ou le hardware de ta clé wifi, qui ne se manifeste peut-être qu’en mode master/AP. Tu peux la tester en mode station connecter à la fonera maintenant.

#35

Normal puisqu’un pont travaille uniquement sur la couche ethernet et n’a pas besoin de connaître les protocoles transportés au-dessus (sauf pour quelques subtilités style IGMP pour la gestion intelligente des groupes multicast). Par contre pas de filtrage possible avec ip6tables du coup.

Tu peux la tester en mode station connecter à la fonera maintenant.[/quote][/quote]
Pas si simple, cette machine sert de serveur (dépots, site, spamassassin pour le smtp sur une autre machine. Donc ne pouvant mettre une interface wlan0 ayant une IP sur le même réseau que eth0, ça va être plus compliqué que ça. Mais je dois pouvoir lancer juste wpa_supplicant sans lancer dhclient et pourvoir faire les tests. Je vais essayer.

#36

Bon, j’ai fait les tests, j’ai fait les choses suivantes:

wpa_supplicant -D wext -i wlan0 -c /tmp/cave.conf -w -d
[/code]
À ce stade la connexion se fait, quasi immédiatement l’interface se dote d’une IPV6 (mais pas IPV4), ce qui est de bon signe. Je test de mon portable la connexion:
ndisc6 fonctionne dans les deux sens. rdisc6 fonctionne sur hercule (rdisc6 -r 10 wlan0 récupère prefixe et autres et un tcpdump montre les paquets circuler correctement), par contre bien sûr je ne peux pas essayer dans l’autre sens. Ça semble bien être un souci dans le mode point d’accès.