UKE zaszalało.

Na szczęście nie biorę bezpośrednio udziału w wypełnianiu dokumentów do Systemu Informacyjnego o Infrastrukturze Szerokopasmowej (SIIS), ale pewnych rzeczy nawet z boku nie sposób nie zauważyć. Jak wszystko w kraju, inwentaryzacja jest robiona na ostatnią chwilę, zarówno od strony ISP, jak i UKE. I akurat ISP, którzy się nie pospieszyli, tym razem wygrali. Co jest źle?

Niejasne przepisy – fajnie, że można zadać pytanie (i dostać odpowiedź), fajnie, że było spotkanie, ale czemu nie jest po prostu czarno na białym, w sposób nie budzący wątpliwości napisane? Do tego dochodzą kwiatki w niektórych miejscach typu dane w formacie XLS zgodnym z generowanym przez Weryfikator (Weryfikator to program pomocniczy). IMO formatu danych w dokumentach urzędowych nie powinien określać program, szczególnie arkusz kalkulacyjny, szczególnie … Jasne, to tylko instrukcja i być może gdzieś jest normalny opis.

Zmiany zasad w trakcie gry –  czyli czemu nie warto się spieszyć. Jak można zauważyć, spotkanie na którym doprecyzowano/zmieniono interpretacje, miało miejsce już po publikacji dokumentów. Jeśli któryś ISP się pospieszył, spora szansa, że niepotrzebnie wykonał pracę. Podobnie zmieniła się wersja Weryfikatora (tak, tego, co gdzieniegdzie definiuje format).

Nieznany faktyczny cel inwentaryzacji – w sumie nie ma co pisać, spekulacji jak zostaną wykorzystane bardzo szczegółowe przecież dane jest sporo, informacji oficjalnej (poza „góra kazała”) nie ma… Brak grokowania problemu nie ułatwia czytania dokumentów i sensownego ich wypełniania… Oficjalna wersja, do czego posłużą dane jest tu, ale jak na to, co tam piszą, dane są stanowczo zbyt szczegółowe. Do wersji oficjalnej wystarczyłby zasięg usługi (OK, nieco problematyczny w przypadku sieci bezprzewodowych) i maksymalna oferowana na danym rejonie prędkość (OK, też problematyczna w przypadku Wi-Fi i *DSL).

Naprawdę nie można było opublikować dokumentów wcześniej, dać miesiąca czy dwóch na zgłoszenie uwag (mailowo), na ich podstawie przygotować wersje finalne i instrukcje i dopiero wtedy publikować? Spotkania, jak opisane wyżej są pewnie wygodne, ale bardzo zasobochłonne, zwłaszcza dla mniejszych ISP. Zresztą spotkanie w trakcie okresu na zgłaszanie uwag też spokojnie mogłoby się odbyć, a po nim mogłaby powstać kolejna wersja dokumentów. Czyli wersja wstępna -> czas na uwagi -> spotkanie -> wersja z poprawkami -> czas na uwagi -> wersja finalna.

Póki co, efekt jest taki, że na grupie pl.internet.polip czyli poświęconej problemom Internetu polskiego i światowego, ostatnio pisze się głównie o UKE. Znamienne. Ale nie dziwi – nawet mając 70-90% danych w wewnętrznym systemie i tak dobrych kilka osobodni zostanie poświęconych na przygotowanie raportu… 😉

Twitter/Identi.ca DNS hack, czyli jak obejść zabezpieczenie Wi-Fi.

Przyjeżdżasz na konferencję, wpadasz do pokoju hotelowego, znajomi już powinni być, ale czy faktycznie dojechali? Jeśli poruszasz się bez mobilnego internetu, masz mało wygodny Internet w telefonie, uruchomionego laptopa i nie spięte te dwa urządzenia z jakiegoś powodu, czy recepcja hotelowa jest daleko lub przeżywa oblężenie, to można to sprawdzić wykorzystując fakt, że zwykle hotelowe systemy dostępu przepuszczają zapytania (i odpowiedzi) DNS. Teraz jest to jeszcze prostsze, bo nie trzeba samemu ustawiać tunelu DNS. O ile tylko znajomi korzystają z Twittera lub Identi.ca…

Prostą w użyciu, nie wymagającą logowania i publicznie dostępną bramkę Twitter/Identi.ca -> DNS zapewnia serwis Any.IO. Można pobrać ostatni status użytkownika, ostatnich 10 statusów, informacje o użytkowniku i… to w zasadzie tyle (przykłady na stronie). Wszystko w trybie tylko odczyt – nie ustawimy swojego statusu (dziwnym nie jest, wymagałoby podania hasła), ale czasem może być przydatne.

Oczywiście to tylko namiastka tunelu i ciekawostka (ale bardzo wygodny gotowiec), jeśli ktoś szuka więcej informacji to więcej o tunelowaniu ruchu w zapytaniach DNS jest tutaj (ang.; nie bawiłem się, ale wygląda sensownie i sporo przydatnych linków).

PS. Wszyscy piszą disclaimery nt. legalności tego typu rozwiązań. IANAL, ale IMVHO jeśli jesteśmy klientem hotelu, a zapytania DNS są przepuszczane, to nie jest to nieuprawniony dostęp. A już na pewno nie pojedyncze zapytanie w formie prezentowanej przez Any.IO.