Połączenie PPP z wykorzystaniem sieci GSM przy pomocy Bluetooth, IRDA, RS232C/USB lub kart pcmcia
Ostatnia zmiana: 2013-11-26 18:43
"Internet bez granic" i "Mobilność bez ograniczeń" to ostatnio modne terminy przy promocjach bezprzewodowego dostępu do internetu. Niestety rzeczywistość nie jest już tak różowa; bardzo duże opóźnienia (do 2000ms), zrywanie połączeń, brak zasięgu/sygnału, brak sensownego QoS, ograniczenia ilości nawiązanych połączeń, limity transferu czy w końcu problemy techniczne po stronie operatorów mogą dość skutecznie odstraszyć od tego typu rowiązań. Ale gdy się nie ma co się lubi...
Przy tego typu połączniu można wyróznić dwa etapy: skonfigurowanie modemu (przy pomocy kabla, bluteooth, IrDA) i połączenie przy pomocy ppp (tu już standardowo jak przy połączniu ppp np. z TPSA - zminia się tylko numer i parę opcji dla pppd. Generlanie połączenie wygląda następująco (ASCII art rulez)
---- Bluetooth ----
/ \
Komputer - kabel (USB, RS232C) - GSM (telefon, PCMCIA) - internet
\ /
----- IrDA --------
Przykładowe rozwiązania wykonano na systemie Debian SID i kernel > 2.6.12.
Bluetooth
Specyfikacja Bluetooth obejmuje szybkość połączeń do 723kbps (z kompresją danych do 1.2Mb). Możliwe są interfejsy bluetooth występujące jako dongle USB (bardzo popularne ostatnio) lub widoczne jako port szeregowy (UART, w przypadku niektórych wbudowanych w notebooki lub kart PCMCIA)
Połączenie wykonuje się bardzo prosto; w sumie prawie wszystko już jest w systemie. Ja użyłem Bluetooth Dongle USB Dlinka DBT-120 oraz Nokii 6310i.
Przygotowania
W telefonie: włączyć bluetootha oraz identyfikacje przez inne urządzenia (uwaga do nokii - firmware w wersji V5.52. W przypadku starszych wersji softu mogą być problemy z połączeniem poprzez bluetooth - w takim przypadku należy wykonać upgrade firmware). Trzeba przekompilować jajko z włączeniem blutetooth'a, ppp no i oczywiście USB. Moja przykładowa konfiguracja:
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
# CONFIG_BT_HCIUART is not set
CONFIG_BT_HCIBCM203X=m
CONFIG_BT_HCIBPA10X=m
CONFIG_BT_HCIBFUSB=m
CONFIG_BT_HCIDTL1=m
CONFIG_BT_HCIBT3C=m
CONFIG_BT_HCIBLUECARD=m
CONFIG_BT_HCIBTUART=m
CONFIG_BT_HCIVHCI=m
CONFIG_PPP=m
# CONFIG_PPP_MULTILINK is not set
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPPOE=m
CONFIG_PPPOATM=m
Po podłączeniu bluetootha system powinien go wykryć. W debianie instalujemy pakiety bluez-utils, bluez-pin, ppp.
Uruchomienie
Sprawdzamy czy w ogóle bluetooth jest widoczny:
# hciconfig -a
hci0: Type: USB
BD Address: XX:XX:XX:XX:XX:XX ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:5046 acl:147 sco:0 events:212 errors:0
TX bytes:3835 acl:127 sco:0 commands:52 errors:0
Features: 0xff 0xff 0x0f 0x00 0x00 0x00 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'localhost-0'
Class: 0x3e0100
Service Classes: Networking, Rendering, Capturing
Device Class: Computer, Uncategorized
HCI Ver: 1.1 (0x1) HCI Rev: 0x20d LMP Ver: 1.1 (0x1) LMP Subver: 0x20d
Manufacturer: Cambridge Silicon Radio (10)
XX:XX:XX:XX:XX:XX to mac adres naszego bluetootha. Nazwa to nazwa naszego hosta + numer interfejsu (można ją zmienić w pliku konfiguracyjnym).
Następnie:
# hcitool scan
Scanning ...
YY:YY:YY:YY:YY:YY Nokia 6310i
YY:YY:YY:YY:YY:YY to mac adres naszego telefonu. Nazwa jest taka jak ustawiona w telefonie. Jeżeli widoczne jest więcej urządzeń to całkiem możliwe, że ktoś w okolicy ma włączony bluetooth w telefonie :). W pliku /etc/bluetooth/rfcomm.conf zaszywamy na stałe ten mac adres żeby specjalnie nie robić ustawień z każdym razem:
rfcomm0 {
bind yes;
device YY:YY:YY:YY:YY:YY;
channel 1;
comment "Nokia 6310i";
}
Zapis YY:YY:YY:YY:YY:YY trzeba zamienić na mac adres telefonu. Następnie restartujemy usługę bluetooth.
W innych dystrybucjach można też zrobić to "ręcznie":
# rfcomm bind rfcomm0 YY:YY:YY:YY:YY:YY
W tym momencie telefon powinien poprosić o hasło; to samo hasło powinno zostać wprowadzone w komputerze. Pytanie o hasło nie nastąpi, jeżeli urządzenia zostały już
sparowane.
Numer kanału do usługi "Dial-up Networking" można uzyskać wydając polecenie:
# spdtool search DUN
Inquiring ...
Searching for DUN on YY:YY:YY:YY:YY:YY ...
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: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100
Zwykle jest to kanał numer 1.
To wszystko. Modem powinien być widoczny pod /dev/rfcomm0 (lub /dev/bluetooth/rfcomm/0 - Radio Frequency COMM). Można wykonać dowiązanie symboliczne:
# ln -s /dev/rfcomm0 /dev/modem
lub
# ln -s /dev/bluetooth/rfcomm/0 /dev/modem
Nokia 6310i jest dość prostym telefonem. O wiele bardziej skompilowanym jest Sony Ericsson P910i. To komentarz nadesłany przez Szymona Madeja:
"Moduł BT, który używam to karta" PCMCIA Xircom Credit Card Bluetooth". Jest troche bardziej problematyczny niż wyżej opisany moduł USB.Pierwszy problem to fakt że konieczne jest zainstalowanie paczki (Debian) bluez-pcmcia-support albo za każdym razem trzeba będzie spinać modem (u mnie ttyS2) ze sterownikiem xircom za pomocą hciattach bo inaczej nie powstanie urządzenie hci0.Druga sprawa to fakt że ten moduł BT Xircoma używa sterownika hci-uart (ma "Type: UART" nie jak powyższy "Type: USB"). Dużo czasu mi zajeło, dojście do tego dlaczego urządzenie hci0 mi powstaje ale jest DOWN bo umiera na inicjalizacji. A problem rozwiązało resetowanie modułu BT przed jego inicjalizacją (parametr reset=1 modułu hci-uart).I ostatnia i najważniejsza sprawa to konfiguracja RFCOMM. Urządzenie rfcomm0 tworzyło się ale ppp umierało z dziwnymi błędami I/O. Dogooglałem się w końcu do faktu, że przyczyna tkwi w moim telefonie, którego używałem do zestawiania GPRS. Mianowicie Sony-Ericsson P910i (jak i pewnie większość jak nie wszystkie telefony ze stajni S-E) nie daje możliwości zestawienia połączenia GPRS (a precyzyjnie to DUN - Dial-Up Networking) na dowolnym kanale. Najpierw trzeba sprawdzić na jakim kanale BT można zestawiać połączenia BT:Skanowanie w poszukiwaniu sprzętu sinozębego:
# hcitool scan
Scanning ...
XX:XX:XX:XX:XX:XX P910i
Jak widać znalazł telefon. Kolejny etap to znaleźć kanał na którym w naszym telefonie pracuje DUN (Dial-Up Networking):
# sdptool search DUN --bdaddr XX:XX:XX:XX:XX:XX
Inquiring ...
Searching for DUN on XX:XX:XX:XX:XX:XX ...
Service Name: Dial-up networking
Service RecHandle: 0x10000
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100
Searching for DUN on XX:XX:XX:XX:XX:XX ...
Service Name: Dial-up Networking
Service Description: Dial-up Networking
Service Provider: Sony Ericsson
Service RecHandle: 0x10007
Service Class ID List:
"Dialup Networking" (0x1103)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 7
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100
Jak widać niby oba znalezione kanały 1 i 7 umożliwiają zestawienie DUN, ale w przypadku kanału 1 jest to niemożliwe - pewnie został wylistowany z racji tego że kanał 1 jest przede wszystkim "Generic Networking" w co pewnie wpada i DUN. W tym przypadku jest to kanał 7. W pliku /etc/bluetooth/rfcomm.conf dopisujemy więc taką konfigurację naszego urządzenia:
rfcomm0 {
bind yes;
device XX:XX:XX:XX:XX:XX;
channel 7;
comment "P910i";
}
I dopiero wtedy po poprawnym skonfigurowaniu ppp udało mi się zestawić połączenie GPRS."IrDA
Specyfikacja IrDA obejmuje dwie szybkości przesyłu danych: SIR (do 115200bps) i FIR (do 4Mbps). W pierwszym przypadku IrDA jest zwykłym portem szeregowym (nawet takim samodzielnego montażu). Można także kupić odpowiednie przejściówki z RS232C lub wpinane bezpośrednio w płytę główną. W drugim przypadku na płycie niezbędny jest odpowiedni chip.
Uzyskanie połączenia poprzez IrDA jest stosunkowo proste: należy załadować moduł SIR lub FIR oraz uruchomić polecenie irattach.
Do przykładu wykorzystano telefon Nokia 6310i oraz notebooka wyposażonego w w IrDA FIR (ThinkPad 600, moduł nsc-ircc)
Konfiguracja jÄ…dra:
CONFIG_IRDA=m
CONFIG_IRLAN=m
CONFIG_IRNET=m
CONFIG_IRCOMM=m
# CONFIG_IRDA_ULTRA is not set
CONFIG_IRDA_CACHE_LAST_LSAP=y
CONFIG_IRDA_FAST_RR=y
# CONFIG_IRDA_DEBUG is not set
CONFIG_IRTTY_SIR=m
# CONFIG_DONGLE is not set
CONFIG_IRPORT_SIR=m
# CONFIG_DONGLE_OLD is not set
# CONFIG_USB_IRDA is not set
# CONFIG_SIGMATEL_FIR is not set
CONFIG_NSC_FIR=m
# CONFIG_WINBOND_FIR is not set
# CONFIG_TOSHIBA_FIR is not set
# CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not set
# CONFIG_VLSI_FIR is not set
# CONFIG_VIA_FIR is not set
Konfiguracja przystosowana jest do mojego FIR'a. Należy pamiętać o skompilowaniu odpowiedniego drivera. W przypadku dongle USB będzie to CONFIG_USB_IRDA.
W pliku /etc/modules.conf (/etc/modprobe.d/*) powinny się znaleźć wpisy:
alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty
Następnie należy zainstalować pakiet irda-utils. W debianie wystarczy wydać polecenie
# aptitude install irda-utils
a następnie udzielić odpowiedzi dotyczące konfiguracji interfejsu IrDA. Można to też oczywiście wykonać "ręcznie".
SIR
Aby skonfigurować interfejs IrDA w trybie SIR wystarczy podać port szeregowy. Jeżeli irda dołączona jest to portu ttyS1 to należy wydać polecenie:
# irattach /dev/ttyS1 none -s
Opcja -s oznacza włączony tryb discovery (aktywne poszukiwanie urządzeń IrDA - powoduje to zwiększone zużycie energii w laptopie)
FIR
Aby skonfigurować interfejs IrDA w trybie FIR należy załadować moduł sterownika danego chipa. W moim przypadku był to nsc-ircc:
W przypadku niewykrycia chipa można podać paramtery do modułu; odsyłam do odpowiedniego manuala. Po załadowaniu modułu należy wydać polecenie irattach:
irda0 to nazwa interfejsu tworzona przez sterownik FIR.
Należy pamiętać żeby sterownik FIR bezwzględnie załadować
przed modułem obsługi portów szeregowych 8250. W przeciwnym przypadku IrDA zostanie zajęta przez zwykły port SIR i sterownik FIR nie będzie w stanie zainicjalizować chipa.
IrDA powinna być uruchomiona. Należy uaktywnić interfejs IrDA w telefonie a następnie przysunąć go na ok 10cm od interfejsu IrDA w notebooku. Jeżeli intefejs został uruchomiony i telefon został wykryty, to po wydaniu polecenia:
# cat /proc/net/irda/discovery
powinna pojawić się informacja o wykrytym telefonie:
IrLMP: Discovery log:
nickname: Nokia 6310i, hint: 0xb125, saddr: 0xad550934, daddr: 0x0000f3ea
Przy pomocy
minicoma można sprawdzić czy możemy "rozmawiać" z telefonem przy pomocy poleceń AT. Interfejsem kominikacyjnym IrDA jest /dev/ircommX (zwykle 0 - Infared COMM).
Na końcu można wykonać dowiązanie symboliczne:
# ln -s /dev/ircomm0 /dev/modem
W przypadku problemów z wykryciem telefonu należy skompiliwać irdę z obsługą debug, wyłączyć tryb FIR i przejść na SIR (część telefonów na problem z większymi szybkościami). Dobrym pomysłem jest też zupełne wyładowanie modułów związanych z IrDA i portami szeregowymi, a następnie uruchomienie irattach z odpowiednimi opcjami. Należy tez pamiętać o uaktywnieniu interfejsu IrDA w telefonie jak również o widocznośc optycznej pomiędzy telefonem a okienkiem interfejsu IrDA w komputerze. Należy tez sprawdzić czy istnieje /dev/ircommX. Można go założyc poleceniem
# mknod /dev/ircomm0 c 161 0
Problemem może też być zbyt stara wersja firmware telefonu - niestety w tym przypadku należy udać się do serwisu i wgrać nowe firmware.
Należy równiez pamiętać, że w telefonach zwykle IrDA jest typu SIR, czyli 115200bps. Jeżeli telefon jest nowszej generacji i posiada np. EDGE, możemy zostać ograniczeni w transferze przez IrDĘ do 115200bps - w takim przypadku należy kupić kabel lub przejść na bluetooth'a.RS232 / USB
W przypadku telefonów GSM zwykle istnieje także możliwość połączenia ich za pomocą odpowiedniego kabelka RS232C (np. Nokia 5110, 7110, 6310 itd.), za pomocą kabla USB (np. Nokia 6230(i)) lub kabla USB/RS (zwykła przejściówka z USB na RS232C). Jedyną konfiguracją jaką należy wykonać w systemie to skonfigurowanie portu szeregowego RS232C (ttySX) przy pomocy polecenia setserial lub portu USB (ttyACMX).
Karty PCMCIA GPRS
Popularne ostatnio karty Sony Ericsson GC75, GC75e, GC85 czy BlueConnect są tak prawdę mówiąc zwykłymi modemami GSM widocznymi w systemie jako port szeregowy.
Konfiguracja karty sprowadza się do włączenia w konfiguracji jądra obsługi portów szeregowych PCMCIA
Device Drivers --->
Character devices --->
Serial drivers --->
[*] 8250/16550 and compatible serial support
[M] 8250/16550 PCMCIA device support
oraz oczywiście obsługi kart PCMCIA.
Po włożeniu karty w logach powinna byś widoczna informacja o wykryciu następnego portu szeregowego, np:
ttyS3 at I/O 0x3f8 (irq = 3) is a 16550A
Numer portu (ttyS3) uzależniony jest od ilości obecnych już portów szeregowych w systemie. W przypadku problemów należy spróbować skonfigurować port szeregowy przy pomocy polecenia setserial (ustawić odpowiednią szybkość portu), np:
# setserial /dev/ttyS3 spd_vhi ustawia szybkość 115k zamiast 38.4k
# setserial /dev/ttyS3 spd_shi ustawia szybkość 230k zamiast 38.4k
# setserial /dev/ttyS3 spd_warp ustawia szybkość 460k zamiast 38.4k
Ponieważ karty PCMCIA są zwykle "szybsze" i często występują w postaci GPRS/EDGE lub GRPS/UMTS zalecane jest ustawienie ich na jak największą szybkość (najlepiej 460800).
Zwykle, aby można było nawiązać połączenie z modem GSM i wykonywać polecenia AT należy wydać do niego odpowiednie polecenia:
# minicom --noinit /dev/ttyS3
a po pojawieniu siÄ™ okna:
Oczywiście w miejsce PIN należy podać kod pin do karty SIM. Można także te polecenia wydać w skryptach startowych systemu lub przy połączeniu ppp (uwaga: w niektórych kartach takie polecenie można wydać tylko raz, przy ponownej próbie karta może przestać nawiązywać połączenia).
Po podaniu PINu należy odczekać ok 10 - 20 sekund, żeby terminal GSM zdążył zalogować się do sieci. W przypadku skryptów startowych można także dodać '\d' powodujące uśpienie demona pppd na sekundę. Przykładowy skrypt dla chat może wyglądać następująco:
# /etc/chatscripts/gprs
TIMEOUT 5
ECHO ON
ABORT '\nBUSY\r'
ABORT '\nERROR\r'
ABORT '\nNO ANSWER\r'
ABORT '\nNO CARRIER\r'
ABORT '\nNO DIALTONE\r'
ABORT '\nRINGING\r\n\r\nRINGING\r'
'' \rAT
TIMEOUT 30
OK 'AT+CFUN=1,1'
OK 'AT+CPIN="PIN"'
OK 'ATE1\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d\d'
OK 'AT+CGDCONT=1,"IP","www.plusgsm.pl","",0,0'
OK ATD*99***1#
CONNECT ""
W przypadku posiadania karty GPRS/EDGE lub GPRS/UMTS nie ma potrzeby dodatkowego konfigurowania karty; przełączenie z GPRS na EDGE/UMTS wykonywane jest samoczynnie i "sprzętowo".
Niekiedy warto dodać ATZ (zresetowanie modemu) przed ATE1.
Po poprawnym skonfigurowaniu karty należy wykonać (czysta kosmetyka)
# ln -s /dev/ttyS3 /dev/modem
UWAGA: niektóre karty sprawiają niekiedy dużo problemów: przegrzewają się, wymagają odpowiedniego firmware itd. Warto w takich przypadkach zajrzeć na forum np.
http://www.bez-kabli.pl . W przypadku najnowszych kart GPRS/EDGE/UMTS/HSDPA należy też zainstalować odpowiednie sterowniki
Nozomi.
Połączenie PPP
Połączenie pakietowe GPRS ma tą zaletę, że płaci się za ilość przesłanych danych a nie za czas połączenia. Operatorzy często udostępniają tez inny numer służący do połączeń internetowych; jednakże jest on "zwykłym" numerem, koszt naliczany jest za czas połączenia a prędkość tylko 9600bps. W przypadku GPRS szykość ograniczona jest do 56kbps (dla modemów GPRS klasy 10).
W przpadku GPRS teoretycznie można zestawić połączenie i być online cały dzień. W praktyczne następuje dość często zerwanie lub zawieszenie połączenia.
Skrypty
Mając już działające i sprawdzone połączenie /dev/modem możemy napisać skrypty startowe do połączenia
Można to wykonać przy pomocy pppconfig lub stworzyć je ręcznie:
# /etc/chatscripts/gprs
TIMEOUT 5
ECHO ON
ABORT '\nBUSY\r'
ABORT '\nERROR\r'
ABORT '\nNO ANSWER\r'
ABORT '\nNO CARRIER\r'
ABORT '\nNO DIALTONE\r'
ABORT '\nRINGING\r\n\r\nRINGING\r'
'' \rAT
TIMEOUT 30
OK ATZ
OK ATE1
OK 'AT+CGDCONT=1,"IP","www.plusgsm.pl","",0,0'
OK ATD*99***1#
CONNECT ""
Skrypty są dla PlusGSM, dla innego trzeba zmienić linijkę 'AT+CGDCONT=1,"IP","www.plusgsm.pl","",0,0' na taką, jaka powinna być dla danego operatora:
Plus: (użytkownik: brak, hasło: brak):
'AT+CGDCONT=1,"IP","www.plusgsm.pl","",0,0'Era: (użytkownik: erainternet, hasło: erainternet):
'AT+CGDCONT=1,"IP","erainternet","",0,0'Heyah: (użytkownik: heyah, hasło: heyah):
'AT+CGDCONT=1,"IP","heyah.pl","",0,0'Idea: (użytkownik: ppp, hasło: ppp):
'AT+CGDCONT=1,"IP","www.idea.pl","",0,0'Użytkownika i hasło (o ile jest wymagane) należy umieścić w pliku /etc/ppp/pap-secrets, np:
Linia
definiuje numer GPRS (jest on identyczny dla wszystkich operatorów). Ogólna postać tego numeru to:
ATD*99[*APN[*Protocol[*CID]]]#
gdzie zarówno "APN", "Protocol" jak i "CID" są opcjonalne (przyjmują wówczas wartości domyślne). Wartości "Protocol" nie należy ustawiać. CID (ConnectionID) określa numer kolejny punktu dostępowego APN zdefiniowanego w telefonie. Zwykle jest zdefiniowany jeden taki punkt (wpisany na pozycji 1), ale możliwe jest zdefiniowanie wielu takich punktów; wtedy należy podać odpowiednią cyfrę odpowiadającą pozycji wpisanego APN.
Niekiedy należy jeszcze dodać ATZ przed ATE1 w celu zresetowania modemu w telefonie.
# /etc/ppp/peers/gprs
/dev/modem
115200
connect '/usr/sbin/chat -v -f /etc/chatscripts/gprs'
noauth
defaultroute
debug
noipdefault
local
ipcp-accept-local
novj
novjccomp
lcp-echo-failure 4
lcp-echo-interval 65535
Przy założeniu, że modem jest widoczny pod /dev/modem (dlatego też w przykładach bluetooth czy irda były robione odpowiednie linki). Nic nie stoi na przeszkodzie, żeby umieścić tam /dev/ttyS3, /dev/rfcomm0 czy /dev/ircomm0. Liczba 57600 określa prędkość komunikacji z modem (telefonem GSM). Może się zdarzyć, że modem będzie działać pod inną szybkością (np. 230400 lub 460800); należy to dobrać w zależności od posiadanego sprzętu.
W zależności od operatora (rozłączanie się połączeń) konieczna może się okazać zmiana parametrów niektórych parametrów:
mtu 524
mru 524
nocrtscts
nocdtrcts
W przpadku połączenia wymagającego podania użytkownika lub hasła należy dodać odpowiednią linię, np.
Uruchomienie pppd
Zostaje tylko wykonanie połączenia. Na sposób debianowy jest to:
lub standardowo:
W logach powinno zostać mniej wiecej coś takiego:
Jul 10 10:23:03 localhost pppd[6242]: pppd 2.4.3 started by root, uid 0
Jul 10 10:23:23 localhost chat[6246]: timeout set to 5 seconds
Jul 10 10:23:23 localhost chat[6246]: abort on (\nBUSY\r)
Jul 10 10:23:23 localhost chat[6246]: abort on (\nERROR\r)
Jul 10 10:23:23 localhost chat[6246]: abort on (\nNO ANSWER\r)
Jul 10 10:23:23 localhost chat[6246]: abort on (\nNO CARRIER\r)
Jul 10 10:23:23 localhost chat[6246]: abort on (\nNO DIALTONE\r)
Jul 10 10:23:23 localhost chat[6246]: abort on (\nRINGING\r\n\r\nRINGING\r)
Jul 10 10:23:23 localhost chat[6246]: send (^MAT^M)
Jul 10 10:23:23 localhost chat[6246]: timeout set to 12 seconds
Jul 10 10:23:23 localhost chat[6246]: expect (OK)
Jul 10 10:23:23 localhost chat[6246]: ^MAT^M^M
Jul 10 10:23:23 localhost chat[6246]: OK
Jul 10 10:23:23 localhost chat[6246]: -- got it
Jul 10 10:23:23 localhost chat[6246]: send (ATE1^M)
Jul 10 10:23:23 localhost chat[6246]: expect (OK)
Jul 10 10:23:23 localhost chat[6246]: ^M
Jul 10 10:23:23 localhost chat[6246]: ATE1^M^M
Jul 10 10:23:23 localhost chat[6246]: OK
Jul 10 10:23:23 localhost chat[6246]: -- got it
Jul 10 10:23:23 localhost chat[6246]: send (AT+CGDCONT=1,"IP","www.plusgsm.pl","",0,0^M)
Jul 10 10:23:24 localhost chat[6246]: expect (OK)
Jul 10 10:23:24 localhost chat[6246]: ^M
Jul 10 10:23:24 localhost chat[6246]: AT+CGDCONT=1,"IP","www.plusgsm.pl","",0,0^M^M
Jul 10 10:23:24 localhost chat[6246]: OK
Jul 10 10:23:24 localhost chat[6246]: -- got it
Jul 10 10:23:24 localhost chat[6246]: send (ATD*99***1#^M)
Jul 10 10:23:24 localhost chat[6246]: expect (CONNECT)
Jul 10 10:23:24 localhost chat[6246]: ^M
Jul 10 10:23:27 localhost chat[6246]: ATD*99***1#^M^M
Jul 10 10:23:27 localhost chat[6246]: CONNECT
Jul 10 10:23:27 localhost chat[6246]: -- got it
Jul 10 10:23:27 localhost chat[6246]: send (^M)
Jul 10 10:23:27 localhost pppd[6242]: Serial connection established.
Jul 10 10:23:27 localhost pppd[6242]: using channel 1
Jul 10 10:23:27 localhost pppd[6242]: Using interface ppp0
Jul 10 10:23:27 localhost pppd[6242]: Connect: ppp0 <--> /dev/modem
Jul 10 10:23:28 localhost pppd[6242]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa0458d44> <pcomp> <accomp>]
Jul 10 10:23:28 localhost pppd[6242]: rcvd [LCP ConfRej id=0x1 <magic 0xa0458d44> <pcomp> <accomp>]
Jul 10 10:23:28 localhost pppd[6242]: sent [LCP ConfReq id=0x2 <asyncmap 0x0>]
Jul 10 10:23:28 localhost pppd[6242]: rcvd [LCP ConfAck id=0x2 <asyncmap 0x0>]
Jul 10 10:23:30 localhost pppd[6242]: rcvd [LCP ConfReq id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
Jul 10 10:23:30 localhost pppd[6242]: sent [LCP ConfAck id=0x0 <auth pap> <mru 1500> <asyncmap 0xa0000>]
Jul 10 10:23:30 localhost pppd[6242]: sent [LCP EchoReq id=0x0 magic=0x0]
Jul 10 10:23:30 localhost pppd[6242]: sent [PAP AuthReq id=0x1 user="localhost" password=<hidden>]
Jul 10 10:23:30 localhost pppd[6242]: rcvd [LCP EchoRep id=0x0 00]
Jul 10 10:23:30 localhost pppd[6242]: lcp: received short Echo-Reply, length 1
Jul 10 10:23:30 localhost pppd[6242]: rcvd [PAP AuthAck id=0x1 ""]
Jul 10 10:23:30 localhost pppd[6242]: PAP authentication succeeded
Jul 10 10:23:30 localhost kernel: PPP BSD Compression module registered
Jul 10 10:23:30 localhost kernel: PPP Deflate Compression module registered
Jul 10 10:23:30 localhost pppd[6242]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
Jul 10 10:23:30 localhost pppd[6242]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
Jul 10 10:23:30 localhost pppd[6242]: rcvd [IPCP ConfReq id=0x0 <addr 10.6.6.6>]
Jul 10 10:23:30 localhost pppd[6242]: sent [IPCP ConfAck id=0x0 <addr 10.6.6.6>]
Jul 10 10:23:30 localhost pppd[6242]: rcvd [LCP ProtRej id=0x0 80 fd 01 01 00 0f 1a 04 78 00 18 04 78 00 15 03 2f]
Jul 10 10:23:30 localhost pppd[6242]: Protocol-Reject for 'Compression Control Protocol' (0x80fd) received
Jul 10 10:23:32 localhost pppd[6242]: rcvd [IPCP ConfNak id=0x1 <addr 172.17.66.153>]
Jul 10 10:23:32 localhost pppd[6242]: sent [IPCP ConfReq id=0x2 <addr 172.17.66.153>]
Jul 10 10:23:32 localhost pppd[6242]: rcvd [IPCP ConfAck id=0x2 <addr 172.17.66.153>]
Jul 10 10:23:32 localhost pppd[6242]: local IP address 172.17.66.153
Jul 10 10:23:32 localhost pppd[6242]: remote IP address 10.6.6.6
Jul 10 10:23:32 localhost pppd[6242]: Script /etc/ppp/ip-up started (pid 6276)
Jul 10 10:23:32 localhost pppd[6242]: Script /etc/ppp/ip-up finished (pid 6276), status = 0x0
Można jeszcze dla pewności wykonać route, ifconfig, sprawdzić czy jest interfejs ppp0 i spróbować wykonać np. ping www.google.pl (niestety, czasy są rzędu 700 - 2000ms). Najczęstszym problem jest brak ustawionych dnsów. Jeżeli ping 64.233.183.99 zadziała, a ping www.google.pl już nie, to należy w pierszej kolejności sprawdzić ustawienie dnsów (plik /etc/resolv.conf)!
Jeżeli wszystko działa to można usunąć opcje
debug z ppp oraz
-v z wywołania chat, będzie mniej informacji w logach.
Rozłączenie połączenia następuje po wywołaniu polecenia:
Zostaje jeszcze parę spraw kosmetycznych - dodanie userów do grupy dialup żeby mogli ze swojego konta uruchamiać połączenie oraz ewentualnie skonfigurowanie appletu z GNOME, żeby mieć "ładny" graficzny klikany program do połączenia.