Linux Certif

Toute la documentation sur la certification Linux LPI

ip

NAZWA

ip - implementacja protoko³u IPv4 dla systemu Linux

SK£ADNIA

#include <sys/socket.h>
#include <netinet/in.h>

tcp_socket = socket(PF_INET, SOCK_STREAM, 0);
raw_socket = socket(PF_INET, SOCK_RAW, protokó³);
udp_socket = socket(PF_INET, SOCK_DGRAM, protokó³);

OPIS

Linux implementuje protokó³ IPv4 opisany w RFC791 i RFC1122. ip zawiera 2. poziom implementacji adresowania grupowego (multicasting) zgodny z RFC1112. Zawiera te¿ router IP w³±czaj±c w to filtr pakietów.

Protokó³ jest obs³ugiwany w j±drze i bazuje na zgodnym z BSD interfejsie gniazd. Wiêcej informacji na temat gniazd mo¿na znale¼æ przegl±daj±c socket(7).

Gniazdo IP jest tworzone poprzez wywo³anie funkcji socket(2) jako socket(PF_INET, rodzaj_gniazda, protokó³). Poprawne typy gniazd to SOCK_STREAM s³u¿±ce do tworzenia gniazd po¶rednicz±cych w obs³udze protoko³u tcp(7), tak¿e SOCK_DGRAM obs³uguj±ce protokó³ udp(7), a nawet SOCK_RAW pozwalaj±ce tworzyæ gniazda raw(7) (surowe) umo¿liwiaj±ce bezpo¶redni dostêp do protoko³u IP. protokó³ jest protoko³em bazuj±cym na IP. Informacja o nim jest umieszczana w nag³ówku wysy³anego b±d¼ odbieranego pakietu IP. Dla gniazd TCP poprawnymi warto¶ciami s± tylko 0 i IPPROTO_TCP, a dla gniazd UDP - 0 i IPPROTO_UDP. Dla SOCK_RAW mo¿na podaæ dowolny prawid³owy numer protoko³u IP okre¶lony przez IANA w RFC1700.

Kiedy proces chce odbieraæ nowe, nadchodz±ce pakiety lub po³±czenia, powinien pod³±czyæ gniazdo do adresu lokalnego interfejsu za pomoc± funkcji bind(2). Do dowolnej lokalnej pary (adres, port) mo¿na pod³±czyæ tylko jedno gniazdo IP. Gdy w wywo³aniu bind podana jest warto¶æ INADDR_ANY , to gniazdo zostanie dowi±zane do wszystkich lokalnych interfejsów sieciowych. Gdy dla niedowi±zanego gniazda zostanie wywo³ane listen(2) lub connect(2), gniazdo to zostanie automatycznie dowi±zane do losowo wybranego wolnego portu, przy czym adres lokalny zostanie ustawiony na INADDR_ANY.

Przypisywanie (czêsto w literaturze: "nazywanie") lokalnego gniazda TCP jest niemo¿liwe przez pewien okres czasu po jego zamkniêciu, chyba ¿e zostanie dla tego gniazda ustawiony atrybut SO_REUSEADDR. Nale¿y u¿ywaæ tego atrybutu z rozwag±, gdy¿ czyni on TCP mniej niezawodnym.

FORMAT ADRESU

Adres gniazda IP jest przedstawiony za pomoc± kombinacji adresu interfejsu IP i numeru portu. Podstawowy protokó³ IP nie zawiera numerów portów, s± one zaimplementowane w protoko³ach wy¿szej warstwy, takich jak udp(7) i tcp(7). Dla gniazd surowych sin_port jest ustawione na protokó³ IP. Taki fragment okre¶laj±cy po³owê danych potrzebnych do zachodzenia po³±czenia okre¶la siê te¿ mianem pó³asocjacji.

struct sockaddr_in {

    sa_family_t    sin_family; /* rodzina adresów AF_INET */

    u_int16_t      sin_port;   /* port - sieciowa kolejno¶æ bajtów */

    struct in_addr  sin_addr;  /* adres internetowy */

};



/* Adres internetowy */

struct in_addr {

    u_int32_t      s_addr; /* adres IPv4 - sieciowa kolejno¶æ bajtów */

};

sin_family ma zawsze warto¶æ AF_INET. Jest to wymagane; w Linuksie 2.2 wiêkszo¶æ funkcji sieciowych zwraca EINVAL je¶li brakuje tego ustawienia. sin_port zawiera numer portu podany w sieciowej kolejno¶ci bajtów. Numery portów ni¿sze ni¿ 1024 nazywamy portami zarezerwowanymi. Tylko procesy z efektywnym identyfikatorem u¿ytkownika równym 0 lub z ustawionym atrybutem CAP_NET_BIND_SERVICE mog± wywo³aæ bind(2) dla tego rodzaju gniazd. Nale¿y zauwa¿yæ, ¿e surowy protokó³ IPv4 jako taki nie zawiera pojêcia portu (takie rozró¿nienie jest dopiero w warstwie transportowej, a to jest warstwa sieciowa). Numery portów pozwalaj±ce identyfikowaæ ju¿ konkretne procesy na odleg³ej maszynie wystêpuj± dopiero w protoko³ach wy¿szej warstwy, takich jak tcp(4) i udp(4).

