Annex A im und fürs Ausland einrichten.

@imagomundi:

1. Lass europeart doch mit ruKernelTool experimentieren, dann lernt er zumindestens seine Box besser kennen.

2. Zur 7270_v3:
Damit kennst Du Dich sicher besser aus als ich, der noch nie eine v3 in den Fingern hatte. Bisher habe ich "nur" den AnnexA DSL Treiber der 74.04.xx FW für das Patchen diverser 7240 und 7270_v1 verwendet.

3. Zu Deiner wiederholten Empfehlung, "kernel_args annex=A" zu setzen, falls die Box mit einer MultiAnnex FW nicht synchronisieren will:
Wie verstehst Du folgendes Zitat von Jpascher (von gestern, 23.04.2010)?
Derzeitiger Stand ist, dass bei einer internationalen Firmware mit Multiannex und Multilingual kernel_args keine Annex Angabe enthalten darf. Und die Variable Annex auf B gesetzt sein muss. Für reine "de" Versionen hat der Wert von Annex im kernel_args auch zu entfallen. Und Annex ist auch auf B gesetzt.
Wohl können nach wie vor die meisten de Firmwares mit den über kernel_args Annex=A Parameter auf Annex A umgestellt werden jedoch sind dann in fast jeden Fall die Treiber nicht optimiert für Annex A. Im Fall einer Multiannexfirmware hätte der Parameter Vorrang vor den Einstellungen die in der Bedinugsoberfläche vorgenommen werden.
Ich habe noch nie "kernel_args annex=A" gebraucht, um mit einer MultiAnnex FW an AnnexA zu synchronisieren. Ich weiss auch nicht, was dieser zusätzliche Parameter hierbei bringen sollte. Wenn man MultiAnnex korrekt konfiguriert hat, ist "annex A" gesetzt und der passende AnnexA Treiber aktiviert.
Meine Interpretation ist, dass man bei MultiAnnex FW "kernel_args annex=A" nicht setzten sollte.
 
[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
[Edit frank_m24: Vollzitat gelöscht, siehe Forumregeln.]
ich seh das auch so - ich versuchs jetzt nochmal.
Das wegen der Leitung: Ich hab im Moment nur die Daten angeschlossen - die normale Leitung werd ich wahrscheinlich gar nicht hernehmen, da ich einen sipgate oder netelip account verwenden wollte.
Nochwas wegen dem Splitter: Der Splitter hier in Spanien ist mehr sowas wie ein Filter - d.h. wenn du das Modem direkt in die Telefonbuchse steckt gehts auch (der Filter liegt sozusagen nur auf der Telefonleitung um die hohen Toene der Daten aus dem Spektrum zu filtern. Die DSL Leitung ist allerdings nur durchgeschleift.
Ist das mit dem dt. Splitter auch so oder macht der mehr? Sollte ich es mal mit einem dt. Filter versuchen (waere Misst - den muestte ich mir erst bestellen)

[Beitrag 2:]
Noch eine Frage zur Leitung: Die meisten Router haben sowas wie eine Protokollliste (bei der man z.b. die dB der Leitung, ausgehandelte Protokolle etc. sieht)
Auf der Seite mit den Grafiken (im 7270) steht bei mir immer 0.
Sollte das denn nicht schon hoeher stehen auch wenn sich der Annex-A noch nicht verbunden hat?
Hat schonmal jemand den Router ohne den Splitter direkt an die Leitung gesteckt (ohne Telefon parallel) und hat funktioniert?
Ich frag jetzt mal so dumm da mir das seltsam vorkommt dass sich da so gar nix ruehrt. Der router meldet wenn ich manuell die Befehle eingebe (per Telnet) und dann den Router restarte per init.d, dass er den Treiber fuer Annex-A sucht (und der ist auch da) - dann sollte er ihn auch finden...
 
Hier werden ein paar Dinge gewaltig durcheinander gewürfelt! :)

Hier mal mein Stand.Es gibt eigentlich 3 Fälle:
  1. Fritzboxen mit Multi-Annex-Firmwaren von "Werk" ab
    - 7570 mit internationaler Fimrware
    - 7270_v3
    Bei der 7570 Fimrware kenne ich die Umschaltung von Annex ausschließlich über die Benutzeroberfläche der Fritzbox. Welcher Annex verwendet wird, steht auch in der exports drin und diese Firmware reagiert auch nicht auf Veränderung über die Variablen "annex" und "kernel_args".
    Ich gehe davon aus, dass es bei der 7270_v3 auch so ist.


    [*]"normale" Fritzboxen, also alle anderen, die nicht in Punkt 1 stehen
    Die Variable "annex" wird schon durch den Bootloader gesetzt und lies sich auch mit Kommandos nur kurzfristig umsetzen. Beim nächsten Reboot wird die Variable aber wieder auf den im mtd2-Bereich voreingestellten Wert gesetzt.

    Und je nach Firmware und je nach dem was für ein Wert in der "annex"-Variablen steht, wird der passende Treiber für Annex A oder B verwendet bzw. der DSL-Treiber in Annex A- oder Annex B-Mode betrieben.

    Da man aber die Variable "annex" nicht ändern kann, zumindest nicht nachhaltig und auf einfachem Weg, kann man den Annex über die Variable "kernel_args" setzen. kernel_args sind höherwertig und wie mir MaxMuster in einem Script auch zeigte, sticht diese Variable immer die "normale" Annex-Variable! Quasi Ober sticht Unter ;-)

    Damit lassen sich eben beispielsweise Annex B Boxen mit Annex B Firmware im Annex A-Mode betreiben. Ob dann eine gute DSL-Verbindung zustande kommt, hängt aber wieder von vielen anderen Faktoren ab.


    [*]Boxen mit modifizierten Firmwaren
    Da gibt es so allerlei. Von der "Kopiermethode", über Freetz bis hin zu Speedport2Fritz. Alle 3 Methoden "implantieren" einen Annex A-Treiber.

    Bei der Kopiermethode ist es eben wichtig, dass der Treibername stimmt und das die Firmware bzw. die darin enthaltenen rc-Scripte dann je nach "Vorhandensein des Treibers" den richtigen Treiber benutzt.

    Freetz und S2F passt ggf. zusätzlich eben noch Variablen bzw. Scripte mit an.

Und natürlich spielen die passenden Kabel auch eine wichtige Rolle, aber das ist ein anderes Thema.

happy computing!
R@iner
 
@skyteddy
  1. Fritzboxen mit Multi-Annex-Firmwaren von "Werk" ab
    - 7570 mit internationaler Fimrware
    ... diese Firmware reagiert auch nicht auf Veränderung über die Variablen "annex" und "kernel_args". ...
Ich muss das erneut in den letzten Firmwareversionen von AVM nachsehen, bis jetzt war es so wie ich es beschrieben habe.

EDIT2:
Habe nun in der 75.04.81. nachgesehen, ist kernel_args noch in Verwendung!

7270v3 ist es genauso, also wird es sicher auch bei allen andern multiannex Firmwares so sein.


Siehe folgenden Auszug aus der rc.S:

## aus den kernel parameters die für die module ermitteln
##########################################################################################
avm_event_param=
atm_param=
ar7wdt_param=
cpmac_param=
i2c_param=
annex_param=
for i in `cat /proc/cmdline` ; do
case $i in
avm_event_*)
avm_event_param=$i
;;
atm_*)
atm_param="$atm_param $i"
;;
ar7wdt_*)
ar7wdt_param="$ar7wdt_param $i"
;;
cfg_*)
cpmac_param="$cpmac_param $i"
;;
i2c_*)
i2c_param="$i2c_param $i"
;;
annex=*)
annex_param=${i##annex=}
;;
CPU_NR=*)
CPU_NR=${i##CPU_NR=}
;;
mute=*)
mute_param=${i##mute=}
;;
*)
;;
esac
done
########################################################################
Siehe folgenden Auszug aus der rc.conf:

Wobei "annex_param" der in kernel_args übergbebe Wert ist.

##########################################################################################
## Annex
##########################################################################################
if [ -z "$annex_param" ] ; then
if [ "${CONFIG_DSL_MULTI_ANNEX}" = "y" ] ; then
LOADANNEX=`echo ar7cfg.dslglobalconfig.Annex | ar7cfgctl -s 2>/dev/null | sed s/\\"//g` ; # annex aus userselection?
if [ -z "${LOADANNEX}" ] ; then
export ANNEX=`cat $CONFIG_ENVIRONMENT_PATH/annex` ; # annex aus /proc nehmen, nicht von Config!
else
export ANNEX=${LOADANNEX} ; # annex aus userselection
fi
else
export ANNEX=`cat $CONFIG_ENVIRONMENT_PATH/annex` # annex aus /proc nehmen, nicht von Config!
fi
if [ -z "${ANNEX}" ] ; then export ANNEX=${CONFIG_ANNEX} ; fi # nur wenn vom /proc nix kommt, default setzen.
else # annex_param
echo "overwrite annex"
export ANNEX=$annex_param
fi
##########################################################################################
Wichtig ist da das if [ -z "$annex_param" ] ; then

Wenn somit die Variable gefunden wird zieht diese vor den Menüeinstellungen.
Du kannst das ja nochmal auf einer Box testen.

Bitte ändere deinen Beitrag entsprechend ab.

Die beiden geposteten Ausschnitte sind Vollständig was diese Variablen betrifft in der Firmware wird an keiner andern Stelle noch etwas an diesen Entscheidungen geändert. Jeder der die Skipre lesen kann kan sich daraus auch ein eigns bild machen was da entschieden wird.

In der Firmware selber wird nur mehr die Variable "ANNEX" weiter verwendet um wie erwähnt entweder einen Parameter an den DSL Treiber zu übergeben oder eine andern Treiber auszuwählen aber auch in der GUI wird diese Parameter ausgiebig genutzt.
 
Zuletzt bearbeitet:
Hier werden ein paar Dinge gewaltig durcheinander gewürfelt!
Beziehst Du das "würfeln" auch auf meinen Beitrag? Ich habe nicht das Gefühl, "durcheinander zu würfeln".

Vielleicht muss ich ergänzen, dass ich beim Modden einer B-Box auf Annex A immer:
a) "annex a" im bootloader fixiere (wenn sinnvoll, auch HWRevision)
b) einen passenden AnnexA DSL Treiber "implantiere" bzw. gleich die passende AnnexA FW verwende
Auf dieser Basis braucht man kernel_args nicht.
Mir kommt es darauf an, die optimale AnnexA Qualität heraus zu kitzeln und nicht "irgendwie irgendeine" Verbindung herzustellen.

Neu wäre für mich, wenn aktuelle FW Versionen, z.B. von der 7570 oder 7270_v3, den Parameter "kernel_args" gar nicht mehr kennen bzw. nicht darauf reagieren. Jpascher hatte das ja zunächst bestätigt, aber in seinem "Edit2" widersprochen:
Jpascher schrieb:
Habe nun in der 75.04.81. nachgesehen, ist kernel_args noch in Verwendung!

Fazit (für mich):
- Wenn ich eine AnnexB Box ordentlich auf AnnexA patche, brauche ich "kernel_args" nicht.
- Ob "kernel_args" in speziellen Fällen schaden kann, weiss ich nicht.
- ruKernelTool ist eine prima und vielseitige Hilfe, speziell für diejenigen, die nicht alles "von Hand" machen können oder wollen.
 
@el_valiente
Jpascher hatte das ja zunächst bestätigt, aber in seinem "Edit2" widersprochen:


Ja stimmt, bin normal leicht zu irritieren und hab den Fehler bei mir gesucht, und vorschnell eine Falsche Erwiederung gegeben.


Fazit (für mich):

- Wenn ich eine AnnexB Box ordentlich auf AnnexA patche, brauche ich "kernel_args" nicht.


Ja stimmt auch wenn du den Bootlader oder die Firmware entsprechend pacht dann zieht kernel_args nicht mehr.

- Ob "kernel_args" in speziellen Fällen schaden kann, weiss ich nicht.


Nein es kann halt nicht mehr übers Routermenü gewählt werden auch wenn das Menü vorhanden ist.

- ruKernelTool ist eine prima und vielseitige Hilfe, speziell für diejenigen, die nicht alles "von Hand" machen können oder wollen.

EDIT: Offtopic Teil gelöscht ich hoffe auch die Antwort darauf wird entsorgt.
 
Zuletzt bearbeitet:
Habe nun in der 75.04.81. nachgesehen, ist kernel_args noch in Verwendung!
Ich kenne die Scripte und war selber verwundert, bei folgendem Test:

- 75.04.81-16961 geflasht
- Beim ersten Booten folgendes eingestellt: Sprache Deutsch und Land Deutschland
- Router fertig konfiguriert und rebootet
- Einstellungen gesichert. Im der ar7.cfg im Bereich dslglobalconfig steht Annex = "B";
- hab dann ein echo "kernel_args annex=A" > /proc/sys/urlader/environment gemacht und den Router rebootet
- ich war überrascht, er ging sofort online
- Via Telnet eingeloggt und nachgeschaut, aber kernel_arg ist annex=A
- nochmal rebootet
- ging wieder online und auch kernel_args ist immer noch annex=A

Daher komm ich zu dem Schluß, dass diese Variable zumindest bei dieser Firmware wirkungslos ist.

Ich muß jetzt dann los, schau es mir aber hernach nochmal an.


- ruKernelTool ist eine prima und vielseitige Hilfe, speziell für diejenigen, die nicht alles "von Hand" machen können oder wollen.

Ja fast schon zu einfach, da sich immer weniger Leute für andere Lösungen Interessieren und uns die Rückmeldungen weg bleiben.

Das ist leider so wir "Elektroniker" haben uns ja schon immer selber weg rationalisiert.
Das "Bessere" was immer das sein mag ist halt immer der Feind des Guten.
Sorry, das versteh ich nun überhaupt nicht und das aus mehreren Gründen!

Thema Annex oder Branding-Umstellung:
Das Forum ist voll von Threads zu Versuchen wie man das eine und wie man das andere umstellen kann. Eisbär hat mal angefangen "How-Tos" zu schreiben, was aber auch immer wieder zu Fragen führt, zumal immer noch zuviele Pseudo-Images rumschwirren, die je nach Box und Firmware eben mal funktionieren oder nicht, zu Problemen führen oder gar ne Rebootschleife auslöst.

Das war der Beweggrund für mich, diese beiden Funktionen "Annex auslesen ändern" und "Branding auslesen/ändern", zu implementieren, denn bei 90% aller Anfragen spulen wir wieder die selben Fragen mit den selben Lösungen runter und versuchen den ein oder anderen Fehler der User wieder gerade zu biegen.

Mit dem ruKernelTool kannste hingengen nur das machen, was die Firmware hergibt, mehr aber auch nicht, das dafür aber fehlerlos. Es ist eine Erleichterung und vermeidet unnötige Fheler und somit unnötig wiederkehrende Fragen.

Thema Speedport flashen:
Auch hier kamen die Tage von Dir solche Anmerkungen, die ich nicht verstehe.

Der W920V ist der einzige Speedport-Router, der direkt geflasht werden kann. Zum einen wollen 95% der User ne schnelle und einfache Lösung und zum anderen ist die Firmware-Auswahl sehr begrenzt.

Von daher brauchst Du Dir da keine Sorgen machen, dass Du überflüssig bist, denn
- es gibt viele W920V-User, die immer aktuelle Labors haben wollen
- es gibt noch sehr viele andere Speedports die bis heute noch nicht sauber laufen
- Freetz-Unterstützung fehlt auch
- es hoffentlich auch zukünftig neue Speedport-Modelle rauskommen, die von AVM stammen

Du hast da in meinen Augen immer zuviel Konkurrenzdenken. Sieh das lieber mehr als ein Miteinander, denn mit dem ruKernelTool wurden sehr sehr oft missglückte s2f-Versuche gerettet, denn nicht jeder ist in der Lage oder Willens, das mittels Linux wieder gerade zu biegen.

Und die Frage nach "besser" und "gut" stellt sich für mich überhaupt nicht!

Und ehrlich gesagt habe ich keine Lust, laufend remote irgendwelche Router zu reanimieren oder auch im Forum die immer wieder selbe Leier runterzurattern. Es reicht mir jetzt schon, dass vieles wiederholt werden muß.

Ich bin froh darum, dass durch dieses Tool das Supportaufkommen weit weit runter gegangen ist.

Und keine Sorge, Bastler die basteln wollen, basteln auch weiter!

Happy computing!
R@iner
 
Noch eine Frage zur Leitung: Die meisten Router haben sowas wie eine Protokollliste (bei der man z.b. die dB der Leitung, ausgehandelte Protokolle etc. sieht)
Auf der Seite mit den Grafiken (im 7270) steht bei mir immer 0.Sollte das denn nicht schon hoeher stehen auch wenn sich der Annex-A noch nicht verbunden hat?

1. Dann wirst Du wohl auch NULL DSL-Verbindung haben.
2. Nein, wie soll denn eine Geschwindigkeit angezeigt werden, wenn keine Verbindung besteht?

Hat schonmal jemand den Router ohne den Splitter direkt an die Leitung gesteckt (ohne Telefon parallel) und hat funktioniert?

Nein, bin auch noch nie auf diese Idee verfallen - ich bin übrigens nicht in Deutschland, sondern in Venezuela und nutze die selbe Art "filtro" wie in Spanien - also nimm mal schleunigst zuerst einen "filtro" und verbinde die Box ordentlich damit so wie ich vorgeschlagen habe. Würde mich nicht wundern, wenn damit Dein Problem schon gelöst wäre.
Der router meldet wenn ich manuell die Befehle eingebe (per Telnet) und dann den Router restarte per init.d, dass er den Treiber fuer Annex-A sucht..

Welche Befehle gibst Du denn da in Telnet ein? Ich werde das Gefühl nicht los, daß entweder Du nicht so genau weisst, was Du tust oder wir wissen es nicht, weil Du es nicht mitteilst.

MEINE derzeit in Benutzung befindliche V3 hat übrigens auch OHNE irgendeine Modifizierung sofort an meiner A-Leitung synchronisiert,- das hatten auch andere User früher schon im Forum berichtet - d.h. die Box erkennt AUTOMATISCH, in welchem Annex-Netz sie eingesetzt wird.
Setzt natürlich immer voraus, daß die Anschlüsse in Ordnung sind (Kabel und Splitter=filtro)

Schliesslich: Lösche bitte das Vollzitat meines vorhergehenden Beitrags und fasse hintereinander geschriebene Beiträge per EDIT zusammen = Forenregeln! Es kann jeder selbst lesen, was andere User zuvor geschrieben haben.

Zur "Fachsimpelei" mit skyteddy und JPascher erspare ich mir hier zunächst einen Beitrag (obwohl dazu noch einiges zu sagen ist), um nicht vom eigentlichen Thema/Problem abzukommen.
 
Ja lassen wir die Fachsimpelei, wichtiger ist das Resultat warum es so is und nicht anders - egal wer nun Recht hat es könnte ja ohne weiteres sein, dass die "Wahrheit" wieder mal irgendwo dazwischen liegt oder beides stimmt unter bestimmten Bedingungen.

Egal was nun stimmt bezüglich kernel_args in Verbindung mit multannex Firmwares eins ist sicher man bracht den parmaeter nicht mehr bei einer Multiannex Firmware.


Ich habe keiner Zeit es bei mir erneut durchzusetzen.
Ich warte was andere dazu noch berichten.


Im übrigen finde ich eure (imagomundi und el_valiente) Arbeit hier im Unterforum bezüglich annex A ausgezeichnet!


Arbeite derzeit wieder Vorrangig in meiner Handwerklichen Tätigkeit.

Generell will ich ein Miteinader und nicht Konfrontationen, aber angemessen sachliche Kritik finde ich unbedingt erforderlich damit auch Fortschritt möglich ist.
 
Splitter/Filter

1. Dann wirst Du wohl auch NULL DSL-Verbindung haben.
nutze die selbe Art "filtro" wie in Spanien - also nimm mal schleunigst zuerst einen "filtro" und verbinde die Box ordentlich damit so wie ich vorgeschlagen habe. Würde mich nicht wundern, wenn damit Dein Problem schon gelöst wäre.

Also nochmal:
Mein DSL Leitung funktioniert - mit einem normalen spanischen Router
Zu den Splittern: Abhaengig vom Provider erhaeltst du in Spanien mit dem Router verschiedene Filter/Splitter.
Ums aber ganz einfach darzustellen: Es handelt sich um einen stinknormalen Doppelstecker, auf der einen Seite steckst du den Router ein, der dann direkt an der Telefonleitung haengt, auf der anderen Seite steckst du den Filter ein und danach das Telefon (es kommen auch mehrere Filter mit falls du mehrere Telefone an einem Amt hast). Wie schon vorher erlaeutert bringt der Filter in Bezug auf den Router gar nix - sondern filtert nur die hohen Routertoene aus dem Telefon (wenn man das Telefon ohne den Filter ansteckt hoert man das Datenpiepsen)
Deswegen meine Frage ob der Router vielleicht den dt. Splitter benötigt (kann ja sein dass die spanischen Geraete den schon mit drinnen haben)
Vielleicht liegt da der Wurm - am liebsten wuerde ich den Router einfach so hernehmen - ohne irgendwelches Patchen
 
@europeart:

Splitter ist für AnnexB und Filter ist für AnnexA, da muss man nicht mehr diskutieren.
Und Du hast recht: Der "microfiltro" ist nur erforderlich, wenn man parallel auf der selben Leitung telefoniert.
Und selbstverständlich funktionieren die Fritzboxen auch mit Filter, nicht nur mit mit (deutschem) Splitter.

Wenn Du die FB nicht anfassen willst, empfehle ich Dir, das AnnexA Modem/Router vorzuschalten, das Du vom Provider (Telefónica?) bekommen hast.
Dahinter betreibst Du die FB im Modus "Internetzugang über LAN1" und fertig. Dann ist das interne Modem der FB deaktiviert und der Annex spielt keine Rolle.
 
Ums aber ganz einfach darzustellen:


Für Dich ist das ganz einfach, weil Du es vor Dir siehst - soll ich mal schreiben, was ich aus Deiner Beschreibung herauslese:

Du hast IN DER WAND eine Doppel(telefon)steckdose mit 2 Buchsen für RJ11-Stecker - an eine davon (TELEFON) hängst Du dann noch einen Filter und danach an diesen Filter ein Telefon. An die andere Buchse (MODEM) steckst Du DIREKT den (spanischen) Router. Ist das so?

Falls ja, würde ich das so interpretieren, daß die "Doppelsteckdose" bereits ein Splitter/ Filter (unsichtbar - unter Putz) ist. Dann allerdings müsste das DSL laufen, wenn Du die DSL-Buchse der FRITZ direkt mit einem normalen 2-adrigen Telefonkabel mit der "MODEM"-Buchse des "Doppelsteckers" verbindest - vorausgesetzt sie läuft mit dem A-Treiber und die ATM-Einstellungen für DSL (VPI/VCI und Kapselung) sind richtig.

