2006.11_Karty sieci ethernet_[Sprzet].pdf

sprzęt

Sieci ethernet

Karty sieci ethernet

Piotr Wolny

Dla Linuksa sieć komputerowa jest niczym dla pingwina woda - naturalnym środowiskiem.

W efekcie karty sieci ethernet są bardzo dobrze obsługiwane i nie wymagają od użytkownika

specjalnych starań lub wiedzy w celu ich koniguracji. Nie oznacza to jednak, że dociekliwi

użytkownicy nie znajdą ciekawych możliwości zmian w ich koniguracji. Linux pozwala

m.in. na zmianę ich nazw czy kolejności, co może bardzo przydać się, gdy mamy więcej kart

sieciowych. Dodatkowe wyzwania pojawiają się w przypadku kart włączanych w czasie pracy

systemu.

W tym artykule opiszę także sposoby ra-

formacja o nowym urządzeniu sieciowym pojawia się za

to w logach systemowych oraz w systemie pseudoplików

/proc - polecenie cat /proc/net/dev poda nam pełną li-

stę urządzeń sieciowych. Karty sieci ethernet nazywane

są oczywiście eth0 , eth1 itd. O kolejności przyznawanych

nazw decyduje kolejność ładowania modułów, chyba że

zdeiniowaliśmy “sztywne” przypisania kart do nazw

urządzeń, o czym piszę w dalszej części. Informacje na te-

mat tego, jaki sprzęt dostał jaki identyikator można uzy-

skać m.in. przy pomocy programu ethtool . W pierwszej li-

nii wydruku komendy np. ethtool -i eth0 otrzyma-

my nazwę modułu jądra, odpowiedzialnego za daną kar-

tę. Jeszcze więcej informacji uzyskamy, wydając polecenie

udevinfo -a -p /sys/class/net/eth0/ - na wydruku

działania tej komendy można odnaleźć nie tylko moduł ją-

dra, ale również adres MAC karty sieciowej, który będzie

szczególnie potrzebny, gdy mamy więcej kart, obsługiwa-

nych przez ten sam moduł. W ten sposób możemy oczy-

wiście sprawdzić po kolei wszystkie urządzenia, wpisując

zamiast eth0 - eth1 , eth2 , itd.

Sam fakt wykrycia przez jądro urządzenia i załadowa-

nia modułu nie oznacza jeszcze, iż mamy działającą kartę

Urządzenia i interfejsy

Aby nasza karta sieciowa działała w Linuksie musi zostać

załadowany jej sterownik, czyli moduł jądra. Co prawda

może on być „wkompilowany” na stałe w jądro, jednak

popularne dystrybucje nie stosują takiego rozwiązania.

W praktyce listę wszystkich modułów, obsługujących kar-

ty sieciowe, znajdziemy w katalogu /lib/modules/[wersja_

jądra]/kernel/drivers/net . Potrzebne moduły ładowane są au-

tomatycznie podczas startu dystrybucji - niezwykle rzad-

ko zdarza się konieczność ręcznego załadowania odpo-

wiedniego modułu.

Gdy jądro ładuje sterownik karty sieci ethernet tworzy

sobie “wirtualne” urządzenie, którego nie ma w katalogu

/dev/ (w innych systemach operacyjnych karty sieciowe

są często dostępne za pośrednictwem pliku w /dev/ ). In-

listopad 2006

dzenia sobie z kłopotliwymi kablami

i switch'ami , metody testowania połączeń

ethernet i mierzenia ich przepustowości,

będzie także o tym, jak połączyć dwie karty sieciowe w jed-

ną.

sprzęt

Sieci ethernet

sieciową. Musi ona zostać jeszcze skoniguro-

wana, co w przypadku najpopularniejszych

sieci TCP/IP wiąże się z nadaniem adresu IP

i określeniem parametrów sieci. Gdy wyda-

my polecenie ifconig (lub /sbin/ifconig ,

bądź ip link show ) w niektórych dystrybu-

cjach zobaczymy listę wszystkich urządzeń,

które zna jądro, w innych zaś jedynie tych,

które zostały skonigurowane i mają już swój

adres IP, itp.

Zagadnienia związane z koniguracją sie-

ci TCP/IP oczywiście przekraczają ramy te-

go artykułu. Wspomnę tylko, że w większo-

ści dystrybucji koniguracja kart przechowy-

wana jest w katalogu /etc/sysconig/network-