sin_addr to adres IP hosta (maszyny). Pole addr struktury struct in_addr zawiera adres interfejsu maszyny w sieciowej kolejno¶ci bajtów. in_addr powinien byæ modyfikowany tylko przy u¿yciu funkcji bibliotecznych inet_aton(3), inet_addr(3), inet_makeaddr(3) lub bezpo¶rednio przez resolvera (patrz te¿ gethostbyname(3)). Adresy IPv4 dzielimy na pojedyncze (unicast), rozg³oszeniowe (broadcast) i grupowe (multicast). Adresy pojedyncze okre¶laj± nam pojedynczy interfejs maszyny, adresy rozg³oszeniowe okre¶laj± wszystkie maszyny w obrêbie jakiej¶ sieci (podsieci), a adresy grupowe wszystkie maszyny w obrêbie jakiej¶ grupy odbiorców. Datagramy kierowane do adresów rozg³oszeniowych trafiaj± do odbiorcy tylko wtedy, gdy jego gniazdo ma ustawiony atrybut rozg³oszenia SO_BROADCAST. Ten sam atrybut musi byæ te¿ ustawiony, gdy zachodzi potrzeba wys³ania datagramów rozg³oszenia. W aktualnej implementacji gniazda po³±czeniowe mog± u¿ywaæ wy³±cznie adresów pojedynczych.

Nale¿y zauwa¿yæ, ¿e dla adresu i portu zawsze jest u¿ywana sieciowa kolejno¶æ bajtów. W szczególno¶ci, oznacza to, ¿e trzeba u¿ywaæ funkcji htons(3) dla numeru przypisanego do portu. Wszystkie funkcje standardowej biblioteki manipuluj±ce adresem/portem automatycznie przekszta³caj± podan± warto¶æ na jej sieciow± reprezentacjê.

Istnieje kilka adresów specjalnych: INADDR_LOOPBACK (127.0.0.1) zawsze odnosi siê do lokalnego hosta poprzez urz±dzenie loopback; INADDR_ANY (0.0.0.0) oznacza przy dowi±zywaniu dowolny adres; INADDR_BROADCAST (255.255.255.255) oznacza dowolny host i ze wzglêdów historycznych zachowuje siê przy dowi±zywaniu tak samo jak INADDR_ANY.

OPCJE GNIAZD

IP wspiera niektóre opcje specyficzne dla protoko³u, które mog± byæ ustawione przy u¿yciu setsockopt(2) i odczytane z pomoc± getsockopt(2). Poziom opcji gniazda dla IP to SOL_IP. Dla ka¿dego ze znaczników logicznych warto¶æ ca³kowita zero oznacza fa³sz, a ka¿da inna - prawdê.

IP_OPTIONS

Ustawia lub pobiera opcje IP, które bêd± wysy³ane z ka¿dym pakietem z danego gniazda. Argumenty s± wska¼nikiem do bufora pamiêci zawieraj±cego opcje i ich d³ugo¶ci. setsockopt(2) ustawia opcje IP skojarzone z gniazdem. Maksymalny rozmiar opcji dla IPv4 to 40 bajtów. Zobacz RFC791 by poznaæ mo¿liwe opcje. Gdy pakiet wstêpnego potwierdzenia po³±czenia (ACK) dla gniazda typu SOCK_STREAM zawiera opcje IP, to opcje wychodz±cego pakietu IP bêd± automatycznie pobrane z opcji IP pobranego pakietu z odwróconymi nag³ówkami mówi±cymi o trasie. Wobec tego, wychodz±ce pakiety bêd± wtedy zawieraæ lustrzane odbicia odbieranych opcji. Po ustanowieniu po³±czenia przychodz±ce pakiety nie s± uprawnione do zmiany swoich opcji. Przetwarzanie wszystkich przychodz±cych opcji ¼ród³a mo¿e byæ wy³±czone przy pomocy kontrolki systemowej accept_source_route, domy¶lnie wy³±czonej. W przypadku gniazd datagramowych opcje IP mog± byæ ustawione jedynie przez u¿ytkownika lokalnego. Funkcja getsockopt(2) z argumentem IP_OPTIONS zwróci obecnie wys³ane opcje poprzez umieszczenie ich w dostarczonym buforze.

IP_PKTINFO

