Wyszukaj

Wyświetlanie wyników dla tagów 'linux' .



Więcej opcji wyszukiwania

  • Wyszukuj po tagach

    Wpisz tagi, oddzielając je przecinkami.
  • Wyszukuj po autorze

Typ zawartości


Forum

  • Kategoria Główna
    • Regulamin Forum - zasady korzystania
    • Kształt forum - dyskusja, propozycje, opinie.
    • tplinklogin.net oraz tplinkextender.net
    • Przydatne adresy internetowe
    • ftp://tplink-forum.pl
    • FOTO GALERIA - TP-Link w twojej sieci
    • CONNECTED nr 4/2016 (13) - NOWY NUMER
  • TP-LINK Forum
    • ADSL, DSL, LTE, PLC, USB - jaki model TP-Linka kupić?
    • BAZAR - kupię sprzedam
    • DOMOWE SIECI KOMPUTEROWE
    • PORADNIKI - FAQ - KONFIGURACJA
    • FIRMWARE
    • NOWOŚCI
    • NEFFOS - wsparcie techniczne
    • OPINIE UŻYTKOWNIKÓW / OPINIE EKSPERTÓW
    • POGOTOWIE KONFIGURACYJNE TP-LINK
    • PORADY SERWISOWE
    • ZAUFANY DYSTRYBUTOR - SPRZEDAWCA TP-LINKa
  • TP-Link rozwiązania SOHO - katalog
    • Urządzenia bezprzewodowe - standard AD
    • Urządzenia bezprzewodowe - standard AC
    • Urządzenia bezprzewodowe Dual Band
    • Urządzenia bezprzewodowe - standard N, 300Mb/s
    • Urządzenia bezprzewodowe - standard N, 150Mb/s
    • Urządzenia ADSL
    • Wzmacniacze sygnału
    • Karty bezprzewodowe
    • Routery 3G/4G/LTE
    • Modemy 3G
    • Przełączniki SOHO - niezarządzalne
    • Transmitery sieciowe PLC
    • Kamery IP Cloud
    • Serwery druku
    • Anteny i akcesoria
    • Karty przewodowe
    • Wycofane z produkcji
  • TP-Link rozwiązania SMB - katalog
    • Katalog produktów SMB 2013
    • Katalog produktów SMB 2015
  • TP-Link alternatywne oprogramowanie
    • Kto i gdzie tworzy alternatywne oprogramowanie
    • Aktualny firmware Gargoyle, LEDE, DD-WRT, OpenWRT, Luci,
    • FAQ - alternatywne oprogramowanie
    • Pogotowie konfiguracyjne - alternatywne oprogramowanie
  • Sieci komputerowe, internet
    • FAQ - sieci komputerowe
    • Konfiguracja popularnych urządzeń sieciowych
    • Routery innych producentów
  • Inne dyskusje
    • Hydepark

Grupa podstawowa


AIM


MSN


Strona URL


ICQ


Yahoo


Jabber


Skype


Gadu-Gadu


Lokalizacja:


Zainteresowania


O mnie

