WiFi w domu, z przygodami oczywiście

Niedawno żonka dostała
nowego laptopa
. Z różnych ciekawych rzeczy, ten laptop ma, między innymi,
WiFi. Karta na chipsecie Prism 2.5 została od kopa rozpoznana przez Linuksa
(na początku jako eth0, co przez chwilę powodowało moje wątpliwości
w sprawność normalnego portu Ethernet). Szkoda by było tego nie
wykorzystać.

W domu mam jeszcze dwie bezprzewodowe karty sieciowe: na PCMCIA i na USB,
obie Compex, obie zawsze sprawiały mi problemy, ale przynajmniej dawało się na
otwartych sterownikach to jakoś odpalić. Tę na PCMCIA sobie
odpuściłem, bo nie będę odpalał innego laptopa i kernela 2.4, żeby sprawdzić
czy WiFi u żony działa. Postanowiłem spróbować z tą na USB, od razu
podłączając ją do mojego routerka.

Karta jest na chipsecie ATMELa. Zasadniczo są do tego dwa sterowniki:
atmelwlandriver i at76c503a (berlios driver). Oba
od dawna nie rozwijane. Żadnego z tych sterowników w PLD nie ma (pewnie
w żadnej dystrybucji nie ma). Poprzednio tę kartę uruchamiałem na tym pierwszym
sterowniku, nawet udawało się do tego PLDową paczkę zbudować i jako-tako to
działało. Z drugim też próbowałem, ale bez lepszych rezultatów (innych niż
zwis maszyny czy okazały Oops).

Tym razem atmelwlandriver nie udało mi się nawet skompilować
– systemu budowania dostosowanego do antycznych kerneli nie umiałem
pogodzić z PLDowym kernel-module-build. O dziwo, sterownik z Berliosa,
w wersji CVS, skompilował się bez problemów. Co więcej, załadował się na
tropku i połączył się z laptopem żonki. Oczywiście konfiguracja nie może być
normalna (gdzie router z kartą WiFi robiłby za AP) – karty
działają w trybie Ad-Hoc, bo ta na USB trybu master nie umie.

Połączył się, ale coś za bardzo sieć nie działała. Sprawdziłem
tcpdumpem i zobaczyłem ip packet truncated – 4 bytes
missing
. No fajnie, pewnie sterownik spieprzony. Ale nie wyglądało to na
coś, czego nie dałoby się naprawić. Google dużo na ten temat nie miało do
powiedzenia. Zajrzałem więc do źródeł i lepiej przyjrzałem się logom. W logach
znalazłem: firmware version 1.103.0 #175 (fcs_len 4) . Najpierw
spróbowałem starszego firmware’u (ze sterownikiem przyszły dwie wersje), ale
to w ogóle nie działało. Pozostało pogrzebać w źródłach. Okazało się, że jest
tam kod odpowiedzialny za obcięcie FCS (cokolwiek to jest) z końca ramki. Ten
FCS to 4 bajty, z wyjątkiem jednej wersji firmware (jakiejś starej), gdzie
ta długość była ustawiona na 0 (z komentarzem, że ta wersja jest głupia i FCS
nie doczepia). No to wpisałem 0 na stałe i bingo! Zadziałało :-).

Kolejnym problemem były straty pakietów. W pokoju, gdzie zwykle stoi
laptop, 17%. Przeszedłem się z nim po mieszkaniu i w przedpokoju, gdzie
powiesiłem nadajnik (kartę USB) było 0%. Ale w przedpokoju nikt pracować nie
będzie… Spróbowałem jeszcze przenieść nadajnik (najpierw powiesiłem nad
drzwiami, obok dzwona, bo tam się ładnie komponował ;-)), położyłem na
drzwiczkach szafki… i w całym domu jest zasięg i 0% strat. Tylko jak to tam
na stałe powiesić… próbowałem dwustronną taśmą klejącą, ale odpadało. Ten
problem zostawiłem sobie na później.

Na początek teksty robiłem na gołym 802.11b, nawet bez WEP. Oczywiście nie
mogło tak zostać. WAP to też żadne zabezpieczenie. O WPA na tych kartach
mogłem zapomnieć (tylko 802.11b umieją, a więc WPA na pewno nie). Bawić się
w 802.1x+WEP nie widziałem sensu. PPPoE też już przerabiałem w pracy (więc
żadne wyzwanie), a do tego też wydawało mi się to mało sensowne w domowej
sieci z jednym komputerem. Postanowiłem spróbować IPSec. W końcu tę
technologię też trzeba poznać. Dodatkowo chciałem też WEP odpalić z prostym
kluczem, po co cokolwiek ułatwiać… ale to nawet nie chciało ruszyć między
tymi kartami. Trudno.

