Sous les étoiles... - Tag - linux

How to make Skype work with PulseAudio on 64 bits Linux systems

Schnouki — Sat, 16 Aug 2008 02:45:00 +0200

Some people like to hurt themselves: their computers run Linux, they have a 64 bits system, they use PulseAudio to have more fun with their sound cards, and they use Skype to call their geeky friends.

That's what I do. My laptop has an Athlon64 CPU, runs ArchLinux, and I'm a PulseAudio addict (exporting display and sound through the network when connecting to my remote PC with SSH is just awesome). And since my girlfriend will soon go and spend one semester in a university in Sweden, I need to have Skype working so I can call her without ruining myself. ^[1]

The problem is that the Linux version of Skype is designed to use Alsa only. This shouldn't be a problem since there is an Alsa plugin to use PulseAudio as a backend: with this library (in its 32 bits version), everything should work properly. Except...

Except that Skype developers are some kind of morons who didn't realize that everybody isn't using the very same system as them. You can't change the directory where Skype will look for the Alsa libs: it will search for them in /usr/lib/alsa-lib and that's all. No chance to change it using the environment variable ALSA_LIBS. And therefore this 32 bits executable tries to load the 64 bits libraries in /usr/lib/alsa-lib instead of the nice 32 bits libraries in /opt/lib32/usr/lib/alsa-lib.

One solution to this problem would be to set up a 32 bits chroot and launch Skype from there. But this is quite complicated for the end-user ^[2] and it isn't really comfortable to chroot and then to launch Skype (what if I want it to start when I log on KDE?).

Another solution would be to disassemble the executable, change the hard-coded path, and assemble it again. Hehe, just kidding, I'm not a great SM fan

A last solution is to do some clever hacking including library preloading. This is, of course, the solution I have chosen.

Library preloading allows one to "replace" any libc function with your own one, without having to recompile the entire libc (glibc is just huge). It works by loading the libraries specified in the environment variable LD_PRELOAD against an app before loading any other libraries (such as the ones you can see when running ldd my_app), and it can therefore replace just any system call. Since it uses a simple environment variable, you can use it to modify a single app too: just run it with LD_PRELOAD=./mylib.so myapp and you're done!

This is interesting in our case because Skype use the standard dlopen() system call to load the Alsa libraries. When it tries to open the 64 bit libraries, you can see on the console the following messages:

/*
Copyright (c) 2008, Schnouki <schnouki _at_ schnouki _dot_ net>
 
Permission to use, copy, modify, and/or distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.
 
THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/
 
#include <string>
#include <iostream>
#include <dlfcn.h>
 
// Thanks to Stephen Done!
// http://sources.redhat.com/ml/libc-alpha/2001-05/msg00321.html
 
#if defined(RTLD_NEXT)
#define REAL_LIBC RTLD_NEXT
#else
#define REAL_LIBC ((void *) -1L)
#endif
 
void* dlopen(const char *file, int mode)
{
	// Pointer to the original dlopen()
	static void* (*o_dlopen) (const char *file, int mode) = NULL;
 
	// string-ified file name
	std::string filename = file;
 
	// Get the original dlopen()
	if (o_dlopen == NULL) {
		o_dlopen = (void*(*)(const char *file, int mode)) dlsym(REAL_LIBC, "dlopen");
		if (o_dlopen == NULL) {
			std::cerr << "libskypepulse: can't get a pointer to the original dlopen()" << std::endl;
			return NULL;
		}
	}
 
	// Do we need to do something?
	if (filename.find("/usr/lib/alsa-lib/") == 0) {
		filename = "/opt/lib32" + filename;
		return o_dlopen(filename.c_str(), mode);
	}
	else {
		return o_dlopen(file, mode);
	}
}

So, if we just "patch" dlopen() so that Skype loads the libs in /opt/lib32/usr/lib/alsa-lib instead of the ones in /usr/lib/alsa-lib, it should be able to load the libs properly and then to use PulseAudio. Well, let's do it!

The code is actually pretty simple. We get a pointer to the "original" dlopen() from glibc and we test if the provided file name begins with /usr/lib/alsa-lib. If so we add /opt/lib32 at the beginning of this path, otherwise we don't touch it. And then we call the "original" dlopen() with this new file name.

This code was inspired by a piece of code I found thanks to Google; many thanks to its original author. I just adapted it to this situation and moved to C++ because I didn't want to do nasty char* hacks when the class string is so easy to use.

To use it: in a 32 bits environment ^[3], run g++ -fPIC -shared -o libskypepulse.so libskypepulse.cpp. Then run Skype with the following command: LD_PRELOAD=./libskypepulse.so skype. Open pavucontrol and test Skype (for example calling the Echo test): Skype should appear in the playback streams list. If it does, congratulations! your Skype is now PulseAudio-ready; if it doesn't, check the messages in the console and only blame yourself

If you don't have access to a 32 bits environment or if you don't want to compile it yourself, my compiled library (as well as its source code) is available (included at the end of this post). I also made a little launcher (don't forget to adjust the library path), and ArchLinux users may use the package I put on the AUR (bin32-skype-pulse) which will install everything (all the needed 32 bits libraries) properly ^[4].

After you installed this library, you should modify your PulseAudio config: in /etc/pulseaudio/daemon.conf, add the following lines:

; For Skype, thanks to http://ubuntuforums.org/showthread.php?t=789578&highlight=skype+Pulse
default-fragments = 8
default-fragment-size-msec = 5

This will improve the sound quality quite dramatically.

Voilà, that's enough for now. Please leave a comment if this post helped you or if you had any problem with the library

Notes

[1] I know we could use Ekiga or any other SIP clients, but I don't want to deal with messy SIP configurations, NAT traversal, settings on both Windows and Linux, etc., when Skype is so easy to set up...

[2] Yeah, I care about others

[3] A 32 bits chroot or another computer...

[4] And to install packages from AUR, yaourt is your friend!

X11 et sudo

Schnouki — Mon, 09 Apr 2007 11:46:00 +0200

Quand on est fan de sudo, c'est parfois assez pénible de ne pas pouvoir lancer d'application graphique avec. Il existe pourtant une solution simple pour y remédier.

Le problème de sudo est que, dans sa configuration « classique », il ne conserve pas les variables d'environnement nécessaires au bon fonctionnement des applications X11 lors du changement d'utilisateur. Pour y remédier, il y a deux solutions :

utiliser sux (disponible dans Portage : x11-misc/sux), un petit programme qui fonctionne comme su, mais en transférant les données nécessaires. Ça marche, mais ça ouvre un shell (ce dont on n'a pas toujours envie) et ça demande toujours un mot de passe root (il n'est évidemment pas possible de l'utiliser avec sudo...). Et il semble poser des problèmes pour afficher les caractères UTF-8, ce qui est plutôt gênant.
bien configurer sudo : c'est possible, et heureusement pour les fans d'Ubuntu ^[1]

On va donc modifier le fichier /etc/sudoers. Évidemment, il n'est pas question de le modifier « à la main » : pour des raisons de sécurité, mieux vaut utiliser visudo.

Une fois l'éditeur de texte lancé, il faut spécifier quelles variables il faut transférer et pour quels utilisateurs. Ces variables, ce sont $DISPLAY et $XAUTHORITY. Pour les utilisateurs, dans mon cas il s'agit du groupe wheel ; certains préféreront spécifier des utilisateurs séparément : c'est leur choix

Voilà donc les lignes que j'ai dû ajouter à mon fichier sudoers :

# Faire marcher X11 avec sudo
Defaults:%wheel env_reset
Defaults:%wheel env_keep += DISPLAY
Defaults:%wheel env_keep += XAUTHORITY

Chez certaines personnes, il semble qu'il est nécessaire de se déconnecter entièrement (jusqu'à redémarrer le serveur X) pour que la modification prenne effet ; chez moi ce n'a pas été le cas, j'ai juste eu besoin de quitter visudo

Il suffit ensuite de tester si ça marche, par exemple avec sudo gedit /etc/make.conf.

Un grand merci à Thomas Wisniewski pour l'info.

Notes

[1] eh oui, les docs d'Ubuntu utilisent abondamment les sudo avec des logiciels comme gedit... Preuve que c'est possible !

La Fonera : réseau privé en WPA et Linux

Schnouki — Mon, 19 Feb 2007 10:20:00 +0100

Dans ses réglages d'usine, le routeur La Fonera propose un réseau privé avec cryptage WPA dont le SSID est MyPlace. La clef de cryptage est basée sur le numéro de série indiqué sur l'étiquette en-dessous du routeur :

Nous allons voir comment configurer son ordinateur sous Linux (de préférence Gentoo, bien sûr ;-)) pour pouvoir accéder à Internet en passant par ce réseau.

Configuration du système

Installation de wpa_supplicant

wpa_supplicant est le programme qui permet de gérer le WPA sous Linux. Il permet aussi de gérer les connexion WEP ou même sans cryptage, d'ailleurs... C'est un outil très puissant mais assez complexe à configurer ; pour le moment nous allons nous contenter de l'installer.

Sous Gentoo, un simple emerge wpa_supplicant suffit.

Si vous avez une carte utilisant le driver madwifi, il faut ajouter le useflag correspondant : echo net-wireless/wpa_supplicant madwifi >> /etc/portage/package.use, puis un emerge wpa_supplicant devrait suffire.

Configuration des interfaces réseau

Une fois que wpa_supplicant est installé, il faut indiquer à Gentoo de l'utiliser. Pour cela, modifiez avec votre éditeur de texte préféré le fichier /etc/conf.d/net et ajoutez-y les lignes suivantes :

modules=( "wpa_supplicant" )
wpa_supplicant_wlan0="-Dwext -iwlan0"
wpa_timeout_wlan0=10
config_wlan0=( "dhcp" )

Il y aura éventuellement quelques détails à modifier selon votre configuration :

selon le driver, il faudra peut-être remplacer wext par autre chose (madwifi, atmel, ipw, broadcom...). Normalement wext est le nom générique et devrait fonctionner avec à peu près tout ; si ce n'est pas le cas, consultez la documentation : man wpa_supplicant. Petit détail cependant : même si vous utiliser un pilote ndiswrapper, laissez -Dwext ; l'option -Dndiswrapper est obsolète et ne fonctionne plus.
selon le nom de votre interface réseau : chez moi c'est wlan0, chez vous c'est peut-être eth1 ou ath0... Si c'est le cas pensez à le changer.

Sauvegardez ensuite ce fichier et relancez votre interface réseau avec /etc/init.d/net.wlan0 restart.

Configuration de wpa_supplicant

Il faut maintenant configurer wpa_supplicant lui-même. La tâche peut parfois être assez ardue, alors on va y aller doucement.

Configuration de base

Le fichier de configuration de wpa_supplicant est /etc/wpa_supplicant/wpa_supplicant.conf. Lancez votre éditeur de texte préféré et ouvrez-le.

Il faut commencer par la configuration générale, celle qui est commune à tous les réseaux que vous allez utiliser avec wpa_supplicant. C'est en fait la partie la plus simple

Chez moi, ça donne ça :

# Nécessaire pour pouvoir utiliser des interfaces comme wpa_gui ou wpa_cli
ctrl_interface=/var/run/wpa_supplicant
# ...pour autoriser les utilisateurs dans le groupe wheel à les utiliser
ctrl_interface_group=wheel
# Autoriser les interfaces à modifier le fichier de configuration
#update_config=1
# Mode de connexion au point d'accès
ap_scan=2
# Réauthentification rapide pour le mode EAP
# (commentée car ne marche pas à Supélec...)
#fast_reauth=1

Si vous avez besoin de documentation plus précise, vous en trouverez dans le dossier /usr/share/doc/wpa_supplicant-0.5.7.

Calcul de la clef PSK

La Fonera utilise un cryptage WPA avec une clef de type PSK (Pre-Shared Key). Cette clef de 256 bits est calculée à partir d'un mot de passe (passphrase pour être exact) et du SSID du réseau ; ainsi, deux SSID ayant le même mot de passe n'auront pas la même clef PSK.

Pour calculer cette clef PSK, on va utiliser un outil fourni avec wpa_supplicant et qui s'appelle wpa_passphrase. Son utilisation est simplissime : wpa_passphrase <SSID> <mot de passe>

En supposant que le mot de passe (indiqué en-dessous de la Fonera je vous le rappelle) est 123456789 pour le SSID MyPlace, cela nous donne :

$ wpa_passphrase MyPlace 123456789
network={
        ssid="MyPlace"
        #psk="123456789"
        psk=2af518af5ce090638477fcb1623cf9b32fdf56151b612fcd879518d193b6cc14
}

Notez la ligne en "psk=2af..." quelque part (vive les copier/coller...), elle nous servira bientôt.

Configuration du réseau

On va ensuite ajouter un bloc qui décrit le réseau auquel on veut se connecter.

network={
        ssid="MyPlace"
        proto=WPA
        key_mgmt=WPA-PSK
        pairwise=TKIP
        psk=2af518af5ce090638477fcb1623cf9b32fdf56151b612fcd879518d193b6cc14
        priority=1
}

En gros, là-dedans, on indique à wpa_supplicant le SSID (MyPlace), le protocole (WPA, c'est-à-dire WPA version 1 et non pas WPA2 qui ne marche pas chez moi...), le type de clef (WPA-PSK), la méthode de cryptage (TKIP et non pas CCMP ou AES), et la clef PSK calculée précédemment.

Si on veut en plus pouvoir se connecter à son SSID public, on peut ajouter le bloc suivant :

network={
        ssid="FON_AP"
        key_mgmt=NONE
        priority=2
}

Ici aucun cryptage donc aucun problème.

Si vous avez un autre réseau qui utilise un cryptage WEP, voici la manière de le configurer :

network={
        ssid="MonWifiPerso"
        key_mgmt=NONE
        # wep_key_0 pour la clef n°1, wep_key_3 pour la clef n°4...
        wep_key0="Ma clef WEP"
        priority=3
}

Si vous cherchez d'autres exemples, il y en a beaucoup dans /usr/share/doc/wpa_supplicant-0.5.7/wpa_supplicant.conf.gz ; n'hésitez pas à y jeter un œil, c'est très instructif.

Test de connexion

Sauvegardez le fichier et quittez votre éditeur de texte. Il va d'abord falloir indiquer à wpa_supplicant de recharger son fichier de configuration. Deux solutions :

la méthode barbare : /etc/init.d/net.wlan0 restart, pas pratique si c'est la seule interface réseau et qu'on a d'autres services qui dépendent du réseau
la méthode propre : on lance wpa_cli, on tape reconfigure et Entrée, puis on quitte avec Ctrl+C.

Le moyen le plus simple de suivre ce qui se passe ensuite est d'utiliser l'interface graphique : lancez wpa_gui. Dans le menu Network choisissez MyPlace et attendez... Après que Status indique COMPLETED, il faut encore attendre que l'ordinateur ait reçu une adresse IP du serveur DHCP. Une fois que c'est bon... tout devrait être bon

Si quelque chose ne va pas, ouvrez un wpa_cli en même temps que wpa_gui et notez les messages qui s'affichent, ils vous aideront peut-être à comprendre où est le problème.

Pour finir...

Voilà voilà, j'espère que vous n'aurez pas eu trop de mal à me lire, je débute un peu dans l'écriture de tutoriels

Si vous avez un problème, une question, un compliment (sait-on jamais... ), n'hésitez pas à me laisser un commentaire

Hey hi, hey ho, me voilà Fonero...

Schnouki — Mon, 19 Feb 2007 03:13:00 +0100

Il y a quelques temps, j'avais appris par je-ne-sais-plus-quel-site ^[1] que suite à un article dans le quotidien gratuit 20 Minutes (que j'aimais bien lire à Strasbourg...), il y avait une offre spéciale qui permettait de commander gratuitement un routeur Wifi La Fonera, et ainsi de participer activement à la communauté FON.

FON, c'est un objectif ambitieux avec un principe simple : construire le plus grand réseau Wifi au monde en utilisant le partage. Concrètement, chaque membre de FON (chaque Fonero dans le jargon approprié) a le choix :

s'il ne partage pas sa connexion : c'est un Alien, il paye pour se connecter aux points d'accès FON répartis à travers le monde... Mais à 3 € de l'heure, c'est bien moins cher que les autres hotspots existants.
s'il partage sa connexion contre rétribution : c'est un Bill, il paye aussi pour se connecter sur les hotspots FON mais il touche 50% de ce que payent les Aliens ou les autres Bills pour se connecter sur son propre hotspot.
s'il partage sa connexion gratuitement : c'est un Linus, il peut se connecter gratuitement à tous les hotspots FON du monde, mais ne touche rien sur ce que payent les Aliens et les Bills sur son hostpot.

Le principe est relativement simple et paraît assez utopiste... Et pourtant ça marche. Lancé il y a quelques années en Espagne, FON compte maintenant des dizaines de milliers de membres à travers l'Europe, et plusieurs milliers aux États-Unis en à peine quelques semaines...

Au départ, pour faciliter la mise en place d'un partage, FON proposait un firmware pour les routeurs Linksys, mais depuis 2006 il existe un petit routeur dédié appelé La Fonera (29,95 € sur le site de FON). Et donc l'offre en partenariat avec 20 Minutes dont je parlais au début de ce billet consistait à offrir 6000 routeurs de ce type aux lecteurs de 20 Minutes.

J'ai réussi à m'inscrire sur le site à temps et à recevoir ma Fonera gratuitement. J'ai passé une bonne partie de l'après-midi à m'amuser avec, et c'est franchement sympa : le routeur crée deux cellules Wifi, une publique (celle qu'on partage) et une autre privée (avec cryptage WPA...) ; il fonctionne sous Linux et, après une petite manip' pour activer ssh dessus, on peut en faire tout ce qu'on veut ; et en plus le routeur est d'une taille minuscule (bientôt des photos... peut-être, en attendant y'en a déjà sur Flickr).

Et voilà, maintenant je partage ma connexion, je suis un Fonero, un Linus bien évidemment... Vivement que j'aie l'occasion de tester la connexion sur un autre FONspot

Notes

[1] vive la précision...