sprzęt

(z góry przepraszam za masę polskawo-anielskawych słówek ;-))

Ostatnio w firmie zajmujemy się łączami radiowymi. Obecne założenia to szkielet sieci na
urządzeniach Proxim Tsunami 5GHz, i łącza końcowe na 2.4Ghz. Jedno łącze 5GHz
działa już od paru tygodni i jest przez nie podłączona jedna duża sieć
osiedlowa. Niestety działy się z tym różne dziwne rzeczy (zawisało od strony
ethernetu satelity lub stacji bazowej). Upgrade firmware do 2.0 tylko pogorszył
sprawę. Na szczęście pojawiła się wersja 2.0.1, która wydaje się rozwiązywać
problem (przynajmniej na razie).

To był konkretny błąd, który najprawdopodobniej został naprawiony (ale wciąż nie
wiem na czym polegał), jednak pewne felery tych Proximów pozostają bez zmian, a
podczas wymiany firmware dały się mocno we znaki. Po pierwsze czas rebootu.
Urządzenie restartuje się kilka minut, a trzeba je restartować po większości
zmian w konfiguracji. Naprawdę nieprzyjemne. Po drugie — interfejs do
zarządzania przez WWW — nawet dość wygodny, ale jedynie w
przedlądarce z JavaScript. Oczywiście ze standardami W3C ma niewiele wspólnego.

Ze względów bezpieczeństwa adresów access-pointów nie routujemy w świat.
Niestety z routera nie da się tym zarządzać, bo tam nie odpalę graficznej
przeglądarki (wiem, że jak się uprzeć to się da, ale ja nie chcę). Postanowiłem
sobie więc forwardować porty przez SSH. I to nawet działa — dopóki nie
próbuję zmienić jakiegoś parametru. Zmiany robione są przez funkcje JavaScript,
które odwołują się do urządzenia po HTTP, ale z konkretnym IP, czyli nie przez
127.0.0.1 na który mam porty przekierowane. Muszę więc dla każdego urządzenia:
1. przeforwardować port przez SSH i 2. dodać regułkę iptables przekierowującą
odwołania do adresu urządzenia na tak przeforwardowany port. Kupa roboty jak na
interfejs mający ułatwić pracę administratorowi. 😦

Ale te Proximy są i tak lepsze niż AP DLinka (2.4GHz). Ten ostatni też ma interfejs
WWW do zarządzania, jednak nie działający w żadnej Linuksowej przeglądarce. Żeby
zmienić jakiś parametr muszę to badziewie podłączać do Win*. Brrrr…

Najlepiej wypada interfejs WWW switchy DLinka. Też używa JavaScript,
miejscami nawet Java (nawet do wyświetlenia tabelek!), ale można go normalnie
forwardować i działa w Firefoksie. Jest nawet dość wygodny, miejscami może nawet
bardziej niż telnetowy interfejs (bardzo fajny, pełnoekranowy) ze starszych
switchy tej firmy. W jednym (a może nawet nie tylko jednym) switchu mam nawet SSH,
ale połączenie (dokładniej wymiana kluczy) trwa tak długo, że raczej nie będę
używał.

Wracając do AP DLinka — w czwartek skonfigurowałem jeden taki do pary
z odpowiednim urządzeniem Proxima do radiołącza na 2.4GHz. Podłączone w biurze
działało. Wczoraj zamontowali Proxima na kominie, DLinka na dachu w pobliżu.
Było to jak już kończyłem pracę, ale donieśli mi telefonicznie, że to nie
działa. Podobno DLink nie odpowiadał nawet na pingi po ethernecie i
nawet po resecie do ustawieni fabrycznych — tzw.
zgon. Dzisiaj więc skonfigurowałem innego DLinka (tego samego typu) i pojechałem
go podłączyć na tym dachu. Niby wszystko OK, nawet DLink pisze że połączył się z
AP. AP (Proxim) przez jakiś czas pokazuje, że DLink jest podłączony, ale potem
go znika z listy. No i łącze nie działa. Kombinujemy jak możemy,
wyłączamy wszelkie filtry, szyfrowanie itp. i nic. Zadzwoniłem więc do drugiego
admina, żeby spróbował reanimować tego martwego DLinka. Okazało się że
jest sprawny i normalnie odpowiada na domyślnym (fabrycznym) IP.
Poprosiłem o sprawdzenie wersji firmware. Okazało się, że w tym niby
martwym jest firmware 2.0.7 (piszę z pamięci), a w tym który próbowaliśmy
uruchomić 2.0.3. Kazaliśmy przywieść tamten. Skonfigurowałem, podłączyłem… i
ruszyło :-). Ufff.

Potem jeszcze w firmie trochę walczyliśmy z VLANami. Postanowiliśmy wydzielić
tę nową sieć do osobnego VLANa. Jednak był problem w skonfigurowaniu switchy, bo
nie mogliśmy się połapać na których portach ma być (w grę wchodziło 6 switchy 24
portowych)… nie ma to jak dobry bajzelek ;-). W końcu się
udało i chyba na razie wszystko działa jak należy. Oby jak najdłużej.

P.S. poprzedni wpis dla wybranych zalogowanych

