# airmon-ng start wifi0

Vous verrez quelque lignes apparaitre à la suite de cette commande dont la dernière qui vous indiquera l’activation de la capture sur l’interface ath1 probablement. Rappelez vous cette interface, c’est celle que nous utiliserons par la suite.

Nous allons maintenant scanner les réseaux disponibles.

# airodump-ng –channel 0-11 –encrypt wep –bssid monreseauwifiamoi

Vous aurez remarqué quelque options relativement explicites. Je ne les expliques pas, le man le fera pour moi. Seul chose, comme il est spécifié, ce sont des options et elles sont donc « optionnelle ». Je sais c’est un pléonasme mais au moins c’est clair.

Passons ensuite à la « fake authentification » pour laquelle la plupart des paramètres auront été récupérés grâce à la commande précédente. Là encore pas de détail, juste la commande :

# airplay-ng -1 0 -e essid_du_reseau -a mac_du_point_d’accès -h mac_du_client_déjà_connecté

Si cela réussi, vous aurez un message qui vous le dira clairement. Commande suivante : l’injection

# aireplay -3 -b mac_du_point_d’accès -h mac_du_client_déjà_connecté -x vitesse_d’injection

Précision, la vitesse d’injection peux être de 100 à 1000 sachant qu’une valeur trop élevée peut faire planter le point d’accès.

Maintenant il faut attendre que les arp commencent à décoller et ensuite que les IVS arrivent à 300 000 dans le cas d’une attaque standard et seulement 40 000 si vous disposez du nouvel algo de décryptage. Une fois ces chiffres atteint :

# aircrack-ng -x *.cap

Ça c’est la commande simple. Pour un décryptage avec le nouvelle algo, remplacer le -x par -z. Pour plus de lisibilité, -0 et si ça ne marche pas, essayez de modifier le fudge factor avec -f et un chiffre de 2 à 12.

Voilà pour le résumé. Je me doute que pour les nouveaux c’est sûrement très confus mais pour ceux qui veulent juste un rappel des commandes ça devrait suffire. Je rappel encore une fois que l’utilisation de tels outils sur des réseaux qui ne vous appartient pas est punis par la loi.

Si tel est votre cas, je suppose que vous seriez ravis d’utiliser votre mini oreillette Bluetooth pour vos conversations Skype tout en gardant le bénéfice de votre 5.1 pour votre musique préférée… Nous allons donc voir comment réaliser cela.

Tout d’abord, installons quelques logiciels :

# apt-get install libopenobex1 bluetooth-alsa bluez-utils bluez-btsco

On lance un module (à noter que pour qu’il se lance à chaque démarrage, il faut l’ajouter à /etc/modules) ainsi qu’un petit logiciel qui permettra de saisir le code d’appareillement lors de la connexion à l’oreillette :

# modprobe snd-bt-sco

$ bluetooth-applet &

Vérifions l’identifiant de votre périphérique Bluetooth interne ainsi que l’adresse MAC de votre oreillette :

$ hcitool dev

Devices:

hci0 00:00:00:00:00:00

$ hcitool scan

Scanning …

00:00:00:00:00:00 Nokia HS-54w

La première commande vous donnera le ‘nom’ de votre périph BT ainsi que son adresse (pas utile pour nous), la deuxième commande l’adresse de votre oreillette et son modèle.

On active les services voix sur le périphérique BT (remplacer hci0 par le résultat de ‘hcitool dev’):

# hciconfig hci0 voice 0×0060

Et enfin on connecte l’oreillette :

$ btsco -v @mac_de_votre_oreillette

Vous devriez voir apparaître une fenêtre vous demandant le code d’appareillement de votre oreillette Bluetooth, souvent ’0000′. Vous pouvez paramétrer Skype pour utiliser votre oreillette. Pour cela allez dans les options (ctrl + o) –> ‘Équipements sonores’ et modifiez les périphériques pour ‘sons entrants’ et ‘sons sortants’ qui devraient normalement laisser apparaître quelque chose du genre ‘BT Headset (hw:Headset,0). pour vérifier que tout fonctionne, vous pouvez ‘Faire un essai d’appel’.

