[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3

[nero355]

ed1703 schreef op zaterdag 28 september 2019 @ 11:37:
Die speedtest doet unifi vanaf de USG voor zover ik weet. Dit doet de USG via het proces linkcheck, wat dus in de software afgehandeld moet worden en totaal niet geschikt is om vanaf router-hardware te testen.

Wat je eigenlijk wil zeggen : De CPU van de USG kan het niet aan!

Daarom gebruikt men liever ook geen functies waarbij de hardware offload voor NAT en andere dingen wordt uitgeschakeld

Doe je zelf een plezier en test het gewoon vanaf een pc/laptop/tablet/smartphone. De waardes die je vanaf de controller krijgt zijn eigenlijk niet relevant en zeggen niet zoveel.

Helemaal waar!

[geenwindows]

RobertMe schreef op vrijdag 27 september 2019 @ 19:43:
Heren (@ed1703, @Oesie, @geenwindows, @nero355),
Ik heb nu even de tijd genomen om het zelf in te regelen, en deze werkt, voor mij:

JSON:

{
  "service": {
    "nat": {
      "rule": {
        "1": {
          "description": "Redirect all DNS trafic",
          "destination": {
            "port": "53",
            "address": "!192.168.1.3"
          },
          "inbound-interface": "eth1.10",
          "inside-address": {
            "address": "192.168.1.3",
            "port": "53"
          },
          "source": {
            "address": "!192.168.1.3"
          },
          "log": "disable",
          "protocol": "tcp_udp",
          "type": "destination"
        }
      }
    }
  }
}

Ik heb dus een extra source blok met daarop weer een uitzondering van het IP van Pi-Hole.

Overigenss moet ik wel nog kijken of ik dit blok nu moet herhalen voor elke interface, want naast deze .10 voor "prive" apparaten heb ik ook nog 20 voor IoT en .50 voor gasten.


Edit:
Proberen zonder inbound-interface was niet het slimste idee. Bleef provisionen, commit error, en had SSH sessie open en die kwam op gegeven moment met "going down for reboot" en duurde voor mijn gevoel erg lang voordat die weer up was. Vermoed dus dat het een kwestie van continu die blok vervangen met aangepaste interface wordt
Edit2: Zie dus hieronder. "inbound-interface": "eth1+" werkt ook en matcht alle interfaces waarbij de naam begint met "eth1".

thnx, dit werkt. enkel heb ik eth0+ ingevoerd want USG pro4.
nu zie ik ook in pi-hole dat de verzoeken rechtstreeks van de devices komen en niet de usg, gisteren werd pi-hole volledig belast met 15k verzoeken van de usg, binnen 3 minuten. (daarna klapte internet eruit.)
Wat mij wel opvalt: 1, de USG heeft nu aan de WAN zijde dns ingestelt op localhost (127.0.0.1) pi-hole gebruikt af en toe de usg voor verzoeken, hier stonden de dns van Ziggo...
2, Nextcloud client hier is "kapot" deze is ingesteld met DDNS en dat werkt nu niet meer... pi-hole loopt vol met verzoeken van m'n desktop. (nextcloud is inmiddels dood)
3, waarom maakt Youless (LS120) elke minuut verbinding??? (deze gaan we verplaatsen naar een IoT vlan en verbindingen naar buiten blokkeren.)

overigens gebruik ik Pi-hole in HA (2 piholes, 1 ipadress) en heb ik Unbound draaien.

Edit; Nee, dit werkt toch niet echt helemaal, Tweakers werkt, maar de rest van internet is kapot.. verzoeken komen binnen bij pi-hole maar ik zie bij 'replay' telkens N/A, terwijl bij de adressen die wel werken NODATA x.x ms, of IP 0.x ms staan... iets gaat hier fout...

edit2: Nexctloud en andere zaken welke vanaf buiten beschikbaar zijn, zijn nog steeds beschikbaar.
ik heb voor nu geprobeerd de wan dns van de usg erin te zetten, maar dat werkt ook niet, zag wel een melding voorbij komen met NAT en DESTINATION, melding verdween tijdens lezen en blijkbaar heeft unifi daar geen logboek van...

edit3: ik zie nu pas dat achter elk domain welke niet werkt .LOCALDOMAIN erachter staan, ja dat werkt inderdaad niet... enkel ben ik geen netwerk persoon, enkel een hobbyist...

[ Voor 13% gewijzigd door geenwindows op 28-09-2019 14:17 ]

[ed1703]

Deze combi..

geenwindows schreef op zaterdag 28 september 2019 @ 13:57:
[...]
overigens gebruik ik Pi-hole in HA (2 piholes, 1 ipadress) en heb ik Unbound draaien.

{
"service": {
"nat": {
"rule": {
"1": {
"description": "Redirect all DNS trafic",
"destination": {
"port": "53",
"address": "!192.168.1.3"
},
"inbound-interface": "eth1.10",
"inside-address": {
"address": "192.168.1.3",
"port": "53"
},
"source": {
"address": "!192.168.1.3"
},
"log": "disable",
"protocol": "tcp_udp",
"type": "destination"
}
}
}
}
}

Heb je gekeken met tcpdump hoe deze verzoeken door je Pi-Hole uitgestuurd worden?
Ik vraag mij met een HA af of je dan niet beide fysieke interfaces in je json moet opnemen en niet het HA-adres.

[geenwindows]

ed1703 schreef op zaterdag 28 september 2019 @ 16:07:
Deze combi..


[...]


[...]

Heb je gekeken met tcpdump hoe deze verzoeken door je Pi-Hole uitgestuurd worden?
Ik vraag mij met een HA af of je dan niet beide fysieke interfaces in je json moet opnemen en niet het HA-adres.

geen tcpdump gebruikt, puur gekeken wat pi-hole aangaf. tevens stopte ook tweakers er na een klein kwartiertje mee... config verwijderd en usg gereboot (WAN dns bleef hangen op localhost) nu geeft pi-hole als reply; NODATA, IP, CNAME. NXDOMAIN (behalve de geblokkeerde adressen) pi-hole gebruikt naast unbound en blocklist ook de dns van de usg, (ookal staat enkel unbound in de settings van pi-hole)
Vind het ook raar dan de WAN dns settings in de usg veranderen terwijl ik de LAN zijde aanpas.. maar dat zal ook wel komen omdat ik de script niet helemaal snap... (geef mij maar de GUI)

[RobbieB]

nero355 schreef op vrijdag 27 september 2019 @ 00:33:
[...]

Zet die Raspberry Pi gewoon achter de USG direkt op de UniFi Switch en verbind bekabeld met het netwerk = Done!

Zoals je het nu omschrijft probeer je alles vanaf de WAN kant van de USG te doen en dat is niet de bedoeling!

Toen ik alle UniFi spullen binnen had heb ik het ook zo gedaan :
Oude xDSL modem/router -> Switchje -> USG WAN 1 kant - USG LAN 1 kant <- UniFi Switch <- UniFi Accesspoints + Raspberry Pi als Controller + PC NIC #2 op het nieuwe netwerk aangesloten.

En dan gewoon alles stap voor stap opbouwen

Check, heb alles nu werkend .

De Ziggo modem staat nog niet in bridge mode, maar is dat persé nodig? ISG zit nu in een andere range (192.168.1.x/24) dus werkt naar behoren. Voegt het dan nog iets toe om dat aan te laten passen in de connectbox?

[nero355]

RobbieB schreef op zaterdag 28 september 2019 @ 17:45:
Check, heb alles nu werkend .

De Ziggo modem staat nog niet in bridge mode, maar is dat persé nodig? ISG zit nu in een andere range (192.168.1.x/24) dus werkt naar behoren. Voegt het dan nog iets toe om dat aan te laten passen in de connectbox?

NAT achter NAT is in principe onwenselijk, maar zolang je er geen last van ondervindt kan je het zo laten

Heb je de standaard range van de USG gebruikt voor je eigen netwerk ?!
Eigenlijk kan je die beter als Management VLAN overlaten en in een nieuw VLAN je eigen netwerk opzetten

[RobbieB]

nero355 schreef op zaterdag 28 september 2019 @ 23:55:
[...]

NAT achter NAT is in principe onwenselijk, maar zolang je er geen last van ondervindt kan je het zo laten

Heb je de standaard range van de USG gebruikt voor je eigen netwerk ?!
Eigenlijk kan je die beter als Management VLAN overlaten en in een nieuw VLAN je eigen netwerk opzetten

Ja nu wel. Maar wat je voorstelt is dus eigenlijk om:

- mgt. VLAN 192.168.1.x/24 te maken met daarin alleen mijn rPi met controller en de USG op 1.1
- VLAN 192.168.2.x/24 voor de rest van mijn netwerk

Correct?

[nero355]

RobbieB schreef op zondag 29 september 2019 @ 00:00:
Ja nu wel. Maar wat je voorstelt is dus eigenlijk om:

- mgt. VLAN 192.168.1.x/24 te maken met daarin alleen mijn rPi met controller en de USG op 1.1
- VLAN 192.168.2.x/24 voor de rest van mijn netwerk

Correct?

Yup!

En of je er een Guest of een normale VLAN van maakt moet je zelf maar effe kijken!

[RobbieB]

nero355 schreef op zondag 29 september 2019 @ 00:01:
[...]

Yup!

En of je er een Guest of een normale VLAN van maakt moet je zelf maar effe kijken!

Ja, wil hier sowieso nog wat verder induiken. Zou ook graag een apart VLAN aan maken voor mijn IoT-apparaten (Nest, Hue), maar weet nog niet of dat voor problemen gaat zorgen met bediening...

Edit: nog een vraag..
Sluit ik de rPi dan direct op de lan2 poort van de USG aan of gewoon via de switch met een static ip? In principe zou het natuurlijk niet uit moeten maken (want VLAN), maar als ik daar een extra poort op mijn switch mee vrij maak is dat wel relaxt.

[ Voor 24% gewijzigd door RobbieB op 29-09-2019 00:18 ]

[rinkel]

RobbieB schreef op zaterdag 28 september 2019 @ 17:45:
[...]

Check, heb alles nu werkend .

De Ziggo modem staat nog niet in bridge mode, maar is dat persé nodig? ISG zit nu in een andere range (192.168.1.x/24) dus werkt naar behoren. Voegt het dan nog iets toe om dat aan te laten passen in de connectbox?

Heb je de usg in de dmz staan van de ziggo router?
Dan hoef je portforwarding niet dubbel te doen.

RobbieB schreef op zondag 29 september 2019 @ 00:04:
[...]

Edit: nog een vraag..
Sluit ik de rPi dan direct op de lan2 poort van de USG aan of gewoon via de switch met een static ip? In principe zou het natuurlijk niet uit moeten maken (want VLAN), maar als ik daar een extra poort op mijn switch mee vrij maak is dat wel relaxt.

Ik heb de rpi gewoon op de switch staan, net als alle andere apparaten. Static ip is wel zo handig. Uiteindelijk wordt verbinding op ip gemaakt, maakt niet zo heel veel uit waar die staat. Tenzij met vlans gewerkt wordt, maar dat is niet echt nodig bij ziggo.

[ Voor 40% gewijzigd door rinkel op 29-09-2019 10:20 ]

[The Eagle]

RobbieB schreef op zondag 29 september 2019 @ 00:04:
[...]

Ja, wil hier sowieso nog wat verder induiken. Zou ook graag een apart VLAN aan maken voor mijn IoT-apparaten (Nest, Hue), maar weet nog niet of dat voor problemen gaat zorgen met bediening...

Edit: nog een vraag..
Sluit ik de rPi dan direct op de lan2 poort van de USG aan of gewoon via de switch met een static ip? In principe zou het natuurlijk niet uit moeten maken (want VLAN), maar als ik daar een extra poort op mijn switch mee vrij maak is dat wel relaxt.

Rpi met je controller rechtstreeks op de USG kan, maar is niet zo handig. Als je je USG gaat upgraden kun je namelijk niet meer bij je controller. Hang je de controller op een switch is er geen issue.

[geenwindows]

nieuwe dag, nieuwe poging. nu wel compleet werkend.

code:

{
"service": {
"nat": {
"rule": {
"1": {
"description": "Redirect all DNS trafic",
"destination": {
"port": "53",
"address": "!192.168.1.9-192.168.1.10"
},
"inbound-interface": "eth0+",
"inside-address": {
"address": "192.168.1.9-192.168.1.10",
"port": "53"
},
"source": {
"address": "!192.168.1.9-192.168.1.10"
},
"log": "disable",
"protocol": "tcp_udp",
"type": "destination"
}
}
}
}
}

.9 en .10 zijn de 2 pi-hole adressen. .11 is de HA adress
nu worden verzoeken ook naar de 2e pi-hole gestuurd. het is dus nu geen backup-only dns server meer.
enkel staat in de WAN setting van de usg nu als dns server 127.0.0.1 (localhost) als ik dit aanpas klapt het draadloze gedeelte eruit (dhcp timeout, AP veranderd op beide frequenties continue van kanalen), de enige oplossing die helpt is ALLES herstarten, waardoor de WAN dns settings weer op localhost staan. dit lijkt me raar want ik zie in pi-hole dat dns verzoeken af en toe door de usg worden beantwoord...
tevens worden DNS verzoeken op het gasten netwerk nu ook door de pi-holes afgehandeld..

puntje voor ubnt, zorg voor betere logboek registratie, diagnose stellen is zo rete onduidelijk!

edit:
toch werkte het niet helemaal ok, na wat zoek werk kwam ik deze script tegen:

code:

{
    "service": {
        "nat": {
            "rule": {
                "1": {
                    "description": "Redirect DNS requests",
                    "destination": {
                        "port": "53"
                    },
                    "inbound-interface": "eth0+",
                    "inside-address": {
                        "address": "192.168.1.9-192.168.1.10",
                        "port": "53"
                    },
                    "source": {
                        "address": "!192.168.1.9-192.168.1.10"
                    },
                    "log": "disable",
                    "protocol": "tcp_udp",
                    "type": "destination"
                },
                "6000": {
                    "description": "MASQ DNS requests to LAN",
                    "destination": {
                        "address": "192.168.1.9-192.168.1.10",
                        "port": "53"
                    },
                    "log": "disable",
                    "outbound-interface": "eth0+",
                    "protocol": "tcp_udp",
                    "type": "masquerade"
                }
            }
        }
    }
}

ik ontdekte dat wanneer ik een dig command stuurde met @9.9.9.9 er achter stuurde ik een timeout error kreeg, alles wat dus een hardcode dns had kreeg dus nooit een reactie. heb als test de dns server op m'n dekstop geforceerd naar 9.9.9.9 gezet en zie nu de dns verzoeken in Pi-hole verschijnen alsof het afkomstig is van de USG. nu wordt dus all het dns verzoeken dus wel goed afgehandeld. ik zie als reactie van de dig command ook dat het denkt dat het vanaf de gevraagde dns server komt

code:

dig google.nl @9.9.9.9

; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> google.nl @9.9.9.9
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24381
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.nl.         IN  A

;; ANSWER SECTION:
google.nl.      3001    IN  A   172.217.17.67

;; Query time: 2 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sun Sep 29 12:58:04 CEST 2019
;; MSG SIZE  rcvd: 54

de script heb ik gevonden op deze githubpagina
eth0+ is voor de USG Pro4 (anders inderdaad eth1+)

[ Voor 45% gewijzigd door geenwindows op 29-09-2019 13:10 . Reden: meer ondekt ]

[KeRsTmAnNeKe]

Afgelopen week 2 Unifi lite AP's gekocht, vriendin en ik vonden de kwaliteit van het wifi signaal in huis tegen vallen, komende van een Airport extreme (woonkamer) en Airport express (bovenverdieping), spullen uit 2011 en 2008 .

Na wat gerommel om die controller software werkend te krijgen op mijn pc (verouderde java versie) wat gaan rommelen... en behalve dat ze gewoon erg goed werken is die software ook leuk om mee te rommelen :-) (en grafiekjes ) ik had een Rpi zero met Pi-Hole draaien, die is sinds gisteren vervangen door een 3B, zodat daar ook die controller 24/7 op kan draaien.

