[Ubiquiti & IPTV] Ervaringen & Discussie

[dezonnebril]

ptjuh schreef op maandag 6 september 2021 @ 14:53:
[...]


Nadat KPN wat dingen had gewijzigd,altijd fijn , heb ik een reboot gedaan van de USG3 en na bovenstaande vraag ben ik van alles gaan uitzoeken. Helaas was het simpeler dan ik dacht...

Onderstaande comando uitgevoerd en tada....

unifiadmin@HVA-USG-GW:~$ restart igmp-proxy
Stopping IGMP proxy
Starting IGMP proxy service

Iemand enig idee of het te scripten is dat de IGMP-Proxy na een herstart nogmaals een herstart krijgt? Dan hoef ik niets meer uit te voeren

Hier een stukje uit mijn git config (readme), ik heb onderstaande eenmalig gedaan op mijn EdgeRouter om dit probleem te tackelen. Geen idee of je dit ook kunt doen op je USG.

code:

# Script: restart-igmp-proxy.sh
# Location: /config/scripts/post-config.d/
# Permissions: chmod 755
# Purpose: Fix hanging IGMP-PROXY after reboot (KPN IPTV ISSUE)
##################################################
sudo vbash -c 'cat > /config/scripts/post-config.d/restart-igmp-proxy.sh' << EOF
#!/bin/bash
/bin/vbash -ic 'restart igmp-proxy'
EOF
##################################################

# MAKE SCRIPT EXECUTABLE AT BOOT
sudo chmod 755 /config/scripts/post-config.d/restart-igmp-proxy.sh

[Coolhva]

ptjuh schreef op maandag 6 september 2021 @ 14:53:
[...]


Nadat KPN wat dingen had gewijzigd,altijd fijn , heb ik een reboot gedaan van de USG3 en na bovenstaande vraag ben ik van alles gaan uitzoeken. Helaas was het simpeler dan ik dacht...

Onderstaande comando uitgevoerd en tada....

unifiadmin@HVA-USG-GW:~$ restart igmp-proxy
Stopping IGMP proxy
Starting IGMP proxy service

Iemand enig idee of het te scripten is dat de IGMP-Proxy na een herstart nogmaals een herstart krijgt? Dan hoef ik niets meer uit te voeren

https://github.com/coolhv.../blob/master/igmpproxy.sh

[OMX2000]

Ik heb momenteel xs4all. En ik overweeg om de overstap te maken naar KPN aangezien ik nog weinig toegevoegde waarde zie van xs4all. De enige unieke dienst waar ik in geïnteresseerd was was het /29 subnet wat je kon aanvragen.

Nu is mijn enige twijfel nog of er nog wat nadelen zijn tussen het runnen van glas via kpn tov xs4all, en dan natuurlijk gebruik makend van een USG Pro. Ik zie dat KPN bijvoorbeeld wel 1 GBIT aanbiedt op het nieuwe adres, en xs4all blijft steken op 500 Mbit. En ja ik weet dat ik met de USG Pro nie heel veel voordeel van de 1 Gbit aansluiting zal hebben.

[loeberce]

OMX2000 schreef op maandag 6 september 2021 @ 15:49:
En ja ik weet dat ik met de USG Pro nie heel veel voordeel van de 1 Gbit aansluiting zal hebben.

Waarom niet? Mijn USG Pro kan mijn Gbit aansluiting van T-Mobile prima aan. Zonder IPS/IDS weliswaar maar daar zie ik zelf het nut niet zo van in.

[nklaver234]

Vandaag is de monteur geweest om de glasvezel te installeren. Het is geen gpon maar een 'normale' point-to-point bverbinding. Gekke is wel dat alleen bij Kpn, Solcon en youfone er een 1-Gbit verbinding mogelijk is, XS4all 500-mbit en de rest enkel 100-mbit.

Na installatie heb ik het KPN modem Box 12 verwijderd en de netwerkkabel rechtstreeks aangesloten op de UDM PRO.
Nu heb ik internet en de tv werkt. Echter stokt het beeld zo iedere 3 tot 5 minuten en en soms loopt de tv ontvanger vast met de melding stb-nmc-400. Op de afstandsbediening een zender omhoog en omlaag is dan voldoende om het weer verder te laten lopen.

Ik heb een apart vlan gemaakt voor iptv. DPI en Thread management staan beiden uit maar dat maakt geen verschil. Iemand een idee waar dit vandaan kan komen?

[Coolhva]

nklaver234 schreef op maandag 13 september 2021 @ 20:03:
Vandaag is de monteur geweest om de glasvezel te installeren. Het is geen gpon maar een 'normale' point-to-point bverbinding. Gekke is wel dat alleen bij Kpn, Solcon en youfone er een 1-Gbit verbinding mogelijk is, XS4all 500-mbit en de rest enkel 100-mbit.

Na installatie heb ik het KPN modem Box 12 verwijderd en de netwerkkabel rechtstreeks aangesloten op de UDM PRO.
Nu heb ik internet en de tv werkt. Echter stokt het beeld zo iedere 3 tot 5 minuten en en soms loopt de tv ontvanger vast met de melding stb-nmc-400. Op de afstandsbediening een zender omhoog en omlaag is dan voldoende om het weer verder te laten lopen.

Ik heb een apart vlan gemaakt voor iptv. DPI en Thread management staan beiden uit maar dat maakt geen verschil. Iemand een idee waar dit vandaan kan komen?

igmp-proxy al herstart?

[3DDude]

Coolhva schreef op maandag 13 september 2021 @ 21:26:
[...]


igmp-proxy al herstart?

Volgens mij hadden ze igmp uit die pro gesloopt. dat was het probleem daarmee / met iptv toch?

https://community.ui.com/...-b44c-2beb85e37772?page=2

je kan hier stemmen, maar kwa firmware doen ze volgens mij vrij weinig bij Ubiquiti

[ Voor 27% gewijzigd door 3DDude op 13-09-2021 21:35 ]

[nklaver234]

edit:

gisteravond de decoder op een radiozender gezet een gaan slapen. Vanmorgen liep de radio nog steeds.
Daarna gewisseld naar een tv-zender en die heeft daarna een half uur prima gewerkt. Nu naar het werk. Vanavond eens kijken of het nu echt goed blijft werken.

igmp-proxyressetten lukt mij niet maar ik voer telkens dit scriptje uit:
[code]sh -c "$(curl -s https://raw.githubusercon...er/docs/iptv/install.sh)"[/code]
dat lijkt ook tot een reset te leiden.

Nu nog even kijken of de glas/utp media converter er tussenuit kan.

Ik snap er niets van.

Ik heb deze handleiding gevolgd: https://github.com/fabian.../blob/master/docs/iptv.md

UDM Pro gereset en nu doet die het helemaal niet meer. Configuratie nagelopen maar zie niets geks.

KPN TV geeft nu een fout 365 opstarten niet mogelijk.

via de ssh 'ip -4 addr show dev iptv' geeft geen enkele output meer.
'ip route list' geeft alleen nog de /24 netwerken en de ppp0.

Internet werkt nog maar ip tv helemaal niet meer. 'restart igmp-proxy' geeft '-sh: restart: not found'

Als ik de box12 aansluit dan werkt de decoder wel weer.

Deze netwerk setting had ik uitgezet maar nu weer aan:
Had Multi-host gewijzigd in Auto en Enable LLPD-MED en Enable topology change notification uitgezet.

Nu weer aan. Nu werkt het dus weer 3 tot 5 min. Dan een Freeze. Dan werkt het weer 3 tot 5 nimuten en dan de melding melding stb-nmc-400.

C: bash

# sh -c "$(curl -s https://raw.githubusercontent.com/fabianishere/udm-kernel-tools/master/docs/iptv/install.sh)"
What is your WAN port?
  1. eth8 (WAN 1, RJ45)
  2. eth9 (WAN 2, SFP+)
Enter WAN port [default: eth8]: 1
Is IPTV traffic carried over a separate VLAN? ([Y]es or [N]o): Y
Enter VLAN ID [default: 4]: 4
Which addresses are used for IPTV traffic?
Enter WAN ranges [default: 213.75.0.0/16 217.166.0.0/16]: 
Which LANs are allowed to receive IPTV traffic?
  1: br0                   [IPv4 Address: 192.168.2.1]
  2: br1003                [IPv4 Address: 10.0.0.1]
  3: br25                  [IPv4 Address: 192.168.3.1]
  4: br400                 [IPv4 Address: 192.168.5.1]
Enter LAN interfaces separated by spaces [default: br0]: 4
Generated the following configuration:
  WAN Interface:      eth8
  IPTV VLAN (WAN):    4
  IPTV Ranges (WAN):  213.75.0.0/16 217.166.0.0/16
  LAN Interfaces:     br0 br400
IPTV boot script successfully installed at /mnt/data/on_boot.d/15-iptv.sh
See https://github.com/fabianishere/udm-kernel-tools/blob/master/docs/iptv.md for more information
Should the container be started immediately? ([Y]es or [N]o): Y
Starting container...
143979a5efe5633b1be0139849a0b77c02a38a32a25efb103ba937aff96910b1
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
abb3e1d795d32a6494d1b3ea391bce55a475d077ebfa4f4129ddd2a03ad5bbf0
udm-iptv: Obtaining IP address for VLAN interface...
udhcpc: started, v1.33.1
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending select for 10.174.116.100
udhcpc: lease of 10.174.116.100 obtained, lease time 3600
mv: can't rename '/etc/resolv.conf.19': Resource busy
udm-iptv: NATing IPTV network ranges (if necessary)...
udm-iptv: Setting up igmpproxy..
udm-iptv: Starting igmpproxy..
# ip -4 addr show dev iptv
34: iptv@eth8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.174.116.100/22 brd 10.174.119.255 scope global iptv
       valid_lft forever preferred_lft forever
# ip route list
10.0.0.0/24 dev br1003 proto kernel scope link src 10.0.0.1 
10.174.116.0/22 dev iptv proto kernel scope link src 10.174.116.100 
192.168.2.0/24 dev br0 proto kernel scope link src 192.168.2.1 
192.168.3.0/24 dev br25 proto kernel scope link src 192.168.3.1 
192.168.5.0/24 dev br400 proto kernel scope link src 192.168.5.1 
195.190.228.85 dev ppp0 proto kernel scope link src 86.87.91.161 
213.75.112.0/21 via 10.174.116.1 dev iptv metric 234 
# 

[ Voor 92% gewijzigd door nklaver234 op 14-09-2021 08:52 ]

[nero355]

3DDude schreef op maandag 13 september 2021 @ 21:30:
Volgens mij hadden ze igmp uit die pro gesloopt. dat was het probleem daarmee / met iptv toch?

https://community.ui.com/...-b44c-2beb85e37772?page=2

je kan hier stemmen, maar kwa firmware doen ze volgens mij vrij weinig bij Ubiquiti

Mee eens, maar dat topic is outdated info ondertussen : fabianishere in "[Ubiquiti & IPTV] Ervaringen & Discussie"

/EDIT :

3DDude schreef op dinsdag 14 september 2021 @ 16:48:
je verwijst naar een post / met een beta firmware die een 404 geeft

Dat komt omdat jij geen account hebt aangemaakt met Beta Access Enabled

[ Voor 20% gewijzigd door nero355 op 14-09-2021 20:09 ]

[3DDude]

nero355 schreef op dinsdag 14 september 2021 @ 16:02:
[...]

Mee eens, maar dat topic is outdated info ondertussen : fabianishere in "[Ubiquiti & IPTV] Ervaringen & Discussie"

je verwijst naar een post / met een beta firmware die een 404 geeft

[nklaver234]