Je l’ai écrit afin de surveiller la mise en vente du EEE Pc de chez Asus qui était annoncé en exclue chez deux VPIstes, Materiel.net et LDLC.com. Connaissant la date de sortie officiel mais pas les dates de pré-commandes supposés et au vu de la demande pour ce produit, un petit script pour surveiller la mise en pré-commande afin d’être dans les premiers à le commander me semblais intéressant.

De conception très simple, j’en fais part comme d’une base à adapter pour les personnes qui pensent ne pas être capable de réaliser un script. Le principe est simple, on récupère le fichier RSS des deux VPIste, on cherche dedans une chaîne de caractères et si celle-ci est présente, on l’envoie par mail…

Le voici donc, détails à la suite :

#!/bin/bash

wget http://www.materiel.net/rss/nouveaute.rss
wget http://feeds.feedburner.com/ldlc/com/rss/nouveautes

> temp.txt
cat nouveaute* | grep EEE >> temp.txt
cat nouveaute* | grep eee >> temp.txt
cat nouveaute* | grep 701 >> temp.txt

if [ -s temp.txt ]
then
./send_myemail.sh mail_expediteur mail_destinataire « sujet » « temp.txt » | telnet smtp_de_votre_FAI 25
fi

rm nouveaute*
rm temp.txt

La première ligne est indispensable afin de spécifier que c’est un script et avec quoi l’exécuter. Les deux lignes suivantes permettent de récupérer les flux RSS, sous la forme ‘wget l’adresse_du_flux‘.

On crée ensuite un fichier vide nommé temp.txt et viens le moment de chercher nos chaînes de caractères. Si vous êtes adeptes de la console, la syntaxe vous est familière, pour les autres petits détails :

« cat » indique que l’on veux afficher le contenu du fichier qui suit, en l’occurrence tout les fichiers placés dans le même dossiers que le scripts qui commencent par ‘nouveaute’ qu’importe ce qui suis (dans notre cas cela permet de regarder dans nouveaute.rss et nouveautes). Le pipe « | » permet de re-diriger le résultat de la commande vers la commande suivante : « grep » qui elle va rechercher réellement la chaîne de caractère qui suit. »>> » signifie que l’on rajoute le résultat à la fin du fichier spécifié. Ces 3 lignes permettent donc telles quelles de chercher ‘eee’ ‘EEE’ et 701 et de placer les lignes correspondantes dans le fichier temp.txt.

Vient ensuite une action conditionnelle ‘if‘. Si temp.txt est non vide (-s) alors sera executé ce qui se situe entre ‘then‘ et ‘fi‘. Pour le détail de cette ligne (envoie du résultat par mail), reporter vous à Envoie de mail autonome.

On supprime ensuite les fichiers que l’on à crées afin qu’ils ne soient pas pris en compte dans la prochaine exécution du script.

N’oubliez pas de rendre le script exécutable (chmod +x). Le but étant de vérifier régulièrement un flux rss, vous pouvez rajouter une ligne à votre cron afin qu’il lance le script toute les 5 mn par exemple. À noter que tant que le script trouvera la chaîne de caractère dans les fichiers récupérés il vous enverra les lignes correspondantes par mail…

Effectivement, le sujet de ce post est de pouvoir inclure dans un script de votre composition l’envoie d’information par mail et ce sans que rien n’ai été configuré sur la machine. Comment cela se fait? par un petit script trouvé sur un forum (je remercie l’auteur si il passe par là…) qui ouvre directement une connexion telnet vers un serveur SMTP et qui ensuite effectue la routine nécessaire à l’envoie…

Le script complet se trouve à la fin du post, on identifier 3 parties, détaillons les un peux.

La première ligne vous l’aurez reconnue, indique que c’est un script à lancer avec bash, viens ensuite la déclaration de 4 variables avec des valeurs qui auront été passés en argument au script et la suite, c’est la routine nécessaire afin d’envoyer un mail à un serveur SMTP… Je ne la détail pas, rien d’intéressant pour notre cas.

Passons maintenant à l’utilisation de notre script. Celle-ci est simple mais requière quand même des explications. Dans votre script d’appel, au moment ou vous souhaitez envoyer le mail, placez la ligne suivante :

./send_myemail.sh vous@gmail.com l_autre@gmail.com « le sujet » « le corps du message » | telnet le_serveur_smtp 25

Premièrement on appel le script en spécifiant qu’il se trouve dans le même dossier. Le deuxième argument est l’adresse qui sera spécifiée comme adresse de l’expéditeur, le troisième argument est l’adresse du destinataire (les deux peuvent être identiques). Le premier argument entre guillemets sera le sujet du mail et le deuxième le corps du message. À noter que vous pouvez mettre le nom d’un fichier pour corps du message. Les deux derniers arguments sont le serveur SMTP que vous utilisez et son port d’écoute. N’oubliez pas évidemment de rendre le scripte send_myemail.sh exécutable.

Et voilà, en espérant que ça vous sera utile…

————————– send_myemail.sh ————————–

#!/bin/bash
FROM= »$1″
TO= »$2″
SUBJECT= »$3″
BODY= »$4″
echo HELO ‘hostname’
sleep 1
echo « MAIL FROM:< »$FROM »> »
sleep 1
echo « RCPT TO:< »$TO »> »
sleep 1
echo DATA
echo Subject: $SUBJECT\r
echo
cat $BODY
echo .
sleep 1
echo quit

Sur mon eee j’ai décidé d’installer une distribution pour tester mon réseau. J’ai choisi d’installer backtrack3. La version 3 est encore en version béta donc il se peut que vous trouviez quelques beugs. Pour ma part je n’ai rencontré aucun problème. Backtrack sert donc à tester son réseau wifi comme filaire. Il permet aussi de voir si un site est vulnérable ou pas.

Pour revenir au sujet, voici comment installer backtrack sur une clé usb ou bien une carte SDHC.

Tout d’abord récupéré l’archive de backtrack3 clé usb sur internet ( une simple recherche sur google devrait suffir ).

Pendant que l’archive se télécharge, nous allons formater la clé usb ou la carte en format fat32.

Pour cela nous allons utiliser gparted pour gnome ou bien tout autre éditeur de partition.

Créer une nouvelle partition sur votre carte ou votre clé puis selectionner « fat32 » comme systeme de partition.

Lancer un terminal depuis votre distribution linux.

Monter votre clé si cela n’est pas encore fait :

sudo mkdir /mnt/cle_usb

sudo mount /dev/sdXX /mnt/cle_usb

Votre clé est monté.

Nous allons maintenant copier les fichiers téléchargé sur la carte SD ou la clé USB.

sudo cp -R /votre_repertoire/ou_se_trouve_Backtrack/boot /mnt/cle_usb/

sudo cp -R /votre_repertoire/ou_se_trouve_Backtrack/BT3 /mnt/cle_usb/

Nous avons fait le plus gros.

Il nous reste plus qu’a installer le boot au demarrage. Aller dans le dossier de boot sur la clé usb.

cd /mnt/cle_usb/boot/

Ensuite il faut lancer un petit script qui se nomme : bootinst.sh

sudo bash bootinst.sh

Suivez les instructions et redémarrer le pc.

Au demarrage de l’ordinateur, booter sur la clé usb ou la carte SDHC et voilà. Backtrack se lance.

Cependant avoir votre musique sur un serveur chez vous et rien sur votre portable, ça vous donne des séances de projets tuteurés à l’université assez moroses. J’ai bien essayé un petite connexion SSH pour récupérer quelques pistes via scp, mais le tout est pas très rapide et pas très utilisable. À partir de là, une idée qui me trottais dans la tête depuis quelques temps m’a semblé devenir indispensable…

L’idée c’est d’implémenter un service de stream sur mon serveur qui diffuserai à la demande et de façon très restreinte la musique que j’ai. Après quelques recherches, j’ai trouvé une solution qui me convenait assez bien, à savoir MPD (que j’utilise déjà quand je suis en local) pour lire la musique sur le serveur, commandé par une interface web grâce à pitckfork, le flux produit par MPD étant dirigé sur Icecast2 afin d’y être transformé en flux stream. Ce flux reste en local car je ne souhaite pas que n’importe qui écoute en même temps que moi. Il sera donc nécessaire d’établir une connexion ssh avec redirection de port pour y avoir accès.

