Skip to main content

Ik ben al telefonisch in gesprek geweest met de Odido klantenservice en zij hebben mij naar dit forum verwezen, omdat hier meer medewerkers met verstand van zaken zouden zitten (apart). 

 

Ik heb het probleem dat mij Ubiquiti Cloud Key geen IP-adres krijgt van de Zyxel T-56 bij glasvezelinternet van Odido. Dit ligt 100% aan het modem. De cloud key is nieuw en nooit eerder aangesloten geweest. Ik heb alles al geprobeerd en uitgesloten:

Ik heb de cloud key aangesloten middels een UTP-kabel. In eerste instantie via een switch, later direct op het modem. Als ik de Cloud key inplug en ik de setup start, gaat de setup als eerste verbinden met internet. Dit lukt niet. Het apparaat krijgt geen IP van de Zyxel en valt terug op zijn standaard fall back IP.

Ik heb al andere kabels geprobeerd, via de switch, direct in het modem, andere UTP-poorten in het modem, factory reset van het modem, factory reset van de cloud key. Ik heb firewalls compleet uit gezet (hoewel ik niet verwacht had dat dit zou helpen). Geprobeerd met een ip-bereik van 192.168.0.x en 192.168.1.x.

Ik heb een RMA van de cloud key gehad, zij pluggen de cloud key in en het heeft meteen internetverbinding. Ik heb met hun support alle mogelijke andere opties die ik aan kan passen binnen de cloud key geprobeerd, geen enkele heeft het probleem opgelost. Het probleem blijft.

 

Ik heb de cloud key meegenomen naar mijn ouders om het daar in het netwerk te pluggen, direct verbinding zonder problemen. Ik heb vervolgens een statisch IP-adres ingesteld voor het apparaat en ditzelfde statische IP-adres binnen mijn eigen netwerk ook gebruikt voor de cloud key, in de hoop dat dit zou werken. Nee dus. 

Ik ben nu al 3 weken met allerlei oplossingen bezig om mijn cloud key te laten verbinden, met verschillende support sites, maar tot op heden nog geen oplossing gevonden. Support aan de telefoon was ook om te huilen. Eerste persoon die ik sprak bleef maar doorgaan over wifi-instellingen, ondanks dat ik al 3x had gezegd dat de cloud key aan de UTP-kabel zat. Hij wilde niet luisteren en heeft van afstand een wifi-instelling in de router veranderd wat zou moeten helpen, ondanks dat ik uitlegde dat dit niet zou helpen. Als het niet hielp, moest ik maar terugbellen.

Uiteraard hing ik de volgende dag weer aan de telefoon. Toen een dame gesproken die ten minste wel de moeite heeft genomen het probleem op te lossen en niet kon begrijpen dat haar collega wifi-instellingen had veranderd, omdat dit het probleem niet zou oplossen. 

Lang verhaal kort: zij kon het probleem ook niet oplossen, ondanks dat ze wel moeite heeft gedaan. Ik heb uitgelegd dat ik graag een nieuw modem wilde van een ander merk, omdat dit probleem specifiek is voor Zyxel. Er zijn online meerdere meldingen van dergelijke problemen bij het Zyxel modem. Ook met andere merken apparatuur. Zyyxel kan ik niet benaderen voor support, als ik daar een ticket in wil dienen, moet ik het serienummer invullen en krijg ik de melding dat ik bij hen geen ticket in kan dienen en dat ik bij mijn ISP moet zijn. Tot zover de support van een bedrijf dat gewoon gebruikers met problemen zou moeten helpen….

Volgens de dame van support zijn er geen andere opties voor een ander modem. Zij zag online ook dat dit modem problemen geeft. Toen ik zei dat ik dit raar vond dat Odido een product levert dat niet functioneert, zei ze dat alles wel goed werkt en dat dit een extra service is. Nee, het werkt niet. Het modem hoort apparaten binnen het netwerk een IP te geven zodat deze met internet kunnen verbinden. Dat dit modem dat met sommige apparaten wel doet, betekent niet dat dit werkt. Bij sommige apparaten doet het modem dat niet. Het werkt dus niet. Daarnaast wordt er ook nog eens een modem geleverd zonder bridge-modus. Anders had ik er gewoon een router achter kunnen hangen om het probleem op te lossen, maar om de een of andere vage reden, kan dit ook niet. Ook dat is een keuze van Odido zelf geweest.

