Skrypt windowsowy podtrzymujący połączenie Aero2 przed usypianiem

[tomaszmister]

UPDATE 26-09-2015:

W jednym z kolejnych wpisów poniżej dodałem nowszą wersję skryptu, zawierająca drobne usprawnienia:
skrypt podtrzymujący połączenie Aero2.zip
Nie wprowadza ona jednak żadnych zmian w głównej części skryptu, dlatego osoby, dla których pierwsza wersja skryptu zamieszczona w tym wpisie okazała się przydatna, absolutnie nie muszą martwić się pobieraniem nowszej wersji i ponownym edytowaniem jej ustawień.
Natomiast osoby, które jeszcze zechcą wypróbować skrypt, zapraszam do pobrania właśnie tej nowszej wersji!
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Pozwoliłem sobie założyć nowy wątek, aby podzielić się skryptem pomagającym rozwiązać, albo w możliwie dużym stopniu załagodzić problem "usypiania połączenia Aero2", jaki pojawił się od około czerwca 2015 r.

Jest to problem polegający na nagłym zamieraniu ruchu w poprawnie nawiązanym połączeniu, wymagający jego zrestartowania, aby odzyskać sprawnie działające połączenie, co w praktyce ogromnie przeszkadza w korzystaniu z Aero2.

Problem ten został zaobserwowany i opisany przez wielu użytkowników na forum oraz przez Jakuba m.in. w dwóch poniższych artykułach:
http://jdtech.pl/2015/09/aero2-uzytkowni...orzej.html
http://jdtech.pl/2015/07/problemy-z-szyb...-2015.html

Przydatnym sposobem zapobiegania takiemu "usypianiu" połączenia Aero2 jest ciągłe utrzymywanie ruchu w połączeniu poprzez wysyłanie zapytań ping (metodę tą poznałem właśnie na forum jdtech oraz w komentarzach pod artykułami na blogu). Sposób ten sumarycznie generuje bardzo niewielkie zużycie transferu danych, rzędu kilku MB na godzinną sesję połączenia, dzięki czemu połączenie Aero2 nie będzie niepotrzebnie obciążone.
Jednak "ręczne nastawianie" polecenia ping również stałoby się bardzo niewygodne, tym bardziej że po każdym rozłączeniu sesji przez kod captcha konieczne byłoby ponowne wznowienie polecenia ping, najlepiej ze zmienionym adresem, gdyż adres badany przez ping po przejściu w tryb captcha staje się na pewien czas "spalony" i trzeba go wymienić (o takim dziwnym zachowaniu ping w sieci Aero2 dowiedziałem się również z jednego z artykułów Jakuba).
Co gorsze jednak, wysyłanie zapytań ping, choć w dużym stopniu pomaga, jednak (chyba także niezależnie od rozmiaru przesyłanego pakietu, jak zauważył to jeden z użytkowników w komentarzach na blogu) nie chroni na 100% przed spadnięciem połączenia w stan uśpienia.

Dlatego aby rozwiązać te niedogodności przygotowałem skrypt windowsowy, który za pomocą powtarzanych zapytań ping stara się podtrzymać połączenie Aero2 przed usypianiem, a ponadto jeśli już dojdzie do uśpienia połączenia, wówczas skrypt wykryje to i sam zrestartuje połączenie.

Skrypt ponadto potrafi rozpoznać przejście w tryb wpisywania captchy, aby odróżnić ten tryb od przejścia w stan uśpienia, dzięki czemu w trakcie wpisywania kodu captchy skrypt nie dokona niepotrzebnego restartowania połączenia.

Cały skrypt, zawierający także obszerne komentarze, umieściłem w skompresowanym katalogu w załączniku:
  podtrzymywanie połączenia Aero2.zip (Rozmiar: 64,54 KB / Pobrań: 860)

Po rozpakowaniu załącznika, oprócz skryptu (będzie to plik skrypt podtrzymujący połączenie Aero2.cmd) będzie w nim znajdować się jeszcze drugi plik: PortQry.exe

Jest to niewielkie dodatkowe narzędzie Microsoftu, działające w wierszu poleceń, bezpłatnie udostępnione pod adresem: https://www.microsoft.com/en-us/download...x?id=17148

Z jego pomocą skrypt wykrywa tryb wpisywania captcha (gdyż sam ping niestety nie mógłby posłużyć w tym celu).

Po rozpakowaniu załącznika katalog zawierający obydwa pliki można umieścić w dowolnym miejscu. Następnie warto jest utworzyć skrót do skryptu, gdyż wtedy we właściwościach skrótu dostępna będzie opcja umożliwiająca uruchomienie okienka skryptu w postaci zminimalizowanej. Tak przygotowany skrót można już wygodnie dodać do katalogu "Autostart".



Przed rozpoczęciem korzystania ze skryptu należy otworzyć go za pomocą edytora tekstowego (takiego jak tradycyjny windowsowy Notatnik, choć wspaniale do edycji plików skryptów oraz wszelkich podobnych nadaje się darmowy program Notepad++, który ogromnie ułatwia czytanie takich plików poprzez kolorowanie ich składni).

W początkowej części skryptu znajdują się ustawienia, które można dostosować (są one bardzo szczegółowo opisane za pomocą komentarzy).