Przekazuje pomocniczy komuniakt IP_PKTINFO zawieraj±cy strukturê pktinfo dostarczaj±c± trochê informacji o przychodz±cym pakiecie. Dzia³a to jedynie dla gniazd datagramowych. Argument jest znacznikiem mówi±cym gniazdu, czy nale¿y przekazaæ komunikat IP_PKTINFO, czy te¿ nie. Sam komunikat mo¿e zostaæ przes³any/otrzymany wraz zpakietem jedynie jako komunikat steruj±cy za pomoc± recvmsg(2) lub sendmsg(2).

struct in_pktinfo {

    unsigned int   ipi_ifindex;  /* Indeks interfejsu */

    struct in_addr ipi_spec_dst; /* Adres lokalny */

    struct in_addr ipi_addr;     /* Nag³ówek adresu docelowego */

};

ipi_ifindex jest indeksem interfejsu, przez który pakiet zosta³ odebrany. Adres ipi_spec_dst jest lokalnym adresem pakietu, a ipi_addr jest adresem docelowym wynikaj±cym z nag³ówka pakietu. Je¶li IP_PKTINFO jest przekazane do sendmsg(2) a ipi_spec_dst ma warto¶æ niezerow±, to IP_PKTINFO zostanie u¿yte jako ¼ród³owy adres lokalny podczas przeszukiwania tablicy routingu i dla ustawienia opcji routingu wg adresu ¼ród³owego. Gdy ipi_ifindex ma warto¶æ niezerow±, to podstawowy adres lokalny interfejsu wskazywanego przez ten indeks nadpisuje ipi_spec_dst podczas przeszukiwania tablicy routingu.

IP_RECVTOS

Je¶li jest ustawione, to pomocniczy komunikat IP_TOS jest przepuszczany razem z nadchodz±cymi pakietami. Zawiera on bajt, który okre¶la pole zdefiniowane tak¿e jako bajt znajduj±ce siê w nag³ówku pakietu, a zwane Typ Us³ugi/Pierwszeñstwa. Wymaga logicznego znacznika w postaci liczby ca³kowitej.

IP_RECVTTL

Gdy ten znacznik jest ustawiony, przepuszczny jest komuniakat pomocniczy IP_RECVTTL, zawieraj±cy pole okre¶lane mianem "czas ¿ycia" odbieranego pakietu w postaci bajtu. Nie jest to wspierane w przypadku strumieniowych gniazd typu SOCK_STREAM.

IP_RECVOPTS

Przekauje u¿ytkownikowi wszystkie nadchodz±ce opcje IP z komunikatu steruj±cego IP_OPTIONS Nag³ówek wyboru trasy i inne opcje s± ju¿ wstêpnie wype³nione informacjami o lokalnej maszynie. Nie stosuje siê w przypadku gniazd typu SOCK_STREAM.

IP_RETOPTS

Dzia³anie identyczne do IP_RECVOPTS ale zwraca surowe, nieprzetworzone opcje w³±cznie z rekordem opcji mówi±cym o znaczniku czasowym i trasie, nie wype³nionym warto¶ciami w tym przej¶ciu pakietu.

IP_TOS

Ustawia lub pobiera pole znacznika Typ-Us³ugi (ang. Type-Of-Service - w skrócie TOS), które jest przesy³ane z ka¿dym pakietem IP pochodz±cym z danego gniazda. S³u¿y do ustalenia priorytetów pakietów w sieci. TOS jest bajtem. Oto definicje niektórych standardowych znaczników TOS: IPTOS_LOWDELAY minimalizacja opó¼nienia we wzajemnym ruchu, IPTOS_THROUGHPUT optymalizacja wyj¶cia, IPTOS_RELIABILITY optymalizacja pod k±tem niezawodno¶ci, IPTOS_MINCOST powinna byæ u¿ywana jako "dane wype³niaj±ce" tam, gdzie szybko¶æ transmisji nie ma wiêkszego znaczenia. Mo¿na podaæ najwy¿ej jedn± z powy¿szych warto¶ci TOS. Inne bity s± niepoprawne i powinny byæ wyzerowane. Linux domy¶lnie wysy³a najpierw datagram IPTOS_LOWDELAY ale dok³adne zachowanie zale¿y od konfiguracji w³a¶ciwo¶ci szeregowania. Niektóre poziomy o wysokim priorytecie mog± wymagaæ efektywnego identyfikatora u¿ytkownika 0 lub ustawionego atrybutu CAP_NET_ADMIN. Priorytet mo¿na te¿ ustawiæ w sposób niezale¿ny od protoko³u poprzez opcjê gniazda (SOL_SOCKET, SO_PRIORITY) (patrz te¿ socket(7)).

IP_TTL

Ustawia lub pobiera pole "czas ¿ycia" (ang. Time-To-Live, w skrócie TTL) dla ka¿dego wychodz±cego z danego gniazda pakietu IP.

