News items for tag lastmile - Koos van den Hout

2020-07-06 En verder op zoek naar de stabiele VDSL configuratie
Ook de aanpassingen aan de configuratie van het Draytek Vigor 130 modem gaven niet het gewenste resultaat: zondag was er weer uitval. Dus het is niet een conflict tussen de pppoe client op mijn router en die in het Draytek Vigor 130 modem.

Om nu meer richting een ondersteunde configuratie te komen heb ik de nieuwste firmware er op gezet maar dan met de 'modem5' vectored VDSL driver. Ik hoop dat dat een betere situatie oplevert. De 'modem5' driver is volgens Draytek documentatie 'optimized for KPN'. Die levert wel wat meer vertraging op, maar dat is in de orde van milliseconden.

En als extra aanpak van het probleem heb ik een script geschreven wat het modem vraagt om een vdsl herstart. Dit script roep ik aan als het er alle tekenen van heeft dat de verbinding naar buiten weg is.

Tags: ,
2020-07-04 Wijziging configuratie Draytek Vigor 130 om onderbrekingen te verminderen
De vervelende lange onderbrekingen van de Internet verbinding bleven aanhouden en ik zocht hulp in de xs4all.adsl nieuwsgroep.

Ik kreeg een suggestie om de configuratie van het Draytek Vigor 130 modem aan te passen. Ondanks dat deze in PPPoE passthrough staat blijft de interne PPPoE client toch proberen om een verbinding op te bouwen. En dat geeft een probleem als het proberen op te bouwen van een nieuwe sessie een conflict geeft met een oude sessie wat alleen op te lossen is door een tijdje te wachten.

De suggestie was ook om logging van het Draytek Vigor 130 modem aan te zetten naar een syslog server zodat het zichtbaar werd wat er gebeurde. En dat gaf meer informatie wat inderdaad aangaf dat de PPPoE client op de Draytek Vigor 130 modem storing gaf.
Read the rest of Wijziging configuratie Draytek Vigor 130 om onderbrekingen te verminderen

Tags: ,
2020-06-03 Paar lange onderbrekingen Internet door PPPoE probleem
Ik heb een paar keer de afgelopen dagen een vrij lange onderbreking van het Internet thuis gehad, die eigenlijk leken te komen door een hik in de PPP sessie zonder dat de DSL sessie wegviel. Vervolgens probeert pppd met PPPoE (PPP over Ethernet) erg enthousiast de verbinding weer aan de gang te krijgen wat niet lukt. Netto resultaat: een langdurige uitval tot ik een keer met de hand het modem herstart (en dus de DSL sessie ook laat wegvallen).

Na wat navraag in xs4all.adsl lijkt dit een gevolg te zijn van het hardnekkig en snel weer opbouwen van de sessie terwijl er nog 'state' is van de oude sessie. En er is misschien wel een hik geweest in het transportnetwerk tussen de straatkast hier en de xs4all routers maar de sessie was nog niet weg.
Read the rest of Paar lange onderbrekingen Internet door PPPoE probleem

Tags: ,
2020-03-08 Updating the Fritz!box 7360v1: still no PPPoE passthrough
A while ago I noticed a mention of new firmware for the Fritz!box 7360v1. As I want a separate PPPoE process to have full control of my Internet connection I hoped the PPPoE passthrough option would become available, since this would be a firmware version later than 6.30, but no.

At least the upgrade went fine without having to use the recovery options. So the 'in case of emergency' settings have been kept forwarding the necessary ports via IPv4.

Tags: , ,
2020-01-21 Suricata and ppp: restart of suricata needed after ppp down/up
Suricata is running and detecting attacks, but it was causing a 100% cpu load after a restart of the ppp connection (the DSL here uses PPP over Ethernet).

