Tag: arm

Opublikowane w

Monitoring Tora w konsoli – howto.

Jak wiadomo m.in. z poprzedniego wpisu, prowadzę węzeł Tora. Bez połączeń wychodzących, czyli robię tylko za żuczka dokładającego jeden hop w ścieżce w celu zwiększenia anonimowości korzystających z tego programu. Od pewnego czasu miałem wrażenie, że jedyne, co robi mój Tor, to zajmuje pamięć (ponad 30% na biednym Dockstarze). Nie robiłem żadnych dokładnych statystyk, po prostu obserwowałem ilość ruchu na interfejsach, ale wyglądało, że jest mniej, niż kiedyś.

Postanowiłem sprawdzić, co się dzieje w rzeczywistości. Już kiedyś widziałem, że jest projekt arm czyli anonymizing relay monitor, ale wtedy nie było pakietów w Debianie, więc nie instalowałem, a pozwala on na znacznie więcej, niż tylko obejrzenie ilości ruchu, więc postanowiłem zainstalować arm.

W tej chwili paczka tor-arm jest dostępna w Debianie unstable (na stable instaluje się czysto), więc doinstalowałem ją (wajig install tor-arm). Samo uruchomienie (wpisanie arm) nic nie dało (używa domyślnej konfiguracji), więc po pierwsze, skopiowałem domyślną konfigurację (położenie w Debianie nieco inne niż podawane w manualu):

zcat /usr/share/doc/tor-arm/armrc.sample.gz > .arm/armrc

Nadal nic. Kolejna sprawa, to uruchomienie portu do kontroli w samym Torze, czyli dodanie w configu opcji:

ControlPort 9051

Po ponownym uruchomieniu arm jak najbardziej się połączył, ale ostrzega, że port do kontroli jest otwarty. Co prawda maszynka jest firewallowana, ale wypadałoby dodać hasło do zarządzania. Nie jest to trywialne i znalezienie zajęło mi dłuższą chwilę (chociaż jest w dokumentacji), więc opiszę. Najpierw generujemy hash hasła:

tor --hash-password jakieshaslo 

Otrzymujemy coś w stylu ciągu

16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

Następnie w konfiguracji Tora dodajemy linię

HashedControlPassword 16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

i restartujemy Tora (/etc/init.d/tor restart). Na koniec edytujemy ~.arm/armrc i uzupełniamy linię z startup.controlPassword, by miała postać:

startup.controlPassword jakieshaslo

Po zmianach okazało się, że miałem nosa i faktycznie niewiele się dzieje. Nawet bardzo niewiele. Praktycznie nic. Ponieważ kiedyś ruchu było więcej, postanowiłem sprawdzić, czy winnym nie jest ustawienie węzła jako bridge node. Bingo! Po zmianie od razu jest więcej ruchu. Zatem w chwili obecnej mój konfig Tora wygląda następująco:

ControlPort 9051
RelayBandwidthRate 20 KBytes
RelayBandwidthBurst 30 KBytes
ExitPolicy reject *:* # no exits allowed
ORPort 443
HashedControlPassword 16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

UPDATE: Przy okazji wygląda, że wyłączając tryb bridge node upiekłem dwie pieczenie na jednym ogniu. Po 16 godzinach zużycie pamięci RAM przez Tor wynosi ledwie 9%, zamiast wspomnianych 30%. Czyżby jakiś bug związany z trybem bridge? W każdym razie średni ruch upload i download teraz to po 50 Kbps, zużycie pamięci, które mnie trochę bolało mniejsze. Jednym słowem: lubię to! 😉

Opublikowane w

Seagate Dockstar jako router.

Jakiś czas temu było o HP T5520 jako routerze, który działał i byłem z niego zadowolony, ale trzeba poznawać nowe rzeczy (w tym przypadku: sprzęt na ARM). Poza tym, z T5520 można zrobić nieco więcej, niż tylko router (ma wyjście audio, w połączeniu z MPD będzie pewnie robił za odtwarzacz radiowy, shell i NAS w innej lokalizacji). Jasne, mogłem dołożyć do Dockstara kartę dźwiękową na USB, ale ciekawiło mnie też, czy modem USB (Sagem F@st 800) zadziała na ARM.

Wybór padł na Seagate Dockstar, bo był to tani sprzęt (wówczas ~100 zł, obecnie dwa razy drożej), o niezłych parametrach (128 MB RAM, procesor 1,2 GHz). Jako alternatywa dla T5520 w tym zastosowaniu – teoretycznie idealny. I – z racji architektury ARM – znacznie bardziej energooszczędny (maksymalnie poniżej 10W poboru prądu). Last but not least – Dockstar obsługuje niemodyfikowanego Debiana.

Od zakupu do uruchomienia minęło sporo czasu. O ile instalacja Debiana była bezproblemowa, o tyle działało to nieco losowo, więc dwa podejścia spędziłem na ustalaniu, co się sypie, że czasem wstaje z Debianem, a czasem z oryginalnym systemem. W końcu doszedłem, że winny był pendrive. Faktycznie, po wymianie na inny zaczęło działać stabilnie i można było się zająć przeniesieniem konfiguracji.

Przeniesienie było proste, podłączenie modemu i… zonk. Okazało się, że debianowe kernele nie są równe, konkretnie brakowało modułu br2684. Niby żaden problem przekompilować kernel, ale jeśli mam to robić na niedużym pendrive zamiast dysku, albo crosskompilując, to tak różowo nie jest. Ostatecznie zgłosiłem błąd dotyczący braku br2684, który szybko został poprawiony.

Niestety, poprawka wyszła dla kernela w wersji 3.0 z experimental. Jakoś nie ciągnęło mnie do wrzucania na produkcyjną (choć prywatną) maszynkę takiego wynalazku, tym bardziej, że nie sam kernel trzeba wymienić. A cokolwiek innego wiązało się z kompilacją… No dobrze, niech będzie. Skoro już kompilować, to jednak 2.6 ze Squeeze. I natywnie, na Dockstarze (jakoś się na tym pendrive zmieściło po rozpakowaniu).

Pobrane źródła, pobrane i nałożone patche, korekta pliku konfiguracyjnego, make-kpkg… I zonk z kryptycznym komunikatem (niestety nie zanotowałem). Okazuje się, że make-kpkg nie potrafi sam wykryć architektury, na której jest uruchamiany. Po podaniu –arch armel (dzięki przewodnikowi po crosskompilacji dla Dockstara) poszło dalej, choć niewiele. Tym razem winne lzma i cannot allocate memory (OSLT; mimo sporego swapa – IIRC 160 MB) i tyle. A przecież nie tak dawno kompilowałem kernele na maszynach z 64 MB RAM…

Na szczęście ww. przewodnik po crosskompilacji ładnie opisuje jak stworzyć środowisko i krok po kroku wyjaśnia, jak zrobić kernel. Stwierdziłem, że skoro akcja pewnie będzie się powtarzać, to warto mieć coś szybszego do kompilacji… Opis jest bdb, używanie środowiska do crosskompilacji proste. Wystarczyło poczekać parę h (tak, kernel debianowy to krowa z masą zbędnych opcji, ale stawiałem na kompatybilność i nie chciałem się bawić…) i kernel gotowy.

Kolejna ARMowa ciekawostka to instalacja. Zwykłe dpkg -i nie wystarcza. Jak widać w przewodniku po crosskompilacji kernela, trzeba jeszcze odczynić ręczną magię z uImage i uInitrd. Z pozytywów: wstało od kopa. Jest moduł, ale… nadal nie działa. Tym razem po podłączeniu modemu masa wpisów w stylu:

ATM dev 0: usbatm_submit_urb: urb 0xc6c50b40 submission failed (-28)!

Oczywiście modem się nie łączy… Googlanie po całości wpisu nie dało efektów, ale ostatecznie, szukając po fragmentach, trafiłem na ten błąd dla OpenWRT, który sugeruje wymuszenie bulk mode. Niby wolniejsze przy większych prędkościach, ale dla łącza 1 Mbps nie stanowi. Zresztą, innych pomysłów brak, zatem:

echo "options ueagle-atm altsetting=0,0,0,0" > /etc/modprobe.d/eagle-usb.conf

W końcu działa. Nawet się połączył. Małe dopieszczenie konfigów i w końcu maszynka przeniesiona. Generalnie z odkrytych wad Dockstara: nie ma RTC, więc po restarcie startuje bez aktualnej daty i godziny. Oczywiście instalacja ntp załatwia problem po nawiązaniu łączności z Internetem, ale przy ppp chwilę to trwa i przez tę chwilę wpisy w logach będą ze złą datą.

Inna uwaga odnośnie Debiana i ARM: nie jest to tak dopracowane jak architektury i386 i amd64. Generalnie działa, ale zamiast po prostu działa, trzeba bawić się w podawanie opcji (make-kpkg) lub nawet robienie części rzeczy ręcznie (initrd).

Parę przydatnych/użytych linków, niekoniecznie występujących w treści:

Wiki Debian on Dockstar

Zgłoszenie błędu z modemem USB dla OpenWRT

Komunikaty błędu na Dockstarze dotyczące Sagem F@st 800

Opis przygotowania środowiska do crosskompilacji i zrobienia nowszego kernela dla Dockstara

Póki co, trwa niezbyt obiecująco wyglądające (wygląda, że raz się wywalił z powodu loadu…) wygrzewanie sprzętu.

