wtorek, września 08, 2009

GPRS on Linux Part 2 - Bluetooth

Było o GPRS przez USB, a teraz czas zabawić się znów Bluetooth'em. Konkretnie to profilem DUN. W tym celu potrzebny będzie włączony protokół rfcomm (ot, taki sobie emulowany port szeregowy, tylko że bezprzewodowy). Zakładam, że BT już zostało skonfigurowane i urządzenia zostały sparowane. Teraz przyda się polecenie sdptool wchodzące w skład pakietu bluez.
# sdptool search DUN
Inquiring ...
Searching for DUN on 00:XX:XX:XX:XX:EA ...
Service Name: Dial-up Networking
Service RecHandle: 0x10002
Service Class ID List:
  "Dialup Networking" (0x1103)
  "Generic Networking" (0x1201)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 2
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100
Polecenie odpytało wszystkie znajdujące się pobliżu urządzenia BT czy dostarczają usługi Dialup Networking. Jak widać laptop znalazł moją komórkę i wykrył, że może ona działać jako modem używając protokołu rfcomm na kanale 2. Informacja odnośnie kanału na którym pracuje telefon, będzie nam potrzebna. Edytujemy plik /etc/bluetooth/rfcomm.conf wpisując zdobyte informacje.
#
# RFCOMM configuration file.
#

rfcomm0 {
#       # Automatically bind the device at startup
        bind yes;
#
#       # Bluetooth address of the device
        device 00:XX:XX:XX:XX:EA;
#
#       # RFCOMM channel for the connection
        channel 2;
#
#       # Description of the connection
        comment "Lightnirs SE k550";
}
Teraz restartujemy demona bluetooth, aby zastosować zmiany. # /etc/rc.d/bluetooth restart Do komórki będziemy odwoływać się jako urządzenia /dev/rfcomm0. Podobnie jak w przypadku GPRS poprzez USB będą nam potrzebne dwa pliki - jeden do negocjacji połączenia, a drugi do ustawień pracy modemu. Pierwszy plik (/etc/ppp/chat-era) wygląda dokładnie tak samo jak w wersji GPRS poprzez USB, co jest logiczne skoro dostawca internetowy jest ten sam. Ponieważ tym razem modem to inne urządzenie (z punktu widzenia systemu), więc wymaga nieco innych ustawień. Utworzyłem sobie taki oto plik konfiguracyjny /etc/ppp/peers/erabt
/dev/rfcomm0
115200
defaultroute
usepeerdns
crtscts
lock
hide-password
holdoff 3
maxfail 3
ipcp-accept-local
lcp-echo-failure 12
noauth
novj
novjccomp
persist
mtu 1500
mru 1500
linkname erabluetooth
#nodetach
#debug
connect '/usr/sbin/chat -v -f /etc/ppp/chat-era'
Teraz o ile użytkownik posiada odpowiednie uprawnienia (por. "GPRS on Linux Part 1 - USB") może nawiązać połączenie wykonując sudo pon erabt Analogicznie by się rozłączyć wpisujemy sudo poff erabt. Na koniec jeszcze małe zestawienie wad i zalet GPRS przez USB oraz Bluetooth. Zaletą Bluetooth niewątpliwie jest wygoda użytkowania, bo nie trzeba nosić ze sobą dodatkowego kabla by podłączyć telefon. Niestety technologia Bluetooth w porównaniu z np. z Zigbee działającym na tym samym paśmie jest naprawdę prądożercza i zakłada, że urządzenia BT będą w miarę często ładowane. Nie jest to więc optymalne rozwiązanie jeśli jesteśmy w szczerym polu i laptop posiada nie w pełni naładowaną baterię. Wariant z USB jest bardziej korzystny, ale telefon posiada ustawienia fabryczne, które włączają automatyczne ładowanie akumulatora podczas połączenia USB. Całe szczęście można to wyłączyć korzystając z ukrytego menu serwisowego. By się do niego dostać w telefonach Sony Ericsson trzeba wystukać następującą sekwencję na klawiaturze → * ← ← * ← *, gdzie strzałki to ruchy joysticka. W menu serwisowym wybieramy "Ustawienia usług" -> "Ładowanie wył."

Ach, aż mam ochotę wybrać się gdzieś na łono natury. Tylko ja, świeże powietrze, rower, laptop i komórka... ]:)

sobota, września 05, 2009