Najważniejsze jest pierwsze ustawienie, w którym należy podać nazwę połączenia Aero2, pod jaką zostało ono skonfigurowane w systemie.

Następnie istotne może okazać się drugie ustawienie, wskazujące czy skrypt powinien automatycznie nawiązywać połączenie po tym, gdy dokona jego rozłączenia (stanie się tak w sytuacji wykrycia połączenia uśpionego).

Domyślnie skrypt ma tą opcję załączoną, a więc sam nawiąże połączenie w razie jego restartowania przy stanie uśpienia połączenia.
Takie ustawienie sprawdzi się najczęściej dla użytkowników Windows XP, Vista i 7, a dokładniej mówiąc dla tych użytkowników, którzy nie korzystają z dodatkowego programu w celu automatycznego wybierania połączenia Aero2 (gdyż w tych systemach w ustawieniach połączenia istenie opcja automatycznego wznowienia połączenia po rozłączeniu i zapewne większość użytkowników korzysta właśnie z takiej konfiguracji).

Jeśli natomiast do automatycznego włączania połączenia Aero2 wykorzystywany jest dodatkowy program, np. program Aero3 z zaznaczoną opcją "Zawsze łącz Aero2", wówczas warto jest tą opcję w skrypcie wyłączyć, gdyż w przeciwnym wypadku automatyczne wznawianie połączenia przez skrypt będzie "gryzło się" z tą samą funkcją wykonywaną przez zewnętrzny program.
A więc wyłączenie tej opcji sprawdzi się najczęściej dla użytkowników Windows 8 i zapewne również 10, gdyż w tych systemach nie ma już opcji automatycznego wznawiania połączenia w jego systemowej konfiguracji, dlatego trzeba w nich stosować funkcję wybierania połączenia pochodzącą z dodatkowych programów, np. w doskonałym programie Sebusa Aero3.


Dziś w dzień postaram się opisać jeszcze dokładniej działanie skryptu i podać szczegóły techniczne.
Natomiast w samym skrypcie zawarte są bardzo dokładne komentarze, także one również powinny pomóc w razie wszelkich problemów.

Na pewno tylko jeszcze jedną ważną uwagą jest to, że skrypt przystosowany jest do działania z połączeniami RAS.
Dokładniej chodzi tutaj o używane przez skrypt polecenie rasdial, za pomocą którego wykonywane jest rozłączanie i łączenie w przypadku konieczności restartu w razie wykrycia stanu uśpienia połączenia.
Gdyby można było to polecenie zastąpić poleceniem odpowiednim dla połączeń NDIS, lub poleceniem sterującym routerem z podłączonym do niego modemem, wówczas skrypt powinien zadziałać również dla takich konfiguracji, niestety nie mam możliwości przetestowania takich konfiguracji, dlatego w skrypcie ograniczyłem się do zastosowania polecenia rasdial.


Mam nadzieję, że skrypt ten pomoże choć trochę załagodzić ten fatalny problem jaki dotknął wielu użytkowników Aero2 i uczyni korzystanie z niego zdecydowanie bardziej znośnym!

Choć najlepiej byłoby, jeśli problem ten zostałby naprawiony u źródła w Aero2 :-)

Pozdrawiam wszystkich czytelników jdtech!

[szopen]

nie wiem jak wygląda kwestia licencyjna dotycząca redystrybucji
"PortQry Command Line Port Scanner Version 2.0 "
prawdopodobnie należało zamieścić oryginalny instalator - wyświetla on licencję MS wymagającą zaakceptowania przez użytkownika końcowego

a co do samego skryptu - "szacun" naprawdę dobrze skomentowany, mógłby być wzorem dla niejednego studenta
działanie prześledziłem wprawdzie jedynie "na sucho" i prawie nie mam uwag, no może poza tymi:
- umieściłeś w nim dwukrotnie ten sam adres IP do pingowania (serwera OpenDNS) co uniemożliwi działanie skryptu bez edycji, czyli w przypadku użytkowników nie umiejących samodzielnie wybrać odpowiednich adresów (i właściwie wyedytować pliku) - mój błąd faktycznie adresy są różne choć wizualnie podobne (różnią się jedną cyfrą czego nie zauważyłem)
- przydałoby się zatem choćby kilka przykładów i/lub rozwiązanie uniemożliwiające użycie skryptu bez wstępnej edycji (np. adresy można zastąpić ciągiem x.x.x.x)
- sposób redystrybucji piku PortQry.exe

wątek przenoszę tam gdzie są inne rozwiązania tego typu i podwieszam - niech o użyteczności wypowiedzą się użytkownicy realnie używający Aero2 jako podstawowego łącza do internetu

[tomaszmister]

Szopen dziękuję bardzo za przejrzenie skryptu, przeniesienie go i dobre słowa o nim :-) !!

Najważniejsze właśnie czy po przetestowaniu przez innych użytkowników spełni on oczekiwania i okaże się choć trochę pomocny w załagodzeniu tego bardzo męczącego problemu powstałego w Aero2.

Bo w rzeczywistości jest to dość prymitywny skrypt, ale założeniem było właśnie, aby wynikowy skrypt był jak najprostszy, stosujący najprostsze środki, nie nakładający żadnego zbędnego obciążenia, aby tylko dać ulgę użytkownikom borykającym się z tym problemem powstałym w Aero2.

