News items for tag lastmile - Koos van den Hout

2020-08-04 Een slechte dag voor VDSL 6 days ago
Gisterenmiddag viel de VDSL weer eens 'ouderwets' uit zonder aanwijsbare redenen. Tijdens thuiswerken, wat natuurlijk niet handig is. De maximale snelheid ging even naar ADSL snelheden (7 mbit down, 2 mbit up) maar was snel weer op hoge snelheid. Het kostte een paar pogingen weer een stabiele PPP connectie te krijgen dus misschien was er ergens anders in het netwerk ook even iets mis.

Gisterenavond werd ik actief met amateurradio op 14 en 7 MHz. Dat gaf diverse verstoringen van de VDSL, ik was gewend dat de verbinding per nieuwe band waarop ik actief ben een keer 'leert' om het stuk waar ik actief ben niet te gebruiken. Ik bleek ook een storing in de antenne op 7 MHz te hebben waardoor veel signaal reflecteerde, wat misschien de oorzaak was van de meervoudige storingen. Uiteindelijk dat op kunnen lossen en daarna bleef de VDSL verbinding ook actief.

Afgelopen nacht is er nog wel twee keer een uitval geweest. Maar het is vlot hersteld zonder dat het script wat een vdsl reboot forceert actief is geworden.

Tags: ,
2020-07-18 VDSL lijkt weer stabiel te zijn 3 weeks ago
Sinds de overschakeling naar de modem5 vectored VDSL driver voor de Draytek vigor 130 is er maar een keer een VDSL uitval geweest, en die was gerelateerd aan amateurradio activiteit op de 40 meter band (7 MHz) en dat ben ik gewend.

Het lijkt er dus op dat dit een verder stabiele configuratie is. Daar was ik ook wel weer aan toe na alle problemen sinds begin Juni.

Snelheden zijn sinds die herstart wel anders. De ruimte tussen 'attainable' en 'current' zijn nu groter. Upstream is 34.5 / 30.9 en downstream is 69.1 / 111.0. Snel genoeg in ieder geval voor wat ik wil.

Tags: ,
2020-07-06 En verder op zoek naar de stabiele VDSL configuratie 1 month ago
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 1 month ago
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 2 months ago
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 5 months ago
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 6 months ago
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 1 year ago
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 1 year ago
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 1 year ago
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 1 year ago
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 2 years ago
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: , , ,
2018-01-14 Recovering firmware on the Draytek Vigor 130 VDSL2 modem with linux / macosx 2 years ago
I needed the recovery procedure again: there was a new firmware 3.8.12 with newer VDSL modem driver and the standard update via the webinterface failed.

I just want to keep the notes from "OzCableguy" since his shop and blog have gone. I found the saved version via archive.org, Updating Draytek firmare using the MacOS X or UNIX command line and TFTP - OzCableguy.

Draytek modems have several methods available to update their firmware.

You can use the Firmware Upgrade Utility under Windows, load it from the web interface via HTTP, FTP the file to the modem or use the TFTP (Trivial File Transfer Protocol) service built into the box.

If your modem has been bricked you can’t use FTP or HTTP. If you don’t want to use Windows or go through the web interface, then this TFTP method is a viable alternative. Note that unlike a lot of other boxes using TFTP to load firmware, the Draytek is acting as a TFTP server, the UNIX/MacOS box as a client and you PUT the file onto the modem. It is normally the other way around, but that needs some extra setup steps that are conveniently avoided with this method.

The firmware comes in two pieces. Use the .rst version of the file if you want to change the modem settings back to factory defaults, use the .all file to keep the current settings (.all may not be a good option if the modem is bricked).

Secondly you need an ethernet interface on your Mac or UNIX box set to the subnet 192.168.1.0 (eg: with IP address 192.168.1.10) so that you can talk to the modem at its default IP address of 192.168.1.1.

If the modem is up and running (and not bricked), you should now be able to ping it ..
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.309 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.421 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.409 ms
^C
—-192.168.1.1 PING Statistics—-
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.309/0.380/0.421/0.050 ms$ 
If your modem is really bricked then the ping will only work when the modem is actually in TFTP upload mode as below. You can ignore this step, it just demonstrates that the ethernet cable is working.