scripts/ (w plikach o nazwach ifcfg-nazwa_in-

terfejsu , np. ifcfg-eth0 ), jednak ich ręczna edy-

cja na ogół nie jest zalecana, bowiem twórcy

dystrybucji przewidzieli do tego narzędzia

graiczne. Na przykład w Mandrivie możemy

w tym celu kliknąć na Conigure Your Compu-

ter -> Network -> Network Interfaces , a w Fedo-

rze Core na “ Network Coniguration ” w menu

z ustawieniami środowiska. W dystrybucjach

Debian oraz Ubuntu , choć mamy rozmaite gra-

iczne narzędzia koniguracji sieci, wygodniej

jest moim zdaniem po prostu modyikować

plik /etc/network/interfaces .

Rysunek 1. Koniguracja interfejsów sieciowych w FC5. Na liście, poza kartami sieciowymi, pojawia się

karta DVB

problemy, które wymagają od nas ingerencji

w konigurację urządzeń sieciowych.

Czasem spore zamieszanie w konigura-

cji kart potrai wprowadzić inne urządzenie

sieciowe. W niektórych dystrybucjach może

to być np. karta DVB, albo nawet kontroler

IEEE 1394 ( FireWire ). Dlaczego? Otóż jed-

no i drugie z tych urządzeń może być uży-

wane do przesyłu danych - karta DVB potra-

i odbierać transmisję z satelity a przy kon-

trolera IEEE 1394, po załadowaniu modułu

eth1394 , można również przesyłać dane, po-

dobnie jak przez kartę sieciową. Ze wzglę-

du na błędy w niektórych dystrybucjach mo-

że się zdarzyć, że takie urządzenie jest trak-

towane przez jądro jako karta sieciowa, na-

tomiast skrypty koniguracji sieci go „nie

widzą” i zaburzeniu ulega kolejność urzą-

dzeń. W niektórych przypadkach (np. jeśli

takie urządzenie jest wykryte jako pierwsze

i otrzymuje nazwę eth0 ) może to doprowa-

dzić do zupełnego nie działania sieci, a in-

terfejsy wydają się nie reagować na wpisy

w ich koniguracji.

Inną potencjalną przyczyną problemów

są karty sieciowe, które mogą być instalowa-

ne w czasie pracy systemu. Na przykład, gdy

włożymy kartę USB przed startem systemu

może ona otrzymać nazwę eth0 . Jednak ta sa-

ma karta, zainstalowana w trakcie pracy mo-

że już być eth5 . Gdy chcemy używać dwóch

kart USB, bez specjalnych zabiegów, otrzy-

mamy ich lokalizacje będą wręcz losowe,

a więc tradycyjne metody koniguracji nie

zdadzą często egzaminu.

Jak sobie radzić w takich sytuacjach? Naj-

ważniejszym jest znaleźć przyczynę proble-

mów – jeśli posłużymy się omówionymi

wcześniej ethtool czy udevinfo będziemy wie-

dzieć, jakie urządzenia sieciowe widzi nasze

jądro. Niepotrzebne nam urządzenia może-

my zdezaktywować, zakazując systemowi ła-

dowania odpowiedniego modułu (patrz ram-

ka “Jak zapobiec załadowaniu modułu”). Al-

ternatywnie możemy też stworzyć sztywne

powiązania, pomiędzy danym urządzeniem

a nazwą interfejsu, o czym piszę dalej.

W przypadku kart podłączanych w czasie

pracy systemu, w Linuksie znajdziemy spe-

cjalne programy do ich obsługi. Warto wie-

dzieć o ich istnieniu i skorzystać z ich moż-

liwości.

Nazewnictwo interfejsów

Jak wcześniej wspominałem, jądro nada-

je urządzeniom sieciowym kolejne nazwy,

zaczynając od eth0 , zgodnie z kolejnością

ładowania modułów. W Linuksie możliwe

jest używanie dowolnych nazw interfejsów

– czyli na przykład zamiast eth0 i eth1 mo-

żemy mieć urządzenia o nazwie „gorne_

gniazdko” i „dolne_gniazdko”. Bardzo rzad-

ko jednak występuje racjonalne uzasadnie-

nie dla tego typu zmian.

Możliwe problemy

W prawidłowo działającej dystrybucji, pod-

czas startu systemu znajdowane jest urządze-

nie sieciowe, ładuje się moduł jądra, mamy

urządzenia eth0 , eth1 , itd., następnie w czasie

