Gebruik een eigen router i.p.v. de Experia Box

wjb schreef:

Ik ben vandaag met de EdgeRouter Lite 3 over gegaan naar firmware versie 2.0.9.

Ik had verwacht dat ik de IGMP proxy server geen herstart meer hoefde te geven, maar helaas moest ik dat nog wel moeten doen.

Daar was ik ook al tegenaan gelopen, ik heb de regel WAIT_ONLINE_METHOD=ifup weer aan networking toegevoegd want deze was (zoals je al had vermeld) weg na de update. Na het toevoegen van de regel loopt alles weer als een zonnetje. Ik denk niet dat er snel nog een firmware update komt dus voorlopig zitten we denk ik wel veilig

Wanneer komt je ER4 binnen?, en wat moet ik nu met mijn ER4 als de UXG-PRO uitkomt

Mijn script in firstboot.d heeft wel netjes de regel WAIT_ONLINE_METHOD=ifup in /etc/default/networking gezet, dus die heeft z'n werk netjes gedaan.

Toch had de IGMP proxy server nog een herstart nodig.

Die komt dinsdag binnen. Ik ben bang dat je jouw ER-4 voorlopig nog wel zult moeten gebruiken. Ik heb nog geen indicaties gezien dat de UXG-PRO een IGMP proxy server huisvest. Daar kon ik dus niet op wachten en dus moest ik er zelf maar ééntje kopen. 