IP_HDRINCL

Je¶li w³±czone to dopuszczalne jest tworzenie przez u¿ytkownika w³asnego nag³ówka IP przed danymi u¿ytkownika. Dzia³a to jedynie dla gniazd SOCK_RAW. Obejrzyj te¿ raw(7) by uzyskaæ wiêcej informacji. Gdy ten znacznik jest w³±czony, to warto¶ci ustawiane przez IP_OPTIONS, IP_TTL i IP_TOS s± ignorowane.

IP_RECVERR (zdefiniowane w <linux/errqueue.h>)

W³±cza zwiêkszon± pewno¶æ przy realizowaniu zawiadomieñ o b³êdach. Gdy jest to ustawione w gnie¼dzie datagramowym to wszystkie generowane b³êdy bêd± zapamiêtane w specjalnej, przypisanej do gniazda, kolejce b³êdów. Gdy u¿ytkownik (proces u¿ytkownika) otrzyma b³±d (poprzez zwrócony kod b³êdu operacji na gnie¼dzie) to b³êdy mog± byæ odebrane przy u¿yciu funkcji recvmsg(2) z ustawionym znacznikiem MSG_ERRQUEUE. Struktura opisuj±ca b³±d sock_extended_err zostanie przekazana w pomocniczym komuniakcie o typie IP_RECVERR i poziomie SOL_IP. Jest to niezwykle pomocne przy niezawodnym przechwytywaniu b³êdów niepo³±czonych gniazd. Odbierana z kolejki b³êdów porcja danych zawiera pakiet z informacj± o b³êdzie.

Komunikat steruj±cy IP_RECVERR zawiera strukturê sock_extended_err zdefiniowan± nastêpuj±co:

#define SO_EE_ORIGIN_NONE       0

#define SO_EE_ORIGIN_LOCAL      1

#define SO_EE_ORIGIN_ICMP       2

#define SO_EE_ORIGIN_ICMP6      3



struct sock_extended_err {

    u_int32_t       ee_errno;   /* numer b³êdu */

    u_int8_t        ee_origin;  /* ¼ród³o b³êdu */

    u_int8_t        ee_type;    /* typ */

    u_int8_t        ee_code;    /* kod */

    u_int8_t        ee_pad;

    u_int32_t       ee_info;    /* informacje dodatkowe */

    u_int32_t       ee_data;    /* inne dane */

    /* Dalej mog± wyst±piæ dodatkowe dane */

};



struct sockaddr *SO_EE_OFFENDER(struct sock_extended_err *);

ee_errno zawiera numer errno b³êdu kolejki. ee_origin jest kodem miejsca pochodzenia b³êdu. Pozosta³e pola s± zale¿ne od protoko³u. Makro SO_EE_OFFENDER zwraca wska¼nik do adresu obiektu sieciowego, z którego pochodzi³ b³±d o zadanym wska¼niku do komunikatu pomocniczego. Gdy ten adres nie jest znany, pole sa_family struktury sockaddr zawiera warto¶æ AF_UNSPEC a pozosta³e pola tej struktury s± sockaddr niezdefiniowane.

IP u¿ywa struktury sock_extended_err w nastêpuj±cy sposób: ee_origin ustawione na SO_EE_ORIGIN_ICMP dla b³êdów odbieranych jako pakiet ICMP, albo te¿ SO_EE_ORIGIN_LOCAL dla b³êdów generowanych lokalnie. Nieznane warto¶ci nale¿y ignorowaæ. ee_type i ee_code s± ustawiane zgodnie z typem i kodem pól w nag³ówku ICMP. ee_info zawiera rozpoznan± warto¶æ MTU dla b³êdów EMSGSIZE. Komunikat zawiera równie¿ sockaddr_in wêz³a, który spowodowa³ b³±d, a do którego mo¿na uzyskaæ dostêp za pomoc± makra SO_EE_OFFENDER. Pole sin_family adresu SO_EE_OFFENDER ma warto¶æ AF_UNSPEC, gdy ¼ród³o b³êdu nie jest znane. Gdy b³±d pochodzi z sieci, wszystkie opcje IP (IP_OPTIONS, IP_TTL, itd.) w³±czone w gnie¼dzie i zawarte w pakiecie b³êdu s± przekazywane jako komunikaty kontrolne. W³a¶ciwe dane pakietu, który spowodowa³ b³±d s± zwracane jako normalne dane. Nale¿y zauwa¿yæ, ¿e TCP nie ma kolejki b³êdów; MSG_ERRQUEUE jest niedozwolone w przypadku gniazd SOCK_STREAM. Wszystkie b³êdy s± przekazywane poprzez zwracan± warto¶æ funkcji albo SO_ERROR.