aktywacji sieci, do poszczególnych urządzeń

przypisywane są odpowiednie pliki konigu-

racyjne, które na ogół zawierają zdeiniowa-

ne przez nas „statyczne” ustawienia adresu

i maski sieci, albo aktywują korzystanie z ser-

wera DHCP.

Ten mechanizm działa bardzo dobrze

w ogromnej większości przypadków, co nie

oznacza, że w Linuksie nie zdarzają się z nim

Jak zapobiec załadowaniu

modułu

Współczesne dystrybucje Linuksa starają

się automatycznie załadować moduły od

wszystkich dostępnych w systemie urzą-

dzeń. Bywa jednak, że nie chcemy akty-

wować jakiegoś urządzenia, lub jakiejś je-

go funkcji i chcemy przekonać system, aby

nie ładował automatycznie danego modu-

łu jądra.

Procedura w tym przypadku jest za-

leżna od dystrybucji. W Mandrivie i De-

bianie Sarge nazwę niechcianego modu-

łu należy dopisać w osobnej linii do pliku

/etc/hotplug/blacklist . Natomiast w Fedora

Core oraz Ubuntu można utworzyć linię

o treści np. blacklist eth1394 w pliku /etc/

modprobe.d/blacklist . W tym przykładzie

zablokowaliśmy ładowanie modułu eth1394 .

Listing 1. Przykłady koniguracji Udev

KERNEL=="eth*",

SYSFS{address}=="00:13:8f:0a:e6:

68", NAME="eth0"

KERNEL=="eth*",

SYSFS{address}=="00:31:84:7a:19:

9c", NAME="eth1"

KERNEL=="eth*",

SYSFS{address}=="00:30:e8:00:08:

90", NAME="eth6"

KERNEL=="eth*",

SYSFS{address}=="00:02:3c:01:01:15:

82:af", NAME="niepotrzebna"

www.lpmagazine.org

sprzęt

Sieci ethernet

Adres MAC

Rozwiązaniem tego typu problemów jest

zastosowanie stałego przypisania danej na-

zwy interfejsu (np. eth0 ) do konkretnej kar-

ty. Można ją zidentyikować na podstawie

bardzo rozmaitych parametrów (sterowni-

ka, umiejscowienia w szynie PCI, identyika-

torów USB i wielu innych), stosunkowo naj-

pewniejsze i najprostsze wydaje się jednak

rozróżnianie kart na podstawie adresu MAC

(patrz ramka - “Adres MAC”)

Tak się dziwnie składa, że w Linuksie

można doliczyć się blisko dziesięciu metod

wykonania tej w zasadzie prostej operacji.

Niektóre z nich mają zastosowanie dość uni-

wersalne, inne związane są z konkretnymi

dystrybucjami. Na przykład w Fedora Core

5 wystarczy w koniguracji sieci (“ Network

Coniguration ”) dwukrotnie kliknąć na naz-

wie interfejsu sieciowego i następnie w za-

kładce hardware device mamy możliwość przy-

pisania go do stałego urządzenia ( Bind to

MAC address ). W Mandriva Linux domyślnie

tworzony jest plik /etc/iftab , przechowujący

właśnie sztywne przypisania. Wystarczy zmie-

nić w nim nazwy interfejsów, lub go skaso-

wać, jeśli chcemy skorzystać z innego sposo-

bu. Większość pozostałych dystrybucji rów-

nież zapewnia jakieś własne metody wyko-

nania tej czynności, choć już nie takie wygod-

ne, jak w FC5. Ich opisy znajdziemy w od-

powiednich podręcznikach, dostarczanych

razem z dystrybucją.

Jednak niezależnie od tego, jakiej dystry-

bucji używamy, możemy przypisać dowolne,

stałe nazwy do kart sieciowych, modyikując

konigurację udev.

Udev to podsystem dynamicznie tworzo-

nych, „wirtualnych” plików urządzeń w ka-

talogu /dev/ . W Linux+ z lutego 2006r. zamie-

ściliśmy cały artykuł na jego temat, zawierają-

cy opisy tej i innych różnych „sztuczek” z je-

go koniguracją.

A zmiana nazw urządzeń sieciowych jest

bardzo prosta - musimy jedynie dopisać kilka

linii w któryś z plików w /etc/udev/rules.d/ . Pli-

ki te analizowane są w kolejności alfabetycznej

i na ogół wystarcza wprowadzenie naszych