Uiteindelijk moest ik mij hier maar melden, in de hoop dat hier iemand het probleem kan oplossen. Hopelijk is het probleem oplosbaar. Graag hulp hierbij

 

Zo niet, zie ik nog maar 3 opties: Odido levert een nieuw wifi6-modem van een ander merk (wat volgens support niet kan), Odido vergoed de aankoop van een nieuw modem, ontbinding van het contract omdat verwachte service niet geleverd kan worden.

Kijk eens in de log van de Zyxel op het moment dat de Ubiquity is aangesloten en een IP-adres vraagt.
Als daar regelmatig regels voorkomen van de vorm:

dnsmasq-dhcp: DHCP, IP range 192.168.1.1 -- 192.168.1.200, lease time 1d en
dnsmasq-dhcp: read /etc/ethers - 0 addresses

dan is dit probleem bekend: de dhcp-afhandeling in de Zyxel is brak, en kan niet overweg met ‘moderne’ dhcp-aanvragen. Wat dan een mogelijkheid is, is de Ubiquity handmatig een IP-adres toe te kennen.
192.168.1.2 met netmask 255.255.255.0 en standaard gateway 192.168.1.1.

Hier uitleg hoe dat te doen: https://community.ui.com/questions/Static-IP-on-Cloud-Key-Gen2-Plus/2db3a127-3628-4e93-afd0-31cb4e89209a#answer/b10d43b0-a525-4084-ab07-8b77d1583699

Hier uitleg over mijn zoektocht toen ik tegen hetzelfde probleem aan liep:

Men schijnt bezig te zijn met een nieuwe firmware voor de Zyxel, maar hoe lang dat nog gaat duren is een grote vraag. Er komen steeds meer mensen bij met hetzelfde probleem in steeds meer verschillende apparatuur. Ik heb al een paar keer gevraagd om een roll-back naar de laatste firmware die wel werkte (de problemen lijken een kleine twee maanden geleden begonnen, dus daarvoor leek het wel goed te gaan), maar daarop wordt niet gereageerd. Ook niet met: nee, doen we niet.

Als die dnsmasq-regels niet in de logfile verschijnen is het een ander probleem, maar ik schat dat dit het waarschijnlijk is.

Succes met oplossen!


Als daar regelmatig regels voorkomen van de vorm:

dnsmasq-dhcp: DHCP, IP range 192.168.1.1 -- 192.168.1.200, lease time 1d en
dnsmasq-dhcp: read /etc/ethers - 0 addresses

 

yep, dat is exact wat er staat: 

dnsmasq-dhcp: read /etc/ethers - 0 addressesdnsmasq-dhcp: DHCP, IP range 192.168.0.4 -- 192.168.0.254, lease time 1d

Handmatig een statisch IP-adres toekennen aan de Cloud Key lukt helaas niet. Ik kom niet zover in het setupproces dat ik dit al kan instellen. 

Fijn dat je reageert op mijn topic. Vreemd dat tot op heden nog steeds niemand van Odido heeft gereageerd…

Ik verwacht van Odido een inschatting wanneer de huidige problemen opgelost zijn. Dit is dus een nieuwe firmwareversie geweest, speciaal gemaakt voor Odidio, die niet fatsoenlijk is ontwikkeld en waarvan geleverde apparatuur niet doet wat er redelijkerwijs van wordt verwacht. Daarbij betaal ik dus voor een service die uiteindelijk niet geleverd wordt. 

Dat betekent dat bij Odido niet alleen de verantwoordelijkheid ligt om ons hierover goed en uitgebreid te informeren, maar dat hier ook een vergoeding tegenover staat, aangezien men niet aan de verplichtingen van geleverde dienst voldoet. Aangezien ik immers geen internet heb, waarom zou ik hier dan in de tussentijd voor betalen? 

Daarnaast wist Odido van dit probleem en heeft men hier onvoldoende over gecommuniceerd. Informatie hierover staat vertstopt in een andere bericht, maar niet in een centraal bericht, zodat voor iedere klant duidelijk is wat er aan de hand is. Zelfs als ik bel met Odido en het probleem duidelijk uitleg, is er niemand die mij verteld heeft dat dit een bekend probleem is, of hier verder over heeft geïnformeerd. 

Dit houdt concreet in dat ik hierdoor vele uren heb moeten besteden aan het troubleshooten van het probleem, terwijl ik hier met fatsoenlijke communicatie binnen 3 min uit was geweest. Daarnaast heb ik kosten moeten maken voor de RMA van de cloud key, om uit te kunnen sluiten dat de cloud key het probleem was. Dit had ik allemaal kunnen voorkomen als Odido openlijk en fatsoenlijk over dit probleem had gecommuniceerd.

Kortom, allemaal kosten waar Odido als leverancier aansprakelijk voor is. Hoe denkt Odido dit op te gaan lossen?

 


Als daar regelmatig regels voorkomen van de vorm:

dnsmasq-dhcp: DHCP, IP range 192.168.1.1 -- 192.168.1.200, lease time 1d en
dnsmasq-dhcp: read /etc/ethers - 0 addresses

 

yep, dat is exact wat er staat: 

dnsmasq-dhcp: read /etc/ethers - 0 addressesdnsmasq-dhcp: DHCP, IP range 192.168.0.4 -- 192.168.0.254, lease time 1d

 

Mooi, dan weten we in ieder geval dat we niet naar een andere oorzaak hoeven zoeken.
Het gaat er wel om dat deze regels regelmatig in de log terugkomen.
Na opstarten van de router zal dit er altijd 1x staan (het is het opstartbericht van de DHCP-module), maar als het er elke paar minuten staat is er dus iets wat de DHCP-module ongewenst opnieuw laat opstarten.

Handmatig een statisch IP-adres toekennen aan de Cloud Key lukt helaas niet. Ik kom niet zover in het setupproces dat ik dit al kan instellen. 

Installatie zonder DHCP schijnt wel te kunnen: https://community.ui.com/questions/Setup-Cloud-Key-Gen2-without-DHCP/451ca2d4-2cb8-4109-b40e-a75fab1229a0

De simpelste optie voor nu is waarschijnlijk een andere router in plaats van de Zyxel aan te sluiten (vlan 300, PPPoE), of, nog simpeler, een tweede router tijdelijk tussen het UniPhi netwerk en de Zyxel zetten. Dan maakt de Cloud Key verbinding, kun je de setup voltooien, en dan daarna de IP-instellingen op fixed zetten. Zorg dat de tweede router, als die er tussen staat, een andere IP-range heeft dan de Zyxel, en pas de IP-instellingen van de Zyxel na afloop aan zodat de Ubiquity weer in dezelfde IP range zit als waar je hem mee hebt ingesteld. Als je daar niet uitkomt kan ik wat voorbeelden geven.

Voor het instellen van een vast ip-adres na de eerste installatie zou wllicht deze link kunnen helpen: https://community.ui.com/questions/Change-Cloud-Key-IP-address/7e1ca2f7-75c2-42f6-bfe0-66994f55478d

Fijn dat je reageert op mijn topic. Vreemd dat tot op heden nog steeds niemand van Odido heeft gereageerd…

Die werken de topics van oud naar nieuw door, en in het weekend is de bezetting waarschijnlijk minimaal.

Ik verwacht van Odido een inschatting wanneer de huidige problemen opgelost zijn. Dit is dus een nieuwe firmwareversie geweest, speciaal gemaakt voor Odidio, die niet fatsoenlijk is ontwikkeld en waarvan geleverde apparatuur niet doet wat er redelijkerwijs van wordt verwacht. Daarbij betaal ik dus voor een service die uiteindelijk niet geleverd wordt. 

Die verwachting zul je waarschijnlijk moeten bijstellen.
Odido komt niet verder dan: “Wat vervelend voor je dat je nog steeds problemen hebt! We zullen er alles aan doen om die zo snel mogelijk op te lossen!”

Een tijdsplan geven is ook gevaarlijk, zeker met software-ontwikkeling. Als je niet weet waar het probleem vandaan komt of van externe partijen afhankelijk bent is het erg moeilijk om een inschatting te geven. In zoverre begrijp ik ze wel. Beloftes doen waarvan je niet weet of je je er aan kunt houden is erger dan geen beloftes doen.

 

Dat betekent dat bij Odido niet alleen de verantwoordelijkheid ligt om ons hierover goed en uitgebreid te informeren, maar dat hier ook een vergoeding tegenover staat, aangezien men niet aan de verplichtingen van geleverde dienst voldoet. Aangezien ik immers geen internet heb, waarom zou ik hier dan in de tussentijd voor betalen? 