(tym co z pewnością może razić w skrypcie jest częste korzystanie z goto, jednak w skryptach windowsowych brakuje wielu elementów pozwalających ładniej zapisać oczekiwany schemat działania i w rezultacie w wielu miejscach goto służy w tym skrypcie jako zastępnik dla pętli do-while, instrukcji break, a czasami po prostu pozwalał na uniknięcie niepotrzebnego skomplikowania skryptu).

Sam przez dwa tygodnie testowałem go pod Windows XP oraz Windows 7 z modemami Huawei E173u-2 (a więc modemem szczególnie cierpiącym na tym problemie) oraz na jeszcze jednym modemie Huawei (był to chyba model E176), również niskiej kategorii, który także doświadczał tego problemu.
I na podstawie tych testów wydaje się, że skrypt ten będzie mógł zapewnić ulgę dla użytkowników (korzystających z Windows oraz z podatnych na ten problem modemów, a wydaje się, że może być to bardzo duża grupa użytkowników Aero2) i przynajmniej załagodzić ten problem, choć oczywiście najlepiej, gdyby problem ten został rozwiązany odgórnie przez Aero2, ale nie możemy wiedzieć, ani liczyć na to, czy kiedykolwiek to nastąpi

Adresy IP badane przez ping, które umieściłem w skrypcie oczywiście wskazują na Open DNS, jednak celowo są to dwa różne adresy: 208.67.220.220 i 208.67.222.220 (różniące się trzecim oktetem).

Natomiast faktycznie w przypadku programu PortQry.exe zupełnie nie wiedziałem, jak wolno jest podejść do możliwości jego rozpowszechniania.
Dla ułatwienia użytkowników pomyślałem o dołączeniu go razem ze skryptem.
Plik z tym programem po pobraniu ze strony Microsoftu można rozpakować (z pominięciem korzystania z samorozpakowującego się archiwum), a wówczas po rozpakowaniu otrzymamy katalog zawierający właśnie program PortQry.exe oraz dwa malutkie pliki tekstowe: readme oraz eula, w której jednak znajduje się jedynie standardowa formułka o braku odpowiedzialności Microsoft za efekty użycia programu.

Przygotuję jeszcze dokładniejszy opis działania skryptu i wóczas umieszczę w nim skrypt oddzielnie, a program PortQry zamieszczę jako odsyłacz do pobrania ze strony Microsoft
(tutaj dla uproszczenia zamieściłem program i skrypt w jednym katalogu, ale równie dobrze po pobraniu PortQry użytkownicy mogą umieścić go sobie np. w katalogu Windows\system32, na wypadek gdyby okazał się on przydatny także w przyszłości, w sytuacjach niezwiązanych z tym skryptem).

[szopen]

tomaszmister napisał(a):(różniące się trzecim oktetem).

zwracam honor - faktycznie adresy są różne - wyszła moja ślepota

[tomaszmister]

To absolutnie nie jest ślepota, tylko normalne działanie ludzkiego umysłu - po prostu bardzo ciężko jest nam bezbłędnie wyłapywać tak drobne różnice w cyfrach - z tym niech męczą się maszyny :-)
A w dodatku był to mój błąd, bo akurat wybrałem taką parę adresów Open DNS, która różni się trzecim oktetem, zamiast wybrać parę różniącą się czwartym ostatnim oktetem - wówczas człowiekowi byłoby łatwiej odróżnić te adresy.
Ale faktycznie pomysł z początkowym zapisem adresu w skrypcie jako x.x.x.x byłby bardzo dobry, aby dzięki temu użytkownicy mogli już od początku ustawić pingowane adresy według własnej woli.

[K4r0lSz]

Na Windows 8.1 zgłasza się "obrońca Windowsa", Filtr Windows SmartScreen, który blokuje uruchomienie skryptu, trzeba dodatkowo kliknąć Uruchom mimo to - jak raz zezwolimy, to przy kolejnych razach nie pojawia się już.
Na moje oko skrypt wygląda dobrze i jest świetnie opisany

[penknife]

Dlaczego kolega nie zastosował "@echo off" na początku skryptu, a używa "@" przy każdym poleceniu ?

Kod:

::  poniższe polecenie służy jako przenośna wersja instrukcji zatrzymującej skrypt na 2 sekundy
@ping 127.0.0.1 -n 2 >nul

powyższe zatrzymuje na 1 sekundę ! (-n X zatrzymuje na N sekund, gdzie X=1+N)
Zamiast pisać za każdym razem "ping 127.0.0.1 -n 2 >nul" można:

Kod:

set "sleep=ping 127.0.0.1 -n 2 >nul &ping >nul 127.0.0.1 -n "
%sleep% 2

Które przez zmienną sleep, wykonuje najpierw czekanie przez 1 sekundę, po czym przechodzi do zadanej liczby sekund.

Może zamiast czekać przed wznowieniem połączenia, zaczekać po rozłączeniu ?
Jeśli ktoś przypisze wartość "tak" do zmiennej wznawianie_restartowanego_polaczenia z choćby jedną dużą literą wówczas if zadziała niepoprawnie, należy zapisać:

Kod:

@if /i %wznawianie_restartowanego_polaczenia% == tak ...

P.S. Ja w celu szukania poprawnej odpowiedzi stosuję:

Kod:

ping ... |find /i "ttl=">nul &&(echo poprawna odpowiedz & goto sprawdz_ponownie )||(echo niepoprawna odpowiedz & goto zweryfikuj)

P.P.S. Dla osób, które uruchamiają skrypt jako administrator lub mają błąd ze znalezieniem PortQry(które jest w katalogu skryptu), zalecam na początku skryptu (przed linijką ":poczatek") dodanie:

Kod:

::Przenosi katalog działań skryptu do folderu skryptu
@pushd "%~dp0"
rem LUB
::Dodaje ścieżkę do folderu skryptu dla poszukiwanych programów do zmiennej PATH
@set path=%~dp0;%path%

[tomaszmister]

K4r0lSz i Penknife dziękuję za uwagi o skrypcie !!

I przepraszam za tak opóźnione odpisanie, jakoś nie mogłem zebrać się aby przygotować dokładniejszy opis skryptu, a w dodatku przez pewien czas wydawało mi się, że problem zamierania połączenia stawał się ostatnio jakby trochę łagodniejszy (choć oczywiście może to być odczucie bardzo niedokładne, a w dodatku pewnie tylko lokalne), sądziłem że może Aero2 zaczęło nareszcie naprawiać ten problem, niestety okazało się, że o ile być może nastąpiła (w mojej lokalizacji) lekka poprawa i połączenie nie zamiera aż tak często jak wcześniej, to jednak problem ten nadal cały czas występuje, wciąż pozostaje nierozwiązany przez Aero2.

Dotąd bardzo rzadko korzystałem z Windows 8, dlatego nie pomyślałem o możliwym ostrzeżeniu zgłaszanym przez filtr SmartScreen przy pierwszym uruchomieniu skryptu. Zapewne taka jest już uroda działania SmartScreen i pewnie przy każdym nowym uruchamianym skrypcie musi zachować się on w ten sposób.

Znak @ tłumiący pokazywanie poleceń skryptu na wyjściu stosowałem początkowo, w trakcie pisania skryptu przed każdym poleceniem w celach łatwiejszego debugowania, ale faktycznie o wiele łatwiej i czytelniej jest zastosować echo off tuż na początku skryptu.

Również przy opisie polecenia "ping 127.0.0.1 -n 2" popełniłem błąd logiczny, podając że tworzy ono przerwę ok. 2 sekund, gdyż faktycznie powstanie tutaj przerwa ok. 1 sekundy, jako że sekunda to właśnie odstęp pomiędzy kolejnymi wysyłanymi ping-ami, a tutaj zostają one wysyłane dwukrotnie.

Nie zdawałem sobie również sprawy z tego, że uruchomienie skryptu pod Windows Vista i wyższymi w trybie "jako Administrator" powoduje zmianę bieżącego katalogu wykonywania się skryptu (domyślnie chyba na katalog systemowy Windows\system32), przez co skrypt mógłby nie dać rady odnaleźć programu PortQry.exe, jeśli zostałby on umieszczony w katalogu razem ze skryptem (a dokładniej w katalogu nie wskazywanym przez zmienną środowiskową PATH, a taki właśnie najczęściej będzie dowolnie wybrany lub utworzony katalog, w którym zostanie umieszczony skrypt).
Na szczęście sposób z poleceniem pushd "%~dp0", wymuszającym powrót do katalogu ze skryptem jest świetny i ładnie rozwiązuje ten problem!

Również porada o wyłączeniu sprawdzania wielkości liter podczas porównywania ciągu znaków przypisanego do ustawienia/zmiennej "wznawianie_restartowanego_polaczenia" jest bardzo słuszna (na wypadek gdyby użytkownik przypisał ciąg znaków np. "Tak" lub "TAK", aby zostały one potraktowane jednakowo).

Wszystkie te porady dodałem do poprawionej wersji skryptu.

[tomaszmister]

Pozwoliłem sobie dopisać jeszcze jeden oddzielny wpis, aby umieścić w nim poprawioną wersję skryptu:

  skrypt podtrzymujący połączenie Aero2.zip (Rozmiar: 4,95 KB / Pobrań: 926)

Jest to wersja oznaczona jako 1.1 (w odróżnieniu od wersji pierwszej, w domyśle 1.0, zamieszczonej w pierwszym wpisie na początku wątku).

Zostały w niej wprowadzone poprawki na podstawie otrzymanych uwag i porad w wątku, oraz poprawki w komentarzach (tj. przede wszystkim na początku skryptu dopisana została krótka instrukcja, opisująca jego przygotowanie do użycia wraz z adresem do pobrania programu PortQry.exe).

Ta poprawiona wersja nie wprowadza żadnych zmian w działaniu głównej części skryptu, dlatego osoby, dla których pierwsza wersja skryptu mogła okazać się w jakimś stopniu przydatna, nie muszą martwić się pobraniem i ponownym edytowaniem ustawień tej nowszej wersji, gdyż pierwsza wersja skryptu wykonuje dokładnie to samo.

Ponadto w wersji 1.1 na wszelki wypadek nie dołączałem już programu PortQry.exe, aby nie naruszyć możliwych wymagań licencyjnych dotyczących jego udostępniania.