zmian w ostatnim w kolejności pliku.

Zaczynamy od sprawdzenia przy pomo-

cy programu udevinfo wszystkich dostępnych

w naszym systemie kart sieciowych. Skład-

nie tego użycia tej komendy podałem wcze-

śniej w punkcie „Urządzenia i interfejsy”.

W ten sposób uzyskamy adresy MAC każdej

z kart. Następnie dla każdej z kart tworzymy

linię w postaci:

Zamiast moja_nazwa , zapewne najczęściej bę-

dziemy wpisywać eth0 , eth1 , itd., choć mo-

żemy posłużyć się dowolną nazwą. W tym

przypadku jednak musimy zmodyikować

wszystkie pliki koniguracyjne w dystrybucji,

które odnoszą się do oryginalnej nazwy inter-

fejsu, czyli ethX .

Tego typu linii powinniśmy najlepiej mieć

tyle, ile urządzeń ethX w systemie. Oczywiście

najmniejsza literówka spowoduje, że wpis nie

będzie działał. Zwróćmy więc szczególną uwa-

gę na to, że:

Adres MAC to niepowtarzalny identyikator

każdej karty sieci ethernet . Ma on 48-bitów

(pierwsze 24 bity identyikują producen-

ta karty, pozostałe 24 dany egzemplarz).

Przyjęło się zapisywanie go szesnastko-

wo, np. 00:0C:6E:1A:13:7E. Adresy MAC

są oczywiście niezbędne do jakiejkolwiek

komunikacji w sieci lokalnej. Na ich pod-

stawie możemy jednoznacznie zidentyi-

kować kartę nie tylko w sieci, ale również

w systemie. Powszechnie stosuje się po-

nadto przy koniguracji serwerów DHCP

i zasad dostępu do sieci.

Aby - korzystając z Linuksa - spraw-

dzić adresy MAC wszystkich kart w sieci

lokalnej, możemy na przykład użyć polece-

nia nmap -sP 192.168.1.1-254 .

Adres MAC w Linuksie może zostać

bez żadnego wysiłku zmieniony przez

użytkownika, praktycznie niezależnie od

posiadanej przez niego karty. W tym celu

wystarczy dezaktywować interfejs siecio-

wy (np. ifconig eth2 down ), wydać po-

lecenie ifconig eth2 hw ether [no-

wy_adress] i ponownie uruchomić inter-

fejs ( ifconig eth2 up ). Przed tymi opera-

cjami należy wyłączyć netplugd lub ifplugd .

Większość dystrybucji umożliwia wprowa-

dzenie takiej zmiany na stałe w konigura-

cji interfejsu, przy pomocy różnych narzę-

dzi i plików koniguracyjnych. Można rów-

nież wpisać odpowiednie polecenie do pli-

ków startowych - należy jedynie pamiętać,

że polecenie ifconig ethX ether... mu-

si zostać wydane po załadowaniu modułu

jądra od naszej karty.

• przy porównaniach występuje podwójny

znak równości “==”, natomiast przy przy-

pisaniu nazwy - pojedynczy “=”. Analo-

gicznie jak np. w języku PHP;

• adres MAC musi być koniecznie podany

dokładnie w tej postaci, jak zwraca go po-

lecenie udevinfo , a więc małymi literami.

Na przykład ifconig drukuje ten sam ad-

res kapitalikami i taki wpis nie zadziała;

• udev po znalezieniu wpisu dotyczące-

go np. karty eth0 nie przerwie przetwa-

rzania reszty linii plików, może się więc

zdarzyć, że to samo urządzenie jest kilku-

krotnie modyikowane przez różne wpisy

w plikach koniguracyjnych.

Przykłady wpisów w koniguracji udev za-

mieszczam na listingu 1.

Karty USB

Gdy mamy kartę sieciową USB skoniguro-

wanie w systemie „sztywnego” przypisania

nazw interfejsów do konkretnych urządzeń

jest szczególnie pożyteczne. Bez tego, nawet

Poważnym problemem jest jednak pew-

na nieprzewidywalność przyporządkowa-

nia poszczególnych urządzeń do nazw inter-

fejsów. Gdy nagle np. w programowym ro-

uterze na Linuksie, karty sieciowe zamienią

się adresami IP i innymi parametrami sieci,

to nie tylko sieć może przestać działać, ale do-

datkowo narażamy się na niebezpieczeństwo

ataków z internetu. A do sytuacji, w której