Helaas, toen ik thuis kwam toch weer vastgelopen (geen idee hoelang die het nu gedaan had. Zender omhoog/omlaag en helaas na zo'n 10-15min liep die weer vast.

Ik ga nu maar eens proberen telkens apparaten los te koppelen van het netwerk en hoop dat ik zo kan uitzoeken of er iets dwars zit in het netwerk waar de tv slecht op reageert.

[Coolhva]

nklaver234 schreef op dinsdag 14 september 2021 @ 17:51:
Helaas, toen ik thuis kwam toch weer vastgelopen (geen idee hoelang die het nu gedaan had. Zender omhoog/omlaag en helaas na zo'n 10-15min liep die weer vast.

Ik ga nu maar eens proberen telkens apparaten los te koppelen van het netwerk en hoop dat ik zo kan uitzoeken of er iets dwars zit in het netwerk waar de tv slecht op reageert.

https://github.com/fabian.../blob/master/docs/iptv.md

debug van iptv container aanzetten, je kan ook podmap ps, podman stop <containerid>, podman start <containerid> proberen.

[nklaver234]

Nu al een paar dagen stabiel!
Oorzaak: een chromecast V2. Zodra ik die weer insteek is het na 10-15 minuten afgelopen.

Iemand anders die ook een UDM PRO heeft rechtstreeks op de glasvezel waarbij de chromecast het wel doet?
Dan hoor ik graag welke chromecast je gebruikt of wat je gedaan hebt om het werkend te krijgen.

edit:
Hmmm, Blijft lastig.

Ene moment duurt het langer dan de andere keer. Telkens als ik denk het gevonden te hebben loopt het uiteindelijk toch weer vast.

up/down op de afstandsbediening lost het op.
Dit ook:
[code]
# /mnt/data/on_boot.d/15-iptv.sh
c7c746e6eafef5d882f120afbd4e755facf13ea0425c3975b262c6d439dc80e0
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
861460714df42594f58396ac77c719f0dd590f6e1b9d674e884b9684b40fadd9
#
[/code]

[q]
[code]
# podman logs iptv
udm-iptv: Obtaining IP address for VLAN interface...
udhcpc: started, v1.33.1
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending select for 10.174.116.100
udhcpc: lease of 10.174.116.100 obtained, lease time 3600
mv: can't rename '/etc/resolv.conf.17': Resource busy
udm-iptv: NATing IPTV network ranges (if necessary)...
udm-iptv: Setting up igmpproxy..
udm-iptv: Starting igmpproxy..
adding VIF, Ix 0 Fl 0x0 IP 0x0102a8c0 br0, Threshold: 1, Ratelimit: 0
adding VIF, Ix 1 Fl 0x0 IP 0x0105a8c0 br400, Threshold: 1, Ratelimit: 0
adding VIF, Ix 2 Fl 0x0 IP 0x6474ae0a iptv, Threshold: 1, Ratelimit: 0
Joining group 224.0.0.2 on interface br0
Joining group 224.0.0.22 on interface br0
Joining group 224.0.0.2 on interface br400
Joining group 224.0.0.22 on interface br400
RECV Membership query from 192.168.2.1 to 224.0.0.1
RECV Membership query from 192.168.5.1 to 224.0.0.1
RECV V2 member report from 192.168.5.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.5.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.2.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.2.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.2.217 to 239.255.255.251
Inserted route table entry for 239.255.255.251 on VIF #0
Joining group 239.255.255.251 on interface iptv
RECV V2 member report from 192.168.2.18 to 224.0.1.1
Inserted route table entry for 224.0.1.1 on VIF #0
Joining group 224.0.1.1 on interface iptv
RECV V2 member report from 192.168.2.3 to 239.254.127.63
Inserted route table entry for 239.254.127.63 on VIF #0
Joining group 239.254.127.63 on interface iptv
RECV V2 member report from 192.168.5.1 to 233.89.188.1

[...]

Adding MFC: 192.168.2.3 -> 233.89.188.1, InpVIf: 2
Adding MFC: 192.168.2.5 -> 233.89.188.1, InpVIf: 2
Adding MFC: 192.168.2.4 -> 233.89.188.1, InpVIf: 2
Adding MFC: 192.168.2.1 -> 233.89.188.1, InpVIf: 2
RECV Membership query from 192.168.2.1 to 224.0.0.1
RECV Membership query from 192.168.5.1 to 224.0.0.1
The IGMP message was local multicast. Ignoring.
RECV V2 member report from 192.168.2.217 to 239.255.255.251
Updated route entry for 239.255.255.251 on VIF #0
Adding MFC: 192.168.2.21 -> 239.255.255.251, InpVIf: 2
Adding MFC: 192.168.2.22 -> 239.255.255.251, InpVIf: 2
The IGMP message was local multicast. Ignoring.
RECV V2 member report from 192.168.2.5 to 239.254.127.63
Updated route entry for 239.254.127.63 on VIF #0
RECV V2 member report from 192.168.2.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.2.1 to 233.89.188.1
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.2.18 to 224.0.1.60
Updated route entry for 224.0.1.60 on VIF #0
Route activation request from 10.174.116.100 for 233.89.188.1 is from myself. Ignoring.
RECV V2 member report from 192.168.2.5 to 233.89.188.1
Updated route entry for 233.89.188.1 on VIF #0
Adding MFC: 192.168.2.3 -> 233.89.188.1, InpVIf: 2
Adding MFC: 192.168.2.5 -> 233.89.188.1, InpVIf: 2
Adding MFC: 192.168.2.4 -> 233.89.188.1, InpVIf: 2
Adding MFC: 192.168.2.1 -> 233.89.188.1, InpVIf: 2
RECV V2 member report from 192.168.5.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.2.1 to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.5.56 to 224.3.2.6
Updated route entry for 224.3.2.6 on VIF #1
Adding MFC: 213.75.167.58 -> 224.3.2.6, InpVIf: 2
RECV V2 member report from 192.168.2.18 to 224.0.1.1
Updated route entry for 224.0.1.1 on VIF #0
RECV V2 member report from 192.168.5.1 to 233.89.188.1
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.2.217 to 239.255.3.22
Updated route entry for 239.255.3.22 on VIF #0
RECV V2 member report from 192.168.2.1 to 224.0.0.251
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.5.1 to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.5.56 to 224.0.251.124
Updated route entry for 224.0.251.124 on VIF #1
Adding MFC: 217.166.225.124 -> 224.0.251.124, InpVIf: 2
The IGMP message was local multicast. Ignoring.
RECV V2 member report from 192.168.5.1 to 224.0.0.251
The IGMP message was from myself. Ignoring.
RECV V2 member report from 192.168.5.56 to 225.0.71.1
Updated route entry for 225.0.71.1 on VIF #1
The IGMP message was local multicast. Ignoring.
[/code][/]

In de logs zag ik de ip-adressen van de google apparaten terugkomen. Na deze uitgezet te hebben was de tv goed. Eén voor één weer aangezet.
Probleem lijkt in de chromecast te zitten. Als ik die weer aanzet dan loopt de tv 10-15 minuten later vast.

Iemand nog een idee wat ik in het netwerk kan doen zodat de chromecast de tv niet verstoord maar ik er nog wel naar kan streamen?

[ Voor 91% gewijzigd door nklaver234 op 18-09-2021 08:20 ]

[joudejans76]

Geachte allen;

Onderwerp: IPTV Foutcode STB-NMC-400

Ook ik start nu hier een topic na een aantal uren met kpn backend te hebben gekeken naar mijn problemen met iptv.

Situatie is als volgt:
FTU --> Gpon
USG-3p
USG8-60 w
- IPTV kpn
- Synology Nas
- Synology Nas
- Andere switch
- Andere switch
- UAP AC Pro
- UAP AC Pro


Ik heb de handleiding van https://www.vanachterberg...teway-kpn-ftth-iptv-ipv6/ gevolgd. Alles werkt behalve iptv vloeiend. Ik krijg om de zoveel tijd freezes en een vastloper met een blauw scherm en de melding : Foutcode STB-NMC-400

Graag ontvang ik hulp / uitleg wat ik moet doen.

Ik heb een vlan aangemaakt
kpn.sh geupload en rechten 0755 aangepast.
json file geupload.
Router gerestart en provisioned. etc etc..


Hieronder post ik mijn json file. mochten jullie eenzelfde setup hebben en een werkende json file ontvang ik graag de jsonfile met aanpassing zodat ik deze kan uploaden daar mijn programmeer kennis niet zo best is.
Mijn dank voor het meedenken en helpen word enorm gewaardeerd.

Met vriendelijke groet,

Johan

[-----------------------------SCRIPT JSON -----------------------------------]

{
"system": {
"offload": {
"ipv4": {
"forwarding": "enable",
"gre": "enable",
"pppoe": "enable",
"vlan": "enable"
},
"ipv6": {
"forwarding": "enable",
"pppoe": "enable",
"vlan": "disable"
}
}
},
"firewall": {
"ipv6-name": {
"WANv6_LOCAL" : {
"rule": {
"1": {
"action": "accept",
"description": "Allow ICMPv6",
"log": "enable",
"protocol": "icmpv6"
},
"2": {
"action": "accept",
"description": "DHCPv6",
"destination": {
"port": "546"
},
"protocol": "udp",
"source": {
"port": "547"
}
}
}
},
"WANv6_IN" : {
"rule": {
"1": {
"action": "accept",
"description": "Allow ICMPv6",
"log": "enable",
"protocol": "icmpv6"
}
}
}
}
},
"interfaces": {
"ethernet": {
"eth0": {
"dhcp-options": {
"default-route": "no-update",
"default-route-distance": "1",
"name-server": "no-update"
},
"description": "WAN",
"vif": {
"4": {
"address": [
"dhcp"
],
"description": "IPTV",
"dhcp-options": {
"client-option": [
"send vendor-class-identifier "IPTV_RG";",
"request subnet-mask, routers, rfc3442-classless-static-routes;"
],
"default-route": "no-update",
"default-route-distance": "210",
"name-server": "no-update"
},
"ip": {
"source-validation": "loose"
},
"mtu": "1500"
},
"6": {
"firewall": {
"in": {
"ipv6-name": "WANv6_IN",
"name": "WAN_IN"
},
"local": {
"ipv6-name": "WANv6_LOCAL",
"name": "WAN_LOCAL"
},
"out": {
"ipv6-name": "WANv6_OUT",
"name": "WAN_OUT"
}
},
"pppoe": {
"2": {
"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"
},
"out": {
"ipv6-name": "WANv6_OUT",
"name": "WAN_OUT"
}
},
"ipv6": {
"address": {
"autoconf": "''"
},
"dup-addr-detect-transmits": "1",
"enable": "''"
},
"default-route": "auto",
"mtu": "1500",
"name-server": "auto",
"password": "kpn",
"user-id": "kpn"
}
}
}
}
},
"eth1": {
"description": "LAN",
"ipv6": {
"address": {
"autoconf": "''"
},
"dup-addr-detect-transmits": "1",
"router-advert": {
"cur-hop-limit": "64",
"link-mtu": "0",
"managed-flag": "true",
"max-interval": "600",
"name-server": [
"2606:4700:4700::1111",
"2606:4700:4700::1001"
],
"other-config-flag": "false",
"prefix": {
"::/64": {
"autonomous-flag": "true",
"on-link-flag": "true",
"valid-lifetime": "2592000"
}
},
"radvd-options": "RDNSS 2606:4700:4700::1111 2606:4700:4700::1001 {};",
"reachable-time": "0",
"retrans-timer": "0",
"send-advert": "true"
}
}
}
}
},
"protocols": {
"igmp-proxy": {
"interface": {
"eth0.4": {
"alt-subnet": [
"0.0.0.0/0"
],
"role": "upstream",
"threshold": "1"
},
"eth1.4": {
"alt-subnet": [
"0.0.0.0/0"
],
"role": "downstream",
"threshold": "1"
}
}
},
"static": {
"interface-route6": {
"::/0": {
"next-hop-interface": {
"pppoe2": "''"
}
}
}
}
},
"port-forward": {
"wan-interface": "pppoe2"
},
"service": {
"dns": {
"forwarding": {
"except-interface": [
"pppoe2"
]
}
},
"nat": {
"rule": {
"5000": {
"description": "MASQ all traffic to IPTV network",
"destination": {
"address": "0.0.0.0/0"
},
"log": "disable",
"outbound-interface": "eth0.4",
"protocol": "all",
"type": "masquerade"
},
"6001": {
"outbound-interface": "pppoe2"
},
"6002": {
"outbound-interface": "pppoe2"
},
"6003": {
"outbound-interface": "pppoe2"
}
}
}
}
}

[mvug]

@hermanh je noemt in je post over igmp-proxy dat je interfaces disabled om “ruis” te voorkomen. Kun je dit eens uitleggen?

[__Kevind__]

joudejans76 schreef op woensdag 22 september 2021 @ 16:52:

Ik heb de handleiding van https://www.vanachterberg...teway-kpn-ftth-iptv-ipv6/ gevolgd. Alles werkt behalve iptv vloeiend. Ik krijg om de zoveel tijd freezes en een vastloper met een blauw scherm en de melding : Foutcode STB-NMC-400

