Przytoczę kilka linijek logów serwera dhcpd:

Zaczyna się tak:



potem bywa tak:



a potem czasami pojawia się coś takiego



5 minut przerwy i znowu:



Trochę o konfiguracji. DHCPD odpalony na FreeBSD 6.2, problemy mają najczęściej Visty. Całość działa w sieci w WPA Enterprise (PEAP/MSCHAPv2). Komputer/użytkownik autoryzuje się poprawnie, a następnie Vista ma problemy z dostaniem IP. Z logów wynikałoby, że to wszystko wina Visty (brak reakcji na DHCPOFFER), ale pomaga ... nie wiem do końca co:
- wyłączenie/włączenie sieciówki w systemie i logowanie od zera (nie zawsze)
- restart AP (tego jeszcze nie przebadałem do końca)
- skasowanie dhcpd.leases i restart dhcpd (wydawało mi się, że pomaga ... ale nagle okazało się, że tylko czasami)

Zacząłem monitorować tcpdumpem serwer ... Tam jest (chyba) oki, serwer odpowiada OFFER na DISCOVER. Znalazłem sobie taką nie działającą Vistę i chciałem tam jakiś program do filtrowania załączyć [Vista 64-bit i były problemy, ale jakiś Trial się znalazł] ... ale było tak:
- Vista napisała, że jest problem z IP
- załączyłem program do monitorowania, żeby sprawdzić co się dzieje na łączu bezprzewodowym
- naprawiło się, Vista dostała IP i klapa z monitorowania

--------

Teraz pytania:
1. Ktoś wie w czym problem? Dlaczego tak się dzieje?
2. Znacie jakiś inny serwer DHCP działający na FreeBSD?
3. Może istnieje jakiś inny klient DHCP na Windows?

Pozdrawiam,
Mickey

Gdyby nie wzmianka o Viście przeniósłbym ten temat do stosownego działu zajmującego się nielotami. Do rzeczy jednak. Czy takie same problemy występują na skrętce? Z zamieszczonych logów wynika, że problem dotyczy Wi-Fi.
Nie mam wielkiego doświadczenia jeśli chodzi o systemy z rodziny Unix. Natomiast każdy Windows ma wbudowaną usługę DHCP i nie jest wymagany do tego żaden alternatywny klient. O takim też nigdy nie słyszałem. Serwis ten uruchamia się przy każdym starcie systemu automatycznie. Chyba, że ktoś go wyłączy, to już inna kwestia.

Ten serwer obsługuje właściwie tylko ruch na wifi, na kablu nie był w praktyce testowany pod takim obciążeniem, a od ponad roku żaden klient kablowy z niego nie korzystał. Właśnie na wifi co chwilę następuje rozłączenie, negocjacja połączenia i ponowne zapytanie do DHCP ... może tego za dużo jest i zbyt często?

Z XP takich problemów nie ma. Z linuksami też nie. Ale jak grzebałem w konfiguracji serwera , to przez chwilę miałem opisany problem z prawie każdym komputerem. Co może powodować takie zachowanie? Dlaczego system nie reaguje na OFFER?

Gdyby nie działało zawsze, to byłoby łatwiej, ale ten problem, nawet na tych samych komputerach, pojawia się i znika, i trudno go diagnozować (albo po prostu nie potrafię...).

Co do wyłączonego klienta DHCP ... ten problem też już przerabiałem. W niektórych poradnikach ten klient jest podawany jako "niepotrzebna usługa", ludzie go więc wyłączają i narzekają, że nie działa im coś :/

Witam,

Problem (prawie) rozwiązałem, ale może po kolei:

Załączyłem więc na dłużej tcpdumpa:


W całodobowym logu wyczytałem:



A 3 minuty później się posypało:



Porównując to z logami z serwera DHCP mamy taką sytuację:

- pierwsza próba poprawna:



- druga próba nie, czyli w kółko:



No i zacząłem się temu "intensywnie" przyglądać. Na początku zauważyłem, że pierwsza odpowiedź ma następujący kierunek: 192.168.64.1.67 > 192.168.64.251.68, a ta druga, problematyczna: 192.168.64.1.67 > 255.255.255.255.68. Wszystkie problematyczne były tak kierowane. Wcześniej w ramach testowania na chybił-trafił ustawiłem w dhcpd.conf opcję "always-broadcast on;" ... i się posypało wszystko. Nikt nie dostawał IP :/ Włączyłem na chwilę i pakiety odpowiedzi były podobne - czyli: 192.168.64.1.67 > 255.255.255.255.68 i ... flags: [Broadcast] (0x8000). Trochę czytania i zapytałem googla o [dhcp broadcast flag], a tu zaskoczenie bo pierwsza odpowiedź prowadzi do: http://support.microsoft.com/kb/928233 ... może już nie powinienem być zaskoczony?

A tam mamy:

Znajdź następujący klucz w rejestrze: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}
Wybierz (GUID) odpowiadający karcie sieciowej, która ma problem. Utwórz nową wartość typu DWORD (32-bit) Value, nazwij ją DhcpConnEnableBcastFlagToggle i ustaw na 1.

Hmmm... To nie pomogło za wiele, znaczy nie pomogło wcale, ale poniżej mamy, żeby ustawić DhcpConnForceBroadcastFlag na 0. U mnie ten wpis był, tyle że ustawiony na 1, więc zmieniłem. Pomogło. Flaga Broadcast zniknęła i komputer natychmiast dostał IP.

Polecam pozostałe wyniki googla na podane zapytanie. Ta drobnostka powoduje problemy z wieloma serwerami DHCP ... chociaż oczywiście żadnych z serwerem Microsoftu ... ale to nic dziwnego :/

------------------------------------------------------------------------------------------------------

Oki, to powyżej to jakieś rozwiązanie. Powiedzmy, że satysfakcjonujące w 90%. Pozostaje pytanie, czy nie da się czegoś zrobić od strony serwera? Żeby nie trzeba było każdego klienta ustawiać? Wydaje się, że to nie problem serwera, bo dostaje zapytanie z flagą broadcast i odpowiada także z w/w flagą ustawioną ... ale ta odpowiedź nie dociera do klienta? Sniffer na Viście wykrył wiele pakietów adresowanych na 255.255.255.255 port 68 z flagą broadcast ustawioną ... ale jakoś systemy na to nie reagowały. Może te pakiety są źle sformatowane....

Oki, nie gdybam już,
Pozdrawiam,
Mickey