Dlatego w przypadku pobierania po raz pierwszy tej wersji skryptu, oprócz sprawdzenia poprawności ustawień zapisanych w początkowej części skryptu (i w razie potrzeby wyedytowaniu ich - wszelkie objaśnienia o znaczeniu ustawień zostały zapisane w komentarzach w skrypcie), konieczne jest także pobranie programu PortQry.exe.

(Jest to niewielkie, darmowe narzędzie Microsoftu działające w wierszu poleceń, dzięki któremu skrypt będzie mógł rozpoznać tryb wpisywania captcha;
aby go pobrać należy przejść pod adres: https://www.microsoft.com/en-us/download...x?id=17148,
następnie po pobraniu pliku i rozpakowaniu go, otrzymany program PortQry.exe wystarczy przenieść do katalogu, w którym skrypt będzie mógł go odnaleźć, a więc np. może to być ten sam katalog, w którym umieszczony został skrypt)

------------------------------------------------------------------------------------------------------------------

OPIS DZIAŁANIA SKRYPTU

Poniżej zamieściłem opis sposobu działania skryptu, aby można było rzucić okiem i już przed jego pobraniem sprawdzić, czy skrypt ten w ogóle ma jakikolwiek sens :-)

Ale po dłuższym już testowaniu myślę, że może on przynieść znaczną ulgę użytkownikom Aero2, dla których problem zamierania ruchu w nawiązanym poprawnie połączeniu stał się nieznośny, w praktyce uniemożliwiający normalne korzystanie, dopóki nie zostanie on faktycznie naprawiony przez Aero2.

Głównym celem skryptu jest podtrzymywanie połączenia Aero2 przed "usypianiem" poprzez wysyłanie zapytań ping nastawionych z niewielkim pakietem danych (w tej wersji skryptu domyślnie jest on ustawiony na 512 bajtów).

Obciążenie transferu wygenerowane w ten sposób jest bardzo niewielkie, rzędu kilku MB na godzinną sesję połączenia, co odpowiada wykorzystaniu ok. 1 KB/s.

Dzięki temu metoda ta nie obciąża w stopniu odczuwalnym i tak skromnego połączenia Aero2, jak mogłaby to już zrobić inna metoda zastępcza, np. nastawianie radia internetowego.

Ponieważ jednak wysyłanie zapytań ping nie stanowi całkowitego zabezpieczenia przed usypianiem połączenia (a jedynie wydaje się znacząco zmniejszać częstość występowanie usypiania), dlatego skrypt bada zwracane odpowiedzi i w przypadku rozpoznania stanu uśpienia połączenie zostanie automatycznie zrestartowane.

Przez większość czasu skrypt zajmuje się wykonywaniem pętli:

Kod:

:podtrzymywanie_i_testowanie_polaczenia

ping -n 3 -l %rozmiar_pakietu% %badane_IP% > nul

if %errorlevel% EQU 0 goto :podtrzymywanie_i_testowanie_polaczenia

Pętla ta wysyła trzykrotnie zapytanie ping (rozmiar pakietu oraz badany adres IP są zapisane w ustawieniach skryptu).

Jeśli zapytania zakończą się pomyślnie, wówczas zmienna errorlevel będzie mieć wartość 0 i wtedy wykonywanie pętli (wysłanie kolejnych trzech zapytań ping) będzie kontynuowane.

Odpowiedź zwróconą przez ping skrypt może zbadać dokładniej za pomocą polecenia find, wyszukując w niej określony ciąg znaków.
Ponieważ jednak przeszukiwanie nawet krótkiego ciągu znaków przez polecenie find powoduje na chwilę wzrost obciążenia pracy procesora (można to zaobserwować wyraźniej na słabszych maszynach - obciążenie to jest oczywiście niewielkie, ale wymaganiem dla tak prostego skryptu działającego nieustannie w tle musi być to, aby jak najbardziej zminimalizować generowane przez niego obciążenie), dlatego skrypt korzysta z find tylko gdy stanie się to konieczne.

W razie niepowodzenia działania ping zmienna errorlevel przyjmie wartość 1.

Negatywna odpowiedź ping (gdy errorlevel przyjmie wartość 1) może mieć treść "Host docelowy jest nieosiągalny" lub "Upłynął limit czasu żądania".

Aby dokonać ich rozróżnienia skrypt wysyła jeszcze jedno zapytanie ping i tym razem już dokładniej bada zwróconą odpowiedź za pomocą find.

Odpowiedź "Host docelowy jest nieosiągalny" oznacza brak nawiązanego połączenia internetowego. W takiej sytuacji skrypt, dla uproszczenia działania powróci do pętli głównej, podtrzymującej i testującej połączenie. Z tego względu skrypt nie dokonuje rozróżnienia pomiędzy połączeniem poprawnie działającym, a całkowicie wyłączonym, w obydwu przypadkach kontynuuje pracę w tle i w razie nawiązania połączenia płynnie przejdzie do jego podtrzymywania i testowania.

Dlatego w przypadku negatywnej odpowiedzi ping, poszukiwaną odpowiedzią jest "Upłynął limit czasu żądania".
W przypadku połączenia Aero2 (i przy założeniu, że pingowana maszyna cierpliwie udziela pozytywnych odpowiedzi) taka odpowiedź oznacza, że połączenie weszło w stan uśpienia - lub przeszło do trybu wpisywania captcha.

W tym momencie skrypt musi sprawdzić, czy połączenie faktycznie weszło w tryb wpisywania captcha, aby nie pomylić go ze stanem uśpienia, gdyż wtedy wykonany zostałby niepotrzebnie restart połączenia, co tylko przeszkadzałoby we wpisywaniu kodu captcha.
Do wykrycia trybu wpisywania captcha niestety nie nada się samo polecenie ping, dlatego w tym celu konieczne stało się skorzystanie z dodatkowego narzędzia PortQry.

Jeśli połączenie znajdzie się w trybie wpisywania captcha, wówczas polecenie:

Kod:

portqry -n bdi.free.aero2.net.pl -e 8080 -q

bardzo sprawnie zwróci w errorlevel wartość 0
(w takiej sytuacji skrypt przejdzie do pętli oczekującej na zakończenie trybu captcha - gdyż nigdy nie wiadomo, jak długo on potrwa - a gdy już skończy się tryb captcha, skrypt powróci do początkowej pętli kontynuującej podtrzymywanie i testowanie połączenia).

W przeciwnym przypadku wartość errorlevel będzie różna od 0.
Po zbadaniu zwracanych wartości udało się ustalić, że wartości różne od 2 (i różne od 0) wystąpią przy połączeniu uśpionym.

W przypadku poprawnie działającego połączenia i nie będącego w trybie captcha, powyższe polecenie portqry zwróci w errorlevel wartość 2.
Czasami może się jednak zdarzyć wartość 2 zostanie zwrócona także wtedy, gdy połączenie znajduje się w stanie uśpienia.

Nie udało mi się ustalić tutaj już żadnej dokładniejszej zależności, dlatego po otrzymaniu po wykonaniu powyższego polecenia portqry wartości 2, skrypt wykona jeszcze jedno badanie za pomocą ping i po otrzymaniu jego odpowiedzi już ostatecznie podejmie decyzję, czy połączenie jest OK - a wtedy powróci do początkowej pętli głównej podtrzymującej i testującej połączenie, czy też doszło do stanu uśpienia - a wtedy skrypt wykona zrestartowanie połączenia.

Fragment wykonujący restartowanie połączenia znajduje się tuż pod koniec skryptu:

Kod:

rasdial %nazwa_polaczenia% /disconnect > nul

if /I %wznawianie_restartowanego_polaczenia% == tak (
ping 127.0.0.1 -n 2 > nul
rasdial %nazwa_polaczenia%
)

Wyłączenie, a następnie ponowne nawiązanie połączenia odbywa się za pomocą polecenia rasdial.
To właśnie tylko to polecenie ogranicza działanie skryptu do połączeń Aero2 skonfigurowanych w systemie jako połączenia typu RAS.

Jeśli istnieje polecenie umożliwiające wyłączenie i włączenie połączenia skonfigurowanego jako NDIS, albo analogiczne polecenie umożliwiające restartowanie połączenia Aero2 podłączonego poprzez router, wówczas nic nie stałoby na przeszkodzie, aby skrypt ten mógł posłużyć również przy takich konfiguracjach (nie miałem możliwości przetestowania działania na takich konfiguracjach, dlatego ograniczyłem się tylko do polecenia rasdial).

Po wykonaniu rozłączenia skrypt sprawdza ustawienie/zmienną wznawianie_restartowanego_polaczenia.

Jeśli została ona ustawiona na "tak", wówczas skrypt sam ponownie włączy połączenie, aby w ten sposób wykonany został jego pełny restart i stan uśpienia został "naprawiony".

Na wszelki wypadek skrypt odczeka około 1 sekundę, gdyż błyskawiczne nawiązywanie połączenia natychmiast po jego rozłączeniu często kończy się niepowodzeniem.
Oczywiście czasem może zdarzyć się, że nawiązywanie połączenia przez skrypt zakończy się błędem z jakiegoś jeszcze innego powodu, a wtedy będziemy musieli już wznowić je ręcznie.

Jeśli jednak w systemie skonfigurowany został jeszcze inny program, służący do automatycznego nawiązywa połączenia Aero2 (bardzo często jest to konieczne pod Windows 8 / 10, gdyż systemy te nie posiadają już opcji automatycznego wznawiania połączenia po rozłączeniu we właściwościach połączenia), np. program Aero3 z zaznaczoną opcją "Zawsze łącz Aero2", wówczas warto jest wyłączyć w ustawieniach skryptu opcję wznawianie_restartowanego_polaczenia (jest to dokładnie opisane także na początku skryptu, w sekcji ustawień), gdyż w takiej sytuacji wznawianie połączenia przez skrypt "pokrywałoby się" z tą samą funkcją świadczoną przez dodatkowy program, co mogłoby prowadzić do błędów podczas wznawiania restartowanego po uśpieniu połączenia.

Na koniec wyjaśnienia wymaga jeszcze tylko to, że skrypt korzysta do badania poleceniem ping z dwóch różnych adresów IP i w razie wykrycia podejrzenia problemów z połączeniem (co może wskazywać, że połączenie przeszło właśnie przez tryb wpisywania captcha, a po szybkim wpisaniu captcha przez użytkownika skrypt może nawet nie zdążyć uchwycić pojawienia się tego trybu), dokonuje ich zamiany.
Jest to konieczne, gdyż gdyby skrypt zbadał poleceniem ping dany adres IP w momencie, gdy połączenie znajduje się w trybie captcha, to wówczas po zakończeniu tego trybu adres ten pozostałby na pewien czas "spalony" do dalszego badania pingiem (o tym dziwnym zachowaniu ping w Aero2 dowiedziałem się z jednego z artykułów Jakuba) i w efekcie wkrótce po wyjściu z trybu captcha skrypt błędnie uznawałby połączenie za uśpione i niepotrzebne dokonywał jego restartowania.

