Linux, Cinnamon i problem z hotspotami chronionymi hasłem
Ostatnio korzystałem sobie z systemu PorteuX w wariancie Cinnamon.
Cinnamon odnosi się tu do środowiska graficznego, czyli ogólnego wyglądu i zachowania systemu. Jest znany choćby z popularnego, polecanego dla świeżaków systemu Linux Mint.
PorteuX dodawał od siebie lekkość. Korzystając z Minta Cinnamona na tym samym laptopie, miałem lekkie, ale irytujące opóźnienie przy otwieraniu okien. Na Porteuksie było nieodczuwalne.
I wszystko byłoby pięknie, gdyby nie jeden zgrzyt – nie mogłem połączyć się z hotspotem chronionym hasłem.
I nie ma znaczenia, że je znałem. Nawet nie mogłem go wpisać, bo problem pojawiał się na etapie kliknięcia nazwy hotspota.
Zamiast okna pytającego o hasło, w górnym rogu od razu wyskakiwał komunikat o błędzie:
A że internet to obecnie podstawa, taki problem był dokuczliwy. Poczytałem trochę, poklikałem i go rozwiązałem. A wiedzą, w sposób najprzystępniejszy jak umiem, podzielę się w tym miniwpisie.
Spis treści
Śledztwo
Komunikat pokazałem wyżej. Kompletnie nic mi nie mówił, nie było się czego złapać. Zwłaszcza że nie za bardzo wiedziałem, jak podpiąć strace’a (popularny program monitorujący) pod klikanie nazwy z paska.
Dlatego trochę pogrzebałem, klikając na różne sposoby ikonę internetu z paska systemowego. Szukałem możliwości otwarcia listy hotspotów wewnątrz osobnego okna, a nie ulotnego menu.
Odkryłem, że taką możliwość daje kliknięcie lewym przyciskiem myszy i wybranie opcji Network Settings.
Otwarło się wtedy nowe okno. Po lewej stronie miałem domyślnie zaznaczoną zakładkę Wi-Fi. Zaś w większym polu po prawej była lista hotspotów wokół mnie.
Kiedy kliknąłem nazwę hotspota wewnątrz tego okna, to również pokazało komunikat o błędzie w górnym rogu.
Ale poza tym – przez ułamek sekundy – mignął też inny tekst, tuż nad listą. Poklikałem więcej razy, żeby wyłapać jego treść. A mówiła ona:
Podobny błąd pokazałby się również przy próbie połączenia przez konsolę, tylko że tam miałbym jasną podpowiedź.
Wpisałem treść komunikatu w wyszukiwarkę (na innym Linuksie, bo na tym – przypomnę – nie miałem jak się zalogować). W ten sposób odkryłem parę potencjalnych rozwiązań.
Rozwiązanie doraźne
Opisany problem występuje na szczęście tylko na poziomie interfejsu graficznego. Nadal można się połączyć przez konsolę.
W tym celu można użyć w niej polecenia:
nmcli device wifi connect "NAZWA_HOTSPOTA" password "HASŁO"
Przypomnę: „użycie polecenia” polega na uruchomieniu konsoli/terminala (często ikoną z paska), wpisaniu podanych słów i wciśnięciu klawisza Enter. Aby wkleić tam tekst, należy użyć kombinacji Ctrl+Shift+V.
Za NAZWA_HOTSPOTA należy podstawić czytelną nazwę widoczną na liście, jak na przykład Kawiarnia Open. Nazwa ta, zwłaszcza jeśli zawiera spację, powinna być otoczona cudzysłowami (w innym wypadku wystąpi błąd).
Należy też podać HASŁO do tego hotspota. Zasada z cudzysłowami jak wyżej.
Po użyciu polecenia bezproblemowo połączyło mnie z siecią.
Alternatywa - interaktywne podanie hasła
Zamiast podawać hasło wewnątrz komendy, można zażądać od systemu pola na jego samodzielne wpisanie:
nmcli device wifi connect NAZWA_HOTSPOTA --ask
Ta forma może przydać się zwłaszcza wtedy, gdy jednocześnie:
- wielokrotnie uruchamiamy system od zera (norma choćby w przypadku Porteuksa),
- po każdym uruchomieniu chcemy łączyć się z konkretną siecią (np. z domowym hotspotem),
- nie chcemy trzymać hasła na widoku, wewnątrz skryptu.
W takim przypadku wystarczy mieć hasło w głowie, a wspomniane polecenie konsolowe – w skrypcie uruchamianym po starcie systemu.
Rozwiązanie trwalsze
A co, jeśli kogoś razi konsola albo woli mieć działający system, ze współgrającymi okienkami i bez komunikatów o błędach?
Rozwiązaniem w moim przypadku była instalacja programu gnome-keyring i uruchomienie go w tle.
To program od przechowywania haseł, takich jak to do Wi-Fi. Nazwa oznacza dosłownie „breloczek na klucze”, więc pozwolę sobie dla urozmaicenia nazywać ten program Brelokiem.
Sposób instalowania Breloka różni się między systemami. Tutaj przytoczę sposób dla Porteuksa, którego fundamentem jest Slackware. Programem od instalowania domyślnych modułów jest tam getpkg.
Żeby pobrać Breloka, musiałem użyć takiego polecenia:
getpkg -m gnome-keyring
W ten sposób pobrało mi moduł i zapisało go jako plik XZM. Wystarczyło go dwukrotnie kliknąć, żeby został zainstalowany. I, co lepsze, od razu zaczął śmigać w tle.
Po zainstalowaniu Breloka mogłem zobaczyć, czy działa. W tym celu wpisałem polecenie znajdujące go wśród aktywnych procesów:
Gdyby ktoś szczerze nienawidził konsoli, to można podejrzeć procesy również przez program System Monitor, zainstalowany na wielu Linuksach.
Powinno mi pokazać na liście taki proces:
Kiedy teraz kliknąłem ikonkę Wi-Fi, to wyświetliło mi się oczekiwane okno pytające o hasło:
A po jego wpisaniu połączyło mnie z siecią i wszystko śmigało jak powinno. Sukces!
Rozwiązywanie problemów
Część główna zakończona. Oba opisane sposoby, graficzny i konsolowy, powinny w większości przypadku pozwolić na łączenie się z zabezpieczonymi hotspotami.
Gdyby jednak coś było nie tak, to służę opisami paru problemów, z którymi osobiście się zetknąłem.
Brak procesu gnome-keyring-daemon na liście aktywnych
Możliwe, że z tego czy innego powodu instalacja pakietu gnome-keyring nie aktywuje od razu procesu Breloczka i nie pojawi się on na liście procesów.
W takim wypadku można spróbować aktywować go ręcznie:
gnome-keyring-daemon --start
Gdyby po tym poleceniu wyświetliło informację o nieznanym programie – to znaczy, że coś poszło nie tak podczas instalacji. Powinna była bowiem przenieść ten program do folderu systemowego, czyniąc go publicznie dostępnym.
Można spróbować w takiej sytuacji zainstalować gnome-keyring od nowa, ewnetualnie pozyskując pakiet z innego źródła.
Możliwy komunikat o braku pliku
Gdybym zakończył ręcznie cały proces i aktywował go ponownie, poleceniem takim jak wyżej, to wyświetliłoby mi taki komunikat:
Nie miał on jednak wpływu na dalsze działanie programu, dlatego przytaczam go jedynie jako ciekawostkę.
System zaczął wolno reagować na kombinacje klawiszy
Po instalacji Breloka warto na próbę zrobić zrzut ekranu klawiszem PrintScreen i ocenić, czy został wykonany z taką samą szybkością jak zwykle.
Taki problem mnie dotknął, kiedy użyłem modułu pobranego z innego źródła niż getpkg. Dokładniej: na stronce pkgs.org znalazłem link do pliku (gnome-keyring-50.0-x86_64-1.txz). Pobrałem go, skonwertowałem ręcznie i aktywowałem dwukrotnym kliknięciem.
Niestety w tym przypadku Brelok popsuł mi działanie systemowych skrótów klawiszowych. Zaczęło występować znaczne, wielosekundowe opóźnienie między wciśnięciem klawiszy a spodziewaną reakcją. Dotyczyło między innymi:
- kombinacji otwierającej okno Terminala,
- kombinacji robiącej zrzut (screenshota) całego ekranu.
Problem udało mi się naprawić przez metodę uniwersalną typu „wyłącz i włącz ponownie”.
Naprawienie problemu przez restart procesu
Czy błąd czymś się wyróżniał na poziomie systemu? Tak. Zauważyłem, że gdybym wyświetlił listę procesów taką komendą:
ps -ax | grep keyring
…to pokazałoby takie coś:
To inne parametry programu niż przy poprawnej instalacji, którą opisałem wcześniej. Z jakiegoś powodu chyba nie lubiły się z systemem.
Skoro z procesem było coś nie tak, to postanowiłem go ubić:
kill NR_PROCESU
Następnie aktywowałem proces od zera:
gnome-keyring-daemon --start
To naprawiło problem. Miałem teraz działające okno z pytaniem o hasło, a jednocześnie brak opóźnienia przy podstawowywych skrótach klawiszowych.
Gdybym teraz jeszcze raz sprawdził listę aktywnych procesów, to zobaczyłbym przy Breloku to samo, co przy aktywacji przez „dobry” moduł. Ten właściwy zestaw parametrów:
Gdybym jednak mógł coś doradzić, to proponuję w przypadku dziwnego pakietu, niedziałającego po pierwszej instalacji, spróbować sięgnąć po inny.
W końcu jeśli pojawiła się jedna oczywista niekompatybilność, to nie można wykluczyć, że idą za nią inne, głębiej ukryte w programie.
I na tym kończę ten wpis – z lekkim systemem, Cinnamonem pełnym bajerów i do tego działającym internetem. Tak trzeba żyć 