Hik: dsl blijft prima up maar ppp sessie weg

Discussion:

(te oud om op te antwoorden)

Rob

2020-06-02 20:30:13 UTC

Ik ben zo eigenwijs dat ik het ppp eindpunt naar een ander apparaat
verplaatst heb. En nu heb ik de laatste dagen al een paar keer dat de DSL
prima blijft werken maar de ppp sessie wegvalt en wegblijft tot ik de DSL
ook herstart.
De eerste paar keer was de uitval 's nachts omstreeks 02:30, wat voor mij
aanvoelt als een onderhoudswindow. Maar vanmiddag ook om 16:15.
Enfin, mijn ppp sessie loopt via lo0.dr12.d12.xs4all.net
Jun 2 17:01:22 wozniak pppd[18630]: Timeout waiting for PADO packets
Jun 2 17:01:22 wozniak pppd[18630]: Unable to complete PPPoE Discovery
Jun 2 17:02:27 wozniak pppd[18630]: Timeout waiting for PADO packets
Jun 2 17:02:27 wozniak pppd[18630]: Unable to complete PPPoE Discovery
Jun 2 17:03:32 wozniak pppd[18630]: Timeout waiting for PADO packets
Jun 2 17:03:32 wozniak pppd[18630]: Unable to complete PPPoE Discovery
Jun 2 17:04:17 wozniak pppd[18630]: PPP session is 3094
Jun 2 17:04:17 wozniak pppd[18630]: Connected to 78:fe:3d:bc:44:83 via
interface eth2
Jun 2 17:04:17 wozniak pppd[18630]: Using interface ppp0
Suggesties welkom.
Koos

Dat heb ik hier wel eens bediscussieerd met Mike. Het is een bug.
Je moet de pppd een paar minuten down brengen en dan weer up en dan
kun je er weer in.
Doe je alles op 1 box dan heb je hier geen last van.

Rob

2020-06-03 07:50:25 UTC

Permalink

Post by Rob
Dat heb ik hier wel eens bediscussieerd met Mike. Het is een bug.
Je moet de pppd een paar minuten down brengen en dan weer up en dan
kun je er weer in.

Ik zit in de manpage van pppd te kijken (en naar pppoe, ik gebruik de
rp-pppoe.so plugin) maar ik zie niet echt de 'wacht een stuk langer voor
herstarten onderhandelingen' optie. Een maxfail zetten en eens in het
kwartier controleren of de link up is en anders een ifup doen klinkt ook
wat minder robuust.
Kortom, ik zoek een manier om iets minder agressief de pppoe/pppd sessie te
herstarten, maar wel robuust.

Ja ik baal er ook van!
Het schijnt een bug te zijn in de afhandeling van PPPoE halfweg in het
netwerk, waarbij er state informatie wordt bijgehouden van je connectie.
Als om de een of andere reden de PPPoE sessie aan jouw kant down is
(bijvoorbeeld omdat je te lang niks terug gehoord hebt, bijvoorbeeld door
een netwerk onderbreking) terwijl "het netwerk" denkt dat die nog up
zou moeten zijn dan gaat het fout en kun je geen nieuwe connectie meer
opzetten tot "het netwerk" de vorige connectie vergeten is.

Het zou kunnen dat ze het inmiddels iets verbeterd hebben want toen ik
daar tegen aan liep loste dit zich niet vanzelf op! Als je bleef proberen
te connecten dan werd die state informatie verlengd en ging het nooit
lukken, je MOEST echt even een paar minuten niks doen en het dan pas
weer proberen. Mijn connectie is ooit wel een paar uur down geweest na
zo iets en kwam pas terug nadat ik zelf had ingegrepen op bovenstaande
wijze. Maar jouw log lijkt er op te wijzen dat het zich na een paar
minuten vanzelf oplost.

Ik heb toen een scheduled job gemaakt op mijn router, die als de PPPoE
down is deze disabled en 5 minuten later weer enabled en sindsdien heb
ik dat niet meer gezien. Maar of dat nu echt nog nodig is kan ik lastig
testen.

Als je invloed hebt op alle parameters zou je ook eens kunnen overwegen
om het moment dat pppd besluit dat de boel down is verder uit te stllen.
(dus langer geen replies op een lopende connectie accepteren voor hij
denkt "is down" en opnieuw gaat connecten)
Want ik denk dat deze problemen komen door tijdelijke onderbekingen in
het transportnetwerk die eigenlijk gewoon zonder reconnectie overleefd
hadden moeten worden.
Ik kan dat op mijn router niet configureren maar jij wellicht wel.

Post by Rob
Doe je alles op 1 box dan heb je hier geen last van.

Moet je ook wel iets over en weer met de state doen. pppoe/pppd mislukt ->
dsl onderhandeling herstarten. En pas na linkup weer de andere kant uit.
Vast iets wat de fritzboxen doen.

Ja als je VDSL connectie re-trained dan wordt die state informatie meteen
gewist. En ik heb diverse malen gezien dat een fritzbox na een dergelijke
fout een reboot deed en dus ook een re-train. Of dat er met opzet in
gebouwd is als workaround voor dergelijke problemen, of dat die reboot
van de fritzbox het gevolg was van een andere bug dat weet ik niet.

Rob

2020-06-03 12:56:30 UTC

Permalink

Post by Rob
Als je invloed hebt op alle parameters zou je ook eens kunnen overwegen
om het moment dat pppd besluit dat de boel down is verder uit te stllen.
(dus langer geen replies op een lopende connectie accepteren voor hij
denkt "is down" en opnieuw gaat connecten)
Want ik denk dat deze problemen komen door tijdelijke onderbekingen in
het transportnetwerk die eigenlijk gewoon zonder reconnectie overleefd
hadden moeten worden.
Ik kan dat op mijn router niet configureren maar jij wellicht wel.

Ik heb de lcp-echo-interval eens een stuk ruimer gezet.
Het was
lcp-echo-interval 10
lcp-echo-failure 6
Dus als het transport een minuut down is geeft pppd het op. Maar dus ook
als het een minuut lang niet gelukt is om te connecten.
Ik heb het eens omgezet naar
lcp-echo-interval 60
lcp-echo-failure 6
zodat het transportnetwerk iets langer kan hikken.

Ja ik ben benieuwd of dat uitmaakt. Ik had denk ik eerder de failure op
30 gezet ofzo (met interval 10). Maar echt uitmaken doet het niet.

Als die recovery nog zo werkt als toen ik er tegenaan liep zou je
de holdoff op 300 moeten zetten om het op zeker te verhelpen.

Coen

2020-06-03 09:29:32 UTC

Permalink

Hoi,

Ik gebruik onderstaande settings voor ppp:

----------------------------
plugin rp-pppoe.so modem
user ***@xs4all.nl
noipdefault
ipv6 ,
ipv6cp-use-persistent
defaultroute
persist
maxfail 0
noproxyarp
ipparam xs4all
lcp-echo-interval 6
lcp-echo-failure 5
pty "pppoe -I eth3.6"
mtu 1500
mru 1500
noauth
holdoff 10
----------------------------

De holdoff zorgt voor een pauze tussen connectie pogingen.
De lcp-echo settings voor testen of de verbinding up is.
Door persist blijft de interface connecten als deze down is net zo lang
totdat er weer verbinding is. (Mits maxfail op nul staat)

In /etc/network/interfaces (voor Debian gebaseerde systemen) worden de
ethernet interfaces gestart:

----------------------------
auto eth3
iface eth3 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
mtu 9000
post-down poff vdsl
post-up pon vdsl

auto eth3.6
iface eth3.6 inet manual
post-up ifconfig $IFACE up
pre-down ifconfig $IFACE down
mtu 9000
----------------------------

Ik ben zelf net overgeschakeld van untagged naar tagged verkeer en ik
zie dat eth3.6 nog op manual staat, dus dat zou bij een volgende reboot
een probleem zijn. Moet ik nog even oplossen...

Mijn ppp connectie voor die wijziging was behoorlijk lang up:

Wed Jan 29 16:55:56 CET 2020 ppp0 Started.
Thu May 28 13:29:16 CEST 2020 ppp0 Stopped.

Ik gebruik een Vigor 130 trouwens. Op dit moment met 3.8.4_m4 firmware.

gr,
Coen

Rob

2020-06-03 12:50:47 UTC

Permalink

Post by Coen
Ik ben zelf net overgeschakeld van untagged naar tagged verkeer en ik
zie dat eth3.6 nog op manual staat, dus dat zou bij een volgende reboot
een probleem zijn. Moet ik nog even oplossen...
Wed Jan 29 16:55:56 CET 2020 ppp0 Started.
Thu May 28 13:29:16 CEST 2020 ppp0 Stopped.
Ik gebruik een Vigor 130 trouwens. Op dit moment met 3.8.4_m4 firmware.

Is dat probleem dat je met tagged verkeer geen 1500 byte MTU kunt maken
dan opgelost? Is voor mij de reden geweest om het taggen door de Vigor
te laten doen: je kunt dan RFC4638 gebruiken en de PPPoE MTU/MRU op
1500 zetten. Echter in de versie waar ik dat ooit probeerde werkte dat
niet als je ook nog VLAN tagging op de ethernet interface had staan,
de ethernet MTU was dan te laag. Wellicht is dat in latere firmware
opgelost hoor...

Coen

2020-06-03 14:23:38 UTC

Permalink

Post by Rob
Is dat probleem dat je met tagged verkeer geen 1500 byte MTU kunt maken
dan opgelost? Is voor mij de reden geweest om het taggen door de Vigor
te laten doen: je kunt dan RFC4638 gebruiken en de PPPoE MTU/MRU op
1500 zetten. Echter in de versie waar ik dat ooit probeerde werkte dat
niet als je ook nog VLAN tagging op de ethernet interface had staan,
de ethernet MTU was dan te laag. Wellicht is dat in latere firmware
opgelost hoor...

Ik heb enorm zitten puzzelen vorige week naar waarom jij wel en ik niet
een mtu van 1500 over de ppp verbinding heen kreeg. Dat ik nu even op
tagged zit is daar een gevolg van.

Ik bleef altijd steken op 1496 bytes over ppp. (Een vlan tag is 4 bytes.
Toevallig of niet)
Nadat ik heel veel settings heb geprobeerd blijk het mogelijk om PPPoE
op twee verschillende manier te forwarden:

Ik gebruik nu:
PPPoE/PPPoA Client: Enable
PPPoE Pass-through: For Wired LAN
(Beide op 'PPPoE / PPPoA' tabblad)

Eerder gebruikte ik:
MPoA (RFC1483/2684): Enable
Bridge Mode: Enable Bridge Mode
(Beide op 'MPoA / Static or dynamic IP' tabblad)

Bij die laatste methode mis ik dus een paar bytes.
Zou je eens kunnen kijken welke methode jij gebruikt?

Met beide methodes staat op 'General Setup' VDSL2 enabled met een tag
value van '0'. Als ik die weer op 6 zet kan ik waarschijnlijk weer over
untagged ethernet naar buiten.

Het nadeel van de PPPoE Pass-through is dat het router deel van het
modem connectie op wil gaan zetten. Daar heb je verder geen last van,
maar het spuugt wel veel meldingen in syslog.

Over firmware heb ik hier in mijn archief:
3.8.3_m5 upstream interleaved ipv fast (hoge ping)
3.8.4_m6 upstream interleaved ipv fast (hoge ping)

_m8 heb ik eerder ook wel gebruikt, maar die was minder stabiel dan _m4.
Het hangt erg af van de gebruikte DSLAM. Hier is nog een exemplaar
zonder VPLUS in gebruik. Dus dit gaat er hopelijk ooit nog een keer uit,
alhoewel de uitrol van VPLUS gestaakt lijkt... Met een Vigor 165 zou
200Mbit dan moeten kunnen. En meer is beter :)

gr,
Coen

Rob

2020-06-03 16:18:52 UTC

Permalink

Post by Coen

Ik gebruik die 1e setting dus met PPPoE pass-through, dan onderin dat
scherm de MTU op 1500 en in het General setup scherm bij VDSL2 de
Customer tag op Enable zetten en tag value 6.

De draytek voegt dan zelf de VLAN tag toe, je router moet dus PPPoE
over untagged ethernet doen. Gelukkig kun je evengoed het IP adres
van de Draytek dan nog bereiken op die poort, ik heb daar in mijn
router een apart RFC1918 netwerk op zitten wat je dan naar keuze met
een static route in de Draytek kunt routeren naar je LAN of je kunt
het in je router NATten dan werkt dat ook.

Post by Coen
Met beide methodes staat op 'General Setup' VDSL2 enabled met een tag
value van '0'. Als ik die weer op 6 zet kan ik waarschijnlijk weer over
untagged ethernet naar buiten.

inderdaad.

Post by Coen
Het nadeel van de PPPoE Pass-through is dat het router deel van het
modem connectie op wil gaan zetten. Daar heb je verder geen last van,
maar het spuugt wel veel meldingen in syslog.

Daar let ik verder niet op. De Fritzbox doet dat overigens ook.

Post by Coen
3.8.3_m5 upstream interleaved ipv fast (hoge ping)
3.8.4_m6 upstream interleaved ipv fast (hoge ping)
_m8 heb ik eerder ook wel gebruikt, maar die was minder stabiel dan _m4.
Het hangt erg af van de gebruikte DSLAM. Hier is nog een exemplaar
zonder VPLUS in gebruik. Dus dit gaat er hopelijk ooit nog een keer uit,
alhoewel de uitrol van VPLUS gestaakt lijkt... Met een Vigor 165 zou
200Mbit dan moeten kunnen. En meer is beter :)

Ik zie nu dat ik i.t.t. wat ik eerder schreef toch m8 heb draaien
dus niet m4 of m5. Inderdaad die hebben interleaved. Ik heb vroeger
een tijd met m6 gewerkt tot die het ineens niet meer goed deed.

Miquel van Smoorenburg

2020-06-03 20:04:40 UTC

Permalink

Post by Coen
Het hangt erg af van de gebruikte DSLAM. Hier is nog een exemplaar
zonder VPLUS in gebruik. Dus dit gaat er hopelijk ooit nog een keer uit,
alhoewel de uitrol van VPLUS gestaakt lijkt... Met een Vigor 165 zou
200Mbit dan moeten kunnen. En meer is beter :)

Afhankelijk van het type DSLAM kan de kaart VPLUS, maar neemt
het dubbele resources in (dus de poort ernaast kan je niet
gebruiken), of er zit naast de gewone VVDSL kaarten een VPLUS
kaart in (die dan 2 sloten in beslag neemt). In beide gevallen
zal je verbinding dus niet zomaar VPLUS gaan doen als het niet
nodig is - het gebruikt meer resources, en in veel gevallen zal
een monteur eerst je aansluiting op een andere poort moeten zetten.

Mike.

Rob

2020-06-03 12:54:51 UTC

Permalink

Hier ook een vigor 130, met 3.8.4_m8 firmware. Ooit voor m8 gekozen om de
laagst mogelijke latency te krijgen (geen interleaving).

Welke versie optimaal is dat is in de loop van de tijd (in ieder geval
bij mij) veranderd. Waarschijnlijk als gevolg van firmware updates in
de DSLAM. Ik gebruik nu m5. Daarvoor inderdaad m8 en ook wel m4 geprobeerd
maar die werkte nooit zo goed.

Rob

2020-06-03 16:19:33 UTC

Permalink

Post by Rob

Hier ook een vigor 130, met 3.8.4_m8 firmware. Ooit voor m8 gekozen om de
laagst mogelijke latency te krijgen (geen interleaving).

Dit had ik op afstand bekeken in mijn logs maar ik heb me vergist, ik
werk inderdaad met m8 en daarvoor met m6.

Rob

2020-06-21 17:46:52 UTC

Permalink

Vanavond even herstarten (nu de harde thuiswerker niet storen) en dan
kijken wat dit op de lange termijn oplevert.

Ook op de lange termijn blijft het zo dat ik perse de Vigor een 'vdsl
reboot' moet geven als de ppp sessie weg was zonder een onderbreking van de
vdsl sessie, anders blijft PPPoE in discovery mode en gebeurt er nooit wat.
Ondanks allerlei aanpassingen aan holdoff. En ik zie met tcpdump ook echt
wel die aanpassingen terug.

En welke holdoff gebruik je dan? Het moet echt wel 5 a 10 minuten zijn
is mijn ervaring. Maar problemen heb ik sinds ik dat in mijn router
ingebouwd heb niet meer gezien.
(ik zet die hele PPPoE verbinding een tijd uit en daarna weer aan)

Coen

2020-06-21 22:15:10 UTC

Permalink

Ik was naar 1 minuut, ik stel het nu in op 5 minuten.
Vervelend dat dit nodig is, dit overkomt me nu eigenlijk pas de laatste
tijd.

Ik herken het probleem uit het verleden met sommige Vigor firmwares.
Maar ik heb het eigenlijk al in geen tijden meer gezien.
De lijn is hier tegenwoordig ook super stabiel.

Rob

2020-06-22 07:49:28 UTC

Permalink

Post by Coen

Ik was naar 1 minuut, ik stel het nu in op 5 minuten.
Vervelend dat dit nodig is, dit overkomt me nu eigenlijk pas de laatste
tijd.

Ik herken het probleem uit het verleden met sommige Vigor firmwares.
Maar ik heb het eigenlijk al in geen tijden meer gezien.
De lijn is hier tegenwoordig ook super stabiel.

Het heeft volgens mij niks te maken met de Vigor firmware, of je zou
het moeten hebben over een Vigor die zelf de PPPoE opzet, dan zou dat
kunnen.

Koos en ik hebben het over een situatie waarin een losse router of
PC zelf de PPPoE verbinding opzet "via" een Vigor modem dat als relay
ingesteld is. Dan heeft de modem firmware er niets mee van doen. Je
zou hooguit willen dat zo'n modem een simpel commando heeft om de VDSL
verbinding te resetten wat dan door de ppp laag gegeven kan worden als
het niet meer lukt een verbinding te maken.

Het probleem wordt getriggerd als de PPPoE verbinding uitvalt door een
probleem ergens in het transportnetwerk, en de VDSL verbinding gewoon
op blijft. Het lukt dan niet meer een nieuwe PPPoE verbinding op te
zetten omdat er in het netwerk elementen zitten die daar niet goed mee
omgaan en die denken dat je bezig bent met de vorige PPPoE verbinding
die niet meer bestaat. Dat is een bug, lijkt me.
Maar omdat de gebruikers van gecombineerde modem/routers hier geen
last van hebben heeft het natuurlijk een lage prioriteit om er iets aan
te doen.

Miquel van Smoorenburg

2020-06-22 10:25:59 UTC

Permalink

Post by Rob

Vanavond even herstarten (nu de harde thuiswerker niet storen) en dan
kijken wat dit op de lange termijn oplevert.

En welke holdoff gebruik je dan? Het moet echt wel 5 a 10 minuten zijn
is mijn ervaring. Maar problemen heb ik sinds ik dat in mijn router
ingebouwd heb niet meer gezien.

Ik was naar 1 minuut, ik stel het nu in op 5 minuten.
Vervelend dat dit nodig is, dit overkomt me nu eigenlijk pas de laatste
tijd.

Kan je je PPPoE pratend device vertellen dat die eerst een PADT stuurt
met het laatste PPPoE session-id voordat het PADIs gaat sturen?

(nooit getest, is maar een idee)

Mike.

Rob

2020-06-24 13:45:45 UTC

Permalink

Ik was naar 1 minuut, ik stel het nu in op 5 minuten.

Update: ook 5 minuten zorgde voor een nacht down.
Nu met de instelling op 7.5 minuut was afgelopen nacht het effect dat de
nacht door iedere keer de ppp sessie heel veel packetloss heeft en op een
bepaald moment herstart wordt.
Pas na een vdsl reboot krijg ik een stabiele sessie.
Volgens de rp-pppoe mailinglist zou de nieuwste versie iets meer doen om
oude sessies op te ruimen. Eens tijd maken om die te proberen binnenkort.

Oh heb jij iedere nacht problemen dan? Want dan is er wellicht iets
anders aan de hand, ik had die problemen maar heel zo nu en dan...

Ik kon ze wel reproduceren (door de ethernet verbinding tussen router
en modem evel los te trekken) maar het vanzelf optreden dat was alleen
bij storingen in het netwerk.

Rob

2020-07-01 08:27:36 UTC

Permalink

Patch[1] voor PADT on disconnect toegevoegd en nieuwe pppoe/pppd gebouwd,
maar de eerste keer ging het weer mis.

Ook handmatig een PADT voor de oude sessie sturen helpt niet.
Alleen een vdsl reboot hielp om weer actie te krijgen.

Ook een aantal minuten niets sturen werkt niet meer?

Ik denk dat er op jouw lijn iets anders gaande is want die onderbrekingen
heb ik al een tijd niet meer gehad. Laatste keer dat PPPoE is opgebouwd
hier was op 17 juni toen ik de router gereboot heb voor een update.

Rob

2020-07-02 13:38:26 UTC

Permalink

Post by Rob
Ik denk dat er op jouw lijn iets anders gaande is want die onderbrekingen
heb ik al een tijd niet meer gehad. Laatste keer dat PPPoE is opgebouwd
hier was op 17 juni toen ik de router gereboot heb voor een update.

Ik was nog eens aan het zoeken en toen kwam ik weer eens langs
https://www.haroldschoemaker.nl/2014/02/eigen-router-achter-een-xs4all-vdsl-aansluiting-2/
"De PPPoE-sessie met XS4ALL wordt opgezet over vlan 6. Het ligt daarom voor
de hand om het modem de vlan-tag alvast te laten strippen. In de praktijk
De Vigor 130 gaat er zelf met de PPPoE-sessie vandoor. (Dat verklaart
ook waarom de verbinding in de eerdere testopstelling niet robuust te
krijgen was: er ontstond blijkbaar een “wedstrijd” tussen het modem en de
router over welk van de twee als eerste de PPPoE-sessie kon krijgen.)"
Dus ik moet naar een config waarbij het modem untagged aan een ander vlan
hangt en tagged aan vlan 6, en vlan 6 op de correcte manier bij de router
vm terecht komt.
Als ik op de vigor de log van ppp login pogingen opvraag zijn die van net
na het beginmoment van de voorlaatste hik. Opvallend. De laatste hik was
midden in een videoconference dus die had ik heel gauw aangepakt.

Hoe stel je de Draytek dan in?
Bij mij staat ie zo dat hij zelf de VLAN tag toevoegt (de verbinding
met de computer is dus untagged zowel voor het beheer van de Draytek
als voor de PPPoE sessie) en in PPPoE/PPPoA staat ingesteld dat de
PPPoE client enabled is en PPPoE Passthrough for Wired LAN vinkje staat
ook aan. De rest van de info op dat scherm is allemaal niet ingevuld.

Bij General setup staat dus bij VDSL2 "Enable tag value 6 / 0".
De rest (ook IPv6!) staat allemaal op disabled.

Dan krijg ik dus wel die situatie van het niet kunnen opbrengen van
de PPPoE nadat die even down geweest is, en in de status staat dat
de boel offline is.

Maar als je dit met een Fritzbox doet dan heb je hetzelfde.

Wouter Smaal

2020-07-03 12:08:02 UTC

Permalink

On 7/3/2020 9:21 AM, Koos van den Hout wrote:

< knip>

OT:
Sinds kort gebruik ik (ook) news.eternal-september.org.

TKN:
Mij is opgevallen dat al jouw postings in de onderhavige thread op
eternal-september ontbreken. De postings van Rob, Coen en Miquel staan
er wel.

Rob

2020-07-04 09:03:13 UTC

Permalink

Post by Wouter Smaal
< knip>
Sinds kort gebruik ik (ook) news.eternal-september.org.
Mij is opgevallen dat al jouw postings in de onderhavige thread op
eternal-september ontbreken. De postings van Rob, Coen en Miquel staan
er wel.

Dan moet je bij eternal-september.org zijn denk ik.
Het komt wel vaker voor dat postings daar ontbreken, ze doen kennelijk
allerlei "checks" op headers die anderen niet doen.

A. Dumas

2020-07-04 11:49:13 UTC

Permalink

Post by Wouter Smaal

[...]

Mij is opgevallen dat al jouw postings in de onderhavige thread op
eternal-september ontbreken. De postings van Rob, Coen en Miquel staan
er wel.

Ja ik zag het ook. In tegenstelling tot een tijdje terug bij een andere
poster, zie ik ook niks vreemds aan de headers hier. Ik heb het gevraagd
in e-s.support.

Rob

2020-07-04 09:01:41 UTC

Permalink

Post by Rob
Hoe stel je de Draytek dan in?

Mijn huidige settings (ik heb nog niets gewijzigd) zijn zichtbaar op
https://imgur.com/a/oEmI1aI
Ik heb dus ook nog de optie om te kiezen tussen een 'Customer' vlan tag en
een 'Service' vlan tag.

Dat moet Customer zijn.

Post by Rob
Bij mij staat ie zo dat hij zelf de VLAN tag toevoegt (de verbinding
met de computer is dus untagged zowel voor het beheer van de Draytek
als voor de PPPoE sessie) en in PPPoE/PPPoA staat ingesteld dat de
PPPoE client enabled is en PPPoE Passthrough for Wired LAN vinkje staat
ook aan. De rest van de info op dat scherm is allemaal niet ingevuld.
Bij General setup staat dus bij VDSL2 "Enable tag value 6 / 0".
De rest (ook IPv6!) staat allemaal op disabled.
Dan krijg ik dus wel die situatie van het niet kunnen opbrengen van
de PPPoE nadat die even down geweest is, en in de status staat dat
de boel offline is.

Volgens die pagina op haroldschoemaker.nl (ondertussen ook wat jaartjes oud
en met een oudere draytek firmware) moet dus de tag insertion helemaal uit.

Het nadeel is dan dat je geen 1500 byte MTU meer kunt halen omdat de
ethernet MTU niet genoeg is om EN de PPPoE header EN de VLAN header
te transporteren. Het is het een of het ander.

Maarten Carels

2020-07-06 07:54:41 UTC

Permalink

Post by Rob
Het nadeel is dan dat je geen 1500 byte MTU meer kunt halen omdat de
ethernet MTU niet genoeg is om EN de PPPoE header EN de VLAN header
te transporteren. Het is het een of het ander.

Daar hebben we RFC4648 voor..
XS4ALL BRAS ondersteunt dat, net als anderen

--maarten

Rob

2020-07-06 08:56:31 UTC

Permalink

Post by Maarten Carels

Post by Rob
Het nadeel is dan dat je geen 1500 byte MTU meer kunt halen omdat de
ethernet MTU niet genoeg is om EN de PPPoE header EN de VLAN header
te transporteren. Het is het een of het ander.

Daar hebben we RFC4648 voor..
XS4ALL BRAS ondersteunt dat, net als anderen

Die moest ik even opzoeken, ik zie even niet wat die toevoegt in deze.
(ik dacht even zou dat een ethernet fragmentatie/reassembly protocol
zijn ofzo)

Ik neem aan dat je RFC4638 bedoelt, maar het probleem waar ik op wilde
wijzen is dat de ethernet MTU van de Draytek 130 niet voldoende is
om een frame van 1500 bytes plus PPPoE header (8 bytes) plus VLAN tag
(4 bytes) te transporteren, althans daar liep ik tegenaan. Untagged
PPPoE werkt wel, dus MTU is 1508 denk ik. Zou 1512 moeten zijn.

Uit een reactie van Koos begreep ik dat het bij hem wel werkt dus
wellicht is dat ooit eens gefixed in een firmware update van Draytek.

richard lucassen

2020-07-06 09:15:16 UTC

Permalink

On 06 Jul 2020 08:56:31 GMT

Post by Rob
Ik neem aan dat je RFC4638 bedoelt, maar het probleem waar ik op wilde
wijzen is dat de ethernet MTU van de Draytek 130 niet voldoende is
om een frame van 1500 bytes plus PPPoE header (8 bytes) plus VLAN tag
(4 bytes) te transporteren, althans daar liep ik tegenaan. Untagged
PPPoE werkt wel, dus MTU is 1508 denk ik. Zou 1512 moeten zijn.
Uit een reactie van Koos begreep ik dat het bij hem wel werkt dus
wellicht is dat ooit eens gefixed in een firmware update van Draytek.

Ik vrees van niet en ik heb Draytek gevraagd of de ethernet MTU van
de 165 inmiddels al groter was dan 1508 maar daar kwam een ontkennend
antwoord op (of diegene begreep niet waar het om ging, dat kan ook
natuurlijk)

--
richard lucassen
https://contact.xaq.nl/

Maarten Carels

2020-07-06 11:00:05 UTC

Permalink

Post by Rob

Post by Maarten Carels

Post by Rob
Het nadeel is dan dat je geen 1500 byte MTU meer kunt halen omdat de
ethernet MTU niet genoeg is om EN de PPPoE header EN de VLAN header
te transporteren. Het is het een of het ander.

Daar hebben we RFC4648 voor..
XS4ALL BRAS ondersteunt dat, net als anderen

Die moest ik even opzoeken, ik zie even niet wat die toevoegt in deze.
(ik dacht even zou dat een ethernet fragmentatie/reassembly protocol
zijn ofzo)

Die bedoelde ik ook, dislectical fingers...

Klopt, je hele keten moet die iets grotere pakketten aankunnen.
Hardwarematig moet dat in het algemeen kunnen.

Post by Rob
Uit een reactie van Koos begreep ik dat het bij hem wel werkt dus
wellicht is dat ooit eens gefixed in een firmware update van Draytek.

Dat zou netjes zijn.

--maarten

Rob

2020-07-06 17:47:10 UTC

Permalink

Post by Maarten Carels

Klopt, je hele keten moet die iets grotere pakketten aankunnen.
Hardwarematig moet dat in het algemeen kunnen.

Ja zoals Coen zegt (en Koos) werkt het nu wel.
Overigens werkt dit op de AVM Fritzbox niet. Ja je kunt wel RFC4638
aanzetten in het modem zelf, maar als je die PPPoE relay wilt doen dan
kun je hem wel op transparant zetten maar de ethernet MTU kun je nergens
hoger zetten.

Overigens werkt ook niet alle hardware, hoor. Ik heb hier zelf in mijn PC
een Broadcom NetXtreme BCM5721 adapter zitten en die kan niet hoger dan
MTU 1500 (maar wel met VLAN dus eigenlijk 1504). MTU 1512 dat weigert
dat ding, of in ieder geval de Linux driver.
De ethernet poorten in mijn router gaan tot 1598 dus geen probleem...

Coen

2020-07-06 17:05:44 UTC

Permalink

1500 bytes over een tagged verbinding tussen modem en router kan
tegenwoordig prima:

$ ping -M do -s 1472 -c 2 -4 ping.xs4all.nl
PING ping.xs4all.nl (194.109.6.8) 1472(1500) bytes of data.
1480 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=1 ttl=61 time=7.93 ms
1480 bytes from ping.xs4all.nl (194.109.6.8): icmp_seq=2 ttl=61 time=8.20 ms

# ps ax | grep ppp
3932 ? Ss 0:00 /usr/sbin/pppd call vdsl
4130 ? S 0:00 sh -c pppoe -I eth3.6

Modem firmware 3.8.4.

groet,
Coen

Rob

2020-07-06 17:39:16 UTC

Permalink

Post by Coen
1500 bytes over een tagged verbinding tussen modem en router kan
Modem firmware 3.8.4.

Ok, wellicht is het gefixed! Ik werk nog met 3.8.3 maar ik heb ook
oudere versies gedraaid, ik denk vanaf 3.7.8.1 als ik in mijn firmware
collectie kijk. Ooit werkte dit in ieder geval niet goed.

Coen

2020-07-06 19:18:35 UTC

Permalink

Post by Rob
Ok, wellicht is het gefixed! Ik werk nog met 3.8.3 maar ik heb ook
oudere versies gedraaid, ik denk vanaf 3.7.8.1 als ik in mijn firmware
collectie kijk. Ooit werkte dit in ieder geval niet goed.

Tot 1512 bytes naar het modem lijkt het geen probleem:

$ ping -M do -s 1484 -c 2 -4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 1484(1512) bytes of data.
1492 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.325 ms
1492 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.307 ms

(Modem is 192.168.1.1)

Groter krijg ik geen antwoord meer op.

Rob

2020-07-06 21:32:03 UTC

Permalink

Post by Coen

$ ping -M do -s 1484 -c 2 -4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 1484(1512) bytes of data.
1492 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.325 ms
1492 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.307 ms
(Modem is 192.168.1.1)
Groter krijg ik geen antwoord meer op.

Aha dat is hier ook zo... dus ik denk dat het in 3.8.3 al is opgelost.

Coen

2020-07-06 19:29:58 UTC

Permalink

Vanavond maar eens een modem5 ('optimized for KPN') firmware gekozen.
Geeft iets meer latency, maar als ik daarvoor terugkrijg dat de verbinding
stabieler is doe ik het er voor.

Ik herken je probleem van vroeger....
Het is hier gelukkig voorbij. Grootse verschil heeft denk ik voor mij
het verwijderen van het Alcatel ADSL splitter gemaakt. (Die knoopte wat
touwtjes aan elkaar waardoor het er niet zomaar tussenuit kon) Met dat
ding er nog tussen had ik vaak VDSL disconnets en het niet meer starten
van ppp daarna. Tegenwoordig allemaal super solide. In je syslog zou je
kunnen zien of de Vigor ook van Showtime status veranderd.

M5 en M6 firmware doen interleaved ipv fast op de uplink waardoor de
lantency veel hoger is.

Over M8 heb ik mijn admin log staan:
"11-07-2019 switch from 3.8.3_m8 to 3.8.4_m4 (De 3.8.3_m8 geeft de
laatste dagen veel ppp errors. VDSL connect blijft staan, maar ppp komt
niet meer op tot het modem herstart is)"

Inmiddels ben ik dus al bijna een jaar happy met M4. Maar de chipset in
de straatkast kan het verschil maken. Firmware in de straatkast en
omstandigheden op de lijn ook. Misschien is er nog wel iets anders
verandert buitenshuis hier waardoor ik denk dat ik het zelf opgelost heb...

Coen

2020-07-02 17:36:08 UTC

Permalink

Hoi,

Als ik op de vigor de log van ppp login pogingen opvraag zijn die van net
na het beginmoment van de voorlaatste hik. Opvallend. De laatste hik was
midden in een videoconference dus die had ik heel gauw aangepakt.

De Vigor kan in een paar varianten ingesteld worden:

Met 'MPoA / Static or dynamic IP' en 'Bridge Mode'. Hierbij staakt de
mtu van je packets op 1496 bytes. De PPP client van de Vigor doet niets.

Met 'PPPoE / PPPoA Client Mode' en 'PPPoE Pass-through for Wired Lan'.
Hierbij wordt de PPP client wel wakker, als hij weet op welk vlan de
verbinding zit. Dus als bij 'General Setup' onder VDSL2 ingesteld staat
op 6, dan wordt de client actief. Zet je deze op 0 of op disabled dan
gaat de client uit. (Want geen kennis over welk vlan) Er is dan ook nog
een verschil tussen VDSL disabled (geen vlan support) of Enabled op vlan
0. In dat laatste geval worden alle vlan tags doorgeven van 'lan' naaar
'wan' en vice versa.

Als je de remote syslog van de Vigor configureert naar je server toe dan
zie je een hoop informatie over zijn doen en laten in je log
verschijnen. In ieder geval elke minuut de status van VDSL sync:

Jul 2 19:28:50 192.168.1.1 Vigor: ADSL_Status:[Mode=17A States=SHOWTIME
UpSpeed=33028000 DownSpeed=111214000 SNR=5 Atten=12 ]

En met VLAN kennis zie je hem actief verbinding maken:

Jul 2 19:28:43 192.168.1.1 Vigor: PAP Login Failed (PPPoA) -
Jul 2 19:28:43 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADT ID:4785
Jul 2 19:28:43 192.168.1.1 Vigor: WAN1 PPPoE ==> Protocol:LCP(c021)
TermReq Identifier:0x01 ##
Jul 2 19:28:43 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADT ID:4785
Jul 2 19:28:49 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADT ID:4785
Jul 2 19:28:50 192.168.1.1 Vigor: ADSL_Status:[Mode=17A States=SHOWTIME
UpSpeed=33028000 DownSpeed=111214000 SNR=5 Atten=12 ]
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADI ID:0
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE <== V:1 T:1 PADO ID:0
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADR ID:0
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE <== V:1 T:1 PADO ID:0
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE <== V:1 T:1 PADS ID:4785
Jul 2 19:28:53 192.168.1.1 Vigor: PPP Start (PPPoA)
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE ==> Protocol:LCP(c021)
ConfReq Identifier:0x00 MRU: 1500 ##
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE <== Protocol:LCP(c021)
ConfReq Identifier:0x18 Authentication Type: PAP Magic Number:
0x16d578bd ##
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE ==> Protocol:LCP(c021)
ConfAck Identifier:0x18 Authentication Type: PAP Magic Number:
0x16d578bd ##
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE <== Protocol:LCP(c021)
ConfAck Identifier:0x00 MRU: 1500 ##
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE ==> Protocol:PAP(c023)
Authenticate-Request Identifier:0x53 Peer-ID: Password: ##
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE <== Protocol:PAP(c023)
Authenticate-Nak Identifier:0x53 Message: ##
Jul 2 19:28:53 192.168.1.1 Vigor: PAP Login Failed (PPPoA) -
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADT ID:4785
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE ==> Protocol:LCP(c021)
TermReq Identifier:0x01 ##
Jul 2 19:28:53 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADT ID:4785
Jul 2 19:28:59 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADT ID:4785
Jul 2 19:29:03 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADI ID:0
Jul 2 19:29:03 192.168.1.1 Vigor: WAN1 PPPoE <== V:1 T:1 PADO ID:0
Jul 2 19:29:03 192.168.1.1 Vigor: WAN1 PPPoE ==> V:1 T:1 PADR ID:0
Jul 2 19:29:03 192.168.1.1 Vigor: WAN1 PPPoE <== V:1 T:1 PADO ID:0
Jul 2 19:29:03 192.168.1.1 Vigor: WAN1 PPPoE <== V:1 T:1 PADS ID:1281
Jul 2 19:29:03 192.168.1.1 Vigor: PPP Start (PPPoA)
Jul 2 19:29:03 192.168.1.1 Vigor: WAN1 PPPoE ==> Protocol:LCP(c021)
ConfReq Identifier:0x00 MRU: 1500 ##
Jul 2 19:29:03 192.168.1.1 Vigor: WAN1 PPPoE <== Protocol:LCP(c021)
ConfReq Identifier:0x20 Authentication Type: PAP Magic Number:
0x4c8abbb0 ##
Jul 2 19:29:03 192.168.1.1 Vigor: WAN1 PPPoE ==> Protocol:LCP(c021)
ConfAck Identifier:0x20 Authentication Type: PAP Magic Number:
0x4c8abbb0 ##

Is wel een beetje log vervuiling, maar dat nemen we maar voor lief. Ik
moet weer even omschakelen naar VLAN op de router zoals je ziet.

Helemaal transparant en eenvoudig is het apparaat dus niet.

groet,
Coen