The errors point at the problem starting when the ppp connection restarts:
21/1/2020 -- 00:59:36 - <Error> - [ERRCODE: SC_ERR_AFP_READ(191)] - Error reading data from iface 'ppp0': (100u) Network is down
21/1/2020 -- 00:59:37 - <Error> - [ERRCODE: SC_ERR_AFP_CREATE(190)] - Couldn't set fanout mode, error Invalid argument
Which also starts to fill the system log with:
Jan 21 00:59:42 xxxxxxxx kernel: [11347441.726755] device ppp0 left promiscuous mode
Jan 21 01:00:13 xxxxxxxx kernel: [11347472.055712] device ppp0 entered promiscuous mode
Jan 21 01:00:13 xxxxxxxx kernel: [11347472.071533] device ppp0 left promiscuous mode
Jan 21 01:00:13 xxxxxxxx kernel: [11347472.091653] device ppp0 entered promiscuous mode
The interesting part is that this causes higher power usage about five and a half hours later.

Solution: restart suricata in an /etc/ppp/ip-up.d/ script.

Tags: , , ,
2019-02-27 Rare verandering in VDSL upstream snelheid
VDSL upstream snelheid week Ineens is de haalbare VDSL upstream snelheid (engels 'attainable') gezakt naar wat daarvoor ongeveer de huidige VDSL upstream snelheid (engels 'current') was. Een opvallende hik in de grafieken. Ik heb geen idee wat de aanleiding is en of dit weer kan veranderen.

Dit is alleen te zien in het modem, de hele PPP sessie is gewoon in stand gebleven.

Tags: , ,
2018-11-05 De gevolgen van DSL interleave
Ping stats Gisterenavond dus toegekomen aan het vervangen van het vdsl modem na de eerdere storing en ineens viel me wat op in de ping stats: tijdens het gebruik van de fritzbox was de round trip tijd lager en stabieler, de uitschieters naar boven komen dus puur van de vdsl laag. De fritzbox zet de interleave uit (fast/fast), de huidige modemdriver in de vigor op fast down en interleaved up.

Misschien toch eens een andere vdsl driver proberen op de vigor.
Read the rest of De gevolgen van DSL interleave

Tags: , ,
2018-11-02 Een hikkende internet verbinding
Sinds woensdagmiddag hikt de VDSL verbinding. Op het VDSL modem lijkt alles prima in orde, maar toch hapert verkeer erg regelmatig.

Ik laat mtr lopen en ik zie ineens een patroon ontstaan:
                             Last  50 pings
 1. 124.ae0.xr4.1d12.xs4all. ..................................................
 2. 0.ae1.dr12.d12.xs4all.ne ..................................................
 3. outgate.idefix.net       b23.....>b3b22...>c3b22.....>b3b22...>c3b22.....?
 4. 2001:980:14ca:1::23      b11.....>b1b.1...>b2b.1.....>b1b.....>b2b11.....?

Scale:  .:38 ms  1:154 ms  2:347 ms  3:616 ms  a:963 ms  b:1387 ms  c:1888 ms  >
Blijkbaar is eens in de 9 of 11 seconden er een vertraging gedurende 5 seconden. Tijd voor een rondje diagnose. De eerste verdachte is het vdsl modem, want het vdsl modem zelf benaderen hikt ook met dezelfde regelmaat. Volgens de switch waar het modem aanzit is er op ethernet niveau niets mis.

Toevoeging: Na een herstart functioneerde het VDSL modem helemaal niet meer. Het lijkt er op dat het slachtoffer geworden is van de stroomstoring van dinsdagmorgen. Er is een nieuwe onderweg. Het VDSL modem is ouder dan 2 jaar, dus daar zit zeker geen garantie meer op.

Op dit moment werkt de verbinding naar buiten met het Fritz!box 7360v1 modem van xs4all. Met de nodige IPv4 portforwards zijn diverse zaken in ieder geval weer bereikbaar over IPv4 en kunnen we over IPv4 naar buiten.
Read the rest of Een hikkende internet verbinding

Tags: ,
2018-09-14 Recent Internet outages without VDSL link
Two (at this moment) long outages in the last two days without VDSL link which makes it look like the VDSL service was out completely (no sync at all). A telecom engineer busy in the local wire cabinet? Some other outage?

