[Ubiquiti & IPTV] Ervaringen & Discussie

[Verwijderd]

The-Priest-NL schreef op dinsdag 16 april 2019 @ 08:08:
[...]

Nee klopt is ook meer "niet omdat het moet maar omdat het kan"


[...]

Ahh check, die klik miste ik nog, je kan dus waarschijnlijk bij T-mobile wel gewoon routed IPTV doen.


[...]


Lijkt me een goed plan en daar wil ik natuurlijk van harte aan meewerken.
Misschien is het handig om eerst e.e.a. via DM kort te sluiten om zo het topic niet te vervuilen daarmee?

Was het nog gelukt met de een Routed config voor T-Mobile Thuis? Ik zou hem namelijk best willen testen

[thijsjek]

Ik heb nu zelf Iptv via kpn aan het werk op de usg 3p. ik heb echter een vervelend probleem waar ik niet uit kom.
Ik krijg een melding van dat poort 8 geblokkeerd door STP protocol op de us-8-60. Dan valt ook IPTV uit voor een tijdje.
Topologie:
USG3p --> US-8-60w --> ap ac iw --> setop box kpn. Ik heb verder de config van xbeam gevolgd.

[nero355]

thijsjek schreef op zaterdag 22 juni 2019 @ 19:36:
Ik krijg een melding van dat poort 8 geblokkeerd door STP protocol op de us-8-60. Dan valt ook IPTV uit voor een tijdje.
Topologie:
USG3p --> US-8-60w --> ap ac iw --> setop box kpn. Ik heb verder de config van xbeam gevolgd.

Zitten daar ook ergens Sonos clients tussen ?!

Sonos spullen kunnen een loop op je netwerk veroorzaken en dan krijg je inderdaad STP meldingen!

[thijsjek]

nero355 schreef op zondag 23 juni 2019 @ 19:54:
[...]

Zitten daar ook ergens Sonos clients tussen ?!

Sonos spullen kunnen een loop op je netwerk veroorzaken en dan krijg je inderdaad STP meldingen!

Ja een sonos one, als een wireless client. Nu ik hem bedraad heb aangesloten geeft hij geen problemen meer.

[Goz3rr]

Ik ben zelf een poging aan het doen om een Experia Box v8 (Telfort glasvezel) te vervangen door een Ubiquiti USG 3P. Internet werkend krijgen was bijna direct klaar, gewoon kabeltje van de FTU naar WAN1 van de USG en in network VLAN 34 aanzetten (ipv 6 bij KPN).

Nu probeer ik echter de IPTV ook werkend te krijgen maar het wil nog niet helemaal lukken. Ik ben begonnen met deze config.gateway.json:

code:

{
    "interfaces": {
        "ethernet": {
            "eth0": {
                "vif": {
                    "34": {
                        "address": [
                            "dhcp"
                        ],
                        "description": "eth0.34 - Internet",
                        "dhcp-options": {
                            "client-option": [
                                "retry 60;"
                            ],
                            "default-route": "update",
                            "default-route-distance": "1",
                            "name-server": "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"
                            }
                        }
                    }
                }
            }
        }
    }
}

Na deze te provisionen blijft internet gewoon werken. Vervolgens bereid ik de config uit naar het volgende:

code:

{
    "interfaces": {
        "ethernet": {
            "eth0": {
                "vif": {
                    "4": {
                        "address": [
                            "dhcp"
                        ],
                        "description": "eth0.4 - 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": "update"
                        },
                        "ip": {
                            "source-validation": "loose"
                        }
                    },
                    "34": {
                        "address": [
                            "dhcp"
                        ],
                        "description": "eth0.34 - Internet",
                        "dhcp-options": {
                            "client-option": [
                                "retry 60;"
                            ],
                            "default-route": "update",
                            "default-route-distance": "1",
                            "name-server": "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"
                            }
                        }
                    }
                }
            }
        }
    },
    "protocols": {
        "igmp-proxy": {
            "interface": {
                "eth0.4": {
                    "alt-subnet": [
                        "0.0.0.0/0"
                    ],
                    "role": "upstream",
                    "threshold": "1"
                },
                "eth1": {
                    "alt-subnet": [
                        "0.0.0.0/24"
                    ],
                    "role": "downstream",
                    "threshold": "1"
                }
            }
        },
        "static": {
            "route": {
                "213.75.112.0/21": {
                    "next-hop": {
                        "10.247.220.1": "''"
                    }
                }
            }
        }
    }
}

Bijna direct nadat ik deze aanpassingen provision valt de internet verbinding weg. De DHCP lease voor VLAN34 blijft nog even bestaan:

code:

admin@USG:~$ show dhcp client leases
interface  : eth0.34
ip address : 86.83.61.xxx       [Active]
subnet mask: 255.255.255.0
router     : 86.83.61.1
name server: 213.75.63.75 213.75.63.76
dhcp server: 86.83.61.1
lease time : 600
last update: Mon Jun 24 23:19:40 CEST 2019
expiry     : Mon Jun 24 23:29:36 CEST 2019
reason     : RENEW

interface  : eth0.4
ip address : 10.247.222.115     [Active]
subnet mask: 255.255.252.0
router     : 10.247.220.1
dhcp server: 10.247.220.1
lease time : 3600
last update: Mon Jun 24 23:20:27 CEST 2019
expiry     : Tue Jun 25 00:20:22 CEST 2019
reason     : BOUND

En word tcpdump -ni eth0 gevuld met enkel het volgende

code:

23:20:43.416287 ARP, Request who-has 86.83.61.1 tell 86.83.61.xxx, length 28
23:20:44.416298 ARP, Request who-has 86.83.61.1 tell 86.83.61.xxx, length 28
23:20:45.442614 ARP, Request who-has 86.83.61.1 tell 86.83.61.xxx, length 28
23:20:46.436293 ARP, Request who-has 86.83.61.1 tell 86.83.61.xxx, length 28

Zodra de DHCP lease voor VLAN 34 verloopt veranderd de netwerk dump naar:

code:

23:42:13.566443 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:e8:29:42:2c:b0, length 300
23:42:26.676442 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:e8:29:42:2c:b0, length 300
23:42:34.536328 IP 10.247.222.115 > 224.0.0.22: igmp v3 report, 1 group record(s)
23:42:38.786324 IP 10.247.222.115 > 224.0.0.22: igmp v3 report, 1 group record(s)
23:42:41.246450 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:e8:29:42:2c:b0, length 300
23:42:59.796456 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:e8:29:42:2c:b0, length 300
23:43:54.776679 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:e8:29:42:2c:b0, length 300
23:44:02.476445 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:e8:29:42:2c:b0, length 300
23:44:05.017613 IP 10.60.151.31 > 224.0.0.1: igmp query v3
23:44:17.116448 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:e8:29:42:2c:b0, length 300
23:44:33.816451 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 18:e8:29:42:2c:b0, length 300

Zoals ook te zien is komt er wel gewoon verkeer tussen door voor het IPTV VLAN, en kan ik zelfs zonder problemen de IPTV DHCP lease vernieuwen met "renew dhcp interface eth0.4", of de router daar pingen, iets wat niet werkt over het gewone internet:

code:

admin@USG:~$ ping 10.247.220.1
PING 10.247.220.1 (10.247.220.1) 56(84) bytes of data.
64 bytes from 10.247.220.1: icmp_req=1 ttl=255 time=0.936 ms
64 bytes from 10.247.220.1: icmp_req=2 ttl=255 time=0.368 ms
64 bytes from 10.247.220.1: icmp_req=3 ttl=255 time=0.352 ms
^C
--- 10.247.220.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.352/0.552/0.936/0.271 ms

admin@USG:~$ ping 86.83.61.1
connect: Network is unreachable

Als ik vervolgens terug ga naar de 1e config en deze provision, moet ik ongeveer 30 minuten wachten tot het internet weer toegankelijk is. Ondertussen de FTU of USG herstarten lijkt hier geen effect op te hebben. Iemand een idee wat ik verkeerd doe?

[MisteRMeesteR]

@Goz3rr Volgens mij komt dit gedrag doordat je met hetzelfde MAC-adress (de bia van Eth0) twee DHCP requests wilt doen. Ik heb dit vergelijkbare gedrag ook gezien:

MisteRMeesteR in "[Telfort xDSL] Ervaringen & Discussie - Deel 20"

[Goz3rr]

@MisteRMeesteR Bedankt, dit was het interdaad. Ik had dit al een keer eerder geprobeerd (met de oude MAC adressen van de Experia Box), maar liep toen tegen wat hetzelfde probleem leek aan. Nu weer, alleen na 10 minuten verviel de oude DHCP lease en begon het internet weer te werken.

Nu loop ik helaas tegen het volgende probleem aan. De STB start op en laat een paar frames en wat seconden geluid zien, om daarna te klagen dat de zender niet beschikbaar is. Even een seconde of twee de zender op pauze zetten en het probleem is verholpen, tot je van zender wisselt. Eerder in deze thread lijkt @captnemo hetzelfde probleem te hebben, maar bij mij staan IPS en IPv6 allebei al uit

Voor wat het uitmaakt mijn huidige opstelling is USG -> GS105Ev2 -> GS105Ev2 -> STB. Beide switches hebben IGMP snooping aan staan en waren ook al in gebruik met de Experia box, zonder problemen.

[ Voor 8% gewijzigd door Goz3rr op 25-06-2019 19:10 ]

[ik222]

@Goz3rr Dat gedrag duidt op een probleem met IGMPProxy, hoe heb je die config staan? En probeer anders sowieso eens die service te herstarten.

[Goz3rr]

@ik222 Mijn config ziet er als volgt uit:

code:

        "protocols": {
                "igmp-proxy": {
                        "interface": {
                                "eth0.4": {
                                        "alt-subnet": [
                                                "0.0.0.0/0"
                                        ],
                                        "role": "upstream",
                                        "threshold": "1"
                                },
                                "eth1": {
                                        "alt-subnet": [
                                                "0.0.0.0/24"
                                        ],
                                        "role": "downstream",
                                        "threshold": "1"
                                }
                        }
                },
                "static": {
                        "route": {
                                "213.75.112.0/21": {
                                        "next-hop": {
                                                "10.35.224.1": "''"
                                        }
                                }
                        }
                }
        },

Ik voer "/opt/vyatta/sbin/config-igmpproxy.pl --action=restart" uit, en power cycle voor de zekerheid de 2 switches en STB, maar nog geen verschil.

edit: Ik zat met m'n domme kop gewoon niet op te letten:

code:

admin@USG:~$ ps aux | grep igmp
admin     9806  0.0  0.1   2184   628 pts/0    S+   20:33   0:00 grep igmp

Ik zag een regel output en stopte met lezen, schijnbaar werkt dat config-igmpproxy.pl commando dus niet? Ipv daarvan "restart igmp-proxy" gebruikt, nu draait igmpproxy wel degelijk en zijn de problemen weg! Bedankt!

[ Voor 12% gewijzigd door Goz3rr op 25-06-2019 21:21 ]

[thijsjek]

thijsjek schreef op maandag 24 juni 2019 @ 18:24:
[...]


Ja een sonos one, als een wireless client. Nu ik hem bedraad heb aangesloten geeft hij geen problemen meer.

Ik heb nog even verder onderzoek uitgevoerd. Sonos bedraad levert geen problemen op. Als wireless uplink aanstaat voor m'n AP AC mesh in de tuin, dan krijg ik meerdere dhcp errors en hapert de het IPTV signaal bij elke gebeurtenis (5minuten). Nu dus maar wireless uplink uitgeschakeld.

Is er een oplossing voor dit probleem met wireless uplink?

Update:
Wireless uplink stond niet goed ingesteld, vanaf de basis weer opnieuw ingesteld en werkt weer naar behoren.

[ Voor 9% gewijzigd door thijsjek op 29-06-2019 20:29 ]

[Gunner]

Goed, na lang overwegen heb ik een USG gekocht om m'n Experiabox te vervangen. Het loopt alleen voor geen meter. Na heel veel problemen om het apparaat uberhaupt adopted te krijgen heb ik het voor elkaar.

Echter, ik krijg geen PPoE interface onine. Met de username kpn/kpn werkt het niet en de handleiding volgende van https://www.free2wifi.nl/2018/09/25/ubnt-usg-iptv/ krijg ik geen eens output met dit commando om de iptv hop te bepalen.

code:

show dhcp client leases interface eth0.4

Frustratie alom... wat doe ik fout??

Vremde is ook dat ik geen IP krijg op de WAN poort;

code:

Incomplete command
admin@ubnt:~$ info

Model:       UniFi-Gateway-3
Version:     4.4.41.5193700
MAC Address: 18:e8:29:42:32:02
IP Address:  0.0.0.0
Hostname:    ubnt
Uptime:      1246 seconds

Status:      Connected (http://192.168.2.41:8080/inform)

nu heb ik een default json gekopieerd naar

code:

cp -f ./config.gateway.json /var/lib/unifi/sites/default

Re-provision...
even kijken wat dat doet.....

[ Voor 27% gewijzigd door Gunner op 29-06-2019 21:07 ]

[ik222]

Je hebt dus nog totaal geen verbinding, want zowel je PPPoE sessie over VLAN 6 werkt niet en je krijgt ook geen IP adres via DHCP in VLAN4.

Een paar vragen:
- Hoe zit je USG aangesloten op de NTU of FTU van KPN?
- Welke config heb je er nu precies op staan?
- Is je config überhaupt succesvol geladen?
- Wat zeggen je logs.

Overigens wat een bullshit op die handleiding die je linkt betreffende source-validation, moest er wel om lachen. Eerst een wazig klok en klepel verhaal dat hackers zo je netwerk binnenkomen als je het uitzet. En dan daarna zelf met een oplossing komen waarbij het enige voordeel boven uitzetten is dat je van binnenuit niets naar buiten kan spoofen, iets wat je ISP sowieso zal blokkeren

[Gunner]

ik222 schreef op zaterdag 29 juni 2019 @ 21:23:
Je hebt dus nog totaal geen verbinding, want zowel je PPPoE sessie over VLAN 6 werkt niet en je krijgt ook geen IP adres via DHCP in VLAN4.

Een paar vragen:
- Hoe zit je USG aangesloten op de NTU of FTU van KPN?
- Welke config heb je er nu precies op staan?
- Is je config überhaupt succesvol geladen?
- Wat zeggen je logs.

Overigens wat een bullshit op die handleiding die je linkt betreffende source-validation, moest er wel om lachen. Eerst een wazig klok en klepel verhaal dat hackers zo je netwerk binnenkomen als je het uitzet. En dan daarna zelf met een oplossing komen waarbij het enige voordeel boven uitzetten is dat je van binnenuit niets naar buiten kan spoofen, iets wat je ISP sowieso zal blokkeren

Ik heb geen idee hoe,maar ondanks dat de SSh client nog steeds 0.0.0.0 zegt qua internet heb ik wel verbinding en m'n vrouw kan gewoon tv kijken. Opnames via KPN gingen niet maar ineens kon ik via dat commando wel de hop bekijken van onze wijkcentrale en heb ik deze provisioned. Nu kan ik wel opnames kijken

Vaag allemaal en het heeft blijkbaar tijd nodig maar alles lijkt nu te werken zoals ik wil

[ik222]

Goed dat het werkt, die nexthop is helaas alleen niet vast voor je wijkcentrale, met een keer opnieuw opstarten of na onderhoud kun je zo in een ander subnet komen.

Het blijft gewoon erg jammer dat zo'n USG RFC3442 niet ondersteund. Er zijn wel scripts te vinden / maken om het nexthop goedzetten te automatiseren.

[ Voor 4% gewijzigd door ik222 op 30-06-2019 00:09 ]

[marcel19]

Al enige tijd ben ik een tevreden gebruiker van Ubiquiti.
Ook heb ik al enige tijd een edgerouter X gehad in mijn netwerk als vervanging van het ISP modem.

Aangezien deze defect is gegaan, heb ik de overstap gemaakt naar de USG 3P.
Ik zou graag willen weten hoe ik deze instel dat uit LAN1 internet komt, en uit de VOIP poort juist IPTV.

Wij hebben 1 tv in huis, en deze zal rechtstreeks aangesloten worden op de USG.
Ik heb al wel zitten kijken in de USG, maar ik krijg het niet voor elkaar

Iemand met een duidelijke tutorial welke mij meer op weg kan helpen hiermee?
Heb voor mijn gevoel overal al een beetje gekeken, en dan zie ik elke keer de oplossing met een unifi switch, maar die mogelijkheid heb ik op dit moment niet.

[nero355]

marcel19 schreef op maandag 1 juli 2019 @ 19:58:
Heb voor mijn gevoel overal al een beetje gekeken, en dan zie ik elke keer de oplossing met een unifi switch, maar die mogelijkheid heb ik op dit moment niet.

Het gaat erom dat je een Managed Switch hebt en zo duur zijn die niet meer :
- pricewatch: Netgear Prosafe Gigabit Plus GS105E
- pricewatch: Netgear Prosafe Gigabit Plus GS108Ev3

Één van die twee kan je zelfs van je ISP krijgen geloof ik als je bij één van de KPN Glasvezel providers zit

[marcel19]

@nero355

Die heb ik nog wel liggen hier ik zit bij T-mobile.

Heb je een idee waar ik een schets kan inzien, of hoe dit dan werkt?
Komt hij dan tussen de USG en de NTU?

En dan het IPTV kastje rechtstreeks op de Netgear switch met het juiste vlan?


edit: na wat gepiel is alles gelukt.

Heb nu de Netgear GS105e tussen de USG en het NTU zitten.
Tv rechtstreeks op de netgear, en een kabel naar de USG.

alles lekker gescheiden en alles werkt.

[ Voor 46% gewijzigd door marcel19 op 02-07-2019 20:48 ]

[xbeam]

ik222 schreef op zaterdag 29 juni 2019 @ 21:23:
Je hebt dus nog totaal geen verbinding, want zowel je PPPoE sessie over VLAN 6 werkt niet en je krijgt ook geen IP adres via DHCP in VLAN4.

Een paar vragen:
- Hoe zit je USG aangesloten op de NTU of FTU van KPN?
- Welke config heb je er nu precies op staan?
- Is je config überhaupt succesvol geladen?
- Wat zeggen je logs.

Overigens wat een bullshit op die handleiding die je linkt betreffende source-validation, moest er wel om lachen. Eerst een wazig klok en klepel verhaal dat hackers zo je netwerk binnenkomen als je het uitzet. En dan daarna zelf met een oplossing komen waarbij het enige voordeel boven uitzetten is dat je van binnenuit niets naar buiten kan spoofen, iets wat je ISP sowieso zal blokkeren

https://www.iij.ad.jp/en/dev/tech/sav/

[ik222]

Ja ik weet wat source validation doet maar het voegt hier op je thuis firewall helemaal niets toe en je kunt het prima simpelweg uitzetten.

Loose mode heeft al helemaal geen zin hier, immers omdat je een default route hebt naar buiten is er voor elke bestemming een route. Blijft over strict mode op de WAN, die zorgt er in potentie voor dat verkeer met als source adres een route over de ITV interface of de interne subnets gedropt worden op de WAN interface. Echter ook dit voegt in de praktijk hier niets toe, je firewall werkt toch op source interface en daarnaast zal je ISP gespoofed verkeer sowieso al blokkeren.

Op de juiste plek in een ISP netwerk is source validation overigens wel heel zinnig.

[QempZoR]

Vandaag weer geprobeerd om de USG aan te zetten. Heeft +- half jaar gedraaid, maar nu helaas om de paar minuten “zap naar een andere zender”

Is er in de afgelopen maand iets veranderd bij de Telfort kant? Static route e.d lijken allemaal goed te staan.. FTU 15 min van de stroom geeft helaas ook geen verbetering

EDIT: inmiddels wat dingen uitgesloten en het enige wat ik heb veranderd is 2 nieuwe IP Cams (Kingcams, 1080p AliEx versies)
Via RTSP stream gekoppeld aan de Syno.

Zojuist de camera's uit de switch getrokken, en de IPTV streams lopen nu prima door!
Camera's weer in de switch gedaan en binnen 5 minuten loopt de IPTV weer vast

[ Voor 34% gewijzigd door QempZoR op 07-07-2019 19:37 ]

[To_Tall]

Dat klinkt als een igmp snooping issue.

[kariem112]

QempZoR schreef op zondag 7 juli 2019 @ 14:16:
Vandaag weer geprobeerd om de USG aan te zetten. Heeft +- half jaar gedraaid, maar nu helaas om de paar minuten “zap naar een andere zender”

Is er in de afgelopen maand iets veranderd bij de Telfort kant? Static route e.d lijken allemaal goed te staan.. FTU 15 min van de stroom geeft helaas ook geen verbetering

EDIT: inmiddels wat dingen uitgesloten en het enige wat ik heb veranderd is 2 nieuwe IP Cams (Kingcams, 1080p AliEx versies)
Via RTSP stream gekoppeld aan de Syno.

Zojuist de camera's uit de switch getrokken, en de IPTV streams lopen nu prima door!
Camera's weer in de switch gedaan en binnen 5 minuten loopt de IPTV weer vast

Heb sinds kort dezelfde problemen...heeft het toch een aantal maanden prima gedaan. Heb de meest recente firmware, IGMP snooping staat aan. Echter, geen ip camera's in het netwerk dus, wat het probleem dan is?

igmp proxy lijkt te draaien. Indien de zender vastloopt ik in deze herstart, dan werkt het weer even. Next hop staat ook goed.

[To_Tall]

Na updaten van de next hop even je igmp-proxy herstarten.

Op camera’s werken vaak standaard op broadcast. Zodat elk apparaat in je netwerk onzinnige pakketjes krijgt voorgeschoteld. Broadcasten uitzetten en kijken wat er dan gebeurd.

[QempZoR]

kariem112 schreef op maandag 15 juli 2019 @ 19:18:
[...]

Heb sinds kort dezelfde problemen...heeft het toch een aantal maanden prima gedaan. Heb de meest recente firmware, IGMP snooping staat aan. Echter, geen ip camera's in het netwerk dus, wat het probleem dan is?

igmp proxy lijkt te draaien. Indien de zender vastloopt ik in deze herstart, dan werkt het weer even. Next hop staat ook goed.

Toch vreemd. IGMP snooping staat aan (op de switches) en zodra de camera’s ontkoppeld zijn gaat t goed. IGMP proxy draait ook.

Heb de cameras via V&A maar verkocht. Heb ook nog een Bsder camera liggen (ook ali) en daar totaal geen problemen mee..

[kariem112]

To_Tall schreef op maandag 15 juli 2019 @ 19:42:
Na updaten van de next hop even je igmp-proxy herstarten.

Op camera’s werken vaak standaard op broadcast. Zodat elk apparaat in je netwerk onzinnige pakketjes krijgt voorgeschoteld. Broadcasten uitzetten en kijken wat er dan gebeurd.

Zojuist gedaan... duurt wel langer totdat er een freeze optreed, maar is nog niet opgelost

Ook geen broadcast apparaten in het netwerk... de logging op de USG is ook niet echt veelzeggend.

[TheDuke]

Ik probeer IPTV werkend te krijgen met TriNed (Noord-Brabant) met een EdgeRouter 4.
Ik zie TriNed nog niet in het starttopic van deze thread. Heeft iemand dit al werkend gekregen toevallig?

In het TriNed ervaringen topic heb ik 't een en ander kunnen vinden om internet werkend te krijgen. Dit lukt ook en werkt verder prima. Het IPTV verhaal is wat lastiger… in het TriNed ervaringen topic is er ook niks over te vinden, anders dan het -supposed- VLAN ID.

VLAN ID	Functie	verbindingstype
4	IP-tv	???
6	Internet & VoIP	pppoe

Als ik eth0.4 configureer voor DHCP krijg ik geen ip:

code:

subnt@Thuis:~$ show dhcp client leases
interface  : eth0.4
last update: Wed Jul 17 21:41:34 CEST 2019
reason     : FAIL

Heeft iemand ideeen hoe ik erachter kan komen wat de juiste instellingen zijn? Zo weet ik bijvoorbeeld het static route ook nog niet, maar het IPTV/Vlan4 verbindingstype is de eerste vraag.

EDIT
Na het assignen van het FritzBox mac address aan de Vlan eth0.4 interface krijg ik in ieder geval een IP. Ben weer een stapje verder...

[ Voor 23% gewijzigd door TheDuke op 17-07-2019 22:58 ]

[hermanh]

TheDuke schreef op woensdag 17 juli 2019 @ 21:55:

EDIT
Na het assignen van het FritzBox mac address aan de Vlan eth0.4 interface krijg ik in ieder geval een IP. Ben weer een stapje verder...

Helemaal Goed..

Om te zien wat de static route zou moeten zijn, kun je in DHCP leases kijken in de /VAR map van je edgerouter / USG. ergens in de subfolders staan HDCP Leases (met in de bestandsnaam je eth ID)

In dat tekst bestand staat een bult aan interessante info, inclusief static routing.

Edit: Moest effe zoeken naar een oude post van mijzelf..
Het gaat om wat op de regel : rfc3442-classless-static-routes staat

code:

}
lease {
  interface "eth1.4";
  fixed-address 10.10.51.50;
  option subnet-mask 255.255.248.0;
  option routers 10.10.48.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option dhcp-server-identifier 10.10.0.33;
  option rfc3442-classless-static-routes 24,185,24,175,10,10,48,1,24,185,41,48,10,10,48,1;
  renew 5 2019/01/04 14:34:03;
  rebind 5 2019/01/04 14:58:43;
  expire 5 2019/01/04 15:06:13;
}

[ Voor 34% gewijzigd door hermanh op 18-07-2019 10:53 . Reden: Toevoegen stukje script ]

[Thepierce86]

Big shout out naar onder andere @xbeam !! dankzij dit topic en jou site https://free2wifi.nl/2018/09/25/ubnt-usg-iptv/ heb ik zowel ITV en VPN aan de praat gekregen. Dank!

[Thepierce86]

Statusvraagje @xbeam, heb je toevallig inzichtelijk wanneer we de VPN via de controller kunnen instellen?

[xbeam]

Thepierce86 schreef op dinsdag 23 juli 2019 @ 14:42:
Statusvraagje @xbeam, heb je toevallig inzichtelijk wanneer we de VPN via de controller kunnen instellen?

Volgens mij kan dat al met 4.4.41.

Zo niet dan fixed deze regel je niet werkende vpn instellingen.

code:

set vpn ipsec ipsec-interfaces interface pppoe2
delete vpn l2tp remote-access dhcp-interface eth0
set vpn l2tp remote-access outside-address 0.0.0.0

[Thepierce86]

xbeam schreef op dinsdag 23 juli 2019 @ 16:10:
[...]


Volgens mij kan dat al met 4.4.41.

Zo niet dan fixed deze regel je niet werkende vpn instellingen.

code:

set vpn ipsec ipsec-interfaces interface pppoe2
delete vpn l2tp remote-access dhcp-interface eth0
set vpn l2tp remote-access outside-address 0.0.0.0

Ik heb die regels inderdaad op die manier via ssh werkend, echter bij elke reboot en provisioning moet die weer opnieuw. Zodra ik hem via de controller toevoeg dan werkt hij niet zoals bij de bekende klachten. Dacht dat dat nog steeds een bug was.

[johnbetonschaar]

Weet iemand of er iets veranderd is bij KPN waardoor mijn USG + IPTV over KPN glas na maanden probleemloos werken ineens geen beeld meer geeft?

Mijn setup is NTU => USG => LAN, waarbij ik de config van basmeerman gebruik, met de aanpassing van @xbeam om source-validation niet te hoeven disablen. Dit werkte dus tot gisteren prima, echter na een paar power cycles van de USG achter elkaar omdat ik aan de electra aan het klussen was, krijgen de IPTV decoders nu alleen nog maar zwart beeld. Geen foutmelding, geen popup met 'zap naar andere zender', de EPG wordt gewoon geladen en ik zie zelfs de tijdbalkjes van het programma dat op staat vooruit lopen, maar het beeld blijft helemaal zwart. Zeer frappant detail is dat van de 1001 zenders in het pakket, er precies twee zijn die *wel* werken: Studio 040 en kabelkrant Veldhoven (de lokale zenders hier dus). Beeld en geluid op die zenders is volkomen normaal. Dit suggereert een of ander authenticatie/decryptie probleem, maar ik heb geen idee hoe/wat/waarom. Iemand een idee?

Het gedrag is hetzelfde op 2 decoders op verschillende plekken in huis. Hang ik de ExperiaBox er tussen in plaats van de USG dan werkt alles weer.

Al gecheckt:

- eth0.4 heeft een IP
- eth0.6 heeft een IP, internet werkt normaal
- route naar IPTV netwerk matched met die in config.gateway.json
- igmp proxy draait
- voor zover ik in de controller kan zien geen events over kapott config files of wat dan ook

Ik trek me de haren er van uit het hoofd, elke keer weer iets anders met die IPTV, ik begin er serieus aan te denken om maar weer terug naar Ziggo te gaan op deze manier

[Tylen]

Telnet naar je usg en type: restart igmp-proxy

[johnbetonschaar]

Tylen schreef op zaterdag 27 juli 2019 @ 19:26:
Telnet naar je usg en type: restart igmp-proxy

Maakt helaas geen verschil...

Er komt wel iets door de USG en terug bij de decoders, gezien het feit dat die twee lokale zenders dus wel prima werken. Zou het kunnen zijn dat KPN door een configuratie verschil gewoon alle zenders blokkeert of geen/verkeerde decryptiesleutels aan de decoders uitgeeft, maar de lokale zenders ongecodeerd doorstuurt voor in geval van rampen of wat dan ook?

[QempZoR]

johnbetonschaar schreef op zaterdag 27 juli 2019 @ 20:10:
[...]


Maakt helaas geen verschil...

Er komt wel iets door de USG en terug bij de decoders, gezien het feit dat die twee lokale zenders dus wel prima werken. Zou het kunnen zijn dat KPN door een configuratie verschil gewoon alle zenders blokkeert of geen/verkeerde decryptiesleutels aan de decoders uitgeeft, maar de lokale zenders ongecodeerd doorstuurt voor in geval van rampen of wat dan ook?

Niet toevallig ook IPcams aangesloten? Bepaalde type IPcams zorgde bij mij voor veel frustratie. (Zie een paar posts hierboven.

[johnbetonschaar]

QempZoR schreef op zaterdag 27 juli 2019 @ 20:41:
[...]


Niet toevallig ook IPcams aangesloten? Bepaalde type IPcams zorgde bij mij voor veel frustratie. (Zie een paar posts hierboven.

Nope, geen IPCams, enige wat ik heb aangesloten tussen dat het wel en niet werkte is twee powerline ethernet adapters... ik zal ze er morgen eens proberen uit te trekken, maar het lijkt me sterk dat die er iets mee te maken hebben. Het is wel kapot gegaan toen ik die aangesloten heb maar dat is waarschijnlijk alleen maar omdat ik daar de stroom een paar keer voor heb afgezet om een nieuw stopcontact te maken...

Edit: helaas, dat is het ook niet, ook zonder de powerline adapters alleen zwart beeld behalve op de twee lokale zenders. Ik ben door mij ideeen heen, geen idee wat ik nog kan proberen. Waarom is dat hele IPTV systeem toch zo’n idiote black box die bij elk zuchtje wind begint te haperen...

[ Voor 32% gewijzigd door johnbetonschaar op 28-07-2019 11:27 ]

[Frankie20]

johnbetonschaar schreef op zaterdag 27 juli 2019 @ 21:24:
[...]


Nope, geen IPCams, enige wat ik heb aangesloten tussen dat het wel en niet werkte is twee powerline ethernet adapters... ik zal ze er morgen eens proberen uit te trekken, maar het lijkt me sterk dat die er iets mee te maken hebben. Het is wel kapot gegaan toen ik die aangesloten heb maar dat is waarschijnlijk alleen maar omdat ik daar de stroom een paar keer voor heb afgezet om een nieuw stopcontact te maken...

Edit: helaas, dat is het ook niet, ook zonder de powerline adapters alleen zwart beeld behalve op de twee lokale zenders. Ik ben door mij ideeen heen, geen idee wat ik nog kan proberen. Waarom is dat hele IPTV systeem toch zo’n idiote black box die bij elk zuchtje wind begint te haperen...

Ik heb in mijn USG een Auto update IPTV route automatically script draaien. Weet niet of dat nog van toepassing is, maar zo draai ik al enkele maanden probleemloos iptv.

[johnbetonschaar]

Frankie20 schreef op dinsdag 30 juli 2019 @ 10:02:
[...]


Ik heb in mijn USG een Auto update IPTV route automatically script draaien. Weet niet of dat nog van toepassing is, maar zo draai ik al enkele maanden probleemloos iptv.

Yep dat script gebruik ik ook. De route is ok, en alles heeft ook maandenlang probleemloos gewerkt, pas na de power cycle werkt het niet meer. Omdat er dus 2 zenders wel prima werken lijkt mij dat de decoders wel verbindingen hebben met het IPTV netwerk, maar op de een of andere manier het signaal niet kunnen decoderen.

Een ander data punt dat wellicht interessant is, is dat ik op het gegeven moment alles weer aangesloten en geherstart heb met de ExperiaBox, en toen zonder reboot de ExperiaBox geswapt heb met de USG (gewoon omgeplugd dus). Toen werkte IPTV weer voor 20 minuten, daarna weer bevroren beeld, en na herstart weer alleen zwart.

Misschien heeft iemand een idee waar ik verder zou moeten kijken, bijvoorbeeld rejected connections en dropped packets van de firewall ofzo? Het moet toch op de een of andere manier te debuggen zijn. En een ander vraagje: waar kan ik ergens fatsoenlijke documentatie van de hele USG userland vinden? Dus allle commandos en configuratie settings etc? Ik vind wel van alles over de EdgeRouter, maar veel commando's werken niet of zijn net anders voor USG lijkt het.

[ik222]

De STB's kunnen dus de decryptiesleutels niet ophalen via de USG. Mogelijke oorzaken daarvan zijn te strak geconfigureerde firewall regels, een onjuiste route of een te strak geconfigureerde igmpproxy. Ik heb zelf geen Ubiquiti apparatuur (gebruik zelf pfSense) maar ik neem aan dat je op dat ding ook de logs van igmpproxy en de firewall kan uitlezen? Wellicht vindt je daarin een aanwijzing?

[johnbetonschaar]

ik222 schreef op dinsdag 30 juli 2019 @ 10:33:
De STB's kunnen dus de decryptiesleutels niet ophalen via de USG. Mogelijke oorzaken daarvan zijn te strak geconfigureerde firewall regels, een onjuiste route of een te strak geconfigureerde igmpproxy. Ik heb zelf geen Ubiquiti apparatuur (gebruik zelf pfSense) maar ik neem aan dat je op dat ding ook de logs van igmpproxy en de firewall kan uitlezen? Wellicht vindt je daarin een aanwijzing?

Dat is inderdaad wat ik wilde doen, in /var/log kon ik het echter nergens terugvinden, en ook niet in de Unifi Controller web interface. Maar het moet er zijn inderdaad... Ik ga er van het weekend nog een keer induiken als het frustratie niveau weer voldoende gedaald is . Maar alle tips zijn welkom.

[nero355]

ik222 schreef op dinsdag 30 juli 2019 @ 10:33:
Ik heb zelf geen Ubiquiti apparatuur (gebruik zelf pfSense) maar ik neem aan dat je op dat ding ook de logs van igmpproxy en de firewall kan uitlezen? Wellicht vindt je daarin een aanwijzing?

Kijk uit met dat soort aannames wat betreft de USG : Er zijn heeel veel dingen die een pfSense machine wel kan en de USG absoluut niet!

[johnbetonschaar]

@ik222
Firewall logging stond uit vandaar dat er niks te zien was in /var/log/messages, ik heb de logging aangezet maar ik zie hoegenaamd niks waar ik iets mee kan. De igmpproxy logt eigenlijk helemaal niks, behalve dat ie gestopt/gestart is. Als botte bijl methode heb ik ook eens geprobeerd domweg een 'allow all' regel aan de WAN_LOCAL toe te voegen, maar ook dat mocht niet baten.

Wat ik verdacht vindt is dat de multicast statistieken er vreemd uitzien:

code:

show ip multicast mfc
Group           Origin           In          Out                Pkts         Bytes  Wrong
239.254.127.63  192.168.2.1      eth0.4      eth1                  3        96.00b      0
239.254.127.63  192.168.2.17     eth0.4      eth1                  4       380.00b      4
239.254.127.63  192.168.2.16     eth0.4      eth1                 21        2.30KB     21
239.255.255.250 192.168.2.18     eth0.4      eth1                144       47.23KB    144
239.255.255.250 192.168.2.11     eth0.4      eth1                600      199.80KB    600
239.255.255.250 192.168.2.22     eth0.4      eth1                528      153.48KB    528
239.254.127.63  192.168.2.34     eth0.4      eth1                 22        1.67KB     22
239.255.255.250 192.168.2.14     eth0.4      eth1                624      207.80KB    624
239.254.127.63  192.168.2.10     eth0.4      eth1                 11       352.00b     11
239.255.255.250 192.168.2.25     eth0.4      eth1               2276     1004.59KB   2276
239.254.127.63  192.168.2.27     eth0.4      eth1                 12       552.00b     12

Veel getalletjes in de 'wrong' kolom (wat dat ook mag betekenen), maar als ik het goed begrijp zouden er in de 'origin' kolom ook IP adressen van het KPN IPTV netwerk moeten verschijnen.

code:

show ip multicast interfaces
Intf             BytesIn        PktsIn      BytesOut       PktsOut            Local
eth1               0.00b             0         0.00b             0      192.168.2.1
eth0.4             0.00b             0         0.00b             0    10.215.135.36

Hier apart dat alle counters op 0 staan, zelfs terwijl de Kabelkrant Veldhoven al 2 uur op staat

Ik kom er niet meer uit denk ik, iets klopt niet maar ik heb geen idee waar ik moet zoeken om er achter te komen wat...

[ik222]

Die lokale kabelkrant is unicast waarschijnlijk, dus dat die wel werkt betekent niet dat multicast werkt.

Post eens je exacte IGMPProxy configuratie? En sta je ook genoeg toe vanaf de IPTV WAN interface in de firewall?

[johnbetonschaar]

ik222 schreef op woensdag 31 juli 2019 @ 23:00:
Die lokale kabelkrant is unicast waarschijnlijk, dus dat die wel werkt betekent niet dat multicast werkt.

Post eens je exacte IGMPProxy configuratie? En sta je ook genoeg toe vanaf de IPTV WAN interface in de firewall?

code:

    "protocols": {
        "igmp-proxy": {
            "disable-quickleave": "''",
            "interface": {
                "eth0": {
                    "role": "disabled",
                    "threshold": "1"
                },
                "eth0.4": {
                    "alt-subnet": [
                        "0.0.0.0/0"
                    ],
                    "role": "upstream",
                    "threshold": "1"
                },
                "eth1": {
                    "alt-subnet": [
                        "0.0.0.0/24"
                    ],
                    "role": "downstream",
                    "threshold": "1"
                },
                "pppoe2": {
                    "role": "disabled",
                    "threshold": "1"
                }
            }
        },
        "static": {
                      "interface-route": {
                                "0.0.0.0/0": {
                                        "next-hop-interface": {
                                                "pppoe2": {
                                                        "distance": "1"
                                                }
                                        }
                                }
                        },
            "route": {
                "213.75.112.0/21": {
                    "next-hop": {
                        "10.215.128.1": "''"
                    }
                }
            }
        }
    },

Ik heb ook al eens geprobeerd de 'interface_route' sectie weg te laten, evenals de disabled interfaces (eth0 en pppoe2) en de disable-quickleave optie, omdat ik zag dat deze niet in xbeam zijn configuratie staan. Maar dit maakt geen verschil.

Voor wat betreft de firewall: er zijn geen extra regels voor de IPTV, behalve voor de masquerading:

code:

 "nat": {
            "rule": {
                "5000": {
                    "description": "MASQ corporate_network to IPTV network",
                    "destination": {
                        "address": "213.75.112.0/21"
                    },
                    "outbound-interface": "eth0.4",
                    "protocol": "all",
                    "type": "masquerade"
                },
                "6001": {
                    "outbound-interface": "pppoe2",
                    "protocol": "all",
                    "source": {
                        "group": {
                            "network-group": "corporate_network"
                         }
                    },
                    "type": "masquerade"
                },
                "6002": {
                    "outbound-interface": "pppoe2"
                },
                "6003": {
                    "outbound-interface": "pppoe2"
                }
            }
        }

Zo heeft het altijd gedraaid eigenlijk, maandenlang zonder problemen. Ik ga er van uit dat er geen extra regels nodig zijn omdat alles via de connection tracking werkt (state related), nadat de IPTV decoders naar buiten toe beginnen te praten. Het is heel vaag allemaal omdat ik dus zelf niks veranderd heb ten opzichte van hoe het maandenlang werkte

[ik222]

In je IGMPProxy config klopt sowieso het alt-subnet niet. Dat moet zijn 0.0.0.0/0 en niet /24 als je het invult. Al zou ik verwachten dat dit niet het probleem is, immers IGMPProxy werkt default sowieso ook voor het connected subnet.

Verder wat betreft firewall regels moet in elk geval IGMP inclusief options en UDP toegestaan worden vanaf IPTV WAN naar de IGMPProxy aangezien dat in de basis niet statefull is. Maar ik weet niet hoe dat normaal werkt op de USG, misschien betekent geen regels "allow all" of accepteert hij in elk geval het verkeer naar de IGMPProxy deamon. Op pfSense moet ik ik het in elk geval expliciet configureren.

[ Voor 12% gewijzigd door ik222 op 01-08-2019 07:13 ]

[johnbetonschaar]

ik222 schreef op donderdag 1 augustus 2019 @ 07:11:
In je IGMPProxy config klopt sowieso het alt-subnet niet. Dat moet zijn 0.0.0.0/0 en niet /24 als je het invult. Al zou ik verwachten dat dit niet het probleem is, immers IGMPProxy werkt default sowieso ook voor het connected subnet.

Yep subnet is idd twijfelachtig, dat was me ook al opgevallen. De twee config files die ik als voorbeeld heb gebruikt (basmeerman config en xbeam config) gebruiken inderdaad verschillende subnets, het was mij niet helemaal duidelijk welke correct was. Ik weet bijna zeker dat ik 0.0.0.0/0 ook al in mijn config gehad heb sinds het niet meer werkt, en dat dat geen oplossing was (zoals je ook al vermoedde), maar ik zal het van het weekend nog eens proberen.

Verder wat betreft firewall regels moet in elk geval IGMP inclusief options en UDP toegestaan worden vanaf IPTV WAN naar de IGMPProxy aangezien dat in de basis niet statefull is. Maar ik weet niet hoe dat normaal werkt op de USG, misschien betekent geen regels "allow all" of accepteert hij in elk geval het verkeer naar de IGMPProxy deamon. Op pfSense moet ik ik het in elk geval expliciet configureren.

Dit klinkt heel logisch en ik heb sterk het vermoeden dat er zoiets aan de hand is (de firewall iets blokt dus). Voorheen werkte alles met de standaard firewall settings, en hoefde je niks speciaals te doen om beeld te krijgen. Maar de firewall configuratie wordt vanaf de controller gepushed, dus het zou kunnen dat die na een update stricter is geworden, zo ging het met die source-validation ook (stond ooit standaard uit, na een update van de controller en/of USG firmware was het ineens nodig om hem via de config.gateway.json te disablen of als 'loose' in te stellen voor het IPTV vlan). Source validation is nu overigens niet het probleem want disablen helpt ook niks.

Misschien is er iemand die KPN IPTV over glas momenteel nog steeds heeft werken via de USG, die kan bevestigen of ontkrachten dat je specifieke firewall regels nodig hebt die niet in bijvoorbeeld de xbeam config staan? En dan ook na een reboot en met de laatste controller en USG firmware versie dus

[karlkani1985]

Hallo allemaal,

Ik heb de USG lite geconfigureerd zoals hier staat beschreven: https://www.free2wifi.nl/2018/09/25/ubnt-usg-iptv/

Alles werkt. Alleen de tv gaat happeren en dan stilstaan. Dan moet ik zappen en binnen enkele seconden loopt hij weer "vast"

Wie van jullie weet wat ik nog moet doen. Het ip-adres blijft via deze command "show dhcp client leases interface eth0.4" is nog steeds niet veranderd.

Mijn setup is als volgt:

FTU
USG
(simpele switch ) TV-decoder, PS4, TV, Apple TV

Ik heb de TV ook direct aan de USG gehangen maar het probleem blijft zich voordoen.

Hoop dat iemand mij kan helpen.

[ Voor 16% gewijzigd door karlkani1985 op 06-08-2019 07:23 ]

[Thepierce86]

*knip

Probeer je igmp proxy eens te herstarten? dat heeft het destijds bij mij opgelost.

[karlkani1985]

Vreemd... Heb alles opnieuw aangesloten. Switch van power gehaald en nu blijft het "werken"

Helaas tijdens het zappen kwam ik er achter dat andere zenders op zwart bleven. Na deze command restart igmp-proxy kwam alles terug. Wie weet hoe ik dat probleem kan oplossen?


Nog een ander puntje. wie van jullie heeft de tvroute.sh draaien van https://kriegsman.io/
En hoe hebben jullie deze draaiend? Ik zie verschillende mogelijkheden

in de Json file
en
Hernoem het bestand naar tvroute.sh (verwijder .txt extentie) en upload het script naar de USG
Maak het script uitvoerbaar: chmod +x tvroute.sh
Verplaats naar de juiste folder: mv tvroute.sh /config/scripts/post.config.d/tvroute.sh
Test het script: /config/scripts/post.config.d/tvroute.sh
Stel een cronjob in zodat het script automatisch gestart wordt:


Ik ben op dit gebied niet bekend en hoop dat er iemand is die mij op weg kan helpen

[ Voor 21% gewijzigd door karlkani1985 op 06-08-2019 17:19 ]

[karlkani1985]

Ik heb de IMGP snooping op de controller aan gezet en nu lijkt de TV te blijven werken.

To be continu

[Dutchess_Nicole]

Heeft iemand toevallig ook ervaring met VLAN settings (en evt andere eigenaardigheden) van Online.nl?

Nu Fiber.nl overgenomen is door online.nl (wiens site offline was... typisch) weet ik vrijwel zeker dat ze gaan lopen morrelen met network settings.

Ze gaan me uiteraard een nieuwe router toesturen die linea recta retour gaat. Hooguit trek ik de config er eerst even uit maar dat was het dan ook wel.

Maar als ik voorbereid kan zijn en niet door 1e lijns scripts heen hoef is dat alleen maar voordeliger.

[harrytasker]

Vandaag update gedaan naar: 5.10.26-11685-1 met als gevolg dat mijn IPTV niet meer werkt. Heb al een igmp proxy restart gedaan, maar leverde niets op. Beide kastjes geven nu een 561 error, dat ze de instellingen niet kunnen ophalen. Enig idee wat er gewijzigd is na de update en hoe te herstellen?

[Frankie20]

harrytasker schreef op zaterdag 17 augustus 2019 @ 16:11:
Vandaag update gedaan naar: 5.10.26-11685-1 met als gevolg dat mijn IPTV niet meer werkt. Heb al een igmp proxy restart gedaan, maar leverde niets op. Beide kastjes geven nu een 561 error, dat ze de instellingen niet kunnen ophalen. Enig idee wat er gewijzigd is na de update en hoe te herstellen?

Ik heb versie 5.10.26-11685-1 draaien met KPN en het werkt zonder problemen.. echter zag ik zojuist dat er een Cloud Key Firmware update klaar staat v1.0.11. Heb jij deze ook geïnstalleerd?

[harrytasker]

Frankie20 schreef op zaterdag 17 augustus 2019 @ 22:09:
[...]


Ik heb versie 5.10.26-11685-1 draaien met KPN en het werkt zonder problemen.. echter zag ik zojuist dat er een Cloud Key Firmware update klaar staat v1.0.11. Heb jij deze ook geïnstalleerd?

Ja, alles op de laatste versie. Na opnieuw een reboot van de UGS werkt het weer.

[mathias82]

Weet er iemand toevallig de instellingen voor Proximus TV (België)? Ik veronderstel dat al de informatie (zoals DHCP opties, statische routes enz) door de provider zelf moeten bekend gemaakt worden, dit is niet iets dat je zelf kan sniffen vermits dit op de WAN kant gebeurt?

Het enige dat ik weet van Proximus is dat ze VLAN10 gebruiken voor internet en VLAN30 voor IPTV...

[nero355]

[quote]mathias82 schreef op zondag 18 augustus 2019 @ 18:20:
Weet er iemand toevallig de instellingen voor Proximus TV (België)? Ik veronderstel dat al de informatie (zoals DHCP opties, statische routes enz) door de provider zelf moeten bekend gemaakt worden, dit is niet iets dat je zelf kan sniffen vermits dit op de WAN kant gebeurt?

Het enige dat ik weet van Proximus is dat ze VLAN10 gebruiken voor internet en VLAN30 voor IPTV...[/quote]
Tja, de vraag is eigenlijk : Kan je de WAN kant aansluiten op een Switch die poorten kan Mirroren

Dan kan je namelijk de poort die wordt gespiegeld gewoon sniffen, terwijl je apparatuur niks ervan merkt!

/EDIT :

mathias82 schreef op maandag 19 augustus 2019 @ 20:04:
Ik denk het niet. Bij Proximus wordt de telefoonlijn rechtstreeks op de modem/router aangesloten. Zal een beetje moeilijk worden om de telefoonlijn te sniffen

Het was dan ook een vraag...

* nero355 heeft geen ervaring met Belgische ISP's

[ Voor 22% gewijzigd door nero355 op 20-08-2019 15:50 ]

[SpeedfreakR]

Ik heb wat hulp nodig met een scriptje om vpn werkend te krijgen. Ik wil niet meer iedere keer de commando's op de command line invoeren dus wil ik ze in een script zetten zodat ik alleen het script hoef aan te roepen. En het liefste zelfs als cronjob draaien elke ochtend ofzo.

Commando's die in het script moeten komen.

configure
set vpn ipsec ipsec-interfaces interface pppoe2
delete vpn l2tp remote-access dhcp-interface eth0
set vpn l2tp remote-access outside-address 0.0.0.0
commit
save

Hebbben jullie deze commando's ook in een script staan?
Ik heb verschillende dingen geprobeerd: vbash, vyatta-cfg-cmd-wrapper, en nog wat gegoogelde dingen maar wil niet te veel prutsen in een werkende omgeving


Ik was weer eens te snel met vragen.. Het is al gelukt

#!/bin/vbash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper begin
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set vpn ipsec ipsec-interfaces interface pppoe2
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper delete vpn l2tp remote-access dhcp-interface eth0
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set vpn l2tp remote-access outside-address 0.0.0.0
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper commit
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper save
exit

Dit script lijkt te werken

[ Voor 29% gewijzigd door SpeedfreakR op 19-08-2019 19:20 ]

[mathias82]

nero355 schreef op maandag 19 augustus 2019 @ 17:45:
[...]

Tja, de vraag is eigenlijk : Kan je de WAN kant aansluiten op een Switch die poorten kan Mirroren

Dan kan je namelijk de poort die wordt gespiegeld gewoon sniffen, terwijl je apparatuur niks ervan merkt!

Ik denk het niet. Bij Proximus wordt de telefoonlijn rechtstreeks op de modem/router aangesloten. Zal een beetje moeilijk worden om de telefoonlijn te sniffen

[SpeedfreakR]

Even een vervolg op mn vorige post. Misschien hebben mensen hier wat aan.
Ik heb dus een scriptje gemaakt wat de vpn fix doet wat nodig is icm iptv.

code:

#!/bin/vbash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper begin
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set vpn ipsec ipsec-interfaces interface pppoe2
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper delete vpn l2tp remote-access dhcp-interface eth0
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set vpn l2tp remote-access outside-address 0.0.0.0
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper commit
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper save
exit

Deze code is geplaatst in /config/scripts/vpn-fix.sh en vervolgens executable gemaakt. (chmod +x)

Nu wil ik dat dit scriptje runt elke keer als ik een reboot of een provision doe. Ik heb hiervoor het volgende aan mijn "config.gateway.json" toegevoegd (controleer goed de brackets!):

code:

{
    "system": {
        "task-scheduler": {
            "task": {
                "runonprovision": {
                    "executable": {
                        "path": "/config/scripts/vpn-fix.sh"                        
                    },
                    "interval": "2m"
                }
            }
        }
    }
}

Nu zal na elke reboot (nog niet getest) en na elke provision (wel getest) automatisch de vpn fix ook doorgevoerd worden.

[Jeroen_ae92]

SpeedfreakR schreef op maandag 19 augustus 2019 @ 20:28:
Even een vervolg op mn vorige post. Misschien hebben mensen hier wat aan.
Ik heb dus een scriptje gemaakt wat de vpn fix doet wat nodig is icm iptv.

code:

#!/bin/vbash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper begin
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set vpn ipsec ipsec-interfaces interface pppoe2
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper delete vpn l2tp remote-access dhcp-interface eth0
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set vpn l2tp remote-access outside-address 0.0.0.0
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper commit
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper save
exit

Deze code is geplaatst in /config/scripts/vpn-fix.sh en vervolgens executable gemaakt. (chmod +x)

Nu wil ik dat dit scriptje runt elke keer als ik een reboot of een provision doe. Ik heb hiervoor het volgende aan mijn "config.gateway.json" toegevoegd (controleer goed de brackets!):

code:

{
    "system": {
        "task-scheduler": {
            "task": {
                "runonprovision": {
                    "executable": {
                        "path": "/config/scripts/vpn-fix.sh"                        
                    },
                    "interval": "2m"
                }
            }
        }
    }
}

Nu zal na elke reboot (nog niet getest) en na elke provision (wel getest) automatisch de vpn fix ook doorgevoerd worden.

Zet em dan in de folder /config/scripts/post-config.d/ en pas de scheduled task aan met het nieuwe pad. Elk script in die folder wordt gerund bij booten. Moet uiteraard wel executable zijn. Volgens mij ben je dan rond.

[SpeedfreakR]

Jeroen_ae92 schreef op maandag 19 augustus 2019 @ 20:49:
[...]

Zet em dan in de folder /config/scripts/post-config.d/ en pas de scheduled task aan met het nieuwe pad. Elk script in die folder wordt gerund bij booten. Moet uiteraard wel executable zijn. Volgens mij ben je dan rond.

Volgens mij werkt dat niet. Na de boot wordt alsnog een provision gedaan. En daarmee worden de instellingen weer overschreven. Ook bij een update van de UniFi controller wordt een provison gedaan en niet de router gereboot. Dus ook dan worden de instellingen overschreven. Door het script na een provision te runnen zit je altijd goed.

[Jeroen_ae92]

SpeedfreakR schreef op maandag 19 augustus 2019 @ 21:08:
[...]


Volgens mij werkt dat niet. Na de boot wordt alsnog een provision gedaan. En daarmee worden de instellingen weer overschreven. Ook bij een update van de UniFi controller wordt een provison gedaan en niet de router gereboot. Dus ook dan worden de instellingen overschreven. Door het script na een provision te runnen zit je altijd goed.

Na een boot of reboot wordt de bestaande config geladen. Pas als er een connectie is met de controller wordt er een een provision gedaan indien nodig (lees wispelturig karakter). Dus als je je script in de startup folder post-config.d plaatst, runt ie altijd bij een boot/reboot. Als je dan je scheduled task aanpast naar het nieuwe pad, dan loopt dat script ook elke 2 minuten. Ik zeg niet dat je je scheduled task moet weghalen

Even een klein stukje ervaring in deze... Bouw een check in in het script. Dus enkel uitvoeren indien nodig en anders niet. Al die writes met een commit;save gaat ten kostte van de levensduur van de USG. Er zit immers een USB stick in waar het OS op staat. En die heeft geen eeuwig leven

[SpeedfreakR]

Jeroen_ae92 schreef op maandag 19 augustus 2019 @ 21:14:
[...]

Na een boot of reboot wordt de bestaande config geladen. Pas als er een connectie is met de controller wordt er een een provision gedaan indien nodig (lees wispelturig karakter). Dus als je je script in de startup folder post-config.d plaatst, runt ie altijd bij een boot/reboot. Als je dan je scheduled task aanpast naar het nieuwe pad, dan loopt dat script ook elke 2 minuten. Ik zeg niet dat je je scheduled task moet weghalen

Even een klein stukje ervaring in deze... Bouw een check in in het script. Dus enkel uitvoeren indien nodig en anders niet. Al die writes met een commit;save gaat ten kostte van de levensduur van de USG. Er zit immers een USB stick in waar het OS op staat. En die heeft geen eeuwig leven

Ik heb er nu dit van gemaakt.

code:

#!/bin/vbash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
/opt/vyatta/sbin/vyatta-cfg-cmd-wrapper begin

if ! /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper show | grep outside-address > /dev/null; then 
  /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set vpn ipsec ipsec-interfaces interface pppoe2
  /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper delete vpn l2tp remote-access dhcp-interface eth0
  /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set vpn l2tp remote-access outside-address 0.0.0.0
  /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper commit                                             
  /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper save   
fi                                             
exit

[Old-Tweaker]

Hoi Allen,

Dankzij jullie en de informatie van xbeam en freewifi heb ik alles tot in de puntjes kunnen voorbereiden.
Vandaag was de grote dag en de KPN modem vervangen door de USG3P en alles werkt

Maar zit gelijk met zorgen. Want de stap die ik niet gedaan heb is de Next Hop instellingen.
Dus huidige IP opgezocht een aangepast in de config.json. En dus ook niet het scriot voor het automatisch instellen bij een reboot. Heb daarna alles updates gedraaid en moest daardoor ook rebooten en de TV werkt nog steeds. Alle apps van ITV werken ook nog.

Klopt dit? Of kan ik in de toekomst nog problemen verwachten? Want wat ik niet wil is dat wederhelft geen TV kan kijken.

Hoor graag van jullie

[Tylen]

Old-Tweaker schreef op woensdag 21 augustus 2019 @ 13:49:
Hoi Allen,

Dankzij jullie en de informatie van xbeam en freewifi heb ik alles tot in de puntjes kunnen voorbereiden.
Vandaag was de grote dag en de KPN modem vervangen door de USG3P en alles werkt

Maar zit gelijk met zorgen. Want de stap die ik niet gedaan heb is de Next Hop instellingen.
Dus huidige IP opgezocht een aangepast in de config.json. En dus ook niet het scriot voor het automatisch instellen bij een reboot. Heb daarna alles updates gedraaid en moest daardoor ook rebooten en de TV werkt nog steeds. Alle apps van ITV werken ook nog.

Klopt dit? Of kan ik in de toekomst nog problemen verwachten? Want wat ik niet wil is dat wederhelft geen TV kan kijken.

Hoor graag van jullie

Dus niet alles in de punjtes vootbereid

Maar je gaat zeker igmp-proxy problemen krijgen in de toekomst. Last van schokkend beeld met dan de melding dat je van kanaal moet zappen etc Etc. En ja dat gebeurd altijd als jij niet thuis bent en de wederhelft tv wilt kijken. Been there, done that.

[Old-Tweaker]

Tylen schreef op woensdag 21 augustus 2019 @ 14:20:
[...]


Dus niet alles in de punjtes vootbereid

Maar je gaat zeker igmp-proxy problemen krijgen in de toekomst. Last van schokkend beeld met dan de melding dat je van kanaal moet zappen etc Etc. En ja dat gebeurd altijd als jij niet thuis bent en de wederhelft tv wilt kijken. Been there, done that.

Ok, dus wat ik je hoor zeggen is dat ik die laatste stappen dus wel moet uitvoeren?
Dus IP opzoeken en aanpassen in config.json en dat het script toevoegen en zorgen dat er een taak loopt die het automatisch aanpast?

[ Voor 0% gewijzigd door Old-Tweaker op 21-08-2019 15:15 . Reden: typo ]

[Thysiej]

Old-Tweaker schreef op woensdag 21 augustus 2019 @ 15:15:
[...]


Ok, dus wat ik je hoor zeggen is dat ik die laatste stappen dus wel moet uitvoeren?
Dus IP opzoeken en aanpassen in config.json en dat het script toevoegen en zorgen dat er een taak loopt die het automatisch aanpast?

Ik heb het toevallig twee weken geleden gedaan, de Experia Box vervangen door een USG 4 Pro. In eerste instantie ook de next-hop niet gedaan en alles leek te werken. Tot een dag later, bepaalde zenders werkte niet meer zonder zappen etc. etc.

Vervolgens de next-hop netjes ingesteld en het script toegevoegd en het werkt weer als een zonnetje.

Dus ja, je moet die stappen uitvoeren

[Old-Tweaker]

Thysiej schreef op woensdag 21 augustus 2019 @ 15:20:
[...]


Ik heb het toevallig twee weken geleden gedaan, de Experia Box vervangen door een USG 4 Pro. In eerste instantie ook de next-hop niet gedaan en alles leek te werken. Tot een dag later, bepaalde zenders werkte niet meer zonder zappen etc. etc.

Vervolgens de next-hop netjes ingesteld en het script toegevoegd en het werkt weer als een zonnetje.

Dus ja, je moet die stappen uitvoeren

Ok even de stappen voor de zekerheid. Klopt dit zo? Want dan ga ik dat vandaag nog even doen

Stap 1:
Kopieer en plak dit commando in je ssh terminal
show dhcp client leases interface eth0.4

Stap 2:
output
interface : eth0.4
ip address : 10.164.xx.xx [Active]
subnet mask: 255.255.224.0
router : 10.164.xx.x (iptv Router ip)
dhcp server: 10.164.xx.xx
lease time : 82174
last update: Thu Sep 27 07:41:35 CEST 2018
expiry : Fri Sep 28 06:31:08 CEST 2018
reason : RENEW

Stap 3:
Router IP. Toevoegen aan config.json en uploaden.

Stap 4:
Auto update IPTV route automatically
The routed IP network sometimes changes, therefore the next-hop settings for routing should periodically change

Pull the update_iptv_route.sh from the repo
SFTP into the USG
Push the update script: push update_iptv_route.sh
SSH into the USG
Move the file: mv update_iptv_route.sh /config/scripts/post-config.d/
Make the file executable chmod +x /config/scripts/post-config.d/update_iptv_route.sh
Execute the script ./update_iptv_route.sh

Of moet ik voor de laatst stap iets anders gebruiken?
Ik zie namelijk ook iets anders voor bij komen van xbream

[Ethirty]

Tylen schreef op woensdag 21 augustus 2019 @ 14:20:
[...]


Dus niet alles in de punjtes vootbereid

Maar je gaat zeker igmp-proxy problemen krijgen in de toekomst. Last van schokkend beeld met dan de melding dat je van kanaal moet zappen etc Etc. En ja dat gebeurd altijd als jij niet thuis bent en de wederhelft tv wilt kijken. Been there, done that.

Hmm, klinkt wel als het probleem dat die kennis van mij nog heeft nadat ik zijn wifi recent gefixed heb. TV doet af en toe gek.

Alleen gebruikt hij als router gewoon de Experiabox en zit de TV als het goed is niet op het LAN. Althans, hij heeft alleen 3 AP's (waarvan maar 1 bedraad) en verder geen switches.

Nog suggesties toevallig die ik hem kan laten proberen?

[Alsjemenou]

Old-Tweaker schreef op woensdag 21 augustus 2019 @ 15:44:
[...]


Ok even de stappen voor de zekerheid. Klopt dit zo? Want dan ga ik dat vandaag nog even doen

Yes, gaat goed komen! Vergeet niet opnieuw te force-provisionen na het aanpassen van het JSON bestand.

[ Voor 13% gewijzigd door Alsjemenou op 21-08-2019 16:20 ]

[Old-Tweaker]

Alsjemenou schreef op woensdag 21 augustus 2019 @ 16:20:
[...]


Yes, gaat goed komen! Vergeet niet opnieuw te force-provisionen na het aanpassen van het JSON bestand.

Nou alle stappen uitgevoerd.
Dus komende dagen in de gaten houden.

[Tylen]

Ethirty schreef op woensdag 21 augustus 2019 @ 16:15:
[...]

Hmm, klinkt wel als het probleem dat die kennis van mij nog heeft nadat ik zijn wifi recent gefixed heb. TV doet af en toe gek.

Alleen gebruikt hij als router gewoon de Experiabox en zit de TV als het goed is niet op het LAN. Althans, hij heeft alleen 3 AP's (waarvan maar 1 bedraad) en verder geen switches.

Nog suggesties toevallig die ik hem kan laten proberen?

Hoe zijn de tv kastjes aangesloten dan?

Bij ubiquiti routers is het een kwestie van restart igmp-proxy in een terminal sessie.

[Ethirty]

Tylen schreef op woensdag 21 augustus 2019 @ 16:55:
[...]


Hoe zijn de tv kastjes aangesloten dan?

Bij ubiquiti routers is het een kwestie van restart igmp-proxy in een terminal sessie.

Goede vraag. Ik gok op de Experiabox. Maar ik zou dan eerder verwachten dat de wifi onderuit gaat, dan de tv kastjes.

[Old-Tweaker]

Tylen schreef op woensdag 21 augustus 2019 @ 16:55:
[...]


Hoe zijn de tv kastjes aangesloten dan?

Bij ubiquiti routers is het een kwestie van restart igmp-proxy in een terminal sessie.

Nu heb ik alles uitgevoerd maar daarna krijg ik opeens hangend beeld na het zappen.

Na restart igmp-proxy werkt het weer prima.

Moet ik een reboot doen nadat ik alle stappen van het script heb uitgevoerd?

De vraag is dus ben ik iets vergeten?

[Tylen]

Old-Tweaker schreef op woensdag 21 augustus 2019 @ 17:27:
[...]


Nu heb ik alles uitgevoerd maar daarna krijg ik opeens hangend beeld na het zappen.

Na restart igmp-proxy werkt het weer prima.

Moet ik een reboot doen nadat ik alle stappen van het script heb uitgevoerd?

De vraag is dus ben ik iets vergeten?

Restart igno-proxy ook in script zetten

[Old-Tweaker]

Tylen schreef op woensdag 21 augustus 2019 @ 17:40:
[...]


Restart igno-proxy ook in script zetten

Ik heb nu deze gebruikt

#!/bin/vbash

source /opt/vyatta/etc/functions/script-template

r_ip=$(run show dhcp client leases | grep router | awk '{ print $3 }');
iptv_static=$(echo "set protocols static route 213.75.112.0/21 next-hop $r_ip")

configure
delete protocols static route 213.75.112.0/21
eval $iptv_static
commit
save
exit

Moet ik dan deze gebruken?

sudo vbash -c 'cat > /config/scripts/tvroute.sh' << EOF
#!/bin/vbash

# configured static route target
CUR_IP=\$(cat /config/config.boot | grep 213.75.112.0/21 -A1 | grep next-hop | awk '{ print \$2}');

# static route target
NEW_IP=\$(cat /var/run/dhclient_eth0.4_lease | grep new_routers | awk -F= '{print \$2}' | tr -d \');

if [ "\$CUR_IP" = "\$NEW_IP" ]; then
echo Addresses the same
exit 1;
fi

source /opt/vyatta/etc/functions/script-template

configure
delete protocols static route 213.75.112.0/21 next-hop \$CUR_IP
set protocols static route 213.75.112.0/21 next-hop \$NEW_IP
commit
save
exit

restart igmp-proxy
EOF

[Tylen]

Precies. Al zal ik er nog even een sleep van een paar seconden inbouwen vlak voor de restart. Werkte bij mij beter.

[Old-Tweaker]

Tylen schreef op woensdag 21 augustus 2019 @ 17:54:
Precies. Al zal ik er nog even een sleep van een paar seconden inbouwen vlak voor de restart. Werkte bij mij beter.

Door dit er voor te zetten?

sleep 5

En moet ik deze ook nog uitvoeren voor automatisch check om de 5 min?

Add the script to the task scheduler to automatically check/update the static route

1. configure
2. set system task-scheduler task updateIPTVroute executable path /config/scripts/tvroute.sh
3. set system task-scheduler task updateIPTVroute interval 5m
4. commit
5. save
6. exit

[Tylen]

Old-Tweaker schreef op woensdag 21 augustus 2019 @ 18:19:
[...]


Door dit er voor te zetten?

sleep 5

En moet ik deze ook nog uitvoeren voor automatisch check om de 5 min?

Add the script to the task scheduler to automatically check/update the static route

1. configure
2. set system task-scheduler task updateIPTVroute executable path /config/scripts/tvroute.sh
3. set system task-scheduler task updateIPTVroute interval 5m
4. commit
5. save
6. exit

Hmm elke 5 minuten zou ik niet doen. Op tijden dat je niet tv kijkt is beter .

[Comp User]

Tylen schreef op woensdag 21 augustus 2019 @ 18:54:
[...]


Hmm elke 5 minuten zou ik niet doen. Op tijden dat je niet tv kijkt is beter .

Of lopende opnames hebt - dan is het ook niet handig.

[Tylen]

Comp User schreef op woensdag 21 augustus 2019 @ 19:34:
[...]


Of lopende opnames hebt - dan is het ook niet handig.

Dat zou niet uit moeten maken. Dat gebeurd in het dc van kpn.

[Old-Tweaker]

Tylen schreef op woensdag 21 augustus 2019 @ 18:54:
[...]


Hmm elke 5 minuten zou ik niet doen. Op tijden dat je niet tv kijkt is beter .

Het meest handige is dan 02:00 in de nacht. Is 1x per dag voldoende?

Dus interval 5 min moet aangepast worden naar: crontab-spec "* 2 * * *"

En wordt dus:

set system task-scheduler task updateIPTVroute crontab-spec "* 2 * * *"

[RobertMe]

Old-Tweaker schreef op woensdag 21 augustus 2019 @ 20:25:
[...]


Het meest handige is dan 02:00 in de nacht. Is 1x per dag voldoende?

Dus interval 5 min moet aangepast worden naar: crontab-spec "* 2 * * *"

En wordt dus:

set system task-scheduler task updateIPTVroute crontab-spec "* 2 * * *"

Een cron job/scheduled task om 02:00 is nooit handig. Als de klok om gaat doe je het dan potentieel niet, of 2x. Tussen 02:00 en 03:00 iets "inplannen" om dagelijks uit te voeren is dus nooit een goed idee als je het net zo goed om 01:00, 01:30, 04:00 of elk ander tijdstip kunt doen.

[Old-Tweaker]

RobertMe schreef op woensdag 21 augustus 2019 @ 22:42:
[...]

Een cron job/scheduled task om 02:00 is nooit handig. Als de klok om gaat doe je het dan potentieel niet, of 2x. Tussen 02:00 en 03:00 iets "inplannen" om dagelijks uit te voeren is dus nooit een goed idee als je het net zo goed om 01:00, 01:30, 04:00 of elk ander tijdstip kunt doen.

Hmm daar had ik inderdaad niet bij stil gestaan. Klinkt logisch inderdaad. Bedankt voor de tip.
Maar de code is wel goed? Dus alleen andere tijd kiezen

[RobertMe]

Old-Tweaker schreef op woensdag 21 augustus 2019 @ 22:47:
[...]


Hmm daar had ik inderdaad niet bij stil gestaan. Klinkt logisch inderdaad. Bedankt voor de tip.
Maar de code is wel goed? Dus alleen andere tijd kiezen

Sorry, ik heb de discussie niet gevolgd (omdat ik geen IPTV heb) en ik durf dus ook niet te zeggen of dat klopt. Qua "cron" an zich lijkt de * 2 * * * in ieder geval te kloppen. Maar of het ook de juiste commando's er omheen zijn om het te laten werken op een USG en/of EdgeRouter weet ik niet.

[xbeam]

Old-Tweaker schreef op woensdag 21 augustus 2019 @ 15:44:
[...]


Ok even de stappen voor de zekerheid. Klopt dit zo? Want dan ga ik dat vandaag nog even doen

Stap 1:
Kopieer en plak dit commando in je ssh terminal
show dhcp client leases interface eth0.4

Stap 2:
output
interface : eth0.4
ip address : 10.164.xx.xx [Active]
subnet mask: 255.255.224.0
router : 10.164.xx.x (iptv Router ip)
dhcp server: 10.164.xx.xx
lease time : 82174
last update: Thu Sep 27 07:41:35 CEST 2018
expiry : Fri Sep 28 06:31:08 CEST 2018
reason : RENEW

Stap 3:
Router IP. Toevoegen aan config.json en uploaden.

Stap 4:
Auto update IPTV route automatically
The routed IP network sometimes changes, therefore the next-hop settings for routing should periodically change

Pull the update_iptv_route.sh from the repo
SFTP into the USG
Push the update script: push update_iptv_route.sh
SSH into the USG
Move the file: mv update_iptv_route.sh /config/scripts/post-config.d/
Make the file executable chmod +x /config/scripts/post-config.d/update_iptv_route.sh
Execute the script ./update_iptv_route.sh

Of moet ik voor de laatst stap iets anders gebruiken?
Ik zie namelijk ook iets anders voor bij komen van xbream

Klopt in mijn json worden inderdaad geen anker hooks geladen. Door Het installeren van de hooks heb Je het routing gedeelte uit de json niet meer nodig. Alleen voor heel veel mensen(thuis gebruikers) is het uitvoeren van een json al erg complex. Vandaar dat ik dat ik hooks installatie en de cron jobs niet vermeld.

Voor een groot deel van iptv gebruikers wijzigt het router adres nooit en is de json voldoende.

Maar @Jeroen_ae92 is de ⚓️ en job koning als hij zegt dat het goed is.

[Old-Tweaker]

xbeam schreef op donderdag 22 augustus 2019 @ 08:34:
[...]


Klopt in mijn json worden inderdaad geen anker hooks geladen. Door Het installeren van de hooks heb Je het routing gedeelte uit de json niet meer nodig. Alleen voor heel veel mensen(thuis gebruikers) is het uitvoeren van een json al erg complex. Vandaar dat ik dat ik hooks installatie en de cron jobs niet vermeld.

Voor een groot deel van iptv gebruikers wijzigt het router adres nooit en is de json voldoende.

Maar @Jeroen_ae92 is de ⚓️ en job koning als hij zegt dat het goed is.

Ehh, ik ben ook een thuis gebruiker en het is inderdaad complex maar dat houdt me niet tegen.

Ik kom nu op het volgende stappen plan alleen het laatste stukje van de cronjob weet ik niet of het juist is. Dus de tijd van het uitvoeren.
Dus stap 3:. set system task-scheduler task updateIPTVroute crontab-spec "* 4 * * *"

Stap 1:
Kopieer en plak dit commando in je ssh terminal van de USG
show dhcp client leases interface eth0.4

Stap 2:
output
interface : eth0.4
ip address : 10.164.xx.xx [Active]
subnet mask: 255.255.224.0
router : 10.164.xx.x (iptv Router ip)
dhcp server: 10.164.xx.xx
lease time : 82174
last update: Thu Sep 27 07:41:35 CEST 2018
expiry : Fri Sep 28 06:31:08 CEST 2018
reason : RENEW

Stap 3:
Router IP. Toevoegen aan config.json, uploaden.en force provision

Stap 4: Update IPTV routering automatisch
Het gerouteerd IP netwerk veranderd soms daarvoor moet de next-hop instellingen voor de routing periodiek aangepast worden.

Gebruik hiervoor onderstaande script

#!/bin/vbash

# configured static route target
CUR_IP=\$(cat /config/config.boot | grep 213.75.112.0/21 -A1 | grep next-hop | awk '{ print \$2}');
# static route target
NEW_IP=\$(cat /var/run/dhclient_eth0.4_lease | grep new_routers | awk -F= '{print \$2}' | tr -d \');

if [ "\$CUR_IP" = "\$NEW_IP" ]; then
echo Addresses the same
exit 1;
fi

source /opt/vyatta/etc/functions/script-template

configure
delete protocols static route 213.75.112.0/21 next-hop \$CUR_IP
set protocols static route 213.75.112.0/21 next-hop \$NEW_IP
commit
save
exit

sleep 5

restart igmp-proxy

Sla het bestand op als: update_iptv_route.sh

SFTP naar de USG
Ga naar: /config/scripts/post-config.d/
Plaats het bestand "update_iptv_route.sh" in deze map

SSH in de USG
Maak het bestand uitvoerbaar (let op!! root rechten nodig. Dus sudo su)

chmod +x /config/scripts/post-config.d/update_iptv_route.sh

Voor het script uit door het volgende commando uit te voeren:
./update_iptv_route.sh

Stap 5: Cronjob
Voeg het script toe aan de taakplanner om automatisch te controleren / updaten van de statische route.
1. configure
2. set system task-scheduler task updateIPTVroute executable path /config/scripts/post-config.d/update_iptv_route.sh
3. set system task-scheduler task updateIPTVroute crontab-spec "* 4 * * *"
4. commit
5. save
6. exit

Maar ben wel benieuwd naar onderstaande want ik wil graag leren en misschien is die optie beter dan wat ik nu aan het doen ben.

"Door het installeren van de hooks heb je het routing gedeelte uit de json niet meer nodig. Vandaar dat ik dat ik hooks installatie en de cron jobs niet vermeld".

[Alsjemenou]

@Old-Tweaker persoonlijk zou ik niet voor de cronjobs gaan. De kans is nog aanwezig dat je om 04:00 de cron job uitvoert en om 06:00 KPN de routering veranderd waardoor je alsnog de USG moet rebooten. Wanneer je het shell bestand in /config/scripts/post-config.d/ zet wordt deze automatisch bij een restart uitgevoerd, dus dan los je het probleem ook op.

[karlkani1985]

Ik heb ook de manual van @xbeam gevolgd en alles in de JSON file gezet.
Alles werkt top.
Nu heb ik een paar keer de next-hop aan moeten passen en de file weer moeten uploaden.

Wie heeft voor deze stap de "jusite" stappenplan?

Ik lees sommige die zeggen moet je niet doen vanwege de slijtage van de USG.

[Alsjemenou]

karlkani1985 schreef op donderdag 22 augustus 2019 @ 09:41:
Ik heb ook de manual van @xbeam gevolgd en alles in de JSON file gezet.
Alles werkt top.
Nu heb ik een paar keer de next-hop aan moeten passen en de file weer moeten uploaden.

Wie heeft voor deze stap de "jusite" stappenplan?

Ik lees sommige die zeggen moet je niet doen vanwege de slijtage van de USG.

Volg deze stappen: https://github.com/basmee...-iptv-route-automatically

[karlkani1985]

Alsjemenou schreef op donderdag 22 augustus 2019 @ 09:55:
[...]


Volg deze stappen: https://github.com/basmee...-iptv-route-automatically

Thanks ik ga deze stappen doorlopen

[rens-br]

Ik heb de vraag van @DarkGodMaster verhuisd naar: [Ubiquiti-apparatuur] Ervaringen & Discussie - Deel 3 aangezien het weinig te maken had met IPTV.

[wmo]

Weet iemand toevallig wat de gegevens zijn voor Caiway Glasvezel IPTV ?
Is dat hetzelfde als de Fiber (via caiway)?
(de VLAN's zijn anders VLAN100 internet en VLAN101voor IPTV)

Fiber (via caiway)
VLAN ID Functie verbindingstype
148 IP-tv DHCP
141 Internet DHCP
149 VoIP DHCP
IGMP Snooping / Routing over VLAN 148
Static route naar 217.166.226.0/24 over het IP-TV Gateway (IP-adres verkregen op VLAN 148)
IGMP Proxy whitelist : 239.0.3.0/16, 225.0.71.0/24, 224.0.0.0/16

[ Voor 6% gewijzigd door wmo op 26-08-2019 16:27 ]

[wmo]

Ik kom er nog niet uit. De Caiway Amino (decoder) krijgt een IP-adres in VLAN101 (als goed is moet dat voor Caiway IPTV zijn).

als ik r_ip=$(show dhcp client leases | grep router | awk '{ print $3 }'); uitvoer krijg ik het volgende:

213.184.x.x 172.25.64.1

USG:/home/admin# show dhcp client leases interface eth0.101
interface : eth0.101
ip address : 172.25.65.35 [Active]
subnet mask: 255.255.240.0
router : 172.25.64.1
dhcp server: 62.45.70.22
lease time : 28800
last update: Tue Aug 27 20:46:48 CEST 2019
expiry : Wed Aug 28 04:46:41 CEST 2019
reason : BOUND

root@wmoUSG:/home/admin# show dhcp client leases interface eth0.100
interface : eth0.100
ip address : 213.184.103.30 [Active]
subnet mask: 255.255.240.0
router : 213.184.96.1
name server: 62.45.46.69 83.128.0.2
dhcp server: 62.45.70.54
lease time : 1800
last update: Tue Aug 27 21:50:57 CEST 2019
expiry : Tue Aug 27 22:20:53 CEST 2019
reason : RENEW

wat moet ik nou dan als static route in de USG config plaatsen?

[karlkani1985]

Iemand met kpn zijn USG 3P al geupdate van 4.4.41.5193700 to 4.4.44.5213844?

[RUFFNECK]

karlkani1985 schreef op woensdag 28 augustus 2019 @ 14:11:
Iemand met kpn zijn USG 3P al geupdate van 4.4.41.5193700 to 4.4.44.5213844?

Ja, vorige week gedaan, why?

[toets23]

Sinds vandaag een USG met versie 4.3....., en wil deze rechtstreeks aansluiten op mijn glasvezel aansluiting. Ik ben alleen geïnteresseerd in Internet (vlan 6), dus IPTV gaat niet geconfigureerd worden.

Naar mijn idee kan dit via de WEBUI, ik zie namelijk ppoe staan en vlan, echter als ik dit invul werkt het niet...
Kan dit ook te maken hebben met een oudere firmware versie?

Aanvulling: KPN Glasvezel

[ Voor 3% gewijzigd door toets23 op 29-08-2019 10:06 ]

[Thysiej]

toets23 schreef op donderdag 29 augustus 2019 @ 10:06:
Sinds vandaag een USG met versie 4.3....., en wil deze rechtstreeks aansluiten op mijn glasvezel aansluiting. Ik ben alleen geïnteresseerd in Internet (vlan 6), dus IPTV gaat niet geconfigureerd worden.

Naar mijn idee kan dit via de WEBUI, ik zie namelijk ppoe staan en vlan, echter als ik dit invul werkt het niet...
Kan dit ook te maken hebben met een oudere firmware versie?

Aanvulling: KPN Glasvezel

Dat werkt zeker via de WEBUI, maar je moet naast het VLAN ook nog de username en password doorgeven. Check even https://github.com/basmee...pn#1-setup-basic-internet

Hiermee werkte het voor mij al direct. De rest kan je negeren in dat geval.

[toets23]

Thysiej schreef op donderdag 29 augustus 2019 @ 10:21:
[...]

Dat werkt zeker via de WEBUI, maar je moet naast het VLAN ook nog de username en password doorgeven. Check even https://github.com/basmee...pn#1-setup-basic-internet

Hiermee werkte het voor mij al direct. De rest kan je negeren in dat geval.

Oh, ik zie andere settings, ga ik vanavond testen. Dank je!

[ Voor 10% gewijzigd door toets23 op 29-08-2019 10:26 ]

[GerjanT]

Ik heb een edgerouter Lite met de Kriegsman-configuratie met XS4ALL. Ik heb met enige regelmaat dat het beeld 0,5-1 seconde stilstaat terwijl het geluid wel doorgaat. Heeft iemand anders deze ervaring ook en wellicht een oplossing?