Après la parlotte, passons à la pratique. Je vous laisse installer MPD, Pitchwork (ou autre, Pitchwork n’est pas la seul interface web pour MPD mais cependant je la trouve assez réussi) et Icecast suivant les distributions que vous avez. Je ne m’intéresserai qu’à la configuration de MPD et Icecast2.

MPD :

Dans /etc/mpd.conf hormis la configuration par défault qui consite à indiquer l’emplacement de votre musique, des playlist, de l’utilisateur pour lequel MPD est lancé etc… ce qui nous intéresse est ce qui se trouve sous la bannière :

################ SHOUT STREAMING ################

Je vous met à la suite la configuration pour l’un de mes flux (j’ai configuré MPD pour avoir un flux ‘haute qualité’ et un ‘moyenne qualité’ ) Le détail est en dessous

audio_output {
type « shout »
name « Thot’s HQ stream »
host « localhost »
port « 8000″
mount « /hq.ogg »
password « abcdefgh »
quality « 5.0″
# bitrate « 128″
format « 44100:16:1″
#
# Optional Paramters
user « source »
description « Flux Haute Qualitée »
genre « All »
}

audio_output{ } est obligatoire et indique la configuration d’une sortie audio (vous vous en seriez doutés) celle-ci peut etre pour une sortie physique ou comme ici vers un fichier, spécifié par l’argument ‘ type « shout » ‘.

Viens ensuite le nom que vous voulez lui donner, celui-là même qui apparaîtra dans Icecast. Host et port définissent où est envoyé le flux de sortie, en l’occurence sur le même hôte vers le port 8000.

Mount défini le ‘point de montage’ c’est à dire l’emplacement ou sera disponible ce flux Dans notre cas : http://localhost:8000/hq.ogg

Le mot de passe qui suit est celui qui servira entre MPD et Icecast. Notez le, il vous sera redemandé par la suite.

Viennent ensuite quelques paramètres de qualités que je vous laisse analyser, le paramètre ‘user’ qui définit le nom utilisé pour se connecter à Icecast et en ‘optional parameters’ des infos qui seront affichés en rapport au stream diffusé.

Pour MPD ça sera tout, si vous souhaitez plus de renseignement, n’hésitez pas à consulter la page MPD sur ubuntu-fr.org

Passons à Icecast :

Le fichier de configuration est au format XML et se trouve dans /etc/icecast2/icecast.xml

Je ne vous détail pas tout les paramètres, ils sont très nombreux et pas tous intéressants. Ce qui nous occupe se trouve entre les balises <authentification> :

<source-password>abcdefgh</source-password>

C’est ici qu’il faut placer le mot de passe spécifié dans mpd.conf

<admin-user>admin</admin-user>
<admin-password>change_me</admin-password>

Ces deux paramètre servent pour accéder à la partie admin de l’interface web.

Vérifiez aussi la balise suivante et la configuration pour une utilisation basique devrait être suffisante.

<hostname>localhost</hostname>

Il ne vous reste plus qu’à redémarrer mpd et icecast après quoi vous pourrer lancer la diffusion avec mpd (via pitchfork) et écouter ce qui en résulte avec VLC par exemple en choisissant la lecture d’un flux réseau pour lequel vous indiquerez donc :

http://ip_du_serveur:8000/nom_du_flux.ogg

Je ne saurais que vous conseiller de ne pas ouvrir ce port sur internet et, lorsque vous souhaiterez en profiter depuis l’extérieur, d’ouvrir une session ssh avec redirection de ce port pour une plus grande sécurité.

Si vous avez des soucis d’installation ou de configuration, je suis dispo.

Je dis ça c’est pour le frime, ça m’a un peut cassé les pieds (pas longtemps) du coup j’ai cherché une solution pour pouvoir me connecter à mon serveur perso depuis la connexion de mon université et j’ai trouvé un petit truc tout simple que je m’en vais vous expliquer…

