Pytanie:
Serwer DHCP Raspberry Pi: klienci nie otrzymują adresów IP
Flux
2019-01-31 21:26:27 UTC
view on stackexchange narkive permalink

Networking, jestem stosunkowo nowy, więc proszę o wyrozumiałość. Na potrzeby czysto edukacyjnego projektu założyłem sieć, w której Raspberry Pi 3 z Raspbian Stretch ma działać zarówno jako router, jak i serwer DHCP. Celem jest posiadanie sieci prywatnej, która współużytkuje połączenie internetowe. Oto topologia sieci: 

  + ---------- + | Internet | + ----- + ---- + | (wlan0) + ----- + ---------- + | Raspberry Pi 3 | (router + serwer DHCP) + ----- + ---------- + | (eth0) + ----- + - + | Przełącznik | (5-portowy przełącznik TP-Link TL-SF1005D) + ----- + - + | + ----- + ------- + | Mój komputer | + ------------- +

Sieć prywatna ma być 10.0.0.0/24 , z Raspberry Pi ( który jest routerem i serwerem DHCP) z adresem 10.0.0.1 (przez eth0).

Konfiguracja routingu na Raspberry Pi

Dla Raspberry Pi do routingu pakiety między wlan0 a eth0 , zrobiłem sudo sysctl -w net.ipv4.ip_forward = 1 (i wyedytowałem / etc / sysctl .conf , aby zmiana była trwała).

Następnie na początkowo pustych tabelach iptables, zrobiłem: 

  # iptables -P INPUT ACCEPT # iptables - P OUTPUT ACCEPT # iptables -P FORWARD DROP # iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE # iptables -A FORWARD -i wlan0 -o eth0 -m conntrack --ctstate USTANOWIONO, POWIĄZANE -j AKCEPTUJ # iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT

Konfiguracja interfejsu sieciowego na Raspberry Pi

Ponieważ Raspbian Stretch używa /etc/dhcpcd.conf zamiast / etc / network / interfaces na automat Aby skonfigurować interfejsy sieciowe, wyedytowałem /etc/dhcpcd.conf tak, aby wyglądały tak (zobacz sekcję MOJE USTAWIENIA ): 

  # /etc/dhcpcd.conf na Raspberry Pi (router + serwer DHCP). # Poinformuj serwer DHCP o naszej nazwie hosta dla DDNS.hostname # Użyj adresu sprzętowego interfejsu dla Client ID.clientid
# Utrwalaj konfigurację interfejsu, gdy dhcpcd exits.persistent # Rapid commit support.option rapid_commit # Lista opcji żądanych od serwera DHCP.option domain_name_servers, domain_name, domain_search, host_nameoption classless_static_routes # Większość dystrybucji ma obsługę NTP.option ntp_servers # Szanuj sieć MTU. Jest to stosowane do routingu DHCP route.option interface_mtu # Identyfikator serwera jest wymagany przez RFC2131.require dhcp_server_identifier # Generuj stabilne prywatne adresy IPv6 zamiast sprzętu opartego naesslaac private # MOJE USTAWIENIA: interface eth0static ip_address = 10.0.0.1 / 24static broadcast_address = 10.0.0.255static domain_name_servers = 8.8.8.8 8.8.4.4

Konfiguracja DHCP na Raspberry Pi

Zainstalowałem isc-dhcp-server i skonfigurowałem go w ten sposób: 

  # /etc/dhcp/dhcpd.conf na Raspberry Pi (router + serwer DHCP). # Plik konfiguracyjny dla ISC dhcpd # Użyj Google Public DNS.option Domain-name-servers 8.8.4.4, 8.8.8.8; domyślny czas dzierżawy 600; maksymalny czas dzierżawy 7200; styl aktualizacji ddns brak; autorytatywny; maska ​​sieciowa podsieci 10.0.0.0 255.255.255.0 {zakres 10.0.0.10 10.0.0.254; routery opcjonalne 10.0.0.1; opcja broadcast-address 10.0.0.255;}