Dla gniazd surowych, IP_RECVERR w³±cza przepuszczanie do aplikacji wszystkich odebranych komunikatów ICMP o b³êdach, w przeciwnym przypadku b³êdy s± zg³aszane tylko dla gniazd po³±czonych.

Mamy tu do czynienia ze znacznikiem logicznym zapisanym za pomoc± liczby ca³kowitej IP_RECVERR domy¶lnie wy³±czonym.

IP_MTU_DISCOVER

Ustawia lub pobiera opcjê badania MTU ¶cie¿ki (ang. Path MTU Discovery) dla gniazda. Gdy opcja ta jest w³±czona, to Linux bêdzie przeprowadza³ badanie MTU scie¿ki dla tego gniazda zgodnie z definicj± zawart± w RFC1191. Znacznik zakazu fragmentacji jest ustawiany we wszystkich pakietach wychodz±cych. Ogólne, domy¶lne zachowanie okre¶lone dla danego systemu jest ustawiane przez "kontrolkê systemow±" ip_no_pmtu_disc dla gniazd typu SOCK_STREAM i wy³±czone dla wszystkich innych typów gniazd. W przypadku gniazd innych ni¿ SOCK_STREAM za odpowiednie, zgodne z warto¶ci± MTU, spakietowanie danych i za wykonanie ewentualnych retransmisji jest odpowiedzialny program u¿ytkownika. J±dro odrzuci pakiety wiêksze ni¿ znane MTU ¶cie¿ki gdy ten znacznik jest ustawiony (³±cznie z EMSGSIZE ).

Znaczniki badania MTU ¶cie¿ki	Znaczenia
IP_PMTUDISC_WANT	U¿ywaj ustawieñ zale¿nych od trasy
IP_PMTUDISC_DONT	Nie badaj MTU ¶cie¿ki
IP_PMTUDISC_DO	Zawsze badaj MTU ¶cie¿ki

Gdy w³±czone jest badanie MTU ¶cie¿ki, j±dro automatycznie namierza warto¶ci MTU ¶cie¿ki dla ka¿dego hosta docelowego. Gdy aktywne jest po³±czenie z danym hostem, mo¿na wygodnie odczytaæ aktualnie rozpoznan± warto¶æ MTU ¶cie¿ki za pomoc± connect(2) u¿ywaj±c opcji gniazda IP_MTU (np. po wyst±pieniu b³êdu EMSGSIZE ). Mo¿e ona siê zmieniaæ z czasem. Dla gniazd bezpo³±czeniowych z wieloma hostami docelowymi, MTU dla danego, równie¿ nowego, hosta docelowego mo¿na uzyskaæ za pomoc± kolejki b³êdów (zobacz IP_RECVERR). Po nadej¶ciu ka¿dej aktualizacji MTU zostanie skolejkowany nowy b³±d.

W trakcie rozpoznawania MTU, pakiety inicjuj±ce z gniazd datagramowych mog± zostaæ porzucone. Programy korzystaj±ce z UDP powinny byæ tego ¶wiadome i nie braæ tego pod uwagê w swojej strategii retransmisji pakietów.

Aby zanicjowaæ proces badania MTU ¶cie¿ki dla gniazd niepo³±czonych mo¿na rozpocz±æ z du¿ym rozmiarem datagramu (do 64K-nag³ówek bajtów) i pozwoliæ na jego zmniejszenie w wyniku aktualizacji MTU ¶cie¿ki.

Aby oszacowaæ inicjalne MTU ¶cie¿ki, nale¿y pod³±czyæ gniazdo datagramowe do adresu docelowego za pomoc± connect(2) i pobraæ MTU wo³aj±c getsockopt(2) z opcj± IP_MTU.

IP_MTU

Pobiera znan± aktualnie warto¶æ MTU ¶cie¿ki obecnego gniazda. Jest to poprawne tylko, gdy gniazdo zosta³o po³±czone. Zwraca liczbê ca³kowit±. Dzia³a tylko z getsockopt(2).

IP_ROUTER_ALERT

Przekazuje wszystkie pakiety z opcj± Alarmu Rutera IP, które mia³yby byæ przekazywane (ang. forwarded) do tego gniazda. Dzia³a tylko dla gniazd surowych. Jest to przydatne na przyk³ad dla demonów RSVP dzia³aj±cych w przestrzeni u¿ytkownika. Wykorzystane pakiety nie s± przekazywane (ang. forwarded) przez j±dro. Ponowne ich wys³anie nale¿y do obowi±zków programu u¿ytkownika. Dowi±zywanie gniazda jest w tym przypadku ignorowane, pakiety te s± filtrowane jedynie w oparciu o protokó³. Wymaga liczby ca³kowitej jako argumentu.

IP_MULTICAST_TTL

