7581 oeps ....

[Rudi]

Hallo Allemaal

(Hallo Maarten (Carels), heb jij een "lijntje" met AVM ook voor niet
ADSL gerelateerde dingen ?!)

Hier een weekje mijn Nieuwe 7581 152.06.85 DECT 5.32 in gebruik.
Ik gebruik DECT met 4 handsets, 2 st. Siemens Gigaset SL1 (oudjes)
en 2 st A415 (nieuwere). DECT toestellen hebben prima ontvangst

De volgende vreemde dingen vallen op.

- Ik heb nog niet de (geluids) problemen gehad met de SL1 toestellen.
- Ik heb recentelijk tot 2 maal toe in een gesprek met de A415 toestel een
heleboel gekraak en gestoor gehoord (gesprek naar extern GSM)

Ik heb de eco mode op de 7581 uit staan en de expanded security aan.
verder zie ik dat de A415 zowel G.726 als G.722 doen, terwijl de SL1s
Slechts G726 ondersteunen (en geen eco of expanded security)

Ik heb een vaag vermoeden dat het DECT probleem bij mij slechts bij de
A415 optreedt. ....

Verder vallen mij 2 andere bugjes op:

-1. Bij het gebruik van (comet) radiatorthermostaten zie ik in de "smart home"
overview, niet het schakelaartje <aan>/<uit> en het mode veld is niet ingevuld.

-2. Bij het aanmaken van een "call diversion" (doorschakel) regel, is deze
vervolgens *altijd* ge-enabled, als je het <enable> vinkje uit zet,
blijft bij een
reload deze aan staan.

- Is er behalve een "oude" 7360 achter mijn 7581 hangen iets wat ik voor mijn
DECT issues kan proberen ??
- Is dit het juiste kanaal om de andere (twee) bugs te rapporteren,
en/of is daar
een workaround voor ?
- Kan ik iets doen om te helpen debuggen / oplossen ?

THX
Rudi

[Erik]

On Mon, 22 Jan 2018 19:55:01 +0100, Rudi <nom...@xs4all.nl> wrote:

>Ik heb de eco mode op de 7581 uit staan en de expanded security aan.
>verder zie ik dat de A415 zowel G.726 als G.722 doen, terwijl de SL1s
>Slechts G726 ondersteunen (en geen eco of expanded security)
>
>Ik heb een vaag vermoeden dat het DECT probleem bij mij slechts bij de
>A415 optreedt. ....

Dat vervelende codec probleem heb ik ook met de 7490

Doet zich voornamelijk voor bij nieuwe centrales die ook een keuze menu hebben.
Ik hoor hun wel, zij mij niet.

Na een onderzoek bij AVM van de trace bestanden kwam de volgende conclusie.
- - - - -
uit de ons toegestuurde gegeven hebben wij een probleem kunnen vinden.
Alles duit op een zog, Codec Probleem. De Provider stuurt een g729 DTMF Stream, maar van tevoren is er een g711 Stream afgesproken.
Nu lijkt het erop, dat de g711 Stream door de Provider niet gecodeerd kan worden, omdat de Provider van een g729 uitgaat.
Dus is dit een fout die buiten de FRITZ!Box optreed.
U kunt nu gewoon andere DTMF-Settings in de FRITZ!Box gaan testen.
- - - - -

Ik vroeg nog, of ze iets in de fritzbox in konden bouwen die de fout van de tegenpartij opvangt.
Het antwoord was NEE.

Ze konden me ook geen advies geven, welke DTMF settings beter zijn.
Hier staat de DTMF nu op 'Inband' voor beide voip providers.

Erik

[kees6238]

Ik had/heb ook allerlei vage problemen met fritzboxen, de mensen bij
AVM zijn best behulpzaam en geduldig en spreken en schrijven ook
nederlands

Ik heb hier nu een 7360 met verschillende "oudere" dects er aan zonder
probemen, alhoewel, onlangs tot 2x na het kiezen van een doorkeuzemenu
geen geluid van mij naar tegen partij, 3e x geenkeuze gemaakt toen
werkte het wel . . .
kan toeval zijn

NB, voor zo ver je het nog weet of gedaan hebt, in de push-email kun
je zien wat de codec (ed) van je gesprek was.

[Erik]

On Thu, 25 Jan 2018 22:46:14 +0100, kees6238 <kees...@xs4all.nl> wrote:

>Ik had/heb ook allerlei vage problemen met fritzboxen, de mensen bij
>AVM zijn best behulpzaam en geduldig en spreken en schrijven ook
>nederlands
>
>Ik heb hier nu een 7360 met verschillende "oudere" dects er aan zonder
>probemen, alhoewel, onlangs tot 2x na het kiezen van een doorkeuzemenu
>geen geluid van mij naar tegen partij, 3e x geenkeuze gemaakt toen
>werkte het wel . . .
>kan toeval zijn

Is geen toeval, heb ik irritant vaak.
Kreeg ook geen duidelijk advies, wat ik moet proberen ipv 'DTMF: Inband'

>
>NB, voor zo ver je het nog weet of gedaan hebt, in de push-email kun
>je zien wat de codec (ed) van je gesprek was.