Ik zit ook te denken om de KPN zooi te vervangen voor het Ubiquiti spul. Na vele sites te hebben doorgelezen en de vlee topics kwam ik onder andere deze post tegen op het KPN forum. Ik weet niet zeker of je er wat aan hebt maar het is het proberen waard. Bij hem lijkt het aan de switch te liggen icm met igmp snooping.

[kramon]

Ik ben wel benieuwd op wat voor versie de USG3 gebruikers hier zitten? Ik heb 'm al tijden niet geupdate (zit nog op: 4.4.50.5272448), terwijl ik al m'n andere Unifi apparatuur wel up to date heb. Dat vind ik toch wat eng qua veiligheid.

[Zjemm]

weet iemand hoe IPV6 op de unifi USG werkt?
ik zit sinds kort op het KPN (VDSL) netwerk en kan gebruik maken van IPV6

ik heb op mn WAN interface (PPPOE) IPV6 op DHCP staan met een prefix delegation size van 48
ik had op mn WAN interface een IPV6 adres verwacht maar dat gebeurd niet.

pas als ik op een van mn LAN netwerken IPV6 aan zet (Prefix delegation aan) en een prefix ID van bijvoorbeeld 1
Dan krijgt mn USG netwerk (lan) een IPV6 adres, en dan krijgen mijn clients ook IPV6 adressen.

so far so good, behalve dan dat ik een v6 adres op mn WAN ook had verwacht maar goed. misschien denk ik te old skool ipv4


maar hoe werkt dit nou in de praktijk? op ipv4 vragen mijn clients via dhcp een v4 adres aan de USG en die krijgen ze dan van de USG.
werkt dat op v6 ook nog steeds zo? Krijgt de USG van KPN het V6 block, en deelt de USG daaruit aan de hand van de prefix ID weer adressen uit aan de clients? de USG is dan nog steeds gateway.


Hoe ziet het vervolgens met firewalling? voorheen had je je interne netwerk wat toegang had naar buiten (genat)

verkeer naar binnen (genat) met port forwarding voor bijvoorbeeld een webserver op v4

maar met v6 zijn het allemaal publieke adressen en is NAT niet nodig.
Hoe ga ik dan de USG firewall rule inrichten? gewoon hetzelfde als op v4? maar dan zonder port forwarding in geval van inkomend verkeer.?


laatste, Hoe ga ik om met static v6 adressen? mn webserver moet natuurlijk altijd hetzelfde v6 adres hebben net als met v4

[nero355]

Zjemm schreef op vrijdag 24 september 2021 @ 11:23:
weet iemand hoe IPV6 op de unifi USG werkt?

Voor zover ik weet is dat nog steeds heel erg buggy en niet volledig bruikbaar, maar ik kan het mis hebben...

maar hoe werkt dit nou in de praktijk?

Krijgt de USG van KPN het V6 block, en deelt de USG daaruit aan de hand van de prefix ID weer adressen uit aan de clients? de USG is dan nog steeds gateway.

Hoe ziet het vervolgens met firewalling? voorheen had je je interne netwerk wat toegang had naar buiten (genat)

verkeer naar binnen (genat) met port forwarding voor bijvoorbeeld een webserver op v4

maar met v6 zijn het allemaal publieke adressen en is NAT niet nodig.
Hoe ga ik dan de USG firewall rule inrichten? gewoon hetzelfde als op v4? maar dan zonder port forwarding in geval van inkomend verkeer.?


laatste, Hoe ga ik om met static v6 adressen? mn webserver moet natuurlijk altijd hetzelfde v6 adres hebben net als met v4

Je zou eens rond kunnen kijken in Het grote IPv6 topic voor meer informatie

Zo effe snel in het kort :
- IPv6 hoef je alleen te Firewallen.
- Static IP's kan je op twee manieren configureren : Statisch zoals je dat gewend bent of half automatisch.
- In principe zou de USG de boel inderdaad intern verder moeten verdelen, maar jij moet het deels zelf instellen.

Succes alvast!

[Coolhva]

nero355 schreef op vrijdag 24 september 2021 @ 16:35:
[...]

Voor zover ik weet is dat nog steeds heel erg buggy en niet volledig bruikbaar, maar ik kan het mis hebben...


[...]

Je zou eens rond kunnen kijken in Het grote IPv6 topic voor meer informatie

Zo effe snel in het kort :
- IPv6 hoef je alleen te Firewallen.
- Static IP's kan je op twee manieren configureren : Statisch zoals je dat gewend bent of half automatisch.
- In principe zou de USG de boel inderdaad intern verder moeten verdelen, maar jij moet het deels zelf instellen.

Succes alvast!

Heel kort ff een antwoord:

IPv6 werkt goed op de USG.
De USG heeft (op elke interface) een IPv6 link-local adres, wanneer de USG via IPv6 prefix delegation een prefix opvraagt en toewijst aan de LAN interface zal KPN voor die prefix een route aanmaken dat ze het verkeer naar het link-local adres op de PPPoE interface sturen.

De prefix delegatie is redelijk vast, dus gewoon vast IPv6 adres instellen op je apparaat instellen.

[jzoin2]

Wellicht een noop vraag, bij de gen2 switch daar zitten een glasvezel poort op. Maandag krijg ik mn kpn glasvezel installatie binnen, glasmodem en router.

Maar ik kan toch in principe de glasmodem direct aansluiten op de ubi switch?

[SilencerNL]

jzoin2 schreef op zaterdag 25 september 2021 @ 19:26:
Wellicht een noop vraag, bij de gen2 switch daar zitten een glasvezel poort op. Maandag krijg ik mn kpn glasvezel installatie binnen, glasmodem en router.

Maar ik kan toch in principe de glasmodem direct aansluiten op de ubi switch?

Ja, dat heb ik hier ook. Glasvezel direct in mijn USG 4 Pro. Scheelt weer een media converter kastje in de meterkast

[nero355]

jzoin2 schreef op zaterdag 25 september 2021 @ 19:26:
Wellicht een noop vraag, bij de gen2 switch daar zitten een glasvezel poort op. Maandag krijg ik mn kpn glasvezel installatie binnen, glasmodem en router.

Maar ik kan toch in principe de glasmodem direct aansluiten op de ubi switch?

SilencerNL schreef op zondag 26 september 2021 @ 09:14:
Ja, dat heb ik hier ook. Glasvezel direct in mijn USG 4 Pro. Scheelt weer een media converter kastje in de meterkast

Ligt er natuurlijk aan wat je krijgt :
- SFP module die je ergens uit kan halen en in je Switch of Router proppen kan altijd als je daar een vrije SFP (WAN) Poort voor hebt!
In geval van de Switch maak je dan effe een losse VLAN aan om het een en ander door te sturen richting je Router zoals we dat deden bij de oude Bridged IPTV Setup voor de IPTV kastjes
- Krijg je echter een NTU die alleen UTP heeft dan houdt het verhaal al gauw op!

[pitchdown]

Laatste dagen wederom met kpn de bekende 400 melding.
Ik draai al het kpn scrip uit het kpn-forum inclusief separaat vlan voor iptv.
Iemand met nog een valide oplossing voor dit probleem?

[Ralphie]

pitchdown schreef op zondag 26 september 2021 @ 22:05:
Laatste dagen wederom met kpn de bekende 400 melding.
Ik draai al het kpn scrip uit het kpn-forum inclusief separaat vlan voor iptv.
Iemand met nog een valide oplossing voor dit probleem?

Hier ook dat sinds een week de NMC-400 melding weer om de haverklap. USG3 icm met de Flex mini en 2 AP's. Herstarten van de igmp-proxy heeft ook maar voor een paar minuten effect. Wel dacht ik dat het een stuk beter ging toen ik de HUE Bridge loskoppelde (las wat dingen over mDNS?) en toen leek het probleem verholpen. Biertje gepakt om het te vieren, maar helaas na verloop van tijd toch weer de NMC-400 problemen. Stream pauzeren en weer starten helpt wel, dat komt denk ik doordat je dan van multicast naar unicast gaat?

Ook heb ik de KPN app op de TV (LG Oled) dat werkt vlekkeloos. Weet iemand hoe die streams aangeboden worden? Ook multicast (maar dan zou ik de problemen ook met de app moeten ondervinden) of is via de app altijd unicast? Heb een extra managed switch aangeschaft om zo maar met VLANS te gaan werken, maar naar ik het nu lees gaat dat dit probleem niet oplossen.

Edit: lees ik nou goed dat de Flex Mini helemaal geen IGMP snooping ondersteund? Krijg steeds meer spijt van de overstap naar Unifi.. Wellicht dat VLANS nog wat gaan helpen om dan alleen maar de "flooden" binnen dat VLAN. Dat verklaard het gedrag wel voor een gedeelte, want heb een week of 2 geleden de TPlinks (met IGMP snooping) ingeruild voor de flex-mini (ook omdat de andere unifi 8 port switches nergens te leveren zijn), om zo volledige "Unifi" te zijn.

[ Voor 15% gewijzigd door Ralphie op 27-09-2021 12:55 ]

[nklaver234]

edit:
geen idee wat het nu was maar na een paar resets en stroomloos maken van de Aris tv ontvanger werkte het ineens.
Hopelijk blijft het nu stabiel.

Ik heb nu ook glas rechtstreeks in mijn UDM Pro. Echter krijg ik iptv nog niet aan de praat.

Ik had deze handleiding gevolgd en die deed het via utp.

Nu heb ik de configuratie opnieuw doorlopen door

code:

sh -c "$(curl -s https://raw.githubusercontent.com/fabianishere/udm-kernel-tools/master/docs/iptv/install.sh)"

En voor sfp+ eth9 gekozen maar helaas. nog geen iptv. Ik zal die vraag nog eens in het iptv topic stellen.

code:

Welcome to UbiOS

By logging in, accessing, or using the Ubiquiti product, you
acknowledge that you have read and understood the Ubiquiti
License Agreement and agree to be bound by its terms.

root@192.168.2.1's password: 
  ___ ___      .__________.__
 |   |   |____ |__\_  ____/__|
 |   |   /    \|  ||  __) |  |   (c) 2010-2021
 |   |  |   |  \  ||  \   |  |   Ubiquiti Inc.
 |______|___|  /__||__/   |__|
            |_/                  http://www.ui.com

      Welcome to UniFi Dream Machine!
# sh -c "$(curl -s https://raw.githubusercontent.com/fabianishere/udm-kernel-too
ls/master/docs/iptv/install.sh)"
What is your WAN port?
  1. eth8 (WAN 1, RJ45)
  2. eth9 (WAN 2, SFP+)
Enter WAN port [default: eth8]: 2
Is IPTV traffic carried over a separate VLAN? ([Y]es or [N]o): Y
Enter VLAN ID [default: 4]: 4
Which addresses are used for IPTV traffic?
Enter WAN ranges [default: 213.75.0.0/16 217.166.0.0/16]: 
Which LANs are allowed to receive IPTV traffic?
  1: br0                   [IPv4 Address: 192.168.2.1]
  2: br1003                [IPv4 Address: 10.0.0.1]
  3: br25                  [IPv4 Address: 192.168.3.1]
  4: br400                 [IPv4 Address: 192.168.5.1]
Enter LAN interfaces separated by spaces [default: br0]: 4
Generated the following configuration:
  WAN Interface:      eth9
  IPTV VLAN (WAN):    4
  IPTV Ranges (WAN):  213.75.0.0/16 217.166.0.0/16
  LAN Interfaces:     br0 br400
IPTV boot script successfully installed at /mnt/data/on_boot.d/15-iptv.sh
See https://github.com/fabianishere/udm-kernel-tools/blob/master/docs/iptv.md for more information
Should the container be started immediately? ([Y]es or [N]o): Y
Starting container...
6d85ceb8f958ae20eec4875c26870c0b4cfcfd2b9aa2edfd60e06d3faef575a6
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
WARNING: The same type, major and minor should not be used for multiple devices.
f8b0f0d5bcbe6e920fc04d3905937e347d88c7517a65b08f15a5233749acef55
udm-iptv: Obtaining IP address for VLAN interface...
udhcpc: started, v1.33.1
udhcpc: sending discover
udhcpc: sending discover
udhcpc: sending select for 10.23.146.106
udhcpc: lease of 10.23.146.106 obtained, lease time 3600
mv: can't rename '/etc/resolv.conf.18': Resource busy
udm-iptv: NATing IPTV network ranges (if necessary)...
udm-iptv: Setting up igmpproxy..
udm-iptv: Starting igmpproxy..
#