Konfiguracja obsługująca tylko eth0 : 

  # / etc / default / isc -dhcp-server na Raspberry Pi (router + serwer DHCP) .INTERFACESv4 = "eth0" INTERFACESv6 = ""

Następnie zrestartowałem Raspberry Pi i upewniłem się, że isc-dhcp -server jest uruchomiony.

Obserwacja problemu

Podekscytowany nową siecią wziąłem komputer ( Mój komputer w schemat sieci powyżej) i podłączono kabel Ethernet do portu Ethernet. Komputer nie łączy się, więc zaglądam do pliku / var / log / syslog na komputerze. Widzę tam te wiersze: 

  home dhclient [14783]: DHCPDISCOVER na enp3s0 do 255.255.255.255 port 67, interwał 3 (xid = 0xcab1222)
home dhclient [14783]: DHCPDISCOVER na enp3s0 do 255.255.255.255 port 67, interwał 5 (xid = 0xcab1222) home dhclient [14783]: DHCPDISCOVER na enp3s0 do 255.255.255.255 port 67 interwał 14 (xid = 0xcab1222) home dhclient [14783]: DHCPDISCOVER na enp3s0 do 255.255.255.255 port 67 interwał 16 (xid = 0xcab1222) ## itd.

Ciekawe, czy Raspberry Pi (router + serwer DHCP) odbiera te żądania, Spojrzałem na / var / log / syslog na Raspberry Pi: 

  rpi dhcpd [9685]: DHCPDISCOVER z f4: 8e: 38: e9: 88: d7 (home) przez eth0rpi dhcpd [9685]: DHCPOFFER od 10.0.0.11 do f4: 8e: 38: e9: 88: d7 (home) przez eth0rpi dhcpd [9685]: DHCPDISCOVER od f4: 8e: 38: e9: 88: d7 (home) przez eth0rpi dhcpd [9685]: DHCPOFFER od 10.0.0.11 do f4: 8e: 38: e9: 88: d7 (home) przez eth0rpi dhcpd [9685]: DHCPDISCOVER od f4: 8e: 38: e9: 88: d7 (home) przez eth0rpi dhcpd [9685]: DHCPOFFER na 10.0.0.11 do f4: 8e: 38: e9: 88: d7 (home) przez eth0 ## itd.

Rzeczywiście, malina Pi wysyła DHCPOFFER s, ale komputer kliencki w jakiś sposób ich nie odbiera (lub ignoruje).

Dziwna obserwacja

Chcąc zbadać dalej, uruchomiłem tcpdump na Mój komputer . Po podłączeniu kabla Ethernet do My Computer uruchomiłem sudo tcpdump -n udp port 68 -v . I ... łączy! Mój komputer pobiera adres IP ( 10.0.0.11 ) z serwera DHCP. I mogę użyć tego połączenia, aby pomyślnie przeglądać stackoverflow.com bez żadnych problemów.

Ciekawe, odłączyłem i ponownie podłączyłem kabel Ethernet, a następnie uruchomiłem tcpdump nieco inaczej: sudo tcpdump -n udp port 68 --no-promiscuous-mode -v . Niestety, wracając do punktu wyjścia: brak połączenia, brak przypisanego adresu IP.

Więc wygląda na to, że Mój komputer może odbierać DHCPOFFER , ale tylko w trybie swobodnym? Nie sądzę, żeby winna była karta sieciowa; Mogę z powodzeniem korzystać z przewodowej sieci Ethernet poza tym eksperymentem.

Kolejna obserwacja: próbowałem ponownie podłączyć Mój komputer do sieci, ale tym razem bez przełącznika (tj. połączenie z Mój komputer do RPi). Dokładnie ten sam problem. Dokładnie ta sama obserwacja w dziennikach i przy zachowaniu tcpdump .

Pytania

  1. Czy moja topologia sieci jest prawidłowa?
  2. Czy mój sprzęt sieciowy jest prawidłowy?
  3. Co jest nie tak z konfiguracją sieci?

Próbowałem rozwiązać ten problem, czytając dużo, a ja ' wiele się z tego nauczyłem, ale myślę, że nadszedł czas, abym uzyskał kilka wskazówek.