Die gegevens zijn niet voldoende om dat probleem in beeld te krijgen.
Vandaar dat er een trace naar AVM gegaan is, van mij.

[Erik]

On Fri, 26 Jan 2018 00:50:28 +0100, Erik <id.4...@xs4all.nl> wrote:

>Kreeg ook geen duidelijk advies, wat ik moet proberen ipv 'DTMF: Inband'

Heb het nu op de gok op automatisch gezet.

[BUSSIE]

Heb ik zal jaren op DTMF staan (met diverse verschillende Fritzboxen)
en dat gaat tot nu toe vlekkeloos.

[Maarten Carels]

Er is een DECT probleem, maar het is bijzonder lastig om dat op een
zodanige manier te reproduceren dat er debugging uit te krijgen is. We
hebben bij een XS4ALL medewerker (die het probleem ook regelmatig heeft)
een speciaal aangepaste 7581 staan, sindsdien treedt het niet meer op.
Niet alle gebruikers van de 7581 hebben het probleem, de bij de meeste
gaat het goed.

Dat het met nieuwe handsets wel, en met oude niet optreedt klopt met
andere waarnemingen, het lijkt met de G.722 codec te maken te hebben.

Wat dat betreft is het wachten op wat AVM vindt.

De andere zaken die Rudi noemde (Call diversion en radiatorthermostaten)
staan hier los van, ik zal proberen wat we daarin kunnen reproduceren.
Contacten met AVM zijn er in ieder geval.

--maarten

[groenlinks...@gmail.com]

Op vrijdag 26 januari 2018 15:54:09 UTC+1 schreef Maarten Carels:

En niet te vergeten dat de eco-modus niet werkt

[Dirk T. Verbeek]

Op 26-01-18 om 17:15 schreef groenlinks...@gmail.com:

> En niet te vergeten dat de eco-modus niet werkt

Wat met name voor een groenlinkser onaanvaardbaar is.

[Luuk]

On 26-01-18 15:53, Maarten Carels wrote:
> Niet alle gebruikers van de 7581 hebben het probleem, de bij de meeste
> gaat het goed.
>

Is dat zo?
Of melden de meeste mensen deze problemen niet....

Ik kreeg van XS4ALL het 'advies' om maar het eigen basisstation van
Siemens te gaan gebruiken i.p.v. het ingebouwde DECT-spul van AVM.

Over 'eco' gesproken ... ;)

[Joe]

On Sat, 27 Jan 2018 10:39:22 +0100, Luuk <lu...@invalid.lan> wrote:

>Of melden de meeste mensen deze problemen niet....
>
>Ik kreeg van XS4ALL het 'advies' om maar het eigen basisstation van
>Siemens te gaan gebruiken i.p.v. het ingebouwde DECT-spul van AVM.
>

Dat lost NIET het DTMF probleem op. Ik gebruik 2 DECT basisstations aan de 7581 (Gigaset en Philips), bij sommige verbindingen
wordt de DTMF niet herkend en bel ik maar mobiel (erg beroerd want slechte mobiele dekking). Ik heb hierover inderdaad nog nooit
geklaagd bij XS4all, over alles klagen heeft zo weinig zin.

Heb wel hottere issues aangekaart zoals een VDSL die niet op snelheid wil blijven, maar, fourstack zegt dat het klopt - daarmee is
de kous af. Wacht met smart op (weer uitgesteld) glasvezel.

[Maarten Carels]

Klagen is een ding, meestal negatief ("het werkt niet!", of erger
"Natuurlijk werkt het weer niet")

Iets anders is bugs melden, zeker als dat vergezeld wordt van een
duidelijk verhaal wat er wanneer mis gaat, zoiets als "als ik zo doe,
doet het hier pijn".
Daarmee kan XS4ALL en/of AVM aan de slag.
Om een bug op te lossen, is het om te beginnen nodig dat je weet hoe je
het verschijnsel reproduceert, dan kan je zien wat er precies mis gaat,
en dan ken je het oplossen.
Zeker als het om iets gaat dat alleen onder bepaalde omstandigheden
optreedt is alleen met meldingen (en wat hulp van een klant) op te
lossen.

Dus...

--maarten

[Rob]

Maarten Carels <mca...@xs4all.nl> wrote:
> Klagen is een ding, meestal negatief ("het werkt niet!", of erger
> "Natuurlijk werkt het weer niet")
>
> Iets anders is bugs melden, zeker als dat vergezeld wordt van een
> duidelijk verhaal wat er wanneer mis gaat, zoiets als "als ik zo doe,
> doet het hier pijn".
> Daarmee kan XS4ALL en/of AVM aan de slag.

Ok komt er een: als ik probeer MTU 1500 over PPPoE te doen dan doet
het pijn. max MTU is 1492, RFC4638 implementatie ontbreekt.

Duidelijk verhaal, aan de slag, zou ik zeggen!

[rene....@gmail.com]

Op maandag 29 januari 2018 09:56:59 UTC+1 schreef Maarten Carels:

Ok, nog 1, hoewel reeds genoemd:
Toen ik nog de FB7390 had werkte de eco modus daarop met de daarop aangesloten Fritzfonen prima. Altijd als ingeschakeld.
Nadat ik de FB7390 heb vervangen door een FB7581 werkt de Eco-modus nooit, of het nu ingeschakeld is of niet. Met nog steeds dezelfde Fritzfonen.

[Maarten Carels]

Maarten Carels <mca...@xs4all.nl> wrote:
> Er is een DECT probleem, maar het is bijzonder lastig om dat op een
> zodanige manier te reproduceren dat er debugging uit te krijgen is. We
> hebben bij een XS4ALL medewerker (die het probleem ook regelmatig heeft)
> een speciaal aangepaste 7581 staan, sindsdien treedt het niet meer op.
> Niet alle gebruikers van de 7581 hebben het probleem, de bij de meeste
> gaat het goed.
>
> Dat het met nieuwe handsets wel, en met oude niet optreedt klopt met
> andere waarnemingen, het lijkt met de G.722 codec te maken te hebben.

Iets nauwkeuriger (na contact met AVM):

-Alleen bij SD gesprekken Dus DECT G726 naar VoIP G711
-Dus NIET bij G722 (HD)(DECT stuurt G722, dus geen Codec translatie)
-Dit betekent dat FRITZ!Box -> FRITZ!Box via voip en beide een HD Dect
(een AVM telefoon) dit altijd prima gaat zonder storingen
-Probleem komt vaak pas na enkele dagen
-Na reset van de reset van de box is het probleem vaak weer een paar
dagen weg.
-Debug FW (alleen Telnet console aan) heeft het probleem nog niet weten
te reproduceren.

--maarten

[Maarten Carels]

Daar kan ik simple iets over zeggen, dat request ligt al lang bij AVM.
Op dit moment is de status:
* Zit in de code van de 7581, niet in de GUI. Als je het (door de config
te bewaren, aan te passen, checksum aan te passen, terug te laden) in je
box krijgt werkt het feilloos.
* In de andere recente boxen (5490, 7490, 7590, broadcom based) zit het
nog niet.

We blijven duwen...

--maarten

[Maarten Carels]

<rene....@gmail.com> wrote:

[...]

> Ok, nog 1, hoewel reeds genoemd:
> Toen ik nog de FB7390 had werkte de eco modus daarop met de daarop
> aangesloten Fritzfonen prima. Altijd als ingeschakeld.
> Nadat ik de FB7390 heb vervangen door een FB7581 werkt de Eco-modus nooit,
> of het nu ingeschakeld is of niet. Met nog steeds dezelfde Fritzfonen.

Gaan we naar kijken.

--maarten

[Rob]

Tja dit is het type wijziging dat bij de concurrentie een paar maanden
na de melding (en het antwoord "ja dat is nuttig, gaan we doen!") gewoon
in de release zit. Maar goed we blijven gewoon hopen.
(ook dat het dan nog in de 7360v2 komt die XS4ALL me ter beschikking
heeft gesteld maar die nu ongebruikt in de kast ligt)

[Ruud Uphoff]

Op 29-01-2018 om 09:56 schreef Maarten Carels:

Heeft bugs melden dan toch zin? Helaas is ook XS4ALL afgedaald naar de
moderne helpdesk die niet in staat is tot LEZEN. Dat laatste begrip, in
hoofdletters om stemverheffing te virtualiseren, is een activiteit die
volgens ter zake kundigen, 80% van de geletterde werelbevolking niet
machtig is.

Na twee keer een vriendelijk en beleefd, maar daarom niet minder dom
antwoord heb ik dat opgegeven. Ook bij Xs4ALL bestaat lezen niet uit het
bestuderen van een tekst, zonder dat de lezer zijn brein laat triggeren
door een paar kreten die hij herkent, zonder die de context van het
geheel te plaatsen.

Maar ik zal nog een poging wagen.

--
Met vr. gr,
Ruud Uphoff

[Ruud Uphoff]

Op 29-01-2018 om 09:56 schreef Maarten Carels:

FRITZ!Box 7581 als DECT basisstation met 2x FRITZ!Fon MT-F
FOUT: Ik ben voor de "andere kant" meestal onverstaanbaar door gekraak.
En nee, dat ligt niet aan mijn telefoons. Als work around werkt mijn
eigen 7390 nu als IP-telefoon en daar bestaat het probleem niet.

Per telefoon onder "Telephony Device Features":
"HD Telephony".
Instelling maakt geen verschil. (Eco etc. staat uit)

Equalizer Settings
Kolom "Bass" geen instelling zichtbaar indien anders dan "normal"

Calling line identification restriction (CLIR)
werkt niet voor SIP van XS4all.

Van het laatste, (CLIR) die fout ligt bij XS4ALL, niet bij AVM. Ook
nummer kiezen als *31#<nummer> werkt anders dan de klant mag verwachten
niet. *31# staat in de documentatie van FRITZ!Box en behoort dus zonder
meninkje uiten gewoon te werken.
Maar melding aan de helpdesk inclusief hoe te verhelpen, leverde geen
professioneel antwoord op, wel klantvriendelijk gezwets. De installatie
kan gewoon in de configuratie aangepast worden.