Mein Splitter/Filtro sieht so aus, wie auf diesem Bild die Nr. 553-1185 ND, 553-1187 ND und 553-1495 ND. Das Kabel mit dem RJ11-Stecker wird in die Wandtelefonbuchse gesteckt und in die Buchsen an dem Splitter/Filter kommt einmal der Anschluß für das Modem/den Router/die FRITZ und in die andere der fürs Telefon.
 
Erfahrungen hier in Mexiko.
14 tage Mailkontakt mit AVM, da meine 7270 int. trotz Einrichtung auf Annex=A sich partout nicht verbinden will. Gestern kam die Forderung von AVM die Box zu resetten, auf Annex=A einzustellen und neu einzurichten. Dies hatte ebenfalls keinen Erfolg.
Heute habe ich in Eigeninitiative den kernel_arg manuell via Telnet von Annex=A auf Annex=B umgestellt und siehe da die Box verbindet sich anstandslos.
In der Support Datei hatte ich vorher als Verbindung Annex=A, die kernel_arg verblieb aber auf Annex=B. Anscheinend war dies mein Problem.
Bin mal gespannt was mir morgen AVM drauf antwortet.

Grüsse aus Mexiko
Andreas
 
Heute habe ich in Eigeninitiative den kernel_arg manuell via Telnet von Annex=A auf Annex=B umgestellt und siehe da die Box verbindet sich anstandslos.

Wieso hattest Du denn den "kernel_arg" auf A umgestellt? Bei einer Internationalen sollte doch die reine Auswahl von "Annex=A" (nicht zu verwechseln mit "kernel_args annex") im WebGui bei der Ersteinrichtung ausreichen, damit die Box sich im A-Netz verbindet. Oder "liefert" Dein Provider vielleicht doch Annex-B?
 
Ich habs einfach nicht hinbekommen das sich die Box verbindet.
AVM hat schon diverse Suportdateien zugeschickt bekommen und meinte nun das ich die Box noch einmal resette und Annex=A erneut einrichte. Da dies wiederum keinen Erfolg brachte hab ich hier aus dem Forum diese Kernel-Änderung per Telnet angewendet und siehe da, nach einem Neustart verbindet sich die Box anstandslos.
2 Wochen Frickelei mit AVM brachten keine Änderung. Seit heute morgen läuft sie anstandslos.

Das ist fuer mich das wichtigste

Andreas

PS: Mein Provider ist Telmex Prodigy der Annex=A anbietet mit VPI/VCI 8/81
 
Gut das sollte sich Skytaddy mal auch durchlesen.

Wir hatten ja da unterschiedliche Standpunkte, was den kernel_args annex=A Parameter bei einer multiannex Box angeht.

Ich war fix der Meinug dass der Parameter auf jeden Fall funktioniert für annex=A
 
I

Das ist fuer mich das wichtigste

Klar ist das so - deshalb nur für die "Wissensdatenbank" dieses Forums die Nachfrage: Hattest Du denn selbst zuvor die Box auf "kernel_args annex A" gestellt oder hattest Du nur in der Oberfläche bei der Annex-Auswahl "A" gewählt?
 
Heute habe ich in Eigeninitiative den kernel_arg manuell via Telnet von Annex=A auf Annex=B umgestellt und siehe da die Box verbindet sich anstandslos. In der Support Datei hatte ich vorher als Verbindung Annex=A, die kernel_arg verblieb aber auf Annex=B. Anscheinend war dies mein Problem.
Das finde ich nun doch sehr interessant und es passt auch zu diesem statement von Jpascher:
Derzeitiger Stand ist, dass bei einer internationalen Firmware mit Multiannex und Multilingual kernel_args keine Annex Angabe enthalten darf.
Und die Variable Annex auf B gesetzt sein muss.
Es scheint da doch einige Konflikte zu geben mit "kernel_args annex=a/b" bei FW Versionen mit Multiannex.

