Kan Cloudkey Gen1 niet configureren (ziggo connectbox)

[sean-paul]

Je kan er donder op zeggen dat ik bij mij thuis altijd 1 dag in het jaar heb waarop mijn hele netwerk stopt met werken.

Ik heb een ziggo connect box waarop een netgear gs108pp PoE switch aangesloten zit en op de andere drie porten mijn homelab en somfy tahoma box. De laatste poort gaat naar mijn slaapkamer. Op de netgear switch zit de cloudkey Gen 1 en overige bekabelde punten in ons huis (waaronder ook drie ubiquiti Lite accesspoints)

Het probleem is dat ik de cloudkey niet meer kan configureren via de iOS App zowel de web interface. Als ik met een usb-c naar ethernet adapter de switch of de connect box inga dan krijg ik ook op mijn laptop geen ip address. Dit is ook waar ik denk dat het probleem ligt. Ik heb de connect box en de cloudkey beide naar fabrieksinstellingen gedaan maar niks schijt te werken. Ook de cloudkey recovery mode gaf geen resultaat.

Hardware:
- ubiquite CloudKey generatie 1
- Ziggo connect box
- Macbook pro 16" 2020

Wat ik al gevonden of geprobeerd heb
- CloudKey naar febrieksinstellingen
- CloudKey in recovery mode proberen te benaderen
- Ziggo connect box naar fabrieksinstelingen
- DHCP staat aan op de connectbox
- Alle draadloze apparaten hebben wel wifi (via de connectbox aangezien ik de accespoints heb uitgezet ivm nieuwe configuratie)
- Discovery tools van ubiquiti werken niet.
- Via de unifi iOS app de cloudkey instellen (krijg dan een error: Setup failed, The setup process for this unifi device was disrupted. Please try agiain... hier kan ik zelfs als software engineer niks mee)
- Mijn macbook bedraad verbinden. Met automatische dhcp instellingen krijg ik geen ip adres, uiteindelijk wijst mijn macbook zichzelf een ip adres toe.
- handmatig een ip adres toevoegen aan mijn macbook netwerkinstellingen, dan werkt de bedrade verbinding wel.

Zou iemand mij hierbij willen helpen?

Alvast bedankt voor jullie tijd en moeite!

...

[Voor 6% gewijzigd door sean-paul op 10-09-2022 19:05]

[PhilipsFan]

Ik begrijp helemaal niks van je verhaal. Waarom zou je een Ubiquiti Cloudkey willen gebruiken als je verder geen Unifi spullen hebt?

Maw vertel je verhaal eens wat completer en met wat meer samenhang, want dit schiet niet op.

[sean-paul]

Als je goed leest zie je dat ik 3 unifi accesspoints heb.

Betrekking tot de samenhang leg ik eerst het probleem uit. dan welke hardware en daarna wat ik al geprobeerd heb met troubleshooting.

[jvanhambelgium]

Probleem is je connect-box zou ik denken, Kan je op geen enkele manier "inloggen" op zo'n box en kijken welke IP's hij heeft uitgegeven enz? Als er geen IP's worden toegewezen aan bekabelde toestellen ... tja ... dan kan je lang blijven proberen natuurlijk.

[sean-paul]

jvanhambelgium schreef op zaterdag 10 september 2022 @ 19:08:
Probleem is je connect-box zou ik denken, Kan je op geen enkele manier "inloggen" op zo'n box en kijken welke IP's hij heeft uitgegeven enz? Als er geen IP's worden toegewezen aan bekabelde toestellen ... tja ... dan kan je lang blijven proberen natuurlijk.

