Orange, wvdial i modem Huawei E1752C

Ponieważ w ramach jednego projektu (hm, na razie nic nie nadaje się do publikacji) klikałem na dwa modemy GSM, to obok mojego Huawei E3131 w laptopie pojawił się pożyczony modem GSM Huawei E1752C z kartą sieci Orange. Dla pamięci i gdyby komuś miało się przydać – konfiguracja dostępu do internetu dla sieci Orange pod Linuksem.

W lsusb Huawei E1752C jest widoczny jako:

new high-speed USB device number 11 using ehci-pci
New USB device found, idVendor=12d1, idProduct=141b
New USB device strings: Mfr=3, Product=2, SerialNumber=4
Product: HUAWEI Mobile
Manufacturer: HUAWEI Technology

w dmesg jako:

Bus 002 Device 011: ID 12d1:141b Huawei Technologies Co., Ltd.

Sam modem działał od kopa (kernel 4.1.0-1-amd64, Debian unstable) i nie wymagał żadnych ingerencji, ale zaznaczam, że trafił do mnie jako używka, więc nie wiem, czy było grzebane.

Szybka przeróbka mojej konfiguracji dla Aero2, w oparciu o oficjalne instrukcje ze strony Orange nie zakończyła się sukcesem. Poszukiwania w sieci naprowadziły mnie na ten artykuł nt. konfiguracji modemu GPRS dla sieci Orange w Debianie. Potwierdzam, działa. Ale IMO trochę przydługie, więc postanowiłem skrócić do wersji mniej więcej minimalnej. Skończyłem z takim konfigiem do wvdial:

[Dialer orange-pin]
Modem = /dev/ttyUSB0
Init1 = ATZ
Init2 = AT+CPIN=1234

[Dialer orange]
Modem = /dev/ttyUSB0
Init3 = AT+CGDCONT=1,"IP","internet"
Username = "internet"
Password = "internet"
Phone = "*99#"
Dial Command = ATDTW
Stupid Mode = yes
Dial Attempts = 0

Najpierw trzeba wywołać wvidal orange-pin, a gdy się zakończy, można połączyć się z siecią przy pomocy wvidal orange. Jak widać, kluczową różnicą było ustawienie parametru Dial Command.

Samo połączenie z Orange można uruchomić na Linuksie prościej, ponieważ na desktopie da się wyklikać konfigurację w network manager. Sprawdzone na Debianie Jessie z kernelem w okolicach 4.0. Czasem jednak może przydać się wersja bardziej ręczna, szczególnie jeśli ktoś nie ma GUI w maszynce.

Microsoft kupi Canonical?

Dziś przy porannej kawie natknąłem się na ten artykuł i postanowiłem skrobnąć szybką notkę. Sprawa nie jest wcale taka nieprawdopodobna.

Po pierwsze, wiadomo, że Microsoft interesuje się coraz bardziej rozwiązaniami opartymi o Linuksa. Uważam to za zupełnie naturalne, bo Linux w wielu zastosowaniach radzi sobie równie dobrze, albo i lepiej, niż Windows. Poczynając od nietypowych architektur (typu ARM), przez zastosowania serwerowe, po chmurę i wirtualizację. Jeśli chodzi o desktopy i łatwość obsługi (IMO pozorną, ale…), to oczywiście wygrywa Windows, choć nie ukrywajmy, że Ubuntu miało ambicje tu powalczyć, i miało trochę podobną filozofię, co Windows. Ze wszystkimi jej wadami i zaletami, ale także dodatkowymi wadami Linuksa.