Dat zal in de kleine lettertjes van het contract wel fijn uitgesloten zijn.
“En”, zullen ze zeggen, “je hebt toch internet?”
“Als je je computer of laptop rechtstreeks op de router aansluit doet die het.
Al die rare externe apparatuur is ons pakkie-an niet.”
Dan zullen ze er achter gaan komen dat ze steeds meer boze klanten met “rare apparatuur” hebben, want moderne apparatuur maakt steeds vaker gebruik van de moderne versies van DHCP-requests.
Mijn Linux-laptop gaat nog goed, maar de Raspberry Pi die ik een paar weken geleden probeerde in te richten met de linux versie Ubuntu Server kreeg geen verbinding.
Wiim Pro Plus, Harman Kardon Citation, JBL, Nest deurbel, Ubiquiti, Ubuntu Server, het lijstje wordt steeds langer.
Steeds meer boze klanten.

Daarnaast wist Odido van dit probleem en heeft men hier onvoldoende over gecommuniceerd. Informatie hierover staat vertstopt in een andere bericht, maar niet in een centraal bericht, zodat voor iedere klant duidelijk is wat er aan de hand is. Zelfs als ik bel met Odido en het probleem duidelijk uitleg, is er niemand die mij verteld heeft dat dit een bekend probleem is, of hier verder over heeft geïnformeerd. 

In eerste instantie hadden ze niet in de gaten dat dit allemaal hetzelfde probleem is, en probeerden ze elk probleem op de - voor dat probleem - bekende manier op te lossen. “Zal ik de 2.4 en 5 GHz banden van je router voor je splitsen?”. Pas sinds kort hebben ze door dat het allemaal hezelfde probleem is, en dat wifi-instellingen veranderen hier niet helpt. Ik hoop dat mijn bijdragen daar een zetje aan gegeven hebben.

En inderdaad, een vastgepind bericht bovenaan, met:
NIET-WERKENDE APPARATUUR AAN EEN ZYXEL-T56 ROUTER? LEES DIT!

zou heel veel ellende schelen.
Maar dan vestig je zelf aandacht op het probleem

Dit houdt concreet in dat ik hierdoor vele uren heb moeten besteden aan het troubleshooten van het probleem, terwijl ik hier met fatsoenlijke communicatie binnen 3 min uit was geweest. Daarnaast heb ik kosten moeten maken voor de RMA van de cloud key, om uit te kunnen sluiten dat de cloud key het probleem was. Dit had ik allemaal kunnen voorkomen als Odido openlijk en fatsoenlijk over dit probleem had gecommuniceerd.

Kortom, allemaal kosten waar Odido als leverancier aansprakelijk voor is. Hoe denkt Odido dit op te gaan lossen?

Amen. Ik ben ook de nodige uren bezig geweest met troubleshooten, ben er achter gekomen dat het probleem in de DHCP-module zit, en dat je dat kunt zien aan de terugkerende regels in de logs. Dat het probleem getriggerd wordt door apparatuur die een nieuwere versie van het DHCP-protocol gebruikt (hooguit 20 jaar oud...) dat een langere string als identifier gebruikt, waardoor waarschijnlijk andere data (die verderop in het geheugen ligt) wordt overschreven, en dat daardoor de dhcp-module crasht. Maar dat het niet de eigenlijke dhcp-server (dnsmasq) is, want dat is een algemeen bekende unit die zelf dit probleem niet heeft. Dat het dus een eigen schil van Odido moet zijn die de dnsmasq gegevens verwerkt voor gebruik in de UI.

Maar ik merk op geen enkele manier dat er wat met deze informatie gedaan wordt.
Bij problemen eerst even in de logs van het modem kijken of die twee beruchte regels telkens terugkeren, en zo ja, dan weten we wat het is en hoeven we niet verder te zoeken zou een heleboel onnodige support-tijd schelen. En als je weet waar je de buffer-overflow in je firmware moet zoeken zou hij toch zo verholpen moeten kunnen zijn.

Maar helaas, ik mis kennelijk de communicatieve vaardigheden om mijn berichten zo in te kleden dat men inziet dat ze de organisatie veel tijd kunnen besparen door de informatie door te spelen aan afdelingen die hier wat mee kunnen.

En om een of andere reden wordt de suggestie van een roll-back naar een voorgaande versie van de firmware, die deze fout kennelijk niet had, niet afgewezen, maar volledig genegeerd. Diverse malen door verschillende mensen gedaan: stilte.

Helaas.

</rant>


@Bonesie85 Ik heb gereageerd in het andere topic en gevraagd of de update maar jou kan worden uitgestuurd. Heel erg bedankt voor je geduld! 


Reageer