Ook hier is het gekraak inmiddels in volle hevigheid teruggekeerd Ik heb de 7581 nog niet gereboot, maar het zou me niet verbazen als dat werkt (waarschijnlijk tijdelijk). Terug bij af dus.

Recent een paar heftige krakende verbindingen (extern) die vervolgens werden verbroken, terwijl ik werk met de FB7581 - 06.85-50446 PLUS, in combinatie met de 7490 voor het DECT gedeelte. Zou het probleem van het kraken misschien helemaal niet in het DECT stuk zitten?

De oorzaak hoeft inderdaad niet per se in het DECT-gedeelte te zitten. AVM moet om performanceredenen nogal wat doen in kernel modules (al die real time data heen en weer schuiven tussen kernel space en user space gaat gewoon veel te traag). In tegenstelling tot user space processen zijn kernel modules niet van elkaar geïsoleerd. Gevolg is dat een fout in de ene module de data van een andere module kan beschadigen. Dus ja, het is mogelijk dat de echte oorzaak heel ergens anders ligt. Het zwakke punt van deze theorie is dat je in zo'n geval al snel een kernel panic en een reboot zou verwachten. En dat gebeurt juist weer niet.

Waar de oorzaak precies zit, zal AVM uit moeten zoeken. Gesprekken via een telefoon aangesloten op FON1 gaan overigens perfect (ook als dat een Gigaset DECT-setje is). Maar dat weten we al heel erg lang.

Edit: een andere mogelijkheid is dat de transcoding tussen G.726 (DECT SD Audio) en G.711 hapert. Bij een gesprek via FON1/FON2 zal denk ik direct G.711 worden geproduceerd zodat geen transcoding nodig is. Ik heb wel eens wat gelezen over transcoding issues bij FB's.

Ik ben net weer terug gegaan naar de laatste Beta 06.85-50446 PLUS want ik had twee gesprekken waar de tegenpartij klaagde over dat ik niet verstaanbaar was.

Nu ik ben teruggegaan kan herinnerde ik mij een schuifregelaar in het DECT gedeelte helemaal onderaan in de Fritz.box die ook iets betrouwbaarheid te maken had. Kan iemand dat checken?
Ik had daar niet meer aangedacht en wil niet weer de procedure van recovery doorlopen....ging nogal vaak mis en ik kon de box niet meer bereiken.
Hij wilde niet de gegevens van de DHCP server overnemen en bleef op 192.168.188.1 vertoeven.

Toen maar de backup teruggezet en toen veranderde ook het MAC adres weer naar de vorige instelling.....never a dull moment.

ps. de DECT telefoons blijven nu op nederlands staan. Dat komt waarschijnlijk omdat er geen Nederlands in de Beta van maart zit.

Ik had op één van de drie Xs4all aansluitingen die ik beheer al voordat de snelheid van 20/2 werd verhoogd naar 40/5 een upload van 10Mb. Na de verhoging bleef de upload 10Mb.

Ik heb er over geklaagd. Niet dus.

Het upload gedrag is zoals ontworpen. Waarom de upload niet wordt "gecapped" is ook goed te verklaren. VDSL traint in op de hoogst mogelijke snelheid. Dus als je de 100Mb down kan halen, word je wel gecapped op je downloadprofiel op IP niveau. Dus als je 50Mb down afneemt, traint je router in op 100Mb en krijg je maximaal 50Mb verkeer aangeboden. De andere kant op probeert je router met de maximale upload data te versturen. Jij probeert dat dus op 10Mb. Stel dat je maar 1Mb upload afneemt, dan staat je router 90% packets droppen waar niemand vrolijk van wordt. Om dat te voorkomen staat de upload dan ook "wide open". Hoger dan de 10Mb upload zal je dan ook niet komen vrees ik ...

Ik ben terug gegaan naar de DECT stabiele versie van Beta firmware 06.85-50446 PLUS omdat ik weer onverstaanbaar was aan de andere kant.

Ik meen mij een schuifregelaar in het DECT gedeelte helemaal onderaan in de Fritz.box die ook iets betrouwbaarheid te maken had. Dit was in versie 6.98-60543 LabBeta

Kan iemand dat nog voor mij bekijken die op 6.98-60543 zit?

Er zit in 6.98-60543 bij DECT-toestellen in de tab Kenmerken van het telefonie-apparaat een schuifregelaar Storingsfilter (zit die niet in 6.85-50446?). Ik heb die nu op Uit gezet bij alle toestellen. Eens kijken wat het oplevert. Goede tip.

Edit: dit lost het probleem helaas niet op (maar veroorzaakt het dus waarschijnlijk ook niet). Instelling weer terug naar het midden.

Dat lijkt me vrij onwaarschijnlijk. Reductie in de maximaal haalbare downloadsnelheid wordt echt niet bereikt dmv "packet drops". Eerder door het niet benutten van het volledige voor de upload beschikbare spectrum of anders in de centrale door het één of ander timing en/of mux mechanisme.

upload op DSL wordt niet gecapped, maximum per aderpaar is 33 mbit. dit ivm limitaties in DSLAM