Po drugie, Ubuntu to nie tylko kolejna dystrybucja Linuksa. Jest o tym w artykule, ale ponieważ ostatnio „trochę” siedzę w OpenStacku, to widzę, co mają w tej dziedzinie. A mają sporo, poczynając od dystrybucji w wersji LTS, z gwarantowanym wsparciem przez ok. 5 lat, co jest wartością przyzwoitą i akceptowalną, co niekoniecznie można powiedzieć o debianowym wariancie. Mają też sporo narzędzi ułatwiających tworzenie i zarządzanie chmurą (na różnych poziomach, od hardware’u, po wirtualizację (OpenStack)). Większość instalacji OpenStacka w tej chwili jest właśnie oparta o Ubuntu. Dochodzi do tego specyficzne podejście – Ubuntu ma tendencję do własnych rozwiązań, które niby są opensource, ale w praktyce nie bardzo jest sens używania ich bez Ubuntu. Z perspektywy wieloletniego użytkownika Debiana, Ubuntu jawi mi się trochę jako państwo w państwie…

Dlatego uważam, że jeśli Microsoft poważnie myśli o Linuksie, to kupno Canonical nie tylko jest możliwe, ale wręcz jest jedną z niewielu sensownych opcji pojawienia się na tym rynku. Niechęć części użytkowników do MS i tak pozostanie, ale z drugiej strony i tak musieliby z nią walczyć, jeśli chcą mieć swoją dystrybucję, community i pozycję na linuksowym rynku… Kupno Canonical (lub podobnej firmy) zapewniłoby dostęp do wiedzy, technologii i bazy „oswojonych” użytkowników. Bez tego są skazani na wymyślanie koła od nowa i eksperymenty, a wygląda mi na to, że Microsoft w ogóle nie grokuje Linuksa, więc mieliby trudne zadanie…

Zatem, choć wiele przemawia za tym, że plotka niekoniecznie jest prawdziwa, to raczej po prostu nie tym razem, a nie rzecz zupełnie nie do pomyślenia.

SLA 99,5% – so what?

SLA na poziomie 99,5% robi wrażenie, prawda? Przy okazji dyskusji pod wpisem u Boniego poleciało 99.5% jako synonim jakości (czegoś tam). Co z kolei skłoniło mnie do sprawdzenia, jak to się ma do danych dotyczących dostępności łącza, które wystawiam przy pomocy PUM. No i w skrócie: 99,5% dostępności w skali miesiąca to żaden wyczyn.

Na początek disclaimer: nie jest to wyraźnie napisane w FAQ, ale z tego co się dowiedziałem od autorów/supportu. Uptime Robot w wersji darmowej nie zlicza (poprawnie?) uptime dla okresu powyżej jednego miesiąca. Co niestety nie przeszkadza mu zwracać jakichś wartości dla okresów powyżej 30 dni.

The Free Plan can return uptime ratios back to 1 month due to the limit of the logs kept. The Pro Plan supports back to 1 year. And, the alltimeuptimeratio variable in the API currently returns 1-month uptime (and it’ll be removed from the APIv2).

I jak widać z powyższego, All uptime to tak naprawdę, w przypadku planu darmowego, uptime dla poprzedniego miesiąca.

Spójrzmy na the domek. Komputer Linuksem, dokładnie, Seagate Dockstar robiący za router, więc trochę embedded w porównaniu z typowym PC, czyli bardziej niezawodny. Za to z dyskiem w kieszeni USB, bez jakiegokolwiek podtrzymania prądu przy pomocy UPS. Łącze przez wiekowy modem USB, 3rd party dostawca over linia TPSAOrange (BSA).

Aby było weselej: połączenie resetowane raz dziennie, skrypt podnoszący/sprawdzający uruchamiany co 4 minuty , a PPPoE trochę wstaje…

I cała ta rzeźba, łącznie z przerwami po stronie 3rd party usługodawcy, Orange, dostawcy monitoringu (czyli Uptime Robot), zwłoką przy odświeżaniu dyndns (monitoring jest po domenie) i problemami w globalnym internecie daje radę. Generalnie, bo oczywiście są miesiące, że nie da.

SLA 99,5% my ass… 😉

[1] Nie pamiętam już, czemu tak, zdaje się, że musiał mieć chwilę na sprawdzenie albo ubicie pppd. Albo nie chciało mi się pisać obsługi lockfile’a, bo parę minut przerwy w nocy i tak jest pomijalne w tym zastosowaniu…