# iwpriv ath0 mode 11b

Sauf que, sur ma LS2, je mangeais l’erreur suivante:

Interface doesn't accept private ioctl...
mode (8BE2): Invalid argument

Rien à faire, ça foire.
J’ai trouvé un (vilain) hack pour ce problème sur le bug system de madwifi:

I get same problem using a Z-COM XG623 minPCI card (AR2413 11b&g modes) in AP mode. The failure is due to ieee80211_check_mode_consistency() that doesn’t validate 11b (2) mode because current channel (vap->iv_des_channel) is an 11g-dyn (CCK+OFDM) channel. A possible workaround is set current channel to 0 (any channel), select the requested mode (iwpriv athx mode 11b) and then configure again the rigth operating channel. This not fix the problem but allows 11b mode operations.

Et effectivement:

# iwconfig ath0 channel 0
# iwpriv ath0 mode 11b
# iwconfig ath0 channel 7

March.
Reste à rendre ce changement un peu plus élégant en modifiant le fichier /lib/wifi/madwifi.sh à la ligne 105:

iwconfig "$ifname" channel 0 >/dev/null 2>/dev/null

puisque de toutes façons, le canal est re-placé un peu plus bas.

Ce bug est probablement une typo et il semble être corrigé dans Kamikaze 8.09.

Après quelques minutes de recherche, j’ai résolu le problème en plaçant ces quelques règles supplémentaires dans mon nginx.conf:

location / {
    set $mobile_ua '0';

    if ($http_user_agent ~* '(iPhone|iPod|mobile|Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile)') {
        set $mobile_ua '1';
    }
    # ...directives proxypass...
    proxy_cache_key imil.net$request_uri$mobile_ua;
    # ...plein d'autres trucs...
}

Explication: on initialise une variable $mobile_ua à 0, si le User Agent match l’une des chaînes de caractères listées dans la condition if, la variable $mobile_ua est placée à 1.
La clé de cache étant maintenant composée également de cette variable, nous disposons de deux espaces de cache distincts, un pour les mobiles, l’autre pour le reste.

mmmmm nginx.

• Évidemment, il faudra activer le mode IPv6 sur votre interface free
• On place les sysctl adéquats:

  net.ipv6.conf.all.forwarding=1
  net.ipv6.conf.all.proxy_ndp=1
  # pas d'autoconfiguration pour la passerelle
  net.ipv6.conf.all.autoconf=0
  net.ipv6.conf.all.accept_ra=0

• On renseigne son IPv6, par exemple pour le sous-réseau 2a01:e35:39d7:e3e0::/64:

  ip -6 addr add 2a01:e35:39d7:e3e0::2/64 dev eth1

• On déclare sa passerelle:

  ip route add default via 2a01:e35:39d7:e3e0::1 dev eth1

• Puis on place une IPv6 qui servira de passerelle à notre réseau privé sur eth0 avec une longueur de préfixe juste suffisante:

  ip -6 addr add 2a01:e35:39d7:e3e0:1::1/126 dev eth0

• L’astuce, ici encore, consiste à proxyiser les adresses du LAN sur l’interface raccordée à la freebox afin d’apparaître comme un réseau “à plat”:

  ip neigh add proxy 2a01:e35:39d7:e3e0:1::1 dev eth1

• Il suffit alors de faire de même pour toute machine de votre LAN que vous souhaitez raccorder à l’IPv6, par exemple, toujours sur la passerelle:

  ip neigh add proxy 2a01:e35:39d7:e3e0:1::2 dev eth1

• Sur la machine qui portera l’adresse 2a01:e35:39d7:e3e0:1::2, on ajoute à l’interface son IPv6, et on déclare comme passerelle par défaut 2a01:e35:39d7:e3e0:1::1:

  ip -6 addr add 2a01:e35:39d7:e3e0:1::2/126 dev eth0
  ip route add default via 2a01:e35:39d7:e3e0:1::1

