Chyba przyszły z serwera. Ofertę przesyła zawsze serwer DHCP, nie klient.

Co to za adres 89.71.248.97 i dlaczego on wysyła oferty DHCP? I skąd tyle transakcji... I dlaczego serwer (prawdopodobnie, bo na tym co pokazałeś g... widać) nie potwierdza (NAK) własnych ofert...? A klient po otrzymaniu NAK powinien zacząć od nowa. Zrobiłeś w końcu aktualizację systemu na routerze?

Pokaż pełną transakcję od momentu wymuszenia zwolnienia adresu (DHCP Release) do momentu uzyskania nowego lub NAK z serwera. Najlepiej wrzuć plik, a nie sam zrzut ekranu, bo słabo to widać. To mi wygląda albo na jakiegoś bubka w sieci z serwerem DHCP na swoim WAN lub coś UPC namieszało i dostajesz z jednego serwera oferty dwa razy?

I po co zamazywałeś adres? I tak nie jest stały...

PS. Żaden technik, żadne wymienianie rozdzielaczy i zmienianie filtrów, nie tutaj leży problem...

Nie mam kabla do TV, tylko do modemu. Co powinienem w takim razie zrobić, żeby "osłabić" sygnał?
Logi z tcpdump/wireshark dostarczę w późniejszych godzinach popołudniowych jak nastąpi odnowienie dzierżawy.

Gdyby to był problem związany z sygnałem, to w ogóle miałbyś problemy z dostępem do sieci, a jak już dobrze wszyscy wypowiadający się w tym wątku powinni wiedzieć, jedyny problem jaki masz, to odnawianie dzierżawy DHCP - komunikację masz, co doskonale widać na wcześniejszym zrzucie. Nie doszukuj się problemów, tam gdzie ich nie ma.

Po prostu wymuś na routerze odnowienie dzierżawy i pokaż co i skąd dostajesz w odpowiedzi.

Problem polega na tym, że po wymianie filtra i tak jest niezbędna regulacja w skrzynce - a tam dostępu nie masz. Wiadomo, że każdy filtr/rozdzielacz ma pewną tolerancję wykonania - po to są potrzebne ostateczne strojenia linii w skrzynce.
Możesz też oczywiście mieć nieprawdopodobny fart i trafić od strzału.
To tyle jeżeli chodzi o sprawy czysto sprzętowe - co do sprawy software i reszty niezbędnych czynności/szukania przyczyny zapewne pomogą Ci koledzy, którzy do tej pory piszą w tym temacie.

To nie wystarczy jeśli kupię filtr o zbliżonych parametrach i te wartości na modemie będą ok?

http://www9.zippyshare.com/v/36259354/file.html - tutaj wynik działania wireshark. Dałem komendę ipconfig /renew i zakończyła się ona błędem.

W zrzucie wiresharka widzę, że wysyłam 4 pakiety DHCP Request i na żaden nie ma odpowiedzi. Tak samo w samym windowsie jak i w OpenWRT.

W okolicach pakietu 3300 następuje pełny restart interfejsu.
http://www19.zippyshare.com/v/33391585/file.html
Skąd ten drugi DHCP nie mam pojęcia.

Obejrzyj sobie fragment od pakietu 3306 (ID transakcji: 3ab8108) - to jest DHCP Request wysłany od Ciebie (zgaduję po Vendor ID MAC == Netgear), dostajesz 4 odpowiedzi NAK i dopiero piąta jest ACK.

Nie wiem czy zauważyłeś, ale Twój router zawsze wysyła zapytania bez ustawionej flagi "Broadcast" w BOOTP (czyli de facto, z opcją Unicast i takiej będzie oczekiwał w odpowiedzi), natomiast serwer odpowiada z tą flagą ustawioną (4x NAK) i prawdopodobnie Twój klient ignoruje taką odpowiedź. Kolejne odpowiedzi z serwera są już bez flagi i są typu ACK, z adresem IP (który zresztą dostałeś później po całej sekwencji DISCOVER... OFFER... REQUEST... ACK), ale router też je ignoruje (dlaczego?).

Coś jest tutaj totalnie namieszane po stronie ich serwera DHCP i u Ciebie chyba też.
Nie mówiąc już o tym, że ten sam serwer DHCP (na podstawie adresu MAC) odpowiada raz z publicznego IP, a raz z prywatnego?

Ktoś z większą ilością wolnego czasu powinien te logi dokładnie przejrzeć, a Tobie sugeruję kontakt z ich działem technicznym - wyślij im te logi, napisz, że zebrałeś to na PC i z jakiej racji docierają do Ciebie oferty DHCP dla innych klientów, z ich adresami MAC/IP...

Identyczna sytuacja - serwer odpowiada NAK, restart WAN, ponowne pobranie ustawień z DHCP.
Czy u Ciebie (@connexion2000) też masz w logach informację o NAK z serwera DHCP, czy router to ignoruje?

I jeszcze do poczytania: https://dev.openwrt.org/ticket/12114

Po pierwsze - następnym razem, z łaski swojej, podaj od razu wszelkie istotne informacje (w tym: logi, w których od razu byśmy dojrzeli odpowiedź NAK), bo żeby to wyciągnąć od Ciebie potrzebowaliśmy aż 2 strony postów, co doprowadziło nawet do kuriozalnych stwierdzeń, że przyczyną problemów z DHCP są... kable

A po drugie, na przyszłość nie wprowadzaj w błąd:

Udostępniasz logi, których sam dokładnie nie przejrzałeś... NAK to też odpowiedź I tak jak ktoś napisał w przytoczonym zgłoszeniu, reakcja na taką odpowiedź, polegająca na rozpoczęciu całej procedury uzyskania adresu z DHCP od początku, jest zupełnie prawidłowa - przeanalizuj wstawiony wcześniej przeze mnie schemat.

Raz, zaktualizuj w końcu firmware na routerze. Dwa, jak dalej będziesz miał problem, to męcz UPC. Chociaż i tak już teraz nadaje się to na zgłoszenie.

Odsyłam do zamieszczonego przeze mnie schematu. Przy braku odpowiedzi, po odpowiednim czasie i liczbie ponowień (do doczytania), Twój router powinien rozpocząć cały proces od początku, tak samo jak przy NAK. I tak jak sugerowałem - zgłoś to do UPC, bo to raczej niespotykane, żeby serwer DHCP przy odnawianiu dzierżawy odpowiadał najpierw 4xNAK, a chwilę później 2xACK.

A gdzie reszta tych logów...? Dostałeś w końcu ten adres później?

W RFC dotyczące BOOTP/DHCP zaglądałem wieki temu więc pewności nie mam, ale nie wydaje mi się, żeby to było nieprawidłowe zachowanie serwera (w tym sensie, że taka odpowiedź jest dopuszczalna - może mają przeciążony serwer, albo tak skonfigurowany). Klient dostał NAK, więc powinien na to zareagować, dokładnie tak samo jak w logach od @dazzler.

Dla mnie to jest tam zdecydowanie za dużo NAK. Vectra ma czas dzierżawy ustawiony na 2h i przez 15 minut obserwowania ruchu nie mam tylu pakietów związanych z DHCP, co Ty w UPC... i żadnego NAK - same oferty i ACK

Ja nie miałem nigdy NAK - tylko tak jak na początku tematu. I też UPC.
Druga sprawa po przeczytaniu wszystkiego, odnoszę wrażenie, ze kolega tak do końca to nie wie co i jak powinno być wgrane z alternatywy i jak skonfigurowane. Wracając do tłumienności linii sprawa nadal aktualna - ale wobec całokształtu to mały, nieistotny pikuś.