Systeem kon het extern IP-adres 0.0.0.0/0:0:0:0:0:0:0:0 niet registreren

[Briolet]

Deze meldingen heb ik met DSM 4.2 ook een paar keer gehad en nu voor het eerst weer. Het lijkt me toch dat DSM moet kunnen zien dat dit een foutief IP is en moet registratie overslaan.

Ik heb even in het log gekeken. Ik heb sinds een week 2 DDNS services naast elkaar lopen en normaal worden ze elke 24 uur gelijktig geregistreerd. Nu, met het foute IP zag ik:

Code: [Selecteer]

Information,Systeem,2014/09/29 06:37:58,SYSTEM,System successfully registered [0.0.0.0] to [xxx.serveblog.net] in DDNS server [NoIP.com].
Error,Systeem,2014/09/29 06:37:55,SYSTEM,System failed to register [0.0.0.0/0:0:0:0:0:0:0:0] to [xxx.i234.me] in DDNS server [Synology] because of [Failed to resolve IP address of DDNS server].

Dus No-IP geeft geen foutmelding terug op dat IP (maar negeert dat intern wel) En Synology's ddns systeem geeft wel een fout terug.
Verder maak ik uit de structuur op dat aan No-IP alleen een IPv4 adres doorgegeven wordt en aan Synology een IPv4 en IPv6 adres.

Een paar minuten later werden beide IP's succesvol geregistreerd. 2 uur later echter weer dezelfde foutmelding en kort erna wel weer de goede registratie. Geen idee wat er mis ging. Zonder internetverbinding kan de router het adres 0.0.0.0 aannemen, dus misschien een kortdurende storing op de lijn want de verbinding was er wel anders was er geen succesvolle registratie met No-IP. Of de nas had geen verbinding met beide servers, maar dan vind ik de twee verschillende loggings vreemd.
Het is in elk geval een bug dat hij 0.0.0.0 probeert te registreren.

[TonVH]

Zelfde probleem heb ik ook met een DS214se onder DSM 5.1. Ik zie dezelfde foutmeldingen.

Information,Systeem,2014/09/29 07:21:51,SYSTEM,System successfully registered [0.0.0.0] to [heb.loginto.me] in DDNS server [NoIP.com].
Error,Systeem,2014/09/29 07:21:49,SYSTEM,System failed to register [0.0.0.0/0:0:0:0:0:0:0:0] to [Nicole.myDS.me] in DDNS server [Synology] because of [Bad parameter].

Zie ook: http://www.synology-forum.nl/ddns-extern-benaderen/synology-dns-heartbeat/new/#new  Wellicht topic samenvoegen.

[Briolet]

In mijn geval denk ik dat het probleem in de internetverbinding zelf ligt. Volgens de router handleiding van mijn Ubee, neemt hij IP 0.0.0.0 aan als de internetverbinding wegvalt.
De nas reageert ogenblikkelijk op het veranderde IP en probeert het te registreren. Synology is de eerste  en daar faalt hij bij. Een paar seconden later probeert hij het bij No-IP en dat lukt wel omdat dan de internetverbinding weer okay is.
Na erover nagedacht te hebben is dat de meest logische verklaring voor de verschillende reacties tussen de twee ddns servers. Ik zal dat vanavond eens testen door handmatig de coaxkabel los te trekken.

En dan een bugmelding doen, want de nas moet weten dat 0.0.0.0 geen reëel IP adres is en gewoon negeren. Blijkbaar zijn er ook routers die bij verlies van contact hun laatst bekende IP blijven gebruiken.

[Briolet]

Volgens de router handleiding van mijn Ubee, neemt hij IP 0.0.0.0 aan als de internetverbinding wegvalt.

Wel weer vreemd dan dat in het router-log staat dat er de laatste 17 dagen 33 T3 timeouts waren en 1 T4 timeout. In totaal heb ik vannacht 2 keer de 0.0.0.0 melding gehad. (en niet 33 keer of maar 1 keer)

[TonVH]

Ik heb die heartbeat melding gehad op een moment waarop ik zeker weet dat er wel verbinding was tussen NAT en rest Internet. Er liep namelijk een grote backup van extern naar die NAS. Die backup was zonder meer abrupt gecancelled als de verbinding verbroken was geweest.

[Briolet]

@Ton: Dan een ander idee voor de oorzaak, omdat mijn nas de hele ochtend al op 99% cpu loopt door een cloud sync proces:

Is de nas niet te druk met andere zaken, waardoor hij daardoor een fout heeft met het ophalen van dat externe IP en die fout wordt als IP=0.0.0.0 geïnterpreteerd?

Die drukte op de nas is bij mij het enige nieuwe en ik begrijp dat de nas bij jou ook druk bezig was ten tijde van de melding.

[TonVH]

Drukte kwam al eerder in mij op omdat ik gemerkt heb dat de DS214se erg snel boven de 90% zit. Overigens met goede prestaties zowel intern als extern.

