[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4

[nero355]

RobertMe schreef op vrijdag 8 april 2022 @ 21:33:
Als ik het goed begrijp / teruglees gaat het over mDNS? Dat heb ik gewoon op de USG draaien, maar dan wel via de gateway.config.json.

Hmm... ik zou zweren dat jij één van de medeTweakers was die mDNS via een apart Raspberry Pi bordje of iets soortgelijks regelt... My bad!

lazybones schreef op vrijdag 8 april 2022 @ 19:30:
Ik heb twee U6-LR waarvan er eentje online is op de benedenverdieping en de andere (zolder) momenteel offline omdat ik bekabeling aan het aanpassen ben.
Met die ene LR beneden heb ik dekking van achter in de tuin , gehele BG en 1e etage. Stabiel en snel, zowel op 2,4GHz als 5GHz.

Klinkt als een slechte setup waarbij je op beide frequenties keihard zit uit te zenden...

[xbeam]

nero355 schreef op vrijdag 8 april 2022 @ 23:50:
[...]

Hmm... ik zou zweren dat jij één van de medeTweakers was die mDNS via een apart Raspberry Pi bordje of iets soortgelijks regelt... My bad!


[...]

Klinkt als een slechte setup waarbij je op beide frequenties keihard zit uit te zenden...

Dat klinkt als DNS held Bert Hubert. Maar hij doet igmp proxy via een lose pi.
https://berthub.eu/articl...nteractieve-tv-zelf-doen/

*knip*

[ Voor 79% gewijzigd door rens-br op 11-04-2022 15:03 ]

[pitchdown]

Ik gebruik de laatste versie van de unifi controller-software op een windows-vm.
Met de "nieuwe interface" krijg ik nooit push-meldingen dat er een nieuwe versie van de controller beschikbaar is.
Wanneer ik overschakel naar de oude interface komt er direct een pushmelding dat er een nieuwe versie van de controller beschikbaar is.
Ik kan in de instellingen nergens een verborgen setting hierover vinden.
Iemand die dit herkend en een oplossing weet?
Een mail-notificatie naast een push-melding zou ook nog een hele fijne feature zijn. Mijn instellingen zijn hiervoor wel geconfigureerd.

[Raven]

nero355 schreef op vrijdag 8 april 2022 @ 23:50:
[...]

Hmm... ik zou zweren dat jij één van de medeTweakers was die mDNS via een apart Raspberry Pi bordje of iets soortgelijks regelt... My bad!

Misschien in de war met mijn Debian router die mDNS forward naar alle andere VLAN's zodat die daar ook opgepikt worden?

[Yahiko750]

Ik heb recent nog een FTU TY01 patchcover weten te scoren (Glasvezel, KPN), kan iemand mij vertellen welke SFP module ik hiervoor moet gebruiken in mijn UDMP? De patchcover heeft een blauwe enkele connector. KPN monteur komt over 3 weken en ik zou het fijn vinden als ik alles dan in huis heb om het snel werkend te krijgen .

[nero355]

xbeam schreef op zaterdag 9 april 2022 @ 00:58:
Dat klinkt als DNS held Bert Hubert. Maar hij doet igmp proxy via een lose pi.
https://berthub.eu/articl...nteractieve-tv-zelf-doen/

Die noemde inderdaad @Coolhva in [Ubiquiti & IPTV] Ervaringen & Discussie een tijdje geleden en dat vind ik ook een geweldige oplossing, maar die bedoelde ik niet!

Raven schreef op zaterdag 9 april 2022 @ 09:46:
Misschien in de war met mijn Debian router die mDNS forward naar alle andere VLAN's zodat die daar ook opgepikt worden?

Ook leuk, maar bedoelde ik ook niet

*knip*

Yahiko750 schreef op zaterdag 9 april 2022 @ 14:52:
Ik heb recent nog een FTU TY01 patchcover weten te scoren (Glasvezel, KPN), kan iemand mij vertellen welke SFP module ik hiervoor moet gebruiken in mijn UDMP? De patchcover heeft een blauwe enkele connector.

KPN monteur komt over 3 weken en ik zou het fijn vinden als ik alles dan in huis heb om het snel werkend te krijgen

Dan heb je dus genoeg tijd om alles zelf op te zoeken, want je bent echt niet de eerste met die wens!

Maar om je maar voor een hele grote fout te behoeden : Wat voor type verbinding heb je gekregen of was er al aanwezig

AON/GPON/XGS-PON werken allemaal op een andere manier namelijk...

[ Voor 17% gewijzigd door rens-br op 11-04-2022 15:04 ]

[lazybones]

nero355 schreef op vrijdag 8 april 2022 @ 23:50:

Klinkt als een slechte setup waarbij je op beide frequenties keihard zit uit te zenden...

Beetje voorbarige conclusie denk je niet?
Ik meet altijd eerst uit waar signaalverstorende en -dempende elementen zitten en probeer een zo goed mogelijke plaatsing te doen (dus niet in de meterkast) waarbij zendvermogen teruggeschroefd wordt om zo min mogelijk overlapping tussen AP's te hebben. Ja, helemaal achterin de tuin geven de shelly devices nu aan dat ze een slecht signaal hebben nu er 1 AP offline is, maar desondanks verbinden ze en geven ze geen enkele uitval. Bovendien helpt "keihard uitzenden" helemaal niet omdat het device aan de andere kant nooit voldoende vermogen heeft om ook "keihard" terug te zenden en dan werkt het nog niet. Het bereik van de LR is simpelweg beter dan ik had verwacht

[ Voor 10% gewijzigd door lazybones op 09-04-2022 23:48 ]

[nero355]

lazybones schreef op zaterdag 9 april 2022 @ 23:46:
Beetje voorbarige conclusie denk je niet?

Op het moment dat iemand vanuit zijn huis ook een WiFi signaal in de tuin wil hebben dan haak ik al snel af zeg maar...

Dat is en zal altijd de verkeerde aanpak blijven!

[lazybones]

nero355 schreef op zaterdag 9 april 2022 @ 23:49:
[...]

Op het moment dat iemand vanuit zijn huis ook een WiFi signaal in de tuin wil hebben dan haak ik al snel af zeg maar...

Dat is en zal altijd de verkeerde aanpak blijven!

Dat was de intentie niet en ook heb ik geen tuin van 20 meter die ik probeer te overbruggen . . . het blijkt gewoon dat met goede plaatsing en vrij zicht er verbinding is. En lager dan low kan het zendvermogen niet, dus welke aanpak jij het over hebt weet ik niet. Ben je altijd zo kort door de bocht met je conclusies zonder dat je de details weet?

[xbeam]

lazybones schreef op zondag 10 april 2022 @ 00:10:
[...]


Dat was de intentie niet en ook heb ik geen tuin van 20 meter die ik probeer te overbruggen . . . het blijkt gewoon dat met goede plaatsing en vrij zicht er verbinding is. En lager dan low kan het zendvermogen niet, dus welke aanpak jij het over hebt weet ik niet. Ben je altijd zo kort door de bocht met je conclusies zonder dat je de details weet?

Lager dan custom/aangepast kan je WiFi niet
Veel harder dan 4dbm heb ik mijn Ap’s thuis niet staan en dan ook nog 80 breed, dat is effectief dus nog minder zend vermogen

[ Voor 34% gewijzigd door xbeam op 10-04-2022 06:37 ]

[Vaevictis_]

Sinds 1,5 maand een UDM Pro in gebruik (ipv Edgeroute 16p), ik had al een cloud key en AC Lite AP en een switch van Ubiquity. Erg fijn om nu 1 apparaat te hebben ipv EdgeOS ernaast.

Enfin, ik gebruik NextDNS zowel op de UDM Pro via shell ingeinstalleerd als DNS meegegeven in DHCP. Alleen heb ik sinds 2 weken DNS issues. Resolven gaat langzaam, accesspoints vallen soms weg en wifi clients doen het opeens weer na een reconnect. Als ik b.v. DNS server op 1.1.1.1 zet dan helemaal geen issues meer maar ja daarvoor geen NextDNS genomen natuurlijk. Weet iemand wat er aan de hand zou kunnen zijn?

Ik draai op de laatste stabiele release.

[tcviper]

Vaevictis_ schreef op zondag 10 april 2022 @ 09:33:
Sinds 1,5 maand een UDM Pro in gebruik (ipv Edgeroute 16p), ik had al een cloud key en AC Lite AP en een switch van Ubiquity. Erg fijn om nu 1 apparaat te hebben ipv EdgeOS ernaast.

Enfin, ik gebruik NextDNS zowel op de UDM Pro via shell ingeinstalleerd als DNS meegegeven in DHCP. Alleen heb ik sinds 2 weken DNS issues. Resolven gaat langzaam, accesspoints vallen soms weg en wifi clients doen het opeens weer na een reconnect. Als ik b.v. DNS server op 1.1.1.1 zet dan helemaal geen issues meer maar ja daarvoor geen NextDNS genomen natuurlijk. Weet iemand wat er aan de hand zou kunnen zijn?

Ik draai op de laatste stabiele release.

Je gebruikt dus de nextdns CLI neem ik aan op je UDM? Herstart die eens voor de flauwekul:
nextdns restart op je UDM in ssh

[Vaevictis_]

tcviper schreef op zondag 10 april 2022 @ 10:16:
[...]


Je gebruikt dus de nextdns CLI neem ik aan op je UDM? Herstart die eens voor de flauwekul:
nextdns restart op je UDM in ssh

Klopt ik zie al allemaal timeouts....

code:

Apr 10 10:18:46 ubnt nextdns[21208]: Query 192.168.1.191 UDP AAAA api.nomics.com. (qry=43/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:18:51 ubnt nextdns[21208]: Query 192.168.1.191 UDP A token1.habackup.io. (qry=47/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:18:53 ubnt nextdns[21208]: Query 192.168.1.191 UDP A www.googleapis.com. (qry=47/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:18:57 ubnt nextdns[21208]: Query 192.168.1.191 UDP A buyer.17track.net. (qry=46/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:19:24 ubnt nextdns[21208]: Endpoint provider failed: &{dns.nextdns.io https://dns.nextdns.io#45.90.28.0,2a07:a8c0::,45.90.30.0,2a07:a8c1::}: exchange: roundtrip: dial tcp 45.90.28.0:443: connect: connection timed out

restart gedaan. @tcviper

code:

pr 10 10:19:26 ubnt nextdns[16991]: Listening on TCP/127.0.0.1:5553
Apr 10 10:19:26 ubnt nextdns[16991]: Starting mDNS discovery
Apr 10 10:19:26 ubnt nextdns[16991]: Listening on UDP/127.0.0.1:5553
Apr 10 10:19:26 ubnt ssh[16992]: Welcome to UbiOS
Apr 10 10:19:26 ubnt ssh[16992]: By logging in, accessing, or using the Ubiquiti product, you
Apr 10 10:19:26 ubnt ssh[16992]: acknowledge that you have read and understood the Ubiquiti
Apr 10 10:19:26 ubnt ssh[16992]: License Agreement and agree to be bound by its terms.
Apr 10 10:19:26 ubnt systemd[1]: Started NextDNS DNS53 to DoH proxy..
Apr 10 10:19:31 ubnt nextdns[16991]: Setting up router
Apr 10 10:19:33 ubnt nextdns[16991]: Query 203.0.113.2 UDP A ping.ui.com. (qry=29/res=12) 5007ms : doh resolve: context deadline exceeded
Apr 10 10:19:33 ubnt nextdns[16991]: Query 203.0.113.2 UDP A ping.ui.com. (qry=29/res=12) 5007ms : doh resolve: context deadline exceeded
Apr 10 10:19:33 ubnt nextdns[16991]: Query 203.0.113.2 UDP AAAA ping.ui.com. (qry=29/res=12) 5108ms : doh resolve: context deadline exceeded
Apr 10 10:19:33 ubnt nextdns[16991]: Query 203.0.113.2 UDP AAAA ping.ui.com. (qry=29/res=12) 5108ms : doh resolve: context deadline exceeded
Apr 10 10:19:44 ubnt nextdns[16991]: Connected 95.179.134.211:443 (con=5ms tls=149ms, TCP, TLS13)
Apr 10 10:19:44 ubnt nextdns[16991]: Switching endpoint: https://dns.nextdns.io#188.172.219.167,2a00:11c0:63:350::3,95.179.134.211,2001:19f0:5001:1faf:5400:2ff:fec8:7d49
Apr 10 10:21:05 ubnt nextdns[16991]: Connected 95.179.134.211:443 (con=5ms tls=7ms, TCP, TLS13)
#

[ Voor 40% gewijzigd door Vaevictis_ op 10-04-2022 10:28 ]

[tcviper]

Vaevictis_ schreef op zondag 10 april 2022 @ 10:21:
[...]


Klopt ik zie al allemaal timeouts....

code:

Apr 10 10:18:46 ubnt nextdns[21208]: Query 192.168.1.191 UDP AAAA api.nomics.com. (qry=43/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:18:51 ubnt nextdns[21208]: Query 192.168.1.191 UDP A token1.habackup.io. (qry=47/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:18:53 ubnt nextdns[21208]: Query 192.168.1.191 UDP A www.googleapis.com. (qry=47/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:18:57 ubnt nextdns[21208]: Query 192.168.1.191 UDP A buyer.17track.net. (qry=46/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:19:24 ubnt nextdns[21208]: Endpoint provider failed: &{dns.nextdns.io https://dns.nextdns.io#45.90.28.0,2a07:a8c0::,45.90.30.0,2a07:a8c1::}: exchange: roundtrip: dial tcp 45.90.28.0:443: connect: connection timed out

restart gedaan. @tcviper

Vreemd, dat zie ik niet bij mij. Misschien toch even melden op de NextDNS git? https://github.com/nextdns/nextdns/issues

Of eens de CLI uninstallen en opnieuw erop zetten kijken of dat iets doet.

[Vaevictis_]

tcviper schreef op zondag 10 april 2022 @ 10:28:
[...]


Vreemd, dat zie ik niet bij mij. Misschien toch even melden op de NextDNS git? https://github.com/nextdns/nextdns/issues

Of eens de CLI uninstallen en opnieuw erop zetten kijken of dat iets doet.

Toevallig gisteren de laatste versie geinstalleerd dus dat moet goed zijn. Ik zal het melden als bug.

[tomdh76]

xbeam schreef op zondag 10 april 2022 @ 06:26:
[...]

Lager dan custom/aangepast kan je WiFi niet
Veel harder dan 4dbm heb ik mijn Ap’s thuis niet staan en dan ook nog 80 breed, dat is effectief dus nog minder zend vermogen
[Afbeelding]

Ik zie je wifi kanaal op auto staan? Ik begreep dat je altijd een vast kanaal moest kiezen?

[lolgast]

xbeam schreef op zondag 10 april 2022 @ 13:49:
[...]

Klopt dat is Thuis luiheid. Plus er is hier hoog wifi verloop er zit nog wel eens iemand te prutsen en die dan voor een project of fun alle air time van een kanaal aan zichzelf toe bedeeld. . Dan zorgt een herstart voor vrije airtime en de rest in huis weer kan Netflixen.

Normaal wil en zeker bij grotere locaties inderdaad niet dat AP’s random kanalen gaan selecteren.

En dan kun je ook nog kanalen excluden van de auto-pool

[nero355]

lazybones schreef op zondag 10 april 2022 @ 00:10:
Dat was de intentie niet en ook heb ik geen tuin van 20 meter die ik probeer te overbruggen . . . het blijkt gewoon dat met goede plaatsing en vrij zicht er verbinding is. En lager dan low kan het zendvermogen niet, dus welke aanpak jij het over hebt weet ik niet.

Ben je altijd zo kort door de bocht met je conclusies zonder dat je de details weet?

Op basis van wat je tot nu toe hebt verteld blijf ik het nog steeds verkeerd vinden...

Vaevictis_ schreef op zondag 10 april 2022 @ 10:21:
Klopt ik zie al allemaal timeouts....

code:

Apr 10 10:18:46 ubnt nextdns[21208]: Query 192.168.1.191 UDP AAAA api.nomics.com. (qry=43/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:18:51 ubnt nextdns[21208]: Query 192.168.1.191 UDP A token1.habackup.io. (qry=47/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:18:53 ubnt nextdns[21208]: Query 192.168.1.191 UDP A www.googleapis.com. (qry=47/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:18:57 ubnt nextdns[21208]: Query 192.168.1.191 UDP A buyer.17track.net. (qry=46/res=12) cache fallback HTTP/2.0: doh resolve: context deadline exceeded
Apr 10 10:19:24 ubnt nextdns[21208]: Endpoint provider failed: &{dns.nextdns.io https://dns.nextdns.io#45.90.28.0,2a07:a8c0::,45.90.30.0,2a07:a8c1::}: exchange: roundtrip: dial tcp 45.90.28.0:443: connect: connection timed out

Afhankelijk zijn van derden voor je DNS verkeer zuigt gewoon zoals je in de laatste melding kan zien

Ik zou zeggen vergeet die hele bende en draai lekker volledig onafhankelijk van anderen je eigen DNS Server i.c.m. Pi-Hole zoals zij dat op hun website hebben staan : https://docs.pi-hole.net/guides/dns/unbound/

[Wachten...]

nero355 schreef op vrijdag 8 april 2022 @ 17:50:
[...]


Tja, het is maar net wat je wilt, maar soms zeg ik bepaalde dingen niet omdat ik dat grappig vind of zo hé!

Ik geloof zelfs dat @RobertMe zeg maar "De Raspberry Pi Methode" al heel wat jaartjes in gebruik heeft omdat de Ubiquiti UniFi implementatie simpelweg vreselijk brak is!

Op de EdgeRouters schijn je namelijk wat betere/logischere keuzes te hebben, maar dan nog : Je kan beter zoiets zelf bouwen om zodoende meer controle te hebben over het geheel!

Nee ik snap dat je het niet zomaar zegt, Ik heb al even gezocht op Raspberry Pi en mDNS, en ik kom dan uit bij Avahi deamon, klopt dat?

Ik moet me daar dan maar eens in gaan lezen, al vrees ik het ergste met mijn kennis.

Kun je overigens wel verklaren waarom ik wel gewoon Youtube Netflix etc allemaal kan casten vanaf alle VLANs naar IoT VLAN en dat het specifiek niet werkt voor Synology Photos? TENZIJ ik de Shield in hetzelfde VLAN gooi, dan werkt het wel. Dit is dezelfde Shield waar ik de rest dus wel heen kan casten zoals Youtube e.d.

Ik snap dit namelijk niet zo goed, want verder werkt alles hier in huis qua Casten, Ariplay etc. Ik snap dit dus niet zo goed. Of is dat precies wat je bedoelt met het onbetrouwbare van Unifi qua mDNS?

@RobertMe Kun jij hier iets zinnigs over zeggen, aangezien jij het dus wel werkend hebt op een USG? Ik heb zelf overigens een Unifi Dream Machine.

[ Voor 5% gewijzigd door Wachten... op 10-04-2022 20:02 ]

[nero355]

Wachten... schreef op zondag 10 april 2022 @ 19:59:
Ik heb al even gezocht op Raspberry Pi en mDNS, en ik kom dan uit bij Avahi deamon, klopt dat?

Ondanks dat ik er een pleureshekel aan heb is dat waarschijnlijk wel je beste gok inderdaad!

Ik moet me daar dan maar eens in gaan lezen, al vrees ik het ergste met mijn kennis.

Succes alvast!

Kun je overigens wel verklaren waarom ik wel gewoon Youtube Netflix etc allemaal kan casten vanaf alle VLANs naar IoT VLAN en dat het specifiek niet werkt voor Synology Photos? TENZIJ ik de Shield in hetzelfde VLAN gooi, dan werkt het wel. Dit is dezelfde Shield waar ik de rest dus wel heen kan casten zoals Youtube e.d.

Wat heeft je Synology Photos te maken met de Nvidia Shield TV

Zoals je het nu vertelt zou ik denken aan Firewall rules of iets in die richting op je Synology NAS ???

Ik snap dit namelijk niet zo goed, want verder werkt alles hier in huis qua Casten, Ariplay etc. Ik snap dit dus niet zo goed. Of is dat precies wat je bedoelt met het onbetrouwbare van Unifi qua mDNS?

Als je vinkjes op plekken hebt staan waarvan je niet weet wat ze doen dan zou het inderdaad zo kunnen zijn dat je de mDNS Reflector/Repeater al aan hebt staan!

[Wachten...]

nero355 schreef op zondag 10 april 2022 @ 20:04:
[...]

Ondanks dat ik er een pleureshekel aan heb is dat waarschijnlijk wel je beste gok inderdaad!

Zou je iets anders aanraden dan? Ik kan niet echt iets anders vinden. Ik heb ook geen idee waar ik zou moeten starten hoor, laat ik dat voorop stellen.

Succes alvast!

Dank je!

Wat heeft je Synology Photos te maken met de Nvidia Shield TV

Zoals je het nu vertelt zou ik denken aan Firewall rules of iets in die richting op je Synology NAS ???

Dat is ook wat ik eerder zelf aankaartte (over de firewall regels), echter zij je toen dat hier het probleem niet zou liggen. "Ik gok van niet" was je antwoord.

Dus in zoverre heeft mijn Shield ermee te maken, dat ik daar alles heen cast. En dat werkt dus voor alle apparaten in huis. Ik kan ook Airplayen naar mijn versterker etc. Dus ergens heb ik het idee dat mDNS gewoon werkt en dat het speciefiek iets is met of naar de NAS.

Het enige verschil met de ander diensten zoals Youtube, Netflix etc. Is dat zij dingen uit de cloud plukken. De Synology Photo app doet dit niet en maakt direct verbinding met de server. Dit is ook de reden dat ik zelf aan een Firewall probleem zat te denken. Zet ik echte de Firewall uit op de NAS, dan werkt het nog steeds niet, en ik heb ook al een keer specifiek het IoT netwerk toegang gegeven om connectie te mogen maken met de server (dit dan in de Firewall instellingen van de Unifi)

[...]

Als je vinkjes op plekken hebt staan waarvan je niet weet wat ze doen dan zou het inderdaad zo kunnen zijn dat je de mDNS Reflector/Repeater al aan hebt staan!

Zoals eerder gezegt staat de optie mDNS aan op mijn Unifi
Ik heb min of meer onderstaande tutorial gevolgd, en ik weet het, je houdt niet van video`s

[nero355]

Wachten... schreef op zondag 10 april 2022 @ 20:21:
Zou je iets anders aanraden dan?

Mijn blik op het gekke ding is meer vanuit een Client oogpunt : AVAHI staat echt overal zowat geïnstalleerd, terwijl ik zoiets heb van "Doe eens niet! Er is al genoeg Multicast rommel op mijn netwerk en dingen als <hostname>.local gebruik ik toch nooit!"

Ik kan niet echt iets anders vinden. Ik heb ook geen idee waar ik zou moeten starten hoor, laat ik dat voorop stellen.

Ga gewoon ermee aan de slag en het komt wel goed!

Dat is ook wat ik eerder zelf aankaartte (over de firewall regels), echter zij je toen dat hier het probleem niet zou liggen. "Ik gok van niet" was je antwoord.

Het was een gok hé!

Maar nu ik dit weet :

Dus in zoverre heeft mijn Shield ermee te maken, dat ik daar alles heen cast. En dat werkt dus voor alle apparaten in huis. Ik kan ook Airplayen naar mijn versterker etc. Dus ergens heb ik het idee dat mDNS gewoon werkt en dat het speciefiek iets is met of naar de NAS.

Het enige verschil met de ander diensten zoals Youtube, Netflix etc. Is dat zij dingen uit de cloud plukken. De Synology Photo app doet dit niet en maakt direct verbinding met de server. Dit is ook de reden dat ik zelf aan een Firewall probleem zat te denken. Zet ik echte de Firewall uit op de NAS, dan werkt het nog steeds niet, en ik heb ook al een keer specifiek het IoT netwerk toegang gegeven om connectie te mogen maken met de server (dit dan in de Firewall instellingen van de Unifi)

Zou ik zeggen dat je Nvidia Shield TV de data op je NAS wil ophalen en je moet aangeven dat die zelf een verbinding mag initiëren richting je NAS in je Firewall Rules

Maar dan op de juiste manier deze keer...

Zoals eerder gezegt staat de optie mDNS aan op mijn Unifi
Ik heb min of meer onderstaande tutorial gevolgd, en ik weet het, je houdt niet van video`s

[YouTube: Part 2 | Ultimate Home Network 2021 | VLANs, Firewall Rules, and WiFi Networks for IoT UniFi 6.0]

Heerlijk die "I have no idea what I am doing, but the YouTube guy told me to do it, so it should work!" generatie...

[g1n0]

*knip*

Ik heb laatste tijd veel last van hangende ipsec tunneltjes. Zover ik weet en kan vinden hebben die USG-Pro nog steeds geen DPD?
Meer mensen deze problemen (gehad)?

[ Voor 24% gewijzigd door rens-br op 11-04-2022 11:11 ]

[pitchdown]

pitchdown schreef op zaterdag 9 april 2022 @ 08:08:
Ik gebruik de laatste versie van de unifi controller-software op een windows-vm.
Met de "nieuwe interface" krijg ik nooit push-meldingen dat er een nieuwe versie van de controller beschikbaar is.
Wanneer ik overschakel naar de oude interface komt er direct een pushmelding dat er een nieuwe versie van de controller beschikbaar is.
Ik kan in de instellingen nergens een verborgen setting hierover vinden.
Iemand die dit herkend en een oplossing weet?
Een mail-notificatie naast een push-melding zou ook nog een hele fijne feature zijn. Mijn instellingen zijn hiervoor wel geconfigureerd.

Iemand?

[Wachten...]

nero355 schreef op zondag 10 april 2022 @ 23:47:
[...]

Mijn blik op het gekke ding is meer vanuit een Client oogpunt : AVAHI staat echt overal zowat geïnstalleerd, terwijl ik zoiets heb van "Doe eens niet! Er is al genoeg Multicast rommel op mijn netwerk en dingen als <hostname>.local gebruik ik toch nooit!"


[...]

Ga gewoon ermee aan de slag en het komt wel goed!

[...]

Ja maar ik snap dan dus nog steeds niet waar te beginnen. Ik probeer te zoeken, maar snap er niet zoveel van, zeker omdat ik enkel AVAHI vind, en dat jij eigenlijk zegt om dit weer niet te gebruiken. Dus ik heb echt werkelijk geen idee wat ik nou wel of niet moet doen, en heb al wat searches gedaan, maar kom er niet uit.

(echter lees even onderstaand, want het probleem is gevonden)

Maar nu ik dit weet :

[...]

Zou ik zeggen dat je Nvidia Shield TV de data op je NAS wil ophalen en je moet aangeven dat die zelf een verbinding mag initiëren richting je NAS in je Firewall Rules

Maar dan op de juiste manier deze keer...

Ik heb dus even al mijn firewall regels uitgezet in Unifi en dan werkt het. Kortom alles werkt in theorie, echter gaat er iets niet goed met een allow regels in Unifi en ik snap niet zo goed waarom.

Gooi ik deze regel er in:
Allow IoT netwerk (als source) en dan als destination (default network) dan werkt het:



Ik wil echter dat enkel het IoT netwerk kan communiceren met enkel de server (het liefst op een specifieke poort) maar als ik zelfs onderstaand doe
Allow IoT netwerk (als source) en dan als destination (Synology IP adres) dan werkt het niet.

[ Voor 5% gewijzigd door Wachten... op 11-04-2022 10:32 ]

[rens-br]

Ik heb wat offtopic berichten verwijderd.

[loyske]

RobertMe schreef op vrijdag 8 april 2022 @ 21:33:
[...]

He wat? Wat heb ik gemist? Als ik het goed begrijp / teruglees gaat het over mDNS? Dat heb ik gewoon op de USG draaien, maar dan wel via de gateway.config.json. De optie die in de Controller zit gebruikt in ieder geval op de USG een backend dat het verkeer inderdaad op alle interfaces gooit. Via de gateway.config.json kun je een andere implementatie gebruiken, die wel configureerbaar is en per interface aan gezet moet worden. Maar uiteraard werkt dit dus weer alleen op de USG en niet voor de UDM / UDR / UXG.

JSON:

{
  "service": {
    "mdns": {
      "repeater": {
        "interface": [
          "eth1.10",
          "eth1.11",
          "eth1.20"
        ]
      }
    }
  }
}

Moet je dan de setting per network voor mDNS ook nog activeren?

[nero355]

Wachten... schreef op maandag 11 april 2022 @ 09:56:
Ja maar ik snap dan dus nog steeds niet waar te beginnen.

- Linux basics leren.
- Networking basics leren.

En dan pas met dit soort dingen knoeien!

Ik probeer te zoeken, maar snap er niet zoveel van

Komt omdat je de basiskennis mist!

zeker omdat ik enkel AVAHI vind, en dat jij eigenlijk zegt om dit weer niet te gebruiken.

Dat zeg ik helemaal niet!

Dus ik heb echt werkelijk geen idee wat ik nou wel of niet moet doen, en heb al wat searches gedaan, maar kom er niet uit.

Als ik dit zoek : https://duckduckgo.com/?q=avahi+mdns+with+vlan+interfaces
Dan kom ik hierop uit : https://blog.christophers...ns-with-avahi-on-openwrt/
Of dit : http://nateallen.co.uk/airplay-across-vlans/

Ziet er simpel genoeg uit zo!

Ik heb dus even al mijn firewall regels uitgezet in Unifi en dan werkt het. Kortom alles werkt in theorie, echter gaat er iets niet goed met een allow regels in Unifi en ik snap niet zo goed waarom.

Gooi ik deze regel er in:
Allow IoT netwerk (als source) en dan als destination (default network) dan werkt het:

[Afbeelding]

Ik wil echter dat enkel het IoT netwerk kan communiceren met enkel de server (het liefst op een specifieke poort) maar als ik zelfs onderstaand doe
Allow IoT netwerk (als source) en dan als destination (Synology IP adres) dan werkt het niet.

[Afbeelding]

Daar moet iemand anders je mee helpen, want ik doe echt niks met de Firewall Rules binnen UniFi

Als ik iets wil afschermen dan donder ik het geheel gewoon in een Guest VLAN

g1n0 schreef op maandag 11 april 2022 @ 06:54:
Ik heb laatste tijd veel last van hangende ipsec tunneltjes.

Zover ik weet en kan vinden hebben die USG-Pro nog steeds geen DPD?

Meer mensen deze problemen (gehad)?

DPD

Je zal echt wat meer info moeten geven voordat iemand ook maar iets zinnigs over je probleem kan zeggen!

[Roy Batty]

-

[ Voor 100% gewijzigd door Roy Batty op 11-04-2022 21:35 ]

[Huub-]

Wachten... schreef op maandag 11 april 2022 @ 09:56:
[...]

Ja maar ik snap dan dus nog steeds niet waar te beginnen. Ik probeer te zoeken, maar snap er niet zoveel van, zeker omdat ik enkel AVAHI vind, en dat jij eigenlijk zegt om dit weer niet te gebruiken. Dus ik heb echt werkelijk geen idee wat ik nou wel of niet moet doen, en heb al wat searches gedaan, maar kom er niet uit.

(echter lees even onderstaand, want het probleem is gevonden)


[...]

Ik heb dus even al mijn firewall regels uitgezet in Unifi en dan werkt het. Kortom alles werkt in theorie, echter gaat er iets niet goed met een allow regels in Unifi en ik snap niet zo goed waarom.

Gooi ik deze regel er in:
Allow IoT netwerk (als source) en dan als destination (default network) dan werkt het:

[Afbeelding]

Ik wil echter dat enkel het IoT netwerk kan communiceren met enkel de server (het liefst op een specifieke poort) maar als ik zelfs onderstaand doe
Allow IoT netwerk (als source) en dan als destination (Synology IP adres) dan werkt het niet.

[Afbeelding]

Ben het met @nero355 eens, je geeft veel te weinig info om iets zinnigs te kunnen zeggen. Advies: begin simpel en bereidt het dan langzaam uit. Er zijn voldoende YouTube filmpjes te vinden over hoe je Firewall rules binnen UniFi kunt gebruiken…

[-Jaap-io]

De dream machine pro SE is/was in stock 😎

[Laurences]

nero355 schreef op donderdag 7 april 2022 @ 23:26:


[...]

Ik heb dit echt serieus nog nooit meegemaakt, maar lees het wel vaker in dit topic dus als iemand het daadwerkelijke antwoord op het verhaal weet dan ben ik daar ook wel naar benieuwd!

Een tijdje terug werd er nog over gesproken, maar was er geen duidelijk antwoord geloof ik...

Inmiddels bijna een week verder en we hebben nog geen internet thuis. Dit begint érg vervelend te worden en dringend zou ik om jullie hulp willen vragen.

Ik heb een cloudkey gen 2 plus aangeschaft om die controller eenvoudig te kunnen bedienen. Werkt goed, althans, als ik de modem van t-mobile op de switch aangesloten heb. WiFi netwerk aangemaakt via de controller die draait op de cloudkey. Alles goed tot hier.

Op het moment dat ik de modem van t-mobile verwissel met die van Ziggo (een connectbox in bridge modus) ben ik direct het aangemaakte WiFi netwerk kwijt. Ik kan vanaf dat moment dus ook niet meer de controller bereiken om evt iets in te stellen of te troubleshooten.

Aan de Ziggo kant krijg ik te horen dat de connectbox correct staat ingesteld in bridge modus (zelfs nog even laten terugzetten in WiFi modus om te checken of dat wel werkte, dat werkt, vervolgens weer in bridge laten plaatsen).

Zien jullie hier een stap of handeling die ik kan uitvoeren om dit werkend te krijgen. Wellicht een stap of handeling in de instellingen van de controller voordat ik de ziggo modem aansluit?

Met vriendelijke en hulp vragende groet.

[lier]

Wat gaat in dat geval de routerfunctie vervullen, @Laurences ?
Want zoals ik het lees sluit je een bridged modem op de switch aan.

[Laurences]

lier schreef op dinsdag 12 april 2022 @ 13:41:
Wat gaat in dat geval de routerfunctie vervullen, @Laurences ?
Want zoals ik het lees sluit je een bridged modem op de switch aan.

Dat klopt, en ik begrijp uit jouw reactie dat dat niet de bedoeling is(?). Voorheen werkte dit namelijk wél, voordat Ziggo een onderhoud pleegde in onze regio (6 op 7 april).

Ik gebruik de Unifi Switch US-8-60W.

[ Voor 4% gewijzigd door Laurences op 12-04-2022 13:50 ]

[lier]

Laurences schreef op dinsdag 12 april 2022 @ 13:48:
Dat klopt, en ik begrijp uit jouw reactie dat dat niet de bedoeling is(?). Voorheen werkte dit namelijk wél, voordat Ziggo een onderhoud pleegde in onze regio (6 op 7 april).

Tenzij je je hele netwerk publiek toegankelijk wil maken via Internet (mocht Ziggo jou zoveel IP adressen geven), anders is het netjes gezegd niet zo slim. Waarom staat je modem in bridge? Heb je een eigen router liggen die je in wil gaan zetten?

[RobertMe]

Laurences schreef op dinsdag 12 april 2022 @ 13:48:
[...]


Dat klopt, en ik begrijp uit jouw reactie dat dat niet de bedoeling is(?). Voorheen werkte dit namelijk wél, voordat Ziggo een onderhoud pleegde in onze regio (6 op 7 april).

Ik gebruik de Unifi Switch US-8-60W.

No way dat dat gewerkt heeft. Waarschijnlijk heeft het modem van Ziggo gewoon in router mode gestaan en is dat aangepast naar bridge mode.

[Frij5fd]

Laurences schreef op dinsdag 12 april 2022 @ 13:48:
[...]


Dat klopt, en ik begrijp uit jouw reactie dat dat niet de bedoeling is(?). Voorheen werkte dit namelijk wél, voordat Ziggo een onderhoud pleegde in onze regio (6 op 7 april).

Ik gebruik de Unifi Switch US-8-60W.

https://www.intogadgets.n...-switch-wat-het-verschil/
Je zal je toch wat moeten verdiepen, via internet of op een andere manier, hoe netwerken werken. Als je dingen verkeerd verbindt of configureert kan je thuisnetwerk open te komen staan naar het internet toe. Ik zou zsm de Ziggo router van bridged afhalen (en wifi van het ding desgewenst uitzetten). Dan daarna kijken of het echt meerwaarde heeft om zelf een router in te gaan zetten; kosten (in euro's en tijd), versus risico's van fout configureren en benefits van goed configureren afwegen.

[Quad]

Bridge kan wel, maar dan moet je een eigen router erachter zetten, bijvoorbeeld de Ubiquiti Dream Machine.
Ik lees ook iets over een T-Mobile router, wat is daar de bedoeling van als je Ziggo hebt?

[xbeam]

Ubnt nieuws brief ( is de link)
https://mailchi.mp/ubnt/welcome-to-ubiquiti-insider

[Embed: welkominsider]

[ Voor 219% gewijzigd door xbeam op 13-04-2022 00:54 ]

[Airw0lf]

Laurences schreef op dinsdag 12 april 2022 @ 13:28:
[...]


Inmiddels bijna een week verder en we hebben nog geen internet thuis. Dit begint érg vervelend te worden en dringend zou ik om jullie hulp willen vragen.

Ik heb een cloudkey gen 2 plus aangeschaft om die controller eenvoudig te kunnen bedienen. Werkt goed, althans, als ik de modem van t-mobile op de switch aangesloten heb. WiFi netwerk aangemaakt via de controller die draait op de cloudkey. Alles goed tot hier.

Op het moment dat ik de modem van t-mobile verwissel met die van Ziggo (een connectbox in bridge modus) ben ik direct het aangemaakte WiFi netwerk kwijt. Ik kan vanaf dat moment dus ook niet meer de controller bereiken om evt iets in te stellen of te troubleshooten.

Aan de Ziggo kant krijg ik te horen dat de connectbox correct staat ingesteld in bridge modus (zelfs nog even laten terugzetten in WiFi modus om te checken of dat wel werkte, dat werkt, vervolgens weer in bridge laten plaatsen).

Zien jullie hier een stap of handeling die ik kan uitvoeren om dit werkend te krijgen. Wellicht een stap of handeling in de instellingen van de controller voordat ik de ziggo modem aansluit?

Met vriendelijke en hulp vragende groet.

Als ik het hele verhaal zo lees lijkt het erop dat je in twee gevallen een werkende opstelling hebt.
(1) - de t-mobile router tussen de ziggo router (wat in bridge mode staat) en de rest
(2) - de ziggo router van bridge mode afhalen zodat die als router acteert naar de rest.

Eigenlijk geef je daarmee de oplossing zelf al aan: je hebt een router nodig... welk smaakje maakt niet uit.

Doe je dat niet, dan zal het ziggo netwerk volharden met een IP-adres toewijzen aan het eerst-beste apparaat wat daar via DHCP om vraagt. Elke volgende DHCP-aanvraag wordt geweigerd waardoor er niks meer werkt => er worden immers geen (bruikbare) IP-adressen meer uitgedeeld. Hooguit een aantal "willekeurige" in de reeks 196.254.0.0 (met subnet masker 255.255.0.0). Maar dat gaat je verder niks brengen.

Eventuele vaste IP-adressen spelen niet meer mee omdat ze in een ander IP-net zitten. Van dat IP-net ontbreekt de router... die van t-mobile, ziggo of nog iets anders => je bent alles "kwijt".

Dus voor de korte termijn: een van twee routers er toch tussen laten staan?
Voor de langere termijn: toch een Ubiquiti router er tussen plaatsen?

Met daarnaast inlezen in de principe werking van ethernet (kabel en wifi), ethernet-bridging/vlans, routing en UDP/TCP mechanismes? Oftewel de principewerking van iets wat in netwerkenland OSI-laag 1 t/m 4 heet? En dan nog eens kijken hoe je het zou willen hebben?

[Acradavos]

Zojuist mijn UDM SE aangesloten, maar tot mijn verbazing zie ik maar 5,71GB internal storage. (i.p.v. 128GB)

[Verwijderd]

Acradavos schreef op woensdag 13 april 2022 @ 17:59:
Zojuist mijn UDM SE aangesloten, maar tot mijn verbazing zie ik maar 5,71GB internal storage. (i.p.v. 128GB)

[Afbeelding]

128GB is alleen zichtbaar voor Protect

[Acradavos]

Verwijderd schreef op woensdag 13 april 2022 @ 18:13:
[...]


128GB is alleen zichtbaar voor Protect

Ahh vandaar, nu maar eens verder spelen. 😛

[MJV]

Ik ben een beetje teneinde raad aan het raken. Ik heb een setup met 2 Unifi AC-lite's en een Edgerouter X. Netwerk is opgedeeld in VLANs, maar dat is voor nu niet relevant verwacht ik. Ik draai DHCP op de Edgerouter. Zowel de 2.4Ghz als de 5Ghz hebben hetzelfde SSID.

Sinds kort heb ik een nieuwe smartphone, een Samsung A52S, de eerste smartphone hier in huis met wi-fi op de 5Ghz band. De smartphone verliest echter elke keer internverbinding nadat hij tussen twee AP's is geroamd. De wifi-verbinding blijft dus intact (5 streepjes), maar er verschijnt een uitroepteken, en er is geen connectiviteit meer. Als ik wifi even aan- en uitzet maakt de smartphone opnieuw verbinding en is het probleem weg, totdat ik weer rondloop in huis en de smartphone gaat roamen.

Wat ik zoal al geprobeerd heb:
- Multicast aanzetten (Unifi)
- Andere DNS server (i.p.v. Pihole)
- Band Steering voor alle AP's uitgezet
- Fast Roaming uit/aan gezet; daarmee komt het probleem minder vaak voor (want minder vaak roaming), maar lost het probleem niet op.
- IPv6 op de Edgerouter uitgezet.
- Op de smartphone gekozen voor wel/geen random mac-adressen.
- Diverse Transmit Power instellingen; maar denk dat dat alleen iets zegt over wanneer/hoe er geroamd wordt.
- Op de Samsung: netwerkinstellingen gereset.

Probleem blijft dus: na roamen internetconnectiviteit op smartphone weg. Lijkt dus specifiek in 5Ghz te zitten, heb het met oudere smartphones nooit aan de hand gehad.

Wat kan ik proberen om dit op te lossen?

[Polyphemus]

MJV schreef op woensdag 13 april 2022 @ 20:01:
Ik ben een beetje teneinde raad aan het raken. Ik heb een setup met 2 Unifi AC-lite's en een Edgerouter X. Netwerk is opgedeeld in VLANs, maar dat is voor nu niet relevant verwacht ik. Ik draai DHCP op de Edgerouter. Zowel de 2.4Ghz als de 5Ghz hebben hetzelfde SSID.

Sinds kort heb ik een nieuwe smartphone, een Samsung A52S, de eerste smartphone hier in huis met wi-fi op de 5Ghz band. De smartphone verliest echter elke keer internverbinding nadat hij tussen twee AP's is geroamd. De wifi-verbinding blijft dus intact (5 streepjes), maar er verschijnt een uitroepteken, en er is geen connectiviteit meer. Als ik wifi even aan- en uitzet maakt de smartphone opnieuw verbinding en is het probleem weg, totdat ik weer rondloop in huis en de smartphone gaat roamen.

Wat ik zoal al geprobeerd heb:
- Multicast aanzetten (Unifi)
- Andere DNS server (i.p.v. Pihole)
- Band Steering voor alle AP's uitgezet
- Fast Roaming uit/aan gezet; daarmee komt het probleem minder vaak voor (want minder vaak roaming), maar lost het probleem niet op.
- IPv6 op de Edgerouter uitgezet.
- Op de smartphone gekozen voor wel/geen random mac-adressen.
- Diverse Transmit Power instellingen; maar denk dat dat alleen iets zegt over wanneer/hoe er geroamd wordt.
- Op de Samsung: netwerkinstellingen gereset.

Probleem blijft dus: na roamen internetconnectiviteit op smartphone weg. Lijkt dus specifiek in 5Ghz te zitten, heb het met oudere smartphones nooit aan de hand gehad.

Wat kan ik proberen om dit op te lossen?

Voor dit soort problemen heb ik uiteindelijk maar twee aparte SSIDs aangemaakt, eentje voor 2,4 en eentje voor 5. Alle apparaten die 5 GHz aankunnen laat ik daarmee verbinden, al het 'oude', wat geen 5 GHz aankan, laat ik op de 2,4 SSID connecten... Ik had het met mijn iPhones in huis jaren gelezen.

[MJV]

Polyphemus schreef op woensdag 13 april 2022 @ 20:06:
[...]

Voor dit soort problemen heb ik uiteindelijk maar twee aparte SSIDs aangemaakt, eentje voor 2,4 en eentje voor 5. Alle apparaten die 5 GHz aankunnen laat ik daarmee verbinden, al het 'oude', wat geen 5 GHz aankan, laat ik op de 2,4 SSID connecten... Ik had het met mijn iPhones in huis jaren gelezen.

Heb het maar geprobeerd, maar op zowel het 2.4Ghz als op het 5Ghz hetzelfde probleem.

Wat me wel opvalt dat ik heel veel van deze events in mijn serverlog heb:

code:

[2022-04-13T18:19:15,509] <inform_stat-1> WARN  event  - Unrendered device from unknown type ap_from while trying to render device name
[2022-04-13T18:19:15,509] <inform_stat-1> WARN  event  - Unrendered device from unknown type ap_to while trying to render device name

Volgens de Unifi-forums kan het geen kwaad, maar ik vind het vreemd.

[verzenden]

Probeer eens op je Samsung telefoon randomized MAC uit te zetten. Instellingen, verbindingen, wifi, puntjes rechtsboven, advanced, manage network, selecteer je wifi netwerk, bekijk meer, set Mac adres type to phone.

Ben benieuwd of dit verschil maakt.

[Tonne]

MJV schreef op woensdag 13 april 2022 @ 20:01:
Ik ben een beetje teneinde raad aan het raken. Ik heb een setup met 2 Unifi AC-lite's en een Edgerouter X. Netwerk is opgedeeld in VLANs, maar dat is voor nu niet relevant verwacht ik. Ik draai DHCP op de Edgerouter. Zowel de 2.4Ghz als de 5Ghz hebben hetzelfde SSID.

Sinds kort heb ik een nieuwe smartphone, een Samsung A52S, de eerste smartphone hier in huis met wi-fi op de 5Ghz band. De smartphone verliest echter elke keer internverbinding nadat hij tussen twee AP's is geroamd. De wifi-verbinding blijft dus intact (5 streepjes), maar er verschijnt een uitroepteken, en er is geen connectiviteit meer. Als ik wifi even aan- en uitzet maakt de smartphone opnieuw verbinding en is het probleem weg, totdat ik weer rondloop in huis en de smartphone gaat roamen.

Wat ik zoal al geprobeerd heb:
- Multicast aanzetten (Unifi)
- Andere DNS server (i.p.v. Pihole)
- Band Steering voor alle AP's uitgezet
- Fast Roaming uit/aan gezet; daarmee komt het probleem minder vaak voor (want minder vaak roaming), maar lost het probleem niet op.
- IPv6 op de Edgerouter uitgezet.
- Op de smartphone gekozen voor wel/geen random mac-adressen.
- Diverse Transmit Power instellingen; maar denk dat dat alleen iets zegt over wanneer/hoe er geroamd wordt.
- Op de Samsung: netwerkinstellingen gereset.

Probleem blijft dus: na roamen internetconnectiviteit op smartphone weg. Lijkt dus specifiek in 5Ghz te zitten, heb het met oudere smartphones nooit aan de hand gehad.

Wat kan ik proberen om dit op te lossen?

Welke firmware draai je op de ap’s?

[MJV]

Tonne schreef op woensdag 13 april 2022 @ 21:01:
[...]

Welke firmware draai je op de ap’s?

De meest recente.

Nadat ik ergens een andere 5Ghz telefoon vandaan heb gehaald, die gewoon bleek te werken, en mijn laptop die ook probleemloos roamde; werd de verdenking dat het in de A52S zelf zat. Nadat ik de smartphone opnieuw heb opgestart lijkt het probleem opgelost. Had ik eerder moeten proberen natuurlijk.

[JBS]

Aangezien mijn Zigbee2MQTT poort 8080 in gebruik heeft, wil ik die poort graag wijzigen voor de UniFi Controller. Deze draait, net als Zigbee2MQTT, in docker. Iemand dit succesvol kunnen doen? Inloggen op de docker container en in het setting bestand de inform port aanpassen? Worden de AP's door de Controller geïnformeerd over dit gewijzigde poort nummer?

[Miki]

JBS schreef op donderdag 14 april 2022 @ 07:05:
Aangezien mijn Zigbee2MQTT poort 8080 in gebruik heeft, wil ik die poort graag wijzigen voor de UniFi Controller. Deze draait, net als Zigbee2MQTT, in docker. Iemand dit succesvol kunnen doen? Inloggen op de docker container en in het setting bestand de inform port aanpassen? Worden de AP's door de Controller geïnformeerd over dit gewijzigde poort nummer?

Lees je eens in over het opzetten van een macvlan in docker

[et36s]

Is er al iemand met een Unifi Dreammachine Pro Special Edition op een KPN 1GB glasvezel verbinding. Ik heb namelijk problemen met het behalen van de maximale snelheid van 60MB/s up zoals beschreven in

https://community.ui.com/...2f-41c7-9188-a30036c2e4c2

Op basis daarvan de UDM teruggestuurd en een 2e hand USG aangeschaft en haal zonder problemen 100MB/s. Dit werkt nu ong. een half jaar perfect maar een usg + switch poe + switch + wifi ap + cloudkey is geen elegante oplossing. Zou hem graag vervangen door een UDM PRO Special Edition mits de issues met KPN opgelost zijn.

[RobertMe]

et36s schreef op donderdag 14 april 2022 @ 09:42:
Is er al iemand met een Unifi Dreammachine Pro Special Edition op een KPN 1GB glasvezel verbinding. Ik heb namelijk problemen met het behalen van de maximale snelheid van 60MB/s up zoals beschreven in

https://community.ui.com/...2f-41c7-9188-a30036c2e4c2

Op basis daarvan de UDM teruggestuurd en een 2e hand USG aangeschaft en haal zonder problemen 100MB/s. Dit werkt nu ong. een half jaar perfect maar een usg + switch poe + switch + wifi ap + cloudkey is geen elegante oplossing. Zou hem graag vervangen door een UDM PRO Special Edition mits de issues met KPN opgelost zijn.

De UDM Pro SE bestaat niet Bij de (GA) release hebben ze de "Pro" laten vallen. On a more serious note: dat issue zit in PPPoE toch? En ik meen dat daarvoor een of meerdere firmware fixes zijn geweest.

[Verwijderd]

et36s schreef op donderdag 14 april 2022 @ 09:42:
Is er al iemand met een Unifi Dreammachine Pro Special Edition op een KPN 1GB glasvezel verbinding. Ik heb namelijk problemen met het behalen van de maximale snelheid van 60MB/s up zoals beschreven in

https://community.ui.com/...2f-41c7-9188-a30036c2e4c2

Op basis daarvan de UDM teruggestuurd en een 2e hand USG aangeschaft en haal zonder problemen 100MB/s. Dit werkt nu ong. een half jaar perfect maar een usg + switch poe + switch + wifi ap + cloudkey is geen elegante oplossing. Zou hem graag vervangen door een UDM PRO Special Edition mits de issues met KPN opgelost zijn.

Ik dacht op het forum gelezen te hebben dat de SE niet de problemen met PPPoE had.

[Airw0lf]

Laurences schreef op donderdag 7 april 2022 @ 22:48:
Al jaren met veel plezier gebruik gemaakt van UniFi voor ons thuisnetwerk. We gebruiken een switch met twee APs. Sinds vandaag staan de AP om de 5 seconden te blauw te knipperen. Volgens UniFi staan ze in isolated mode.

Ik heb een modem van t-mobile in bridge modus aangesloten. Het UniFi netwerk werkt dan naar behoren.

Voor zover ik weet (en voor zover nog relevant) heeft het modem van t-mobile geen bridge mogelijkheid => het is altijd een router.
Hooguit kan je iets doen dat heet DMZ met een vast IP-adres naar een achterliggende, tweede router. Maar dat is niet hetzelfde als bridge mode.

[ Voor 3% gewijzigd door Airw0lf op 14-04-2022 12:34 ]

[Tortelli]

HKLM_ schreef op zondag 9 januari 2022 @ 12:28:
[...]


Die droom kan je wel vergeten de opvolger voor de USG is de UDM serie. De UDM, UDM-Pro, UDR is wat ubnt momenteel wilt.

RobertMe schreef op zondag 9 januari 2022 @ 11:33:
[...]

Kleine correctie: de UDM kan niet offloaden <punt>. De UDM zit alleen een ARM SoC in en die doet alles. De USG zit wel een dedicated chip in die veel taken kan overnemen (maar als die het niet kan moet ook daar alles op de CPU worden gedaan).


[...]

Volgens mij komt het voornamelijk neer op een software probleem en niet een hardware probleem. PPPoE op zichzelf dat niet efficiënt is of dat het op de UDM niet efficiënt is ingericht. Dat de UDM wél IDS/IPS kan doen op 1Gbit/s (en sneller?) maar geen PPPoE lijkt mij toch aan te tonen dat de CPU het probleem niet is.

Wat is de status eigenlijk van de UDM Pro (SE) en KPN verbindingen? Nog altijd hetzelfde "hoe cpu load" probleem waardoor de uploadsnelheid blijft hangen rond de 500Mbit?

Edit: was net met et36s hierover in discussie. Hij was me voor met deze vraag .

[ Voor 49% gewijzigd door Tortelli op 14-04-2022 12:11 ]

[ph4nt0m]

Tortelli schreef op donderdag 14 april 2022 @ 12:07:
[...]


[...]


Wat is de status eigenlijk van de UDM Pro (SE) en KPN verbindingen? Nog altijd hetzelfde "hoe cpu load" probleem waardoor de uploadsnelheid blijft hangen rond de 500Mbit?

Edit: was net met et36s hierover in discussie. Hij was me voor met deze vraag .

Ikzelf heb ene UDMpro en haal stabiel 1gb up en down. zelfs met IPS/IDS aan

Tortelli schreef op donderdag 14 april 2022 @ 13:03:
[...]


KPN met PPPoE? Ik heb in januari een UDM Pro getest en had het probleem wat vaker omschreven wordt. Upload bleef hangen rond de 500Mbit (met 1 cpu tread maxxed out).

Kortom de UDM toen verkocht aan een medetweaker en mijn USG maar weer gaan gebruiken.

KPN met PPPoE ja, ik geloof dat ze het e.e.a. hebben gepatched / verholpen in afgelopen sofware versies.

[ Voor 34% gewijzigd door ph4nt0m op 14-04-2022 13:16 ]

[Tortelli]

ph4nt0m schreef op donderdag 14 april 2022 @ 12:59:
[...]


Ikzelf heb ene UDMpro en haal stabiel 1gb up en down. zelfs met IPS/IDS aan

KPN met PPPoE? Ik heb in januari een UDM Pro getest en had het probleem wat vaker omschreven wordt. Upload bleef hangen rond de 500Mbit (met 1 cpu tread maxxed out).

Kortom de UDM toen verkocht aan een medetweaker en mijn USG maar weer gaan gebruiken.

[ Voor 10% gewijzigd door Tortelli op 14-04-2022 13:04 ]

[EagleTitan]

Vanaf een Synology, via een USW-16 naar de UDM-Pro (KPN met PPPoE), thread management uitgeschakeld, device en traffic identification ingeschakeld.

code:

$ curl http://speedtest.ams01.softlayer.com/downloads/test500.zip -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  500M  100  500M    0     0   105M      0  0:00:04  0:00:04 --:--:--  106M

[mydogisgone]

Tortelli schreef op donderdag 14 april 2022 @ 13:03:
[...]


KPN met PPPoE? Ik heb in januari een UDM Pro getest en had het probleem wat vaker omschreven wordt. Upload bleef hangen rond de 500Mbit (met 1 cpu tread maxxed out).

Kortom de UDM toen verkocht aan een medetweaker en mijn USG maar weer gaan gebruiken.

Hier ook een UDM SE met KPN PPPoE en haal hier tegen de 950mbps met IPS/IDS aan
Rechtstreeks op het glas met een 1000BASE-BX BiDi SFP 1310nm-TX/1550nm-RX module

Naar mijn weten zijn die PPPoE problemen al een tijdje terug opgelost in een update.

[ Voor 7% gewijzigd door mydogisgone op 14-04-2022 13:24 ]

[Tortelli]

Nice. In januari was dit nog niet het geval!

[Mimiix]

Ik kom hier ook lurken Sinds we in onze nieuwe woning zitten heb ik een UDM PRO met 2x een AC-LR en een Flex switch.

Ik gebruik de UDM PRO als hoofd router en zit direct op de KPN Glasvezel aansluiting. Met de DPI en Threat management haal ik 950 up/down.

[Tortelli]

Al lang?
Toen ik de UDM had begin januari bleef hij echt hangen rond de 500Mbit upload.

Hebben jullie er camera's aan hangen overigens?

EagleTitan schreef op donderdag 14 april 2022 @ 13:15:
Vanaf een Synology, via een USW-16 naar de UDM-Pro (KPN met PPPoE), thread management uitgeschakeld, device en traffic identification ingeschakeld.

code:

$ curl http://speedtest.ams01.softlayer.com/downloads/test500.zip -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  500M  100  500M    0     0   105M      0  0:00:04  0:00:04 --:--:--  106M

En multitreaded?

[ Voor 69% gewijzigd door Tortelli op 14-04-2022 14:11 ]

[nero355]

EagleTitan schreef op donderdag 14 april 2022 @ 13:15:
Vanaf een Synology, via een USW-16 naar de UDM-Pro (KPN met PPPoE), thread management uitgeschakeld, device en traffic identification ingeschakeld.

code:

$ curl http://speedtest.ams01.softlayer.com/downloads/test500.zip -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  500M  100  500M    0     0   105M      0  0:00:04  0:00:04 --:--:--  106M

Een 500 MB groot bestand is IMHO te klein om de snelheid echt goed te meten...

Pak eens iets richting de 1000 MB of nog beter : Zo'n 10.000 MB bestand dat je hier en daar kan vinden!

Daarnaast zou je eigenlijk ook iets moeten verzinnen dat zowel de Download als de Upload tegelijk kan belasten en dan kijken waarop je uitkomt!

MJV schreef op woensdag 13 april 2022 @ 20:01:
Sinds kort heb ik een nieuwe smartphone, een Samsung A52S, de eerste smartphone hier in huis met wi-fi op de 5Ghz band. De smartphone verliest echter elke keer internverbinding nadat hij tussen twee AP's is geroamd.

MJV schreef op woensdag 13 april 2022 @ 21:04:
Nadat ik ergens een andere 5Ghz telefoon vandaan heb gehaald, die gewoon bleek te werken, en mijn laptop die ook probleemloos roamde; werd de verdenking dat het in de A52S zelf zat. Nadat ik de smartphone opnieuw heb opgestart lijkt het probleem opgelost. Had ik eerder moeten proberen natuurlijk.

In de meest recente updates/upgrades wordt volgens mij ook een Samsung A32 of A52 genoemd die allerlei problemen schijnt op te leveren dus kijk daar eens naar!

xbeam schreef op woensdag 13 april 2022 @ 00:33:
Ubnt nieuws brief ( is de link)
https://mailchi.mp/ubnt/welcome-to-ubiquiti-insider

[Embed: welkominsider]

Nog iets bijzonders dat je opviel of...

[mydogisgone]

Tortelli schreef op donderdag 14 april 2022 @ 14:11:
Al lang?
Toen ik de UDM had begin januari bleef hij echt hangen rond de 500Mbit upload.

Hebben jullie er camera's aan hangen overigens?

Ik heb hier 7 camera's hangen

Ik zie trouwens nu dat je het over de upload hebt. Deze blijft bij mij steken op 730mbps.
Getest met een losse file (8gb) richting azure.

[ Voor 19% gewijzigd door mydogisgone op 14-04-2022 14:52 ]

[EagleTitan]

nero355 schreef op donderdag 14 april 2022 @ 14:12:
[...]

Een 500 MB groot bestand is IMHO te klein om de snelheid echt goed te meten...

Pak eens iets richting de 1000 MB of nog beter : Zo'n 10.000 MB bestand dat je hier en daar kan vinden!

Daarnaast zou je eigenlijk ook iets moeten verzinnen dat zowel de Download als de Upload tegelijk kan belasten en dan kijken waarop je uitkomt!

Heb de eerste link gepakt die ik kon vinden Ok, de tweede, de eerste kakte enorm in qua snelheid , dus als je nog een 1GB of 10GB link hebt, run ik die ook.

Tortelli schreef op donderdag 14 april 2022 @ 14:11:
Hebben jullie er camera's aan hangen overigens?

Yes, twee camera's (en UPS is nog onderweg met twee extra)

[Airw0lf]

nero355 schreef op donderdag 14 april 2022 @ 14:12:
[...]

Een 500 MB groot bestand is IMHO te klein om de snelheid echt goed te meten...

Pak eens iets richting de 1000 MB of nog beter : Zo'n 10.000 MB bestand dat je hier en daar kan vinden!

Daarnaast zou je eigenlijk ook iets moeten verzinnen dat zowel de Download als de Upload tegelijk kan belasten en dan kijken waarop je uitkomt!

[...]

IPerf3 is dan wellicht een handige. Als je twee keer een test start (een keer als client en een keer als server) kun je FDX-stress-testen met variabele payloads.

Zie ook: https://iperf.fr/iperf-servers.php
Hier staan een aantal publieke iperf3 servers.
En de instructies om zelf iets op te zetten (in Ubuntu).

[nero355]

@Airw0lf
Dat kan uiteraard ook nog, maar soms kreeg ik wat rare resultaten als ik bijvoorbeeld via WiFi zowel iPerf3 als SMB transfers deed : De laatste gingen sneller dan iPerf3 had gemeten!

[Airw0lf]

nero355 schreef op donderdag 14 april 2022 @ 14:57:
@Airw0lf
Dat kan uiteraard ook nog, maar soms kreeg ik wat rare resultaten als ik bijvoorbeeld via WiFi zowel iPerf3 als SMB transfers deed : De laatste gingen sneller dan iPerf3 had gemeten!

Mja - maar wifi is een shared media en daardoor eigenlijk geen handige voor dit soort stress testen.

Met de aanname dat je getest hebt met Windows en daarmee naast iperf3-testen seperaat nog eens een SMB-transfer had lopen:
Het OS heeft een stevige vinger in de pap als het gaat om de afhandeling van packets voor (quasi) gelijktijdig draaiende applicaties. De resultaten komen waarschijnlijk doordat SMB deels via de Windows-kernal loopt. En iperf3 alleen in de Windows-user-space draait.

[xbeam]

EagleTitan schreef op donderdag 14 april 2022 @ 13:15:
Vanaf een Synology, via een USW-16 naar de UDM-Pro (KPN met PPPoE), thread management uitgeschakeld, device en traffic identification ingeschakeld.

code:

$ curl http://speedtest.ams01.softlayer.com/downloads/test500.zip -o /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  500M  100  500M    0     0   105M      0  0:00:04  0:00:04 --:--:--  106M

500MB is veel te klein. Bestanden onder een 1GB worden vaak geburst waarna de Traffic shaping in kicked en dan blijkt je werkelijk snelheid in veel minder.

Zie mail conversatie
xbeam in "[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4"

[ Voor 9% gewijzigd door xbeam op 14-04-2022 22:17 ]

[nero355]

Airw0lf schreef op donderdag 14 april 2022 @ 15:37:
Mja - maar wifi is een shared media en daardoor eigenlijk geen handige voor dit soort stress testen.

Zoveel storende netwerken heb ik hier niet dus dat valt wel mee

Met de aanname dat je getest hebt met Windows en daarmee naast iperf3-testen seperaat nog eens een SMB-transfer had lopen:
Het OS heeft een stevige vinger in de pap als het gaat om de afhandeling van packets voor (quasi) gelijktijdig draaiende applicaties. De resultaten komen waarschijnlijk doordat SMB deels via de Windows-kernal loopt. En iperf3 alleen in de Windows-user-space draait.

Eerst iPerf3 en daarna SMB waarbij de Server uiteraard bedraad aangesloten was!

[Airw0lf]

nero355 schreef op donderdag 14 april 2022 @ 15:43:
[...]

Eerst iPerf3 en daarna SMB waarbij de Server uiteraard bedraad aangesloten was!

Ow - ok. Dat maakt het verschil kleiner - maar het blijft bestaan:
Aan twee kanten een Windows systeem met een SMB-test zal altijd sneller zijn dan een iPerf3-test.

Hoe groot was het verschil eigenlijk?

[EagleTitan]

xbeam schreef op donderdag 14 april 2022 @ 15:42:
[...]


500MB is veel te klein. Bestanden onder een 1GB worden vaak geburst waarna de Traffic shaping in kicked en dan blijkt je werkelijk snelheid in veeel minder.

Zie mail conversatie
[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4

code:

$ curl -o /dev/null https://speedtest.novoserve.com/files/1GB.bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100 1024M    0     0   105M      0  0:00:09  0:00:09 --:--:--  106M

$ curl -o /dev/null https://speedtest.novoserve.com/files/10GB.bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10.0G  100 10.0G    0     0   104M      0  0:01:37  0:01:37 --:--:--  102M

Zo goed dan? (was nog best zoeken naar een server die genoeg bandbreedte had)

[xbeam]

EagleTitan schreef op donderdag 14 april 2022 @ 16:15:
[...]

code:

$ curl -o /dev/null https://speedtest.novoserve.com/files/1GB.bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1024M  100 1024M    0     0   105M      0  0:00:09  0:00:09 --:--:--  106M

$ curl -o /dev/null https://speedtest.novoserve.com/files/10GB.bin
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 10.0G  100 10.0G    0     0   104M      0  0:01:37  0:01:37 --:--:--  102M

Zo goed dan? (was nog best zoeken naar een server die genoeg bandbreedte had)

Ik vindt altijd alles goed, het was alleen een tip om altijd grotere bestanden te testen omdat providers nog wel eens willen smokkelen door de bursten

[nero355]

Airw0lf schreef op donderdag 14 april 2022 @ 15:52:
Ow - ok. Dat maakt het verschil kleiner - maar het blijft bestaan:
Aan twee kanten een Windows systeem met een SMB-test zal altijd sneller zijn dan een iPerf3-test.

Hoe groot was het verschil eigenlijk?

Het is alweer een een flink tijdje geleden, maar het waren dus 1x1 Clients verbonden met een In Wall die 2x2 is en ik geloof dat iPerf3 met allerlei custom waardes voor de window size tot iets van 115 a 120 Mbps kwam, terwijl de SMB transfers iets van 150 Mbps deden als ik het me goed kan herinneren...

Dat zijn dan 5 GHz 802.11ac snelheden als het goed is, want er wordt met de accesspoints op 433 a 390 Mbps verbonden!

[JBS]

Miki schreef op donderdag 14 april 2022 @ 07:08:
[...]

Lees je eens in over het opzetten van een macvlan in docker

Dank voor de suggestie, ga ik op een later moment doen. Voor nu heb ik in de Docker container de inform port aangepast, en dat werkt

[xbeam]

nero355 schreef op donderdag 14 april 2022 @ 14:12:

Nog iets bijzonders dat je opviel of...

Ja, dat ik hem niet embedded kan posten de vermelding van de Unifi OS Console Resource Calculator? Waar we het laatst over hadden dat die tussen de UDM P\RO en SE afwijken met de zelfde cpu verschillende cpu performance weergeeft. En dat echt nieuws over over producten en security ontwikkeling ontbreken.

Maar je hebt gelijk Ik was nog bezig met opmaak en toen kwam er wat tussendoor waarna ik de post vergeten ben af te maken.

[ Voor 34% gewijzigd door xbeam op 15-04-2022 17:36 ]

[ewoutw]

Goede morgen,

Ik heb een beetje vreemde issue. Ik van van koper overgegaan op glas (XS4ALL). Sinds dien is mijn cloudkay (gen) onbereikbaar. Ik krijg geen verbinding via de app lokaal als via de cloud remote. Hij blijft offline. Verder werkt internet gewoon prima.

Ik zou graag de glasvezel zonder Fritz!box willen aansluiten. Maar ik heb dan toch echt de controller nodig. Voor nu is dus alleen aangepast dat de Fritz!box geen xDSL meer heeft maar een glas verbinding en dus dat ook ingesteld is.

ik heb de cloudkey al meerde malen herstart. Maar dat lijkt niet te werken.... Iemand nog andere Ideeën of ervaring met dit issue?

[zeroday]

ewoutw schreef op vrijdag 15 april 2022 @ 11:36:
Goede morgen,

Ik heb een beetje vreemde issue. Ik van van koper overgegaan op glas (XS4ALL). Sinds dien is mijn cloudkay (gen) onbereikbaar. Ik krijg geen verbinding via de app lokaal als via de cloud remote. Hij blijft offline. Verder werkt internet gewoon prima.

Ik zou graag de glasvezel zonder Fritz!box willen aansluiten. Maar ik heb dan toch echt de controller nodig. Voor nu is dus alleen aangepast dat de Fritz!box geen xDSL meer heeft maar een glas verbinding en dus dat ook ingesteld is.

ik heb de cloudkey al meerde malen herstart. Maar dat lijkt niet te werken.... Iemand nog andere Ideeën of ervaring met dit issue?

Het meest waarschijnlijke is dat je cloudkey een fixed prive IP adres heeft die niet in dezelfde range zit als waar nu je netwerk op draait. Hierdoor valt ie buiten je netwerk en kan je hem niet benaderen.

Enige manier om dit op te lossen is: wat was het IP adres van je cloudkey?
En indien je dat niet meer weet .. dan wordt het wat lastiger want dan moet je aannames doen of zoeken in welke range de vorige router iets aanbood
bijv. 192.168.0.x of 192.168.1.x of 192.168.100.x of 10.0.0.x of 10.1.1.x etc..

Suc6

[Roy Batty]

ewoutw schreef op vrijdag 15 april 2022 @ 11:36:
Goede morgen,

Ik heb een beetje vreemde issue. Ik van van koper overgegaan op glas (XS4ALL). Sinds dien is mijn cloudkay (gen) onbereikbaar. Ik krijg geen verbinding via de app lokaal als via de cloud remote. Hij blijft offline. Verder werkt internet gewoon prima.

Ik zou graag de glasvezel zonder Fritz!box willen aansluiten. Maar ik heb dan toch echt de controller nodig. Voor nu is dus alleen aangepast dat de Fritz!box geen xDSL meer heeft maar een glas verbinding en dus dat ook ingesteld is.

ik heb de cloudkey al meerde malen herstart. Maar dat lijkt niet te werken.... Iemand nog andere Ideeën of ervaring met dit issue?

lijkt me iets van poortbeveiliging van XS4ALL als je het bij je vorige ISP niet had. Ik zou daar eens op zoeken bij je nieuwe provider.

Dan nog zou het binnen je netwerk wel moeten werken. In de command prompt van windows kun je met commando arp -a alle apparaten binnen dat netwerk opsnorren, daar zou de cloud key met z`n mac-adres tussen moeten staan. Dan de cloud key op IP adres benaderen met je webbrowser; dan ben je zeker lokaal, dus zou het moeten werken.

[nero355]

ewoutw schreef op vrijdag 15 april 2022 @ 11:36:
Sinds dien is mijn cloudkay (gen) onbereikbaar. Ik krijg geen verbinding via de app lokaal als via de cloud remote. Hij blijft offline. Verder werkt internet gewoon prima.

Welk model CloudKey heb je precies

Met een beetje pech heb je een exemplaar met een brakke accu die ervoor zorgt dat het ding bijna zo goed als onbruikbaar is geworden...

Roy Batty schreef op vrijdag 15 april 2022 @ 13:40:
lijkt me iets van poortbeveiliging van XS4ALL als je het bij je vorige ISP niet had. Ik zou daar eens op zoeken bij je nieuwe provider.

IMHO heeft dat er echt 0,0 mee te maken

zeroday schreef op vrijdag 15 april 2022 @ 13:26:
Enige manier om dit op te lossen is: wat was het IP adres van je cloudkey?
En indien je dat niet meer weet .. dan wordt het wat lastiger want dan moet je aannames doen of zoeken in welke range de vorige router iets aanbood
bijv. 192.168.0.x of 192.168.1.x of 192.168.100.x of 10.0.0.x of 10.1.1.x etc..

In de command prompt van windows kun je met commando arp -a alle apparaten binnen dat netwerk opsnorren, daar zou de cloud key met z`n mac-adres tussen moeten staan. Dan de cloud key op IP adres benaderen met je webbrowser; dan ben je zeker lokaal, dus zou het moeten werken.

Vergeet je Broadcast Ping niet!

Iets van :

ping -b 255.255.255.255

Als het goed is...

[ewoutw]

zeroday schreef op vrijdag 15 april 2022 @ 13:26:
[...]
Het meest waarschijnlijke is dat je cloudkey een fixed prive IP adres heeft die niet in dezelfde range zit als waar nu je netwerk op draait. Hierdoor valt ie buiten je netwerk en kan je hem niet benaderen.

Nee, er is aan de lan kant niets veranderd. De fritz!box geeft nog steeds de USG het zelfde adres op de WAN interface. Aan de lan kant van de USG is al helemaal niets veranderd.

Roy Batty schreef op vrijdag 15 april 2022 @ 13:40:
[...]
lijkt me iets van poortbeveiliging van XS4ALL als je het bij je vorige ISP niet had. Ik zou daar eens op zoeken bij je nieuwe provider.

Dan nog zou het binnen je netwerk wel moeten werken. In de command prompt van windows kun je met commando arp -a alle apparaten binnen dat netwerk opsnorren, daar zou de cloud key met z`n mac-adres tussen moeten staan. Dan de cloud key op IP adres benaderen met je webbrowser; dan ben je zeker lokaal, dus zou het moeten werken.

Dan zou KPN porten moeten blokkeren die ze alleen op glas blokkeren. verklaard ook niet waarom het intern niet werkt. Vrees toch wat anders. Maar bedankt voor het mee denken.

nero355 schreef op vrijdag 15 april 2022 @ 14:37:

Welk model CloudKey heb je precies


Met een beetje pech heb je een exemplaar met een brakke accu die ervoor zorgt dat het ding bijna zo goed als onbruikbaar is geworden...

Sorry Gen1, dus zonder batterij. Maar in eerste instantie is die nooit uit geweest doordat de PoE switch gewoon is blijven werken.

nero355 schreef op vrijdag 15 april 2022 @ 14:37:
Vergeet je Broadcast Ping niet!

Iets van :

ping -b 255.255.255.255

Als het goed is...

Ik zal eens gaan kijken. zal mijn laptop maar eens aan de zelfde switch en vlan hangen.

[nero355]

ewoutw schreef op vrijdag 15 april 2022 @ 14:57:
Sorry Gen1, dus zonder batterij. Maar in eerste instantie is die nooit uit geweest doordat de PoE switch gewoon is blijven werken.

Die raakten nog weleens corrupt geloof ik dus dat is ook één groot feest geweest in het verleden...

Er is op een bepaald moment wel het een en ander aan gedaan, maar of dat de problemen permanent heeft verholpen durf ik niet te zeggen!

[ed1703]

ewoutw schreef op vrijdag 15 april 2022 @ 14:57:
[...]

Nee, er is aan de lan kant niets veranderd. De fritz!box geeft nog steeds de USG het zelfde adres op de WAN interface. Aan de lan kant van de USG is al helemaal niets veranderd.

Op een switch doe ik (SSH):

code:

cli
show mac address-table  interfaces  GigabitEthernet 9

 VID  | MAC Address       | Type              | Ports
------+-------------------+-------------------+----------------
   12 | DC:A6:32:F8:7D:91 | Dynamic           | gi9

Dan naar de USG (SSH):

code:

show arp | grep -iF DC:A6:32:F8:7D:91
10.0.112.44                ether   dc:a6:32:f8:7d:91   C                     eth1.12

[zeroday]

ed1703 schreef op vrijdag 15 april 2022 @ 15:13:
[...]

Op een switch doe ik (SSH):

code:

cli
show mac address-table  interfaces  GigabitEthernet 9

 VID  | MAC Address       | Type              | Ports
------+-------------------+-------------------+----------------
   12 | DC:A6:32:F8:7D:91 | Dynamic           | gi9

Dan naar de USG (SSH):

code:

show arp | grep -iF DC:A6:32:F8:7D:91
10.0.112.44                ether   dc:a6:32:f8:7d:91   C                     eth1.12

Dan zou die toch op 10.0.112.44 bereikbaar moeten zijn? als dat MAC adres het adres is van je cloudkey, alleen als de VLAN niet goed staat dan verberg je die ook voor jan en alleman ..

oeps.. niet als tip naar de originele vraagsteller

[ Voor 4% gewijzigd door zeroday op 15-04-2022 15:39 ]

[zeroday]

nero355 schreef op vrijdag 15 april 2022 @ 14:37:
[...]

Welk model CloudKey heb je precies

Met een beetje pech heb je een exemplaar met een brakke accu die ervoor zorgt dat het ding bijna zo goed als onbruikbaar is geworden...

dat heeft op zich niet zoveel met het probleem te maken. Ookal is de batterij kaduuk dan kan je Cloudkey gen2 plus best wel werken. Enige probleem is dat als je de kabel eruit trekt deze direct boem doet en uit is. In plaats van gracefully een shutdown te doen ..
Mijn eerste was al bij de aankoop defect, die is omgewisseld door de perfecte leverancier en doet het nu nog steeds goed.

dus in dit geval niet van toepassing qua probleem.

[ed1703]

zeroday schreef op vrijdag 15 april 2022 @ 15:35:
[...]


Dan zou die toch op 10.0.112.44 bereikbaar moeten zijn? als dat MAC adres het adres is van je cloudkey, alleen als de VLAN niet goed staat dan verberg je die ook voor jan en alleman ..

oeps.. niet als tip naar de originele vraagsteller

Troubleshooten doe je altijd laag voor laag.
Laag1 (zit de stekker er in staat alles aan)
Laag2 (zie je een mac adres? juiste vid?) bij dhcp kan je ook nog de snooping tabel bevragen (als dhcp snooping aan staat), maar dat zal wel vast ip zijn. Dan heb je aan snooping niets.
Dan ga je door naar laag 3 op een router.

Lijkt mij overigens ook niet erg aannemelijk dat er iets op laag3 mis is.
Een controller die niet wil is gewoon kip/ei waardoor de zwakheid van Unifi naar voren komt.

[ Voor 14% gewijzigd door ed1703 op 15-04-2022 16:03 ]

[xbeam]

zeroday schreef op vrijdag 15 april 2022 @ 13:26:
[...]


Het meest waarschijnlijke is dat je cloudkey een fixed prive IP adres heeft die niet in dezelfde range zit als waar nu je netwerk op draait. Hierdoor valt ie buiten je netwerk en kan je hem niet benaderen.

Enige manier om dit op te lossen is: wat was het IP adres van je cloudkey?
En indien je dat niet meer weet .. dan wordt het wat lastiger want dan moet je aannames doen of zoeken in welke range de vorige router iets aanbood
bijv. 192.168.0.x of 192.168.1.x of 192.168.100.x of 10.0.0.x of 10.1.1.x etc..

Suc6

Hij kan ook met een LaN scanner zijn netwerk scannen en kijken of de cloud key binnen ethernet op Mac adres zichtbaar is en welk ip deze dan adverteert naar de ARP tabels van de voor liggende switch.

Update:
Hehehe. Sorry hij wordt daar al door @ed1703 al meegeholpen. (Hoor de leraar van de basisschool alweer roepen “eerst alles en ook de vragen lezen voordat je de vragen gaat beantwoorden”.

[ Voor 11% gewijzigd door xbeam op 15-04-2022 18:28 ]

[nero355]

xbeam schreef op vrijdag 15 april 2022 @ 17:41:
Hij kan ook met een LaN scanner zijn netwerk scannen

Volgens mij werkt de bekendste vooral met IP adressen en doet die niks op basis van het MAC adres

Is alweer een tijdje geleden dat ik ermee bezig was bij iemand...

Wat meuk zelf typen op de CLI/Command Prompt/Terminal werkt gewoon ALTIJD !!!

zeroday schreef op vrijdag 15 april 2022 @ 15:38:
dat heeft op zich niet zoveel met het probleem te maken. Ookal is de batterij kaduuk dan kan je Cloudkey gen2 plus best wel werken. Enige probleem is dat als je de kabel eruit trekt deze direct boem doet en uit is. In plaats van gracefully een shutdown te doen ..
Mijn eerste was al bij de aankoop defect, die is omgewisseld door de perfecte leverancier en doet het nu nog steeds goed.

dus in dit geval niet van toepassing qua probleem.

Hmm...

Zou zweren dat er in een aantal gevallen totaal geen leven meer uit dat ding kwam, maar blijkbaar gaat het niet om een dergelijk model dus dat maakt niks meer uit

[Mr-D.]

Heb nu toch een vage bug gevonden in de UDM pro
Zo nu en dan word het network gedeelte van de applicatie omgeving Unresponsive terwijl ik wel gewoon protect en alle andere dingen kan benaderen.
internet en netwerk opzich blijft gewoon werken, maar als je dan inlogt op het gasten netwerk hoef je geen code in te voeren en zit je direct op internet.

Een reboot op de controller zelf verhelpt het euvel kan dan gewoon weer bij het netwerk gedeelte en je krijg dan ook gewoon weer de inlog pagina te zien op het gasten netwerk.
vind ik toch wel een dingetje.

[xbeam]

Mr-D. schreef op vrijdag 15 april 2022 @ 20:38:
Heb nu toch een vage bug gevonden in de UDM pro
Zo nu en dan word het network gedeelte van de applicatie omgeving Unresponsive terwijl ik wel gewoon protect en alle andere dingen kan benaderen.
internet en netwerk opzich blijft gewoon werken, maar als je dan inlogt op het gasten netwerk hoef je geen code in te voeren en zit je direct op internet.

Een reboot op de controller zelf verhelpt het euvel kan dan gewoon weer bij het netwerk gedeelte en je krijg dan ook gewoon weer de inlog pagina te zien op het gasten netwerk.
vind ik toch wel een dingetje.

Zelf een een Eigen CNA op bijv pi werkt plezieriger dan heb vaak veel meer mogelijkheden en je kan vaak een uitgebreidere walled garden bouwen.

Waneer je gasten/bezoekers kunnen verbinding (autorisatie hebben ) zonder dat ze een portal krijgen kan dat door 2 dingen komen. 1 ze hebben nog een vorige sessie/autorisatie lopen of de controller is down en het accespoint geeft internet access aan iedereen om internet interruptie voor je bezoekers voorkomen.

Dit kan je op config file toegang van/in de controller uit zetten.

[ Voor 42% gewijzigd door xbeam op 17-04-2022 09:59 ]

[Mr-D.]

xbeam schreef op zaterdag 16 april 2022 @ 08:26:
[...]

Zelf een een Eigen CNA op bijv pi werkt dan heb vaak veel meer mogelijkheden of je kan compleet eigen walled garden bouwen.

Waneer je gasten/bezoekers kunnen verbinding (autorisatie hebben ) zonder dat ze een portal krijgen kan dat door 2 dingen komen. 1 ze hebben nog een vorige sessie/autorisatie lopen of de controller is down en het accespoint geeft internet access aan iedereen om internet interruptie voor je bezoekers voorkomen.

Dit kan je op config file toegang van/in de controller uit zetten.

Ja dat bedoelde ik eigenlijk te zeggen alleen de controller was down, rest van de UDM werkte nog wel
Heb nog een eerste generatie pi liggen zal mij daar eens in verdiepen.

[abusimbal]

Introducing: UniFi Connect [Early Access]
YouTube: Introducing: UniFi Connect [Early Access]

Ubiquiti komt met een nieuwe app, UniFi Connect.
Met displays, controlpanels, thermostaat, led panelen, dimmer switches en een auto laadpaal.

[cautje]

Goedemiddag,
Ik kan een beetje hulp gebruiken.
Het doel is om de mogelijkheid te hebben om af en toe YouTube helemaal af te kunnen sluiten.
Het gaat dus niet om de reclame in Youtube.

Ik heb locaal op op rapberry Adguard home draaien met daarin de youtube service uit staan.
Maar YouTube blijft werken op android TV en chromebook.
Ik het adguard forum had men me al de tip gegeven om 8.8.8.8 en 8.8.4.4 te blokkeren.
Dit heb ik gedaan via onderstaande in de Unify pro 4



Maar dit is niet genoeg, youtube blijft werken.
Wie kan we laten zien hoe ik via de nieuwe GUI een firewall rule aanmaak om all het uitgaande verkeer op Vlan1 en Vlan2 naar 8.8.8.8 en 8.8.4.4 te blokkeren.
En eventueel indien nodig te routeren naar 192.168.1.10 de Adguard home.

Bedankt!

[ Voor 27% gewijzigd door cautje op 16-04-2022 14:34 ]

[Polyphemus]

abusimbal schreef op zaterdag 16 april 2022 @ 14:14:
Introducing: UniFi Connect [Early Access]
YouTube: Introducing: UniFi Connect [Early Access]

Ubiquiti komt met een nieuwe app, UniFi Connect.
Met displays, controlpanels, thermostaat, led panelen, dimmer switches en een auto laadpaal.

Dat trekt de UDM-P/SE nooit tegelijk

[xbeam]

Official release Unifi Connect

abusimbal schreef op zaterdag 16 april 2022 @ 14:14:
Introducing: UniFi Connect [Early Access]
YouTube: Introducing: UniFi Connect [Early Access]

Ubiquiti komt met een nieuwe app, UniFi Connect.
Met displays, controlpanels, thermostaat, led panelen, dimmer switches en een auto laadpaal.

Dat denk ik allemaal niet anders zouden ze volgens het filmpje ook met printers en slagbomen komen. Led verlichting daar in tegen hebben ze al jaren. https://unifi-led.ui.com


Het gaat denk om een iot platform om dat allemaal te kunnen aansturen. Waar bij een Connect display het gebruik, de bediening of status van het van het iot devies weer geeft (display aan de waar op staat vergader ruimte bezet door afdeling X )

[ Voor 150% gewijzigd door xbeam op 16-04-2022 14:58 ]

[mrdemc]

cautje schreef op zaterdag 16 april 2022 @ 14:28:
Goedemiddag,
Ik kan een beetje hulp gebruiken.
Het doel is om de mogelijkheid te hebben om af en toe YouTube helemaal af te kunnen sluiten.
Het gaat dus niet om de reclame in Youtube.

Ik heb locaal op op rapberry Adguard home draaien met daarin de youtube service uit staan.
Maar YouTube blijft werken op android TV en chromebook.
Ik het adguard forum had men me al de tip gegeven om 8.8.8.8 en 8.8.4.4 te blokkeren.
Dit heb ik gedaan via onderstaande in de Unify pro 4

[Afbeelding]

Maar dit is niet genoeg, youtube blijft werken.
Wie kan we laten zien hoe ik via de nieuwe GUI een firewall rule aanmaak om all het uitgaande verkeer op Vlan1 en Vlan2 naar 8.8.8.8 en 8.8.4.4 te blokkeren.
En eventueel indien nodig te routeren naar 192.168.1.10 de Adguard home.

Bedankt!

Zelf heb ik een Port group aangemaakt onder "profiles" voor de poorten 853 en 53. Vervolgens heb ik die poorten geblokkeerd voor alle apparaten uitgaand op het internet.
Daarnaast heb ik voor de Raspberry PI op basis van het IP juist wel de DNS toegang op poortbasis toegestaan.
Sommige mensen kiezen ervoor om Port forwarding te gebruiken waarbij alles uitgaand over poort 53 naar de Adblocker wordt doorgestuurd.

Echter; soms wordt er gebruik gemaakt van DNS over HTTPS, in dat geval is dat eigenlijk niet te blokkeren.

Heb je gekeken naar het verkeer dat het apparaat uitgaand verstuurt? En of er überhaupt DNS verzoeken naar buiten gaan of misschien wel op de Rpi binnenkomen maar slechts niet ondervangen worden?

[cautje]

mrdemc schreef op zaterdag 16 april 2022 @ 14:53:
[...]


Zelf heb ik een Port group aangemaakt onder "profiles" voor de poorten 853 en 53. Vervolgens heb ik die poorten geblokkeerd voor alle apparaten uitgaand op het internet.
Daarnaast heb ik voor de Raspberry PI op basis van het IP juist wel de DNS toegang op poortbasis toegestaan.
Sommige mensen kiezen ervoor om Port forwarding te gebruiken waarbij alles uitgaand over poort 53 naar de Adblocker wordt doorgestuurd.

Echter; soms wordt er gebruik gemaakt van DNS over HTTPS, in dat geval is dat eigenlijk niet te blokkeren.

Heb je gekeken naar het verkeer dat het apparaat uitgaand verstuurt? En of er überhaupt DNS verzoeken naar buiten gaan of misschien wel op de Rpi binnenkomen maar slechts niet ondervangen worden?

Bedankt!
dat ga ik ff checkken

[xbeam]

mrdemc schreef op zaterdag 16 april 2022 @ 14:53:
[...]

Echter; soms wordt er gebruik gemaakt van DNS over HTTPS, in dat geval is dat eigenlijk niet te blokkeren.

Edgerouter en USG_OS bevatten een default uitgeschakelde squid
https://wiki.squid-cache....Intercept/SslBumpExplicit

HTTPS interception has ethical and legal issues which you need to be aware of.

some countries do not limit what can be done within the home environment,
some countries permit employment or contract law to overrule privacy,
some countries require government registration for all decryption services,
some countries it is an outright capital offence with severe penalties
DO Seek legal advice before using this configuration, even at home.

Heb je een UDM dan zijn een PI web_gateway en @nero355 je vriend.

[ Voor 53% gewijzigd door xbeam op 17-04-2022 10:18 ]

[boomer21]

Heb twee “gescheiden netwerken” adopten van UniFi apparatuur kan soms moeilijk zijn.

1 netwerk gebruik zo nu en dan dus die staan zonder stroom maar bij testen doe ik die aan.
Maar heb maar 1 controller hoe kan je het beste die dan gebruiken.

Is via multiple sites (menu controller) de beste manier?

Bijvoorbeeld Dus netwerk 1 de eerste site en als je em dan voor netwerk 2 gebruikt 2e site dan plug je de controller in de poe switch van netwerk 2 en als klaar bent weer terug naar site 1 en plug em weer terug in de poe switch van netwerk 1