eko.one.pl - Połączenie PPP z wykorzystaniem sieci GSM

Połączenie PPP z wykorzystaniem sieci GSM

Połączenie PPP z wykorzystaniem sieci GSM przy pomocy Bluetooth, IRDA, RS232C/USB lub kart pcmcia
Ostatnia zmiana: 2007-03-20 12:21

1. Bluetooth
1.1. Przygotowania
1.2. Uruchomienie
2. IrDA
2.1. SIR
2.2. FIR
3. RS232 / USB
4. Karty PCMCIA GPRS
5. Połączenie PPP
5.1. Skrypty
5.2. Uruchomienie pppd

"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:


    # modprebe 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:


    # irattach irda0 none -s

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:


    AT+CFUN=1,1
    AT+CPIN=PIN

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:


    ppp * ppp

Linia


    OK	ATD*99***1#

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.


    user "ppp"

Uruchomienie pppd

Zostaje tylko wykonanie połączenia. Na sposób debianowy jest to:


    # pon gprs

lub standardowo:


    # pppd

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:


    # poff gprs

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.

Skomentuj na forum