Poczytałem o ipsec-tools, poeksperymentowałem, w końcu
załapałem jak ten racoon i setkey działają.
Okazało się że w takim przypadku jak mój, gdzie nie potrzeba DHCP, czy innej
automatycznej konfiguracji, to takie IPSec całkiem dobrze może się sprawdzić.

Gdy już miałem prawie wszystko gotowe, z szyfrowaniem, przygotowanym
routingiem, NATem itd… połączenie przestało działać. Karty się nie
widziały… przypomniałem sobie, że wcześniej dziecko walnęło drzwiami w tę
wiszącą kartę USB… przestraszyłem się, że się rozwaliła. Kilka jej restartów
nie pomogło. Rozkręciłem… w środku wyglądało bardzo solidnie i raczej na
nienaruszone… postanowiłem sprawdzić jeszcze jedną możliwość –
zrestartowałem laptopa (samo ifdown/ifup, czy nawet wyładowywanie modułu nie
pomagał)… ruszyło… uff…

Na koniec zamontowałem trochę solidniej nadajnik:

[img:wifi
full-prof]

A teraz żonka siedzi przy laptopiku, bez kabelka i nie narzeka. Wiec chyba
jest ok. 🙂 Tylko czemu zawsze w tą radiówką musi być tyle problemów?…

Reklamy

Dobra rada

Jeśli ktoś chce mieć pewność co do serwerów DNS to powinien się zastanowić nad hostowaniem głównego i zapasowego nameserwera w zupełnie różnych miejscach. Szczególnie głupio wychodzi, gdy serwer usług działa, a żaden z zewnętrznych serwerów DNS wskazujących te usługi nie.

W tej chwili niedostępne są oba serwery DNS dla domeny jogger.pl. Dla uzależnionych, na przyszłość: IP joggera (stan na dzisiaj) to: 212.14.32.26. Wpisałem do /etc/hosts… pewnie kiedyś będę tego żałował, chyba że będę pamiętał o zakomentowaniu.

Firefox windowsieje?

This address is restricted

This address uses a network port which is normally used for purposes other than
Web browsing. Firefox has canceled the request for your protection.

Teraz będzie przeglądarka mi mówić co jest dla mnie dobre? Gdyby to jeszcze
chodziło o jakieś realne zagrożenie, czy adekwatne do zagrożenia
zabezpieczenie. Jeśli coś mi się ma stać od skierowania przeglądarki na port
„79”, to czemu niby port np. „76” miałby być bezpieczny?

SNMP pod Linuksem…

Mamy w firmie kilkadziesiąt modemów, kilkanaście zarządzalnych switchy,
ileś urządzeń radiowych. To wszystko razem tworzy dość skomplikowaną sieć.
A ja, wraz z kolegami muszę nad tym zapanować. Oczywiście radzimy sobie, ale
bywa to dość upierdliwe. Zwykle konfigurujemy urządzenia i badamy ich stan
przez WWW lub telneta. Oczywiście każde urządzenie ma inny interfejs,
a z każdym z tych interfejsów są jakieś problemy (np. w jednym modemie hasło
zmieniam elinksem, a przepustowość firefoksem, bo pierwsze nie działa
w firefoksie, drugie w elinksie). Sprzętu przybywa, więc zarządzanie nim staje
się coraz większym problemem.

Fajnie by było móc zarządzać wszystkim z jednego miejsca. Można część zadań
zautomatyzować jakimiś skryptami z osobnymi backendami dla każdego typu
urządzenia (tak mam teraz zrobiony backup konfiguracji części urządzeń)
i całością zarządzać w jednym miejscu (własny interfejs WWW), ale tu byłaby
kupa roboty. Taka śmierdząca kupa… więc sobie to daruję, przynajmniej na
większą skalę.

Jest jednak coś co łączy większość naszych urządzeń: SNMP. Prawie wszystkie te urządzenia obsługują
SNMP. Dotychczas używałem tego tylko do monitorowania wykorzystania łącz,
ewentualnie traktowałem jako ficzer, który należy wyłączać ze względów
bezpieczeństwa (niektóre urządzenie po ustawieniu hasła dostępu do WWW
i telneta dalej pozwalały na dostęp r/w przez SNMP z community name
private). Wczoraj, myśląc nad zautomatyzowaniem kolejnego zadania
(przygotowania konfiguracji MRTG dla wszystkich switchy, zsynchronizowanej
z danymi o topologii sieci z bazy danych), zacząłem się zastanawiać, czy nie
można by spróbować tego SNMP jakoś szerzej wykorzystać…

