Holidays (IT)checklist


Well, it’s that time of the year again, next week I’ll be flying to my beloved Ibiza.

Being an Internet/IT junkie, I don’t exactly “disconnect”; actually I like to read / dig / test some new topics while on holidays (and while I’m not at the beach / clubbing / sunbathing). So every year I go through a particular “checklist” in order to be sure I can connect to the Internet no matter what, here’s the list as of now:

  • A dual-Atheros-based OpenWrt access point
  • Serial cable in case of AP bricking ;)
  • A power strip
  • One directionnal antenna
  • One omnidirectonnal antenna
  • A 10m ethernet cable
  • SDcard USB adapter
  • A UNIX based laptop
  • OpenVPN
  • aircrack-ng (you know, for… things)
  • wireshark
  • tshark
  • ettercap
  • metasploit (for research purposes only)
  • OpenSSH public key deployed on every machine I’d like to ssh to
  • A fallback SSH server with password access (strong one)

Any idea that comes to mind? :)

virt-manager: “nc: unix connect failed”

Tags: , ,
No Comments »

I came across an annoying behaviour while trying to connect to a remote KVM hypervisor from a FreeBSD GUI. virt-manager failed to connect to the server and showed the following error message:

libvirtError: End of file while reading data: nc: unix connect failed: No such file or directory: Input/output error

In short, virt-manager tries to access to /usr/local/var/run/libvirt/libvirt-sock because it is compiled with a /usr/local PREFIX on FreeBSD. Of course they didn’t plan anything on a plain text configuration file. I figured out this has to be configured in GConf, for example using gconf-editor, simply replace:




Other parameters for remote URIs can be found at this address.

FreeBSD 10, KMS and Intel 4500MHD

No Comments »

I recently borrowed a Dell machine at work, model E4300, a nice little laptop whose graphical display is done by a much common Intel 4500MHD. While the card worked out of the box for a classical 2D display with a fresh FreeBSD 10.0 install, I noticed that DRM/DRI (in short, 3D) wasn’t available; I knew it was somewhat related to the new KMS/GEM infrastructure, so I began a few searches and found those useful resources:

Those pages gave bits and pieces of information, but stack a lot of useless complex information for the newcomer. Actually, setting up KMS on FreeBSD 10 is pretty simple. Olivier and farfa gave me the right link: a post on the FreeBSD announce mailing list which explains that there’s an alternative repository for what they call “NEW_XORG”, aka Xorg 1.12.4 with KMS. Simply create a new pkg configuration file in /usr/local/etc/pkg/repos/FreeBSD_new_xorg.conf (create the directory if it does not exist), it must contain the following:

FreeBSD_new_xorg: {
   url: "pkg+${ABI}/new_xorg",
   mirror_type: "srv",
   signature_type: "fingerprints",
   fingerprints: "/usr/share/keys/pkg",
   enabled: yes

Then run:

# pkg update -f
# pkg upgrade

You should be asked whether or not you want to upgrade a couple of packages, and among them, some Xorg-related packages.

There was one glitch on this process, xf86-input-keyboard and xf86-input-mouse actually have the same version in the standard pkg repository and the WITH_NEW_XORG repository, so it is mandatory to delete them using:

# pkg delete -f xf86-input-mouse xf86-input-keyboard

Then add:


to /etc/make.conf, ensure your ports tree is up to date by running:

# portsnap fetch update

and rebuild xf86-input-keyboard and xf86-input-mouse with portmaster:

# portmaster x11-drivers/xf86-input-mouse x11-drivers/xf86-input-keyboard

If you don’t do this, Xorg will start but its log will explain the mouse and keyboard driver ABI mistmatches Xorg current version.

Restart Xorg, and enjoy your GLX-enabled environment :)

Back to 2000-2005: FreeBSD desktop

Tags: , ,

A while ago, I had my ${DAYWORK} workstation running NetBSD, and honestly, it did pretty well. Things began to become more painful when there was no more DRI acceleration with the radeon driver, it then did an okay-ish job, but the overall desktop became somewhat laggy.
It was told someone was working on porting KMS/GEM, that was more than a year ago, and as of today, that work -and I guess it is not an easy one- isn’t mature enough to be used as a workstation, I need my desktop to run various tools, and not only terminal-based ones.
Two weeks ago, I asked for a new desktop, more powerful, so I can run more virtual machines with it. That new box was shipped with an nvidia graphic card and various modern components which I knew were not supported by NetBSD. This is one regret I have about that beautiful project, running on VAX, PlayStation 2 and Amiga is fun, but I’ll tell you a little secret: nobody cares anymore about VAX, PlayStation 2 and Amiga.
So I gave FreeBSD 10 a try. And I was not disappointed: everything, and I mean everything worked almost out-of-the-box. Of course there was a bit of fighting with the proprietary nvidia driver, but it worked as expected with 3D acceleration and all.
Not everything is perfect either, but I must say FreeBSD does a great job as a workstation, actually, it does what I needed: display a decent 2014 hardware powered desktop, no more, no less.
Under no circumstances will I replace my NetBSD servers / virtual machines (as long as they still support the underlying hardware!), they do an amazing job and I am quite happy with them, but don’t expect desktop-related commits from me to pkgsrc for the time being…


Well well, this blogpost have bring much unexpected rage. Just to clarify: this is definitely not a troll or whatsoever, only an end user opinion on what’s preventing me of using NetBSD as a desktop at work for the moment.
Read the previous sentence a couple of times and notice the word “work”, the place where you can’t spend countless hours patching / tuning / trying / crashing / rebooting (sounds like a Daft Punk song) before you can reply to an urgent customer inquiry. Yes, that place. The only thing I say is: FreeBSD, as of today, does a better job at being an out-of-the-box modern desktop.
I will continue to use NetBSD as my server OS of choice, because it does rock, because it is stable, simple and fills the task perfectly. As soon as it doesn’t anymore, I’ll switch to something else, that’s what I do. Pragmatic.
So yes, I have the weakness to like shiny desktops that run something else than twm, I like transparency, I like effects when I change my virtual desktop, I like my windows to be displayed and moved rapidly, you know, pretty much like all those BSD developers that actually use OSX because it does all those things.
I will also continue contributing to pkgsrc, because it is in my optinion the most beautifull packaging system around, all I’m saying is that I won’t commit desktop-related tools I can’t really test or use. Nothing more.

Plus qu’un blog post


Ok, je vous l’accorde je poste pas des masses. MAIS ! je n’écris pas moins. Et je le prouve.
J’écris depuis plusieurs années pour le vénérable GNU/Linux Magazine France, ces articles, je les propose sous licence Creative Commons BY-NC-ND, cela signifie que 4 mois après leur parution dans le magazine, moyennant une rémunération moins importante par article, ces derniers sont publiquement et gratuitement disponibles en ligne.
Comme je ne suis pas certain d’avoir exhaustivement listé les articles disponibles ici, voici les liens directs vers les articles récents, et n’hésitez pas à vous perdre dans les milliers d’autres contributions !

D’autres sont en attente de publication, comme par exemple la serie sur Salt et Flask, stay tuned.

Bypass neufbox 6 avec NetBSD

Tags: , , , , ,

Comme je l’expliquais dans le post précédent, je suis passé chez SFR/neuf avec un forfait fibre. La box de l’opérateur, la neufbox donc, ne supportant pas de mode bridgé, quelques opérations sont nécessaires à une intégration cohérente dans votre réseau domestique.

Je me suis grandement inspiré de cette excellente documentation pour réaliser le bypass de la neufbox, cependant plusieurs éléments du tutoriel ne sont plus d’actualité. Je ne rentrerai donc pas dans le détail théorique puisque l’article de est parfaitement explicite, mais focaliserai sur les méthodes à mettre en œuvre pour faire rentrer votre neufbox dans votre réseau local.

