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.