Tag: router

Opublikowane w

Yet Another Stupid Checkpoint.

Co jakiś czas łapię się na tym, że robię porządki, zmiany, podsumowania i postanowienia. Zwykle grupowo i w okolicach urlopów. Jako, że właśnie skończyłem urlop, to pora na małe podsumowanie.

Na początek rzeczy z publicznej listy TODO. Przede wszystkim, w końcu uruchomiłem produkcyjnie Dockstara. Póki co – działa i podoba mi się. Prawie pewne jest też, że pojawi się wkrótce test sprzętowego simlocka – muszę (i to szybko!) przenieść numer spam z Plusa, zapewne do Play, bo długie terminy po doładowaniach, a numer tylko na przychodzące. Zobaczymy jak to działa, zobaczymy co dalej z telefonami…

Znowu lenistwo wzięło górę i nie poszukałem kasety Bez Krótkich Spodni. Numer jeden do zrobienia przy najbliższej okazji, razem z (dopisanym w tej chwili) eksportem archiwum listy SzLUUG. Router w domu… kiedyś zrobię, najpierw kable trzeba zabezpieczyć jakoś, bo małą ciągnie i gotowa zepsuć połamać. Certyfikat IPv6 ugrzązł. Chciałem robić tylko w oparciu o publiczne, darmowe zasoby i poległem na revDNS – wygląda, że nikt z dynDNSów nie umożliwia ustawienia reva (albo za słabo poszukałem, po prostu).

Z innych sieciowych rzeczy – dziś przypadkiem sprawdziłem i okazało się, że Google podniósł blogowi pagerank (do 4). Co ciekawe, staremu, nieutrzymywanemu blogowi nie spada (nadal 3). Przypominają się ludzie ze starych projektów. Tydzień na zastanowienie i trzeba sobie jasno odpowiedzieć, czy jest sens się bawić czy kolejne rzeczy do zaorania. Tym bardziej, że są nowe plany (nie nadają się na publiczne TODO) i czas będzie potrzebny.

Z nie wpisanych na listę – zacząłem klepać kod do gry. Tak, zainspirowałem się historią RPG Idee Fixe, które powstawało latami i stwierdziłem, że skoro nic podobnego do tkwiącego w mojej głowie pomysłu nie istnieje (albo przynajmniej o istnieniu nie wiem), to będę pomału rzeźbić, bo pośpiechu nie ma. Na razie bawię się pojedynczymi funkcjami, nie wiem jeszcze, czy miałoby być to webowe, czy standalone. O ile cokolwiek powstanie, co wcale pewne nie jest… Na razie jest pomysł (miejscami mglisty), do tego napiszę parę funkcji i postaram się złożyć to w spójną całość. Potem pozostało dobranie parametrów (czytaj: prawdopodobieństw) i jakby to wyszło, to tylko pozostanie opakować w formę strawną dla przeciętnego użytkownika (czytaj: nie CLI).

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

Quagga, czyli czemu czasem warto zerwać z kompatybilnością wsteczną.

Tak się złożyło, że w użyciu jest sobie Quagga. Złożyło się też tak, że pobierane z niej są pewne dane przy pomocy polecenia vtysh. W postaci:

vtysh -c "show ip bgp neighbors  advertised-routes"

Następnie wynik polecenia jest parsowany skryptem. Generalnie chodzi o pobranie sieci w notacji CIDR. I wszystko byłoby fajnie, ale Quagga w ramach kompatybilności wstecznej (it’s not a bug, it’s a feature!) zwraca czasem samo IP. Niejednoznacznie, przez co z prostego w założeniu skryptu powinien zrobić się automat domyślający się, czy chodzi o /8, /16 czy /24.

Szukałem informacji czy można coś z tym zrobić na kanałach IRCowych, dostałem dane, że nie ma opcji, by zmienić takie zachowanie, tzn. aby Quagga zwracała jednoznacznie (np. uruchomienie z jakąś opcją). Za to było zainteresowanie ew. znalezionym rozwiązaniem. Nie znalazłem. Wygląda, że po prostu się nie da (tak, wiem, zawsze można pogrzebać w kodzie…).

Nie znalazłem też prostej koncepcji na określanie, o jaką długość prefiksu chodzi w danym przypadku. Akurat w przypadku, w którym używam średnio mi na tym zależy, ale elegancko byłoby móc jednoznacznie określić o jaki prefiks chodzi. Pomysły mile widziane. Przychodzi mi do głowy sprawdzanie, czy dla /8 i /16 nie ma nakładających się sieci z prefiksami określonymi wprost. Wtedy wiadomo, że chodzi o /24.

PS. Wiem, że jest BIRD. Jest rozważany, ale to trochę inny temat.