Emile “iMil” Heitor ’s home

Deux ptites astuces que je poste plus pour m’en souvenir qu’autre chose.

J’avais acheté il y a quelques temps une oreillette bluetooth. À cette époque, j’avais vilainement galéré avec btsco et la stack bluetooth Linux, pour finalement obtenir un résultat moyennement satisfaisant puisque l’attachement de l’oreillette nécessitait moult manipulations.

Sur ma Debian flambant neuve, et pres de 3 ans plus tard, les choses se sont considérablement améliorées.

1. ajout des lignes suivantes dans le fichier ~/.asoudrc :

pcm.bluetooth {
         type bluetooth
         device 00:11:22:33:44:55
}

Ou vous remplacerez evidemment 00:11:22:33:44:55 par l’identifiant que vous retournera un hcitool scan, correspondant à votre oreillette.

2. création du fichier /etc/bluetooth/audio.service avec le contenu suivant :

[Bluetooth Service]
Identifier=audio
Name=Audio service
Description=Bluetooth Audio service
Autostart=true

Après un redémarrage de la stack bluetooth, /etc/init.d/bluetooth restart, il suffira alors de spécifier dans le logiciel souhaité, twinkle par exemple, “bluetooth” comme device in/out. Et non, ekiga ne supporte pas ça (ceci est explicitement ecrit ici)

Sur un sujet complètement different, pour assouvir les vils instincts de gamaize qui m’assaillent parfois, j’ai fait l’aquisition d’une NVidia 8600GT, une carte d’entrée de gamme chez NVidia, mais qui s’avère tout à fait efficace avec les jeux recents pour peu qu’on ne veuille pas taper dans des résolutions élevées. J’ai appris que ces cartes ne sont pas, loin s’en faut, livrées avec leur clocking optimal, comprendre qu’elles sont allègrement underclockées. La manipulation nécessaire à l’obtention de leur capacité prévue est la suivante :

Ajouter l’option Option "Coolbits" "1" à la section Device de votre /etc/X11/xorg.conf, redémarrer X11, installer puis démarrer nvidia-settings. Une section “Clock Frequencies” devrait être disponible. Séléctionnez “3D Clock Frequencies” et cliquez sur “Auto-detect”. Une fois les fréquences détectées, cliquer sur “apply”. J’ai gagné une centaine de mégahertz de cette façon. Attention, l’operation n’est pas permanente, un redémarrage de X réinitialise ces valeurs aux factory defaults, un petit script sera du meilleur effet pour automatiser ce parametrage.

Depuis que j’ai collé des foneras partout, il y a très peu de RJ chez moi. Seulement voila, impitoyable est la vie, et j’ai reçu ceci de la part d’un mysterieux “PiteurPetw’elli” :

Evidemment, le bestiau ne se raccorde que via un RJ45 magique.

Tout naturellement, je me tourne vers brctl et commence une conf des plus classiques à coups de brctl addbr br0; brctl addif blah blah blah vous connaissez tout ça par coeur. Et bah oui mais non. Il se trouve que ça merde à plein tubes cette histoire. Je ne sais pas si c’est parce que le lien vers l’exterieur se trouve sur le brin wireless, si c’est parce que ce dernier utilise WPA, mais le résultat est là, l’interface monte, fonctionne pendant quelques secondes / minutes, puis plus rien, néant, no route to host. Misère.
Je me souviens alors de ce tout petit tool, parprouted, qui permettait de faire du bridging ARP. Ni une ni deux :

# parprouted wlan0 eth0
# ifconfig 10.20.30.40

Je sette l’IP du snom, et.. et AH-AAAH DANS TON CUL BRCTL. Ça marche.
Voici la partie associé de mon /etc/network/interfaces

auto eth0
iface eth0 inet static
        pre-up parprouted wlan0 eth0
        address 192.168.30.21
        netmask 255.255.255.0
        gateway 192.168.30.1

Trop dur…

