Zacznijmy od początku - czyli od modemów/telefonów.
Prawdopodobnie każde urządzenie o charakterze modemu w Linuksie (hm, właśnie zacząłem się zastanawiać nad swoim modemem do neostrady, dobra, nie każde;) na pewnym etapie sprowadzi się do urządzenia o charakterze portu szeregowego, podobnie z resztą jak w Windowsie. (nie spotkałem tutaj czegoś analogicznego dla trybu NDIS, może dlatego że NDIS to standard sterownika charakterystyczny dla DOS/Windows - w zależności od wersji NDIS. Inną sprawą jest ndiswrapper, sterownik pozwalający użyć sterowników NDIS z Windowsa pod Linuksem, ale w kontekście modemów komórkowych to bez znaczenia).
Używamy zatem "trybu RAS".
W Windowsie porty komunikacyjne są numerowane jako COM1, COM2, jeżeli "do któregoś przyłączony jest modem" (co jest określeniem wirtualnym, bo i tak to tylko struktura logiczna, fizycznie to najczęściej i tak leci po USB ;) to port COM jest ukrywany, i widoczne jest urządzenie modemu pracujące na tym porcie.
W Linuksie sprzęt jest pogrupowany w zależności od typu, a ściślej - od sterownika jakiego używa dane urządzenie. Urządzenia siedzą w /dev, porty komunikacyjne to /dev/ttyCOŚTAM . /dev/tty0, /dev/tty1, /dev/tty2 itd to urządzenia odpowiadające konsolom, terminalom linuksowym, nie będą nas tutaj za bardzo interesować.
/dev/ttyS0 jest już bardziej interesujące - S to literka sugerująca że to rzeczywisty port komunikacyjny, wiecie, taki oldschoolowy, 9 pinowy ;) Może się przydać jak chcecie wykorzystać archaiczną komórkę jako modem, i macie do niego kabel COM, względnie kupiliście na allegro ciekawy modem podpinany pod COM. (Chyba kiedyś takie widywałem, siemensy czy coś... raczej tylko GPRS, o 3G zapomnijcie, ale mają ciekawe możliwości ;)
/dev/ttyS1,/dev/ttySn to oczywiście kolejne fizyczne porty komunikacyjne w systemie.
Za te porty odpowiada moduł jądra serio_raw. (chyba ;)
/dev/ttyUSB0, i /dev/ttyUSB1 i ogólnie /dev/ttyUSBn, to porty które będą nas interesować chyba najczęściej - strzelam że większość modemów jest podpinana przez USB i obsługiwana przez moduł usbserial - czyli moduł zaprojektowany żeby urządzenia mające działać jako porty szeregowe a podpinane przez USB były widziane jako porty szeregowe ;)
Należy w tym miejscu wspomnieć, że samo urządzenie jako urządzenie o charakterze USB również widnieje w /dev/ - w zależności od wersji jadra pewnie gdzieś w /dev/bus/usb/, ale to nie ma dla nas prawdopodobnie żadnego znaczenia.
Dosyć często można utknąć na etapie "braku urządzenia /dev/ttyUSBn", najczęściej z powodu funkcji ZeroCD, która w linuksie przysparza samych problemów, bo zawartość tego co tam dają i tak jest dla linuksa bezużyteczna. Do tego jak rozwiązać ten problem jeszcze wrócimy, bo metod jest kilka.
Domyślacie się pewnie, że takie urządzenia jak Huawei E160 będą działały właśnie za pośrednictwem tego sterownika - na dodatek portów powinno być tyle ile w windowsie - w Windowsie macie HUAWEI Mobile Connect - 3G PC UI Interface i HUAWEI Mobile Connect - 3G Application Interface, to tu będzie /dev/ttyUSB0 i /dev/ttyUSB1.
/dev/ttyHS0, /dev/ttyHSn - to chyba moje ulubione urządzenia, wszak korzystam z Optiona. Korzystają z modułu jądra hso, w moim GTM380 obecnie jeden modem daje aż 5 urządzeń, w tym jedno z nich daje sygnał GPS ;)
To co robią poszczególne porty jednak sobie podaruję, szukajcie opisów dla windowsa.
Łażąc chwilę po dziale dla linuksa można odkryć, że plik urządzenia może być jeszcze inny - dajmy na to /dev/noz0 i /dev/noz1 itd - dla jakichśtam modemów PCMCIA. Wszystko zależy od modułu jądra jakiego używamy.
W tym miejscu wrócę do problemów z ZeroCD - jak wiecie modemy dysponujące tą funkcją domyślnie po podpięciu zgłaszają się jako urządzenia klasy USB Mass Storage typu Napęd CD, i dopiero po otrzymaniu kodu sterującego ujawniają swoje prawdziwe zastosowanie odkrywając porty komunikacyjne.
Oczywiście w linuksie nie ma co liczyć na to, że oprogramowanie producenta modemu zrobi to tak jak powinno.
Obecnie najczęściej wysłaniem tego kodu sterującego zajmuje się udev - usługa która jest odpowiedzialna za to, żeby odpowiednie pliki urządzeń w /dev pojawiały się i znikały wtedy kiedy urządzenie jest podpinane i odpinane, ładując moduły jądra, kojarząc je z urządzeniami itd. Rozszerzono tą usługę o funkcję wysyłania takich kodów sterujących,czy na przykład firmware'ów do windrukarek czy modemów z neostrady ;)
Czasem jednak zdarzy się tak, że udev nie zadziała jak powinien - mamy starego udeva, albo w ogóle mamy dystrybucję która go nie używa, albo coś nie zadziała. Wtedy z pomocą przychodzą nam programy takie jak usb-modeswitch - ich jedyną funkcją jest wysyłanie takich właśnie kodów sterujących do modemów. Niegdyś była to jedyna opcja. Jak to ugryźć - szukajcie. Był jeszcze jakiś, jego nazwa gdzieś mi się tu przewinęła w tym dziale.
A, jeszcze jedną możliwością jest chyba skojarzenie urządzenia ze sterownikiem "na chama" poprzez użycie komendy modprobe <nazwa modułu> <jakiśtam identyfikator urządzenia> czy jakoś tak. Nie polecam.
jako przykład można podać rozwiązanie stąd: http://www.bez-kabli.pl/viewtopic.php?t=11239
Kod: Zaznacz cały
modprobe usbserial vendor=0xaf0 product=0x6971
VID i PID można wziąć z programu lsusb.
Jeśli chcemy na sztywno przypisać moduł do urządzenia to faktycznie należałoby dodać do /etc/modules wpis
Kod: Zaznacz cały
usbserial vendor=0xaf0 product=0x6971
Ale idźmy dalej - wszak wszystko co wyżej napisałem powinno wydarzyć się w czasie 1/10 sekundy po podpięciu modemu :D
Jako że używamy trybu odpowiadającego trybowi RAS, bezwzględnie potrzebujemy takiego wynalazku jakim jest PPP. Za połączenia wg Point to Point Protocol w linuksie odpowiada program/usługa pppd i moduł jądra ppp ( i inne z nim związane - polecam lsmod | grep ppp).
W większości wypadków jednak nie obchodzi nas że istnieje moduł ppp i pppd, bowiem jesteśmy już nieco ucywilizowani, i używamy różnego rodzaju nakładek na program pppd - jest ich dużo, i w różnych wypadkach różnie się sprawdzą. Generalnie jednak wszystkie robią to samo -> doprowadzają do wywołania pppd z odpowiednimi parametrami, co możemy oczywiście zrobić całkowicie ręcznie, jest to jednak niezbyt wygodne.
Można jednak na tym forum spotkać również rozwiązania niskopoziomowe bazujące właśnie na ustawieniach pppd. Poznacie je po tym, że zaleca się edycję plików /etc/ppp/, a w szczególności zawartość /etc/ppp/peers/, co można by porównać do zawartości folderu Połączenia sieciowe (ale tylko modemowe) z Windowsa. Można ich tam sobie stworzyć dużo, z różnymi configami, itd.
Jeżeli chcielibyśmy tak na próbę wywołać jakieś połączenie to możemy zrobić pppd call <nazwa pliku z /etc/ppp/peers/>, tylko że wtedy sesja pppd zostanie podpięta do konsoli. W każdym razie generalnie większość programów sprowadza się do tego żeby zrobić to za nas.
Skutkiem wywołania pppd będzie nawiązanie połączenia, co objawi się tym, że poleceniem ifconfig (jako root... generalnie większość rzeczy tutaj opisanych, zwłaszcza dot. pppd czy modułów jądra należy wykonywać jako root) ujrzymy połączenie typu Point-to-Point najczęściej nazwane ppp0. (i tutaj przyszła refleksja - u mnie na Optionie jest to hso0, muszę jeszcze looknąć jak to tam jest). Generalnie ethN to połączenia kablowe ethernetowe, wlanN, wifiN, raN albo inne syfy to WiFi, choć mogą tez wisieć pod ethN, lo to loopback, itd. Jakoś się połapiecie które połączenie jest wasze, modemowe.
Rozwińmy teraz troszkę to co w plikach w /etc/ppp/peers/.
Pozwolę sobie wykorzystać przyklejone howto: http://www.bez-kabli.pl/viewtopic.php?t=11239
W tym howto autorzy zeszli jeszcze niżej - napisali (a pewnie przerobili jakieśtam znalezione w necie ;) skrypty nawiązujące i rozłączające połączenie, i wykonują je z poziomu pppd za pośrednictwem /usr/sbin/chat - skrypty są w osobnych plikach, które sugeruje się zapisać w /etc/ppp, ale mogłyby sobie leżeć gdziekolwiek.
Generalnie wersja z użyciem bezpośrednio pppd powinna być używana tylko jeżeli mamy
a) dobre howto krok po kroku dla naszego urządzenia/łącza
b) nic innego nie działa.
c) lubimy to. ;D (zaśmierdziało facebookiem).
Zostawmy już to pppd na chwilę, niech coś je wywoła za nas, możliwości jest wiele.
Opcją wartą uwagi w tym miejscu jest wvdial - programik o sporych możliwościach, daje sobie radę chyba ze wszystkim. Często polecany na tym forum, generalnie można zmieścić wszystkie ustawienia w jednym pliku tekstowym i on już za nas zrobi wszystko.
Czyli jak już mamy odpowiedni plik konfiguracyjny to robimy wvdial w konsoli i nas łączy. Czasem wvdial wymaga parametru będącego nazwą połączenia. Po więcej odsyłam do szukaczki forumowej i google'a.
Jego zalety to, to że nie wymaga niczego poza pppd i istniejącym urządzeniem modemowym, jest samodzielny, działa w trybie tekstowym, więc nadaje się na urządzenia robiące za routery, gdzie nie ma środowiska graficznego.
A, nie byłbym debianowcem, gdybym nie wspomniał o pliku /etc/network/interfaces, obecnym w debianie i służącym konfiguracji sieci. Plik ma naprawdę ogromne możliwości, ale dla zastosowań ppp (a takie nas tutaj interesują) wystarczy że będzie zawierał
Kod: Zaznacz cały
auto ppp0
iface ppp0 inet ppp
provider <nazwa pliku z /etc/ppp/peers/>
name Nasz dostawca
Połączenia nawiązane poprzez ten plik obsługuje się komendami ifdown <nazwa interfejsu> oraz ifup <nazwa interfejsu>, czyli dajmy na to ifup ppp0.
Uwaga, można tu wpaść w pewną pułapkę - nazewnictwo z /etc/network/interfaces NIE MUSI pokrywać się z tym z ifconfig. Lepiej więc nadawać ładne nazwy (ppp0) i się ich trzymać.
Generalnie /etc/network/interfaces jest raczej rozwiązaniem pozwalającym nam na ucywilizowanie tego co osiągnęliśmy pracując bezpośrednio z pppd.
Idźmy dalej, czas już na rozwiązania łatwe "lekkie" (choć w gruncie rzeczy ciężkie dla systemu) i przyjemne, czyli graficzne.
Słowo klucz - NetworkManager. Jest to stosunkowo młode rozwiązanie, które powstało po to, żeby w jakiś sposób ustandaryzować bajzel jaki powstał w obsłudze WiFi w linuksie - moim zdaniem rozwiązanie to jest obleśne, obrzydliwe, okropne, zasobożerne, idiotyczne, itd, ale ma tą zaletę, że działa, i jest standardowe.
Od jakiejśtam NetworkManager wersji obsługuje połączenia pakietowe - na jego potrzeby powstała nawet baza providerów i parametrów połączeń (dla gsm i cdma - więc pewnie cdma też obsługuje ;) -> http://live.gnome.org/NetworkManager/Mo ... eProviders
NetworkManager najczęściej wpieprza się do naszego systemu przy instalacji, wraz z Gnomem, w wielu dystrybucjach, które uważam za uszkodzone, nie da się go wywalić całkowicie, co najwyżej wyłączyć. Najczęściej obsługuje się go klikając "w ikonkę sieci w trayu". Istnieją odpowiednie frontendy dla Gnome'a i KDE. Generalnie ma to do siebie, że jak nic nie nawaliło na poziomie udeva (czy tam, pożal się boże, devkita) to NM wykryje modem, czy komórkę podpiętą kabelkiem, i klikając dalej dalej dalej i wybierając ISP z listy/wpisując ręcznie (właśnie pragnę uzupełnić bazę polskich ISP) nawiążemy połączenie.
jest także tekstowy klient NetworkManagera, cnetworkmanager, jednak ten program to porażka - czasem jednak się przydaje. Warto wspomnieć że NM zrywa połączenie wraz z wylogowaniem się (domyślnie w debianie).
W tym miejscu rozpocznę wywód na temat programów o których nie mam pojęcia.
Te programy to graficzny HSOConnect, tekstowy hsolink - jak mniemam zastępują funkcje NM, należy zatem zadbać o to żeby wcześniej NM wyłączyć - no i oczywiście hso w nazwie jasno daje do zrozumienia że programy te tyczą modemów obsługiwanych sterownikiem hso - czyli Optionów.
Są też programy działające niejako podobnie do ifdown && ifup z /etc/network/interfaces, omijające NetworkManagera a nawiązujące połączenie ppp. Szczerze - odpuście je sobie. Najczęściej powstały dla modemów analogowych i niewiele wam dadzą. Są to kppp, gnome-ppp i inne.
Chwilowo brakło mi pomysłów co jeszcze byłoby istotne - czekam na sugestie.
Tak, wiem, że przydałoby się jakieś formatowanie - niech każdy czuje się upoważniony je wprowadzić ;)