[nero355]

Ralphie schreef op maandag 27 september 2021 @ 11:22:
Edit: lees ik nou goed dat de Flex Mini helemaal geen IGMP snooping ondersteund?

Voor zover ik weet is dat zo sinds die is uitgebracht inderdaad!

Krijg steeds meer spijt van de overstap naar Unifi...

Tja, kwestie van inlezen en als je dat niet doet dan kan je dat soort dingen verwachten...

Wellicht dat VLANS nog wat gaan helpen om dan alleen maar de "flooden" binnen dat VLAN. Dat verklaard het gedrag wel voor een gedeelte, want heb een week of 2 geleden de TPlinks (met IGMP snooping) ingeruild voor de flex-mini (ook omdat de andere unifi 8 port switches nergens te leveren zijn), om zo volledige "Unifi" te zijn.

De beste non-UniFi oplossing zijn de Netgear switches die KPN ook verkoopt : https://tweakers.net/netw...s-gs_p283301/vergelijken/

Zie : https://apparatuurvoorthu...42/switch-netgear-gs105e/

[La1974]

Ralphie schreef op maandag 27 september 2021 @ 11:22:
[...]


Hier ook dat sinds een week de NMC-400 melding weer om de haverklap. USG3 icm met de Flex mini en 2 AP's. Herstarten van de igmp-proxy heeft ook maar voor een paar minuten effect. Wel dacht ik dat het een stuk beter ging toen ik de HUE Bridge loskoppelde (las wat dingen over mDNS?) en toen leek het probleem verholpen. Biertje gepakt om het te vieren, maar helaas na verloop van tijd toch weer de NMC-400 problemen. Stream pauzeren en weer starten helpt wel, dat komt denk ik doordat je dan van multicast naar unicast gaat?

Ook heb ik de KPN app op de TV (LG Oled) dat werkt vlekkeloos. Weet iemand hoe die streams aangeboden worden? Ook multicast (maar dan zou ik de problemen ook met de app moeten ondervinden) of is via de app altijd unicast? Heb een extra managed switch aangeschaft om zo maar met VLANS te gaan werken, maar naar ik het nu lees gaat dat dit probleem niet oplossen.

Edit: lees ik nou goed dat de Flex Mini helemaal geen IGMP snooping ondersteund? Krijg steeds meer spijt van de overstap naar Unifi.. Wellicht dat VLANS nog wat gaan helpen om dan alleen maar de "flooden" binnen dat VLAN. Dat verklaard het gedrag wel voor een gedeelte, want heb een week of 2 geleden de TPlinks (met IGMP snooping) ingeruild voor de flex-mini (ook omdat de andere unifi 8 port switches nergens te leveren zijn), om zo volledige "Unifi" te zijn.

Bij mij werkt dit al maanden vlekkeloos. Al heb ik tussen de USG3 en de Flex Mini nog wel een USW-Lite zitten.

Verder ook een VLAN voor IPTV icm een LG OLED tv.

[Roylee]

Even een snel vraagje. Heb al gezocht in dit topic en kwam een reactie tegen van 27 jul 2021 maar geen reactie gevonden hierop. Het betreft een eigen IPv6 DNS servers (adguard of tegen de tijd mn eigen synology DNS server) om in te vullen in de json ipv de huidige kpn ipv6 dns servers die ik in de json kan vinden. Dit heb ik geprobeerd. Maar na een reprovision heb ik geen IPv6 meer in mn netwerk. Heb ik een fout in de json of is dit gewoon niet mogelijk?
Alvast bedankt heren!

[Coolhva]

Roylee schreef op dinsdag 28 september 2021 @ 01:00:
Even een snel vraagje. Heb al gezocht in dit topic en kwam een reactie tegen van 27 jul 2021 maar geen reactie gevonden hierop. Het betreft een eigen IPv6 DNS servers (adguard of tegen de tijd mn eigen synology DNS server) om in te vullen in de json ipv de huidige kpn ipv6 dns servers die ik in de json kan vinden. Dit heb ik geprobeerd. Maar na een reprovision heb ik geen IPv6 meer in mn netwerk. Heb ik een fout in de json of is dit gewoon niet mogelijk?
Alvast bedankt heren!

Is zeker wel mogelijk! Je moet ze op twee plekken wijzigen in de json.

Je kan ze er ook uithalen en IPv4 intern gebruiken.

[roccothehelper]

nero355 schreef op donderdag 2 september 2021 @ 15:43:
[...]

"Use The Force Search Luke!"


[...]

Het is een GPON kastje en geen simpele mediaconverter!


[...]

Yup!


[...]

Misschien handig om te weten :

Bij Delta zou weleens het volgende aan de hand kunnen zijn in jouw gebied :
- Nieuwe klant dus IPTV gaat gewoon via de WAN i.p.v. een aparte IPTV VLAN aan de WAN kant.
- Hierbij heb je als het goed is ook het hele Multicast en IGMP Snooping gezeik niet...
- De SFP die in de Genexis 7840 gaat en die je waarschijnlijk erbij krijgt kan je zo in de UDM Pro of een Ubiquiti switch met SFP poorten prikken!

Echter...

1. Weet ik niet zeker of bovenstaande voor jouw gebied geldt!
2. Ik zou als ik de keuze tussen Delta en KPN had altijd voor KPN kiezen, maar ik hoef dan ook geen IPTV erbij te hebben

* nero355 is een ex-KPN xDSL klant en zit nu in een Caiway (van Delta!) Glasvezel gebied, maar mist toch wel stiekem de voordelen van een KPN verbinding...

Binnen een maand zit ik ook op Delta ipv Caiway. In de hoop dat een nieuw abonnement ons over zet op IPTV over WAN. Ons Caiway abonnement loopt al jaren lang en heeft nog VLAN's die niet leuk meespelen met de UDM Pro.

[rjhilbrink]

Oeps. Kan duidelijk niet lezen..

[ Voor 98% gewijzigd door rjhilbrink op 28-09-2021 20:20 ]

[Roylee]

Coolhva schreef op dinsdag 28 september 2021 @ 11:31:
[...]


Is zeker wel mogelijk! Je moet ze op twee plekken wijzigen in de json.

Je kan ze er ook uithalen en IPv4 intern gebruiken.

Deze toch? Want dit had ik inderdaad gedaan. Dan ga ik het nogmaals proberen!

[Coolhva]

Roylee schreef op woensdag 29 september 2021 @ 18:24:
[...]

[Afbeelding]
Deze toch? Want dit had ik inderdaad gedaan. Dan ga ik het nogmaals proberen!

Je mag de hele regels verwijderen, inclusief name-server [ en de regel met ], daarna en de radvd- options regel.

[Roylee]

Coolhva schreef op woensdag 29 september 2021 @ 18:56:
[...]


Je mag de hele regels verwijderen, inclusief name-server [ en de regel met ], daarna en de radvd- options regel.

Heb het zelfde bestand wat ik eerder had aangepast naar de ad guard dns servers er weer opgezet. Het enige wat ik moest hebben was wat meer geduld met wachten tot hij weer volledig up was.
Bedankt voor de toelichting!

[Roylee]

Na een aantal weken vlekkeloos te hebben gewerkt. Heb ik nu problemen met IPTV. De beroemde stb-nmc-400 error. Ik heb het IPTV kastje al in een VLAN gezet maar het blijft hetzelfde probleem helaas. Het beeld stottert en geluid valt weg. En na een aantal seconden verschijnt de bovenstaande error.
Wat dient er aangepast te worden om dit goed te krijgen? Dit hele topic staat vol met deze problemen. Maar de oplossing heb ik nog niet direct gevonden.
Alvast bedankt!

[La1974]

Roylee schreef op zondag 10 oktober 2021 @ 20:51:
Na een aantal weken vlekkeloos te hebben gewerkt. Heb ik nu problemen met IPTV. De beroemde stb-nmc-400 error. Ik heb het IPTV kastje al in een VLAN gezet maar het blijft hetzelfde probleem helaas. Het beeld stottert en geluid valt weg. En na een aantal seconden verschijnt de bovenstaande error.
Wat dient er aangepast te worden om dit goed te krijgen? Dit hele topic staat vol met deze problemen. Maar de oplossing heb ik nog niet direct gevonden.
Alvast bedankt!

Als het altijd heeft gewerkt en je heb niets gewijzigd, dan waarschijnlijk IGMP herstarten.

[nklaver234]

Roylee schreef op zondag 10 oktober 2021 @ 20:51:
Na een aantal weken vlekkeloos te hebben gewerkt. Heb ik nu problemen met IPTV. De beroemde stb-nmc-400 error. Ik heb het IPTV kastje al in een VLAN gezet maar het blijft hetzelfde probleem helaas. Het beeld stottert en geluid valt weg. En na een aantal seconden verschijnt de bovenstaande error.
Wat dient er aangepast te worden om dit goed te krijgen? Dit hele topic staat vol met deze problemen. Maar de oplossing heb ik nog niet direct gevonden.
Alvast bedankt!

Bij mij was het een Google chromecast die 400 melding veroorzaakte. Als eens geprobeerd om chromecast en firetv achtingen uit te schakelen?

[arjanhs]

Coolhva schreef op woensdag 29 september 2021 @ 18:56:
[...]


Je mag de hele regels verwijderen, inclusief name-server [ en de regel met ], daarna en de radvd- options regel.

Schakel je op die wijze IPv6 uit op je netwerk ? Gebruik het script nu ook in mijn USG, maar van mijn mag IPv6 wel uit.

Dus als ik het goed begrijp als ik de regels name-server tot ], en de radvd-options regels verwijder dan staat IPv6 uit ?

Arjan

[Coolhva]

arjanhs schreef op maandag 11 oktober 2021 @ 10:39:
[...]


Schakel je op die wijze IPv6 uit op je netwerk ? Gebruik het script nu ook in mijn USG, maar van mijn mag IPv6 wel uit.

Dus als ik het goed begrijp als ik de regels name-server tot ], en de radvd-options regels verwijder dan staat IPv6 uit ?

Arjan

Ho, ho ho! Hold your horses!

Wat is je probleem? Dat je apparaten gebruik maken van de IPV6 DNS servers die in de config.gateway.json staan en daardoor niet de (dns verzoeken, lees:)websites blokkeert welke anders wel zouden worden geblokkeerd door de DNS servers die je ingesteld hebt op IPv4.

IPv6 uitschakelen is helemaal niet nodig en heeft misschien zelfs een nadelig effect omdat IPv6 steeds meer gebruikt wordt en soms sneller is als IPv4. De DNS servers uit de json halen is voldoende. Ik heb als voorbeeld de KPN met IPTV VLAN json gepakt en de DNS servers eruit gehaald en deze hier gepost:

https://gist.github.com/c...61a02dba9774a1c609fd5ae46

Zoals je ziet zijn de DNS servers voor IPv6 verdwenen en is de RADVD regel ook verdwenen. Dit kan je ook toepassen in de andere configs die op mijn github repo staan.

[ Voor 4% gewijzigd door Coolhva op 11-10-2021 16:44 ]

[arjanhs]

Coolhva schreef op maandag 11 oktober 2021 @ 16:42:
[...]
Wat is je probleem? Dat je apparaten gebruik maken van de IPV6 DNS servers die in de config.gateway.json staan en daardoor niet de (dns verzoeken, lees:)websites blokkeert welke anders wel zouden worden geblokkeerd door de DNS servers die je ingesteld hebt op IPv4.

Dat is inderdaad wat ik wil bereiken, gebruik nu AdGuard en wil alle DNS verzoeken daar langs hebben, zie nj af en toe dat advertenties wel geblockt worden en soms niet en verdenk hier IPv6 van. Heb nu deze regels er tussen uit gehaald en krijg nu op mijn clients geen ipv6 dns entry meer, dus zouden nu alle dns request langs adguard gaan ipv nog via ipv6 direct naar buiten.

Kan ook natuurlijk adguard op ipv6 instellen, maar ben ook aan het testen met een edgerouter waarop ik ipv6 wel volledig uitgeschakeld heb. Als ik dan switch dan gaat het elkaar tegen werken. En ipv4 begrijp ik, ipv6 nog niet.

[Roylee]

La1974 schreef op zondag 10 oktober 2021 @ 21:16:
[...]


