:strip_exif()/i/2003058510.png?f=thumbmini)
:strip_exif()/i/2003058504.png?f=thumbmini)
:strip_exif()/i/2003247502.png?f=thumbmini)
:fill(white):strip_exif()/i/2005714546.jpeg?f=thumbmini)
:strip_exif()/i/2004809138.webp?f=thumbmini)
:strip_exif()/i/2005808142.webp?f=thumbmini)
:fill(white):strip_exif()/i/2002253379.jpeg?f=thumbmini)
:strip_exif()/i/2001954595.png?f=thumbmini)
Korte patchkabeltjes gebruiken inderdaad!
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
/u/8572/crop59bc1c268024e_cropped.png?f=community)
Daarover gesproken.. bedankt voor je handleiding en config. Werkt bijna als een zonnetje! Ik wil graag voor IPV6 DNS ook het IP-adres van m'n USG gebruiken en dat die het weer forward naar de DNS servers van CloudFlare of Google, zodat al het DNS verkeer voor zowel IPV4 als IPV6 via de USG verloopt.
Ik probeer namelijk adblocking op DNS niveau goed werkend te krijgen met deze oplossing en dat lijkt maar deels goed te werken, namelijk alleen op m'n laptop en desktop en niet op m'n Android tablet en telefoon. Ik vermoed dat dat komt omdat de eerste 2 IPV4 DNS gebruikt via de USG en de laatste 2 de voorkeur geven aan IPV6 en daarmee rechtstreeks naar CloudFlare gaan.
Wat is nou m'n vraag..
Enig idee of ik gewoon kan aanprutsen met de settings in de config.gateway.json zolang ik maar valide JSON hou en in het goede formaat op sla, of kan ik ook iets bricken door verkeerde waardes in te voeren? Wellicht misschien meer een vraag voor het algemene Ubiquiti topic maar aangezien het gaat om de combi tussen Coolhva's config en adblocking toch maar hier geplaatst.
/u/3626/front-kabels.png?f=community)
Bricken kan nooit, aangezien je de USG altijd kan factory resetten en opnieuw kan adopten in de controller.:
[...]
Daarover gesproken.. bedankt voor je handleiding en config. Werkt bijna als een zonnetje! Ik wil graag voor IPV6 DNS ook het IP-adres van m'n USG gebruiken en dat die het weer forward naar de DNS servers van CloudFlare of Google, zodat al het DNS verkeer voor zowel IPV4 als IPV6 via de USG verloopt.
Ik probeer namelijk adblocking op DNS niveau goed werkend te krijgen met deze oplossing en dat lijkt maar deels goed te werken, namelijk alleen op m'n laptop en desktop en niet op m'n Android tablet en telefoon. Ik vermoed dat dat komt omdat de eerste 2 IPV4 DNS gebruikt via de USG en de laatste 2 de voorkeur geven aan IPV6 en daarmee rechtstreeks naar CloudFlare gaan.
Wat is nou m'n vraag..
De actuele opbrengst van mijn Tibber Homevolt
Thanks voor de aanmoediging. In plaats van prutsen met IPv6 heb ik maar besloten het er gewoon helemaal uit te slopen want heb er in m'n thuisnetwerk toch geen behoefte aan. Werkt nu prima samen met die adblocking oplossing, ook op Android devices. IPTV getest net, dat werkt ook nog dus ben happy
Hieronder m'n uiteindelijke configuratie. Btw, aandachtspuntje, om die stappen te doorlopen voor de adblocker installatie moest ik MTU naar 1492 zetten in plaats van de 1500 die standaard in Coolhva's config staat. Zonder dat bleef het commando "sudo curl -L https://raw.githubusercontent.com" hangen. Ben verder geen netwerker dus geen idee wat de impact hier precies van is, maar dacht ergens wat uitleg te lezen van Coolhva dat het vooral een optimalisatie is om hem op 1500 te zetten?
Nu nog uitvogelen hoe ik eigen DNS servers instel in plaats van die van KPN te gebruiken, wat nu denk ik gebeurt.. gebruiksvriendelijk is het niet echt he
Hieronder m'n uiteindelijke configuratie. Btw, aandachtspuntje, om die stappen te doorlopen voor de adblocker installatie moest ik MTU naar 1492 zetten in plaats van de 1500 die standaard in Coolhva's config staat. Zonder dat bleef het commando "sudo curl -L https://raw.githubusercontent.com" hangen. Ben verder geen netwerker dus geen idee wat de impact hier precies van is, maar dacht ergens wat uitleg te lezen van Coolhva dat het vooral een optimalisatie is om hem op 1500 te zetten?
Nu nog uitvogelen hoe ik eigen DNS servers instel in plaats van die van KPN te gebruiken, wat nu denk ik gebeurt.. gebruiksvriendelijk is het niet echt he
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
| {
"system": {
"task-scheduler": {
"task": {
"postprovisionroutes": {
"executable": {
"path": "/config/scripts/post-config.d/setroutes.sh"
},
"interval": "2m"
}
}
},
"offload": {
"ipv4": {
"forwarding": "enable",
"gre": "enable",
"pppoe": "enable",
"vlan": "enable"
}
}
},
"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": "1492"
},
"6": {
"firewall": {
"in": {
"name": "WAN_IN"
},
"local": {
"name": "WAN_LOCAL"
},
"out": {
"name": "WAN_OUT"
}
},
"pppoe": {
"2": {
"default-route": "auto",
"firewall": {
"in": {
"name": "WAN_IN"
},
"local": {
"name": "WAN_LOCAL"
},
"out": {
"name": "WAN_OUT"
}
},
"mtu": "1492",
"name-server": "auto",
"password": "kpn",
"user-id": "kpn"
}
}
}
}
},
"eth1": {
"description": "LAN"
}
}
},
"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"
}
}
},
"static": {
"interface-route": {
"0.0.0.0/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"
}
}
}
}
} |
:fill(white):strip_exif()/f/image/eP7ovOpmDKLTY1opkl41Uwjy.png?f=user_large)
Ik heb even zelf een trace die curl gedaan (vanaf een niet KPN PPPoE lijn) en zie inderdaad dat github frames van 1494 terug stuurt met een DF set. Daar gaat het dus fout als je de maximale MTU van 1492 niet instelt op de interface. Daarnaast kan ik hieruit afleiden dat je ergens ICMP packets dropt, waarschijnlijk op de WAN interface van je USG. Ik zou je aanraden om deze door te laten, of in ieder geval de ICMP type 3 messages, want die zijn essentieel voor een goede werking van het Internet.
De actuele opbrengst van mijn Tibber Homevolt
:strip_icc():strip_exif()/u/85951/crop651b30b545187_cropped.jpg?f=community)
ph34r my [WCG] Cows :P
:strip_exif()/u/49248/DPCkoeienUD.gif?f=community)
Waarom draai je geen Pi-Hole
Is veel makkelijker te beheren dan die oplossing en je kan het onafhankelijk van je Router draaien die al niet al te rijk is uitgerust qua SoC
Gooi effe alles tussen code tags met een setje quote tags eromheen :
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Als je de regel:
Thanks voor de aanmoediging. In plaats van prutsen met IPv6 heb ik maar besloten het er gewoon helemaal uit te slopen want heb er in m'n thuisnetwerk toch geen behoefte aan. Werkt nu prima samen met die adblocking oplossing, ook op Android devices. IPTV getest net, dat werkt ook nog dus ben happy
Hieronder m'n uiteindelijke configuratie. Btw, aandachtspuntje, om die stappen te doorlopen voor de adblocker installatie moest ik MTU naar 1492 zetten in plaats van de 1500 die standaard in Coolhva's config staat. Zonder dat bleef het commando "sudo curl -L https://raw.githubusercontent.com" hangen. Ben verder geen netwerker dus geen idee wat de impact hier precies van is, maar dacht ergens wat uitleg te lezen van Coolhva dat het vooral een optimalisatie is om hem op 1500 te zetten?
Nu nog uitvogelen hoe ik eigen DNS servers instel in plaats van die van KPN te gebruiken, wat nu denk ik gebeurt.. gebruiksvriendelijk is het niet echt he
code:
{ "system": { "task-scheduler": { "task": { "postprovisionroutes": { "executable": { "path": "/config/scripts/post-config.d/setroutes.sh" }, "interval": "2m" } } }, "offload": { "ipv4": { "forwarding": "enable", "gre": "enable", "pppoe": "enable", "vlan": "enable" } } }, "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": "1492" }, "6": { "firewall": { "in": { "name": "WAN_IN" }, "local": { "name": "WAN_LOCAL" }, "out": { "name": "WAN_OUT" } }, "pppoe": { "2": { "default-route": "auto", "firewall": { "in": { "name": "WAN_IN" }, "local": { "name": "WAN_LOCAL" }, "out": { "name": "WAN_OUT" } }, "mtu": "1492", "name-server": "auto", "password": "kpn", "user-id": "kpn" } } } } }, "eth1": { "description": "LAN" } } }, "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" } } }, "static": { "interface-route": { "0.0.0.0/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" } } } } }
code:
uit de JSON haalt dan geef je geen DNS mee met IPv6 en zal je apparaat terugvallen op de IPv4 DNS servers die je hebt ingesteld op je USG.
1
| "radvd-options": "RDNSS 2606:4700:4700::1111 2606:4700:4700::1001 {};", |
Klein vraagje hier over vooral over het volgende gedeelte
Regel 169 verwijderen betekend dat hij de dns server van je IP4 instellingen gebruikt,
Maar waar is regels 158,159 voor dan ?
Ik draai namelijk zelf ook een pihole,
en heb ip6 uit staan naar mijn weten.
Maar valt me op dat ik toch meer advertenties binnen krijg dan ik eerst binnen kreeg.
en hij laat niet alle Queries laat zien die gedaan worden.
En volgens mij hoefde ik alleen de ip van de pihole in de volgende instellingen zetten normaal.
Regel 169 verwijderen betekend dat hij de dns server van je IP4 instellingen gebruikt,
Maar waar is regels 158,159 voor dan ?
Ik draai namelijk zelf ook een pihole,
en heb ip6 uit staan naar mijn weten.
Maar valt me op dat ik toch meer advertenties binnen krijg dan ik eerst binnen kreeg.
en hij laat niet alle Queries laat zien die gedaan worden.
En volgens mij hoefde ik alleen de ip van de pihole in de volgende instellingen zetten normaal.
I think I'm afraid to be happy whenever I get to happy, something bad always happen.
Nee eigenlijk niet,
Vraag me af of ik iets fout gedaan heb aangezien ik er niemand anders over hoor.
Ben wel hier wezen zoeken voor een oplossing.
En het enigste wat ik kon vinden was om weer de Experiabox aan te sluiten voor de upgrade
I think I'm afraid to be happy whenever I get to happy, something bad always happen.
Het enige dat ik me kan bedenken is dat je stb niet bij de update multicast group kan.:
[...]
Nee eigenlijk niet,
Vraag me af of ik iets fout gedaan heb aangezien ik er niemand anders over hoor.
Ben wel hier wezen zoeken voor een oplossing.
En het enigste wat ik kon vinden was om weer de Experiabox aan te sluiten voor de upgrade
Ik heb xs4all en de software update kwam binnen via MC Group 224.0.250.87 vanaf Source 213.75.167.58.
Check even of die source pingbaar is en wat je bij alt-subnets geconfigureerd hebt op de eth0.4 interface.
De actuele opbrengst van mijn Tibber Homevolt
Ik kom van een Asus router waar ik ook alles in 1 had. Upgrade gedaan naar USG/UAP's/USW's, dat was al een behoorlijke stap. Toen KPN router er tussenuit en ben eigenlijk gewoon 1 ding per keer aan het veranderen nu. Pi-Hole staat ook op m'n todo lijstje, maar daar moet ik ook nog even de spulletjes voor bestellen. Nu eerst nog even spelen met de config.gateway.json om daar wat meer gevoel bij te krijgen.:
[...]
Waarom draai je geen Pi-Hole
Is veel makkelijker te beheren dan die oplossing en je kan het onafhankelijk van je Router draaien die al niet al te rijk is uitgerust qua SoC
[...]
Gooi effe alles tussen code tags met een setje quote tags eromheen :
[...]
Thanks allen, ben al tijd niet echt actief geweest op het forum maar top dat de community nog altijd zo behulpzaam is!
:fill(white):strip_exif()/f/image/pul7GeWia2h3KupLIe1FW4h5.png?f=user_large)
Mijn STB is .43 en ik heb deze trace gemaakt toen ik de STB bootte. Nadat de STB MC Group 224.0.250.87 joinde, begon de download. Nadat de download compleet was, stuurde de STB een IGMP leave voor MC Group 224.0.250.87.
De actuele opbrengst van mijn Tibber Homevolt
Dit kan inderdaad de oplossing zijn, want ik heb al vanaf dag 1 mijn USG geconfigureerd als DNS forwarder naar Google's DNS (8.8.8.8 en 8.8.4.4).
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| {
"expected_system_cfg" : {
"service" : {
"dns" : {
"forwarding" : {
"cache-size" : "10000",
"options" : [ "all-servers", "cname=unifi", "server=127.0.0.1" ],
"except-interface" : [ "eth0.6" ],
"name-server" : [ "8.8.8.8", "8.8.4.4" ]
}
}
}
}
} |
En als ik die DNS servers dig voor het TXT record krijg ik netjes dit antwoord: "SAP/1/224.3.2.6:9875".
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| ; <<>> DiG 9.10.6 <<>> -t TXT sap.stb.itvonline.nl @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44168 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;sap.stb.itvonline.nl. IN TXT ;; ANSWER SECTION: sap.stb.itvonline.nl. 21575 IN TXT "SAP/1/224.3.2.6:9875" ;; Query time: 55 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu Jun 11 23:22:05 CEST 2020 ;; MSG SIZE rcvd: 82 |
Ik heb even terug gekeken in mijn trace, en ik heb door hoe de updates werken.
Een STB doet een DNS query voor de sap.stb.itvonline.nl TXT, welke linkt naar MC group 224.3.2.6 wat een soort admin multicast groep is. Er komen zo'n 40 announces voorbij, met STB types, MC group adressen, versie nummers en MD5s.
Na de laatste announce (waar de VIP5202 in genoemd wordt) doet de STB een leave van MC group 224.3.2.6 en direct een join van de MC groep die in die announce stond (224.0.250.87). Dat is dus de update die de STB wil hebben. (EDIT: de STB wil de MC groep hebben met x-version "default").
Vervolgens begint direct de UDP stream vanaf de carousel die de update binnen haalt.
Een screenshot van de hele STB communicatie (DNS, MC 224.3.2.6 en MC 224.0.250.87)
- packets 46/48 --> DNS query & response
- packet 49 --> Join van de admin MC group
- packet 104 --> announce van MC Groep voor de VIP5202
- packet 105 --> leave van de admin MC group
- packet 106 --> join van de MC Groep met de VIP5202 update
- packet 107 en verder --> UDP stream met VIP5202 update
:fill(white):strip_exif()/f/image/J8FnXCCQVB3K09YkEA84MB4Z.png?f=user_large)
Een screenshot van een random announce (in dit geval van een HMB2260 update)
:fill(white):strip_exif()/f/image/bCVaVW2lzMY3omL2oDVyjtK5.png?f=user_large)
Een screenshot van de laatste announce van de VIP5202 MC groep die de STB wil hebben.
:fill(white):strip_exif()/f/image/uPbmc84771j36Nni6HFHNygE.png?f=user_large)
[ Voor 4% gewijzigd door JackBol op 11-06-2020 23:29 ]
De actuele opbrengst van mijn Tibber Homevolt
:strip_icc():strip_exif()/u/40635/tux.jpg?f=community)
Eens, ik ben zelf 'gebruiker' dus zit vooral te wachten op het moment dat iemand zegt: "gebruik deze config, want die werkt"
Maar wil stiekem ook begrijpen hoe dit werkt en volg de verschillende posts aandachtig.
Het uitgangspunt van de CoolHVA config is dat deze heel robuust is en dat hij meebeweegt met de aanpassingen die KPN/XS4ALL doet. Ik zou het dan ook logisch vinden als daar ook de XS4ALL en KPN dns standaard is ingericht. (het lijkt erop dat als dat al zo was geweest de VIP5202 het meteen had gedaan)
ps. niemand had natuurlijk kunnen voorzien dat cloudflare 'iets' met TXT reccords doet (overigens ook met andere domeinen. Probeer nu.nl maar eens
hier verschilt de grote ook.
:fill(white):strip_exif()/f/image/Eite9wDO9RXYzLTRJI6pgXhp.png?f=user_large)
Bitwise het enige verschil tussen de google en cloudflare response is dat cloudflare de hele name toevoegd aan het Answer RR, terwijl Google een pointer gebruikt naar de name in de query (onderdeel van DNS label compression).
Daar gaat het wellicht in de STB mis.
De actuele opbrengst van mijn Tibber Homevolt
Dit was de vraag!
En dit is het antwoord omdat je die aanvraag niet in je Json config heb staan en de usg de dns dus ook niet uitvraagt tijdens je pppoe login bij kpn/xs4all.
JSON:
1
2
3
4
5
6
7
| "pppoe": { "2": { "default-route": "none", "name-server": "none", "password": "kpn", "user-id": "kpn" } |
.
Dat leg ik je toch uit dat 1.1.1.1 met de nieuwere controller versies het default fallback dns is
Ik baseerde me nergens op jouw config. ik geef alleen waar je moet kijken en wat de rede kan zijn dat je USG dit gedrag vertoont.
er mist waarschijnlijk een stukje technische kennis over pppoE en over de USG.
Pppoe gebruikt namelijk helemaal geen dhcp dus kan die ook niet via dhcp opvragen. Je kan wel een andere dns dan die je van het pppoe protocol krijgt via dhcp aan een vlan(subnet) uitdelen. Maar dat iets heel anders dan wat je vraagt.
Ongeacht wat je daar invult gebruikt USG nog steeds de Pppoe2 DNS of bij het ontbreken daarvan zijn failback dns 1.1.1.1
Wil je dat niet lees dan mijn openings post van dit topic en verdiep je de json die daar staat. De doe het zelf json die daar staat werkt 100% inclusief stb updates. Wat staat daar bij de dns forward setting omdat je eigen in de controller ingevulde dns wil gebruiken?
Inderdaad!
JSON:
1
2
3
4
5
6
7
8
| service": { "dns": { "forwarding": { "except-interface": [ "pppoe2" ] } }, |
Meer niet alles wat extra staat is te veel en die je inde controller. In de json mag je namelijk alleen maar dingen configureren die je niet in de controller kan wijzigen. Ik zie dat mensen daar proberen een dns op te geven. Dat is absoluut not done.
Sorry vat het niet persoonlijk. Maar lees het start topic vergelijk je json en zie wat je fout doet
[ Voor 72% gewijzigd door xbeam op 13-06-2020 15:40 ]
Lesdictische is mijn hash#
Jij reageert op mij reactie Ik niet op jouwe.
Maar veel plezier vanavond.
Lesdictische is mijn hash#
Sinds enkele dagen krijg ik weer de melding om naar een andere zender te zappen.... niks aan de config veranderd, geen firmware updates laten uitvoeren. Nu log ik in op de USG4, en krijg ik dit te zien:
show dhcp client leases
interface : eth2
last update: Tue Jun 16 18:46:49 CEST 2020
reason : FAIL
Kan dat een oorzaak zijn?
nevermind, eth2 is niet verbonden, dus dit heeft er niks mee te maken. Hoe kan ik dit het beste Trouble shooten?
show dhcp client leases
interface : eth2
last update: Tue Jun 16 18:46:49 CEST 2020
reason : FAIL
Kan dat een oorzaak zijn?
nevermind, eth2 is niet verbonden, dus dit heeft er niks mee te maken. Hoe kan ik dit het beste Trouble shooten?
[ Voor 14% gewijzigd door kariem112 op 16-06-2020 19:42 ]
Volgens mij heb ik het zelfde probleem. Alleen RTL7 deed het nog. Ik had geen tijd om te troubleshooten dus ik heb tijdelijk even de Fritzbox terug gehangen. Dit weekend even kijken of ik het kan reproduceren.:
Sinds enkele dagen krijg ik weer de melding om naar een andere zender te zappen.... niks aan de config veranderd, geen firmware updates laten uitvoeren. Nu log ik in op de USG4, en krijg ik dit te zien:
show dhcp client leases
interface : eth2
last update: Tue Jun 16 18:46:49 CEST 2020
reason : FAIL
Kan dat een oorzaak zijn?
FYI: USG3 --> US-8 --> VIP5202.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/eY6f7aIwdOKCNesBPsJbbIjp.jpg?f=user_large)
De actuele opbrengst van mijn Tibber Homevolt
Verduurzamen doe je niet voor je portemonnee, maar voor je kroost. | Huis: A++++ | Zon: SolarEdge 10k Homehub, 13kWp, 19,4kWh accu’s | MV: DucoBox Focus | Warmtepomp: ME Ecodan SW75YAA met EHST20D | Tuin: natuurinclusief | Auto: Audi Q4 etron
ph34r my [WCG] Cows :P
VoIP gaat toch tegenwoordig via het Internet gewoon
|| Stem op mooiere Topic Search linkjes! :) " || Pi-Hole : Geen advertenties meer voor je hele netwerk! >:) ||
Ja klopt, maar wil die van Telfort gewoon gebruiken en als ik de Experiabox op een van de swtich poorten aansluit op de WAN aansluting krijg ik geen IP op deze poort.:
[...]
VoIP gaat toch tegenwoordig via het Internet gewoon
Kan ook een andere VoiP afnemen, maar heb deze al.
Bij pauzeren stap je van de multicast stream af. Dus dat hoef je maar 1x te doen
Arcadyan HMB2260 v2 hier. Dus het lijkt niet (alleen) aan de Arris te liggen.
[ Voor 52% gewijzigd door Mrk87 op 18-06-2020 20:30 ]
Ik gebruik nu een tijdje de config van 'coonhva' echter wil ik graag het verkeer ook intern opsplitsen in Vlan. Ondanks het halve topic doorgespit te hebben is het mij nog niet helemaal duidelijk. Het configureren van Vlan zelf is allemaal duidelijk echter mis ik het stuk hoe het iptv verkeer naar een bepaal Vlan doorgezet moet worden zonder de andere vlans tot last te zijn. Ik wil het verkeer liever niet bridgen van de 'publieke' vlans maar gebruik blijven maken routed iptv, kan iemand mij de goede richting insturen
Dit is momenteel mijn config:
10 private
20 guest
30 IPTV
Dit is momenteel mijn config:
De interne vlan's worden:
10 private
20 guest
30 IPTV
:strip_icc():strip_exif()/u/5964/crop56503163e97a5.jpeg?f=community)
Staat hier uitgelegd: https://github.com/coolhva/usg-kpn-ftth#vlans hoor t graag als hier dingen niet duidelijk zijn zodat t verbeterd kan worden (dit stukje had ik namelijk uitgevonden omdat ik problemen had met VLANs terwijl t zonder wel werkte).:
Ik gebruik nu een tijdje de config van 'coonhva' echter wil ik graag het verkeer ook intern opsplitsen in Vlan. Ondanks het halve topic doorgespit te hebben is het mij nog niet helemaal duidelijk. Het configureren van Vlan zelf is allemaal duidelijk echter mis ik het stuk hoe het iptv verkeer naar een bepaal Vlan doorgezet moet worden zonder de andere vlans tot last te zijn. Ik wil het verkeer liever niet bridgen van de 'publieke' vlans maar gebruik blijven maken routed iptv, kan iemand mij de goede richting insturen
Dit is momenteel mijn config:
[...]
De interne vlan's worden:
10 private
20 guest
30 IPTV
Oke, ik had het stukje gezien (en jouw weg er naar toe
) maar denk ik dat ik het verkeerd begrepen had, ik dacht dat het een extra setting was als alles al in vlan is geconfigureerd, maar ik begrijp dus dat onderstaande voldoende is om het naar een vlan te routeren, thanks, ik ga het uitproberen."At the "igmp-proxy" section replace "eth1" with "eth.{vlan}" where {vlan} would be the VLAN where your decoders are in.
"eth1.100": {
"alt-subnet": [
"0.0.0.0/0"
],
"role": "downstream",
"threshold": "1"
}"
Om het iets concreter te maken, hier hoe het bij mij geconfigureerd is::
[...]
Oke, ik had het stukje gezien (en jouw weg er naar toe
"At the "igmp-proxy" section replace "eth1" with "eth.{vlan}" where {vlan} would be the VLAN where your decoders are in.
"eth1.100": {
"alt-subnet": [
"0.0.0.0/0"
],
"role": "downstream",
"threshold": "1"
}"
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
| "protocols": {
"igmp-proxy": {
"interface": {
"eth0.4": {
"alt-subnet": [
"0.0.0.0/0"
],
"role": "upstream",
"threshold": "1"
},
"eth1": {
"role": "disabled",
"threshold": "1"
},
"eth1.200": {
"role": "disabled",
"threshold": "1"
},
"eth1.300": {
"role": "disabled",
"threshold": "1"
},
"eth1.400": {
"alt-subnet": [
"0.0.0.0/0"
],
"role": "downstream",
"threshold": "1"
}
}
}, |
eth1.400 is bij mij de VLAN (400 dus op eth1) voor IPTV waar de proxy actief is, bij de andere VLANs is deze uitgeschakeld.
En voor de duidelijkheid; eth0.4 is de upstream naar KPN toe waar de 4 staat voor het VLAN van IPTV aan hun kant.
[ Voor 4% gewijzigd door Cartman! op 19-06-2020 15:28 ]
/u/771875/crop5ee931e52e3b3_cropped.png?f=community)
Heb jij dit probleem nog kunnen oplossen? Ik heb nu ook alles werkend, maar heb mijn Sonos op een aparte VLAN staan. En kan deze niet met de controller beheren, zonder een extra IGMP proxy (upstream).
**EDIT**
Nog even zitten pielen en uiteindelijk werkend voor elkaar gekregen met de volgende IGMP proxy instellingen in de config.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| "igmp-proxy": {
"interface": {
"eth1": {
"alt-subnet": [
"0.0.0.0/0"
],
"role": "downstream",
"threshold": "1"
},
"eth0.4": {
"alt-subnet": [
"0.0.0.0/0"
],
"role": "upstream",
"threshold": "1"
},
"eth1.20": {
"role": "downstream",
"threshold": "1",
"alt-subnet": "0.0.0.0/0"
}
}
}, |
Daarnaast heb ik een firewall rule aangemaakt met alle benodigde poorten van Sonos (https://support.sonos.com/s/article/688?language=en_US) en deze toegang gegeven tot de LAN.
So far so good.....
[ Voor 29% gewijzigd door semmtex op 20-06-2020 14:05 . Reden: Nieuwe info. ]
:strip_exif()/u/68185/crop5aacf7c17c46e_cropped.gif?f=community)
Blijf toch raar vinden dat bij de ene wel freezes voorkomen en bij een ander niet met hetzelfde script:
[...]
Geen last van freezes elke 5 minuten? Zo nee, dan is je config "klaar" genoeg
Ja, er moet toch ergens een verschil te ontdekken zijn ?:
[...]
Blijf toch raar vinden dat bij de ene wel freezes voorkomen en bij een ander niet met hetzelfde script
In mijn geval: xs4all, usg4 pro en de scripts van @Coolhva
Firmware op de switches is de meest recente, de firewall draait op de vorige firmware. Fast leave staat aan....
Heb nog even gekeken naar de CoolHVA config, en los van de manier van configureren en offload configuratie zie ik geen gekke dingen.:
[...]
Ja, er moet toch ergens een verschil te ontdekken zijn ?
In mijn geval: xs4all, usg4 pro en de scripts van @Coolhva
Firmware op de switches is de meest recente, de firewall draait op de vorige firmware. Fast leave staat aan....
Wat mijn setup wel anders maakt:
- IPTV is bij mij een apart netwerk, deze hangt direct aan LAN2 van de USG. Dus ook geen switch in het spel
- Ik heb dus ook geen andere (multicast) devices op dat netwerk. Mogelijk is dat nog iets?
- Ik heb niks met fast leave gedaan, dus heb wat de default ook maar mag zijn
Zoubeginnen met IPTV op eigen VLAN te zetten en kijken of dat verschil maakt.
:strip_icc():strip_exif()/u/16414/crop55b88276a3a5d.jpeg?f=community)
![[Afbeelding]](https://tweakers.net/i/WpfKNdNnOnnnb3AU72ewabKoMSk=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/1oUvJCV4fxBn5zmZ1K7lsN8q.png?f=user_large){kind=link}
![[Afbeelding]](https://tweakers.net/i/t72syPhRbMrJzLmjaUVrr1I0b0A=/full-fit-in/4000x4000/filters:no_upscale():fill(white):strip_exif()/f/image/y8dsFCv2dSZeb0t9KCoxGmn5.png?f=user_large){kind=link}