[Diskussion] Speedport W920V - Problem PPPoE-Zeitüberschreitung

[abraXxl]

@Jpascher: Bei ATM/ADSL Habe ich keinen Plan, wie das Handschake beidseitig mitschneiden könnte.

Deine Fehlermeldungen, von welchem Programm kommen die? Ich wuerde auf Multid tippen. Da der als einziges mit allen devices "spielt". Die Nummern vor den Fehlermeldungen sehen nach linux-internen Devicenummern aus. Hast du mal mein Addonverzeichnis in deine Images integreiert? Das "busybox" da drin kennt das "ip"-Applet. Check dochmal "busybox ip link". Die Nummern sollten passen, zumindest bei mir tun sie es.

Bei ATM/VDSL koennte ich versuchen hier zu Hause ein Testsetup aufzubauen (wenn aber erst in zwei Wochen, bin im Moment sehr eingespannt.)

Bei PPPoE/ADSL und PPPoE/VDSL habe diese Fehlermeldung noch nicht gesehen. Aber ich habe auch schon PPP-Timeouts mit Fehler 0xc021 gesehen. Und zwar wenn ich das "wan" fi von Hand mit cpmaccfg konfiguiere(entweder per Vinax oder per Port1), und dann auf dem wan Interface pppd mit pppoe.so Versuche laufen zu lassen. Ich sehe via "tcpdump -nvv -i wan"
schoen die Pakete die rausgehen und ankommen. Koenntest du evtl auch mal probieren sollte in meinem addon.tgz von der zweiten Seite sein.

Da ich ja die passende VDSL-Gegenstelle habe, habe ich auf der anderen Seite dies auchmal gemacht (br0 auf meinem PC).

W920V <-> VDSL-Master <-+
   |                    |
ttyUSB0                 |
   |                    |
 PC-br0 - eth0 ---------+
      |
      +---eth1 ----------------------W900V mit PPPoE-Relay --- T-Com

Das Ergebnis ist, dass ich in allen Testcases (natuerlich per Diff-by-Eyes) alle Pakete, welche das wan-Interface auf dem W920V verlassen haben auch an der br0 im PC vorbeifliegen hab sehen können.

Also PADI- und PADR-Pakete vom W920 via br0 waren okay.

Interessant ist das was am br0 zum W920V geflogen ist, bzw. was nicht am W920 ankam.

Mit pppd sind nicht alle Pakete beim W920V auf dem wan-Port angekommen.
Wichtige Pakete wie PAD0 oder PADS bzw. spaeter LCP-Configrequest sind definitiv nicht beim W920V angekommen. (Die Paketnamen und deren Bedeutungen kenne ich erste seit ein paar Tagen. Ich bin kein ppp-Experte. )
Dies gibt dann ein DSL Timeout.

Mit kdsld und kdsldmod funktionierte dies dann wie gewohnt.

Leider kann ich nicht wie erst gedacht auf dem Allnet126AM auch ADSL bereitstellen, daher kann ich den problematischen Fall ADSL/Vinax nicht auf diese Weise nachbauen. Ich sehe jedoch, wenn ich pppd oder kdsld mit Problem-FW nutze auch das manchmal LCP-Confireustfehlen oder die PADO- und PADS-Pakete ausbleiben. Als Folge gibt es dann PPPoE-Timeouts.

Warum weis ich leider noch nicht. Ich vermute das igrnedein kleines "Schräubchen" in den Vinax- oder Switcheinstellungen vom kdsld gesetzt wird, welches in neueren FW-Kombination, nicht mehr gedreht wird.

so das mal als mein Status

:wq

 

[Jpascher]

Was du da berichtest ist ja schon mal ein guter Anfang und ich überlege jetzt mal was ich da noch machen kann, brauche aber auch erst mal wieder etwas Zeit.

Egal wie klarerweise möchte ich das Problem lösen, Die Zusammenhänge zu verstehen ist aber noch wichtiger, wenn man an zukünftige Entwicklungen denkt.

Währe halt super, wenn sich da noch weitere Bastler oder Experten finden die intensiv da weiterforschen.

 

[BayesBug]

Errmm...ja unabsehbar hat die Telekom etwas zu gut gewerkelt...heute ist hier VDSL geschalten worden (owbwohl die erst meinten auf der Leitung kann wegen Noise Margin und Co wohl nur DSL 16000+ geschalten werden...umso erstaunlicher das VDSL25 jetzt mit praktisch voller Kapazität arbeitet)...weswegen ich natürlich nicht mehr wirklich am ADSL/PPPoE problem arbeiten kann, mangels ADSL Gegenstelle. Aber zumindest noch ein paar sachen die mir aufgefallen sind die hier scheinbar noch nicht gepostet wurden:

Ich konnte den Ansatz jetzt nur ansatzweise verfolgen bevor VDSL gekommen ist. Mir scheint als würde das "dsl" interface das der treiber nach dem sync zusätzlich zum "wan" interface erzeugt nicht richtig eingebunden. Folgendes spielt sich nach erfolgreichem sync ab:

Der dsld der sonst ständig pollt ob der sync da ist (oder ähnliches) fängt an das wan interface beim treiber zu registrieren macht dort nen socket auf und bridged des (ist es das was er tut?) mit hilfe von cpmac...aber dann will er denk ich das "dsl" interface erstellen (es entsteht zwar eins aber das ist denke ich kapput):

13486 Firmware:

<6>kdsld: showtime
<6>kdsld: VCC 0: registered (wan)
<6>kdsld: 0:  VPI/VCI 0/0 PPPoE internet 00:24:fe:19:40:a8 (32,0) mc upstream
<6>kdsld: dsl: registered
<6>kdsld: VCC 0: iface internet dslencap PPPoE pcapencap ETHER llctype ether
<6>kdsld: VCC 0: pcapencap ETHER
<6>kdsld: no vpnconnections configured
<6>kdsld: setup done.

13538 Firmware:

<6>kdsld: showtime
<6>kdsld: VCC 0: registered (wan)
<3>kdsld: KDSLDIFACE_CREATE: copy dslifacecfg failed
<6>kdsld: dsl: registered
<6>kdsld: no vpnconnections configured
<6>kdsld: setup done.

...und der dazugehörige ltrace Ausschnitt zu "KDSLDIFACE_CREATE: copy dslifacecfg failed":

strcmp("internet", "internet")                                = 0
strncmp("dsl", "dsl", 16)                                     = 0
kdslinterface_create(0, 0, 0x2ad0a000, 0x432e5c, 0x2aab5540 <unfinished ...>
  ioctl(4, -2145369824, 0x7fe68948 <unfinished ...>
    __errno_location()                                        = 0x2acf0010
  <... ioctl resumed> )                                       = -1
<... kdslinterface_create resumed> )                          = -1

ich bin jetzt nicht mehr dazu gekommen die dslds mal auszutauschen und dem genauer auf den Grund zu gehen aber es ist ja schon mal verdächtig oder? dslifacecfg ...hmmm ich schätze mal der muss da irgendwie per ipc über den ctlmgr auf irgendwelche Einstellungen zugreifen und das schlägt fehl. Auf den ctlmgr komme ich weil man effektiv alle Komponenten bis auf den inkl. Libraries austauschen kann, die mit der Sache irgendwie zu tun haben, und man bekommt trotzdem noch scheinbar den selben Fehler, können das andere bestätigen? Allerdings den ctlmgr auszutauschen ohne effektiv alles andere auszutauschen is auch nicht drinn (bei der 538 gehts noch weil die so nach dran is, da brauchts dann nur ~4 Komponenten, aber die abhängigkeiten werden immer grösser, ausserdem will man den denk ich nicht austauschen da ich da jeweils einen großteil der verbesserungen vermute).

 

[BayesBug]

Man müsste wohl mal einen gdb an die kdsldmod.ko hängen um zu sehen was genau da schief geht. Aber um das noch ergänzend zu sagen: ich weis nicht, ob das tatsächlich der Fehlergrund ist oder nur von Unterschieden der dsld kdsld +system interaktion herrührt (das dsld Interface also in ordnung ist weils etwa bei neueren ctlmgr Versionen von dem gemacht wird,...)...

kann mal einer versuchen die 486 dsld in eine 538 fw zu packen (mit 7570 tcom incl tcom kdsldmod)?

PS: ja im letzten Post die FWs waren jeweils gefreetzte 486 bzw. 538 FWs mit der 7570 als tcom incl deren kdsldmod.ko

 

[satglotzer]

Wie ist das Möglich

Hallo Leute.
Zu der PPPoE-Zeitüberschreitungs-Geschichte ist mir folgendes aufgefallen:

Ich habe aus der T-Com 04.71 und der 7570 eine Firm für mein neues ADSL2 16+ Entertain gebaut.
Die Firm habe ich eingespielt und anschließend meine Sicherungsdaten mit Zugangskennung, Telefonbuch und sonstige Einstellungen geladen.
Diese Sicherungsdatei stammt aus meiner 7570/7570 die ich für meinen alten 3000er ADSL-Anschluss gebaut hatte.
Die neue Firm hatte sofort funktioniert, inkl. Entertain.
Dann wollte ich wissen was passiert, wenn ich den Haken für IP-TV entferne.
Das Entertain blieb nach kurzer Zeit hängen und lief immer nur ein paar Sekunden wenn man umgeschaltet hat.
Also den Haken wieder gesetzt und schon war sie da, die PPPoE-Zeitüberschreitung.
War der Haken weg konnte ich nach Neustart der Anlage wieder ins Internet, aber Entertain war immer noch gestört.
War der Haken da, gabs die Zeitüberschreitung. Schöne Sch......

Dann die Idee, die Sicherungsdatei!
Und siehe da, alles lief wieder inkl. Entertain.

Nun habe ich folgendes ausprobiert:
Haken IP-TV entfernt -> Kein Fernsehn aber DSL.
Haken IP-TV wieder gesetzt -> PPPoE-Zeitüberschreitung.
Diesen Zustand habe ich in einer neuen Sicherungsdatei gespeichert und sofort wieder eingespielt.
Ergebniss: Alles geht wieder! Eigenartig.
:bahnhof:

Kann sich da einer einen Reihm drauf machen?

Bis dann......

Satglotzer

 

[Jpascher]

Das ist sehr eigenartig, ja!

Einen Reim, kann ich mir auch nicht daraus machen.
Prinzipiell sollte ja da die selben Vorgänge ablaufen wie wenn man per Weboberfläche was ändert, man musste jetzt analysieren was beim Einspielen genau abläuft.

 

[Fifaheld]

Hoffnung für alle ADSL User? Avm hat eine neue Version seiner Labor für DSL rausgegeben. Vielleicht geht ja damit ADSL wieder?

http://www.avm.de/de/Service/Service-Portale/Service-Portal/Labor/7270_dsl/labor_start_dsl.php

 

[abraXxl]

Hi,

ich habe eine weitere Untersuchung vorgenommen um den Fehler weiter einzugrenzen.

Ich habe W920-71 mit erstens 7270-13486 und zweitens 7270-70 gepaart.
Ich habe jeweils nur eingerichtet Zugang via DSL mit PPPoE nach clear mtd3/4.

Danach habe ich alle Dateien aus dem tffs (/var/flash) extrahiert.
Und mit "diff -uaNr" auf unterschiede untersucht. Mehr als die Datumszeilen diffen nicht.

Fazit: Es liegt irgendwo in einer Bibliothek bzw. im dsld, welche die VCCs fuer das dsl-Interface registriert. Ich habe leider die lib.so noch nicht gefunden in welchem das Symbol verstectt ist. Ich vermute seine Signatur bzw. die Signatur von Funktionen die es aufruft hat sich verändert

 

[Jpascher]

Hab nun einig firmwares verglichen.

Gibt es nur in der 7570:

/libfuse.so.2.7.2
/libsqlite3-3.6.9.so.0.8.6
/libewnwnet.so.0.0.0
/libntfs-3g.so.28.0.0

(Gibt mir zu denken da wir die fehlenden libs ja nicht kopieren).

Ident in 7570 und 14080, in 14047 nicht vorhanden:

/libz.so.1.2.3
/libexif.so.12.2.0
/libavmid3tag.so.2.0.0

Unterschidlich in 7570 und 14080, in 14047 nicht vorhanden:
/libmsgwrap.so.1.0.0

Verschieden in 7570 und 14047, ident in 14047 und 14080:

/libcm.so.0.0.0
/libfwsign.so
/libikeapi.so.2.0.0
/libled2.so.2.2.0
/libmaillib.so.2.0.0
/libwlanparams.so.1.0.0
/libuClibc-0.9.29.so
/libpop3lib.so.1.0.0


In allen drei Firmwares unterschiedlich:

/libacgenusb.so.1.0.0
/libar7cfg.so.1.0.0
/libavmcsock.so.2.0.0
/libavmssl.so.2.0.0
/libavmupnpapi.so.2.0.0
/libavmupnpbig.so.2.0.0
/libboxlib.so.0.0.0
/libcrypto.so.0.9.8
/libewnwlinux.so.2.0.0
/libmxml.so.1.0.0
/libosip2.so.4.0.0
/librtpstreamt38.so.2.0.0
/libsiplib.so.2.0.0
/libusbcfg.so.1.0.0
/libwebsrv.so.2.0.0

 

[abraXxl]

Nach etwas diggen in den lib/.so-Files habe ich das gesucht Symbol "kdslinterface_create" nicht in den Bibliotheken gefunden.
"mipsel-linux-uclibc-objdump" mit "-t" und "-T" haben dort Hilfe geleistet.
Ich habe zu Sicherheit auch noch in den Modulen/.ko gescuht.

for i in $(find ! -type l -name "*.[ks]o*"); do mipsel-linux-objdump -t $i > $i.syms; done
find -name *.syms -exec grep kdslinterface_create {} \;

Leider gibt das weder für "-t" und "-T" übereinstimmungen, d.h. dieses Symbol liegt entweder im Kernel oder im dsld.
Da aber

grep kdslinterface /proc/kallsyms

auch nix zeigt auf einer laufenden Box, bleibt letzteres.
Das würde bedeuten durch einfaches Austauschen des dsld mit irgendwas besserem könnte es funktionieren. Leider hilft dies nicht nur, wie BayesBug gezeigt hat. Es muss mehr getauscht werden.
Was getauscht werden muss hat Bayesbug auch gezeigt. Ich werde die nächsten Tage mal weiter schauen, wie man dies evtl verheiraten kann. Meine Vermutung ist, dass ein dsld-wrapper+Tcom-libar7*+tcom-dsld+LD_LIBRARY_PATH-Kleber evtl. Hilfe bringt.

Jo es geht, ich habe eben eine W920-r13571 mit einer 7270-70 verheiratet! Noch ist das Frikelkram und nicht nicht fertig fuers Skript.
Was habe ich gemacht: Ich habe aus der W920-r13571 /lib/ar7cfg* und /sbin/dskd zusätzlich herausoperiert und in ein Verzeichnis /lib/dsld/ kopiert (via addon/tmp/squashfsroot). Danach habe ich das Image geflasht (clear mtd3/4) und nach einem Start die Verbindungsdaten eingetragen. Wie erwartet Sync aber keine Internetverbindung. Dann habe ich brav mit "dsld -s" den dsld gestoppt. Gestarttet habe ich den dsld dann so:

PATH=/lib/dsld:$PATH; LD_LIBRARY_PATH=/lib/dsld dsld

Et Voila ich durfte ins Internet.

Ich weis nicht bis zu welcher Labor-Version dieser "Kleber" funktioniert, ich befüchte aber fast das mit dem dsl-aus dem W920V keine AVM-VPN geht.

Mehr dazu morgen. n8.


cya

 

[Jpascher]

Sehr gut, damit hast du Problem nun schon sehr eingekeist!

 

[abraXxl]

Ich habe gerade gesehen, das das Skript nur den kdsldmod aus der SP-FW extarhiert.
Also ist der Kit zwischen drv_vinax und kdslmod nur der dsld und libar7cfg.
Mit diesen Erkenntnissen habe ich mal versucht W920-r13571+7270-70 mit dem dsld+libar7cfg aus der 7270-r13486 zu kombineren. Es geht!

Der dsld+libar7cfg aus W920-r13571 und 7270-r13486 sind BTW identisch.

Hier nun ein Quick-Workaround für die Leute die es testen wollen:

Irgendwie dsld+libar7cfg aus W920-r13571 oder 7270-r13486 extrahieren. Dies geht z.B. durch anstarten des Skriptes mit passend gewählten FWs und abbrechen nach dem die FWs entpackt sind.
Die extarhierten Datein nehmen und wie folgt ins Addon-Verzeichnis kopieren.
Zusatzlich folgendes Wrapper-Skript mit x-Rechten ins Addon-Verzeichnis kopieren und verlinken.

#!/bin/sh
# dsld-wrapper.sh

DSLD_DIR=/lib/dsld

PATH="$DSLD_DIR:$PATH"
export PATH

