Pisząc ostatnio artykuł o tym jak uchronić nasz prywatny punkt dostępu do sieci WiFi przed zmapowaniem i umieszczeniem jego fizycznej lokalizacji w serwisach pokroju Wigle.net czy też w usługach Google/Mozilla, poruszony został temat ewentualnego usuwania wpisów z takich baz danych AP za sprawą dopisywania do nazwy sieci (ESSID) sufiksu _nomap . Nie wszystkie organizacje/firmy respektują naszą prywatność i raczej też nie będą tej końcówki w nazwie sieci honorować. Jako, że jednym z dwóch parametrów, na podstawie których takie mapowanie punktów dostępowych się odbywa, jest adres MAC interfejsu bezprzewodowego danego AP (BSSID), to możemy od czasu do czasu pokusić się o zmianę tego adresu. Jest to mniej więcej to samo rozwiązanie, co zastosowane przy klonowaniu adresu MAC dla portu WAN routera, które z reguły użytkownicy wykorzystują do obchodzenia zabezpieczeń tych bardziej wrednych ISP. Jako, że temat zmiany BSSID trochę się różni od zmiany adresu MAC dla portu WAN, to w niniejszym artykule postanowiłem opisać jak w routerze z wgranym firmware OpenWRT podejść do tego zadania.

Parę dni temu napisał do mnie megabajt z forum DUG z wiadomością, że nazwa mojego WiFi figuruje w bazie danych serwisu Wigle.net oraz, że lepiej nie zdradzać nazw swoich WiFi osobom trzecim, bo ktoś w oparciu o te dane może poznać nasze fizyczne położenie. Jak najbardziej istnieje taka możliwość, a sam serwis Wigle.net nie jest jedynym, który zbiera informacje o położeniach geograficznych punktów dostępowych WiFi, bo od lat robi to też Google i Mozilla. Niemniej jednak, podchodziłbym z pewną dozą ostrożności do danych zgromadzonych w serwisie Wigle.net (i tych pozostałych dwóch też), bo nie zawsze muszą one być akuratne. W zasadzie to nie zdziwiłem się zbytnio, że nazwa mojej sieci WiFi figuruje w bazie danych Wigle.net, bo sam ją tam umieściłem świadomie jakiś czas temu w ramach testów wykorzystując do tego celu aplikację WiGLE WiFi Wardriving, którą można wgrać przez F-Droid na każdy telefon z Androidem. Jako, że nadarzyła się okazja, to postanowiłem napisać parę słów na temat unikania bycia zmapowanym, tak by jakiś nieznany nam bliżej osobnik przez przypadek nie wrzucił lokalizacji naszych domowych/firmowych AP do bazy danych Google/Mozilla czy też wspomnianego wyżej serwisu Wigle.net, o ile oczywiście sobie tego nie życzymy.

Od już dłuższego czasu (będzie parę lat) korzystam z internetu LTE zamiast tradycyjnego połączenia przewodowego. Głównie ze względu na fakt, że w mojej okolicy nie ma praktycznie żadnych szanujących się ISP, z którymi warto by wejść w interakcję i podpisać z nimi jakąś sensową umowę. Poza tym, dla osób mojego pokroju, które cenią sobie mobilność, internet stacjonarny i tak jest mało praktyczny. Dlatego w moim domowym routerze mam wgrany firmware OpenWRT umożliwiający zainstalowanie na tym urządzeniu odpowiedniego oprogramowania obsługującego modemy LTE podłączane przez port USB. Połączenie sieciowe ze światem zwykle działa prawidłowo ale z jakiegoś powodu jest ono zrywane. Zwykle taka sytuacja ma miejsce w środku nocy (czasami parokrotnie), zwłaszcza gdy przekroczę limit danych i do końca okresu rozliczeniowego muszę przemęczyć się z lejkiem 1 mbit/s. Gdy ten lejek jest aplikowany, to zwykle odpalam sobie torrent'a, tak by pobrać najnowsze obrazy ISO tej czy innej dystrybucji linux'a. Niemniej jednak, jak mi net rozłączą, to nie załączy się on ponownie sam z siebie. Modem Huawei E3372s-153 w wersji NON-HiLink zdaje się pracować poprawnie, bo świeci się na nim dioda sugerująca, że połączenie z internetem jest nawiązane. Dlatego też postanowiłem w końcu ten problem rozwiązać raz na zawsze i mieć przy tym nieco spokojniejszy sen.

Jakiś już czas temu opisywałem w jaki sposób skonfigurować AdBlock'a na routerze WiFi z wgranym firmware OpenWRT oraz jak wdrożyć szyfrowanie zapytań DNS w oparciu o dnscrypt-proxy dla wszystkich klientów naszej sieci domowej. Zarówno AdBlock jak i dnscrypt-proxy można w dalszym ciągu wykorzystywać, zwłaszcza na routerach wyposażonych w niewielkich rozmiarów flash i mało pamięci RAM. Niemniej jednak, nie każdy lubi konfigurować swój bezprzewodowy router za pośrednictwem terminala. Dla takich osób powstał właśnie AdGuard Home, który ma na celu możliwie uprościć konfigurację routera, przynajmniej jeśli chodzi o rzeczy związane z protokołem DNS. W tym artykule przyjrzymy się nieco bliżej AdGuard'owi i zobaczymy czy można z niego zrobić jakiś większy użytek.

Od dłuższego już czasu na swoich routerach WiFi wykorzystuję firmware OpenWRT. W przypadku mojego domowego routera TP-Link Archer C7 v2 zarządzanie jego oprogramowaniem sprowadza się w zasadzie do przeprowadzania aktualizacji raz na kilka tygodni czy miesięcy. Z reguły nie jest to jakoś czasochłonne zadanie, bo wystarczy pobrać stosowny obraz z serwera eko.one.pl i wrzucić go na router czy to przez interfejs LuCI, czy też przez sysupgrade . No tak tylko, że po wgraniu OpenWRT na flash routera trzeba zwykle też dograć szereg pakietów, których nie ma w standardzie, przynajmniej jeśli chodzi akurat o ten mój router bezprzewodowy. Podobnie sprawa ma się z odtwarzaniem konfiguracji, której pewne elementy pozostają niezmienne nawet po aktualizacji ze starszego wydania OpenWRT do nowszego. Postanowiłem zatem zgłębić nieco proces kompilacji źródeł i budowy obrazu z firmware OpenWRT, tak by nieco zautomatyzować sobie (czy też wręcz wyeliminować) chociaż część z kroków, które zwykle przeprowadzam chwilę po wgraniu obrazu na router. Cały ten proces budowy obrazu zostanie opisany przy wykorzystaniu dystrybucji Debian linux.

Jeden z moich routerów, a konkretnie był to Archer C7 v2 wymagał, by powrócić jego firmware z LEDE/OpenWRT do tego, który widnieje na oficjalnej stronie TP-Link. Niby ta czynność nie jest zbyt skomplikowana ale jak zwykle coś poszło nie tak. Konkretnie to odłączyłem zasilanie nie w tej listwie co trzeba i w efekcie podczas flash'owania routera nowym firmware, to urządzenie się zwyczajnie wyłączyło. Zawału oczywiście nie dostałem, bo przecież obraz, który był wgrywany na router nie zawierał uboot'a, czyli części z bootloader'em, więc wiedziałem, że wystarczy przez tryb recovery wgrać obraz jeszcze raz i po sprawie. Problem w tylko w tym, że nie znałem w zasadzie ani nazwy pliku obrazu, ani też adresu IP, który jest wymagany dla połączenia w przypadku routera Archer C7 v2. Te dane można naturalnie znaleźć w sieci ale co w przypadku, gdy ubijemy sobie w taki sposób nasz jedyny router, przez co pozbawimy się jednocześnie dostępu do internetu? Czy istnieje jakiś sposób na ustalenie tych danych, inny niż przez konsolę szeregową?