Telephonie => CallDiversion uitschakelen door het vinkje te wissen: Na
weer inloggen in de GUI staat het vinkje weer aan, maar is het eerste
cijfer van het telefoonnummer verminkt. Om weer in te schakelen moet je
het nummer herstellen.

Home Network => Home Network Overview => Network Connections
De kolom "Connection" geeft onjuiste informatie. Dat is al sinds de
oerversie aan AVM bekend, maar kennelijk heeft men daar zodanig
minachting voor de klant, dat het niet even wordt verholpen. En ja: het
is zeer hinderlijk.

Ook "cosmetische" fouten horen niet te bestaan. Soms droom ik dat ik
mijn oude functie (QA) bij AVM mag uitoefenen. Ik deel links en rechts
verbale rotschoppen uit": waar halen jullie de gore moed vandaan, om een
product zo af te leveren aan de klant?

Maar shit! Op dat moment wordt ik wakker. ;-(

[Ruud Uphoff]

Op 29-01-2018 om 13:24 schreef Maarten Carels:

> Maarten Carels <mca...@xs4all.nl> wrote:
>> Er is een DECT probleem, maar het is bijzonder lastig om dat op een
>> zodanige manier te reproduceren dat er debugging uit te krijgen is. We
>> hebben bij een XS4ALL medewerker (die het probleem ook regelmatig heeft)
>> een speciaal aangepaste 7581 staan, sindsdien treedt het niet meer op.
>> Niet alle gebruikers van de 7581 hebben het probleem, de bij de meeste
>> gaat het goed.
>>
>> Dat het met nieuwe handsets wel, en met oude niet optreedt klopt met
>> andere waarnemingen, het lijkt met de G.722 codec te maken te hebben.
>
> Iets nauwkeuriger (na contact met AVM):
>
> -Alleen bij SD gesprekken Dus DECT G726 naar VoIP G711
> -Dus NIET bij G722 (HD)(DECT stuurt G722, dus geen Codec translatie)
> -Dit betekent dat FRITZ!Box -> FRITZ!Box via voip en beide een HD Dect
> (een AVM telefoon)

Laat ik nu met alleen maar AVM telefoons toch echt flink last hebben van
onverstaanbare verbindingen. Zie verderop in deze draad.

dit altijd prima gaat zonder storingen
> -Probleem komt vaak pas na enkele dagen
> -Na reset van de reset van de box is het probleem vaak weer een paar
> dagen weg.

Ja. Herkenbaar. Maar dus ook met een FRITZ!Fon MT-F.

> -Debug FW (alleen Telnet console aan) heeft het probleem nog niet weten
> te reproduceren.
>
> --maarten
>

[rudi]

Bedankt Maarten,

Ik begrijp dat de Call diversion en radiatorthermostaten niet
gerelateerd zijn aan
het DECT probleem, ik heb al verschillende dingen geprobeerd, maar het (DECT
issue) niet duidelijker kunnen pinpointen (qua reproduceerbaarheid).

Een ander dingetje wat ik in mijn fritz heb ontdekt is dat als je een
aantal thermostaten
in een groep plaatst, vervolgens daar een tijds (dag-nacht) schema op
zet met per
dag een andere periode van dagtemp, lijkt het dat wanneer je met de
hand de temp
"overruled" op bijvoorbeeld woensdag ochtend in de dagperiode, dit weer
ongedaan
lijkt te worden op de (eerstkomende) schakel*tijd* (die niet perse op
de woensdag hoeft
te vallen) ongeacht de dag.

vb, ik heb op dinsdag een dag temp ingesteld vanaf 15:00-22:00, op
woensdag dagtemp
08:00-22:00. nu zet ik op woensdag om 09.00 de temp handmatig (met het
<-> knopje)
terug naar de nachtwaarde, en lijkt hij om 15:00 weer "vanzelf" naar
dag te gaan.

Ik moet dit nog eens beter testen (kost tijd), maar vermoed dit gedrag,
wat uiteraard niet
volgens de regeltjes is :-)

Ondertussen ga ik kijken of ik voor de vermeende bugs wat meer info kan
verzamelen.

Thanks again !, verder: 7581: prima ding !

Rudi

[Maarten Carels]

rudi <nom...@xs4all.nl> wrote:
[...]

> Ik begrijp dat de Call diversion en radiatorthermostaten niet
> gerelateerd zijn aan
> het DECT probleem, ik heb al verschillende dingen geprobeerd, maar het (DECT
> issue) niet duidelijker kunnen pinpointen (qua reproduceerbaarheid).

DECT probleem heeft te maken met interactie tussen verschillende codecs,
maar is tot nu toe nog niet onder gecontroleerde omstandigheden
gereproduceerd. We weten dat het er is, AVM weet dat het er is, AVM
zoekt, maar wat het veroorzaakt is er nog niet uit. Een fix is er dus
ook nog niet. Helaas...

