ip

IP(7)                   PodrÄcznik programisty Linuksa                   IP(7)



NAZWA
       ip - Implementacja protokoÅu IPv4 dla systemu Linux

SKÅADNIA
       #include <sys/socket.h>
       #include <netinet/in.h>
       #include <netinet/ip.h> /* nadzbiór poprzedniego */

       tcp_socket = socket(AF_INET, SOCK_STREAM, 0);
       udp_socket = socket(AF_INET, SOCK_DGRAM, 0);
       raw_socket = socket(AF_INET, SOCK_RAW, protokóÅ);

OPIS
       Linux implementuje protokóŠIPv4 opisany w RFC 791 i RFC 1122. ip
       zawiera drugi poziom implementacji adresowania grupowego (multicasting)
       zgodny z RFC 1112. Zawiera też router IP, wÅÄczajÄc w to filtr
       pakietów.

       Interfejs programistyczny jest zgodny z gniazdami BSD. WiÄcej
       informacji na temat gniazd można znaleźÄ, przeglÄdajÄc socket(7).

       Gniazdo IP jest tworzone za pomocÄ socket(2):

           socket(AF_INET, typ_gniazda, protokóÅ);

       Poprawne typy gniazd to: SOCK_STREAM sÅużÄce do tworzenia gniazd
       poÅredniczÄcych w obsÅudze protokoÅu tcp(7), SOCK_DGRAM obsÅugujÄce
       protokóŠudp(7) oraz 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 poprawny numer protokoÅu
       IP okreÅlony przez IANA w RFC 1700.

       Kiedy proces chce odbieraÄ nowe, nadchodzÄce pakiety lub poÅÄczenia,
       powinien podÅÄczyÄ gniazdo do adresu lokalnego interfejsu za pomocÄ
       funkcji bind(2). W takim przypadku do dowolnej lokalnej pary (adres,
       port) można podÅÄczyÄ tylko jedno gniazdo IP. Gdy w wywoÅaniu bind(2)
       podana jest wartoÅÄ INADDR_ANY, to gniazdo zostanie dowiÄzane do
       wszystkich lokalnych interfejsów sieciowych. Gdy do niedowiÄzanego
       gniazda wywoÅywane jest listen(2), to gniazdo zostanie automatycznie
       dowiÄzane do losowo wybranego wolnego portu, przy czym adres lokalny
       zostanie ustawiony na INADDR_ANY. Gdy dla niedowiÄzanego gniazda
       zostanie wywoÅane connect(2), gniazdo to zostanie automatycznie
       dowiÄzane do losowo wybranego wolnego portu lub do używalnego portu
       dzielonego, 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 16-bitowego 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.

           struct sockaddr_in {
               sa_family_t    sin_family; /* rodzina adresów: AF_INET  */
               in_port_t      sin_port;   /* port - sieciowa kolejnoÅÄ bajtów */
               struct in_addr sin_addr;   /* adres internetowy */
           };

           /* Adres internetowy */
           struct in_addr {
               uint32_t     s_addr;     /* adres - 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 sÄ nazywane portami
       uprzywilejowanymi (lub czasem portami zarezerwowanymi). Tylko procesy
       uprzywilejowane (tj. 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 wystÄpujÄ dopiero w protokoÅach wyższej
       warstwy, takich jak tcp(7) i udp(7).

       sin_addr to adres IP komputera (maszyny). Pole s_addr struktury struct
       in_addr zawiera adres interfejsu maszyny w sieciowej kolejnoÅci
       bajtów. Polu in_addr należy albo przypisaÄ jednÄ z wartoÅci INADDR_*
       (np. INADDR_ANY), albo użyÄ funkcji bibliotecznych inet_aton(3),
       inet_addr(3), inet_makeaddr(3) do ustawienia wartoÅci, albo ustawiÄ
       bezpoÅrednio przez resolvera (patrz też gethostbyname(3)).

       Adresy IPv4 dzielimy na pojedyncze (unicast), rozgÅoszeniowe
       (broadcast) i grupowe (multicast). Adresy pojedyncze okreÅlajÄ
       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 obecnej 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 komputer i ze wzglÄdów historycznych
       zachowuje siÄ przy dowiÄzywaniu tak samo, jak INADDR_ANY.

   Opcje gniazda
       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 IPPROTO_IP. Dla każdego
       ze znaczników logicznych wartoÅÄ caÅkowita zero oznacza faÅsz, a
       każda inna - prawdÄ.

       Gdy poda siÄ nieprawidÅowÄ opcjÄ gniazda, getsockopt(2) i setsockopt(2)
       zwrócÄ bÅÄd ENOPROTOOPT.

       IP_ADD_MEMBERSHIP (od Linuksa 1.2)
              PrzyÅÄcza grupÄ adresów. Argumentem jest struktura 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 interfejsu */
                  };

              imr_multiaddr zawiera adres grupy, którÄ aplikacja chce
              podÅÄczyÄ lub rozÅÄczyÄ. Musi byÄ to poprawny adres grupowy
              (multicast; w przeciwnym wypadku setsockopt(2) zwróci bÅÄd
              EINVAL). 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.

              Struktura ip_mreqn jest dostÄpna tylko od wersji 2.2 Linuksa.
              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 (jÄdro okreÅla którÄ strukturÄ
              zastosowano na podstawie rozmiaru podanego w optlen).

              IP_ADD_MEMBERSHIP jest prawidÅowe wyÅÄcznie dla setsockopt(2).

       IP_ADD_SOURCE_MEMBERSHIP (od Linuksa 2.4.22 / 2.5.68)
              PrzyÅÄcza adres grupowy (multicast) i zezwala na otrzymywanie
              danych jedynie z podanego źródÅa. Argumentem jest struktura
              ip_mreq_source.

                  struct ip_mreq_source {
                      struct in_addr imr_multiaddr;  /* grupowy adres IP */
                      struct in_addr imr_interface;  /* adres IP interfejsu
                                                        lokalnego */
                      struct in_addr imr_sourceaddr; /* adres IP
                                                        grupowego źródÅa */
                  };

              Sktruktura ip_mreq_source jest podobna do ip_mreqn opisanej pod
              hasÅem IP_ADD_MEMBERSIP. Pole imr_multiaddr zawiera adres
              grupowy do którego aplikacja ma zamiar doÅÄczyÄ lub opuÅciÄ go.
              Pole imr_interface jest adresem interfejsu lokalnego z którego
              system powinien doÅÄczyÄ do adresu grupowego. Pole
              imr_sourceaddr zawiera adres źródÅowy, z którego aplikacja ma
              zamiar otrzymywaÄ dane.

              Opcja może byÄ użyta kilkakrotnie aby otrzymywaÄ dane z kilku
              źródeÅ.

       IP_BIND_ADDRESS_NO_PORT (od Linuksa 4.2)
              Informuje jÄdro, aby nie rezerwowaÄ portu efemerycznego przy
              korzystaniu z bind(2) z numerem portu 0. Port bÄdzie wybrany
              automatycznie później, w trakcie wykonywania connect(2), w
              sposób umożliwiajÄcy wspóÅdzielenie portu źródÅowego tak
              dÅugo, jak dÅugo unikatowa jest czteroelementowa krotka.

       IP_BLOCK_SOURCE (od Linuksa 2.4.22 / 2.5.68)
              KoÅczy otrzymywanie danych grupowych z podanego źródÅa i
              podanej grupy. Jest to odpowiednie jedynie po zapisaniu siÄ do
              adresu grupowego za pomocÄ IP_ADD_MEMBERSHIP lub
              IP_ADD_SOURCE_MEMBERSHIP.

              Argumentem jest struktura ip_mreq_source opisana w czÄÅci
              dotyczÄcej IP_ADD_SOURCE_MEMBERSHIP.

       IP_DROP_MEMBERSHIP (od Linuksa 1.2)
              OdÅÄcza siÄ od grupy adresów. Argumentem jest struktura
              ip_mreqn lub ip_mreq podobna do IP_ADD_MEMBERSHIP.

       IP_DROP_SOURCE_MEMBERSHIP (od Linuksa 2.4.22 / 2.5.68)
              OdÅÄcza siÄ od grupy z podanego źródÅa - zaprzestaje
              otrzymywania danych z podanej grupy adresów pochodzÄcej z
              podanego źródÅa. JeÅli programy zostaÅy przypisane do wielu
              źródeÅ z tej samej grupy, dane z pozostaÅych źródeÅ wciÄż
              bÄdÄ dostarczane. Aby zatrzymaÄ otrzymywanie danych ze
              wszystkich źródeÅ na raz, należy użyÄ IP_LEAVE_GROUP.

              Argumentem jest struktura ip_mreq_source opisana w czÄÅci
              dotyczÄcej IP_ADD_SOURCE_MEMBERSHIP.

       IP_FREEBIND (od Linuksa 2.4)
              JeÅli jest wÅÄczona, to ta opcja logiczna pozwala na przypisanie
              do adresu nielokalnego lub (jeszcze) nieistniejÄcego. Pozwala to
              na nasÅuchiwanie na gnieździe bez wymagania, żeby  interfejs
              sieciowy niższej warstwy lub podany dynamiczny adres IP byÅy
              ustawione podczas próby przypisania gniazda przez aplikacjÄ. Ta
              opcja jest odpowiednikiem - dla pojedynczego gniazda - opisanego
              poniżej interfejsu /proc ip_nonlocal_bind.

       IP_HDRINCL (od Linuksa 2.0)
              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, patrz 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_MSFILTER (od Linuksa 2.4.22 / 2.5.68)
              Opcja pozwala na uzyskanie dostÄpu do zaawansowanego interfejsu
              filtrowania peÅnostanowego. Argumentem jest struktura
              ip_msfilter.

                  struct ip_mreqn {
                      struct in_addr imsf_multiaddr; /* grupowy adres IP */
                      struct in_addr imsf_interface; /* adres IP interfejsu
                                                        lokalnego */
                      uint32_t       imsf_fmode;     /* tryb filtra */
                  };

                      uint32_t       imsf_numsrc;    /* Liczba źródeŠw
                                                        kolejnej macierzy */
                      struct in_addr imsf_slist[1];  /* Macierz źródeÅ
                                                        adresów */
                  };

              Do okreÅlenia trybu filtrowania sÅuÅ¼Ä dwa makra - MCAST_INCLUDE
              i MCAST_EXCLUDE. Makro IP_MSFILTER_SIZE(n) sÅuży natomiast do
              okreÅlenia wielkoÅci pamiÄci potrzebnej do przechowania
              struktury ip_msfilter z n źródeÅ w liÅcie źródeÅ.

              PeÅny opis filtrowania źródeÅ adresów zawiera dokument RFC
              3376.

       IP_MTU (od Linuksa 2.2)
              Pobiera bieżÄcÄ wartoÅÄ MTU Åcieżki obecnego gniazda. Zwraca
              liczbÄ caÅkowitÄ.

              IP_MTU jest poprawne tylko do getsockopt(2) i można go użyÄ
              wyÅÄcznie gdy gniazdo zostaÅo poÅÄczone.

       IP_MTU_DISCOVER (od Linuksa 2.2)
              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 Åcieżki dla gniazd SOCK_STREAM
              zgodnie z definicjÄ zawartÄ w RFC 1191. W przypadku gniazd nie
              bÄdÄcych gniazdami SOCK_STREAM, IP_PMTUDISC_DO wymusza
              ustawienie we wszystkich pakietach wychodzÄcych znacznika zakazu
              fragmentacji. Za poprawne zgodne z wartoÅciÄ MTU, podzielenie na
              pakiety i za wykonanie ewentualnych retransmisji jest
              odpowiedzialny program użytkownika.  JÄdro odrzuci (z bÅÄdem
              EMSGSIZE) pakiety wiÄksze niż znane MTU Åcieżki. Ustawienie
              znacznika IP_PMTUDISC_WANT spowoduje sfragmentowanie datagramu,
              jeÅli MTU Åcieżki tego wymaga, albo - w przeciwnym wypadku -
              ustawienie znacznika zakazujÄcego fragmentacji.

              DomyÅlnÄ dla systemu wartoÅÄ można ustawiÄ na  IP_PMTUDISC_WANT
              lub na IP_PMTUDISC_DONT, wpisujÄc odpowiednio - zero lub wartoÅÄ
              niezerowÄ - do pliku /proc/sys/net/ipv4/ip_no_pmtu_disc.

              Wart. badan. MTU Åcieżki   Znaczenie
              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.
              IP_PMTUDISC_PROBE           Ustawia bit DF, ale ign. MTU Åcieżki.

              Gdy wÅÄczone jest badanie MTU Åcieżki, jÄdro automatycznie
              namierza wartoÅci MTU Åcieżki dla każdego komputera
              docelowego. Gdy aktywne jest poÅÄczenie z danym komputerem,
              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). WartoÅÄ MTU Åcieżki może
              siÄ zmieniaÄ z czasem. Dla gniazd bezpoÅÄczeniowych z wieloma
              komputerami docelowymi MTU dla danego, również nowego,
              komputera 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 zainicjowaÄ proces badania MTU Åcieżki dla gniazd
              niepoÅÄczonych, można rozpoczÄÄ z dużym rozmiarem datagramu (o
              dÅugoÅci do 64K bajtów nagÅówka) 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.

              Poprzez ustawienie wartoÅci w IP_PMTUDISC_PROBE (dostÄpnej od
              Linuksa 2.6.22) możliwe jest zaimplementowanie opisanego w
              RFC 4821 próbkowania MTU dla gniazd  SOCK_DGRAM lub SOCK_RAW.
              Jest to szczególnie użyteczne w narzÄdziach diagnostycznych
              typu tracepath(8), które w sposób zamierzony chcÄ wysyÅaÄ
              pakiety testowe wiÄksze niż zaobserwowane MTU Åcieżki.

       IP_MULTICAST_ALL (od Linuksa 2.6.31)
              Tej opcji można użyÄ do modyfikacji zasad dostarczania
              wiadomoÅci grupowych do gniazd ograniczonych maskÄ adresu
              INADDR_ANY. Argument wynosi 0 lub 1 (domyÅlnie 1). Gdy jest
              ustawiony na 1, to gniazdo otrzyma wiadomoÅci ze wszystkich
              grup, które doÅÄczono globalnie z caÅego systemu. W przeciwnym
              razie dostarczone bÄdÄ tylko wiadomoÅci z grup doÅÄczonych
              jawnie (np. opcjÄ IP_ADD_MEMBERSHIP) do tego konkretnego
              gniazda.

       IP_MULTICAST_IF (od Linuksa 1.2)
              Ustawia lokalne urzÄdzenie dla gniazda grupowego. Argumentem do
              setsockopt(2) jest ip_mreqn lub (od Linuksa 3.5) ip_mreq,
              struktura podobna do IP_ADD_MEMBERSHIP; albo struktura in_addr
              (jÄdro okreÅla którÄ strukturÄ siÄ podaÅo na podstawie rozmiaru
              przekazanego w optlen). Do getsockopt(2) argumentem jest
              struktura in_addr.

       IP_MULTICAST_LOOP (od Linuksa 1.2)
              Ustawia lub pobiera logiczny argument typu caÅkowitego,
              okreÅlajÄcy, czy przesyÅane pakiety grupowe powinny wracaÄ do
              lokalnego gniazda.

       IP_MULTICAST_TTL (od Linuksa 1.2)
              Ustawia lub pobiera wartoÅÄ czasu życia pakietu dla
              wychodzÄcych z tego gniazda pakietów grupowych. Jest bardzo
              istotne 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_NODEFRAG (od Linuksa 2.6.36)
              JeÅli wÅÄczone (argument jest niezerowy), ÅÄczenie pakietów
              wychodzÄcych przez warstwÄ netfilter jest wyÅÄczone. Argumentem
              jest liczba caÅkowita.

              Ta opcja jest prawidÅowa tylko dla gniazd SOCK_RAW.

       IP_OPTIONS (od Linuksa 2.0)
              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 RFC 791, 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. Po
              ustanowieniu poÅÄczenia przychodzÄce pakiety nie sÄ uprawnione
              do zmiany swoich opcji. Przetwarzanie wszystkich przychodzÄcych
              opcji źródÅa jest domyÅlnie wyÅÄczone, ale można je wÅÄczyÄ
              ustawiajÄc accept_source_route w interfejsie /proc. 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 przez umieszczenie ich
              w dostarczonym buforze.

       IP_PKTINFO (od Linuksa 2.2)
              Przekazuje pomocniczy komunikat 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 z pakietem 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 unikatowym 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 zostanie
              użyte jako źródÅowy adres lokalny podczas przeszukiwania
              tablicy routingu i dla ustawienia opcji routingu wedÅug 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_RECVERR (od Linuksa 2.2)
              WÅÄcza przekazywanie dodatkowych komunikatów o bÅÄdach,
              zwiÄkszajÄc niezawodnoÅÄ poÅÄczenia. Gdy jest to ustawione w
              gnieździe datagramowym, to wszystkie generowane bÅÄdy bÄdÄ
              zapamiÄtane w specjalnej kolejce bÅÄdów przypisanej do gniazda.
              Gdy użytkownik (proces użytkownika) otrzyma bÅÄd (przez
              zwrócony kod bÅÄdu operacji na gnieździe), to może go
              odebraÄ, używajÄc funkcji recvmsg(2) z ustawionym znacznikiem
              MSG_ERRQUEUE. Struktura opisujÄca bÅÄd sock_extended_err
              zostanie przekazana w pomocniczym komunikacie o typie IP_RECVERR
              i poziomie IPPROTO_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 {
                      uint32_t ee_errno;   /* numer bÅÄdu */
                      uint8_t  ee_origin;  /* źródÅo bÅÄdu */
                      uint8_t  ee_type;    /* typ */
                      uint8_t  ee_code;    /* kod */
                      uint8_t  ee_pad;
                      uint32_t ee_info;    /* informacje dodatkowe */
                      uint32_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 sockaddr sÄ
              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 nielegalne w przypadku gniazd
              SOCK_STREAM. IP_RECVERR jest poprawne dla TCP, ale wszystkie
              bÅÄdy sÄ przekazywane przez zwracanÄ wartoÅÄ funkcji albo przez
              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.

              Ustawia lub pobiera znacznik logiczny zapisany za pomocÄ liczby
              caÅkowitej. IP_RECVERR jest domyÅlnie wyÅÄczone.

       IP_RECVOPTS (od Linuksa 2.2)
              Przekazuje 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. NieobsÅugiwane w przypadku gniazd typu SOCK_STREAM.

       IP_RECVORIGDSTADDR (od Linuksa 2.6.29)
              Ta opcja logiczna wÅÄcza komunikat pomocniczy IP_ORIGDSTADDR w
              recvmsg(2), w którym jÄdro zwraca oryginalny adres docelowy
              otrzymywanego wÅaÅnie datagramu. Ten komunikat pomocniczy
              zawiera strukturÄ struct sockaddr_in.

       IP_RECVTOS (od Linuksa 2.2)
              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 (od Linuksa 2.2)
              Gdy ten znacznik jest ustawiony, przepuszczany jest komunikat
              pomocniczy IP_TTL, 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_RETOPTS (od Linuksa 2.2)
              DziaÅanie identyczne do IP_RECVOPTS, ale zwraca surowe,
              nieprzetworzone opcje, wÅÄcznie z rekordem opcji, mówiÄcym o
              znaczniku czasowym i trasie, niewypeÅnionym wartoÅciami w tym
              przejÅciu pakietu.

       IP_ROUTER_ALERT (od Linuksa 2.2)
              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 na podstawie
              protokoÅu. Wymaga liczby caÅkowitej jako argumentu.

       IP_TOS (od Linuksa 1.0)
              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, a 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Ä uprawnieÅ administratora (ustawionego
              atrybutu CAP_NET_ADMIN).

       IP_TRANSPARENT (od Linuksa 2.6.24)
              Ustawienie tej opcji logicznej wÅÄcza przezroczyste (ang.
              "transparent") proxy dla tego gniazda. Ta opcja gniazda pozwala
              wywoÅujÄcej aplikacji przypisanie gniazda do nielokalnego adresu
              IP i operowanie jako zarówno klient, jak i serwer z zewnÄtrznym
              adresem IP dla lokalnego punktu docelowego. UWAGA: wymaga to
              takiego ustawienia reguÅ routingu, żeby pakiety wysyÅane na ten
              adres zewnÄtrzny byÅy przekazywane przez TProxy (tj. system na
              którym dziaÅa aplikacja korzysta z opcji gniazda
              IP_TRANSPARENT). WÅÄczenie tej opcji wymaga uprawnieÅ
              administratora (wÅaÅciwoÅÄ CAP_NET_ADMIN).

              Przekierowanie TProxy używajÄce celu TPROXY z iptables(8)
              także wymagajÄ wÅÄczenia tej opcji w przekierowywanym
              gnieździe.

       IP_TTL (od Linuksa 1.0)
              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_UNBLOCK_SOURCE (od Linuksa 2.4.22 / 2.5.68)
              Odblokowuje zablokowanÄ uprzednio grupÄ adresów. Zwraca
              EADDRNOTAVAIL gdy podane źródÅo nie byÅo zablokowane.

              Argumentem jest struktura ip_mreq_source opisana w czÄÅci
              dotyczÄcej IP_ADD_SOURCE_MEMBERSHIP.

   Interfejsy /proc
       ProtokóŠIP obsÅuguje zbiór interfejsów /proc i korzysta z niech do
       ustawiania niektórych parametrów globalnych. Parametry sÄ dostÄpne
       przez zapis lub odczyt plików z katalogu /proc/sys/net/ipv4/.
       Interfejsy opisane jako logiczne pobierajÄ liczbÄ caÅkowitÄ, której
       wartoÅÄ niezerowa ("prawda") oznacza, że dana opcja jest wÅÄczona, a
       zero ("faÅsz"), oznacza, że opcja jest wyÅÄczona.

       ip_always_defrag (logiczna; od Linuksa 2.2.13)
              [Nowa w jÄdrze 2.2.13; we wczeÅniejszych wersjach jÄdra funkcjÄ
              tÄ sterowaÅo siÄ w czasie kompilacji za pomocÄ opcji
              CONFIG_IP_ALWAYS_DEFRAG, która nie jest już obecna w 2.4.x i
              kolejnych]

              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 komputer pomiÄdzy komputerem ź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 firewallu, 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
              komputerze. 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 skonfigurowane jest
              maskowanie lub przezroczyste proxy.

       ip_autoconfig (od Linuksa 2.2 do 2.6.17)
              Nie udokumentowane.

       ip_default_ttl (liczba, domyÅlnie: 64; od Linuksa 2.2)
              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_dynaddr (logiczna; domyÅlnie: wyÅÄczona; od Linuksa 2.0.31)
              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_forward(logiczna; domyÅlnie: wyÅÄczona; od Linuksa 1.2)
              WÅÄcza przekazywanie (ang. forwarding) pakietów przy użyciu
              logicznego znacznika. Może byÄ ustawione także na podstawie
              interfejsu.

       ip_local_port_range (od Linuksa 2.2)
              Plik zawierajÄcy dwa liczby caÅkowite okreÅlajÄce domyÅlny
              zakres lokalnych portów przypisanych do gniazd niebÄdÄcych
              bezpoÅrednio przydzielonych do portu - tj. zakres ten jest
              używany do portów efemerycznych (portów przypisywanych
              dynamicznie). Port efemeryczny jest przydzielany do gniazda w
              nastÄpujÄcych sytuacjach:

              *  numer portu w adresie gniazda jest okreÅlony jako 0 w trakcie
                 wywoÅywania bind(2);

              *  listen(2) jest wywoÅywane na gnieździe strumieniowych,
                 które nie byÅo wczeÅniej przydzielone;

              *  connect(2) byÅa wywoÅana na gnieździe, które nie byÅo
                 wczeÅniej przydzielone;

              *  sendto(2) jest wywoÅywane na gnieździe datagramowym, które
                 nie byÅo wczeÅniej przydzielone.

              Przypisywanie portów efemerycznych rozpoczyna siÄ od pierwszego
              numeru w ip_local_port_range i koÅczy siÄ na drugim numerze.
              JeÅli wyczerpie siÄ zakres portów efemerycznych, to odpowiednie
              wywoÅanie systemowe zwróci bÅÄd (ale proszÄ sprawdziÄ rozdziaÅ
              BÅÄDY!).

              ProszÄ zauważyÄ, że zakres portów w ip_local_port_range 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 zaporami
              sieciowymi, które robiÄ pewne zaÅożenia odnoÅnie do portów
              używanych lokalnie. Pierwsza liczba powinna byÄ wiÄksza niż
              1024, albo - co byÅoby lepsze - wiÄksza niż 4096, aby uniknÄÄ
              konfliktów z dobrze znanymi portami i zminimalizowaÄ problemy z
              zaporami sieciowymi.

       ip_no_pmtu_disc (logiczna; domyÅlnie: wyÅÄczona; od Linuksa 2.2)
              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 firewalli
              (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ż niewykonywanie tej
              operacji pociÄga za sobÄ duże straty w obrÄbie sieci.

       ip_nonlocal_bind (logiczna; domyÅlnie: wyÅÄczona; od Linuksa 2.4)
              Jeżeli ustawione, pozwala procesowi na wywoÅanie funkcji bind()
              z nielokalnym adresem IP, co może byÄ caÅkiem przydatne, ale
              może popsuÄ niektóre aplikacje.

       ip6frag_time (liczba; domyÅlnie: 30)
              Czas w sekundach przetrzymywania w pamiÄci fragmentu IPv6.

       ip6frag_secret_interval (liczba; domyÅlnie: 600)
              InterwaÅ (w sekundach) odÅwieżania sekretnego klucza funkcji
              mieszkajÄcej (lub czasu życia tego klucza) dla fragmentów
              IPv6.

       ipfrag_high_thresh (liczba), ipfrag_low_thresh (liczba)
              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.

       neigh/*
              Patrz arp(7).

   Kontrolki systemowe (ioctl)
       Do protokoÅu ip majÄ zastosowanie wszystkie kontrolki wejÅcia/wyjÅcia
       opisane w socket(7).

       Kontrolki konfigurowania ogólnych parametrów urzÄdzenia sÄ opisane w
       netdevice(7).

BÅÄDY
       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Å firewalla, nie majÄc
              uprawnieÅ administratora (ustawionego znacznika CAP_NET_ADMIN),
              próbÄ przypisania uprzywilejowanego portu, nie majÄc uprawnieÅ
              administratora (ustawionego znacznika CAP_NET_BIND_SERVICE).

       EADDRINUSE
              Próbowano przypisaÄ port do adresu bÄdÄcego już w użyciu.

       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.

       EALREADY
              Operacja ÅÄczenia na gnieździe nieblokujÄcym już trwa.

       ECONNABORTED
              PoÅÄczenie zostaÅo zamkniÄte podczas accept(2).

       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.

       EINVAL Przypisano niewÅaÅciwy argument. W przypadku operacji wysyÅania
              może to byÄ spowodowane przez wysyÅanie drogÄ przypisanÄ do
              czarnej dziury.

       EISCONN
              connect(2) byÅa wywoÅana na już poÅÄczonym gnieździe.

       EMSGSIZE
              Datagram jest wiÄkszy niż wartoÅÄ MTU po drodze do celu i nie
              może byÄ podzielony.

       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%.

       ENOENT SIOCGSTAMP byÅo wywoÅane na gnieździe, do którego nie dotarÅ
              żaden pakiet.

       ENOPKG Podsystem jÄdra nie byÅ konfigurowany.

       ENOPROTOOPT i EOPNOTSUPP
              Przypisano niewÅaÅciwÄ opcjÄ gniazda.

       ENOTCONN
              Operacja może byÄ wykonana tylko na poÅÄczonym gnieździe, a
              gniazdo nie zostaÅo poÅÄczone.

       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.

       EPIPE  PoÅÄczenie zostaÅo nieoczekiwanie zamkniÄte lub wyÅÄczyÅ siÄ
              drugi koniec.

       ESOCKTNOSUPPORT
              Gniazdo nie jest skonfigurowane lub zażÄdano nieznanego typu
              gniazda.

       Inne bÅÄdy mogÄ byÄ generowane przez protokoÅy wyższych warstw;
       obejrzyj tcp(7), raw(7), udp(7) i socket(7).

UWAGI
       IP_FREEBIND, IP_MSFILTER, IP_MTU, IP_MTU_DISCOVER, IP_RECVORIGDSTADDR,
       IP_PKTINFO, IP_RECVERR, IP_ROUTER_ALERT i IP_TRANSPARENT sÄ typowo
       linuksowe.

       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 niezalecane.

       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 udostÄpnia bardziej ogólnÄ
       opcjÄ IP_PKTINFO, robiÄcÄ to samo.

       Niektóre implementacja gniazd BSD także udostÄpniajÄ opcjÄ
       IP_RECVTTL, ale ÅÄcznie z przychodzÄcym pakietem jest przekazywany
       pomocniczy komunikat o typie IP_RECVTTL. W tym wÅaÅnie różni siÄ to
       od opcji IP_TTL, używanej w Linuksie.

       Używanie poziomu opcji gniazd SOL_IP jest nieprzenoÅne, gniazda oparte
       na BSD używajÄ poziomu IPPROTO_IP.

   ZgodnoÅÄ
       Dla zgodnoÅci z Linuksem 2.0, wciÄż jest dopuszczalna przestarzaÅa
       skÅadnia socket(AF_INET, SOCK_PACKET, protokóÅ), by stworzyÄ gniazdo
       typu packet(7). Nie jest to zbyt poprawne i powinno byÄ zastÄpowane
       przez socket(AF_PACKET, SOCK_RAW, protokóÅ). 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.

BÅÄDY
       Jest zbyt wiele nieokreÅlonych wartoÅci bÅÄdów.

       BÅÄd używany do zdiagnozowania wyczerpania siÄ zakresu portów
       efemerycznych różni siÄ miÄdzy poszczególnymi wywoÅaniami
       systemowymi (connect(2), bind(2), listen(2), sendto(2)), które
       przypisujÄ porty efemeryczne.

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

       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.

ZOBACZ TAKŻE
       recvmsg(2), sendmsg(2), byteorder(3), ipfw(4), capabilities(7),
       icmp(7), ipv6(7), netlink(7), raw(7), socket(7), tcp(7), udp(7)

       RFC 791 - oryginalny opis IP. RFC 1122 - wymagania stacji IPv4.
       RFC 1812 - wymagania rutera IPv4.

O STRONIE
       Angielska wersja tej strony pochodzi z wydania 4.05 projektu Linux
       man-pages. Opis projektu, informacje dotyczÄce zgÅaszania bÅÄdów oraz
       najnowszÄ wersjÄ oryginaÅu można znaleÅºÄ pod adresem
       https://www.kernel.org/doc/man-pages/.

TÅUMACZENIE
       Autorami polskiego tÅumaczenia niniejszej strony podrÄcznika man sÄ:
       PaweÅ Wilk (PTM) <siewca@pld.org.pl>, Robert Luberda
       <robert@debian.org> i MichaÅ KuÅach <michal.kulach@gmail.com>.

       Polskie tÅumaczenie jest czÄÅciÄ projektu manpages-pl; uwagi, pomoc,
       zgÅaszanie bÅÄdów na stronie http://sourceforge.net/projects/manpages-
       pl/. Jest zgodne z wersjÄ  4.05 oryginaÅu.



Linux                             2016-03-15                             IP(7)