beantwoord

DHCP server van Telfort is een ramp!

  • 26 maart 2016
  • 10 reacties
  • 1457 keer bekeken

Reputatie 1
Badge
Reeds jaren maak ik gebruik van Telfort VDSL2 Internet, 30/3 verbinding. Dit tot grote tevredenheid. Afgelopen zondag op maandag nacht is echter mijn VDSL2 lijn gemigreerd naar een zogenaamde "VDSL2 SNI-F" lijn. Sindsdien zijn er constant problemen met het toekennen van een IP-adres vanuit de DHCP server van Telfort.

Ik maak gebruik van een FRITZ!Box 7390, nieuwste firmware (06.30). Het modem krijgt altijd keurig direct een DSL Sync en vervolgens gaat het modem naar de DHCP server zoeken middels een DISCOVER. Die DISCOVER wordt in 99 van de 100 keer niet beantwoord door de DHCP server, hetgeen resulteert dat het modem na 5 á 6 minuten actief zoeken zegt: DHCPv4 no answer on DISCOVER. Het modem staakt vervolgt het verkrijgen van een IP-adres en er komt dus geen Internet verbinding tot stand. De DSL Sync blijft keurig behouden, maar zonder IP-adres, default gateway, DNS, etc. werkt natuurlijk niks.

Aangezien Telfort geen support geeft op "eigen modems" (hetgeen ik absoluut kan begrijpen), wil men enkel testen met hun eigen Arcadyan modem. Echter ook daar, géén antwoord op de DHCP request. Het modem is echter wat "brutaler" en "blijft langer door gaan", waardoor het uiteindelijk toch lukt om de DHCP server te vinden, een request te doen en vervolgens ook een DHCP lease te krijgen. Echter doordat de DHCP server van Telfort zó slecht werkt, kan ik mijn FRITZ!Box dus niet meer gebruiken. Het is toch ronduit belachelijk dat een DHCP server zo verschrikkelijk slecht reageert op verzoeken? Bovendien heb ik voor mijn migratie nooit ergens last van gehad. Jaren nog geen één storing. Hebben hier meer mensen last van, met name na migratie naar een "SNI-F" lijn (wat dat ook moge zijn, want het lijkt geen echte "standaard" te zijn ofzo. Er is bijzonder weinig over te vinden).

Hier wat loggings uit het Arcadyan modem (de datum klopt niet, want het modem heeft nog geen verbinding met Internet en heeft derhalve nog geen tijd kunnen ophalen van een timeserver):

07/31/2015 00:05:03 DHCP Client: [ATM1]Send Discover
07/31/2015 00:05:03 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:05:00 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:57 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:54 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:51 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:50 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:04:47 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:44 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:41 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:38 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:37 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:04:34 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:31 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:28 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:25 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:24 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:04:21 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:18 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:15 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:12 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:11 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:04:10 192.168.2.2 Admin login success
07/31/2015 00:04:08 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:05 DHCP Client: [ATM1]Send Discover
07/31/2015 00:04:02 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:59 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:58 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:03:55 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:52 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:49 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:46 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:45 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:03:42 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:39 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:36 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:33 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:32 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:03:29 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:26 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:23 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:20 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:19 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:03:16 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:13 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:10 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:07 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:06 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:03:03 DHCP Client: [ATM1]Send Discover
07/31/2015 00:03:00 DHCP Client: [ATM1]Send Discover
07/31/2015 00:02:57 DHCP Client: [ATM1]Send Discover
07/31/2015 00:02:54 DHCP Client: [ATM1]Send Discover
07/31/2015 00:02:53 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:02:50 DHCP Client: [ATM1]Send Discover
07/31/2015 00:02:47 DHCP Client: [ATM1]Send Discover
07/31/2015 00:02:44 DHCP Client: [ATM1]Send Discover
07/31/2015 00:02:41 DHCP Client: [ATM1]Send Discover
07/31/2015 00:02:40 DHCP Client: [ATM1]Could not find DHCP daemon to get information
07/31/2015 00:02:37 DHCP Client: [ATM1]Send Discover
07/31/2015 00:02:34 DHCP Client: [ATM1]Send Discover

Hier een logging van de FRITZ!Box. Op 25-03-2016 om 19:00u heb ik geluk gehad. De DHCP server heeft toen wel het IP-adres toegekend. Om 19:00:39 de DSL Sync echter pas om 19:05:47 de DHCP toekenning. Ruim 5 minuten is veel te lang daarvoor (en valt nog nét binnen de maximale waarde dat de FRITZ!Box zoekt). 's Nachts reset van de DSL lijn, keurig weer DSL Sync, modem gaat zo'n 6 minuten zoeken, DHCP reageert niet en het resulteert in een "no answer on DISCOVER". De FRITZ!Box doet vervolgens ook géén poging meer, hetgeen natuurlijk vervelend is. Maar in beginsel moet die DHCP server van Telfort gewoon binnen een redelijke termijn reageren.



Hebben hier meer mensen last van? (met name na een SNI-F migratie).
icon

Beste antwoord door rogervdh 27 maart 2016, 14:13

Afgelopen nacht wederom een reset van de DSL lijn gehad (iedere nacht een terugkerend ritueel) en nu ging het perfect. Zie hieronder de logging uit de FRITZ!Box 7390:



Nu gaat 't precies zoals het hoort te gaan! Om 03:17:10 is de nieuwe DSL sync er en om 03:17:16 wordt het IP-adres vanuit de DHCP server toegekend. Hebben we het over 6 seconden (!) voor het zoeken van de DHCP server, het verzoek indienen voor een IP-adres én het daadwerkelijk toekennen van het IP-adres. Terwijl dit andere dagen nog niet in 6 minuten lukte... Bovendien, heb het betreffende modem al ruim 3 jaar aan een Telfort VDSL lijn hangen en echt nog nooit problemen mee gehad, totdat men overstapte op SNI-F. Hoe dan ook, het probleem zit bij Telfort (of hopelijk "zat bij Telfort").

@Babylonia, vooralsnog niet gereset naar fabrieksinstellingen. Ik betwijfel nu nog te sterk dat het een oplossing gaat bieden. Heb nog veel te sterk het vermoeden dat Telfort haar zaken onvoldoende op orde heeft m.b.t. SNI-F.
Bekijk reactie

Op dit topic kun je niet reageren. Wil je iets toevoegen, start dan een nieuw topic.

10 reacties

Reputatie 8
Badge +19
Het enige zinnige dat ik je kan vertellen over SNI-F is dat het de opvolger lijkt te zijn of te gaan worden van
de WBA (A + E) netwerktechniek.
Waar voorheen een hoop aandacht werd gegeven aan dit soort veranderingen (denk maar aan de overgang van ADSL naar VDSL, van WBA-A naar WBA-E) wordt er nu nogal geheimzinnig over gedaan en niets over losgelaten, zo lijkt het vooralsnog...

Hopelijk pakt een Telfort webcaremedewerker dit snel voor je op, andere bezoekers kunnen in deze weinig voor je betekenen als het probleem inderdaad veroorzaakt wordt door dat SNI-F geklooi.
Reputatie 8
Elders op het forum heb ik wel eens gelezen dat het verkrijgen van een IP-adres voor een eigen router wel tot 10 minuten kan duren. Eenmaal vastgelegd, is het daarna gewoon snel aanwezig na bijv. een fabrieks-reset.
Dus als je Fritz!box er na 6 minuten er de brui aan geeft, heel vervelend.

Zelf heb ik het achterliggende systeem van Telfort wat is gekoppeld aan mijn account ook wel eens "in de war gebracht" door de eerste aansluiting van mijn eigen router. In die zin dat --in mijn geval met een glasvezelverbinding-- de snelheden die bij mijn account horen totaal van slag waren. Een 100/100 verbinding was praktisch toen iets van 177/35


De Experia Box terug, was ook die van slag. Door meerdere keren achter elkaar een volledige fabrieks-reset te doen (zeker wel 3 keer) heb ik het systeem weer "normaal" gekregen. De communicatie is dan in ieder geval zodanig dat telkens opnieuw een "Tefort" router met hetzelfde MAC-adres contact legt en de standaard instellingen worden opgevraagd om door te sturen.

Met die procedure heb ik in mijn geval erna een stabiele "normale" verbinding gekregen als ik:
- De standaard Experia Box als 1e router heb aangesloten
- Een Telfort ZyXEL modem/router die ik een keer van marktplaats heb gekocht voor "testen" als 1e router
- Een Synology RT1900ac router als 1e router.

Bij elk van die routers, als ik die aansluit, krijg ik het IP-adres weer terug wat er de eerste keer een keer aan is gekoppeld. Dus bij elkaar wel 3 verschillende WAN IP's, maar wel altijd hetzelfde WAN IP bij elk van de "vaste" gebruikte 3 routers. Laatst bij test wel een keer met aansluiten van de ZyXEL router (ten aanzien van vragen op het forum), en daarna het terugplaatsen van de Experia Box, kreeg ik geen VOIP gegevens meer in mijn Experia Box. Ook niet na diverse resets, en voldoende lang wachten (>10 minuten).

Heb toen even de klantenservice gebeld, en die hebben de SIP-gegevens toen van daaruit gepushed, en de paar vreemde foutmeldingen geschoond. Was alles weer "netjes" en werkte het weer normaal.

Je zou in ieder geval eens kunnen beginnen, met diverse keren achter elkaar een volledige reset door te voeren, zowel met de Experia Box als met de Fritz!box. Kijken wat dat oplevert.

Overigens dat het meer dan 5 minuten kan duren voordat er een WAN IP ter beschikking is, is absoluut niet vreemd.
IPv4 adressen zijn zodanig schaars dat er niet een hele bunch aan "reserve" voorraad van aanwezig is om jou nieuwe IP-adressen te verschaffen bij elke andere router die jij aansluit. Juist omdat er schaarste is, koppelt men achterliggend in het systeem zoveel mogelijk een vast IP-adres aan het MAC-adres van een router. Dat moet dus tevens in het systeem van je persoonlijke account vastgelegd worden. Voordat heel die "riedel" aan doorlopen data en geldige "goedkeuring" is afgerond met achterliggende DNS-servers etc., kan daar dus absoluut meer tijd overheen gaan dan die vermeende 5 minuten die jij al te lang vind.

Bedenk dat het vastleggen van bijv. een domeinnaam 24-48 UUR kan duren voordat DNS-servers "verder weg" zijn aangepast om een geldige connectie te kunnen leggen met het domein. Dat geldt als marge waar je rekening mee dient te houden voor een domein. Een aanpassing van een "vast" IP voor je internet account is vergelijkbaar, maar dan dichterbij de bron. Die aanpassing in 5-10 minuten voordat jezelf vooruit kunt is dus absoluut niet zo vreemd.
Reputatie 1
Badge

Overigens dat het meer dan 5 minuten kan duren voordat er een WAN IP ter beschikking is, is absoluut niet vreemd.
IPv4 adressen zijn zodanig schaars dat er niet een hele bunch aan "reserve" voorraad van aanwezig is om jou nieuwe IP-adressen te verschaffen bij elke andere router die jij aansluit. Juist omdat er schaarste is, koppelt men achterliggend in het systeem zoveel mogelijk een vast IP-adres aan het MAC-adres van een router. Dat moet dus tevens in het systeem van je persoonlijke account vastgelegd worden. Voordat heel die "riedel" aan doorlopen data en geldige "goedkeuring" is afgerond met achterliggende DNS-servers etc., kan daar dus absoluut meer tijd overheen gaan dan die vermeende 5 minuten die jij al te lang vind.

Bedenk dat het vastleggen van bijv. een domeinnaam 24-48 UUR kan duren voordat DNS-servers "verder weg" zijn aangepast om een geldige connectie te kunnen leggen met het domein. Dat geldt als marge waar je rekening mee dient te houden voor een domein. Een aanpassing van een "vast" IP voor je internet account is vergelijkbaar, maar dan dichterbij de bron. Die aanpassing in 5-10 minuten voordat jezelf vooruit kunt is dus absoluut niet zo vreemd.


Het is zeer ongebruikelijk dat het toekennen van een WAN IP adres meer dan 5 minuten duurt. Ten eerste krijg ik keer op keer exact hetzelfde IP adres toegewezen in het Arcadyan als FRITZ!Box modem, ondanks dat beide (uiteraard) een ander MAC adres hebben. Blijkbaar wordt het IP-adres toegewezen op lijn niveau. In het verleden had ik inderdaad twee verschillende IP-adressen bij verschillende modems, maar nu dus niet meer. Dus de DHCP server zou het IP-adres binnen enkele seconden moeten kunnen uitgeven. Bovendien heb je in eerste instantie een DISCOVER. Het modem roept dus feitelijk "DHCP server, waar ben je, laat iets van je horen, op welk adres kan ik jou bereiken?". Dáár gaat het in beginsel al fout... In de log van het Arcadyan modem kun je het mooi zien dat het modem iedere 3 seconden zo'n oproep uitzendt! Na 4 pogingen zegt het modem "Could not find DHCP daemon to get information". Vervolgens gaat het modem weer door. Hieruit kun je concluderen dat het normaliter gebruikelijk is dat de DHCP server binnen 1 á 2 seconden van zich laat horen. Daarna kan het modem een REQUEST doen, dus "Ken mij een IP-adres toe". Maar zover komen we niet eens... Als je in het originele bericht kijkt, dan zie je slechts 'n klein deel van de logging...zo gaat het gewoon minuten lang door.

Bovendien, op de "niet SNI-F lijn" heb ik nog nóóit een probleem gehad. Verder heeft AVM (fabrikant FRITZ!Box) blijkbaar ingesteld dat het modem zo'n 6 minuten naar een DHCP server moet zoeken. Die 6 minuten zal niet "zomaar" gekozen worden. Onder normale omstandigheden heeft een DHCP server al lang van zich laten horen. Door die nieuwe SNI-F techniek is dat blijkbaar veelal niet het geval. Ik kan niet anders concluderen dan dat het hele SNI-F gebeuren een zeer negatieve uitwerking heeft op het DHCP onderhandelings proces. Onderbouwen kan ik dat niet, maar het loopt niet lekker, zelfs niet met de originele modems van Telfort. Men heeft het geluk dat die modems blijkbaar oneindig door gaan met verzoeken uitzenden en daarom merken de klanten er uiteindelijk weinig of niks van, terwijl een FRITZ!Box bezitter met een niet werkende lijn zit (tenzij de DHCP server -met veel geluk- binnen 6 minuten van zich laat horen).

Beetje jammer dat Telfort niks van zich laat horen in deze thread, maar waarschijnlijk té technisch van aard... Jammer!
Reputatie 8
Kennelijk werkt die techniek iets anders als mijn ervaring met glasvezel.
Jij krijgt nog niet eens de beschikking over een ander IPv4 adres als je er een andere router aan hangt.
En nee, het is niet te vergelijken met een normale DHCP IP-adres uitgave, omdat het achterliggende systeem in basis zoals het wordt ingezet niet is afgestemd om er telkens andere IP-adressen aan te hangen, maar juist om zoveel mogelijk met "dezelfde" IP-adressen te werken in de schaarste aan IPv4 adressen die er nu eenmaal zijn.

Maar ondanks je aanvullende informatie, heb je de Experia Box gewoon eens een aantal keren achter elkaar een fabrieksreset gegeven en gekeken wat dat oplevert? En als dat dan functioneert, hetzelfde met de Fritz!box?
Ik zit ook op zo'n SNI-F verbinding sinds bijna 'n jaar en bij mij staat er dit in het log:

03/26/2016 20:33:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 20:33:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 20:30:33 192.168.2.1 Admin login success
03/26/2016 20:28:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 20:28:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 20:23:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 20:23:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 20:18:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 20:18:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 20:13:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 20:13:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 20:08:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 20:08:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 20:03:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 20:03:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 19:58:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 19:58:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 19:53:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 19:53:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 19:48:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 19:48:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 19:43:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 19:43:24 DHCP Client: [ATM1]Send Request, Request IP=145.
03/26/2016 19:38:24 DHCP Client: [ATM1]Receive Ack from 145.132.123.1,Lease time=600
03/26/2016 19:38:23 DHCP Client: [ATM1]Send Request, Request IP=145.


Dit is niet mijn expertise maar zoals ik het lees vind de oproep van de modem vrijwel onmiddellijk gehoor bij de DHCP sever?
Waarna het vraag en antwoord spelletje direct opnieuw begint.
Het gaat dus niet in alle gevallen fout met kennelijk. Of interpreteer ik dat wat in het log staat onjuist?
Reputatie 8
En @Nisan welke router gebruik jij daarvoor?
De standaard Experia Box?
En @Nisan welke router gebruik jij daarvoor?
De standaard Experia Box?


Correct. 'n gewone V8
Reputatie 8
Vandaar dat er wellicht geen reden is om het achterliggende account-systeem in de war te laten brengen, en je om die reden meteen een lease krijgt bij je IP-adres.
Reputatie 1
Badge
Afgelopen nacht wederom een reset van de DSL lijn gehad (iedere nacht een terugkerend ritueel) en nu ging het perfect. Zie hieronder de logging uit de FRITZ!Box 7390:



Nu gaat 't precies zoals het hoort te gaan! Om 03:17:10 is de nieuwe DSL sync er en om 03:17:16 wordt het IP-adres vanuit de DHCP server toegekend. Hebben we het over 6 seconden (!) voor het zoeken van de DHCP server, het verzoek indienen voor een IP-adres én het daadwerkelijk toekennen van het IP-adres. Terwijl dit andere dagen nog niet in 6 minuten lukte... Bovendien, heb het betreffende modem al ruim 3 jaar aan een Telfort VDSL lijn hangen en echt nog nooit problemen mee gehad, totdat men overstapte op SNI-F. Hoe dan ook, het probleem zit bij Telfort (of hopelijk "zat bij Telfort").

@Babylonia, vooralsnog niet gereset naar fabrieksinstellingen. Ik betwijfel nu nog te sterk dat het een oplossing gaat bieden. Heb nog veel te sterk het vermoeden dat Telfort haar zaken onvoldoende op orde heeft m.b.t. SNI-F.
Reputatie 8

@Babylonia, vooralsnog niet gereset naar fabrieksinstellingen. Ik betwijfel nu nog te sterk dat het een oplossing gaat bieden. Heb nog veel te sterk het vermoeden dat Telfort haar zaken onvoldoende op orde heeft m.b.t. SNI-F.

Mooi dat het nu wel werkt en vooralsnog lijkt opgelost.
Verder vertelde ik je alleen mijn ervaring, wat "na het in de war raken" van het achterliggend gekoppelde internet-account systeem wat daarmee samenhangt, en inclusief de eerste keer dat ik ook lang moest wachten op een IP-adres, met die herhaalde keren resetten achter elkaar van de Experia Box, een herstel bracht. Eveneens voor de andere routers die erop aangesloten werden.

Als je dat dan niet eens gaat proberen, komt mij wat eigenwijs over. Een reset kan nooit kwaad en is feitelijk een van de eerste zaken om toe te passen en te proberen bij storingen. Nee, heb je, ja kun je krijgen. Dat je Telfort dan beticht dat zij hun zaken niet op orde zouden hebben, lijkt mij met het niet eens proberen van reset(s) een onterechte aanname.

Als je opziet tegen het opnieuw moeten instellen van persoonlijke settings na een reset, kun je daar ook in voorzien door van de instellingen een back-up te maken, en later (als de basis werkt na een reset of meerdere malen reset) weer opnieuw in te laden.