Od razu zaznaczam, że z SNMP jestem dość zielony, co może mieć duży wpływ
na to co napiszę poniżej – jak pisze bzdury, to prosze dać znać.

Wiem, że jest coś takiego jak słynne Open View, którego na oczy nie
widziałem, ale podejrzewam, że byłoby tym czego poszukuję. I to, że na pewno nas
na to nie stać. Postanowiłem poszukać coś tańszego, najlepiej otwartego i za
darmo. Zacząłem oczywiście od tego co widzi poldek…

Poldek, poza narzędziami do monitorowania urządzeń, w sensie rysowania
statystyk (to mi już u mnie MRTG + RRDTool załatwiają), znalazł niewiele. GXSNMP
jest nierozwijany od lat, a gdy go ostatnio oglądawał, to się za bardzo nie
nadawał do użytku. Tym razem sobie go darowałem. Kolejny był Scotty, którym już
też kiedyś się bawiłem. Pamiętam go jako brzydkie, ale działające coś w Tk/Tcl.
Chciałem znowu tego spróbować, ale nawet się nie uruchomiło. Scotty okazał się
niekompatybilny z aktualnym Tcl (używa jakiegoś prywatnego symbolu, którego
w nowej wersji biblioteki brak). Na razie nie chciało mi się z tym dalej
walczyć.

GXSNMP i Scotty to narzędzia nie tylko do zarządzania siecią przez SNMP, ale
też, a może przede wszystkim, do rysowania mapy sieci. Do SNMP poldek pokazał mi
jeszcze Mbrowse – Mbrowse is an SNMP MIB browser based on GTK and
net-snmp
. Pomyślałem, że to może się przydać – pozwoli się dobrać do
konkretnych zmiennych urządzenia. Po zainstalowaniu się nawet uruchomił, pokazał
drzewko MIB… ale nie udało mi się tym odczytać chociażby jednej wartości
z localhost (snmpwalk i snmpget z konsoli działały).
Do kitu.

W PLD nie znalazłem czego szukałem (rzadko to się zarza), to zajrzałem na
Freshmeat. Pierwsze na co tam
trafiłem, to MIB
Views
, firmy Muonics. Oprogramowanie komercyjne, z możliwością darmowego
wypróbowania przez piętnaście minut. Postanowiłem spróbować. Na pierwszy rzut
oka wygląda podobnie do Mbrowse, tyle że dużo ładniej… i działa. Wygląda na
to, że to co ma robić, to robi i robi to dobrze. Interfejs jest ładny
i wygodny (na tyle, na ile mnie się to udało teraz stwierdzić). Jednak raczej
tego nie kupimy – MIB Views nie daje żadnych mechanizmów zarządzania
całą siecią. W danym momencie pracuje się z jednym urządzeniem (agentem
SNMP), a żeby przełączyć się na inne trzeba od nowa podawać jego parametry.
Jeszcze muszę zobaczyć jak to będzie działać z konkretnymi urządzeniami (na
razie bawiłem się w domu, tylko z localhost), ale raczej to sobie darujemy.

Na Freshmeatcie znalazłem też trochę otwartego lub darmowego
oprogramowania. W szczególności zainteresowały mnie dwa Javowe programy: Open
Eyes i NetWhistler. Obydwa służą do
tworzenia mapy sieci i zarządania siecią. Pierwszy ma brzydki i mało
intuicyjny interfejs, nie chciało mi się w to wgłębiać. Drugi wydaje się
całkiem sensowny, ale strasznie długo z nim walczyłem, żeby dodać tam chociaż
jedną maszynę. Okazało sie, że NetWhistler działa tylko uruchomione z roota,
inaczej wali jakimiś mało mówiącymi wyjątkami. To zdaje się być normą
w oprogramowaniu Javowym – oprogramowanie zakłada, że ma dostęp do
wszystkich swoich plików, a instalator NetWhlister upierał się jeszcze, żeby
instalowac z roota. W każdym razie, z roota chodzi i nawet daje się używać,
ale na kolana nie powala. I zakłada, że wszystko jest zorganizowane w ładne
podsieci IP (u nas to bardziej skomplikowane – wiele VLANów, podsieci
w kilku VLANach jednocześnie, adresy oderwane od jakiejkolwiek podsieci)
i bezpośrednio dostępne (u nas wiele sieci jest odizolowanych, nie chciałbym
włączać pomiędzy nimi routingu, żeby wszystko dało się zapingowac z workstacji
adminów). Może warto się tym jeszcze pobawić… a może i nie.

