Änderung des PPPoE Tag/Host-Uniq möglich?

[rpc]

Hallo,

ich versuche von meiner FritzBox aus, welche hinter einer VDSL2 Box (BBox2 von Belgacom) hängt, eine eigenständige PPPoE-Verbindung aufzubauen. Durch langes Testen mit Wireshark habe ich rausgefunden daß der sog. PPPoE Tag "Host-Uniq", welche die FritzBox aussendet (broadcast/PADI), 18 bytes lang ist, das VDSL-Modem der BBox2 aber nur mit PADO antwortet, wenn dieser String maximal 14 bytes lang ist.

Ist es irgendwie möglich den durch die Fritz!box beim PPPoE Discovery verwendeten Host-Uniq Tag zu ändern, bzw. zu kürzen?

Leider erlaubt Belgacom nicht die Verwendung anderer VDSL2 Modems, und wer möchte schon auf eine Fritzbox verzichten ;-).

Danke schonmal für's lesen.
rpc

 

[RalfFriedl]

Wenn Du schon die Länge des Strings herausgefunden hast, kennst Du vermutlich auch den Inhalt. Dieser muß letztlich irgendwo her kommen. Wenn Du Glück hast, ist er als Konstante irgendwo hinterlegt und man kann es ändern.

Wenn das Problem auch mit einer Original-Firmware auftritt, würde ich empfehlen, an AVM zu schreiben.

Ansonsten gab es auch schon Erfolge mit einem eigenen pppd, aber dann mußt Du auf etliche AVM-Funktionen verzichten.

 

[rpc]

Hallo,

habe die 7050 und die supported AVM nicht mehr, meine Anfrage dort blieb leider unbeantwortet.

Der String scheint so auch nicht vorzukommen, konnte ihn zumindest nicht finden.

Haben die neueren Boxen noch immer so einen langen String? Wäre nett wenn jemand mal mit Wireshark nachschauen könnte.

 

[TrinityOne]

Das RFC sagt dazu, dass der Host-Uniqe Tag dynamisch ist, also schlechte Karten.
http://www.ietf.org/rfc/rfc2516.txt

0x0103 Host-Uniq

This TAG is used by a Host to uniquely associate an Access
Concentrator response (PADO or PADS) to a particular Host request
(PADI or PADR). The TAG_VALUE is binary data of any value and
length that the Host chooses. It is not interpreted by the Access
Concentrator. The Host MAY include a Host-Uniq TAG in a PADI or
PADR. If the Access Concentrator receives this TAG, it MUST
include the TAG unmodified in the associated PADO or PADS
response.

Ich würde auch nicht sagen, dass das ein Problem von AVM ist, da der Tag beliebige Länge haben kann. Vielleicht gehst Du mal zum Hersteller des VDSL Modems oder machst darauf ein FW Update?

 

[rpc]

[Edit frank_m24: Sinnfreies Vollzitat vom Beitrag direkt darüber gelöscht, siehe Forumregeln.]
Vom Hersteller des Modems (Sagem aus Frankreich) ist leider keine Hilfe zu erwarten, deren Unterstützung für Endanwender ist nicht existent. Und leider verbietet mein Provider die Benutzung anderer VDSL2 Modems (und hat sich dieses durch die Regulierungsbehörde absegnen lassen).

Der host_uniq ist eine Art cookie die der Router/PPPoE client generiert, damit der Router sicher sein kann, dass die PADO-Antwort des Modems (eigentlich ja des AC/DSLAM) auch an ihn gerichtet ist. Für eine Windows WAN Miniport Verbindung, oder auch Linux PPPoE ist dieser z.B. 8 bytes lang. Bei meiner Fritz!Box ist dieser Wert 18 bytes lang, dazu enthält das PADI-Paket von AVM am Ende noch weitere 14 bytes, die Wireshark nicht zuordnen kann, und die der RFC zufolge da auch nicht hingehören.

Ich habe das ganze mal unter Linux mit dem tollen Tool "pppoe-discovery" nachgespielt, und so die 14 bytes Grenze herausfinden können. Die unidentifizierten 14 weiteren bytes im AVM PADI-Paket dürfen auch nicht da sein wenn eine Verbindung durch das VDSL2 Modem klappen soll.

Schade, möchte die FritzBox eigentlich nicht in Rente schicken.

 

[RalfFriedl]

In 8 Bytes kann man auch schon genug Kombinationen unterbringen, daß eine Kollision unwahrscheinlich ist. 18 Bytes ist wirklich sehr lang. Was packt AVM denn da hinein?

Ich fürchte, ohne Unterstützung von AVM wirst Du da nichts machen können.

 

[rpc]

[Edit frank_m24: Sinnfreies Vollzitat vom Beitrag direkt darüber gelöscht, siehe Forumregeln.]
Würde ich auch gerne wissen wieso das bei AVM so lang sein muss. Eine angepasste fw von AVM kann ich ja leider nicht erwarten (da EoL erreicht).

Netterweise hat mir AVM eben geantwortet, dass dieser String bei aktuellen Versionen auf 30 bytes angewachsen ist und dieser leider nicht änderbar sei, schade.

 

[TrinityOne]

Welcher AVM-Prozess auf der FB macht denn die PPPoE-Einwahl? Vielleicht könnte man den entsprechend patchen?
[Edit] das wäre dann der dsld

 

[RalfFriedl]

Ich bin sicher, daß man das patchen kann. Das Problem ist nur, die richtige Stelle zu finden.

 

[TrinityOne]

Ich habe mir den dsld gestern Abend mal in einem Disassembler angesehen. Obwohl viele sprechende Funktionsnamen existieren habe ich noch keine Vermutung, wo die PADI erzeugt werden. Vielleicht wäre ein Debugging des laufenden Prozesses hilfreich. Ich werde die Tage mal mit dem gdbserver experimentieren - falls in der Binary überhaupt Debugsymbole existieren. Ansonsten ist hier hier wahrscheinlich vorbei
[Edit] Scheinbar liegen die Funktionen zum Erstellen der Frames in einem Kernel Modul /lib/modules/2.6.13.1-ohio/kernel/drivers/dsld/kd
sldmod.ko

 

[RalfFriedl]

Ich glaube nicht, daß Du da Debugsymbole finden wirst.

 

[rpc]

Zunächst bedanke ich mich bei euch für euere Unterstützung.

Hier mal ein Screenshot wie dieser Tag bei mir aussieht ...

Vorhanden ist immer der Bestandteil "F! Box"

 

[RalfFriedl]

Es ist sogar "F!Box" + drei Leerzeichen. Wenn Du die findest und entfernen kannst, könnte es von der Länge reichen.

 

[TrinityOne]

Der String "F!Box" ist schonmal eine Konstante im vermuteten Kernel-Modul.
Scheinbar wird der an jedest Uniq als Suffix angehängt.
Das wäre doch schon mal eine Idee
[Edit] So sieht das aus im Modul:

pingresp^@^@^@^@^@^@^@F!Box   ^@^

ich würde das jetzt ganz dummdreist mal ersetzen

[Edit2] BTW alles ohne Gewähr, denn ich habe keine 7050 mehr, sondern gucke mir das auf meiner 7170 an
[Edit3] Ich habe das jetzt mal gepatcht und Dir eine Fw für die 7050 erstellt. Statt F!Box steht jetzt nur noch ein Leerzeichen drin. Probier das doch mal.
[Edit4] Auf Anfrage kann ich das entsprechende Image gerne zur Verfügung stellen
Grüße

 

[rpc]

das ist der entsprechende Abschnitt (siehe Anhang) bei mir (7050).

Da ich nicht so der große AVM-Crack bin wäre es nett wenn ihr mal die Vorsehensweise abnicken könntet:

(1) also "F!Box " durch "FBox" (und dahinter nur 00 00 00 00) ersetzen (um also 14 bytes in der Summe des host_uniq zu haben), und das Image neu zusammenzusetzen (analog http://www.ip-phone-forum.de/showpost.php?p=775110&postcount=33)

(2) firmware drauf ist die *.33, muss ich erstmal downgraden, oder ersetzt er beim update mit der gleichen Revision auch alle Dateien ?


[EDIT: SORRY, hab' das Image gar nicht gesehen, danke TrinityOne! ]

 

[MaxMuster]

Downgrade ist nicht erforderlich, es wird immer das komplette Image ersetzt.

Zum Testen ginge es auch ohne neues Image:
Das "gepatchte" Kernelmodul auf die Box bringen (per wget, tftp ...) und dort das originale Modul "übermounten".

Dazu müsstest du erstmal das Modul entladen (rmmod), ggf. in einer "Kette" von rmmods, falls noch andere Module darauf zugreifen (was man mit "lsmod" sehen kann) dann die Datei "übermounten", wenn z.B. die neue Datei "/var/tmp/kdsldmod.ko" ist:

mount -o bind /var/tmp/kdsldmod.ko /lib/modules/2.6.13.1-ohio/kernel/drivers/dsld/kdsldmod.ko

und danach das Modul per "modprobe kdsldmod" wieder laden (ggf. die anderen entladenen Module neu laden).


Jörg

 

[TrinityOne]

Danke für den Hinweis mit dem Imgae Max, habe es entsprechend gerade umgesetzt Ich bin gespannt wie ein Flitzebogen, ob das klappt
Also, ich habe F!Box<blank><blank><blank> mit <blank> ersetzt, damit ist der Uniq natürlich kürzer als 14, und mit Hilfe der fwmod von Freetz ein neues Image erstellt. Damit hast Du ein Tool um das Image zu entpacken und mußt das nicht zu Fuß wie in dem von Dir verlinkten Beitrag machen. Mal wieder ein großes Danke an die Maintainer von Freetz!

Der Ansatz mit dem übermounten des Modul ist klasse. Damit sparst Du Dir das flashen des Images.

 

[rpc]

Danke euch beiden, habe das image aufgespielt - Box läuft noch ;-) - irgendwie scheint aber der dsld aber damit zu haken, jedenfalls startet dieser leider nicht, und kein PPPoE möglich.

Jan  1 01:16:36 dsld[586]: startup (May 10 2007 13:25:44)
Jan  1 01:16:36 dsld[588]: DSL Mac 00:04:0e:b7:73:38
Jan  1 01:16:36 dsld[588]: VOIP Mac 00:04:0e:b7:73:39
Jan  1 01:16:36 dsld[588]: VCC2 Mac 00:04:0e:b7:73:3a
Jan  1 01:16:36 dsld[588]: VCC3 Mac 00:04:0e:b7:73:36
Jan  1 01:16:36 dsld[588]: Can't open /dev/kdsld - No such device or address (6)

 

[TrinityOne]

was sagt lsmod? Bzw. insmod auf das gepatchte Modul? Und dmesg ?
[Edit] Ich will auch nicht ausschließen, dass das Image korrupt ist. Vielleicht flasht Du die Original .33 wieder und machst den Vorschlag von Max.

 

[rpc]

Hatte leider schon wieder die original aufgespielt, und test gerade die Methode von Max.

Den dsld muss ich doch dann auch neu starten, oder?