GPRS on Linux Part 1 - USB

Jak już się bawię tym moim telefonem pod pingwinem to opiszę jeszcze jak można z niego korzystać jako modemu zarówno pod USB, jak i pod Bluetooth. Osobiście uważam to za dość przydatną funkcję, bo już parę razy zdarzyło mi się, że byłem gdzieś głęboko w sercu borneańskiej dżungli i musiałem nagle wysłać kilka ważnych maili, albo zrobić przelew. Przejdźmy jednak do konkretów. Podpięcie SE k550 za pomocą kabla USB do komputera powoduje wykrycie go jako dwóch urządzeń szeregowych: /dev/ttyACM0 i /dev/ttyACM1.
# dmesg | tail
usb 2-2: new full speed USB device using uhci_hcd and address 9
usb 2-2: configuration #3 chosen from 1 choice
cdc_acm 2-2:3.1: ttyACM0: USB ACM device
cdc_acm 2-2:3.3: ttyACM1: USB ACM device
cdc_wdm 2-2:3.7: cdc-wdm-176: USB WDM device
usb0: register 'cdc_ether' at usb-0000:00:1d.0-2, CDC Ethernet Device, 02:80:37:09:03:00
Po podpięciu kabla na telefonie wybieramy "Połączenie USB: Tryb telefonu". Teraz pozostaje jedynie konfiguracja komputera. Niezależnie od metody połączenia (USB, BT) i używanego programu trzeba najpierw skonfigurować sposób negocjowania połączenia zależny od naszego dostawcy. Ponieważ posiadam telefon w Erze utworzyłem sobie plik /etc/ppp/chat-era, który wygląda następująco:
TIMEOUT 5
ECHO OFF
ABORT 'BUSY'
ABORT 'NO ANWSER'
ABORT 'ERROR'
ABORT 'NO CARRIER'
SAY "Ustawianie polaczenia...\n"
'' 'ATZ'
SAY "Ustawiam APN\n"
OK 'AT+CGDCONT=1,"IP","erainternettt"'
SAY 'Wydzwaniam...\n'
OK 'ATD*99***1#'
SAY "Czekam na polaczenie....\n "
CONNECT ""
SAY "POLACZONO. Milej zabawy ]:)\n"
Wytłuszczony fragment jest loginem jaki używamy w danej sieci komórkowej. W Tak Taku jest to "erainternett", w Plusie "www.plusgsm.pl", a w Orange i Play "internet". Następnie zabieramy się za utworzenie pliku konfiguracyjnego dla wywoływania połączenia. Mój /etc/ppp/peers/era wygląda tak:
/dev/ttyACM0
115200
noipdefault
usepeerdns
defaultroute
crtscts
lock
hide-password
holdoff 3
ipcp-accept-local
lcp-echo-failure 12
noauth
novj
novjccomp
persist
#nodetach
#debug
connect '/usr/sbin/chat -v -f /etc/ppp/chat-era'
W zasadzie najważniejsze są cztery pierwsze wiersze oraz ostatni. /dev/ttyACM0 jest ścieżką do modemu, 115200 jest szybkością transferu (baud rate) do urządzenia szeregowego(modemu), noipdefault ustawia oczekiwanie na przydzielenie nam adresu IP przez dostawcę, a usepeerdns włącza pobranie adresów serwerów DNS od dostawcy. W ostatnim wierszu zdefiniowany został sposób w jaki negocjowane ma być połączenie, czyli w tym wypadku program chat pobiera stosowne komendy wywoławcze modemu z utworzonego wcześniej pliku /etc/ppp/chat-era. Wiersze za komentowane są przydatne w poszukiwaniu przyczyny niepowodzenia podczas połączenia - nodetach wyłącza wybieranie jako proces w tle, dzięki czemu można śledzić stan negocjacji połączenia w konsoli, a debug jak sama nazwa wskazuje włącza odrobaczanie. Ostatnią rzeczą jaką należy zrobić to pozwolić użytkownikowi na wykonanie połączeń. W systemach unixowych tak już jest, że interfejsy sieciowe normalnie może uruchamiać i zamykać tylko root. W innych przypadkach potrzebne jest polecenie sudo oraz stosowne wpisy w na liście sudoersów. Logujemy się na konto roota i uruchamiamy polecenie: # visudo Dopisujemy lightnir ALL=NOPASSWD: /usr/bin.pon, /usr/bin/poff, /usr/sbin/pppd a następnie zapisujemy i zamykamy(:wq). Dzięki temu użytkownik lightnir będzie mógł uruchamiać polecenia pon, poff oraz pppd na uprawnieniach roota bez pytania o hasło. Teraz aby nawiązać połączenie wystarczy jedynie wykonać polecenie: sudo pon era lub sudo pppd call era. Analogicznie, by się rozłączyć wykonujemy sudo poff era lub killall pppd.

wtorek, września 01, 2009

The Runes have spoken

ᚼᛒ
Czy powyższe dwie runy (Haglaz i Berkanan) są komuś znajome? W takim zapisie pewnie mało kto je widział na oczy. Wspomniane runy można jednak zapisać w formie runy łączonej, którą niejeden wielokrotnie widział w sklepie multimedialnym i bez problemu rozpoznaje. Chodzi oczywiście o biało-błękitne logo bluetooth. Tak jak Harald I Sinozęby zjednoczył Danię, Szwecję i Norwegię pod jedną koroną, tak technologia bluetooth pozwala na bezprzewodową współpracę wielu urządzeń poczynając od telefonów komórkowych, systemów nawigacji, komputerów, a kończąc na prostetycznych nogach. Jak pisałem wcześniej w końcu udało mi się zintegrować moją komórkę (SE k550) z laptopem (Philips X58) pod moim pingwinem (Archlinux, KDE 4). Postaram się pokrótce(albo i nie) opisać jak tego dokonałem. No to jedziemy.

Standardowo zabrałem się za instalację odpowiednich paczek. pacman -S bluez kbluetooth Krótkie wylistowanie urządzeń usb i widać, że sterownik do wbudowanego w laptopie modułu BT jest załadowany i urządzenie działa w trybie HCI (Host controller interface), ale o tym później. # lsusb|grep -i bluetooth
Bus 004 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Następnie wyedytowałem plik /etc/conf.d/bluetooth odkomentując usługę HID. # Run the bluetooth HID daemon (default: false)
HIDD_ENABLE="true"
Oba urządzenia działają, sterownik jest, więc uruchomiłem usługę bluetooth. # /etc/rc.d/bluetooth start Szybki test za pomocą hcitool, czy aby wszystko idzie jak po maśle.
# hcitool dev
Devices:
        hci0    00:XX:XX:XX:XX:3C
Ok. A więc mam adres BT mojego laptopa. Następnie wyszukałem urządzeń BT (komórki).
# hcitool scan
Scanning ...
        00:XX:XX:XX:XX:EA       Lightnir
OK. No to mam adres BT komórki. Co ciekawe komputer widział telefon, ale wyszukiwanie laptopa za pomocą komórki nie działało. Jak się później dowiedziałem spowodowane było to przez ustawiony na laptopie tryb niewidoczności. Teraz tylko wystarczy sparować oba urządzenia. W tym celu trzeba wykonać połączenie z jednego urządzenia na drugie wykorzystując jeden z 26 profili BT. Ja zdecydowałem się na najprostsze z możliwych rozwiązań, a mianowicie użycie mojego telefonu jako urządzenia HID (Human Interface Device). Ten profil pozwala na korzystanie z komórki jako dodatkowej myszy/klawiatury. Jak wcześniej wspominałem moduł BT w laptopie działa w trybie HCI. By móc korzystać z telefonu w trybie HID potrzebny będzie odpowiedni demon - hidd. # hidd --connect 00:XX:XX:XX:XX:EA Po chwili na telefonie wyświetli się monit: "Nieznane prosi o udostępnienie telefonu jako pilota zdalnego sterowania. Zezwolić?". Z zezwoleniem jeszcze chwilę się wstrzymujemy, odpalamy kolejny terminal logując się na roota i uruchamiamy agenta parowania urządzeń pakietu bluez. # bluez-simple-agent Teraz na komórce zezwalamy na połączenie z laptopa, podajemy pin i zatwierdzamy. Ten sam pin wpisujemy w konsoli z uruchomionym bluez-simple-agent. Powinno to wyglądać mniej więcej tak:
bash-4.0# bluez-simple-agent
Agent registered
RequestPinCode (/org/bluez/3717/hci0/dev_00_XX_XX_XX_XX_EA)
Enter PIN Code: 123456
Authorize (/org/bluez/3717/hci0/dev_00_XX_XX_XX_XX_EA, 00001124-0000-1000-8000-00805f9b34fb)
Po sparowaniu urządzeń można wyłączyć agenta wciskając Control-C. W tej chwili mogę się połączyć z laptopa na komórkę, ale nie w drugą stronę. Wynika to z dwóch rzeczy: a) laptop jest niewidoczny jako urządzenie BT dla komórki oraz b) automatycznie nie zezwala na połączenia przychodzące z danego urządzenia.
Niestety nie znalazłem sposobu jak to obejść w trybie tekstowym, dlatego użyłem graficznej nakładki w środowisku KDE - kbluetooth4. Problem z tym, że w moim przypadku nie działała ona zaraz po instalacji i nie wiem, czy wynikało to z mojej przesiadki z kdemod3 na kdemod i jakiś zalegających wpisach w plikach konfiguracyjnych, czy też najzwyczajniej w świecie paczki zawierały błędy. Po części przyczyną kłopotów było to, że moje konto nie należało do grupy wheel (sudo, PAM i te sprawy...), więc je do niej dodałem. gpasswd -a lightnir wheel To oczywiście nie rozwiązało to problemu. Po trochę dłuższym dłubaniu w konsoli doszedłem do przyczyny problemu. Aplikacje KDE4 wymagają działającej usługi ConsoleKit. Teoretycznie ConsoleKit powinien być uruchamiany automatycznie przez dbus i dla każdego zalogowanego użytkownika automatycznie tworzyć sesje. Teoria teorią, ale praktyka pokazuje, że na moim systemie to nie działa tak z biegu. Oczywiście mógłbym ręcznie uruchamiać sesje consolekit ck-launch-session ale znalazłem inną solucję. Zmieniłem wpisy w /etc/inittab z:
# Boot to console
#id:3:initdefault:
# Boot to X11
id:5:initdefault:

...

# Example lines for starting a login manager
x:5:respawn:/opt/kde/bin/kdm -nodaemon
na:
# Boot to console
id:3:initdefault:
# Boot to X11
#id:5:initdefault:

...

# Example lines for starting a login manager
#x:5:respawn:/opt/kde/bin/kdm -nodaemon
oraz dodałem uruchamianie kdm jako demona w /etc/rc.conf DAEMONS=(syslog-ng dbus hal network bluetooth kdm @autowifi netfs @crond) Taka konfiguracja działa bezproblemowo. Uruchomiłem więc kbluetooth4 i skonfigurowałem resztę brakujących rzeczy. Przede wszystkim zmieniłem tryb pracy adaptera BT na laptopie z ukrytego na wykrywalny: A następnie ustawiłem akceptację połączeń przychodzących z komórki (Tasks -> Set Trusted). Teraz komunikacja telefon-laptop działa w obie strony. Czas zabawić się telefonem ]:) SE k550 posiada wbudowaną aplikację zwaną "Sterowanie zdalne", która korzysta właśnie z profilu HID BT. Domyślnie posiada ona 3 konfiguracje: Presenter, MediaPlayer oraz Desktop. Jak się można domyśleć służą one do sterowaniem za pomocą komórki prezentacją multimedialną, odtwarzaczem multimedialnym, czy też używaniem jej jako myszki wzbogaconej o kilka dodatkowych klawiszy. Jak to działa? W skrócie to klawiszom telefonu przypisane są zdarzenia (skróty klawiszowe, ruch myszki), które wysyłane są do komputera i tam przetwarzane tak jakby pochodziły z klawiatury/myszki. Mnie jednak nie zadowalają dostępne konfiguracje, więc postanowiłem sobie zrobić kilka własnych. Problem w tym, że nie ma dedykowanej dla Linuksa aplikacji generującej pliki konfiguracyjne, a używanie poprzez wine Windowsowego programu nie pozwala na złożone kombinacje klawiszy. Jeśli pobierzemy sobie pliki konfiguracyjne z komórki przekonamy się, że tak naprawdę są to tarowane archiwa posiadające rozszerzenie .hid. W środku znajduje się zdjęcie (dowolny format, który komórka rozpoznaje) oraz plik .kcf, który tak naprawdę jest plikiem XML. Przykładowo mój plik sterujący amarokiem wygląda następująco:
amarok.kcf(Toggle Plain Text)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
<!-- Lightnir was hare ]:) -->
<SONY_ERICSSON_REMOTE_CONTROL_CONFIGURATION VERSION = "1.0">
  <KEYMAP>

    <KEY_JOY>
      <ACTION>
        <KEYBOARD MODIFIERS = "0A" USAGEID = "2B"/> <!-- Focus Player -->
      </ACTION>
    </KEY_JOY>
    <KEY_CAM>
      <ACTION>
        <KEYBOARD MODIFIERS = "08" USAGEID = "06"/> <!-- PLAY -->
      </ACTION>
    </KEY_CAM>
    <KEY_1>
      <ACTION>
        <KEYBOARD MODIFIERS = "0A" USAGEID = "2D"/> <!-- REWIND -->
      </ACTION>
    </KEY_1>
    <KEY_2>
      <ACTION>
        <KEYBOARD MODIFIERS = "08" USAGEID = "06"/> <!-- PLAY -->
      </ACTION>
    </KEY_2>
    <KEY_3>
      <ACTION>
        <KEYBOARD MODIFIERS = "0A" USAGEID = "2E"/> <!-- FAST FORWARD -->
      </ACTION>
    </KEY_3>
    <KEY_4>
      <ACTION>
        <KEYBOARD MODIFIERS = "08" USAGEID = "1D"/> <!-- PREV -->
      </ACTION>
    </KEY_4>
    <KEY_5>
      <ACTION>
        <KEYBOARD MODIFIERS = "08" USAGEID = "19"/> <!-- STOP -->
      </ACTION>
    </KEY_5>
    <KEY_6>
      <ACTION>
        <KEYBOARD MODIFIERS = "08" USAGEID = "05"/> <!-- NEXT -->
      </ACTION>
    </KEY_6>
    
    <KEY_STAR>
      <ACTION>
        <KEYBOARD MODIFIERS = "0A" USAGEID = "1C"/> <!-- RANDOM -->
      </ACTION>
    </KEY_STAR>

    <KEY_HASH>
      <ACTION>
        <KEYBOARD MODIFIERS = "08" USAGEID = "10"/> <!-- MUTE -->
      </ACTION>
    </KEY_HASH>

    <KEY_VOL_UP>
      <ACTION>
        <KEYBOARD MODIFIERS = "08" USAGEID = "2E"/> <!-- VOL UP -->
      </ACTION>
    </KEY_VOL_UP>
    <KEY_VOL_DOWN>
      <ACTION>
        <KEYBOARD MODIFIERS = "08" USAGEID = "2D"/> <!-- VOL DOWN -->
      </ACTION>
    </KEY_VOL_DOWN>
  </KEYMAP>
</SONY_ERICSSON_REMOTE_CONTROL_CONFIGURATION>
Jak widać plik .kcf zawiera serię wpisów o podobnej treści. Dla przykładu:
1
2
3
4
5
    <KEY_2>
      <ACTION>
        <KEYBOARD MODIFIERS = "08" USAGEID = "06"/> <!-- PLAY -->
      </ACTION>
    </KEY_2>
Taki wpis oznacza, że wciśnięcie na telefonie klawisza "2" generuje skrót klawiszowy Win+C, który tak się akurat składa jest globalnym skrótem klawiszowym w amaroku, który uruchamia odtwarzanie. Wartość wpisu "MODIFIERS" określa kombinację klawiszy modyfikujących (Alt, Ctrl, Shift, GUI). W tym wypadku szesnastkowe "08" odnosi się do lewego klawisza GUI, czyli po prostu Win. Szczegółowy opis można znaleźć w dokumentacji HID dla Sony Ericssonów (str. 18). Z kolei wartość USAGEID określa wciśnięty niemodyfikujący klawisz na klawiaturze, w tym wypadku C. Wartości USAGEID można sobie wyszukać w oficjalnej dokumentacji USB HID począwszy od strony 53. Teraz wystarczy tylko stworzyć sobie plik amarok.hid tar -cvvf amarok.tar amarok.kcf amarok.jpg
mv amarok.tar amarok.hid
i wysłać go na telefon używając OBEX. Telefon automatycznie rozpozna format i doda do obecnych konfiguracji aplikacji "Sterowanie zdalne". Mam nadzieję, że tekst okaże się pomocny nie tylko mnie jako "przypominajka".

Pozdrawiam runicznie,
ᛚᛁᚷᚼᛐᚿᛁᚱ