[Freedom] Ervaringen & Discussie

[HoleinOne]

De ontvanger een powerflip gegeven. Build 76904 staat er op. Het werkt nog steeds goed bij mij.

[jurry]

Verwijderd schreef op donderdag 22 oktober 2020 @ 13:28:
Maar waar dan wel? Dit PPPoE-probleem is bij mij echt begonnen met de overstap naar Freedom. Hiervoor jaren XS4ALL gehad met exact hetzelfde modem, exact dezelfde router en exact dezelfde config, en toen gebeurde dit helemaal nooit. Het herstarten van m'n WAN zorgde altijd direct weer voor verbinding, nu werkt dat helemaal nooit en gaan er minuten overheen voordat de verbinding terug is.

Hier bijna dezelfde situatie dat regelmatig valt de verbinding weg met het verschil dat bij de XS4ALL verbinding een FRITZ!Box 7581 terwijl er ik van Freedom een FRITZ!Box 7583 heb ontvangen. Enkele dagen gaat het goed en dan opeens meerdere keren binnen paar uur.

code:

24.10.20 04:01:28 Internet connection failed: Reason for error: 2 (DHCPv4 no answer on DISCOVER)
24.10.20 03:55:43 IPv6 internet connection error: DHCPv6 error because of 8 ()
24.10.20 00:19:52 Internet connection failed: Reason for error: 2 (DHCPv4 no answer on DISCOVER)
23.10.20 19:47:03 Internet connection failed: Reason for error: 2 (DHCPv4 no answer on DISCOVER)

Sinds vanochtend dus een nieuwe variant namelijk wanneer ik op reconnect druk op de pagina Online Monitor de PPPoE verbinding direct opnieuw wordt opgestart maar zonder IPv6. Na paar keer opnieuw verbinden is ondertussen IPv6 ook weer actief.

code:

24.10.20 08:22:50 IPv6 internet connection error: DHCPv6 error because of 8 ()

Wat mij ook opvalt, is het aantal unrecoverable errors dat enorm varieert. Gisteravond na opnieuw opstarten omdat de PPPoE verbinding niet snel genoeg terugkwam, zie ik op de pagina Statistics rond de 10.000 per uur unrecoverable errors. Na de restarts om 04:00 is het aantal unrecoverable errors in de grafiek minimaal. Op de pagina DSL zie ik nu bij Error Counter het volgende

code:

                            FRITZ!Box   Central Exchange
Seconds With Errors (ES)    2           0
Many Errors (SES)           0           0
        
Not Remediable Errors (CRC)         
per Minute                  0           0
Last 15 Minutes             0           0
        
corrected DTU       
per minute                  85          0
Last 15 minutes             0           173
        
uncorrected DTU         
per minute                  5199        0
last 15 minutes             0           0

Hopelijk heeft @raymonvdm nog nieuws?

[Verwijderd]

jurry schreef op zaterdag 24 oktober 2020 @ 08:50:
[...]


Hier bijna dezelfde situatie dat regelmatig valt de verbinding weg met het verschil dat bij de XS4ALL verbinding een FRITZ!Box 7581 terwijl er ik van Freedom een FRITZ!Box 7583 heb ontvangen. Enkele dagen gaat het goed en dan opeens meerdere keren binnen paar uur.

code:

24.10.20 04:01:28 Internet connection failed: Reason for error: 2 (DHCPv4 no answer on DISCOVER)
24.10.20 03:55:43 IPv6 internet connection error: DHCPv6 error because of 8 ()
24.10.20 00:19:52 Internet connection failed: Reason for error: 2 (DHCPv4 no answer on DISCOVER)
23.10.20 19:47:03 Internet connection failed: Reason for error: 2 (DHCPv4 no answer on DISCOVER)

Sinds vanochtend dus een nieuwe variant namelijk wanneer ik op reconnect druk op de pagina Online Monitor de PPPoE verbinding direct opnieuw wordt opgestart maar zonder IPv6. Na paar keer opnieuw verbinden is ondertussen IPv6 ook weer actief.

code:

24.10.20 08:22:50 IPv6 internet connection error: DHCPv6 error because of 8 ()

Wat mij ook opvalt, is het aantal unrecoverable errors dat enorm varieert. Gisteravond na opnieuw opstarten omdat de PPPoE verbinding niet snel genoeg terugkwam, zie ik op de pagina Statistics rond de 10.000 per uur unrecoverable errors. Na de restarts om 04:00 is het aantal unrecoverable errors in de grafiek minimaal. Op de pagina DSL zie ik nu bij Error Counter het volgende

code:

                            FRITZ!Box   Central Exchange
Seconds With Errors (ES)    2           0
Many Errors (SES)           0           0
        
Not Remediable Errors (CRC)         
per Minute                  0           0
Last 15 Minutes             0           0
        
corrected DTU       
per minute                  85          0
Last 15 minutes             0           173
        
uncorrected DTU         
per minute                  5199        0
last 15 minutes             0           0

Hopelijk heeft @raymonvdm nog nieuws?

Let wel, bij mij is de verbinding nog nooit weggevallen. Als hij eenmaal up is, is hij ook stabiel. Niet anders dan bij XS4ALL.

Maar het opzetten van de PPPoE-tunnel is echt een drama. Het opnieuw opzetten is vooralsnog alleen gebeurd wanneer ik handmatig de WAN herstartte of mijn router rebootte, maar ik ben dus wel bang dat als de verbinding ooit een seconde wegvalt, hij minuten down blijft omdat PPPoE-discovery zo glitchy is.

Bij XS4ALL viel de PPPoE-tunnel eens in de paar weken 's nachts nog wel eens weg, maar kwam dan binnen 3 seconden weer terug. Bij Freedom houd ik m'n hart vast als dat gebeurt. En dat is jammer, want ik ben verder echt heel tevreden.

[Out.of.Control]

Verwijderd schreef op donderdag 22 oktober 2020 @ 13:28:
[...]


Maar waar dan wel? Dit PPPoE-probleem is bij mij echt begonnen met de overstap naar Freedom. Hiervoor jaren XS4ALL gehad met exact hetzelfde modem, exact dezelfde router en exact dezelfde config, en toen gebeurde dit helemaal nooit. Het herstarten van m'n WAN zorgde altijd direct weer voor verbinding, nu werkt dat helemaal nooit en gaan er minuten overheen voordat de verbinding terug is.

Ik herken dit wel van XS4ALL. Ik gebruik een OpenBSD systeem als router (zowel in het verleden bij XS4ALL als nu bij Freedom) en als ik de router herstart komt de PPPOE verbinding ook niet in de lucht. Lijkt erop dat de oude verbinding nog actief is of zoiets.
Als ik dan nog een keer reboot (of de eerste keer een paar minuten wacht met opnieuw opstarten) dan werkt het vlekkeloos. Kennelijk is de oude verbinding dan wel weg.
In de nieuwsgroep xs4all.general is dit ook al vaker aan de orde geweest, o.a. door ene Rob.

[Verwijderd]

Out.of.Control schreef op zaterdag 24 oktober 2020 @ 10:00:
[...]


Ik herken dit wel van XS4ALL. Ik gebruik een OpenBSD systeem als router (zowel in het verleden bij XS4ALL als nu bij Freedom) en als ik de router herstart komt de PPPOE verbinding ook niet in de lucht. Lijkt erop dat de oude verbinding nog actief is of zoiets.
Als ik dan nog een keer reboot (of de eerste keer een paar minuten wacht met opnieuw opstarten) dan werkt het vlekkeloos. Kennelijk is de oude verbinding dan wel weg.
In de nieuwsgroep xs4all.general is dit ook al vaker aan de orde geweest, o.a. door ene Rob.

Hmm, in de afgelopen 6-7 jaar bij XS4ALL heb ik dit echt nooit gehad. Nu bij Freedom altijd. Mijn gevoel zegt dat het ofwel een soort anti-hammeringfeature is ("PPPoE lockout" is daadwerkelijk een feature op Juniper-routers, en Cisco zal het vast ook hebben), of dat er een sessie op de RADIUS-server open blijft, of iets in die richting.

Ik heb nu maar een script geschreven dat ik laat starten door /etc/rc.local. Maar het zint me niet dat dit nodig is.

code:

#!/bin/sh

interface="wan"
check_interval="30"
holdoff_time="120"

while true; do

log_time="$(logread -t | grep "Timeout waiting for PADO packets" | tail -n 1 | awk -F"[" '{print $2}' | awk -F"." '{print $1}')"

   if [ -n "$log_time" ] && [ $(($(/bin/date +%s) - log_time)) -lt $check_interval ]; then
      echo "PPPoE discovery seems to be failing. Holding off for 2 minutes..."
      ifdown $interface
      sleep $holdoff_time
      ifup $interface
   else
      echo "PPPoE discovery is not active or not failing."
      sleep $check_interval
   fi

done

Komt bij jou de PPPoE-tunnel uiteindelijk wel weer up na eindeloze retries? Want ik heb het gevoel dat tijdelijk stoppen met PADI's sturen ervoor zorgt dat het een stuk sneller gaat.

[AgamemnonZ]

AgamemnonZ schreef op maandag 14 september 2020 @ 14:06:
Doet DNSSEC het bij anderen? Als ik de 'test your connection' scan van https://internet.nl/ draai dan staat er bij mij dat DNSSEC niet werkt.

[Afbeelding]

Vorige week deed DNSSEC het nog steeds niet. Inmiddels blijkbaar weer wel (getest via 'Test your connection' op internet.nl). Mooi!

[YWatchman]

Verwijderd schreef op zaterdag 24 oktober 2020 @ 10:37:
[...]


Hmm, in de afgelopen 6-7 jaar bij XS4ALL heb ik dit echt nooit gehad. Nu bij Freedom altijd. Mijn gevoel zegt dat het ofwel een soort anti-hammeringfeature is ("PPPoE lockout" is daadwerkelijk een feature op Juniper-routers, en Cisco zal het vast ook hebben), of dat er een sessie op de RADIUS-server open blijft, of iets in die richting.

Ik heb nu maar een script geschreven dat ik laat starten door /etc/rc.local. Maar het zint me niet dat dit nodig is.

code:

#!/bin/sh

interface="wan"
check_interval="30"
holdoff_time="120"

while true; do

log_time="$(logread -t | grep "Timeout waiting for PADO packets" | tail -n 1 | awk -F"[" '{print $2}' | awk -F"." '{print $1}')"

   if [ -n "$log_time" ] && [ $(($(/bin/date +%s) - log_time)) -lt $check_interval ]; then
      echo "PPPoE discovery seems to be failing. Holding off for 2 minutes..."
      ifdown $interface
      sleep $holdoff_time
      ifup $interface
   else
      echo "PPPoE discovery is not active or not failing."
      sleep $check_interval
   fi

done

Komt bij jou de PPPoE-tunnel uiteindelijk wel weer up na eindeloze retries? Want ik heb het gevoel dat tijdelijk stoppen met PADI's sturen ervoor zorgt dat het een stuk sneller gaat.

Heb je in je ARP table wel gekeken of het een Juniper router is waar je mee praat? ;-)

[Verwijderd]

YWatchman schreef op zaterdag 24 oktober 2020 @ 13:03:
[...]


Heb je in je ARP table wel gekeken of het een Juniper router is waar je mee praat? ;-)

De PPPoE-negotiation wordt gedaan met 00:30:88:11:7f:c2. Dat is zo te zien een Ericsson MAC-adres.

Binnen PPP wordt geen ARP gebruikt toch? Dan kan ik niet het MAC-adres van de access router/concentrator vinden. De eerste hop na m'n router is lo0.cmbr.nikhef-1.connected.by.freedom.nl.

[YWatchman]

Verwijderd schreef op zaterdag 24 oktober 2020 @ 13:13:
[...]


De PPPoE-negotiation wordt gedaan met 00:30:88:11:7f:c2. Dat is zo te zien een Ericsson MAC-adres.

Binnen PPP wordt geen ARP gebruikt toch? Dan kan ik niet het MAC-adres van de access router/concentrator vinden. De eerste hop na m'n router is lo0.cmbr.nikhef-1.connected.by.freedom.nl.