Ik heb zelf "te druk" eigenlijk afgewezen want ik neem toch aan dat ze een goede scheduling met prioriteiten hebben geïmplementeerd. Hierdoor horen m.i. interne processen de hoogste prioriteit te krijgen. Overigens zou ik bij failure van DNS direct en meerdere malen herproberen en pas na bijv. 5 mislukte pogingen overgaan tot een melding. Linux is tenslotte afgeleid van Unix en dat heeft vanaf dag 1 multi tasking/processing gekend.


Maar het inderdaad opvallend dat het optreedt bij drukte beter gezegd hoge belasting.

[Briolet]

Op zich zit het wel goed met die prioriteiten.

Ik gebruik al een jaar de radius server van de nas om de Wifi inlogs te reguleren. Dat heeft eigenlijk nooit problemen gegeven met authenticatie als de nas vol belast was. Zelfs als hij zo druk is dat inloggen via dsm traag gaat, loopt de authenticatie via de radius server vlot.
En sinds een paar week gebruik ik nu de DNS server op de nas. Ook bij volle cpu belasting, heb ik er geen last van bij het surfen, dus ook de dns server heeft een hoge prioriteit.

Maar het blijft frappant dat het ophalen van het externe IP mislukte onder hoge belasting. Toeval?

[TonVH]

Ik moest net (alles remote) de router resetten en nog voordat de router melde dat hij off-line ging kwam de melding van Heartbeat al binnen.

Dus wellicht is e.e.a. toch te scherp afgestemd. Bedoel hiermee dat de melding direct verstuurd wordt terwijl een controle na 1 (tot max. 5 min). zou hebben uitgewezen dat er niets echt mis was.

[Briolet]

De heartbeat heeft hier niets mee te maken. Dat is iets speciaals van Synology dat er voor zorgt dat je een e-mail krijgt als er een tijd geen update geweest is. Standaard staat dat aan, maar ik heb het gisteren uit gezet toen ik realiseerde dat die heartbeat voor mij niet belangrijk is. No-IP kent het ook niet.

Ik heb vanochtend mijn router gereset. Dat gaf bij mij ook de melding in het log:

Code: [Selecteer]

Error,Systeem,2014/09/30 09:36:20,SYSTEM,Failed to send email. (Failed to connect mijndomein.nl:465).
Error,Systeem,2014/09/30 09:35:55,SYSTEM,System failed to register [0.0.0.0/0:0:0:0:0:0:0:0] to [xxx.i234.me] in DDNS server [Synology] because of [Failed to resolve IP address of DDNS server].
…
Information,Systeem,2014/09/29 15:29:41,System successfully change DDNS Heartbeat from [yes] to [no] of [Synology].
Alleen vreemd dat hij nu alleen met de Synology ddns server een error geeft en voor mijn No-IP server niet eens een poging tot updaten gedaan heeft.

Over het log van de mail moest ik even nadenken voordat ik hem begreep. Ik draai een eigen DNS server, dus een IP  voor mijn eigen domein kon hij ook zonder internet connectie vinden. Dat is echter het WAN IP van mijn router, dus bij het verbinden met de interne mailserver ging het mis omdat dat verkeer via het WAN IP loopt.

In elk geval vreemd dat een router reset zo'n melding geeft. Met alleen No-IP had ik nooit een melding bij een router reset. En nu heeft No-IP ook geen ddns update geprobeerd.
In elk geval een bug die ik zal proberen te formuleren.

[TonVH]

Ik heb contact gehad met Synology en zij hebben een kijkje genomen. Deze week kreeg ik bericht dat het probleem sedert enkele dagen verholpen zou moeten zijn. Of dat klopte wist ik niet want de melding werd direct bij binnenkomst verwijderd maar dat is ongedaan gemaakt en ik heb nu sedert 3 dagen geen melding meer gezien.

[Briolet]

Ik wilde het weten en heb mijn router gisteravond even ge-restart. Deze korte onderbreking was al weer voldoende voor deze systeemmelding bij mij. Een mailtje komt in deze situatie niet omdat hij zonder router niet verstuurt kan worden, ook al loopt het gehele mailproces binnen de eigen mailserver op de nas.

Dus misschien is één bron aangepakt, maar als de router door ontbrekend internetsignaal even zelf het IP 0.0.0.0 genereert, wordt dat IP nog steeds door de nas als een geldige IP aanpassing gezien en probeert dit via ddns aan te passen.

[TonVH]

Dat ene mailtje lijkt mij niet erg want wat mij stoorde was dat er continu dergelijke mailtjes verstuurd weden zonder dat er sprake was van een verbroken verbinding. En ik nu al eventjes geen mailtjes meer gezien.

De reden dat ik naast de Noip DNS die van Synology gebruik is vanwege de heartbeat. De betreffende NAS staat 15 Km verder en praktisch onbewaakt. Dus dan is het handig als je bericht bij uitval krijgt ook als je op dat moment de betreffende NAS niet gebruikt.