1.) Każda topologia jest w porządku. Projektujesz topologię, jaką chcesz. 2.) Nie możemy sprawdzić Twojego sprzętu. Musisz to zrobić sam. Sprawdź każdy komponent osobno, a następnie podłącz je razem zgodnie z planem topologii. 3.) Myślę, że to jest prawdziwe pytanie
Dwa odpowiedzi:
Flux
2019-02-01 02:21:35 UTC
view on stackexchange narkive permalink

Rozwiązałem problem.

AKTUALIZACJA: Wydaje się, że główny problem dotyczy sterowników jądra. Problem rozwiązany przez aktualizację jądra z 4.14.50-v7 + do najnowszej stabilnej wersji (obecnie 4.14.79-v7 +) przy użyciu sudo apt-get install raspberrypi-kernel i ponowne uruchomienie. Kroki opisane poniżej nie są już konieczne. ( odniesienie).

AKTUALIZACJA 2: Złe sterowniki po stronie klienta (np. Mój komputer na powyższym schemacie sieci) mogą również stanowić problem. Jeśli karta interfejsu sieci Ethernet klienta to Realtek RTL8111,8168,8411 PCI Express Gigabit Ethernet Controller (aby sprawdzić, uruchom: lscpi | egrep -i 'ethernet' ), Debian i Ubuntu zapewniają lepszy sterownik niż ta, która jest już zawarta w jądrze instalacji podstawowej. Zainstaluj lepszy sterownik: sudo apt-get install r8168-dkms . Uważam, że będziesz musiał zrestartować komputer, aby nowy sterownik działał.

Uwagi

Najpierw odłączyłem kabel sieciowy od Mój komputer . Na My Computer uruchomiłem sudo tcpdump -n udp port 68 -e -vv .

Jednocześnie na Raspberry Pi uruchomiłem sudo tcpdump -n udp port 67 -e -vv .

Następnie ponownie podłączyłem kabel Ethernet do Mój komputer i obserwowałem wszystkie pakiety wyświetlane przez tcpdump na obie maszyny. Zauważyłem, że wyjście tcpdump na Raspberry Pi czasami wskazywało, że suma kontrolna udp jest zła. Domyślam się, że ta zła suma kontrolna jest powodem, dla którego Mój komputer nie zaakceptował pakietu DHCPOFFER z Raspberry Pi.

Aby dokładniej zdiagnozować problem , Zainstalowałem ethtool na Raspberry Pi i uruchomiłem ethtool -k eth0 : 

  Funkcje dla eth0: rx-Checkumming: ontx- suma kontrolna: on tx-checksum-ipv4: on tx-checksum-ip-generic: off [naprawiono] tx-checksum-ipv6: off [naprawiono] tx-checksum-fcoe-crc: off [naprawiono] tx-checksum-sctp: off [naprawiono] - snip -

Najwyraźniej suma kontrolna wychodzących pakietów jest obsługiwana przez sam interfejs sieciowy (patrz tx-checksum-ipv4: on ). Dowiedziałem się, że nazywa się to `` odciążaniem '', tj. Obliczanie sum kontrolnych jest `` przenoszone '' na interfejs sieciowy, dzięki czemu procesor nie musi wykonywać pracy. Opierając się na problemie, który mam, interfejs sieciowy źle sobie radzi z generowaniem poprawnych sum kontrolnych.

Rozwiązanie

Dlatego zdecydowałem, że interfejs sieciowy nie powinien sumować wychodzących pakiety i zamiast tego pozwól procesorowi się tym zająć. czyli decyduję się wyłączyć odciążanie. Aby uniemożliwić interfejsowi sieciowemu sprawdzanie sumy kontrolnej wychodzących pakietów: 

  sudo ethtool --offload eth0 tx off

Więc teraz ethtool -k eth0 pokazuje to: 

  Funkcje dla eth0: rx-Checkumming: ontx-Checksuming: off tx-checksum-ipv4: off tx-checksum-ip-generic: off [fixed] tx-checksum -ipv6: off [naprawiono] tx-checksum-fcoe-crc: off [naprawiono] tx-checksum-sctp: off [naprawiono] - snip -