Tout d’abord il est nécessaire de connaitre un port ouvert dans le proxy. Le port 80 bien évidement mais si vous avez un serveur web il vous est utile… par contre il est possible que le 443 (https) ne vous serve pas. Si ces deux là sont utilisés par votre serveur, regardez du coté des ports correspondants au pop, imap, smtp… Dans mon cas ce sera le 443 mais ça ne change pas grand chose.

Le principe est simple, vous faites écouter votre serveur SSH sur un port qui est ouvert dans le proxy, pour cela :

#vi /etc/ssh/sshd_config

Et ajouter :

Port 443

Du coté serveur ça sera tout, sans oublier bien évidemment de redémarrer le service…

Coté Client maintenant il va falloir rajouter un script qui sera appelé lors de l’initialisation de la connexion SSH par le biais du fichier de configuration du client SSH.

Le script est relativement long, vous le trouverez donc en fin d’article afin de ne pas nuire à la lisibilité de ce dernier. Copiez/collez le ou vous voulez (je l’ai mis dans /usr/local/bin) avec le nom ssh-https-tunnel. Il est aussi disponible dans la « box » en page d’accueil. Il y a 2 ou 4 variables à modifier à partir de la ligne 33, tout d’abord le nom du proxy qui vous pose problème (ou son IP) puis son port d’écoute et éventuellement l’id/mdp que vous devez utiliser pour vous y connecter

Il faut maintenant modifier la configuration de votre client SSH afin qu’il utilise le script et nous allons en profiter pour automatiser un peut la connexion…

Pour cela nous allons éditer (créer) le fichier de configuration propre à votre utilisateur :

$ vi ~/.ssh/config

et ajoutez y cela :

host ma_connexion
hostname mon_serveur
user _mon_utilisateur
localforward 8000 127.0.0.1:8000
ProxyCommand /usr/local/bin/ssh-https-tunnel %h %p
Port 443

La première ligne signal que les lignes à suivre sont des ‘options’ pour la connexion ‘ma_connexion’.

La deuxième permet de spécifier l’hôte sur lequel se connecter.

Viens ensuite l’utilisateur qui sera utilisé pour se logger sur l’hôte.

La quatrième ligne configure dés la connexion une redirection de port (le port 8000 de l’hôte est renvoyé sur le port 8000 du pc qui a l’IP 127.0.0.1 ce qui n’est autre que l’ip local de la carte réseau de toute machine, aussi appelé localhost).

La cinquième ligne spécifie d’utiliser notre script précédent.

Enfin la dernière ligne renseigne sur le port d’écoute du serveur distant.

Avec tout cela, lorsque, dans une console, depuis un poste derrière un proxy, vous tapperez :

$ ssh ma_connexion

Votre PC se connectera directement avec l’utilisateur indiqué sur le serveur/port indiqué en effectuant les autres options, le tout à travers le proxy qui vous gênait… Cependant évitez de le dire à votre admin réseau, il pourrait faire la gueule :$

Merci à Mark Suter pour le script utilisé.

———————————– ssh-https-tunnel—————————————-

#!/usr/bin/perl -T -w
# Copyright (C) 2001,2002 Mark Suter <suter@humbug.org.au>
#
# This program tunnels a secure shell connection via a https proxy as
# the ProxyCommand program. The destination secure shell server needs
# to be running on port 443 unless the proxy is very lenient.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#
# $Id: ssh-https-tunnel,v 2.7 2003/10/07 02:22:12 suter Exp $

use strict;
use IO::Socket;
use IO::Select;

################################
## Start User Configuration ##
################################

# Proxy details
my $host = « proxy »;
my $port = 8080;

# Proxy authentication (only if needed!)
my $user = «  »;
my $pass = «  »;

# Add an entry to ~/.ssh/config so « ssh remote.example.org » uses
# this program to proxy the connection.
#
# host remote.example.org
# Port 443
# ProxyCommand /path/to/ssh-https-tunnel %h %p
#
# Many proxies will timeout connections very quickly when there is
# no activity. If you ssh client supports it, add the following to the
# ~/.ssh/config file.
#
# ProtocolKeepAlives 5
#
# Another popular method is to X-Forward something like « xclock -update 5″
# to keep the connection « active. »
#
# If you are behind a Microsoft ISA server, this script can be used with
# http://apserver.sourceforge.net/ to tunnel connections out.