Ustawia lub pobiera warto¶æ czas-¿ycia-pakietu dla wychodz±cych z tego gniazda pakietów grupowych. Jest bardzo istotnym w przypadku adresowania grupowego by ustawiæ najmniejsz± mo¿liw± warto¶æ TTL. Domy¶lnie jest to 1, co oznacza, ¿e pakiety grupowe nie opuszczaj± sieci lokalnej, chyba ¿e program u¿ytkownika wyra¼nie tego ¿±da. Argument jest liczb± ca³kowit±.

IP_MULTICAST_LOOP

Ustawia lub pobiera logiczny argument typu ca³kowitego, mówi±cy o tym, czy przesy³ane pakiety grupowe powinny wracaæ do lokalnego gniazda.

IP_ADD_MEMBERSHIP

Przy³±cza grupê adresów. Argumentem jest struktura struct ip_mreqn .

struct ip_mreqn {

    struct in_addr imr_multiaddr; /* grupowy adres IP */

    struct in_addr imr_address;   /* adres IP interfejsu lokalnego */

    int                           imr_ifindex;/* indeks nnterfejsu */

};

imr_multiaddr zawiera adres grupy, któr± aplikacja chce pod³±czyæ lub roz³±czyæ. Musi byæ to poprawny adres grupowy (multicast). imr_address jest to adres lokalnego interfejsu, przez który system powinien po³±czyæ grupê; je¶li jest równy INADDR_ANY, to odpowiedni interfejs jest wybierany przez system. imr_ifindex jest indeksem interfejsu, który powinien byæ pod³±czony/od³±czony do obs³ugi grupy imr_multiaddr lub 0 by wskazaæ na dowolny interfejs.

Dla kompatybilno¶ci stara struktura ip_mreq wci±¿ jest obs³ugiwana. Ró¿ni siê wprawdzie od ip_mreqn lecz tylko tym, ¿e nie zawiera pola imr_ifindex. Dzia³a tylko z setsockopt(2).

IP_DROP_MEMBERSHIP

Od³±cza siê od grupy adresów. Argumentem jest struktura ip_mreqn lub ip_mreq podobna do IP_ADD_MEMBERSHIP.

IP_MULTICAST_IF

Ustawia lokalne urz±dzenie dla gniazda grupowego. Argumentem jest struktura ip_mreqn lub ip_mreq podobna do IP_ADD_MEMBERSHIP.

Gdy podana jest niepoprawna opcja gniazda, to zwracan± warto¶ci± jest ENOPROTOOPT.

SYSCTLS

