Aero2 – zmiany na stronach WWW
Dzisiaj około godziny 15tej operator wprowadził kilka zmian na swoich stronach.Informacje o usłudze trafiły wreszcie do głównego menu znajdującego się w nagłówku strony, oznaczona dość tajemniczym (dla niewtajemniczonych) skrótem BDI. Tym samym pod raz trzeci zmienił się adres, pod którym znajdziemy informacje o usłudze. Z jednej strony to cieszy, że informacje nie są już tak ukryte jak wcześniej w informacjach o spółce, a drugiej z pewnością może utrudniać znalezienie informacji za pomocą odnośników umieszczonych na rzadko aktualizowanych stronach.
Zmianę zauważyłem podczas odświeżania stanu magazynowego kart SIM – zamiast normalnej strony zobaczyłem błąd 404. Zobaczmy jak zmieniał się adres od maja 2011 w ostatnim czasie:
- http://www.aero2.pl/www/ubdi.html – od około 10 maja 2011
- http://www.aero2.pl/www/bdi.html – od 1 września 2011
- http://www.aero2.pl/bdi.html – od 13 września 2011
Ciągle nie został rozwiązany problem nazw kanonicznych – strona występuje pod dwoma, rozłącznymi adresami w sieci: aero2.pl oraz www.aero2.pl. Mam nadzieję, że także i tę drobną wadę uda się poprawić.
ja odbierałem 26 sierpnia swoją i koleżanki na obydwu były domyślnie włączone PIN-y.
Wszystkie karty przydzielone od połowy lipca do 11 sierpnia piny mają włączone. Ciekawi mnie natomiast, jak to jest z kartami przydzielanymi od 8-9 września. Wygląda na to, że to kolejna zmiana (drobna na szczęście i ułatwiająca życie) w konfiguracji kart.
tzn jaka zmiana ?
Jeżeli wydawane teraz karty mają wyłączony PIN, to jest to kolejna zmiana w konfiguracji kart. "Stare" karty (do połowy lipca) PIN miały wyłączony, nowe karty PIN mają włączony i teraz wygląda (być może) nowe karty z puli wrześniowej znowu PINu nie mają – ale dopiero jedna osoba to potwierdziła, więc pewności nie mam.
Ja również mogę potwierdzić, że 'wrześniowe' karty nie mają włączonego PINu.
Również potwierdzam, karta odebrana 12. września nie ma włączonego PINu.
Jaka zmiana, możesz coś przybliżyć?
koleżanka odebrała SIM dziś rano – karta od razu aktywna. Bez założonego PIN-u – czyżby Aero2 w tej serii kart odeszło od PIN-owania kart typowego dla drugiej transzy?
Ciekawa informacja. Ktoś z posiadaczy świeżo odebranych kart może potwierdzić, że PIN jest wyłączony?
Wczoraj odebrałem kartę. Po włożeniu UMIS do modemu i ustawieniu apn na 'darmowy' połącząyłem się z internetem. Żadnego pytania o PIN nie było, chociaż i PIN i PUK są wytłoczone na tej większej karcie.
To prawda, PIN jest wyłączony.
W poniedziałek odebrałem kartę i dziś nadal jest nieaktywna. Czy to jest norma?
Czy ktoś odebrał kartę w tym tygodniu i może z niej korzystać?
Wg regulaminu mają 5 dni roboczych na aktywację karty, więc niby wszystko jest OK,
ale z różnych postów wynikało, że przeważnie karty działały od razu.
Nie spotkałem się ciągle z ani jednym raportem potwierdzającym wydanie karty, która nie jest aktywna. Jakie masz objawy, jak sprawdzasz, w czym i gdzie.
Modem E173-u2.
Platforma Linux
Skrypt wvdial.conf:
[Dialer Defaults]
Modem = /dev/ttyUSB0
Baud = 460800
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2
Init3 = AT+CGDCONT=1,"IP","darmowy"
Init4 = AT&C1
Carrier Check = no
Phone = *99#
Dial Command = ATDTW
Stupid Mode = 1
ISDN = 0
Auto DNS = 1
apn = darmowy
Username =;
Password =;
Objawy:
–> WvDial: Internet dialer version 1.61
–> Cannot set information for serial port.
–> Initializing modem.
–> Sending: ATZ
ATZ
OK
–> Sending: ATQ0 V1 E1 S0=0 &C1 &D2
ATQ0 V1 E1 S0=0 &C1 &D2
OK
–> Sending: AT+CGDCONT=1,"IP","darmowy"
AT+CGDCONT=1,"IP","darmowy"
OK
–> Sending: AT&C1
AT&C1
OK
–> Modem initialized.
–> Sending: ATDTW*99#
–> Waiting for carrier.
ATDTW*99#
NO CARRIER
–> No Carrier! Trying again.
–> Sending: ATDTW*99#
–> Waiting for carrier.
ATDTW*99#
NO CARRIER
–> No Carrier! Trying again.
–> Sending: ATDTW*99#
–> Waiting for carrier.
ATDTW*99#
NO CARRIER
Z kartą PLUSa i PLAY działa poprawnia
Sygnał jest OK. (AT+CSQ zwraca 18,99)
Oczywiście siła sygnału dotyczy sieci AERO2.
AT+COPS=? zwraca:
+COPS: (1,"","","26017",2),(3,"Orange PL","Orange","26003",2),(3,"POL","Play","26006",2),(3,"Plus","PLUS","26001",2),(3,"Era","Era","26002",
2),,(0,1,2,3,4),(0,1,2)
OK
To nie koniecznie wina braku aktywowania karty. To może być efekt uboczny problemu "nowej karty SIM" z zablokowanym TS11. Spróbuj odpalić ten sam zestaw na Win XP/Vista lub za pomocą instrukcji http://jdtech.pl/2011/08/aero2-i-huawei-e173u-2-p… – jeżeli objawy będą te same to faktycznie możesz mieć coś z kartą.
Hmmm, rzeczywiście dziś połączył mi się z Windows. (W poniedziałek nie chciał, twierdząc, że nie może zarejestrować się w sieci, a we wtorek nie używałem Windowsów).
To oznacza, że przepis na podłączanie się z Linuxa przez wvdial nie działa z nowymi kartami.
Po podłączeniu modemu pojawia mi się w systemie interfejs sieciowy "wwan0" (emulowany Ethernet), ale próba jego skonfigurowania nie powodzi się.
Nie jest on też widziany jako emulowny interfejs WiFi, w którym mógłbym kontrolować więcej parametrów.
Wygląda na to, że muszę dokompilować sterownik cdc_ether .
Dam znać, czy to pomogło.
Niestety cdc_ether jak się okazało już był w systemie (dlatego widziałem urządzenie wwan0). Zebrałem logi komunikacji pod Windows programem sniffusb, jednak nie udało się znaleźć w nich żadnych magicznych komend AT włączających tryb NDIS.
Niestety nie działa AT*ENAP używane w niektórych modemach.
(np. jak to opisano tu: http://www.mail-archive.com/lfs-chat@linuxfromscr… )
Wykaz komend HUAWEI związanych z UMTS: http://www.net139.com/UploadFile/menu/HUAWEI%20UM… też niestety nic nie wyjaśnił.
W logach wypatrzyłem, że wybranie APN i włączenie transmisji jest spowodowane wysłaniem pakietu USB:
– URB_FUNCTION_CLASS_INTERFACE:
TransferFlags = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRA
NSFER_OK)
TransferBufferLength = 0000001b
TransferBuffer = 88fde070
TransferBufferMDL = 00000000
00000000: 01 1a 00 00 01 02 00 05 00 20 00 0e 00 14 07 00
00000010: 64 61 72 6d 6f 77 79 16 01 00 02
UrbLink = 00000000
RequestTypeReservedBits = 00000000
Request = 00000000
Value = 00000000
Index = 00000001
Jak na razie nie jestem w stanie stwierdzić, co to za protokół
Chodzi o to że potem mogą powiedzieć że nie otrzymali formularza do 30 września i nie zwrócą kasy.
Jakby ktoś dostał takie potwierdzenie otrzymania na Zwrot Nadpłaty to niech napisze tutaj.
Pozdrawiam Marcin.
Po 6 dniach dostałem takie potwierdzenie.
Dziękuję za odpowiedz.
Ja wysłałem formularz zwrotu 2011-09-08, potem zapytanie o otrzymane dok. 14 września i dalej nic choć jest dzisiaj 19 września.
Czy ktoś dostał potwierdzenie otrzymania formularza zwrotu nadpłaty przez e-mail od Aero?
Bo ja wysłałem w czwartek i potwierdzenia otrzymania nie dostałem, czy w takim wypadku poprosić o potrwierdzenie otrzymania od Aero?
Dostałem potwierdzenie złożenia dokumentów, ale przelewu już nie otrzymałem. Nie ma co siać paniki, bo mają na to 30 dni.
…. taka postawa może być oznaką choroby, np uzależnienia od internetu. życzę zdrowia wszystkim.
co za typek się Pana czepia? ostro! mogę doradzić temu komuś, aby wyłączył komputer i odpoczął na świeżym powietrzu.
Krytykować to każdy potrafi. Jak się komuś ten blog nie podoba to niech tu nie zagląda – a tym bardziej nie psuje „nastroju” zainteresowanym i prowadzącemu. Nikt tu nikogo pod pistoletem nie zatrzymuje – dla mnie niektóre tematy poruszane przez Jakuba tez są mniej ciekawe (głównie dla tego że jestem laikiem i są dla mnie one nie zrozumiałe, lub mnie po prostu nie interesują – np. nie zamierzam korzystać z FreeM), ale nie przechodzi mi przez myśl żeby zarzucać mu iż zajmuje się „pierdołami”, bo wiem że kogoś te tzw. „pierdoły” mogą interesować. Gro tematów poruszanych na blogu jest jednak warte mojej uwagi – i te tematy śledzę. Kwestie szacunku dla cudzej pracy pomijam – zakładając ze na blog wchodzą ludzie na pewnym poziomie kultury i intelektu.
zamiast sie zajmowac jakimis pierdolami ze zmiana literek w linkach do aero2 to zaczalbys robic cos konkretnego na tym blogu.
1. miales opisac inne alternatywy darmowego lub prawie darmowego internetu
2. jakis filmik miales nagrac jak dziala freeM w telefonie
3. mial byc artykul o tym jak nabic sobie iles tam GB w orange free na karte by wyjasnic jak to robia ludzie z allegro ktorzy to sprzedaja
gdzies tam pisales ze tematyka aero cie pochlonela na tyle ze nie masz czasu na nic.
sorki ale codziennie wbijam na neta i niusow o aero nie ma tyle ze zajmuje mi to pol dnia wiec albo zaczniesz pisac konkretnie na blogu i poruszac tematy ktore ludzie tu poruszyli albo moze pora sobie dac spokoj z prowadzeniem bloga skoro cie to przerasta???
Niestety blog prowadzę amatorsko w wolnym czasie – a tego nie mam aż tak dużo. Niestety nie jest to działalność, z której można się utrzymać, a jeść trzeba
Do tego cały czas pomagam w rozwiązywaniu problemów – w komentarzach i innymi kanałami. O wspomnianych tematach pamiętam i artykuły powoli powstają – filmik, którego przygotowanie, obróbka i publikacja zajmuje kilka godzin i obejrzy go niewiele osób schodzi na drugi plan wobec obróbki bieżących informacji, ale nie martw się, powstanie. A co do testów, to jeżeli mam opublikować niesprawdzone lub niepełne informacje, to wolę ich nie publikować niż narażać się na krytykę z drugiej strony, że materiał jest do niczego.
Ad.1. Inne "darmowe" dostępy to praktycznie bezsens. Co z tego, że w FreeM można za 2 złote wykupić zwiększenie limitu do 1 GB na 7 dni, kiedy dzienny limit to 150MB a do tego co około 1MB pobranych danych lub co godzinę musisz obejrzeć stronę z reklamami, które dodatkowo odliczane są od limitu
.
.
.
Ad.2. jak wyżej
Ad.3. W Orange Free na kartę (OFnK) ładujesz za 100 złotych i dostajesz 6 GB bonusu i masz 100 złotych plus 10 złotych na koncie głównym. Do tego wcześniej uruchamiasz skarbonkę i będziesz miał 5 złotych na koncie. Otrzymane w ten sposób środki sprzedajesz na allegro, przykładowo 22x5zł doładowań SMS po 3,2zł za sztukę – 22×0,2zł za przelew SMS i po odliczeniu kosztów (3% + jakaś tam drobna kwota za wystawienie) masz około 68 złotych zwrotu. Czyli w ten sposób uzyskujesz około 6,2GB transferu za 32 złotych. A jak kupisz doładowanie 100 złotych za mniejszą kwotę, przykładowo 90 złotych to wtedy 22 złote za 6,2 GB na 5 miesięcy. To na prawdę świetna oferta dla osób pracowitych, ale dużo nie zarabiających
Człowieku, Ty chyba nie wiesz, co piszesz. Skoro Ci się nie podoba, nie wchodź na tę stronę. Jakub robi gigantyczną robotę za darmo. Rozumiesz? Za darmo!
Czlowieku, tutaj nikt nie jest nic tobie winien. Don't Like, Don't Read.
Nie wiem czy to było wcześniej ale pojawiła się też mapka z zasięgiem planowanym w na grudzień 2011 całkiem dobrze to wygląda
Mapka planowanego zasięgu na grudzień wisi od samego początku. Jest podobnie bezużyteczna, jak ta z maja
Ale jak ktoś się dobrze orientuje i opracuje sobie mapę według np. informacji z Cyfrowego Polsatu to można ustalić, czy w interesującym obszarze pojawić się mają nadajniki.
Jest trochę lepsza niż ta aktualna bo ma dużą rozdzielczość i zaznaczone powiaty ale ciekawe czy prawdziwa.
Taka mapa o objętości 15 MB od początku była na stronie o (U)BDI.
.
Akurat w mojej okolicy i drodze do stolicy żadnych zmiana do końca roku nie planują. A białe plamy są wielkości starego województwa
W ten sposób modem pracuje mi z kartami Plusa i Playa.
Natomiast z kartą Aero2 (z ostatniej wrześniowej emisji) nie chce.
Najwyraźniej ta karta nie chce działać w trybie PPP tylko jako CDC ethernet (RNDIS?).
Czy Twoja karta jest też z września?
Właśnie sprawdziłem, jak to wygląda w Windows.
Gdy ustawię w PLAY ONLINE tryb "RAS(modem)" – nie chce się łączyć, pisząc "Nie możesz się połączyć przed rejestracją dostępnej sieci"
Gdy ustawię tryb "NDIS" – działa poprawnie.
Niestety w Linuxie nie mogę uruchomić trybu NDIS (Debian).
Udało mi się nawiązać połączenie bez używania trybu NDIS.
Po prostu przed wybraniem numeru (ATD*99#) należy wywołać komendę AT+CGACT=1,1
Niestety mam jeszcze jakiś problem z pppd, który ginie marnie z komunikatem "The PPP daemon has died: A modem hung up the phone (exit code = 16)"
Dokładniej dostaję:
Serial connection established.
using channel 57
Using interface ppp0
Connect: ppp0 <–> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3d642375> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xb <asyncmap 0x0> <auth chap MD5> <magic 0x106b478> <pcomp> <accomp>]
sent [LCP ConfNak id=0xb <auth pap>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x3d642375> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xc <asyncmap 0x0> <auth pap> <magic 0x106b478> <pcomp> <accomp>]
sent [LCP ConfAck id=0xc <asyncmap 0x0> <auth pap> <magic 0x106b478> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x3d642375]
sent [PAP AuthReq id=0x1 user="" password=<hidden>]
rcvd [LCP DiscReq id=0xd magic=0x106b478]
rcvd [LCP EchoRep id=0x0 magic=0x106b478 3d 64 23 75]
rcvd [PAP AuthAck id=0x1 ""]
PAP authentication succeeded
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Modem hangup
Connection terminated.
Konfiguracja pppd:
#hide-password.
connect "/usr/sbin/chat -v -f /etc/chatscripts/play"
/dev/ttyUSB0
debug
crtscts
noipdefault
ipcp-accept-local
lcp-echo-interval 60
lcp-echo-failure 5
usepeerdns
refuse-chap
refuse-mschap
refuse-mschap-v2
refuse-eap
receive-all
noauth
#nodeflate
nodetach
noccp
novjccomp
novj
user ""
password ""
Skrypt chatscript:
ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TONE' ABORT 'NO ANSWER
' ABORT DELAYED
# modeminit
'' ATZ
# ispnumber
#OK "AT+CPIN=3732"
OK "AT+CGDCONT=1,"IP","darmowy""
OK-AT-OK
# ispconnect
# postlogin
AT+CGACT=1,1 OK
ATD*99# CONNECT
Ja bym usunął z konfiguracji "user" i "password", gdyż pomimo to że podałeś noauth to pppd próbuje się uwierzytelnić (PAP AuthReq) a Aero2 tego nie wymaga i chyba z tego powodu otrzymujesz nakaz rozłączenia (LCP DiscReq).
I jeszcze jedno. W konfiguracji masz "refuse-chap" a serwer takie uwierzytelnienie proponuje: "rcvd [LCP ConfReq id=0xb <asyncmap 0×0> <auth chap MD5> …".
Hmmm, wyrzuciłem refuse-chap, ale mój pppd nadal odrzuca protokół chap.
Jeśli nie dam "refuse-pap", a zablokuję "user" i "password" to pppd sam wymyśla nazwę użytkownika (bierze hostname).
Teraz wygląda to tak:
————Log sesji ————————
Serial connection established.
using channel 36
Using interface ppp0
Connect: ppp0 <–> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xa3f88a88> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3e <asyncmap 0x0> <auth chap MD5> <magic 0x18b4f2d> <pcomp> <accomp>]
No auth is possible
sent [LCP ConfRej id=0x3e <auth chap MD5>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xa3f88a88> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3f <asyncmap 0x0> <magic 0x18b4f2d> <pcomp> <accomp>]
sent [LCP ConfAck id=0x3f <asyncmap 0x0> <magic 0x18b4f2d> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xa3f88a88]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [LCP DiscReq id=0x40 magic=0x18b4f2d]
rcvd [LCP EchoRep id=0x0 magic=0x18b4f2d a3 f8 8a 88]
Modem hangup
Connection terminated.
—- konfiguracja pppd —————
connect "/usr/sbin/chat -v -f /etc/chatscripts/play"
/dev/ttyUSB0
debug
crtscts
idle 0
refuse-pap
noauth
nodetach
noccp
To pozostał username i password w konfigu. Tylko usuń "refuse-chap". Ale prawdę powiedziawszy to chyba będziesz musiał szukać pomocy na forach. Skąd "wytrzasnąłeś" poprzedni tak rozbudowany konfig dla ppd?
Szczerze mówiąc to nie pamiętam – gdzieś z forów…
Na razie chyba dam sobie spokój z PPP bo właśnie odkryłem nowy i chyba lepszy sposób podłączenia.
Otóż analizując wynik komendy AT+CLAC znalazłem ciekawą komendę AT+NDISUPD
Po wysłaniu AT+NDISUPD=1,1,"darmowy" dioda w modemie zaświeciła się na niebiesko i uaktywnił się port wwan0 – polecenie "dhclient wwan0" ustawiło mi poprawnie adres ip, tabelę routingo i /etc/resolv.conf. Pozostał jeden problem – nie przechodzą pakiety TCP. Analizując ruch wiresharkiem widzę, że działa UDP, DNS, DHCP, ARP i parę innych, ale TCP nie przechodzi.
W logach widzę: cdc_ether 1-6:1.1: wwan0: CDC: unexpected notification 01!
więc może to jest jakiś problem ze sterownikiem cdc_ether. Jeśli nie, to może konieczna jest jakaś magiczna komenda odblokowująca TCP.
Jest jedna ciekawa wyrzucana przez AT+CACL:
^SOCKETCONT, ale niestety wszystkie próby jej wywołania kończą się odpowiedzią COMMAND NOT SUPPORT
Oczywiście pomyliłem się pisząc. Nie AT+NDISDUP tylko AT^NDISDUP !!!
Zbadałem sprawę dokładniej – to nie jest sprawa nieprzesyłania pakietów TCP.
Po prostu wireshark widzi odpowiedzi DNS dochodzące do interfejsu, ale kernel ich nie odbiera (?!!!). Kiedy odczytałem z wiresharka adres IP maszyny na którą chciałem się zalogować przez SSH i jawnie podałem ten adres wywołując SSH, to zobaczyłem w wiresharku, że mój komputer wysyła pakiet TCP i dostaje na niego odpowiedź – i koniec. Po chwili widzę jak mój komputer ponownie wysyła pakiet TCP, tak jakby nie dostał odpowiedzi. W iptables wpisałem "iptables -I INPUT 1 -j ACCEPT" więc nie jest to sprawka firewalla. Wygląda na to, że pakiety wracające z wwan0 są "trefne" – wireshark je widzi, ale kernel już nie. Jakaś czarna magia
Obejrzałem dokładnie podejrzane pakiety w wiresharku. Okazuje się, że pakiety wysyłane mają adres nadawcy i odbiorcy ustawiony na 02:50:f3:00:00:00 (oba takie same! zgodne z adresem jaki ifconfig zwraca dla wwan0). Natomiast pakiety wracające mają adres odbiorcy ustawiony na 00:01:02:03:04:05 , więc oczywiście nie docierają do kernela!
Nie wiem czy ten efekt jest zasługą:
1. Błedu w sterowniku cdc_ether
2. Błędu w działaniu e173-u2
3. Mojej błędnej obsługi e173-u2 (może jakąś komendą należy mu powiedzieć pod jaki MAC ma wysyłać odebrane pakiety?
SUKCES! E173-U2 DZIAŁA W LINUKSIE Z "WRZEŚNIOWĄ" KARTĄ!
Stwierdziłem, że nie ma co "kopać się z koniem". Skoro e173-u2 (albo sterownik scd_ether) chce mi przysyłać pakiety pod MAC adres 00:01:02:03:04:05, to ja mu ten adres zapewnię
.
użyłem "ifconfig wwan0 hw ether 00:01:02:03:04:05" i w końcu UDAŁO MI SIĘ NAWIĄZAĆ POŁĄCZENIE.
Podsumuję więc całą receptę:
1. Podłączamy minicoma do /dev/ttyUSB0
2. W minicomie wpisujemy: AT^NDISDUP=1,1,"darmowy"
3. W konsoli root'a wpisujemy:
ifconfig wwan0 hw ether 00:01:02:03:04:05
4. W konsoli root'a wpisujemy:
dhclient wwan0
i mamy działające połączenie.
Aby się rozłączyć – w minicomie wpisujemy:
AT^NDISDUP=1,0
Oczywiście można to pewnie przetłumaczyć na skrypt dla wvdial, albo napisać skrypt włączający sieć w pythonie, albo zrobić jeszcze coś innego… W każdym razie przetarłem ścieżkę.
Oczywiście, żeby rozwiązanie było "czyste", należałoby jeszcze wyjaśnić sprawę tego nieszczęsnego "przymusowego" MACa 00:01:02:03:04:05. Ja na razie mam dość
Prymitywne i dość niechlujnie napisane
, ale działające, skrypty automatyczujące podłączanie do Aero2 i odłączanie są dostępne tu: http://groups.google.com/group/comp.os.linux.hard…
Oczywiście trzeba zmienić nazwę APN z "my_apn_name" na "darmowy".
Powoli zbliża się czas przygotowania jakiegoś fajnego opisu w postaci pełnego artykułu – dla Ubuntu.
Żeby to było w pełni przydatne, skrypt powinien jeszcze wykrywać rozłączenie przez operatora.
Jak na razie jedyne wyjście to działanie z wyprzedzeniem i puszczenie w pętli:
while true; do ./e173_NDIS_off.py ; ./e173_NDIS_on.py ; sleep 57m; done
Ale nie masz pewności, że zerwanie (z dowolnego powodu) nie wystąpi wcześniej. Co dzieje się po rozłączeniu? Może jak pada interfejs to można po prostu wpiąć się w jakiś skrypt if-up/if-down?
Niestety po rozłączeniu interfejs wwan0 nadal istnieje i jest włączony, tyle, że nie przechodzą przez niego pakiety…
Komendy używane do obsługi trybu NDIS są nieudokmentowane (to co wiem, to z wyniku komendy AT+CACL i domysłów).
Zauważyłem jedynie, że po rozłączeniu zmienia się wynik komendy AT^DHCP? :
AT^NDISDUP=1,1,"darmowy"
OK
AT^DHCP?
^DHCP:207b1e4e,c0ffffff,17b1e4e,17b1e4e,e7029c1,127029c1,384000,384000
OK
AT^NDISDUP=1,0
OK
AT^DHCP?
+CME ERROR: no connection to phone
Może więc skrypt mógłby okresowo sprawdzać wynik komendy AT^DHCP? i na tej podstawie decydować o próbie ponownego podłączenia?
Sprawdzę to i w razie czego podeślę poprawiony skrypcik.
Gdyby ktoś wiedział coś więcej o komendach z grupy AT^… to cenne byłoby podzielenie się tą wiedzą
AT są inne dla każdego modemu, czasem dla serii modemów. Co do NDIS to routery i Windows nie mają problemu z wykryciem utraty połączenia, więc i w Linuksie da się ro zrobić bez aktywnego monitorowania, które jest najgorszym możliwym rozwiązaniem.
Sprawdziłem porty dodatkowe – diagnostyczny
/dev/ttyUSB0 i port który gdzieś był nazwany pcUI (do interfejsu graficznego naPC?) /dev/ttyUSB1 . Niestety na pierwszy rzut oka nic ciekawego nie pojawia się tam przy "przymusowym rozłączeniu".
Być może należy jakoś zainicjować raportowanie stanu modemu na tych portach…
Sprawdziłem jeszcze raz na innej maszynie i wydaje się, że w raportach wysyłanych na /dev/ttyUSB2 widać komunikat "^SRVST=2" przy połączeniu i "^SRVST=1" przy rozłączeniu. Można to użyć do wyzwolenia akcji odnawiania połączenia.
Bardzo prymitywna wersja "dialera" do e173 w trybie NDIS dla Linuxa jest właśnie udostępniona na grupie alt.sources (link bezpośredni: http://groups.google.com/group/alt.sources/browse… ). Program jest napisany w Pythonie + Glade + GTK. wyświetla siłę sygnału, pozwala zestawić i rozłączyć połączenie i wydaje się w miarę poprawnie obsługiwać zerwnie połączenia przez operatora oraz chwilowe zaniki sygnału (testowałem to ekranując modem folią aluminiową
. Może komuś się to przyda. Kod jest "public domain", więc można go usprawniać jak kto chce. Miło będzie, jeśli ktoś podzieli się poprawioną wersją. Oczywiście w kodzie e173.py trzeba zmienić nazwę APN z my_apn_name na darmowy.