Z oprogramowania na Freshmeat znalezionego pod hasłem SNMP zainteresowało
mnie jeszcze jedno: Internode
Nodemap
. Internode Nodemap to zestaw narzędzi to tworzenia map sieci, ale
nie koncentrujące się na urządzeniach, ale na łączech. Sama mapa nie jest
wyklikiwana, ale wczytywana z plików konfiguracyjnych. Pod każdą mapkę może być
podłożony obrazek jako tło – w ten sposób można np. wrysować swoje łącze
na plan miasta. To mogło by się dobrze u nas sprawdzić, wymagałoby jednak sporo
pracy – wypadałoby zrobić coś co zamieni dane o topologii sieci z naszej
bazy na plik konfiguracyjny dla Internode Nodemap i dołożyć informacje
o geograficznym/fizycznym położeniu urządzeń (czyli zrobić interfejs w którym to
będzie można wyklikać). Możliwy do uzyskania efekt kusi, więc może się tym
zajmiemy.

Wciąż nie jestem w pełni zadowolony z wyniku poszukiwań. To co znalazłem
może i może się do czegoś przydać, ale ciągle to nie jest to.
Nie znalazłem narzędzia, które mógłbym po prostu zainstalować i stosować,
wiedząc, że ułatwi mi pracę i nie musząc dostosowywać tego do naszej sieci, czy
naszej sieci do tego narzędzia. Np. myślałem o czymś, co mogło by bezpiecznie
(wykorzystując SNMPv3) korzystać z SNMP proxy na maszynach z dostępem do
zamknietych sieci. Jednak mało co umie SNMP w wersji 3, a obsługi proxy (czy
raczej kontekstów, bo jak dobrze zrozumiałem, to do tego się to sprowadza) nie
widziałem nigdzie. Liczyłem też na to, że uda się jakoś wykorzystać dane
o topologii sieci z naszej bazy – co do czego i jak jest podłączone.
A może wciąż gdzieś tam jest coś, czego nie znalazłem, a co rozwiązało by
wszelkie moje problemy…

Po nocce

Wczoraj znowu rozpierdziel w firmie. Tym razem przemeblowanie serwerowni.
Firma znalazła kupca na szafę rackową, a że w niej akurat stał nasz sprzęt, to
trzeba było wszystko poprzestawiać do stojaków (które, swoją drogą, mają w tej
serwerowni większy sens niż szafy). Do roboty przyszedłem na 15:00, żeby od
16-tej zacząć. Kolega miał do tego czasu opisać mi wszystkie połączenia (4
switche 24-portowe, z dziesięć serwerów, ponad dwie setki gniazd na
patch-panelach i cała masa połączeń). Nie zdążył, więc robiliśmy to razem
jeszcze z dwie godzinki. Potem było rozbieranie starych szaf, składanie
i wstawianie nowych stojaków, przekładanie patch-paneli z rozszytymi setkami
par itp. atrakcje. W końcu wstawianie sprzętu na nowe miejsce i podłączanie
wszystkiego tak aby zadziałało (oczywiście od razu działać nie chciało).
Wyszliśmy (brudni i śmierdzący, bo w budynku wodę na noc wyłaczają) z firmy
o 3:25. A niektórzy byli w pracy od 8:00.

Dzisiaj rano, normalnie od 8:00, też jakiś admin w firmie się przydał.
Jeden ma chorobowe, zostało nas dwóch. To uzgodniłem z kuplem, co wczoraj od
rana siedział, że ja przyjdę na tę ósmą, a w południe się zamienimy. Więc
przespałem się 3 godzinki, łyknąłem kofeinę z puszki (Booster — taka
podróba Red Bulla z Plusa, za grosze) i, niewiele czyściejszy niż przed
wyjściem z serwerowni, podobnie śmierdządzy i ledwo przytomny, pojechałem do
roboty.

W pracy oczywiście okazało się że parę rzeczy nie działa, ileś innych
działa, ale są podłączone tam, gdzie nie powinny itp. Latałem więc między
serwerowaniami (budynki oddalone o jakieś 500m), z serwerowni do swojego
pokoju, rozszyłem jeszcze parę kabelków na patch-panelu… i o 11-tej jakoś
się uspokoiło. Obiecałem jeszcze coś komuś sprawdzić, więc posiedziałem
jeszcze do wpół do pierwszej, ale do domu wróciłem sporo wcześniej niż
normalnie. Ufff…