LD_LIBRARY_PATH="$DSLD_DIR:$LD_LIBRARY_PATH"
LD_LIBRARY_PATH="${LD_LIBRARY_PATH%:}"
export LD_LIBRARY_PATH

exec dsld "$@"

Das sollte dann etwa so aussehen:

./src/sp2fr-svn/addon/tmp/squashfs-root/lib/dsld/dsld
./src/sp2fr-svn/addon/tmp/squashfs-root/lib/dsld/libar7cfg.so
./src/sp2fr-svn/addon/tmp/squashfs-root/lib/dsld/libar7cfg.so.1.0.0 
./src/sp2fr-svn/addon/tmp/squashfs-root/lib/dsld/libar7cfg.so.1 ( Symlink nach libar7cfg.so.1.0.0 )
./src/sp2fr-svn/addon/tmp/squashfs-root/lib/dsld/libar7cfg.so (Symlink nach libar7cfg.so.1 )
./src/sp2fr-svn/addon/tmp/squashfs-root/lib/dsld/dsld-wrapper.sh
./src/sp2fr-svn/addon/tmp/squashfs-root/sbin/dsld (Symlink nach ../lib/dsld/dsld-wrapper.sh )

Jetzt gewünschte FW kombi bauen: Es funkt z.B. W920-r13571+7270-70 und W920-70+7270-70.

Neuere FWs habe ich nicht getestet.

Have more fun.

 

[Jpascher]

Hab das mal ins Skript übernommen, bitte durchsehen ob ich das richtig umgesetzt habe.
Ich habe nur das Skript durchlaufen lassen aber nicht am Speedport die erstellte Firmware getestet.

 

[iqjet]

Muß im Script kdsldmod und wrap gewählt werden?
Script läuft fehlerfrei durch, kann aber heute leider nicht laden

 

[abraXxl]

@iqjet: jo

 

[abraXxl]

Also seit Skript r260 funkt es fuer PPPoE und Kabel.
Nachteil Portforwardings gehen nicht mehr.

Bei W920-7x als Basis gibt dann leider eine Rebootschleife, sobald es genutzt wird
Bei 7570-70 als Basis wird es vom dsld schlicht ignoriert

Die Nachrichtenwege, also wie der dsld über die Portforwardings informiert wird, damit diese auf dem dsl-Interface eingerichtet werden sind irgendwie kaputt.

dsld scheint vom ctlmgr bei Änderungen in den Port-FWs informiert zu werden. jedoch scheint AVM die "Sprache"/Datenstrukturen hier verändert zu haben. Und der alte dsld versteht den neuen ctlmgr nicht mehr.

Bin für Anregungen offen.

Hat wer schon mal getetste ob VDSL mit dieser Option geht?
Wenn ja, können sich VDSL-User auch wieder am Debugging beteiligen. Zu mindest für diesen Lösungsansatz.

 

[hans]

Hi,
dem kann ich vollkommen zustimmen.

Sobald ein Forwarding Rule eingetragen ist, bootet die Box ständig.

Ebenso ist die PPPoE bei mir nicht sonderlich stabil.

ADSL 16+

Gruss

Hans

 

[pointde]

@abraXxl
funktioniert der Super-Kleber bei der neuen Labor eigentlich noch?

 

[abraXxl]

Die Option im sp2fr funktioniert. Wie es aber mit den jeweiligen FW kombinationen aussieh kann ich dir nicht genau sagen. Ich fang erst wieder richtig an zu basteln wenn die 7270-74 stable draussen ist.

Was ich jedoch fuer W920-74 vermute ist das es auch hier starke Probleme geben wird. Die Datenstrukturen des kdsldmod aus der W920-71 (oder neuer -74) und 7270-70 und neuer laufen zu stark auseinander soweit ich das sehen kann. (objdump). D.h es geht nicht, , Reboots bei Portfreigaben o.ä..

Mit einer 7570-70 könnte es als Basis noch gehen. Daher hoffe ich auch auf neuere 7570er FWs. Es gibt ja angeblich schon 7570er Beta-FWs, laut Signaturen einiger Schreiber hier.

 

[Fifaheld]

Laut script gibs nicht gerade wenig 7570er betas, das problem ist aber, das die immer nur paar bestimmten leuten hier vorbehalten sind, oder einer bestimmten person und daher bringt es nichts, da wir otto normalverbraucher die firmware`s niemals sehen werden Also brings nichts in richtung adsl 7570er was zu basteln