Als het altijd heeft gewerkt en je heb niets gewijzigd, dan waarschijnlijk IGMP herstarten.

Dit heb ik inderdaad geprobeerd. Heb ook het igmpproxy.sh script op de USG gezet maar dit bracht niet het gewenste resultaat.

nklaver234 schreef op zondag 10 oktober 2021 @ 22:54:
[...]

Bij mij was het een Google chromecast die 400 melding veroorzaakte. Als eens geprobeerd om chromecast en firetv achtingen uit te schakelen?

Dit kan ik nog wel proberen. Heb 2 chromecasts in het netwerk. Echter heb ik voor de IPTV een aparte VLAN. Kan dit dan nog steeds storen?

[Coolhva]

Roylee schreef op dinsdag 12 oktober 2021 @ 18:25:
[...]

Dit heb ik inderdaad geprobeerd. Heb ook het igmpproxy.sh script op de USG gezet maar dit bracht niet het gewenste resultaat.


[...]


Dit kan ik nog wel proberen. Heb 2 chromecasts in het netwerk. Echter heb ik voor de IPTV een aparte VLAN. Kan dit dan nog steeds storen?

Ik zou het proberen, technisch gezien is alles mogelijk ;-).

[nklaver234]

Roylee schreef op dinsdag 12 oktober 2021 @ 18:25:

Dit kan ik nog wel proberen. Heb 2 chromecasts in het netwerk. Echter heb ik voor de IPTV een aparte VLAN. Kan dit dan nog steeds storen?

Ik heb ook een apart vlan voor iptv maar toch stoorde de chromecast.
Ik heb overigens een udm pro en geen usg.
Even de stroom van de chromecast’s afhalen kan het snel duidelijk maken. Ben benieuwd wat het resultaat bij jou is.

[neorider]

Binnenkort wordt bij mij ook glasvezel van KPN aangesloten en kan ik mijn Unifi omgeving gaan configureren.
Hiervoor heb ik de scripts e.d. gevonden van CoolHVA. Dank voor de duidelijke uitleg tot zover.

