Vraag

DHCP server V10 loopt vol en looptvast

  • 30 juni 2018
  • 45 reacties
  • 2043 keer bekeken


Toon eerste bericht

45 reacties

Kan je mij vertellen wat voor een apparaten je op de IP adressen 192.168.2.116, 192.168.2.118 en 192.168.2.120 hebt staan?

Dat zijn de IPTV kastjes van KPN.
Ik heb even vanochtend gekeken of er nog iets geks is gebeurd en dat is. Verschillende apparaten zijn veranderd naar een hoger IP adres. De IP adressen waar ze dus vandaan komen kunnen niet meer worden gebruikt. Deze dus: 192.168.1.109 / 111 / 113 / 124 / 128 / 131 / 133 / 134

Dus na 1 á 2 weken heeft de V10 geen IP adressen meer om uit te geven en moet ik hem opnieuw opstarten.

Gister:



Vandaag:

Reputatie 7
De IP adressen waar ze dus vandaan komen kunnen niet meer worden gebruikt. Deze dus: 192.168.1.109 / 111 / 113 / 124 / 128 / 131 / 133 / 134Die conclusie trek ik nog niet, die IP adressen behoren gewoon vrijgegeven te zijn en als ze ook niet meer in de ARP tabel voorkomen (lijst van apparaten vanuit het hoofdscherm) dat duidt er nog niets op dat dit niet het geval is. Helaas blijkt nog uit geen enkel screenshot van je dat de DHCP server vol zou lopen. Ja, die apparaten hadden geen nieuw IP adres behoren te krijgen als ze zich keurig binnen de DHCP lease opnieuw op het netwerk aanmelden. Dat ze een nieuw IP adres hebben gekregen is dus niet goed, maar het is daarmee nog niet een oorzaak van het vollopen van de DHCP server.
Ik had gehoopt dat je zou kunnen komen dat een apparaat werkelijk twee IP adressen heeft, maar die heb ik nog niet gezien.
Reputatie 7
Badge +30
Naar mijn idee niet hoe het normaliter werkt, maar naar mijn idee laat dit nog niet zien dat die adressen daadwerkelijk niet meer uitgegeven worden.

Adressen zoals .131, 133, 134 zijn waarschijnlijk gewoon geOFFERt aan een apparaat, maar die heeft hem (nog) niet bevestigd en toen is voor het volgende apparaat 135 uitgegeven.

Ik zou bijna willen zeggen dat je hier eigenlijk alleen achterkomt door alle verkeer te monitoren/mirroren en dan te filteren op DHCP in tcpdump/wireshark. Maar dat is voor de meeste mensen wel heel veel werk waarschijnlijk.

Ik kijk even of ik dit in mijn setup makkelijk kan nabootsen met een lagere lease tijd

Robin
Ik had gehoopt dat je zou kunnen komen dat een apparaat werkelijk twee IP adressen heeft, maar die heb ik nog niet gezien.

Ik heb zelf nog nooit mee gemaakt dat een apparaat 2 IP adressen zou hebben.

Helaas blijkt nog uit geen enkel screenshot van je dat de DHCP server vol zou lopen. Ja, die apparaten hadden geen nieuw IP adres behoren te krijgen als ze zich keurig binnen hu DHCP lease opnieuw op het netwerk aanmelden. Dat ze een nieuw IP adres hebben gekregen is dus niet goed, maar het is daarmee nog niet een oorzaak van het vollopen van de DHCP server.

Dit is dus het begin. Die IP adressen waar ik het overhad worden er veel meer en al die adressen geeft de V10 niet meer uit.

Deze dus: 192.168.1.109 / 111 / 113 / 124 / 128 / 131 / 133 / 134

Uiteindelijk heeft een apparaat IP adres 192.168.1.252 en dan doet de V10 geen IP adressen meer uitgeven. Ook niet de IP adressen die eigenlijk vrij zouden moeten zijn.

Zoals ik al zei werkte alles 100% voor de update V3.2 / 3.4 van de V10. Ik heb in de hardware niks aangepast en alles zo gelaten sinds dat ik KPN heb gekregen.
Reputatie 7
Uiteindelijk heeft een apparaat IP adres 192.168.1.252 en dan doet de V10 geen IP adressen meer uitgeven. Ook niet de IP adressen die eigenlijk vrij zouden moeten zijn.Dus wat je eigenlijk zegt is dat er geen IP adressen meer uitgegeven worden als de bovengrens van de DHCP range bereikt wordt. Het zou dus ook zo kunnen zijn dat dit puur veroorzaakt wordt doordat de DHCP server "vergeet" terug te keren naar de ondergrens van de DHCP range.
Kan je eens een screenshot plaatsen van de instellingen van de DHCP server van jouw Experia Box?

Reputatie 7


Uiteindelijk heeft een apparaat IP adres 192.168.1.252 en dan doet de V10 geen IP adressen meer uitgeven. Ook niet de IP adressen die eigenlijk vrij zouden moeten zijn.
@Jaap-1955, @Paul_,
Dit lijkt me dan toch iets waar KPN zijn licht eens over moet laten schijnen want dit riekt dan toch echt naar een probleem in de DHCP functionaliteit van de V10!

Ik ga er wel vanuit dat er geen apparaten zijn die een op het apparaat zelf ingesteld vast IP adres hebben dat binnen de DHCP range valt.
Interessant is dat Jasper niet het standaard subnet gebruikt (192.168.1.x i.p.v. 192.168.2.x) en dat hij de Experia Box op adres 1 heeft staan i.p.v. 254. Daar is overigens niets mis mee, maar het zou een lead kunnen zijn in de zoektocht naar de oorzaak.
Interessant is dat Jasper niet het standaard subnet gebruikt (192.168.1.x i.p.v. 192.168.2.x) en dat hij de Experia Box op adres 1 heeft staan i.p.v. 254. Niets mis mee, maar het zo een lessen kunnen zijn in de zoektocht naar de oorzaak.

Ik kan het aanpassen in de instellingen van de V10 en kijken wat er dan gebeurt. Maar dit is raar want alle instellingen staan zoals ik het had voor de update V3.2 / 3.4. En toen werkt alles 100%

Ik ga er wel vanuit dat er geen apparaten zijn die een op het apparaat zelf ingestekd vast IP adres hebben staan binnen de DHCP range.

De apparaten die zelf een vast IP adres hebben zijn de 4 WRT1900AC's. Deze zitten op 192.168.1.3 / 5 / 7 / 9.
Reputatie 7
Interessant is dat Jasper niet het standaard subnet gebruikt (192.168.1.x i.p.v. 192.168.2.x) en dat hij de Experia Box op adres 1 heeft staan i.p.v. 254. Niets mis mee, maar het zo een lessen kunnen zijn in de zoektocht naar de oorzaak.Ik kan het aanpassen in de instellingen van de V10 en kijken wat er dan gebeurt. Maar dit is raar want alle instellingen staan zoals ik het had voor de update V3.2 / 3.4. En toen werkt alles 100%Dat alle instellingen zo staan als voor de update naar V3.2 / 3.4 kan prima. Zoals ik eerder al aangaf is het gedrag van de DHCP server sinds V3.2 heel anders dan daarvoor en dat betekent dus dat KPN t.a.v. de DHCP functionaliteit wijzigingen heeft aangebracht in die firmware. Daarbij is die bug dus geïntroduceerd.

Ik hoop dat @Paul_ zich geroepen voelt om even te reageren en dit issue door te zetten naar "modemdevelopment".
Reputatie 7
Badge +30
Ik heb de lease tijd naar 1 uur gezet, alle DHCP verkeer gecaptured in een .pcap die ik in Wireshark kan laden, en elk uur een screenshot van de DHCP table gemaakt:
13:00:


14:00:


15:00:



Wat opvalt in de capture is dat de Android-55..976b met MAC 84:38:38:..:..:.. meerdere keren een DISCOVER doet (binnen dezelfde minuut), en meerdere keren een OFFER krijgt maar pas na 3x tevreden is en REQUEST/ACK afmaakt.

In de screenshots zie je ook Android-98..5e14 met MAC 64:89:9a:..: ..:.. een ander IP krijgt, dat is in dit geval omdat deze om 13:18 een IP vroeg, en om 14:56 weer, en toen was de lease logischerwijs al verlopen. Dit is een smartwatch en die is niet constant verbonden met WiFi.

Wat daarnaast opvalt is dat de V10 niet direct weer begint met het uitgeven van (gebruikte) (lagerliggende) IPs.

Robin
Ik had mijn DHCP eind IP adres op 192.168.1.137 gezet (zonder opnieuw op te starten) aangezien het laatste apparaat daar op zat. Toen heb ik gekeken met een nieuw apparaat te verbinden en die kreeg nu wel een oud IP adres. Daarna had ik het DHCP eind IP adres op 192.168.1.252 terug gezet en toen weer verbinding gemaakt met een ander apparaat. Deze kreeg nu ook een oud IP adres toegewezen. Alle 2 de apparaten waren nog niet verbonden geweest met wifi.

Ik ga de V10 nu opnieuw opstarten met DHCP eind IP adres op 192.168.1.252 en een keer met DHCP eind IP adres op 192.168.1.137 kijken wat de V10 dan met de IP adressen doet.
Reputatie 7
Ik ga de V10 nu opnieuw opstarten met DHCP eind IP adres op 192.168.1.252 en een keer met DHCP eind IP adres op 192.168.1.137 kijken wat de V10 dan met de IP adressen doet.Zet hierbij dan eens de lease tijd heel kort, want dan zal je waarschijnlijk door de IP adressen heen vliegen en is het resultaat ook snel bekend.
De kortst mogelijke lease tijd op de V10 is 60 seconde.
Dacht ik ook al aan. Ben het nu aan het proberen.
Ik ga de V10 nu opnieuw opstarten met DHCP eind IP adres op 192.168.1.252 en een keer met DHCP eind IP adres op 192.168.1.137 kijken wat de V10 dan met de IP adressen doet.Zet hierbij dan eens de lease tijd heel kort, want dan zal je waarschijnlijk door de IP adressen heen vliegen en is het resultaat ook snel bekend.
De kortst mogelijke lease tijd op de V10 is 60 seconde.


Bij DHCP eind IP adres op 192.168.1.137 en bij DHCP eind IP adres op 192.168.1.252 ( met opnieuw opstarten) gebeurde hetzelfde. Hij gaat verder met IP adressen uitdelen waar de hoogste is geëindigd. Stel een apparaat meld zich aan op 192.168.1.120 en daarna meld het volgende apparaat zich aan op 192.168.1.137 dan doet de V10 niks meer tussen IP adres op 192.168.1.120 en IP adres op 192.168.1.137 maar gaat het volgende apparaat meteen op IP adres op 192.168.1.138 zitten.

Maar als ik het maximum verander zonder opnieuw op te starten dan pakt ie meteen het laagste IP adres wat vrij is.

Ik had mijn DHCP eind IP adres op 192.168.1.137 gezet (zonder opnieuw op te starten) aangezien het laatste apparaat daar op zat. Toen heb ik gekeken met een nieuw apparaat te verbinden en die kreeg nu wel een oud IP adres. Daarna had ik het DHCP eind IP adres op 192.168.1.252 terug gezet en toen weer verbinding gemaakt met een ander apparaat. Deze kreeg nu ook een oud IP adres toegewezen. Alle 2 de apparaten waren nog niet verbonden geweest met wifi.
Ik dacht dat het werkte maar nee. Verander ik het eind adres naar 192.168.1.137 dan geeft hij de IP adressen weg die vrij zijn als een apparaat ook 192.168.1.137 in beslag heeft, maar verander ik hem daarna naar 192.168.1.252 dan gaat ie weer verder bij de hoogste dus bij 192.168.1.138 en niet de IP adressen die nog vrij zijn onder 192.168.1.137
Reputatie 7
Badge +30
Tja, om heel eerlijk te zijn is dat volgensmij gewoon toegestaan volgens het DHCP protocol:
In some environments it will be necessary to reassign network
addresses due to exhaustion of available addresses. In such
environments, the allocation mechanism will reuse addresses whose
lease has expired. The server should use whatever information is
available in the configuration information repository to choose an
address to reuse. For example, the server may choose the least
recently assigned address. As a consistency check, the allocating
server SHOULD probe the reused address before allocating the address,
e.g., with an ICMP echo request, and the client SHOULD probe the
newly received address, e.g., with ARP.
Reputatie 7
Ik dacht dat het werkte maar nee. Verander ik het eind adres naar 192.168.1.137 dan geeft hij de IP adressen weg die vrij zijn als een apparaat ook 192.168.1.137 in beslag heeft, maar verander ik hem daarna naar 192.168.1.252 dan gaat ie weer verder bij de hoogste dus bij 192.168.1.138 en niet de IP adressen die nog vrij zijn onder 192.168.1.137Maar focus je nu eens op de situatie dat je problemen gaat ervaren. Dat was volgens mij dat als het hoogste IP adres uit de DHCP range uitgegeven was er geen andere IP adressen meer uitgegeven werden. Dat het IP adres telkens oploopt (of juist niet) vind ik voor nu helemaal niet interessant, het enige wat ik wil weten is of het reproduceerbaar zo is dat de DHCP server tot stilstand komt al het hoogste IP adres uit de range vergeven is.
Maar focus je nu eens op de situatie dat je problemen gaat ervaren. Dat was volgens mij dat als het hoogste IP adres uit de DHCP range uitgegeven was er geen andere IP adressen meer uitgegeven werden. Dat het IP adres telkens oploopt (of juist niet) vind ik voor nu helemaal niet interessant, het enige wat ik wil weten is of het reproduceerbaar zo is dat de DHCP server tot stilstand komt al het hoogste IP adres uit de range vergeven is.

Ga het proberen ik hou jullie op de hoogte.
Reputatie 7
Badge +18
Ik hoop dat @Paul_ zich geroepen voelt om even te reageren en dit issue door te zetten naar "modemdevelopment".

Hoi wjb. @Jaap-1955 is daar werkzaam, vandaar dat ik hem al op dit topic had geattendeerd. Zijn reactie bevat een aantal tips en praktische inzichten. Ik deel jullie mening dat er merkwaardige dingen gebeuren met die DHCP. En zo te lezen is de zoektocht nu naar een reproduceerbare error. Super! Ik stel voor om de reactie van Jasper nog even af te wachten. Wellicht leest Jaap mee maar anders zal ik hem direct mailen zodra we die laatste update van Jasper hebben.

Reageer