Ja precies, daar ging mijn gevoel ook naartoe. Zeker omdat mijn laptop bedraad ook geen verbinding krijgt zonder dat ik handmaitg een ip adres invoer. De DHCP instellingen leken mij niet gek:
De dhcp server begint met uitdelen bij adres 192.168.178.10 (Bij de vorige config had ik deze hoger staan bijvoorbeeld xxx.xxx.xxx.50 zodat mijn homelab containers onder die range kon opvangen.
Subnet is 255.255.255.0
Aantal apparaten: 245
lease: 86400 seconden

Dit zijn dus eigenlijk de standaard instellingen voor de connectbox.
Uiteindelijk zet in de draadloze verbinding uit omdat die ubuquiti accespoints dat overnemen met de cloudkey.

Mocht je nog meer info nodig hebben dat hoor ik het graag!

[laurens0619]

Werkt je bekabelde verbinding van je macbook wel?
Ik vind het zeer vreemd dat de connectbox via wifi wel adressen geeft via dhcp en via de lan niet…

Wat veel aannemelijk is dat de cloudkey gewoon dood is

[Voor 16% gewijzigd door laurens0619 op 10-09-2022 20:15]

[nelizmastr]

laurens0619 schreef op zaterdag 10 september 2022 @ 20:11:
Werkt je bekabelde verbinding van je macbook wel?
Ik vind het zeer vreemd dat de connectbox via wifi wel adressen geeft via dhcp en via de lan niet…

Wat veel aannemelijk is dat de cloudkey gewoon dood is

Zeker als het een gen1 cloud key is. Die dingen zijn echt niet heel best. Falende accu’s, goedkope flash chips, hardbricks na updates etc.

Lekker unifi controller in een container gaan draaien.

[sean-paul]

laurens0619 schreef op zaterdag 10 september 2022 @ 20:11:
Werkt je bekabelde verbinding van je macbook wel?
Ik vind het zeer vreemd dat de connectbox via wifi wel adressen geeft via dhcp en via de lan niet…

Wat veel aannemelijk is dat de cloudkey gewoon dood is

Yes! die werkte zodra ik zelf een ip adres in voerde. Hij kreeg geen ip adres van de router.

[sean-paul]

nelizmastr schreef op zaterdag 10 september 2022 @ 21:07:
[...]


Zeker als het een gen1 cloud key is. Die dingen zijn echt niet heel best. Falende accu’s, goedkope flash chips, hardbricks na updates etc.

Lekker unifi controller in een container gaan draaien.

Het is inderdaad een gen1 , Hoe stabiel ervaar jij de Unifi software in een container? Ik merk dat de cloudkey samen met de iOS app best onstabiel is. Topologie werkt niet, vaak geeft de app aan dat bepaalde AC's niet meer geadopteerd zijn (terwijl ze het wel zijn) of begint unifi zelf dingen aan te passen in de configuratie.

Ik zal mij eens verdiepen in het draaien van Unifi in een container! Bedankt voor de info en tips!!

[M2M]

Is het niet een idee om alle vaste dingen een fixed ip te geven? Is het probleem ook opgelost toch?

[laurens0619]

sean-paul schreef op zaterdag 10 september 2022 @ 21:53:
[...]


Yes! die werkte zodra ik zelf een ip adres in voerde. Hij kreeg geen ip adres van de router.

Sorry ik was wat onduidelijk
Werkt dhcp wel op dr bekabelde verbinding?
Heb ne geen ander bedraad apparaat waar je het mee kunt testen of die een ip krijgt?

[sean-paul]

laurens0619 schreef op zaterdag 10 september 2022 @ 22:18:
[...]

Sorry ik was wat onduidelijk
Werkt dhcp wel op dr bekabelde verbinding?
Heb ne geen ander bedraad apparaat waar je het mee kunt testen of die een ip krijgt?

Ja, onze AppleTV krijgt ook geen ip adres meer en ik merkte vannacht dat ik ook niet meer de rolluiken kon bedienen met onze somfy tahoma app. Grote kans dat ook die somfy box geen ip meer krijgt. En mijn laptop natuurlijk die dus ook geen ip toegewezen kreeg en bedraad allen werkte toen ik zelf een ip adres invulde.

Het lijkt net alsof de Ziggo ConnectBox niet "merkt" dat er een nieuw apparaat aangesloten is. Soms geeft hij de apparaten wel een ip en de andere keer gewoon niks. Helaas geeft hij ze vaker geen ip dan wel.

[Kabouterplop01]

Wat is er veranderd in het netwerk voor die éne specifieke dag in het jaar?
Het kan niet zo zijn dat dat in 1x is gebeurd.

Wat is de meest recente "change" geweest?

[sean-paul]

Kabouterplop01 schreef op zondag 11 september 2022 @ 09:04:
Wat is er veranderd in het netwerk voor die éne specifieke dag in het jaar?
Het kan niet zo zijn dat dat in 1x is gebeurd.

Wat is de meest recente "change" geweest?

Ik weet niet zo goed wanneer en hoe Ziggo firmware updates doet, ik heb het gevoel dat dat de boosdoener is. Ik ben zelf niet bezig met instellingen te veranderen in de unifi software en die van de ConnectBox. Laatste change was twee jaar geleden omdat ik de eerste 40 ip adressen buiten de DHCP range wilde hebben zodat ik die zelf kan toewijzen en zeker weet dat daar geen andere apparaten op gaan zitten. Die ip adressen gebruik ik puur voor containers, vm's en andere services.

Wat mij deze keer opviel is dat de unifi software aangaf een van de drie accesspoints niet meer geadopteerd was. Dat merk ik wel vaker dat de unifi software zijn eigen gang gaat.

[sean-paul]

Wat ik nu zie is dat de pagina "Verbonden apparaten" nu alleen nog mijn laptop laat zien en verder ook mijn homelab en truenas niet meer laat zien. het begint nu wel erg bijzonder te worden wat die connectbox allemaal aan het doen is. Reset naar fabrieksinstellingen blijkt geen verschil te maken.

[Kabouterplop01]

zie je wat in de logging van je connectbox? Na een update moet die nl een restart hebben.

[Ben(V)]

Heb je niet ergens een device dat een fixed ipadres heeft en dat in de lage range zit, wat nu door de dhcp server van je Connectbox gebruikt wordt.
Laat die dhcp server gewoon dezelfde range gebruiken die je vroeger gebruikte.
Vergeet niet dat devices die altijd aan staan zoals iot device heel lang hun oude ipadre houden en als die door de dhpc server opnieuw worden uitgegeven je een ip conflict hebt

Bedenk verder dat als jij ergens een device een fixed ipadres geeft dat in dezelfde range ligt als je dhcp server je potentieel een ip conflict krijgt.

Beste opzet is altijd om iot device een vast ipadres te geven niet in het device zelf maar door de dhcp server altijd hetzelfde adres aan een macadres te laten uitgeven en dat in een reeks die buiten de automatische uitgifte ligt.

PS Die firmware updates van die Connectbox hebben hier echt niets mee te maken.

[Voor 4% gewijzigd door Ben(V) op 11-09-2022 09:41]

[sean-paul]

Ben(V) schreef op zondag 11 september 2022 @ 09:39:
Heb je niet ergens een device dat een fixed ipadres heeft en dat in de lage range zit, wat nu door de dhcp server van je Connectbox gebruikt wordt.
Laat die dhcp server gewoon dezelfde range gebruiken die je vroeger gebruikte.
Vergeet niet dat devices die altijd aan staan zoals iot device heel lang hun oude ipadre houden en als die door de dhpc server opnieuw worden uitgegeven je een ip conflict hebt

Bedenk verder dat als jij ergens een device een fixed ipadres geeft dat in dezelfde range ligt als je dhcp server je potentieel een ip conflict krijgt.

Beste opzet is altijd om iot device een vast ipadres te geven niet in het device zelf maar door de dhcp server altijd hetzelfde adres aan een macadres te laten uitgeven en dat in een reeks die buiten de automatische uitgifte ligt.

PS Die firmware updates van die Connectbox hebben hier echt niets mee te maken.

Oh oke! Ik heb even een screenshot gemaakt met hoe de standaard configuratie van de ConnectBox is en hoe ik die en paar jaar geleden had veranderd.

Dit is de standaard dhcp config:


En dit is hoe ik het had ingesteld:

Zo kon ik dus alles vanaf xxx.xxx.xxx.3 tot aan xxx.xxx.xxx.39 zelf aanwijzen. Althans ik dacht dat het zo moest (mijn laatste Datacom en netwerkbeheer lessen waren erg lang geleden )

[Voor 4% gewijzigd door sean-paul op 11-09-2022 10:19. Reden: Goede afbeelding toegevoegd]

[Dyckie]

Met die laatste configuratie ga je de adressen tussen xxx.xxx.xxx.3 en xxx.xxx.xxx.39 nooit niet kunnen gebruiken hoor.

[SambalBij]

Ben(V) schreef op zondag 11 september 2022 @ 09:39:
Heb je niet ergens een device dat een fixed ipadres heeft en dat in de lage range zit, wat nu door de dhcp server van je Connectbox gebruikt wordt.
Laat die dhcp server gewoon dezelfde range gebruiken die je vroeger gebruikte.

Idd, zolang je niet zoveel apparaten hebt die DHCP adressen vragen maakt dat echt niet uit.
Beter om wat vrije ruimte te hebben voor statische adressen, als je daar mee werkt. De gemiddelde Ziggo klant gebruikt dat niet, dus daarom dat standaard die scope bijna het hele subnet groot is.

Vergeet niet dat devices die altijd aan staan zoals iot device heel lang hun oude ipadre houden en als die door de dhpc server opnieuw worden uitgegeven je een ip conflict hebt

Zou normaal niet moeten gebeuren. Die apparaten houden heel lang hun IP adres omdat ze halverwege de lengte van de lease (dus ruim vóórdat de DHCP server dat adres weer mag hergebruiken omdat de lease vervallen is) dat adres alweer 'verlengen' bij de DHCP server. Zolang de DHCP server geen reden heeft om dat te weigeren krijgt het device gewoon weer een nieuwe lease voor de volledige duur. (Die dan weer halverwege die leasetijd wordt verlengd... ad infinitum...)

De enige redenen voor de DHCP server om die verlenging te weigeren kunnen zijn omdat dat adres niet meer beschikbaar is omdat je bijvoorbeeld de scope hebt aangepast of dat adres gereserveerd hebt voor een ander device. In alle andere gevallen weet ook de DHCP server welke client welk adres heeft. Is door bijvoorbeeld een reset/config update vanuit Ziggo de leasetabel van de DHCP server verdwenen (en weet de DHCP server dus niet meer welk device welk adres heeft en voor hoe lang) dan zou je problemen kunnen krijgen wanneer je vlak daarna (=binnen de helft van de geconfigureerde leasetermijn) nieuwe devices introduceert. Bestaande devices die nog wel hun IP kennen zullen dat weer aan de DHCP server vragen, en zolang dat adres nog vrij is binnen de, op dat moment. nog vrijwel lege scope, ook de request voor dat specifieke IP weer honoreren en weer in de leasetabel opnemen.

PS Die firmware updates van die Connectbox hebben hier echt niets mee te maken.

Tenzij die de DHCP leasetabel leeggegooid hebben, maar zelfs dan lost dat zichzelf binnen uiterlijk 24 uur weer op (=de leasetermijn)

---

Dyckie schreef op zondag 11 september 2022 @ 10:21:
Met die laatste configuratie ga je de adressen tussen xxx.xxx.xxx.3 en xxx.xxx.xxx.39 nooit niet kunnen gebruiken hoor.

Euh, ja... Die ga je dan juist wél zelf kunnen gebruiken.

De DHCP server op het kabelmodem zal die dan niet toewijzen aan DHCP clients, waardoor ze vrij blijven om ze zelf statisch op apparaten te configureren.
Doe je dit niet, en je wijst vervolgens toch de 192.168.178.25 bijvoorbeeld handmatig/statisch aan een apparaat toe, dan heb je een IP conflict wanneer het Ziggo modem dat adres óók toewijst (wat hij kan want dat adres is onderdeel van de DHCP scope) aan een ander, dynamisch ingesteld apparaat.

[Voor 61% gewijzigd door SambalBij op 11-09-2022 10:49]

[Dyckie]

SambalBij schreef op zondag 11 september 2022 @ 10:33:
[...]

Euh, ja... Die ga je dan juist wél zelf kunnen gebruiken.

De DHCP server op het kabelmodem zal die dan niet toewijzen aan DHCP clients, waardoor ze vrij blijven om ze zelf statisch op apparaten te configureren.
Doe je dit niet, en je wijst vervolgens toch de 192.168.178.25 bijvoorbeeld handmatig/statisch aan een apparaat toe, dan heb je een IP conflict wanneer het Ziggo modem dat adres óók toewijst (wat hij kan want dat adres is onderdeel van de DHCP scope) aan een ander, dynamisch ingesteld apparaat.

Als je in een toestel een statisch ip adres insteld in de range van u dhcp dan ziet u modem dat dit ip adres ingebruik is en gaat die zeker dit ip adres niet nog eens toewijzen aan een ander toestel hoor. En je ziet het toch ook op de afbeeldingen staan dat in de eerste 245 adressen beschikbaar zijn en in de 2de 215 beschikbaar zijn. Dus in het 2de geval kun je die adressen tussen xxx.xxx.xxx.3 en xxx.xxx.xxx39 helemaal niet gebruiken.

[Voor 12% gewijzigd door Dyckie op 11-09-2022 10:53]

[SambalBij]

Dyckie schreef op zondag 11 september 2022 @ 10:49:
[...]


Als je in een toestel een statisch ip adres insteld in de range van u dhcp dan ziet u modem dat dit ip adres ingebruik is en gaat die zeker dit ip adres niet nog eens toewijzen aan een ander toestel hoor.

Daar zou ik niet zo makkelijk vanuit gaan!
Ja, er zijn mechanismen voor conflictdetectie door een DHCP server, maar die zijn afhankelijk van bijvoorbeeld een ping naar het IP om te zien of dat in gebruik is. En met de huidige trend om alles maar standaard een firewall te geven kun je er niet echt meer vanuit gaan dat een device ook op die ping reageert.

Dan is het aan het modem om bijvoorbeeld uit de ARP tabel een ander device te detecteren en dat adres tijdelijk uit te sluiten uit de scope. Maar als dat device toevallig net de afgelopen 60 seconden (of wat de arp cache timeout op het modem dan ook is) geen verkeer heeft gegenereerd, dan weet het modem niet dat dat adres in gebruik is.

Toch echt beter om het netjes in te stellen, en niet te vertrouwen op dit soort mechanismen.

En daarnaast, ik reageerde op post dat je die adressen tussen .3 en .39 helemaal niet zou kunnen gebruiken als je die buiten de DHCP scope houdt, en dat statement is volledig 100% stierenpoep

En je ziet het toch ook op de afbeeldingen staan dat in de eerste 245 adressen beschikbaar zijn en in de 2de 215 beschikbaar zijn.

beschikbaar zijn voor de DHCP server om uit te delen!

En als je ze statisch gebruikt, dan moeten ze dus NIET beschikbaar zijn voor de DHCP server om uit te delen...

[Voor 11% gewijzigd door SambalBij op 11-09-2022 11:12]

[Ben(V)]

DHCP server kijken echt niet of een ipadres al fixed is ingesteld.
Die heeft gewoon een reeks (die je zelf instelt) en als een device opstart en een dhcp request uitstuurt dan geeft hij gewoon een ipadres uit die reeks die hij zelf nog niet heeft uitgegeven.

Als een device een ipadres heeft en hij doet halverwege de leasetijd een renew van dat ipadres, maar dat ipadres zit niet in de dhcp range van de dhcp server dan houd hij gewoon dat ipadres en krijgt hij geen ander.

Kortom zet de range weer terug naar 192.178.1.40
Zoek uit wat de mac adressen van je iot devices, van je acesspoint, printers scanners enz zijn (dus van alle devices die je moet kunnen benaderen).
Maak in die Connectbox bij "Add reserved rules" een koppeling tussen die mac-adressen en een ip-adressen uit de reeks 192.178.1.2 tot 192.178.1.39
Save het en zorg ervoor dat al je devices opnieuw opstarten (spanning eraf ).

Dit zorgt ervoor dat alle devices die bereikbaar moeten zijn altijd hetzelfde ipadres krijgen uit de lage reeks en de andere devices zoals pc's laptops, telefoons enz een ipadres uit de dhcp reeks krijgen.

[Dyckie]

Kijk ook een op ziggo forum zelf daar wordt aangehaald dat bij lage ip adressen er een bug in zit. Weet niet of dit al opgelost is maar je kunt dit mss eerst eens uitzoeken.

https://community.ziggo.n...der-onder-het/td-p/388313

[sean-paul]

Ik heb nu de configuratie dhcp teruggezet naar hoe ik het eerst had. Zodat de DHCP server ip adressen begint uit te delen vanaf xxx.xxx.xxx.40 en ik alles daaronder zelf kan toewijzen aan IoT devices en vm's etcetera.

Ik ben gelijk bezig gegaan met het maken van een vm met daarop docker voor de Unifi contianer. Dit heb ik gedaan op de TrueNas aangezien ik dat al had staan. Wat ik nu merk is dat de connectie met TrueNas over de webinterface vrij vaak onderbroken wordt. TrueNas geeft zelf aan dat het ip adres voor de webinterface niet veranderd is maar ik krijg ook een timeout tijdens het bezoeken ervan. Ik denk toch dat die ConnectBox een goede tik heeft gehad van iets. Maar wat voor iets kan ik niet herleiden.

[sean-paul]

Dyckie schreef op zondag 11 september 2022 @ 11:41:
Kijk ook een op ziggo forum zelf daar wordt aangehaald dat bij lage ip adressen er een bug in zit. Weet niet of dit al opgelost is maar je kunt dit mss eerst eens uitzoeken.

https://community.ziggo.n...der-onder-het/td-p/388313

Oh wist ik helemaal niet! Ik ga het gelijk proberen!

[SambalBij]

Ik ken die TrueNAS verder niet, maar kun je daar niet toevallig een DHCP server op draaien?
Dat is wellicht stabieler en flexibeler dat het buggy stuk ellende in dat Ziggo modem.

(Bijvoorbeeld welke DNS server je de clients meegeeft, mocht je intern een eigen DNS willen draaien of liever Google of Cloudflare gebruiken ipv Ziggo)

[Ben(V)]

De Connectbox heeft niets te maken met wat timeouts op je Lan.
Die is alleen dhcp server en router, wat verder op het lan gebeurd doet die Connextbox niets mee.

Verder is wat je op dat Ziggo forum leest een conclusie die niet echt gerechtvaardigt is dat het een bug in de Connectbox is.
Ik gebruik die reeks al jaren zo en nooit problemen gehad en ik heb twee typen Connectboxen gehad (een Compal en een Arris).
Lijkt mij meer een probleem van een nieuwe configuratie terwijl er nog heel veel oude ipadressen in het lan rondzwerven.

Zoals ik al zei, als je met dhcp reeksen gaat veranderen in de dhcp server moet je ervoor zorgen dat alles herstart om zeker te weten dat alle ok komt.
Het beste is alles van de spanning af, dan de Connectbox configureren en daarna je devices weer opbrengen.

En vast ipadressen in een device instellen is nooit een goed idee, dat levert bij veranderingen altijd problemen op.
Zet gewoon al je devices op dhcp en regel alles zoals ik beschreven heb in je router, dan zit alles op een plek en krijg je nooit problemen.

[Voor 5% gewijzigd door Ben(V) op 11-09-2022 11:59]

[Kabouterplop01]

Ben(V) schreef op zondag 11 september 2022 @ 11:56:
De Connectbox heeft niets te maken met wat timeouts op je Lan.
Die is alleen dhcp server en router, wat verder op het lan gebeurd doet die Connextbox niets mee.

dat ligt eraan, als die timeouts langer duren dan de 3 standaard packets die worden verstuurd bij een dhcp request krijg je geen IP adres, of een 169.254.

En vast ipadressen in een device instellen is nooit een goed idee, dat levert bij veranderingen altijd problemen op.

maakt niks uit, als je weet wat je doet.

Kortom zet de range weer terug naar 192.178.1.40
Zoek uit wat de mac adressen van je iot devices, van je acesspoint, printers scanners enz zijn (dus van alle devices die je moet kunnen benaderen).
Maak in die Connectbox bij "Add reserved rules" een koppeling tussen die mac-adressen en een ip-adressen uit de reeks 192.178.1.2 tot 192.178.1.39

Let op! het is 192.168.178/24 zo gaat het nooit werken

Zet gewoon al je devices op dhcp en regel alles zoals ik beschreven heb in je router, dan zit alles op een plek en krijg je nooit problemen.

Eens!

[laurens0619]

Maar heb je nu al een werkende dhcp server op je lan?

[Ben(V)]

Kabouterplop01 schreef op zondag 11 september 2022 @ 12:11:
[...]

dat ligt eraan, als die timeouts langer duren dan de 3 standaard packets die worden verstuurd bij een dhcp request krijg je geen IP adres, of een 169.254.

Dit ging niet over het dhcp deel maar over het feit dat de webconnectie naar die TrueNas timeouts krijg als het wel verbonden is.
Dat speelt zich enkel op het lan af en heeft niets met de router en/of de dhcp server te maken.

[Kabouterplop01]

Ben(V) schreef op zondag 11 september 2022 @ 13:44:
[...]


Dit ging niet over het dhcp deel maar over het feit dat de webconnectie naar die TrueNas timeouts krijg als het wel verbonden is.
Dat speelt zich enkel op het lan af en heeft niets met de router en/of de dhcp server te maken.

de toegang naar internet is vanaf het LAN, als er iets stuk is wat vreselijk loopt te broadcasten en het netwerk omver flood dan is je stelling niet juist. Dat kan mogelijk die timeouts verklaren.

Dat is juist waar we proberen achter te komen

[sean-paul]

Oke ik heb bovenstaande toegepast en ik zal het even opsommen:

- Statische ip adressen "naar boven gehaald" zoals @Dyckie beschreef hier de link naar dat Ziggo forum:
https://community.ziggo.n...der-onder-het/td-p/388313

- de DHCP instellingen terug gezet. Dus niet dat dhcp pas vanaf x.x.x.40 begint uit te delen maar vanaf de fabrieksstandaard instelling x.x.x.10. Daarna "aantal apparaten" beperkt naar 150 dus het ip adres kan tot x.x.x.159

- reservering gemaakt voor het ip adres van de truenas server en mac adres toegevoegd, aangezien daar een docker container van unifi gaat draaien.

Het probleem met het herkennen van apparaten die bedraad zijn keert weer terug. Vanochtend kon ik de hele ochtend truenas benadren op ip adres 192.168.178.201/24 en nu wil ik net verder gaan (deze avond) en kan ik truenas niet meer benaderen.... zucht, dus ga kijken bij verbonden apparaten in de software van de connectbox en dit is wat ik zie:


Als ik de connectbox herstart dan ziet hij wel weer alle apparaten, althans dit verschilt per keer dat ik herstart. Het is een beetje Russisch roulette. Maar na een tijd zoals vanochtend knikkert hij de bedrade apparaten er weer uit.

Dit is precies het probleem. Ik snap ook niet zo goed wat hier dan fout gaat. De server heeft continu aangestaan en de server zegt ook dat het webadres van truenas 192.168.178.201 is... Ik weet ook niet zo goed hoe ik dit moet monitoren en wat er dus fout gaat. Het lijkt net alsof de connectbox gewoon dood aan het gaan is. Uit mijn hoofd zijn er sowieso 4 bedrade apparaten die momenteel aan staan op ons netwerk.

[Voor 10% gewijzigd door sean-paul op 11-09-2022 21:15. Reden: Url naar ziggo forum gefixt]

[sean-paul]

laurens0619 schreef op zondag 11 september 2022 @ 12:21:
Maar heb je nu al een werkende dhcp server op je lan?

Ik heb een nieuwe comment toegevoegd, als er nog wat info ontbreekt dar hoor ik het graag!

[laurens0619]

Is er niet toevallig, van je homelab misschien?, een 2e dhcp server actief?

[sean-paul]

laurens0619 schreef op zondag 11 september 2022 @ 21:15:
Is er niet toevallig, van je homelab misschien?, een 2e dhcp server actief?

Geen idee eigenlijk. Heb alleen de truenas aan staan en die is zo minimaal ingericht dat ik daar nooit iets met DHCP heb gedaan. Er is wel een Netgear GS108PP in ons netwerk die voor de PoE zorgt voor de accespoints en de cloudkey. Ik lees op internet dat het een gewone unmanaged switch is. De connectbox ziet beide switches (ook de switch van mijn homelab) niet. Dus ik heb ook geen ip adressen van deze switches.

[Voor 3% gewijzigd door sean-paul op 11-09-2022 21:35]

[Dyckie]

Mss doordat het fallback ip adres van de cloudkey 192.168.1.30 en omdat gij in een andere range zit dat het niet wilt werken.

[Voor 7% gewijzigd door Dyckie op 11-09-2022 22:20]

[sean-paul]

Even een update!

Ik heb alle switches van de stroom af gehaald en daarbij gelijk gekeken naar loopjes in het netwerk. Simpel gekeken er een kabel uit en in een switch ging. Kon niks vinden. Connectbox laten herstarten en alle switches weer aangezet. Zoals ik in een reactie naar @laurens0619 als zei kan ik geen tweede dhcp server vinden op het netwerk. Althans zover ik kan zien niet, zeker omdat er nu maar 1 server aanstaat en dat is de truenas server.

Ik blijf het wel gek vinden dat de connectbox wisselvallig is met het laten zien welke apparaten er verbonden zijn. Dit geldt alleen voor de bedrade apparaten want de draadloze apparaten laat hij prima zien. Ik dacht eerst dat het te maken heeft dat er een switch tussen de connectbox en mijn homelab zit maar zoals ik hierboven aangaf is de connectbox erg wisselvallig met welke bedrade apparaten hij wel of niet laat zien.

[Ben(V)]

Dat ligt niet aan de Connectbox maar aan de apparatuur.
Als die apparatuur in slaap valt ziet de Connectbox ze niet meer en vooral iot spullen doen dat vaak.

[yay]

Ik had ook allerlei vage problemen op mijn netwerk toen de ConnectBox de router functie inclusief DHCP uitvoerde. Dan duurde het soms een uur voordat alles weer werkte.

Ik heb mijn ConnectBox in bridge modus laten zetten en er een router achter gezet. Sindsdien geen problemen meer.

[Ben(V)]

Half Nederland heeft zo'n Connectbox en die werken gewoon zoals het hoort, dus als zoiets optreed lijkt het me waarschijnlijker dat de oorzaak elders ligt.

[Kabouterplop01]

Dyckie schreef op zondag 11 september 2022 @ 22:19:
Mss doordat het fallback ip adres van de cloudkey 192.168.1.30 en omdat gij in een andere range zit dat het niet wilt werken.

Hij zit niet in een andere range, het is nog steeds hetzelfde subnet. Stop met verwarring zaaien.

@sean-paul kan het zijn dat jouw NAS in hybernation valt en dat mocht je de server willen ontwaken je eest naar de server moet browsen/pingen/ (hoe je er connectie naar toe moet maken)

[Voor 22% gewijzigd door Kabouterplop01 op 13-09-2022 08:38]

[Dyckie]

Kabouterplop01 schreef op dinsdag 13 september 2022 @ 08:36:
[...]

Hij zit niet in een andere range, het is nog steeds hetzelfde subnet. Stop met verwarring zaaien.

@sean-paul kan het zijn dat jouw NAS in hybernation valt en dat mocht je de server willen ontwaken je eest naar de server moet browsen/pingen/ (hoe je er connectie naar toe moet maken)

Sorry he maar het ging hier wel eerst over de cloudkey die niet bereikbaar was. En niet dat zijn modem ip adressen uitdeeld want dat is een ander verhaal.

[sean-paul]

Update!

Gister heel het netwerk afgekoppeld. Alles met wifi of een bedrade verbinding uitgezet. Na de tip van @nelizmastr draait de Unifi controller nu in een docker container en ik moet zeggen dat hij nu al veel stabieler is dan de Cloudkey Gen1. Geen problemen met verbinding maken etc vanuit de iOS app. Gelijk ook alle kabels gelabeld die vanuit de meterkast naar alle wandpunten in het huis gaan.

Op basis van de tip van @Dyckie over de ip adressen onder de dhcp scope en de bug in de connectbox firmware URL (link naar het Ziggo forum: https://community.ziggo.n...der-onder-het/td-p/388313), heb ik alle statische ip adressen “omhoog” gehaald en het aantal apparaten verminderd. voorbeeld: DHCP van de connectbox begint op x.x.x.10 dan vult de connectbox het aantal apparaten aan tot 254 dus heb je 245 apparaten (als je x.x.x.10 ook meerekent) om een ip adres aan uit te delen. Ik heb de dhcp range verminderd met 80 apparaten dus kan ik vanaf x.x.x186 beginnen met het toewijzen van de apparaten die ik een statisch adres wil geven zoals de unifi controller, nas, containers, IoT devices, etc.

Door de reactie van @Kabouterplop01 hield ik tijdens het afsluiten van alle apparaten die met het internet verbonden in mijn achterhoofd dat er misschien kans was op een loop in het netwerk. Ik kwam ik er achter dat onze AppleTV zowel bedraad als via de wifi was verbonden. Toen heb ik gezocht over een broadcast flood met een AppleTV bedraad en wifi en toen kwam ik hierop; https://discussions.apple.com/thread/6830097. Dit zou dus het probleem geweest kunnen zijn. Wel bijzonder dat ik er niet altijd last van had. En ik ben benieuwd of dit er ook voor heeft gezorgd dat daarom de Cloudkey van de rel was.

Vanaf het moment dat alle apparaten waren afgesloten had ik ook geen problemen meer met de verbindingen naar de Truenas Server. Joost mag weten wat het probleem was.

Ik ga deze weken kijken of ik gekke dingen tegenkom maar zoals het er nu uitziet doet alles het weer goed. Jammer dat ik niet zoals op stackoverflow meerdere reacties kan combineren en die als antwoord toewijzen. Maar iedereen super bedankt voor alle hulp!