UPDATE: Jednak działa stabilnie od blisko dwóch tygodni. Prawdopodobna przyczyna ww. wywałki – błędy filesystemu (pewnie z czasu instalacji, kiedy nie był read only jeszcze). Po fsck, naprawieniu błędów i reboocie bez problemu.

UPDATE2: W jednym z kolejnych wpisów opisuję jak zrobić na Linuksie router Wi-Fi. Po dołożeniu karty Wi-Fi na USB Dockstar się nada.

Opublikowane w

UnARMed.

Na procesorach ARM powstaje sporo sprzętu. Teoretycznie świetnego, bo i niski pobór mocy, i spore możliwości, i niewielka cena.

Przykłady sprzętu opartego o ARM:

  • Toshiba AC100 – smartbook od Toshiby oparty na chipsecie Nvidii Tegra2. Dwurdzeniowy procesor taktowany 1GHz, 512 MB RAM. 8-10h na baterii, możliwość odtwarzania filmów full HD (1080p). Ekran 10,1″. Do tego dysk SSD. Cena? W zależności od wariantu już od 800 zł (polski sklep internetowy).
  • Trim-Slice – Ten sam procesor i chipset, pobór prądu 2-6W wg producenta. 1GB RAM, gigabitowa karta sieciowa. Wersja bez SSD – 199 USD. Oczywiście też umie full HD, więc aż się prosi o dołożenie dysku i przerobienie na domowe media center (plus ew. router, NAS, a dla geeków serwer WWW i shell), albo nawet i desktop.
  • Seagate Freeagent Dockstar – opiszę, bo i mój pierwszy kontakt z ARM, i stosunkowo ciekawy. Tania (pierwotnie ~25 euro; potem podrożały, ale wydaje mi się, że w Polsce nadal do kupienia w okolicach ~45 euro) zabawka pierwotnie mająca służyć za NAS z serwerem WWW. Gigabitowa karta sieciowa, procesor 1GHz, 128 MB RAM. Na oko świetny zamiennik dla HP T5520, służącego mi za router, ale domowy serwerek WWW, shell czy – po dołożeniu karty dźwiękowej USB – player muzyki itp. też spokojnie można uruchomić. Minimalnie lepsze parametry, aktualnie podobna cena, mniejszy pobór prądu. Jak w końcu uruchomię, to dam znać jak się spisuje. Nietypowy także dlatego, że na Dockstar działa niemodyfikowany Debian.

Wady:

  • Niewygórowane parametry – nie ma co ukrywać, 512 MB czy nawet 1GB RAM to obecnie trochę mało, zwłaszcza, jeśli mówimy o desktopie (patrz poprzedni wpis o małej ilości RAM na desktopie). Procesor też nadmiarem mocy nie grzeszy. To raczej tani sprzęt, więc na komplet złącz i ich sporą ilość też nie ma co liczyć (np. Toshiba tylko 1 pełnowymiarowe USB, Dockstar brak czegokolwiek poza USB i ethernetem, nawet audio nie ma).
  • Brak możliwości rozbudowy – zarówno procesor, SSD, jak i RAM są niewymienne, wlutowane na płytę – SoC. W połączeniu z punktem pierwszym powoduje, że przy zwiększeniu wymagań czy awarii któregoś podzespołu trzeba się liczyć z wymianą całego sprzętu.
  • Słabe wsparcie Linuksa od strony producentów – ani Toshiba, ani Trim-Slice nie pozwolą na uruchomienie Linuksa tak po prostu. Instalacja zawsze jest większą lub mniejszą rzeźbą (Dockstar ma niezły, choć nieprzyjazny użytkownikowi instalator, na Trim-Slice niby udało uruchomić się Debiana, ale z kernelem z Ubuntu). Toshiba oficjalnie wspiera tylko Androida, niby da się na AC100 zainstalować Ubuntu 10.10 (oczywiście rzeźba), ale nie działa dźwięk.
  • Nie działają niektóre aplikacje – dobra, nie ma co ukrywać, chodzi głównie o Flasha. Niby nic, ale na tę chwilę niestety Flash jest furtką do multimediów i praktycznie niezbędny do przeglądania Internetu. Być może HTML5 coś w tym temacie zmieni, pytanie czy zmieni i, jeśli tak, to kiedy.

Co dalej? Nie ukrywam, że jestem kibicem energooszczędnych i stosunkowo tanich rozwiązań o dużych możliwościach, a taki właśnie jest ARM. Niestety, w tej chwili trudno rozważać ARM jako pełnowymiarową architekturę pod Linuska, dlatego – nie licząc Dockstara – jestem unARMed. Mam nadzieję, że rosnące zainteresowanie nią Ubuntu i Apple odbije się pozytywnie na wsparciu Linuksa.