Installing Samsung ML-2950 series printer drivers on FreeBSD

I've just replaced my inkjet printer with a laser one (Samsung ML-2955ND: Netword and Duplex).
Samsung provide drivers for lot's of OS (HP-UX, IBM AIX, GNU/Linux, MacOSX, etc…) but nothing for FreeBSD :-(

Hopefully the GNU/Linux drivers is CUPS based and use standard PPD file… But with a binary only cups-filter.
I didn't know if it was possible to use the Linux emulation layer of FreeBSD for using this cups-filter, but a previous experience was successful, then I try it too.


The major idea is to:

1. Install print/cups
2. Enable and install the FreeBSD Linux binary compatibility
3. Getting the Samsung Unified drivers for the ML-2950 series
4. Extracting the PPD file and the i386 binary cups-filter used by the PPD
5. Fixing the missing dependency needed by the samsung cups-filter

I will not explain the steps 1,2 and 3.

Extract the Unified Linux Drivers:
$ tar zxvf UnifiedLinuxDriver_0.92.tar.gz

Then check the filter used by the PPD file:

$ grep cupsFilter cdroot/Linux/noarch/at_opt/share/ppd/ML-2950spl2.ppd 
*cupsFilter:  "application/vnd.cups-postscript 0 rastertosamsungspl"

=> This PPD file use the "rastertosamsungspl" filter.

Now copy the PPD and the Samsung cups-filter to the local cups directories:
$ mkdir /usr/local/share/cups/model/samsung
$ cp cdroot/Linux/noarch/at_opt/share/ppd/ML-2950spl2.ppd /usr/local/share/cups/model/samsung/
$ cp cdroot/Linux/i386/at_root/usr/lib/cups/filter/rastertosamsungspl /usr/local/libexec/cups/filter/

Once copied, you can execute rastertosamsungspl from a CLI for displaying the missing Linux libs:

# /usr/local/libexec/cups/filter/rastertosamsungspl 
/usr/local/libexec/cups/filter/rastertosamsungspl: error while loading shared libraries: libcups.so.2: cannot open shared object file: No such file or directory

This method will display missing libs one by one: You need to install the missing libs, running a ldconfig and re-execute rastertosamsungspl for discovering that another libs is missing.

Here is the list of all libs that I've installed:

# cd /tmp
# fetch http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/10/Everything/i386/os/Packages/cups-libs-1.3.9-2.fc10.i386.rpm
# fetch http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/10/Everything/i386/os/Packages/gnutls-2.4.2-2.fc10.i386.rpm
# fetch http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/10/Everything/i386/os/Packages/libtasn1-1.5-1.fc10.i386.rpm
# fetch http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/10/Everything/i386/os/Packages/libgcrypt-1.4.3-2.fc10.i386.rpm
# fetch http://archives.fedoraproject.org/pub/archive/fedora/linux/releases/10/Everything/i386/os/Packages/libgpg-error-1.6-2.i386.rpm
# cd /compat/linux
# rpm2cpio /tmp/cups-libs-1.3.9-2.fc10.i386.rpm | tar -zxf -
# rpm2cpio /tmp/gnutls-2.4.2-2.fc10.i386.rpm | tar -zxf -
# rpm2cpio /tmp/libtasn1-1.5-1.fc10.i386.rpm | tar -zxf -
# rpm2cpio /tmp/libgcrypt-1.4.3-2.fc10.i386.rpm | tar -zxf -
# rpm2cpio /tmp/libgpg-error-1.6-2.i386.rpm | tar -zxf -
# /compat/linux/sbin/ldconfig

Once all dependencies are installed, you should have this message when executing rastertosamsungspl:


# /usr/local/libexec/cups/filter/rastertosamsungspl 
INFO: Usage: rastertosamsungspl job-id user title copies options [file]
ERROR: Wrong number of arguments

Now you can your printer from the CUPS admin panel and use your printer :-)

BSD Router Project: Version 1.0 disponible

Cela faisait plusieurs mois qu'il n'y avait pas eu de nouvelle version de ce routeur libre: C'est corrigé depuis cette nuit.
Et comme j'ai passé pas mal de temps à le tester dans tous les sens, je me suis dit que cette version méritait finallement de passer directement en 1.0.
J'ai par contre découvert une grosse limitation concernant la protection des protocoles de routages IPv6 sous FreeBSD (RIPng et OSPFv3): Ces protocoles n'incluent plus leur propre mécanismes de sécurité mais les délèguent à la couche IPSec d'IPv6. Cela veux dire que nous devons passer par setkey(8) pour configurer des SAD/SPD manuels les protégeant.… Or la couche IPSec de FreeBSD ne sait pas gérer les adresses multicast et l'usage du multicast est très courant en IPv6 (RIPng et OSPFv3 l'utilisent). Cette limitation est assez bloquante car elle ne permet pas d'avoir le même niveau de protection des réseaux RIP/OSPF en IPv6 qu'en IPv4 sous FreeBSD.

J'ai aussi amélioré les scripts VirtualBox (PowerShell et Shell) permettant de lancer les labs virtuels facilement pour qu'ils prennent en charge les fonctionnalités de linked-type-clone et Page Fusion: Le gain en ressource pour la machine hôte est impressionnant!
Par exemple sur le lab BGP route reflector/confederation qui nécessite le lancement de 7 routeurs, donc 7 VMs (avec 128Mo de RAM et 256Mo de disque alloué à chacune):

• La fonctionnalité «linked-type-clone» permet de ne consommer que 153Mo d'espace disque pour l'ensemble des VMs: Le template de référence utilise 80Mo et chacun des clones 10Mo.
• La fonctionnalité «Page Fusion», elle, permet de ne consommer que 112Mo de RAM pour l'ensemble des VMs (environ 16Mo par VM).

Pour la suite, va falloir que je travaille un système de centralisation/gestion des configurations et pourquoi pas permettre le pre-provisionning des configurations pour du déploiement grande échelle.

Pourquoi ne jamais utiliser iperf sur FreeBSD

J'ai enfin eu le temps de remonter mon petit lab pour faire quelques tests de performance réseaux avec BSDRP:

• Un PC Engines wrap1e203, qui va me servir de routeur (Geode à 233Mhz)
• Deux clients léger HP Compaq T5000 (Transmeta Crusoe à 800Mhz)
• Un switch gigabit

L'avantage d'utiliser des vieilles machines FastEthernet est qu'elles sont plus faciles à saturer que des nouvelles supportant le gigabit.
Avant de tester les perfs de routage du WRAP, j'ai commencé par noter ma valeur de référence, en mesurant les perfs réseaux maximum des HP Compaq T5000.
Pour cela il existe plusieurs logiciels, le plus connus étant iperf. Mais sur les différentes mailing-list FreeBSD, j'ai souvent lus que iperf «ça pue car codé par des linuxiens et donc incapable d'utiliser le pleins potentiel de FreeBSD».
Dans le doute, j'ai donc aussi utilisé netblast (les sources sont cachées dans /usr/src/tools/tools/netrate/netblast, et il n'est pas installé par défaut).
D'ailleur concernant netblast sur sparc64: Il faut le patcher pour corriger un problème d'alignement.
Bref, lancons nos tests (en UDP et avec les tailles de paquet au max), et voici les résultats:

• iperf: 60Mbit/s
• netblast : 80Mbit/s

Le verdict est sans appel en faveur de netblast!
Et après avoir activé le polling, j'ai pus monter jusqu’à 92Mbit/s: On arrive presque au 100Mbit/s de leur carte réseaux… Pas mal du tout pour ces petites bêtes.

Backporting Intel PRO/Wireless 6205a FreeBSD 9.0 modules to 8.2

My old professionnal Dell Latitude D630 laptop was replaced by a new Dell Latitude E5420… and this new one have a wireless chipset not supported on FreeBSD 8.2:

[root@laptop]~#dmesg | grep iwn
iwn0: <Intel(R) PRO/Wireless 6205a> mem 0xe5300000-0xe5301fff irq 17 at device 0.0 on pci2
0xe5300000-0xe5301fff irq 17 at device 0.0 on pci2
iwn0: MIMO 2T2R, MoW, address a0:88:b4:7d:40:9c
iwn0: [ITHREAD]
iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
iwn6005fw: could not load firmware image, error 2
iwn0: iwn_read_firmware: could not load firmare image "iwn6005fw"
iwn0: iwn_init_locked: could not read firmware, error 22

But, this new chipset is supported on FreeBSD-current, then I've backported it to 8.2.
I had to do 3 small changes in if_iwn.c file : One function name to revert (pci_find_cap to pci_find_extcap), and remove 2 lines (use of ic_rxstream and ic_txstream).
You can install this drivers like this:

cd /tmp

fetch http://gugus69.free.fr/tools/FreeBSD-8.2-iwn-current.tgz

cd /

tar zxvf /tmp/FreeBSD-8.2-iwn-current.tgz

cd /usr/src

make buildkernel

make installkernel

reboot

I've tested Internet browsing and small files transfert with this drivers without problem.

Creating and starting VirtualBox machine with PowerShell

BSD Router Project provided a VBScript for starting MS Windows based virtualbox lab. But because this vbs script works only on XP, I had to found a more powerful solution: Why not discovering PowerShell and using the VirtualBox COM API ?
I didn't found very detailed examples, then here is a PowerShell script that explains how to create, configure and start a VirtualBox Machine.
The goal is:

1. Create a VM (OS type: FreeBSD_64)
2. Configure it (with a serial port that redirect to a pipe)
3. Convert a unzipped BSDRP-full-amd64-vga disk image file to a VDI file, and attach this VDI to the VM
4. Start the VM

And here are the big steps of this script:

1. Initialize the COM API
2. Create the VM
3. Configure the VM (excluding attaching medium to it)
4. Save and register the VM
5. Convert a RAW file to VDI (using VBoxManage.exe) and registering it
6. Lock the VM in write mode for attaching the medium
7. Launch the VM

Now the PowerShell code sample:

Serveur NFS v4 avec FreeBSD

NFS v4 possède quelques avantages bien sympa: En plus de la possibilité de s'appuyer sur kerberos, il utilise un seul port TCP (très pratique lorsqu'il se trouve derrière un firewall).
Cet exemple montre sa mise en place, et les problèmes rencontrés pour un fonctionnement sans l'authentification kerberos avec FreeBSD (8.1 et 8.2).
On commence par lire nfsv4(4), qui nous indique que pour activer le serveur NFS v4 il faut:

1. Ajouter 3 lignes dans le /etc/rc.conf:

nfs_server_enable="YES"

nfsv4_server_enable="YES"

nfsuserd_enable="YES"

2. Créer un fichier nfs-stablerestart (en root):

install -o root -g wheel -m 600 /dev/null /var/db/nfs-stablerestart

Maintenant on passe à la lecture du exports(5) qui, pour NFS v4 est un peu plus complexe.
Mon but est de partager le dossier /home/olivier en lecture seule, le fichier exports se résume donc à 2 lignes:
V4: /
/home/olivier -ro 127.0.0.1

Puis je lance les services:
/etc/rc.d/nfsd start
Starting mountd.
Starting nfsd.

/etc/rc.d/nfsuserd start
Starting nfsuserd.

Aucun message d'erreur, ça semble bon, maintenant affichons la liste des exports:

showmount -e

Exports list on localhost:

Rien :-(
Et aucun message dans les logs indiquant une erreur dans le fichier exports.

On va quand même essayer:

mount -o nfsv4 localhost:/home/olivier /mnt/

nfsv4 err=10029

mount_nfs: /mnt, : Input/output error

Le message d'erreur le plus intéressant ici est le «nfsv4 err=10029», je n'ai pas trouvé grand chose sur le net concernant ce message, sauf une petite note dans le draft nfsv4:

NFS4ERR_SYMLINK (Error Code 10029)
The current filehandle designates a symbolic link when the current operation does not allow a symbolic link as the target.

Je n'avais pas fait attention à un détail du exports(5):

«The pathnames must not have any symbolic links in them»

Et sur FreeBSD le dossier /home est un lien symbolique qui pointe sur /usr/home.

On corrige donc le fichier /etc/exports:

V4: /

/usr/home/olivier -ro 127.0.0.1

Et on demande à mountd de charger ce nouveau fichier:

/etc/rc.d/mountd reload

Vérifions si c'est mieux 

showmount -e

Exports list on localhost:

/usr/home/olivier                  127.0.0.1

Cool, maintenant je vais pouvoir le monter (en localhost pour débuter):
mount -o nfsv4 localhost:/usr/home/olivier /mnt/
mount | grep olivier
localhost:/usr/home/olivier on /mnt (newnfs)

Parfait, maintenant on liste les fichiers sur du dossier /mnt

ls /mnt/

ls: /mnt/: Input/output error

Bon, ça ne fonctionne toujours pas :-(

Qu'est que ce bordel ?

Voici la commande qui donne un indice sur ce problème:

netstat -a | grep nfsd

tcp6       0      0 localhost.nfsd         localhost.18082        ESTABLISHED

tcp6       0      0 localhost.18082        localhost.nfsd         ESTABLISHED

tcp6       0      0 localhost.621          localhost.nfsd         TIME_WAIT

tcp6       0      0 *.nfsd                 *.*                    LISTEN

tcp4       0      0 *.nfsd                 *.*                    LISTEN

udp6       0      0 *.nfsd                 *.*

udp4       0      0 *.nfsd                 *.*

Et oui, je n'ai autorisé que l'IP 127.0.0.1 à accéder à mon partage dans mon /etc/exports, et la commande mount localhost a utilisé l'IPv6 localhost (::1) pour s'y connecter.

On va donc forcer un montage en utilisant la pile IPv4:

umount /mnt/

mount -t nfs -o nfsv4 127.0.0.1:/usr/home/olivier /mnt/

ls /mnt

.complete                           .mailrc                                

.cshrc                              .profile                                   

.history                            .rhosts                              

.lesshst                            .shrc                                                    

.lftp                               .ssh                                

.login                              .viminfo                            

.login_conf                         .vimrc                              

Enfin, cela fonctionne en local :-)

Comme je veux le monter aussi en IPv6, j'ajoute donc ::1 à ma liste d'IP autorisées:

V4: /

/usr/home/olivier -ro 127.0.0.1 ::1

Maintenant que le montage local IPv4/IPv6 fonctionne, on édite le /etc/exports pour y autoriser les subnets du LAN:

V4: /

/usr/home/olivier -ro -network 2a01:e35:aaaa:aaaa::/64

/usr/home/olivier -ro -network 192.168.100.0

Puis on recharge mountd et vérifie que le fichier exports a été correctement interprété:

/etc/rc.d/mountd reload

showmount -e

Exports list on localhost:

/usr/home/olivier                  2a01:e35:aaaa:aaaa:: 192.168.100.0

Note concernant un client sous Linux, la syntaxe de la commande mount est la suivante:

mount -t nfs4 server-name:/usr/home/olivier/ /mnt

Donc, à noter pour la configuration NFS v4:

1. Ne pas oublier de créer le fichier /var/db/nfs-stablerestart
2. Ne pas déclarer de chemin utilisant des liens symboliques dans le fichier exports
3. Si showmount -e n'indique rien suite au rechargement de mountd, ce n'est pas la peine de continuer
4. Attention aux doubles piles IPv4/IPv6, n'oubliez pas de déclarer aussi les IPv6 dans votre exports
5. Ce n'est pas parce que le montage s'effectue que vous êtes autorisé

FreeBSD packages generator

  
Update (8 april 2011): There is a best method detailled here (in french)

Using up-to-date ports on my old workstations became more and more painful (more than 8 hours for compiling the latest LibreOffice).
Then I've decided to use my brand new server (used for generating BSD Router Project images and running BSDRP routing labs using virtualbox) as a FreeBSD packages generator.
But I've faced to a problem with the "make package-recursive" command on FreeBSD:
The port needs to be installed before generating the package! And I didn't want to install useless programs  (xorg, hal, etc…) on my server.
Then I've wrote small ugly script that:

1. Generate a full new freebsd in a working dir (downloading FreeBSD base, src and lib32 sets).
2. Update the local port tree
3. Launch a chrooted portmaster into the working dir for generating the packages.

This script, package_gen.sh, is to be use like that:

Package generator usage:
./package_gen.sh COMMAND [familly/port-name] [build-option]
Where COMMAND can be:
 generate [familly/port-name] [build-option]
 upgrade [port-name] [build-option]
 replace familly/port-name familly/port-name
 delete [familly/port-name]
examples:
./package_gen.sh generate sysutils/tmux                         : Generate tmux package
./package_gen.sh generate editors/vim-lite -DWITHOUT_X11        : Generate vim-lite package without X11 stuffs
./package_gen.sh generate editors/libreoffice LOCALIZED_LANG=fr : Generate french libreoffice
./package_gen.sh upgrade                                        : Upgrade all packages previously generated
./package_gen.sh delete editors/vim-lite                        : Delete vim-lite
 

All generated packages are in /usr/ports/packages.

Once generated or upgraded, I upload them onto a web server using a small lftp script (-f option):


  set ftp:list-options -a
  set cmd:fail-exit true
  debug -o /home/USER/lftp_debug.log 3
  open -p 21 LOGIN:PASS@ftpperso.free.fr
  cd /packages/8.2/amd64/Latest
  lcd /usr/ports/packages/Latest
  mirror -eRL --only-newer --parallel=2 --verbose=4
  cd /packages/8.2/amd64/All
  lcd /usr/ports/packages/All
  mirror -eRL --only-newer --parallel=2 --verbose=4
 quit
 

This lftp script replaces symbolic links found in /usr/ports/packages by the real file.

Now, from my workstations, I can install up-to-date ported software with this command:

env PACKAGESITE=http://gugus69.free.fr/packages/8.2/amd64/Latest/ pkg_add -r openjdk6

You can use this package repository freely. I will try to kept it online (if my ISP accept this uses) and up-to-date.
But here are some information about theses packages:

• FreeBSD amd64 8.2 only
• www/firefox-i8n include only french language pack
• emulators/qemu with kqemu support and GNS3 patch
• java/jdk16 is compiled with IPv6 enabled