################################
## End User Configuration ##
################################

## Taken from « MIME::Base64::old_encode_base64″ to avoid that dependancy
sub auth_header($$) {
my ($user, $pass) = @_;

sub encode_base64 ($;$)
{
my $eol = $_[1];
$eol = « \n » unless defined $eol;

my $res = pack(« u », $_[0]);
# Remove first character of each line, remove newlines
$res =~ s/^.//mg;
$res =~ s/\n//g;

$res =~ tr|` -_|AA-Za-z0-9+/|; # `# help emacs
# fix padding at the end
my $padding = (3 – length($_[0]) % 3) % 3;
$res =~ s/.{$padding}$/’=’ x $padding/e if $padding;
# break encoded string into lines of no more than 76 characters each
if (length $eol) {
$res =~ s/(.{1,76})/$1$eol/g;
}
return $res;
}

return « Proxy-Authorization: Basic  » . encode_base64 (« $user:$pass », « 1512″);
}

## Tunnel the connection and return a handle for it
sub tunnel_connect($$$$$$) {
my ($host, $port, $user, $pass, $remote_host, $remote_port) = @_;

my $socket = IO::Socket::INET->new(PeerAddr => $host, PeerPort => $port)
or die « $0: Can’t connect to $host:$port: $!\n »;

$socket->print(« CONNECT $remote_host:$remote_port HTTP/1.01512″,
$user ? auth_header($user, $pass) : «  »,
« 1512″) or die « $0: Can’t write: $!\n »;

local $/ = « 12″;
my $response = $socket->getline() or die « $0: Can’t read: $!\n »;
$response =~ /^HTTP\/… 2/i or die « $0: CONNECT failed: $response »;
do { $response = $socket->getline() or die « $0: Can’t read: $!\n »; }
until $response =~ /^\s+$/;

return $socket;
}

## Move data from one handle to another
sub proxy_data($$) {
my ($source, $destination) = @_;

my ($buffer, $length, $offset, $bytes) = («  », 0, 0, 0);
$length = sysread($source, $buffer, 4096, $offset) or return 0;
while ($length) {
$bytes = syswrite($destination, $buffer, $length, $offset) or return 0;
$offset += $bytes;
$length -= $bytes;
}
return 1;
}

## Check we have two arguments
defined $ARGV[0] and defined $ARGV[1] or die « Usage $0 <host> <port>\n »;

## Setup the tunnel
my $proxy = tunnel_connect($host, $port, $user, $pass, $ARGV[0], $ARGV[1]);

## Shift data around in each direction
my $sel = IO::Select->new( [ \*STDIN, $proxy ], [ $proxy, \*STDOUT ] );
SELECT: while (my @ready = $sel->can_read()) {
foreach my $handle (@ready) {
proxy_data($$handle[0], $$handle[1]) or last SELECT;
}
}

Mis de coté le célèbre push mail qui consiste à recevoir en temps réel les mails des boites que vous aurez configuré sur le site approprié (www.orange.blackberry.com pour orange) directement sur votre Backberry, vous pourrez également :

C’est le dernier point pour lequel je voulais vous donner des précisions dans ce post. Dans les applications Google dédiés, je pense à 3 applications qui sont GoogleSync, Google Talk Mobile et Gmail Mobile. Tout trois sont des logiciels développés par Google (si je ne m’abuse) et téléchargeable gratuitement. Voyons ensemble comment les installer et à quoi ils servent…

Gmail Mobile :

Vous vous en serez doutés, Gmail Mobile est un client blackberry pour votre compte Gmail. Celui-ci est, j’avous, bien fait. Loin de moi l’idée d’encenser Google et ses développeurs mais ils ont encore fait quelque chose de pas mal. Vous retrouverez toutes les fonctions de votre boite Gmail que ce soit la recherche, les archives, vos contacts, etc… Pour l’installer sur votre Blackberry, allez sur http://m.google.com/app depuis votre mobile et choisissez l’appli correspondante. Une fois cette application téléchargée et installée, vous aurez l’enveloppe rouge particulière à gmail dans votre liste d’applications. Lancez le programme et il ne vous reste plus qu’a entrer votre couple login/mot de passe pour etre connecté en permanence à votre compte gmail. Je vous laisse découvrir par vous-même les différentes fonctions.

