Ubiquiti cloud key krijgt geen IP van Zyxel t-56

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>