Now we can upload the firmware. With the modem powered off, press and hold the factory reset button, then power up the modem. Continue to hold the button down until ’some’ of the lights flash together. On the Vigor2820Vn ’some’ is the left column of three. On the 2800 and 2910 the left two LEDs flash.

Release the button and on your UNIX/MacOS box type the following commands (note that the modem only stays in TFTP mode for a short time, you can actually type right up to the end of the put command and just press return when the left-hand modem lights start flashing).

The name of the firmware and the number of bytes transmitted depend on the product you are trying to recover.
$ tftp 192.168.1.1
tftp> binary
tftp> put v2820_v03301_211011_A.rst
Sent 4973144 bytes in 13.1 seconds
tftp> quit
$ 
There will be a pause after the ‘put’ command, but your modem ethernet port light should be flashing madly. The transfer is done when you get the “Sent” message. Quit the TFTP client and perhaps your Terminal session, there’s nothing more to see.

What happens next isn’t really documented but we presume that the modem has to unpack the firmware and load it into flash. On our 2820Vn the column of 3 lights continued to flash, but gradually slowed down, speeded up, then slowed again. Eventually after a minute or two the modem rebooted in the normal fashion. Just be patient.
And this last bit is where the windows utility is better: it will tell you when the recovery is done and a success. With a commandline tool you'll just have to wait for the leds to blink right.

After all the recovery and the waiting the modem works again and the line is stable. I chose the 'modem6' version again. I may try the 'modem5' and 'modem4' version too to see whether I can get lower latency without losing stability. Although the improvement may be in the single digit millisecond range so it would be a lot of work for very little improvement.
Read the rest of Recovering firmware on the Draytek Vigor 130 VDSL2 modem with linux / macosx

Tags: , ,
2017-09-08 VDSL tijdelijk met ADSL2 snelheid 2 years ago
Ik had een hik vandaag met de DSL verbinding en toen was ineens de snelheid 15 mbit downstream en 1.2 mbit upstream in plaats van 103 mbit downstream en 27 mbit upstream wat ik meestal gewend ben. Het leken wel ADSL2 snelheden. Ook met maar 512 carriers van de 4096 in gebruik. Toch was het DSL profiel nog wel 17a, wat een VDSL profiel is.

Na een tweede hik was de snelheid weer gewoon wat ik gewend was met vectored VDSL.

Update 2017-09-11: De snelheid blijft toch inzakken. De verbinding is nog stabiel maar ik verwacht eigenlijk problemen in de komende tijd. Het regent veel de laatste dagen dus het kan zijn dat er ergens water in de telefoonkabels terecht komt.

Update 2017-09-12: VDSL downstream week 20170912 En na een nieuwe hik is de snelheid weer terug. Het blijft magie, maar omdat het radiofrequenties zijn verwacht ik dit soort magie.

Tags: , ,
2017-04-19 En nu is de MTU wel naar 1500 van de VDSL PPPoE sessie 3 years ago
Recent postte 'Coen' in xs4all.adsl een stappenplan om onder Ubuntu 12.04 de MTU van de PPP verbinding naar 1500 bytes te krijgen. Alle lof dus naar Coen, want met zijn stappenplan is het me wel gelukt en is alles nu doorgaand MTU 1500, wat minder issues zou moeten geven.
Na een gezellig avondje stoeien is het gelukt om dit met terugwerkende
kracht voor Ubuntu 12.04 op te lossen met een nieuwe pppd en pppoe versie.

Voor wie durft en bovendien wat Linux ervaring heeft hier de te volgen
stappen:

Nieuwe pppd builden:

mkdir ppp
cd ppp
apt-get source ppp
cd ppp-2.4.5/
wget -O debian/patches/zz_pppoe1500
"http://git.ozlabs.org/?p=ppp.git;a=patch;h=fd1dcdf758418f040da3ed801ab001b5e46854e7"
dch -i
dpkg-buildpackage -us -uc