• Il conviendra de rajouter tout ce petit monde dans votre /etc/network/interfaces comme il se doit, encore une fois je vous renvoie 2 posts plus bas.

La méthode est fastidieuse et pas forcément élégante, mais tant que l’opérateur free ne se sera pas sorti les ne routera pas plus qu’un /64 dans les foyers, nous devrons nous contenter de cela… ou passer la freebox en mode routeur. Nan j’déconne.

Ça a l’air tordu comme ça, mais jvous promets qu’il y a une bonne raison à tous ces choix :)

Pas d’étonnement, mon HTC Desire HD sous Android montre le même résultat:

Et histoire de me gausser, je fais le même test avec l’iPoo du boulot… bah pareil:

Ça commence à sentir bon !

Je précise qu’évidemment, ces tests ont été menés en mode WiFi et non en passant par l’opérateur de téléphonie.

Les routeurs des deux sociétés s’attendent donc à recevoir du flux IPv6 depuis un réseau “plat”, et ceci pose un réel soucis lorsque vous souhaitez distribuer une connectivité IPv6 à votre réseau possiblement NATté derrière votre passerelle. Plusieurs astuces sont disponibles depuis belle lurette, parmi elles l’utilisation d’un bridge associé à une règle ebtables, mais aussi et surtout la mise en place du proxying NDP. Je me suis basé sur cette dernière méthode, que j’ai adapté à mon éternel setup: dom0 debian GNU/Linux et domU NetBSD.

La procédure est la suivante:

On active en premier lieu le mode proxy NDP ainsi que le forwarding IPv6 sur notre dom0:

sysctl -w net.ipv6.conf.all.forwarding=1
sysctl -w net.ipv6.conf.all.proxy_ndp=1

Il conviendra evidemment de rendre cette configuration permanente en ajoutant ces valeurs dans le fichier /etc/sysctl.conf
Puis, sur notre interface de bridging Xen, nous ajoutons l’IPv6 dans le sous-réseau fourni par le fournisseur, cette adresse sera l’IP passerelle pour nos domUs:

# ifconfig xenbr0 inet6 add 2001:41e8:1:fe10::1/64

Toute l’astuce consiste à proxyiser l’adresse MAC de l’interface xenbr0 sur l’interface physique de la machine que voit réellement le fournisseur à l’aide de la commande ip:

ip neigh add proxy 2001:41e8:1:fe10::1 dev eth0

Il convient évidemment d’ajouter une route par défaut pour les adresses IPv6, cette dernière vous est fournie par votre fournisseur, par exemple pour OVH:

route -A inet6 add default gw 2001:41e8:1:feff:ff:ff:ff:ff

Nous attribuerons à notre domU l’IPv6 2001:41e8:1:fe10::2, ainsi, nous proxyisons également cette dernière de cette façon:

ip neigh add proxy 2001:41e8:1:fe10::2 dev eth0

Enfin, sur notre domU, nous ajoutons cette IP à l’interface raccordée au bridge ainsi qu’une route par défaut pointant vers l’IP de ce dernier:

ifconfig xennet0 inet6 2001:41e8:1:fe10::2 prefixlen 64
route -n add -inet6 default 2001:41e8:1:fe10::1

Et rendons ces paramètres permanents en ajoutant dans le fichier /etc/ifconfig.xennet0:

inet6 2001:41e8:1:fe10::2 prefixlen 64
!route -n add -inet6 default 2001:41e8:1:fe10::1

Finalement, nous inscrivons dans le fichier /etc/network/interfaces de notre dom0:

iface xenbr0 inet6 static
	2001:41e8:1:fe10::1
	netmask 64
	gateway 2001:41e8:1:feff:ff:ff:ff:ff
	# NDP / ARP proxying for xenbr0
	up ip neigh add proxy 2001:41e8:1:fe10::1 dev eth0
	down ip neigh del proxy 2001:41e8:1:fe10::1 dev eth0
	# NDP / ARP proxying for domU 1
	up ip neigh add proxy 2001:41e8:1:fe10::2 dev eth0
	down ip neigh del proxy 2001:41e8:1:fe10::2 dev eth0

Et le tour est joué.

Notez que je n’ai pas eu besoin, au contraire de ce qu’indique la documentation sur laquelle je me suis appuyé, de passer l’interface eth0 en mode promiscuous, probablement parce que j’utilise un bridge monté sur une interface de type dummy, dissocié de l’interface physique, et que les routes IPv6 de mes domU utilisent explicitement l’IP montée sur ce dernier.

Tout ceci manquait cruellement d’un soupçon d’IPv6. Ainsi, après m’être frotté à SixXs et son système de crédits aussi ingénieux que pénible, j’ai finalement opté pour Hurricane Electric qui a en plus le bon goût de posséder un endpoint à Paris.

Si la configuration d’un tunnel v4/v6 se réalise le plus simplement du monde depuis plus de 10 ans via des tunnels gif, l’opération n’est pas complètement triviale lorsque le endpoint se trouve être NATté et qu’en plus ce dernier utilise une route par défaut différente de l’IP publique officielle du dom0.

Ainsi, après avoir souscrit à un endpoint IPv6 chez HE, quelques opérations sont nécessaires au bon fonctionnement du routage. Nous considèrerons que l’ip du endpoint gif IPv4 chez Hurricane est 1.2.3.4 et que notre IPv4 publique, sur le dom0 donc, est 5.6.7.8.

La première chose à faire sur notre dom0 est de rediriger tout le traffic en provenance de HE vers notre domU, dont nous considèrerons que l’IPv4 privée est 192.168.0.1.

# iptables -t nat -A PREROUTING -i eth0 -s 1.2.3.4 -j DNAT --to-destination 192.168.0.1

Il faudra évidemment, si cela n’est pas déjà fait, appliquer du SNAT afin que votre domU puisse “sortir” et se présenter avec notre IPv4 publique au monde. Par exemple:

# iptables -t nat -A POSTROUTING -s 192.168.0.1/32 -o eth0 -j SNAT --to-source 5.6.7.8

C’est l’unique configuration à effectuer sur le dom0. Jusqu’ici tout va bien.

Sur notre domU NetBSD, nous créons l’interface de tunneling comme ceci:

# ifconfig gif0 create
# ifconfig gif0 tunnel 192.168.0.1 1.2.3.4
# ifconfig gif0 inet6 2001:470:1e31:b2c::2 2001:470:1e31:b2c::1 prefixlen 128

Notez que c’est bien l’IPv4 privée que nous utilisons pour monter le tunnel gif, le SNAT du dom0 s’occuppera de transformer cette IP au vol.
Cette seule configuration, compte tenu du routage particulier de notre domU, ne suffira pas au bon fonctionnement du tunnel. Deux opérations sont nécessaires:

• Ajouter une route explicite vers le endpoint HE
• Forcer la sortie vers l’interface réelle du dom0 lorsqu’on essaye de joindre une adresse IPv6

Execution:

# route add -host 1.2.3.4 192.168.0.254

Ici, 192.168.0.254 est l’adresse passerelle du dom0.

# grep he_tunnel /etc/pf.conf-ovpn
he_tunnel="1.2.3.4/32"
pass out quick route-to ($real_if $gateway) from any to $he_tunnel

$real_if représente l’interface xennet0, et $gateway l’adresse de notre passerelle coté dom0, à savoir 192.168.0.254.
Reste à appliquer une route par défaut pour les adresses IPv6:

route -n add -inet6 default 2001:470:1e31:b2c::1

Et nous y sommes. Enfin, il faut evidemment automatiser toutes ces manipulations afin de retrouver notre état fonctionnel à chaque reboot, cela est réalisé en créant le fichier /etc/ifconfig.gif0 avec ce contenu:

create
tunnel 192.168.0.1 1.2.3.4
inet6 2001:470:1e31:b2c::2 2001:470:1e31:b2c::1 prefixlen 128
!route add -host 1.2.3.4 192.168.0.254
!route -n add -inet6 default 2001:470:1e31:b2c::1

And voila, Danse petite tortue, danse !

Nov 10 05:32:22 yavin kernel: [838380.839883] BUG: soft lockup - CPU#0 stuck for 61s! [swapper:0]
Nov 10 05:32:22 yavin kernel: [838380.839883] Modules linked in: dummy xt_tcpudp iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_physdev iptable_filter ip_tables x_tables xen_evtchn xenfs bridge stp ext2 w83627hf w83793 hwmon_vid loop snd_pcm snd_timer snd radeon soundcore snd_page_alloc ttm drm_kms_helper parport_pc drm parport pcspkr evdev i2c_i801 i2c_algo_bit rng_core serio_raw i2c_core container shpchp pci_hotplug i3000_edac button processor edac_core acpi_processor ext3 jbd mbcache dm_mod raid1 md_mod sd_mod crc_t10dif ata_generic uhci_hcd ata_piix libata thermal floppy ehci_hcd scsi_mod thermal_sys usbcore nls_base e1000e [last unloaded: dummy]

Le tout saupoudré de quelques stack traces du meilleur effet:

Nov 11 19:52:20 yavin kernel: [976376.042974]    [] ? xen_swiotlb_unmap_page+0x0/0x5
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? xen_force_evtchn_callback+0x9/0xa
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? check_events+0x12/0x20
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? xen_swiotlb_unmap_page+0x0/0x5
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? xen_restore_fl_direct_end+0x0/0x1
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? kfree+0xc6/0xcb
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? skb_release_head_state+0xb4/0xc8
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? __kfree_skb+0x9/0x7d
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? e1000_put_txbuf+0x5a/0x6c [e1000e]
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? e1000_clean_tx_irq+0x9d/0x21e [e1000e]
Nov 11 19:52:20 yavin kernel: [976376.042974]  [] ? e1000_clean+0x5c/0x235 [e1000e]

Et j’en passe. Bref, ça pue.

Après m’être documenté quelque peu sur les erreurs constatées, deux actions semblent avoir stabilisé la situation. Premièrement, plusieurs posts dans quelques forums indiquent que l’installation de intel-microcode et microcode.ctl permet de “réparer” certains bugs embarqués dans les processeurs Intel. Je m’execute:

# apt-get install intel-microcode microcode.ctl

Deuxièmement, comme le conseille la section Best Practices de Xen.org, il est de bon ton de:

• Fixer la quantité de mémoire du dom0 afin d’éviter le ballooning
• Attacher un core (“cpu pinning”) au dom0

Ainsi, j’ajoute la ligne suivante au fichier /etc/default/grub:

GRUB_CMDLINE_XEN="dom0_mem=1024M dom0_max_vcpus=1 dom0_vcpus_pin"

Et précise dans /etc/xen/xend-config.sxp:

(dom0-min-mem 1024)

Ne disposant, sur cette machine, que de deux cores, je n’exclurai pas le CPU0 de la configuration des domU, mais fais confiance à l’hyperviseur pour équilibrer les ressources efficacement, sachant que désormais le CPU0 est “pinné” au dom0. Reste alors à régénérer la configuration de grub:

# update-grub

Et, malheureusement, de rebooter. Pas le choix ici.

Moyennant ces ajustements, mon dom0 ne semble plus souffir, alors que ses domUs compilent à tour de bras.

La première chose à faire est de préciser que nous souhaitons bénéficier du support TLS et SASL dans sendmail. Ceci est réalisé dans le fichier /etc/mk.conf:

PKG_OPTIONS.sendmail=   tls sasl

Je ne sais pas si cela est lié au fait que la machine sur laquelle j’ai mené l’opération est “encore” en 5.0.2, mais la compilation de cyrus-sasl a misérablement échoué dans sa configuration par défaut. Ceci:

db_ndbm.c: In function '_sasldb_getdata':
db_ndbm.c:95: warning: passing argument 3 of 'utils->getcallback' from incompatible pointer type

M’a mis sur la voie, et j’ai donc ajouté dans mon /etc/mk.conf la ligne suivante:

SASL_DBTYPE=            berkeley

Un make update clean plus loin, tout était installé. Il est à noter que, par défaut, cyrus-sasl ne fournit aucun plugin, aussi, il sera nécessaire d’en installer au moins un, par exemple:

# cd /usr/pkgsrc/security/cy2-login
# make install clean

Qui nous permettra d’utiliser le couple login/password de notre système. Deux étapes sont nécessaires pour utiliser cette méthode, tout d’abord, il faut installer le démon saslauthd, en charge des échange d’authentification plain text:

# cd /usr/pkgsrc/security/cyrus-saslauthd/
# make install clean
# cp /usr/pkg/share/examples/rc.d/saslauthd /etc/rc.d
# echo "saslauthd=YES" >> /etc/rc.conf
# /etc/rc.d/saslauthd start

Puis de préciser au plugin SASL qu’il devra utiliser le démon saslauthd pour l’authentification en provenance de sendmail.

# cat /usr/pkg/lib/sasl2/Sendmail.conf
pwcheck_method:saslauthd

Nous ajoutons maintenant à sendmail la gestion de ces deux nouvelles fonctionnalités:

# cd /usr/pkg/share/sendmail/cf
# cat monserveur.mc
[...]
dnl ### SMTP AUTH
define(`confAUTH_MECHANISMS', `LOGIN')dnl
TRUST_AUTH_MECH(`LOGIN')dnl
dnl ### STARTTLS
dnl ### Ces sertificats sont en provenance de CACert.org. Il ne s'agit pas de certificats auto-signés
define(`confCACERT_PATH',`/etc/mail/certs/')dnl
define(`confCACERT', `/etc/mail/certs/cacert.crt')
define(`confSERVER_CERT',`/etc/mail/certs/certificat_serveur.pem')dnl
define(`confSERVER_KEY',`/etc/mail/certs/certificat_privatekey.pem')dnl
[...]

Puis nous compilons et installons la nouvelle configuration:

# make install-cf CF=monserveur
rm -f monserveur.cf
m4 ../m4/cf.m4 monserveur.mc > monserveur.cf || ( rm -f monserveur.cf && exit 1 )
echo "### monserveur.mc ###" >>monserveur.cf
sed -e 's/^/# /' monserveur.mc >>monserveur.cf
chmod 444 monserveur.cf
/usr/bin/install -c -o root -g wheel -m 0444 monserveur.cf /etc/mail/sendmail.cf
/usr/bin/install -c -o root -g wheel -m 0444 monserveur.cf /etc/mail/submit.cf

À l’issue d’un /etc/rc.d/sendmail restart, nous devrions constater les choses suivantes:

# sendmail -d0.1 -bv root | grep SASL
                SASLv2 SCANF SOCKETMAP STARTTLS TCPWRAPPERS USERDB XDEBUG

Et également:

# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220monserveur ESMTP Sendmail 8.14.5/8.14.5; Fri, 11 Nov 2011 13:13:17 +0100 (CET)
ehlo localhost
250-monserveur Hello localhost [127.0.0.1], pleased to meet you
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-EXPN
250-VERB
250-8BITMIME
250-SIZE 5000000
250-DSN
250-ETRN
250-AUTH LOGIN
250-STARTTLS
250-DELIVERBY
250 HELP

Ne reste alors qu’à configurer votre MUA pour qu’il utilise votre serveur SMTP sur le port 587 en TLS avec la méthode LOGIN, avec les login/passwd de l’utilisateur souhaité.

Enjoy.