GoogleSync :

Cette applications est particulièrement intéressante car elle permet de synchroniser (son nom le laissait penser) l’agenda de votre blackberry avec l’agenda de votre compte gmail : Google Agenda. Comme pour Gmail Mobile, pas grand chose à faire, allez sur http://m.google.com/sync téléchargez l’application et rentrez le couple id/mdp. A savoir que vous pouvez choisir les agenda de votre compte Google Agenda que vous souhaitez synchroniser. Cependant les donnés que vous entrerez sur l’agenda de votre Blackberry seront ajoutés au premier agenda de votre compte gmail. La syncronisation se fait automatiquement toute les 2h normalement mais vous pouvez la forcer au moment que vous souhaitez.

Pour ces deux applications il semble cependant nécessaire de rentrer les paramètre d’APN dans Options -> Options – avancé -> TCP (pour orange, ça sera orange/orange/orange) afin de que les applications puissent se connecter. C’est là que je voudrais vous avertir, ça peut faire mal à votre forfait… Pour la part, je suis chez Orange mais ni en compte bloqué (incompatible avec l’option Blackberry) ni en forfait pro, cela implique que chaque connexion de l’un ou l’autre des logiciels précédent initialise une « session multimédia » qui m’est facturée forfaitairement 0.50€. En moins de 36H j’en était donc à plus de 13€ de hors forfait, ça fait relativement mal surtout si l’on n’est pas prévenu. Renseignez vous donc sur les conditions de votre forfait afin de savoir comment cela sera compté (je suppose qu’avec un forfait pro c’est compris dedans et que c’est moins de 0.50€ / session).

Venons maintenant à Google Talk Mobile. Étant utilisateur de Linux (étonnant vu le nom du blog…) j’ai eu quelque problème pour l’installation de ce logiciel. Effectivement, celle-ci ne se présente pas de la même manière que les précédentes. Afin d’y parvenir il vous sera nécessaire d’utiliser Internet Explorer et de connecter votre Blackberry au PC. Allez à l’adresse http://www.blackberry.com/GoogleTalk et suivez les instructions. Je ne vous en dirai pas plus n’ayant pas réussi à l’installer la dernière fois (problème de chargement venant du PC, de Google ou autre…). Beaucoup se dirons que Google Talk sur son Blackberry c’est bien jolie mais pas franchement utile si comme moi vous utilisez MSN (je sais, bhouu Crosoft, mais tout mes amis l’utilisent…) cependant, avec un peut de recherche sur le sujet vous découvrirez qu’avec Google Talk vous pouvez importer vos contacts MSN et là, ça deviens intéressant mais ça n’est pas le sujet de ce post, peut être bientôt… A noter que n’ayant pas pus le tester je ne sais pas comment cela se passe pour les connexions et leurs coût mais c’est sûrement à la façon des deux autres.

En résumé, 3 applications bien sympathiques mais qui peuvent vous coûter chère… Donc attention.

Dans un premier temps, ouvrez un terminal :

ctrl + alt + t

Ensuite, il faut éditer les dépôts en activant seulement ceux de Asus :

$ sudo kwrite /etc/apt/sources.list

Un éditeur s’ ouvre, Ajouter un « # » avant chaque ligne autre que les dépôts Asus.

Enfin, recharger la liste des paquets :

$ sudo apt-get update

Maintenant que les dépôts sont près, nous allons installer le mode Full Desktop :

$ sudo apt-get install ksmserver kicker

Une fois l’opération terminé, redémarrez votre Pc.

Au lancement de votre ordinateur, aller dans réglage puis personnalisation. vous avez plusieurs choix qui s’ offre à vous : démarrer en Full Desktop ( l’ordinateur mettra un peu plus de temps à se lancer ) ou bien laisser le mode simple et lorsque vous avez besoin du full desktop, appuyer sur la touche arrêté de votre ordinateur et choisissez « bureau entier ». L’ordinateur se relancera en mode full desktop.