Znaleziono 15 wyników

  1. Bawiąc się ostatnio smartfonem Neffos C5 MAX od TP-LINK, obiecałem sobie, że jak tylko będę miał chwilę czasu, to postaram się ukorzenić Androida, który w tym telefonie siedzi (Lollipop). Generalnie rzecz biorąc, sposób root'owania tego urządzenia jest bardzo podobny do tego, który miałem już możliwość przeprowadzić na innym modelu TP-LINK'a, tj. Neffos C5. Dlatego też poniższy artykuł jest bardzo zbliżony treścią, choć lekko zaktualizowany pod kątem Neffos'a C5 MAX. Grunt, że nie było żadnych problemów z przeprowadzeniem backup'u flash'a telefonu jak i samego procesu root. Narzędzia ADB i fastboot Przede wszystkim, by zabrać się za proces root'owania smartfona Neffos C5 MAX, musimy przygotować sobie odpowiednie narzędzia. Zapewnią one nam możliwość rozmawiania z telefonem. Będziemy potrzebować adb (Android Debug Bridge) oraz fastboot . Proces instalacji tych narzędzi na linux, a konkretnie w dystrybucji Debian, został opisany osobno. Narzędzie SP Flash Tool Kolejnym narzędziem, które będzie nam niezbędne jest SP Flash Tool. Niestety nie jest ono włączone do dystrybucji Debian i musimy posiłkować się paczką, którą można znaleźć w podanym wyżej linku. Tutaj ważna uwaga. SP FLash Tool jest przeznaczony tylko dla smartfonów mających SoC od Mediatek. Pobieramy paczkę .zip dla linux'a i wypakowujemy ją. Jako, że SP Flash Tool wykorzystuje do komunikacji interfejs /dev/ttyACM0 , to do poprawnej pracy wymaga on operowania na tym interfejsie. Standardowo tylko administrator systemu oraz członkowie grupy dialout są w stanie korzystać z tego interfejsu. Musimy zatem dodać naszego użytkownika do tej grupy w poniższy sposób: # gpasswd -a morfik dialout Kompletny backup flash'a Neffos C5 MAX Mając zainstalowane te powyższe narzędzia, możemy przejść do zrobienia backup'u całego flash'a, który jest w naszym smartfonie. Proces backup'u najprościej przeprowadzić za pomocą SP Flash Tool. Niemniej jednak, potrzebne nam są pewne informacje, które możemy uzyskać przy pomocy adb . Podpinamy zatem telefon do portu USB komputera i w terminalu wpisujemy poniższe polecenie: # adb shell cat /proc/partinfo Name Start Size pgpt 0x0000000000000000 0x0000000000080000 proinfo 0x0000000000080000 0x0000000000300000 nvram 0x0000000000380000 0x0000000000500000 protect1 0x0000000000880000 0x0000000000a00000 protect2 0x0000000001280000 0x0000000000a00000 lk 0x0000000001c80000 0x0000000000080000 para 0x0000000001d00000 0x0000000000080000 boot 0x0000000001d80000 0x0000000001000000 recovery 0x0000000002d80000 0x0000000001000000 logo 0x0000000003d80000 0x0000000000800000 expdb 0x0000000004580000 0x0000000000a00000 seccfg 0x0000000004f80000 0x0000000000080000 oemkeystore 0x0000000005000000 0x0000000000200000 secro 0x0000000005200000 0x0000000000600000 keystore 0x0000000005800000 0x0000000000800000 tee1 0x0000000006000000 0x0000000000500000 tee2 0x0000000006500000 0x0000000000500000 frp 0x0000000006a00000 0x0000000000100000 nvdata 0x0000000006b00000 0x0000000002000000 metadata 0x0000000008b00000 0x0000000002500000 system 0x000000000b000000 0x0000000100000000 cache 0x000000010b000000 0x0000000019000000 userdata 0x0000000124000000 0x0000000286780000 flashinfo 0x00000003aa780000 0x0000000001000000 sgpt 0x00000003ab780000 0x0000000000080000 Ten zwrócony wyżej wynik jest dla smartfona Neffos C5 MAX. W przypadku innych telefonów, ta tabelka może mieć inną postać i nie możemy kopiować z niej wartości jeśli mamy inne urządzenie. Generalnie rzecz biorąc, to te dane potrzebne nam są do zbudowania pliku scatter.txt , w oparciu o który działa SP Flash Tool. Ten plik to zwyczajna mapa przestrzeni flash'a telefonu, który podzielony jest na szereg widocznych wyżej partycji. Plik scatter.txt dla Neffos C5 MAX Tutaj znajduje się plik scatter.txt (mt6753-neffos-c5-max-tp-link-scatter.txt), który ja wykorzystałem do pracy z Neffos C5 MAX. Kluczowa sprawa, to opisanie każdej partycji. W sumie to musimy odpowiednio dostosować pole partition_index , które jest zwyczajnie kolejnym numerkiem. Z kolei w partition_name podajemy nazwę partycji, którą uzyskaliśmy przez adb . Dalej w linear_start_addr oraz physical_start_addr wpisujemy tę wartość, która została wypisana przez adb w kolumnie Start . Na podobnej zasadzie uzupełniamy partition_size , podając wartość, którą widzieliśmy w adb w kolumnie Size . I to w zasadzie wszystkie zmiany, które musimy wprowadzić do pliku scatter.txt . Póki co nie mam informacji co do pozostałych opcji w tym pliku, wiem tylko, że część z nich jest uzupełniana przez SP Flash Tool podczas przeprowadzania działań w tym programie. Tworzenie backupu Mając plik scatter.txt możemy go wskazać w SP Flash Tool. Przechodzimy zatem do katalogu z wypakowaną zawartością pobranej paczki i uruchamiamy SP Flash Tool wpisując w terminalu ./flash_tool . Powinniśmy zobaczyć okienko, z kilkoma zakładkami. Na jednej z nich widnie napis Download . W niej z kolei znajduje się pozycja Scatter-loading file . To tutaj musimy wskazać ścieżkę do pliku scatter.txt , który utworzyliśmy wcześniej: Teraz przechodzimy na zakładkę Readback i tam dodajemy nową pozycję w tabelce. To tutaj określamy przestrzeń flash'a w telefonie, która zostanie skopiowana na dysk komputera. Nas interesuje cały flash. Dlatego też początek ustawiamy na 0x0 , a koniec musimy obliczyć z danych dostarczanych przez adb . Interesuje nas ostatnia partycja. Ma ona początek na 0x3ab780000 , a jej rozmiar to 0x80000 . Te dwie wartości musimy do siebie dodać, w wyniku czego otrzymujemy 0x3ab800000 i to tę wartość wpisujemy w SP Flash Tool. Region określamy jako EMC_USER : Dodajemy również drugą pozycję, która zrobi nam backup preloader'a. Z tym, że tutaj wybieramy region EMMC_BOOT_1 i określamy początek jako 0x0 , a koniec jako 0x40000 : Teraz wyłączamy telefon. Następnie w SP Flash Tool aktywujemy proces backup'u Neffos'a C5 MAX przyciskając Read Back . Podłączamy telefon do portu USB komputera. Po chwili smartfon powinien nam zawibrować ale nie uruchomi się. Rozpocznie się za to kopiowanie danych z telefonu na dysk. Proces backup'u potrwa dłuższą chwilę. W moim przypadku trwało prawie dwie godziny (transfer na poziomie 3 MiB/s). Ten backup jest nas w stanie zabezpieczyć na wypadek popełnionych błędów przy flash'owaniu telefonu. Podejrzymy jeszcze ten obraz w fdisk/gdisk , by mieć absolutną pewność, że jest w nim faktyczna kopia flash'a Neffos'a C5 MAX: Jak odblokować bootloader w Neffos C5 MAX Mając zrobiony kompletny backup flash'a, możemy przejść do odblokowania bootloader'a. Chodzi o to, że na smartfonach zwykle jest ulokowana partycja /recovery/ . Na niej znajduje się oprogramowanie umożliwiające przeprowadzanie operacji na poziomie systemowym, np. backup lub też flash'owanie ROM'u. Problem w tym, że to oprogramowanie w standardzie zwykle za wiele nie potrafi i by przeprowadzić proces root'owania Androida, musimy pozyskać bardziej zaawansowany soft, np. ClockworkMod czy TWRP, i wgrać go na partycję /recovery/ . By to zrobić musimy pierw odblokować bootloader. Proces odblokowania bootloader'a usuwa wszystkie dane, które wgraliśmy na flash telefonu, tj. podczas odblokowywania jest inicjowany factory reset. Dane na karcie SD pozostają nietknięte. By ten proces zainicjować zaczynamy od przestawienia jednej opcji w telefonie. W tym celu musimy udać się w Ustawienia => Opcje Programistyczne i tam przełączyć Zdjęcie blokady OEM : Następnie wyłączamy telefon i włączamy go trzymając Volume Up + Power. Z menu wybieramy tryb fastboot. Następnie w terminalu wpisujemy poniższe polecenia: # fastboot devices 8HCMMZFI89ROBI9H fastboot # fastboot oem unlock Na ekranie smartfona powinno nam pokazać się poniższe ostrzeżenie: Unlock bootloader? If you unlock the bootloader, you will be able to install custom operating system software on this phone. A custom OS is not subject to the same testing as the original OS, and can cause your phone and installed application to stop working properly. To prevent unauthorized access to your personal data, unlocking the bootloader will also delete all personal data from your phone "factory reset". Press the Volume UP/Down buttons to select Yes/No. Wciskamy Volume Up, by potwierdzić chęć odblokowania bootloader'a, po czym restartujemy smartfon: # fastboot reboot Jako, że proces odblokowania bootloader'a usunął wszelkie ustawienia, to jeszcze raz musimy włączyć Opcje Programistyczne, a w nich tryb debugowania portu USB. Wyodrębnianie obrazu partycji /recovery/ z obrazu Neffos'a C5 MAX Mając zrobiony backup flash'a telefonu, możemy z niego wyciągnąć obraz partycji /recovery/ . Musimy tylko zamontować ten obraz w systemie za pomocą losetup . Pamiętajmy, że ten obraz ma wiele partycji. Trzeba zatem nieco dostosować moduł kernela, by wszystkie z tych partycji zostały zamontowane za pomocą jednego polecenia. Informacje na temat tego jak dostosować moduł loop znajdują się tutaj. Przechodzimy zatem w miejsce, w którym zapisaliśmy obraz i montujemy go w poniższy sposób: # cd /path/to/image/ # losetup /dev/loop0 ROM_0 Teraz tworzymy obraz partycji /recovery/ . W tym przypadku /dev/loop0p8 jest urządzeniem, które musimy podać dd : # dd if=/dev/loop0p8 of=./recovery.img # file recovery.img recovery.img: Android bootimg, kernel (0x40080000), ramdisk (0x44000000), page size: 2048, cmdline (bootopt=64S3,32N2,64N2) Pozyskanie obrazu recovery.img z TWRP Musimy także pozyskać obraz recovery.img zawierający TWRP. Niestety, póki co nie ma obrazów dla Neffos'a C5 MAX. Dlatego też musimy sobie taki obraz recovery.img stworzyć sami przerabiając inny obraz, który jest przeznaczony na telefon zbliżony parametrami do naszego urządzenia (ten sam SoC, wielkość flash i rozdzielczość ekranu). Tutaj znajduje się gotowy obraz recovery, który można wgrać na telefon (recovery-neffos-c5-max-tp-link-twrp.img). Warto tutaj zaznaczyć, że nie zawsze taki obraz będzie nam działać bez problemu. W takim przypadku trzeba próbować innych obrazów, aż któryś zadziała. Nie musimy się tez obawiać wgrania złego obrazu na partycję /recovery/ . Jeśli zdarzy nam się wgrać niedziałający obraz recovery.img , to nie uszkodzimy smartfona. Zamiast tego telefon się zrestartuje i przywróci sobie starą partycję /recovery/ , a nas zaloguje do systemu jak gdyby nigdy nic. Przepakowanie obrazu recovery.img z innego smartfona By przepakować obraz przeznaczony na inny smartfon, który jest zbliżony parametrami do naszego Neffos'a C5 MAX, musimy pierw pozyskać odpowiednie narzędzia. Na linux'ie możemy skorzystać tego celu z abootimg lub też ze skryptów Android Image Kitchen. Ja będę korzystał z tego drugiego rozwiązania. Tworzymy sobie jakiś katalog roboczy i kopiujemy do niego zarówno oryginalny obraz partycji /recovery/ jak i ten z innego smartfona. Następnie znajdując się w tym katalogu roboczym, pobieramy skrypty z github'a (wymagane zainstalowane narzędzie git w systemie) i przechodzimy do utworzonego w ten sposób katalogu. W nim zaś tworzymy dwa podkatalogi stock/ oraz port/ : $ git clone https://github.com/ndrancs/AIK-Linux-x32-x64/ $ chmod +x ./AIK-Linux-x32-x64/* $ chmod +x ./AIK-Linux-x32-x64/bin/* $ cd ./AIK-Linux-x32-x64/ $ mkdir stock/ port/ Kopiujemy oryginalny obraz partycji /recovery/ z katalogu nadrzędnego i wypakowujemy go za pomocą skryptu unpackimg.sh . Następnie przenosimy tak wyodrębnioną zawartość do katalogu stock/ : $ cp ../recovery_orig.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ stock/ $ rm recovery.img Kopiujemy teraz obraz partycji /recovery/ mający TWRP i wypakowujemy go. Przenosimy jego zawartość do katalogu port/ : $ cp ../recovery_twrp.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ port/ $ rm recovery.img Zgodnie z informacją zawartą w tym HOWTO (windows), musimy przekopiować kilka plików z oryginalnego obrazu naszego Neffos'a C5 MAX do obrazu TWRP: $ cp ./stock/split_img/recovery.img-kerneloff ./port/split_img/ $ cp ./stock/split_img/recovery.img-zImage ./port/split_img/ $ cp ./stock/ramdisk/fstab.mt6735 ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.modem.rc ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.project.rc ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.rc ./port/ramdisk/ $ cp ./stock/ramdisk/ueventd.rc ./port/ramdisk/ Z tak przygotowanych plików w katalogu port/ trzeba zrobić nowy obraz recovery.img przy pomocy skryptu repackimg_x64.sh : $ rm -R stock/ $ mv port/ramdisk ./ $ mv port/split_img ./ $ rmdir port/ $ ./repackimg_x64.sh W katalogu roboczym powinien zostać utworzony nowy plik o nazwie image-new.img . To jest właśnie nasz nowy obraz partycji /recovery/ , który musimy wgrać na telefon w trybie fastboot. Wgrywanie przepakowanego obrazu recovery.img na Neffos'a C5 MAX Wyłączamy telefon i podpinamy go do portu USB. Następnie włączamy go trzymając VolumeUP + Power. Z menu, które nam się pokaże na ekranie telefonu wybieramy tryb fastboot. Wracamy na komputer i przy pomocy narzędzia fasboot wgrywamy wyżej wygenerowany obraz na telefon. # fastboot flash recovery image-new.img target reported max download size of 134217728 bytes sending 'recovery' (12868 KB)... OKAY [ 1.125s] writing 'recovery'... OKAY [ 0.360s] finished. total time: 1.485s Restartujemy telefon ( fastboot reboot ) i wchodzimy w tryb recovery (VolumeUp + Power), by potwierdzić, że nasz nowy obraz recovery się wgrał pomyślnie. W przypadku wgrania poprawnego obrazu, powinniśmy zobaczyć logo TWRP. Jeśli wgrany obraz był nieprawidłowy, to zobaczymy jedynie czarny ekran i nasz Neffos C5 MAX się po chwili uruchomi ponownie w normalnym trybie przywracając oryginalną partycję /recovery/ . SuperSU, BusyBOX, RootCheck i emulator terminala Ostatnią rzeczą na drodze do zrobienia root na Neffos C5 MAX jest wgranie aplikacji umożliwiającej korzystanie różnym programom z praw administratora systemu w telefonie. My skorzystamy z SuperSU. Dodatkowo, musimy wgrać sobie BusyBOX, który zawiera minimalistyczne odpowiedniki linux'owych narzędzi, co pozwoli nam swobodnie operować w Androidzie, tak jakbyśmy to robili pod pełnowymiarowym pingwinem. Potrzebny nam także będzie jakiś emulator terminala, w którym to będziemy wpisywać wszystkie nasze polecenia. Instalacja SuperSU Zacznijmy od pobrania stosownej paczki z SuperSU. Jako, że my nie mamy jeszcze zrobionego root'a, to musimy pobrać TWRP / FlashFire installable ZIP . Tej paczki nie wypakowujemy, tylko wrzucamy ją w pobranej formie na kartę SD w telefonie. Odpalamy teraz tryb recovery w smartfonie (VolumeUp + Power) i przechodzimy do Instaluj (TWRP jest również w języku polskim): Następnie wskazujemy paczkę .zip , którą umieściliśmy na karcie SD. Tam z kolei zaznaczamy Weryfikuj sygnatury pliku zip i przeciągamy trzy strzałki na prawą stronę. Teraz możemy uruchomić ponownie Neffos'a C5 MAX i zainstalować jakąś aplikację, która pokaże nam czy nasz smartfon ma root'a. Sprawdzenie czy Neffos C5 MAX ma root'a Po uruchomieniu się systemu na smartfonie, instalujemy aplikację RootCheck, po czym uruchamiamy ją. Powinien się pojawić monit informujący, że ta aplikacja żąda praw administracyjnych, na co zezwalamy. Jeśli nasz telefon ma root'a, to powinien się pojawić stosowny komunikat: Instalacja BusyBOX Kolejnym krokiem jest instalacja BusyBOX'a. Po wgraniu tej aplikacji na smartfona, musimy ją uruchomić i wcisnąć w niej przycisk install . BusyBOX również nas poprosi o dostęp do praw administracyjnych: Po zainstalowaniu, weryfikujemy jeszcze, czy aby wszystko zostało pomyślne wgrane. Możemy to zrobić zarówno w samej aplikacji BusyBOX, jak i w CheckRoot: Instalacja terminala Z BusyBOX'em zostały dostarczone niskopoziomowe narzędzia, które mogą korzystać z uprawnień administratora systemu za sprawą SuperSU. Niemniej jednak, by móc odpalać te programiki, musimy w czymś je uruchomić. Do tego celu potrzebny jest nam shell oraz emulator terminala. Domyślny shell ash jest dostarczany razem z BusyBOX. Terminal musimy doinstalować osobno. Generalnie to znalazłem dwa terminale, które są OpenSource i bez reklam/opłat. Są to Android-Terminal-Emulator oraz Termux. Wybieramy sobie jeden z nich i instalujemy w systemie. Tutaj warto jeszcze zaznaczyć, że ten drugi terminal instaluje sobie również shell dash (domyślny shell w Debianie) . Również w jego przypadku możemy łatwo doinstalować sobie aplikacje za pomocą apt , podobnie jak w Debianie (do tego celu nie jest wymagany root). Jako, że ja korzystam na co dzień z Debiana, to instaluje Termux'a. Aplikacje i prawa administracyjne Teraz już pozostało nam tylko odpalenie terminala i zalogowanie się na użytkownika root. Do tego celu służy polecenie su . Wpiszmy je zatem w okienku Termux'a: I teraz możemy uruchamiać aplikacjie z prawami admina, tak jak to zwykliśmy robić w każdym innym linux'ie. Pamiętajmy tylko, że standardowo system plików jest zamontowany w trybie tylko do odczytu (RO) i by móc zmieniać pliki systemowe z poziomu tego terminala, musimy przemontować system plików w tryb do zapisu (RW). Robimy to w poniższy sposób: $ su # mount -o remount,rw /system Gdy skończymy się bawić, to montujemy ten system plików ponownie w tryb RO: # mount -o remount,ro /system
  2. Smartfony mają to do siebie, że ogromna większość z nich pracuje pod kontrolą systemu linux, a konkretnie jest to jakiś Android. Tak też jest w przypadku Neffos'a C5 od TP-LINK, gdzie mamy zainstalowaną wersję 5.1 (Lollipop). My linux'iarze chcemy mieć pełny dostęp do systemu operacyjnego, by bez większych przeszkód móc zarządzać urządzeniem, które pod jego kontrolą pracuje. Problem w tym, że ten Neffos C5 nie ma w standardzie root'a i nie mamy administracyjnego dostępu do całego systemu plików telefonu. Jest kilka metod root'owania smartfona, np. za pomocą Kingoroot/Kingroot ale nie działają one w przypadku tego telefonu (i całe szczęście). W tym artykule zostanie pokazany sposób na root systemu Neffos'a C5 przy zachowaniu wszelkich norm bezpieczeństwa, które w sytuacjach podbramkowych pomogą nam odzyskać kontrolę nad telefonem. Narzędzia ADB i fastboot Przede wszystkim, by zabrać się za proces root'owania smartfona Neffos C5, musimy przygotować sobie odpowiednie narzędzia. Zapewnią one nam możliwość rozmawiania z telefonem. Będziemy potrzebować adb (Android Debug Bridge) oraz fastboot . Proces instalacji tych narzędzi na linux, a konkretnie w dystrybucji Debian, został opisany osobno. Narzędzie SP Flash Tool Kolejnym narzędziem, które będzie nam niezbędne jest SP Flash Tool. Niestety nie jest ono włączone do dystrybucji Debian i musimy posiłkować się paczką, którą można znaleźć w podanym wyżej linku. Tutaj ważna uwaga. SP FLash Tool jest przeznaczony tylko dla smartfonów mających SoC od Mediatek. Pobieramy paczkę .zip dla linux'a i wypakowujemy ją. Jako, że SP Flash Tool wykorzystuje do komunikacji interfejs /dev/ttyACM0 , to do poprawnej pracy wymaga on operowania na tym interfejsie. Standardowo tylko administrator systemu oraz członkowie grupy dialout są w stanie korzystać z tego interfejsu. Musimy zatem dodać naszego użytkownika do tej grupy w poniższy sposób: # gpasswd -a morfik dialout Kompletny backup flash'a Neffos C5 Mając zainstalowane te powyższe narzędzia, możemy przejść do zrobienia backup'u całego flash'a, który jest w naszym smartfonie. Proces backup'u najprościej przeprowadzić za pomocą SP Flash Tool. Niemniej jednak, potrzebne nam są pewne informacje, które możemy uzyskać przy pomocy adb . Podpinamy zatem telefon do portu USB komputera i w terminalu wpisujemy poniższe polecenie: # adb shell cat /proc/partinfo Name Start Size pgpt 0x0000000000000000 0x0000000000080000 proinfo 0x0000000000080000 0x0000000000300000 nvram 0x0000000000380000 0x0000000000500000 protect1 0x0000000000880000 0x0000000000a00000 protect2 0x0000000001280000 0x0000000000a00000 lk 0x0000000001c80000 0x0000000000080000 para 0x0000000001d00000 0x0000000000080000 boot 0x0000000001d80000 0x0000000001000000 recovery 0x0000000002d80000 0x0000000001000000 logo 0x0000000003d80000 0x0000000000800000 expdb 0x0000000004580000 0x0000000000a00000 seccfg 0x0000000004f80000 0x0000000000080000 oemkeystore 0x0000000005000000 0x0000000000200000 secro 0x0000000005200000 0x0000000000600000 keystore 0x0000000005800000 0x0000000000800000 tee1 0x0000000006000000 0x0000000000500000 tee2 0x0000000006500000 0x0000000000500000 frp 0x0000000006a00000 0x0000000000100000 nvdata 0x0000000006b00000 0x0000000002000000 metadata 0x0000000008b00000 0x0000000002500000 system 0x000000000b000000 0x0000000100000000 cache 0x000000010b000000 0x0000000019000000 userdata 0x0000000124000000 0x000000027ed80000 flashinfo 0x00000003a2d80000 0x0000000001000000 sgpt 0x00000003a3d80000 0x0000000000080000 Ten zwrócony wyżej wynik jest dla smartfona Neffos C5. W przypadku innych telefonów, ta tabelka może mieć inną postać i nie możemy kopiować z niej wartości jeśli mamy inne urządzenie. Generalnie rzecz biorąc, to te dane potrzebne nam są do zbudowania pliku scatter.txt , w oparciu o który działa SP Flash Tool. Ten plik to zwyczajna mapa przestrzeni flash'a telefonu, który podzielony jest na szereg widocznych wyżej partycji. Plik scatter.txt dla Neffos C5 Tutaj znajduje się plik scatter.txt, który ja wykorzystałem do pracy z Neffos C5 (mt6735-neffos-c5-tp-link-scatter.txt). Kluczowa sprawa, to opisanie każdej partycji. W sumie to musimy odpowiednio dostosować pole partition_index , które jest zwyczajnie kolejnym numerkiem. Z kolei w partition_name podajemy nazwę partycji, którą uzyskaliśmy przez adb . Dalej w linear_start_addr oraz physical_start_addr wpisujemy tę wartość, która została wypisana przez adb w kolumnie Start . Na podobnej zasadzie uzupełniamy partition_size , podając wartość, którą widzieliśmy w adb w kolumnie Size . I to w zasadzie wszystkie zmiany, które musimy wprowadzić do pliku scatter.txt . Póki co nie mam informacji co do pozostałych opcji w tym pliku, wiem tylko, że część z nich jest uzupełniana przez SP Flash Tool podczas przeprowadzania działań w tym programie. Tworzenie backupu Mając plik scatter.txt możemy go wskazać w SP Flash Tool. Przechodzimy zatem do katalogu z wypakowaną zawartością pobranej paczki i uruchamiamy SP Flash Tool wpisując w terminalu ./flash_tool . Powinniśmy zobaczyć okienko, z kilkoma zakładkami. Na jednej z nich widnie napis Download . W niej z kolei znajduje się pozycja Scatter-loading file . To tutaj musimy wskazać ścieżkę do pliku scatter.txt , który utworzyliśmy wcześniej: Teraz przechodzimy na zakładkę Readback i tam dodajemy nową pozycję w tabelce. To tutaj określamy przestrzeń flash'a w telefonie, która zostanie skopiowana na dysk komputera. Nas interesuje cały flash. Dlatego też początek ustawiamy na 0x0 , a koniec musimy obliczyć z danych dostarczanych przez adb . Interesuje nas ostatnia partycja. Ma ona początek na 0x3a3d80000 , a jej rozmiar to 0x80000 . Te dwie wartości musimy do siebie dodać, w wyniku czego otrzymujemy 0x3a3e00000 i to tę wartość wpisujemy w SP Flash Tool. Region określamy jako EMC_USER : Dodajemy również drugą pozycję, która zrobi nam backup preloader'a. Z tym, że tutaj wybieramy region EMMC_BOOT_1 i określamy początek jako 0x0 , a koniec jako 0x40000 : Teraz wyłączamy telefon i podłączamy go do portu USB komputera. Następnie w SP Flash Tool aktywujemy proces backup'u Neffos'a C5 przyciskając Read Back . Włączamy teraz telefon przyciskając i trzymając przycisk Volume Up + Power do momentu aż nam zawibruje. Smartfon się nie włączy ale za to rozpocznie się kopiowanie danych z telefonu na dysk. Proces backup'u potrwa dłuższą chwilę. W moim przypadku trwało prawie dwie godziny (transfer na poziomie 3 MiB/s). Ten backup jest nas w stanie zabezpieczyć na wypadek popełnionych błędów przy flash'owaniu telefonu. Podejrzymy jeszcze ten obraz w fdisk/gdisk , by mieć absolutną pewność, że jest w nim faktyczna kopia flash'a Neffos'a C5: Jak odblokować bootloader w Neffos C5 Mając zrobiony kompletny backup flash'a, możemy przejść do odblokowania bootloader'a. Chodzi o to, że na smartfonach zwykle jest ulokowana partycja /recovery/ . Na niej znajduje się oprogramowanie umożliwiające przeprowadzanie operacji na poziomie systemowym, np. backup lub też flash'owanie ROM'u. Problem w tym, że to oprogramowanie w standardzie zwykle za wiele nie potrafi i by przeprowadzić proces root'owania Androida, musimy pozyskać bardziej zaawansowany soft, np. ClockworkMod czy TWRP, i wgrać go na partycję /recovery/ . By to zrobić musimy pierw odblokować bootloader. Proces odblokowania bootloader'a usuwa wszystkie dane, które wgraliśmy na flash telefonu, tj. podczas odblokowywania jest inicjowany factory reset. Dane na karcie SD pozostają nietknięte. By ten proces zainicjować zaczynamy od przestawienia jednej opcji w telefonie. W tym celu musimy udać się w Ustawienia => Opcje Programistyczne i tam przełączyć Zdjęcie blokady OEM : Następnie wyłączamy telefon i włączamy go trzymając Volume Up + Power. Z menu wybieramy tryb fastboot. Następnie w terminalu wpisujemy poniższe polecenia: # fastboot devices TSL7DA69OBSO49PJ fastboot # fastboot oem unlock Na ekranie smartfona powinno nam pokazać się poniższe ostrzeżenie: Unlock bootloader? If you unlock the bootloader, you will be able to install custom operating system software on this phone. A custom OS is not subject to the same testing as the original OS, and can cause your phone and installed application to stop working properly. To prevent unauthorized access to your personal data, unlocking the bootloader will also delete all personal data from your phone "factory reset". Press the Volume UP/Down buttons to select Yes/No. Wciskamy Volume Up, by potwierdzić chęć odblokowania bootloader'a, po czym restartujemy smartfon: # fastboot reboot Jako, że proces odblokowania bootloader'a usunął wszelkie ustawienia, to jeszcze raz musimy włączyć Opcje programistyczne, a w nich tryb debugowania portu USB. Wyodrębnianie obrazu partycji /recovery/ z obrazu Neffos'a C5 Mając zrobiony backup flash'a telefonu, możemy z niego wyciągnąć obraz partycji /recovery/ . Musimy tylko zamontować ten obraz w systemie za pomocą losetup . Pamiętajmy, że ten obraz ma wiele partycji. Trzeba zatem nieco dostosować moduł kernela, by wszystkie z tych partycji zostały zamontowane za pomocą jednego polecenia. Informacje na temat tego jak dostosować moduł loop znajdują się tutaj. Przechodzimy zatem w miejsce, w którym zapisaliśmy obraz i montujemy go w poniższy sposób: # cd /path/to/image/ # losetup /dev/loop0 ROM_0 Teraz tworzymy obraz partycji /recovery/ . W tym przypadku /dev/loop0p8 jest urządzeniem, które musimy podać dd : # dd if=/dev/loop0p8 of=./recovery.img # file recovery.img recovery.img: Android bootimg, kernel (0x40080000), ramdisk (0x44000000), page size: 2048, cmdline (bootopt=64S3,32N2,64N2) Pozyskanie obrazu recovery.img z TWRP Musimy także pozyskać obraz recovery.img zawierający TWRP. Niestety, póki co nie ma obrazów dla Neffos'a C5. Dlatego też musimy sobie taki obraz recovery.img stworzyć sami przerabiając inny obraz, który jest przeznaczony na telefon zbliżony parametrami do naszego urządzenia (ten sam SoC, wielkość flash i rozdzielczość ekranu). Warto tutaj zaznaczyć, że nie zawsze taki obraz będzie nam działać bez problemu. W takim przypadku trzeba próbować innych obrazów, aż któryś zadziała. Nie musimy się tez obawiać wgrania złego obrazu na partycję /recovery/ . Jeśli zdarzy nam się wgrać niedziałający obraz recovery.img , to nie uszkodzimy smartfona. Zamiast tego telefon się zrestartuje i przywróci sobie starą partycję /recovery/ , a nas zaloguje do systemu jak gdyby nigdy nic. Moje pierwsze podejście do wgrania obrazu recovery.img na Neffos'a C5 się nie powiodło. Prawdopodobnie obraz nie był odpowiednio przygotowany i w efekcie trzeba było wgrać inny obraz. Ja skorzystałem z obrazu podrzuconego przez użytkownika @GWJ. Musiałem go tylko dostosować pod Neffos'a C5 (recovery-neffos-c5-tp-link-twrp.img). Przepakowanie obrazu recovery.img z innego smartfona By przepakować obraz przeznaczony na inny smartfon, który jest zbliżony parametrami do naszego Neffos'a C5, musimy pierw pozyskać odpowiednie narzędzia. Na linux'ie możemy skorzystać tego celu z abootimg lub też ze skryptów Android Image Kitchen. Ja będę korzystał z tego drugiego rozwiązania. Tworzymy sobie jakiś katalog roboczy i kopiujemy do niego zarówno oryginalny obraz partycji /recovery/ jak i ten z innego smartfona. Następnie znajdując się w tym katalogu roboczym, pobieramy skrypty z github'a (wymagane zainstalowane narzędzie git w systemie) i przechodzimy do utworzonego w ten sposób katalogu. W nim zaś tworzymy dwa podkatalogi stock/ oraz port/ : $ git clone https://github.com/ndrancs/AIK-Linux-x32-x64/ $ chmod +x ./AIK-Linux-x32-x64/* $ chmod +x ./AIK-Linux-x32-x64/bin/* $ cd ./AIK-Linux-x32-x64/ $ mkdir stock/ port/ Kopiujemy oryginalny obraz partycji /recovery/ z katalogu nadrzędnego i wypakowujemy go za pomocą skryptu unpackimg.sh . Następnie przenosimy tak wyodrębnioną zawartość do katalogu stock/ : $ cp ../recovery_orig.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ stock/ $ rm recovery.img Kopiujemy teraz obraz partycji /recovery/ mający TWRP i wypakowujemy go. Przenosimy jego zawartość do katalogu port/ : $ cp ../recovery_twrp.img ./recovery.img $ ./unpackimg.sh recovery.img $ mv split_img/ ramdisk/ port/ $ rm recovery.img Zgodnie z informacją zawartą w tym HOWTO (windows), musimy przekopiować kilka plików z oryginalnego obrazu naszego Neffos'a C5 do obrazu TWRP: $ cp ./stock/split_img/recovery.img-kerneloff ./port/split_img/ $ cp ./stock/split_img/recovery.img-zImage ./port/split_img/ $ cp ./stock/ramdisk/fstab.mt6735 ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.modem.rc ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.project.rc ./port/ramdisk/ $ cp ./stock/ramdisk/meta_init.rc ./port/ramdisk/ $ cp ./stock/ramdisk/ueventd.rc ./port/ramdisk/ Z tak przygotowanych plików w katalogu port/ trzeba zrobić nowy obraz recovery.img przy pomocy skryptu repackimg_x64.sh : $ rm -R stock/ $ mv port/ramdisk ./ $ mv port/split_img ./ $ rmdir port/ $ ./repackimg_x64.sh W katalogu roboczym powinien zostać utworzony nowy plik o nazwie image-new.img . To jest właśnie nasz nowy obraz partycji /recovery/ , który musimy wgrać na telefon w trybie fastboot. Wgrywanie przepakowanego obrazu recovery.img na Neffos'a C5 Wyłączamy telefon i podpinamy go do portu USB. Następnie włączamy go trzymając VolumeUP + Power. Z menu, które nam się pokaże na ekranie telefonu wybieramy tryb fastboot. Wracamy na komputer i przy pomocy narzędzia fasboot wgrywamy wyżej wygenerowany obraz na telefon. # fastboot flash recovery image-new.img target reported max download size of 134217728 bytes sending 'recovery' (12642 KB)... OKAY [ 1.301s] writing 'recovery'... OKAY [ 0.279s] finished. total time: 1.580s Restartujemy telefon ( fastboot reboot ) i wchodzimy w tryb recovery (VolumeUp + Power), by potwierdzić, że nasz nowy obraz recovery się wgrał pomyślnie. W przypadku wgrania poprawnego obrazu, powinniśmy zobaczyć logo TWRP. Jeśli wgrany obraz był nieprawidłowy, to zobaczymy jedynie czarny ekran i nasz Neffos C5 się po chwili uruchomi ponownie w normalnym trybie przywracając oryginalną partycję /recovery/ . SuperSU, BusyBOX, RootCheck i emulator terminala Ostatnią rzeczą na drodze do zrobienia root na Neffos C5 jest wgranie aplikacji umożliwiającej korzystanie różnym programom z praw administratora systemu w telefonie. My skorzystamy z SuperSU. Dodatkowo, musimy wgrać sobie BusyBOX, który zawiera minimalistyczne odpowiedniki linux'owych narzędzi, co pozwoli nam swobodnie operować w Androidzie, tak jakbyśmy to robili pod pełnowymiarowym pingwinem. Potrzebny nam także będzie jakiś emulator terminala, w którym to będziemy wpisywać wszystkie nasze polecenia. Instalacja SuperSU Zacznijmy od pobrania stosownej paczki z SuperSU. Jako, że my nie mamy jeszcze zrobionego root'a, to musimy pobrać TWRP / FlashFire installable ZIP . Tej paczki nie wypakowujemy, tylko wrzucamy ją w pobranej formie na kartę SD w telefonie. Odpalamy teraz tryb recovery w smartfonie (VolumeUp + Power) i przechodzimy kolejno do Instaluj (TWRP jest również w języku polskim): Następnie wskazujemy paczkę .zip , którą umieściliśmy na karcie SD. Tam z kolei zaznaczamy Weryfikuj sygnatury pliku zip i przeciągamy trzy strzałki na prawą stronę. Teraz możemy uruchomić ponownie Neffos'a C5 i zainstalować jakąś aplikację, która pokaże nam czy nasz smartfon ma root'a. Sprawdzenie czy Neffos C5 ma root'a Po uruchomieniu się systemu na smartfonie, instalujemy aplikację RootCheck, po czym uruchamiamy ją. Powinien się pojawić monit informujący, że ta aplikacja żąda praw administracyjnych, na co zezwalamy. Jeśli nasz telefon ma root'a, to powinien się pojawić stosowny komunikat: Instalacja BusyBOX Kolejnym krokiem jest instalacja BusyBOX'a. Po wgraniu tej aplikacji na smartfona, musimy ją uruchomić i wcisnąć w niej przycisk install . BusyBOX również nas poprosi o dostęp do praw administracyjnych: Po zainstalowaniu, weryfikujemy jeszcze, czy aby wszystko zostało pomyślne wgrane. Możemy to zrobić zarówno w samej aplikacji BusyBOX, jak w w CheckRoot: Instalacja terminala Z BusyBOX'em zostały dostarczone niskopoziomowe narzędzia, które mogą korzystać z uprawnień administratora systemu za sprawą SuperSU. Niemniej jednak, by móc odpalać te programiki, musimy w czymś je uruchomić. Do tego celu potrzebny jest nam shell oraz emulator terminala. Domyślny shell ash jest dostarczany razem z BusyBOX. Terminal musimy doinstalować osobno. Generalnie to znalazłem dwa terminale, które są OpenSource i bez reklam/opłat. Są to Android-Terminal-Emulator oraz Termux. Wybieramy sobie jeden z nich i instalujemy w systemie. Tutaj warto jeszcze zaznaczyć, że ten drugi terminal instaluje sobie również shell dash (domyślny shell w Debianie) . Również w jego przypadku możemy łatwo doinstalować sobie aplikacje za pomocą apt , podobnie jak w Debianie (do tego celu nie jest wymagany root). Jako, że ja korzystam na co dzień z Debiana, to instaluje Termux'a. Aplikacje i prawa administracyjne Teraz już pozostało nam tylko odpalenie terminala i zalogowanie się na użytkownika root. Do tego celu służy polecenie su . Wpiszmy je zatem w okienku Termux'a: I teraz możemy uruchamiać aplikacjie z prawami admina, tak jak to zwykliśmy robić w każdym innym linux'ie. Pamiętajmy tylko, że standardowo system plików jest zamontowany w trybie tylko do odczytu (RO) i by móc zmieniać pliki systemowe z poziomu tego terminala, musimy przemontować system plików w tryb do zapisu (RW). Robimy to w poniższy sposób: $ su # mount -o remount,rw /system Gdy skończymy się bawić, to montujemy ten system plików ponownie w tryb RO: # mount -o remount,ro /system
  3. Gdy zamierzamy zbudować sobie własny ROM na smartfon z Androidem, np. LineageOS (CyanogenMod nie jest już rozwijany) czy nawet jedynie obraz recovery (TWRP albo CWM), to potrzebne nam jest stosowne urządzenie oraz odpowiedni kod źródłowy. Skoro chcemy budować te ww. rzeczy, to prawdopodobnie nasz telefon nie jest przez to oprogramowanie jeszcze wspierany lub też sam soft nie jest regularnie aktualizowany przez dewelopera. W zasadzie zarówno pełne ROM'y jak i obrazy recovery są budowane ze źródeł Androida. Niemniej jednak, oficjalny kod dostarczany przez Google budzi czasem wiele kontrowersji i ci nieco bardziej zaawansowani użytkownicy zmieniają go, np. czyniąc go w pełni OpenSource czy też implementując w nim pewną niestandardową funkcjonalność. Tak powstają Custom ROM'y, które w późniejszym czasie z racji swojej popularności przestają być "Custom" i zaczynają żyć swoim własnym życiem obok tego Góglowskiego Androida. W przypadku budowania obrazu recovery nie są nam potrzebne całe źródła konkretnego ROM'u. Jakby nie patrzeć, potrafią one zajmować trochę miejsca, a poza tym proces ich budowania jest stosunkowo czasochłonny. Tak czy inaczej, jakieś źródła trzeba pozyskać i przygotować je do dalszej pracy. W tym artykule nie będziemy sobie jeszcze budować całego ROM'u i skupimy się na zbudowaniu od podstaw jedynie obrazu TWRP recovery ze źródeł OMNI ROM. Ten proces zostanie pokazany na przykładzie smartfona Neffos Y5 od TP-LINK przy wykorzystaniu systemu linux, a konkretnie dystrybucji Debian. Android SDK Operowanie na oprogramowaniu, które mamy w naszych smartfonach, wymaga zainstalowania na komputerze pakietu Android SDK. W nim zawarte są narzędzia deweloperskie min. fastboot i adb , przy pomocy których będziemy w stanie przeprowadzić szereg akcji na smartfonie. Te narzędzia można zainstalować w systemie na kilka sposobów. Standardowo fastboot i adb są dostępne w repozytoriach Debiana w pakietach android-tools-adb oraz android-tools-fastboot . Proces instalacji i konfiguracji tych narzędzi na Debianie został opisany w osobnym wątku. Niemniej jednak, nie są to wszystkie narzędzia, które Android SDK dostarcza, a biorąc pod uwagę fakt, że obecnie w Debianie panuje spory nieporządek w pakietach, to lepiej zainstalować Android SDK lub Android Studio bezpośrednio ze strony Google. Narzędzia repo i git Do pobrania źródeł Androida jest wykorzystywane dedykowane narzędzie repo . W dystrybucji Debiana mamy taki pakiet i możemy go bez większego problemu zainstalować. Problem w tym, że wersja tego narzędzia może być nieaktualna. Obecnie jest to 1.23 . Najnowsza wersja repo jest dostępna zawsze pod tym linkiem. By ją zainstalować ręcznie w systemie, w terminalu wpisujemy poniższe polecenia: # curl https://storage.googleapis.com/git-repo-downloads/repo > /usr/local/bin/repo # chmod a+x /usr/local/bin/repo # chown root:staff /usr/local/bin/repo Narzędzie repo operuje na git i ten pakiet również musimy w systemie sobie zainstalować. Podstawy operowania na repozytorium GIT musimy znać. Warto zatem rzucić okiem na dokumentację git'a i ją sobie chociaż powierzchownie przejrzeć. Przygotowanie katalogu roboczego pod źródła Źródła Androida trzeba gdzieś pobrać. Stwórzmy sobie zatem dedykowany katalog roboczy i przejdźmy do niego: $ mkdir /Android/android-src/ $ cd /Android/android-src/ Od tej chwili wszystkie polecenia będą wydawane w tym właśnie katalogu. Inicjowanie repozytorium GIT Na samym początku trzeba zainicjować lokalne repozytorium. Różne smartfony działają pod kontrolą innych wersji Androida (Lollipop, Marshmallow, Nougat). Jeśli zamierzamy kompilować jedynie część modułów, a nie cały ROM, i to głównie dla siebie, to warto zadbać o to, by wersja źródeł Androida pasowała do wersji Androida, którą mamy w telefonie. Niemniej jednak, w przypadku obrazu TWRP recovery możemy korzystać z najnowszych źródeł, bo w zasadzie nie będziemy wgrywać żadnych plików bezpośrednio na partycję /system/ , która zawiera stock'owy ROM. Musimy zatem określić stosowną gałąź repozytorium GIT, którą zamierzamy sobie sklonować na dysk. Lista wszystkich gałęzi jest dostępna tutaj i z reguły Custom ROM'y przestrzegają tego nazewnictwa. Warto też określić parametr --depth=1 , który uchroni nas przed pobraniem wszystkich rewizji. Zamiast tego, zostanie pobrany jedynie ostatni snapshot wskazanej przez nas gałęzi, a to z kolei znacznie zmniejszy ilość danych, które trzeba będzie przetransferować przez sieć. Bez tej opcji zostałoby pobranych jakieś 30-40 GiB, a może nawet i więcej). Źródła TWRP recovery znajdują się tutaj. Niektóre ROM'y nie mają zawartego w sobie tego repozytorium i trzeba je ręcznie określić w pliku .repo/manifest.xml w katalogu ze źródłami Androida. My jednak będziemy korzystać ze źródeł OMNI ROM, które już to repozytorium zawiera. Zatem żadnych dodatkowych kroków nie będziemy musieli przeprowadzać. Lokalne repozytorium inicjujemy w poniższy sposób: $ repo init -u https://github.com/omnirom/android -b android-7.1 --depth=1 Po zainicjowaniu lokalnego repozytorium, w katalogu roboczym powinien pojawić się folder .repo/ . W nim z kolei znajduje się plik (właściwie link) manifest.xml . Zajrzyjmy do niego i upewnijmy się, że w default revision widnieje numerek wskazanej wyżej wersji Androida ( android-7.1.x ). Warto wspomnieć, że większość repozytoriów zdefiniowanych w pliku manifest.xml jest zbędna przy budowaniu samego obrazu TWRP recovery. Jeśli komuś nie zależy na oszczędzaniu transferu danych oraz ma dostatecznie dużo miejsca na dysku, to może pobrać całe źródła OMNI ROM. Dla tych, którzy skąpią miejsca na dysku i transferu jest okrojona wersja, którą można z powodzeniem wykorzystać. Poniżej jest polecenie inicjujące lokalne repozytorium z wykorzystaniem okrojonego pliku manifest.xml . $ repo init -u git://github.com/minimal-manifest-twrp/platform_manifest_twrp_omni.git -b twrp-6.0 --depth=1 W tym przypadku, lokalne repozytorium zostało zainicjowane w oparciu o ten okrojony plik manifest.xml . Trzeba tutaj jednak wyraźnie zaznaczyć, że niektóre konfiguracje sprzętowe (czy też opcje trybu recovery) będą wymagać dodatkowych repozytoriów, które trzeba będzie ręcznie dodać do pliku .repo/local_manifests/local_manifest.xml . Warto zatem poznać budowę tego pliku i nauczyć się na nim operować. Gdy już uporządkujemy sprawy związane z repozytoriami, to przy pomocy repo sync synchronizujemy źródła każdego repozytorium, które mamy zdefiniowane w pliku manifests.xml . Naturalnie im więcej ich mamy, tym więcej miejsca będą one zajmować i dłużej będzie trwał proces synchronizacji. W przypadku, gdy dysponujemy szybkim łączem internetowym, to możemy też zwiększyć liczbę jednoczesnych połączeń przy pomocy --jobs (domyślnie 4): $ repo sync --current-branch --jobs=4 Zależności potrzebne do zbudowania Androida ze źródeł Pobranie źródeł to jedna sprawa, a ich zbudowanie to całkiem inna kwestia. By uniknąć ewentualnych problemów będziemy musieli zainstalować w systemie kilka dodatkowych zależności. Poniżej jest lista potrzebnych rzeczy: # aptitude install git-core gnupg flex bison gperf build-essential \ zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 \ lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z-dev ccache \ libgl1-mesa-dev libxml2-utils xsltproc unzip openjdk-7-jdk Bez tych pakietów, proces budowy obrazu będzie napotkał błędy podobne do tego opisanego tutaj. Przyśpieszenie procesu kompilacji z ccache Kompilacja to proces czasochłonny i dość zasobożerny. W zasadzie budując ten sam kod kilka razy, nie ma potrzeby ponawiania całego procesu kompilacji, bo w sporej części przypadków można odwołać się do już zbudowanych obiektów. Niemniej jednak, potrzebny jest nam jakiś cache dla kompilatora, którego standardowo w linux'ie nie ma. Dlatego właśnie powstało narzędzie ccache , które jest nam w stanie dość znacznie umilić życie, przy ciągłym budowaniu tych samych programów czy projektów. Narzędzie ccache musimy sobie odpowiednio skonfigurować. Na dobrą sprawę, to jedyne co musimy zrobić, to dodać te dwie poniższe zmienne do pliku ~/.bashrc lub ~/.zshrc : export USE_CCACHE=1 export CCACHE_DIR=/mnt/.ccache Rozmiar całego cache definiujemy w poniższy sposób (polecenie wywołane z głównego katalogu ze źródłami Androida): $ prebuilts/misc/linux-x86/ccache/ccache -M 50G Jeśli chcemy się upewnić, czy ccache działa prawidłowo, to odpalamy osobny terminal podczas procesu kompilacji, przechodzimy do katalogu ze źródłami i wydajemy poniższe polecenie: $ watch -n1 -d prebuilts/misc/linux-x86/ccache/ccache -s Tworzenie konfiguracji dla TWRP recovery pod konkretny model smartfona W zasadzie źródła już mamy przygotowane do budowania ale potrzebna nam jest jeszcze konfiguracja dla naszego smartfona. Musimy zatem stworzyć kilka plików i katalogów. Poniższe informacje dotyczą smartfona Neffos Y5 ale ten krok w zasadzie nie różni się w przypadku innych modeli telefonów. Jedyne co, to trzeba pozyskać pewne informacje na temat podzespołów urządzenia (min. SoC), dla którego zamierzamy zbudować obraz TWRP i wpisać te dane w stosowne miejsca. Najprościej jest zacząć od pliku /system/build.prop , który został zawarty w stock'owym firmware (można też wyciągać zawartość zmiennych przez getprop ). Podłączmy zatem na moment smartfon do komputera i przy pomocy adb patrzymy co siedzi w zmiennych ro.product.manufacturer oraz ro.product.name : # adb shell "getprop ro.product.manufacturer" TP-LINK # adb shell "getprop ro.product.name" TP802A Przechodzimy teraz do głównego folderu ze źródłami Androida i pod device/ tworzymy strukturę katalogów na zasadzie manufacturer/name . Wszystkie nazwy mają być pisane z małych liter: $ mkdir device/tp-link/tp802a/ W tak powstałym katalogu tworzymy konfigurację dla naszego smartfona, w tym przypadku Neffos Y5. Poniżej znajduje się krótkie objaśnienie co do struktury plików. Plik device.mk Zaczynamy od utworzenia pliku device.mk , gdzie będziemy definiować wszystkie niezbędne moduły i pliki wymagane do zbudowania obrazu TWRP recovery dla naszego smartfona. Plik omni_tp802a.mk Następnie tworzymy plik omni_tp802a.mk , w którym będą deklarowane informacje takie jak nazwa, model i producent smartfona. Plik AndroidProducts.mk Kolejny plik, który musimy utworzyć, to AndroidProducts.mk . W nim zamieszczamy wpis wskazujący na ten powyższy plik omni_tp802a.mk . Plik BoardConfig.mk Plik BoardConfig.mk jest w zasadzie sercem całej konfiguracji. To w tym pliku określamy min. to co tak naprawdę siedzi w naszym smartfonie. Znajdują się tutaj ustawienia platformy sprzętowej, architektury systemowej, konfiguracja kernela, rozmiary poszczególnych partycji oraz oczywiście opcje TWRP recovery. Wszystkie te parametry mogą się różnic w zależności od podzespołów smartfona, z którym mamy do czynienia. W zasadzie obraz TWRP recovery powinien działać bez zarzutu nawet przy minimalnej konfiguracji ale w przypadku budowania pełnego ROM'u, to już niestety będziemy musieli nieco bardziej się postarać, by nasz smartfon działał bez problemu na nowym oprogramowaniu. Część opcji, które trzeba określić w BoardConfig.mk , można wyciągnąć ze smartfona zaglądając do pliku /system/build.prop . Poniżej znajduje się też lekka rozpiska ułatwiająca pozyskanie informacji dla poszczególnych sekcji. Sekcja Platform Sekcję Platform może nam sprawić najwięcej problemów, zwłaszcza gdy nie mamy za bardzo pojęcia jakie podzespoły siedzą w naszym smartfonie. W tym przypadku mamy do czynienia z Neffos Y5 i on posiada SoC MSM8909 od Qualcomm. Konfiguracja konkretnego SoC jest w zasadzie stała i można ją przepisać ze źródeł innego smartfona, który ma ten sam SoC, zakładając oczywiście, że deweloper nie popełnił błędów w konfiguracji tamtego urządzenia. Sekcja Kernel Bawiąc się w ukorzenianie swoich Neffos'ów, jednym z wymaganych etapów było rozmontowanie obrazu boot.img za pomocą tych skryptów. Podczas tego procesu, w terminalu można było zanotować poniższe wyjście: Jak widzimy, praktycznie cała sekcja jest nam podana jak na dłoni i wystarczy uzupełnić stosowne parametry dodając przed ich wartościami 0x . Trzeba tutaj zaznaczyć, że my nie budujemy kernela ze źródeł Androida i załączamy tutaj plik kernela, który można wyciągnąć po rozmontowaniu stock'owego obrazu boot.img . Sekcja Qualcomm Sekcja Qualcomm definiuje szereg opcji specyficznych dla SoC tego producenta. W zasadzie to trzeba dostosować ścieżkę, która musi wskazywać na bazę platformy naszego smartfona. Ścieżka w tym przypadku wskazuje na katalog /sys/devices/soc.0/ ale z pominięciem /sys/ . Sekcja Encryption Nowsze wersje TWRP recovery wspierają szyfrowanie/deszyfrowanie partycji /data/ . Jeśli z poziomu Androida zaszyfrowaliśmy dane użytkownika, to TWRP standardowo nie będzie w stanie zamontować tej partycji, co będzie przyczyną całej masy błędów. Dlatego też musimy włączyć moduł szyfrowania. W zasadzie mamy dwa rodzaje szyfrowania: programowe i sprzętowe. To, które w naszym smartfonie zostało zaimplementowane możemy odczytać przechodząc w Ustawienia Androida => Zabezpieczenia => Typ Pamięci. W przypadku smartfona Neffos Y5, widzimy, że mamy do czynienia z szyfrowaniem sprzętowym, bo widnieje zapis "Wspomagana sprzętowo". Gdyby tam widniał zapis "Tylko programowa", to szyfrowanie byłoby jedynie programowe. Naturalnie szyfrowanie sprzętowe wymaga od nas dodatkowych nakładów pracy, by je skonfigurować. W zasadzie to trzeba będzie pozyskać szereg plików ze stock'owego firmware i uwzględnić je w obrazie TWRP. Bez tych plików, nie da rady odszyfrować danych na partycji /data/ nawet podając prawidłowe hasło. System za każdym razem zwróci nam taki oto błąd. To jakie pliki trzeba będzie uwzględnić w obrazie zależy od modelu smartfona. Nie da rady tego prosto ustalić i w zasadzie pozostaje nam dochodzenie do rozwiązania metodą prób i błędów. Możemy naturalnie podpierać się logami z trybu recovery, które mogą zawierać nazwy wymaganych bibliotek, a to już może nam wskazać dobrą drogę. Sekcja Partitions W oparciu o dane z pliku /proc/partitions lub /proc/emmc trzeba odpowiednio opisać kilka partycji smartfona. Chodzi generalnie o partycje /boot/ , /recovery/ , /system/ , /data/ oraz /cache/ . Do odczytania rozmiaru można też zaprzęgnąć różne aplikacje na Androida, np. diskinfo. Wartości podajemy w HEX. Możemy także skonfigurować sobie wsparcie dla szeregu dodatkowych systemów plików. Trzeba jednak pamiętać, że każde dodatkowe ficzery zajmują miejsce i w pewnych konfiguracjach może nam tej przestrzeni zwyczajnie zabraknąć. Tutaj mamy do dyspozycji 32 MiB i w zasadzie jest to dość sporo. Sekcja Recovery W sekcji Recovery musimy wskazać lokalizację do pliku fstab . To przy jego pomocy TWRP będzie w stanie operować na partycjach smartfona. Ten plik trzeba sobie zbudować samemu podpierając się wpisami w /proc/partitions lub /proc/emmc oraz aplikacjami na smartfona typu diskinfo. Sekcja TWRP W sekcji TWRP ustawia się opcje charakterystyczne dla TWRP recovery. Wszystkich opcji jest dość sporo i są one wyszczególnione pod tym linkiem. W zasadzie to musimy poprawnie ustawić zmienną TW_THEME , która odpowiada za rozdzielczość wyświetlacza smartfona. Do wyboru mamy: # portrait_mdpi = 320x480 480x800 480x854 540x960 # portrait_hdpi = 720x1280 800x1280 1080x1920 1200x1920 1440x2560 1600x2560 # watch_mdpi = 240x240 280x280 320x320 # landscape_mdpi = 800x480 1024x600 1024x768 # landscape_hdpi = 1280x800 1920x1200 2560x1600 Neffos Y5 ma rozdzielczość 720x1280, dlatego został wybrany portrait_hdpi . Może i mamy tutaj do wyboru dwa tryby wyświetlania (portrait i landscape) ale TWRP nie potrafi się przełączać między nimi dynamicznie. Jeśli chcemy mieć układ poziomy, to nie da rady przełączyć go w pionowy i vice versa. Pozostałe opcje mają raczej samo opisujące się nazwy. Plik vendorsetup.sh Za sprawą pliku vendorsetup.sh będziemy w stanie dodać nasze urządzenie do budowania. Ten plik będzie miał jedną linijkę, w której musimy określić dwie rzeczy: product_name oraz variant . Jeśli chodzi o product_name , to odczytujemy go z pliku omni_tp802a.mk ze zmiennej PRODUCT_NAME . Natomiast w variant możemy ustawić min. eng , user albo userdebug . Nas interesuje ta ostatnia opcja oferująca dostęp root i tryb debugowania. Budowanie obrazu TWRP recovery By przygotować środowisko pod budowę źródeł TWRP recovery, musimy wyeksportować szereg zmiennych. Nie robimy tego jednak ręcznie, a za pomocą pliku build/envsetup.sh w poniższy sposób: $ make clobber $ . ./build/envsetup.sh including device/tp-link/tp802a/vendorsetup.sh Jak widać wyżej, konfiguracja dla naszego smartfona została załączona. W przypadku korzystania z innego shell'a niż bash (w moim przypadku zsh ) wydanie tego powyższego polecenia zwraca takie oto ostrzeżenie: $ . ./build/envsetup.sh build/envsetup.sh:565: command not found: complete WARNING: Only bash is supported, use of other shell would lead to erroneous results Wygląda na to, że na czas budowy czegoś związanego z Androidem, trzeba korzystać z bash'a. Teraz możemy wpisać lunch i wybrać wcześniej stworzoną kombinację: $ lunch You're building on Linux Lunch menu... pick a combo: 1. aosp_arm-eng 2. aosp_arm64-eng 3. aosp_mips-eng 4. aosp_mips64-eng 5. aosp_x86-eng 6. aosp_x86_64-eng 7. omni_tp802a-userdebug Which would you like? Mamy na liście omni_tp802a-userdebug i to ją musimy wskazać. Możemy także od razu podać tę pozycję w lunch : $ lunch omni_tp802a-userdebug No i teraz pozostało nam już zbudowanie źródeł. Pamiętajmy tylko, że budujemy jedynie obraz TWRP recovery, a do tego celu służy poniższe polecenie: $ make clean && make -j2 recoveryimage Po kilku czy kilkunastu minutach, obraz recovery powinien nam się zbudować: Repozytorium git na Github'ie Po zbudowaniu obrazu TWRP sprawdzamy naturalnie czy działa on prawidłowo ładując plik out/target/product/tp802a/recovery.img na smartfon przy pomocy fastboot boot . Jeśli nie mamy zastrzeżeń co do działania trybu recovery, to możemy stworzoną w powyższy sposób konfigurację TWRP opublikować na GitHub'ie. Oczywiście musimy posiadać stosowne konto i stworzyć odpowiednie repozytorium. Nazwa tego repozytorium ma wskazywać na ścieżkę drzewa katalogów konfiguracji urządzenia. Przykładowo, mamy tutaj ścieżkę source/device/tp-link/tp802a/ , zatem nazwa repozytorium to android_device_tp-link_tp802a : Następnie przechodzimy do katalogu z plikami konfiguracyjnymi, z których zbudowaliśmy obraz TWRP recovery i inicjujemy w nim lokalne repozytorium: $ cd /Android/omni-twrp-6.0/device/tp-link/tp802a/ $ git init $ git remote add origin git@github.com:morfikov/android_device_tp-link_tp802a.git W pliku .git/config dopisujemy sobie te poniższe parametry: [user] name = Mikhail Morfikov email = morfik@nsa.com signingkey = 0xCD046810771B6520 [gpg] program = gpg Następnie dodajemy wszystkie plik, tworzymy commit i nową gałąź, którą nazywamy sobie, np. twrp-6.0 : $ git add --all $ git commit -S -m "first commit" $ git branch twrp-6.0 $ git checkout twrp-6.0 $ git add --all Teraz już wystarczy przesłać zmiany do zdalnego repozytorium na GitHub'ie: $ git push origin master $ git push origin twrp-6.0 I to w zasadzie cała robota. Wszelkie zmiany w repozytorium od tej pory będą rejestrowane przez system kontroli wersji. Możemy także przesłać całą konfigurację, tak by TWRP oficjalnie wspierało naszego smartfona.
  4. W jaki sposób na Neffos'ach wgrywa się dane na kartę SD? Nie wiem czy ten problem, który ja doświadczam, dotyczy tylko Neffos'ów (albo tylko mojego smartfona), czy jest to problem z Androidem ogólnie ale po podłączeniu telefonu do portu USB komputera, jestem w stanie zamontować go w systemie (linux) bez większego problemu przy pomocy jmtpfs. Mam dostęp zarówno do karty SD jak i pamięci telefonu: Wrzucam zatem przykładowy plik na kartę SD i niby zostaje on wrzucony: Przeglądając teraz zawartość karty SD z poziomu telefonu, mam coś takiego: Brakuje jednego zip'a. Okazuje się, że jest on w pamięci telefonu, a nie na karcie SD: To, że jest root na tym Neffos'ie C5 nie ma znaczenia. Bo taki sam stan rzeczy był przed root'em. Ciekawą rzeczą jest jednak fakt, że gdy zamontuję jeszcze raz system plików telefonu na kompie i podejrzę kartę SD, to ten plik tam fizycznie istnieje ale jak tylko podejrzę jego właściwości, to coś dziwnie one wyglądają: Chodzi o pozycję Size On Disk. Dlaczego ona ma 0 bajtów? Za każdym razem jak coś wgrywam na telefon/pendrive, to daję sync + ręczny unmount partycji, tak by czasem nie odłączyć telefonu podczas przesyłu danych. Ten plik nie jest uszkodzony. Znajduje się tylko.... dokładnie nie wiem gdzie... ale można go przekopiować z poziomu telefonu na kartę SD i wtedy będzie już widoczny na karcie SD. Ktoś się spotkał z takim zachowaniem i wie może coś więcej na ten temat?
  5. Każdy z nas słyszał o alternatywnym firmware na bezprzewodowe routery WiFi. Mam tutaj na myśli oczywiście OpenWRT/LEDE oraz jego GUI Gargoyle i LUCI. Przy zabawach z takim oprogramowaniem bardzo łatwo jest uszkodzić router w sytuacji, gdy tak na dobrą sprawę nie wiemy co robimy. Mi się jeszcze nie zdarzyło ubić żadnej z moich maszyn, a mam ich kilka. Problem w tym, że tak naprawdę nie wiem jak wygląda proces odzyskiwania routera w przypadku zaistnienia takiego złego scenariusza. Dlatego też postanowiłem zainicjować zdarzenie, które doprowadziło do ubicia systemu w moim TL-WR1043ND V2 od TP-LINK. Co zrobić w takim przypadku, gdy system routera nie chce wystartować, a na obudowie diody sygnalizują nieprawidłową pracę urządzenia? W takiej sytuacji będziemy musieli rozebrać sprzęt i podłączyć się do portu szeregowego na PCB za pomocą adaptera USB-UART, najlepiej na układzie CP2102, który bez problemu działa pod linux. Ten artykuł nie powstałby (tak szybko), gdyby nie pomoc ze strony @Heinz. Jaki adapter USB-UART wybrać Przed przystąpieniem do procesu odzyskiwania władzy nad systemem routera, musimy się zaopatrzyć w odpowiednie narzędzia, które umożliwią na bardzo niskopoziomową komunikację z ubitym urządzeniem. Może i system takiego routera nie może się załadować ale jest duża szansa na to, że bootloader w dalszym ciągu pracuje prawidłowo (można to poznać po migających diodach), z tym, że z jakiegoś powodu nie może on uruchomić systemu. Jest wiele adapterów USB-UART, które możemy zakupić w sklepach internetowych. Co ciekawe, w fizycznych sklepach w ogóle o takich urządzeniach nie słyszeli (przynajmniej u mnie na wsi) i raczej pozostaje nam zakup zdalny. Cena takiego adaptera zamyka się w granicach 10-20 zł. Przy zakupie musimy brać pod uwagę jedną bardzo istotną rzecz. Chodzi o to, że standardowe napięcie w porcie USB komputera jest na poziomie 5 V. Te adaptery USB-UART na takim napięciu standardowo działają w przeciwieństwie do obwodu szeregowego w większości routerów. Nie możemy zatem się podłączyć do routera od tak. Jeśli ten obwód w naszym routerze jest zasilany innym napięciem, zwykle 3,3 V, to przed zakupem musimy się upewnić, że adapter USB-UART na pinach RX i TX będzie miał takie właśnie napięcie, ewentualnie będzie wyposażony w konwerter napięć. Patrząc na fotki urządzenia w sklepie możemy czasem na nich zobaczyć informacje o dwóch rodzajach napięć 3,3 V i 5 V. Popatrzmy na te poniższe adaptery USB-UART na układach CP2102: Na pierwszym adapterze konwerter napięć jest w postaci trzech padów i zespolenie dwóch z nich steruje napięciem. Na tym drugim zaś mamy nieco bardziej cywilizowane rozwiązanie, bo napięciem operujemy przy użyciu zworki. Niemniej jednak, w obu przypadkach sterujemy jedynie napięciem na pinie VCC, a nas interesują piny RX i TX. W przypadku adapterów na układzie CP2102 napięcie na pinach RX i TX jest zawsze takie samo i wynosi 3,3 V, zatem możemy zakupić dowolny adapter o ile jest on na tym właśnie układzie. Test napięcia w konwerterze USB-UART Jeśli nie jesteśmy pewni czy zakupiliśmy odpowiedni adapter USB-UART i nie chcemy spalić routera (czy tylko jego obwodu szeregowego), to zawsze możemy sprawdzić jakie napięcie na pinach RX/TX tego adaptera faktycznie jest. Do tego celu posłuży nam multimetr. Napięcie mierzymy między GND i RX lub TX. Powinniśmy uzyskać wskazanie na poziomie około 3,3 V, tak jak to widać na poniższej fotce: Jak widać z portu USB dostarczanych jest 5 V, a a między pinem GND i TX adaptera mamy już ~3,3 V. Możemy zatem bez obaw wykorzystać to urządzenie i wpiąć się do portu szeregowego routera. W tym przypadku położenie zworki nie ma żadnego znaczenia i wskazania są takie same nawet po jej usunięciu. W przypadku, gdyby zmiana położenia zworki dawała inne napięcia, to oczywiście wybieramy tę pozycję, która wskazuje 3,3 V. Warto też zaznaczyć, że oferty adapterów USB-UART znacznie się różnią pod względem dodatków, które dostajemy razem z adapterem. Zwykle kupujemy gołe urządzenie ale czasem też dorzucane są kolorowe kabelki albo też i goldpiny. Mi do jednego zestawu dorzucili kabelki, a drugiego trochę goldpinów: Jeśli jednak nabyliśmy taki adapter bez kabelków i goldpinów, to albo musimy dokupić je osobno, albo też zrobić je samemu. Port szeregowy routera (serial port) Port szeregowy znajduje się na płycie głównej routera. By się dostać do płyty, trzeba ściągnąć obudowę. Czasami nie jest to proste zadanie i trzeba poszukać odpowiedniej instrukcji. Zwykle informacje na ten temat są podane na wiki OpenWRT przy specyfikacji konkretnego modelu routera. Jeśli zaś chodzi o TL-WR1043ND, to raczej ze ściągnięciem górnej części obudowy nie powinno być problemu. Po odkręceniu śrubek, trzeba wypiąć ją z zatrzasków. Jest ich 8: 1 na tylnej krawędzi, 2 na prawej, 2 na lewej i 3 na przedniej. Są one rozlokowane w rogach i mniej więcej po środku. Otwieranie obudowy najlepiej zacząć od jednego z rogów przy tylnej krawędzi zahaczając palcami o wystający część obudowy i podnosząc ją lekko do góry, tak by można było w powstały otwór wsunąć cienki ale sztywny kawałek metalu czy czegoś podobnego. Później wystarczy przesunąć się jak najbliżej rogu i pewnie podważyć, zatrzask powinien bez problemu puścić. Później wystarczy przesuwać się wzdłuż krawędzi i powtarzać czynność podważenia w miejscu, w którym już nie możemy dalej się przemieścić. Po zdjęciu obudowy, mamy dostęp do płyty głównej. Port szeregowy, a właściwie tylko jego wyprowadzenia są ulokowane w lewej górnej części płyty, to te cztery dziurki widoczne na poniższej fotce: Trzeba tam przylutować jakaś wtyczkę albo chociaż gołe goldpiny. Niemniej jednak, by to zrobić, musimy wyciągnąć ten PCB z routera. Trzeba pierw odkręcić gniazda anten. Niektóre z nich mogą mieć problemy z przeciśnięciem się przez otwór. Trzeba nimi trochę pokręcić i poruszać na boki: Konstrukcja wtyczki dla portu szeregowego routera Po wyciągnięciu płyty z routera, możemy zabrać się za przylutowanie goldpinów czy wtyczki. Ja sobie skonstruowałem wtyczkę z elementów odzyskanych ze starej płyty głównej. Odlutowałem z niej 4 goldpiny i ściągnąłem kawałek plastiku, który był do nich przymocowany: Później takie ustrojstwo wsadziłem na płytę routera i przylutowałem. Całość się trzyma w miarę pewnie, choć ciężko było to przylutować (brak profesjonalnych narzędzi i wprawy). Tak czy inaczej, całość działa. Warto przed podłączeniem zasilania routera sprawdzić multimetrem czy nie ma tam czasem jakiegoś zwarcia. Jeśli miernik nie zabrzęczy, tzn. że jest wszytko w porządku. Konfiguracja linux'a na potrzeby połączenia szeregowego Ja korzystam z linux'a, a konkretnie z dystrybucji Debian. Dlatego też opiszę na jego przykładzie jak przebiega proces konfiguracji systemu pod kątem połączenia komputera z portem szeregowym routera. Przede wszystkim, podepnijmy sam adapter USB-UART do portu USB komputera. Układ CP2102 powinien zostać bez większego problemu rozpoznany w naszym systemie ( idVendor=10c4 , idProduct=ea60 ). Poniżej log ze zdarzenia: kernel: usb 2-1.3: new full-speed USB device number 6 using ehci-pci kernel: usb 2-1.3: New USB device found, idVendor=10c4, idProduct=ea60 kernel: usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-1.3: Product: CP2102 USB to UART Bridge Controller kernel: usb 2-1.3: Manufacturer: Silicon Labs kernel: usb 2-1.3: SerialNumber: 0001 kernel: usbcore: registered new interface driver usbserial kernel: usbcore: registered new interface driver usbserial_generic kernel: usbserial: USB Serial support registered for generic kernel: usbcore: registered new interface driver cp210x kernel: usbserial: USB Serial support registered for cp210x kernel: cp210x 2-1.3:1.0: cp210x converter detected kernel: usb 2-1.3: cp210x converter now attached to ttyUSB0 Został zarejestrowany nowy interfejs ttyUSB0 i to przy jego pomocy będziemy się komunikować z routerem. Standardowo tylko użytkownik root oraz członkowie grupy dialout mają prawa dostępu do urządzenia /dev/ttyUSB0 . Dodajmy zatem standardowego użytkownika do tej grupy w poniższy sposób: # adduser morfik dialout Potrzebne nam jest także jakieś oprogramowanie, które zinterpretuje nasze polecenia i prześle je do routera. Musimy zatem mieć dostęp do terminala i zainstalować program do komunikacji szeregowej, np. minicom czy picocom . W Debianie znajdują się one w pakietach pod tymi samymi nazwami. Wybieramy sobie jeden z nich i instalujemy w systemie. Ja będę korzystał z picocom . Kolejna sprawa, to konfiguracja picocom . By skomunikować się z routerem za pomocą konsoli szeregowej, musimy zdefiniować kilka parametrów dla połączenia. Konkretne ustawienie zależą od sprzętu lub jego firmware. Zwykle będziemy musieli dostosować parametr baud, którego najczęściej używane wartości to 9600, 38400 lub 115200 bit/s. W przypadku korzystania tylko z 3 przewodów (na PCB routera widzieliśmy 4 piny), tj. RX, TX, GND, powinniśmy ustawić flow control: none. W zasadzie to są te najważniejsze rzeczy ale możemy także sprecyzować data bits: 8, parity: none, stop bits: 1. Oznaczenia pinów na adapterze USB-UART i PCB routera By zestawić połączenie z routerem potrzebujemy podłączyć do jego płyty co najmniej trzy przewody. Jeden z nich to masa (GND), drugi odpowiada za przesył danych (TX), a ostatni zaś za odbiór danych (RX). Jeśli chodzi zaś o sposób podłączenia przewodów, to łączymy następująco: GND-GND, RX-TX i TX-RX. Na Adapterze USB-UART mamy stosownie oznaczone piny. Pytanie tylko, które piny na płycie głównej routera to GND, RX i TX? Zwykle możemy te dane znaleźć na wiki OpenWRT. A co jeśli w przypadku naszego modelu routera tych danych nie znajdziemy na wiki? W takiej sytuacji trzeba ręcznie ustalić oznaczenia pinów, a do tego potrzebny nam będzie multimetr. Pin GND Wyłączamy zatem nasz router i przełączamy multimetr w tryb omomierza na brzęczyk. Podłączamy czarną sondę do znanego nam punktu masy na PCB routera. Jak ustalić gdzie znajduje się znany punkt masy na PCB routera? Najprościej skorzystać z zasilacza, a konkretnie z gniazda zasilania w routerze. Na zasilaczu mamy oznaczenia + i - . Wygląda to mniej więcej tak jak na force poniżej: W tym przypadku wiemy, że masa jest na zewnątrz. Gdybyśmy nie mieli oznaczeń na zasilaczu, to trzeba by sprawdzić ten stan rzeczy multimetrem. W tym celu podłączamy sam zasilacz do gniazdka i wtykamy jedną sondę we wtyczkę, a drugą sondą dotykamy zewnętrznej jej części, tak jak pokazane na poniższej fotce: Wskazanie multimetru przy takim podłączeniu przewodów zarówno do miernika jak i wtyczki zasilacza jest dodatnie, zatem wiemy, że masa jest tam, gdzie mamy podpięty czarny przewód, tj. na zewnątrz, co potwierdza oznaczenie na zasilaczu. Mając tę wiedzę, możemy przyjrzeć się bliżej routerowi. Ma on gniazdo zasilania: Widać tam bolec w środku i blaszkę na spodzie. Nasz znany punkt masy to właśnie ta blaszka, bo to ona styka się z zewnętrzną częścią wtyczki zasilacza. To do niej musimy podłączyć naszą czarną sondę, a czerwoną do każdego kolejnego pinu konsoli szeregowej. Przy jednym z pinów, multimetr zacznie nam brzęczeń, bo wskaże nam prawie zerową rezystancję. Oznacza to, że znaleźliśmy pin GND konsoli szeregowej: W przypadku pozostałych pinów, rezystancja będzie sporo wyższa: Pin VCC Mając pin GND, możemy włączyć router do prądu. Przełączamy multimetr w tryb woltomierza na zakres najbliższy 5 V (u mnie 20 DCV) i podpinamy czarną sondę do pinu GND, a czerwoną do każdego z pozostałych trzech pinów. Wynik jednego ze wskazań powinien nam pokazać 3,3 V (ewentualnie 5 V). Ten pin oznaczamy VCC. Lepiej wyprowadzić sobie kabelki z pinów na płycie, by czasem nie zewrzeć pinów, bo może nam to uszkodzić router. Pin RX i TX Pozostały nam dwa piny RX i TX. Odróżnienie ich odbywa się na zasadzie prób i błędów. Mamy w sumie dwie konfiguracje na linii komputer-router: RX-RX/TX-TX lub RX-TX/TX-RX. Niewłaściwe podłączenie przewodów sprawi, że na konsoli nie zobaczymy żadnego wyjścia lub też będzie ono w ogóle nieczytelne dla nas. Z kolei poprawne połączenie RX i TX powinno pokazać nam na konsoli komunikaty z fazy startu routera. Z reguły powinniśmy podłączyć te piny naprzemiennie, tj. RX-TX i TX-RX ale czasami oznaczenia RX/TX na adapterze USB-UART mogą już uwzględniać zamianę tych pinów i wtedy trzeba łączyć RX-RX i TX-TX i tak było w tym przypadku. Nawiązywanie połączenia z routerem za pomocą konsoli szeregowej Mając odpowiedni adapter USB-UART i oznaczone piny na routerze, możemy spróbować nawiązać połączenie z routerem przez konsolę szeregową. Podpinamy zatem przewody do adaptera USB-UART oraz do wtyczki konsoli szeregowej na płycie routera. Pamiętajmy, interesują nas jedynie piny GND, RX i TX. Adapter umieszczamy w porcie USB komputera. Odpalamy terminal i wpisujemy w nim to poniższe polecenie: $ picocom --baud 115200 --flow=none --parity=none --databits 8 /dev/ttyUSB0 port is : /dev/ttyUSB0 flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv imap is : omap is : emap is : crcrlf,delbs, Terminal ready Teraz włączamy przycisk power na routerze. Urządzenie powinno się nam włączyć (zapalą się diody): Jednocześnie obserwujemy co się będzie działo na konsoli. Przy prawidłowej konfiguracji powinniśmy zobaczyć na niej jakieś komunikaty. Jak widać, pierwsza część logu to sekwencja bootloader'a. Na samym dole zaś mamy zainicjowany start kernela. Ta powyższa sytuacja dotyczy sprawnego routera. Co jednak w przypadku, gdy naszemu routerowi coś dolega? Jeśli jesteśmy w stanie dojść do momentu, gdzie widoczny jest napis Autobooting in 1 seconds (pod koniec logu na powyższej fotce), to jak tylko się on pojawi nam na ekranie, to musimy wpisać tpl . Nie jest to łatwe zadanie i pewnie będziemy musieli powtórzyć tę czynność parokrotnie. Gdy wpiszemy tę fazę w wyznaczonym czasie, pojawi się prompt: Mapa obszaru flash'a routera W przypadku, gdy udało nam się uzyskać dostęp do bootloader'a, możemy spróbować wgrać obraz firmware na router. Zanim jednak przejdziemy bezpośrednio do wgrywania obrazu, musimy ustalić kilka rzeczy. Gdy nasz router jest sprawny, lub też ktoś inny posiada dokładnie takie samo urządzenie, które działa bez zarzutu, można z niego wyciągnąć informacje na temat układu partycji na flash'u. Te dane są dla nas bardzo cenne, bo bez nich nie uda nam się z powodzeniem odratować naszego padniętego urządzenia. Układ flash'a routera można odczytać z dwóch plików: /proc/partitions oraz /proc/mtd . Poniżej jest zawartość pierwszego z nich: root@OpenWrt:/# cat /proc/partitions major minor #blocks name 31 0 128 mtdblock0 31 1 1158 mtdblock1 31 2 6841 mtdblock2 31 3 4352 mtdblock3 31 4 64 mtdblock4 31 5 8000 mtdblock5 Rozmiar bloku równy jest 1024 KiB. Z powyższych informacji wiemy, że jakiś bliżej nieznany nam obszar na flash'u routera ma ściśle określony rozmiar. Nie mamy jednak żadnych ludzkich nazw, które byłyby w stanie nam coś o tych przestrzeniach powiedzieć. Bardziej czytelnym plikiem jest zaś /proc/mtd : root@OpenWrt:/# cat /proc/mtd dev: size erasesize name mtd0: 00020000 00010000 "u-boot" mtd1: 00121b70 00010000 "kernel" mtd2: 006ae490 00010000 "rootfs" mtd3: 00440000 00010000 "rootfs_data" mtd4: 00010000 00010000 "art" mtd5: 007d0000 00010000 "firmware" Jak widać wyżej, poza rozmiarem konkretnego obszaru (wartość w HEX) mamy również jego ludzką nazwę. Cały obraz firmware routera TL-WR1043ND V2 ma 8192 KiB, czyli 8 MiB. Możemy to odczytać sumując u-boot, firmware i art. Da nam to wartość 0x00800000, czyli po przeliczeniu właśnie 8 MiB. Kernel i rootfs jest ulokowany w firmware. Z kolei rootfs_data zawiera się w rootfs. Jeśli nasz router nie chce się uruchomić z jakiegoś powodu ale mamy jednocześnie dostęp do bootloader'a przez konsolę szeregową, to znaczy, że obszar u-boot nie został naruszony i mamy sporą szansę na odzyskanie urządzenia. Niemnie jednak, musimy sobie zdawać sprawę, że nie będziemy zapisywać całej przestrzeni flash'a i z tego względu, ten proces jest iście niebezpieczny, bo źle wgrany firmware z poziomu bootloader'a może nam kompletnie uwalić router. Urządzenia po źle wgranym firmware już odratować się tak prosto nie da. Trzeba będzie odlutować flash z PCB routera i podpiąć go do zewnętrznego programatora. Jak się to robi, to nie mam zielonego pojęcia, więc lepiej się kilka razy zastanowić przed wydaniem jakichkolwiek poleceń będąc w konsoli bootloader'a. Procedura wgrania firmware z poziomu bootloader'a Przechodzimy zatem na stronę z obrazami firmware OpenWRT/LEDE i pobieramy plik dla modelu naszego routera mający w nazwie factory. Upewnijmy się też, że ten obraz jest przeznaczony na wersję sprzętową taką, którą router ma wypisaną na spodzie obudowy. Mając pobrany obraz z firmware, musimy go jakoś przesłać na router. Do tego celu wykorzystuje się protokół TFTP (uboższa wersja protokołu FTP). Do zestawienia połączenia wymagany jest klient i serwer. Klientem będzie router. Serwerem zaś nasz komputer. Bootloader routera posiada odpowiednie oprogramowanie kliencie (narzędzie tftp ). Na komputerze musimy zaś postawić serwer. Konfiguracja serwera TFTP pod linux W dystrybucji Debian jest kilka pakietów mających w nazwie tftp . Nas interesują pakiety zawierające demona umożliwiającego postawienie serwera TFTP, np. atftpd lub tftpd . Instalujemy zatem pierwszy z brzega, tj. atftpd . W procesie ratowania routera nie działa WiFi. Musimy zatem łączyć się przy wykorzystaniu przewodu. Nie będzie nam działał też serwer DHCP, przez co nie uzyskamy adresacji dynamicznej dla komputera. Musimy określić ją statycznie w poniższy sposób: # ifdown eth0 # ip link set dev eth0 up # ip addr add 192.168.1.100/24 brd + dev eth0 Adres widoczny wyżej (192.168.1.100) nie może być przypadkowy. Będąc w konsoli bootloader'a, przy pomocy printenv możemy podejrzeć kilka zmiennych, które u-boot wykorzystuje do swojej pracy. Tam z kolei mamy min. te dwie poniższe: ipaddr=192.168.1.111 serverip=192.168.1.100 Zatem router będzie miał adres 192.168.1.111 i będzie próbował połączyć się z adresem 192.168.1.100 . Dlatego to ten adres musimy ustawić w konfiguracji karty sieciowej komputera. Jeśli kogoś interesują pozostałe zmienne zwrócone przez printenv , to są one opisane na wiki OpenWRT. Musimy jeszcze uruchomić serwer TFTP. W tym celu edytujemy pierw plik /etc/default/atftpd i przepisujemy go do poniższej postaci: USE_INETD=false OPTIONS="--tftpd-timeout 300 --retry-timeout 5 --maxthread 100 --verbose=5 --bind-address=192.168.1.100 /srv/tftp-openwrt" Tworzymy jeszcze katalog /srv/tftp-openwrt/ i nadajemy mu odpowiednie uprawnienia: # mkdir /srv/tftp-openwrt/ # chown nobody:nogroup /srv/tftp-openwrt/ Teraz stawiamy serwer poniższym poleceniem, weryfikując przy tym czy został on faktycznie uruchomiony: # /etc/init.d/atftpd start # netstat -tupan | grep atftpd udp 0 0 192.168.1.100:69 0.0.0.0:* 25408/atftpd Jak wgrać firmware przez konsolę szeregową z poziomu bootloader'a Serwer TFTP został uruchomiony, a jego katalog główny to /srv/tftp-openwrt/ . Do tego katalogu musimy wrzucić plik z obrazem firmware, nazywając go przy tym, np. obraz.bin , nazwa dowolna: # cp /home/morfik/Desktop/openwrt-15.05-ar71xx-generic-tl-wr1043nd-v2-squashfs-factory.bin /srv/tftp-openwrt/obraz.bin Przechodzimy teraz do konsoli szeregowej. U-boot dysponuje kilkoma użytecznymi poleceniami. My będziemy wykorzystywać tftp , erase oraz cp.b . Poniżej znajdują się polecenia, które ja wykorzystałem przy ratowaniu swojego TL-WR1043ND V2. Polecenie tfpt pobierze plik obrazu firmware z dysku komputera i wrzuci go do pamięci RAM routera. Ta komenda przyjmuje dwa argumenty. Są nimi adres pamięci RAM, od którego obraz firmware będzie zapisywany, oraz nazwa pliku firmware, który zostanie pobrany z serwera TFTP naszego komputera. Nazwę znamy ale problematyczne może być określenie adresu pamięci RAM. O tym będzie w dalszej części artykułu. ap135> tftp 0x80060000 obraz.bin Using eth1 device TFTP from server 192.168.1.100; our IP address is 192.168.1.111 Filename 'obraz.bin'. Load address: 0x80060000 Loading: ################################################################# Bytes transferred = 8126464 (7c0000 hex) Polecenie erase służy do zerowania pamięci flash. Przyjmuje ono również dwa argumenty. Pierwszym z nich jest adres pamięci flash, od którego ma się rozpocząć zerowanie. (ustalenie go również może być problematyczne). Drugim argumentem jest ilość bajtów, które zostaną wyzerowane (musi pasować do 0x7c0000). Operację zerowania musimy wykonać ze względu na budowę komórek pamięci flash. Dopiero po wyzerowaniu interesującego nas obszaru, możemy zacząć umieszczać na nim dane z firmware. ap135> erase 0x9f020000 +0x7c0000 Erasing flash... First 0x2 last 0x7d sector size 0x10000 125 Erased 124 sectors Polecenie cp.b ma za zdanie skopiować firmware z pamięci RAM i wgrać je na pamięć flash. Tutaj z kolei musimy określić trzy argumenty. Pierwszym z nich jest początkowy adres pamięci RAM, czyli to miejsce, w którym znajduje się początek obrazu firmware. Drugim argumentem jest początkowy adres pamięci flash, od którego zamierzamy zacząć wgrywać firmware. Trzecim zaś argumentem jest ilość bajtów, które zostaną skopiowane z pamięci RAM na pamięć flash routera. ap135> cp.b 0x80060000 0x9f020000 0x7c0000 Copy to Flash... write addr: 9f020000 done Teraz można zrestartować router. Jeśli nie pomyliliśmy adresów i przeprowadziliśmy powyższe kroki prawidłowo, to będziemy w stanie się zalogować na router z wykorzystaniem protokołu telnet. Jak ustalić odpowiednie adresy pamięci RAM i flash routera Powyższe adresy są unikatowe dla konkretnego modelu routera. Nie możemy zatem korzystać z nich w przypadku każdego routera, który nawali z jakiegoś bliżej nieznanego nam powodu. Nasuwa się zatem pytanie: jak ustalić te adresy? Zwykle tego typu informacje powinny być podane na wiki OpenWRT. W przypadku części routerów,polecenie printenv (wydane z poziomu bootloader'a) jest nam w stanie zwrócić kilka zmiennych zawierających pewne polecenia. Poniżej przykład z mojego routera: ... bootcmd=bootm 0x9f020000 ... lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize&&cp.b $fileaddr 0x9f000000 $filesize lf=tftp 0x80060000 ${dir}ap135${bc}-jffs2&&erase 0x9f050000 +0x630000&&cp.b $fileaddr 0x9f050000 $filesize lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize&&cp.b $fileaddr 0x9f680000 $filesize ... Na podstawie użytych tutaj adresów można ustalić adres pamięci RAM i flash, od których powinniśmy zacząć zapisywać dane. W bootcmd mamy adres pamięci flash, który ma zostać odczytany podczas fazy startu routera. Przed nim znajduje się tylko obszar bootloader'a. Wiemy zatem od którego adresu trzeba będzie flash wyczyścić. Znając rozmiar firmware (ten wgrany do pamięci RAM), wiemy jaki obszar należy wyzerować. W lu widzimy zaś tftp 0x80060000 . Jako, że polecenie tftp ładuje obraz do pamięci RAM routera, to mamy adres pamięci od którego możemy zacząć zapisywać dane w RAM. Nie zawsze tego typu zmienne będziemy mieć dostępne w środowisku bootloader'a i odpowiednie adresy trzeba będzie ustalić w bliżej mi nie znany jeszcze sposób. Warto tutaj nadmienić, że wyżej widoczny adres odnoszący się do pamięci flash, tj. 0x9f000000, zostawiamy w spokoju. Określa on początek pamięci i nie możemy się nim posługiwać. Przy czyszczeniu i wgrywaniu danych na pamięć flash ( erase i cp.b ) musimy uwzględnić offset na bootloader. Standardowo jest to 128 KiB, które w zapisie HEX przyjmują wartość 0x20000. Trzeba zatem tę wartość dodać do 0x9f000000 i w ten sposób otrzymamy początkowy adres pamięci flash, od którego możemy zacząć kasować/zapisywać dane z firmware, tj. 0x9f020000, czyli uzyskaliśmy dokładnie taki sam adres co w bootcmd . Trzeba także uważać na długość wgrywanego obrazu (ilość bajtów). Na końcu flash'a routera mającego podzespoły od Qualcomm Atheros znajduje się obszar art (Atheros Radio Test). Zawiera on dane kalibracyjne dla WiFi (EEPROM). Informacje zawarte na tej partycji są unikatowe dla każdego indywidualnego routera. Jeśli uszkodzimy ten obszar, np. zapisując zbyt wiele danych, to trwale uwalimy WiFi w routerze, no chyba, że mamy backup tej przestrzeni albo i całego flash'a routera i będziemy w stanie ten obszar odtworzyć. Przykład z życia, czyli planowe ubicie TL-WR1043ND Nigdy mi się jeszcze nie zdarzyło ubić żadnego z posiadanych przeze mnie sprzętów. Niemniej jednak, przydałoby się odpowiedzieć na kilka pytań, a do tego potrzebny jest test na żywym organizmie. Postanowiłem zatem wgrać na mój router TL-WR1043ND V2 kilka różnych obrazów, w tym też te nieprzeznaczone dla niego. Obrazy są różne: oficjalne (z/bez boot) oraz OpenWRT/LEDE factory/sysupgrade. Przetestowałem też zanik zasilania podczas wgrywania firmware. Wszystko po to, by sprawdzić co tak naprawdę jest w stanie uszkodzić router i w jakim stopniu. Czy obraz "factory" uszkodzi router z OpenWRT/LEDE Mając wgrany firmware OpenWRT/LEDE zwykle flash'ujemy go obrazem mającym w nazwie sysupgrade . Jak jednak zareaguje nasz router po podaniu mu pełnego obrazu factory ? W sumie zawsze chciałem to sprawdzić ale jakoś nigdy nie było okazji. Kopiujemy zatem firmware do pamięci routera via scp , logujemy się na router i wgrywamy firmware via sysupgrade : Jak widzimy wyżej, router działa bez problemu. Zatem wiemy, że obrazy OpenWRT/LEDE mające w nazwie factory nie ubiją nam routera. Niemniej jednak, w porównaniu do tych mających w nazwie sysupgrade są zwykle parokrotnie większe przez co lepiej jest korzystać z tych drugich, a factory używać jedynie przy zmianie firmware z oficjalnego na OpenWRT/LEDE. Czy obraz przeznaczony na inną wersję/model routera uszkodzi router Wgranie obrazu firmware przeznaczonego na inną wersję/model routera powinno uszkodzić router. W przypadku innej wersji sprzętowej nie zawsze jest to regułą. Pytanie zwykle sprowadza się do różnicy w podzespołach routera. Jeśli te się zmieniły nieznacznie, to jest duża szansa, że router wstanie, choć może nie działać tak jak byśmy tego oczekiwali. Ja dysponuję routerem TL-WR1043ND w wersji V2, a on się zmienił dość znacznie w porównaniu do wersji V1. Możemy zatem przypuszczać, że wgranie firmware dla wersji V1 ubije router. Sprawdźmy zatem co faktycznie się stanie (bez znaczenia czy użyjemy sysupgrade czy factory ). Nie mamy możliwości wgrania firmware przeznaczonego na inną wersję sprzętową routera. Podobnie sprawa będzie wyglądać w przypadku zupełnie innego modelu routera. Jak widać w powyższym komunikacie, został porównany ID: Invalid image, hardware ID mismatch, hw:10430002 image:10430001 . Zatem ID sprzętu nie pasuje do ID uzyskanego z obrazu, w efekcie system odmawia próby wgrania takiego firmware z oczywistych względów. Może i mechanizmy obronne wbudowane w firmware OpenWRT/LEDE działają i są w stanie nas ochronić przed tak banalnymi błędami, to w dalszym ciągu możemy uszkodzić router wgrywając oprogramowanie na siłę przez sysupgrade (przełącznik -F ). Innym sposobem flash'owania, który może nam napytać biedy, jest nieumiejętne korzystanie z narzędzia mtd , przy pomocy którego można wykonywać operacje bezpośrednio na pamięci flash. Jeśli zatem zamierzamy przy pomocy sysupgrade -F lub mtd write wgrywać jakiś obraz firmware, to upewnijmy się, że nie jest on przeznaczony na inne wersje sprzętowe routerów albo i całkowicie inne modele. Czy zanik prądu uszkodzi router z OpenWRT/LEDE Zanik prądu jest znanym mordercą routerów. Niemniej jednak, z racji różnicy w oficjalnym firmware TP-LINK'a i firmware OpenWRT/LEDE, sprawa może się inaczej potoczyć. Przede wszystkim, zanik prądu może pojawić się w różnych momentach. W przypadku obrazów TP-LINK'a mających w nazwie boot , system będzie próbował przepisać bootloader (bez części konfiguracyjnej). By to zrobić musi wyczyścić ten obszar. Jeśli w tym czasie nastąpi zanik napięcia, to nie tylko router zostanie uszkodzony ale też już nie damy rady go odzyskać przez konsolę szeregową i trzeba będzie korzystać z programatora. W przypadku firmware OpenWRT/LEDE nie musimy się aż tak martwić, bo tutaj nie jest ruszany w ogóle bootloader. W efekcie nawet jeśli nastąpi zanik napięcia, to obszar u-boot zostaje nietknięty i możemy wgrać się później przez konsolę szeregową. Podobnie sprawa ma się w przypadku obrazów oficjalnych bez frazy boot w nazwie. Tutaj również nie jest przepisywany bootloader i przy zaniku napięcia będziemy w stanie odzyskać router. Sprawdźmy zatem co się stanie po puszczeniu procesu aktualizacji firmware via sysupgrade i odłączeniu zasilania routera tak po trzech sekundach. Oczywiście flash'ujemy router z poziomu sysupgrade na firmware OpenWRT/LEDE: W momencie uwiecznionym powyżej nastąpił symulowany zanik zasilania. System routera po włączeniu nie startuje. Zapalają się wszystkie diody, po czym część z nich gaśnie. Dioda Power, System i WPS świecą się ciągle. Dioda WLAN jest zgaszona cały czas, natomiast wszystkie pięć diod od portów ethernet miga. Ten proces zdaje się być zapętlony, czyli jakaś aktywność routera się zachowała. Jako, że diody migają i router się cały czas restartuje, oznacza to, że bootloader działa raczej prawidłowo i jego obszar nie uległ przepisaniu. Niemniej jednak, bootloader nie jest w stanie podnieść systemu. Napotyka jakiś "bliżej nieznany błąd" i restartuje system mając nadzieję, że to coś da. Poniżej jest komunikat, który można zobaczyć na konsoli szeregowej: Autobooting in 1 seconds ## Booting image at 9f020000 ... Uncompressing Kernel Image ... ERROR: LzmaDecode.c, 543 Decoding error = 1 LZMA ERROR 1 - must RESET board to recover Router jest do odzyskania ale musimy zrobić użytek z konsoli szeregowej i opisanym wyżej sposobem wgrać firmware z poziomu bootloader'a. Czy obraz przeznaczony na inną wersję/model routera ubije router z oficjalnym firmware Podobnie jak w przypadku firmware OpenWRT/LEDE, oficjalny firmware TP-LINK'a również weryfikuje obrazy przed wgraniem ich przez panel administracyjny. Nie musimy się zatem obawiać, że przez przypadek wgramy obraz nieprzeznaczony dla naszego modelu/wersji routera. Czy wgranie oficjalnego firmware z "boot" w nazwie via sysupgrade uszkodzi router z OpenWRT/LEDE Firmware OpenWRT/LEDE nie dotyka praktycznie wcale obszaru flash, w którym siedzi bootloader. Jeśli teraz zamierzamy powrócić do oficjalnego firmware, to musimy pozyskać stosowny obraz. Wszystkie obrazy na stronie TP-LINK mają frazę boot . Oznacza to, że zawierają one część bootloader'a, którą proces flash'owania przepisuje podczas aktualizacji firmware z poziomu panelu administracyjnego TP-LINK'a. Jeśli taki obraz podamy w sysupgrade , to ta część bootloader'a z oficjalnego firmware powędruje na flash routera w miejsce, gdzie powinno znajdować się faktyczne oprogramowanie. W efekcie router nie będzie chciał się uruchomić ale będziemy w stanie go odzyskać przez konsolę szeregową. By uniknąć tego typu problemów, potrzebny nam jest obraz nieposiadający w nazwie frazy boot . Takie obrazy są dostępne w różnych miejscach: tutaj, tutaj, tutaj i pewnie jeszcze w wielu innych, o których nie wiem. Jeśli jednak dysponujemy obrazem mającym w nazwie boot i z jakiegoś powodu nie możemy pozyskać obrazu bez części bootloader'a, to możemy ten zbędny i niebezpieczny zarazem kawałek usunąć ręcznie. Możemy to zrobić przy pomocy dd z poziomu każdego linux'a (nawet OpenWRT/LEDE) w poniższy sposób: # dd if=firmware_z_boot.bin of=firmware_bez_boot.bin skip=257 bs=512 To powyższe polecenie usunie z początku obrazu pierwsze 131584 bajów (0x20200 w HEX) i taki obraz możemy już wgrać bez problemu na router via sysupgrade . Czy wgranie oficjalnego firmware NIEmającego "boot" w nazwie przez panel admina uszkodzi router Gdy oficjalny plik z firmware nie zawiera frazy boot w nazwie, to jest to mniej więcej taka sama wersja obrazu co w przypadku firmware OpenWRT/LEDE, który ma w nazwie factory . Wgranie oficjalnego obrazu bez boot z poziomu panelu administracyjnego TP-LINK'a nie uszkodzi naszego routera. Wgrywanie oficjalnych obrazów bez boot w nazwie jest nawet bezpieczniejsze, bo w tym przypadku nie jest przepisywany obszar u-boot. Dlatego też nawet w przypadku utraty zasilania podczas procesu flash'owania routera, będziemy w stanie odzyskać router przez konsolę szeregową. Czy obraz "sysupgrade" wgrany z panelu TP-LINK uszkodzi router Przy przechodzeniu z oficjalnego firmware na OpenWRT/LEDE stosuje się obrazy mające w nazwie factory . Z kolei zaś obrazy mające w nazwie sysupgrade są przeznaczone dla aktualizacji firmware routera. Czy wgrywając obraz sysupgrade można uszkodzić router? Sprawdźmy: Wygląda na to, że oficjalne oprogramowanie nie przyjmuje takiego obrazu zupełnie. Obraz factory i sysupgrade praktycznie niczym się nie różnią pod kątem zawartości. W przypadku factory na początku obrazu znajduje się tylko dodatkowy nagłówek i prawdopodobnie jego brak uniemożliwia wgranie obrazu na router z poziomu panelu administracyjnego TP-LINK'a. Backup pamięci flash router'a Jak widać z powyższych obserwacji bardzo ciężko jest doprowadzić router do stanu nieużywalności. Jeśli nie przytrafi nam się nagły zanik zasilania podczas procesu flash'owania, to raczej nie mamy możliwości uszkodzić routera, no chyba, że bardzo się o taki stan rzeczy postaramy. By uniknąć problemów przy ewentualnym eksperymentowaniu z routerem, najlepiej postarać się o backup całej przestrzeni flash. Backup z poziomu działającego firmware Jeśli nasz router działa bez problemu, możemy się na niego zalogować po ssh i przy pomocy dd zrzucić obrazy wszystkich pozycji, które widnieją w pliku /proc/mtd . Oczywiście moglibyśmy zrobić backup tylko u-boot, firmware i art ale później musielibyśmy kroić obraz by wyodrębnić konkretne jego części. Backup robimy przy pomocy dd zapisując dane w pamięci RAM routera: root@OpenWrt:/tmp# dd if=/dev/mtdblock0 of=/tmp/mtdblock0-u-boot.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock1 of=/tmp/mtdblock1-kernel.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock2 of=/tmp/mtdblock2-rootfs.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock3 of=/tmp/mtdblock3-rootfs_data.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock4 of=/tmp/mtdblock4-art.bin root@OpenWrt:/tmp# dd if=/dev/mtdblock5 of=/tmp/mtdblock5-firmware.bin Następnie tak utworzone pliki trzeba przesłać na komputer, np. via scp : $ scp root@192.168.1.1:/tmp/mtd\* ./ Odtwarzanie backup'u z poziomu firmware Odtworzenie backup'u uszkodzonego obszaru pamięci flash z poziomu działającego firmware jest stosunkowo proste. Załóżmy, że uszkodziliśmy sobie obszar art, w wyniku czego uszkodziliśmy WiFi. By przywrócić ten obszar, logujemy się na router i wrzucamy do pamięci plik backup'u. Później przy pomocy mtd write wgrywamy backup na odpowiedni obszar pamięci flash w poniższy sposób: # mtd write /tmp/mtdblock4-art.bin art Backup i odtwarzanie go z poziomu bootloader'a W przypadku, gdy nasz router znajduje się w stanie agonalnym ale mamy jeszcze możliwość zalogowania się do bootloader'a, to możemy pokusić się o zrobienie backup'u flash'a za sprawą konsoli szeregowej. Niemniej jednak, nie wszystkie wersje u-boot dysponują komendami umożliwiającymi przesłanie backup'u na serwer TFTP. Jeśli u-boot naszego routera takimi poleceniami nie dysponuje, to musimy postarać się o obraz initramfs, który załadujemy do pamięci RAM routera. W tym initramfs będą znajdować się potrzebne nam polecenia i backup wykonamy bez trudu. Obraz initramfs musimy sobie sami zbudować albo tez pozyskać od kogoś, kto już go zbudował. Jak przeprowadzić proces budowy obrazu initramfs wykracza poza ramy tego artykułu. (link FIXME). Jeśli zaś chodzi o kwestie odtworzenia backupu za pomocą bootloader'a, to raczej nie będziemy potrzebować takiej funkcjonalności. Poza tym, nie wszystkie bootloader'y dają nam możliwość skorzystania z mtd , tak jak to ma miejsce przy działającym firmware OpenWRT/LEDE. Nawet jeśli nasz bootloader wspiera taką możliwość, to trzeba uważać, bo nie zawsze obszary mtd widziane przez bootloader muszą się pokrywać z tymi udostępnianymi przez kernel w pliku /proc/mtd . Dlatego też lepiej posługiwać się offset'ami. Problemy z uruchomieniem routera przy podłączonym adapterze USB-UART Mój routera TL-WR1043ND V2 miał wgrany firmware OpenWRT Chaos Calmer. Był też jak najbardziej sprawny ale po podłączeniu adaptera USB-UART nie chciał się uruchomić. Zatrzymywał się na etapie bootloader'a z poniższą informacją: U-Boot 1.1.4 (Sep 10 2015 - 12:05:08) ap135 - Scorpion 1.0DRAM: sri Scorpion 1.0 ath_ddr_initial_config(211): (16bit) ddr1 init tap = 0x00000002 Tap (low, high) = (0xaa55aa55, 0x0) Tap values = (0x8, 0x8, 0x8, 0x8) 4 MB Niektóre adaptery USB-UART mogą uniemożliwić start routera. No to pojawia się pytanie jak próbować odzyskać router, gdy nie mamy możliwości zainicjowania bootloader'a? Najprościej jest kupić normalny adapter (jakieś polecane modele?), który nie zawiesi startu routera. Innym wyjściem jest podłączenie przewodu do pinu GND po włączeniu przycisku power routera. Trzeba tylko ustalić czas, po którym możemy ten pin GND podłączyć, a to już robimy metodą prób i błędów. W moim przypadku mogłem praktycznie od razu się podłączyć (tuż przed zgaśnięciem wszystkich diod na routerze). W innych sytuacjach trzeba będzie poczekać jedną czy kilka sekund i dopiero wtedy się wpiąć. Nie trzeba się oczywiście spieszyć z tym faktem, bo bootloader się będzie w kółko resetował, przez co i tak zobaczymy wszystkie komunikaty, które nam zostaną zwrócone.
  6. Przy okazji zabawy z konsolą szeregową przy ratowaniu jednego z moich routerów TP-LINK (TL-WR14043ND 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. Czym jest tryb recovery w routerach WiFi Tryb recovery ma nam nieco ułatwić odzyskiwanie uszkodzonego routera bez potrzeby zaciągania do tego celu konsoli szeregowej. Może i nasz router posiada wyprowadzenia portu szeregowego na swoim PCB ale by się do niego podłączyć musimy zwykle przebrnąć przez proces lutowania pinów. Poza tym, musimy także postarać się o zakup odpowiedniego adaptera USB-UART. W przypadku trybu recovery nie musimy się bawić w lutowanie czy zakup dodatkowych narzędzi, które pomogą nam odzyskać router. Cały proces odbywa się przez sieć, mniej więcej na takiej samej zasadzie co przy wgrywaniu nowej wersji firmware. Oczywiście są drobne różnice ale grunt, że praktycznie ten proces można przeprowadzić z wykorzystaniem przewodu ethernet (RJ-45), a to już ułatwia nam znacznie robotę. Trzeba jednak sobie zdawać sprawę, że ten recovery nie jest lekiem na każde zło. Jest to tryb bootloader'a, a by móc z niego skorzystać, bootloader musi być sprawny. Jeśli z jakiegoś powodu uszkodziliśmy bootloader, tryb recovery nam nie zadziała. Z kolei zaś, by ocenić czy bootloader funkcjonuje poprawnie, możemy przyjrzeć się diodom na obudowie routera. Jeśli te migają, to jest szansa, że bootloader jest sprawny i możemy spróbować naprawić router wgrywając firmware przez tryb recovery. Jak sprawdzić czy router posiada tryb recovery Trzeba także sobie zdawać sprawę, że nie wszystkie routery ten tryb recovery posiadają. To czy nasz router WiFi ma taki tryb zależy od producenta sprzętu, który wypuścił (bądź też i nie) aktualizację oficjalnego firmware zawierającego stosowną poprawkę dla bootloader'a. Dlatego też po ewentualnym zakupie routera, dobrze jest wgrać najnowszy firmware ze strony TP-LINK. Jeśli zawiera on nowszą wersję bootloader'a, to prawdopodobnie będziemy mieć dostęp do trybu recovery. Jeśli nie mamy pewności czy nasz router posiada tryb recovery, to nic nie stoi na przeszkodzie, by zbadać tę kwestię. Wyłączamy zatem urządzenie, po czym wciskamy i przytrzymujemy przycisk Reset. Następnie włączamy router przyciskiem Power. Jeśli zaświeci nam się dioda WPS, to bootloader posiada tryb recovery. Ja korzystając z dobrodziejstw wyprowadzonego potu dla konsoli szeregowej mogę podejrzeć co się dzieje na routerze po uruchomieniu go z wciśniętym przyciskiem reset. Poniżej znajduje się log bootloader'a z mojego TL-WR1043ND V2: W stosunku do normalnego procesu boot zmienił się is_auto_upload_firmware z 0 na 1 , co sugeruje automatyczny upload obrazu firmware przy starcie routera z wciśniętym przyciskiem Reset. Mamy też informację na temat adresu IP serwera TFTP, z którego ten obraz firmware ma zostać pobrany. W tym przypadku jest to 192.168.0.66 . Jest też nazwa pliku, króßego bootloader będzie szukał na serwerze TFTP, tj. wr1043v2_tp_recovery.bin . Tak będziemy musieli nazwać plik, którym zamierzamy wgrać na router z poziomu bootloader'a. Na tę nazwę składa się model routera ( wr1043 ), jego wersja sprzętowa ( v2 ) oraz fraza _tp_recovery.bin . Jak odzyskać router przez tryb recovery Wiemy zatem, że nasz przykładowy router TL-WR1043ND V2 posiada bootloader, który jest w stanie przełączyć się w tryb recovery. Na potrzeby tego doświadczenia popsułem po raz kolejny swój router, by sprawdzić jak wygląda odzyskiwanie tego urządzenia przez tryb recovery. Oczywiście bootloader jest w dalszym ciągu sprawny. Diody migają, choć router się zapętla i nie chce wystartować. Statyczna adresacja komputera Jako, że w procesie ratowania routera nie będzie nam działał serwer DHCP, to musimy ustawić statyczną adresację na komputerze, który zamierzamy podpiąć przewodem ethernet do routera. Na linux'ie możemy to zrobić w poniższy sposób: # ifdown eth0 # ip link set dev eth0 up # ip addr add 192.168.0.66/24 brd + dev eth0 Serwer TFTP By naprawić router, potrzebny nam będzie serwer TFTP. To taki bardzo prosty serwer FTP pozbawiony całej masy rzeczy. W różnych systemach operacyjnych jest dostępne inne oprogramowanie, które możemy wykorzystać do postawienia takiego serwera. Ja na linux'ie będę korzystał z atftpd . Ten pakiet jest dostępny standardowo w dystrybucji Debian, zatem nie powinno być problemów z jego instalacją. Natomiast konfiguracja serwera TFTP sprowadza się do edycji pliku /etc/default/atftpd , który musimy przepisać do poniższej postaci: USE_INETD=false OPTIONS="--tftpd-timeout 300 --retry-timeout 5 --maxthread 100 --verbose=5 --bind-address=192.168.0.66 /srv/tftp-openwrt" Teraz odpalamy serwer TFTP i sprawdzamy czy demon nasłuchuje: # /etc/init.d/atftpd start # netstat -tupan | grep tft udp 0 0 192.168.0.66:69 0.0.0.0:* 56791/atftpd Wgrywanie firmware na router Wyłączamy router. Pobieramy obraz firmware, czy to ze strony TP-LINK czy OpenWRT/LEDE. Plik nazywamy zgodnie z instrukcją, którą wypisał nam bootloader, tj. wr1043v2_tp_recovery.bin i wrzucamy go do katalogu /srv/tftp-openwrt/ : # cp /home/morfik/Desktop/TL-WR1043ND/openwrt-15.05-ar71xx-generic-tl-wr1043nd-v2-squashfs-factory.bin /srv/tftp-openwrt/wr1043v2_tp_recovery.bin W przypadku obrazów firmware pobranych ze strony TP-LINK trzeba trochę uważać. Jako, że zawierają one część bootloader'a, to trzeba ten kawałek obrazu pierw usunąć. Jeśli nie chcemy się w to bawić, to zawsze możemy pobrać już gotowe obrazy recovery, np. stąd. Te obrazy są takie same jak te bez boot dostępne choćby tutaj. Jedyna różnica między nimi to zmieniona nazwa na taką, której bootloader żąda. Trochę dziwne, że TP-LINK nie ma na swojej stronie tego tupu obrazów. Mając już odpowiedni plik recovery, wciskamy i trzymamy przycisk reset na obudowie routera, po czym włączamy zasilanie przyciskiem Power. Proces flash'owania potrwa chwilę. Jest on w pełni automatyczny i nie musimy wykonywać praktycznie żadnych czynności. Wystarczy trochę poczekać. Router powinien się samoczynnie uruchomić ponownie, tym razem już z działającym systemem. Cały ten powyższy proces podejrzałem sobie na konsoli szeregowej: Jak widać, tryb recovery automatyzuje cały proces naprawy routera przez konsolę szeregową. Niżej zaś w logu mamy jeszcze: Czyli proces flash'owania przebiegł bez problemów i router startuje. Zatem jeśli bootloader w naszym routerze posiada taki tryb recovery, to możemy zapomnieć o bawieniu się konsolą szeregową, przynajmniej jeśli chodzi o odzysk routerów po nieudanym wgraniu firmware.
  7. Proces root na smartfonie Neffos C5 od TP-LINK można przeprowadzić w miarę bez większych problemów, choć nie jest to rozwiązanie działające OOTB. Niemniej jednak, taki root telefonu czyni go bardziej podatnym na zagrożenia ze strony wrogich aplikacji. Ponadto, kasując czy też zmieniając pliki systemowe, możemy sprawić, że nasze urządzenie zwyczajnie przestanie nam działać, tj. już się nie uruchomi. Niektórzy użytkownicy smartfonów nie zdają sobie z tego sprawy i ukorzeniają Androida bez głębszego zastanowienia się. Mi jako linux'iarzowi, root jest niezbędny do pracy ale czy aby na pewno każdy musi go mieć? Ci z was, którzy taki root systemu przeprowadzili i nie korzystają z niego praktycznie wcale, zastanawiają się pewnie czy istnieje sposób, by cofnąć wprowadzone zmiany i przywrócić Androida do stanu pierwotnego. Krótka odpowiedź brzmi: "oczywiście, że tak" i temu procesowi przyjrzymy się w niniejszym artykule. Czy potrzebny mi jest root Android'a Standardowo w Androidzie każda aplikacja zainstalowana w telefonie ma przypisane indywidualne UID/GID (użytkownika i grupę). Żadna aplikacja nie jest w stanie odczytać danych innych programów, które zainstalowaliśmy w systemie. Zaprzęgając mechanizm root dajemy możliwość pewnym aplikacjom na dostęp do danych każdego innego programu. Jeśli teraz wgramy podejrzaną aplikację, to może ona wykorzystać fakt ukorzenienia Androida i uzyskać dostęp do poufnych danych czy nawet przejąc całkowitą kontrolę nad systemem operacyjnym telefonu, wliczając to podsłuch z mikrofonu, kamery i klawiatury. Dlatego też w pewnych sytuacjach root Androida nie jest wskazany. Trzymając się pewnych zdroworozsądkowych zasad można uniknąć zagrożeń, które niesie ze sobą root systemu. Niemniej jednak, jeśli niezbyt rozważnie korzystamy z telefonu, np. pobieramy aplikacje bez ich uprzedniej weryfikacji, to root może tylko przyczynić się do kompromitacji zabezpieczeń telefonu, przez co potencjalny atakujący może bez problemu uzyskać dostęp, np. do danych konta bankowego. Jakie zmiany po przeprowadzaniu procesu root można cofnąć Standardowo na smartfonie z Androidem mamy min. partycję /system/ oraz /data/ . Na /system/ znajduje się fabryczny Android, czyli ten system, który w tym przypadku został wypuszczony przez TP-LINK. Tej partycji nie można zapisać bez przeprowadzenia procesu ukorzeniania systemu. Z kolei zaś na partycji /data/ są przechowywane wszystkie zmiany jakie użytkownik telefonu wprowadził, np. za sprawą wgrania plików, zmiany konfiguracji/ustawień czy aktualizacji poszczególnych aplikacji. W przypadku posiadania smartfona, który przeszedł proces root, to na takim urządzeniu zostały poczynione pewne zmiany. Przede wszystkim, aplikacje SuperSU i BusyBox wgrały nam pliki do katalogu /system/xbin/ (przynajmniej na Android 5.1 Lollipop). Dodatkowo, każda aplikacja wymagająca uprawnień administratora mogła również wprowadzić jakieś zmiany na partycji /system/ . Wszelkie niestandardowe zmiany (edycja/dodanie/usunięcie plików systemowych) wprowadzane czy to przez nas czy przez aplikacje wymagające root mogą zostać cofnięte przez wgranie wcześniej zrobionego backup'u flash'a telefonu. Oczywiście nie musimy wgrywać całego backupu, a jedynie tę część, na której znajduje się partycja /system/ oraz /data/ . O ile przywrócenie partycji /system/ jest wielce niezbędne, o tyle przywrócenie partycji /data/ może trwać sporo czasu. Biorąc pod uwagę, że są tam jedynie dane użytkownika, których nie ma za wiele tuż po wyjęciu smartfona z pudełka, to przydałoby się wyczyścić również i tę przestrzeń przed odkorzenieniem Androida. Ten proces możemy przeprowadzić korzystając z Factory Reset z poziomu systemu. Powinien nam on efektywnie te dane bardzo szybko usunąć. Trzeba także pamiętać, że zmiany wprowadzone w procesie ukorzeniania telefonu nie ograniczają się jedynie do partycji /system/ . Została zmieniona przecież także partycja recovery , bez której nie byłby możliwy root Neffos'a C5. Tę partycję również musimy przywrócić. Odinstalowanie SuperSU (unroot) Od czego zatem zacząć powrót do stock'owego oprogramowania naszego Neffos'a C5? To pytanie trzeba rozważyć pod kątem wprowadzanych zmian po dokonaniu procesu root. Jeśli nie były one zbyt zaawansowane, np. instalowaliśmy jedynie kilka aplikacji wymagających praw administracyjnych w celu odczytu plików systemowych, to możemy skorzystać z opcji dostępnej w SuperSU, tj. Pełny unroot : Pamiętajmy tylko, by usunąć wszelkie aplikacje wymagające root przed usunięciem SuperSU. W przypadku mojego Neffos'a C5, opcja unroot widoczna w SuperSU nie zadziałała z początku. Po przyciśnięciu na ekranie pojawiła się jedynie informacja o czyszczeniu, a proces się zawiesił. Jeśli też natrafiliśmy na tego typu problem, to trzeba zresetować smartfon i ponowić proces unroot bezpośrednio po włączeniu urządzenia. Po odinstalowaniu SuperSU trzeba uruchomić smartfon ponownie. Spróbujmy się teraz zalogować na użytkownika root z poziomu jakiegoś terminala. Powinniśmy zobaczyć poniższy komunikat: Nie musimy się obawiać o dane zgromadzone na partycji /data/ , bo nie zostaną one ruszone w żaden sposób. Podobnie sprawa ma się w przypadku karty SD. No i nie zostaną cofnięte żadne zmiany na partycji /system/ , oczywiście w przypadku, gdy coś zmienialiśmy. Zatem widzimy, że proces likwidacji root w Neffos C5 jest praktycznie automatyczny. Niemniej jednak, co w przypadku, gdy mamy jakieś zmiany na partycji /system/ lub też wgraliśmy niestandardowy ROM? Odpowiedź jest prosta: trzeba przeprowadzić Factory Reset, który wyczyści dane na partycji /data/ oraz przywrócić partycję /system/ z wcześniej utworzonego backupu flash'a smartfona. Trzeba będzie także przywrócić partycję recovery , bo nie została ona odtworzona w procesie unroot przeprowadzonym z poziomu SuperSU. Factory Reset W przypadku wprowadzenia zmian na partycji /system/ (innych niż wgranie SuperSU i BusyBox) dobrze jest pierw usunąć wszystkie dane znajdujące się na partycji /data/ . Chodzi o to, że pliki zgromadzone na tej partycji mogą generować różne problemy w sytuacji, gdy przywraca się oryginalny ROM. Nie jest to regułą ale jeśli chcemy uniknąć błędów, to zalecane jest przeprowadzić pierw Factory Reset. Oczywiście możemy ten krok całkowicie pominąć. W przypadku ewentualnych problemów po flash'owaniu telefonu, Factory Reset będziemy mogli przeprowadzić z poziomu trybu recovery (przyciski Power + Volume UP trzymane podczas startu telefonu). Jeśli jednak chcemy wyczyścić wszystkie dane na partycji /data/ przed flash'owaniem telefonu, to możemy to zrobić z poziomu działającego systemu przechodząc do Ustawienia => Kopia i kasowanie danych => Ustawienia fabryczne: Przywrócenie partycji /system/ na Neffos C5 Jak już zostało wspomniane wyżej, na partycji /system/ znajduje się ROM TP-LINK z Androidem 5.1. By powrócić do niego musimy przywrócić całą partycję. Możemy to zrobić z poziomu aplikacji SP Flash Tool, oczywiście zakładając, że pierw utworzyliśmy backup flash. Zamontujmy ten backup w systemie przy pomocy poniższego polecenia: # losetup /dev/loop0 /media/Kabi/neffos/backup_phone/NeffosC5-orig.img W systemie powinniśmy mieć dostęp do szeregu partycji tego obrazu. Jeśli się tak nie stało to musimy odpowiednio skonfigurować moduł loop. Podejrzymy także w gdisk jak prezentuje się tablica partycji samego obrazu. Interesuje nas generalnie pozycja system : # gdisk -l /media/Kabi/neffos/backup_phone/NeffosC5-orig.img Number Start (sector) End (sector) Size Code Name ... 20 360448 8749055 4.0 GiB 0700 system ... Widzimy przy niej numer 20. Teraz w systemie odszukujemy urządzenie loop mające numer 20. W moim przypadku jest to /dev/loop0p20 . Możemy także zamontować tę partycję, by się upewnić, że faktycznie znajduje się na niej stock'owy system: # mount /dev/loop0p20 /mnt Jeśli nie ma żadnego błędu i możemy przeglądać katalog /mnt/ bez problemu, oznacza to, że jest to ta partycja, której dane musimy przesłać na smartfona. Odmontujmy ją zatem i zrzućmy dane z tego urządzenia loop do pliku przy pomocy dd : # dd if=/dev/loop0p20 of=./orig_system.img bs=2M 2048+0 records in 2048+0 records out 4294967296 bytes (4.3 GB, 4.0 GiB) copied, 216.991 s, 19.8 MB/s Mając wyodrębnioną partycję /system/ możemy ją wgrać na smartfon przy pomocy SP Flash Tool. Potrzebna nam jest tylko mapa przestrzeni flash, a ta siedzi w pliku mt6735-neffos-c5-tp-link-scatter.txt. Jest tam również pozycja dotycząca partycji /system/ . Odpalamy zatem SP Flash Tool i przechodzimy na zakładkę Download, gdzie wskazujemy nasz plik scatter.txt : Mamy tutaj wyszczególnione obszary pamięci flash w Neffos C5, które możemy zapisać. Nas interesuje w tej chwili tylko pozycja system . Zaznaczamy ją i upewniamy się, że nad tabelką wybraliśmy Download Only . Może i tutaj jest słówko Download ale trzeba patrzyć na ten proces z perspektywy telefonu, czyli to on będzie pobierał dane z komputera. Podłączamy teraz Neffos'a C5 do portu USB komputera. Następnie w SP Flash Tool przyciskamy przycisk Download i wyłączamy telefon. Następnie próbujemy go uruchomić w trybie recovery przyciskając przycisk Power + Volume UP jednocześnie. Smartfon się nie uruchomi ale rozpocznie się proces flash'owania. Sam proces powinien zakończyć się powodzeniem. Teraz można wyciągnąć smartfona z portu USB i uruchomić. Przywrócenie partycji recovery W przypadku partycji recovery możemy postąpić dokładnie w taki sam sposób, tj. wgrać stock'owy obraz przy pomocy SP Flash Tool. Niemniej jednak, nie musimy tego robić po wgraniu obrazu partycji /system/ . W moim przypadku, partycja recovery została automatycznie odtworzona po wgraniu obrazu partycji /system/ . Sprawdzenie czy Neffos C5 ma root'a Ostatnią rzeczą, która nam została to na własne oczy przekonanie się czy wszystkie zmiany zostały cofnięte. Factory reset powinien nam wyczyścić wszystkie dane na partycji /data/ . Powinniśmy mieć także stock'ową partycję /system/ oraz recovery . Z kolei root możemy sprawdzić za pomocą Root Check: Zablokowanie bootloader'a Ostatnią rzeczą, którą musimy zrobić, to zablokowanie bootloader'a. Odpalamy zatem smartfon w trybie fastboot (Power + VolUp). Podłączamy także urządzenie do portu USB komputera i wpisujemy w terminalu poniższe polecenie: # fastboot oem lock ... (bootloader) Start lock flow OKAY [4.132s] finished. total time: 4.132s Po wydaniu tej komendy, na ekranie smartfona pojawi się poniższa informacja: If you lock the bootloader you will need to install official operating system software on this phone. To prevent unauthorized access to your personal data, locking the bootloader will also delete all personal data from your phone (a "Factory data reset"). Press the Volume Up/Down button to select Yes or No. Yes (Volume Up) Lock bootloader No (Volume Down) Do not lock bootloader Proces zablokowania bootloader'a usuwa wszystkie dane użytkownika (Factory Reset), zatem upewnij się, że zrobiliśmy ewentualny backup. Przyciskamy teraz Volume Up. Po chwili zostaniemy przeniesieni do menu wyboru. Restartujemy telefon wpisując w terminalu poniższe polecenie: # fastboot reboot Smartfon zrestartuje się parokrotnie podczas procesu blokowania bootloader'a ale ostatecznie system powinien się bez większego problemu załadować na domyślnych ustawieniach.
  8. Systemy operacyjne nie są w stanie wejść w interakcję ze sprzętem, do którego nie posiadają sterowników. Linux już od dość dawna żyje sobie wśród nas i coraz bardziej pcha się na desktopy. Niemniej jednak producenci tych wszystkich urządzeń niechętnie wypuszczają sterowniki dla alternatywnych systemów. Ostatnio próbowałem uruchomić adapter TL-WN823N V2 od firmy TP-LINK. Na opakowaniu widnieje napis sugerujący, że ta karta działa pod linux'em. Rzeczywistość jednak okazała się zupełnie inna. Mianowicie, mój Debian w ogóle nie rozpoznał tej karty. Jedyne informacje jakie mi zwrócił to nazwę producenta czipu, którym okazał się być Realtek , oraz idVendor=2357 i idProduct=0109 . Sterowników dostępnych na stronie TP-LINK'a nie szło zbudować na obecnym kernelu 4.6 . Trzeba było zatem poszukać innej alternatywy. Na szczęście udało się znaleźć moduł 8192eu (rtl8192eu), który się skompilował i zainstalował bez problemu. Karta TL-WN823N V2 została wykryta i działa. W tym wpisie zostanie pokazany proces kompilacji tego modułu. Kompilacja modułu 8192eu dla TL-WN823N V2 Kod źródłowy sterownika dla karty TL-WN823N V2 znajduje się na github'ie. Pozyskać go możemy odwiedzając ten link lub też wykorzystać do tego celu narzędzie git . Który ze sposobów wybierzemy jest kompletnie bez znaczenia. W tym przypadku korzystamy z git'a: $ git clone https://github.com/Mange/rtl8192eu-linux-driver Moduł możemy zbudować ręcznie za pomocą poleceń make i make install ale nie będziemy tego robić ze względów "estetycznych". Chodzi generalnie o to, że w przypadku nowszych wersji kernela, trzeba będzie ten moduł ponownie ręcznie budować. Zamiast tak sobie życie utrudniać, zaprzęgniemy mechanizm DKMS. Po wydaniu powyższego polecenia, w katalogu roboczym został utworzony folder rtl8192eu-linux-driver . Kopiujemy go do katalogu /usr/src/ i zmieniamy jego nazwę na 8192eu-1.0 : # mv rtl8192eu-linux-driver /usr/src/8192eu-1.0 By mechanizm DKMS zadziałał, potrzebna jest mu krótka instrukcja. W katalogu /usr/src/8192eu-1.0/ musimy zatem utworzyć plik dkms.conf . Do niego zaś dodajemy poniższą treść: PACKAGE_NAME="8192eu" PACKAGE_VERSION="1.0" BUILT_MODULE_NAME="8192eu" DEST_MODULE_LOCATION="/kernel/drivers/net/wireless/" REMAKE_INITRD="yes" AUTOINSTALL="yes" MAKE="'make' all" CLEAN="'make' clean" Teraz w terminalu wydajemy to poniższe polecenie: # dkms install -m 8192eu -v 1.0 ... DKMS: install completed. Informacje o module 8192eu Moduł powinien się zbudować bez większego problemu. Sprawdźmy czy jesteśmy w stanie uzyskać jakieś informacje na jego temat: # modinfo 8192eu filename: /lib/modules/4.6.0-1-amd64/updates/dkms/8192eu.ko version: v4.3.1.1_11320.20140505 author: Realtek Semiconductor Corp. description: Realtek Wireless Lan Driver license: GPL srcversion: DC4944779709F5666CC49A7 alias: usb:v2357p0109d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v2357p0108d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v2357p0107d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v2001p3319d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0BDAp818Cd*dc*dsc*dp*icFFiscFFipFFin* alias: usb:v0BDAp818Bd*dc*dsc*dp*icFFiscFFipFFin* depends: usbcore vermagic: 4.6.0-1-amd64 SMP mod_unload modversions parm: rtw_ips_mode:The default IPS mode (int) parm: rtw_usb_rxagg_mode:int parm: rtw_qos_opt_enable:int parm: ifname:The default name to allocate for first interface (charp) parm: if2name:The default name to allocate for second interface (charp) parm: rtw_initmac:charp parm: rtw_channel_plan:int parm: rtw_chip_version:int parm: rtw_rfintfs:int parm: rtw_lbkmode:int parm: rtw_network_mode:int parm: rtw_channel:int parm: rtw_mp_mode:int parm: rtw_wmm_enable:int parm: rtw_vrtl_carrier_sense:int parm: rtw_vcs_type:int parm: rtw_busy_thresh:int parm: rtw_ht_enable:int parm: rtw_bw_mode:int parm: rtw_ampdu_enable:int parm: rtw_rx_stbc:int parm: rtw_ampdu_amsdu:int parm: rtw_lowrate_two_xmit:int parm: rtw_rf_config:int parm: rtw_power_mgnt:int parm: rtw_smart_ps:int parm: rtw_low_power:int parm: rtw_wifi_spec:int parm: rtw_antdiv_cfg:int parm: rtw_antdiv_type:int parm: rtw_enusbss:int parm: rtw_hwpdn_mode:int parm: rtw_hwpwrp_detect:int parm: rtw_hw_wps_pbc:int parm: rtw_max_roaming_times:The max roaming times to try (uint) parm: rtw_mc2u_disable:int parm: rtw_80211d:Enable 802.11d mechanism (int) parm: rtw_notch_filter:0:Disable, 1:Enable, 2:Enable only for P2P (uint) parm: rtw_tx_pwr_lmt_enable:0:Disable, 1:Enable, 2: Depend on efuse (int) parm: rtw_tx_pwr_by_rate:0:Disable, 1:Enable, 2: Depend on efuse (int) parm: rtw_phy_file_path:The path of phy parameter (charp) parm: rtw_load_phy_file:PHY File Bit Map (int) parm: rtw_decrypt_phy_file:Enable Decrypt PHY File (int) Poniżej jest jeszcze standardowa konfiguracja modułu: # systool -v -m 8192eu Module = "8192eu" Attributes: coresize = "909312" initsize = "0" initstate = "live" refcnt = "0" srcversion = "DC4944779709F5666CC49A7" taint = "OE" uevent = <store method only> version = "v4.3.1.1_11320.20140505" Parameters: if2name = "wlan%d" ifname = "wlan%d" rtw_80211d = "0" rtw_ampdu_amsdu = "0" rtw_ampdu_enable = "1" rtw_antdiv_cfg = "2" rtw_antdiv_type = "0" rtw_busy_thresh = "40" rtw_bw_mode = "33" rtw_channel_plan = "88" rtw_channel = "1" rtw_chip_version = "0" rtw_decrypt_phy_file= "0" rtw_enusbss = "0" rtw_ht_enable = "1" rtw_hw_wps_pbc = "1" rtw_hwpdn_mode = "2" rtw_hwpwrp_detect = "0" rtw_initmac = "(null)" rtw_ips_mode = "1" rtw_lbkmode = "0" rtw_load_phy_file = "68" rtw_low_power = "0" rtw_lowrate_two_xmit= "1" rtw_max_roaming_times= "2" rtw_mc2u_disable = "0" rtw_mp_mode = "0" rtw_network_mode = "0" rtw_notch_filter = "0" rtw_phy_file_path = rtw_power_mgnt = "1" rtw_qos_opt_enable = "0" rtw_rf_config = "5" rtw_rfintfs = "2" rtw_rx_stbc = "1" rtw_smart_ps = "2" rtw_tx_pwr_by_rate = "0" rtw_tx_pwr_lmt_enable= "0" rtw_usb_rxagg_mode = "2" rtw_vcs_type = "1" rtw_vrtl_carrier_sense= "2" rtw_wifi_spec = "0" rtw_wmm_enable = "1" Sections: .bss = "0xffffffffc0d01200" .data = "0xffffffffc0ce9000" .exit.text = "0xffffffffc0cc3cb4" .gnu.linkonce.this_module= "0xffffffffc0d00ec0" .init.text = "0xffffffffc0d27000" .note.gnu.build-id = "0xffffffffc0cc4000" .parainstructions = "0xffffffffc0ce7bf0" .rodata = "0xffffffffc0cc4040" .rodata.str1.1 = "0xffffffffc0cdf773" .rodata.str1.8 = "0xffffffffc0cd09c0" .smp_locks = "0xffffffffc0ce7ba0" .strtab = "0xffffffffc0d39448" .symtab = "0xffffffffc0d28000" .text = "0xffffffffc0c48000" __mcount_loc = "0xffffffffc0ce4250" __param = "0xffffffffc0ce7c10" Testy modułu 8192eu Moduł przydałoby się jeszcze przetestować i sprawdzić czy aby karta TL-WN823N V2 w ogóle działa. Podpinamy zatem nasz adapter do portu USB i po chwili w logu powinniśmy ujrzeć sporo komunikatów: kernel: usb 2-1.3: new high-speed USB device number 14 using ehci-pci kernel: usb 2-1.3: New USB device found, idVendor=2357, idProduct=0109 kernel: usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-1.3: Product: 802.11n NIC kernel: usb 2-1.3: Manufacturer: Realtek kernel: usb 2-1.3: SerialNumber: 00e04c000001 ... kernel: rtl8192eu 2-1.3:1.0 wlan20: renamed from wlan1 Wyżej widzimy wyraźnie, że pojawił się w systemie nowy interfejs wlan20 . Teraz możemy bez większego problemu skonfigurować sobie bezprzewodowe połączenie sieciowe i wydać ifup wlan20 . Problemy z modułem 8192eu Moduł 8192eu jest w stanie obsłużyć kartę TL-WN823N V2, z tym, że działa ona bardzo niestabilnie. Problematyczne może być ponowne podłączenie adaptera do portu USB. W takim przypadku, moduł może zachować się nieprzewidywalnie. Przy replug'u pomaga całkowite wyładowanie modułu za pomocą modproble -r . Później nie trzeba go ponownie ładować, zrobi to event przy podłączaniu adaptera do portu USB.
  9. Dziś postanowiłem się wziąć za ostatnią kartę WiFi, którą podesłał mi TP-LINK. Jest to nano adapter Archer T1U V1 na czipie MediaTek MT7610U identyfikowany w systemie jako idVendor=2357 , idProduct=0105 . Na opakowaniu pisało, że ta karta działa na linux'ach ale oczywiście w przypadku mojego Debiana, ten adapter nie został w ogóle wykryty. Winą są zbyt stare sterowniki, które nie zostały zaktualizowane przez MediaTek od 2013 roku. TP-Link może i ma u siebie na stronie nieco nowszą wersję sterowników, bo z 2015 roku ale nie udało mi się za ich sprawą zbudować poprawnie modułu mt7610u_sta na kernelu 4.6 . Na szczęście mamy jedną alternatywę, która pomoże nam jako tako wybrnąć z tej sytuacji. Kompilacja modułu mt7610u_sta dla Archer T1U V1 Nowszą wersję kodu źródłowego modułu mt7610u_sta możemy pozyskać z z github'a. Ten sterownik ma kilka fork'ów, niemniej jednak niektóre z nich działają, a inne nie. Generalnie trzeba przygotować się na spore problemy. Ja zdecydowałem się na tę wersję modułu, bo się buduje, choć z błędami. Wymagane jest jednak dostosowanie kilku rzeczy, by karta WiFi nam zadziałała. Pobierzmy sobie zatem źródła za pomocą narzędzia git : $ git clone https://github.com/xaep/mt7610u_wifi_sta_v3002_dpo_20130916 Problem z DKMS W przypadku modułu mt7610u_sta , jako, że jest on w opłakanym stanie, nie damy rady wykorzystać mechanizmu DKMS do automatycznego budowania modułów ilekroć tylko będziemy instalować w systemie nowszą wersję kernela. Na wypadek, gdyby kod tego modułu został poprawiony, zostawiam instrukcję dla DKMS. Kopiujemy utworzony za sprawą git'a katalog do folderu /usr/src/ i nazywamy go mt7610u_sta-1.0 : # mv mt7610u_wifi_sta_v3002_dpo_20130916/ /usr/src/mt7610u_sta-1.0 W źródłach nie ma odpowiedniej instrukcji dla DKMS i musimy takową napisać. Przechodzimy zatem do katalogu /usr/src/mt7610u_sta-1.0/ i tworzymy w nim plik dkms.conf o poniższej treści: PACKAGE_NAME="mt7610u_sta" PACKAGE_VERSION="1.0" BUILT_MODULE_NAME="mt7610u_sta" DEST_MODULE_LOCATION="/kernel/drivers/net/wireless/" REMAKE_INITRD="yes" AUTOINSTALL="yes" MAKE="'make' all" CLEAN="'make' clean" Moduł budujemy w następujący sposób: # dkms install -m mt7610u_sta -v 1.0 Make i make install Póki moduł mt7610u_sta nie zostanie doprowadzony do porządku, musimy korzystać z make oraz make install . W przeciwnym razie nie uda nam się zbudować modułu i karta nam nie będzie działać. Odpalamy zatem terminal i wpisujemy w nim te oto polecenia: # make # make install Informacje o module mt7610u_sta Moduł powinien się już znajdować na swoim miejscu, a my być w stanie odczytać trochę informacji o nim: # modinfo mt7610u_sta filename: /lib/modules/4.6.0-1-amd64/kernel/drivers/net/wireless/mt7610u_sta.ko version: 3.0.0.2 license: GPL description: RT2870 Wireless Lan Linux Driver author: Paul Lin <paul_lin@ralinktech.com> license: GPL srcversion: 0DF01AEB28FDA9F7C0AEE9F alias: usb:v0E8Dp7650d*dc*dsc*dp*icFFisc02ipFFin* alias: usb:v0E8Dp7630d*dc*dsc*dp*icFFisc02ipFFin* alias: usb:v20F4p806Bd*dc*dsc*dp*ic*isc*ip*in* alias: usb:v2019pAB31d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v293Cp5702d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v057Cp8502d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v04BBp0951d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v07B8p7610d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0586p3425d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v2001p3D02d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0DF6p0075d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0B05p17DBd*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0B05p17D1d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v148Fp760Ad*dc*dsc*dp*ic*isc*ip*in* alias: usb:v148Fp761Ad*dc*dsc*dp*ic*isc*ip*in* alias: usb:v7392pB711d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v7392pA711d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v13B1p003Ed*dc*dsc*dp*ic*isc*ip*in* alias: usb:v0E8Dp7610d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v148Fp7610d*dc*dsc*dp*ic*isc*ip*in* alias: usb:v2357p0105d*dc*dsc*dp*ic*isc*ip*in* depends: cfg80211,usbcore vermagic: 4.6.0-1-amd64 SMP mod_unload modversions parm: mac:wireless mac addr (charp) parm: debug:log verbosity level (0: off, 1: error only [default], 2: warnings, 3: trace, 4: info, 5: loud) (long) Test modułu mt7610u_sta System dysponuje już odpowiednim modułem. Wyżej widzimy również alias dla adaptera Archer T1U V1 ( idVendor=2357 , idProduct=0105 ), zatem powinien on zostać rozpoznany przez kernel. Podłączmy kartę WiFi do portu USB. W systemie powinien zostać utworzony nowy interfejs sieciowy ra0 . Teraz wystarczy już tylko skonfigurować sam interfejs, np. przez plik /etc/network/interfaces : iface ra0 inet dhcp wpa-driver wext wpa-debug-level -1 wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf Po podniesieniu interfejsu ra0 , powinniśmy zostać podłączeni do sieci bezprzewodowej: # iwconfig ra0 ra0 Ralink STA ESSID:"TP-LINK_15D5_5G" Nickname:"MT7610U_STA" Mode:Managed Frequency=5.22 GHz Access Point: EC:08:6B:84:15:D4 Bit Rate=40.5 Mb/s RTS thr:off Fragment thr:off Encryption key:C422-4DA8-3E32-42F0-4A4A-2281-5A2F-ABEC [2] Security mode:restricted Security mode:open Link Quality=60/100 Signal level:-76 dBm Noise level:-114 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 Nie za dobrze wyglądają te parametry. Problemy z modułem mt7610u_sta Ten moduł jest z bez wątpienia najgorszym z jakim miałem styczność. Może i kartę Archer T1U V1 udało się ostatecznie uruchomić ale dla linux'a to ona nie jest przeznaczona zupełnie. Brak wsparcia w sterowniku dla interfejsu nl80211 jeszcze tylko bardziej pogarsza sprawę, bo większość aktualnych narzędzi linux'owych nam zwyczajnie z tą kartą nie zadziała.
  10. Bawiąc się smartfonem Neffos C5 od TP-LINK chciałem sprawdzić czy da radę zainstalowanemu na nim Androidowi 5.1 (Lollipop) zrobić root'a. Chodzi o uzyskanie dostępu administracyjnego do systemu plików na flash'u telefonu. Proces się powiódł, z tym, że by do niego przystąpić, potrzebne są narzędzia takie jak adb i fastboot , bo przy ich pomocy możemy sterować telefonem, np. z poziomu jakiegoś linux'a. Niemniej jednak, system komputera jak i smartfona trzeba pierw przygotować odpowiednio, by taka komunikacja była możliwa i ten proces zostanie właśnie opisany poniżej. Androidowe narzędzia pod linux Na linux'ie nie musimy instalować całego zestawu narzędzi developerskich dla Androida (Software Development Kit). Bardziej zaawansowani programiści potrzebują pełnego pakietu, bo to oprogramowanie jest raczej im niezbędne do pracy z systemem Android. Nas interesują głównie dwa narzędzia: Android Debug Bridge (adb) oraz fastboot. Fastboot jest protokółem diagnostycznym, który jest wykorzystywany zwykle do wprowadzania zmian w firmware telefonu (ROM), np. aktualizacje. Podczas przełączania Androida w tryb recovery, mamy na liście pozycję fastboot mode, zatem Neffos C5 obsługuje ten protokół. Informacje na temat aktywowania tego protokołu są w dalszej części artykułu. Niemniej jednak, nie wszystkie smartfony mają aktywny tryb fastboot i trzeba mieć to na uwadze przy ewentualnej próbie skomunikowania komputera z telefonem. Za obsługę adb w Debianie odpowiada pakiet android-tools-adb . Z kolei jeśli chodzi zaś o fastboot, to musimy doinstalować w systemie pakiet android-tools-fastboot . Android Debug Bridge (ADB) W zależności od wersji Androida, którą mamy zainstalowaną w telefonie, musimy się upewnić, że posiadamy odpowiednią wersję narzędzia adb . Dla Androida 5.1 (Lollipop) musimy dysponować co najmniej wersją 1.0.32. Jeśli nie wiemy, którą wersję adb mamy zainstalowaną w systemie, to zawsze możemy to sprawdzić wpisując w terminalu poniższe polecenie: $ adb version Android Debug Bridge version 1.0.32 Na smartfonie musimy włączyć z kolei Debugowanie USB . Możemy to uczynić w chodząc w ustawienia, gdzie na samym dole mamy pozycję Informacje o telefonie . Tam z kolei (również na dole) mamy informację dotyczącą numeru kompilacji: Musimy stuknąć w ten numerek siedem razy. Dopiero wtedy w ustawieniach telefonu pojawi się pozycja Opcje programistyczne , w których to będziemy mogli zaznaczyć szukany tryb debugowania USB: Teraz możemy podłączyć telefon do komputera i sprawdzić czy zostanie on rozpoznany przez naszego linux'a. Mój Neffos C5 z początku nie został rozpoznany: # adb devices * daemon not running. starting it now on port 5037 * * daemon started successfully * List of devices attached Okazuje się, że różne rzeczy mogą mieć wpływ na to, czy telefon zostanie wykryty. Przede wszystkim, upewnijmy się, że ekran telefonu nie jest zablokowany. Być może przełączenie trybu USB w telefonie pomoże. Chodzi o przełączenie między protokołem MTP/PTP. Warto też odłączyć i ponownie podłączyć telefon do portu USB komputera, jak i ubić demona adb przez wydanie w terminalu poniższego polecenia : # adb kill-server Jeśli chodzi zaś o mojego Neffos'a C5, to żadne z tych powyższych czynności nie pomogły. System był w stanie go wykryć dopiero po dodaniu do pliku ~/.android/adb_usb.ini numeru widocznego w idVendor=2357 (domyślnie ów plik nie istnieje). Ten numer można odczytać z logu systemowego po podłączeniu telefonu do portu USB, lub też z wyjścia polecenia lsusb . Mając numer, dodajemy go do ww. pliku jako: 0x2357 Od tej chwili, za każdym razem jak tylko podłączymy telefon w trybie debugowania USB do komputera za pomocą przewodu, te dwa urządzenia będą parowane automatycznie. Oczywiście za pierwszym razem na telefonie musimy dodać informację o kluczu publicznym, którym identyfikuje się komputer. Klucz jest zaś w katalogu ~/.android/ : Po zweryfikowaniu klucza publicznego komputera, możemy ponownie wpisać w terminalu polecenie adb devices i tym razem już powinniśmy ujrzeć na liście nasz smartfon: # adb devices List of devices attached TSL7DA69OBSO49PJ device Fastboot Jeśli telefon ma odblokowany tryb fastboot, a tak jest w przypadku tego Neffos'a C5 od TP-LINK, to możemy odpalić go zwyczajnie w tym trybie. W tym celu musimy pierw wyłączyć telefon. Następnie przyciskamy i trzymamy przycisk Volume Up oraz przyciskamy równocześnie przycisk Power. Trzymamy oba przyciski wciśnięte do momentu aż telefon się włączy. Na ekranie powinniśmy ujrzeć fastboot mode, który musimy wybrać zaznaczając go przyciskiem Volume Up i aktywując przyciskiem Volume Down. W tej chwili tryb fastboot działa, a my możemy podłączyć telefon do komputera. Sprawdźmy jeszcze czy nasz linux jest w stanie zobaczyć tego smartfona. Odpalamy terminal i wpisujemy w nim poniższe polecenie: # fastboot devices TSL7DA69OBSO49PJ fastboot
  11. Przeglądając ofertę na stronie TP-LINK, zaciekawiło mnie pewne urządzenie. Chodzi o serwer druku MFP i pamięci masowej TL-PS310U. Niby słyszałem kiedyś w przeszłości frazę "Print Server" ale nigdy zbytnio się nie zastanawiałem nad tym do czego takie coś ma w istocie służyć. Po nazwie można jedynie przypuszczać, że chodzi o coś związanego z sieciowymi urządzeniami drukującymi. Niemniej jednak, ten serwer wydruku, który dotarł do mnie nie przypomina zbytnio drukarki sieciowej. To co to w takim razie jest? Zawartość opakowania Podobno obrazek jest warty więcej niż tysiąc słów, zatem zamiast się trudzić przy próbie opisu TL-PS310U, lepiej jest go zwyczajnie ofotkować, by nie było żadnych niedomówień. Poniżej znajduje się pudełko jak i jego zawartość: Tak, to małe kwadratowe w środku, to właśnie nasz serwer druku. Jego dokładne wymiary to 56 x 52 x 23 mm. No i jak widać, sam zasilacz jest od niego sporo większy. Co ciekawe, ten adapter zasilania ma 5V/2A (długość przewodu jakieś 1,5 metra), zatem niezły żarłok musi być z tego naszego małego urządzenia: Przyjrzyjmy się bliżej temu TL-PS310U: Z lewej strony widać gniazdo do podłączenia zasilacza. Mamy też port ethernet 100 mbit/s. Na tym porcie są dwie diody: zielona z podpisem "100M" i pomarańczowa z podpisem "Link". Obie diody zapalają się po podłączeniu przewodu ethernet. Świecą one ciągle, tylko ta pomarańczowa dioda miga, gdy dane są wymieniane z urządzeniem. Nie wiem po co są dwie diody. Ta pomarańczowa powinna chyba wystarczyć. Wyżej widzimy także trzecią diodę, na prawo od portu. Ta dioda z kolei sygnalizuje status podłączenia jakiegoś urządzenia do portu USB 2.0, który jest ulokowany po przeciwnej stronie obudowy: Z kolei zaś trzeci z boków TL-PS310U skrywa czarny przycisk reset: Poniżej jest jeszcze spód urządzenia zawierający min. informacje z domyślnym adresem IP, choć ten mój serwer druku uzyskał adresację po DHCP. Na tej etykiecie znajduje się także adres MAC urządzenia: Co ciekawe, na stronie TP-LINK'a jest informacja, że w opakowaniu ma znajdować się także przewód ethernet ale najwyraźniej go zabrakło. Specyfikacja TL-PS310U TL-PS310U można bardzo łatwo otworzyć. Jedyną przeszkodą na drodze jest ta naklejka, której naruszenie oznacza utratę gwarancji. W środku obudowy znajduje się mały PCB: TL-PS310U ma wbudowany SoC EST E2868M4-B, który jest w stanie obsługiwać do 4 urządzeń USB. Problem tylko w tym, że jak widzieliśmy wyżej na fotkach, TL-PS310U ma tylko jeden port USB. By mieć możliwość podłączenia więcej niż jednego urządzenia do tego serwera druku, potrzebny nam będzie HUB USB, a takiego w zestawie zabrakło. Ten czip wspiera także drukowanie z wykorzystaniem protokołu LPD/LPR przez co mamy dużą szansę obsługi tego urządzenia na stacjach linux'owych. Zgodnie z informacjami, jakie znajdują się w tym datasheet, E2868M4-B jest nie tylko w stanie obsługiwać drukarki ale także skanery, HUB'y USB, pamięć masową (USB storage) i czytniki kard SD. Na opakowaniu zaś widnieje jeszcze informacja, że damy radę do tego Print Server'a podłączyć głośniki i kamery oczywiście te na USB. Próbowałem przeskanować TL-PS310U w poszukiwaniu otwartych portów. Znalazłem jedynie te poniższe: # nmap -p 1-65535 192.168.1.132 ... Not shown: 65532 filtered ports PORT STATE SERVICE 80/tcp open http 515/tcp open printer 4660/tcp open mosmig ... O ile dwa pierwsze są w miarę logiczne, o tyle ten ostatni kompletnie nic mi nie mówi. Doszukałem się również informacji o kolejkowaniu użytkowników podczas korzystania z oprogramowania dostarczonego na płytce dołączonej do zestawu. Wygląda na to, że jeśli korzystamy w danej chwili z tego softu, to żaden inny użytkownik w sieci przez ten czas nie może korzystać z TL-PS310U. Oczywiście dla linux'a zabrakło wersji i nas ten problem nie dotyczy, bo będziemy korzystać z protokołu LPD/LPR. Zarządzenie TL-PS310U Jako, że TL-PS310U jest wyposażony jedynie w port ethernet i port USB do podłączania urządzeń, to tym serwerem druku zarządzamy w zasadzie przez dedykowane oprogramowanie, które znajduje się na płytce CD. My linux'iarze musimy sobie inaczej radzić, bo widać w XXI wieku ciągle brakuje wsparcia dla używanego przez nas systemu operacyjnego. Niemniej jednak, ten Print Server dysponuje webowym panelem administracyjnym, ubogim bo ubogim ale zawsze to lepsze niż nic. Na etykiecie znajdującej się na obudowie wiedzieliśmy, że domyślny adres tego urządzenia to 192.168.0.10 . W przypadku mojej sieci, po podłączeniu przewodu ethernet, TL-PS310U pobrał sobie adresację z serwera DHCP mojego routera. Zatem faktyczny adres tego urządzenia trzeba odczytać z lease DHCP routera i to nim się posłużyć przy próbie dostępu do panelu administracyjnego. Sam panel wygląda mniej więcej tak: W zasadzie, to ten panel jest głównie do odczytu. Możemy, co prawda, włączyć/wyłączyć konfigurację via DHCP, zresetować ustawienia do fabrycznych, zaktualizować firmware do nowszej wersji czy też zrestartować urządzenie ale nic poza tym. Podłączane do portów USB drukarki, skanery albo dyski są zwracane w formie widocznej powyżej. Jeśli chodzi zaś o zarządzenie samymi urządzeniami podpiętymi do TL-PS310U, to konfigurujemy je z poziomu konkretnego systemu operacyjnego. Na linux'ach działają jedynie drukarki i nie damy rady zamontować pendrive czy innych zewnętrznych dysków, nie wspominając już o tych wszystkich pozostałych urządzeniach, które ten serwer druku jest w stanie obsłużyć. Serwer druku TL-PS310U pod linux'em Do konfiguracji drukarki udostępnianej w sieci za pomocą TL-PS310U będziemy wykorzystywać narzędzie CUPS. Ten proces jest podobny do opisywanej już przeze mnie metody konfiguracji drukarki pod linux udostępnianej przez router z OpenWRT. Różnica sprowadza się jedynie do zdefiniowania innego protokołu i odpowiedniej jego konfiguracji. Na stronie TP-LINK'a jest informacja jak skonfigurować przykładową drukarkę na przykładzie Ubuntu. Co prawda nie używam Ubuntu ale opis graficznych aplikacji wykorzystanych w tamtym HOWTO może się przydać także użytkownikom dystrybucji Debian. Poniższy opis sprowadzać się będzie do bezpośredniej konfiguracji CUPS. Ubuntu dodaje tylko dodatkową warstwę (GUI) i przez nią CUPS jest zarządzany. My tego nie potrzebujemy i zrobimy użytek z przeglądarki internetowej. By mieć możliwość wejścia w interakcję z drukarkami musimy w systemie posiadać odpowiednie oprogramowanie. Potrzebny nam będzie pakiet cups oraz printer-driver-gutenprint zawierający bazę sterowników do całej masy drukarek. Po instalacji tych pakietów, logujemy się do panelu administracyjnego CUPS'a, który znajduje się pod adresem http://localhost:631/ . Tam z kolei dodajemy nową drukarkę sieciową z wykorzystaniem protokołu LPD/LPR: Następnie konfigurujemy protokół LPD/LPR. Nasza drukarka sieciowa będzie miała przypisany adres IP. Będzie to ten sam adres IP, którym dysponuje Print Server. Ten adres poprzedzamy lpd:// . Musimy także określić nazwę kolejki do której będą dodawane drukowane dokumenty. Cały adres może zatem przyjąć następującą postać lpd://192.168.1.132/lpr1 . Adres IP oczywiście trzeba sobie dostosować. Teraz jeszcze opisujemy naszą drukarkę: Wybieramy jej producenta oraz model: Po chwili drukarka powinna zostać dodana: I to w sumie cała robota. Drukarka powinna być widoczna w edytorach tekstu i przy jej pomocy powinniśmy być w stanie bez problemu drukować dokumenty: Czy taki serwer druku jest potrzebny linux'iarzom Czy linux'iarz powinien sobie zawracać głowę takim Print Server'em? Jeśli ma on tylko nam udostępniać drukarkę w sieci bez potrzeby zaprzęgania do tego dedykowanego komputera, to raczej można sobie darować ten TL-PS310U. Powodów jest kilka. Praktycznie każdy router WiFi dysponuje jednym lub dwoma portami USB, które są w stanie udostępnić drukarkę w sieci. Nawet jeśli nasz router dysponuje tylko jednym portem, to nic nie stoi na przeszkodzie, by do tego portu podpiąć HUB USB i rozszerzyć nieco możliwości samego routera. Z tym, że tutaj już jest potrzebny alternatywny firmware OpenWRT/LEDE. Jeśli jednak posiadamy już router ale bez portów USB, to inwestowanie w taki serwer druku jest raczej pozbawione sensu, oczywiście w przypadku sieci zrzeszającej hosty linux'owe. Chodzi generalnie o cenę, która jest na poziomie ceny routerów WiFi wspieranych przez OpenWRT/LEDE. Zamiast TL-PS310U można nabyć taki właśnie router i wgrać na niego alternatywne oprogramowanie. Przy tym nie ma problemów z przerobieniem takiego routera na serwer druku, który będzie w o wiele lepszym stopniu nadawał się do sieci linux'owych.
  12. Ostatnio recenzowałem dwie bezprzewodowe karty WiFi w standardzie mini/mikro, które podesłał mi TP-LINK. W zestawie był jeszcze jeden adapter, a konkretnie chodzi o kartę Archer T1U. Jest ona bardzo podobna do TL-WN725N, przynajmniej pod względem wizualnym. To co odróżnia od siebie te dwa adaptery, to pasmo, w którym mogą pracować oraz oczywiście prędkość transferu. Archer T1U działa w 5 GHz (standard AC) i teoretycznie może pochwalić się prędkością do 433 mbit/s. Zobaczmy zatem jak on spisze się w przypadku linux'ów. Zawartość pudełka Opakowanie standardowe, tj. bardzo duże jak na rozmiary samego adaptera. W środku poza kartą Archer T1U mamy też płytkę ze sterownikami i całą masę makulatury. Jest też instrukcja w języku polskim. Całość wygląda mniej więcej tak: Jak widać, adapter jest malutki. Po wsadzeniu go do portu USB, idealnie komponuje się z obudową laptopa. Nie wystaje zanadto i nie idzie go uszkodzić przez przypadkowe zahaczenie: Sterowniki i firmware dla Archer T1U Niestety, w porównaniu do swojego kolegi, tj TL-WN725N, adapter Archer T1U nie jest wykrywany w ogóle przez mojego Debiana. Niby na opakowaniu jest wyraźnie napisane, że jest wsparcie dla linux'a ale widać powoli trzeba odchodzić od wiary w to co producenci wypisują na opakowaniach. Po wsadzeniu tej karty do portu USB, w logu systemowym zobaczymy jedynie te poniższe komunikaty. kernel: usb 2-1.3: new high-speed USB device number 9 using ehci-pci kernel: usb 2-1.3: New USB device found, idVendor=2357, idProduct=0105 kernel: usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-1.3: Product: WiFi kernel: usb 2-1.3: Manufacturer: MediaTek kernel: usb 2-1.3: SerialNumber: 1.0 mtp-probe[51104]: checking bus 2, device 9: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3" mtp-probe[51104]: bus: 2, device: 9 was not an MTP device Karta jest na czipie MediaTek MT7610U. Sterowniki OpenSource od MediaTek dla tego chipu ostatni raz były aktualizowane w 2013 roku. Zaś te driver'y, które są na stronie TP-LINK'a, są datowane na środek roku 2015. Świat nie stoi w miejscu i przez te parę lat kernel linux'a się trochę zmienił. Także na obecnym kernelu 4.6 te sterowniki się nam zbytnio nie przydadzą, chyba, że ktoś je ogarnie i zmodyfikuje w taki sposób, by się zbudowały bez problemu na kernelu 4.6 . Po wielu trudach znalezienia rozwiązania problemu sterowników do karty Archer T1U, natrafiłem na fork bazowych sterowników, które znośnie się budują na najnowszym kernelu dostępnym w Debianie. Znośnie nie oznacza bez błędów, oraz też pozostaje kwestia jakości samego modułu. Proces budowy modułu mt7610u_sta został opisany w osobnym artykule. Specyfikacja karty Archer T1U Trzeba wyraźnie zaznaczyć, że Archer T1U pod kontrolą sterownika mt7610u_sta zachowuje się bardzo niestabilnie. Ten moduł cierpi także na brak wsparcia dla interfejsu nl80211. Zatem narzędzia takie jak iw , crda , hostapd czy wpa_supplicant nie będą chciały z nim współpracować. Poniżej zaś jest zamieszczone wyjście polecenia lsusb : # lsusb -vvv -d 2357:0105 Bus 002 Device 012: ID 2357:0105 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.01 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x2357 idProduct 0x0105 bcdDevice 1.00 iManufacturer 1 MediaTek iProduct 2 WiFi iSerial 3 1.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 74 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 160mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 8 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 255 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x08 EP 8 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x09 EP 9 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 12 bNumDeviceCaps 1 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported Device Status: 0x0000 (Bus Powered) Problemy z Archer T1U pod linux'em Adapter WiFi Archer T1U nie działa za dobrze pod linux'em. Jeśli miałbym być szczery, z tą kartą są same problemy. Transfer jest wręcz tragiczny, a zasięg jeszcze gorszy. Zanim jednak przejdziemy do testów, trzeba wspomnieć, o fakcie, że logu systemowym podczas pracy tego adaptera jest generowana cała masa komunikatów podobnych do tego poniżej: kernel: DeQueueRunning[0]=] TRUE! Co jakiś czas można też zauważyć informacje o temperaturze czipu: kernel: MlmePeriodicExec - Do VCORecalibration again!(LastTemperatureforVCO=28, NowTemperature = 49) kernel: MlmePeriodicExec - Do VCORecalibration again!(LastTemperatureforVCO=49, NowTemperature = 70) Podczas 5 minut pracy (intensywnego pobierania danych), karta się zagotowała tak mocno, że przestała działać. Trzeba było posiłkować się dodatkowym wiatrakiem chłodzącym, by dokończyć testy. Generalnie odradzam tę bezprzewodową kartę wszystkim linux'iarzom. Testy Archer T1U Jakieś testy trzeba przeprowadzić, by nie być gołosłownym. Zatem po podpięciu adaptera do portu USB, zapuściłem iperf . Poniżej jest fotka obrazująca transfer z laptopa oddalonego od routera o jakieś 2 metry: Biorąc pod uwagę fakt rozpoczęcia pracy i przepracowane 2 minuty, to transfer jest taki sobie. Pamiętajmy, że Archer T1U ma pracować w paśmie 5 GHz i osiągać prędkość do 433 mbit/s. Póki co nawet się nie zbliżył do połowy tej wartości. Przestawmy laptopa trochę dalej (3-4 metry) od routera i między te dwa urządzenia wstawmy niezbyt grubą ścianę: Tu już mamy dość poważny problem z ubytkiem transferu. No to pójdźmy jeszcze dalej (6 metrów) i dołóżmy jeszcze jedną ścianę: Z początku nie było tak źle, w porównaniu do poprzedniej próby. Natomiast w połowie testu coś się stało i transfer zdechł zupełnie. To jest właśnie ten moment, w którym karta uległa przegrzaniu. Ostatnie dwie próbki, są po podłączeniu wiatraka. Zatem bez dodatkowego chłodzenia, Archer T1U pod linux'em wysiądzie po 5 minutach transferu z prędkością 20 mbit/s.
  13. Jako mobilny osobnik wiem jak ważne są niewielkie rozmiary sprzętu, na którym przyjdzie mi operować gdzieś poza miejscem mojego zamieszkania. Wielkość urządzeń ma zatem dla mnie ogromne znaczenie. Nikogo raczej nie trzeba przekonywać, że wraz z miniaturyzacją sprzętu, maleje również jego funkcjonalność. Idealne urządzenie to takie, które ma na tyle małe wymiary, by za ich sprawą nie ucierpiały wszystkie te niezbędne nam dobrodziejstwa oferowane przez nowe technologie. Bez internetu w obecnych czasach ani rusz, zatem potrzebne nam są różnego rodzaju adaptery i karty WiFi umożliwiające naszym komputerom bezprzewodowe połączenie sieciowe. Jest cała masa urządzeń, które moglibyśmy podłączyć do naszych laptopów ale nie wszystkie z nich mają na tyle małe wymiary, by ich zastosowanie było dla nas iście komfortowe. TP-LINK dysponuje w swojej ofercie kilkoma bezprzewodowymi kartami sieciowymi w standardzie micro/mini. W tym wpisie zobaczymy jak na linux'ie będzie sprawował się mini adapter TL-WN823N. Zawartość pudełka W pudełku poza samym adapterem TL-WN823N mamy również trochę makulatury, w tym też instrukcję obsługi, oraz płytkę ze sterownikami. Instrukcja jest w kilku językach, min. również i po polsku. Poniżej znajdują się fotki opakowania oraz jego zawartości: Jak widzimy, karta ma interfejs USB 2.0 oraz posiada przycisk WPS. Na dobrą sprawę w przypadku mojego laptopa, ta karta jest zwrócona tym przyciskiem w dół. W efekcie zostaje mi może 1,5 cm przestrzeni, by ten przycisk wcisnąć, co nie jest chyba wykonalne bez uszkadzania samej karty czy też i portu USB w laptopie. Sam przycisk bardzo ciężko się wciska, zwłaszcza, gdy adapter jest w porcie USB. Oczywiście można korzystać z przedłużki ale takowej do zestawu nie dołączono, w końcu to mini adapter. Poniżej jest fotka adaptera TL-WN823N w porcie USB mojego laptopa: Nie przypadła mi do gustu również ta skuwka, z którą karta może i dobrze się prezentuje ale trzeba ten zbędny dodatek zdejmować i ciągle pilnować, by go nie zgubić. To mniej więcej tyle z pierwszego wrażenia po wyjęciu adaptera z pudełka. Zobaczmy, czy zadziała on nam bezproblemowo pod linux'em. Adapter TL-WN823N i jego dwie wersje Zgodnie z tym, co można wyczytać na stronie TP-LINK'a, adapter TL-WN823N ma dwie różne wersje: V1 i V2 . W tym przypadku trafiła mi się wersja V2. Niestety to urządzenie w tej wersji nie jest w ogóle rozpoznawane przez mojego Debiana z kernelem 4.6 i chyba jest to regułą w przypadku wszystkich pozostałych linux'ów. Po podłączeniu urządzenia do portu USB, w logu systemowym pojawiają się tylko te poniższe komunikaty: kernel: usb 2-1.3: new high-speed USB device number 10 using ehci-pci kernel: usb 2-1.3: New USB device found, idVendor=2357, idProduct=0109 kernel: usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-1.3: Product: 802.11n NIC kernel: usb 2-1.3: Manufacturer: Realtek kernel: usb 2-1.3: SerialNumber: 00e04c000001 mtp-probe[33755]: checking bus 2, device 10: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3" mtp-probe[33755]: bus: 2, device: 10 was not an MTP device Urządzenie jest wykrywane jako idVendor=2357 oraz idProduct=0109 ale kernel nie ma dla niego stosownego modułu. W rezultacie nie jest rejestrowany nowy interfejs sieciowy sieciowy i nie damy rady wejść w interakcję z kartą TL-WN823N v2 na linux'ie, przynajmniej nie zaraz po jej podłączeniu do portu USB naszego laptopa czy komputera. Sterowniki dla TL-WN823N od TP-LINK Na stronie TP-LINK'a są niby sterowniki do karty TL-WN823N V2. Niemniej jednak, przy ich kompilacji na kernelu 4.6 jest zwracany bliżej nie znany mi błąd. W efekcie kompilacja nie może być kontynuowana i nici ze sterownika. Oczywiście na stronie mamy wzmiankę, że sterownik jest przeznaczony dla kernela w wersji 2.6.18 - 3.10.10 ale przydałoby się go od czasu do czasu zaktualizować. Nawet stabilny Debian ma kernela w wersji 3.16 , a wszyscy wiemy, że nikt z niego nie korzysta, bo za stary. Moduł 8192eu (rtl8192eu) No nic, zostawmy te nieszczęsne sterowniki od TP-LINK'a i spróbujmy znaleźć jakieś alternatywne rozwiązanie. Z tego co można było wyczytać na wikidev, adapter w wersji V1 był rozpoznawany przez system i działał w oparciu o moduł rtl8192cu . W przypadku V2 potrzebny nam jest moduł 8192eu (rtl8192eu), a takim kernel linux'a póki co nie dysponuje. Niemniej jednak, sami możemy skompilować sobie moduł 8192eu i podczepić go pod mechanizm DKMS. Trzeba tylko wyraźnie zaznaczyć, że moduł jest bardzo ale to bardzo niestabilny i może powodować całą masę problemów. Niemniej jednak, karta TL-WN823N potrafi działać na nim dość dobrze. Specyfikacja karty TL-WN823N Karta TL-WN823N działa w paśmie 2,4 GHz (standard N) i teoretycznie może osiągnąć 300 mbit/s. Niestety nie dam rady zamieścić wyjścia polecenia iw list z powodu braku wsparcia sterownika karty dla interfejsu nl80211. Inne narzędzia operujące na tym interfejsie, np. crda , hostapd czy też wpa_supplicant również będą mieć problemy z obsługą tej karty. Poniżej jest zaś jedynie wyjście polecenia lsusb : # lsusb -vvv -d 2357:0109 Bus 002 Device 047: ID 2357:0109 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x2357 idProduct 0x0109 bcdDevice 2.00 iManufacturer 1 Realtek iProduct 2 802.11n NIC iSerial 3 00e04c000001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 53 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 5 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 2 802.11n NIC Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x87 EP 7 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 3 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x08 EP 8 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 12 bNumDeviceCaps 1 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 Link Power Management (LPM) Supported Device Status: 0x0001 Self Powered Tryb monitor Na chwilę obecną moduł 8192eu nie pozwala na przełączenie karty TL-WN823N w tryb monitor. Tryb oszczędzania energii Tryb oszczędzania energii w przypadku adaptera TL-WN823N zdaje się działać i to nawet poprawnie. Choć oczywiście jak to na linux'ach bywa, ten tryb może powodować problemy. Jeśli przeglądanie stron www odbywa się z wyraźnym opóźnieniem lepiej jest ten tryb wyłączyć. Można to zrobić przez załadowanie modułu 8192eu z odpowiednimi opcjami. W tym celu wystarczy dopisać do pliku /etc/modprobe.d/modules.conf poniższą linijkę: options 8192eu rtw_power_mgnt=0 Programowy WPS Może i karta TL-WN823N posiada przycisk WPS ale w przypadku laptopów jest on kompletnie bezużyteczny. Poza tym, na linux'ie i tak nie działa. Niemniej jednak ten adapter ma zaimplementowaną obsługę programowego WPS, który działa mniej więcej na takiej samej zasadzie co ten fizyczny, z tym, że z poziomu systemu operacyjnego "wciskamy" wirtualny przycisk. Tryb AP Na chwilę obecną moduł 8192eu nie pozwala na przełączenie karty TL-WN823N w tryb AP. Test karty TL-WN823N No to już wiemy z grubsza czym karta TL-WN823N dysponuje. Jak widać, średnio się ta karta nadaje na linux'a pod względem funkcjonalności. Oczywiście większość z nas raczej chciałaby jedynie podłączyć się do istniejącej sieci WiFi i pobierać lub wysyłać dane. Sprawdźmy zatem jak ten adapter będzie się zachowywał w takim przypadku. Poniższa fotka odnosi się do sytuacji, w której laptop znajduje się w tym samym pomieszczeniu co router WiFi TP-LINK Archer C2600. Odległość nie przekracza 2 metrów: Około 170 mbit/s. Całkiem przyzwoicie jak na taki mały adapter. Na opakowaniu może i widnieje i 300 mbit/s ale wszyscy wiemy, że te liczby lekko odbiegają od stanu faktycznego. Sprawdźmy jak będzie wyglądał transfer po zmianie położenia laptopa i dołożeniu przeszkody w postaci niezbyt grubej ściany. Odległość około 3-4 metry: Dość spory spadek transfery o około 30 mbit/s. Dorzućmy jeszcze jedną ścianę i zobaczmy jak adapter sobie poradzi w takiej sytuacji. Odległość 5-6 metrów: Poniżej 100 mbit/s ale generalnie nie jest źle, choć mogłoby być trochę lepiej. Problemy z TL-WN823N pod linux'em Jako, że sterownik nie ma póki co wsparcia dla interfejsu nl80211, to nie możemy go określać w konfiguracji różnych narzędzi. W przypadku osób, korzystających z wpa_supplicant do konfiguracji sieci WiFi, zamiast określać w pliku /etc/network/interfaces opcji wpa-driver nl80211 , musimy dać wpa-driver wext , przykładowo: iface wlan20 inet dhcp wpa-driver wext wpa-debug-level -1 wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf Parametry sieci umieszczamy standardowo w pliku określonym przez parametr wpa-conf .
  14. Świat ciągle idzie do przodu i oferuje nam coraz to nowsze rozwiązania, które są w większym stopniu dostosowane do naszych potrzeb. Mobilność w obecnych czasach to podstawa. Niekoniecznie jednak musimy upychać naszą wirtualną rzeczywistość w urządzeniu wielkości smartfona. Może takie rozwiązanie idealnie nadaje się dla osób podróżujących ale też nic nie stoi na przeszkodzie, by zabrać ze sobą nieco większy komputer w postaci laptopa. Niemniej jednak, w terenie ciężko o przewód, którym moglibyśmy się podpiąć do sieci. Dlatego też technologia WiFi jest nam zwykle niezbędna. Na rynku jest wiele kart i adapterów, które mogą nam umożliwić połączenie bezprzewodowe, choć nie wszystkie z nich są na tyle poręczne, abyśmy rozważali ich zakup i użytkowanie. Potrzebne jest nam raczej urządzenie na tyle minimalistyczne, że na pierwszy rzut oka nie zauważymy żadnej różnicy po jego podłączeniu do komputera. Firma TP-LINK oferuje kilka rozwiązań tego typu i w tym wpisie przyjrzymy się nieco bliżej nano adapterowi WiFi TL-WN725N i przetestujemy jego kompatybilność z linux'ami. Zawartość pudełka Pudełko gabarytowo jest ogromne w porównaniu do rozmiarów adaptera TL-WN725N. W zasadzie rozmiary opakowania są dyktowane makulaturą (instrukcja obsługi) i płytką CD ze sterownikami. Poniżej są fotki opakowania oraz jego zawartości: Instrukcja obsługi jest również w języku polskim. Niżej zaś jest przedstawiony sam adapter: Jest on mały, choć 2/3 jego wielkości to złącze USB 2.0 i raczej mniejszego urządzenia się już zrobić nie da. No może się i da ale raczej problematyczne byłoby wyciąganie go z portu USB. Po podłączeniu do laptopa, karta jest praktycznie niezauważalna. Jedynie podczas pracy mieni się zielonym kolorem sygnalizującym przesył danych w sieci WiFi. Wygląda to mniej więcej tak: Plusem tak małych rozmiarów jest fakt, że praktycznie nie uszkodzimy tego urządzenia (czy samego portu USB) przez przypadkowe zahaczenie o nie, tak jak to ma miejsce w przypadku innych kart bezprzewodowych, które wystają kilka centymetrów poza obudowę laptopa. Jaką wersję adaptera TL-WN725N posiadam Na rynku można spotkać dwie wersje karty TL-WN725N. W tym przypadku mamy do czynienia z V2 ale też gdzieniegdzie widuje się V1 . Po wyglądzie praktycznie nie damy rady ich odróżnić. Jeśli nie posiadamy pudełka, to jedyną opcją, jaka nam pozostaje, to podłączenie karty do portu USB i identyfikacja jej przez system. Każda z wersji działa na linux'ie w oparciu o inny moduł. Wersja V1 wykorzystuje rtl8192cu zaś wersja V2 r8188eu . Sterowniki i firmware dla TL-WN725N Na opakowaniu adaptera TL-WN725N widnieje informacja, że to urządzenie jest wspierane min. przez alternatywny system operacyjny jakim jest linux. Sprawdzimy czy faktycznie tak jest i podłączmy tę kartę do portu USB naszego komputera. W logu systemowym powinny pojawić się poniższe komunikaty: kernel: usb 2-1.3: new high-speed USB device number 12 using ehci-pci kernel: usb 2-1.3: New USB device found, idVendor=0bda, idProduct=8179 kernel: usb 2-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 kernel: usb 2-1.3: Product: 802.11n NIC kernel: usb 2-1.3: Manufacturer: Realtek kernel: usb 2-1.3: SerialNumber: 00E04C0001 mtp-probe[19903]: checking bus 2, device 12: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3" mtp-probe[19903]: bus: 2, device: 12 was not an MTP device kernel: r8188eu: module is from the staging directory, the quality is unknown, you have been warned. kernel: Chip Version Info: CHIP_8188E_Normal_Chip_TSMC_D_CUT_1T1R_RomVer(0) kernel: usbcore: registered new interface driver r8188eu kernel: r8188eu 2-1.3:1.0 wlan10: renamed from wlan1 Widzimy zatem, że adapter TL-WN725N jest identyfikowany przez kernel linux'a jako idVendor=0bda oraz idProduct=8179 . Dalej mamy informację, że karta działa w oparciu o moduł r8188eu. Z tym, że w aktualnym kernelu (4.6), ten moduł pochodzi z tzw. staging directory, przez co mogą pojawić się problemy natury użytkowej. Jeśli byśmy z miejsca chcieli podłączyć się do sieci WiFi, to nie będziemy w stanie tego zrobić: kernel: r8188eu 2-1.3:1.0: firmware: failed to load rtlwifi/rtl8188eufw.bin (-2) kernel: r8188eu 2-1.3:1.0: Direct firmware load for rtlwifi/rtl8188eufw.bin failed with error -2 kernel: r8188eu 2-1.3:1.0: Firmware rtlwifi/rtl8188eufw.bin not available Mamy tutaj informację, że karta TL-WN725N wymaga do pracy firmware. W repozytorium Debiana figuruje pakiet firmware-realtek , w którym to znajduje się wymieniony wyżej plik powiązany z modułem r8188eu , tj. /lib/firmware/rtlwifi/rtl8188eufw.bin . Zatem bez instalacji tego pakietu się nie obejdzie. Sterowniki dla TL-WN725N oferowane przez TP-LINK Na płytce dołączonej do karty jest informacja, że na stronie TP-LINK znajdują się linux'owe sterowniki dla tego adaptera. Jest nawet instrukcja jak skompilować i zainstalować wymagany moduł, z tym, że dla kernela od wersji 2.6.18 do 3.19.3 , czyli nieco leciwego. Oczywiście moduł może działać i na późniejszych wersjach ale nikt nie gwarantuje, że da się ten moduł zbudować oraz, że będzie on działał stabilnie. Przy obecnej wersji kernela w gałęzi testowej pozostaje nam raczej korzystanie z modułu oferowanego przez sam kernel. Specyfikacja karty TL-WN725N Kawałek logu widoczny powyżej mówi nam tylko tyle, że karta TL-WN725N jest w stanie pracować pod linux'em. Jeśli chodzi zaś o bardziej szczegółowe informacje, to wiemy, że na pokładzie tego adaptera znajduje się chipset Realtek RTL8188EUS ale nasz sterownik cierpi na brak wsparcia dla interfejsu nl80211, przez co są drobne problemy z obsługą tego czipa w narzędziach iw , crda , hostapd oraz wpa_supplicant . Poniżej zaś jest zamieszczone wyjście polecenia lsusb : # lsusb -vvv -d 0bda:8179 Bus 002 Device 012: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x8179 RTL8188EUS 802.11n Wireless Network Adapter bcdDevice 0.00 iManufacturer 1 Realtek iProduct 2 802.11n NIC iSerial 3 00E04C0001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0002 (Bus Powered) Remote Wakeup Enabled Karta działa w standardzie N do 150 mbit/s. Niestety nie mogę załączyć również wyjścia polecenia iw list z przyczyn opisanych powyżej. Parametry modułu r8188eu Moduł r8188eu obsługujący adapter TL-WN725N ma sam w sobie dość sporo parametrów, które możemy dostosować. Poniżej znajduje się kompletna lista wraz z domyślnymi ustawieniami dla tej karty: # systool -v -m r8188eu ... Parameters: debug = "1" if2name = "wlan%d" ifname = "wlan%d" monitor_enable = "N" rtw_80211d = "0" rtw_ampdu_amsdu = "0" rtw_ampdu_enable = "1" rtw_antdiv_cfg = "2" rtw_antdiv_type = "0" rtw_busy_thresh = "40" rtw_cbw40_enable = "3" rtw_channel_plan = "66" rtw_channel = "1" rtw_chip_version = "0" rtw_enusbss = "0" rtw_fw_iol = "1" rtw_ht_enable = "1" rtw_hw_wps_pbc = "1" rtw_hwpdn_mode = "2" rtw_hwpwrp_detect = "0" rtw_initmac = "(null)" rtw_ips_mode = "1" rtw_lbkmode = "0" rtw_low_power = "0" rtw_lowrate_two_xmit= "1" rtw_max_roaming_times= "2" rtw_mc2u_disable = "0" rtw_network_mode = "0" rtw_notch_filter = "0" rtw_power_mgnt = "1" rtw_rf_config = "5" rtw_rfintfs = "2" rtw_rx_stbc = "1" rtw_smart_ps = "2" rtw_vcs_type = "1" rtw_vrtl_carrier_sense= "2" rtw_wifi_spec = "0" rtw_wmm_enable = "1" Tryb monitor Lista opcji zwróciła nam min. pozycję monitor_enable , która sugeruje, że adapter TL-WN725N może posiadać obsługę trybu monitor. Standardowo jest on wyłączony ale jeśli chcielibyśmy włączyć go, to trzeba załadować moduł z opcją monitor_enable=1 . A to z kolei można zrobić, np. za pomocą pliku /etc/modprobe.d/modules.conf przez dodanie w nim poniższej linijki: options r8188eu monitor_enable=1 Następnie trzeba przeładować moduł: # ifdown wlan10 # modprobe -r r8188eu # modprobe r8188eu # ifup wlan10 Można także załadować moduł bezpośrednio z linii poleceń: # modprobe -r r8188eu # modprobe r8188eu monitor_enable=1 W każdym z tych dwóch przypadków, w systemie powinniśmy zobaczyć nowy interfejs mon0 , który można wykorzystać choćby w wireshark czy airodump-ng . Tryb oszczędzania energii W opcjach modułu można także doszukać się parametru rtw_power_mgnt , który odpowiada za tryb oszczędzania energii w kartach i adapterach WiFi. To nic nowego ale na linux'ach ten tryb często sprawia problemy i zaleca się jego wyłączenie. Jeśli obserwujemy wysoki ping podczas spoczynku karty, czy też idzie wyraźnie odczuć opóźnienie związane z przeglądaniem stron www, to powinniśmy wyłączyć automatyczne zarządzanie energią. By to uczynić, w pliku /etc/modprobe.d/modules.conf dodajemy poniższy wpis: options r8188eu rtw_power_mgnt=0 Do końca nie wiem czy obsługa trybu oszczędnego jest zaimplementowana w tym module, czy też i nie jest. Karta zdaje się pracować poprawnie bez względu na stan opcji rtw_power_mgnt . Niemniej jednak, w iwconfig widnieje Power Management:off zarówno w przypadku ustawienia tej opcj na 0 jak i na 1. Programowy WPS Karta jest na tyle mała, że nie sposób na niej zamontować przycisku WPS. Niemożliwa zatem jest szybka i bezproblemowa konfiguracja połączenia WiFi za pomocą jednego wciśnięcia przycisku. Niemniej jednak, przyciski WPS pod linux'em są znane z tego, że nie działają. Zatem niewiele tracimy przez fakt braku przycisku WPS na obudowie adaptera. Ważniejszą rzeczą zaś jest programowy WPS, który działa bez problemu na linux'ach. Na liście opcji modułu mamy pozycję rtw_hw_wps_pbc implementującą obsługę wirtualnego przycisku, który "można wcisnąć" programowo z poziomu systemu operacyjnego. Opcja jest domyślnie włączona zatem powinniśmy być w stanie bez problemu wynegocjować parametry połączenia. Tryb AP Istnieje także możliwość przełączenia tej karty w tryb AP, z tym, że standardowo w linux'ie się tego nie da zrobić -- brak wsparcia dla sterownika nl80211 w hostapd . Z tej sytuacji można wybrnąć przez wgranie łaty na hostapd implementującą sterownik rtl871xdrv. Niemniej jednak dokładny opis jak uruchomić tryb AP na karcie TL-WN725N jest poza zakresem tego artykułu. Na pewno taki opis pojawi się w przyszłości i zostanie tutaj podlinkowany (FIXME). Test karty TL-WN725N Karta została poprawnie rozpoznana przez system linux i działa. Połączenie z siecią WiFi można nawiązać bez większego problemu i nie widać zbytnio błędów. Karta zachowuje się w miarę stabilnie i nie zrywa połączenia. Przydałoby się zatem sprawdzić jeszcze jaki transfer jesteśmy w stanie uzyskać za pomocą karty TL-WN725N. Poniższa fotka odnosi się do sytuacji, w której laptop znajduje się w tym samym pomieszczeniu co router WiFi TP-LINK Archer C7 v2 (wewnętrzne anteny 2.4 GHz). Odległość nie przekracza 2 metrów: Zatem mamy około 80 mbit/s. Całkiem przyzwoity wynik jak na tak bardzo mały adapter, choć na opakowaniu widnieje 150 mbit/s. Sprawdźmy jak będzie wyglądał transfer po zmianie położenia laptopa i dołożeniu przeszkody w postaci niezbyt grubej ściany. Odległość około 3-4 metry: Transfer lekko się obniżył, choć nadal pozostaje powyżej 50 mbit/s. Dorzućmy jeszcze jedną ścianę i zobaczmy jak adapter TL-WN725N poradzi sobie w takiej sytuacji. Odległość 5-6 metrów: Tutaj już balansujemy na granicy 50 mbit/s. Choć i tak jestem pod wrażeniem, że taki transfer się utrzymuje. Problemy z TL-WN725N pod linux'em Dostępny w kernelu linux'a moduł może i zapewnia w miarę normalne użytkowanie adaptera WiFi TL-WN725N ale jeszcze trzeba nad nim trochę popracować. Problemy są widoczne, np. w wavemon , gdzie nie można ustalić siły i jakości sygnału. W przypadku iw i rfkill w ogóle nie zostają zwrócone żadne informacje. Ta sytuacja nie wpływa jednak w widoczny sposób na działanie samego adaptera. W przypadku obsługi sieci WiFi na linux'ie realizowanej za sprawą narzędzia wpa_supplicant trzeba wziąć poprawkę w stosunku do wykorzystywanego sterownika. Standardowo w pliku /etc/network/interfaces określilibyśmy coś na wzór wpa-driver nl80211 . Niemniej jednak, w przypadku TL-WN725N, ten sterownik nie zadziała i przy próbie podłączenia zostanie zwrócony poniższy komunikat: # ifup wlan10 wpa_supplicant: /sbin/wpa_supplicant daemon failed to start run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1 Failed to bring up wlan10. Musimy zatem korzystać z wpa-driver wext lub też w ogóle nie precyzować tej opcji w konfiguracji (na jedno wyjdzie). Reasumując, zwrotka konfigurująca interfejs sieciowy w pliku /etc/network/interfaces powinna wyglądać mniej więcej tak: iface wlan10 inet dhcp wpa-driver wext wpa-debug-level -1 wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf Oczywiście parametry specyficzne dla samej sieci WiFi podajemy już w konfiguracji narzędzia wpa_supplicant . Poniżej znajduje się log z podłączania do sieci bezprzewodowej: Także trochę błędów jest ale na szczęście nic poważnego.
  15. Karty WiFi implementowane w różnego rodzaju laptopach zwykle są dość przyzwoite. Przynajmniej do czasu aż użytkownik zapragnie korzystać z alternatywnego systemu operacyjnego z rodziny linux. W takim przypadku często okazuje się, że większość kart bezprzewodowych pracuje na układach, których sterowniki nie są wolne i nie ma ich dostępnych w linux'owym kernelu. Czasem takie karty można zmusić do pracy ale uzyskana w ten sposób prędkość transferu zbytnio nie zachwyca. Jedynym przyzwoitym rozwiązaniem jest zakup zewnętrznego adaptera WiFi, który pracuje na czipie wspieranym przez kernel. Zwykle są to karty na układach od firmy QUALCOMM ATHEROS. W tym artykule weźmiemy sobie pod lupę adapter TL-WN722N od firmy TP-LINK, który działa w standardzie N (pasmo 2,4 GHz, transfer do 150 mbit/s). Wygląd adaptera TP-LINK TL-WN722N Adapter TL-WN722N jest wyposażony w port USB 2.0 i posiada również przycisk WPS do uzyskiwania automatycznej konfiguracji połączenia bezprzewodowego. Pod linux'em jednak, z jakichś nieznanych mi powodów, ten przycisk WPS nie chce zbytnio działać. Karta ma doczepianą antenkę 4 dBi. W zestawie jest także dołączony kabelek USB. Teoretycznie ta karta jest w stanie nadawać z prędkością 150 mbit/s. Poniżej jest fotka prezentująca jej wygląd zewnętrzny: Zobaczmy co ten adapter skrywa w sobie: Niżej jest wyciągnięty cały układ z obudowy: Jeszcze jego spód: Z jednej ze stron układu jest wyprowadzone gniazdo antenowe: Z drugiej zaś przycisk WPS: Karta TL-WN722N posiada także zieloną diodę, sygnalizującą stan pracy urządzenia (włączony, transfer danych): Poniżej zaś jest fotka anteny dołączanej do zestawu (ta mniejsza). Ta większa zaś pochodzi od routera TP-LINK TL-WR1043ND v2. Porównane są one jedynie w celach orientacyjnych. Mimo znacznej różnicy w rozmiarze, gniazda anten są takie same i nic nie stoi na przeszkodzie, by korzystać z tej większej anteny, oczywiście jeśli posiadamy takową na zbyciu. Instalacja adaptera TL-WN722N w systemie linux (debian) Zgodnie z informacją dostępną tutaj, adapter TL-WN722N ma czip Atheros AR9271, który jest obsługiwany przez moduł ath9k_htc . Ten moduł jest dostępny w kernelu ale, by ta karta nam działała pod linux'em musimy zainstalować jeszcze firmware. Ten z kolei dostępny jest w debianie w pakiecie firmware-atheros . Jeśli nie doinstalowalibyśmy tego firmware i próbowali odpalić ten adapter, w logu zobaczymy poniższy komunikat: kernel: [18738.288728] usb 2-1.1: new high-speed USB device number 13 using ehci-pci kernel: [18738.397468] usb 2-1.1: New USB device found, idVendor=0cf3, idProduct=9271 kernel: [18738.397479] usb 2-1.1: New USB device strings: Mfr=16, Product=32, SerialNumber=48 kernel: [18738.397485] usb 2-1.1: Product: USB2.0 WLAN kernel: [18738.397489] usb 2-1.1: Manufacturer: ATHEROS kernel: [18738.397493] usb 2-1.1: SerialNumber: 12345 kernel: [18738.398035] usb 2-1.1: ath9k_htc: Firmware htc_9271.fw requested kernel: [18738.398319] usb 2-1.1: firmware: failed to load htc_9271.fw (-2) kernel: [18738.398324] usb 2-1.1: Direct firmware load failed with error -2 kernel: [18738.398328] usb 2-1.1: Falling back to user helper kernel: [18738.428503] usb 2-1.1: ath9k_htc: USB layer deinitialized Po instalacji firmware, karta powinna zostać wykryta przez system bez większego problemu po ponownym podłączeniu do portu USB: kernel: usb 2-1.3: new high-speed USB device number 7 using ehci-pci kernel: usb 2-1.3: New USB device found, idVendor=0cf3, idProduct=9271 kernel: usb 2-1.3: New USB device strings: Mfr=16, Product=32, SerialNumber=48 kernel: usb 2-1.3: Product: USB2.0 WLAN kernel: usb 2-1.3: Manufacturer: ATHEROS kernel: usb 2-1.3: SerialNumber: 12345 kernel: usb 2-1.3: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested kernel: usbcore: registered new interface driver ath9k_htc kernel: usb 2-1.3: firmware: direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw kernel: usb 2-1.3: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008 kernel: ath9k_htc 2-1.3:1.0: ath9k_htc: HTC initialized with 33 credits kernel: ath9k_htc 2-1.3:1.0: ath9k_htc: FW Version: 1.4 kernel: ath9k_htc 2-1.3:1.0: FW RMW support: On kernel: ath: EEPROM regdomain: 0x809c kernel: ath: EEPROM indicates we should expect a country code kernel: ath: doing EEPROM country->regdmn map search kernel: ath: country maps to regdmn code: 0x52 kernel: ath: Country alpha2 being used: CN kernel: ath: Regpair used: 0x52 kernel: ieee80211 phy1: Atheros AR9271 Rev:1 systemd[1]: Starting Load/Save RF Kill Switch Status... systemd[1]: Started Load/Save RF Kill Switch Status. Ten adapter jest wykrywany jako idVendor=0cf3 oraz idProduct=9271 . Poniżej znajduje się wyjście kilku poleceń, które pokażą charakterystykę karty TL-WN722N: # lsusb -v -d 0cf3:9271 Bus 002 Device 008: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 idVendor 0x0cf3 Atheros Communications, Inc. idProduct 0x9271 AR9271 802.11n bcdDevice 1.08 iManufacturer 16 ATHEROS iProduct 32 USB2.0 WLAN iSerial 48 12345 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 60 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 6 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) # iw list Wiphy phy2 max # scan SSIDs: 4 max scan IEs length: 2257 bytes Retry short limit: 7 Retry long limit: 4 Coverage class: 0 (up to 0m) Device supports RSN-IBSS. Device supports T-DLS. Supported Ciphers: * WEP40 (00-0f-ac:1) * WEP104 (00-0f-ac:5) * TKIP (00-0f-ac:2) * CCMP (00-0f-ac:4) * 00-0f-ac:10 * GCMP (00-0f-ac:8) * 00-0f-ac:9 * CMAC (00-0f-ac:6) * 00-0f-ac:13 * 00-0f-ac:11 * 00-0f-ac:12 Available Antennas: TX 0x1 RX 0x1 Configured Antennas: TX 0x1 RX 0x1 Supported interface modes: * IBSS * managed * AP * AP/VLAN * monitor * mesh point * P2P-client * P2P-GO * Unknown mode (11) Band 1: Capabilities: 0x116e HT20/HT40 SM Power Save disabled RX HT20 SGI RX HT40 SGI RX STBC 1-stream Max AMSDU length: 3839 bytes DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 8 usec (0x06) HT TX/RX MCS rate indexes supported: 0-7 Bitrates (non-HT): * 1.0 Mbps * 2.0 Mbps (short preamble supported) * 5.5 Mbps (short preamble supported) * 11.0 Mbps (short preamble supported) * 6.0 Mbps * 9.0 Mbps * 12.0 Mbps * 18.0 Mbps * 24.0 Mbps * 36.0 Mbps * 48.0 Mbps * 54.0 Mbps Frequencies: * 2412 MHz [1] (20.0 dBm) * 2417 MHz [2] (20.0 dBm) * 2422 MHz [3] (20.0 dBm) * 2427 MHz [4] (20.0 dBm) * 2432 MHz [5] (20.0 dBm) * 2437 MHz [6] (20.0 dBm) * 2442 MHz [7] (20.0 dBm) * 2447 MHz [8] (20.0 dBm) * 2452 MHz [9] (20.0 dBm) * 2457 MHz [10] (20.0 dBm) * 2462 MHz [11] (20.0 dBm) * 2467 MHz [12] (20.0 dBm) * 2472 MHz [13] (20.0 dBm) * 2484 MHz [14] (disabled) Supported commands: * new_interface * set_interface * new_key * start_ap * new_station * new_mpath * set_mesh_config * set_bss * authenticate * associate * deauthenticate * disassociate * join_ibss * join_mesh * remain_on_channel * set_tx_bitrate_mask * frame * frame_wait_cancel * set_wiphy_netns * set_channel * set_wds_peer * tdls_mgmt * tdls_oper * probe_client * set_noack_map * register_beacons * start_p2p_device * set_mcast_rate * channel_switch * Unknown command (104) * connect * disconnect Supported TX frame types: * IBSS: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * AP/VLAN: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * mesh point: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0 Supported RX frame types: * IBSS: 0x40 0xb0 0xc0 0xd0 * managed: 0x40 0xd0 * AP: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * AP/VLAN: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * mesh point: 0xb0 0xc0 0xd0 * P2P-client: 0x40 0xd0 * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0 * P2P-device: 0x40 0xd0 software interface modes (can always be added): * AP/VLAN * monitor valid interface combinations: * #{ managed, P2P-client } <= 2, #{ AP, mesh point, P2P-GO } <= 2, total <= 2, #channels <= 1 HT Capability overrides: * MCS: ff ff ff ff ff ff ff ff ff ff * maximum A-MSDU length * supported channel width * short GI for 40 MHz * max A-MPDU length exponent * min MPDU start spacing Device supports TX status socket option. Device supports HT-IBSS. Device supports SAE with AUTHENTICATE command Device supports low priority scan. Device supports scan flush. Device supports AP scan. Device supports per-vif TX power setting Driver supports full state transitions for AP/GO clients Driver supports a userspace MPM Warto odnotować, że karta posiada obsługę trybu AP. Niemniej jednak, zdolności tego punktu dostępowego są dość ograniczone. Maksymalna ilość sieci jakie możemy stworzyć to 2. Natomiast ilość klientów, które mogłyby się z tą kartą podłączyć to 7. Jeśli jednak chcielibyśmy się pokusić o stworzenie takiego Access Point'a, to zachęcam do zaznajomienia się z artykułem dotyczącym instalacji i konfiguracji adaptera TL-WN722N w trybie AP na linux'ie (dystrybucja debian). Jeśli zaś chodzi o konfigurację tej karty w trybie klienta (STA), to z kolei odsyłam do artykułu opisującego konfigurację połączenia WiFi pod debianem. Podsumowanie Może i na tym adapterze TL-WN722N od TP-LINK'a jest napisane 150 mbit/s ale w mojej okolicy (centrum miasta) nie udało się osiągnąć więcej niż 80 mbit/s. Poniżej jest test przeprowadzony za pomocą narzędzia iperf . Test dla szerokości kanałów 20 MHz: # iperf -i 10 -t 100 -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.160 port 52887 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 53.5 MBytes 44.9 Mbits/sec [ 3] 10.0-20.0 sec 53.5 MBytes 44.9 Mbits/sec [ 3] 20.0-30.0 sec 55.0 MBytes 46.1 Mbits/sec [ 3] 30.0-40.0 sec 55.5 MBytes 46.6 Mbits/sec [ 3] 40.0-50.0 sec 55.6 MBytes 46.7 Mbits/sec [ 3] 50.0-60.0 sec 55.9 MBytes 46.9 Mbits/sec [ 3] 60.0-70.0 sec 54.9 MBytes 46.0 Mbits/sec Test dla szerokości kanałów 40 MHz: # iperf -i 10 -t 100 -c 192.168.1.1 ------------------------------------------------------------ Client connecting to 192.168.1.1, TCP port 5001 TCP window size: 85.0 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.1.160 port 52944 connected with 192.168.1.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 90.1 MBytes 75.6 Mbits/sec [ 3] 10.0-20.0 sec 93.1 MBytes 78.1 Mbits/sec [ 3] 20.0-30.0 sec 93.6 MBytes 78.5 Mbits/sec [ 3] 30.0-40.0 sec 93.6 MBytes 78.5 Mbits/sec [ 3] 40.0-50.0 sec 93.0 MBytes 78.0 Mbits/sec [ 3] 50.0-60.0 sec 94.8 MBytes 79.5 Mbits/sec [ 3] 60.0-70.0 sec 93.8 MBytes 78.6 Mbits/sec Większej prędkości w moich warunkach nie da się raczej osiągnąć. Przy czym należy powiedzieć, że nie jest znowu aż tak źle. Na tej karcie WiFi, która jest dołączana w standardzie do mojego laptopa (jakiś Broadcom), wynik jest ponad trzykrotnie gorszy.