Być może czytaliście mój poprzedni wpis na temat wardrivingu z Nokią 5800, Barbelo i GPSd stwierdziłem tam pewien fakt: „Nie posiadałem zewnętrznego GPSu jak i nie zamierzałem takiego kupować”. Okazało się jednak, że byłem w błędzie 🙂 .
W ostatnich dniach udało mi się zmusić do współpracy (poprzez bluetooth) wbudowany GPS w Nokii 5800 XpressMusic z moim laptopem – Toshiba A200.

Umożliwiło mi to skompletowanie całkiem ciekawego zestawu do wardrivingu nie inwestując żadnych dodatkowych środków na ten cel.

Zestaw do wardrivingu

Aby móc wykonać kolejne kroki zamieszczone w tym artykule musimy spełnić kilka warunków. Musimy posiadać:
– Moduł GPS, w moim przypadku będzie to GPS w Nokii 5800 Xpress Music. Można do tego użyć każdego innego telefonu z wbudowanym GPSem, obsługującego ExtGPS (Nokia N95, E90 i wiele wiele innych, trzeba po prostu samemu sprawdzić czy ta aplikacja będzie działać na telefonie).

– Laptop z obsługą sieci bezprzewodowych i bluetooth, ja używam Toshiby A200-1M8, która te wymagania spełnia (Intel Wireless WiFi Link 4965AGN, moduł bluetooth).

– Linux lub inny UNIXo podobny system. W moim wypadku będzie to Ubuntu (Lucid Lynx).

– Zainstalowany Kismet i GPSd (na linuxie) oraz ExtGPS (na telefonie)..

Parowanie Nokii 5800 z komputerem.

Pierwszym krokiem jest pobranie ze strony producenta darmowej aplikacji ExtGPS (Pobierz), jej instalacja oraz uruchomienie na telefonie.

Następnym krokiem jest sparowanie telefonu z komputerem. Włączamy bluetooth w komputerze oraz w telefonie (podczas nawiązywania połączenia telefon musi być widoczny – „Bluetooth -> Dostępność mojego telefonu -> wybrać Publiczny lub określić czas na jaki ma być widoczny np 5 minut” ). Wydajemy polecenie:

sdptool search SP

Po krótkiej chwili aplikacja powinna wyświetlić informacje o znalezionych urządzeniach bluetooth:

Inquiring ...
Searching for SP on 00:24:7C:XX:XX:XX ...
Service Name: Data Transfer
Service Description: Version
Service RecHandle: 0x10051
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)

Service Name: Symarctic ExtGPS
Service Description: Share phone's built-in GPS module via Bluetooth
Service Provider: Symarctic Solutions
Service RecHandle: 0x10054
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
Channel: 11
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100

Jak widać komputer wykrył nasz telefon (00:24:7C:XX:XX:XX) na kanale 11 (Channel: 11). Aby się z nim połączyć w konsoli wpisujemy:

sudo rfcomm connect 1 00:24:7C:XX:XX:XX 11

connect - nawiazujemy połaczenie
1 - nr porządkowy dla rfcomm
00:24:7C:XX:XX:XX - mac modułu bluetooth w telefonie
11 - kanał 

Poprawnie działanie komendy:

Connected /dev/rfcomm1 to 00:24:7C:XX:XX:XX on channel 11
Press CTRL-C for hangup

Pozostawiamy to okienko terminala w spokoju (jak je zamkniemy lub naciśniemy CTRL+C urządzenia zerwą połączenie).

Jeśli GPS złapał fixa oraz komputer poprawnie nawiązał połączenie z telefonem ExtGPS powinien zasygnalizować to zielonymi kropkami:

Test komunikacji oraz uruchamianie GPSd

Na komputerze można też sprawdzić czy wszytko działa. W tym celu otwieramy nowe okno terminala lub nową zakładkę i wpisujemy:

cat /dev/rfcomm1

Jeśli wszystko jest OK cat powinien wyświetlać nam na ekranie współrzędne przekazywane przez telefon.

cat /dev/rfcomm1 
$GPGGA,202056.000,5225.65114,N,02042.60171,E,1,05,3.4,84.9,M,36.1,M,,*6E
$GPGLL,5225.65114,N,02042.60171,E,202056.000,A,A*58
$GPGSA,A,3,02,04,27,09,12,,,,,,,,4.4,3.4,2.8*36
$GPGST,202056.000,14.7,12.8,37.6,15.8,33.3,14.6,34.1*55
$GPGSV,3,1,10,02,40,110,49,04,28,055,35,27,20,158,35,01,09,280,*76
$GPGSV,3,2,10,09,24,158,37,12,77,081,31,14,29,268,25,29,31,222,25*7F
$GPGSV,3,3,10,30,64,285,31,31,18,314,18*70
$GPRMC,202056.000,A,5225.65114,N,02042.60171,E,0.1,260.4,010510,4.3,E,A*07
...

Wciskamy CTRL + C w oknie z cat’em.

Uruchamiamy GPSd.

sudo gpsd -b -N -D 2 /dev/rfcomm1

Gdyby system stwierdził, że gpsd już działa:

gpsd: launching (Version 2.92)
gpsd: Can't bind to port gpsd
gpsd: Maybe gpsd is already running!
gpsd: Can't bind to port gpsd
gpsd: Maybe gpsd is already running!

Wydajemy polecenie:

 sudo /etc/init.d/gpsd status
 * gpsd is running

Jak widzimy gpsd już działał, należy go wyłączyć:

sudo /etc/init.d/gpsd stop

a następnie ponownie wydać polecenie:

gpsd -b -N -D 2 /dev/rfcomm1

Teraz GPSd powinien się bez problemu uruchomić.

gpsd: launching (Version 2.92)
gpsd: listening on port gpsd
gpsd: running with effective group ID 1000
gpsd: running with effective user ID 1000
gpsd: stashing device /dev/rfcomm1 at slot 0

Testowanie GPSd

Większość rzeczy mamy już skonfigurowanych, można już otworzyć odpowiednio skonfigurowany kismet i zacząć naszą zabawę z wardrivingiem.

Jeśli jest to twoje pierwsze spotkanie z GPDd, w ramach testów jego działania można zainstalować pakiet gpsd-clients

sudo aptitude install gpsd-clients

Po instalacji można uruchomić np. xgps. Jeśli wszystko jest OK powinny wyświetlić się informacje o naszym położeniu i o połączanych z GPS satelitami.

Kismet

Aby kismet mógł współpracować z GPSd musi być odpowiednio skonfigurowany. Linie odpowiedzialne z komunikacje z GPSd w kismet.conf wyglądają tak (to co pogrubione zmieniłem sam, reszta była już ustawiona domyślnie):

gps=true
gpstype=gpsd
gpsdevice=/dev/rfcomm1
gpshost=localhost:2947
gpsmodelock=false
gpsreconnect=true

Gdy kismet jest już przystosowany do komunikacji z GPSd możemy go uruchomić.

sudo kismet

Podczas startu serwera kismet można zobaczyć:

INFO: Connected tp a JSON-enabled GPSD version 2.92, turning on JSON mode

Co potwierdza połączenie kismeta z demonem GPSd.

Teraz z menu klienta kismeta wybieramy Windows -> GPS Details. Przy poprawnej komunikacji kismet z GPDd zobaczymy mniej więcej podobny widok:

Teraz nie pozostało nic innego jak zabranie ze sobą telefonu i laptopa na krótki spacer po mieście i zebranie cennych logów.

Kismet i wizualizacja danych

Do wizualizacji możesz użyć skryptów z poprzedniego artykułu:
Wardriving z Nokia 5800, Barbelo i GPSd

Ostatnio znalazłem też dość ciekawy skrypt napisany w perlu -GISKismet. Możemy go pobrać wydając polecenie

 svn co https://my-svn.assembla.com/svn/giskismet/trunk giskismet

Umożliwia on dość proste prze konwertowanie danych z logów kismeta do pliku w formacie kml, obsługiwanych przez Mapy Google. Ciekawą sprawą jest również możliwość tworzenia bazy danych na podstawie zebranych danych i operowanie na nich poleceniami zwykłego SQLa. Więcej informacji na temat możliwości tego skryptu znajdziesz na stronie projektu.

W katalogu z logami kismeta wyszukujemy pliku z rozszerzeniem netxml.

Kismet-20100502-12-03-34-1.netxml

Następnie uruchamiamy skrypt, który doda nasze dane do bazy danych.

perl giskismet -x Kismet-20100502-12-03-34-1.netxml

Checking Database for BSSID:  00:1A:70:XX:XX:XX ... AP added
Checking Database for BSSID:  00:1F:1F:XX:XX:XX ... AP added
Checking Database for BSSID:  00:1F:1F:XX:XX:XX ... AP added
Checking Database for BSSID:  00:21:91:XX:XX:XX ... AP added
Checking Database for BSSID:  00:22:B0:XX:XX:XX ... AP added
Checking Database for BSSID:  00:23:CD:XX:XX:XX ... AP added

W katalogu ze skryptem pojawi się plik wireless.dbl

Aby z wizualizować dane odpytujemy bazę i nakazujemy skryptowi wygenerować plik kml.

perl giskismet -q "select * from wireless" -o mapa.kml

Tak utworzony plik wrzucamy na google maps i możemy cieszyć się naszą mapką:

Jak widać mapa nie jest zbyt duża, gdyż nie chciało mi się za bardzo latać z laptopem i telefonem po mieście.

Warto zauważyć że, w porównaniu do poprzedniego artykułu dane zebrane przez kismet są o wiele dokładniejsze od danych zebranych przez barbelo (mamy informacje o podłączonych do sieci klientach, więcej informacji na temat zabezpieczeń i szyfrowania itp.)