Ik heb contact gehad met een van de EA testers die in de US wel de UXG-PRO kunnen bestellen voor een belachelijk bedrag van 499 dollar. Hij heeft alle opties die ik met KPN nodig hebt getest (meerdere VLAN's op WAN, pppoe op WAN, IGMP proxy) dus ik ging ervan uit dat dit de mogelijke opvolger zou worden van de ER4.

Ik ga hem voor de zekerheid nog maar een keer lastig vallen, tot die tijd is het de ER4 die eigenlijk perfect zijn werk doet

___________________________________________________________________________________________________

Mijn script in firstboot.d heeft wel netjes de regel WAIT_ONLINE_METHOD=ifup in /etc/default/networking gezet, dus die heeft z'n werk netjes gedaan.

Toch had de IGMP proxy server nog een herstart nodig.

ik had iets vergelijkbaars, ik had de regel WAIT_ONLINE_METHOD=ifup onderaan de tekst in networking file ingevoegd en toen moest ik ook een restart geven, nadat ik de regel bovenaan in het networking file had geplaatst was een restart niet meer nodig. Als ik nu een reboot geef hoef ik geen restart igmp-proxy te geven en loopt alles netjes in de boot

Over UXG Pro / UDM Pro vs ander merk: ik heb de UDM Pro overwogen als vervanger van mijn USG 3P, ik wilde een krachtigere router. Maar de ontwikkelingen bij UniFi gaan erg traag, het is bij de USX-Pro nog de vraag wanneer alle functionaliteit in de GUI komt en wanneer dat dan stabiel draait. En ik heb geen 10Gb aansluiting nodig in een router. Wel in een switch.

Ik wilde nu een stabiele, snellere router die ook goed overweg kan met mijn UniFi “stack” zoals jullie dat noemen. Via turorials van Lawrence Systems kwam erg vaak de pfSense naar voren als alternatief. Had ik nog nooit van gehoord, maar schijnt al vele jaren te bestaan en heel stabiel te zijn. En alle instellingen in de GUI, config json files hebben niet mijn voorkeur (maar dat is persoonlijk ). Voorlopig bevalt pfSense mij erg goed.

@Bekabeld,

PfSense is ook een prima opensource SW waar je veel kan tweaken.

Had je nog wat aan mijn uitleg in je PM bericht iz IGMP?

@Multiedje Oh nog niet gezien, sorry. Veel dank alvast voor je moeite! Ga er morgen naar kijken.

Bij mij werd de regel WAIT_ONLINE_METHOD=ifup  niet toegevoegd bij het gebruik van firmware v1.10.11. Na de upgrade naar v2.08-hotfix.1 werd hij dat wel. 

Ik weet niet of dat alleen bij mij het geval was, maar misschien handig om hier te vermelden om eventueel zoekwerk te voorkomen.

Ik gebruik overigens de ER 12.

Had jij dan de recente configuratiescripts of de bootstrap fix van 6 november uit het openingstopic gebruikt voor het configureren van jouw ER-12?

Ja, die had ik gebruikt.

Welke, de recente configuratiescripts en de bootstrap fix?

In beide gevallen is het overigens correct dat na een firmware upgrade die setting weer aan /etc/default/networking toegevoegd is, dat is precies waar die configuratie voor aangepast zijn.

Om niet aan mezelf te twijfelen zelfs een aantal keren volledig opnieuw begonnen met een volledig schone installatie. Dus eerst factory reset.

Draaide lang met de v1.10, omdat ik wilde wachten op v2.09. Maar om dit uit te proberen toch maar nog een upgrade naar 2.08hf.1 gedaan.

EPiC schreef:

EPiC schreef:

wjb schreef:

EPiC schreef:

wjb schreef:

EPiC schreef:

dhcp op de edgerouter disblen is ook geen probleem (pihole kan di prima overnemen), vraag is meer of er in de edgerouter niet ergens iets expliciet is opgehangen hieraan.

Je kunt inderdaad de DHCP server ook disablen. Ik ben daar echter absoluut geen voorstander van. Mijns inziens is de router het aangewezen apparaat om als DHCP server te fungeren en al helemaal als we daarbij ook nog eens IPv6 SLAAC gebruiken.

heb je ook wel een punt, voordeel van dit naar de pihole verhuizen is dat apparaten dan automatisch altijd op zeker via je pihole lopen (tenzij ze een hardcoded dns hebben).

Dat zal ook zo zijn met die dns forwarding naar alleen de pihole.

Als je dat niet vertrouwt en echt wil dat het IP adres van de pihole meegegeven wordt naar de aangesloten apparaten dan kan je het IP adres van de pihole ook in de DHCP server zelf als DNS server meegeven i.p.v. het IP adres van de EdgeRouter.

Je maakt dan echter geen gebruik meer van de dns cache op de EdgeRouter en kan apparaten ook niet meer benaderen op hun naam binnen het domein.

Heb beiden gedaan nu, maar loop tegen het obstakel aan dat ik in de Pi-hole enkel het ip-nr. van de Edgerouter zie en niet van de diverse onderliggende cliënts; zie foto...

Pi-hole kan deze wel herleiden als die zelf de dhcp doet (logisch), maar als de dhcp niet door pihole wordt gedaan zou je die wel kunnen uitlezen dmv enabbe conditional forward in Pihole `(192.168.2.0/24 | 192.168.2.254 | thuis.local)` en heb Zekerheidshalve tevens Never forward non-FQDNs & Never forward reverse lookups for private IP ranges disabled. Helaas komen de cliënts niet door in de query log, lastig want niet kun je dus niet de individuele cliënt zien aangezien alles op 1 hoop onder 192.168.2.254 binnenkomt.

Is dat een instelling die in de Edgerouter dan nog anders kan/moet? Want conditional forward helpt normaliter dus wel, alleen blijkt nu in dit geval geen oplossing te bieden. Daar ter test ook in de dns van de dhcp server de Pihole opgegeven naast de dns forward. Of zou ik nu wellicht juist bewust de dns forward uit moeten zetten en alleen de dns opgeven bij de dhcp server (die combinatie heb ik nog niet geprobeerd).

 

Het volgende nog eens (succesvol) geprobeerd: 

Disabled `DNS forwarding` in mijn EdgeRouterX (service / dns / forwarding : DNS forwarding).

Vervolgens de DNS naar mijn Pi-hole ingesteld in de `dhcp-server` (edgerouter), dus hier in deze dhcp server heb ik bij DNS1 `192.168.2.10` ingevuld, wat dus mijn Pi-hole is, reboot...

En op dit moment zie ik (tot op heden) nu wèl de client id's verschijnen in de query log van de Pihole. Schijnbaar werkt dat dus niet als je DNS-forwarding gebruikt, krijg het met geen mogelijkheid voor elkaar in elk geval. Dan krijg ik dus altijd het ip van de Edgerouter te zien (192.168.2.254) te zien zoals zichtbaar in bovenstaande foto in plaats van de hostnames van de clients. 

Wellicht is dit een 'by design' wellicht? 

In dit scenario komen alle client-IP's (dan wel hostnames) wèl netjes door.  Ik moest`DNS forwarding` wel uitschakelen, zoals in quote hierboven vermeld, omdat ik anders voor alle netwerkverkeer altijd alleen het IP-adres van de EdgeRouterX te zien kreeg namelijk. 

In elk geval, aansluitend heb ik het `hardcoded DNS forward` trucje toegepast. Alleen komt dan dus (o.a.) mijn Chromecast niet meer door onder zijn eigen client-id (IP en/of hostname), maar standaard onder het Edgerouter IP-adres (192.168.2.254). De rest van de apparatuur, zonder een hardcoded-dns, komt wel gewoon netjes afzonderlijk vermeld door (eigen IP's). 

Dat is wel èrg jammer, de vraag is dan ook, kan dat niet anders? OF is dit helaas echt een onontkoombaar 'logisch gevolg van'?

Ik gebruik deze instellingen in mijn Edgerouter X (spf), onder source- en destination NAT; 

(Source NAT) Masquerade for DNS: 

https://www.dropbox.com/s/t6w1nkhlil529at/Screenshot_20201104-204721__01.jpg?dl=0

(Destination NAT)Captive DNS: 

https://www.dropbox.com/s/k8fk6x5ybwfyezt/Screenshot_20201104-204753__01.jpg?dl=0

Mijn EdgeRouterX (SPF) is 192.168.2.254 (gateway) en in de  Edgerouter's DHCP-Server-> Thuis => View details heb ik de DNS1 dus naar mijn Pihole (192.168.2.10) gezet. DNS2 leeg laten of bijvoorbeeld op 192.168.2.254 zetten maakt ook geen verschil, voor de beeldvorming wel even uitgeprobeerd. 

Hopelijk heb ik het een beetje duidelijk uit kunnen leggen wat concreet probleem is. Als ik de Masquerade- en de Captive DNS regeltjes onder NAT uitschakel dan zie ik dus wel weer het ChromeCast ip-nr. i.p.v. die van de EdgerouterX.

@EPiC,

Ik ga ervan uit dat het doel is om reclame te blocken. Waarom gebruik je niet gewoon DNS op je Edgerouter van adguard: https://adguard.com/en/adguard-dns/overview.html Deze gebruik ik zelf ook op mijn ER4 en werkt prima. Als je nog een stapje verder wilt kan je ook Family protection DNS gebruiken.

Ik weet niet wat voor een verbinding je hebt van KPN en welke PI want het zou ook nog kunnen zijn dat je jezelf limiteert in bandbreedte. De Pi 3 en ouder heeft namelijk alleen  een 100MB NIC

Daarmee heb ik niet in de hand wat wel & niet, juist via Pi-hole wèl (je kan evt. ook Adguard als sinkhole-dns installeren, zelfde concept dan als pihole). Als je enkel de Adguard-dns in je Edgerouter kiest dan is dat vervolgens altijd alles of niks. Nu bepaal ik welke adlists (malware, anti-ads, porn, tracking, etc.), extra expliciet black- en/of whitelisten en evt. welke apparaat wel/niet etc.etc.etc.

Tevens extra mogelijkheden met bijvoorbeeld DOH/DOT, of in mijn geval annonimized DNScrypt en zo is er nog veel meer mogelijk (denk bijv. aan unbound).

Daarbij voor dns requests 'limit' je dus niks, want verbruikt nagenoeg geen data/bandbreedte. Het werkt juist zelfs uitstekend op een Pi Zero.

Feitelijk dus niet te vergelijken en bijt je dan ook zeker niet in de performance. (family protection is overigens helemaal een drama, dan loop je alleen maar tegen ellende aan, als in wat allemaal niet meer functioneert 😉)

Heb je dan ook het (v)lan uit de dns forwarding weggehaald.

Zie Config Tree -> service -> dns -> forwarding -> listen-on en options.

Dan zou namelijk het iP adres van jouw Pi-Hole aan de DHCP cliënts gegeven moeten worden en zouden DNS requests dus rechtstreeks aan de Pi-Hole gericht moeten zijn.

Yep, dns forwarding had ik dus al bewust disabled want anders kreeg ik op alle request sowieso de edgerouter als afzender. Als ik dus het 'hardcoded dns forward' trucje doe dan krijg ik juist dat dus weer wel opnieuw alleen dan enkel voor de apparaten die dit als dusdanig aansturen (bijv. ChromeCast, die komt dan weer door onder .2.254 ipv het eigen ip)

Wat bedoel je nu met het "hardcoded dns forward trucje"?

Ik heb de TV ontvangers op een apart vlan staan met een eigen DHCP server.

Dit o.a. omdat ik standaard de DNS servers van Cloudflare gebruik en de Arris VIP 5202 daar niet goed mee om kan gaan bij upgrades van de firmware omdat Cloudflare geen compression toepast en de 5202 dat vereist (  ).

Voor vlan 4 heb ik de DNS servers van KPN dan ook in de DHCP server vastgelegd.

Ik zie DNS requests dan ook rechtstreeks naar de DNS server van KPN.

Oke mensen ik heb de IPTV werkend via de EB12 en Arris 5202. Het probleem was de HDMI kabel.

Nu heb ik geprobeerd de EB ertussenuit te halen en de pfSense direct op de NTU aan te sluiten:

1. Arris uitgezet.
2. ethernetkabel van NTU naar EB12 omgeplugd naar pfSense
3. Check in dashboard: zowel IPTV als Internet VLANs zijn verbonden
4. Arris verbonden met pfSense
5. Arris aangezet.  Ik zie het volgende: “welkom terug bij interactieve TV” 75%, dan 80%, 85%, 90%, klaar.
6. Ik krijg dus wel verbinding.
7. ik krijg geen beeld, wel de zenderinformatie onderin:

Na een paar seconden krijg ik deze melding:

iemand een idee waar ik kan beginnen? Ik ga in elk geval alle instellingen van de IGMP/multicast nog eens langs.

Dit duidt op een probleem met de IGMP proxy server en/of de route naar het IPTV platform.

Is rfc3442-classless-static-routes actief op die pfSense machine?

Loopt de route naar 213.75.112.0/21 netjes over vlan 4?

Onderstaand screenshot is uit de.route tabel op een EdgeRouter, met pfSense ziet de routing tabel er vast anders uit.

Oke het werkt nu. Ik heb de request option “broadcast-address” toegevoegd. Ik had eerst dit staan, conform swords blog:

maar Vikash had nog een 4e option in zijn setup:

Nu heb ik beeld én de stream is continu. Ik zie wel af en toe een kleine onderbreking, waarbij het beeld heel even stil staat en dan vanzelf weer verder gaat.

Nu eerst maar eens een paar dagen gaan kijken met de hele familie en zien hoe het bevalt.

Dank hier alvast nog maar eens een keer voor alle steun en instructies.

Edit: excuses wjb, onze berichten hebben elkaar gekruist

Oeps, te vroeg gejuicht. Na een minuut of 10 staat het beeld stil.

Nog een keer aangezet, nu na 4:30 weer stil. Dit is de melding die erbij hoort:

Na heen- en terug zappen gaat de stream weer verder.

Volgens mij ben ik er bijna 

Edit: oke ik heb nu weer 2x getimed: de stream stopt steeds bij ongeveer 4:20. Dus 260 seconden.

Bekabeld schreef:

wjb schreef:

Loopt de route naar 213.75.112.0/21 netjes over vlan 4?

Onderstaand screenshot is uit de.route tabel op een EdgeRouter, met pfSense ziet de routing tabel er vast anders uit.

 

 

Dat ziet er goed uit.

260 seconden is precies de timeout voor IGMP snooping.

Heb jij een ander apparaat in jouw netwerk hangen die ook een IGMP proxy server huisvest.

Heb je overigens de IGMP quickleave optie aan staan?

@wjb Nee, ik had zelfs de STB direct aangesloten op de LAN poort van de pfSense. Dus het was de enige client. Inmiddels heb ik even de UniFi US8 switch ertussen gezet om de pfSense config te kunnen tweaken. Maar bij elke test (zit nu al op 5 a 8 keer) is het 260 seconden.

Dit zijn mijn IGMP proxy upstream instellingen:

De 213.75.167.0/24 en 217.166.224.0/22 zijn conform swords blog, de 217.166.0.0/16 is van tweaker Ik222. Maar die overlappen.

Dit zijn de instellingen van Vikash:

Die zijn een stuk ruimer gekozen. Wellicht dat ik die eens zou kunnen proberen?

Oke, er waren weer 260 seconden voorbij en het beeld stond weer stil. Vervolgens heb ik 10.0.0.0/8 toegevoegd:

Ik druk op Save en Apply. Na een paar tellen loopt de stream de gestopt was ineens weer verder! Hmmm… en na 2 min of zo (niet getimed) stopt ie weer.

Ik heb zelf 0.0.0.0/0 ingesteld staan.

Mocht KPN onverhoopt een keer mogen beslissen de IP adressen van de IPTV servers te wijzigen dan heb ik daar in ieder geval geen last van.

Overigens is 213.75.112.0/21 voldoende.

Het zal ook niet de oorzaak zijn van het probleem dat jij ervaart.