> Een ander dingetje wat ik in mijn fritz heb ontdekt is dat als je een
> aantal thermostaten in een groep plaatst, vervolgens daar een tijds
> (dag-nacht) schema op zet met per dag een andere periode van dagtemp,
> lijkt het dat wanneer je met de hand de temp "overruled" op bijvoorbeeld
> woensdag ochtend in de dagperiode, dit weer ongedaan lijkt te worden op de
> (eerstkomende) schakel*tijd* (die niet perse op de woensdag hoeft te
> vallen) ongeacht de dag.
>
> vb, ik heb op dinsdag een dag temp ingesteld vanaf 15:00-22:00, op
> woensdag dagtemp 08:00-22:00. nu zet ik op woensdag om 09.00 de temp
> handmatig (met het <-> knopje) terug naar de nachtwaarde, en lijkt hij om
> 15:00 weer "vanzelf" naar dag te gaan.
>
> Ik moet dit nog eens beter testen (kost tijd), maar vermoed dit gedrag,
> wat uiteraard niet volgens de regeltjes is :-)

Dit klinkt als iets dat in Berlijn (of Wijchen) redelijk eenvoudig te
reproduceren moet zijn. Gaat hier op de lijst....

> Ondertussen ga ik kijken of ik voor de vermeende bugs wat meer info kan
> verzamelen.

Dank!

--maarten

[Erik]

On Tue, 30 Jan 2018 10:42:06 +0100, mca...@xs4all.nl (Maarten Carels) wrote:

> We weten dat het er is, AVM weet dat het er is, AVM
>zoekt, maar wat het veroorzaakt is er nog niet uit. Een fix is er dus
>ook nog niet. Helaas...

Die indruk heb ik niet.
De uitleg die ik kreeg van AVM: dat het een fout is een bepaald type bedrijfcentrale.
Die schakelt de codec niet correct om, na verlaten DTMF keuze menu.

AVM doet niets, omdat ze zich aan de norm houden.

Erik

[Louis Lagendijk]

Beste Maarten
In welke versie van de firmware voor de 7581 zit dit? Ik heb sinds kort
een edgrouter achter de 7581 staan en zou graag RFC4638 activeren. Gaat
dat ook werken voot de MTU van 1508 op de externe interface van de 7581?

/Louis

[Louis Lagendijk]

On 01/29/2018 01:31 PM, Maarten Carels wrote:

> Rob <nom...@example.com> wrote:
>
>> Maarten Carels <mca...@xs4all.nl> wrote:

>>
>> Ok komt er een: als ik probeer MTU 1500 over PPPoE te doen dan doet
>> het pijn. max MTU is 1492, RFC4638 implementatie ontbreekt.
>>
>> Duidelijk verhaal, aan de slag, zou ik zeggen!
> Daar kan ik simple iets over zeggen, dat request ligt al lang bij AVM.
> Op dit moment is de status:
> * Zit in de code van de 7581, niet in de GUI. Als je het (door de config
> te bewaren, aan te passen, checksum aan te passen, terug te laden) in je
> box krijgt werkt het feilloos.

Ik heb een aangepaste configuratie geladen, maar met een edgerouter met
PPPOE passthrough werkt het helaas niet: ik kan niet vinden hoe ik de
MTU van de ethernet interface kan aanpassen en die blijft gewoon op 1500
staan, waardoor de rfc4638 optie dus geen effect heeft:

[louis@travel config]$ ping -4 -s 1476 -M do fritz
PING fritz.home.fazant.net (192.168.178.1) 1476(1504) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500

/Louis

[Rob]

Om dit werkend te maken moet je inderdaad op meerdere plekken de MTU
veranderen:

- van de PPPoE subinterface (van 1492 naar 1500)
- van de VLAN subinterface (van 1500 naar 1508)
- wellicht van de ethernet hardware interface (om 12 bytes ruimte
te maken, 8 voor de PPPoE header en 4 voor de VLAN tag, hoewel die
laatste vaak "niet mee geteld" wordt of automatisch verwerkt)

En inderdaad moet je hopen dat dit allemaal kan en mag.

Ik denk dat ik dit weeekend eens een 7581 van het werk ga lenen
(die bij glas geleverd is en dus niet gebruikt wordt) om te kijken
of ik het werkend krijg met mijn MikroTik router die het icm met
een Draytek 130 of een VDSL SFP al goed doet.

[Rob]

Ik ben er ook mee aan de slag gegaan met een geleende 7581 maar het
is me ook niet duidelijk.

Een backup gemaakt en er staat dit in:

mtu_cutback_mode = mtumode_auto;
mtu_cutback = 1500;

Wellicht moet dit omhoog?
Er is ook in de DSL sectie dit:

rfc4638_enabled = no;
mtu = 0;

Dat rfc4638_enabled zal op yes moeten, maar moet de mtu ook ingesteld worden?
En is dat dan op 1500 of op 1508 of 1512 oid?

Tenslotte: waar staat die checksum en hoe moet je die aanpassen?

Vooralsnog heb ik wel verbinding maar op MTU 1492 dus. Wat ook al met
de 7360v2 gelukt was.

[Miquel van Smoorenburg]