Et voilà! Teraz wszystko działa zgodnie z oczekiwaniami! Niemal natychmiast po podłączeniu kabla Ethernet do Mój komputer proces DHCP kończy się pomyślnie. Mogę odłączyć i ponownie podłączyć kabel sieci Ethernet i nadal działa.

Dalsze problemy

Jedynym problemem związanym z rozwiązaniem jest to, że efekt sudo ethtool - offload eth0 tx off nie utrzymuje się po ponownym uruchomieniu. Aby rozwiązać ten problem, utworzyłem plik /etc/dhcpcd.enter-hook , aby umożliwić hakowi dhcpcd obsługę problemu: 

  # /etc/dhcpd.enter-hook# Zobacz 'man dhcpcd-run-hooks', aby uzyskać więcej informacji.if ["$ {powód}" = "PREINIT"] && ["$ {interface}" = "eth0"]; następnie ethtool --offload eth0 tx offfi

Jeśli ktoś ma lepszy sposób na uruchomienie ethtool --offload eth0 tx off , który może utrzymywać się po ponownym uruchomieniu, udostępnij go .

Referencje

Te raporty błędów Raspberry Pi są prawdopodobnie istotne:

W serwisie GitHub również otworzyłem numer dotyczący tego problemu: https://github.com/raspberrypi/linux/issues/2844

+100, przepraszam, że mogę oddać tylko jeden głos za. Sprawdzę moje problemy pod kątem tego błędu. Ale czego nadal nie rozumiem: dlaczego działa z rozwiązłymi?
@Ingo Przeszukując internet stwierdziłem, że nie tylko ja miałem ten problem. Są też inni, którzy drapią się po głowach, dlaczego działa tylko w trybie rozwiązłym. Najprawdopodobniej spowodowane przez buggy sterowniki.
Ingo
2019-02-01 01:38:38 UTC
view on stackexchange narkive permalink

Bardzo dobrze wykonana robota. Twoja topologia sieci jest poprawna. Również sprzęt wydaje się być w porządku. Nie ma nic złego w konfiguracji sieci, ale nie sprawdziłem wszystkich szczegółów pod kątem literówki. Ale wygląda na to, że jest w porządku, ponieważ możesz uzyskać adres IP z serwera DHCP.

Widziałem również to zachowanie w trybie rozwiązłym. Był to złożony problem z adresami mac na wirtualnym interfejsie ap0 połączonym z wlan0 na repeaterze wifi. Jeśli interesują Cię szczegóły, wyszukaj hasło promiscuous w tej witrynie.

O ile widzę, nie jest to problem z Twoją siecią. Jest to problem na Twoim komputerze klienckim. Nie zawsze musisz bawić się tcpdump . Możesz po prostu włączyć / wyłączyć tryb rozwiązły w interfejsie za pomocą 

  pc ~ $ sudo ip link set enp3s0 promisc on | off

Nie wiem coś o ustawieniach sieciowych na komputerze klienckim, ale mój problem polegał na tym, że stos sieciowy nie widzi adresu mac f4: 8e: 38: e9: 88: d7 , aby być członkiem domeny rozgłoszeniowej 10.0.0.0/24 . Jeśli włączysz tryb promiscuous, stos będzie nasłuchiwał wszystkich przychodzących pakietów IP, nie tylko tych, które są zaadresowane do enp3s0 komputera klienckiego. W ten sposób zobaczy DHCPOFFER , nawet jeśli oznacza to, że nie należy do interfejsu.

Proponuję zredukować konfigurację sieci na komputerze klienckim do bardzo prostej konfiguracji z tylko jeden interfejs enp3s0 do testowania.

Rozwiązałem problem: https://raspberrypi.stackexchange.com/a/93738/46753. Problem był na Raspberry Pi.


ⓘ
To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 4.0, w ramach której jest rozpowszechniana.
Loading...