Podsumowując, skrypt nie jest tak strasznie ciężki, jak wskazuje na to jego powyższy opis :-), został on zrobiony z myślą o tym, aby można było uruchomić go do ciągłej pracy w tle, by jego wpływ na obciążenie dla połączenia i systemu był niezauważalny, aby dzięki temu mógł on załagodzić cierpienia użytkowników Aero2 dotkniętych problemem usypiania połączenia, zanim problem ten nie zostanie faktycznie naprawiony przez Aero2.

[penknife]

Przydało by się jeszcze sprawdzać na początku skryptu czy PortQry istnieje, np.:

Kod:

set PortQry.istnieje=nieprawda
if /i exist "%~dp0PortQry.exe" set PortQry.istnieje=prawda
for %%q in ("PortQry.exe") do if /i "%%~n$PATH:q"=="PortQry" set PortQry.istnieje=prawda
if /i "%PortQry.istnieje%" neq "prawda" echo Nie znaleziono PortQry.exe i skrypt zakończy dziłanie>&2 &pause & goto :eof

oraz do poleceń ping dołączyłbym parametr:
-w LiczbaMilisekundOczekiwania

[tomaszmister]

Penknife dziękuję za ten pomysł, sposób sprawdzenia obecności portqry jest bardzo fajny!

Pomyślałem jednak, żeby nie dodawać go już do skryptu, w myśl zasady, że przy tego typu skryptach raczej lepiej unikać ich nadmiernego rozbudowywania oraz biorąc pod uwagę, że użytkownik skryptu ma pełną wiedzę o jego działaniu i świetnie poradzi sobie nawet bez pomocniczych podpowiedzi ze strony skryptu.

Natomiast w przypadku ograniczenia czasu oczekiwania na odpowiedź przez ping, nie chciałem go wprowadzać w obawie, że ustawienie takiego czasu na podstawie testów i czasu dobranego na danym systemie może nie sprawdzić się tak samo dobrze na innych systemach (byłoby to trudne do zbadania), dlatego wolałem już tego nie dodawać.


Bardzo mnie tylko ciekawi, czy może osoby korzystające z Avasta zauważyły w ostatnim czasie problemy w działaniu tego skryptu?

Bo sam od około jednego-dwóch tygodni napotkałem na bardzo dziwny problem.

Mianowicie polecenie portqry zaczęło zwracać odpowiedzi inne niż dawniej, a więc inne, niż oczekuje skrypt, przez co mogło dochodzić do błędów w jego działaniu, a w szczególności skrypt może wtedy "utknąć" w pętli oczekującej na zakończenie trybu wpisywania captcha (będzie to wtedy widoczne w komunikatach pokazywanych przez skrypt).

Dokładniej mówiąc odpowiedzi zwracane przez polecenie portqry (testujące dostępność strony z captcha) stały się w dziwny sposób praktycznie ciągle takie same, tzn. takie same zarówno podczas poprawnego połączenia, jak i w trybie wpisywania captcha (przez co skrypt nie mógłby już odróżnić tych dwóch stanów), a w dodatku często także w stanie uśpienia połączenia odpowiedź była też taka sama.

Odpowiedzi przychodziły też podejrzanie błyskawicznie, ponieważ normalnie tylko odpowiedź w trybie captcha przychodziła błyskawicznie, a w pozostałych trybach potrzebne było kilku sekundowe, lub nawet dłuższe oczekiwanie.

Objawy te nasunęły myśl, że pokazywana odpowiedź z portqry nie jest "prawdziwa" (a przynajmniej nie za każdym razem), ale pochodzi z "jakiegoś cache".

Dalsze poszukiwania i testy doprowadziły do ustawień "osłony WWW" Avasta (ang. Avast Web Shield).
Gdy na jej zakładce "wykluczenia" dodałem jako proces wykluczony PortQry.exe, wówczas problem ten ustąpił !!

Wygląd więc na to, że osłona WWW w Avast na niektórych systemach może spowodować negatywny wpływ na korzystanie z portqry, w jakiś sposób blokując uzyskanie przez portqry za każdym (niemal) razem nowej odpowiedzi.

Nie mogę tylko zrozumieć, jakie zjawisko tutaj zachodzi

Dlatego bardzo mnie ciekawi, czy osoby krzystające z Avast oraz tego skryptu (o ile w ogóle istnieją takie osoby :-)) zauważyły taki problem w ostatnim czasie.
Jeśli tak, to środkiem zaradczym wtedy może być dodanie PortQry.exe do wykluczeń w osłonie WWW.

[tomaszmister]

Na wszelki wypadek dodam jeszcze małą uwagę pomocniczą:

otóż jeśli skrypt ciągle pracuje tylko na etapie "podtrzymywania połączenia" (wysyłania zapytań ping), ale nie wykrywa stanu uśpienia połączenia, gdyż już do niego dojdzie, wtedy warto otworzyć na chwilę okno wiersza poleceń (cmd) i wydać testowe polecenie ping z dowolnym adresem;

wówczas można będzie upewnić się, czy polecenie ping w danym systemie Windows faktycznie zwraca odpowiedzi w wersji polskiej;

dotąd zakładałem, że polska wersja Windows jest równoznaczna także z polskojęzycznymi odpowiedziami generowanymi przez różne podstawowe narzędzia systemowe działające w wierszu poleceń, takie jak ping;

jednak niedawno spotkałem się z sytuacją w systemie Windows 8.1 innej osoby, u której ping zwracał odpowiedzi angielskie zamiast polskich, pomimo że system był w wersji polskiej;
choć nie znałem historii tej konkretnej instalacji systemu od samego początku, jednak najpewniej była to od początku oficjalna polska dystrybucja Windows 8 (później uaktualniona do 8.1), ale pomimo tego ping zwracał odpowiedzi w j. ang.;

w przypadku gdy ping zwraca odpowiedzi w j. ang. konieczne jest odpowiednie ustawienie zmiennej "fragment_poszukiwanego_ciagu_znakow" w sekcji ustawień skryptu;
dla polskich odpowiedzi skrypt oczekuje komunikatu "Upłynął limit czasu żądania", natomiast w wersji ang. będzie to komunikat "Request timed out";

dla wersji polskiej zmienna "fragment_poszukiwanego_ciagu_znakow" ma przypisany fragment:
czasu

a dla wersji angielskiej należy zamiast niego przypisać tej zmiennej np. ciąg znaków:
timed

(dzięki wybraniu takich poszukiwanych fragmentów ominięty zostanie problem kodowania polskich znaków, a także umieszczania spacji w poszukiwanym ciągu)

komentarze zawarte w skrypcie opisują konieczność wprowadzenia modyfikacji językowej przy zmiennej "fragment_poszukiwanego_ciagu_znakow", jednak nie sądziłem, że może okazać się to potrzebne także dla niektórych użytkowników polskich wersji Windows;


- - - - - - - - - - - - - - - - - - - -

Na szczęście wszystko wskazuje na to, że przynajmniej użytkownicy pakietów płatnych w Aero2 nie będą musieli martwić się tym problemem usypiania połączenia - od pewnego czasu korzystając najpierw z pakietu testowego, a potem z pakietów 5 zł/3 GB/ 30 dni ani razu nie napotkałem na sytuację uśpienia połączenia;
Oznaczałoby to prawdopodobnie, że użytkownicy pakietów płatnych otrzymują jakby lepszy priorytet względem użytkowników BDI.
Natomiast powrót do BDI po wyczerpaniu pakietu szybko przypomnia o zjawisku usypiania połączenia

Oby Nowy Rok przyniósł wreszcie naprawę tego problemu w BDI !!

[szopen]

windowsy z MUI w polskiej wersji tak miewają (wyniki poleceń po angielsku), bo "pod pokładem" jest system w wersji US

również niektóre aktualizacje mogą "zangielszczyć" wybrane fragmenty systemu (szczególnie jeśli pochodzą z pakietów dostarczanych z jakimś programem w wersji angielskiej albo zostały ręcznie pobrane przy błędnie wybranym języku US, a nie przez windowsupdate/msupdate)

[tomaszmister]

Szopen dziękuję za to spostrzeżenie!

Bo dotąd sądziłem, że wersja językowa pozostaje cały czas mniej więcej spójna na całym systemie windowsowym (pomijając najwyżej jakieś rzadko napotykane miejsca czy narzędzia, które mogły pozostać bez tłumaczenia z wersji US), a ten opisany przypadek potraktowałem raczej jako jakąś anomalię - w każdym razie teraz już wiem, że na wszelki wypadek podczas konfigurowania skryptu warto sprawdzić wersję językową odpowiedzi zwracanych przez ping.

[penknife]

może taki kod by coś pomógł:

Kod:

for /f "tokens=* delims=" %%# in ('ping -n 3 %addresIP%') do for %%? in (czasu timed) do <nul set /p "=%%~#"|find /i "%%~?">nul &&(echo czas upłynął)

[tomaszmister]

Penknife dziękuję bardzo za kolejną poradę!

Pomyślałem aby jednak na razie jeszcze nie dodawać takiego rozwiązania do skryptu, ponieważ ... jest ono dla mnie zbyt skomplikowane :-)) ... ale co za tym idzie, taki zaawansowany kod mógłby również troszkę wpłynąć na zwiększenie obciążenia generowanego przez skrypt, a najbardziej zależało mi właśnie na tym, aby skrypt był jak najprostszy i generował tylko śladowe obciążenie nawet na tych bardziej wiekowych, słabszych komputerach.

Tak czy inaczej przed pierwszym uruchomieniem skryptu na użytkowniku spoczywa konieczność dostosowania jego ustawień, tak więc z pewnością każda osoba ustawiająca skrypt ma bardzo dobrą i pełną wiedzę o konfigurowaniu połączeń Aero2, więc ostatecznie także ta kwestia związana z wersją językową odpowiedzi zwracanych przez ping nie sprawi kłopotów.

[CamilloS]

Skrypt dla Windows sprawuje się świetnie, szukam podobnego patentu dla Androida. Samo pingowanie wiele nie pomaga. Macie jakieś pomysły?