W domu wreszcie mogłem się doprowadzić do porządku. Pospać to teraz bym
sobie i tak nie pospał (w dzień mi nie wychodzi), więc, mając tę chwilkę
wolnego, męczę Baculę. Jak już
sobie kupiłem tę nagrywarkę DVD do robienia backupów, to trzeba było w końcu
zacząć je robić. Niestety, pakiet z Baculą w PLD wciąż w rozsypce (ale się
buduje i nawet jakoś działa), a wsparcie dla DVD w Baculi wciąż nie domaga…
Ale jakoś udało mi się to zmusić do działania. Znaczy się, dysk mi rzęzi,
nagrywarka mruga diodą… czy z tej płytki się potem będzie dało coś odzyskać,
to się dopiero okaże.

Kłopoty z DNS

Mam kłopoty z DNS dla jajcus.net i dlatego czasami obrazki
z poprzedniego wpisu były niewidoczne. Zrobiłem workarounda: alias na serwerze
WWW w innej domenie i zmiana URLi we wpisie. Więc jak ktoś nie obejrzał sobie
zdjęć, to może spróbować teraz — powinno być lepiej.

PLD RescueCD i PXE

Po pierwsze trzeba mieć serwer DHCP (ten z pakietu dhcp,
zresztą chyba nie mamy innego w PLD) i TFTP. Uwaga serwer z paczki
tftpd nie chciał działać z syslinuxem, więc należy
zainstalować tftpd-hpa. Oprócz tego trzeba mieć bootloadera
umiejącego ładować system przez sieć. W moim przypadku był to
syslinux. No i potrzebna jest płytka RescueCD, z obrazem systemu do
uruchomienia. Trzeba użyć oficjalnego obrazu (datowanego
2004-07-18) dostępnego ze strony RescueCD. Nowsza wersja
(beta z 2005-06-19) się co prawda bootuje, ale nie można się
do niej zalogować.

Montujemy płytkę RescueCD i kopiujemy z niej pliki vmlinuz i rescue.sqf do
/var/lib/tftp. Dla pełniejszej funkcjonalności można tez skopiować
boot.msg, help.msg i memtest. Część plików jest w katalogu
głównym płytki, część w boot/isolinux. Z katalogu /usr/lib/syslinux
kopiujemy plik pxelinux.0 (część syslinux służąca do bootowania przez sieć), też do
/var/lib/tftp. Pozostaje przygotować plik konfiguracyjny dla pxelinux. W tym celu
tworzymy katalog /var/lib/tftp/pxelinux.cfg, a w nim plik default (nazwą
pliku może też być np. adres MAC maszyny którą będziemy bootować, szczegóły w dokumentacji
syslinuxa). Plik ten tworzony jest na podstawie isolinux.cfg
z RescueCD. U mnie wygląda on tak (i to powinno działać z tą wersją RescueCD u każdego):

serial 0
prompt 1
timeout 99
default pxe
label pxe
 kernel vmlinuz
 append initrd=/rescue.sqf init=/linuxrc root=/dev/ram0  ramdisk_size=54000  console=tty0 console=ttyS0,9600n81
 ipappend 1
label mem
  kernel memtest

Ta konfiguracja jest oczywiście przygotowana do użycia z konsolą szeregową. Jak ktoś chce standardową konsolę VGA,
to powinien wywalić serial 0 i console=tty0 console=ttyS0,9600n81.

Gdy już mamy przygotowane pliki dla startowanej maszyny, musimy je jej wskazać. Robi się to przy pomocy
serwera DHCP, jednocześnie przydzielając adres IP. W moim przypadku załatwiał to poniższy wpis w /etc/dhcpd.conf,
w odpowiedniej deklaracji podsieci:

host pxeinstall {
	hardware ethernet 00:40:63:c3:99:a9;
	fixed-address 10.253.0.99;
	filename "pxelinux.0";
}

Adresy MAC i IP należy oczywiście dostosować do swoich potrzeb. Nazwa pliku jest względna do
katalogu /var/lib/ftp i może być właściwie dowolna. Większość wspomnianych wyżej
ścieżek w /var/lib/tftp jest konfigurowalna. Wyjątkiem jest katalog
pxelinux.cfg.

To właściwie tyle konfiguracji. Należy jeszcze się upewnić, że serwery TFTP i DHCP działają
i używają właściwej konfiguracji (dhcpd trzeba zrestartować), włączyć na maszynie do
wystartowania bootowanie przez PXE i uruchomić ją. Po chwili powinna dostać adres IP, pobrać parę
plików po TFTP i uruchomić system.