[Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 2

[stormfly]

burne schreef op donderdag 4 januari 2018 @ 13:09:
[...]
Met het vinkje aan luistert je EdgeRouter of USG naar 224.0.0.251 en beantwoord daar wat 'ie weet.

Klopt maar alleen tussen twee of meer (vlan) interfaces, zie ook de uitleg van Robert hieronder. Op een plat vlan waar ook een Ziggo modem actief is, heeft een mDNS router instelling geen nut. Ook als je de Ziggo modem vervangt door een USG en je blijft bij 1 plat IP subnet en VLAN, gaat dit vinkje je niet helpen. Omdat in hetzelfde VLAN iedereen elkaars MultiCast verkeer al kan zien en terug kan praten.

RobertMe schreef op donderdag 4 januari 2018 @ 13:56:
[...]

Volgensmij heeft mDNS juist niks met nameservers te maken. Maar i.p.v. dat je zoals gewoon bij DNS een query naar de server stuurt, wordt bij mDNS de query naar een broadcast adres gestuurd, waardoor elke apparaat afzonderlijk een (eigen) reply geeft op de query. Daarnaast kunnen apparaten ook zelf een broadcast doen dat er iets beschikbaar is gekomen, waardoor je in principe niet continu queries hoeft te sturen, maar automatisch binnen komt dat er iets is "aangemeld".

Alleen blokkeert de router dus dat broadcast verkeer, omdat broadcasts natuurlijk niet over netwerken/subnets/VLANs heen gaan. Wat vervolgens dat mDNS "vinkje" in de Controller doet is een reflector installeren en uitvoeren die op alle interfaces luistert, en alle mDNS berichten herhaald over de andere interfaces.

Typo *broadcast = multicast, je verhaal klopt verder helemaal

[nero355]

Kanarie schreef op donderdag 4 januari 2018 @ 12:21:
De Edgerouter X heeft een snellere SoC (2c/4t 880Mhz), kan hardware offloaden tegenwoordig, heeft een echte switch en niet de NVRAM problemen van de ER-Lite. Voor mijn use case is het een straight upgrade over de verouderde ER-Lite die (te) zwaar leunt op hardware offloading waar ook nog eens bugs inzitten.

Dat is nieuwe info voor mij : Ik dacht altijd dat van de drie meest voorkomende opties de EdgeRouter X altijd de minste was ?!

1. EdgeRouter Lite
2. USG
3. EdgeRouter X

Is er dan een hardware revisie geweest ondertussen of zo

[Jeroen]

Hey allemaal, ik overweeg een UniFi ap en misschien kan iemand mij adviseren voor mijn specifieke situatie. Ik wil door muren heen wifi in een ruimte krijgen waar dat eigenlijk maar moeilijk gaat. Het is alleen 100% onmogelijk om te bekabelen, dus dan maar kijken of het met een fatsoenlijke upgrade van de apparatuur toch lukt.

Ik heb 2 ruimtes met een gang van 1 meter breed er tussen. Op dit moment staat in de ene ruimte een netgear wndr3700 (zo dicht mogelijk bij) en aan de andere kant een netgear EX6150, waarmee ik dan via de kabel weer verbinding maak. Toch valt de verbinding tussen die twee sporadisch weg. Verder werkt de router binnen de ruimte waar hij staat altijd perfect.

Ik wil de AP van de router uitzetten en een andere AP aansluiten. Het gaat dus niet per se om een grote 'afstand', maar de AP moet wel hard aan de bak om de verbinding te maken. Helpt het hierbij, voor deze ene moeilijke client, als de AP meer antennes heeft, of heeft dat alleen invloed op de hoeveelheid clients de AP fatsoenlijk aan kan? In mijn ervaring komt overigens het 2.4 GHz signaal meestal door maar het 5GHz signaal bijna nooit, dus het lijkt me alleen van belang wat de 2.4GHz antennes doen, of niet?

Wat me ook opvalt is dat de LR versie een langer bereik lijkt te hebben dan de Pro. Hoe komt dat? Zijn daarbij de antennes anders geconfigureerd om dat te bereiken? En heeft dat dan ook voordelen voor mijn geval waarbij hij gewoon door 1.5m en 2 muren moet stralen?

[RobertMe]

Jeroen schreef op donderdag 4 januari 2018 @ 20:49:
Hey allemaal, ik overweeg een UniFi ap en misschien kan iemand mij adviseren voor mijn specifieke situatie. Ik wil door muren heen wifi in een ruimte krijgen waar dat eigenlijk maar moeilijk gaat. Het is alleen 100% onmogelijk om te bekabelen, dus dan maar kijken of het met een fatsoenlijke upgrade van de apparatuur toch lukt.

Ik heb 2 ruimtes met een gang van 1 meter breed er tussen. Op dit moment staat in de ene ruimte een netgear wndr3700 (zo dicht mogelijk bij) en aan de andere kant een netgear EX6150, waarmee ik dan via de kabel weer verbinding maak. Toch valt de verbinding tussen die twee sporadisch weg. Verder werkt de router binnen de ruimte waar hij staat altijd perfect.

Ik wil de AP van de router uitzetten en een andere AP aansluiten. Het gaat dus niet per se om een grote 'afstand', maar de AP moet wel hard aan de bak om de verbinding te maken. Helpt het hierbij, voor deze ene moeilijke client, als de AP meer antennes heeft, of heeft dat alleen invloed op de hoeveelheid clients de AP fatsoenlijk aan kan? In mijn ervaring komt overigens het 2.4 GHz signaal meestal door maar het 5GHz signaal bijna nooit, dus het lijkt me alleen van belang wat de 2.4GHz antennes doen, of niet?

Wat me ook opvalt is dat de LR versie een langer bereik lijkt te hebben dan de Pro. Hoe komt dat? Zijn daarbij de antennes anders geconfigureerd om dat te bereiken? En heeft dat dan ook voordelen voor mijn geval waarbij hij gewoon door 1.5m en 2 muren moet stralen?

Inhoudelijk kan ik niet echt reageren* (na alle Lite vs LR vs Pro discussies hier weet ik ook niet meer welke een beter bereik geeft ). Maar houdt er wel rekening mee dat het probleem niet perse (alleen) je hoofd router hoeft te zijn. Voor hetzelfde geldt komt het signaal daarvan wel goed aan aan 'de overkant' maar zend die andere router te zwak terug waardoor je hoofd router het niet meer 'hoort'. Mogelijk dat je zoiets kunt onderzoeken met bv de Wifi Analyzer app door te kijken wat de signaalsterktes van beide APs zijn aan de overkant.

Wat wellicht ook nog interessant is. Zijn de muren helemaal dicht? Volgens mij doet wifi allemaal slimme dingen met weerkaatsing en zo. Dus mogelijk dat een andere plek (verder van muur? Dichter bij een deur?) een beter signaal geeft.

* De theorie is in ieder geval dat de LR een beter antenne ontwerp heeft wat tot een beter signaal zou moeten leiden. Maar tegelijkertijd zou het ook zo zijn dat een LR breder straalt en zo een grotere afstand kan afleggen, maar dan wel in semi open ruimtes (bv een fabriekshal), maar dat de LR niet perse beter met storing om gaat.

[nero355]

Jeroen schreef op donderdag 4 januari 2018 @ 20:49:
Wat me ook opvalt is dat de LR versie een langer bereik lijkt te hebben dan de Pro. Hoe komt dat? Zijn daarbij de antennes anders geconfigureerd om dat te bereiken? En heeft dat dan ook voordelen voor mijn geval waarbij hij gewoon door 1.5m en 2 muren moet stralen?

De LR modellen schijnen wat gevoeligere antennes te hebben, maar anderen beweren weer dat een normale non-LR UAP ook gewoon voldoet.

Je zou twee dingen kunnen doen :
- 2x een UAP die je via Wireless Uplink met elkaar verbindt.
- De MESH kant op gaan en kijken of je het daarmee voor elkaar krijgt

[Jeroen]

De EX6150 is nieuw en ondersteunt in ieder geval AC, maar de WNDR3700 nog niet. Ik ging er dus voor het gemak nog maar even vanuit dat als ik die nog upgrade dat het dan in ieder geval wat beter gaat, omdat de router kant inderdaad misschien de andere kant niet goed ontvangt.

Aangezien de Pro en de LR wel evenveel 2.4GHz antennes hebben lijkt me de LR dan de beste keuze met zijn 'gevoelige' antennes. Ik overweeg om het gewoon te proberen, het kan altijd terug naar de winkel als het nog niet goed blijft werken.

[ Voor 30% gewijzigd door Jeroen op 04-01-2018 21:14 ]

[RobertMe]

nero355 schreef op donderdag 4 januari 2018 @ 21:07:
- 2x een UAP die je via Wireless Uplink met elkaar verbindt.

Ik meen mij te herinneren dat de wireless uplink alleen via 5GHz werkt, en als ik het goed begrijp heeft hij daarop helemaal geen bereik, dus dat gaat niet werken.

Maar de huidige setup zal waarschijnlijk ook werken met 1 UniFi AP en een ander merk. De tweede router koppelt zichzelf als cliënt en zal daar waarschijnlijk intern een WAN op plakken en dus (dubbel) NAT toepassen. (Met 'standaard wifi' kun je ook een wireless bridge opzetten, maar dat is nogal picky en werkt meestal alleen goed als beide kanten dezelfde wifi chip hebben en dan bij voorkeur ook nog eens dezelfde software draaien).

[RobertMe]

Jeroen schreef op donderdag 4 januari 2018 @ 21:12:
Aangezien de Pro en de LR wel evenveel 2.4GHz antennes hebben lijkt me de LR dan de beste keuze met zijn 'gevoelige' antennes.

But then again, de Pro heeft ook 3 5GHz antennes, en wat ik van andere topics begreep zou dat (mogelijk) ingezet kunnen worden voor een beter signaal. Als de andere router bv maar 2 antennes heeft heeft de UAP Pro er 1 over die in principe niks aan snelheid kan doen, maar wel gebruikt kan worden om de signaalsterkte bij ontvangst te verbeteren (nu ik er zo over denk gok ik dat het idee hetzelfde is als een extra microfoon op bv een telefoon om het achtergrondgeluid wat de hoofdmicrofoon oppakt wat te onderdrukken)

[nero355]

RobertMe schreef op donderdag 4 januari 2018 @ 21:15:
Ik meen mij te herinneren dat de wireless uplink alleen via 5GHz werkt, en als ik het goed begrijp heeft hij daarop helemaal geen bereik, dus dat gaat niet werken.

https://help.ubnt.com/hc/...-wireless-uplink-topology
&
https://help.ubnt.com/hc/...ure-Guide-Wireless-Uplink

Zeggen dat het ook op 2.4GHz kan met de juiste UAP's

Maar de huidige setup zal waarschijnlijk ook werken met 1 UniFi AP en een ander merk. De tweede router koppelt zichzelf als cliënt en zal daar waarschijnlijk intern een WAN op plakken en dus (dubbel) NAT toepassen. (Met 'standaard wifi' kun je ook een wireless bridge opzetten, maar dat is nogal picky en werkt meestal alleen goed als beide kanten dezelfde wifi chip hebben en dan bij voorkeur ook nog eens dezelfde software draaien).

Geen dubbele NAT : Gewoon als Client van het hele netwerk dan

Al zou ik het niet aanraden mocht iemand het gaan proberen met Fritz!Box WiFi Routers

[Jeroen]

Ik weet niet 100% zeker of hij gebruik maakt van dubbel NAT of een ander trucje, hij moet immers meerdere apparaten vertegenwoordigen op het wlan. Maar in ieder geval werkt het prima voor de chromecast als hij maar verbinding heeft. Wireless Uplink ziet er nog veel cooler uit, maar ik was nog even niet echt van plan om 2 APs hiervoor te kopen.

[gastje01]

Kan iemand me hier vertellen hoe ik meer informatie over mijn VPN gebruik inzichtelijk krijg?
Heb L2TP ingesteld op mijn USG met de ingebouwde Radius server, dit werkt perfect. In het dashboard zie ik ook hoeveel tunnels er op dit moment actief zijn, idem voor insights->remote user VPN, maar daar stopt het feest ook. Kan ik ergens logs inzien? Wat ik graag wil zien nadat een sessie beëindigd is:
- Tijdstippen en verbindingsduur
- Totale data gebruik per sessie

DPI per sessie/gebruiker zou leuk zijn, maar daar kan ik al helemaal niks over vinden. Ik zie wel dat het datagebruik en DPI stats wel meetellen voor het totaal. Ik gebruik de laatste stable versie van de controller.

[Verwijderd]

nero355 schreef op donderdag 4 januari 2018 @ 18:04:
[...]

Dat is nieuwe info voor mij : Ik dacht altijd dat van de drie meest voorkomende opties de EdgeRouter X altijd de minste was ?!

1. EdgeRouter Lite
2. USG
3. EdgeRouter X

Is er dan een hardware revisie geweest ondertussen of zo

USG is een EdgeRouter Lite in een andere behuizing en aangestuurd duur een controller. Hardwarematig zijn ze exact gelijk en presteren en kunnen dan ook dan ook exact hetzelfde.

Vind persoonlijk nu niet echt dat je de ERX tegenover de ERL kan zetten, beide zijn bedoeld voor totaal verschillende doeleinden.
ERX heeft hetzelfde probleem als de ERL, prestaties gaan echt zeer zwaar achteruit als je een service gebruikt die de offloading disabled. Bij de ERX wellicht iets minder door de snellere SOC maar nog steeds een zeer zware performance drop.

Met de switch on chip design van de ERX vind ik deze persoonlijk beter/dichter te vergelijken met een ERPoe-5. Ik kan echter de ERX niet zien als een echte upgrade voor de ERL en/of ERPoe-5. Ze hebben allemaal hun eigen user case waarin ze uitblinken maar een echte upgrade voor de huidige lineup zie ik in de nieuwe ER-4 en ER-6 en niet onderling tussen de ERL, ERX en ERPoe-5.

[Tomsworld]

Iemand al enig idee wanneer de ER-4 en ER-6 vlot verkrijgbaar gaan zijn ?

[m3gA]

Tomsworld schreef op vrijdag 5 januari 2018 @ 13:22:
Iemand al enig idee wanneer de ER-4 en ER-6 vlot verkrijgbaar gaan zijn ?

Misschien dat @djkavaa je hier mee kan helpen?

[Kavaa]

Tomsworld schreef op vrijdag 5 januari 2018 @ 13:22:
Iemand al enig idee wanneer de ER-4 en ER-6 vlot verkrijgbaar gaan zijn ?

Gaat nog wel even duren.
Zodra ik ze heb / kan krijgen zal ik het zeker laten weten!

En ik heb er voor mezelf al 5 in bestelling staan die ik moet gaan inzetten.

Edit:

Heb zojuist nog eens contact opgenomen met Distri... En wellicht over een maand de ER-4 maar de ER-6 is nog niets over bekend en ook nog niet onderweg naar NL

[ Voor 19% gewijzigd door Kavaa op 05-01-2018 15:19 ]

[zeroday]

gastje01 schreef op donderdag 4 januari 2018 @ 23:47:
Kan iemand me hier vertellen hoe ik meer informatie over mijn VPN gebruik inzichtelijk krijg?
Heb L2TP ingesteld op mijn USG met de ingebouwde Radius server, dit werkt perfect. In het dashboard zie ik ook hoeveel tunnels er op dit moment actief zijn, idem voor insights->remote user VPN, maar daar stopt het feest ook. Kan ik ergens logs inzien? Wat ik graag wil zien nadat een sessie beëindigd is:
- Tijdstippen en verbindingsduur
- Totale data gebruik per sessie

DPI per sessie/gebruiker zou leuk zijn, maar daar kan ik al helemaal niks over vinden. Ik zie wel dat het datagebruik en DPI stats wel meetellen voor het totaal. Ik gebruik de laatste stable versie van de controller.

tsja dat zou ik ook wel willen, zelfs via SNMP verdwijnt de info nadat de verbinding gestopt is.. tsja ook niet handig.

[Tomsworld]

djkavaa schreef op vrijdag 5 januari 2018 @ 14:44:
[...]


Gaat nog wel even duren.
Zodra ik ze heb / kan krijgen zal ik het zeker laten weten!

En ik heb er voor mezelf al 5 in bestelling staan die ik moet gaan inzetten.

Edit:

Heb zojuist nog eens contact opgenomen met Distri... En wellicht over een maand de ER-4 maar de ER-6 is nog niets over bekend en ook nog niet onderweg naar NL

Ok ik ben gewoon een beetje aan het overwegen, het lijkt me op basis van die nieuwe soc dat de ipsec performantie stukken beter moet zijn dan de ERLITE / ER8 / ER8PRO

[Kavaa]

Tomsworld schreef op vrijdag 5 januari 2018 @ 15:30:
[...]


Ok ik ben gewoon een beetje aan het overwegen, het lijkt me op basis van die nieuwe soc dat de ipsec performantie stukken beter moet zijn dan de ERLITE / ER8 / ER8PRO

Dat klopt vandaar dat ik er ook met smacht op zit te wachten ik heb nogal wat tunneltjes lopen namelijk...

[MvL]

Ik probeer mijn Cloudkey (firmware) te updaten, maar om één of andere reden lukt dit niet. Ik heb het via de Cloudkey config geprobeerd, en de controller software. De firmware wordt wel gedownload. Ook zie ik een venster met iets van installing firmware dan reboot de cloudkey. Na het inloggen heb ik weer de oude versie (v08.2). Ook nog de Chrome browser geprobeerd. Ik heb wel eens begrepen dat andere browsers officieel niet worden ondersteund. Meer mensen met deze problemen?

[Speedboot]

Jouhki schreef op vrijdag 5 januari 2018 @ 12:40


Met de switch on chip design van de ERX vind ik deze persoonlijk beter/dichter te vergelijken met een ERPoe-5. Ik kan echter de ERX niet zien als een echte upgrade voor de ERL en/of ERPoe-5. Ze hebben allemaal hun eigen user case waarin ze uitblinken maar een echte upgrade voor de huidige lineup zie ik in de nieuwe ER-4 en ER-6 en niet onderling tussen de ERL, ERX en ERPoe-5.

Voor mijn huidige idee, om de Ziggo Connectbox te bridgen en deze te vervangen voor de Edgerouter X lijkt me deze zeer geschikt.
Om nu 200 euro voor een thuis gebruik router uit te geven lijkt me niet zinvol, in mijn geval

[tozzke]

MvL schreef op vrijdag 5 januari 2018 @ 16:58:
Ik probeer mijn Cloudkey (firmware) te updaten, maar om één of andere reden lukt dit niet. Ik heb het via de Cloudkey config geprobeerd, en de controller software. De firmware wordt wel gedownload. Ook zie ik een venster met iets van installing firmware dan reboot de cloudkey. Na het inloggen heb ik weer de oude versie (v08.2). Ook nog de Chrome browser geprobeerd. Ik heb wel eens begrepen dat andere browsers officieel niet worden ondersteund. Meer mensen met deze problemen?

Probeer eerst eens je controller versie te updaten en daarna pas de firmware.
Ik zat hier de laatste keer ook mee en op deze manier werkte het wel

[MvL]

tozzke schreef op vrijdag 5 januari 2018 @ 17:09:
[...]

Probeer eerst eens je controller versie te updaten en daarna pas de firmware.
Ik zat hier de laatste keer ook mee en op deze manier werkte het wel

Top man! Het is gelukt. Inderdaad eerst de controller software ge-update, en met wat heen en weer geklik tussen cloudkey config, en controller software is het gelukt om de firmware te updaten. Bedankt voor de tip.

[Verwijderd]

Speedboot schreef op vrijdag 5 januari 2018 @ 16:58:
[...]


Voor mijn huidige idee, om de Ziggo Connectbox te bridgen en deze te vervangen voor de Edgerouter X lijkt me deze zeer geschikt.
Om nu 200 euro voor een thuis gebruik router uit te geven lijkt me niet zinvol, in mijn geval

Of het zinvol is kan ik niet over oordelen daar ik niet weet hoe jouw netwerk er thuis uitziet. Maar in heel veel gevallen is het inderdaad niet zinvol om 200 euro uit te geven aan een router voor een "simpel" thuis netwerk.

(Die 300 euro kostende "gaming" routers zijn pure marketing onzin imho)

De ERX is zeer goed geschikt om te gebruiken in een thuis situatie.
De ER-4 en/of ER-6 zijn nu niet echt de versies waar ik aan denk bij een simpel thuis netwerk.

ps.
Heb nu een beetje zitten porren bij Duitse distri en die verwachten de ER-4 met een maand te kunnen leveren. ER-6 is vanuit Ubiquiti nog niks officieel naar buiten gebracht en alle levertijden daarvoor zijn dus puur speculatief.

[nero355]

Speedboot schreef op vrijdag 5 januari 2018 @ 16:58:
Voor mijn huidige idee, om de Ziggo Connectbox te bridgen en deze te vervangen voor de Edgerouter X lijkt me deze zeer geschikt.
Om nu 200 euro voor een thuis gebruik router uit te geven lijkt me niet zinvol, in mijn geval

Omdat ik vast zit aan xDSL heb ik tot nu toe elke keer een DrayTek moeten kopen tussen de € 180 - 220 dus het is maar net wat je nodig hebt in jouw situatie en soms kost dat helaas net wat meer

[Hammetje]

Zojuist UNMS geinstalleerd op mijn VPS van digital ocean, daar draai ik ook al de UNIFI controller. Was wel een behoorlijk gedoe, op Ununtu 15.10 kreeg ik het niet aan de praat. Uiteindelijk geupgrade naar 16.04, daarna verliep de installatie zeer soepel.

Ondanks dat Ubiquiti vrij zware specs noemen voor UNMS, lijken deze bij gebruik van DigitalOcean wat schappelijker: https://github.com/Ubiqui...wiki/UNMS-on-DigitalOcean
Concreet; voor zover ik kan zien de helft van de eisen die zij officieel stellen wanneer je aan de slag gaat met UNMS. Bij mij reageert de interface van zowel UniFi als UNMS lekker vlot op de droplet van $10,- per maand.

Mocht je aan de slag gaan met UNMS en je wilt gebruik maken van CloudVPS, staar je dan niet direct blind op die dual core CPU en 2GB RAM die officieel benodigd zijn.

[Madshark]

Even een vraag voor de mensen die een Unifi USG in combinatie met een Unifi Switch op KPN glasvezel hebben werken.

Onlangs bij een kennis zijn Experiabox uit zijn netwerk gebonjourd en hiervoor in plaats een USG met Unifi switch in gebruik genomen. Alle config gewoon via de UI kunnen doen, geen custom scripts nodig gehad.

NTU zit rechtstreeks op de switch, switch trekt vervolgens VLAN 4 en 6 uit elkaar, waar VLAN4 untagged naar de IPTV poorten gaat, en VLAN6 untagged naar USG die vervolgens weer de LAN kant terug geeft aan de switch als default VLAN1.

Op zich werkt alles prima, IPTV, opnemen, on-demand en natuurlijk snel en stabiel internet.
Echter na een paar dagen werkt Netflix niet meer op de IPTV kastjes. (wellicht al vanaf start, maar toen nog niet opgevallen)
Hebben die IPTV kastjes dan ook nog je interne lan nodig ? Zoja, welke VLAN moet ik dan untagged aanbieden ?

[xh3adshotx]

Madshark schreef op vrijdag 5 januari 2018 @ 20:54:
Even een vraag voor de mensen die een Unifi USG in combinatie met een Unifi Switch op KPN glasvezel hebben werken.

Onlangs bij een kennis zijn Experiabox uit zijn netwerk gebonjourd en hiervoor in plaats een USG met Unifi switch in gebruik genomen. Alle config gewoon via de UI kunnen doen, geen custom scripts nodig gehad.

NTU zit rechtstreeks op de switch, switch trekt vervolgens VLAN 4 en 6 uit elkaar, waar VLAN4 untagged naar de IPTV poorten gaat, en VLAN6 untagged naar USG die vervolgens weer de LAN kant terug geeft aan de switch als default VLAN1.

Op zich werkt alles prima, IPTV, opnemen, on-demand en natuurlijk snel en stabiel internet.
Echter na een paar dagen werkt Netflix niet meer op de IPTV kastjes. (wellicht al vanaf start, maar toen nog niet opgevallen)
Hebben die IPTV kastjes dan ook nog je interne lan nodig ? Zoja, welke VLAN moet ik dan untagged aanbieden ?

Ja, je IPTV kastjes hebben dan internet nodig. Je kan niet simpelweg een apart VLAN untagged aanbieden je moet kijken naar routed IPTV. Meerdere posts over te vinden in dit topic.

[stormfly]

RobertMe schreef op donderdag 4 januari 2018 @ 21:20:
[...]

But then again, de Pro heeft ook 3 5GHz antennes, en wat ik van andere topics begreep zou dat (mogelijk) ingezet kunnen worden voor een beter signaal. Als de andere router bv maar 2 antennes heeft heeft de UAP Pro er 1 over die in principe niks aan snelheid kan doen, maar wel gebruikt kan worden om de signaalsterkte bij ontvangst te verbeteren (nu ik er zo over denk gok ik dat het idee hetzelfde is als een extra microfoon op bv een telefoon om het achtergrondgeluid wat de hoofdmicrofoon oppakt wat te onderdrukken)

Klopt helemaal, als oud zendamateur (en ik ben nog geen 40 ;-) zal ik wat achtergrond schetsen. Meerdere ontvangers geven het voordeel van " ontvanger diversity Wikipedia: Antenna diversity

Antenna diversity is especially effective at mitigating these multipath situations. This is because multiple antennas offer a receiver several observations of the same signal. Each antenna will experience a different interference environment. Thus, if one antenna is experiencing a deep fade, it is likely that another has a sufficient signal. Collectively such a system can provide a robust link.

Een ander aspect is antenna gain, hoe meer dBi de antenne versterkt (vaak bepaald door lengte, langer = meer dBi) hoe beter het signaal opgepakt kan worden. Daarbij spelen de antennes van de LR weer in het voordeel tov een LITE. De SHD van UniFi is de absolute antenne topper met een antenna array van 6 en 8 dBi gain.

Met het beeld wat ik heb van de techniek, denk ik dat beide factoren van positieve invloed kunnen zijn.

[stormfly]

nero355 schreef op donderdag 4 januari 2018 @ 21:21:
[...]

https://help.ubnt.com/hc/...-wireless-uplink-topology
&
https://help.ubnt.com/hc/...ure-Guide-Wireless-Uplink

Zeggen dat het ook op 2.4GHz kan met de juiste UAP's

We intepreteren het beide anders. Ze zeggen toch dat het alleen kan functioneren op 2.4Ghz met oude single-band only devices? Volgens mij is het recent gelanceerde Mesh v3 protocol helemaal 5Ghz.

Overigens zit in 5.7.12 een set aan nieuwe opties voor Mesh (feitelijk Wireless Uplinking). Het is nu gelukkig geen site global optie, maar een device local optie. Waardoor je veel selectiever je mesh netwerk kunt designer en beter kan wat er gaat gebeuren als een unit een upgrade krijgt. Vaak viel dan je hele optimale pad in duigen omdat iedere mesh unit zelf een nieuw pad ging zoeken. Omdat iedere AP immers Mesh-ready geconfigureerd was door de site global optie.

Een andere optie die ik zelf voorgesteld heb, en hiermee denk ik samen hangt (ik draai op dit moment geen 5.7.12). Is de isolated mode detectie. Omdat mesh een site global parameter was, ging elke AP de gateway pingen. Als je dan je ISP router of USG een upgrade gaf. Vielen al je AP's uit de productie modus terug naar isolated modus, zelfs de bedrade varianten. Hiermee viel dan je LAN RDP sessie naar je LAB server in de meterkast weg, terwijl je een WAN upgrade uitvoerde.

[vonkkie]

Sinds de firmware update voor de unifi ap pro en de 8-60 switch van gisteren
kan mijn vrouw hayday niet meer via wifi spelen
Voor de rest heb ik zelf niets gewijzigd
Heeft iemand een idee hoe dit mogelijk is
Unifi 5.7 .12
Ap wn switch firmware 3.9.19.8123

[rally]

Heb je al geprobeerd om de firmware terug te zetten en kijken of het dan weer werkt?

[vonkkie]

Vreemde vraag misschien maar hou doe je dat ??

rally schreef op zaterdag 6 januari 2018 @ 08:45:
Heb je al geprobeerd om de firmware terug te zetten en kijken of het dan weer werkt?

[RobertMe]

vonkkie schreef op zaterdag 6 januari 2018 @ 09:06:
Vreemde vraag misschien maar hou doe je dat ??


[...]

Link opzoeken naar de download van de oude versie (bv via blog), en dan in de controller device openen, Config => Manage device => Custom upgrade, daar de link plakken en dan Custom upgrade. Maar let wel op dat je de juiste versie, voor het juiste AP/switch pakt. (Ik heb geen idee of/hoe goed de hardware zelf controleert of de firmware voor die hardware is)

[Shaggie_NB]

vonkkie schreef op zaterdag 6 januari 2018 @ 07:42:
Sinds de firmware update voor de unifi ap pro en de 8-60 switch van gisteren
kan mijn vrouw hayday niet meer via wifi spelen
Voor de rest heb ik zelf niets gewijzigd
Heeft iemand een idee hoe dit mogelijk is
Unifi 5.7 .12
Ap wn switch firmware 3.9.19.8123

Heb je eerst de firmware 3.9.19.8123 voor je ap's geinstalleerd voordat je naar 5.7.12 ging?

[vonkkie]

Jep

Shaggie_NB schreef op zaterdag 6 januari 2018 @ 10:52:
[...]

Heb je eerst de firmware 3.9.19.8123 voor je ap's geinstalleerd voordat je naar 5.7.12 ging?

[Shaggie_NB]

vonkkie schreef op zaterdag 6 januari 2018 @ 11:54:
Jep
[...]

Dan zou ik zowel voor de controller software als de AP firmware naar een oudere versie gaan...

[vonkkie]

heb de usg 3p opnieuw opgestart en het werkt weer vaag

maar ja vrouw blij ik blij
thx voor het mee denken

[Ferruginous Hwk]

Met de opkomst van IOT en hun veelal gebrekkige beveiliging, gasten die gebruik willen maken van wifi en in de nabije toekomst een cciv-oplossing zit ik te denken aan een nieuwe netwerk setup.
Daarbij wil ik gebruik gaan maken van ubuiquiti apparatuur zoals de USG, wat POE+ switches en een Access-point (PRO HD).

Nu zit ik te denken aan de volgende indeling.

1. intern netwerk (bekabeld en wifi (eigen SSID))
2. CCTV netwerk (bekabeld en wifi (eigen SSID))
3. IOT-netwerk (bekabeld en wifi (eigen SSID))
4. gasten netwerk (vooral Wifi (eigen SSID))

Het interne netwerk bevat o.a. een NAS
Ik wil dat de camera's naar mijn NAS kunnen schrijven maar andersom mag het interne netwerk niet naar mijn camera's (tenzij ik fysiek inplug in dat specifieke VLAN op de switch)
Het IOT-netwerk mag niet naar het interne netwerk behalve rule-based lezen vanaf een bepaalde share op mijn NAS (voor muziek, e.d.)
Gasten-netwerk mag alleen het internet op en nergens anders bij.

Dit zou moeten lukken met de producten volgens mij.
Heeft iemand van jullie ervaring met een dergelijke setup? Wat zijn jullie ervaringen? Mocht het niet kunnen met deze apparatuur hoor ik het natuurlijk ook graag want deze setup kost ongeveer 800 euro.

[RobertMe]

ReVolpe schreef op zaterdag 6 januari 2018 @ 12:31:
Dit zou moeten lukken met de producten volgens mij.
Heeft iemand van jullie ervaring met een dergelijke setup? Wat zijn jullie ervaringen? Mocht het niet kunnen met deze apparatuur hoor ik het natuurlijk ook graag want deze setup kost ongeveer 800 euro.

Ja, dit kan. Het verkeer tussen de VLANs zal altijd over de USG moeten gaan. Hierop kun je vervolgens via de firewall zelf de juiste regels instellen zodat je dus standaard alle verkeer tussen VLANs kunt blokkeren en dan wel verkeer van/naar een IP adres (of poort) toe staan (bv voor je NAS).

Alleen is er mogelijk een nadeel, en dat is dat automatische service discovery niet werkt tussen de VLANs. Dit omdat dit op basis van multicast is en multicast verkeer nooit tussen VLANs/subnets kan. Voor mDNS (gebruikt door bv ChromeCast) is er wel een oplossing middels een mDNS reflector die het binnenkomende verkeer herhaald over de andere VLANs (deze zit in de USG ingebouwd en kun je in de controller aanzetten).
Voor SSDP ("simple" service discovery protocol) kan dit echter niet. En dit wordt meestal gebruikt door TVs, receivers etc. Dus als bv je telefoon verbonden is met het interne netwerk, en je een ChromeCast in je IoT netwerk hebt werkt dat wel, maar een afstandsbediening app voor je TV zal waarschijnlijk niet werken.

[kromme]

Vandaag de long range binnen gekregen. Maar hij reikt beduidend minder ver dan mijn Ziggo modem. En dit terwijl het Ziggo modem ook nog voor in de kamer staat en de LR in het midden en dus meer naar de tuin toe.

[nero355]

kromme schreef op zaterdag 6 januari 2018 @ 17:59:
Vandaag de long range binnen gekregen. Maar hij reikt beduidend minder ver dan mijn Ziggo modem. En dit terwijl het Ziggo modem ook nog voor in de kamer staat en de LR in het midden en dus meer naar de tuin toe.

Settings van beiden vergeleken ?/Ander straal patroon misschien ?/Hoe heb je de UAP opgehangen ?/enz.

[NeutraleTeun]

Vandaag mijn eerste Ubi device aangesloten en even mee zitten klooien, een UniFi AC Pro.

Nu zie ik dat er ook een Android app (controller) beschikbaar is.
Leek me wel leuk voor het dashboard en bepaalde informatie te kunnen inzien zonder mijn pc te hoeven gebruiken.

Echter krijg ik daar mijn AP niet te zien.
Mis ik iets of is dit gewoonweg niet mogelijk?

[Yoshimi]

NeutraleTeun schreef op zaterdag 6 januari 2018 @ 18:47:
Vandaag mijn eerste Ubi device aangesloten en even mee zitten klooien, een UniFi AC Pro.

Nu zie ik dat er ook een Android app (controller) beschikbaar is.
Leek me wel leuk voor het dashboard en bepaalde informatie te kunnen inzien zonder mijn pc te hoeven gebruiken.

Echter krijg ik daar mijn AP niet te zien.
Mis ik iets of is dit gewoonweg niet mogelijk?

Volgens mij is het zo dat je óf je AP’s via je smartphone app óf controller op je pc/laptop/pi/etc beheert, maar niet en/en.
Om ze via je smartphone te beheren moet je de QR code aan de onderkant scannen en kun je ze op die manier adopten .

[RobertMe]

NeutraleTeun schreef op zaterdag 6 januari 2018 @ 18:47:
Vandaag mijn eerste Ubi device aangesloten en even mee zitten klooien, een UniFi AC Pro.

Nu zie ik dat er ook een Android app (controller) beschikbaar is.
Leek me wel leuk voor het dashboard en bepaalde informatie te kunnen inzien zonder mijn pc te hoeven gebruiken.

Echter krijg ik daar mijn AP niet te zien.
Mis ik iets of is dit gewoonweg niet mogelijk?

Wat @mchl8 zegt klopt. Een AP kan maar zijn aangemeld bij één controller, deze draait dan of op je PC, of op de telefoon (die op de telefoon is echter geen volledige controller en mist functionaliteiten). Wat je dan weer wel kunt doen is de telefoon app laten verbinden met de controller die op je PC draait, maar uiteraard dient de PC dan wel aan te staan.

Wil je wel de volledige controller draaien, maar niet je PC altijd aan laten kun je deze wellicht op een NAS, of op een RPi zetten? Of misschien zelfs in de cloud (mocht je bv een VPS hebben). De UniFi controller draait namelijk "overal", op Windows, Linux, Mac, en van PCs tot NASen (Synology in ieder geval verschillende modellen), RPi, "de cloud" dan etc. Mocht dit niet wenselijk/mogelijk zijn is er nog een alternatief, en dat is de UniFi Cloud Key. Dit is in principe ook een mini computer waarop dan de controller draait, en deze kun je ook via PoE voeden en zo direct met 1 kabel op een (PoE) switch aansluiten en verder heb je dan geen kabels nodig.

[Shaggie_NB]

RobertMe schreef op zaterdag 6 januari 2018 @ 18:58:
[...]

Wat @mchl8 zegt klopt. Een AP kan maar zijn aangemeld bij één controller, deze draait dan of op je PC, of op de telefoon (die op de telefoon is echter geen volledige controller en mist functionaliteiten). Wat je dan weer wel kunt doen is de telefoon app laten verbinden met de controller die op je PC draait, maar uiteraard dient de PC dan wel aan te staan.

Wil je wel de volledige controller draaien, maar niet je PC altijd aan laten kun je deze wellicht op een NAS, of op een RPi zetten? Of misschien zelfs in de cloud (mocht je bv een VPS hebben). De UniFi controller draait namelijk "overal", op Windows, Linux, Mac, en van PCs tot NASen (Synology in ieder geval verschillende modellen), RPi, "de cloud" dan etc. Mocht dit niet wenselijk/mogelijk zijn is er nog een alternatief, en dat is de UniFi Cloud Key. Dit is in principe ook een mini computer waarop dan de controller draait, en deze kun je ook via PoE voeden en zo direct met 1 kabel op een (PoE) switch aansluiten en verder heb je dan geen kabels nodig.

Je kunt in de app ook kiezen om ze via de controller te beheren...

[RobertMe]

Shaggie_NB schreef op zaterdag 6 januari 2018 @ 19:00:
[...]

Je kunt in de app ook kiezen om ze via de controller te beheren...

Dat staan dan ook in het stukje wat je quote

Een AP kan maar zijn aangemeld bij één controller, deze draait dan of op je PC, of op de telefoon (die op de telefoon is echter geen volledige controller en mist functionaliteiten). Wat je dan weer wel kunt doen is de telefoon app laten verbinden met de controller die op je PC draait, maar uiteraard dient de PC dan wel aan te staan.

[Shaggie_NB]

RobertMe schreef op zaterdag 6 januari 2018 @ 19:03:
[...]

Dat staan dan ook in het stukje wat je quote


[...]

Excuse me... Niet goed gelezen..

[NeutraleTeun]

De cloud key is me iets te prijzig. Zoveel do ik er nu nog niet mee. Leek me vooral leuk om zo eens af te kijken wat er verbonden is en hoe alles draait.

De QR code scannen had ik al geprobeerd, maar dan kun je de AP instellen en niet toevoegen aan de app.

Dan maar eens inlezen of en hoe dat werkt voor op mijn Synology.

[Beekforel]

Beekforel schreef op maandag 25 december 2017 @ 10:44:
[...]

Ik ben mij er niet bewust van dat ik iets ingesteld heb t.b.v. wifi roaming?


[...]

2G stond op auto (5G ook), heb ik nu naar med gezet. Misschien wel naar low op den duur. Had er voornamelijk last van op 2G.

[edit] Heb Fast Roaming aangezet en beide 2G radio's op low gezet, eens kijken of het verbetert. Ook geupdate van 3.9.3.7537 naar 3.9.15.8011.

Met Fast Roaming werd het niets beter voor mijn gevoel, maar sowieso 1 device wat niet meer kan verbinden helaas.

Iemand nog een goede tip wat ik over het hoofd zie? Ik zit nu praktisch naast de AP en ben toch verbonden met de andere boven die matig bereik heeft.

[ Voor 6% gewijzigd door Beekforel op 06-01-2018 21:14 ]

[stormfly]

Beekforel schreef op zaterdag 6 januari 2018 @ 21:13:
[...]

Met Fast Roaming werd het niets beter voor mijn gevoel, maar sowieso 1 device wat niet meer kan verbinden helaas.

Iemand nog een goede tip wat ik over het hoofd zie? Ik zit nu praktisch naast de AP en ben toch verbonden met de andere boven die matig bereik heeft.

UBNT's FastRoaming werkt niet heel goed met Apple devices, daar lopen ze nog tegen wat uitdagingen aan.

Met wat voor device zit je naast het AP? Android staat bekend om hun slechte roaming, in sommige releases moet zelfs het AP waarmee je verbonden bent helemaal wegvallen. Voordat hij weer overschakelt naar een sterkere zender.

Met Apple producten, zonder FastRoaming kan ik prima video bellend naar boven lopen, roamt goed over 3 AP's

Heb je toevallig een buitenlands geimporteerd device, waar bv kanaal 13 niet toegestaan is? En staat jouw AP toevallig op kanaal 13 beneden? Zelfde check kan je doen voor 5Ghz, kanaal lijsten zijn op wikipedia inzichtelijk.

Maak eens een channel scan van de omgeving op de plek waar jij roaming verwacht? Voor MacOS is WiFi Explorer echt the bomb om dat uit te voeren.

[RobertMe]

stormfly schreef op zaterdag 6 januari 2018 @ 22:29:
[...]


UBNT's FastRoaming werkt niet heel goed met Apple devices, daar lopen ze nog tegen wat uitdagingen aan.

Is het niet voornamelijk zo dat Apple 802.11r, 82.11k, en 802.11v moet hebben voor goede roaming, waar Ubiquiti nu nog alleen voorziet in 802.11r (onder het fast roaming vinkje). 802.11k was volgensmij wel onderweg (heb ik eens gezien in een beta firmware IIRC), 802.11v durf ik niet te zeggen.

Het zou dan dus niet zozeer zijn dat Ubiquiti nu "uitdagingen" (= bugs ) heeft voor met Apple devices, maar ze nog maar een "halve" implementatie (= missende feature) hebben

[nero355]

RobertMe schreef op zaterdag 6 januari 2018 @ 22:45:
Is het niet voornamelijk zo dat Apple 802.11r, 82.11k, en 802.11v moet hebben voor goede roaming, waar Ubiquiti nu nog alleen voorziet in 802.11r (onder het fast roaming vinkje). 802.11k was volgensmij wel onderweg (heb ik eens gezien in een beta firmware IIRC), 802.11v durf ik niet te zeggen.

Het zou dan dus niet zozeer zijn dat Ubiquiti nu "uitdagingen" (= bugs ) heeft voor met Apple devices, maar ze nog maar een "halve" implementatie (= missende feature) hebben

802.11r/k zijn al in de firmware aanwezig tegenwoordig!

Alleen 802.11v zijn ze nog mee bezig en IMHO duurt het veel te lang : Ik wacht erop sinds de AC-Lite's tekoop zijn


Verder zijn Apple apparaten gewoon verschrikkelijk wat betreft WiFi en ik vind het dan ook erg jammer dat ze bij Apple met hun eigen netwerkprodukten zijn gestopt!

[Beekforel]

stormfly schreef op zaterdag 6 januari 2018 @ 22:29:
[...]


UBNT's FastRoaming werkt niet heel goed met Apple devices, daar lopen ze nog tegen wat uitdagingen aan.

Met wat voor device zit je naast het AP? Android staat bekend om hun slechte roaming, in sommige releases moet zelfs het AP waarmee je verbonden bent helemaal wegvallen. Voordat hij weer overschakelt naar een sterkere zender.

Met Apple producten, zonder FastRoaming kan ik prima video bellend naar boven lopen, roamt goed over 3 AP's

Heb je toevallig een buitenlands geimporteerd device, waar bv kanaal 13 niet toegestaan is? En staat jouw AP toevallig op kanaal 13 beneden? Zelfde check kan je doen voor 5Ghz, kanaal lijsten zijn op wikipedia inzichtelijk.

Maak eens een channel scan van de omgeving op de plek waar jij roaming verwacht? Voor MacOS is WiFi Explorer echt the bomb om dat uit te voeren.

Het is idd een Android device waarmee het niet lekker gaat en een Apple die Fast Roaming niet snapt.

Qua kanalen zitten beide AP's op 11 en zit er verder niets in de weg. Moeten ze nou juist wel of juist niet hetzelfde kanaal hebben?

Het heeft best lang goed gewerkt, ik denk dat het sinds de KRACK update slechter is geworden. Maar in diezelfde periode heb ik ook een "gewone" switch vervangen voor een Unifi. Dat lijkt mij geen probleem.

[edit] Of het is toch sinds ik m'n controller van Windows naar rPi heb gezet misschien?

[ Voor 3% gewijzigd door Beekforel op 07-01-2018 09:12 ]

[lier]

Beekforel schreef op zondag 7 januari 2018 @ 09:10:
Moeten ze nou juist wel of juist niet hetzelfde kanaal hebben?

Nee, altijd verschillende kanalen kiezen.

[stormfly]

Beekforel schreef op zondag 7 januari 2018 @ 09:10:
[...]

Het is idd een Android device waarmee het niet lekker gaat en een Apple die Fast Roaming niet snapt.

Qua kanalen zitten beide AP's op 11 en zit er verder niets in de weg. Moeten ze nou juist wel of juist niet hetzelfde kanaal hebben?

Het heeft best lang goed gewerkt, ik denk dat het sinds de KRACK update slechter is geworden. Maar in diezelfde periode heb ik ook een "gewone" switch vervangen voor een Unifi. Dat lijkt mij geen probleem.

[edit] Of het is toch sinds ik m'n controller van Windows naar rPi heb gezet misschien?

Zoveel mogelijk unieke kanalen gebruiken, WiFi is een one way medium. Als iemand zendt kan de ander niet zenden. Als je alle AP's op hetzelfde kanaal zet dan staan ze heel theoretisch op elkaar te wachten. De reguliere beacons van het SSID blijven ze altijd uitzenden. In deze artikelen zit een Excel waarin je verbaasd zult zijn van het aantal SSID's en het aantal AP's wat elkaar ziet, en wat er dan nog over blijft van netto "AirTime = kanaal vrij voor data". Een kanaal is natuurlijk ook bezet door je buren en door transfers. Ook hier kan de MacOS tool WiFi Explorer weer een schitterend beeld geven over de kanaal belasting.

https://community.ubnt.co...g-Done-Right/ba-p/1948312
http://www.revolutionwifi.net/capacity-planner/


Ik denk dat het je het in de Android moet zoeken ;-) alle andere componenten hebben 0 invloed op roaming, een switch niet maar ook de controller niet.

Als je een channel graph maakt met een tooltje zal je waarschijnlijk zelf kunnen concluderen dat het vermogen toch te hoog is van de "ver weg AP" (2G uitschakelen?) als beide AP's gelijk zijn qua sterkte. Of als de signalen wel goed zijn, dichtbij = sterk, en ver weg = zacht. Dat je Android het gewoon niet snapt en je beter een prachtige Apple kunt aanschaffen

[stormfly]

nero355 schreef op zondag 7 januari 2018 @ 01:51:
[...]
Verder zijn Apple apparaten gewoon verschrikkelijk wat betreft WiFi en ik vind het dan ook erg jammer dat ze bij Apple met hun eigen netwerkprodukten zijn gestopt!

Ehhh nee, juist Apple houdt zich aan alle standaarden is ver vooruit qua ontwikkeling. Het enige "nare" wat ze doen is een heel agressieve vorm van powersavings op de WiFi module.

Vergelijk een Android en Apple eens, Apple heeft de IP stack met IPv6 vele malen beter op orde volgens standaarden. En voor de genoemde WiFi protocollen geldt hetzelfde, ook alles volgens standaarden geïmplementeerd. Op Cisco omgevingen werkt Apple prima met de genoemde standaarden, alleen bij UBNT gaat het nog niet lekker met Fast Roaming.

Maar voor een Apple iOS of MacOS heb je al die fratsen (protocollen) niet nodig, alles roamt al prima met UBNT net uit de doos gehaald. Slechts het 2G signaal verlagen naar pokerlevel LOW of bij 1 van de 3 AP's helemaal uitschakelen, is vaak al voldoende. We willen het vaak teveel tweaken als Tweaker...wat niet altijd nodig.

[stormfly]

RobertMe schreef op zaterdag 6 januari 2018 @ 22:45:
[...]

Is het niet voornamelijk zo dat Apple 802.11r, 82.11k, en 802.11v moet hebben voor goede roaming, waar Ubiquiti nu nog alleen voorziet in 802.11r (onder het fast roaming vinkje). 802.11k was volgensmij wel onderweg (heb ik eens gezien in een beta firmware IIRC), 802.11v durf ik niet te zeggen.

Het zou dan dus niet zozeer zijn dat Ubiquiti nu "uitdagingen" (= bugs ) heeft voor met Apple devices, maar ze nog maar een "halve" implementatie (= missende feature) hebben

Op Cisco omgevingen werkt Apple prima met de genoemde standaarden, alleen bij UBNT gaat het nog niet lekker met Fast Roaming. Je post zal een kern van waarheid bevatten, dat Apple graag alle protocollen wil zien of niets?