[[ppp en ppp-dev installeren]]

Nieuwe pppoe builden:

mkdir pppoe
cd pppoe
wget -4
http://archive.ubuntu.com/ubuntu/pool/universe/r/rp-pppoe/rp-pppoe_3.11-0ubuntu1.dsc
wget
http://archive.ubuntu.com/ubuntu/pool/universe/r/rp-pppoe/rp-pppoe_3.11.orig.tar.gz
wget
http://archive.ubuntu.com/ubuntu/pool/universe/r/rp-pppoe/rp-pppoe_3.11-0ubuntu1.debian.tar.xz
tar -xzvf rp-pppoe_3.11.orig.tar.gz
cd rp-pppoe-3.11/
tar -xf ../rp-pppoe_3.11-0ubuntu1.debian.tar.xz
dch -i
dpkg-buildpackage -us -uc

[[pppoe installeren]]

Mtu op 1500 zetten: klaar!
Vanaf een losse client leek toch nog MTU 1492 gebruikt te worden, dus heb ik /etc/radvd.conf aangepast om expliciet MTU 1500 mee te geven:
interface eth0.3
{  
   AdvSendAdvert on;
   AdvLinkMTU 1500;
En dan de verdere opties. En dan werkt het inderdaad:
koos@kernighan:~$ tracepath6 ping.xs4all.nl
 1?: [LOCALHOST]                        0.018ms pmtu 1500
 1:  eth0-3.idefix.net                                     1.983ms 
 1:  eth0-3.idefix.net                                     1.858ms 
 2:  lo0.dr12.d12.xs4all.net                              17.910ms 
 3:  0.ae22.xr3.3d12.xs4all.net                           17.957ms 
 4:  no reply

Tags: , , ,
2017-01-23 Ontbrekende stukje grotere MTU met VDSL op DrayTek Vigor 130 en Ubuntu 3 years ago
Ongeveer een jaar geleden ging ik over op het Draytek Vigor 130 VDSL modem om weer een configuratie te krijgen waar ik maximale controle heb.

Het nog openstaande punt is dat ik de ppp configuratie graag naar een MTU van 1500 bytes wil. En dat dat toen niet lukte in Vigor VDSL modem in gebruik en Xs4all VDSL met DrayTek Vigor 130 VDSL modem en PPP eindpunt op Linux (ubuntu) server.

Wat ik al goed had was de MTU van de ethernet interfaces hoger en het vinkje op de Draytek aangepast. Maar als ik de mtu/mru hoger forceerde in de ppp opties ging het mis.

Nu kwam voorbij in xs4all.general over dit onderwerp:
> 1500 wordt ondersteund door Xs4all en je test eerst bij 1492 welk pakket
> via ping erdoor gaat zonder in stukken gebroken te worden.
> Daarna zet je de MTU naar 1500 en kijkt of je inderdaad 8 bits meer door
> router kunt drukken zonder dat die gebroken wordt.

Wel zorgen dat het apparaat waar je de PPPoE termineert RFC4638
implementeert.
Die moet dan in de PADI een extra tag plaatsen (PPP payload is 1500
bytes), en de BRAS zet dat ook weet in zijn PADO antwoord.
Zo maar een grotere MTU gebruiken gaat niet werken...
De PPPoE sessie komt bij mij vanaf de thuisserver met rp-pppoe. Even zoeken leverde mij op dat voor rp-pppoe met MaxPayload onderhandeling ik minstens 3.11 nodig heb, en bij de huidige ubuntu versie zit nog 3.8. Tijd om een nieuwere versie te testen.

Update: Daarvoor moeten zowel de pppoe binary als de rp-pppoe.so plugin voor pppd bijgewerkt worden, en dat lukt me op dit moment even niet. Gelukkig had ik de oude pppoe binaries expres klaar staan en kon ik dus heel snel terug.
Read the rest of Ontbrekende stukje grotere MTU met VDSL op DrayTek Vigor 130 en Ubuntu

Tags: , , ,
2016-07-15 DrayTek Vigor 130 firmware herstel 4 years ago
Na weer duidelijke instabiliteit wilde ik weer omschakelen naar de versie 3.7.9 modem6 firmware, alleen ging er iets mis in de update en bleef er een niet-startend modem over.

Het was even zoeken naar de recovery methoden en de ondersteunde methode is via de Windows firmware utility volgens How to recover my router from a failed firmware upgrade?. Ik zag wel dat het modem probeerde DHCP client te zijn maar de standaard methode van een bootfile meegeven met een verwijzing naar firmware op een tftp server hielp niet.

Voor de snelheid maar even windows geboot en de upgrade uitgevoerd. Achteraf met wat uitzoekwerk gevonden dat wat de firmware utility doet is naar de tftp server in het modem die actief is bij een factory reset boot een firmware bestand sturen. Volgens Updating Draytek firmare using the MacOS X or UNIX command line and TFTP kan dit ook prima op de Linux of MacOSX commandline.

Tags: ,
2016-06-23 PPPoE forwarding voor de FRITZ!Box 4 years ago
Ik zag ergens voorbij komen dat er nieuwe firmware voor de FRITZ!Box 7360 was met in de release notes:
Improved: Support can be enabled for PPPoE passthrough
Dus ik haalde snel die firmware binnen en ging deze testen. Maar deze werd geweigerd door de FRITZ!Box. Na goed nakijken bleek dat deze feature en andere updates er alleen zijn voor de 7360 v2 versie, en ik heb in maart 2014 een FRITZ!Box 7360 v1 ontvangen en daar zijn nog geen nieuwere firmware versies dan 06.30 voor, dus geen pppoe passthrough. Via de AVM Nederland supportsite maar even een call aangemaakt met het verzoek om die verbetering ook beschikbaar te stellen.

De DrayTek Vigor 130 doet het goed, maar ik zou het wel prettig vinden om te kunnen wisselen met een "officieel" modem in PPPoE passthrough mode zodat ik de VDSL storingen daar ook kan onderzoeken.

Update 2016-06-24: Antwoord van AVM: zie Why is the latest FRITZ!OS not available for the FRITZ!Box 7360 v1? oftewel door hardware beperkingen van de _v1 versie zal er niet gauw een update komen.

Tags: ,
2016-06-16 Weer andere firmware DrayTek Vigor 130 4 years ago
Na een week met stijgende aantallen hikken in de vectored vdsl verbinding maar weer eens gekeken naar de firmware versies. Op Firmware - Vigor 130 - Draytek staat nu firmware versie 3.7.9 met wat updates in diverse varianten waaronder 2 keer voor het KPN netwerk.

Ik ben maar weer overgeschakeld naar de modem5 versie uit Vigor130_v3.7.9_modem5.zip, eens kijken wat dat doet voor de stabiliteit.
Read the rest of Weer andere firmware DrayTek Vigor 130

Tags: ,
2016-05-02 Experiences with vectored VDSL and amateur radio transmissions 4 years ago
It is a while after my last report on Vectored VDSL and the influence of amateur radio transmissions and it's time to share the current experiences especially with the change to the DrayTek Vigor 130 VDSL modem.

The first conclusion is that the modem doesn't matter much. I am now used to the connection dropping and retraining when I start on a 'new' frequency. I haven't figured out yet what the exact definition of 'new' is, when I haven't been active for a number of days on 20M PSK31 the first transmission on that band can trigger the disconnect. There seems to be no direct influence on the maximum speed after the reconnect, it sometimes goes up. A serious change of frequency (different band or a different part of a band) can trigger another disconnect.

In the mean time an xs4all user shared after long debugging of vectored VDSL problems to have found the cause in the PLC (powerline communications) network devices as delivered by xs4all for television over IP. Yet another reason to not use PLC. But in the ideal world the lastmile connections for high speed would be fiber-based anyway.

Tags: , , ,
  Older news items for tag lastmile ⇒
, 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 pgp key statistics for 0x5BA9368BE6F334E4 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews