Skip to main content
Beantwoord

"udhcpc: Sending discover..." zorgt voor gigantische ping latency


Ik heb onlangs gemerkt dat mijn internetverbinding een apart mankement heeft. Ongeveer elke minuut heb ik ping tijden die oplopen tot wel 3000ms. Waardoor veel applicaties haperen of verbinding verliezen (Remote Desktop, VPN & Multiplayer games).

Ik heb zelf al wat troubleshooting gedaan, en wat mij is opgevallen, is dat deze latency intern ligt bij mijn modem (Zyxel T-56). Deze latency toont zich namelijk ook bij interne communicatie als ik het modem zelf direct ping vanaf mijn laptop (modem heeft ip 192.168.1.1):

De verbinding is heel stabiel, met uitzondering van de enkele pings die tussen de 2000 en 3000 ms duren. (beide bekabeld en via WiFi).

Deze uiterst lange ping tijden komen exact overeen met de “udhcpc: Sending discover...” log entries van mijn modem:

Elke keer dat ik merk vanaf mijn laptop dat een ping langer dan 2000ms duurt, zie ik een nieuw log bericht verschijnen op het modem. En andersom, zodra ik zo’n log bericht zie, is een van de pings langer dan 2 seconden bezig om reactie te ontvangen. En zo nu en dan kan het ook wat langer duren, waarop de pings zo lang duren dat er aangenomen wordt dat er helemaal geen verbinding is (packet loss / connection timeout).

Ik heb op deze forums ook gelezen dat de “udhcpc: Sending discover...” vaak gerelateerd is met IPTV. Maar daar heb ik geen abonnement voor. Dus lijkt het er voor mij op alsof mijn modem continu een IP probeert op te vragen voor de IPTV interface, maar deze nooit zal ontvangen. (bijgevoegd een afbeelding van de status van de interfaces, zonder IP en MAC uiteraard):

Een van de mogelijke stappen die ik zou kunnen bedenken is om de ETH_IPTV interface te verwijderen, zodat daar ook geen IP voor opgevraagd kan worden door het modem. Maar ik weet niet of dit een mogelijkheid is met telnet / SSH. Omdat ik me kan bedenken dat zulke aanpassingen aan de firmware best wel gelimiteerd zijn.

Daarnaast weet ik ook niet of dit probleem veelvoorkomend is of niet. Omdat dit probleem gemakkelijk onopgemerkt onder de radar kan gaan.

Beste antwoord door rvk01

Sigma-Erebus schreef:

Ik denk dat ik inderdaad nog iets anders heb gevonden. elke minuut (tot nu toe redelijk in de buurt van de udhcpc log berichten), krijg ik ook dit in mijn security logs. En in plaats van een paar seconden vertraging, merk ik dat deze berichten tot op de seconde matchen met de ping timeout:

Ja, dat ziet er meer uit als een probleem. Overigens heeft dit dus niets met die dhcp discovery te maken. Maar een PING OF DEATCH is wel een probleem.

Dat zijn nogal wat pings die je intern naar buiten doet. Als de DoS detectie daarop reageert kan dat wel een probleem geven.

Sigma-Erebus schreef:

Deze ping requests worden ongeveer in een window van 1-2 seconden verstuurd naar 150+ endpoints, en ik weet niet of het de rekenkracht is om deze attack alerts te verwerken, of dat er een timeout geconfigureerd staat.

Schakel dan de DoS eens uit in de router. Uiteraard kan een DoS ook van binnen uit je netwerk gedaan worden. (Beveiliging > Firewall > DoS)

Sigma-Erebus schreef:

De reden dat ik weet dat dit False-Positives zijn, is dat dit de Private Internet Access VPN client is die zijn servers pingt om latency te checken. En zeker gezien dat het uitgaand verkeer is, en niet inkomend, snap ik niet waarom dit een firewall activeert.

Kun je daar niet instellen dat er niet in 1 seconden zoveel pings verstuurd worden? Dit kan toch wel uitgestreken worden over een minuut ofzo?

Het lijkt mij overigens absurd om elke minuut 150+ endpoints te pingen om te bepalen welke de beste zou zijn. Dit kan echt wel op een wat langere interval.

Maar goed… ik kan me goed voorstellen dat de DoS hier ingrijpt met een PING OF DEATH.

 

Bekijk origineel

10 reacties

rvk01
Forum|alt.badge.img+3
  • is een legendarische user
  • 1697 reacties
  • 11 juli 2025

Ik denk niet dat het (alleen) aan die “Sending discover” zal liggen. Dat is bij iedereen zo (ook bij mij) maar nergens krijg je die vertraging.

Eerste vraag is uiteraard… test je dit uit met een computer rechtstreeks bekabeld aan de Zyxel? (geen switch ertussen)

Doet zich dit ook voor als je een ping naar b.v. een andere computer/IP op je interne netwerk doet?

Omdat dit op je internet netwerk zit, kun je het natuurlijk goed onderzoeken.

Helaas kun je op de pagina https://192.168.1.1/Diagnostic zelf geen aantal pings opgeven, anders zou je ook kunnen testen vanuit de router naar buiten. En nee, we hebben geen SSH toegang tot de router. Die is zeer gelimiteerd met de custom firmware van Odido.

 


rvk01
Forum|alt.badge.img+3
  • is een legendarische user
  • 1697 reacties
  • 11 juli 2025

@Odido Graag mijn post uit de spambox halen hier in dit topic.

 


Marciano van Odido
Moderator
Forum|alt.badge.img+9

Hoi ​@rvk01, ik heb je bericht uit spam gehaald. Sorry voor het ongemak. Mocht het nog een keer gebeuren, mag je mij taggen. Ik check spam elke dag, maar een tag kan geen kwaad! 😄


  • Auteur
  • is een nieuwe Poster
  • 4 reacties
  • 11 juli 2025

Ik denk dat ik inderdaad nog iets anders heb gevonden. elke minuut (tot nu toe redelijk in de buurt van de udhcpc log berichten), krijg ik ook dit in mijn security logs. En in plaats van een paar seconden vertraging, merk ik dat deze berichten tot op de seconde matchen met de ping timeout:

Alhoewel, weet ik ook dat dit False-Positive attacks zijn. Dit zijn namelijk ping requests die vanuit mijn lokale netwerk naar buiten gaan. En even voor context, in dit voorbeeld is mijn laptop verbonden met de WiFi van mijn Zyxel modem. Normaliter heb ik inderdaad een router ertussen staan i.v.m. het WiFi bereik en de bekabeling in de woning (studentenwoning).

Deze ping requests worden ongeveer in een window van 1-2 seconden verstuurd naar 150+ endpoints, en ik weet niet of het de rekenkracht is om deze attack alerts te verwerken, of dat er een timeout geconfigureerd staat.

De reden dat ik weet dat dit False-Positives zijn, is dat dit de Private Internet Access VPN client is die zijn servers pingt om latency te checken. En zeker gezien dat het uitgaand verkeer is, en niet inkomend, snap ik niet waarom dit een firewall activeert.

Betreffende de vraag of dit ook voor andere apparaten in mijn interne netwerk gebeurt, nee. Het gebeurt alleen als de Zyxel onderdeel is van de route. Stel dat ik mijn router (niet de Zyxel) direct ping, is dat geen probleem, maar zodra ik de router via de Zyxel ping, dan begint het weer.

Dan verandert de vraag een beetje: is er een mogelijkheid om ervoor te zorgen dat de Zyxel deze false-positives niet meer blokkeert?

 


rvk01
Forum|alt.badge.img+3
  • is een legendarische user
  • 1697 reacties
  • Antwoord
  • 11 juli 2025
Sigma-Erebus schreef:

Ik denk dat ik inderdaad nog iets anders heb gevonden. elke minuut (tot nu toe redelijk in de buurt van de udhcpc log berichten), krijg ik ook dit in mijn security logs. En in plaats van een paar seconden vertraging, merk ik dat deze berichten tot op de seconde matchen met de ping timeout:

Ja, dat ziet er meer uit als een probleem. Overigens heeft dit dus niets met die dhcp discovery te maken. Maar een PING OF DEATCH is wel een probleem.

Dat zijn nogal wat pings die je intern naar buiten doet. Als de DoS detectie daarop reageert kan dat wel een probleem geven.

Sigma-Erebus schreef:

Deze ping requests worden ongeveer in een window van 1-2 seconden verstuurd naar 150+ endpoints, en ik weet niet of het de rekenkracht is om deze attack alerts te verwerken, of dat er een timeout geconfigureerd staat.

Schakel dan de DoS eens uit in de router. Uiteraard kan een DoS ook van binnen uit je netwerk gedaan worden. (Beveiliging > Firewall > DoS)

Sigma-Erebus schreef:

De reden dat ik weet dat dit False-Positives zijn, is dat dit de Private Internet Access VPN client is die zijn servers pingt om latency te checken. En zeker gezien dat het uitgaand verkeer is, en niet inkomend, snap ik niet waarom dit een firewall activeert.

Kun je daar niet instellen dat er niet in 1 seconden zoveel pings verstuurd worden? Dit kan toch wel uitgestreken worden over een minuut ofzo?

Het lijkt mij overigens absurd om elke minuut 150+ endpoints te pingen om te bepalen welke de beste zou zijn. Dit kan echt wel op een wat langere interval.

Maar goed… ik kan me goed voorstellen dat de DoS hier ingrijpt met een PING OF DEATH.

 


  • Auteur
  • is een nieuwe Poster
  • 4 reacties
  • 11 juli 2025

Yup, DoS beveiliging uitgezet en het probleem is weg, dus het zal wel een timeout zijn geweest die als response op de DoS op de verbinding geplaatst wordt.

En nee, ik kan de pings niet uitstrijken over een langere termijn, gezien dat ik niet de source code van de VPN client kan aanpassen. Wel heb ik in de instellingen deze gevonden:

Waarvan ik niet snap waarom deze standaard aan staat, gezien dat het dus 150+ pings per minuut stuurt in zo’n korte burst. Vind ik veel voor een achtergrondapplicatie die je niet actief aan het gebruiken bent. Ik heb deze instelling uitgezet en de DoS beveiliging weer ingeschakeld. De resultaten (via WiFi) zijn een stuk stabieler:



En ja, het verbaast me dan ook niet echt dat de beveiligingen in acht springen met zoveel pings in korte termijn. Want van een WireShark trace is inderdaad ook te zien dat de eerste ~10 pings nog een reactie krijgen, waarna de rest geblokkeerd worden. Maar wellicht iets wat naar de developers van PIA gecommuniceerd kan worden. In ieder geval, heel erg bedankt voor de hulp.


rvk01
Forum|alt.badge.img+3
  • is een legendarische user
  • 1697 reacties
  • 11 juli 2025

Ja, met even zoeken op PIA en ping of death kom ik dit probleem wel vaker tegen 😉

https://github.com/pia-foss/desktop/issues/13

https://github.com/pia-foss/desktop/issues/39

Inderdaad niet handig dat dit standaard aan staat. 

Fijn dat we de oorzaak in ieder geval te pakken hebben. (Source code is overigens beschikbaar dus je kunt ook zelf aan de gang 😆 of kijken of er nog meer issues zijn die echt hetzelfde zijn en het anders melden.)

 


  • Auteur
  • is een nieuwe Poster
  • 4 reacties
  • 11 juli 2025

Ja, ik heb ze ook even een berichtje gestuurd via het support formulier. Reactie was dat het doorgestuurd zal worden naar het development team om te kijken of ze de frequentie wellicht wat kunnen aanpassen als de software in de achtergrond open staat. Want als pings door DoS geblokkeerd worden, kun je ze niet echt gebruiken om latency te meten :P
 

 


rvk01
Forum|alt.badge.img+3
  • is een legendarische user
  • 1697 reacties
  • 11 juli 2025

Hun software zelf is open source en er is dus al zo'n issue/feature request met exact dezelfde suggesties (feb.2022). Dus of dit snel aangepast zal worden... Ik ben benieuwd.


  • Auteur
  • is een nieuwe Poster
  • 4 reacties
  • 11 juli 2025

Tja, we zullen zien, misschien dat iets meer activiteit betreffende die problemen een motivatie is om de al bestaande fix te mergen. En zo niet, weet ik nu wel hoe ik het voor mezelf moet oplossen


Reageer


Cookiebeleid

Wij gebruiken cookies om uw bezoekers ervaring te verbeteren en te personaliseren. Ga je akkoord, of ga je door op de website dan ga je akkoord met ons cookiebeleid. Meer informatie.

 
Cookie instellingen