Zainspirowany wątkiem na forum JDtech na temat testów transferów w konkretnych pasmach/częstotliwościach LTE, postanowiłem sprawdzić jak ta sprawa wygląda w mojej okolicy. Generalnie ja obecnie u siebie mam modem Huawei E3372s-153 w wersji NON-HiLink podpięty do routera TP-LINK Archer C2600. Oczywiście na tym routerze jest wgrany alternatywny firmware LEDE/OpenWRT, bo inaczej nie miałbym możliwości skorzystać z tego modemu. Standardowa konfiguracja LTE w LEDE/OpenWRT daje nam jedynie możliwość wyboru między ustawieniami auto , gsm , umts , lte , preferumts oraz preferlte . W przypadku internetu LTE, zwykle wybieramy tutaj tryb auto , ewentualnie też lte , by wymusić konkretny tryb pracy modemu, co może mieć kolosalne znaczenie przy darmowym internecie od RBM/Play. Niemniej jednak, nawet w przypadku wyboru lte , częstotliwość na jakiej będzie pracował modem w dalszym ciągu jest dobierana automatycznie w oparciu o parametry sygnału docierającego z dostępnych w okolicy BTS'ów. W przypadku modemu E3372 można jednak wymusić, by połączenie LTE było realizowane na konkretnej częstotliwości, np. 2100/1800/2600/900/800 MHz i by taki stan rzeczy osiągnąć, trzeba nieco przerobić konfigurację tego alternatywnego oprogramowania znajdującego się w naszym routerze WiFi.

Ostatnio pisałem trochę o konfiguracji serwera VPN na Debianie oraz podłączaniu do niego różnych linux'owych klientów, w tym też smartfonów wyposażonych w system Android. O ile konfiguracja pojedynczego klienta OpenVPN nie jest jakoś szczególnie trudna, to mając w swojej sieci domowej kilka urządzeń zdolnych łączyć się z internetem zarówno przewodowo jak i bezprzewodowo, to dostosowanie konfiguracji na każdym z tych sprzętów może być ździebko problematyczne. To co łączy te wszystkie urządzenia w naszym domu, to router WiFi. Zwykle każdy komputer, nawet ten najmniejszy, łączy się z takim routerem w celu nawiązania połączenia ze światem. Dlatego też zamiast konfigurować osobno wszystkie te urządzenia elektroniczne, możemy skonfigurować sobie router w taki sposób, by cały zebrany ruch z sieci lokalnej przesłał do serwera VPN. Standardowej klasy routery nie wspierają połączeń VPN i by taki mechanizm zaimplementować potrzebne nam będzie alternatywne firmware pokroju LEDE/OpenWRT. W tym artykule postaramy się skonfigurować połączenie VPN dla sieci domowej w oparciu o router Archer C2600 od TP-LINK, który ma wgrany najnowszy snapshot LEDE Chaos Calmer (r2392).

Przeglądając forum eko.one.pl natrafiłem ciekawy problem, nad którym też się zastanawiałem jakiś czas temu. Chodzi o udostępnienie internetu komórkowego (LTE/3G) komputerom w domowej sieci za pomocą smartfona (tzw. tethering). W takiej sytuacji, w przypadku problemów z lokalnym dostawcą internetu moglibyśmy przepiąć wszystkie komputery na internet świadczony przez operatora GSM, z którego korzystamy. Z reguły standardowy firmware routerów WiFi nie pozwala na tego typu rozwiązania. Niemniej jednak, mając do dyspozycji router z OpenWRT można spróbować połączyć go z naszym smartfonem udostępniając sieci lokalnej internet LTE/3G. W tym artykule zostanie przedstawione tego typu rozwiązanie przy wykorzystaniu routera Archer C7 v2 od TP-LINK oraz smartfona Neffos C5, również od TP-LINK. Na routerze zaś jest wgrana najnowsza stabilna wersja OpenWRT (Chaos Calmer). Sprawdzimy sobie jak takie rozwiązanie wygląda oraz sprawuje się w praktyce i czy jest ono w ogóle godne jakiegoś większego zainteresowania.

Przy okazji zabawy z konsolą szeregową przy ratowaniu jednego z moich routerów TP-LINK (TL-WR1043ND V2), parokrotnie przewinęła mi się informacja na temat trybu recovery, który ma być dostępny w części routerów. W czym nam taki tryb może pomóc i czy nasz router go obsługuje? Jeśli tak, to jak za jego pomocą naprawić urządzenie, które nie chce wystartować, np. po przerwanym procesie wgrywania firmware TP-LINK czy też OpenWRT/LEDE? W trym artykule postaramy się odpowiedzieć na te pytania.