Pourquoi donc me direz-vous ? simplement parce-que dans l’éventualité où faire bouger le prestataire en face de vous (celui qui héberge le serveur SSH) coûterait trop d’énergie, on va supposer qu’on ne peut pas facilement faire avaler notre clef publique à l’hébergeur du serveur SSH.

Bref, la commande traditionnelle est :

sftp utilisateur@serveur
Connecting to serveur...
utilisateur@serveur's password:
sftp>

J’ai trouvé une méthode simple : utiliser le client SFTP de “PuTTY”.
Je pensais au départ utiliser celui de “lftp” et sauvegarder ma connexion (avec mot de passe) en bookmark, mais comme mon login dans l’histoire est un utilisateur de domaine windows (ouais, le serveur SSH en face est sous windows O_o), y’a un \ dans le login et même en le doublant, lftp semble mal le digérer, ben j’étais aussi bloqué.

Bref, en installant les outils de PuTTY :

aptitude install putty-tools

On peut alors taper :

psftp -pw mon_pass utilisateur@serveur
Using username "utilisateur".
Remote working directory is /
psftp>

Attention : le mot de passe est en clair dans la ligne de commande, donc dans les processus etc etc. Donc c’est pas idéal comme condition.
Enfin, je n’ai pas mis le paramètre -b pour mon batch, car ce n’est pas le propos là.

Les paroles sont stockées dans le mp3 (le tag “lyrics3″ je suppose) et du coup lisible sur un lecteur qui se respecte. En l’occurrence un iphone.

Ca gère évidemment les OGG, les FLAC etc… en plus des MP3.

• configurer postfix pour gérer des utilisateurs virtuels
• monter une architecture complète “postfix / postgrey / amavisd-new / clamav / spamassassin”

Il manque cependant un morceau : la possibilité de faire appel à des “procmail” personnalisés pour ces utilisateurs virtuels.

Lorsqu’on n’est pas avec des utilisateurs virtuels, chaque utilisateur réel (ayant un compte utilisateur, donc) utilise généralement son ~/.procmailrc pour trier un peu ou - cas qui m’intéresse particulièrement – activer son répondeur d’absence, “vacation“ pour ne pas le nommer.
Dans le cas d’utilisateurs virtuels, c’est sensiblement différent. C’est ce que je décrirai dans cet article. Ce n’est au final pas compliqué, mais il faut comprendre le rôle de chaque composant et les limites de fonctionnement de chaque outil.
En effet, je n’ai pas trouvé de doc ultra-claire sur le sujet sur le web, surtout les bricoles de chacun. Avec un peu de recul, et, voyant ma propre solution, j’ai l’impression qu’il y a tellement de configurations possibles (maildrop et pas procmail, mes utilisateurs virtuels comme ci, pas comme ça, il utilise postfixadmin et pas moi etc) qu’il est impossible d’écrire un truc qui n’est pas spécifique.
Le plus dur est donc de comprendre ce qu’on fait pour transposer à sa conf. Je tâcherai donc, comme d’hab, d’expliquer ce que je fais plutôt que de copier-coller les fichiers de conf.

Allez, let’s go pour la mise en place sur la base d’une archi postfix & co comme décrite dans les docs mentionnées en début de cet article.

Ah, dernier point : à la base, et tel que je le décris, l’utilisateur ne pourra pas mettre lui même son répondeur en place. Dans mon cas, ce n’est pas important. En effet, j’utilise des utilisateurs virtuels car il s’agit d’un serveur frontal de mails (qui trie le spam, en gros), livre les messages dans des arborescences virtuelles en attendant d’être POPées depuis un backend de mails quelconque (un vilain Exchange ). Donc, le répondeur d’absence des utilisateurs “physiques” est géré par eux-mêmes dans Outlook “normalement”, et je n’applique ce principe de répondeur qu’exceptionnellement, à quelques boîtes mails IMAP génériques, qui n’ont pas vraiment de notion de “vacances”. Des boîtes partagées entre plusieurs personnes, si vous voulez, mais stockées sur le frontal et pas dans le backend, pour diverses raisons dont on se moque ici. Après vous pourrez toujours bricoler un truc pour que tout un chacun accède à son procmail ou son message d’asbence pour le mettre, l’enlever etc.

Le principe

On veut activer le répondeur de toto@domaine.fr en utilisant l’outil “vacation” qui gère très bien les réponses. “vacation” ne joue qu’avec des comptes utilisateurs existants. Premier problème.

Pour y arriver, on va créer des alias pour ce compte virtuel “toto@domaine.fr” afin que postfix “forward” (du nom de la table “forwardings” gérant les alias des utilisateurs virtuels) tout mail à destination de toto@domaine.fr vers 2 endroits :

• le réel toto@domaine.fr, histoire de délivrer le mail quand même, au final
• et en plus vers un certain toto@vacation.domaine.fr qui n’existe pas

Ce dernier nom “vacation.domaine.fr” n’a pas besoin d’exister au sens DNS et ne correspond pas non plus à un MX réel. On va juste créer un “transport” (du nom de la table MySQL qu’on a créée avec les docs précédentes) particulier afin de router les messages à destination du domaine “vacation.domaine.fr” vers un “pipe” particulier de postfix qu’on va créer pour l’occasion.
Ce “pipe” UNIX, composant qu’on ajoute à la chaîne postfix, gèrera en fait l’appel à procmail configuré d’une manière globale (un gros procmailrc générique, si vous voulez).
Ce procmail fera ensuite un tri sur le nom du destinaire et appellera “vacation” lorsqu’on le veut avec un message personnalisé.

C’est ce procmail global qu’il conviendrait de découper (avec des INCLUDE), ainsi que les fichiers de messages d’absence qui vont avec, si on voulait donner la main d’une manière pas super pratique (FTP ? samba ?) à des utilisateurs réels sur leur répondeur de compte virtuel…

Je me suis basé sur pas mal de docs bizarroïdes, et surtout sur les quelques explications trouvées ici. Le cheminement y est, mais c’est pas détaillé sur le principe et le type propose son propre script de répondeur ; script qui peut générer une belle boucle infinie entre répondeurs, à mon humble avis. Ce risque n’existe pas avec “vacation“, car il garde une liste des gens “déjà répondus”, sauf si vous forcez à répondre à chaque fois.

Mise en place

Paquets, utilisateur etc

Au besoin, suivant l’état de votre installation :

aptitude install procmail vacation

Ensuite, j’ai expliqué que “vacation” ne travaillait que sur un compte réel. Je lui dédie donc un compte :

useradd -m vacation -s /bin/nologin -c "Utilisateur vacation"

Création du pipe UNIX

On crée le processus qui sera en charge de router (de manière interne à postfix) les messages arrivant dans un pipe qu’on nomme “repondeur” vers procmail (lui même appelant le cas échéant le programme de répondeur “vacation“).
Dans /etc/postfix/master.cf, à la fin (peu importe), on définit ce pipe comme suit :

#ajout d'un appel à procmail pour gérer certains 'vacation' sur les boites IMAP
#attention, l'appel à ce pipe est géré dans la table des transports virtuels + des forwardings qui vont bien
repondeur   unix    -       n       n       -       10      pipe
  flags=Rq user=vacation argv=/usr/bin/procmail -Y -m /etc/postfix/procmail-global-repondeur.rc ${sender} ${recipient}

Les espaces avant “flags” sont importants, c’est ce qui explique à postfix qu’il s’agit d’option du pipe nommé “repondeur”.
Je décrirai le fichier /etc/postfix/procmail-global-repondeur.rc plus tard. C’est lui qui contiendra les appels aux “vacation” de tels et tels utilisateurs.
J’avoue ne pas être super sûr des flags utilisés, voyez man pipe au besoin.

transport virtuel

Si votre base MySQL est exactement celle que je décris dans mes précédentes documentations, insérez une ligne dans la table “transport” afin d’avoir :

mysql> select * from transport;
+---------------------+-----------+
| domain              | transport |
+---------------------+-----------+
| vacation.domaine.fr | repondeur |
+---------------------+-----------+
1 row in set (0.00 sec)

Pour bien relier cette table à votre configuration “virtuelle”, la table “transport” dont je parle est celle décrite comme ça dans postfix :

[extraits de fichiers]
main.cf:transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
mysql-virtual_transports.cf:query = SELECT transport FROM transport WHERE domain='%s'

Création des alias pour router vers le “pipe” “repondeur”

Pour chaque utilisateur virtuel qui devra avoir un répondeur actif (ou potentiellement actif), il faudra ajouter 2 alias le concernant dans la table des alias (“forwardings” dans mon cas, là encore, ça dépend de votre conf de “postfix virtuel”). Ajoutez donc les lignes pour avoir :

mysql> select * from forwardings where source like 'j%doma%';
+--------------------+-----------------------------+
| source             | destination                 |
+--------------------+-----------------------------+
| jacques@domaine.fr | jacques@domaine.fr          |
| jacques@domaine.fr | jacques@vacation.domaine.fr |
+--------------------+-----------------------------+
2 rows in set (0.00 sec)

J’ai eu un souci pour insérer ces 2 lignes, car il y a une contrainte de clef primaire sur “source”, ce qui semble logique, mais qui est en fait bloquant pour nous et inutile dans un cas normal d’alias d’utilisateurs virtuels (on pourrait faire une liste de diffusion en créant plusieurs lignes pour une même source car postfix gère très bien le fait d’avoir plusieurs destination pour une même source).
Bref, j’ai fait sauté la contrainte PK que j’avais mise dans mes docs précédents :

ALTER TABLE forwardings
DROP PRIMARY KEY;

Rassurez-vous, ça ne fait pas sauter les entrées déjà stockées dans la table si vous en avez.

procmailrc et vacation

On y est presque.
Reste à définir le procmail global appelant vacation :
Dans mon “pipe“, j’appelle ce fichier :

servr:/etc/postfix# cat /etc/postfix/procmail-global-repondeur.rc
SHELL=/bin/sh

:0c
* ^(To|Cc).*jacques@domaine.fr
| vacation -f /home/vacation/jacques@domaine.fr.db -m /home/vacation/jacques@domaine.fr.msg -a jacques@domaine.fr vacation

:0c
* ^(To|Cc).*autre_type@domaine.fr
| vacation -f /home/vacation/autre_type@domaine.fr.db -m /home/vacation/autre_type@domaine.fr.msg -a autre_type@domaine.fr vacation

:0
/dev/null

Alors, c’est presque le plus compliqué car ce fichier est plein de petites ruses. Il vous montre comment procéder lorsque vous aurez plusieurs boîtes concernées par un vacation.
Je rappelle que de cette manière, c’est un peu pénible à maintenir car c’est l’admin qui gère. Là il s’agit de boîte IMAP partagées et peu nombreuses, donc c’est gérable.

Le détail est donc :

• Je stocke tous mes messages de “vacances” dans ~vacation/
• -f : pour indiquer dans quelle “base de données” on stocke les gens à qui on a déjà répondu
• -m : pour indiquer le mail de réponse d’un utilisateur donné, je le détaille plus bas
• -a : hyper important : en effet, vacation ne travaille que sur un utilisateur réel. Donc obligé de spécifier un utilisateur réel en fin de commande vacation, c’est l’utilisateur “vacation” himself qui figure en dernier argument de la ligne de commande. Donc, pour que vacation travaille, j’explique aussi que cet utilisateur réel peut être connu sous l’alias (-a) jacques@domaine.fr (ou autre_type@domaine.fr dans la 2è règle). Sinon aucune règle ne s’appliquera jamais.
• “:0c” : OUI : il faut activer le “carbon copy”. J’ai constaté ça à force de tests. En effet, un message arrivant dans postfix a un ID, il est dédoublé avec le même ID, l’un part vers l’utilisateur réel pour livraison, l’autre vers le “pipe“, puis procmail, puis vacation. “vacation” arrête les règles (si on ne met pas le “c” de carbon copy) dès que ça “match”. Si un expéditeur envoi un unique mail à en même temps jacques@domaine.fr et autre_type@domaine.fr, la première règle va marcher, donc procmail arrêtera de bosser. Résultat : pas de répondeur pour “autre_type”. On ne sait pas qu’il est en vacances.
• Et enfin, le piège des “carbon copy” : si on ne fait pas une dernière règle virant vers /dev/null tout message au final, un message légitime auquel on aura répondu par “vacation” sortira de procmail et continuera sa route : il sera donc livré. Mais c’est un utilisateur complètement bidon, untel@vacation.domaine.fr, domaine inexistant => erreur de livraison => log dans /var/log/mail.info et surtout, mail d’erreur bien crade informant l’expéditeur…