W zapowiedziano mi, że w czwartek dostanę access-pointy i switcha do
skonfigurowania na radiołącze na pewnym kominie w Rudzie Śląskiej. W czwartek
sprzęt przyszedł… o godzinie 15:00 (pracuję do 16:00) i szef powiedział że
muszę to jeszcze tego dnia zrobić. Fajnie… sprzęt, którym nigdy się nie
bawiłem — więc go nie znam, do tego dwóch różnych firm (Proxim i
DLink), a mam go skonfigurować do poprawnego (uwzględniając separację VLANami
itp.) i bezpiecznego działania w godzinę (jak nie będzie działało, to będę się
wdrapywał na komin, żeby poprawiać). Zrobiłem to nawet. Napewno nie optymalnie,
ani nie w pełni bezpiecznie, ale działało.

W piątek dostaliśmy do tego switcha, więc mogliśmy też go skonfigurować i
sprawdzić radiołącze z VLANami. Działało. Na komin nie poszło — widać nie
było to tak pilne. Ale to by było za pięknie, więc pod koniec godzin pracy, po
zwisie innej radiolini szef postanowił to naprawiać. Zrobił upgrade na
access-pointach, po którym siadało wszystko, nawet łącze modemowe do centrali
(po chwilowym odłączeniu AP z radiolini od switcha do którego podłączony był
modem). Jak wychodziłem z pracy (już trochę po 16:00) to niby wszystko działało,
ale szef kontynuował psucie (właściwie naprawianie — przez downgrade
firmware’u do poprzeniej wersji) i jeszcze wieczorem coś trzebabyło przez
telefon ustalać. Dobrze, że przynajmniej nie musiałem więcej osobiście przy tym
grzebać.

Bałem się, że w weekend będę musiał jeździć naprawiać te radiówki, ale na
szczęście nie było to konieczne, więc sobotnia impreza (nie nadająca się do
opisania na tym poziomie) odbyła się praktycznie bez zawodowych zakłóceń.

W poniedziałek w pracy spotkała mnie niespodzianka. Szef przyniósł mi karteczkę
z nazwami i adresami access-pointów ze szkieletu naszej sieci radiowej —
tak jak je skonfigurował po kolejnych zmianach firmware.. Były to
nazwy i adresy zupełnie inne niż ja z drugim adminem ustaliłem i udokumentowałem
w naszych materiałach. Do tego jeden AP miał adres należący do switcha (którego
adresu szef nie zmienił — to switch też ma IP?). No kurde —
kto w tej firmie w końcu jest adminem?

Z jednej strony to nawet fajnie, że sam z tym firmware nie musiałem walczyć i
zajął się tym ktoś inny. Trochę nawet mnie to zaskoczyło, bo ostatnio szef nawet
nie zaglądał do serwerowni, bo prezesowi przecież nie wypada np. restartować
modemów (kiedyś czasem jeździł, bo miał znacznie bliżej niż ja). Z drugiej
jednak strony, to w końcu ja jestem odpowiedzialny za działanie całej
infrastruktury sieci i ja ustalam zasady adresacji, podziału łącza
(przyzwyczaiłem już się do tego, że szef regularni podnosi ponad rozsądny poziom
ograniczenie przepustowości łącza do sieci w której jest podpięty) itp. i raczej
nie powinno tak być, żebym o zmianach dowiadywał się ostatni (przecież mogłem
pół nocy stracić zastanawiając się dlaczego gdzieś pingi nie dochodzą).

Wszyscy rozpisują się o tym że miesiąc sie rozpoczął. Pewnie dlatego żeby
nie mieć pustej strony na swoich jogach. Ja też napiszę, szczególnie, że mam
na co się poużalać.

A więc przychodzę do pracy, ciesząc się że drugi admin już wrócił
z urlopu i będę miał mniej roboty. Jednak zaraz jak siadłem do kompa
okazało się, że ten nie dostał adresu IP. Biurowy serwerek/routerek
leży. Podpiąłem do niego monitor, klawiaturę, ale nawet zalogować się
nie da. Magic-SysRq ujawnił, że chodzi tam cała masa procesów
„crond” w stanie „D” („zombie”).
Dziwne, ale reboot pomógł.

Już gdy grzebałem w tym biurowym serwerku dzwonili klienci że im net
albo poczta nie działa. Oni nie są podłączeni przez nasz biurowy LAN,
więc już było wiadomo że na drugiej serwerowni (na TPSA) też coś leży.
Gdy w biurze sieć już działała okazało się, że nie ma wyjścia w świat,
a więc leży router brzegowy. On już szwankował od jakiegość czasu
i nawet nowa płyta do niego była (czekała na nową kartę V.35). Ale to
nie wszystko… okazało się że leży także router/serwer obsługujący
sieci osiedlowe.

Poszliśmy na TPSA. Okazało się że router brzegowy leży tak jak
podejrzewaliśmy, jednak reboot nie pomaga (ostatnio za którymś razem
pomagał). No cóż będzie trzeba płytę wymienić nie czekając na kartę
V.35 (stara karta była na ISA, więc do nowej płyty byśmy jej nie
wcisnęli). Serwer od osiedlówek natomiast wisiał podobnie jak ten
biurowy, tyle że tu dla odmiany była masa procesów „smbd”
w stanie „S”. Reboot pomógł.

W końcu udało się i odpalić router brzegowy. W tym celu trzeba było
znależć kartę grafiki która by do niego pasowała i w nim działała
(zwykłe AGP nie wchodziły w slot 1.5V, a jedna PCI po prostu nie
działa w tym kompie) i zorientować się że pamięc należy włożyć do
slotu 3 a nie jeden.

Teraz niby wszystko działa, ale część klientów oraz szef narzekają że
strony ładują się strasznie wolno, a my nie możemy znaleźć powodu…

ech… Mam nadzieję, że nie będzie cały marzec tak wyglądał…