In article <slrnp92faq...@xs9.xs4all.nl>,

Rob <nom...@example.com> wrote:
>Er is ook in de DSL sectie dit:
>
> rfc4638_enabled = no;
> mtu = 0;
>
>Dat rfc4638_enabled zal op yes moeten, maar moet de mtu ook ingesteld worden?
>En is dat dan op 1500 of op 1508 of 1512 oid?
>Tenslotte: waar staat die checksum en hoe moet je die aanpassen?

Ik gok dat je iets als dit nodig hebt:
https://github.com/mementum/fritzchecksum

De rc4638 instelling is overigens bedoeld om de externe interface
op MTU 1508 te zetten in combinatie met PPPoE, zodat de PPP MTU
een waarde van 1500 kan krijgen.

Zowel WAN als LAN naar 1500 krijgen in bridge mode is iets heel
anders, en ik zou niet weten hoe (en of) dat kan.

Mike.

[Louis Lagendijk]

Ok, ik heb 1508 geprobeerd, maar 1512 zou inderdaad ook kunnen. Verder
iedere MTU die ik kon vinden, en iedere rfc4638 aangepast. Geen succes.
Je wilt de MTU zetten op externe interfaces: Ik wil nog een keer
proberen gewoon een mtu=1508 (of 1512) toe te voegen in de ethinterfaces
sectie en in de brinterfaces sectie, dat lijkt een logsiche plaats. Maar
gezien het feit dat die parameter er niet standaard staat, lijkt de kans
dat het gaat werken niet erg groot

>
> Tenslotte: waar staat die checksum en hoe moet je die aanpassen?

Ergens op de laatste regel. Ik gebruik https://github.com/PeterPawn/decoder
Om de checksum aan te passen:
decoder checksum < aangepaste.export > te-laden.export

[Rob]

Tja het lijkt er op dat het een gedeeltelijke oplossing is... alleen
bruikbaar als het modem zelf de PPPoE doet, en dat wil ik niet omdat
de NAT niet uitschakelbaar is.
(zelf PPPoE doen en dan alles relayen naar ethernet zou ik ook prima
vinden hoor... zoals de oude Thomson/Alcatel modems konden en de
Draytek ook. wel voor IPv4 en IPv6 dan natuurlijk)

Bij de modems en routers die dit wel goed doen kun je de ethernet
mtu ook hoger zetten, tot wel 1600 aan toe, om ruimte te geven voor
de extra header en tag. (en dit wordt ook gebruikt voor MPLS)

Misschien kan AVM dat ook even instelbaar maken zodat RFC4638 ook
in PPPoE relay mode kan werken?

[Louis Lagendijk]

On 02/24/2018 04:46 PM, Louis Lagendijk wrote:
> On 02/24/2018 11:24 AM, Rob wrote:
>> Rob <nom...@example.com> wrote:
>>> Louis Lagendijk <lo...@lagendijk.xs4all.nl> wrote:

>>
>> Ik ben er ook mee aan de slag gegaan met een geleende 7581 maar het
>> is me ook niet duidelijk.
>>
>> Een backup gemaakt en er staat dit in:
>>
>>          mtu_cutback_mode = mtumode_auto;
>>          mtu_cutback = 1500;
>>
>> Wellicht moet dit omhoog?
>> Er is ook in de DSL sectie dit:
>>
>>                  rfc4638_enabled = no;
>>                  mtu = 0;
>>
>> Dat rfc4638_enabled zal op yes moeten, maar moet de mtu ook ingesteld
>> worden?
>> En is dat dan op 1500 of op 1508 of 1512 oid?
>
> Ok, ik heb 1508 geprobeerd, maar 1512 zou inderdaad ook kunnen. Verder
> iedere MTU die ik kon vinden, en iedere rfc4638 aangepast. Geen succes.
> Je wilt de MTU zetten op externe interfaces: Ik wil nog een keer
> proberen gewoon een mtu=1508 (of 1512) toe te voegen in de ethinterfaces
> sectie en in de brinterfaces sectie, dat lijkt een logsiche plaats. Maar
> gezien het feit dat die parameter er niet standaard staat, lijkt de kans
> dat het gaat werken niet erg groot
>

En inderdaad, het werkt niet: mtu op de interfaces blijft 1500...
/Louis

[Rob]

Heb je al geprobeerd of het werkt als de box zelf de PPPoE doet?
Dat wil ik wel eens testen maar is hier niet zo simpel helaas.

[Louis Lagendijk]

Nee, niet geprobeerd: volgens Maarten Carels in zijn post in deze thread
van 29 Jan werkt het perfect. En als Maarten dat zegt geloof ik dat wel.
Die weet wel waar hij het over heeft.

Verder is de vraag of het dan wel werkt voor mij niet zo interessant: ik
heb nu een Edgerouter X die de routing doet via PPOE passthrough. En dat
heeft voor mij grote voordelen:

- Geen rare "port forwards" voor mijn publieke /29 subnet op de Fritzbox
(die omdat er een firewall zit tussen modem en de servers) niet
fatsoenlijk te wijzigen is. Rare jongens die AVM developers: wie verzint
het om firewall settings hard aan een mac-adres te koppelen....

- voor IPv6 geen dhcp pd meer tussen modem en firewall. Nu doet mijn
Edgrouter de dhcpv6 PD afhandeling en routeert mijn hele /48 naar de
firewall.
Voorheen moest ik altijd op de firewall de wan interface herstarten om
weer opnieuw een dhcpv6 request te doen na een modem reboot. Nu doet de
Egerouter zijn DHCP-v6 request en gaat direct IPv6 routeren.
En dhcpv6-pd op een pfsense cluster was toch al verre van ideaal (maar 1
node in het cluster mag dan een dhcp request sturen). En de Fritzbox wil
geen requests voor de /48 (alleen /60 of langer als ik het me goed
herinner).

Dus als ik moet kiezen tussen rfc4638 en de andere zaken dan kies ik
voor het gemak en de controle van de Edgrouter. Dan maar geen RFC4638.

De 7581 werkt voor mij verder prima als modem: alle andere
funtionaliteit wordt door andere dozen opgelost: een Fritzbox 7390 voor
DECT vanwege alle bekende problemen, WIFI op een AP achter de firewall
en routing door de Edgerouter

Ik hoop inderdaad dat XS4all (Maarten, Miquel) nog wat druk op AVM
kunnen zetten om ook een MTU van 1508 op de lan interface mogelijk te
maken zodat RFC4638 ook met de PPPOE passthrough werkt.

Nog een vraag voor Maarten: heb jj getest met de stock 6.85 firmware of
de beta van na 6.85 (6.85.46834)?

Met vriendelijke groet,
Louis

[Rob]

Louis Lagendijk <lo...@lagendijk.xs4all.nl> wrote:
> Nee, niet geprobeerd: volgens Maarten Carels in zijn post in deze thread
> van 29 Jan werkt het perfect. En als Maarten dat zegt geloof ik dat wel.
> Die weet wel waar hij het over heeft.

Ja dat neem ik ook wel aan, daarom ben ik ook niet een geheel aparte
testomgeving gaan maken. Het werkt vast wel.

> Verder is de vraag of het dan wel werkt voor mij niet zo interessant: ik
> heb nu een Edgerouter X die de routing doet via PPOE passthrough. En dat
> heeft voor mij grote voordelen:
>
> - Geen rare "port forwards" voor mijn publieke /29 subnet op de Fritzbox
> (die omdat er een firewall zit tussen modem en de servers) niet
> fatsoenlijk te wijzigen is. Rare jongens die AVM developers: wie verzint
> het om firewall settings hard aan een mac-adres te koppelen....
>
> - voor IPv6 geen dhcp pd meer tussen modem en firewall. Nu doet mijn
> Edgrouter de dhcpv6 PD afhandeling en routeert mijn hele /48 naar de
> firewall.

Ja inderdaad, zelf gebruik ik een MikroTik ipv een Edgerouter maar ik
loop tegen vergelijkbare zaken aan die alleen in een echte router zijn
op te lossen en niet in zo'n thuisrouter als AVM maakt.

Het is eigenlijk wel jammer dat er geen alternatieve router software
op dit ding kan draaien want het is hardwarematig prima, er zou vast
wel RouterOS, JunOS of Edgerouter software op kunnen draaien kwa hardware
mogelijkheden.

> Dus als ik moet kiezen tussen rfc4638 en de andere zaken dan kies ik
> voor het gemak en de controle van de Edgrouter. Dan maar geen RFC4638.

Ik heb nog die Draytek 130 die WEL alles goed doet, maar daar is dan
weer geen bonding en Vplus mee mogelijk en op dit moment hangt er hier
een of andere update in de lucht, misschien wel naar Vplus.
Dus ik laat die 7581 er even aan hangen tot die rond is (6 maart zegt
de helpdesk) en als er dan niks verandert en we weer gewoon terug gaan
naar VVDSL (100/30) dan gaat de Draytek er wel weer aan.

> De 7581 werkt voor mij verder prima als modem: alle andere
> funtionaliteit wordt door andere dozen opgelost: een Fritzbox 7390 voor
> DECT vanwege alle bekende problemen, WIFI op een AP achter de firewall
> en routing door de Edgerouter

Wat ook wel jammer is, is dat als je hem als PPPoE relay instelt je
niet meer de andere functies aan LAN2-4 kunt koppelen, wat bij andere
routers wel kon. Dan zou je de ATA/DECT/WiFi kunnen gebruiken "achter"
je andere router.
Eigenlijk komt het allemaal terug op 1 punt: inflexibel.
Een groot compromis, alles ten gunste van de gemakkelijke configuratie
door papa die het internet moet instellen met hooguit een zoon die wil
gamen. Serieus netwerken gaat er gewoon niet mee.

> Ik hoop inderdaad dat XS4all (Maarten, Miquel) nog wat druk op AVM
> kunnen zetten om ook een MTU van 1508 op de lan interface mogelijk te
> maken zodat RFC4638 ook met de PPPOE passthrough werkt.

Dat zou mooi zijn, of anders een "PPPoE naar ethernet relay" mogelijkheid
waarbij de box de PPPoE tunnel opzet en al het IPv4 en IPv6 verkeer
doorstuurt naar een opgegeven MAC adres. Dan kun je je Edgerouter
configureren met een platte externe ethernet poort (zonder PPPoE) en
zou ook alles moeten werken. Nadeeltje is dat je iets minder goed
kunt zien of de link up is of niet, maar daar valt ook wel wat op te
verzinnen (pingen van de next hop ofzo).

De Draytek kan dat wel. Thomson/Alcatel (SpeedTouch) konden dat ook.
In ieder geval voor IPv4.

[Maarten Carels]

Louis Lagendijk <lo...@lagendijk.xs4all.nl> wrote:
[...]

> Nog een vraag voor Maarten: heb jj getest met de stock 6.85 firmware of
> de beta van na 6.85 (6.85.46834)?

Beiden, en wellicht zelfs ook met wat eerdere betas. Maar en door alleen
de rfc4638_enabled regel aan te passen, verder niets. Maar dus wel de
box zelf die de pppoe doet.

Je kan het zien als je een capture maakt, dan zie je in de PADI een
extra tag verschijnen (PPP-Max-Payload), die wordt je in de PADO netjes
teruggegeven door de BRAS (daarmee vertelt die dat ie het begrijpt). Ook
in de PADR van de box, en de PADS van de BRAS zit die tag. Als je zo de
PPPoEDiscovery fase door bent, is het geregeld.

Als je de box zelf niet de ppp laat doen, maar dat door een extern geval
regelt, zul je:
* moeten regelen dat je externe geval op deze manier de PPPoED doet
(dus met die PPP-Max-Payload tag erbij)
* de fritz moeten vertellen dat ie een 1508 MTU op de link tussen
de fritz en je externe geval toestaat
* en ook zorgen dat de fritz 1508 op de VDSL kant doet

--maarten

[Rob]

Ja dat is duidelijk. Mijn (en ik neem aan ook Louis') router doet dat
gewoon. En dat werkt ook prima als je hem bijvoorbeed direct aan een
glas aansluiting (oude stijl met ethernet NTU) hangt. Of als je hem
aan een Draytek 130 VDSL modem hangt, die ondersteunt die grotere MTU.

Maar de vraag is nu hoe zet je de MTU hoger op een Fritzbox?
Als je die rfc4638_enabled aanzet zal hij de DSL MTU vast wel zelf
verhogen, anders is dit wellicht te forceren met de mtu parameter die
vlak bij die rfc4638_enabled staat?

Maar dan is er nog de MTU op de ethernet interface... daar staat geen
expliciete mtu instelling voor in de file. Alleen globaal staat er
iets, zie eerdere post.

[Louis Lagendijk]

On 02/26/2018 10:19 AM, Maarten Carels wrote:
> Louis Lagendijk <lo...@lagendijk.xs4all.nl> wrote:
> [...]
>> Nog een vraag voor Maarten: heb jj getest met de stock 6.85 firmware of
>> de beta van na 6.85 (6.85.46834)?
>
> Beiden, en wellicht zelfs ook met wat eerdere betas. Maar en door alleen
> de rfc4638_enabled regel aan te passen, verder niets. Maar dus wel de
> box zelf die de pppoe doet.
>
> Je kan het zien als je een capture maakt, dan zie je in de PADI een
> extra tag verschijnen (PPP-Max-Payload), die wordt je in de PADO netjes
> teruggegeven door de BRAS (daarmee vertelt die dat ie het begrijpt). Ook
> in de PADR van de box, en de PADS van de BRAS zit die tag. Als je zo de
> PPPoEDiscovery fase door bent, is het geregeld.
>
> Als je de box zelf niet de ppp laat doen, maar dat door een extern geval
> regelt, zul je:
> * moeten regelen dat je externe geval op deze manier de PPPoED doet
> (dus met die PPP-Max-Payload tag erbij)

Dat kan met de Edgerouter. Die heeft een PPPD die dat kan.

> * de fritz moeten vertellen dat ie een 1508 MTU op de link tussen
> de fritz en je externe geval toestaat

en daar gaat het fout: ik heb ij de Fritz niet kunnen vinden hoe ik de
MTU omhoog krijg.,,

> * en ook zorgen dat de fritz 1508 op de VDSL kant doet
>

Dat is het gemakkelijkste: even rfc4638_enabled zetten
> --maarten

Hoe dank ook: mijn hartelijke dank voor je hulp: het was leuk het te
proberen.

Ik zit nu te wachten op de straatkast: de upgrade stond op 9 maart maar
is nu van fourstack verdwenen. Nu maar hopen dat het komt doordaat de
straatkast de upgrade heeft en ik binnenkort wordt overgezet (en niet
omdat de upgrade alweer gecancelled is of naar een verre toekomst
verschoven, de eerst upgrade datum die ik gezien heb op fourstack was
dach ik q3-2016).
Dan kan ik eindelijk de snelheid van mijjn abonnement halen en evt
kijken of ik van smart naar Plus wil overstappen....

Groeten, Louis