karty zamieniają się identyikatorami, rów-

nież jeśli są to dwie karty PCI, może dojść

bardzo często. Wystarczy zmiana w konigu-

racji urządzeń, spowodowana dołożeniem/

usunięciem jakiegoś urządzenia PCI, co po-

ciągnie za sobą zmianę przydziału przerwań

i w konsekwencji zmianę numeracji interfej-

sów. Czasami wystarczy nawet ingerencja

w BIOS'ie komputera czy w przypadku nie-

których płyt głównych... awaria zasilania.

Listing 2. Prosty skrypt restartujący sieć, urucha-

miany przez program watchdog

#!/bin/bash

logger ' ####wywołano żądanie

naprawy###'

#ifconig eth1 | logger

/etc/init.d/networking stop

/sbin/mii-tool -r

/sbin/mii-tool -R

#karta sieciowa obsługiwana przez

moduł 3c59x

modprobe -r 3c59x

modprobe 3c59x

sleep 5

/etc/init.d/networking start

/etc/init.d/dhcpd restart

exit 0 #inny kod wyjścia powoduje

restart

KERNEL=="eth*", SYSFS{address}=="01:

23:45:67:89:ab", NAME="moja_nazwa"

listopad 2006

sprzęt

Sieci ethernet

przy dwóch kartach sieciowych możemy mieć

problemy z działaniem sieci.

Sama jednak koniguracja udev nie wy-

starczy, aby takiej karty można było używać

wygodnie w systemie. Brakuje bowiem opro-

gramowania, które po podłączeniu karty au-

tomatycznie przypisze jej adres IP i inne pa-

rametry sieci.

Oczywiście takie programy dostępne są

w nowoczesnych dystrybucjach, a nawet z re-

guły są domyślnie instalowane, niezależnie

od posiadanego przez nas sprzętu. W FC5 fun-

kcję tę pełni skrypt netplug (część pakietu net-

tools ), natomiast w większości pozostałych

dystrybucji domyślnie zajmuje się tym nieco

bardziej rozbudowany program ifplugd .

Program netplug praktycznie nie wyma-

ga konigurowania. W systemie znajdziemy

co prawda plik /etc/netplug/netplugd.conf , jed-

nak domyślnie jest w nim jedynie wpis, naka-

zujący kontrolować wszystkie karty sieciowe

(linia o treści eth* ). Zwróćmy uwagę, że pro-

gram ten (zresztą identycznie jak ifplugd ) sam

w sobie nie zawiera informacji o tym, z jaki-

mi parametrami skonigurować interfejs (ad-

res IP, serwer DHCP, itp), ale korzysta z ogól-

nych danych, dostępnych w systemie. Dzię-

ki takiemu rozwiązaniu koniguracja wszyst-

kich interfejsów - zarówno statycznych, jak

i dynamicznych - znajduje się w jednym miej-

scu, i może być wykonana tymi samymi na-

rzędziami, właściwymi dla danej dystrybu-

cji.

Wake on lan

Wake-on-lan , czyli "budzenie przez sieć"

to funkcja, która powinna być obecna na

wszystkich nowo-produkowanych kartach

sieciowych i płytach głównych. Niestety

w praktyce nie na każdym sprzęcie działa

ona prawidłowo - zwłaszcza najtańsze płyty

główne często nie pozwalają na jej używa-

nie. Spróbować jednak warto zawsze.

Jeśli mamy kartę wkładaną w złącze

PCI, do testów będziemy oczywiście po-

trzebowali kabelka do połączenia karty sie-

ciowej z płytą główną. Bywa on dostarcza-

ny wraz z kartami, jeśli jednak nie mamy

go, nietrudno zrobić go samemu - wystar-

czy w sklepie elektronicznym zaopatrzyć

się w odpowiednie małe złączki. Poza ka-

blem, niezbędne są ustawienia w BIOS'ie

płyty głównej. W przypadku kart zintegro-

wanych z płytą, całość koniguracji dokonu-

je się w BIOS'ie.

Część kart, aby mogła obudzić system,

musi zostać do tego skonigurowana z po-

ziomu systemu operacyjnego. W Linuksie

służy do tego program ethtool . Najczęst-

szym jego użyciem jest ethtool -s eth0

wol g, które spowoduje, że karta powin-

na budzić system po otrzymaniu specjal-

nego, "magicznego" pakietu danych. Nie-

które karty obsługują inne - poza "magicz-

nym pakietem" - sposoby budzenia, opi-

sane w man ethtool . Jednak trzeba je za-

wsze sprawdzić doświadczalnie - program

ethtool nie pokaże żadnego komunikatu

o błędach, jeśli aktywujemy tryb nie obsługi-

wany przez kartę.

Do włączenia naszego komputera po-

trzebujemy oczywiście innego hosta w lo-

kalnej sieci, który wyśle do niego "magicz-

ny pakiet". Taki programów jest kilka, np.

etherwake czy wakeonlan . Jako argument

z reguły trzeba podać adres MAC kompu-

tera, który ma zostać włączony. Dodatkowo

etherwake umożliwia podanie nazwy inter-

fejsu, przez który ma zostać wysłany pakiet,

np. etherwake -i eth1 02:54:0C:01:9B:

FF . Określenie interfejsu jest niezbędne, je-

śli komputer, który ma zostać włączony jest

dostępny za pośrednictwem innego interfej-

su, niż eth0 .

( eth0 , itp) powinien być aktywowany wyłącz-

nie wtedy, gdy medium transmisyjne zostało

rozpoznane, ewentualna negocjacja parame-

trów transmisji zakończona i karta jest goto-

wa do pracy. Obydwa te programy powinny

także dezaktywować interfejsy sieciowe, od

których odłączono kabel - nawet jeśli dotyczy

to zwykłych kart sieciowych np. PCI. W prak-

tyce rozpoznawanie podłączenia i odłączenia

kabla działa bardzo różnie, w zależności od

karty sieciowej i wersji jądra. Jeśli szczegól-

nie nam zależy, aby interfejsy były aktywo-

wane i dezaktywowane w momencie podłą-

czenia kabla, powinniśmy spróbować użycia

obydwu tych programów - jest dość prawdo-

podobne, że tylko jeden z nich będzie dzia-

łał. Ponadto lepsze wyniki uzyskamy na star-

szych wersjach jądra (np. tych z dystrybucji),

niż najnowszych z www.kernel.org .

Testowanie ifplugd oraz netplug jest bar-

dzo proste - wystarczy włączyć podgląd

logów systemowych ( tail -f /var/log/

syslog lub tail -f /var/log/messagess )

i podłączyć/odłączyć kartę. Ten sam test mo-

żemy przeprowadzić z samym kablem.

Warto również pamiętać, że nieoczeki-

wane problemy z koniguracją interfejsów

sieciowych mogą również brać się z błędów

w działaniu właśnie tych programów, dlate-

go warto zaglądać do logów systemowych.

Podczas podłączania i odłączania karty sie-

ciowej może się również uaktywniać jakiś in-

ny daemon systemowy, jak np. Avahi - nie na-

leży się tego obawiać - program ten absolut-

nie nie przeszkadza w automatycznej koni-

guracji kart.

W większości pozostałych dystrybucji

domyślnie instalowany jest program ifplugd ,

który pełni identyczne funkcje, jednak jest

nieco bardziej rozbudowany. Oczywiście nie

ma żadnych przeszkód, aby używać ifplugd

również w Fedora Core - gotowe pakiety są ła-

two dostępne.

Koniguracja tego programu znajduje się

w pliku /etc/default/ifplugd ( Debian oraz Ubun-

tu ) lub /etc/ifplugd/ifplugd.conf (m.in. Mandri-

va ). W tym pliku powinniśmy w linii zaczy-

nającej się od INTERFACES= podać nazwy

wszystkich naszych interfejsów sieciowych,

oddzielone spacjami (np. „ eth0 eth1 eth5 ”).

W nowszych wersjach programu możemy

alternatywnie posłużyć się linią HOTPLUG_

INTERFACES="all" , aby monitorować wszel-

kie interfejsy, które pojawiają się w czasie pra-

cy systemu. W pliku tym możemy podać rów-

nież różne inne opcje programu, których peł-

ną listę znajdziemy w man ifplugd , np. dla

kart PCMCIA użyteczna bywa opcja -M .

Zarówno netplug, jak i ifplugd teoretycz-

nie powinny wykrywać nie tyle samo włoże-

nie karty sieciowej ale moment podpięcia ka-

bla sieciowego. W efekcie interfejs sieciowy

Dodatkowe ustawienia karty

Najpopularniejsze obecnie karty sieciowe

używają kabli UTP i mogą pracować w stan-

dardzie 100BASE-TX lub 10Base-T, dodat-

kowo z wykorzystaniem lub nie tzw. pełne-

go dupleksu (czyli równoczesnego wysyła-

nia i odbierania, ang. full-duplex ). Standar-

dem jest oczywiście dziś prędkość 100 mega-

bitów przy pełnym dupleksie, jednak w wie-

lu sieciach używa się nadal wolniejszego

sprzętu. Wybór parametrów transmisji od-

bywa się w drodze „negocjacji” pomiędzy

urządzeniami sieciowymi, która jest nieza-

leżna od systemów operacyjnych czy sterow-

ników i w sprawnie działającej sieci nigdy

nie ma potrzeby forsowania innych para-

metrów, niż te ustalone przez same urządze-

nia. Jeśli w naszej sieci auto-negocjacja poda-

je w efekcie parametry inne, niż oczekiwa-

libyśmy, należy przede wszystkim usunąć

przyczynę problemów w warstwie sprzęto-

wej. Warto jednak wiedzieć, że istnieje moż-

liwość „wymuszenia” konkretnych parame-

www.lpmagazine.org

sprzęt

Sieci ethernet

Programowy watchdog

Watchdog czyli w tłumaczeniu „pies pilnują-

cy” to nazwa specjalnego urządzenia, mon-

towanego w złączu PCI lub ISA, którego za-

daniem jest zresetowanie komputera, gdy

ten się zawiesi. Niegdyś był to sprzęt dość

popularny w zastosowaniach serwerowych,

jednak popularyzacja Linuksa, który po pro-

stu nie zawiesza się (przynajmniej zanim

sami nie popełnimy jakiegoś błędu w jego

administracji), spowodowała, że producenci

watchdog'ów znacznie zmniejszyli obroty.

Choć w Linuksie obsługiwanych jest kil-

ka sprzętowych watchdog'ów , zamiast kup-

na urządzenia, proponuję wybrać znacznie

tańszą metodę - instalację programowego

watchdog'a czyli pakietu o takiej właśnie

nazwie. Jest on dostępny w wielu dystry-

bucjach, źródła można znaleźć w ftp://

www.ibiblio.org/pub/linux/system/daemons/

watchdog/ .

Co ten program ma wspólnego z sie-

cią? Otóż watchdog , o którym piszę potra-

i nie tylko obserwować kluczowe dla sys-

temu parametry (obciążenie, pamięć, pro-

cesy), ale ma również wbudowaną funk-

cję monitoringu sieci. Możemy go tak za-

programować, aby zrestartował komputer,

lub podjął jakąś inną akcję w momencie,

gdy karta sieciowa przestaje pracować. Ta-

kie działanie może się nam bardzo przydać,

gdy mamy do czynienia z “zawieszającymi”

się kartami sieciowymi, czy switch'ami, co

w warunkach amatorskich sieci kompute-

rowych zdarza się dość często. Jeśli więc

z powodu jakichś usterek zdarza nam się

konieczność restartowania np. serwera do-

stępowego sieci na Linuksie, aby przywró-

cić go do działania, to watchdog jest wła-

śnie dla nas.

Po instalacji programu przy pomo-

cy tradycyjnych poleceń, otwieramy plik

/etc/watchdog.conf . Znajduje się tam wiele

opcji monitoringu różnych parametrów pra-

cy systemu, wśród nich te, związane z sie-

cią. W linii zaczynającej się od “ping=” mo-

żemy określić jakiś adres IP (lub kilka ad-

resów), który będzie monitorowany i gdy

przestanie on być dostępny, watchdog wy-

kona swoje zadanie, którym domyślnie jest

zrestartowanie systemu. Alternatywnie, za-

miast podawać IP, można w linii zaczynają-

cej się od “ interface=” podać interfejs siecio-

wy - program będzie sprawdzał, czy karta

ta odbiera jakieś dane.

Jeśli zależy nam, aby watchdog reago-

wał, gdy karta przestaje wysyłać dane (w

przypadku uszkodzenia w sieci najczęściej

właśnie tak się się dzieje), musimy zmodyi-

kować nieco źródła programu. W jego wer-

sji 2.5.6 w źródłach, w pliku src/iface.c , w li-

nii 62 należy zamienić:

unsigned long bytes = strtoul(line

+ i + strlen(dev->name) + 1, NULL,

10);

unsigned long bytes = strtoul(line

+ i + strlen(dev->name) + 60, NULL,

10);

Program watchdog domyślnie powoduje re-

start systemu, można jednak spowodować,

aby zamiast niego uruchamiał dowolny pro-

gram czy skrypt. Wystarczy tylko jego na-

zwę podać w /etc/watchdog.conf w linii “re-

pair-binary=” . Jeśli podany program po uru-

chomieniu zakończy działanie z wynikiem

zero, system nie zostanie zrestartowany.

Funkcję tę można również użyć do napra-

wy sieci. Najprostsze jej zastosowanie, czy-

li włączenie i wyłączenie sieci, podaję na li-

stingu 2. Do przedstawionego skryptu war-

to by jedynie dopisać sprawdzanie, czy sieć

rzeczywiście zaczęła działać i tylko w takim

przypadku rezygnować z restartu maszyny.

trów pracy karty sieciowej w Linuksie. Choć

należy to raczej traktować jako rozwiązanie

tymczasowe, to w ten sposób możemy czę-

sto przywrócić sieć do działania, albo popra-

wić jej stabilność.

Zmiany parametrów pracy karty siecio-

wej można dokonać w Linuksie na trzy sposo-

by - możemy wpisać odpowiednią opcję mo-

dułu jądra, obsługującego naszą kartę siecio-

wą, albo użyć dostępnego w większości dys-

trybucji programu ethtool , albo też zainstalo-

wać często skuteczniejszy programik mii-tool .

W przypadku niektórych kart sieciowych za-

działają wszystkie trzy metody, dla większości

skuteczne okażą się przynajmniej ze dwie, ale

nie wykluczam że istnieją karty, które w ogóle

tego nie umożliwiają.

Dokonanie tej zmiany przy pomocy od-

powiednich parametrów modułów jądra jest

stosunkowo najbardziej skomplikowane.

Musimy bowiem znaleźć gdzieś, np. w inter-

necie lub w dokumentacji jądra (w jego źró-

dłach, w katalogu Documentation/networking/ )

przykłady parametrów dla danego modu-

łu, które powodują wyłączenie „autonego-

cjacji” i „sztywne” określenie typu medium.

Następnie odpowiednią linię należy dopisać

do któregoś z plików w /etc/modprobe.d/ . Na

przykład linia options 8139too media=0x0030

spowoduje, że karta obsługiwana przez mo-

duł 8139too (irmy RTL) będzie ustawiona

w tryb pełnego dupleksu przy 100 megabit

(a np. 0x0010 to 10Mbit, full-duplex ); linia

options 3c59x options=0x4000,0x4000 ustawi

obydwie karty irmy 3Com obecne w syste-

mie na pracę z 10Base-T . Potrzebne parametry

dla danego modułu możemy też znaleźć przy

pomocy komendy modinfo , jednak zrozu-

mienie jej wydruku często wymaga obycia

w programowaniu.

Posłużenie się programem ethtool jest

znacznie prostsze. Ogólna składnia jest nastę-

pująca:

formacji można oczywiście znaleźć w man

ethtool . Po wydaniu danej komendy moż-

na sprawdzić przy pomocy polecenia dmesg

czy jądro nie zgłosiło błędu (niektóre sterow-

niki mogą nie „zrozumieć” polecenia ethto-

ol , co powinno zostać odnotowane), następ-

nie poleceniem ethtool [nazwa_interfej-

su] możemy sprawdzić, czy parametry kar-

ty zmieniły się.

W przypadku wielu kart, lepiej od eth-

tool działać będzie programik mii-tool . Je-

go składnia jest inna - na przykład mii-tool

-F 10baseT-HD eth0 ustawi 10base-T i half du-

plex, a mii-tool -F 100baseTx-FD eth0 usta-

wi oczywiście 100base-TX i pełny dupleks.

Więcej informacji znajdziemy oczywiście

w man mii-tool .

Program ten wyróżnia się dwoma moim

zdaniem bardzo użytecznymi funkcjami, któ-

rych brak w ethtool . Mianowicie przy pomocy

opcji -R możemy zresetować całkowicie kartę

(zachowa się tak, jakby właśnie dopiero do-

stała zasilanie), natomiast opcją -r wymusza-

my przeprowadzenie ponownej autonegocja-

cji. W przypadku problemów z uszkodzo-

ethtool -s [nazwa interfejsu]

[speed 10|100|1000]

[duplex half|full].

A więc na przykład ethtool -s eth6 speed

10 duplex full autoneg off . Więcej in-

listopad 2006

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: