Dan ben ik bang dat het niet zal gaan werken. Wel jammer dat het niet lukt om jouw Experia Box oo deze manier aan te sluiten. Blijkbaar controleert de Experia Box dan of het IP adres binnen het één van de subnetten voor local area networks valt.

Ik heb voor de grap even een DHCP server in de 86.80.61.0/24 range aangemaakt en hierin neemt hij wel een ip adres. Uiteraard meteen even de telefoon getest en hij werkt!!

Zou je dan eens een /24 subnet binnen 172.16.0.0/12 kunnen gebruiken?

Bijvoorbeeld 172.16.0.0/24.

Als dat ook werkt dan kan ik weer een configuratiescript klaarzetten.

Ik heb hem nu ingesteld op 172.16.0.0/24 en daar werkt hij ook op. Hartstikke fijn!

Dank je voor het testen. Ik heb de configuratiescripts in het openingsbericht aangepast.

@wjb dank voor je reactie mbt de standaard IPv6 beveiliging, fijn.

Inmiddels ben ik zover dat ik de telefonie maar laat voor wat het is dus wil graag eth2 weer gaan inzetten voor DMZ-achtige zaken. Heb hiervoor alle interfaces gerelateerd aan VoIP ge-disabled, eth2 weer een vast IP gegeven en een DHCP server voor die range aangemaakt.

Ook wil ik weer een Guest-netwerk voor wifi gaan instellen, via een apart VLAN.

Nu wil ik dat zowel vanaf eth2 als het Wifi-guest VLAN standaard geen verbinding mag worden gemaakt naar eth1 (anders heeft het weinig zin om hier aparte netwerken voor in te richten) en uitzonderingen kunnen toevoegen waar nodig. Qua IPv4 kan ik dit goed regelen in de GUI, maar al deze firewall regels moet ik natuurlijk nu ook voor IPv6 opzetten, toch? Hoe pak ik dit het beste aan?

Zie dit bericht op het forum van Ubiquiti.

@wjb Goed idee, het toevoegen van die WAIT_ONLINE_METHOD en WAIT_ONLINE_TIMEOUT opties! Ik moest inderdaad ook altijd `restart igmp-proxy` draaien na een herstart; anders haperden de TV-ontvangers.

Ik heb je `set-WAIT_ONLINE_METHOD` Bash script bekeken en wil graag een verbeterde versie voorstellen. Mijn versie houdt rekening met meer edge cases en is bovendien eenvoudiger van opzet. Simpel gezegd voegt ‘ie de regel toe als ‘ie er nog niet is, maar als ‘ie er wel al is vervangt ‘ie de gehele regel door de juiste waarde (ongeacht of de regel uitgecomment is).

Voel je vrij om deze op te nemen in je configuratiescripts. ;-)

#!/bin/bash

# Define configuration file path.
CONFIG_FILE="/etc/default/networking"

# Define WAIT_ONLINE_METHOD and WAIT_ONLINE_TIMEOUT values.
WAIT_ONLINE_METHOD=ifup
WAIT_ONLINE_TIMEOUT=120

# Only continue if the configuration file exists.
if i -f $CONFIG_FILE ]; then
    # Set WAIT_ONLINE_METHOD option.
    if grep -Fq "WAIT_ONLINE_METHOD=" $CONFIG_FILE; then
        # The file already contains the WAIT_ONLINE_METHOD option, but it may contain an incorrect value or be commented out.
        # Replace the entire line with the correct value.
        sed -i "/WAIT_ONLINE_METHOD=/c\WAIT_ONLINE_METHOD=${WAIT_ONLINE_METHOD}" $CONFIG_FILE
    else
        # The WAIT_ONLINE_METHOD option is not yet present in the configuration file.
        # Append the correct value to the configuration file.
        echo "WAIT_ONLINE_METHOD=${WAIT_ONLINE_METHOD}" >> $CONFIG_FILE
    fi

    # Set WAIT_ONLINE_TIMEOUT option.
    if grep -Fq "WAIT_ONLINE_TIMEOUT=" $CONFIG_FILE; then
        # The file already contains the WAIT_ONLINE_TIMEOUT option, but it may contain an incorrect value or be commented out.
        # Replace the entire line with the correct value.
        sed -i "/WAIT_ONLINE_TIMEOUT=/c\WAIT_ONLINE_TIMEOUT=${WAIT_ONLINE_TIMEOUT}" $CONFIG_FILE
    else
        # The WAIT_ONLINE_TIMEOUT option is not yet present in the configuration file.
        # Append the correct value to the configuration file.
        echo "WAIT_ONLINE_TIMEOUT=${WAIT_ONLINE_TIMEOUT}" >> $CONFIG_FILE
    fi
fi

Ziet er goed uit. 

Ik zal hem opnemen in een volgende versie van de configuratiescripts.

Overigens draait dit script momenteel alleen bij de eerste reboot na de upgrade van de firmware. Het bestand /etc/default/networking bevat dan de regels sowieso nog niet.

Het simpel toevoegen van de twee regels is feitelijk voldoende maar toch is het goed om rekening te houden met alle scenario's.

@wjb Precies, wellicht zet iemand een bestaande configuratie om op basis van jouw configuratie. Zo heb ik het ook gedaan (alles handmatig aan de hand van jouw config.boot), vandaar dat ik inderdaad van mening ben dat het beter is om alle cases af te vangen. Je weet immers niet hoe iemand z’n configuratie er uit ziet. ;-)

Fijne zondag!

Heeft iemand een tip hoe ik het beste de config.gateway.json kan aanpassen op een Windows computer?

Als ik een kleine aanpassing maak in Notepad++ of de editor in WinSCP dan komt mijn USG in een provisiong loop. Is er een beter manier om een paar aanpassingen te maken?

Ik wil nml de IPTV op eth2 zetten, dat blijkt stabieler te zijn.

Heeft de USG geen GUI waarmee dergelijke wijzigingen doorgevoerd kunnen worden? 

Helaas is het inderdaad zo dat lang niet alles via de Unifi controller software geconfigureerd kan worden. 

Een provisioning loop houdt in dat er toch een foutje zit in de json.

Zie ook dit artikel van ubiquiti.

Kijk dus in de server.log en zoek naar "commit error". Daar zou je moeten kunnen zien wat de fout is.

Kan je anders eens de gewijzigde stukjes van de json hier posten. Zowel voor de wijziging als na de wijziging.

Dat kan idd wel in de GUI, maar als ik het goed begrijp moet ik daarnaast ook nog de igmp-proxy aanzetten? (ik weet niet zeker of dat hetzelfde is als de IGMP snooping wat een setting is in de UI.

config.gateway.json voor aanpassing:

{"protocols": {
	"igmp-proxy": {
		"interface": {
			"eth0.4": {
				"alt-subnet": [
					"0.0.0.0/0"
				],
				"role": "upstream",
				"threshold": "1"
			},
			"eth1": {
				"alt-subnet": [
					"0.0.0.0/0"
				],
				"role": "downstream",
				"threshold": "1"
			}
		}
}

config.gateway.json na aanpassing:

{"protocols": {
	"igmp-proxy": {
		"interface": {
			"eth0.4": {
				"alt-subnet": [
					"0.0.0.0/0"
				],
				"role": "upstream",
				"threshold": "1"
			},
			"eth1": {
				"alt-subnet": [
					"0.0.0.0/0"
				],
				"role": "disabled",
				"threshold": "1"
			}
			"eth2": {
				"alt-subnet": [
					"0.0.0.0/0"
				],
				"role": "downstream",
				"threshold": "1"
			}
		}
}

"alt-subnet": [ "0.0.0.0/0" ], achter eth1 verwijderen

Voor de Edgerouter4 (FW 2.0.9) lijkt die bootstrap fix niet nodig te zijn?
De inhoud van mijn /etc/default/networking:

# Configuration for networking init script being run during
# the boot sequence

# Set to 'no' to skip interfaces configuration on boot
#CONFIGURE_INTERFACES=yes

# Don't configure these interfaces. Shell wildcards supported/
#EXCLUDE_INTERFACES=

# Set to 'yes' to enable additional verbosity
#VERBOSE=no

Ik hoef nooit de IGMP proxy te herstarten, en na een reboot van de ER4 werken de IPTV ontvangers zonder problemen.
Met pidof igmpproxy zie ik ook dat deze draait en met show ip multicast mfc en show ip multicast interfaces zie ik dat het multicastverkeer wordt geforward

Ook ik draai een ER-4 met firmware versie 2.0.9 maar toch moest ik zonder die bootstrap fix wel degelijk een "restart igmp-proxy" geven om de TV ontvangers zonder haperingen te laten werken. Het is een timing kwestie. Als de IGMP proxy server gestart wordt nadat vlan 4 (IPTV) operationeel is, dan werkt alles goed. Wordt de IGMP proxy server gestart voordat vlan 4 (IPTV) operationeel is, dan heb je last van haperingen. Om de afhankelijkheid van die timing te voorkomen doe je er toch verstandig aan die bootstrap fix door te voeren.

Mijn setup werkte niet stabiel, sommige zenders bleven zwart, naar een andere zender was nog trager dan normaal, begin starten werkte niet altijd en er waren soms haperingen waardoor ik de IGMP proxy moest herstarten.

Maar het is me nu gelukt om de LAN2 poort op mijn Unifi USG te gebruiken voor TV (met een eigen netwerk), en dat lijkt een stuk stabieler en sneller te werken. Dus zeker een tip!

Nadat ik deze instructies had gevonden had ik het zo voor elkaar. Hulde!

https://gathering.tweakers.net/forum/view_message/63292180

Ter naslagwerk voor anderen

NEW Pi-hole update (Core 5.2 & FTL 5. 3.1) fixed;   "oorspronkelijke afzender IP-adres" probleem bij gebruik van het eerder genoemde extra hardcoded-dns redirect trucje ➡️ Status in query log, is nu dan: 

(forwarded to localhost#54) EN laat hierbij nu dan vervolgens voortaan dus wèl de correcte oorspronkelijke hostname zien, of te wel die van voor de additionele hardcoded-dns redirect (ipv dat je dus standaard het IP.nr. van de edgerouter doorgegeven krijgt, dus 192.168.2.254).

In het kort nog even de situatie omschreven: 

DHCP door je Edgerouter met hierop DNS naar Pihole ingesteld, op je Pihole conditional forward instellen, voor de extra hard-coded dns redirect 'an sich' voeg je de 2 eerder genoemde extra NAT regels toe op je Edgerouter. 

De Pihole update is: Analyze EDNS(0) records #851
We highlight the Client Subnet (ECS) feature to obtain client IPs even when they are hidden behind a NAT or a deputy DNS server. See Discourse discussion for further technical details. This feature can be used to unveil the real IP addresses of clients even when there used to be the router’s IP address for all clients (if supported by the router).

Bron: 
https://pi-hole.net/2020/11/28/pi-hole-core-web-v5-2-and-ftl-v5-3-released/

@wjb,

ik zag je ook terugkomen op het KPN Smart TV app forum. Zoals je weet gebruik ik nu 2x de VIP5202. 
Stel dat ik besluit om via de smart app te gaan kijken, dan heb ik wel een KPN tv abbo nodig maar geen vlan4 aan de WAN kant toch? Of gebruik die app onder water toch vlan4

Ik heb geen ervaring met de smart-TV app maar aangezien ook de iTV app op tablet en telefoon puur over Internet loopt verwacht ik dat ook de smart-TV geen gebruik maakt van vlan 4.

Overigens is er geen haar op mijn hoofd die ook maar een seconde overweegt om via de smart-TV televisie te gaan kijken. De functionaliteit en beeldkwaliteit ligt beduidend lager dan via een TV ontvanger en dan heb je mijns inziens de twee belangrijkste aspecten van een goede TV-beleving wel te pakken.

Dat heb ik ook uitgezocht bij het bestellen van een pakket en een nieuwe tv.

De smart-tv app werkt gewoon op KPN internet. Daar heb je verder niks anders voor nodig (tv-vlan of multicast etc).

Hi, ik heb gisteren het laatste script gedraait, en de firmware van mijn EdgeRouter 6P geupgrade naar 1.0.9, maar heb nu problemen bij het opstarten van mijn interactive TV, foutcode 842. Daarna blijft hij hangen op 85%. Enig idee wat dit kan zijn?

Heb je de TV ontvanger ook volledig uit en aan gezet?

Geef in de cli eens het commando "restart igmp-proxy".

Geeft dit een ander resultaat?

Beide reeds gedaan, en blijf de foutcode 842 krijgen.

tevens router al gereboot.  
 

Welk configuratiescript heb je gebruikt en via welke poort is de TV ontvanger aangesloten?