Alles werkt nu gewoon goed, maar zit er toch aan te denken een USG te kopen, gewoon om het 'compleet' te maken (al moet ik dan eigenlijk ook de switches nog vervangen, maar dat is iets té nu)

[Cartman!]

Vanmorgen beneden de nanoHD opgehangen, op de verdiepingen hangen LR's. Had door de aannemer in de plafonds loze leidingen laten aanleggen, ging perfect Verbaast me wel hoe erg glas het signaal blokkeert; in de tuin met de vouwdeuren dicht heb ik bijna geen bereik meer. Wordt toch in de schuur nog een extra access point ophangen dus.

[ed1703]

geenwindows schreef op zondag 29 september 2019 @ 12:48:

code:

{
"log": "disable",

puntje voor ubnt, zorg voor betere logboek registratie, diagnose stellen is zo rete onduidelijk!

Als je om te beginnen in de json-file de logging uit zet/laat, dan is diagnose stellen inderdaad erg onduidelijk..
Niet om je aan te vallen, maar zeuren op ubnt is in deze onterecht.

Maar mooi dat het nu werkt!

[ Voor 3% gewijzigd door ed1703 op 29-09-2019 14:04 ]

[geenwindows]

ed1703 schreef op zondag 29 september 2019 @ 14:04:
[...]

Als je om te beginnen in de json-file de logging uit zet/laat, dan is diagnose stellen inderdaad erg onduidelijk..
Niet om je aan te vallen, maar zeuren op ubnt is in deze onterecht.

Maar mooi dat het nu werkt!

ik bedoel eigenlijk niet enkel logging betreft de sjon, logging over het algemeen. zie niks wat de firewall doet, ips is ook redelijk 'kaal'. logs in de gui en logs op de controller zijn ook niet echt fijn uit te lezen
hebben ze zo'n redelijke oké gui met alles er zowat in, is het logboek registratie nog zo incompleet. dat is meer mijn zeur puntje

[RobertMe]

Cartman! schreef op zondag 29 september 2019 @ 13:50:
Vanmorgen beneden de nanoHD opgehangen, op de verdiepingen hangen LR's. Had door de aannemer in de plafonds loze leidingen laten aanleggen, ging perfect Verbaast me wel hoe erg glas het signaal blokkeert; in de tuin met de vouwdeuren dicht heb ik bijna geen bereik meer. Wordt toch in de schuur nog een extra access point ophangen dus.

HR+(+?) glas zit een folie in voor isolatie. Maar naast dat het isoleert tegen warmte / koude houd het ook radiosignalen flink tegen, helaas.

[alexwel]

tcviper schreef op dinsdag 27 augustus 2019 @ 10:20:
Voor degene die het interessant vinden, ben wat aant testen met NextDNS. Das een beetje Cloudflare+Pi Hole in elkaar en qua lookup snelheden zit ie gelijk aan Google en Cloudflare voor mij. Check it out: https://www.nextdns.io/ werkt prima samen met UniFi hardware (DNS).

Inmiddels werkt mijn USG via NextDNS een aantal dagen en so far so good. Fijn om geen Pi Hole meer zelf te hoeven draaien en dat het super snel werkt.

Ik heb het nu een tijdje gebruikt, maar ik kom een aantal problemen tegen:
- Met regelmaat lange response tijden
- Soms voor 1 seconden een fout bij laden van pagina's, welke neerkomen op dns fout. Op desktop laadt hij vaak wel weer opnieuw en dan wel goed, op mobile devices moet ik vaak zelf verversen
- Sommige websites, die wel te vertrouwen zijn, worden volledig geblokkeerd

Deze problemen heb ik niet met andere DNS providers, zoals OpenDNS

[tcviper]

alexwel schreef op zondag 29 september 2019 @ 14:54:
[...]


Ik heb het nu een tijdje gebruikt, maar ik kom een aantal problemen tegen:
- Met regelmaat lange response tijden
- Soms voor 1 seconden een fout bij laden van pagina's, welke neerkomen op dns fout. Op desktop laadt hij vaak wel weer opnieuw en dan wel goed, op mobile devices moet ik vaak zelf verversen
- Sommige websites, die wel te vertrouwen zijn, worden volledig geblokkeerd

Deze problemen heb ik niet met andere DNS providers, zoals OpenDNS

Dan kun je sowieso beste een aantal blacklists uitzetten, er staan er standaard veel aan. Hopelijk komt Ubnt snel met DNS Filter ingebouwd in de UniFi controller, dan hebben we al die dingen niet meer nodig 😀

[rally]

alexwel schreef op zondag 29 september 2019 @ 14:54:
[...]


Ik heb het nu een tijdje gebruikt, maar ik kom een aantal problemen tegen:
- Met regelmaat lange response tijden
- Soms voor 1 seconden een fout bij laden van pagina's, welke neerkomen op dns fout. Op desktop laadt hij vaak wel weer opnieuw en dan wel goed, op mobile devices moet ik vaak zelf verversen
- Sommige websites, die wel te vertrouwen zijn, worden volledig geblokkeerd

Deze problemen heb ik niet met andere DNS providers, zoals OpenDNS

Same here. Ik ga weer terug naar mijn originele setup (combi van Cloudflare, OpenDNS en Google). Het is nl. wel storend.

Het is een leuke oplossing en de Content Filtering werkt *aardig*, maar ik vind betrouwbaarheid toch belangrijker.

[sdk1985]

Ik heb net voor het eerst een Ubiquiti NanoHD aangesloten. Op mijn laptop even de benodigde controller software gezet. De setup was vrij duidelijk en eigenlijk werkte het ding meteen. Echter nu heb ik een RFscan laten doen en na een minuut of 5 ging hij naar heartbeat missed en nu staat er disconnected last seen 11 minutes ago. Is dit normaal? Zo ver ik mij herriner had de popup het over 5 minuten.

[ Voor 7% gewijzigd door sdk1985 op 29-09-2019 16:16 ]

[Cartman!]

RobertMe schreef op zondag 29 september 2019 @ 14:27:
[...]

HR+(+?) glas zit een folie in voor isolatie. Maar naast dat het isoleert tegen warmte / koude houd het ook radiosignalen flink tegen, helaas.

Laten we zeggen dat dit folie goed z'n werk doet

[sdk1985]

Cartman! schreef op zondag 29 september 2019 @ 13:50:
Vanmorgen beneden de nanoHD opgehangen, op de verdiepingen hangen LR's. Had door de aannemer in de plafonds loze leidingen laten aanleggen, ging perfect Verbaast me wel hoe erg glas het signaal blokkeert; in de tuin met de vouwdeuren dicht heb ik bijna geen bereik meer. Wordt toch in de schuur nog een extra access point ophangen dus.

Heb even snel de NanoHD vergeleken met mijn R7000 en die laatste is toch een stuk sterker. Op 2.4 Ghz moet je denken aan 15 mbps tegen 10 mbps op een verre locatie (slaapkamer). Op 5 Ghz was het 12 Mbps vs 130 Mbps. Natuurlijk is dat niet 100% eerlijk maar het is in mijn ervaring niet zo dat een enkele NanoHD een magische oplossing is voor goed bereik. Niet dat ik dat had verwacht, zitten niet eens antennes op .

Zo ver ik nu kan concluderen zit de kracht van dit systeem vooral in de mesh functionaliteit waarbij clients in theorie actief van een foute AP worden 'afgetrapt'. Vooral handig dus wanneer je de zolder oid niet haalt en geen zin hebt in dubbele netwerk ID's. Maar voor dingen als een tuin vrees ik dat je dan toch een extra AP buiten moet hangen (de pro zijn waterdicht staat erbij). Of mazzel hebben dat een R7000+ of beter gewoon overal net genoeg is als je die op de midden verdieping plaatst.

Even een vraag; Als ik zo'n guest control ding wil activeren dan staat er dat er een controller online required is. Zo ver ik kan vinden volstaat de software, maar 24/7 een pc draaien op locatie heb ik niet zo'n trek in. Welke apparatuur kan ook als controller dienen? Zijn dat die cloudkeys? Of zit ik nu helemaal fout (ben echt een leek).

[ Voor 14% gewijzigd door sdk1985 op 29-09-2019 16:49 ]

[996]

sdk1985 schreef op zondag 29 september 2019 @ 16:47:
[...]

Heb even snel de NanoHD vergeleken met mijn R7000 en die laatste is toch een stuk sterker. Op 2.4 Ghz moet je denken aan 15 mbps tegen 10 mbps op een verre locatie (slaapkamer). Op 5 Ghz was het 12 Mbps vs 130 Mbps. Natuurlijk is dat niet 100% eerlijk maar het is in mijn ervaring niet zo dat een enkele NanoHD een magische oplossing is voor goed bereik. Niet dat ik dat had verwacht, zitten niet eens antennes op .

Zo ver ik nu kan concluderen zit de kracht van dit systeem vooral in de mesh functionaliteit waarbij clients in theorie actief van een foute AP worden 'afgetrapt'. Vooral handig dus wanneer je de zolder oid niet haalt en geen zin hebt in dubbele netwerk ID's. Maar voor dingen als een tuin vrees ik dat je dan toch een extra AP buiten moet hangen (de pro zijn waterdicht staat erbij). Of mazzel hebben dat een R7000+ of beter gewoon overal net genoeg is als je die op de midden verdieping plaatst.

Even een vraag; Als ik zo'n guest control ding wil activeren dan staat er dat er een controller online required is. Zo ver ik kan vinden volstaat de software, maar 24/7 een pc draaien op locatie heb ik niet zo'n trek in. Welke apparatuur kan ook als controller dienen? Zijn dat die cloudkeys? Of zit ik nu helemaal fout (ben echt een leek).

Inderdaad een cloiudkey (of op sommige Synology NAS apparaten, of op een RaspberryPI of hoe heet zoiets?)

[Cartman!]

sdk1985 schreef op zondag 29 september 2019 @ 16:47:
[...]

Heb even snel de NanoHD vergeleken met mijn R7000 en die laatste is toch een stuk sterker. Op 2.4 Ghz moet je denken aan 15 mbps tegen 10 mbps op een verre locatie (slaapkamer). Op 5 Ghz was het 12 Mbps vs 130 Mbps. Natuurlijk is dat niet 100% eerlijk maar het is in mijn ervaring niet zo dat een enkele NanoHD een magische oplossing is voor goed bereik. Niet dat ik dat had verwacht, zitten niet eens antennes op .

Ik zeg nergens dat t n magische oplossing is. Al m'n telefoons halen nu 300mbit op 5GHz door t hele huis en daar ben ik tevreden mee. Theoretisch zou t veel hoger kunnen waarschijnlijk maar daar is t ook wel mee gezegd denk ik.

Even speedtest gedaan met Samsung A50: 6ms ping, 311mbps down/348mbps up, netjes denk ik?

Zo ver ik nu kan concluderen zit de kracht van dit systeem vooral in de mesh functionaliteit waarbij clients in theorie actief van een foute AP worden 'afgetrapt'. Vooral handig dus wanneer je de zolder oid niet haalt en geen zin hebt in dubbele netwerk ID's. Maar voor dingen als een tuin vrees ik dat je dan toch een extra AP buiten moet hangen (de pro zijn waterdicht staat erbij). Of mazzel hebben dat een R7000+ of beter gewoon overal net genoeg is als je die op de midden verdieping plaatst.

Dat is zeker een van de krachten van Ubiquiti, daarnaast de controller waar je alles makkelijk kunt instellen mbt vlans, firewall, guest access etc.

Even een vraag; Als ik zo'n guest control ding wil activeren dan staat er dat er een controller online required is. Zo ver ik kan vinden volstaat de software, maar 24/7 een pc draaien op locatie heb ik niet zo'n trek in. Welke apparatuur kan ook als controller dienen? Zijn dat die cloudkeys? Of zit ik nu helemaal fout (ben echt een leek).

Cloudkey kun je ervoor gebruiken ja maar je kunt t ook in de (public) cloud draaien.

[sdk1985]

Cartman! schreef op zondag 29 september 2019 @ 18:17:
[...]

Ik zeg nergens dat t n magische oplossing is. Al m'n telefoons halen nu 300mbit op 5GHz door t hele huis en daar ben ik tevreden mee. Theoretisch zou t veel hoger kunnen waarschijnlijk maar daar is t ook wel mee gezegd denk ik.

Even speedtest gedaan met Samsung A50: 6ms ping, 311mbps down/348mbps up, netjes denk ik?

Haha, ja sorry dat heb jij zeker niet beweert. Maar dat waren een beetje mijn verwachtingen op basis van de lovende woorden die ik over deze producten heb gehoord .

Mooie snelheden. Is een ceiling mount nog het overwegen waard overigens? (Niet zo netjes zo lang je geen systeemplafond hebt, maar goed).

Cloudkey kun je ervoor gebruiken ja maar je kunt t ook in de (public) cloud draaien.

Ah kijk dat wist ik niet. Na wat googlen kwam ik op https://help.ubnt.com/hc/...er-on-Amazon-Web-Services zo te zien kun je de software op afstand vanaf een VPS draaien. Neem aan dat het gewoon op CentOS draait zolang je maar java hebt?

[ Voor 5% gewijzigd door sdk1985 op 29-09-2019 18:52 ]

[Cartman!]

sdk1985 schreef op zondag 29 september 2019 @ 18:51:
[...]

Haha, ja sorry dat heb jij zeker niet beweert. Maar dat waren een beetje mijn verwachtingen op basis van de lovende woorden die ik over deze producten heb gehoord .

Mooie snelheden. Is een ceiling mount nog het overwegen waard overigens? (Niet zo netjes zo lang je geen systeemplafond hebt, maar goed).

Ik heb t gewoon bevestigd aan een betonnen plafond iig, op de verdiepingen met schroeven en begane grond met power tape (was niet helemaal goed uitgevuld dus om t plafond niet verder te beschadigen ff kijken hoe t met tape houdt).

Ah kijk dat wist ik niet. Na wat googlen kwam ik op https://help.ubnt.com/hc/...er-on-Amazon-Web-Services zo te zien kun je de software op afstand vanaf een VPS draaien. Neem aan dat het gewoon op CentOS draait zolang je maar java hebt?

Denk het wel maar geen ervaring mee. Draai de controller zelf op een Synology NAS in Docker.

[nero355]

sdk1985 schreef op zondag 29 september 2019 @ 16:47:
Heb even snel de NanoHD vergeleken met mijn R7000 en die laatste is toch een stuk sterker. Op 2.4 Ghz moet je denken aan 15 mbps tegen 10 mbps op een verre locatie (slaapkamer). Op 5 Ghz was het 12 Mbps vs 130 Mbps. Natuurlijk is dat niet 100% eerlijk maar het is in mijn ervaring niet zo dat een enkele NanoHD een magische oplossing is voor goed bereik. Niet dat ik dat had verwacht, zitten niet eens antennes op

Je bedoelt antennes die je kan richten, want anders had je helemaal geen WiFi signaal!

En doet die R7000 het dan nog steeds goed bij jou ?!
Netgear heeft het arme ding op een gegeven moment helemaal verpest met de laatste paar firmware updates!

Zo ver ik nu kan concluderen zit de kracht van dit systeem vooral in de mesh functionaliteit waarbij clients in theorie actief van een foute AP worden 'afgetrapt'. Vooral handig dus wanneer je de zolder oid niet haalt en geen zin hebt in dubbele netwerk ID's.

Nee, Nee en nog eens Nee : Dat is allemaal dikke onzin!

- Mesh is niet van toepassing, tenzij je met Multi-Hop Mesh units aan de slag gaat.
- Al je Clients zullen nog steeds zelf bepalen wanneer ze roamen van accesspoint naar accesspoint, tenzij je met minRSSI hebt zitten rommelen!
- Welke dubbele netwerk ID's

Maar voor dingen als een tuin vrees ik dat je dan toch een extra AP buiten moet hangen (de pro zijn waterdicht staat erbij). Of mazzel hebben dat een R7000+ of beter gewoon overal net genoeg is als je die op de midden verdieping plaatst.

De UniFi Mesh AC is een prachtige cheapo outdoor accesspoint!

En op elke verdieping een accesspoint plaatsen blijft gewoon het beste!

Even een vraag; Als ik zo'n guest control ding wil activeren dan staat er dat er een controller online required is. Zo ver ik kan vinden volstaat de software, maar 24/7 een pc draaien op locatie heb ik niet zo'n trek in. Welke apparatuur kan ook als controller dienen? Zijn dat die cloudkeys? Of zit ik nu helemaal fout (ben echt een leek).

Lees of Search het Topic en de voorgaande delen!
Zou je toch ondertussen moeten weten als oudere GoT member

HINT : Raspberry Pi 3B FTW!!!
_{Dus niet de 2 of de 3B+ of de 4, want onzuiniger en langzamer en zo...}

[JoeZuCK]

@nero355 klein beetje offtopic, maar ik zit te denken om een Raspberry te halen. Zie dat jij de 3 boven zijn opvolgers prefereert. Waarom is dat precies?

[tcviper]

rally schreef op zondag 29 september 2019 @ 14:57:
[...]


Same here. Ik ga weer terug naar mijn originele setup (combi van Cloudflare, OpenDNS en Google). Het is nl. wel storend.

Het is een leuke oplossing en de Content Filtering werkt *aardig*, maar ik vind betrouwbaarheid toch belangrijker.

Yeps, ben zelf ook weer tijdje terug op Cloudflare, werkt prima.

[pica]

Ik heb vandaag getracht de firmware van mijn Edgerouter lite te upgraden van 1.10.10 naar 2.0.6.
Dit lijkt gewoon goed te gaan, echter blijft de versie in de webinterface aangeven dat het 1.10.10 draait.

Ik heb het eerst via de GUI geprobeerd en daarna via CLI
Is dit puur iets grafisch of doe ik wat fout?

[eymey]

@pica Even cache van je browser leeggooien / control+f5 doen?

[pica]

eymey schreef op maandag 30 september 2019 @ 10:39:
@pica Even cache van je browser leeggooien / control+f5 doen?

Mijn hemel. Ok, ik had wel ctrl+f5 gedaan zonder effect, echter nu ik het in InPrivate navigatie doe krijg ik wel het juiste versienummer in beeld. Bedankt .

[sdk1985]

nero355 schreef op maandag 30 september 2019 @ 00:26:
[...]

Je bedoelt antennes die je kan richten, want anders had je helemaal geen WiFi signaal!

En doet die R7000 het dan nog steeds goed bij jou ?!
Netgear heeft het arme ding op een gegeven moment helemaal verpest met de laatste paar firmware updates!

Haha ja, doel op externe antennes voor die extra decibellen. Verder is het inderdaad zeker voorgekomen dat ik 4x van firmware versie ben gedowngrade.

[...]

Nee, Nee en nog eens Nee : Dat is allemaal dikke onzin!

- Mesh is niet van toepassing, tenzij je met Multi-Hop Mesh units aan de slag gaat.
- Al je Clients zullen nog steeds zelf bepalen wanneer ze roamen van accesspoint naar accesspoint, tenzij je met minRSSI hebt zitten rommelen!
- Welke dubbele netwerk ID's

Het scenario waar ik op doel is alsvolgt
-AP1 staat beneden met SSID netwerka
-AP2 staat op de eerste etage met SSID netwerka

Jij beweegt jezelf van de beneden verdieping naar de zonder. AP1 heeft daar geen bereik dus AP2 neemt het over. Vervolgens ga je terug naar beneden. Echter AP2 blijkt daar nog net 1 balkje bereik te hebben dus je telefoon/tablet blijft doodleuk op AP2 zitten met <10 Mbps in plaats van de 200+ Mbps van AP1 te pakken die 3 meter verderop staat. Wat ik altijd maar deed was het 'oplossen' door de SSD van AP2 te wijzigen naar netwerkB en op het moment dat ik last had zelf handmatig te wisselen.

Zo ver ik heb begrepen, door de community forums te lezen, zou het aanvinken van de mesh functie bij de NanoHd units moeten volstaan om dit probleem te voorkomen. Echter als ik dit fout heb laat het dan aub weten want ik heb er voor mijn testopstelling pas één NanoHD gekocht dus ik kan dat deel niet echt testen nu... Ik had verwacht dat überhaupt één unit configureren lastig was, maar dat viel reuze mee.

Lees of Search het Topic en de voorgaande delen!
Zou je toch ondertussen moeten weten als oudere GoT member

Heb mij nu vooral gebaseerd op de officiele website en forums aldaar. Zal later deze week nog wat bladeren . Er zit ook nog wel semi wat tijdsdruk op ivm uitvallende muziek.

HINT : Raspberry Pi 3B FTW!!!
_{Dus niet de 2 of de 3B+ of de 4, want onzuiniger en langzamer en zo...}

In dit geval help ik een bevriende winkelier met de wifi. Een Raspberri Pi zie ik binnen die context niet zitten, voor thuis zou ik zelfs mijn Rp2 een kans geven want die ligt toch stof te happen .

[ Voor 13% gewijzigd door sdk1985 op 30-09-2019 11:43 ]

[Annuk]

sdk1985 schreef op maandag 30 september 2019 @ 11:33:
[...]

Haha ja, doel op externe antennes voor die extra decibellen. Verder is het inderdaad zeker voorgekomen dat ik 4x van firmware versie ben gedowngrade.

Die "fantastische" externe antennes doen 9 v/d 10x niets he, of is alleen voor de 2,4GHz en niet voor de 5GHz.... en is voornamelijk versiering (lees: hoe meer zichtbare antennes hoe "geiler" de consumenten het vinden).

[...]

Het scenario waar ik op doel is alsvolgt
-AP1 staat beneden met SSID netwerka
-AP2 staat op de eerste etage met SSID netwerka

Jij beweegt jezelf van de beneden verdieping naar de zonder. AP1 heeft daar geen bereik dus AP2 neemt het over. Vervolgens ga je terug naar beneden. Echter AP2 blijkt daar nog net 1 balkje bereik te hebben dus je telefoon/tablet blijft doodleuk op AP2 zitten met <10 Mbps in plaats van de 200+ Mbps van AP1 te pakken die 3 meter verderop staat. Wat ik altijd maar deed was het 'oplossen' door de SSD van AP2 te wijzigen naar netwerkB en op het moment dat ik last had zelf handmatig te wisselen.

Zo ver ik heb begrepen, door de community forums te lezen, zou het aanvinken van de mesh functie bij de NanoHd units moeten volstaan om dit probleem te voorkomen. Echter als ik dit fout heb laat het dan aub weten want ik heb er voor mijn testopstelling pas één NanoHD gekocht dus ik kan dat deel niet echt testen nu... Ik had verwacht dat überhaupt één unit configureren lastig was, maar dat viel reuze mee.

Dan kan je voor de "goedkopere" test ook overwegen om een AP AC-Lite aan te schaffen. Dan kan je in ieder geval testen.
Gezien wat je hieronder zegt is dit allemaal voor die bevriende winkelier of (ook) voor thuis?
Of eerst voor thuis en later voor je bevriende winkelier?

[...]

Heb mij nu vooral gebaseerd op de officiele website en forums aldaar. Zal later deze week nog wat bladeren . Er zit ook nog wel semi wat tijdsdruk op ivm uitvallende muziek.


[...]

In dit geval help ik een bevriende winkelier met de wifi. Een Raspberri Pi zie ik binnen die context niet zitten, voor thuis zou ik zelfs mijn Rp2 een kans geven want die ligt toch stof te happen .

Weet niet of deze persoon (winkelier) iets in de cloud heeft draaien en/of een NAS heeft draaien, anders kan je daar evt. de controller software op draaien i.p.v. een RPi of een Cloudkey (als je voor een cloudkey gaat zou ik voor de Gen2 gaan).

[lier]

sdk1985 schreef op maandag 30 september 2019 @ 11:33:
Zo ver ik heb begrepen, door de community forums te lezen, zou het aanvinken van de mesh functie bij de NanoHd units moeten volstaan om dit probleem te voorkomen. Echter als ik dit fout heb laat het dan aub weten want ik heb er voor mijn testopstelling pas één NanoHD gekocht dus ik kan dat deel niet echt testen nu...

Mesh bepaalt met welke backhaul gewerkt wordt. Oftewel, gebruikt je accesspoint een kabel of maakt het gebruik van een WiFi signaal dat doorgegeven wordt. Dit staat volledig los van de roaming ervaring.

Roaming bereik je (met Unifi) door het zendvermogen goed in te stellen, eventueel in combinatie met data rates. Het gebruik van auto (kanaal en zendvermogen) is altijd af te raden.

[sdk1985]

Annuk schreef op maandag 30 september 2019 @ 11:56:
[...]

Die "fantastische" externe antennes doen 9 v/d 10x niets he, of is alleen voor de 2,4GHz en niet voor de 5GHz.... en is voornamelijk versiering (lees: hoe meer zichtbare antennes hoe "geiler" de consumenten het vinden).

Mja oke ik kan mij goed voorstellen dat 8 antenne's overkill is . Los daarvan ben ik met uitzondering van de kwaliteit van de firmware altijd wel te spreken geweest over de 'kracht' van de R7000. Heb hem ooit eens in de nacht getest tegen een goedkopere dir 842:

1 client

1 streaming client + client


Maar het is nu 3 jaar later dus het kan ongetwijfeld beter.

[...]

Dan kan je voor de "goedkopere" test ook overwegen om een AP AC-Lite aan te schaffen. Dan kan je in ieder geval testen.

Geen gek idee.

Gezien wat je hieronder zegt is dit allemaal voor die bevriende winkelier of (ook) voor thuis?
Of eerst voor thuis en later voor je bevriende winkelier?

Ik heb zelf niets nodig, ik bouw het thuis op en dan gaat het kant en klaar de winkel in. Heb als consument via coolblue besteld dus als ik iets fouts heb bedacht kan het nog 3.5 week terug.

Weet niet of deze persoon (winkelier) iets in de cloud heeft draaien en/of een NAS heeft draaien, anders kan je daar evt. de controller software op draaien i.p.v. een RPi of een Cloudkey (als je voor een cloudkey gaat zou ik voor de Gen2 gaan).

Helaas niet, alleen een paar wat oudere desktops die AFAIK gewoon uit gaan na sluitingstijd.

lier schreef op maandag 30 september 2019 @ 12:08:
[...]

Mesh bepaalt met welke backhaul gewerkt wordt. Oftewel, gebruikt je accesspoint een kabel of maakt het gebruik van een WiFi signaal dat doorgegeven wordt. Dit staat volledig los van de roaming ervaring.

Duidelijk.

De winkel zelf is niet zo'n probleem (18x3), alleen het achterdeel zit achter een muur met een deur. Achter die deur zit een ruime hal van 2x3. Die hal geeft aan de linker kant toegang tot een kamer van 3x3. Het pand heeft dus feitelijk een soort gedraaide L vorm. In die verste kamer staat een desktop met een PCI wifi antenne. Als het signaal niet lekker door die deur heen komt dan verwacht ik niet dat de mesh hierbij gaat helpen. Voor dat scenario had ik het idee dat de enige optie een extra kabel trekken is en dan een AP aan de andere kant van de muur/deur te zetten.

Wellicht dat 2.4 er wel komt omdat het 'slechts' 20 meter is en dat die dan via meshing het signaal van de verste kamer kan doorzetten naar de AP in de winkel. Voor die ene pc en 3-4 medewerkers tijdens de pauze zou zo'n lite überhaupt wel volstaan toch?

Roaming bereik je (met Unifi) door het zendvermogen goed in te stellen, eventueel in combinatie met data rates. Het gebruik van auto (kanaal en zendvermogen) is altijd af te raden.

Oke dat is jammer is had gehoopt op een automagische implementatie op firmware niveau. Dat van het zendvermogen snap ik, dan dwing je gewoon af dat het niet door de muur komt. Echter de data rates snap ik even niet hoe die daarbij gaan helpen. Zou je dat willen toelichten?

[ Voor 6% gewijzigd door sdk1985 op 30-09-2019 12:33 ]

[lier]

Met datarates kan je een threshold waarde instellen waarbij de client van het accesspoint gekickt wordt. Door deze goed in te stellen wordt een client eerder gemotiveerd om opnieuw te zoeken. Echter is het van de client afhankelijk of deze voor het sterkste signaal gaat of opnieuw met het accesspoint waarmee verbonden was een verbinding te maken.

Verder als regel: alles dat vast staat een kabel geven. Dus zowel de accesspoint als de pc. Een Lite is een prima accesspoint en kan de nodige clients bedienen.

[nero355]

JoeZuCK schreef op maandag 30 september 2019 @ 06:37:
@nero355 klein beetje offtopic, maar ik zit te denken om een Raspberry te halen. Zie dat jij de 3 boven zijn opvolgers prefereert. Waarom is dat precies?

Hierom : Magic in "Raspberry Pi - deel 2"

En nu ik het zo zie is de 2B naast de 3B eigenlijk ook helemaal zo gek nog niet!

sdk1985 schreef op maandag 30 september 2019 @ 11:33:
Verder is het inderdaad zeker voorgekomen dat ik 4x van firmware versie ben gedowngrade.

Hmm... dus toch

Het scenario waar ik op doel is alsvolgt
-AP1 staat beneden met SSID netwerka
-AP2 staat op de eerste etage met SSID netwerka

Jij beweegt jezelf van de beneden verdieping naar de zonder. AP1 heeft daar geen bereik dus AP2 neemt het over. Vervolgens ga je terug naar beneden. Echter AP2 blijkt daar nog net 1 balkje bereik te hebben dus je telefoon/tablet blijft doodleuk op AP2 zitten met <10 Mbps in plaats van de 200+ Mbps van AP1 te pakken die 3 meter verderop staat. Wat ik altijd maar deed was het 'oplossen' door de SSD van AP2 te wijzigen naar netwerkB en op het moment dat ik last had zelf handmatig te wisselen.

Ik zou dat ook met een random aantal accesspoints voor elkaar kunnen krijgen door ze fatsoenlijk in te stellen dus dat is gewoon een "Administrator Error"

En als je meerdere SSID's hebt dan gaat je hele Roaming verhaal sowieso stuk!

ik heb voor mijn testopstelling pas één NanoHD gekocht dus ik kan dat deel niet echt testen nu... Ik had verwacht dat überhaupt één unit configureren lastig was, maar dat viel reuze mee.

Waarom gelijk een NanoHD

Een AC Lite zal in 9 van de 10 situaties meer dan genoeg zijn, tenzij je een winkelcentrum of stadion of zo van WiFi gaat voorzien ?!

In dit geval help ik een bevriende winkelier met de wifi. Een Raspberri Pi zie ik binnen die context niet zitten, voor thuis zou ik zelfs mijn Rp2 een kans geven want die ligt toch stof te happen

Een 2B kan dus prima als UniFi Controller dienen samen met Pi-Hole

Hou er wel rekening mee dat de oude simpele CloudKey niet veel stabieler is of zelfs meer kans op corruptie heeft dan een Raspberry Pi

Annuk schreef op maandag 30 september 2019 @ 11:56:
Die "fantastische" externe antennes doen 9 v/d 10x niets he, of is alleen voor de 2,4GHz en niet voor de 5GHz.... en is voornamelijk versiering (lees: hoe meer zichtbare antennes hoe "geiler" de consumenten het vinden).

Ik kan me een test van een WiFi USB Dongle herinneren waarbij de "antenne" gewoon een leeg stuk plastic was!

sdk1985 schreef op maandag 30 september 2019 @ 12:28:
De winkel zelf is niet zo'n probleem (18x3), alleen het achterdeel zit achter een muur met een deur. Achter die deur zit een ruime hal van 2x3. Die hal geeft aan de linker kant toegang tot een kamer van 3x3. Het pand heeft dus feitelijk een soort gedraaide L vorm. In die verste kamer staat een desktop met een PCI wifi antenne. Als het signaal niet lekker door die deur heen komt dan verwacht ik niet dat de mesh hierbij gaat helpen. Voor dat scenario had ik het idee dat de enige optie een extra kabel trekken is en dan een AP aan de andere kant van de muur/deur te zetten.

Wellicht dat 2.4 er wel komt omdat het 'slechts' 20 meter is en dat die dan via meshing het signaal van de verste kamer kan doorzetten naar de AP in de winkel. Voor die ene pc en 3-4 medewerkers tijdens de pauze zou zo'n lite überhaupt wel volstaan toch?

Doe jezelf en die eigenaar een lol een trek gewoon overal een kabel naartoe!

Zal je toch op de een of andere manier nodig hebben voor PoE doeleinden en zo'n winkel of hal kan je veel makkelijker van een heleboel UTP kabels voorzien dan het gemiddelde huis over het algemeen

Verder een paar AC Lite modellen op de juiste plek en gaan met die banaan!

[borft]

nero355 schreef op maandag 30 september 2019 @ 15:06:
[...]

Waarom gelijk een NanoHD

Een AC Lite zal in 9 van de 10 situaties meer dan genoeg zijn, tenzij je een winkelcentrum of stadion of zo van WiFi gaat voorzien ?!

+1 Hier kan ik makkelijk > 40 clients op 1 ac-lite aan, werkt eigenlijk prima.

[m3gA]

nero355 schreef op maandag 30 september 2019 @ 15:06:

Hou er wel rekening mee dat de oude simpele CloudKey niet veel stabieler is of zelfs meer kans op corruptie heeft dan een Raspberry Pi

Dat was vroeger zo. Sinds +/- 1 jaar hebben ze journaling aanstaan. Tenzij je dat handmatig uitzet is de kans op corruptie nihil.

[sdk1985]

borft schreef op maandag 30 september 2019 @ 15:22:
[...]


+1 Hier kan ik makkelijk > 40 clients op 1 ac-lite aan, werkt eigenlijk prima.

Dat is aardig wat. Ik verwacht op de piek 22 active clients. Ik heb mij gebaseerd op de datasheet:

Op basis van die figuur kwam de ac pro tussen de 30 en 130 mbps terwijl de nano tussen de 300 en 440 Mbps blijft zitten. Dan maak ik daarbij even de aanname dat deze figuren kloppen en dat de lite daar nog onder zit qua performance. Maar goed eenmalig een keer 60 euro teveel betalen is in dit geval ook niet het einde van de wereld. Omgekeerd is vervelender als het tegenvalt, dan moet de hele inrichting opnieuw... Dat en de nano heeft MU-MIMO en covers zijn ook wel fancy .

nero355 schreef op maandag 30 september 2019 @ 15:06:
Doe jezelf en die eigenaar een lol een trek gewoon overal een kabel naartoe!

Dat was inderdaad mijn eerste advies . Begin volgend jaar gaat de boel op de schop dus de afspraak is dat ik dan even mijn mening geef over de kabels.

[ Voor 38% gewijzigd door sdk1985 op 30-09-2019 16:57 ]

[borft]

sdk1985 schreef op maandag 30 september 2019 @ 16:52:
[...]

Dat is aardig wat. Ik verwacht op de piek 22 active clients. Ik heb mij gebaseerd op de datasheet:
[Afbeelding]
Op basis van die figuur kwam de ac pro tussen de 30 en 130 mbps terwijl de nano tussen de 300 en 440 Mbps blijft zitten. Dan maak ik daarbij even de aanname dat deze figuren kloppen en dat de lite daar nog onder zit qua performance. Maar goed eenmalig een keer 60 euro teveel betalen is in dit geval ook niet het einde van de wereld. Omgekeerd is vervelender als het tegenvalt, dan moet de hele inrichting opnieuw... Dat en de nano heeft MU-MIMO en covers zijn ook wel fancy .

Hmmm, interesssant grafiekje, daar herken ik me niet echt in. Aan de andere kant, onze glasvezel verbinding is 100Mbps symmetrisch, en die haal je eigenlijk altijd wel. Veel sneller dan dat heb ik dus niet nodig. Wat wel; belangrijk is, is lage latency (want remote sessies), en stabiele bandbreedte (want voip/video conferencing) en dat werkt eigenlijk altijd prima. maar YMMV

Overigens zie ik niet helemaal het nut van 4 antennes en meer. Meeste wifi kaartjes in laptops en telefoons hebben er maximaal 2 namelijk. En met de lage prijzen voor de lite, kan je er 2 kopen voor de prijs van 1 HD. Ik denk dat het wel vrij waarschijnlijk is, dat je met meer AP's (op een lager vermogen), een hogeren bandbreedte / uitilisatie van je uplink gaat halen. Minder clients/AP betekent minder load, betekent ook minder interferentie.....

[sdk1985]

nero355 schreef op maandag 30 september 2019 @ 15:06:


Ik zou dat ook met een random aantal accesspoints voor elkaar kunnen krijgen door ze fatsoenlijk in te stellen dus dat is gewoon een "Administrator Error"

En als je meerdere SSID's hebt dan gaat je hele Roaming verhaal sowieso stuk!

Dat klopt binnen mijn kennis is het dus of willekeurige momenten op het trage AP zitten of handmatig roamen en ik hoopte daar via ubiquitu een alternatief voor te hebben gevonden. Zoals jij het uitlegt kan dat dus ook met 2x een netgear .

Verder ga er eigenlijk vanuit dat wanneer je de transmit power gaat verlagen je daarmee ook de snelheid mee raakt in de ruimt waar je dan alsnog bereik hebt. Dus het is nooit bij mij opgekomen om AP2 terug te schroeven. Ik heb Ziggo zijn modem wel op de laagste stand staan (iets met wifihotspot:P)

borft schreef op maandag 30 september 2019 @ 17:00:


Overigens zie ik niet helemaal het nut van 4 antennes en meer. Meeste wifi kaartjes in laptops en telefoons hebben er maximaal 2 namelijk.

Zorgen die twee extra antennes juist niet voor die hogere concurrency? Daar komt dan nog bij dat iedereen door elkaar heen mag praten in plaats van te wachten op hun timeslot. Het marketing verhaal raakt bij mij wel een snaar .

borft schreef op maandag 30 september 2019 @ 17:00:
En met de lage prijzen voor de lite, kan je er 2 kopen voor de prijs van 1 HD. Ik denk dat het wel vrij waarschijnlijk is, dat je met meer AP's (op een lager vermogen), een hogeren bandbreedte / uitilisatie van je uplink gaat halen. Minder clients/AP betekent minder load, betekent ook minder interferentie.....

Ik snap je punt. In mijn implementatie vraagstuk is één acces point de voorkeursoptie omdat daar een kabeltje voor langs de muur in een kabelgootje kan. Voor een tweede acces point moet er flink wat overhoop gehaald worden omdat er nog een soort keukenblok en een toilet in de weg zit. Dus het kan wel, maar liever niet.

An sich heeft dit nog wel een redelijke kans van slagen omdat de huidige wifi via een ISP router in de meterkast loopt. Als de losse NanoHD niet voldoende blijkt voor de achterruimte dan kan het 2e AP meegenomen worden in de verbouwing begin volgend jaar. Dus het is niet erg als het nu niet in één keer perfect is.

[ Voor 61% gewijzigd door sdk1985 op 30-09-2019 17:17 ]

[RobertMe]

sdk1985 schreef op maandag 30 september 2019 @ 17:08:
[...]

Zorgen die twee extra antennes juist niet voor die hogere concurrency? Daar komt dan nog bij dat iedereen door elkaar heen mag praten in plaats van te wachten op hun timeslot. Het marketing verhaal raakt bij mij wel een snaar .

Dan heeft die marketing praat bij jou inderdaad een snaar geraakt en is het verkeerde blijven hangen.
Die extra antennes van de HD modellen worden alleen gebruikt voor het tegelijkertijd met meerdere clients communiceren als al die clients ondersteuning hebben voor MU-MIMO (Multi User - MIMO). En ook dat is letterlijk nog maar de helft van het verhaal. Want MU-MIMO zoals het is 802.11ac / WIFI 5 zit werkt maar één richting op. Volgens mij in de zin dat het AP wel naar meerdere clients tegelijkertijd kan zenden, maar de clients kunnen niet tegelijkertijd iets naar het AP sturen (of het was andersom, in ieder geval werkt het MU deel maar één richting op).

MU-MIMO beide kanten op zit volgens mij pas in 802.11ax / WIFI 6.

Het enige waar die extra antennes dus voor zorgen is extra ruisonderdrukking. Maar als je ze daarvoor wilt gebruiken zijn 2 antennes van een extra AC-Lite net zo duur en doordat je die beter kunt plaatsen is het effect ervan ook een stuk groter.

[sdk1985]

Ben overigens ondertussen tot de realisatie gekomen dat ik zelf een nas heb. Dus ik heb de controller software op mijn laptop uitgeschakeld en heb hem op mijn NAS geïnstalleerd. Resteert alleen de vraag hoe ik de AP's 'vertel' dat ze straks via het internet moeten 'inbellen' bij mijn NAS.

Ik heb nu de backup van mijn laptop geïmporteerd op de nas. Maar zo te zien is dat helemaal fout; https://help.ubnt.com/hc/...P-adoption-and-management

Leesvoer voor morgen .

[rinkel]

sdk1985 schreef op dinsdag 1 oktober 2019 @ 00:37:
Ben overigens ondertussen tot de realisatie gekomen dat ik zelf een nas heb. Dus ik heb de controller software op mijn laptop uitgeschakeld en heb hem op mijn NAS geïnstalleerd. Resteert alleen de vraag hoe ik de AP's 'vertel' dat ze straks via het internet moeten 'inbellen' bij mijn NAS.

Ik heb nu de backup van mijn laptop geïmporteerd op de nas. Maar zo te zien is dat helemaal fout; https://help.ubnt.com/hc/...P-adoption-and-management

Leesvoer voor morgen .

Dan moet je NAS hetzelfde IP-adres hebben als je Laptop. Anders eerst alle devices op de controller “vergeten” en Dan opnieuw koppelen als de controller op de NAS staat.

[RobertMe]

rinkel schreef op dinsdag 1 oktober 2019 @ 08:19:
[...]


Dan moet je NAS hetzelfde IP-adres hebben als je Laptop. Anders eerst alle devices op de controller “vergeten” en Dan opnieuw koppelen als de controller op de NAS staat.

Dat hoeft niet perse. Standaard is de inform URL unifi en die resolved naar UniFi Controller host. Als de inform URL is aangepast en nu op IP basis is moet die inderdaad worden aangepast, maar het kan ook nog zijn dat die nog op unifi staat en dan gaat het wel goed.

Ik heb in ieder geval toen ik aan UniFi begon de controller ook op laptop gehad en daarna naar mijn NAS verhuisd en met backup & restore ging dat goed, zonder IP / inform shizzle.

[Oesie]

@ed1703, @RobertMe, @nero355, @Jeroen_ae92, @mithras, bedankt voor jullie help so far. Kon in het weekend niet verder kijken dus vandaar een wat late reactie. Goed om te lezen dat jullie het werkend hebben gekregen! Heb nu de json gebruikt van RobertMe (wel het Pi-hole adres aangepast natuurlijk ).

Wat is de juiste manier om het echt te testen? Want als ik een dig command doe zoals ed1703 zie ik qua output nog de 8.8.8.8 DNS server staan en in Pi-hole zie ik de request niet terug komen. Dus het lijkt erop dat ik dan toch nog iets fout heb staan

code:

test@sullivan:~$ dig tweakers.net @8.8.8.8

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> tweakers.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22014
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;tweakers.net.                  IN      A

;; ANSWER SECTION:
tweakers.net.           59      IN      A       213.239.154.30

;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 01 09:45:51 CEST 2019
;; MSG SIZE  rcvd: 57

[geenwindows]

Oesie schreef op dinsdag 1 oktober 2019 @ 09:47:
@ed1703, @RobertMe, @nero355, @Jeroen_ae92, @mithras, bedankt voor jullie help so far. Kon in het weekend niet verder kijken dus vandaar een wat late reactie. Goed om te lezen dat jullie het werkend hebben gekregen! Heb nu de json gebruikt van RobertMe (wel het Pi-hole adres aangepast natuurlijk ).

Wat is de juiste manier om het echt te testen? Want als ik een dig command doe zoals ed1703 zie ik qua output nog de 8.8.8.8 DNS server staan en in Pi-hole zie ik de request niet terug komen. Dus het lijkt erop dat ik dan toch nog iets fout heb staan

code:

test@sullivan:~$ dig tweakers.net @8.8.8.8

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> tweakers.net @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22014
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;tweakers.net.                  IN      A

;; ANSWER SECTION:
tweakers.net.           59      IN      A       213.239.154.30

;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Oct 01 09:45:51 CEST 2019
;; MSG SIZE  rcvd: 57

dit is mijn werkende script:

code:

{
    "service": {
        "nat": {
            "rule": {
                "1": {
                    "description": "Redirect DNS requests",
                    "destination": {
                        "port": "53"
                    },
                    "inbound-interface": "eth0+",
                    "inside-address": {
                        "address": "192.168.1.9-192.168.1.10",
                        "port": "53"
                    },
                    "source": {
                        "address": "!192.168.1.9-192.168.1.10"
                    },
                    "log": "disable",
                    "protocol": "tcp_udp",
                    "type": "destination"
                },
                "6000": {
                    "description": "MASQ DNS requests to LAN",
                    "destination": {
                        "address": "192.168.1.9-192.168.1.10",
                        "port": "53"
                    },
                    "log": "disable",
                    "outbound-interface": "eth0+",
                    "protocol": "tcp_udp",
                    "type": "masquerade"
                }
            }
        }
    }
}

let op, ik heb 2 pi-hole draaien (HA) en gebruik de USG Pro4 (eth0+ ipv eth1+ bij de usg non pro)
dig command staat bij mij ook nog de gevraagde dns server, maar de reactie komt toch echt van pi-hole af.

[sdk1985]

RobertMe schreef op dinsdag 1 oktober 2019 @ 08:33:
[...]

Dat hoeft niet perse. Standaard is de inform URL unifi en die resolved naar UniFi Controller host. Als de inform URL is aangepast en nu op IP basis is moet die inderdaad worden aangepast, maar het kan ook nog zijn dat die nog op unifi staat en dan gaat het wel goed.

Ik heb in ieder geval toen ik aan UniFi begon de controller ook op laptop gehad en daarna naar mijn NAS verhuisd en met backup & restore ging dat goed, zonder IP / inform shizzle.

Dat heeft hij eigenlijk vanzelf opgelost inderdaad; hij ging opnieuw schrijven na de AP.

Maar vermoedelijk inderdaad op basis van het nieuwe lokale ip adres. Ik ga straks natuurlijk de AP's zelf fysiek in een ander netwerk hangen. Dus hij moet het gaan wegschrijven op de hostname van mijn NAS die via het internet bereikbaar is. Ga vanavond eens kijken of dat in de guide die ik gisteren tegenkwam te vinden is.

[Kavaa]

Mooi en duidelijk vergelijk tussen UniFi Router en Switches en Edgerouter en Edgeswitches
UniFi Access Points buiten spel gelaten:

YouTube: UniFi vs EdgeMAX - USG vs EdgeRouter - UniFi Switch vs EdgeSwitch

[sdk1985]

Heb ondertussen een domein gebaseerd hostname gemaakt en in de controller ingevoerd en deze config opgeslagen. Daarna de AP afgekoppeld en fysiek naar een ander huis gebracht en daar aangesloten. An sich werkt de wifi inclusief het gastenportal.

Echter ik krijg deze STUN waarschuwing: https://help.ubnt.com/hc/...STUN-Communication-Errors

Aan mijn kant staat er in mijn ziggo router gewoon een UDP port forward van ANY naar het lokale IP van mijn NAS op UDP. Ook de norton firewall uitzetten op de NAS helpt niet. Is er nog iets anders dat ik hier aan zou kunnen doen?

edit:
Ik heb geprobeerd de stunpoort te verhuizen naar een hogere poort en daarna opnieuw provisioneren. Tot heden geen effect. De melding blijft praten over de originele poort.


Ook zie in de controller bij Netwerken een LAN staan met doel zakelijk en een subnet van 192.168.1.0/24. Wat moet ik hier mee? Mijn eigen netwerk zit op 192.168.178.X en DHCP doet de ziggo routerr. Een 'USG" heb ik niet. Moet ik daar mijn eigen lokale waarden invullen?

[ Voor 33% gewijzigd door sdk1985 op 01-10-2019 22:37 ]

[nero355]

sdk1985 schreef op dinsdag 1 oktober 2019 @ 20:09:
Echter ik krijg deze STUN waarschuwing: https://help.ubnt.com/hc/...STUN-Communication-Errors

Aan mijn kant staat er in mijn ziggo router gewoon een UDP port forward van ANY naar het lokale IP van mijn NAS op UDP. Ook de norton firewall uitzetten op de NAS helpt niet. Is er nog iets anders dat ik hier aan zou kunnen doen?

De Search gebruiken : nero355 in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3"

Ook zie in de controller bij Netwerken een LAN staan met doel zakelijk en een subnet van 192.168.1.0/24. Wat moet ik hier mee? Mijn eigen netwerk zit op 192.168.178.X en DHCP doet de ziggo routerr. Een 'USG" heb ik niet. Moet ik daar mijn eigen lokale waarden invullen?

Dat is het prachtige Management VLAN waar je niks aan hebt zonder een USG

[sdk1985]

nero355 schreef op dinsdag 1 oktober 2019 @ 23:59:
[...]

De Search gebruiken : nero355 in "[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3"


[...]

Moet gewoon werken toch!?

In eerste instantie zag ik via SSH in de logs van de AP wat resolve problemen, heb hem nu even direct op IP gezet. Vreemd genoeg zie ik sindsdien in de logs überhaupt geen inform of stun requests voorbij komen .

Ik gebruik nu stun poort 34780 via een settings override, maar dat lost tot nu toe niets op.

Dat is het prachtige Management VLAN waar je niks aan hebt zonder een USG

Zou het helemaal niets doen nu? Want een DNS probleem zou an sich wel een verklaring voor mijn probleem zijn en bij hele rare DHCP heb je ook geen DNS.

[KeRsTmAnNeKe]

Vandaag een USG binnen gehad, als vervanging voor de Airport Extreme.
Heb de hele avond zitten rommelen, maar krijg hem niet aan de praat, LAN is geen probleem, maar WAN wil niet.

Begon gewoon wat te rommelen, uiteindelijk handleiding erbij gezocht hoe een bestaande router te vervangen (netwerk zit op 10.0.x.x ipv 192.168.x.x zoals default) dat was uiteindelijk allemaal geen issue, heb hem netjes kunnen toevoegen.
Maar geen internet, wat ik ook probeerde. Uiteindelijk dacht ik, fuck it, dan maar opnieuw begonnen, backup getrokken van de controller, controller gereset, basic settings toegepast aan de hand van oa wat videos op youtube... niks.

Uiteindelijk USG los nog gereset, laptop op de LAN poort, modem op de WAN poort, naar https://192.168.1.1, en geen internet.

Lijkt alsof mijn Ziggo modem (Cisco, in bridge modus) geen IP wil uitdelen. Modem ook al enkele keren gereset, doet ook niks. Prik ik de Airport er weer in, modem een trap geven, en het werkt weer.

Om te zien of WAN-LAN gewoon werkt kan ik hem morgen wel op een uitgaande poort van de Airport zetten, heb ik wel 2 routers, maar als test lijkt me dat wel te werken, al moet ik denk ik wel zorgen dat ze niet allebei in de 10.0.0.x range zitten.

Het rare is... ik heb wel even de status van de modem kunnen opvragen via 192.168.178.1, maar kort daarna werkte dat ook niet meer.

Wat ik ook nog kan doen is hem gewoon een fixed IP geven. Heb de gegevens uit de Airport, die is toch al jaren hetzelfde.

Iemand anders nog ideeën?

[m3gA]

En weer nieuwe speelgoed via Reddit.
Een dikke 4 bay NVR en een redundant power supply.

https://www.reddit.com/r/...prps_and_nonpoe_versions/

[rinkel]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 00:17:

Lijkt alsof mijn Ziggo modem (Cisco, in bridge modus) geen IP wil uitdelen. Modem ook al enkele keren gereset, doet ook niks. Prik ik de Airport er weer in, modem een trap geven, en het werkt weer.

Dat klopt, een modem in bridge deelt geen ip-adressen meer uit. DHCP staat dan uit. Het Ziggo modem krijgt dan het standaard ipadres: 192.168.178.1, maar eigenlijk doet dat er niet meer toe, daar kun je toch niets meer wijzigen.
Wel zou Ziggo de USG een ipadres moeten geven aan de WAN kant, dus DHCP aan op de WAN kant.
De LAN kant moet dan een vast ip-adres krijgen en DHCP aan voor de rest van je LAN.

Daarnaast krijg je elke keer als je nu van router wisselt een nieuw ip-adres (WAN) van Ziggo omdat het mac-adres aan de WAN kant wijzigt. Het kan dan soms een paar minuten duren voordat je weer internet hebt.

[ Voor 47% gewijzigd door rinkel op 02-10-2019 09:17 ]

[Hellboy!]

Ben met aan het orienteren naar 2 nieuwe accesspoints, de benedenverdieping gaat prima met de experiabox v10, de oude wifiversterker (1e etage andere kant van het huis )begint kuren te krijgen en is de dekking slecht.

Mijn idee was eerst om 2 LR's aan te schaffen, maar zag in het forum dat een lite meer dan voldoende is.

Echter heb ik nog 2 vragen:

1: de meegeleverde PoE adapter is toch prima, of is het beter een aparte switch te kopen die PoA ondersteund?
2: de controller software heb je niet nodig voor de AP's maar als je deze toch wilt gebruiken, hoeft deze toch niet 24/7 aan te staan?

Alvast bedankt

[Gunner]

Hellboy! schreef op woensdag 2 oktober 2019 @ 09:36:
1: de meegeleverde PoE adapter is toch prima, of is het beter een aparte switch te kopen die PoA ondersteund?
2: de controller software heb je niet nodig voor de AP's maar als je deze toch wilt gebruiken, hoeft deze toch niet 24/7 aan te staan?

Alvast bedankt

De lite voldoet meer dan prima meestal. Als je eenmaal Unifi-spul koopt, dan komen de PoE switchvarianten al vrij snel erbij is mijn ervaring

Controller software hoeft idd niet 24/7 te draaien. Is alleen nodig mocht je een guest portal willen draaien.

[rinkel]

Hellboy! schreef op woensdag 2 oktober 2019 @ 09:36:
Ben met aan het orienteren naar 2 nieuwe accesspoints, de benedenverdieping gaat prima met de experiabox v10, de oude wifiversterker (1e etage andere kant van het huis )begint kuren te krijgen en is de dekking slecht.

Mijn idee was eerst om 2 LR's aan te schaffen, maar zag in het forum dat een lite meer dan voldoende is.

Echter heb ik nog 2 vragen:

1: de meegeleverde PoE adapter is toch prima, of is het beter een aparte switch te kopen die PoA ondersteund?
2: de controller software heb je niet nodig voor de AP's maar als je deze toch wilt gebruiken, hoeft deze toch niet 24/7 aan te staan?

Alvast bedankt

1: Klopt, die werken prima, maar een poe switch is veel practischer, zeker als je later nog een apparaat van stroom wilt voorzien
2: Klopt, en klopt. Maar het is wel zo makkelijk. Ik heb er een PI voor ingezet.

[KeRsTmAnNeKe]

rinkel schreef op woensdag 2 oktober 2019 @ 08:55:
[...]

Dat klopt, een modem in bridge deelt geen ip-adressen meer uit. DHCP staat dan uit. Het Ziggo modem krijgt dan het standaard ipadres: 192.168.178.1, maar eigenlijk doet dat er niet meer toe, daar kun je toch niets meer wijzigen.
Wel zou Ziggo de USG een ipadres moeten geven aan de WAN kant, dus DHCP aan op de WAN kant.
De LAN kant moet dan een vast ip-adres krijgen en DHCP aan voor de rest van je LAN.

Ja precies dit, interne netwerk moet ip adressen krijgen van de USG, dat werkte, alleen de USG kreeg zelf geen ip adres op WAN.
192.168.178.1 is idd niet meer dan een statuspagina, maar die zit wel aan de WAN kant, dus ergens wel raar dat ik deze kortstondig kon bekijken en daarna niet meer.

Daarnaast krijg je elke keer als je nu van router wisselt een nieuw ip-adres (WAN) van Ziggo omdat het mac-adres aan de WAN kant wijzigt. Het kan dan soms een paar minuten duren voordat je weer internet hebt.

Te ongeduldig ?

[Ophidian]

Hellboy! schreef op woensdag 2 oktober 2019 @ 09:36:
Ben met aan het orienteren naar 2 nieuwe accesspoints, de benedenverdieping gaat prima met de experiabox v10, de oude wifiversterker (1e etage andere kant van het huis )begint kuren te krijgen en is de dekking slecht.

Mijn idee was eerst om 2 LR's aan te schaffen, maar zag in het forum dat een lite meer dan voldoende is.

Echter heb ik nog 2 vragen:

1: de meegeleverde PoE adapter is toch prima, of is het beter een aparte switch te kopen die PoA ondersteund?
2: de controller software heb je niet nodig voor de AP's maar als je deze toch wilt gebruiken, hoeft deze toch niet 24/7 aan te staan?

Alvast bedankt

1. De meegeleverde PoE adapter is inderdaad prima. Je kan een PoE switch overwegen, echter kosten die extra. In mijn geval zou de 24-poorts Unifi switch dik 170 euro extra kosten. En dat alleen voor de 2 a 3 access points die het gebruiken en de andere 21 poorten die het niet gebruiken. Ik heb er voor gekozen het niet te doen. Daar waar de wandcontactdoos UTP zit, kan ik ook meteen de PoE injector zetten en dan bereik ik hetzelfde.
2. Ik gebruik ook een Raspberry Pi hiervoor. Unifi draait in docker en dit draait als een trein. Watch Tower update daarnaast automatisch de unifi container zodra er een nieuwe versie beschikbaar is en dat werkt prima.

Ik zelf moet nog kijken naar een extra access point voor in de garage. Het 5Ghz bereik naar buiten is prima, alleen de 2,4Ghz zakt flink in op de oprit. De Nest camera's krijg ik daardoor niet gekoppeld. Proberen maar keer goedkoop een Lite op de kop te tikken denk ik en de camera's hun eigen netwerk geven los van de rest.

[rinkel]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 09:50:
[...]

Ja precies dit, interne netwerk moet ip adressen krijgen van de USG, dat werkte, alleen de USG kreeg zelf geen ip adres op WAN.
192.168.178.1 is idd niet meer dan een statuspagina, maar die zit wel aan de WAN kant, dus ergens wel raar dat ik deze kortstondig kon bekijken en daarna niet meer.


[...]

Te ongeduldig ?

Als de WAN kant op DHCP staat zou deze een IP van Ziggo moeten krijgen.
Niet per ongelukt de kabels op de USG verkeerdom?

[Hellboy!]

2. Ik gebruik ook een Raspberry Pi hiervoor. Unifi draait in docker en dit draait als een trein. Watch Tower update daarnaast automatisch de unifi container zodra er een nieuwe versie beschikbaar is en dat werkt prima.

Als het toch als docker image beschikbaar is kan ik deze mooi vanaf mijn laptop bedienen.

Was ook aan het twijfelen om voor fritzbox te gaan, maar heb geen zin om de experiabox te vervangen, wil geen gezeur als er e.e.a. wijzigt, omdat ik en mijn vrouw veel thuiswerken.

[rinkel]

Hellboy! schreef op woensdag 2 oktober 2019 @ 10:25:
[...]


Als het toch als docker image beschikbaar is kan ik deze mooi vanaf mijn laptop bedienen.

Was ook aan het twijfelen om voor fritzbox te gaan, maar heb geen zin om de experiabox te vervangen, wil geen gezeur als er e.e.a. wijzigt, omdat ik en mijn vrouw veel thuiswerken.

Je hoeft overigens niet meteen een Ubiquiti POE switch te kopen. Ik heb er een paar van TP-Link, prima dingen. Ik heb 2x 5 poort POE naast elkaar hangen. Dus nu 8 POE poorten waarvan 5 in gebruik. Ik had daar geen non-POE nodig, dus daarom 2x de 5-poorts genomen.

[ Voor 5% gewijzigd door rinkel op 02-10-2019 10:37 ]

[Quakie]

Kavaa schreef op dinsdag 1 oktober 2019 @ 19:50:
Mooi en duidelijk vergelijk tussen UniFi Router en Switches en Edgerouter en Edgeswitches
UniFi Access Points buiten spel gelaten:

YouTube: UniFi vs EdgeMAX - USG vs EdgeRouter - UniFi Switch vs EdgeSwitch

Willie!!



Al uren kijkplezier gehad en super leuk om te zien hoe hij zijn channel uitbreidt. In begin was het alleen hij aan het tikken en viewers mee kijken . Hij legt het goed uit en simpel uit naar mijn idee.

[koelkast]

Ik heb de beschikking over een USG en 2 access points. Daartussen heb ik een netgear managed switch zitten.
Nu wil ik gebruik maken van 3 verschillende subnets, per draadloos netwerk, omdat ik mijn internetaansluiting deel met anderen, én een apart Iot wlan netwerk wil hebben.

Ik heb daarom dus 3 verschillende wireless networks aangemaakt waarop ik kan connecten met draadloze apparatuur, voorzien van VLAN tags 10, 30 en 50.
Ook heb ik 3 verschillende networks aangemaakt, die ook de VLAN nummers 10, 30 en 50 hebben gekregen, dus gekoppeld met de De USG moet (dus) op 3 verschillende netwerken adressen uitdelen als DHCP server; 192.168.1.1, 192.168.3.1 en 192.168.5.1.
Echter, de USG geeft geen ip adressen uit op zowel 'buren' netwerk (v30) en het 'iot' netwerk (v50), wel op het VLAN 10 netwerk, wat de 192.168.1.x range is.




Ik lijk dus alles goed ingesteld hebben in de USG. Klopt dat? Nu vraag ik me af of ik nog iets in de netgear switch moet zetten om die VLANs in goede banen te leiden. Moet ik iets taggen? Of trunken?

[ Voor 7% gewijzigd door koelkast op 02-10-2019 17:07 ]

[borft]

koelkast schreef op woensdag 2 oktober 2019 @ 17:04:
Ik heb de beschikking over een USG en 2 access points. Daartussen heb ik een netgear managed switch zitten.
Nu wil ik gebruik maken van 3 verschillende subnets, per draadloos netwerk, omdat ik mijn internetaansluiting deel met anderen, én een apart Iot wlan netwerk wil hebben.

Ik heb daarom dus 3 verschillende SSID's aangemaakt waarop ik kan connecten met draadloze apparatuur, voorzien van VLAN tags 10, 30 en 50.
Ook heb ik 3 verschillende netwerken aangemaakt, die ook de VLAN nummers 10, 30 en 50 hebben gekregen. De USG moet op 3 verschillende netwerken adressen uitdelen als DHCP server; 192.168.1.1, 192.168.3.1 en 192.168.5.1.
Echter, de USG geeft geen ip adressen uit op zowel 'buren' netwerk (v30) en het 'iot' netwerk (v50), wel op het VLAN 10 netwerk, wat de 192.168.1.x range is.

Ik lijk dus alles goed ingesteld hebben in de USG. Klopt dat? Nu vraag ik me af of ik nog iets in de netgear switch moet zetten om die VLANs in goede banen te leiden. Moet ik iets taggen? Of trunken?

Lijkt me dat je in moet stellen dat op de porten die je gebruikt, alles tagged wordt doorgegeven voor de vlan id's die je gebruikt....

[qwasd]

koelkast schreef op woensdag 2 oktober 2019 @ 17:04:
Ik heb de beschikking over een USG en 2 access points. Daartussen heb ik een netgear managed switch zitten.
Nu wil ik gebruik maken van 3 verschillende subnets, per draadloos netwerk, omdat ik mijn internetaansluiting deel met anderen, én een apart Iot wlan netwerk wil hebben.

Ik heb daarom dus 3 verschillende wireless networks aangemaakt waarop ik kan connecten met draadloze apparatuur, voorzien van VLAN tags 10, 30 en 50.
Ook heb ik 3 verschillende networks aangemaakt, die ook de VLAN nummers 10, 30 en 50 hebben gekregen, dus gekoppeld met de De USG moet (dus) op 3 verschillende netwerken adressen uitdelen als DHCP server; 192.168.1.1, 192.168.3.1 en 192.168.5.1.
Echter, de USG geeft geen ip adressen uit op zowel 'buren' netwerk (v30) en het 'iot' netwerk (v50), wel op het VLAN 10 netwerk, wat de 192.168.1.x range is.

[Afbeelding]
[Afbeelding]

Ik lijk dus alles goed ingesteld hebben in de USG. Klopt dat? Nu vraag ik me af of ik nog iets in de netgear switch moet zetten om die VLANs in goede banen te leiden. Moet ik iets taggen? Of trunken?

Waar zijn deze ap’s op aangesloten?
De ap’s moeten deze vlans ook kunnen ontvangen om ze tagged te kunnen koppelen aan het geconfigureerde wifi netwerk.

[ Voor 4% gewijzigd door qwasd op 02-10-2019 17:53 ]

[KeRsTmAnNeKe]

Zo, ik weer... weer aan het rommelen.
Weet iig dat de USG wel wil routeren en gewoon werkt, WAN poort van de USG hangt aan Airport LAN en Airport WAN hangt aan modem.

Heb nu internet, maar wel met 2 routers.

Wat ik ook probeer, ik krijg vanuit Ziggo geen ip adres in de USG als ik deze rechtstreeks aan het modem hang.

[alexwel]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 18:27:
Zo, ik weer... weer aan het rommelen.
Weet iig dat de USG wel wil routeren en gewoon werkt, WAN poort van de USG hangt aan Airport LAN en Airport WAN hangt aan modem.

Heb nu internet, maar wel met 2 routers.

Wat ik ook probeer, ik krijg vanuit Ziggo geen ip adres in de USG als ik deze rechtstreeks aan het modem hang.

De ziggo modem staat in bridge-mode neem ik aan? Het kan zijn dat je hem even opnieuw moet laten starten nadat je de USG hebt aangesloten, voordat je een IP-adres krijgt.

[KeRsTmAnNeKe]

Ja dat heb ik gedaan, meerdere keren, kort, lang...
Merkte ook dat ik hem opnieuw moest starten nadat ik de Airport er steeds weer aan hing

[rinkel]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 18:38:
Ja dat heb ik gedaan, meerdere keren, kort, lang...
Merkte ook dat ik hem opnieuw moest starten nadat ik de Airport er steeds weer aan hing

In de controller heb je wel een LAN en WAN?

[JayOne]

koelkast schreef op woensdag 2 oktober 2019 @ 17:04:
Ik heb de beschikking over een USG en 2 access points. Daartussen heb ik een netgear managed switch zitten.
Nu wil ik gebruik maken van 3 verschillende subnets, per draadloos netwerk, omdat ik mijn internetaansluiting deel met anderen, én een apart Iot wlan netwerk wil hebben.

Ik heb daarom dus 3 verschillende wireless networks aangemaakt waarop ik kan connecten met draadloze apparatuur, voorzien van VLAN tags 10, 30 en 50.
Ook heb ik 3 verschillende networks aangemaakt, die ook de VLAN nummers 10, 30 en 50 hebben gekregen, dus gekoppeld met de De USG moet (dus) op 3 verschillende netwerken adressen uitdelen als DHCP server; 192.168.1.1, 192.168.3.1 en 192.168.5.1.
Echter, de USG geeft geen ip adressen uit op zowel 'buren' netwerk (v30) en het 'iot' netwerk (v50), wel op het VLAN 10 netwerk, wat de 192.168.1.x range is.

[Afbeelding]
[Afbeelding]

Ik lijk dus alles goed ingesteld hebben in de USG. Klopt dat? Nu vraag ik me af of ik nog iets in de netgear switch moet zetten om die VLANs in goede banen te leiden. Moet ik iets taggen? Of trunken?

Voor mijn IoT netwerk op VLAN108 heb ik onderstaande configuratie op de netgearswitch (VLAN -> 802.1Q -> Advanced):



Waarbij port 1 en 2 mijn AP's zijn en 5 de port naar de USG.

Zelfde doe ik voor een gastennetwerk op vlan101, verder heb ik op de usg geen vlan ingesteld.

Lees goed deze handleiding van netgear

[Annuk]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 18:27:
Zo, ik weer... weer aan het rommelen.
Weet iig dat de USG wel wil routeren en gewoon werkt, WAN poort van de USG hangt aan Airport LAN en Airport WAN hangt aan modem.

Heb nu internet, maar wel met 2 routers.

Wat ik ook probeer, ik krijg vanuit Ziggo geen ip adres in de USG als ik deze rechtstreeks aan het modem hang.

Je moet je ziggo-modem minstens 10 minuten uit laten staan (ja het is nu modem omdat ie in bridge staat).

Dan laat je je ziggo-modem volledig opstarten zonder ook maar iets aangesloten.
Dan sluit je de WAN van de USG aan op LAN1 van de Ziggo, dan zet je de USG aan en laat je volledig opstarten.
Als het goed is krijg je nu een (nieuw) WAN-IP-adres en ook direct een internet verbinding

Waarom 10 min? Mijn ervaring is dat als je het te snel doet het nog niet werkt.

P.S. als je graag je WAN-IP aanhoud bij wat ie nu is moet je even het wan-mac-adres van de Aiport clonen op de Wan van de USG.

[KeRsTmAnNeKe]

rinkel schreef op woensdag 2 oktober 2019 @ 19:10:
[...]

In de controller heb je wel een LAN en WAN?

Yup

Annuk schreef op woensdag 2 oktober 2019 @ 19:22:
[...]


Je moet je ziggo-modem minstens 10 minuten uit laten staan (ja het is nu modem omdat ie in bridge staat).

Dan laat je je ziggo-modem volledig opstarten zonder ook maar iets aangesloten.
Dan sluit je de WAN van de USG aan op LAN1 van de Ziggo, dan zet je de USG aan en laat je volledig opstarten.
Als het goed is krijg je nu een (nieuw) WAN-IP-adres en ook direct een internet verbinding

Waarom 10 min? Mijn ervaring is dat als je het te snel doet het nog niet werkt.

P.S. als je graag je WAN-IP aanhoud bij wat ie nu is moet je even het wan-mac-adres van de Aiport clonen op de Wan van de USG.

Ook geprobeerd, beide kwartier uit, stuk voor stuk opstarten... niks.

Ook net nog een belletje gedaan naar Ziggo, kon niks zien, wel iets aangepast, nog niks, konden een monteur langssturen, maar die zal kijken tot het kabeltje wat uit het modem komt en als alles gewoon werkt kost het me geld.

Situatie is dat ik nu 2 routers achter m'n modem heb, wel internet, maar die Apple moet er natuurlijk wel tussenuit, die krijgt netjes een ip vanuit Ziggo... de USG niet, al kreeg ik wel na een keer die modem herstarten 192.168.178.10 als ip, dat was ook de reden dat ik kortstondig wel de statuspagina kon zien.

[rinkel]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 20:41:
[...]


Yup


[...]


Ook geprobeerd, beide kwartier uit, stuk voor stuk opstarten... niks.

Ook net nog een belletje gedaan naar Ziggo, kon niks zien, wel iets aangepast, nog niks, konden een monteur langssturen, maar die zal kijken tot het kabeltje wat uit het modem komt en als alles gewoon werkt kost het me geld.

Situatie is dat ik nu 2 routers achter m'n modem heb, wel internet, maar die Apple moet er natuurlijk wel tussenuit, die krijgt netjes een ip vanuit Ziggo... de USG niet, al kreeg ik wel na een keer die modem herstarten 192.168.178.10 als ip, dat was ook de reden dat ik kortstondig wel de statuspagina kon zien.

Dat je die 10 als ip kreeg is natuurlijk wel erg vreemd. Dan zou dhcp nog aan staan op de ziggo-router.
Overigens kan ik ook nog gewoon bij de ziggo router komen op 192.168.178.1.
Alleen kan ik daar niks, want in bridge (kan wel even een screenshot maken als je dat wilt)

Het gekke is nu dan dat alles werkt als de USG achter de airport hangt... Dan krijgt de WAN van de USG een ip van de dhcp van de Airport. Weet je ook welk adres dit is? aan de WAN kant van de USG dus.

Je kunt overigens ook op de USG zelf komen, maar de settings daar worden altijd door de controller overschreven, maar wellicht geeft het wat inzicht.

Je zou tijdelijk nog de USG in DMZ van de Airport kunnen zetten. Maar dat is geen oplossing voor je probleem.

[nero355]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 20:41:
Ook geprobeerd, beide kwartier uit, stuk voor stuk opstarten... niks.

Doe eens een DHCP Release aan de Ziggo WAN kant voordat je de oude router weghaalt!

[alexwel]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 20:41:
[...]


Yup


[...]


Ook geprobeerd, beide kwartier uit, stuk voor stuk opstarten... niks.

Ook net nog een belletje gedaan naar Ziggo, kon niks zien, wel iets aangepast, nog niks, konden een monteur langssturen, maar die zal kijken tot het kabeltje wat uit het modem komt en als alles gewoon werkt kost het me geld.

Situatie is dat ik nu 2 routers achter m'n modem heb, wel internet, maar die Apple moet er natuurlijk wel tussenuit, die krijgt netjes een ip vanuit Ziggo... de USG niet, al kreeg ik wel na een keer die modem herstarten 192.168.178.10 als ip, dat was ook de reden dat ik kortstondig wel de statuspagina kon zien.

Ziggo heeft wat aangepast? Zou zomaar kunnen dat ze hem dan uit bridge-mode hebben gehaald, als je ook dat IP-adres krijgt.

Krijg je met de Airport nu wel het goede WAN ip-adres?

[rinkel]

alexwel schreef op woensdag 2 oktober 2019 @ 21:16:
[...]


Ziggo heeft wat aangepast? Zou zomaar kunnen dat ze hem dan uit bridge-mode hebben gehaald, als je ook dat IP-adres krijgt.

Krijg je met de Airport nu wel het goede WAN ip-adres?

Dat klinkt inderdaad als een mogelijkheid, zeker omdat dat .10 adres is uitgegeven.
Maar opzich zou het dan alsnog moeten werken.

@KeRsTmAnNeKe
Zou je eens gewoon je pc/laptop direct aan de ziggo-router kunnen hangen, benieuwd of je dan een ip-adres krijgt in de 192.168.178.x range.

[ Voor 7% gewijzigd door rinkel op 02-10-2019 21:23 ]

[KeRsTmAnNeKe]

alexwel schreef op woensdag 2 oktober 2019 @ 21:16:
[...]


Ziggo heeft wat aangepast? Zou zomaar kunnen dat ze hem dan uit bridge-mode hebben gehaald, als je ook dat IP-adres krijgt.

Krijg je met de Airport nu wel het goede WAN ip-adres?

Hij is nog steeds in bridge modus, als ik dat ip van de modem opvraag krijg ik ook gewoon de statuspagina te zien, zonder verdere settings en ook de melding dat router en wifi uit staan.

Zal eens kijken wat ik krijg als ik er een laptop aan knoop.


Laptop lijkt zelfde issue te hebben als de USG, geen ip adres krijgen, en na wat drukken krijg ik wel iets, maar compleet buiten de range die ziggo hier uitdeelt en ook onvolledig, denk eerder iets wat die mac er zelf in gooit.

Heb modem weer eens uitgezet, over 15 mins eens kijken.

Een dhcp release vanuit de airport gaat ook niet

[ Voor 23% gewijzigd door KeRsTmAnNeKe op 02-10-2019 23:04 ]

[rinkel]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 22:52:
[...]

Hij is nog steeds in bridge modus, als ik dat ip van de modem opvraag krijg ik ook gewoon de statuspagina te zien, zonder verdere settings en ook de melding dat router en wifi uit staan.

Zal eens kijken wat ik krijg als ik er een laptop aan knoop.


Laptop lijkt zelfde issue te hebben als de USG, geen ip adres krijgen, en na wat drukken krijg ik wel iets, maar compleet buiten de range die ziggo hier uitdeelt en ook onvolledig, denk eerder iets wat die mac er zelf in gooit.

Heb modem weer eens uitgezet, over 15 mins eens kijken.

Een dhcp release vanuit de airport gaat ook niet

Die staat dan duidelijk in bridge idd.
Dan moet ziggo het ip moeten uitgeven.
Een laatste vraag, en wellicht een overbodige, maar als dubbelcheck: je weet zeker dat de usg aan de WAN kant op DHCP staat?

[nero355]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 22:52:
Laptop lijkt zelfde issue te hebben als de USG, geen ip adres krijgen, en na wat drukken krijg ik wel iets, maar compleet buiten de range die ziggo hier uitdeelt en ook onvolledig, denk eerder iets wat die mac er zelf in gooit.

Hebben ze niet tegenwoordig misschien een of andere procedure waar je eerst doorheen moet

Ik kan me voorstellen dat je eerst een 10.x.x.x adres krijgt, daarna een of andere procedure moet voltooien, waarna je pas weer een normaal WAN IP krijgt


Geen idee wat Ziggo tegenwoordig doet met die nieuwste modems, maar zoiets zou ik niet gek vinden!

[elsinga]

Kan het zijn dat er sprake is van CG-NAT ivm IPv6? Dan krijg je een publiek IPv6 adres, maar een Carrier Grade NAT adres voor IPv4. Je kunt IPv6 dan via de helpdesk weer uit laten zetten.

[Crxtreem]

KeRsTmAnNeKe schreef op woensdag 2 oktober 2019 @ 22:52:
[...]

Hij is nog steeds in bridge modus, als ik dat ip van de modem opvraag krijg ik ook gewoon de statuspagina te zien, zonder verdere settings en ook de melding dat router en wifi uit staan.

Zal eens kijken wat ik krijg als ik er een laptop aan knoop.


Laptop lijkt zelfde issue te hebben als de USG, geen ip adres krijgen, en na wat drukken krijg ik wel iets, maar compleet buiten de range die ziggo hier uitdeelt en ook onvolledig, denk eerder iets wat die mac er zelf in gooit.

Heb modem weer eens uitgezet, over 15 mins eens kijken.

Een dhcp release vanuit de airport gaat ook niet

Zit de USG wel op Lan poort 1 van de Ziggo modem?
Want als ik het goed heb wordt poort 2t/m4 uitgeschakeld.
Dit omdat je het ook heb over je Airport die nog draait. (misschien zit die op poort 1 en prik je de laptop/USG op poort 2.

[KeRsTmAnNeKe]

Crxtreem schreef op donderdag 3 oktober 2019 @ 10:07:
[...]


Zit de USG wel op Lan poort 1 van de Ziggo modem?
Want als ik het goed heb wordt poort 2t/m4 uitgeschakeld.
Dit omdat je het ook heb over je Airport die nog draait. (misschien zit die op poort 1 en prik je de laptop/USG op poort 2.

Momenteel werkt het zo:

Modem poort 1 > Airport WAN > Airport poort 1 > USG WAN > USG LAN > switch + rest netwerk.

Zal dat ipv6 eens gaan navragen

[Joepla]

Iemand die hier Wifibellen (KPN in mijn geval) gebruikt icm AP AC-Lite's?

Mijn ervaring is dat het gesprek niet lekker loopt, alsof je op het randje van bereik van een GSM mast belt. Juist met Wifibellen zou je dit niet mogen ervaren. Overigens ervaart alleen de andere kant dit, zelf klinkt het bij mij prima. Men zegt vaak dat het gesprek even wegvalt.

Geen idee of het wel met de Ubiquiti-spulletjes te maken heeft, maar op andere locaties, bv. bij iemand die een Experiabox heeft met wifi actief, werkt het met mijn telefoon wel prima (internetverbindingen beiden KPN glasvezel).

Details: afstand tot AP is enkele meters, direct zicht, 5.0 Ghz kanaal, iPhone 8+. Een speedtest komt op >150 Mbps down en up, latency gemiddeld 6 ms. Laatste firmware op telefoon en AP's.

[DutchCrownNL]

Joepla schreef op donderdag 3 oktober 2019 @ 13:44:
Iemand die hier Wifibellen (KPN in mijn geval) gebruikt icm AP AC-Lite's?

Mijn ervaring is dat het gesprek niet lekker loopt, alsof je op het randje van bereik van een GSM mast belt. Juist met Wifibellen zou je dit niet mogen ervaren. Overigens ervaart alleen de andere kant dit, zelf klinkt het bij mij prima. Men zegt vaak dat het gesprek even wegvalt.

Geen idee of het wel met de Ubiquiti-spulletjes te maken heeft, maar op andere locaties, bv. bij iemand die een Experiabox heeft met wifi actief, werkt het met mijn telefoon wel prima (internetverbindingen beiden KPN glasvezel).

Details: afstand tot AP is enkele meters, direct zicht, 5.0 Ghz kanaal, iPhone 8+. Een speedtest komt op >150 Mbps down en up, latency gemiddeld 6 ms. Laatste firmware op telefoon en AP's.

Hmm nu je het zegt.. Ik hoor dit ook wel eens van de andere kant als ik thuis bel (met WiFi bellen aan).
Als ik mijn iPhone X van WiFi afhaal is het probleem opgelost, AP's (AC-Lite en AC-Pro) op laatste FW.

[Joepla]

DutchCrownNL schreef op donderdag 3 oktober 2019 @ 13:47:
[...]

Hmm nu je het zegt.. Ik hoor dit ook wel eens van de andere kant als ik thuis bel (met WiFi bellen aan).
Als ik mijn iPhone X van WiFi afhaal is het probleem opgelost, AP's (AC-Lite en AC-Pro) op laatste FW.

Exact, Wifibellen uitschakelen is tot nu toe de enige oplossing/workaround.

[bartvl]

m3gA schreef op maandag 30 september 2019 @ 16:39:
[...]

Dat was vroeger zo. Sinds +/- 1 jaar hebben ze journaling aanstaan. Tenzij je dat handmatig uitzet is de kans op corruptie nihil.

Ik ben in de markt voor een cloud key, maar twijfel heel erg aan gen1 ivm de vele corruptie problemen. Zeg jij nu dat dat tegenwoordig bijna niet het geval meer is? Ik vind het prijsverschilet de gen2 namelijk wel heel groot voor een simpel thuis netwerkje.
Zit er dan nog verschil tussen de gen1 v1/v2/v3 of is dat puur de usb micro naar usb c aansluiting?

[m3gA]

bartvl schreef op donderdag 3 oktober 2019 @ 14:04:
[...]

Ik ben in de markt voor een cloud key, maar twijfel heel erg aan gen1 ivm de vele corruptie problemen. Zeg jij nu dat dat tegenwoordig bijna niet het geval meer is? Ik vind het prijsverschilet de gen2 namelijk wel heel groot voor een simpel thuis netwerkje.
Zit er dan nog verschil tussen de gen1 v1/v2/v3 of is dat puur de usb micro naar usb c aansluiting?

Ik heb alle CK varianten gehad.
De CK1 is goed genoeg voor thuis. Hij werkt best aardig.Gevalletje goed is goed genoeg.
De CK2 heeft een veel betere processor en is heel snel. Hij heeft ook kleine batterij om stroomuitval op te vangen.
De CK2 plus heeft nog 1GB extra geheugen (wordt gebruikt voor protect, de NVR) en een 500GB hd.

Alle cloud keys kun je voorzien van een SD kaart voor backups.

[ Voor 5% gewijzigd door m3gA op 03-10-2019 14:14 ]

[Kavaa]

m3gA schreef op donderdag 3 oktober 2019 @ 14:13:
[...]

Ik heb alle CK varianten gehad.
De CK1 is goed genoeg voor thuis. Hij werkt best aardig.Gevalletje goed is goed genoeg.
De CK2 heeft een veel betere processor en is heel snel. Hij heeft ook kleine batterij om stroomuitval op te vangen.
De CK2 plus heeft nog 1GB extra geheugen (wordt gebruikt voor protect, de NVR) en een 500GB hd.

Alle cloud keys kun je voorzien van een SD kaart voor backups.

1TB HDD Opslag voor UniFi Protect Beelden :-D Uitbreidbaar tot 5TB 2.5inch HDD

[Getto]

Vandaag is mijn zwager geland met in zijn koffer een Ubiquiti Dreammachine. Vanavond even flink mee spelen.
Zijn er nog mensen geïnteresseerd in een aantal zaken die ik even moet proberen?

[ Voor 18% gewijzigd door Getto op 03-10-2019 14:17 ]

[m3gA]

Kavaa schreef op donderdag 3 oktober 2019 @ 14:15:
[...]


1TB HDD Opslag voor UniFi Protect Beelden :-D Uitbreidbaar tot 5TB 2.5inch HDD

Ahja klopt. Heb hem maar even gehad dus wist het niet meer zeker.

[bartvl]

m3gA schreef op donderdag 3 oktober 2019 @ 14:13:
[...]

Ik heb alle CK varianten gehad.
De CK1 is goed genoeg voor thuis. Hij werkt best aardig.Gevalletje goed is goed genoeg.
De CK2 heeft een veel betere processor en is heel snel. Hij heeft ook kleine batterij om stroomuitval op te vangen.
De CK2 plus heeft nog 1GB extra geheugen (wordt gebruikt voor protect, de NVR) en een 500GB hd.

Alle cloud keys kun je voorzien van een SD kaart voor backups.

Dat klinkt goed! Maar houdt dat dus in dat de CK1 inmiddels nagenoeg geen problemen meer heeft met crashende databases? Ik wil namelijk niet al te veel hoeven hobbyen (buiten de instellingen van de USG en AP's dan ) en ben helemaal niet bekend met termen als SSH enz.

[m3gA]

bartvl schreef op donderdag 3 oktober 2019 @ 14:40:
[...]

Dat klinkt goed! Maar houdt dat dus in dat de CK1 inmiddels nagenoeg geen problemen meer heeft met crashende databases? Ik wil namelijk niet al te veel hoeven hobbyen (buiten de instellingen van de USG en AP's dan ) en ben helemaal niet bekend met termen als SSH enz.

In theorie niet. je weet maar nooit. Zet voor de zekerheid een SD kaartje erin en als er iets mis gaat is recoveren een paar minuten werk.

[ardvark99]

Joepla schreef op donderdag 3 oktober 2019 @ 13:44:
Iemand die hier Wifibellen (KPN in mijn geval) gebruikt icm AP AC-Lite's?

Mijn ervaring is dat het gesprek niet lekker loopt, alsof je op het randje van bereik van een GSM mast belt. Juist met Wifibellen zou je dit niet mogen ervaren. Overigens ervaart alleen de andere kant dit, zelf klinkt het bij mij prima. Men zegt vaak dat het gesprek even wegvalt.

Geen idee of het wel met de Ubiquiti-spulletjes te maken heeft, maar op andere locaties, bv. bij iemand die een Experiabox heeft met wifi actief, werkt het met mijn telefoon wel prima (internetverbindingen beiden KPN glasvezel).

Details: afstand tot AP is enkele meters, direct zicht, 5.0 Ghz kanaal, iPhone 8+. Een speedtest komt op >150 Mbps down en up, latency gemiddeld 6 ms. Laatste firmware op telefoon en AP's.

Dit heeft niets met Ubiquiti te maken, is probleem of iPhone, of kpn. Ik bel regelmatig met een klant die het aan het staan op zijn iPhone, af en toe lijkt het of ie in een ton maar dan verweg zit. Galmt en verformt behoorlijk. Maakt niet uit of ie thuis of op het werk zit.hij heeft geen Ubiquiti.

[Joepla]

ardvark99 schreef op donderdag 3 oktober 2019 @ 15:24:
[...]
Dit heeft niets met Ubiquiti te maken, is probleem of iPhone, of kpn. Ik bel regelmatig met een klant die het aan het staan op zijn iPhone, af en toe lijkt het of ie in een ton maar dan verweg zit. Galmt en verformt behoorlijk. Maakt niet uit of ie thuis of op het werk zit.hij heeft geen Ubiquiti.

Ok... kan er verder niets over vinden. Je zou verwachten dat als het een typisch iPhone-probleem is, je heel veel klachten zou zien.

[Louw Post]

Joepla schreef op donderdag 3 oktober 2019 @ 16:14:
[...]

Ok... kan er verder niets over vinden. Je zou verwachten dat als het een typisch iPhone-probleem is, je heel veel klachten zou zien.

Nou bel ik niet heel vaak, maar de keren dat ik via wifi gebeld heb via mijn AP AC Lites icm Vodafone heb ik niks raars gemerkt in mijn gesprekken. Lijkt gewoon prima te werken in mijn geval.