Histoire de m’affranchir de N regles de firewalling / forwarding / nat à se faire des nœuds au cerveau à coups l’iptables, je me suis dit qu’il serait du meilleur effet d’embarquer un simple proxy SIP dans la Fonera.
Après 2/3 googlisations, j’identifie siproxyd comme le candidat idéal pour mon petit exercice.
Muni de l’environnement de développement de FON, je compile :

. libosip2 dont il dépend
. siproxyd lui même

Ça donne à peu près ça :

$ pwd
/home/imil/fonera/src/own/libosip2-2.2.2
$ export FONBUILD=/path/to/fonera/build/env
$ export FONENV=/path/to/fonera/fake/root/filesystem
$ CFLAGS=-I${FONBUILD}/staging_dir_mips/usr/include LDFLAGS="-L${FONBUILD}/staging_dir_mips/usr/lib -lcrypt" CC=mips-linux-uclibc-gcc ./configure --host=mips --disable-hashtable --prefix ${FONENV}
$ make && make install

FONBUILD est le chemin vers l’environnement de compilation décompressé
FONENV est mon point de montage CIFS mounté depuis la Fonera sur /usr/local
puis :

$ pwd
/home/imil/fonera/src/own/siproxd-0.5.13
$ CFLAGS=-I${FONBUILD}/staging_dir_mips/usr/include LDFLAGS="-L${FONBUILD}/staging_dir_mips/usr/lib -lcrypt" CC=mips-linux-uclibc-gcc ./configure --enable-fli4l-22-uclibc --enable-static --host=mips --prefix=${FONBUILD} --with-libosip-prefix=${FONBUILD}
$ make

À la fin de la compilation, j’obtiens un src/siproxyd que je scp dans l’/usr/bin de la Fonera.
Reste à créer un /etc/siproxyd.conf minimal :

if_inbound  = ath1
if_outbound = eth0
sip_listen_port = 5060
daemonize = 1
silence_log = 1
log_calls = 1
registration_file = /tmp/siproxd_registrations
autosave_registrations = 300
pid_file = /var/run/siproxd.pid
# on active le RTP proxy
rtp_proxy_enable = 1
rtp_port_low  = 7070
rtp_port_high = 7089
rtp_timeout = 300
rtp_dscp = 46
default_expires = 600
debug_level =      0x00000000
debug_port = 0
# 1.2.3.4 == l'ip de l'asterisk qui va effectivement enregistrer mes SIP phones
outbound_proxy_host = 1.2.3.4
outbound_proxy_port = 5060
outbound_proxy_port = 5060

Reste à ouvrir quelques ports sur la Fonera :

root@OpenWrt:/etc/init.d# tail -7 /etc/firewall.user
## -- VoIP
# SIP
iptables -t nat -A prerouting_rule -i $WAN -p udp --dport 5060 -j ACCEPT
iptables        -A input_rule      -i $WAN -p udp --dport 5060 -j ACCEPT
# RTP
iptables -t nat -A prerouting_rule -i $WAN -p udp --dport 7070:7089 -j ACCEPT
iptables        -A input_rule      -i $WAN -p udp -m udp --dport 7070:7089 -j ACCEPT

Et evidemment à entrer ces regles “à la main” pour qu’elles soient executées en live.
Moyennant quoi :

/usr/bin/siproxd

Et on admire la beauté d’un header SIP :

Sending to 4.3.2.1 : 5060 (NAT)
Transmitting (NAT) to 4.3.2.1:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 4.3.2.1:5060;branch=z9hG4bKde51f2040c5392cd5619453830d27d85;received=4.3.2.1
Via: SIP/2.0/UDP 192.168.10.231:5060;branch=z9hG4bK066469ba8
From: white ;tag=6af6d7ac5d3c755
To: 087XXXXXXX ;tag=as41ab49a5
Call-ID: a09785bc6c5225000878173ed3169649@192.168.10.231
CSeq: 1169873461 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: 
Content-Length: 0
X-Asterisk-HangupCause: Normal Clearing