Was sagen skyteddy und imagomundi dazu?
 
Wenn das Menü für Annex Umschaltung funktionieren soll darf kein Annex über kernel-args gewählt werden sonst hat der Parameter Vorrang.

Skytaddy hat behauptet, dass der Parameter bei Multianex Firmware funktionslos ist.

Mag sein, dass es irgendwelche Boxen gibt bei denen das so ist oder Ihm ist doch ein Fehler beim Testen passiert.
 
Klar ist das so - deshalb nur für die "Wissensdatenbank" dieses Forums die Nachfrage: Hattest Du denn selbst zuvor die Box auf "kernel_args annex A" gestellt oder hattest Du nur in der Oberfläche bei der Annex-Auswahl "A" gewählt?

Ok. Die ganze Historie:
Am Anfang stellte ich beim ersten Booten die Box auf Deutsch und Annex=A
meine Box ist von Sipgate Modell 7270 20002427
Die Box konnte sich mit diesen Parametern nicht verbinden.
Als erstes wollte ich daraufhin die Firmware updaten. Anstatt das AVM im FTP-Verzeichnis der 7270 die Typen in 20002403, 20002427 und 20002430 einteilt, heissen sie hier de, at-ch und en.

Da ich Deutsch wollte habe ich mir die at-ch Firmware mit 54.04.80 gezogen. Die Box installierte sie anstandslos, verband sich auch. Leider blinkte am nächsten Morgen die FB und war nicht mehr ansprechbar, so das ich sie mit dem Recovery resetten wollte. Das ging dann nicht da Hardware (AVME) und Software (AVM) im Branding nicht übereinstimmten. Dafuer brauchte ich 2 Tage um als Grund das geänderte AVM-Branding zu spezifizieren.
Letztendlich hab ich sie gerecovert mit derrichtigen englischen FW-Recovery.
Da die Verbindung wiederum nicht funktionierte habe ich das alte Speedtouch 585v6 als Modem zwischengeschaltet und bei dann bestehender Verbindung die FW aktualisiert (54.04.81).
Bei den diversen Supportdateien die AVM anforderte fiel mir schon auf das, obwohl oben Annex=A (oberen Zeilen) angegeben ist der Parameter kernel_arg auf Annex=B stand.
Heute morgen kam dann von den AVM-Technikern die Forderung das Modem in den Werkzustand zurückversetzen und anschliessend als Annex=A einzurichten und wiederum die Support-Dateien zu erstellen.
Als ich wiederum keine Verbindung erhielt habe ich stattdessen nach den Tipps hier im Forum per Telnet den kernel_arg Parameter auf Annex=A umgestellt und die FB neugestartet.
Und siehe da die FB fährt hoch und verbindet sich ohne weiteres Murren.
Vielleicht spielt bei europ. DSL-Netzen der kernel_arg keine Rolle, hier in Mexiko vielleicht schon.
Wie schon geschrieben hat Telmex Prodigy einen VPI/VCI von 8/81 und die Verbindung als PPPoE und LLC angegeben.
Falls es jemand interessiert oder hilft hänge ich die alte Konfigurationsdatei des Speedtouch 585v6 hier an. Dies funktionierte monate ohne Probleme.

Ich habe noch folgende fragwürdige Parameter aus der support.txt der FB kopiert:

CONFIG_DSL_MULTI_ANNEX=y
CONFIG_ANNEX=B

DSL Modem Statistics:
--------------------------------
[DSL Modem Stats]
Annex: Unknown psd_mask_qualifier: 0x0000

Kann ich diese auch noch auf Annex=A umstellen? Bringt mir das was?

Dank euch im voraus

Andreas
 

Anhänge

  • user_ini.txt
    68.6 KB · Aufrufe: 3
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.