Wel heb ik nog een vraag voordat ik aan de slag ga. Momenteel heb ik VDSL van T-Mobile met de ExperiaBox en daarachter mijn Unifi omgeving (USG3, Switch en AP's). Daarop heb ik de Wifi uiteraard en VPN op geconfigureerd. Kan ik de handleiding volgen en mijn configuratie aanpassen zodat deze klaar is voor KPN of is het raadzaam om alles te resetten en van scretch af aan opnieuw op te bouwen?

[Tootoo]

@Coolhva, hartelijk dank voor je uitgebreide website en scripts!

Mijn situatie was, waarschijnlijk door mijn onervarenheid, een beetje een gepuzzel. Ik heb mijn USG met switch altijd ingesteld gehad via bridge modus, maar dat werkt bij mij al een tijd lang niet meer. Het werd dus tijd om over te gaan op IPTV, waarbij ik zowel internet als VPN al ingesteld had (toendertijd nog via de oude interface).

Uiteindelijk bleek het super eenvoudig te zijn:
1. JSON neerzetten binnen de cloud key.
2. kpn.sh aanpassen voor VPN: delete van VPN eth0 moest eth0.6 zijn, een issue wat ik vond van reacties in 1 van de posts. En uitrollen.
3. Herstarten maar.

Kostte me dan wel een paar uur uitzoeken, maar alles draait als een zonnetje

[Coolhva]

Tootoo schreef op woensdag 13 oktober 2021 @ 14:08:
@Coolhva, hartelijk dank voor je uitgebreide website en scripts!

Mijn situatie was, waarschijnlijk door mijn onervarenheid, een beetje een gepuzzel. Ik heb mijn USG met switch altijd ingesteld gehad via bridge modus, maar dat werkt bij mij al een tijd lang niet meer. Het werd dus tijd om over te gaan op IPTV, waarbij ik zowel internet als VPN al ingesteld had (toendertijd nog via de oude interface).

Uiteindelijk bleek het super eenvoudig te zijn:
1. JSON neerzetten binnen de cloud key.
2. kpn.sh aanpassen voor VPN: delete van VPN eth0 moest eth0.6 zijn, een issue wat ik vond van reacties in 1 van de posts. En uitrollen.
3. Herstarten maar.

Kostte me dan wel een paar uur uitzoeken, maar alles draait als een zonnetje

Goed en fijn om te horen! De oplossing van de VPN is eerlijk gezegd het uitvinken van VLAN 6 bij je WAN instellingen. Je WAN instellingen moeten op DHCP staan met VLAN uitgevinkt.

[nero355]

neorider schreef op woensdag 13 oktober 2021 @ 08:23:
Binnenkort wordt bij mij ook glasvezel van KPN aangesloten en kan ik mijn Unifi omgeving gaan configureren.
Hiervoor heb ik de scripts e.d. gevonden van CoolHVA. Dank voor de duidelijke uitleg tot zover.

Wel heb ik nog een vraag voordat ik aan de slag ga. Momenteel heb ik VDSL van T-Mobile met de ExperiaBox en daarachter mijn Unifi omgeving (USG3, Switch en AP's). Daarop heb ik de Wifi uiteraard en VPN op geconfigureerd. Kan ik de handleiding volgen en mijn configuratie aanpassen zodat deze klaar is voor KPN of is het raadzaam om alles te resetten en van scretch af aan opnieuw op te bouwen?

Ligt er een beetje aan hoe je de VPN toestanden hebt geregeld :
- Alles via webGUI van de UniFi Controller ?
Begin dan met een lege USG en zet later de VPN Settings erbij.

- Veel JSON of CLI hulp nodig gehad ?
Dan zou je even goed moeten kijken wat je moet/kan mergen uit jouw config.JSON en de KPN Setup config.JSON dus dat is wel een flinke klus!

Succes alvast!

[Tootoo]

@Coolhva en @nero355 dan snap ik nu ook waarom het op deze manier werkt.

ik had eerst alles via de cli ingesteld (zowel WAN met vlan id / pppoe samen met username / password als alle vpn zaken). Als ik dan over ging naar de classic settings dan kon ik ook niet de wan instellingen meer aanpassen, dan kreeg ik een fout over de payload. Iets wat ik niet krijg via het nieuwe instellingen scherm.

Aan de ene kant denk ik dan: afblijven nu, want het werkt. Maar voor de zekerheid: aangezien de VPN al ingesteld is, zou ik via de nieuwe front end enkel de vlan settings weg moeten kunnen halen binnen de WAN instellingen + het kpn.sh bestand weer terug zetten naar hoe het stond?

[nero355]

Tootoo schreef op woensdag 13 oktober 2021 @ 16:34:
ik had eerst alles via de cli ingesteld (zowel WAN met vlan id / pppoe samen met username / password als alle vpn zaken). Als ik dan over ging naar de classic settings dan kon ik ook niet de wan instellingen meer aanpassen, dan kreeg ik een fout over de payload. Iets wat ik niet krijg via het nieuwe instellingen scherm.

Dat is wel gek, want PPPoE inclusief VLAN kan je gewoon via de webGUI instellen

Alleen het IPTV gedeelte heeft heel veel CLI en config.JSON aanpassingen nodig!

Aan de ene kant denk ik dan: afblijven nu, want het werkt. Maar voor de zekerheid: aangezien de VPN al ingesteld is, zou ik via de nieuwe front end enkel de vlan settings weg moeten kunnen halen binnen de WAN instellingen + het kpn.sh bestand weer terug zetten naar hoe het stond?

Dat durf ik effe niet te zeggen...

[Tootoo]

nero355 schreef op woensdag 13 oktober 2021 @ 16:40:
[...]

Dat is wel gek, want PPPoE inclusief VLAN kan je gewoon via de webGUI instellen

Alleen het IPTV gedeelte heeft heel veel CLI en config.JSON aanpassingen nodig!


[...]

Dat durf ik effe niet te zeggen...

Dat stuk van de payload is ook de reden waarom ik er een paar uur mee bezig was. Ik kwam er niet omheen. Maar het lijkt er op dat ik van de VPN instellingen af mag blijven in de oude en nieuwe schermen, het lijkt nog altijd goed te staan.

Wat ik zal doen is een backup maken, de vlan id weghalen / uitzetten in de WAN, en de originele KPN.sh terug zetten om te zien wat er gebeurd. Zal het jullie laten weten en verder het IPTV topic niet vervuilen met VPN zaken

[Coolhva]

Tootoo schreef op woensdag 13 oktober 2021 @ 16:34:
@Coolhva en @nero355 dan snap ik nu ook waarom het op deze manier werkt.

ik had eerst alles via de cli ingesteld (zowel WAN met vlan id / pppoe samen met username / password als alle vpn zaken). Als ik dan over ging naar de classic settings dan kon ik ook niet de wan instellingen meer aanpassen, dan kreeg ik een fout over de payload. Iets wat ik niet krijg via het nieuwe instellingen scherm.

Aan de ene kant denk ik dan: afblijven nu, want het werkt. Maar voor de zekerheid: aangezien de VPN al ingesteld is, zou ik via de nieuwe front end enkel de vlan settings weg moeten kunnen halen binnen de WAN instellingen + het kpn.sh bestand weer terug zetten naar hoe het stond?

Dat kan maar het kpn.sh bestand aanpassen werkt ook. Mocht je ooit een update van kpn.sh doen dan moet je dezelfde aanpassing weer doen.

Ik zou het vinkje uitzetten en de originele kpn.sh plaatsen.

[Roylee]

Coolhva schreef op dinsdag 12 oktober 2021 @ 20:45:
[...]


Ik zou het proberen, technisch gezien is alles mogelijk ;-).

nklaver234 schreef op dinsdag 12 oktober 2021 @ 23:27:
[...]

Ik heb ook een apart vlan voor iptv maar toch stoorde de chromecast.
Ik heb overigens een udm pro en geen usg.
Even de stroom van de chromecast’s afhalen kan het snel duidelijk maken. Ben benieuwd wat het resultaat bij jou is.

Het heeft helaas niet geholpen. Alle chromecasts staan uit. Maar nog steeds dezelfde storing en dus melding.
Ik kan echter wel gewoon kijken als ik na switchen van zender gelijk op de pause knop druk en na een seconde weer op play.

[Coolhva]

Roylee schreef op woensdag 13 oktober 2021 @ 17:43:
[...]


[...]


Het heeft helaas niet geholpen. Alle chromecasts staan uit. Maar nog steeds dezelfde storing en dus melding.
Ik kan echter wel gewoon kijken als ik na switchen van zender gelijk op de pause knop druk en na een seconde weer op play.

Ik denk dat de igmp proxy over zijn nek gaat op dat moment. Je zou de IGMP proxy moeten herstarten, chromecasts voor 24 uur uit je netwerk halen en kijken of het probleem nog voorkomt.

[Roylee]

Coolhva schreef op woensdag 13 oktober 2021 @ 17:51:
[...]


Ik denk dat de igmp proxy over zijn nek gaat op dat moment. Je zou de IGMP proxy moeten herstarten, chromecasts voor 24 uur uit je netwerk halen en kijken of het probleem nog voorkomt.

Ga ik dat proberen. Ik had IGMP op de native LAN wel uitgezet. Moet dit voor beide (v)LAN's aan staan om goed te werken? Of alleen op de VLAN waar de IPTV in zit?

[neorider]

nero355 schreef op woensdag 13 oktober 2021 @ 16:17:
[...]

Ligt er een beetje aan hoe je de VPN toestanden hebt geregeld :
- Alles via webGUI van de UniFi Controller ?
Begin dan met een lege USG en zet later de VPN Settings erbij.

- Veel JSON of CLI hulp nodig gehad ?
Dan zou je even goed moeten kijken wat je moet/kan mergen uit jouw config.JSON en de KPN Setup config.JSON dus dat is wel een flinke klus!

Succes alvast!

Thanks. Dan wordt het in mijn geval een reset en eens kijken of het gaat lukken. De 18de wordt de glasvezel aangesloten en kan ik de herfstvakantie mooi gebruiken om dit werkend te krijgen

[Coolhva]

Roylee schreef op woensdag 13 oktober 2021 @ 18:04:
[...]

Ga ik dat proberen. Ik had IGMP op de native LAN wel uitgezet. Moet dit voor beide (v)LAN's aan staan om goed te werken? Of alleen op de VLAN waar de IPTV in zit?

IGMP snooping wat mij betreft op alles aanzetten. Proxy alleen op IPTV vlans

[Roylee]

Coolhva schreef op woensdag 13 oktober 2021 @ 21:34:
[...]


IGMP snooping wat mij betreft op alles aanzetten. Proxy alleen op IPTV vlans

IGMP Snooping staat nu aan op beide LAN's.
IGMP proxy staat zoals jij hem hebt geschreven. Op eth1.661. Dit VLAN is voor IPTV hier in huis.
Helaas nog geen verbetering.
Moet wel zeggen, heb 1 'domme' switch nog in huis zitten die geen IGMP ondersteund. Kan dit roet in het eten gooien? Zit niet tussen de USG en de STB maar verderop in het netwerk.

Hierbij een link naar een overzicht van mijn netwerk.

[ Voor 10% gewijzigd door Roylee op 14-10-2021 20:49 . Reden: Netwerk diagram toegevoegd ]

[Tootoo]

@Coolhva en @nero355 ik kan bij deze melden dat ik nu via de nieuwe interface de vlan zaken er uit kon gooien voor de WAN en met de originele KPN.sh werkt alles vloeiend nu!

[nero355]

Roylee schreef op woensdag 13 oktober 2021 @ 22:12:
Moet wel zeggen, heb 1 'domme' switch nog in huis zitten die geen IGMP ondersteund.

Kan dit roet in het eten gooien?

Zolang die aan het einde van je netwerk zit als verdeler van 1 VLAN en dus aangesloten zit op een Untagged Poort alsof die een Client is zou het mee moeten vallen, maar als in dat VLAN ook veel Multicast verkeer zit en je IPTV kastjes ook daarin zitten dan kan je problemen verwachten...

Zit niet tussen de USG en de STB maar verderop in het netwerk.

Een simpele schets van je netwerk inclusief VLAN's kan een hoop duidelijker maken!

[Roylee]

nero355 schreef op donderdag 14 oktober 2021 @ 15:21:
[...]

Zolang die aan het einde van je netwerk zit als verdeler van 1 VLAN en dus aangesloten zit op een Untagged Poort alsof die een Client is zou het mee moeten vallen, maar als in dat VLAN ook veel Multicast verkeer zit en je IPTV kastjes ook daarin zitten dan kan je problemen verwachten...


[...]

Een simpele schets van je netwerk inclusief VLAN's kan een hoop duidelijker maken!

Achter deze switches zitten geen IPTV kastjes verder.

Hierbij een link naar een overzicht van mijn netwerk.

[ Voor 0% gewijzigd door Roylee op 14-10-2021 20:26 . Reden: Link aangepast ]

[nero355]

Roylee schreef op donderdag 14 oktober 2021 @ 20:18:
Achter deze switches zitten geen IPTV kastjes verder.

Maar wel apparaten die Multicasten en dus issues kunnen veroorzaken volgens je overzicht :

Hierbij een link naar een overzicht van mijn netwerk.

- TV
- Printer
- DLNA meuk
- IP camera
- enz.

[carlob]

Is het mogelijk is om de USG3 eerst vooraf helemaal gereed te maken ter vervanging van de EB van KPN? Het idee is dat thuis ondertussen alles door gaan terwijl ik daarmee bezig ben (ivm vrouw+pubers...).

Ik probeer de USG3 bekabeld aan mijn netwerk te hangen met de verwachting dat deze via de DHCP van de EB een IP-adres zou moeten krijgen.

Wanneer ik de WAN1-poort gebruik, wordt de USG3 niet zichtbaar in mijn netwerk.
Blijkbaar kreeg deze wel een IP vanuit het subnet 192.168.2.x. Maar werkte pas bij USG wanneer ik het subnet 192.168.1.x wijzigde in 192.168.20.x...

[ Voor 23% gewijzigd door carlob op 17-10-2021 15:45 ]

[johnbetonschaar]

Edit: dubbelpost-faal, zie reactie hieronder

[ Voor 97% gewijzigd door johnbetonschaar op 16-10-2021 14:13 ]

[johnbetonschaar]

Sinds gisteren is er ineens iets vreemds veranderd in mijn USG setup voor KPN glasvezel en IPTV, zonder dat ik zelf iets heb aangepast aan configuratie, de firmware, de controller of wat dan ook.

De IPTV hield er gisteren ineens mee op, en rebooten van de decoders en/of de USG hielp niet, de decoders bleven op 85% van de boot procedure hangen en gaven dan na 10 minuten ofzo een foutcode 561 (decoder IP probleem).

Wat ik in het verleden wel eens heb gehad is dat het router adres voor de IPTV interface (eth0.4) veranderde, waarschijnlijk bij netwerk aanpassingen door KPN. Daar had ik dan een scriptje voor dat het nieuwe router adres uit de DHCP lease informatie haalde en de route tabel voor de IPTV interface opnieuw instelde. Toen ik dat scriptje gisteren probeerde uit te voeren kreeg ik echter ineens een foutmelding dat het commando

code:

set protocols static route 213.75.112.0/21 next-hop $r_ip

Faalde omdat er een argument miste. $r_ip komt hier uit de informatie van het volgende commando, waar een regel in hoort te staan met het router adres:

code:

show dhcp client leases

Wat blijkt nu: de output van dit commando bevat ineens geen router informatie meer:

code:

wouter@USG:~$ show dhcp client leases
interface  : eth0.4
ip address : 10.215.167.38      [Active]
subnet mask: 255.255.192.0
dhcp server: 10.215.128.1
lease time : 3600
last update: Sat Oct 16 13:50:18 CEST 2021
expiry     : Sat Oct 16 14:50:15 CEST 2021
reason     : RENEW

Wat ik nu heb gedaan is het router adres 'gegokt' vanuit het IP adres dat eth0.4 heeft gekregen, en heb de route handmatig ingesteld als 10.215.167.1 wat verrassend genoeg nog werkt ook.

Nu is mijn vraag: is het 'normaal' dat de router info verdwenen is (waarschijnlijk niet meer meegestuurd wordt door de KPN DHCP?) of is hier iets meer aan de hand? En kan ik verwachten dat ik met dit handmatig ingestelde router IP straks alsnog problemen met de IPTV ga krijgen? Het werkt nu al zo'n 24 uur zonder problemen... Zou het wellicht al voldoende zijn om het scriptje aan te passen door in plaats van de 'router: ' regel te matchen en daar het IP vandaan te halen, te matchen op de 'ip address' regel en daar dan het net mask gedeelte van te pakken en er .1 achter te plakken? Of heb ik nu gewoon 'geluk' dat het nu toevallig het juiste router adres is en kan het straks zomaar ineens iets totaal anders worden?

[ Voor 41% gewijzigd door johnbetonschaar op 16-10-2021 14:17 ]

[ik222]

@johnbetonschaar Ik heb dit gisteren ook opgemerkt, in mijn geval werkte mijn setup met pfSense ineens niet meer omdat ik in pfSense "router" als required option had opgegeven in de DHCP client en ik mijn outbound NAT op automatisch had staan. Na dat weggehaald te hebben en zelf een NAT regel voor IPTV geconfigureerd te hebben werkte bij mij alles weer maar dit betekent dus inderdaad dat KPN iets aangepast heeft, namelijk dat ze de router option niet meer meesturen in hun DHCP offer.

Je analyse van wat er aan de hand is klopt dus helemaal, echter dat je nu goed gegokt hebt is puur geluk, met een subnetmasker van 255.255.192.0 had je namelijk 64 mogelijkheden en zelfs dan doe je al de aanname doen dat het altijd op een .1 eindigt

Dat script voor de USG moet dus even een beetje aangepast worden om echt naar option 121 te gaan kijken (vermoedelijk moet je het dan wel als DHCP hook script opzetten) en daar dan ook netjes het next-hop adres uit te halen. Option 121 bevat namelijk een waarde in dit format "213.75.112.0/21-10.236.172.1", het deel achter het streepje is dan het juiste next-hop adres.

[ Voor 5% gewijzigd door ik222 op 16-10-2021 14:41 ]

[johnbetonschaar]

ik222 schreef op zaterdag 16 oktober 2021 @ 14:36:Dat script voor de USG moet dus even een beetje aangepast worden om echt naar option 121 te gaan kijken (vermoedelijk moet je het dan wel als DHCP hook script opzetten) en daar dan ook netjes het next-hop adres uit te halen. Option 121 bevat namelijk een waarde in dit format "213.75.112.0/21-10.236.172.1", het deel achter het streepje is dan het juiste next-hop adres.

Ok, dan is het probleem duidelijk, maar de oplossing nog niet echt.

In de USG config geef ik een aantal client options mee:

code:

"dhcp-options": {
    "client-option": [
       "send vendor-class-identifier "IPTV_RG";",
       "request subnet-mask, routers, rfc3442-classless-static-routes;"
    ],
    "default-route": "no-update",
    "default-route-distance": "210",
    "name-server": "update"
},

Blijkbaar reageert de KPN DHCP dus niet meer op de 'routers' optie? Wat is de 'optie 121' waar je het over had, en vul ik die dan ook hier in?

Edit: ok, met wat Googlen is het me nu duidelijk dat option 121 de 'rfc3442-classless-static-routes' optie is. Maar blijkbaar komt deze informatie dus niet meer mee in de DHCP offer, of is het probleem alleen maar dat de route niet correct wordt weergegeven door 'show dhcp client leases'?

[ Voor 12% gewijzigd door johnbetonschaar op 16-10-2021 15:00 ]

[ik222]

DHCP Option 121 is classless-static-routes. In die config vraag je daarom en KPN stuurt die vervolgens ook mee in de DHCP offer. Normaal moet een router / firewall netjes de routes uit option 121 dan zelf installeren maar blijkbaar kan de USG dat nog altijd niet, dat is de hele reden dat je daarvoor een script nodig hebt. En dat oude scriptje gebruikte dus de output van een commando wat er niet meer is nu KPN een andere DHCP optie (routers) niet meer meestuurt.

Ik heb overigens zelf geen USG of andere Ubiquiti spullen dus kan helaas niet helpen om de scripts hiervoor aan te passen. Ik kan alleen bevestigen wat er veranderd is en hoe je het netwerk technisch zou moeten oplossen.

/Edit: Op zich is de wijziging van KPN heel logisch. Immers de router optie meesturen suggereert dat dit een default gateway kan zijn wat het ook nooit is geweest. Als je slechts een specifieke /21 ergens heen wilt routeren is het heel logisch om routers weg te laten en die route / next-hop alleen nog in de classless-static-routes optie te stoppen.

[ Voor 30% gewijzigd door ik222 op 16-10-2021 15:09 ]

[johnbetonschaar]

Ok top, ik denk dat ik het snap, bedankt!

Ik zag dat de repo [1] van @Coolhva een mooi script bevat dat dit probleem oplost, dat werkt inderdaad foutloos op mijn USG. Het ziet er wel behoorlijk complex uit, dus ik moet me er echt even in verdiepen wat het precies doet, voor het geval er in de toekomst weer iets mis gaat.

Jammer dat het allemaal zo ingewikkeld moet bij de USG, is dat met pfSense eenvoudiger, of moet je daar ook met scripts aan de gang om precies dit probleem op te lossen?

[1] https://github.com/coolhva/usg-kpn-ftth

[ Voor 5% gewijzigd door johnbetonschaar op 16-10-2021 15:18 ]

[ik222]

johnbetonschaar schreef op zaterdag 16 oktober 2021 @ 15:16:
Ok top, ik denk dat ik het snap, bedankt!

Ik zag dat de repo [1] van @Coolhva een mooi script bevat dat dit probleem oplost, dat werkt inderdaad foutloos op mijn USG. Het ziet er wel behoorlijk complex uit, dus ik moet me er echt even in verdiepen wat het precies doet, voor het geval er in de toekomst weer iets mis gaat.

Jammer dat het allemaal zo ingewikkeld moet bij de USG, is dat met pfSense eenvoudiger, of moet je daar ook met scripts aan de gang om precies dit probleem op te lossen?

[1] https://github.com/coolhva/usg-kpn-ftth

Dat is een heel mooi script wat dit inderdaad op de nette en permanente manier oplost.

Bij pfSense is het inderdaad veel eenvoudiger, daar configureer je alles in de webinterface zonder scripts en die snapt optie 121 ook standaard gewoon. Neemt niet weg dat het daar met deze aanpassing door KPN ook stuk was als je vertrouwde op automatische outbound NAT zoals ik dus deed tot gisteren. Maar goed dat is dan wel een logische en zeker eenmalige wijziging die je moet doen.

[frogger9]

zojuist de unifi straat bijgewerkt naar de laatste versies:
usg 4.4.55
usg-8-60w 5.64.8
controller 6.4.54

kpnitv vlan config middels coolvha scripts toegepast.

Tot nu toe stabiel, komende week test op stabiliteit.

[nero355]

carlob schreef op zaterdag 16 oktober 2021 @ 11:18:
Is het mogelijk is om de USG3 eerst vooraf helemaal gereed te maken ter vervanging van de EB van KPN? Het idee is dat thuis ondertussen alles door gaan terwijl ik daarmee bezig ben (ivm vrouw+pubers...).

Dat kan denk ik wel op voorwaarde dat je het huidige netwerk als WAN aansluiting gebruikt en alles achter de USG opbouwt en dus tijdelijk met een NAT achter NAT setup zit, totdat je de config omgooit naar de KPN IPTV config!

Je zal dan geen verbinding met het internet meer hebben, totdat je de USG aansluit op je Glasvezel verbinding!

Dit :

Ik probeer de USG3 bekabeld aan mijn netwerk te hangen met de verwachting dat deze via de DHCP van de EB een IP-adres zou moeten krijgen.

Wanneer ik de WAN1-poort gebruik, wordt de USG3 niet zichtbaar in mijn netwerk. Aan de LAN1-poort wel, maar ik vervolgens kan ik er met WinSCP niet bij. In de Unifi Controller zie ik de USG3 met IP 192.168.1.1 (terwijl de EB de range 192.169.2.x gebruikt) en in de EB zie ik de USG3 verschijnen met IP-adres 0.0.0.0.

Klinkt alsof je totaal verkeer bezig bent namelijk

[carlob]

nero355 schreef op zaterdag 16 oktober 2021 @ 23:36:
[...
Klinkt alsof je totaal verkeer bezig bent namelijk

In het verleden ging dit wel zo bij een ASUS router maar bij deze USG niet. Jammer maar verder geen probleem. Ik wacht wel totdat er een dagje niemand thuis is en dan vervolg ik het stappenplan van Coolhva.

[Tijntje]

Heb sinds vandaag in ons nieuw huis de USG weer aan de praat met KPN inclusief IPTV.
Hartelijk dank @Coolhva het is allemaal perfect uitgelegd.

Laatste stap die ik wil doen is het aansluiten van telefonie, heb een ouderwetse dect set.
Nu lees ik dat dit wel mogelijk is door de Experiav12 aan LAN2 te hangen en de config aan te passen.

Ik weet alleen niet wat ik moet toevoegen aan de json

[Coolhva]

johnbetonschaar schreef op zaterdag 16 oktober 2021 @ 15:16:
Ok top, ik denk dat ik het snap, bedankt!

Ik zag dat de repo [1] van @Coolhva een mooi script bevat dat dit probleem oplost, dat werkt inderdaad foutloos op mijn USG. Het ziet er wel behoorlijk complex uit, dus ik moet me er echt even in verdiepen wat het precies doet, voor het geval er in de toekomst weer iets mis gaat.

Jammer dat het allemaal zo ingewikkeld moet bij de USG, is dat met pfSense eenvoudiger, of moet je daar ook met scripts aan de gang om precies dit probleem op te lossen?

[1] https://github.com/coolhva/usg-kpn-ftth

Unifi is prachtig als het werkt, maar het komt niet voor niets. Heb je mijn handleiding ook gezien?

https://www.vanachterberg...teway-kpn-ftth-iptv-ipv6/

Daar probeer ik het stap voor stap uit te leggen (en als je dat doet raad ik je ook aan om te kijken of je de VLAN setup ook kan integreren, dan werkt je IPTV foutlozer).

[Coolhva]

Tijntje schreef op zondag 17 oktober 2021 @ 17:24:
Heb sinds vandaag in ons nieuw huis de USG weer aan de praat met KPN inclusief IPTV.
Hartelijk dank @Coolhva het is allemaal perfect uitgelegd.

Laatste stap die ik wil doen is het aansluiten van telefonie, heb een ouderwetse dect set.
Nu lees ik dat dit wel mogelijk is door de Experiav12 aan LAN2 te hangen en de config aan te passen.

Ik weet alleen niet wat ik moet toevoegen aan de json

Als je een "Bridge" gaat maken dan gaat de USG op CPU niveau pakketjes overduwen, ik heb daar geen goede ervaringen mee. Ik zou kiezen uit de volgende twee opties:

1. Koop een VOIP enabled telefoon en vul de VOIP gegevens direct in van KPN (kan je zelf bij KPN opvragen via https://servicetools.kpn.com/v2/#/voip-credentials )
2. Zet een managed switch tussen de NTU en de USG, zet op de poort naar de NTU VLAN 4,6,7 tagged in, op de USG VLAN 4 en 6 tagged en op de poort naar de experiabox VLANn 7 tagged. Dan kan je de telefoon (analoog) op de experiabox zetten.
3. Geen vaste telefonie (alleen mobiel).

Pro Tip: VOIP telefoon kost nagenoeg hetzelfde of minder als een managed switch.

[Coolhva]

carlob schreef op zondag 17 oktober 2021 @ 10:40:
[...]


In het verleden ging dit wel zo bij een ASUS router maar bij deze USG niet. Jammer maar verder geen probleem. Ik wacht wel totdat er een dagje niemand thuis is en dan vervolg ik het stappenplan van Coolhva.

Twee routers in hetzelfde netwerk kan, maar nu wil je alles op de controller instellen en dan werkt het toch net ff wat anders.

Wat je kan doen:

1. Maak een intern netwerk in de controller aan (LAN) maar dan ZONDER DHCP.
2. Zet de USG in het netwerk, ga direct naar de webinterface van de USG en zet een vast IP adres in, in dezelfde reeks als je huidige interne netwerk (bijv. 192.168.2.253 (waar de experiabox 254 is).
3. Volg mijn stappen plan met de json plaatsen, etc.
4. Zet de experiabox uit, gooi de WAN kabel om, zet DHCP aan in de controller en provision de USG
5. Alles werkt (hopenlijk ;-)).

Of, als je geen stress wilt, als iedereen uit het huis is.

[nero355]

Coolhva schreef op maandag 18 oktober 2021 @ 13:01:
2. Zet een managed switch tussen de NTU en de USG, zet op de poort naar de NTU VLAN 4,6,7 tagged in, op de USG VLAN 4 en 6 tagged en op de poort naar de experiabox VLANn 7 tagged. Dan kan je de telefoon (analoog) op de experiabox zetten.

VLAN 7 is toch EOL gegaan

Ik zou namelijk zweren dat ik een keer hier of in een ander topic heb gelezen dat VoIP tegenwoordig over de WAN gaat ?!

[Coolhva]

nero355 schreef op maandag 18 oktober 2021 @ 15:15:
[...]

VLAN 7 is toch EOL gegaan

Ik zou namelijk zweren dat ik een keer hier of in een ander topic heb gelezen dat VoIP tegenwoordig over de WAN gaat ?!

Hmm vreemd, ik zie VLAN 7 niet meer voorbij komen in de officiële documentatie van kpn. Juist de layer 2 scheiding maakt dat de NTU QOS kan toepassen, maar blijkbaar hebben ze QOS op IPv4 ingesteld voor voip verkeer op de WAN (aanname). Enige wat ik zou verwachten is dat je zelf ook QOS moet instellen, maar dat is misschien alleen belangrijk als je je upload vol stopt.

[nero355]

Coolhva schreef op maandag 18 oktober 2021 @ 15:46:
Hmm vreemd, ik zie VLAN 7 niet meer voorbij komen in de officiële documentatie van kpn.

Juist de layer 2 scheiding maakt dat de NTU QOS kan toepassen, maar blijkbaar hebben ze QOS op IPv4 ingesteld voor voip verkeer op de WAN (aanname). Enige wat ik zou verwachten is dat je zelf ook QOS moet instellen, maar dat is misschien alleen belangrijk als je je upload vol stopt.

Volgens mij heb ik dat ook inderdaad voorbij zien komen een keer...

[Tijntje]

Coolhva schreef op maandag 18 oktober 2021 @ 13:01:
[...]


Als je een "Bridge" gaat maken dan gaat de USG op CPU niveau pakketjes overduwen, ik heb daar geen goede ervaringen mee. Ik zou kiezen uit de volgende twee opties:

1. Koop een VOIP enabled telefoon en vul de VOIP gegevens direct in van KPN (kan je zelf bij KPN opvragen via https://servicetools.kpn.com/v2/#/voip-credentials )
2. Zet een managed switch tussen de NTU en de USG, zet op de poort naar de NTU VLAN 4,6,7 tagged in, op de USG VLAN 4 en 6 tagged en op de poort naar de experiabox VLANn 7 tagged. Dan kan je de telefoon (analoog) op de experiabox zetten.
3. Geen vaste telefonie (alleen mobiel).

Pro Tip: VOIP telefoon kost nagenoeg hetzelfde of minder als een managed switch.

Dus een Gigaset N300A IP met een setje toestellen.

[johnbetonschaar]

Coolhva schreef op maandag 18 oktober 2021 @ 12:56:
[...]


Unifi is prachtig als het werkt, maar het komt niet voor niets. Heb je mijn handleiding ook gezien?

https://www.vanachterberg...teway-kpn-ftth-iptv-ipv6/

Daar probeer ik het stap voor stap uit te leggen (en als je dat doet raad ik je ook aan om te kijken of je de VLAN setup ook kan integreren, dan werkt je IPTV foutlozer).

Zeker, ik heb al een hoop nuttige info uit je handleiding gehaald, bedankt daarvoor! Waaronder inderdaad de VLAN setup, dat lukte me namelijk zelf niet, maar nu werkt het foutloos.

Het kpn.sh script had ik echter voorheen nog niet gebruikt omdat ik het router adres via een ander scriptje uit de show dhcp client leases kon halen. Maar dat was ook al een imperfecte oplossing omdat het geen dhcp hook was en je het dus handmatig moest uitvoeren of de router moest rebooten. Dit is veel beter

[ZiSE]

Laatste dagen gaat het aantal keren mis met de TV; zie dat er ondertussen een nieuw script is wat wellicht kan helpen. Ik heb in post-config.d nog setroutes.sh en update_iptv_route.sh staan (waarschijnlijk van een andere tutorial). Kan ik die verwijderen en dan het kpn.sh script gebruiken?
@Coolhva in je stappenplan zie ik ook "igmpproxy.sh" staan; zie echter niet waar die gebruikt wordt?

[Coolhva]

ZiSE schreef op maandag 18 oktober 2021 @ 17:04:
Laatste dagen gaat het aantal keren mis met de TV; zie dat er ondertussen een nieuw script is wat wellicht kan helpen. Ik heb in post-config.d nog setroutes.sh en update_iptv_route.sh staan (waarschijnlijk van een andere tutorial). Kan ik die verwijderen en dan het kpn.sh script gebruiken?
@Coolhva in je stappenplan zie ik ook "igmpproxy.sh" staan; zie echter niet waar die gebruikt wordt?

kpn.sh is een all-in-one script en moet alles oppakken, dus je kan setroutes.sh en update_iptv_route.sh verwijderen, alleen weet ik niet of er nog bestanden overblijven in de post-config.d of andere mappen.
Het beste is dat je een factory reset doet, opnieuw adopteren en dan kpn.sh plaatsen.

igmpproxy.sh kan je in post-config.d plaatsen, dat zorgt er voor dat elke minuut wordt gekeken of de igmpproxy service draait en deze logt en start als dat niet zo is.

code:

# Check if igmp proxy is running and restart if not.
if ! pidof igmpproxy >/dev/null 2>&1; then
echo "[$(date)] [igmpproxy.sh] IGMP Proxy not running" >> ${logFile}

# Restarting igmp proxy
echo "[$(date)] [igmpproxy.sh] Restarting IGMP proxy" >> ${logFile}
/opt/vyatta/bin/vyatta-op-cmd-wrapper restart igmp-proxy >> ${logFile}
fi

Dit heb ik voor een paar mensen er in gezet, technisch gezien zou het niet mogelijk zijn maar je kan wel in het log (var/log/igmpproxy.log) of hij crasht en je hoeft hem niet zelf te herstarten als hij crasht. Dit is een pleister voor sommige mensen, maar ik heb hem zelf niet nodig.

[Roylee]

nero355 schreef op zaterdag 16 oktober 2021 @ 03:11:
[...]

Maar wel apparaten die Multicasten en dus issues kunnen veroorzaken volgens je overzicht :

[...]

- TV
- Printer
- DLNA meuk
- IP camera
- enz.

IGMP switches halen dus

[daveverhoef]

-

[ Voor 193% gewijzigd door daveverhoef op 25-10-2021 11:16 . Reden: Verwijderen ]

[F12-DV88]

Hallo,

Al enige tijd ben ik bezig om dit werkend te krijgen voor Online/Canal Digitaal.
Is er iemand die mij kan adviseren en helpen?

Dank alvast

Gr

[Sandertjuhh]

Na de guide van Coolhva gevolgd te hebben (en wat troubleshooting stappen in deze thread) heb ik IPTV via KPN helemaal werkend te samen met Internet, so far so good! Ik vroeg mij alleen af of er al Tweakers zijn die ervaringen hebben met een USG-firmware hoger dan 4.4.51.5287926 i.c.m. met de Coolhva setup?

Tijdens mijn troubleshooting heb ik mijn USG namelijk gedowngrade versie 4.4.51.5287926 omdat ik het vermoeden had dat er ergens iets niet compatible was met mijn versie... Het bleek echter een user-error te zijn, dus onnodig gedowngrade.

[jtenbrink]

cipheos schreef op zaterdag 20 maart 2021 @ 17:29:
Heeft iemand hier toevallig een voorbeeld van een config.gateway.json voor Trined en een USG-PRO-4? Of uberhaupt een voorbeeld voor een andere provider dan KPN?

Deze zou ik ook graag willen hebben.

In de startpost staat overigens ook een fout denk ik.
Trined
VLAN ID Functie verbindingstype
4 IP-tv DHCP
6 Internet DHCP

VLAN 6 moet naar mijn weten via PPPoE.

[nero355]

Sandertjuhh schreef op dinsdag 26 oktober 2021 @ 08:01:
Na de guide van Coolhva gevolgd te hebben (en wat troubleshooting stappen in deze thread) heb ik IPTV via KPN helemaal werkend te samen met Internet, so far so good! Ik vroeg mij alleen af of er al Tweakers zijn die ervaringen hebben met een USG-firmware hoger dan 4.4.51.5287926 i.c.m. met de Coolhva setup?

Tijdens mijn troubleshooting heb ik mijn USG namelijk gedowngrade versie 4.4.51.5287926 omdat ik het vermoeden had dat er ergens iets niet compatible was met mijn versie... Het bleek echter een user-error te zijn, dus onnodig gedowngrade.

Scroll effe een flink stuk terug en je zal de laatste bruikbare versie tegenkomen!

[dbeusink]

Sandertjuhh schreef op dinsdag 26 oktober 2021 @ 08:01:
Na de guide van Coolhva gevolgd te hebben (en wat troubleshooting stappen in deze thread) heb ik IPTV via KPN helemaal werkend te samen met Internet, so far so good! Ik vroeg mij alleen af of er al Tweakers zijn die ervaringen hebben met een USG-firmware hoger dan 4.4.51.5287926 i.c.m. met de Coolhva setup?

Tijdens mijn troubleshooting heb ik mijn USG namelijk gedowngrade versie 4.4.51.5287926 omdat ik het vermoeden had dat er ergens iets niet compatible was met mijn versie... Het bleek echter een user-error te zijn, dus onnodig gedowngrade.

Ik zit zelf (USG-3P) ook nog steeds op v4.4.51 omdat ik bij v4.4.55 last had van spontane reboots. Daarnaast zat er een flinke memory leak in waardoor het geheugen gedurende de dag vol bleef lopen. Het zou natuurlijk kunnen zijn dat ik domme pech heb gehad en dat de upgrade naar v4.4.55 gewoon niet lekker is verlopen. Sinds ik op 4.4.51 zit draait mijn config alweer 161 dagen zonder problemen, dus ik blijf er momenteel lekker van af

[Coolhva]

Ik zit op versie 4.4.55 maar heb ook een redelijk klein netwerk zonder rare apparaten (chromecasts, etc.).

Zelf hou ik er van om de laatste stabiele versie te draaien en alleen te downgraden als ik problemen ervaar, maar dat is natuurlijk persoonlijk.

[Huub-]

De lasten twee weken heb ik ook (weer) last van TV's die gaan stilstaan of haperen. Ook opgenomen programma's vertonen het zelfde probleem. Ik zit bij XS4ALL heb de Coolhva handleiding gevolgd incl. VLANS. Het geheel werkt behoorlijk stabiel tot een paar weken terug. Ik zie wel dat Coolhva een aantal zaken heeft gewijzigd, maar mijn .json file ziet eruit zoals Coolhva het beschrijft in zijn XS4ALL handleiding. Ik zie wel dat ik op de USG in de post-config.d folder twee andere bestanden heb namelijk setroutes.sh en setvpn.sh, op GitHub XS4ALL zie ik wel dat daar nu kpn.sh staat en niet de files die ik heb. Stel dat ik die ga vervangen kan dat de oplossing zijn voor het stilstaan/haperen van IPTV ?

[Coolhva]

Huub- schreef op donderdag 28 oktober 2021 @ 09:56:
De lasten twee weken heb ik ook (weer) last van TV's die gaan stilstaan of haperen. Ook opgenomen programma's vertonen het zelfde probleem. Ik zit bij XS4ALL heb de Coolhva handleiding gevolgd incl. VLANS. Het geheel werkt behoorlijk stabiel tot een paar weken terug. Ik zie wel dat Coolhva een aantal zaken heeft gewijzigd, maar mijn .json file ziet eruit zoals Coolhva het beschrijft in zijn XS4ALL handleiding. Ik zie wel dat ik op de USG in de post-config.d folder twee andere bestanden heb namelijk setroutes.sh en setvpn.sh, op GitHub XS4ALL zie ik wel dat daar nu kpn.sh staat en niet de files die ik heb. Stel dat ik die ga vervangen kan dat de oplossing zijn voor het stilstaan/haperen van IPTV ?

ff factory reset van je USG, kpn.sh erop duwen en gaan met die banaan!

Maar even zonder gekheid, geen nieuwe apparaten in je netwerk? Zo niet dan kan je bovenstaande het beste uitvoeren en kijken of het daarna beter werkt. Eventueel het igmpproxy.sh script ook plaatsen.

[Huub-]

Euh Factory reset? Ben ik dan niet alle settings kwijt? Kan dat ook zonder?

Nee ik heb niet echt nieuwe apparaten in mijn netwerk. Ik heb ook al een aantal keer het IGM proxy herstart maar dat leverde toen niet veel op. Problemen houden aan en rest van het gezin gaat zich er aan storen. Heb een Shield met IPTV als alternatief maar ook niet op elke kamer

Het is dat ik best tevreden ben, met name VPN en netwerk in het algemeen, anders toch meer weer terug naar de FritzBox..

[Coolhva]

Huub- schreef op donderdag 28 oktober 2021 @ 19:15:
Euh Factory reset? Ben ik dan niet alle settings kwijt? Kan dat ook zonder?

Nee ik heb niet echt nieuwe apparaten in mijn netwerk. Ik heb ook al een aantal keer het IGM proxy herstart maar dat leverde toen niet veel op. Problemen houden aan en rest van het gezin gaat zich er aan storen. Heb een Shield met IPTV als alternatief maar ook niet op elke kamer

Het is dat ik best tevreden ben, met name VPN en netwerk in het algemeen, anders toch meer weer terug naar de FritzBox..

Als je de USG een factory reset geeft kan je hem daarna weer adopteren in de controller en zal hij zijn configuratie weer krijgen. Je moet alleen kpn.sh weer terug plaatsen want die overleeft een factory reset niet.

[wolfisking]

Bij Budget Thuis moet voor zowel VLAN 34 en VLAN 4 via DHCP een adres verkregen te worden. Op VLAN34 heb ik daarnaast nog het MAC-adres van de Experiabox die je van ze ontvangt toegevoegd:

code:

        "interfaces": {
                "ethernet": {
                        "eth0": {
                                "description": "WAN",
                                "dhcp-options": {
                                        "default-route": "no-update",
                                        "default-route-distance": "1",
                                        "name-server": "no-update"
                                },
                                "duplex": "auto",
                                "speed": "auto",
                                "vif": {
                                        "34": {
                                                "address": [
                                                        "dhcp"
                                                ],
                                                "description": "Internet",
                                                "dhcp-options": {
                                                        "client-option": [
                                                                "retry 60;"
                                                        ],
                                                        "default-route": "no-update",
                                                        "default-route-distance": "1",
                                                        "name-server": "no-update"
                                                },
                                                "firewall": {
                                                        "in": {
                                                                "ipv6-name": "WANv6_IN",
                                                                "name": "WAN_IN"
                                                        },
                                                        "local": {
                                                                "ipv6-name": "WANv6_LOCAL",
                                                                "name": "WAN_LOCAL"
                                                        },
                                                        "out": {
                                                                "ipv6-name": "WANv6_OUT",
                                                                "name": "WAN_OUT"
                                                        }
                                                },
                                                "mac": "XX:XX:XX:XX:XX"
                                        },
                                        "4": {
                                                "address": [
                                                        "dhcp"
                                                ],
                                                "description": "IPTV",
                                                "dhcp-options": {
                                                        "client-option": [
                                                                "send vendor-class-identifier "IPTV_RG";",
                                                                "request subnet-mask, routers, rfc3442-classless-static-routes;"
                                                        ],
                                                        "default-route": "no-update",
                                                        "default-route-distance": "210",
                                                        "name-server": "no-update"
                                                },
                                                "ip": {
                                                        "source-validation": "loose"
                                                },
                                                "mtu": "1500"
                                        }
                                }
                        }

[Huub-]

Coolhva schreef op vrijdag 29 oktober 2021 @ 16:06:
[...]


Als je de USG een factory reset geeft kan je hem daarna weer adopteren in de controller en zal hij zijn configuratie weer krijgen. Je moet alleen kpn.sh weer terug plaatsen want die overleeft een factory reset niet.

Ik heb uiteindelijk nog geen reset doorgevoerd, De UNIFI mini, zit achter mijn TV en gaat naar TV en SHIELD, heb ik vervangen voor een switch die IGMP ondersteund (Netgear ProSAFE GS105E). Alles natuurlijk in Vlan 200 gezet ook op de nieuwe switch waar ik IGMP ook heb aanstaan. Heb nu bijna geen haperingen meer, heel af en toe komt het nog wel even voor maar dat duurt dan heel even waarna het daarna weer een hele tijd goed gaat..
Ik wacht nu af hoe dit gaat, wellicht later alsnog een reset uitvoeren en de nieuwe kpn.sh toevoegen..

[JeRa]

Ik heb een hele tijd een issue gehad met Ubiquity (Edgerouter X) + KPN IPTV: alles was functioneel, maar bij het zappen tussen zenders worden de IPTV streams niet stopgezet met als gevolg dat na ~15-20 keer zappen de volle 100 MBit/s van de STB werd volgeduwd door KPN. De enige oplossing die ik gevonden had, was het herstarten van igmp-proxy of wachten tot de streams uit zichzelf werden stopgezet.

De oorzaak zat hem in de firewall: ik liet IGMP traffic toe van KPN naar de router, maar was vergeten om IGMP traffic van mijn IPTV VLAN toe te laten naar de router met als gevolg dat igmp-proxy nooit van de STB's te horen kreeg dat streams afgesloten moesten worden.

Een erg lastig te traceren issue, omdat alles lijkt te werken totdat iemand flink gaat zitten te zappen. Hopelijk help ik iemand hiermee :-)

[Shartar]

JeRa schreef op maandag 1 november 2021 @ 20:16:

Een erg lastig te traceren issue, omdat alles lijkt te werken totdat iemand flink gaat zitten te zappen. Hopelijk help ik iemand hiermee :-)

Ja, deze oplossing hielp mij ook thanks!! Ik heb dit issue al een tijdje alleen is het met ons zeer beperkte zapgedrag thuis meer onhandig dan vervelend. Maar toen ik dit las meteen even gecontroleerd of ik IGMP ook goed had staan op IPTV vlan. Helaas, meteen even aangepast, en daarna vlekkeloos zappen!