Emouvant.

Dans la foulée, voici mon zapata.conf. Après quelques options bien placées, le son ne crachote plus sur la ligne FT et il ne semble plus y avoir d’echo :

[channels]
; carte reliant la ligne Free
signalling=fxs_ks
context=free_pstn
channel => 1
language=fr
cidsignalling=bell
callerid=asreceived
callwaiting=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echotraining=yes
echocancelwhenbridged=yes
rxgain=00.0
txgain=00.0
callprogress=no
busydetect=yes
busycount=3
hanguponpolarityswitch=yes ; pour le raccrochage, aparemment pas supporté en 1.2

; carte reliant la ligne FT
signalling=fxs_ks
context=ft_pstn
channel => 2
language=fr
cidsignalling=bell
callerid=asreceived
callwaiting=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echotraining=no
echocancelwhenbridged=yes
rxgain=00.0
txgain=00.0
callprogress=no
busydetect=yes
busycount=3
hanguponpolarityswitch=yes

Étrangement, il arrivait assez fréquemment qu’au boot de ma gate Asterisk, une seule des deux cartes FXO soient prise en compte par le driver wcfxo. Typiquement, je me mangeais ce genre de message :

Apr 29 12:51:55 home /netbsd: Registered Span 2 (‘WCFXO/0′) with 1 channels
Apr 29 12:51:55 home /netbsd: wcfxo0: Out of space to write register 06 with e0
Apr 29 12:51:55 home /netbsd: wcfxo0: Out of space to write register 0f with 10
Apr 29 12:51:55 home /netbsd: 0: Failed to init DAA, giving up…

Et autres messages du driver de type:

wcfxo0: can’t map interrupt

Après quelques rapides recherches, je lis qu’il est souhaitable dans ce type de situation de :

. Activer l’option “Plug and Play OS” dans son BIOS
. Ajouter le support ACPI dans son noyau. Exemple :

options MPBIOS # configure CPUs and APICs using MPBIOS
options MPBIOS_SCANPCI # find PCI roots using MPBIOS
options MPACPI # configure CPUs and APICs using ACPI

acpi0 at mainbus0
options ACPI_PCI_FIXUP # PCI interrupt routing via ACPI
options ACPI_ACTIVATE_DEV # If set, activate inactive devices

Recompilation, installation du nouveau noyau, et depuis, tout semble se dérouler pour le mieux

ouh-ouh sammy, ça maaaarche :

Après avoir raccordé la ligne Free sur une des cartes X100P et la ligne FT sur l’autre, nous obtenons :

La présence des téléphones analogiques sur les lignes “Phone” assure simplement que si tout le systeme se vautrait lamentablement, des téléphones “classiques” seraient toujours en fonction.

Un ztcfg -vv nous donne désormais:

Keyword: [loadzone], Value: [fr]
Keyword: [defaultzone], Value: [fr]
Keyword: [fxsks], Value: [1-2]

Zaptel Configuration
======================

Channel map:

Channel 01: FXS Kewlstart (Default) (Slaves: 01)
Channel 02: FXS Kewlstart (Default) (Slaves: 02)

2 channels configured.

Reste à renseigner le zaptel.conf, comme par exemple nous l’explique ce lien accompagné de que celui ci, et nous découvrons alors :

*CLI> zap show channels
Chan Extension Context Language MusicOnHold
pseudo ft_pstn fr
1 free_pstn fr
2 ft_pstn fr
*CLI>

Maintenant, il suffit d’arranger l’extensions.conf pour placer les appels sur l’un ou l’autre des liens, voire de traiter chaque appel de manière distincte (ou pas !). Exemple rapide dans lequel je passe les appels en 0800 sur FT et le reste sur Free :

; send green numbers to ft hin hin hin
exten => _0800.,1,Dial(Zap/2/${EXTEN})
; if it’s a 10 digit number (i.e local call)
exten => _XXXXXXXXXX,1,Dial(Zap/1/${EXTEN})

tu vois le topo.