Je lijkt jezelf tegen te spreken, je hebt het mac-adres gevonden van het systeem dat niet altijd juist reageert. De hop na je router wijst op een interface aan de cambrium zijde van het netwerk, met die router heb je een point-to-point verbinding. Die handelt dus ook je PPP negotiation af.

[Verwijderd]

YWatchman schreef op zaterdag 24 oktober 2020 @ 13:16:
[...]


Je lijkt jezelf tegen te spreken, je hebt het mac-adres gevonden van het systeem dat niet altijd juist reageert. De hop na je router wijst op een interface aan de cambrium zijde van het netwerk, met die router heb je een point-to-point verbinding. Die handelt dus ook je PPP negotiation af.

Het is niet helemaal zeker dat het probleem bij de de rb600.sara.cambrium.net ligt. Het kan ook bijvoorbeeld nog een RADIUS-server zijn die niet altijd goed reageert. En er zijn ook meldingen dat rb1200.nikhef.cambrium.net ook niet altijd goed werkt.

PPPoE-negotiation wordt volgens de logs niet gedaan met lo0.cmbr.nikhef-1.connected.by.freedom.nl, tenzij dat een andere hostname voor hetzelfde device is. Maar ik denk zomaar dat de rb600 op Sara en de lo0.cmbr op Nikhef staat.

Als ik de berichten van @raymonvdm mag geloven (en dat doe ik wel), komen zijn PADI-packets volgens de Cambrium-engineers soms niet binnen, terwijl hij ze wel verstuurt. Ik zie dat als goede verklaring, want wat ik steeds zie is dat ik geen PADO-packets terugkrijg. Dat zou goed kunnen gebeuren wanneer er geen PADI's aan de overkant ontvangen worden.

De vraag is dan alleen waarom die PADI's niet ontvangen worden, en waarom ineens na een paar minuten wel. Want dat is het probleem dat heel veel users hier omschrijven: er zit vaak een lange tijd tussen het stoppen en herstarten van de PPPoE-tunnel en het opnieuw kunnen opzetten ervan. En dit lijkt te gebeuren met allerlei setups, zowel op koper als op glas.

[ Voor 6% gewijzigd door Verwijderd op 24-10-2020 15:01 ]

[eymey]

Verwijderd schreef op donderdag 22 oktober 2020 @ 21:57:

Maar zo te zien kom jij op rb1200.nikhef.cambrium.net. Ik heb het idee dat die wat minder problemen geeft dan de rb600.sara.cambrium.net.

Probeer het nog eens een paar keer, zou ik zeggen. Als het goed blijft gaan, is dat hoopgevend. Wellicht hebben ze bij Cambrium dan toch iets kunnen aanpassen aan de hand van hun tests met @raymonvdm.

Ik heb zojuist nog twee keer handmatig (vanuit de OPNSense web interface) de PPPoE verbinding gesloten en meteen weer gestart. En beide keren kwam vanzelf de verbinding weer online. Niet instantaan, maar met uiteindelijk ongeveer 20 ping's verloren in een doorlopende ping sessie.

Daarnaast ook nog een aantal keer de OPNSense VM ge-reboot en alle keren weer snel een PPPoE verbinding.

Nou kan ik de mazzel hebben iedere keer weer op rb1200 uit te komen, of de PPPoE implementatie van FreeBSD doet toch iets 'anders' waardoor sommige PPPoE-clients wel tegen gekkigheden van rb600.sara.cambrium.net aan lopen en anderen weer niet.

[Verwijderd]

eymey schreef op zaterdag 24 oktober 2020 @ 15:38:
[...]


Ik heb zojuist nog twee keer handmatig (vanuit de OPNSense web interface) de PPPoE verbinding gesloten en meteen weer gestart. En beide keren kwam vanzelf de verbinding weer online. Niet instantaan, maar met uiteindelijk ongeveer 20 ping's verloren in een doorlopende ping sessie.

Daarnaast ook nog een aantal keer de OPNSense VM ge-reboot en alle keren weer snel een PPPoE verbinding.

Nou kan ik de mazzel hebben iedere keer weer op rb1200 uit te komen, of de PPPoE implementatie van FreeBSD doet toch iets 'anders' waardoor sommige PPPoE-clients wel tegen gekkigheden van rb600.sara.cambrium.net aan lopen en anderen weer niet.

Ik denk niet dat de router waarop je binnenkomt dynamisch is. Waarschijnlijk verschilt dat tussen glas en koper, en tussen KPN WBA en Cambrium.

Ik heb mijn WAN-interface een uur of twee geleden ook nog eens handmatig herstart, en toen kwam de tunnel zowaar binnen een paar seconden weer terug. Dit is voor het eerst sinds ik bij Freedom zit dat het in één keer goed ging.

Toen heb ik maar eens naar m'n syslog gekeken, en toen bleek dat schijn bedroog.

code:

Sat Oct 24 15:52:27 2020 daemon.notice netifd: Interface 'wan' is enabled
Sat Oct 24 15:52:27 2020 daemon.notice netifd: VLAN 'eth0.6' link is up
Sat Oct 24 15:52:27 2020 daemon.notice netifd: Interface 'wan' has link connectivity
Sat Oct 24 15:52:27 2020 daemon.notice netifd: Interface 'wan' is setting up now
Sat Oct 24 15:52:28 2020 daemon.info pppd[27020]: Plugin rp-pppoe.so loaded.
Sat Oct 24 15:52:28 2020 daemon.info pppd[27020]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Sat Oct 24 15:52:28 2020 daemon.notice pppd[27020]: pppd 2.4.7 started by root, uid 0
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  dst ff:ff:ff:ff:ff:ff  src 14:cc:20:xx:xx:xx
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  [service-name] [host-uniq  00 00 69 8c]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 49
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  dst 14:cc:20:xx:xx:xx  src 00:30:88:11:7f:c2
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  [host-uniq  00 00 69 8c] [AC-name asd-itxams9-rtr2.cambrium.net] [service-name] [end-of-list]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: Send PPPOE Discovery V1T1 PADR session 0x0 length 12
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  dst 00:30:88:11:7f:c2  src 14:cc:20:xx:xx:xx
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  [service-name] [host-uniq  00 00 69 8c]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: Recv PPPOE Discovery V1T1 PADS session 0xbd3 length 49
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  dst 14:cc:20:xx:xx:xx  src 00:30:88:11:7f:c2
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  [service-name] [host-uniq  00 00 69 8c] [AC-name asd-itxams9-rtr2.cambrium.net] [end-of-list]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: PADS: Service-Name: ''
Sat Oct 24 15:52:28 2020 daemon.info pppd[27020]: PPP session is 3027
Sat Oct 24 15:52:28 2020 daemon.warn pppd[27020]: Connected to 00:30:88:11:7f:c2 via interface eth0.6
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: using channel 6
Sat Oct 24 15:52:28 2020 kern.info kernel: [341153.562893] pppoe-wan: renamed from ppp0
Sat Oct 24 15:52:28 2020 daemon.info pppd[27020]: Renamed interface ppp0 to pppoe-wan
Sat Oct 24 15:52:28 2020 daemon.info pppd[27020]: Using interface pppoe-wan
Sat Oct 24 15:52:28 2020 daemon.notice pppd[27020]: Connect: pppoe-wan <--> eth0.6
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x275a7aa>]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: rcvd [LCP ConfReq id=0x44 <mru 1492> <auth chap MD5> <magic 0x5c3089a>]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: sent [LCP ConfAck id=0x44 <mru 1492> <auth chap MD5> <magic 0x5c3089a>]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x275a7aa>]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: sent [LCP EchoReq id=0x0 magic=0x275a7aa]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: rcvd [CHAP Challenge id=0x1 <4cc8e7a3793b6603a6f245f87eb86323>, name = "rb600.sara.cambrium.net"]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: sent [CHAP Response id=0x1 <024531f4078a4f93e5fa0a08d749f70f>, name = "[e-mail]"]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: rcvd [LCP EchoRep id=0x0 magic=0x5c3089a]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: rcvd [CHAP Failure id=0x1 "CHAP authentication failure, unit 91"]
Sat Oct 24 15:52:28 2020 daemon.info pppd[27020]: CHAP authentication failed: CHAP authentication failure, unit 91
Sat Oct 24 15:52:28 2020 daemon.err pppd[27020]: CHAP authentication failed
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: rcvd [LCP TermReq id=0x45]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: sent [LCP TermAck id=0x45]
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: rcvd [LCP TermAck id=0x2]
Sat Oct 24 15:52:28 2020 daemon.notice pppd[27020]: Connection terminated.
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]: Send PPPOE Discovery V1T1 PADT session 0xbd3 length 8
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  dst 00:30:88:11:7f:c2  src 14:cc:20:xx:xx:xx
Sat Oct 24 15:52:28 2020 daemon.debug pppd[27020]:  [host-uniq  00 00 69 8c]
Sat Oct 24 15:52:28 2020 daemon.info pppd[27020]: Sent PADT
Sat Oct 24 15:52:28 2020 daemon.info pppd[27020]: Exit.
Sat Oct 24 15:52:29 2020 daemon.notice netifd: Interface 'wan' is now down
Sat Oct 24 15:52:29 2020 daemon.notice netifd: Interface 'wan' is disabled

Sat Oct 24 15:52:29 2020 daemon.notice netifd: Interface 'wan' is enabled
Sat Oct 24 15:52:29 2020 daemon.notice netifd: Interface 'wan' is setting up now
Sat Oct 24 15:52:30 2020 daemon.info pppd[27137]: Plugin rp-pppoe.so loaded.
Sat Oct 24 15:52:30 2020 daemon.info pppd[27137]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Sat Oct 24 15:52:30 2020 daemon.notice pppd[27137]: pppd 2.4.7 started by root, uid 0
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  dst ff:ff:ff:ff:ff:ff  src 14:cc:20:xx:xx:xx
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  [service-name] [host-uniq  00 00 6a 01]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 49
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  dst 14:cc:20:xx:xx:xx  src 00:30:88:11:7f:c2
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  [host-uniq  00 00 6a 01] [AC-name asd-itxams9-rtr2.cambrium.net] [service-name] [end-of-list]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: Send PPPOE Discovery V1T1 PADR session 0x0 length 12
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  dst 00:30:88:11:7f:c2  src 14:cc:20:xx:xx:xx
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  [service-name] [host-uniq  00 00 6a 01]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: Recv PPPOE Discovery V1T1 PADS session 0xf5d length 49
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  dst 14:cc:20:xx:xx:xx  src 00:30:88:11:7f:c2
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  [service-name] [host-uniq  00 00 6a 01] [AC-name asd-itxams9-rtr2.cambrium.net] [end-of-list]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: PADS: Service-Name: ''
Sat Oct 24 15:52:30 2020 daemon.info pppd[27137]: PPP session is 3933
Sat Oct 24 15:52:30 2020 daemon.warn pppd[27137]: Connected to 00:30:88:11:7f:c2 via interface eth0.6
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: using channel 7
Sat Oct 24 15:52:30 2020 kern.info kernel: [341155.251353] pppoe-wan: renamed from ppp0
Sat Oct 24 15:52:30 2020 daemon.info pppd[27137]: Renamed interface ppp0 to pppoe-wan
Sat Oct 24 15:52:30 2020 daemon.info pppd[27137]: Using interface pppoe-wan
Sat Oct 24 15:52:30 2020 daemon.notice pppd[27137]: Connect: pppoe-wan <--> eth0.6
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x4d37191d>]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: rcvd [LCP ConfReq id=0xb4 <mru 1492> <auth chap MD5> <magic 0x2c9891c>]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: sent [LCP ConfAck id=0xb4 <mru 1492> <auth chap MD5> <magic 0x2c9891c>]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x4d37191d>]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: sent [LCP EchoReq id=0x0 magic=0x4d37191d]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: rcvd [CHAP Challenge id=0x1 <d6131cb6db168339874f81eff2faaad8>, name = "rb600.sara.cambrium.net"]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: sent [CHAP Response id=0x1 <e976e4c1bd02752da9533d7945a114ed>, name = "[e-mail]"]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: rcvd [LCP EchoRep id=0x0 magic=0x2c9891c]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: rcvd [CHAP Failure id=0x1 "CHAP authentication failure, unit 91"]
Sat Oct 24 15:52:30 2020 daemon.info pppd[27137]: CHAP authentication failed: CHAP authentication failure, unit 91
Sat Oct 24 15:52:30 2020 daemon.err pppd[27137]: CHAP authentication failed
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: rcvd [LCP TermReq id=0xb5]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: sent [LCP TermAck id=0xb5]
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: rcvd [LCP TermAck id=0x2]
Sat Oct 24 15:52:30 2020 daemon.notice pppd[27137]: Connection terminated.
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]: Send PPPOE Discovery V1T1 PADT session 0xf5d length 8
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  dst 00:30:88:11:7f:c2  src 14:cc:20:xx:xx:xx
Sat Oct 24 15:52:30 2020 daemon.debug pppd[27137]:  [host-uniq  00 00 6a 01]
Sat Oct 24 15:52:30 2020 daemon.info pppd[27137]: Sent PADT
Sat Oct 24 15:52:30 2020 daemon.info pppd[27137]: Exit.
Sat Oct 24 15:52:30 2020 daemon.notice netifd: Interface 'wan' is now down
Sat Oct 24 15:52:30 2020 daemon.notice netifd: Interface 'wan' is disabled