Outages:
  • Thursday 13 september 17:01 - 18:23
  • Friday 14 september 13:59 - 15:48

Update: and another
  • Monday 17 september 10:07 - 11:46
Called the xs4all customer service. They couldn't find any planned or unplanned work but did see the same outages on my line that I saw. The person on the phone was quite baffled too by this behaviour. The first cause to eliminate this is to really powerflip the modem, when that does not help replace it temporarily with a known-good modem (the Fritz!box 7360v1 which I still have).

Update: interruptions haven't happened since my call to xs4all.

Tags: ,
2018-01-27 I caused an interesting problem with the VDSL pppoe session
Normally being active on certain HF bands causes one-time VDSL disconnects but what I have currently done seems to have triggered something else. After the connection dropped it refuses to come back at the moment. The entire session looks like:
22:49:28.466922 PPPoE PADI [Service-Name]
22:49:28.490394 PPPoE PADO [AC-Name "dr12.d12"] [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL]
22:49:28.490603 PPPoE PADR [Service-Name] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83]
22:49:28.517063 PPPoE PADS [ses 0x40c] [Service-Name] [AC-Name "dr12.d12"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83] [EOL]
22:49:28.575266 PPPoE  [ses 0x40c] LCP, Conf-Request (0x01), id 72, length 16
22:49:28.575776 PPPoE  [ses 0x40c] LCP, Conf-Request (0x01), id 99, length 22
22:49:28.575798 PPPoE  [ses 0x40c] LCP, Conf-Reject (0x04), id 72, length 10
22:49:28.589161 PPPoE  [ses 0x40c] LCP, Conf-Ack (0x02), id 99, length 22
22:49:28.589164 PPPoE  [ses 0x40c] LCP, Conf-Request (0x01), id 73, length 12
22:49:28.589666 PPPoE  [ses 0x40c] LCP, Conf-Ack (0x02), id 73, length 12
22:49:28.589682 PPPoE  [ses 0x40c] LCP, Echo-Request (0x09), id 0, length 10
22:49:28.589693 PPPoE  [ses 0x40c] CCP, Conf-Request (0x01), id 89, length 17
22:49:28.589702 PPPoE  [ses 0x40c] IPCP, Conf-Request (0x01), id 89, length 18
22:49:28.589711 PPPoE  [ses 0x40c] IP6CP, Conf-Request (0x01), id 89, length 16
22:49:28.603265 PPPoE  [ses 0x40c] LCP, Echo-Reply (0x0a), id 0, length 10
22:49:28.603267 PPPoE  [ses 0x40c] LCP, Term-Request (0x05), id 74, length 6
22:49:28.604033 PPPoE  [ses 0x40c] LCP, Term-Ack (0x06), id 74, length 6
22:49:31.623454 PPPoE PADT [ses 0x40c] [Generic-Error "RP-PPPoE: System call error: Input/output error"] [AC-Cookie 0xA3FE109A222CE73945C23FCE85E03F83]
So in the end the router at my ISP decides to terminate the connection. On the connection failing I decided to change the configuration to use the kernel mode pppoe driver but after this started showing I reverted that change. Which made no difference, the connection is still not coming up.

Update: I went looking at other changes I made to enable the pppoe server test and reverting the /etc/ppp/pap-secrets file to its original format fixed the problem. I guess I somehow started to authenticate the remote end.

And changing from user-mode pppoe to kernel-mode pppoe does lower the MTU to 1492, so that test is also finished. Back to user-mode pppoe.

Tags: , , ,

IPv6 check

Running test...
, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred. PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers

RSS
Meningen zijn die van mezelf, wat ik schrijf is beschermd door auteursrecht. Sommige publicaties bevatten een expliciete vermelding dat ze ongevraagd gedeeld mogen worden.
My opinions are my own, what I write is protected by copyrights. Some publications contain an explicit license statement which allows sharing without asking permission.
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews
This page generated by $Id: newstag.cgi,v 1.35 2021/11/09 13:09:49 koos Exp $ in 0.023391 seconds.