K en R zijn er, alleen ze blijven uitdagingen houden met Apple. Volgens mij heeft dit uitzoeken op dit moment geen focus. Ze hebben een klein team en maken steeds keuze om resources op de juiste plekken in te zetten, nu weer de XG en nanoHD App in de beta store die aandacht vragen op software gebied.

[Cartman!]

In een setup met 2 LR's heb ik er met zowel een iPad Air als Samsung Galaxy S6 last van dat ie niet meer wil verbinden. Hij blijft dan hangen op verbinding maken, als ik "forget network" doe zegt ie daarna dat t wachtwoord niet klopt. Uiteindelijk "opgelost" voor de iPad door een tijdelijk nieuw netwerk te maken waar ik wel op kon verbinden, de Galaxy S pakte dit niet en na het instellen van een vast IP (ipv DHCP) op de telefoon werkte het vlekkeloos). Iemand die dit bekend voorkomt?

Met mijn telefoon (OnePlus X) nergens last van. Beide probleemapparaten zijn verbonden over 5G en mijn telefoon op 2G. Ik draai de laatste firmware (3.9.15.8011) op alle devices.

[lier]

@Cartman! Kan je eens een 'Show System Config' hier posten?

[athomasse]

Dag mensen,
ik zie aardig wat topics over de edgerouter / USG i.c.m. een T-Mobile finber abonnement, maar helaas kan ik niet mijn issue oplossen.

In mijn opzet heb ik internet werkend en heb ik de menu's werkende van mijn IPTV doos. Maar helaas blijf ik zwart beeld behouden.

Ik heb via een fiber converter mijn de ISP lijn aangesloten op een USG poort eth0 op eth1 is mijn LAN aangesloten via en op eth2 is mijn IPTV aangelosten.
Nu is het natuurlijk handig als ik ook beeld heb bij mijn tv.

Dit is voor mij geen dagelijke kost dus alle hulp is welkom...

Mijn config:

firewall {
all-ping enable
broadcast-ping disable
group {
address-group authorized_guests {
description "authorized guests MAC addresses"
}
address-group guest_allow_addresses {
description "allow addresses for guests"
}
address-group guest_allow_dns_servers {
description "allow dns servers for guests"
}
address-group guest_portal_address {
description "guest portal address"
}
address-group guest_restricted_addresses {
address 192.168.0.0/16
address 172.16.0.0/12
address 10.0.0.0/8
description "restricted addresses for guests"
}
address-group unifi_controller_addresses {
address 192.168.1.12
}
network-group captive_portal_subnets {
description "captive portal subnets"
}
network-group corporate_network {
description "corporate subnets"
network 192.168.1.0/24
}
network-group guest_allow_subnets {
description "allow subnets for guests"
}
network-group guest_network {
description "guest subnets"
}
network-group guest_restricted_subnets {
description "restricted subnets for guests"
}
network-group remote_client_vpn_network {
description "remote client VPN subnets"
}
network-group remote_site_vpn_network {
description "remote site VPN subnets"
}
network-group remote_user_vpn_network {
description "remote user vpn subnets"
}
port-group guest_portal_ports {
description "guest portal ports"
}
port-group guest_portal_redirector_ports {
description "guest portal redirector ports"
port 39080
port 39443
}
port-group unifi_controller_ports-tcp {
description "unifi tcp ports"
port 8080
}
port-group unifi_controller_ports-udp {
description "unifi udp ports"
port 3478
}
}
name AUTHORIZED_GUESTS {
default-action drop
description "authorization check packets from guest network"
}
name GUEST_IN {
default-action accept
description "packets from guest network"
rule 3001 {
action accept
description "allow DNS packets to external name servers"
destination {
port 53
}
protocol udp
}
rule 3002 {
action accept
description "allow packets to captive portal"
destination {
group {
network-group captive_portal_subnets
}
port 443
}
protocol tcp
}
rule 3003 {
action accept
description "allow packets to allow subnets"
destination {
group {
address-group guest_allow_addresses
}
}
}
rule 3004 {
action drop
description "drop packets to restricted subnets"
destination {
group {
address-group guest_restricted_addresses
}
}
}
rule 3005 {
action drop
description "drop packets to intranet"
destination {
group {
network-group corporate_network
}
}
}
rule 3006 {
action drop
description "drop packets to remote user"
destination {
group {
network-group remote_user_vpn_network
}
}
}
rule 3007 {
action drop
description "authorized guests white list"
destination {
group {
address-group authorized_guests
}
}
}
}
name GUEST_LOCAL {
default-action drop
description "packets from guest network to gateway"
rule 3001 {
action accept
description "allow DNS"
destination {
port 53
}
protocol udp
}
rule 3002 {
action accept
description "allow ICMP"
protocol icmp
}
}
name GUEST_OUT {
default-action accept
description "packets forward to guest network"
}
name LAN_IN {
default-action accept
description "packets from intranet"
rule 6001 {
action accept
description "accounting defined network 192.168.1.0/24"
source {
address 192.168.1.0/24
}
}
}
name LAN_LOCAL {
default-action accept
description "packets from intranet to gateway"
}
name LAN_OUT {
default-action accept
description "packets forward to intranet"
rule 6001 {
action accept
description "accounting defined network 192.168.1.0/24"
destination {
address 192.168.1.0/24
}
}
}
name WAN_IN {
default-action drop
description "packets from internet to intranet"
rule 3001 {
action accept
description "allow established/related sessions"
state {
established enable
invalid disable
new disable
related enable
}
}
rule 3002 {
action drop
description "drop invalid state"
state {
established disable
invalid enable
new disable
related disable
}
}
}
name WAN_LOCAL {
default-action drop
description "packets from internet to gateway"
rule 3001 {
action accept
description "allow established/related sessions"
state {
established enable
invalid disable
new disable
related enable
}
}
rule 3002 {
action drop
description "drop invalid state"
state {
established disable
invalid enable
new disable
related disable
}
}
}
name WAN_OUT {
default-action accept
description "packets to internet"
}
options {
mss-clamp {
interface-type pppoe
interface-type pptp
interface-type vti
mss 1452
}
}
receive-redirects disable
send-redirects enable
syn-cookies enable
}
interfaces {
bridge br0 {
aging 300
bridged-conntrack disable
hello-time 2
max-age 20
priority 32768
promiscuous disable
stp false
}
ethernet eth0 {
vif 100 {
description MGT
}
vif 300 {
address dhcp
dhcp-options {
client-option "retry 60;"
default-route-distance 1
}
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
out {
name WAN_OUT
}
}
}
vif 640 {
bridge-group {
bridge br0
}
description IPTV
}
}
ethernet eth1 {
address 192.168.1.1/24
firewall {
in {
name LAN_IN
}
local {
name LAN_LOCAL
}
out {
name LAN_OUT
}
}
}
ethernet eth2 {
bridge-group {
bridge br0
}
description IPTV
vif 640 {
description IPTV
}
}
loopback lo {
}
}
port-forward {
auto-firewall disable
hairpin-nat enable
lan-interface eth1
wan-interface eth0.300
}
protocols {
igmp-proxy {
interface eth0.640 {
alt-subnet 0.0.0.0/0
role upstream
threshold 1
}
interface eth2 {
alt-subnet 0.0.0.0/0
role downstream
threshold 1
}
}
}
service {
dns {
forwarding {
cache-size 10000
except-interface eth0.300
options host-record=unifi,192.168.1.12
}
}
gui {
https-port 443
}
lldp {
interface eth0 {
disable
}
}
nat {
rule 6001 {
description "MASQ corporate_network to WAN"
log disable
outbound-interface eth0.300
protocol all
source {
group {
network-group corporate_network
}
}
type masquerade
}
rule 6002 {
description "MASQ remote_user_vpn_network to WAN"
log disable
outbound-interface eth0.300
protocol all
source {
group {
network-group remote_user_vpn_network
}
}
type masquerade
}
rule 6003 {
description "MASQ guest_network to WAN"
log disable
outbound-interface eth0.300
protocol all
source {
group {
network-group guest_network
}
}
type masquerade
}
rule 6004 {
description "MASQ IPTV"
log disable
outbound-interface eth0.640
type masquerade
}
}
ssh {
port 22
protocol-version v2
}
}

[reinoudkil]

Doe jezelf en een ander even een lol en gebruik volgende keer code tags: Overzicht van UBB-codes #tag_code

[nero355]

stormfly schreef op zondag 7 januari 2018 @ 09:46:
Ehhh nee, juist Apple houdt zich aan alle standaarden is ver vooruit qua ontwikkeling. Het enige "nare" wat ze doen is een heel agressieve vorm van powersavings op de WiFi module.

Vergelijk een Android en Apple eens, Apple heeft de IP stack met IPv6 vele malen beter op orde volgens standaarden. En voor de genoemde WiFi protocollen geldt hetzelfde, ook alles volgens standaarden geïmplementeerd. Op Cisco omgevingen werkt Apple prima met de genoemde standaarden, alleen bij UBNT gaat het nog niet lekker met Fast Roaming.

Maar voor een Apple iOS of MacOS heb je al die fratsen (protocollen) niet nodig, alles roamt al prima met UBNT net uit de doos gehaald. Slechts het 2G signaal verlagen naar pokerlevel LOW of bij 1 van de 3 AP's helemaal uitschakelen, is vaak al voldoende. We willen het vaak teveel tweaken als Tweaker...wat niet altijd nodig.

Allemaal leuk en aardig, maar in de praktijk zie ik vaker Apple toestellen allerlei WiFi problemen hebben en dan niet alleen i.c.m. Ubiquiti dus het zal vast allemaal geweldig zijn, echter heeft het in de praktijk weinig nut.
Om maar wat te noemen : FritzBox apparaten, Netgear, Draytek, enz.

Kijk alleen al naar Deel 1 en Deel 2 van dit topic : Hoe vaak lees je wel niet dat een Apple apparaat verbonden is, maar verder niks kan ?!

En ondertussen alle normale laptops en telefoons, tablets, enz. gewoon werken zonder enig probleem...
MAAR ook dat diezelfde Apple apparaten perfect werken op een Apple WiFi router/accesspoint/enz.

Kortom : Apple had nooit met WiFi produkten moeten stoppen!

[Verwijderd]

Is Apple niet ook recent uit de Wi-Fi Alliance gestapt?

---

RobertMe schreef op zaterdag 6 januari 2018 @ 22:45:
[...]

Is het niet voornamelijk zo dat Apple 802.11r, 82.11k, en 802.11v moet hebben voor goede roaming, waar Ubiquiti nu nog alleen voorziet in 802.11r (onder het fast roaming vinkje). 802.11k was volgensmij wel onderweg (heb ik eens gezien in een beta firmware IIRC), 802.11v durf ik niet te zeggen.

Het zou dan dus niet zozeer zijn dat Ubiquiti nu "uitdagingen" (= bugs ) heeft voor met Apple devices, maar ze nog maar een "halve" implementatie (= missende feature) hebben

802.11v is ook nog niet volledig geïmplementeerd in hostapd.

[ Voor 85% gewijzigd door Verwijderd op 07-01-2018 20:05 ]

[lowfi]

Zijn hier al ervaringen met de US-24-250? Het is voor thuis. Heb liever 1 switch die alles kan ook al heb ik niet 24x POE nodig.

Lees alleen veel negatieve verhalen over het Fan geluid. Al is dat wel op te lossen door de twee 40mm deltas fans te vervangen voor noctua fans ofzo.

Spul komt in in de meterkast te hangen.

code:

Meterkast   10
Woonkamer   5
Werkkamer   2
Gang boven  1
Slaapkmr 1  1
Slaapkmr 2  1
Zolder  1
    21

[ Voor 14% gewijzigd door lowfi op 07-01-2018 20:31 ]

[OsiriS.nl]

Zo... ik heb dit weekend mijn Netgear WNDR3700 router en 1 netgear GS108 vervangen voor een USG en switch8-60w. Wat een makkie, ik had de USG van te voren al geconfigureerd in de contoller.
Omwisselen, provisionen en alles werkte! Hier en daar nog paar kleine aanpassingen gemaakt en alles draaide naar wens.

Ook eindelijk tijd gehad om een ip-camera op te hangen, deze gelijk ook op POE gehangen nu ik toch een POE-switch heb.

Tevens mijn UAP-AC-Pro opgehangen aan het plafond in de gang, gelijk weer iets beter Wifi signaal dan in de meterkast. En gelijk alles netjes weg gewerkt.
In de planning staat nog een UAP voor een deel van het huis waar nu minder goed signaal is t.b.v. de chromecasts. Dan wil ik gelijk met een AC-InWall een draadloze bridge maken naar een plek waar ik geen LAN kabel heb liggen. Dus nog genoeg te doen...ohja en de meterkast weer eens fatsoeneren dat lijkt nu wel een slagveld!

[Spoelly]

Is het ook mogelijk om een vlan toe te kennen aan een mac adres?
Ik heb een USG en twee AP's. De rest zijn unmanaged switches.

[RobertMe]

Spoelly schreef op maandag 8 januari 2018 @ 15:35:
Is het ook mogelijk om een vlan toe te kennen aan een mac adres?
Ik heb een USG en twee AP's. De rest zijn unmanaged switches.

Voor zover ik weet niet, hiervoor moet je switch 802.1X ondersteunen. Daarnaast vereist het volgensmij ook nog aardig wat configuratie, zelfs als je de UniFi switches hebt. Je moet dan namelijk radius volledig inregelen (de radius server draait dan wel weer op de USG).

[Spoelly]

hmm jammer ik had dit gelezen:

https://community.ubnt.co...-Assignment/idi-p/1705044

Alleen kan het niet vinden in de controller.

[RobertMe]

Spoelly schreef op maandag 8 januari 2018 @ 16:05:
hmm jammer ik had dit gelezen:

https://community.ubnt.co...-Assignment/idi-p/1705044

Alleen kan het niet vinden in de controller.

Je linkt dan ook naar een feature request Maar die is dan weer duplicate van een ander, waarin sowieso over switch wordt gesproken, en ook in staat aangegeven dat het (gedeeltelijk?) in een beta controller zit/zat (in mei '17).

Volgensmij is het er in ieder geval dus wel, alleen niet heel eenvoudig te configureren, en het moet dus (ook) op op switch niveau en niet (alleen) op USG niveau. De switch zal immers het VLAN aan de poort moeten toekennen.

Sowieso is het niet zo handig om VLANs over een unmanaged switch te laten lopen, omdat je broadcast verkeer dan ook ineens bij alle apparaten uitkomt etc.

[Spoelly]

ja sorry had even die link moeten posten. Maar bedankt voor je antwoord. Ik ga me eens verdiepen in de switch configuratie.

[Cartman!]

lier schreef op zondag 7 januari 2018 @ 15:23:
@Cartman! Kan je eens een 'Show System Config' hier posten?

Hoe doe ik dat precies? Ik kan die optie niet vinden in de controller

Had t op m'n desktop net ook...ik krijg via DHCP geen IP adres en daardoor kom ik er niet op, zodra ik op de client (desktop in dit geval) een vast IP instel is t probleem opgelost, dat sluit uit dat t aan WiFi ligt meteen.

[ Voor 31% gewijzigd door Cartman! op 08-01-2018 18:45 ]

[RobertMe]

Cartman! schreef op maandag 8 januari 2018 @ 18:44:
[...]

Hoe doe ik dat precies? Ik kan die optie niet vinden in de controller

Settings => Maintenance => Onder het kopje "Support config" => "Show system config", dan krijg je een popup met 2 tabjes aan info, ik neem aan dat @lier daar screenshots van wil.

[glenn456]

Even een vraagje hopelijk kunnen jullie mij op een goede weg wijzen.

Sinds kort een edgerouter lite geinstalleerd icm met KPN FTTH. De configuratie gemaakt met behulp van kriegsman, alles werkt naar behoren alleen met met IPTV loop ik tegen een vreemde bug aan.

Wanneer er gedownload wordt bijv een speedtest. en op de televisies wordt van kanaal gewisseld dan duurt het veel langer dan normaal 8 seconden in plaats van 3 seconden, ook krijg ik soms opeens een zwart scherm. stopt de download dan gaat het weer goed. het lijkt dat het mis gaat met de IGMP proxy maar ik weet niet goed wat nog. De edgerouter draait op de laatste softwareversie 1.9.7hotfix4.

Wat ik verder nog tegenkwam in de multicastlogs is een APIPA IP. Dit lijkt mij ook nogal vreemd.



de configuratie die nu draait is het volgende:

code:

firewall {
    all-ping enable
    broadcast-ping disable
    ipv6-name WANv6_IN {
        default-action drop
        description "WAN inbound traffic forwarded to LAN"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related sessions"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    ipv6-name WANv6_LOCAL {
        default-action drop
        description "WAN inbound traffic to the router"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related sessions"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
        rule 30 {
            action accept
            description "Allow IPv6 icmp"
            protocol ipv6-icmp
        }
        rule 40 {
            action accept
            description "allow dhcpv6"
            destination {
                port 546
            }
            protocol udp
            source {
                port 547
            }
        }
    }
    ipv6-receive-redirects disable
    ipv6-src-route disable
    ip-src-route disable
    log-martians enable
    name WAN_IN {
        default-action drop
        description "WAN naar Intern"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related"
            log enable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invaild state"
            log enable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
    }
    name WAN_LOCAL {
        default-action drop
        description "WAN to router"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related"
            log disable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            log disable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
    }
    receive-redirects enable
    send-redirects enable
    source-validation disable
    syn-cookies enable
}
interfaces {
    ethernet eth0 {
        description "eth0 - FTTH KPN"
        duplex auto
        mtu 1512
        speed auto
        vif 4 {
            address dhcp
            description "eth0.4 - IPTV"
            dhcp-options {
                client-option "send vendor-class-identifier "IPTV_RG";"
                client-option "request subnet-mask, routers, rfc3442-classless-static-routes;"
                default-route no-update
                default-route-distance 210
                name-server update
            }
        }
        vif 6 {
            description "eth0.6 - Internet"
            mtu 1508
            pppoe 0 {
                default-route auto
                dhcpv6-pd {
                    no-dns
                    pd 0 {
                        interface eth1 {
                            prefix-id :1
                            service slaac
                        }
                        prefix-length /48
                    }
                    rapid-commit disable
                }
                firewall {
                    in {
                        ipv6-name WANv6_IN
                        name WAN_IN
                    }
                    local {
                        ipv6-name WANv6_LOCAL
                        name WAN_LOCAL
                    }
                }
                idle-timeout 180
                ipv6 {
                    address {
                        autoconf
                    }
                    dup-addr-detect-transmits 1
                    enable {
                    }
                }
                mtu 1500
                name-server auto
                password kpn
                user-id MAC@internet
            }
        }
    }
    ethernet eth1 {
        address 192.168.1.254/24
        description "eth1 - LAN-Netwerk"
        duplex auto
        ipv6 {
            dup-addr-detect-transmits 1
            router-advert {
                cur-hop-limit 64
                link-mtu 0
                managed-flag false
                max-interval 600
                name-server 2a02:a47f:e000::53
                name-server 2a02:a47f:e000::54
                other-config-flag false
                prefix ::/64 {
                    autonomous-flag true
                    on-link-flag true
                    valid-lifetime 2592000
                }
                radvd-options "RDNSS 2a02:a47f:e000::53 2a02:a47f:e000::54 {};"
                reachable-time 0
                retrans-timer 0
                send-advert true
            }
        }
        speed auto
    }
    ethernet eth2 {
        duplex auto
        speed auto
    }
    loopback lo {
    }
}
protocols {
    igmp-proxy {
        disable-quickleave
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1
        }
    }
    static {
        interface-route6 ::/0 {
            next-hop-interface pppoe0 {
            }
        }
        route 213.75.112.0/21 {
            next-hop 10.138.104.1 {
            }
        }
    }
}
service {
    dhcp-server {
        disabled false
        global-parameters "option vendor-class-identifier code 60 = string;"
        global-parameters "option broadcast-address code 28 = ip-address;"
        hostfile-update disable
        shared-network-name LAN {
            authoritative enable
            subnet 192.168.1.0/24 {
                default-router 192.168.1.254
                dns-server 195.121.1.34
                dns-server 195.121.1.66
                domain-name bm.internal
                lease 86400
                start 192.168.1.50 {
                    stop 192.168.1.252
                }
                static-mapping switch8 {
                    ip-address 192.168.1.50
                    mac-address b0:39:56:6c:d0:58
                }
            }
        }
        use-dnsmasq disable
    }
    dns {
        forwarding {
            cache-size 150
            listen-on eth1
            name-server 195.121.1.34
            name-server 195.121.1.66
            options listen-address=192.168.1.254
        }
    }
    gui {
        http-port 80
        https-port 443
        older-ciphers enable
    }
    nat {
        rule 5000 {
            description IPTV
            destination {
                address 213.75.112.0/21
            }
            log disable
            outbound-interface eth0.4
            protocol all
            source {
            }
            type masquerade
        }
        rule 5010 {
            description "KPN Internet"
            log enable
            outbound-interface pppoe0
            protocol all
            source {
                address 192.168.1.0/24
            }
            type masquerade
        }
    }
    ssh {
        port 22
        protocol-version v2
    }
    unms {
        disable
    }
}
system {
    host-name ubnt
    login {
        user ubnt {
            authentication {
                encrypted-password 
                plaintext-password ""
            }
            full-name ""
            level admin
        }
    }
    name-server 195.121.1.34
    name-server 195.121.1.66
    name-server 2a02:a47f:e000::53
    name-server 2a02:a47f:e000::54
    ntp {
        server 0.ubnt.pool.ntp.org {
        }
        server 1.ubnt.pool.ntp.org {
        }
        server 2.ubnt.pool.ntp.org {
        }
        server 3.ubnt.pool.ntp.org {
        }
    }
    offload {
        hwnat disable
        ipsec enable
        ipv4 {
            forwarding enable
            pppoe enable
            vlan enable
        }
        ipv6 {
            forwarding enable
            pppoe enable
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
    task-scheduler {
        task updateIPTVroute {
            executable {
                path /config/scripts/tvroute.sh
            }
            interval 5m
        }
    }
    time-zone Europe/Amsterdam
    traffic-analysis {
        dpi enable
        export enable
    }
}
traffic-control {
}

Alle ideeën, tips zijn welkom!

[Cartman!]

lier schreef op zondag 7 januari 2018 @ 15:23:
@Cartman! Kan je eens een 'Show System Config' hier posten?

Gevonden dankzij RobertMe:





Het probleem lijkt niet in de WiFi te zitten maar in DHCP want een device dat verbindt krijgt geen IP toegewezen dan, ook niet als deze als statisch ingesteld wordt via de controller. Als ik handmatig op de client een IP (+gateway) toewijs werkt het gewoon prima maar dat laat ik liever aan de DHCP server over.

[Shaggie_NB]

Cartman! schreef op maandag 8 januari 2018 @ 23:08:
[...]

Gevonden dankzij RobertMe:

[afbeelding]

[afbeelding]

Het probleem lijkt niet in de WiFi te zitten maar in DHCP want een device dat verbindt krijgt geen IP toegewezen dan, ook niet als deze als statisch ingesteld wordt via de controller. Als ik handmatig op de client een IP (+gateway) toewijs werkt het gewoon prima maar dat laat ik liever aan de DHCP server over.

Wifi 2G op kanaal 12 en 13? Kunt beter 1, 6 of 11 nemen.

[Verwijderd]

Ach, zolang je devices het netwerk kunnen zien, en connecten, laat maar lekker op kanaal 12 en 13 zitten. Het is dat de Amerikanen niet hoger dan kanaal 11 mogen gaan. Dus alle drivers die je bv. van de Amerikaanse site haalt (voor bv. je laptop), deze een "lock" hebben om t/m kanaal 11 te scannen.

De internationale drivers hebben daar geen last van.

[Shaggie_NB]

Verwijderd schreef op maandag 8 januari 2018 @ 23:53:
Ach, zolang je devices het netwerk kunnen zien, en connecten, laat maar lekker op kanaal 12 en 13 zitten. Het is dat de Amerikanen niet hoger dan kanaal 11 mogen gaan. Dus alle drivers die je bv. van de Amerikaanse site haalt (voor bv. je laptop), deze een "lock" hebben om t/m kanaal 11 te scannen.

De internationale drivers hebben daar geen last van.

Die kunnen elkaar toch lekker verstoren op 12 en 13...

[burne]

Verwijderd schreef op maandag 8 januari 2018 @ 23:53:
Ach, zolang je devices het netwerk kunnen zien, en connecten, laat maar lekker op kanaal 12 en 13 zitten. Het is dat de Amerikanen niet hoger dan kanaal 11 mogen gaan.

Als je leep bent zeg je dat je in Japan woont. Dan heb je opeens ook een kanaal 14.

Van de andere kant: kanaal 14 in Singapore gebruiken kan je een jaar celstraf opleveren.

Dus 'Ach, zolang' je doet alsof je dom bent, ben je vooral een gevaar voor jezelf.

[Chris.nl]

glenn456 schreef op maandag 8 januari 2018 @ 22:49:
Even een vraagje hopelijk kunnen jullie mij op een goede weg wijzen.

Sinds kort een edgerouter lite geinstalleerd icm met KPN FTTH. De configuratie gemaakt met behulp van kriegsman, alles werkt naar behoren alleen met met IPTV loop ik tegen een vreemde bug aan.

Wanneer er gedownload wordt bijv een speedtest. en op de televisies wordt van kanaal gewisseld dan duurt het veel langer dan normaal 8 seconden in plaats van 3 seconden, ook krijg ik soms opeens een zwart scherm. stopt de download dan gaat het weer goed. het lijkt dat het mis gaat met de IGMP proxy maar ik weet niet goed wat nog. De edgerouter draait op de laatste softwareversie 1.9.7hotfix4.

Wat ik verder nog tegenkwam in de multicastlogs is een APIPA IP. Dit lijkt mij ook nogal vreemd.

[afbeelding]

de configuratie die nu draait is het volgende:

code:

firewall {
    all-ping enable
    broadcast-ping disable
    ipv6-name WANv6_IN {
        default-action drop
        description "WAN inbound traffic forwarded to LAN"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related sessions"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
    }
    ipv6-name WANv6_LOCAL {
        default-action drop
        description "WAN inbound traffic to the router"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related sessions"
            state {
                established enable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            state {
                invalid enable
            }
        }
        rule 30 {
            action accept
            description "Allow IPv6 icmp"
            protocol ipv6-icmp
        }
        rule 40 {
            action accept
            description "allow dhcpv6"
            destination {
                port 546
            }
            protocol udp
            source {
                port 547
            }
        }
    }
    ipv6-receive-redirects disable
    ipv6-src-route disable
    ip-src-route disable
    log-martians enable
    name WAN_IN {
        default-action drop
        description "WAN naar Intern"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related"
            log enable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invaild state"
            log enable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
    }
    name WAN_LOCAL {
        default-action drop
        description "WAN to router"
        enable-default-log
        rule 10 {
            action accept
            description "Allow established/related"
            log disable
            protocol all
            state {
                established enable
                invalid disable
                new disable
                related enable
            }
        }
        rule 20 {
            action drop
            description "Drop invalid state"
            log disable
            protocol all
            state {
                established disable
                invalid enable
                new disable
                related disable
            }
        }
    }
    receive-redirects enable
    send-redirects enable
    source-validation disable
    syn-cookies enable
}
interfaces {
    ethernet eth0 {
        description "eth0 - FTTH KPN"
        duplex auto
        mtu 1512
        speed auto
        vif 4 {
            address dhcp
            description "eth0.4 - IPTV"
            dhcp-options {
                client-option "send vendor-class-identifier "IPTV_RG";"
                client-option "request subnet-mask, routers, rfc3442-classless-static-routes;"
                default-route no-update
                default-route-distance 210
                name-server update
            }
        }
        vif 6 {
            description "eth0.6 - Internet"
            mtu 1508
            pppoe 0 {
                default-route auto
                dhcpv6-pd {
                    no-dns
                    pd 0 {
                        interface eth1 {
                            prefix-id :1
                            service slaac
                        }
                        prefix-length /48
                    }
                    rapid-commit disable
                }
                firewall {
                    in {
                        ipv6-name WANv6_IN
                        name WAN_IN
                    }
                    local {
                        ipv6-name WANv6_LOCAL
                        name WAN_LOCAL
                    }
                }
                idle-timeout 180
                ipv6 {
                    address {
                        autoconf
                    }
                    dup-addr-detect-transmits 1
                    enable {
                    }
                }
                mtu 1500
                name-server auto
                password kpn
                user-id MAC@internet
            }
        }
    }
    ethernet eth1 {
        address 192.168.1.254/24
        description "eth1 - LAN-Netwerk"
        duplex auto
        ipv6 {
            dup-addr-detect-transmits 1
            router-advert {
                cur-hop-limit 64
                link-mtu 0
                managed-flag false
                max-interval 600
                name-server 2a02:a47f:e000::53
                name-server 2a02:a47f:e000::54
                other-config-flag false
                prefix ::/64 {
                    autonomous-flag true
                    on-link-flag true
                    valid-lifetime 2592000
                }
                radvd-options "RDNSS 2a02:a47f:e000::53 2a02:a47f:e000::54 {};"
                reachable-time 0
                retrans-timer 0
                send-advert true
            }
        }
        speed auto
    }
    ethernet eth2 {
        duplex auto
        speed auto
    }
    loopback lo {
    }
}
protocols {
    igmp-proxy {
        disable-quickleave
        interface eth0.4 {
            alt-subnet 0.0.0.0/0
            role upstream
            threshold 1
        }
        interface eth1 {
            alt-subnet 0.0.0.0/0
            role downstream
            threshold 1
        }
    }
    static {
        interface-route6 ::/0 {
            next-hop-interface pppoe0 {
            }
        }
        route 213.75.112.0/21 {
            next-hop 10.138.104.1 {
            }
        }
    }
}
service {
    dhcp-server {
        disabled false
        global-parameters "option vendor-class-identifier code 60 = string;"
        global-parameters "option broadcast-address code 28 = ip-address;"
        hostfile-update disable
        shared-network-name LAN {
            authoritative enable
            subnet 192.168.1.0/24 {
                default-router 192.168.1.254
                dns-server 195.121.1.34
                dns-server 195.121.1.66
                domain-name bm.internal
                lease 86400
                start 192.168.1.50 {
                    stop 192.168.1.252
                }
                static-mapping switch8 {
                    ip-address 192.168.1.50
                    mac-address b0:39:56:6c:d0:58
                }
            }
        }
        use-dnsmasq disable
    }
    dns {
        forwarding {
            cache-size 150
            listen-on eth1
            name-server 195.121.1.34
            name-server 195.121.1.66
            options listen-address=192.168.1.254
        }
    }
    gui {
        http-port 80
        https-port 443
        older-ciphers enable
    }
    nat {
        rule 5000 {
            description IPTV
            destination {
                address 213.75.112.0/21
            }
            log disable
            outbound-interface eth0.4
            protocol all
            source {
            }
            type masquerade
        }
        rule 5010 {
            description "KPN Internet"
            log enable
            outbound-interface pppoe0
            protocol all
            source {
                address 192.168.1.0/24
            }
            type masquerade
        }
    }
    ssh {
        port 22
        protocol-version v2
    }
    unms {
        disable
    }
}
system {
    host-name ubnt
    login {
        user ubnt {
            authentication {
                encrypted-password 
                plaintext-password ""
            }
            full-name ""
            level admin
        }
    }
    name-server 195.121.1.34
    name-server 195.121.1.66
    name-server 2a02:a47f:e000::53
    name-server 2a02:a47f:e000::54
    ntp {
        server 0.ubnt.pool.ntp.org {
        }
        server 1.ubnt.pool.ntp.org {
        }
        server 2.ubnt.pool.ntp.org {
        }
        server 3.ubnt.pool.ntp.org {
        }
    }
    offload {
        hwnat disable
        ipsec enable
        ipv4 {
            forwarding enable
            pppoe enable
            vlan enable
        }
        ipv6 {
            forwarding enable
            pppoe enable
        }
    }
    syslog {
        global {
            facility all {
                level notice
            }
            facility protocols {
                level debug
            }
        }
    }
    task-scheduler {
        task updateIPTVroute {
            executable {
                path /config/scripts/tvroute.sh
            }
            interval 5m
        }
    }
    time-zone Europe/Amsterdam
    traffic-analysis {
        dpi enable
        export enable
    }
}
traffic-control {
}

Alle ideeën, tips zijn welkom!

Ik had met Telfort glasvezel last van stotterende TV's tijdens uploadspeedtests. Gefixt door QoS max uploadsnelheid op 55Mbits/sec (110% van m'n 50/50 abonnement) in te stellen, dat haalde de stotterpieken eraf tijdens speedtests en nog steeds 100% snelheid.

Wat doen jou TV's als je QoS max down op 110% zet?

[ Voor 100% gewijzigd door Chris.nl op 09-01-2018 00:49 ]

[glenn456]

Chris.nl schreef op dinsdag 9 januari 2018 @ 00:45:
[...]
Ik had met Telfort glasvezel last van stotterende TV's tijdens uploadspeedtests. Gefixt door QoS max uploadsnelheid op 55Mbits/sec (110% van m'n 50/50 abonnement) in te stellen, dat haalde de stotterpieken eraf tijdens speedtests en nog steeds 100% snelheid.

Wat doen jou TV's als je QoS max down op 110% zet?

Mag ik vragen welk type QoS jij gebruikt?. Ik heb het met smartqueue geprobeerd ingesteld op de WAN interface maar dit was geen succes.

[Verwijderd]

burne schreef op dinsdag 9 januari 2018 @ 00:17:
[...]

Als je leep bent zeg je dat je in Japan woont. Dan heb je opeens ook een kanaal 14.

Van de andere kant: kanaal 14 in Singapore gebruiken kan je een jaar celstraf opleveren.

Dus 'Ach, zolang' je doet alsof je dom bent, ben je vooral een gevaar voor jezelf.

ik zie het "gevaar" niet in van kanaal 12 of 13 / 14..... en aangezien de TS kennelijk niet in Singapore zich bevindt....

[Chris.nl]

glenn456 schreef op dinsdag 9 januari 2018 @ 07:57:
[...]


Mag ik vragen welk type QoS jij gebruikt?. Ik heb het met smartqueue geprobeerd ingesteld op de WAN interface maar dit was geen succes.

Ik gebruik ook Smart Queue:



Ik had tijdens uploadspeedtests pieken van 70/80Mbit/sec die IPTV haperingen veroorzaakten.

[glenn456]

Chris.nl schreef op dinsdag 9 januari 2018 @ 13:06:
[...]

Ik gebruik ook Smart Queue:

[afbeelding]

Ik had tijdens uploadspeedtests pieken van 70/80Mbit/sec die IPTV haperingen veroorzaakten.

De televisie blijft nu wel doorspelen alleen bij het wisselen van kanaal gaat het nog wel mis en krijg ik een zwart scherm. ik heb verschillende waardes geprobeerd.

[gastje01]

nlrb schreef op vrijdag 29 december 2017 @ 11:41:
@gastje01 Waarschijnlik dit probleem, zie oplossing daar: https://community.ubnt.co...USG-Rebooting/m-p/2128018

Beetje vertraagde reactie, maar ik moest m een aantal dagen laten lopen voor ik wist of t geholpen had, en gezien de uptime van meer dan 5 dagen nu lijkt dat zo te zijn :-)

[Muncher]

Muncher schreef op dinsdag 2 januari 2018 @ 08:23:
Heeft er iemand ervaring met het ophangen van AP’s zonder te boren? Bijv. met
magneten zoals bij een brandmelder

(https://www.brandpreventi...3fWcTFoc7qDUaAn4gEALw_wcB)

Ik heb ze uiteindelijk met Pattex Montagetape ophangen van de Praxis. Strip op de plate, paar uur laten drogen en toen de AP’s opgehangen. Hangen nog steeds stevig.

https://www.karwei.nl/ass...nschroeven-80kg/p/B483481

[Cartman!]

Shaggie_NB schreef op maandag 8 januari 2018 @ 23:24:
[...]

Wifi 2G op kanaal 12 en 13? Kunt beter 1, 6 of 11 nemen.

Kan ik sowieso doen maar daar ging m'n vraag niet over

[Shaggie_NB]

Cartman! schreef op dinsdag 9 januari 2018 @ 18:02:
[...]

Kan ik sowieso doen maar daar ging m'n vraag niet over

Je hebt toch problemen dit kan er aan meewerken..

[Cartman!]

Shaggie_NB schreef op dinsdag 9 januari 2018 @ 19:33:
[...]

Je hebt toch problemen dit kan er aan meewerken..

Ik heb al benoemd dat het bedraad zich ook voordoet, dat sluit toch aardig uit dat het het aan het wifi kanaal ligt

[Shaggie_NB]

Cartman! schreef op dinsdag 9 januari 2018 @ 19:34:
[...]

Ik heb al benoemd dat het bedraad zich ook voordoet, dat sluit toch aardig uit dat het het aan het wifi kanaal ligt

Dat wist ik niet... Waar dan?

[Cartman!]

Shaggie_NB schreef op dinsdag 9 januari 2018 @ 19:37:
[...]

Dat wist ik niet... Waar dan?

In het bericht wat je zelf citeerde toen je de kanalen noemde...

Het probleem lijkt niet in de WiFi te zitten maar in DHCP want een device dat verbindt krijgt geen IP toegewezen dan, ook niet als deze als statisch ingesteld wordt via de controller.

Daar staat geen desktop bij... dat stond in het bericht ervoor wel:

Had t op m'n desktop net ook...ik krijg via DHCP geen IP adres en daardoor kom ik er niet op, zodra ik op de client (desktop in dit geval) een vast IP instel is t probleem opgelost, dat sluit uit dat t aan WiFi ligt meteen.

[ Voor 26% gewijzigd door Cartman! op 09-01-2018 19:39 ]

[Shaggie_NB]

Cartman! schreef op dinsdag 9 januari 2018 @ 19:38:
[...]

In het bericht wat je zelf citeerde toen je de kanalen noemde...


[...]


Daar staat geen desktop bij... dat stond in het bericht ervoor wel:


[...]

Je zegt nergens dat het zich bedraad ook voordoet.. ik zie het niet..

[Cartman!]

Shaggie_NB schreef op dinsdag 9 januari 2018 @ 19:40:
[...]

Je zegt nergens dat het zich bedraad ook voordoet.. ik zie het niet..

Technisch gezien heb je gelijk misschien. Desktop = bedraad in mijn geval (en de meeste gevallen denk ik) of draait iedereen tegenwoordig alles over wifi? Ik zeg ieder geval daar wel dat Wifi uitgesloten is ook.

[ Voor 7% gewijzigd door Cartman! op 09-01-2018 19:41 ]

[Shaggie_NB]

Cartman! schreef op dinsdag 9 januari 2018 @ 19:41:
[...]

Technisch gezien heb je gelijk misschien. Desktop = bedraad in mijn geval (en de meeste gevallen denk ik) of draait iedereen tegenwoordig alles over wifi? Ik zeg ieder geval daar wel dat Wifi uitgesloten is ook.

Ik kom bij veel mensen waar alles op de wifi zit.. ook de desktops.
Maar terugkomend op jouw probleem. Ik had dit probleem ook vorige week en had na alles een reset gegeven te hebben nog steeds hetzelfde probleem. Nadat ik mijn switches heb gereset werkte het wel weer... En ik snap nog steeds niet wat er mis is gegaan...

[ Voor 4% gewijzigd door Shaggie_NB op 09-01-2018 20:05 ]

[Cartman!]

Shaggie_NB schreef op dinsdag 9 januari 2018 @ 19:47:
[...]Nadat ik mijn switches heb gereset werkte het wel weer... En ik snap nog steeds niet wat er mis is gegaan...

Done, zal de iPad weer terugzetten op DHCP en kijken of dat t oplost. zou best sneu zijn voor een enterprise systeem wel. Dank voor de suggestie vast

[burne]

Cartman! schreef op dinsdag 9 januari 2018 @ 19:41:
[...]

Technisch gezien heb je gelijk misschien. Desktop = bedraad in mijn geval (en de meeste gevallen denk ik) of draait iedereen tegenwoordig alles over wifi? Ik zeg ieder geval daar wel dat Wifi uitgesloten is ook.

Ik blijk maanden en maanden op wifi gezeten te hebben omdat het lipje van de rj45 afgebroken is en het kabeltje zich vrijwel direct weer uit de poort wriemelt. En ik heb het niet doorgehad. Ik heb een iMac met alle iToeters en iBellen aan, dus mijn desktop heeft het wifiwachtwoord van m'n telefoon geleerd en dan ga je ongemerkt over.

[the_cyberspace]

Iemand die me misschien kan helpen met de Unifi controller?

Ben sinds deze week bezig met virtualisatie en heb een Ubuntu server 16.04 VM draaiend wat dan compatible zou moeten zijn met de Unifi software. Het installeren ging probleemloos en met het "systemctl status unifi" commando zegt ie dat de controller active is en ook gestart.
Nu probeer ik de controller te bereiken via https://ipvandecontroller:8443" maar m`n browser blijft zoeken naar een verbinding. Heb diverse browsers geprobeerd nu, ook via http ipv https, en ben een beetje ten einde raad zeg maar. Iemand enig idee?

Ik heb een backup van de oude situatie en daar werkt de controller probleemloos via https://ipvandecontroller:8443

[RobertMe]

the_cyberspace schreef op woensdag 10 januari 2018 @ 12:30:
Iemand die me misschien kan helpen met de Unifi controller?

Ben sinds deze week bezig met virtualisatie en heb een Ubuntu server 16.04 VM draaiend wat dan compatible zou moeten zijn met de Unifi software. Het installeren ging probleemloos en met het "systemctl status unifi" commando zegt ie dat de controller active is en ook gestart.
Nu probeer ik de controller te bereiken via https://ipvandecontroller:8443" maar m`n browser blijft zoeken naar een verbinding. Heb diverse browsers geprobeerd nu, ook via http ipv https, en ben een beetje ten einde raad zeg maar. Iemand enig idee?

Ik heb een backup van de oude situatie en daar werkt de controller probleemloos via https://ipvandecontroller:8443

Is die VM verder wel bereikbaar vanaf je normale netwerk? (kun je hem pingen, bv?) Ik gok namelijk dat eerder daar iets m.b.t. port forwards, of de VM bridge vs NAT of zo fout gaat.

[the_cyberspace]

RobertMe schreef op woensdag 10 januari 2018 @ 12:44:
[...]

Is die VM verder wel bereikbaar vanaf je normale netwerk? (kun je hem pingen, bv?) Ik gok namelijk dat eerder daar iets m.b.t. port forwards, of de VM bridge vs NAT of zo fout gaat.

De VM is te pingen vanaf een ander ip/pc.

[DennusB]

Is er hier iemand met ervaring met het opzetten van een IPSEC tunnel tussen een Unifi USG en pfSense? Ik krijg t op de 1 of andere manier niet aan de praat...

[Poenzkie]

the_cyberspace schreef op woensdag 10 januari 2018 @ 12:30:
Iemand die me misschien kan helpen met de Unifi controller?

Ben sinds deze week bezig met virtualisatie en heb een Ubuntu server 16.04 VM draaiend wat dan compatible zou moeten zijn met de Unifi software. Het installeren ging probleemloos en met het "systemctl status unifi" commando zegt ie dat de controller active is en ook gestart.
Nu probeer ik de controller te bereiken via https://ipvandecontroller:8443" maar m`n browser blijft zoeken naar een verbinding. Heb diverse browsers geprobeerd nu, ook via http ipv https, en ben een beetje ten einde raad zeg maar. Iemand enig idee?

Ik heb een backup van de oude situatie en daar werkt de controller probleemloos via https://ipvandecontroller:8443

Al in de logfiles van de controller/mongodb gekeken? Dan kan je in ieder geval met zekerheid zeggen of de controller goed is opgestart. Kan ook zijn dat zijn poort al in gebruik is of dat hij een DB issue heeft.

Logs zijn te vinden in: /usr/lib/unifi/logs/