Ik kom nu dus een stap verder sinds ik donderdagmiddag voor het laatst keek, zonder enige configuratiewijziging aan mijn kant. Ik krijg nu wel direct een PADO-respons van de server, maar de eerste twee authenticatiepogingen falen. De derde keer, zo'n 4~5 seconden na het verbreken van de verbinding, gaat het wel goed.

code:

Sat Oct 24 15:52:30 2020 daemon.notice netifd: Interface 'wan' is enabled
Sat Oct 24 15:52:30 2020 daemon.notice netifd: Interface 'wan' is setting up now
Sat Oct 24 15:52:31 2020 daemon.info pppd[27230]: Plugin rp-pppoe.so loaded.
Sat Oct 24 15:52:31 2020 daemon.info pppd[27230]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: pppd 2.4.7 started by root, uid 0
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]:  dst ff:ff:ff:ff:ff:ff  src 14:cc:20:xx:xx:xx
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]:  [service-name] [host-uniq  00 00 6a 5e]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 49
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]:  dst 14:cc:20:xx:xx:xx  src 00:30:88:11:7f:c2
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]:  [host-uniq  00 00 6a 5e] [AC-name asd-itxams9-rtr2.cambrium.net] [service-name] [end-of-list]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: Send PPPOE Discovery V1T1 PADR session 0x0 length 12
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]:  dst 00:30:88:11:7f:c2  src 14:cc:20:xx:xx:xx
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]:  [service-name] [host-uniq  00 00 6a 5e]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: Recv PPPOE Discovery V1T1 PADS session 0x247d length 49
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]:  dst 14:cc:20:xx:xx:xx  src 00:30:88:11:7f:c2
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]:  [service-name] [host-uniq  00 00 6a 5e] [AC-name asd-itxams9-rtr2.cambrium.net] [end-of-list]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: PADS: Service-Name: ''
Sat Oct 24 15:52:31 2020 daemon.info pppd[27230]: PPP session is 9341
Sat Oct 24 15:52:31 2020 daemon.warn pppd[27230]: Connected to 00:30:88:11:7f:c2 via interface eth0.6
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: using channel 8
Sat Oct 24 15:52:31 2020 daemon.info pppd[27230]: Renamed interface ppp0 to pppoe-wan
Sat Oct 24 15:52:31 2020 daemon.info pppd[27230]: Using interface pppoe-wan
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: Connect: pppoe-wan <--> eth0.6
Sat Oct 24 15:52:31 2020 kern.info kernel: [341156.314921] pppoe-wan: renamed from ppp0
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xb57ecf26>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [LCP ConfReq id=0x85 <mru 1492> <auth chap MD5> <magic 0x7cbdffd4>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: sent [LCP ConfAck id=0x85 <mru 1492> <auth chap MD5> <magic 0x7cbdffd4>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xb57ecf26>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: sent [LCP EchoReq id=0x0 magic=0xb57ecf26]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [CHAP Challenge id=0x1 <7c2e6d68e78b60d71ab6ebb66d474c70>, name = "rb600.sara.cambrium.net"]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: sent [CHAP Response id=0x1 <2bebff2aa3794bceed957f6705cf6aac>, name = "[e-mail]"]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [LCP EchoRep id=0x0 magic=0x7cbdffd4]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [CHAP Success id=0x1 "CHAP authentication success, unit 91"]
Sat Oct 24 15:52:31 2020 daemon.info pppd[27230]: CHAP authentication succeeded: CHAP authentication success, unit 91
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: CHAP authentication succeeded
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: peer from calling number 00:30:88:11:7F:C2 authorized
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: sent [IPV6CP ConfReq id=0x1 <addr fe80::6505:c355:3592:4d89>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [IPV6CP ConfReq id=0xb1 <addr fe80::0230:88ff:fe04:9094>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: sent [IPV6CP ConfAck id=0xb1 <addr fe80::0230:88ff:fe04:9094>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [IPV6CP ConfAck id=0x1 <addr fe80::6505:c355:3592:4d89>]
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: local  LL address fe80::6505:c355:3592:4d89
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: remote LL address fe80::0230:88ff:fe04:9094
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: Script /lib/netifd/ppp6-up started (pid 27253)
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [IPCP ConfReq id=0x5e <addr 185.93.175.225>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: sent [IPCP ConfAck id=0x5e <addr 185.93.175.225>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [IPCP ConfNak id=0x1 <addr 45.95.x.x> <ms-dns1 87.251.42.44> <ms-dns2 87.251.42.45>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: sent [IPCP ConfReq id=0x2 <addr 45.95.x.x> <ms-dns1 87.251.42.44> <ms-dns2 87.251.42.45>]
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: rcvd [IPCP ConfAck id=0x2 <addr 45.95.x.x> <ms-dns1 87.251.42.44> <ms-dns2 87.251.42.45>]
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: local  IP address 45.95.x.x
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: remote IP address 185.93.175.225
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: primary   DNS address 87.251.42.44
Sat Oct 24 15:52:31 2020 daemon.notice pppd[27230]: secondary DNS address 87.251.42.45
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: Script /lib/netifd/ppp-up started (pid 27254)
Sat Oct 24 15:52:31 2020 daemon.notice netifd: Network device 'pppoe-wan' link is up
Sat Oct 24 15:52:31 2020 daemon.notice netifd: Interface 'wan' is now up
Sat Oct 24 15:52:31 2020 daemon.debug pppd[27230]: Script /lib/netifd/ppp-up finished (pid 27254), status = 0x1
Sat Oct 24 15:52:32 2020 daemon.notice netifd: Network alias 'pppoe-wan' link is up
Sat Oct 24 15:52:32 2020 daemon.notice netifd: Interface 'wan_6' is enabled
Sat Oct 24 15:52:32 2020 daemon.notice netifd: Interface 'wan_6' has link connectivity
Sat Oct 24 15:52:32 2020 daemon.notice netifd: Interface 'wan_6' is setting up now
Sat Oct 24 15:52:32 2020 daemon.debug pppd[27230]: Script /lib/netifd/ppp6-up finished (pid 27253), status = 0x0
Sat Oct 24 15:52:36 2020 daemon.notice netifd: Interface 'wan_6' is now up

Dus binnen de 9 seconden van het stoppen en herstarten van de verbinding worden er 3 authenticatiepogingen gedaan met dezelfde credentials (niet dat die uitmaken, maar dat terzijde). De eerste twee pogingen falen, de derde lukt wel.

Als ik dit dan weer zo zie, ga ik toch weer denken dat er een RADIUS-server is die niet goed reageert op de authenticatiepogingen. Maar of dat er dan weer voor kan zorgen dat je soms al helemaal geen PADO's terug krijgt..

[ Voor 100% gewijzigd door Verwijderd op 24-10-2020 18:18 ]

[Out.of.Control]

Verwijderd schreef op zaterdag 24 oktober 2020 @ 10:37:
[...]
Komt bij jou de PPPoE-tunnel uiteindelijk wel weer up na eindeloze retries? Want ik heb het gevoel dat tijdelijk stoppen met PADI's sturen ervoor zorgt dat het een stuk sneller gaat.

Ik geloof dat ik de eerste keer dat ik het meemaakte een paar minuten heb gewacht, toen maar een herstart heb gedaan en dat werkte.
Omdat dat altijd goed werkt is dat mijn standaard work around geworden.

Ik heb het idee (maar nooit goed uitgezocht) dat een 2e herstart sneller is dan wachten tot de tunnel zelf weer op komt.

Ik kan op z'n vroegst a.s. dinsdag kijken of de tunnel uiteindelijk toch wel weer op komt. Maar als ik de verdere berichten hier goed begrijp is er mogelijk al het één en ander gewijzigd waardoor dit probleem wellicht niet meer te reproduceren is.

[Verwijderd]

Out.of.Control schreef op zaterdag 24 oktober 2020 @ 22:46:
[...]


Ik geloof dat ik de eerste keer dat ik het meemaakte een paar minuten heb gewacht, toen maar een herstart heb gedaan en dat werkte.
Omdat dat altijd goed werkt is dat mijn standaard work around geworden.

Ik heb het idee (maar nooit goed uitgezocht) dat een 2e herstart sneller is dan wachten tot de tunnel zelf weer op komt.

Ik kan op z'n vroegst a.s. dinsdag kijken of de tunnel uiteindelijk toch wel weer op komt. Maar als ik de verdere berichten hier goed begrijp is er mogelijk al het één en ander gewijzigd waardoor dit probleem wellicht niet meer te reproduceren is.

Ok, en met een herstart bedoel je pppd stoppen, even wachten, en dan pppd weer starten?

Want dat is de hypothese die ik heb; dat het blijven sturen van PADI-packets de situatie erger maakt en het tijdelijk stoppen ermee helpt. En laat dat nou precies zijn wat geen enkele router doet..

[Zr40]

Het werkt niet. Omdat routers graag wel willen werken, blijven ze het af en toe opnieuw proberen. Waarom zou het dan 'erger' worden? De systemen aan de andere kant willen immers ook graag werken.

Ik denk dat je het symptoom verkeerd interpreteert. Als er toevallig een storing was en die was opgelost binnen de tijd dat jij je router even hebt uitgezet, dan lijkt het alsof het uitzetten heeft geholpen, maar in werkelijkheid heeft het er niets mee te maken.

[Verwijderd]

Zr40 schreef op zaterdag 24 oktober 2020 @ 23:15:
Het werkt niet. Omdat routers graag wel willen werken, blijven ze het af en toe opnieuw proberen. Waarom zou het dan 'erger' worden? De hardware aan de andere kant wil immers ook graag werken.

Dat weet ik. Dat is dan ook mijn hele punt. Om de verbinding weer (snel) up te krijgen, lijkt het erop dat je iets moet doen dat geen enkele router normaal gesproken doet: tijdelijk stoppen met proberen opnieuw te verbinden. En dat is behoorlijk tegennatuurlijk.

Ik heb hetzelfde gevoel als @Out.of.Control: een tweede reboot (of gewoon even WAN uitzetten, wachten en WAN weer aanzetten) zorgt ervoor dat de tunnel sneller weer up komt dan wachten tot het vanzelf gebeurt (en al die tijd dus elke paar seconden PADI's sturen).

Zr40 schreef op zaterdag 24 oktober 2020 @ 23:15:
Ik denk dat je het symptoom verkeerd interpreteert. Als er toevallig een storing was en die was opgelost binnen de tijd dat jij je router even hebt uitgezet, dan lijkt het alsof het uitzetten heeft geholpen, maar in werkelijkheid heeft het er niets mee te maken.

Er zijn wel degelijk dingen die dit kunnen veroorzaken. PPPoE lockout is er een voorbeeld van.

https://www.dslreports.co...DO-packet-in-router-s-log
https://www.juniper.net/d...t-pppoe-lockout-time.html

Een andere verklaring is dat de RADIUS-server sessies te lang laat leven en niet antwoordt op nieuwe authenticatierequests terwijl die vorige sessie nog leeft. En er zou wellicht ook nog een probleem op het pad tussen de CPE en de AC kunnen zitten dat er voor zorgt dat PADI-packets niet worden ontvangen.

Het is toch te toevallig dat iedere keer dat ik mijn WAN-interface herstart er precies een storing is en dat die storing iedere keer is opgelost wanneer ik de interface een paar minuten down laat en dan weer up zet, maar dat het altijd goed gaat wanneer er een verbinding wordt opgezet na een redelijke wachttijd tussen dan en het verbreken van de vorige?

Zeker omdat anderen precies hetzelfde beschrijven, met andere hardware, andere firmware, op een andere locatie.

Iemand anders met dit probleem vertelde me in een DM dat hij 300(!) keer zijn PPPoE-sessie had herstart toen hij het aan het testen was met Cambrium-engineers, en dat het al die keren niet direct weer up kwam.

Voor mij was het vandaag de eerste keer dat het wel redelijk snel weer terugkwam (afgezien van twee gefaalde authenticatiepogingen wat ook niet zou moeten gebeuren). Ik kan nu even niet testen wat er gebeurt als ik het nog een keer doe, want ik ben niet op locatie en ik wil mezelf niet buitensluiten.

Maar het zou dus wel kunnen dat er tussen donderdag en vanmiddag iets veranderd is dat het probleem deels heeft opgelost, want mensen van Cambrium zijn er wel aan bezig geweest.

[ Voor 27% gewijzigd door Verwijderd op 25-10-2020 00:59 ]

[Zr40]

Verwijderd schreef op zaterdag 24 oktober 2020 @ 23:24:
[...]


Er zijn wel degelijk dingen die dit kunnen veroorzaken. PPPoE lockout is er een voorbeeld van.

Klopt. Maar dat betreft de situatie waarin de router zelf de verbinding verbreekt na kortstondig verbonden geweest te zijn. Niet het geval hier aangezien de PADI niet ontvangen wordt. Er is dus geen verbinding opgezet die verbroken wordt en een lockout kan triggeren. En zelfs al is er wel sprake van een lockout, dan betreft dit slechts een paar minuten per keer.

Je had zelf trouwens al vastgesteld dat je geen Juniper hardware aan de andere kant van de lijn hebt

Een andere verklaring is dat de RADIUS-server sessies te lang laat leven en niet antwoordt op nieuwe authenticatierequests terwijl die vorige sessie nog leeft. En er zou wellicht ook nog een probleem op het pad tussen de CPE en de AC kunnen zitten dat er voor zorgt dat PADI-packets niet worden ontvangen.

Dat strookt niet met de verklaring dat de PADI packets helemaal niet ontvangen worden aan de kant van Cambrium.

Overigens zie ik in mijn logs ook een verdwaalde authentication failure. Helaas zonder timestamps in de log, maar ik kan het herleiden. Komt op het volgende neer:

Poging 1: slaagt. Up voor 106816.5 minuten (sinds 15 juni tot 28 augustus). Daarna het volgende:

code:

No response to 6 echo-requests
Serial link appears to be disconnected.
Connect time 106816.5 minutes.
Sent 1006225663 bytes, received 1541835167 bytes.
Script /etc/ppp/ip-down started (pid 5973)
Script /etc/ppp/ipv6-down started (pid 5978)
sent [LCP TermReq id=0x2 "Peer not responding"]
Script /etc/ppp/ipv6-down finished (pid 5978), status = 0x0
Script /etc/ppp/ip-down finished (pid 5973), status = 0x0
sent [LCP TermReq id=0x3 "Peer not responding"]
Connection terminated: no multilink.
Modem hangup

Poging 2: Authentication failure.

code:

Renamed interface ppp0 to pppoe0
Using interface pppoe0
Connect: pppoe0 <--> eth3.6
sent [LCP ConfReq id=0x4 <magic 0x88f011c0>]
rcvd [LCP ConfReq id=0x44 <mru 1500> <auth chap MD5> <magic 0x22fb02a0>]
sent [LCP ConfAck id=0x44 <mru 1500> <auth chap MD5> <magic 0x22fb02a0>]
rcvd [LCP ConfAck id=0x4 <magic 0x88f011c0>]
rcvd [CHAP Challenge id=0x1 <bfe81e80d72bfcc4b7ba782122be2743>, name = "rb600.sara.cambrium.net"]
sent [CHAP Response id=0x1 <9443d38a56e6843fbedf08de78d4514d>, name = "edgerouter"]
rcvd [CHAP Failure id=0x1 "CHAP authentication failure, unit 499"]
CHAP authentication failed: CHAP authentication failure, unit 499
CHAP authentication failed
sent [LCP TermReq id=0x5 "Failed to authenticate ourselves to peer"]
rcvd [LCP TermReq id=0x45]
sent [LCP TermAck id=0x45]
rcvd [LCP TermAck id=0x5]
Connection terminated: no multilink.

Poging 3 en 4: Authentication failure, inhoudelijk gelijk aan poging 2.

Poging 5: slaagt. Nog steeds actief, sinds 28 augustus

[ Voor 83% gewijzigd door Zr40 op 24-10-2020 23:46 ]

[ik222]

PADI pakketjes worden over het algemeen ook op de acces switch actief bewerkt, PPPoE IA (Intermediate Agent) zorgt ervoor dat er een circuit / remote-id toegevoegd wordt. Dat zorgt ervoor dat je willekeurige credentials kan opgeven maar je toch altijd als jou aansluiting geauthenticeerd wordt.

Dus als Cambrium niets binnenkrijgt op de redbacks (ik neem aan dat rb600 staat voor een redback SE600 en rb1200 voor een redback SE1200, redback is alweer enige tijd geleden overgenomen door Ericsson) zou het ook daar al veroorzaakt kunnen worden. Al zou je dan wel verwachten dat het zich beperkt tot een specifiek access netwerk.

[Verwijderd]

Ik heb zojuist opnieuw een WAN-reconnect geprobeerd. Hetzelfde verhaal als gisteren: twee authenticatiepogingen falen, de derde slaagt. Binnen 10 seconden was de PPPoE-tunnel weer up.

Dus ik zie absoluut verbetering ten opzichte van donderdag en daarvoor. Dus hopelijk heeft Cambrium wat veranderd.

[.oisyn]

HoleinOne schreef op vrijdag 23 oktober 2020 @ 11:02:
De ontvanger een powerflip gegeven. Build 76904 staat er op. Het werkt nog steeds goed bij mij.

Vreemd, ik heb idd ook 76904

. edit: oh ik krijg de lijst wel als ik op omhoog druk, maar omlaag is hetzelfde als menu

[ Voor 16% gewijzigd door .oisyn op 25-10-2020 21:36 ]

[HoleinOne]

.oisyn schreef op zondag 25 oktober 2020 @ 21:34:
[...]

Vreemd, ik heb idd ook 76904

. edit: oh ik krijg de lijst wel als ik op omhoog druk, maar omlaag is hetzelfde als menu

Het lijkt erop dat je afstandsbediening voor zichzelf is begonnen. Als je er 2 hebt kan je even vergelijken. Hier werkt alles nog met betrekking tot navigatie.

Behalve de titels van de programma gids. Ik heb sterk de indruk dat dat minder goed is dan in de xs4all periode. Mijn vrouw wil terug naar xs4all omdat de verkeerde programma's worden aangegeven en opnames niet afgespeeld kunnen worden. Ook doorspoelen op sommige zenders wat bij xs4all kon kan niet bij canal digitaal.

[.oisyn]

HoleinOne schreef op zondag 25 oktober 2020 @ 21:58:
[...]

Het lijkt erop dat je afstandsbediening voor zichzelf is begonnen. Als je er 2 hebt kan je even vergelijken. Hier werkt alles nog met betrekking tot navigatie.

Dat zou sense maken als omlaag niet als omlaag werkt in de menu's, maar dat doet het wel

[eymey]

ik222 schreef op zaterdag 24 oktober 2020 @ 23:41:
PADI pakketjes worden over het algemeen ook op de acces switch actief bewerkt, PPPoE IA (Intermediate Agent) zorgt ervoor dat er een circuit / remote-id toegevoegd wordt. Dat zorgt ervoor dat je willekeurige credentials kan opgeven maar je toch altijd als jou aansluiting geauthenticeerd wordt.

Dus als Cambrium niets binnenkrijgt op de redbacks (ik neem aan dat rb600 staat voor een redback SE600 en rb1200 voor een redback SE1200, redback is alweer enige tijd geleden overgenomen door Ericsson) zou het ook daar al veroorzaakt kunnen worden. Al zou je dan wel verwachten dat het zich beperkt tot een specifiek access netwerk.

Ha, deze nuttige info verklaart dus wel waarom ik aanvankelijk vorige week woensdag een authentication failure kreeg, toen de PPPoE IA op mijn switchpoort in de area-PoP nog niet aan was gezet.

[raymonvdm]

Verwijderd schreef op zondag 25 oktober 2020 @ 10:31:
Ik heb zojuist opnieuw een WAN-reconnect geprobeerd. Hetzelfde verhaal als gisteren: twee authenticatiepogingen falen, de derde slaagt. Binnen 10 seconden was de PPPoE-tunnel weer up.

Dus ik zie absoluut verbetering ten opzichte van donderdag en daarvoor. Dus hopelijk heeft Cambrium wat veranderd.

Als het goed is wel, maar voor mij leek het niet direct verschil te maken, maar dat zegt natuurlijk niets over alle andere gebruikers

[Verwijderd]

raymonvdm schreef op maandag 26 oktober 2020 @ 10:31:
[...]


Als het goed is wel, maar voor mij leek het niet direct verschil te maken, maar dat zegt natuurlijk niets over alle andere gebruikers

Ik heb het zojuist opnieuw getest, en het ging weer redelijk goed. Eerst 3x CHAP authentication failure, maar de 4e keer CHAP authentication success. Ik heb geen Timeout waiting for PADO packets meer gehad, en binnen 11 seconden was de verbinding weer terug.

Heb jij nog steeds minutenlange downtime?

[raymonvdm]

Ik heb inderdaad nog moment waarop het lang duurt voordat hij online komt. En soms is het PPP interface disable en enable en connected

[Chrizzolicious]

Sinds vandaag de overstap van XS4ALL (met een gevoel van enige weemoed, was al met de Demon Internet inboedel naar XS gegaan nl.) naar Freedom Internet en die overgang is volledig geruisloos gegaan. Tot op heden nog geen downtimes gehad; ik heb zelf de Fr!tz Box 7590.

Wat ik me nog wel afvraag is hoe ik 't domeintje als volg inricht:
- Mail via PGP-client van Freedom (en te allen tijde encrypted mailen)
- Voor webruimte koppelen aan mijn package bij Vimexx: duidelijk is hoe ik eea op het Freedom dashboard moet regelen, hoe ik eea in Direct Admin van Vimexx moet fixen is me een raadsel...

[.oisyn]

Chrizzolicious schreef op maandag 26 oktober 2020 @ 15:24:
- Voor webruimte koppelen aan mijn package bij Vimexx: duidelijk is hoe ik eea op het Freedom dashboard moet regelen, hoe ik eea in Direct Admin van Vimexx moet fixen is me een raadsel...

Wat moet er gefixed worden, dan? Had je al een domein, die je nu verhuist? Dan niets. Is het een nieuw domein? Dan moet je even een domein toevoegen bij de domain administration in DA.

[DiedX]

@.oisyn , had jij nou jouw USG draaiend gekregen met Freedom, IPTV, IPv6 en alles?

[.oisyn]

DiedX schreef op maandag 26 oktober 2020 @ 16:24:
@.oisyn , had jij nou jouw USG draaiend gekregen met Freedom, IPTV, IPv6 en alles?

Ik heb een ER-4, maar ik heb me laten vertellen dat dat vergelijkbaar is.

[DiedX]

.oisyn schreef op maandag 26 oktober 2020 @ 16:25:
[...]

Ik heb een ER-4, maar ik heb me laten vertellen dat dat vergelijkbaar is.

En die had je wel volledig enabled qua Freedom?

[.oisyn]

Jazeker. Al kijk ik nog steeds geen Begin Gemist want dat hapert om de 20 seconde oid. Echt *super* irritant. Het is dat ik het nu even ontzettend druk heb met de verkoop van mijn huis, maar daarna wil ik daar echt even werk van gaan maken.

Maar dat ligt niet aan mijn ER-4, met de geleende Fritzbox van Freedom had ik exact hetzelfde probleem.

[Chrizzolicious]

Ha!

Domeintje staat geregistreerd bij Freedom Internet, bij Vimexx heb ik een package met meerdere domeinen.
Moet ik in DA enkel domein toevoegen of ook nog DNS-instellingen aanpassen (dat is dus waar het bij mij vaak fout gaat)?

[.oisyn]

Chrizzolicious schreef op maandag 26 oktober 2020 @ 17:31:
Ha!

Domeintje staat geregistreerd bij Freedom Internet, bij Vimexx heb ik een package met meerdere domeinen.
Moet ik in DA enkel domein toevoegen of ook nog DNS-instellingen aanpassen (dat is dus waar het bij mij vaak fout gaat)?

Je moet zorgen dat het gewenste domein in je DA staat, en bij je domeininstellingen moet je een A-record hebben die naar de Vimexx server wijst, dat is alles.

[Chrizzolicious]

Ah zo zit dat.
Hartstikke bedankt ga ik dat es effe proberen :-)

[Out.of.Control]

Verwijderd schreef op zaterdag 24 oktober 2020 @ 22:59:
[...]


Ok, en met een herstart bedoel je pppd stoppen, even wachten, en dan pppd weer starten?

Ik bedoelde het hele systeem opnieuw opstarten. Dan weet ik ook zeker dat alle daemons weer in de goede volgorde gestart worden.

Overigens heb ik zojuist de router even opnieuw gestart en ik krijg direct weer een nieuwe PPPoE verbinding. Tot voor kort zou dit niet hebben gewerkt, hoop dat het zo blijft ;-)

[Verwijderd]

Out.of.Control schreef op maandag 26 oktober 2020 @ 23:25:
[...]
Overigens heb ik zojuist de router even opnieuw gestart en ik krijg direct weer een nieuwe PPPoE verbinding. Tot voor kort zou dit niet hebben gewerkt, hoop dat het zo blijft ;-)

Ja, ik zie ook absoluut vooruitgang sinds vorige week. Ik heb de afgelopen drie dagen elke dag de verbinding een keer handmatig verbroken, en steeds kwam hij binnen een seconde of 10 weer terug.

Dat had tot voor kort bij mij inderdaad ook niet gewerkt.

[tlpeter]

Hoe is het nu met de TV ontvangers bij Freedom? Is dat en beetje op orde?
Ik begin het bij XS4all een beetje zat te worden. Ik heb de overstap nog niet durven maken maar ik heb nu elke dag problemen sinds er nieuwe software is ontwikkelt voor de tv ontvangers. Voor het premium bedrag dat ik elke maand betaal verwacht ik dat het gewoon werkt en dat is zeker niet het geval.

[Verwijderd]

tlpeter schreef op dinsdag 27 oktober 2020 @ 06:19:
Hoe is het nu met de TV ontvangers bij Freedom? Is dat en beetje op orde?
Ik begin het bij XS4all een beetje zat te worden. Ik heb de overstap nog niet durven maken maar ik heb nu elke dag problemen sinds er nieuwe software is ontwikkelt voor de tv ontvangers. Voor het premium bedrag dat ik elke maand betaal verwacht ik dat het gewoon werkt en dat is zeker niet het geval.

Ik heb/wil geen TV-ontvangers, maar ik heb een los Canal Digitaal-streamingabonnement. "Bomvol" noemen ze dat. Ik gebruik een HTPC met Ubuntu en Firefox om TV te kijken, en ik moet zeggen dat ik dat een prima dienst vind. In vergelijking met de streamingdiensten die ik eerder heb gebruikt (Ziggo Go en NLZIET) vind ik het absoluut de beste van de drie.

Het enige jammere is dat Freedom zelf geen web-only-dienst aanbiedt, maar alleen die mediaboxen. Ik moest dus buiten Freedom om een los abonnement bij Canal Digitaal afsluiten.

We kijken hier niet heel veel TV, maar de keren dat we dat deden, werkte het zonder problemen.

[TR1969]

Verwijderd schreef op dinsdag 27 oktober 2020 @ 08:58:
[...]


Ik heb/wil geen TV-ontvangers, maar ik heb een los Canal Digitaal-streamingabonnement. "Bomvol" noemen ze dat. Ik gebruik een HTPC met Ubuntu en Firefox om TV te kijken, en ik moet zeggen dat ik dat een prima dienst vind. In vergelijking met de streamingdiensten die ik eerder heb gebruikt (Ziggo Go en NLZIET) vind ik het absoluut de beste van de drie.

Het enige jammere is dat Freedom zelf geen web-only-dienst aanbiedt, maar alleen die mediaboxen. Ik moest dus buiten Freedom om een los abonnement bij Canal Digitaal afsluiten.

We kijken hier niet heel veel TV, maar de keren dat we dat deden, werkte het zonder problemen.

Ik ben de streaming dienst nu ook aan het testen en dat werkt op mijn tv (Philips) prima,
Er zijn alleen 2 zaken waar je je van bewust moet zijn.
Als eerste (is al eerder genoemd) geen Discovery en Eurosport.
En als tweede is het niet mogelijk om het Bomvol pakket aan te vullen met Ziggo sport. (Bv voor F1)

Zelf twijfel ik ook nog of ik de overstap zal doen of dat het misschien verstandig is nog een jaar te wachten.
In deze tijd van thuiswerken en een studerende zoon thuis (ook alles het hele jaar al online) is een stabiel en betrouwbaar internet noodzaak.

[Verwijderd]

TR1969 schreef op dinsdag 27 oktober 2020 @ 11:36:
Er zijn alleen 2 zaken waar je je van bewust moet zijn.
Als eerste (is al eerder genoemd) geen Discovery en Eurosport.
En als tweede is het niet mogelijk om het Bomvol pakket aan te vullen met Ziggo sport. (Bv voor F1)

Dat los ik als volgt op:

https://www.dplay.nl/

https://f1tv.formula1.com/nl/

[TR1969]

Verwijderd schreef op dinsdag 27 oktober 2020 @ 11:46:
[...]


Dat los ik als volgt op:

https://www.dplay.nl/

https://f1tv.formula1.com/nl/

Dplay had ik niet aangedacht maar dat is wel een goed alternatief (en ook nog wel betaalbaar)
F1tv lost idd wel de F1 op (en geen Olav Mol) maar het buitenlandse voetbal heb je dan niet. Dat is dan even de keuze die je doet.

[HoleinOne]

Ik heb 2 ontvangers van Canal Digitaal via Freedom. Werkt prima. Alleen de programmagids is wat minder nauwkeurig dan die van KPN.
Ik heb geen voetbal maar wel F1 en golf etc. Dus Ziggo Sport.

Het is even wennen met de AB. Die is ergonomisch wat minder dan die van de KPN/XS..

Beeldkwaliteit is prima. De bandbreedte is wat meer dan bij het invullen platform van KPN.
Ik zie de stream op 20Mbs kopen. Bij KPN is het ongeveer 14. Dit voor wat het waard is.

Ik heb de logitech remote 650 in gebruik genomen icm met de Yamaha versterker en de andere apparaten die er nog staan, en dan is het probleem van de AB gelijk opgelost. Alle knoppen zijn over te zetten van de originele AB. Bij de meegeleverde AB moet je de knop vrij kort indrukken, anders gebeurt er niets. Ik zou het niet aanbevelen voor ouderen onder ons omdat die wat trager zijn. Of een Logisch remote gebruiken. Dat gaat dan wel goed.

[Ryen]

Na 25 jaar klant geweest te zijn bij xs4all wordt het tijd om uit elkaar te gaan en over te stappen naar Freedom. In dit topic kom ik vooral problemen en 'uitdagingen' tegen. Dat is natuurlijk ook niet zo gek. Ik ben echter benieuwd naar de 'gemiddelde' ervaring bij het overstappen. Hoe lang is de downtime? Kunnen jullie daar iets over vertellen?

Wat meer info:
We hebben glasvezel (via KPN netwerk) en we willen (weer) een 500/500 verbinding. Geen telefoon of TV.

Er hangt al een werkende glasvezel NTU (Genexys) in de meterkast. Hebben we dan nog een monteur nodig? We zijn redelijk handig met netwerk-apparatuur.

[Zr40]

Ryen schreef op dinsdag 27 oktober 2020 @ 17:15:
Na 25 jaar klant geweest te zijn bij xs4all wordt het tijd om uit elkaar te gaan en over te stappen naar Freedom. In dit topic kom ik vooral problemen en 'uitdagingen' tegen. Dat is natuurlijk ook niet zo gek. Ik ben echter benieuwd naar de 'gemiddelde' ervaring bij het overstappen. Hoe lang is de downtime? Kunnen jullie daar iets over vertellen?

Als je in dit topic even zoekt op de term 'downtime', kom je zo ervaringen tegen

Hier was het een seconde of 15, 's nachts. Bij wijze van spreken de tijd om mijn glasvezel fysiek in een andere poort te prikken. Instellingen zijn identiek aan die van XS4ALL.

Er hangt al een werkende glasvezel NTU (Genexys) in de meterkast. Hebben we dan nog een monteur nodig? We zijn redelijk handig met netwerk-apparatuur.

Nee, dat is dan niet nodig. Als de NT nog geplaatst moet worden dan is het officieel wel nodig, maar dat is eigenlijk nog eenvoudiger dan het aansluiten van DSL. Vastklikken en het is klaar

[ Voor 8% gewijzigd door Zr40 op 27-10-2020 17:29 ]

[Sakura_nl]

TR1969 schreef op dinsdag 27 oktober 2020 @ 11:36:
[...]
Zelf twijfel ik ook nog of ik de overstap zal doen of dat het misschien verstandig is nog een jaar te wachten.
In deze tijd van thuiswerken en een studerende zoon thuis (ook alles het hele jaar al online) is een stabiel en betrouwbaar internet noodzaak.

Internet is zo stabiel als een huis, dus die overstap kan je rustig maken. Ik heb hier ook een thuiswerkende in huis, absoluut zonder problemen.

Downtime is er niet.

Je kan zelfs simpelweg de xs4all Fritzbox vervangen door de fritzbox die je van Freedom krijgt zodra die binnen is. Je blijft dan gewoon internet verbinding houden bij xs4all.
En op het moment dat Freedom de verbinding overneemt draait het gewoon verder, maar dan op het Freedom netwerk.
Wel aan te raden even in te loggen op de Fritzbox, en de firmware updaten nadat Freedom de verbinding over genomen heeft.

[ Voor 7% gewijzigd door Sakura_nl op 27-10-2020 20:47 ]

[TR1969]

Sakura_nl schreef op dinsdag 27 oktober 2020 @ 20:45:
[...]


Internet is zo stabiel als een huis, dus die overstap kan je rustig maken. Ik heb hier ook een thuiswerkende in huis, absoluut zonder problemen.

Downtime is er niet.

Je kan zelfs simpelweg de xs4all Fritzbox vervangen door de fritzbox die je van Freedom krijgt zodra die binnen is. Je blijft dan gewoon internet verbinding houden bij xs4all.
En op het moment dat Freedom de verbinding overneemt draait het gewoon verder, maar dan op het Freedom netwerk.
Wel aan te raden even in te loggen op de Fritzbox, en de firmware updaten nadat Freedom de verbinding over genomen heeft.

Voor mij zou de overstap zijn tussen Ziggo (die hier een soort monopoly hebben in de kop van Noord Holland) en Freedom. het is vooral het gedachtengoed dat mij aanspreekt.
Ik ben verder geen it-er of computerexpert maar heb een redelijk goede basiskennis dacht ik (tot ik alle protocollen en technische issues hierboven voorbij zag komen ).
Vandaar mijn aarzeling..

[mr.babek]

tlpeter schreef op dinsdag 27 oktober 2020 @ 06:19:
Hoe is het nu met de TV ontvangers bij Freedom? Is dat en beetje op orde?
Ik begin het bij XS4all een beetje zat te worden. Ik heb de overstap nog niet durven maken maar ik heb nu elke dag problemen sinds er nieuwe software is ontwikkelt voor de tv ontvangers. Voor het premium bedrag dat ik elke maand betaal verwacht ik dat het gewoon werkt en dat is zeker niet het geval.

Nou als je van xs4all komt is de TV functionaliteit echt om te JANKEN. ik weet nu wat ik mis.Dat was redelijk pijnlijk. Zeker omdat mijn vrouw veel tv kijkt en wil opnemen.
Vooral opnemen en terug kijken is erom gelimiteerd tov KPN/XS4ALL.

Verder is de snelheid van de 1Gb lijn nogal slecht, maar dat is een KPN probleem (helaas geen ander aanbieders met Gb in mijn gebied)
De helpdesk is top. paar keer contact mee gehad.
En natuurlijk het gedachtegoed van freedom en de extraatjes zoals een echt vast ip maken dat ik toch blij ben de overstap te hebben gemaakt.

[Verwijderd]

TR1969 schreef op dinsdag 27 oktober 2020 @ 20:54:
[...]


Voor mij zou de overstap zijn tussen Ziggo (die hier een soort monopoly hebben in de kop van Noord Holland) en Freedom. het is vooral het gedachtengoed dat mij aanspreekt.
Ik ben verder geen it-er of computerexpert maar heb een redelijk goede basiskennis dacht ik (tot ik alle protocollen en technische issues hierboven voorbij zag komen ).
Vandaar mijn aarzeling..

Het PPPoE-probleem lijkt grotendeels opgelost. Ik heb er in ieder geval geen last meer van. Verder was het niet dusdanig ernstig dat de verbinding erdoor onbruikbaar was, alleen het opnieuw starten van een verbinding duurde soms wat lang.

Wat TV betreft; ik heb geen klachten, maar ik heb ook geen decoder. Ik kijk alleen online en dat gaat goed. Opnemen doe ik nooit. Als je TV echt belangrijk vindt, kan je waarschijnlijk beter bij Ziggo een Kabel TV-abonnement nemen en bij Freedom alleen internet. Zo heb ik dat bij m'n grootouders ook geregeld bijvoorbeeld.

[Sakura_nl]

Ik heb wel de TV settop box, en is echt prima, absoluut niets mis mee. Uiteraard is het anders dan je gewend bent en is Freedom nog vol in onderhandeling met Canal Digitaal voor extra functionaliteit.
Maar er is in ieder geval niet meerdere keren per avond een storing zoals inmiddels bij xs4all het gaval is.

TV is dus simpelweg anders, maar inmiddels veel beter dan bij xs4all wat ook echt alleen maar slechter en slechter gaat worden dankzij kpn

[Basje]

Ryen schreef op dinsdag 27 oktober 2020 @ 17:15:
Ik ben echter benieuwd naar de 'gemiddelde' ervaring bij het overstappen. Hoe lang is de downtime? Kunnen jullie daar iets over vertellen?

Wij zijn sinds het begin van de maand over en hier heb ik nog geen downtime ervaren. We monitoren niet, maar met twee thuiswerkende personen heb je snel genoeg door of er iets hapert. Het Ziggo-modem hangt al weken ongebruikt in de meterkast als back-up, maar het is bijna 1 november en dan gaat het modem terug. Wij gaan Ziggo niet missen.

Eén punt dat me wel opviel was gisteravond. We wilden NPO1 livestreamen (19:00 uur) via NPO Start en die stream wilde niet werken. Niet via de Shield TV en niet via de NPO-app op mijn Android-telefoon (over wifi). Internet werkte gewoon. Toen ik op mijn telefoon overschakelde naar 4G deed de livestream het wel. Iemand anders dat ook gemerkt? Wat zou de reden kunnen zijn voor zo'n specifieke hapering, en belangrijker, wat zou ik kunnen doen om dat op te lossen?

[goosse]

Ik heb sinds 07:19 geen internet verbinding meer in regio Amersfoort. Zijn er meer mensen met dit probleem?

Ik heb het gemeld bij Freedom maar nog geen reactie buiten de standaard melding dat er een ticket is aangemaakt.

Overigens merk ik nu hoe afhankelijk ik ben met mijn thuiswerken en studerende kinderen....

[Out.of.Control]

Hier geen probleem, ook regio Amersfoort.

[goosse]

Heeft tot uur of 09:00 geduurd maar inmiddels werkt het weer.

[dennistd]

Ik word vandaag overgezet van KPN (ex-Telfort) glas naar Freedom. Volgens de mail had dit tussen 0.00u en 6.00u moeten gebeuren maar ik zit nog steeds op de oude verbinding. Iets om me zorgen over te maken of vindt de overstap wel vaker pas later op de dag plaats?

Update: vanmiddag gebeld met Freedom en een uurtje later was de verbinding over
Overigens nu een Gigabit-verbinding (GoF) met de PoP, voorheen was het een EoF. Voor de snelheid is het niet nodig (100mbit) lijkt me. Maar mogelijk dat het hierdoor pas later overgezet werd?

[ Voor 35% gewijzigd door dennistd op 29-10-2020 02:16 ]

[Verwijderd]

Ik heb zojuist nog eens m'n WAN-interface herstart, en de PPPoE-sessie was binnen 11 seconden weer terug. Dus de fix die Cambrium afgelopen vrijdag (?) heeft gemaakt lijkt toch aardig goed te werken als ik het zo zie. De laatste vijf pogingen verspreid over vijf dagen gingen allemaal goed. (Lees: geen minutenlange downtime, maar slechts luttele seconden.)

Ik zie alleen nog dat de eerste twee of drie CHAP-authenticatiepogingen mis gaan, dus daar moet nog naar gekeken worden. Als dat is opgelost zou de verbinding zelfs binnen een seconde of 4 terug moeten kunnen komen, in plaats van 11. (Hiervoor kon het tot 5 minuten duren, dus het is echt een stuk beter nu.)

Ik heb ondertussen contact gehad met Jesse van Freedom, en hij geeft aan dat Freedom ook weet wat er aan de hand is, en met Cambrium in overleg is om het definitief op te lossen.

@raymonvdm Hoe staat het er bij jou voor?

[ Voor 3% gewijzigd door Verwijderd op 28-10-2020 21:10 ]

[EnigmA-X]

raymonvdm schreef op vrijdag 16 oktober 2020 @ 23:53:
[...]


Ik vermoed dat je dan een internet probleem hebt met je Amino. Live is namelijk multicast en zodra je op pauze en play drukt wordt het OTT (Unicast) en loopt het verkeer anders.

Wat voor router gebruik je, en op welke manier is deze geconfigureerd?

Ik ben er inmiddels achter dat het video-on-demand (VOD) van CanalDigitaal voor Begin gemist en pauzeren werkt middels RTSP.

Hierover staat een kleine hint op de TV instellingen pagina van Freedom:

RTSP connection tracking module moet ingeschakeld worden mits beschikbaar. Bij een enkele TV ontvanger kan er ook een Destination NAT regel worden ingesteld.

Mikrotik ondersteunt geen RTSP connection tracking (heeft geen helper). DNAT werkt alleen bij een enkele STB, omdat je een complete range aan poorten maar kan DNAT'en naar 1 enkel IP in het netwerk. Ik heb twee STB's.

Ondertussen begin ik echt wel een beetje klaar te raken met het hele CanalDigitaal gedoe. De rest van Freedom zit redelijk goed tot uitstekend in elkaar, echter, brakkige TV zorgt voor commentaar van mijn "achterban".

Ik ga toch maar eens vragen of ik nog van mijn iptv af kan, die STB's kunnen wat mij betreft linea recta terug naar Freedom.

[raymonvdm]

Ik denk dat je dit probleem bij andere providers ook zal hebben, volgens mij doen ze namelijk allemaal uitzending gemist / uitgesteld kijken via RTSP (unicast)

In dat geval zou ik dus eerder m`n geld op Mikrotik zetten en misschien RouterOS v7

[ Voor 21% gewijzigd door raymonvdm op 29-10-2020 10:21 ]

[ik222]

raymonvdm schreef op donderdag 29 oktober 2020 @ 10:20:
Ik denk dat je dit probleem bij andere providers ook zal hebben, volgens mij doen ze namelijk allemaal uitzending gemist / uitgesteld kijken via RTSP (unicast)

In dat geval zou ik dus eerder m`n geld op Mikrotik zetten en misschien RouterOS v7

Dat is wel interessant, bij KPN werkt dat allemaal namelijk wel gewoon op Mikrotik routers. En ja die gebruiken ook RTSP.

Net dus eens even ingedoken en het blijkt dat KPN STUN gebruikt daarvoor. De KPN settopboxen doen dus als je een unicast stream start een STUN request naar dezelfde server waar daarna de stream vandaan komt. Krijgen dan dus terug hoe de server hen ziet (dus met het adres + source poort van de ITV WAN poort van mijn router erin) en sturen daarna een nieuwe RTSP SETUP message met daarin dus dat adres + poortnummer. Hierdoor werken daar de RTSP streams dus zonder dat er een helper voor RTSP actief is.

Screenshot waarin je het kunt zien, onderin de details van de 2 belangrijkste pakketjes.



Conclusie die hieruit dat dus volgt is dat Freedom / Canal Digitaal geen STUN gebruikt blijkbaar voor de RTSP streams. En dan heb je dus inderdaad een helper nodig in je NAT router.

[ Voor 6% gewijzigd door ik222 op 29-10-2020 11:02 ]

[.oisyn]

EnigmA-X schreef op woensdag 28 oktober 2020 @ 22:01:
Ondertussen begin ik echt wel een beetje klaar te raken met het hele CanalDigitaal gedoe. De rest van Freedom zit redelijk goed tot uitstekend in elkaar, echter, brakkige TV zorgt voor commentaar van mijn "achterban".

Ja hier ook. Ik heb het overigens wel "werkend", alleen is Begin Gemist gewoon onkijkbaar door de zeer regelmatige hapering steeds. Eerst valt het geluid weg maar gaat het beeld door, dan komt het geluid weer terug maar staat het beeld even stil. Gesprekken tussen mensen zijn daarmee echt niet te volgen.

Voorbeeld. Je ziet het rond 0:03 en 0:50.

Als we nu iets uitgesteld willen kijken dan wachten we of tot het afgelopen is, of we slingeren Ziggo maar weer aan.

[ Voor 26% gewijzigd door .oisyn op 29-10-2020 12:36 ]

[raymonvdm]

.oisyn schreef op donderdag 29 oktober 2020 @ 12:20:
[...]

Ja hier ook. Ik heb het overigens wel "werkend", alleen is Begin Gemist gewoon onkijkbaar door de zeer regelmatige hapering steeds. Eerst valt het geluid weg maar gaat het beeld door, dan komt het geluid weer terug maar staat het beeld even stil. Gesprekken tussen mensen zijn daarmee echt niet te volgen.

Voorbeeld. Je ziet het rond 0:03 en 0:50.

Als we nu iets uitgesteld willen kijken dan wachten we of tot het afgelopen is, of we slingeren Ziggo maar weer aan.

Bij multicast zou ik in dit geval heel veel CRC errors en blokjes verwachten, het lijkt er nu op dat je verkeer gewoon even doodloopt en daarna weer verder gaat, waardoor je dus stukjes mist.

Ik weet niet of je fiber of vdsl hebt, maar je heb niet stieken CRC errors ergens? (of een bridge die verkeer laat vallen, dit had ik met live TV op een Cisco 887VA, iOS upgrade was de fix)

[.oisyn]

raymonvdm schreef op donderdag 29 oktober 2020 @ 12:42:
[...]


Bij multicast zou ik in dit geval heel veel CRC errors en blokjes verwachten, het lijkt er nu op dat je verkeer gewoon even doodloopt en daarna weer verder gaat, waardoor je dus stukjes mist.

Het is geen multicast, dit is Begin Gemist over RTSP. TV Gemist (een ander protocol) en live TV kijken (multicast) gaan wel goed.

[MetalfanBlackness]

ik222 schreef op donderdag 29 oktober 2020 @ 11:01:
[...]

Conclusie die hieruit dat dus volgt is dat Freedom / Canal Digitaal geen STUN gebruikt blijkbaar voor de RTSP streams. En dan heb je dus inderdaad een helper nodig in je NAT router.

Misschien ook melden op de community, misschien kunnen ze hier iets mee doen? https://community.freedom.nl/

Misschien niet op de korte termijn, maar ik hoop dat het helpt.

[raymonvdm]

.oisyn schreef op donderdag 29 oktober 2020 @ 12:46:
[...]

Het is geen multicast, dit is Begin Gemist over RTSP. TV Gemist (een ander protocol) en live TV kijken (multicast) gaan wel goed.

I know, maar heb je een RTSP helper, want die lijkt gewoon issues te hebben vermoed ik

[.oisyn]

raymonvdm schreef op donderdag 29 oktober 2020 @ 13:01:
[...]


I know, maar heb je een RTSP helper, want die lijkt gewoon issues te hebben vermoed ik

Ik snap niet helemaal wat je bedoelt met een "RTSP helper", maar ik heb dit probleem zowel bij mijn eigen ER-4 als de door Freedom geleverde FritzBox.

[ik222]

MetalfanBlackness schreef op donderdag 29 oktober 2020 @ 12:51:
[...]


Misschien ook melden op de community, misschien kunnen ze hier iets mee doen? https://community.freedom.nl/

Misschien niet op de korte termijn, maar ik hoop dat het helpt.

Daar kan ik volgens mij niet op, ben (nog) geen Freedom klant. Voorlopig nog XS4ALL maar ik volg dit topic al met veel interesse omdat als Canal Digitaal TV ooit volwassen wordt ik zeker overweeg over te stappen, vooral als KPN echt de volledige techniek van XS4ALL te integreren waardoor bijvoorbeeld reverse DNS en een echt vast IP komen te vervallen.

[raymonvdm]

.oisyn schreef op donderdag 29 oktober 2020 @ 13:04:
[...]

Ik snap niet helemaal wat je bedoelt met een "RTSP helper", maar ik heb dit probleem zowel bij mijn eigen ER-4 als de door Freedom geleverde FritzBox.

En als je de Fritzbox aansluit met alleen de TV ontvanger dan heb je het probleem ook? Dan moet het toch iets bekabelings technisch zijn. Gekke problemen heb ik wel gezien met CCA kabel

[.oisyn]

raymonvdm schreef op donderdag 29 oktober 2020 @ 14:24:
[...]


En als je de Fritzbox aansluit met alleen de TV ontvanger dan heb je het probleem ook? Dan moet het toch iets bekabelings technisch zijn. Gekke problemen heb ik wel gezien met CCA kabel

Nou ik heb dus het afgelopen uur even wat setups geprobeerd (en wat ontzettend irritant dat je de STB moet rebooten als hij op een ander netwerk wordt gehangen ).

STB -> Router: werkt prima
STB -> Switch meterkast -> Router: werkt prima
STB -> Switch TV kast -> Switch meterkast -> Router: werkt niet lekker.

Voor de zekerheid ook even getest met een nieuwe kabel tussen de twee switches, maar dat verandert niets. Ook even alle andere devices uit de switch in de TV kast getrokken, maar dat verandert ook niets.

Die switch in de TV kast is dus hoogstwaarschijnlijk gaar

Het gekke is dat ik dit probleem eerder al had afgedaan als niet mogelijk, omdat ik het probleem ook had met een directe lijn naar een FritzBox destijds, en al het andere verkeer in principe prima werkt. Ook low-latency zaken zoals het streamen van mijn Xbox naar mijn laptop over wifi, wat over dezelfde apparatuur en kabels loopt . En het ligt ook niet aan die specifieke poort op de switch, dat had ik ook al eens omgeprikt.

[ Voor 3% gewijzigd door .oisyn op 29-10-2020 14:34 ]

[raymonvdm]

.oisyn schreef op donderdag 29 oktober 2020 @ 14:33:
[...]


Nou ik heb dus het afgelopen uur even wat setups geprobeerd (en wat ontzettend irritant dat je de STB moet rebooten als hij op een ander netwerk wordt gehangen ).

STB -> Router: werkt prima
STB -> Switch meterkast -> Router: werkt prima
STB -> Switch TV kast -> Switch meterkast -> Router: werkt niet lekker.

Voor de zekerheid ook even getest met een nieuwe kabel tussen de twee switches, maar dat verandert niets. Ook even alle andere devices uit de switch in de TV kast getrokken, maar dat verandert ook niets.

Die switch in de TV kast is dus hoogstwaarschijnlijk gaar

Het gekke is dat ik dit probleem eerder al had afgedaan als niet mogelijk, omdat ik het probleem ook had met een directe lijn naar een FritzBox destijds, en al het andere verkeer in principe prima werkt. Ook low-latency zaken zoals het streamen van mijn Xbox naar mijn laptop over wifi, wat over dezelfde apparatuur en kabels loopt . En het ligt ook niet aan die specifieke poort op de switch, dat had ik ook al eens omgeprikt.

TP-Link?

[.oisyn]

Netgear.

[raymonvdm]

De https://www.netgear.nl/support/product/GS105Ev2 zouden goed moeten werken, ik weet niet welk type je precies hebt. Maar als ze IGMP snooping doen dan moet dat goed gaan.

Want van live TV naar uitgesteld kijken wil een Multicast sessie nog wel eens blijven staan, als je dan geen IGMP snooping hebt op je switch dan kan je netwerk daar best wel last van hebben zelfs als je STB direct aan je FB hangt

En zoiezo heb ik regelmatig allerlei gekke problemen gezien met slechte bekabeling en "cheap switches"

[.oisyn]

Het betreft hier een unmanaged 8 poort 1Gb switch. Twee stuks. Ze zijn ook al best oud alweer, volgens mij heb deze ooit eens via iBood besteld .

Ik ga over een half jaar verhuizen, daar wil ik wel wat betere managed switches in hebben hangen. Ik zat toevallig al naar de PW te kijken

[GerkeP]

Ik had (ook al bij xs4all) ook regelmatig issues met TV.
Bleek aan mijn netgear swithes te liggen.
Heb nu alles met Ubiquiti switches uitgevoerd, alle issues waren toen ook weg.

Ik had 2 GS724T V3 managed gigabit switches van Netgear.

[Zr40]

Geen TV hier, maar wel een Netgear managed switch, een JGS524PE. Wat een onding is het. VLAN configuratie werkt helemaal niet meer in moderne browsers (behalve in Safari, gelukkig heb ik hier nog een mac liggen ), soms verschuiven VLAN assignments 1 poort naar links (zit je dan met een PVID op een poort die je niet kan wijzigen omdat de VLAN is verschoven naar de buurpoort) ... maar zolang ik er van af blijf blijft alles goed staan.

De fan maakt ook een enorme herrie sinds dag 1. Die heb ik losgekoppeld, switch is nog steeds niet oververhit geraakt, zelfs niet in de hete zomers.

Ergens hoop ik dat ie het een keer begeeft, zodat ik een fatsoenlijkere switch kan (moet) aanschaffen.

[.oisyn]

Beetje offtopic hier, maar ik heb nu deze aangeschaft: pricewatch: ZyXEL GS1200-8. (3x, waarvan 1x de PoE+ variant)

[ Voor 9% gewijzigd door .oisyn op 29-10-2020 17:13 ]

[EnigmA-X]

raymonvdm schreef op donderdag 29 oktober 2020 @ 10:20:
Ik denk dat je dit probleem bij andere providers ook zal hebben, volgens mij doen ze namelijk allemaal uitzending gemist / uitgesteld kijken via RTSP (unicast)

In dat geval zou ik dus eerder m`n geld op Mikrotik zetten en misschien RouterOS v7

Niet dus, zoals @ik222 hier beschrijft. Ik kom bij XS4ALL vandaan en daar werkte IPTV allemaal prima

Het punt is dat ik nog niet helemaal heb kunnen ontdekken of RouterOS v7 het nu wel of niet ondersteunt. Probleem is ook een beetje dat de halve wereld RSTP en RTSP door elkaar haalt. Ga maar eens zoeken op het mikrotik forum... best wel irritant.

Daarnaast, een werkende RTSP-setup helpt helaas nog steeds niet met de brakke UI/UX welke ook nog steeds op de nieuwe Amino van toepassing is.

Anyhow, ik kom waarschijnlijk niet van het tv pakket af en ik zal ook niet zomaar rusten. Ik gok dat het een makeshift nat-over-nat-oplossing wordt met https://github.com/maru-sama/rtsp-linux

[Freee!!]

.oisyn schreef op donderdag 29 oktober 2020 @ 14:33:
[...]
Nou ik heb dus het afgelopen uur even wat setups geprobeerd (en wat ontzettend irritant dat je de STB moet rebooten als hij op een ander netwerk wordt gehangen ).

STB -> Router: werkt prima
STB -> Switch meterkast -> Router: werkt prima
STB -> Switch TV kast -> Switch meterkast -> Router: werkt niet lekker.

Voor de zekerheid ook even getest met een nieuwe kabel tussen de twee switches, maar dat verandert niets. Ook even alle andere devices uit de switch in de TV kast getrokken, maar dat verandert ook niets.

Die switch in de TV kast is dus hoogstwaarschijnlijk gaar

Of twee switches ertussen is er één teveel, ik mis de optie: STB -> Switch TV kast -> Router

[.oisyn]

Freee!! schreef op donderdag 29 oktober 2020 @ 17:04:
[...]

Of twee switches ertussen is er één teveel, ik mis de optie: STB -> Switch TV kast -> Router

De ER-4 heeft geen interne switch.

[mr.babek]

.oisyn schreef op donderdag 29 oktober 2020 @ 14:51:
Het betreft hier een unmanaged 8 poort 1Gb switch. Twee stuks. Ze zijn ook al best oud alweer, volgens mij heb deze ooit eens via iBood besteld .

Ik ga over een half jaar verhuizen, daar wil ik wel wat betere managed switches in hebben hangen. Ik zat toevallig al naar de PW te kijken

Yup herkenbaar, netgear unmanaged + UTP in de TV was geen succes. Hele vreemde dingen. NIeuwere managed switch gekocht (ook van netgear) geen issues meer

[HoleinOne]

mr.babek schreef op donderdag 29 oktober 2020 @ 21:19:
[...]


Yup herkenbaar, netgear unmanaged + UTP in de TV was geen succes. Hele vreemde dingen. NIeuwere managed switch gekocht (ook van netgear) geen issues meer

Ik dacht dat het meer te maken heeft dat de switch IGMP snooping moet ondersteunen. En niet dat het een managed switch is. Correct me if I'm wrong. Ik heb er ervaring mee gehad dat de kleine tp link in het verleden ook daarom problemen gaf. Ik heb nu een 24 poort managed met IGMP ondersteuning switch van tp link in gebruik met Canal Digitaal en een Fritz Box 7490. De TV STB ontvangers functioneren met deze configuratie prima. Zowel met begin gemist en opnames werkt het technisch prima.
Grote kritiekpunt van mijn vrouw betreft vooral de niet accurate programmagids waardoor de verkeerde titels en aanvangstijden. Voorbeeld is de vermelding van National Geografic Wild. Er staat Dr. Pol. Maar je kijkt naar een programma over de dieren in Afrika.

[.oisyn]

Ik volg het niet helemaal. Het enige wat een unmanaged L2 switch doet is toch gewoon de multicast broadcasten ipv alleen sturen naar de apparaten die erom vragen? Minder efficient voor je netwerk natuurlijk, maar ook geen enorm probleem in menig thuisnetwerk.

En in dit geval betreft het dus niet eens multicastverkeer.

[mr.babek]

HoleinOne schreef op donderdag 29 oktober 2020 @ 23:02:
[...]

Ik dacht dat het meer te maken heeft dat de switch IGMP snooping moet ondersteunen. En niet dat het een managed switch is. Correct me if I'm wrong. Ik heb er ervaring mee gehad dat de kleine tp link in het verleden ook daarom problemen gaf. Ik heb nu een 24 poort managed met IGMP ondersteuning switch van tp link in gebruik met Canal Digitaal en een Fritz Box 7490. De TV STB ontvangers functioneren met deze configuratie prima. Zowel met begin gemist en opnames werkt het technisch prima.
Grote kritiekpunt van mijn vrouw betreft vooral de niet accurate programmagids waardoor de verkeerde titels en aanvangstijden. Voorbeeld is de vermelding van National Geografic Wild. Er staat Dr. Pol. Maar je kijkt naar een programma over de dieren in Afrika.

Ik bedoelde er mee te zeggen dat mijn oude unmanaged switch "te dom" was en er daardoor problemen ontstonden.

[MetalfanBlackness]

.oisyn schreef op donderdag 29 oktober 2020 @ 23:46:
Ik volg het niet helemaal. Het enige wat een unmanaged L2 switch doet is toch gewoon de multicast broadcasten ipv alleen sturen naar de apparaten die erom vragen? Minder efficient voor je netwerk natuurlijk, maar ook geen enorm probleem in menig thuisnetwerk.

En in dit geval betreft het dus niet eens multicastverkeer.

Ik dacht dat dit alleen bij de (oude) hubs was dat ze verkeer naar te veel poorten stuurde, maar ik zie inderdaad dat het zo ook nog werkt bij sommige switches.

[ Voor 3% gewijzigd door MetalfanBlackness op 30-10-2020 08:41 ]

[ik222]

Een hub stuurt altijd al het verkeer door naar alle poorten, een switch houdt een MAC adres tabel bij en stuurt zo unicast verkeer alleen naar de daarvoor bestemde poort. Echter broadcast en multicast verkeer stuurt een switch in beginsel nog altijd naar alle poorten (hoe zou hij anders bijvoorbeeld een MAC tabel kunnen opbouwen?).

IGMP snooping zorgt ervoor dat multicast verkeer niet meer naar alle poorten gaat maar enkel naar de poorten die via IGMP hebben aangeven verkeer voor een bepaalde multicast groep te willen ontvangen. Om dit te bepalen leest de switch dus inhoudelijk de IGMP berichten die erover gaan (vandaar de naam IGMP snooping).

IGMP snooping wil je in een thuisnetwerk met IPTV zeker wel hebben zolang je IPTV apparaten en je andere apparatuur in hetzelfde VLAN staan. Multicast verkeer is namelijk funest voor je WiFi en je krijgt bijvoorbeeld anders ook rare dingen als een Playstation in standby zijn netwerkkaart naar 10Mbit schakelt... Als je switch geen IGMP snooping ondersteunt of dat niet goed werkt is een alternatief om de IPTV settopboxen in een eigen VLAN te zetten, als je dat doet zorgt het VLAN er al voor dat het multicast verkeer enkel naar alle poorten in dat VLAN gaat, dan krijgen dus wel al je STB's altijd alle streams binnen maar dat maakt thuis over het algemeen niet uit (je trekt thuis toch over het algemeen geen 100Mbit aan multicast streams). Uiteraard moet je dan dus wel ook een router met VLAN ondersteuning hebben.

Maar goed hoe dan ook heeft IGMP snooping wel of niet helemaal niets te maken met begin gemist of het terugkijken van opnames. Dat zijn namelijk unicast RTSP streams. Vervelende van RTSP is dat het net als bijvoorbeeld SIP een signalling protocol is wat uiteindelijk tot UDP streams voor de daadwerkelijk content leidt. In de RTSP berichten geven de apparaten dus weer op welk adres en welke poort ze die UDP stream uiteindelijk willen ontvangen, echter gaat dat dus fout achter NAT in de basis. Om daar omheen te komen moet ofwel je router een RTSP helper hebben (dat is dus een stukje software die het IP en de poort in RTSP berichten actief aanpast als een bericht de IPTV WAN poort uitgaat). Of het alternatief is dus dat het platform STUN gebruikt waarmee de settopbox zelf kan bepalen hoe de server hem ziet en daar zelf zijn RTSP berichten op kan aanpassen.

KPN gebruikt dus STUN en Canal Digitaal niet als ik de verhalen hier lees. De meeste routers hebben echter een RTSP helper waardoor dat verder geen probleem is, echter Mikrotik heeft zo'n helper ook voor zover ik weet nog altijd niet waardoor die routers dus niet werken met Canal Digitaal wat geen STUN gebruikt.

[.oisyn]

ik222 schreef op vrijdag 30 oktober 2020 @ 09:01:
Multicast verkeer is namelijk funest voor je WiFi

En BAM het kwartje valt. Mijn wifi is boven echt drama, en dat is begonnen rond de tijd dat ik de STB heb aangesloten. Wat stom zeg, hier heb ik dus echt nooit bij stilgestaan.

Vanavond krijg ik de managed switched binnen, ben benieuwd...

.edit: hmm al klopt dit niet helemaal, het is ook bagger op momenten dat de STB niet aan staat.

.edit2: nee pretty sure dit is niet wat er aan de hand is. Mijn router rapporteert momenteel nul IPTV traffic, maar toch werkt mijn WiFi niet. Mijn telefoon connect wel op 300Mbps, maar een speedtest zegt 0,0Mbps download, 1,6Mbps upload, 800ms ping en 2s jitter. Mijn laptop wil niet eens verbinden.

Het betreft een oude Netgear router die nu als AP+switch zijn werk doet. De switch werkt dan weer wel prima. Maar goed, dit is een beetje offtopic in de Freedom thread.

[ Voor 41% gewijzigd door .oisyn op 30-10-2020 11:41 ]

[.oisyn]

Iets anders trouwens, zou je de VLAN4 theoretisch niet gewoon kunnen bridgen, met alle STB's op datzelfde VLAN? Je hebt dan helemaal geen NAT en RTSP snooping meer nodig in de router.

[Freee!!]

.oisyn schreef op vrijdag 30 oktober 2020 @ 09:10:
[...]
En BAM het kwartje valt.

Bewaren, die zijn ondertussen zeldzaam

[ik222]

.oisyn schreef op vrijdag 30 oktober 2020 @ 09:15:
Iets anders trouwens, zou je de VLAN4 theoretisch niet gewoon kunnen bridgen, met alle STB's op datzelfde VLAN? Je hebt dan helemaal geen NAT en RTSP snooping meer nodig in de router.

Nee bij de meeste providers (waaronder in elk geval KPN en volgens mij ook Canal Digitaal) kan dat tegenwoordig niet meer omdat de settopbox bijvoorbeeld zijn menu, tvgids en nog wat zaken via internet binnenhaalt. Je settopbox werkt dus alleen als deze ook internettoegang heeft en dat heeft hij niet als je hem bridged op het IPTV VLAN.

[raymonvdm]

Ik heb mijn STB`s nog steeds via een bridge naar VLAN4 lopen. De provider zorgt ervoor dat de STB het menu van internet kan halen via hun NAT doos. :-)

[ik222]

raymonvdm schreef op vrijdag 30 oktober 2020 @ 15:18:
Ik heb mijn STB`s nog steeds via een bridge naar VLAN4 lopen. De provider zorgt ervoor dat de STB het menu van internet kan halen via hun NAT doos. :-)

Is dat bij Freedom / Canal Digitaal? Ik had daar ook "volgens mij" bij gezet omdat ik het daarvan dus niet zeker weet, ik heb zelf KPN en daar werkt dat in elk geval niet meer. Daar ben je verplicht routed mode te gebruiken zodat je settopbox ook gebruik kan maken van je eigen internet.

Maar als dat bij Freedom / Canal Digitaal wel werkt dan kan VLAN 4 bridgen voor veel mensen een prima oplossing zijn. Simpele managed switch direct aan de FTU of NT (VLAN 4 en 6 tagged), daar direct je STB's op (VLAN 4 untagged) en vervolgens een poort met untagged VLAN 6 naar je router.

[ Voor 3% gewijzigd door ik222 op 30-10-2020 15:27 ]

[.oisyn]

Oeh interessant. Ik heb geen NT, glas gaat direct m'n router in. Helaas heeft de ER-4 geen hardware offloading voor bridges , dus ik denk dat ik het maar bij routing hou.

[raymonvdm]

ik222 schreef op vrijdag 30 oktober 2020 @ 15:25:
[...]

Is dat bij Freedom / Canal Digitaal? Ik had daar ook "volgens mij" bij gezet omdat ik het daarvan dus niet zeker weet, ik heb zelf KPN en daar werkt dat in elk geval niet meer. Daar ben je verplicht routed mode te gebruiken zodat je settopbox ook gebruik kan maken van je eigen internet.

Maar als dat bij Freedom / Canal Digitaal wel werkt dan kan VLAN 4 bridgen voor veel mensen een prima oplossing zijn. Simpele managed switch direct aan de FTU of NT (VLAN 4 en 6 tagged), daar direct je STB's op (VLAN 4 untagged) en vervolgens een poort met untagged VLAN 6 naar je router.

Nee, ik heb geen TV bij mijn Freedom verbinding

[.oisyn]

Nou, managed switches hangen ertussen, maar mijn haperingsprobleem bij Begin Gemist is niet weg

Was wel mooi, TV stond aan, ik hang de nieuwe switch ertussen, alle lampjes beginnen als een gek te knipperen (want hij krijgt dan wel multicast pakketjes maar heeft de IGMP subscribe nog niet gezien). Ik zap van kanaal en het houdt op, het gaat nog louter over de juiste poorten

[ Voor 59% gewijzigd door .oisyn op 30-10-2020 21:36 ]

[ollie1965]

Nog een paar dagen Ollie, nog een paar dagen.

[Sakura_nl]

ollie1965 schreef op zaterdag 31 oktober 2020 @ 23:46:
Nog een paar dagen Ollie, nog een paar dagen.

[Afbeelding: Freedom aansluitpakket]

Erg mooie doos, iets om trots op te zijn

Ik heb inmiddels 2 van die dozen staan

[ollie1965]

Sakura_nl schreef op maandag 2 november 2020 @ 17:52:
[...]


Erg mooie doos, iets om trots op te zijn

Ik heb inmiddels 2 van die dozen staan

Ik ben helemaal niet van sociale media, maar het woord "unboxing video" kwam ineens in me op
Het is wel een mijlpaal ja, eerst "funder", dan "founder" en nu "member" (gewacht met aanvragen/aansluiten vanwege een mogelijke verhuizing).

Maar 2 dozen.... is het verslavend? Want anders ga ik me nu al aanmelden bij een kliniek (vanwege de wachttijd )

[Verwijderd]

Hmm, ik heb 3 Freedom-verbindingen maar geen van die dozen.

Ze hebben me onlangs wel een T-shirt gestuurd. Dat dan weer wel.

[Sakura_nl]

Verwijderd schreef op maandag 2 november 2020 @ 22:37:
Hmm, ik heb 3 Freedom-verbindingen maar geen van die dozen.

Ze hebben me onlangs wel een T-shirt gestuurd. Dat dan weer wel.

Doos ruilen voor een t-shirt ?

LOL

[Hatman]

Ik wacht wel tot Gaston mij de doos komt overhandigen 🤪

[raymonvdm]

Verwijderd schreef op maandag 2 november 2020 @ 22:37:
Hmm, ik heb 3 Freedom-verbindingen maar geen van die dozen.

Ze hebben me onlangs wel een T-shirt gestuurd. Dat dan weer wel.

Wat moet je dan doen voor een T-Shirt? PPPOE problemen hebben