Première chose, donner du lien à la nb6. Ceci est très simplement réalisé par un serveur DHCP, ISC DHCP dans mon cas, présent dans pkgsrc/net/isc-dhcpd. J’ai isolé la neufbox dans un VLAN dedié, untagged coté équipement, tagged sur mon switch. Cette opération n’est absolument pas nécessaire, mais j’aimais assez l’idée d’isoler l’équipement de l’opérateur. Après avoir ajouté le vlan dans la liste des interfaces gêrées par le serveur DHCP dans /etc/rc.conf:

isc_dhcpd_flags="vlan2 vlan3 vlan9"

On ajoute un subnet dédié :

subnet netmask {
        default-lease-time 3600;
        max-lease-time 3600;

        option routers;
        option domain-name-servers;
        # needed for sfr neufbox
        option nis-domain "ftth_axione_omniswitch";
        allow unknown-clients;

Et dans la foulée, on s’assure que la box aura toujours la même IP dans ce range :

host neufbox {
        hardware ethernet 34:85:14:85:52:27; # cette MAC est évidemment fausse

Une fois le port “fibre” (gris) de la box branché à votre switch, un redémarrage plus loin, les 3 leds vertes en façade devraient être allumées.

Si vous souhaitez accéder à l’interface de la neufbox, sachez qu’elle est accessible depuis le switch intégré (ports bleus) sur l’adresse IP Ceci est modifiable via le lien (ce lien n’est pas présent dans le menu).

L’aspect moins simple de l’opération concerne la VoIP. Je vous renvoie à la section “réseau local” de l’article précedemment cité pour comprendre le pourquoi de ce qui suit, mais pour faire court, la box ne disposant pas de son IP publique SFR, il faut intercepter son traffic sortant vers l’infrastructure de l’opérateur, et modifier le contenu des requêtes envoyées afin d’y inclure notre IP publique.

J’ai réalisé ce tour de passe-passe sous NetBSD, à l’aide de pf et nginx. On redirige tout d’abord le traffic HTTP en provenance de la neufbox sur un port spécifique de l’interface loopback :

# [...]
rdr pass on $neufbox_if proto tcp from to any port 80 -> \ port 89

Puis dans le fichier de configuration nginx, on ajoute un nouveau serveur muni d’une location / :

    server {
        server_name foo *;

        access_log  /var/log/nginx/neufbox.access.log;
        error_log  /var/log/nginx/neufbox.error.log;


        location / {
                if ($args ~ "^ip_data=[^&]*&ip_voip=[^&]*&ip_tv=[^&]*&(.*)$") {
                        set $others $1;
                        set $nip "ip.publique.neuf"; # a modifier avec votre IP
                        rewrite /(.*) /$1?ip_data=$nip&ip_voip=$nip&ip_tv=$nip&$others? break;
                proxy_redirect off;
                proxy_pass http://$host;

Merci à Adrien ze pour le coup de main sur la réécriture. En effet, alors que je bataillais sur le mécanisme de rewrite, ze a découvert que cette méthode de nginx ignore purement et simplement les arguments d’une URI, d’où la nécessité de passer par un ifqui match l’URL à modifier.

Un reboot de la neufbox et un tcpdump -A -ni bien placé devraient vous démontrer que la box est désormais capable de télécharger une foule d’informations la concernant, de mettre à jour son firmware et surtout, de s’informer sur les mécanismes SIP en place chez l’opérateur.

La box étant derrière un routeur et accédant à l’Internet à travers du NAT, il est utopique d’imaginer que la voix passera sans sourciller. Car si en effet la signalisation (SIP, donc) passe sans broncher (voyant allumé), si vous tentez de passer un coup de fil, vous ne recevrez ni tonalité, ni son, pas plus que vous n’en emmétrez, simplement parce que le RTP ne parvient pas jusqu’à la box.

Pour résoudre ce casse tête, plusieurs actions sont nécessaires. En premier lieu, l’installation de l’excellent serveur proxy SIP/RTP siproxd, disponible dans la plupart des systèmes de paquets. Sous NetBSD, il est présent dans pkgsrc-wip. Bon en fait il était pété, je l’ai réparé, je suis sur le point de le commit.
La configuration du logiciel est assez simple :

if_inbound  = vlan9 # interface neufbox
if_outbound = vlan8 # interface publique
sip_listen_port = 5060
daemonize = 1
user = nobody
rtp_port_low  = 7070
rtp_port_high = 7089
outbound_proxy_host =
outbound_proxy_port = 5060

Afin d’autoriser le traffic RTP vers notre proxy sur les ports allant de 7070 à 7089, nous ajoutons à notre pf.conf :

# RTP / siproxd
pass in quick on $ext_if proto udp from any to any port 7069 <> 7090

L’adresse du proxy SIP est fournie par la réponse à l’une des requêtes HTTP effectuées par la neufbox à son démarrage. Et justement, c’est cette adresse qu’il va nous falloir modifier pour que la neufbox interroge notre serveur siproxd plutot que ceux de SFR directement.

Dans de précédentes versions des neufbox, il suffisait de remplacer l’adresse du proxy SIP par celle désirée, mais la normalisation et plusieurs protocoles sont passés par là. Ainsi la box ne se contente-t-elle pas uniquement d’interroger un simple serveur SIP passé en argument mais réalise plutôt une requête DNS de type SRV à la recherche d’une entrée _sip._udp dans le sous domaine passé en paramètre. Cela se traduit par les lignes suivantes dans la zone DNS qui régit le réseau domestique :

$ORIGIN sip.mon.domaine.local.
@                       A
_sip._udp               SRV     10 1 5060       sip.mon.domaine.local. est l’IP sur laquelle écoute le service siproxd.

On y est presque.

Il nous reste à modifier le contenu des informations renvoyées par l’infrastructure SFR afin de remplacer les entrées relatives au proxy sip par notre propre proxy. Ceci est à nouveau réalisé par le biais de nginx et en particulier du module sub_filter. Notez qu’il est possible que votre installation de nginx ne possède pas ce module par défaut, auquel cas il faudra recompiler ce dernier avec le flag --with-http_sub_module (oui je vais l’ajouter dans pkgsrc/www/nginx :). On modifie la configuration précédemment enregistrée :

        location / {
                if ($args ~ "^ip_data=[^&]*&ip_voip=[^&]*&ip_tv=[^&]*&(.*)$") {
                        set $others $1;
                        set $nip "";
                        rewrite /(.*) /$1?ip_data=$nip&ip_voip=$nip&ip_tv=$nip&$others? break;
                proxy_redirect off;
                proxy_pass http://$host;
                sub_filter</proxy> sip.mon.domaine.local</proxy>;
                sub_filter_once off;
                sub_filter_types application/xml;

Une fois de plus, on redémarre notre pauvre neufbox dont elle doit se demander ce qu’elle a bien pu faire dans une vie antérieure pour mériter ça… and voila !

Notez que les logs de siproxd affichaient un “can’t resolve “ qui est le realm utilisé pour l’authentification SIP, et que j’ai donc ajouté à mon /etc/hosts l’entrée suivante :

car c’est l’adresse qui semblait être appelée par la neufbox en mode “direct”, mais je n’ai aucune certitude quand à l’exactitude de ce mapping. Le realm ne devrait de toutes façons être d’aucune utilité au proxy local, l’ajout statique de cette entrée n’a donc probablement d’intérêt que de m’éviter des Gigaoctets de logs.

Update Nicolas Sapa m’informe sur Twitter qu’il est parfaitement normal que l’adresse 3gpp ne soit pas resolue hors du GPRS roaming exchange, aussi serait-il probablement plus judicieux de la faire résoudre sur une adresse locale quelconque.

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from
Entries RSS Comments RSS Log in
Optimization WordPress Plugins & Solutions by W3 EDGE