fichier .msg de vacation

Voici à quoi doit ressembler un fichier de réponse minimaliste :

servr:/etc/postfix# cat ~vacation/jacques\@domaine.fr.msg
From: jacques@domaine.fr (Jacques)
Subject: Re: $SUBJECT
Precedence: Bulk

Votre mail a bien été reçu, blablablabla
-- Jacques

reload postfix et tests

A la fin, /etc/init.d/postfix reload et zou, testez des envois de mails, de réenvois de mails (pour n’avoir qu’une fois la réponse etc).
Le plus risqué dans cette manip’ sur un serveur en production, c’est que tout les adresses normales commencent à merdouiller. Le plus rapide pour annuler tout ça le temps de réfléchir, est de commenter les 2 lignes définissant le pipe et de rechargez postfix.

Autres remarques

Réinit d’un répondeur

A une époque, il me semblait qu’en modifiant le fichier .msg, vacation détectait le changement et donc ne tenait plus compte des expéditeurs “déjà répondus”. Après quelques tests, je n’en suis plus si sûr. Le plus simple pour relancer un répondeur “pour tous” : supprimez le fichier .db correspondant.

Permissions

Attention, j’ai interdit le login pour l’utilisateur vacation. Donc tout ce que vous créerez dans ~vacation/*msg sera sûrement au nom de “root”, par exemple. Pensez à changer les droits.
Si vous avez raté un truc, les logs sont très explicites dans /var/log/mail.info.
Je crois aussi me rappeler que si vacation ne voit pas le fichier .msg, il ne fera rien. A vérifier, mais c’est une méthode simple (et crade car ça va faire du log à coup sûr) pour activer/désactiver un répondeur

un log complet pour illustrer

Si tout se passe bien, vous avez ça :
Connexion du serveur expéditeur :

Jun 14 17:10:21 servr postfix/smtpd[20107]: connect from expediteur.org[xx.yy.zz.tt]
Jun 14 17:10:21 servr postgrey[12166]: action=pass, reason=client AWL, client_name=expediteur.org, client_address=xx.yy.zz.tt, sender=exped@expediteur.org, recipient=jacques@domaine.fr
Jun 14 17:10:21 servr postfix/smtpd[20107]: C2B829C4081: client=expediteur.org[xx.yy.zz.tt]
Jun 14 17:10:21 servr postfix/cleanup[20065]: C2B829C4081: message-id=<20100614151021.AF0F0EEC57C@mail.expediteur.org>
Jun 14 17:10:21 servr postfix/qmgr[19547]: C2B829C4081: from=, size=515, nrcpt=2 (queue active)
Jun 14 17:10:21 servr postfix/smtpd[20107]: disconnect from expediteur.org[xx.yy.zz.tt]
Jun 14 17:10:23 servr postfix/smtpd[20208]: connect from localhost.localdomain[127.0.0.1]
Jun 14 17:10:23 servr postfix/smtpd[20208]: 8A0E69C4085: client=localhost.localdomain[127.0.0.1]
Jun 14 17:10:23 servr postfix/cleanup[20065]: 8A0E69C4085: message-id=<20100614151021.AF0F0EEC57C@mail.expediteur.org>
Jun 14 17:10:23 servr postfix/smtpd[20208]: disconnect from localhost.localdomain[127.0.0.1]
Jun 14 17:10:23 servr postfix/qmgr[19547]: 8A0E69C4085: from=, size=1045, nrcpt=3 (queue active)

Pas de greylisting, car c’est un pote. Analyse par amavis OK, on dédouble le message vers jacques@domaine.fr et jacques@vacation.domaine.fr.
Chaque file suivra alors sa route :

Jun 14 17:10:23 servr amavis[18918]: (18918-18) Passed CLEAN, [xx.yy.zz.tt] [xx.yy.zz.tt]  -> ,, Message-ID: <20100614151021.AF0F0EEC57C@mail.expediteur.org>, mail_id: uuW4XqNAoH7S, Hits: 1.714, size: 515, queued_as: 8A0E69C4085, 1902 ms
Jun 14 17:10:23 servr postfix/smtp[20190]: C2B829C4081: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.03/0/0/1.9, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=18918-18, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8A0E69C4085)
Jun 14 17:10:23 servr postfix/smtp[20190]: C2B829C4081: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.03/0/0/1.9, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=18918-18, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8A0E69C4085)
Jun 14 17:10:23 servr postfix/qmgr[19547]: C2B829C4081: removed

La partie “utilisateur virtuel de postfix” traite le “mail normal” => “delivered to maildir”. Ca roule :

Jun 14 17:10:23 servr postfix/virtual[20212]: 8A0E69C4085: to=, relay=virtual, delay=0.3, delays=0.15/0.01/0/0.14, dsn=2.0.0, status=sent (delivered to maildir)

La partie “vacation” (pipe repondeur) route vers le “relay=repondeur”. Le job s’accomplit correctement “(delivered via repondeur service)”. Là on n’a pas d’autre erreur, sinon on pourrait voir vacation ou procmail pas content :

Jun 14 17:10:23 servr postfix/pickup[19550]: ECF179C408A: uid=5001 from=
Jun 14 17:10:23 servr postfix/pipe[20209]: 8A0E69C4085: to=, orig_to=, relay=repondeur, delay=0.41, delays=0.15/0/0/0.25, dsn=2.0.0, status=sent (delivered via repondeur service)
Jun 14 17:10:23 servr postfix/pipe[20209]: 8A0E69C4085: to=, relay=repondeur, delay=0.41, delays=0.15/0/0/0.25, dsn=2.0.0, status=sent (delivered via repondeur service)
Jun 14 17:10:23 servr postfix/cleanup[20065]: ECF179C408A: message-id=<20100614151023.ECF179C408A@domaine.fr>
Jun 14 17:10:23 servr postfix/qmgr[19547]: 8A0E69C4085: removed
Jun 14 17:10:24 servr postfix/qmgr[19547]: ECF179C408A: from=, size=343, nrcpt=1 (queue active)

Deux secondes plus tard, “vacation” a détecté qu’il fallait répondre à “exped@expediteur.org”, donc on envoit un mail :
(le champ From sera jacques@domaine.fr, seul Return-Path sera à vacation@domaine.fr)

Jun 14 17:10:26 servr postfix/smtpd[20208]: connect from localhost.localdomain[127.0.0.1]
Jun 14 17:10:26 servr postfix/smtpd[20208]: 174A99C4081: client=localhost.localdomain[127.0.0.1]
Jun 14 17:10:26 servr postfix/cleanup[20065]: 174A99C4081: message-id=<20100614151023.ECF179C408A@domaine.fr>
Jun 14 17:10:26 servr postfix/qmgr[19547]: 174A99C4081: from=, size=770, nrcpt=1 (queue active)
Jun 14 17:10:26 servr amavis[20202]: (20202-01) Passed CLEAN,  -> , Message-ID: <20100614151023.ECF179C408A@domaine.fr>, mail_id: xw6dpgfdz+b5, Hits: -0.001, size: 343, queued_as: 174A99C4081, 2197 ms
Jun 14 17:10:26 servr postfix/smtp[20190]: ECF179C408A: to=, relay=127.0.0.1[127.0.0.1]:10024, delay=2.3, delays=0.14/0/0/2.2, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=20202-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 174A99C4081)
Jun 14 17:10:26 servr postfix/qmgr[19547]: ECF179C408A: removed
Jun 14 17:10:26 servr postfix/smtp[20219]: 174A99C4081: to=, relay=mail.expediteur.org[xx.yy.zz.tt]:25, delay=0.21, delays=0.14/0/0.02/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4337FEEC560)
Jun 14 17:10:26 servr postfix/qmgr[19547]: 174A99C4081: removed

Les symptomes

Après l’upgrade, on se retrouve en kernel 2.6.32-22. Le wifi fonctionne par exemple sur un réseau en WPA2, mais ça n’accroche pas sur un réseau WPA (certains disent WPA mixte WPA2, j’en sais rien).
Autant utiliser du WPA2. Oui d’accord, mais ma freebox, elle fait que du WPA…
=> Le driver RT2860 est buggé dans ce noyau.

Les logs

Vous verrez qu’on tourne en rond entre “l’association” avec le point d’accès et le rescan des réseaux ça rate X fois, puis on abandonne pour de bon :

May 19 19:33:17 ubuntu NetworkManager:   Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
May 19 19:33:17 ubuntu NetworkManager:   Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
May 19 19:33:17 ubuntu NetworkManager:   (wlan0): device state change: 6 -> 4 (reason 0)
May 19 19:33:17 ubuntu NetworkManager:   Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
May 19 19:33:17 ubuntu NetworkManager:   Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
May 19 19:33:17 ubuntu NetworkManager:   Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
May 19 19:33:17 ubuntu NetworkManager:   (wlan0): device state change: 4 -> 5 (reason 0)
May 19 19:33:17 ubuntu NetworkManager:   Activation (wlan0/wireless): connection 'Auto folie' has security, and secrets exist.  No new secrets needed.
May 19 19:33:17 ubuntu NetworkManager:   Config: added 'ssid' value 'folie'
May 19 19:33:17 ubuntu NetworkManager:   Config: added 'scan_ssid' value '1'
May 19 19:33:17 ubuntu NetworkManager:   Config: added 'key_mgmt' value 'WPA-PSK'
May 19 19:33:17 ubuntu NetworkManager:   Config: added 'psk' value ''
May 19 19:33:17 ubuntu NetworkManager: nm_setting_802_1x_get_pkcs11_engine_path: assertion `NM_IS_SETTING_802_1X (setting)' failed
May 19 19:33:17 ubuntu NetworkManager: nm_setting_802_1x_get_pkcs11_module_path: assertion `NM_IS_SETTING_802_1X (setting)' failed
May 19 19:33:17 ubuntu NetworkManager:   Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
May 19 19:33:18 ubuntu NetworkManager:   Config: set interface ap_scan to 1
May 19 19:33:18 ubuntu NetworkManager:   (wlan0): supplicant connection state:  disconnected -> scanning
May 19 19:33:23 ubuntu wpa_supplicant[3187]: Trying to associate with 66:f2:bc:b8:cc:30 (SSID='folie' freq=2412 MHz)
May 19 19:33:23 ubuntu NetworkManager:   (wlan0): supplicant connection state:  scanning -> associating
May 19 19:33:23 ubuntu kernel: [  660.417251] ===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 636
May 19 19:33:23 ubuntu kernel: [  660.417895] ==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
May 19 19:33:23 ubuntu wpa_supplicant[3187]: Association request to the driver failed
May 19 19:33:28 ubuntu wpa_supplicant[3187]: Authentication with 66:f2:bc:b8:cc:30 timed out.
May 19 19:33:28 ubuntu NetworkManager:   (wlan0): supplicant connection state:  associating -> disconnected
May 19 19:33:28 ubuntu NetworkManager:   (wlan0): supplicant connection state:  disconnected -> scanning
May 19 19:33:33 ubuntu wpa_supplicant[3187]: Trying to associate with 66:f2:bc:b8:cc:30 (SSID='folie' freq=2412 MHz)
May 19 19:33:33 ubuntu kernel: [  670.433534] ===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 636
May 19 19:33:33 ubuntu kernel: [  670.434373] ==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
May 19 19:33:33 ubuntu NetworkManager:   (wlan0): supplicant connection state:  scanning -> associating
May 19 19:33:33 ubuntu wpa_supplicant[3187]: Association request to the driver failed
May 19 19:33:38 ubuntu wpa_supplicant[3187]: Authentication with 66:f2:bc:b8:cc:30 timed out.
May 19 19:33:38 ubuntu NetworkManager:   (wlan0): supplicant connection state:  associating -> disconnected
May 19 19:33:38 ubuntu NetworkManager:   (wlan0): supplicant connection state:  disconnected -> scanning
May 19 19:33:43 ubuntu kernel: [  680.449828] ===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 636
May 19 19:33:43 ubuntu kernel: [  680.450463] ==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
May 19 19:33:43 ubuntu wpa_supplicant[3187]: Trying to associate with 66:f2:bc:b8:cc:30 (SSID='folie' freq=2412 MHz)
May 19 19:33:43 ubuntu NetworkManager:   (wlan0): supplicant connection state:  scanning -> associating
May 19 19:33:43 ubuntu wpa_supplicant[3187]: Association request to the driver failed
May 19 19:33:48 ubuntu wpa_supplicant[3187]: Authentication with 66:f2:bc:b8:cc:30 timed out.
May 19 19:33:48 ubuntu NetworkManager:   (wlan0): supplicant connection state:  associating -> disconnected
May 19 19:33:48 ubuntu NetworkManager:   (wlan0): supplicant connection state:  disconnected -> scanning
May 19 19:33:53 ubuntu wpa_supplicant[3187]: Trying to associate with 66:f2:bc:b8:cc:30 (SSID='folie' freq=2412 MHz)
May 19 19:33:53 ubuntu kernel: [  690.468163] ===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 636
May 19 19:33:53 ubuntu kernel: [  690.468883] ==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
May 19 19:33:53 ubuntu NetworkManager:   (wlan0): supplicant connection state:  scanning -> associating
May 19 19:33:53 ubuntu wpa_supplicant[3187]: Association request to the driver failed
May 19 19:33:58 ubuntu NetworkManager:   wlan0: link timed out.
May 19 19:33:58 ubuntu wpa_supplicant[3187]: Authentication with 66:f2:bc:b8:cc:30 timed out.
May 19 19:33:58 ubuntu NetworkManager:   (wlan0): supplicant connection state:  associating -> disconnected
May 19 19:33:58 ubuntu NetworkManager:   (wlan0): supplicant connection state:  disconnected -> scanning
May 19 19:34:03 ubuntu kernel: [  700.491916] ===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 636
May 19 19:34:03 ubuntu wpa_supplicant[3187]: Trying to associate with 66:f2:bc:b8:cc:30 (SSID='folie' freq=2412 MHz)
May 19 19:34:03 ubuntu kernel: [  700.492792] ==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
May 19 19:34:03 ubuntu NetworkManager:   (wlan0): supplicant connection state:  scanning -> associating
May 19 19:34:03 ubuntu wpa_supplicant[3187]: Association request to the driver failed
May 19 19:34:08 ubuntu wpa_supplicant[3187]: Authentication with 66:f2:bc:b8:cc:30 timed out.
May 19 19:34:08 ubuntu NetworkManager:   (wlan0): supplicant connection state:  associating -> disconnected
May 19 19:34:08 ubuntu NetworkManager:   (wlan0): supplicant connection state:  disconnected -> scanning
May 19 19:34:13 ubuntu kernel: [  710.512617] ===>rt_ioctl_giwscan. 5(5) BSS returned, data->length = 636
May 19 19:34:13 ubuntu wpa_supplicant[3187]: Trying to associate with 66:f2:bc:b8:cc:30 (SSID='folie' freq=2412 MHz)
May 19 19:34:13 ubuntu NetworkManager:   (wlan0): supplicant connection state:  scanning -> associating
May 19 19:34:13 ubuntu kernel: [  710.513600] ==>rt_ioctl_siwfreq::SIOCSIWFREQ[cmd=0x8b04] (Channel=1)
May 19 19:34:13 ubuntu wpa_supplicant[3187]: Association request to the driver failed
May 19 19:34:18 ubuntu NetworkManager:   Activation (wlan0/wireless): association took too long.
May 19 19:34:18 ubuntu NetworkManager:   (wlan0): device state change: 5 -> 6 (reason 0)
May 19 19:34:18 ubuntu NetworkManager:   Activation (wlan0/wireless): asking for new secrets
May 19 19:34:18 ubuntu NetworkManager:   (wlan0): supplicant connection state:  associating -> disconnected
May 19 19:34:18 ubuntu wpa_supplicant[3187]: Authentication with 00:00:00:00:00:00 timed out.
May 19 19:34:33 ubuntu NetworkManager:   wlan0: link timed out.

Le matos est le suivant (lspci -vv) :

01:00.0 Network controller: RaLink RT2860
	Subsystem: RaLink Device 2790
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
	Kernel driver in use: rt2860
	Kernel modules: rt2860sta

Solutions

Tout est très bien décrit ici : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/496093.

Noyau 2.6.33

Pas encore dispo dans Lucid Lynx, mais apparement il règle le problème. A suivre avec les updates de la distribution.

Ancien noyau

Coup de bol, j’ai l’ancien noyau toujours dispo (2.6.31-21) depuis l’upgrade (il n’a supprimé que les vraiment anciens). Avec lui tout marche. Je peux le garder par défaut en attendant que le 2.6.33 fasse partie de Lucid Lynx, s’il en fera partie un jour (probable).
Pour l’instant, je m’en sers pour pouvoir quand même downloader ce qu’il faut pour appliquer l’une des méthodes ci-dessous

Backport du driver dans un 2.6.32 spécifique

La méthode qui consiste à utiliser un backup 2.6.32 fait par un gentil monsieur est elle-même déconseillée par le gentil monsieur. C’est pourtant simple sur le papier : tu récupères le paquet, tu l’installes, tu rebootes.
Je suis son conseil, finalement, et j’opte pour la solution où on recompile le driver, malgré des désavantages. Voir ci-dessous.
Sinon, c’est le commentaire 80 qu’il faut lire.

Recompilation du bon driver

Commentaire 107 sur le post mentionné précédemment
Le désavantage, c’est que si demain Ubuntu met à jour le 2.6.32-22 en -23, il faudra recommencer la manip’.
Je décris cette méthode car apparement le bug réapparait régulièrement depuis Ubuntu “Intrepid Ibex”, donc certains liens sont devenus obsolètes. Ca vous évitera de vous taper les 4 pages de remarques de tout le monde.
Ce qui compte, c’est qu’à-la-fin-ça-marche.

Installation des outils minimums de compilation de kernel

sudo aptitude install linux-headers-`uname -r` build-essential

Récupération du driver chez le fabricant

Partez de là (site principal => Software => Linux). Et vous sélectionnez cette ligne là : “RT2860PCI/mPCI/CB/PCIe(RT2760/RT2790/RT2860/RT2890)”.
En direct, tant qu’ils ne refondent pas tout leur site, ça donne ce fichier.

Compilation et installation du machin

Décompressez (tar -xvjf 2010_01_29_RT2860_Linux_STA_v2.3.0.0.tar.bz2) et allez modifier dans les sources le fichier 2010_01_29_RT2860_Linux_STA_v2.3.0.0/os/linux/config.mk.
Vous reperez et mettez “y” (yes) aux lignes suivantes :

HAS_WPA_SUPPLICANT=y
HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y

Ensuite, vous passez root. Non, “sudo ma_commande” ne revient pas au même dans le cas présent, dixit l’auteur.
Donc :

sudo su
cd 2010_01_29_RT2860_Linux_STA_v2.3.0.0
make && make_install

Ca mouline 10 minutes (c’est lent un eeePC ).
Et on le charge :

modprobe rt2860sta

Enfin, si tout marche, vous ajouterez la ligne :

rt2860sta

dans le fichier /etc/modules pour que ça tienne après reboot.

Conclusion

Linux et le wifi, ça a toujours été le bordel.
Maintenant, j’ai opté pour une méthode simple : avant d’upgrader Ubuntu, je télécharge l’ISO, je crée une clef USB Bootable Live Persistante avec ce merveilleux outil, je boote, je teste tout. Ensuite si ça passe, alors je migre. Sinon j’attends, ou j’aide à débugger si j’ai que ça à foutre.

Update de dernière minute : rien à faire, il chargeait tout le temps l’ancien driver rt2860sta de /lib/modules/le_bon_kernel. J’ai fini par écraser l’ancien avec le nouveau. Ils sont dans 2 arborescences différentes. Je ne l’ai plus sous la main, mais tentez un find /lib/modules/ -name "rt2860sta.ko" -exec ls -l {} \; pour voir, compte-tenu de la date, lequel est lequel. Tambouillez un coup et hop, votre driver marche enfin. Au forceps.