Protokó³ IP obs³uguje interfejs kontrolek systemowych (sysctl) i korzysta z niego do ustawiania niektórych opcji globalnych. Kontrolki mog± byæ dostêpne przez zapis lub odczyt wykonany na plikach /proc/sys/net/ipv4/* lub poprzez u¿ycie interfejsu w postaci funkcji sysctl(2).

ip_default_ttl

Ustawia domy¶ln± warto¶æ "czasu ¿ycia" (ang. time-to-live) wychodz±cych pakietów. Mo¿e byæ ona zmieniona dla gniazda za pomoc± opcji IP_TTL.

ip_forward

W³±cza przekazywanie (ang. forwarding) pakietów przy u¿yciu logicznego znacznika. Mo¿e byæ ustawione tak¿e na podstawie interfejsu.

ip_dynaddr

W³±cza dynamiczne adresowanie gniazda oraz przepisywanie adresu dla maskowania przy zmianie adresu interfejsu. Jest to bardzo przydatne w przypadku korzystania z interfejsu sprzêgniêtego z lini± telefoniczn±, którego adres IP mo¿e siê zmieniaæ. 0 oznacza brak przepisywania, 1 w³±cza przepisywanie a 2 w³±cza tryb rozwlek³y (ang. verbose).

ip_autoconfig

Nie udokumentowane.

ip_local_port_range

Zawiera dwie liczby ca³kowite, które definiuj± lokalny zakres portów przydzielanych gniazdom. Przydzielanie zaczyna siê od pierwszej podanej warto¶ci i koñczy na drugiej. Nale¿y zauwa¿yæ, ¿e zakres ten nie powinien pokrywaæ siê z zakresem portów wykorzystywanym do maskowania (chocia¿ taka sytuacja jest obs³ugiwana). Dowolny wybór mo¿e równie¿ powodowaæ problemy z niektórymi firewalami, które robi± pewne za³o¿enia odno¶nie portów u¿ywanych lokalnie. Pierwsza liczba powinna byæ co najmniej >1024, a lepiej >4096, aby unikn±æ konfliktów z dobrze znanymi portami i zminimalizowaæ problemy z firewalami.

ip_no_pmtu_disc

Je¶li jest to w³±czone to domy¶lnie nie bêdzie wykonywane badanie MTU ¶cie¿ki dla gniazd TCP. Badanie MTU mo¿e siê nie sprawdzaæ w przypadku ¼le skonfigurowanych firewali (odrzucaj±cych wszelkie pakiety ICMP) lub ¼le skonfigurowanych interfejsów (np. po³±czenie typu point-to-point, gdzie oba koñce nie zgadzaj± siê na MTU). Lepiej poprawiæ wszelkie wadliwie skonfigurowane rutery po drodze ni¿ ca³kowicie wy³±czyæ badanie MTU ¶cie¿ki, poniewa¿ nie wykonywanie tej operacji poci±ga za sob± du¿e straty w obrêbie sieci.

ipfrag_high_thresh, ipfrag_low_thresh

Je¶li liczba zebranych w kolejce fragmentów IP osi±gnie warto¶æ okre¶lon± przez ipfrag_high_thresh, wtedy kolejka jest opró¿niana do ilo¶ci okre¶lonej w ipfrag_low_thresh. Zawiera ona liczbê ca³kowit± z podan± liczb± bajtów.

ip_always_defrag

[Nowa w j±drze 2.2.13; we wcza¶niejszych wersjach j±dra funkcj± t± sterowa³o siê w czasie kompilacji za pomoc± opcji CONFIG_IP_ALWAYS_DEFRAG]

Gdy ten znacznik logiczny jest w³±czony (ró¿ny od 0) przychodz±ce fragmenty (czê¶ci pakietów IP, które siê pojawiaj±, gdy pewien host pomiêdzy hostem ¼ród³owym a docelowym zdecyduje, ¿e pakiety by³y za du¿e i podzieli je na kawa³ki) bêd± ponownie z³o¿one (zdefragmentowane) przed ich przetworzeniem, nawet je¶li maj± byæ przekazane dalej (and. forwarded).

Nale¿y w³±czaæ jedynie przy dzia³aj±cym firewalu stanowi±cym g³ówne wej¶cie do danej sieci lub dzia³aj±cym przezroczystym proxy; nigdy nie nale¿y tego w³±czaæ na zwyk³ym routerze lub hoscie. W przeciwnym przypadku ³±czno¶æ mo¿e zostaæ zak³ócona, gdy fragmenty bêd± podró¿owaæ innymi ³±czami. Defragmentacja powoduje równie¿ znaczne wykorzystanie pamiêci i czasu procesora.

Jest to w³±czane automagicznie, gdy skonfihurowane jest maskowanie lub przezroczyste proxy.

neigh/*

See arp(7).

IOCTLS

Te kontrolki wej¶cia/wyj¶cia s± dostêpne poprzez u¿ycie ioctl(2). Wszystkie dotycz±ce IP zosta³y opisane w socket(4).

Kontrolki wej¶cia/wyj¶cia dotycz±ce ustawieñ firewala s± udokumentowane w ipfw(7) z pakietu ipchains.

Kontrolki wej¶cia/wyj¶cia u¿ywane do konfigurowania podstawowych parametrów urz±dzeñ opisane s± w netdevice(7).

UWAGI

Nale¿y byæ bardzo ostro¿nym przy stosowaniu opcji SO_BROADCAST - nie jest ona w systemie Linux uprzywilejowana, jest wiêc ³atwo przeci±¿yæ sieæ za pomoc± niedbale u¿ytych rozg³oszeñ. W przypadku protoko³ów nowych aplikacji lepiej u¿ywaæ grupy adresowej zamiast rozg³oszeñ. Stosowanie adresów rozg³oszeniowych jest nieostro¿no¶ci±.

Niektóre inne implementacje gniazd BSD dopuszczaj± dla gniazd opcje IP_RCVDSTADDR i IP_RECVIF u¿ywane do pobierania adresu przeznaczenia i interfejsu odbieranych datagramów. Linux posiada bardziej ogóln± opcjê IP_PKTINFO robi±c± to samo.

B£ÊDY

ENOTCONN

Operacja mo¿e byæ wykonana tylko na po³±czonym gnie¼dzie, a gniazdo nie zosta³o po³±czone.

EINVAL

Przypisano niew³a¶ciwy argument. W przypadku operacji wysy³ania mo¿e to byæ spowodowane przez wysy³anie drog± przypisan± do czarnej dziury .

EMSGSIZE

Datagram jest wiêkszy ni¿ warto¶æ MTU po drodze do celu i nie mo¿e byæ podzielony.

EACCES

U¿ytkownik próbowa³ wykonaæ operacjê nie maj±c potrzebnych praw. Obejmuje to: Wysy³anie pakietu na adres rozg³oszeniowy bez ustawionego znacznika SO_BROADCAST. Wysy³anie pakietu zakazan± drog±. Próbê modyfikacji ustawieñ firewala bez efektywnego identyfikatora u¿ytkownika równego 0 lub CAP_NET_ADMIN. Próbê przypisania zarezerwowanego portu bez efektywnego identyfikatora u¿ytkownika równego 0 albo ustawionego znacznika CAP_NET_BIND_SERVICE.

EADDRINUSE

Próbowano przypisaæ port do adresu bêd±cego ju¿ w u¿yciu.

ENOPROTOOPT i EOPNOTSUPP

Przypisano niew³a¶ciw± opcjê gniazda.

EPERM

U¿ytkownik nie ma praw do ustawiania wysokiego priorytetu, zmiany konfiguracji lub wysy³ania sygna³ów do ¿±danych procesów lub grup procesów.

EADDRNOTAVAIL

Za¿±dano nieistniej±cego interfejsu lub ¿±dany adres ¼ród³owy nie jest adresem lokalnym.

EAGAIN

Operacja na gnie¼dzie z wy³±czonym blokowaniem spowodowa³aby zablokowanie.

ESOCKTNOSUPPORT

Gniazdo nie jest skonfigurowane lub za¿±dano nieznanego typu gniazda.

EISCONN

connect(2) by³a wywo³ana na ju¿ po³±czonym gnie¼dzie.

EALREADY

Operacja ³±czenia na gnie¼dzie nieblokuj±cym ju¿ trwa.

ECONNABORTED

Po³±czenie zosta³o zamkniête podczas accept(2).

EPIPE

Po³±czenie zosta³o nieoczekiwanie zamkniête lub wy³±czy³ siê drugi koniec.

ENOENT

SIOCGSTAMP by³o wywo³ane na gnie¼dzie, do którego nie dotar³ ¿aden pakiet.

EHOSTUNREACH

Brak wpisu okre¶laj±cego adres docelowy w tabeli routingu. B³±d ten mo¿e byæ wywo³any przez komunikat ICMP od zdalnego routera lub dla lokalnej tabeli routingu.

ENODEV

Urz±dzenie sieciowe niedostêpne lub niezdolne wysy³aæ pakiety IP.

ENOPKG

Podsystem j±dra nie by³ konfigurowany.

ENOBUFS, ENOMEM

Niewystarczaj±ca ilo¶æ dostêpnej pamiêci. Czêsto oznacza to, ¿e przydzielanie pamiêci jest ograniczone przez ograniczenia bufora gniazda, a nie przez ograniczenia pamiêci systemowej. Jednak nie jest to pewne na 100%.

Inne b³êdy mog± byæ generowane przez protoko³y ni¿szych warstw; obejrzyj tcp(7), raw(7), udp(7) i socket(7).

WERSJE

IP_PKTINFO, IP_MTU, IP_MTU_DISCOVER, IP_PKTINFO, IP_RECVERR i IP_ROUTER_ALERT s± nowymi opcjami w Linuksie 2.2. S± one jednocze¶nie specyficzne dla Linuksa i nie powinny byæ u¿ywane w przeno¶nych programach.

struct ip_mreqn jest nowa w Linuksie 2.2. Linux 2.0 wspiera³ jedynie ip_mreq.

Kontrolki systemowe pojawi³y siê z Linuksem 2.2.

ZGODNO¦Æ

Dla zgodno¶ci z Linuksem 2.0, wci±¿ jest dopuszczalna przestarza³a sk³adnia socket(PF_INET, SOCK_RAW, protocol) by stworzyæ gniazdo typu packet(7). Nie jest to zbyt poprawne i powinno byæ zastêpowane przez socket(PF_PACKET, SOCK_RAW, protocol). G³ównym powodem jest ró¿nica w strukturze adresowej sockaddr_ll przechowuj±cej informacje dla warstwy ³±cza (dok³adniej: warstwy kana³owej), które kiedy¶ przechowywane by³y w sockaddr_pkt.

USTERKI

Jest zbyt wiele nieokre¶lonych warto¶ci b³êdów.

Nie s± opisane kontrolki wej¶cia/wyj¶cia do konfigurowania specyficznych dla IP opcji interfejsu i tabele ARP.

Niektóre wersje glibc zapominaj± zadeklarowaæ in_pktinfo. Mo¿na to aktualnie obej¶æ, kopiuj±c j± do programu z niniejszej strony podrêcznika.

Pobieranie pierwotnego adresu docelowego za pomoc± wywo³ania recvmsg(2) z MSG_ERRQUEUE w msg_name nie dzia³a w niektórych j±drach 2.2.

AUTORZY

Tê stronê podrêcznika napisa³ Andi Kleen. Wyja¶nienia niektórych pojêæ (tylko wersja polska) Pawe³ Wilk.

ZOBACZ TAK¯E

sendmsg(2), recvmsg(2), socket(7), netlink(7), tcp(7), udp(7), raw(7), ipfw(7)

RFC791 zawiera pierwotn± specyfikacjê protoko³u IP.
RFC1122 zawiera wymagania dla hostów IPv4.
RFC1812 zawiera wymagania dla routerów IPv4.