Mehrfaches Recovern wegen Fehler in Portweiterleitung?

[maceis]

Hallo zusammen,

ich musste heute meine 7270_v3 schon zum zweiten Mal recovern, nachdem ich mit "allcfgconv" Portweiterleitungen in die ar7.cfg eingetragen hatte, die auf meiner 7270_v1 problemlos funktioniert haben.

Der Sache wollte ich auf den Grund gehen und bin dabei auf einige "Merkwürdigkeiten" gestoßen.

1. Das Flashen von mtd1 mit einem kernel.image über ADAM2 funktionierte zwar, die Box startet danach aber genauso wenig wie vorher.
   Erst ein recover über das AVM Programm erweckt die Box wieder zum Leben.
   
   Frage 1: Liegt das evtl. daran, dass die Konfigurationsdateien in mtd3/mtd4 liegen, die beim Aufspielen eines neuen kernel.images unverändert bleiben?
   
   Frage 2: Kann man ein Backup von mtd3 und mtd4 genauso über ADAM2 zurückschreiben, wie das kernel.image? (put backupfile mtd4)
   
2. Nachdem das Einrichten der Portweiterleitungen mit "allcfgconv" in freetz zwei mal schief gegangen ist, wollte ich das selbe testhalber mal in einer Original Firmware versuchen.
   Dabei habe ich festgestellt, dass man in der AVM Firmware zwar mit "allcfgconv" dyndns Konten (ddns.accounts) hinzufügen kann (der Mechanismus an sich funktioniert also), nicht aber ar7cfg.dslifaces.dsldpconfig.forwardrules
   Besonders merkwürdig fand ich, dass der return code nach "allcfgconv" 0 war (also alles in Ordnung). Trotzdem waren im outfile die Einträge nicht drin
   
3. In der Freetz Firmware hat das funktioniert, soll heißen, die Weiterleitungen wurden wie gewohnt in die ar7.out Datei eingetragen. Nur startete die Box nicht mehr, nachdem ich das outfile auf .../flash/ar7.cfg kopiert hatte.
   
   Der entsprechende Abschnitt in ar7.cfg hat exakt so ausgesehen, wie vorher bei meiner 7270_v1 auch. Nur die VOIP Weiterleitung (5060 udp und tcp) auf 0.0.0.0 hatte ich nicht übernommen, weil nur noch unter einem separaten Eintrag (ar7cfg.pppoefw.voip_forwardrules) stehen.
   
   Frage 3: Hat jemand irgendeine Idee, warum das Merken von forwardrules in der Freetz Firmware geht und in der AVM Firmware nicht?
   
   Frage 4: Kann es sein, dass auf der 7270_v3 gar keine Portweiterleitungen auf 0.0.0.0 mehr akzeptiert werden? Startet vielleicht deshalb die Box nicht mehr?

Ich weiß, das ist jetzt viel Text.
Ich würde mich aber trotzdem freuen, wenn mir da jemand auf die Sprünge helfen könnte.

Letzte Frage am Rande:
Hat schon jemand herausgefunden, wie man mit "ar7cfgctl" Werte in der ar7.cfg setzen kann? Laut Hilfe soll es ja gehen, ist mir aber noch nicht gelungen.

Danke im Voraus und Gruß
maceis

 

[MrTweek1987]

Letzte Frage am Rande: Fb-Editor tuts auch Aber vorsicht beim werkeln ^^ !

 

[maceis]

Es gibt eine ganze Reihe von Möglichkeiten, ar7.cfg zu konfigurieren.
In der Frage ginge mir konkret um "ar7cfgctl".

Zwischenzeitlich habe ich meine forwardrules mit nvi eingetragen.
Box neu gestartet - kein Problem.
Ich komm auch von außen drauf.

Ich würde es ja gerne mit "allcfgconv" noch einmal versuchen, aber ich trau mich nicht.

 

[RalfFriedl]

nachdem ich mit "allcfgconv" Portweiterleitungen in die ar7.cfg eingetragen hatte.

Wie macht man das denn mit allcfgconv?

Liegt das evtl. daran, dass die Konfigurationsdateien in mtd3/mtd4 liegen, die beim Aufspielen eines neuen kernel.images unverändert bleiben?

Ja.

Kann man ein Backup von mtd3 und mtd4 genauso über ADAM2 zurückschreiben, wie das kernel.image?

Sollte funktionieren.

 

[maceis]

Wie macht man das denn mit allcfgconv?

Das ist eigentlich relativ einfach.
Das größte Problem für mich war, dass ich keine gute Dokumentation gefunden hatte und deswegen eine Weile herum probieren musste.

Grundsätzlich gibt es wohl mehre Möglichkeiten.
Ich verwende am liebsten eine Merge Datei zum Einlesen und lasse mir eine Datei schreiben, in die ich noch mal hineinschauen kann, bevor ich damit die ar7.cfg im Flash überschreibe. Man kann aber auch direkt die ar7.cfg im Flash überschreiben lassen.

Der Aufruf geht so:

allcfgconv -C ar7 -M [I]/var/tmp/ar7_infile[/I] -o [I]/var/tmp/ar7_outfile[/I]

Dabei steht -M für merge, wobei das inputfile im Format der ar7.cfg sein muss.
Bei -m muss das infile im diff Format sein. Das habe ich aber noch nicht probiert.

Mit -o wird die Ausgabedatei angegeben, die dann wieder im Format der ar7.cfg erstellt wird. Es wird eine komplette ar7.cfg erstellt, wobei die aktuelle Datei im flash mit dem infile "gemergt" wird.
Mit -i kann man auch ein anderes input configfile angeben, als die im flash.

Mit -O kann man die Datei direkt im flash überschreiben,was ich aber nicht so gerne mache.

Das Wichtigste ist natürlich /var/tmp/ar7_infile.
Wenn hier Fehler drin sind, wird kein outfile erstellt und der return code ist anders als 0. Ich hatte schon 1, 3 und 6, was aber immer an Fehlern im infile lag, die ich daraufhin gefunden hatte.

Bis gestern war das Schöne an dieser Methode, dass man immer eine funktionierende ar7.cfg erhält, weil bei Fehlern im infile erst gar kein outfile erzeugt wird.

Hier mal ein konkretes Beispiel für ein infile:

ar7cfg {
dslifaces {
dsldpconfig { forwardrules =
                                       "tcp 0.0.0.0:22 0.0.0.0:22 0 # ssh-box", 
                                       "udp 0.0.0.0:1194 0.0.0.0:1194 0 # openvpn-box", 
                                       "tcp 0.0.0.0:2210 192.168.100.10:22 0 # ssh-rechner10", 
                                       "tcp 0.0.0.0:2211 192.168.100.11:22 0 # ssh-rechner11", 
                                       "tcp 0.0.0.0:5910 192.168.100.10:5900 0 # vnc-rechner10", 
                                       "tcp 0.0.0.0:5911 192.168.100.11:5900 0 # vnc-rechner11"
                                       ;
}
}
}

Die Formatierung dient nur der besseren Lesbarkeit des infiles.
Soweit ich beobachten konnte, erstellt 'allcfgconv' grundsätzlich eine schön formatierte ar7.cfg

Mit dieser Methode kann man übrigens auch sehr schön mehrere dyndns hosts anlegen.
Dabei können die Zugangsdaten im Klartext stehen. Das Verschlüsseln (base64, wenn ich nicht recht entsinne) übernimmt 'allcfgconv'.

Leider verstehe ich nach wie vor nicht, warum ein korrekt erzeugtes outfile zum Tod der Box führt.
Dies konnte ich bisher nur beim schreiben von ar7cfg.dslifaces.dsldpconfig.forwardrules beobachten.

Wenn ich die erzeugte Datei editiere, sieht der entsprechende Abschnitt genauso aus, wie wenn ich diesen in der ar7.cfg mit nvi direkt hineinschreibe. Dann funktioniert es aber.

Bin ratlos.

Gruß
maceis

 

[maceis]

Okay, ich bin zwischenzeitlich etwas weiter gekommen.

'allcfgconf' merged wohl nicht zu 100% mit der Datei im flash, zumindest nicht, so wie ich es aufgerufen habe.
Manche Werte können u. U. gelöscht oder mit den Voreinstellungen überschrieben werden.

Insbesondere werden anscheinend folgende Werte gelöscht (DELETED) oder auf die angegebenen Einstellungen geändert.

ar7cfg {
  dslifaces {
    ppptarget DELETED ;
    is_mcupstream = no; 
    stay_always_online = no; 
    username_prefix_list DELETED ;
    username_prefix_vdsl_list DELETED ;
    tcclassroutes DELETED ;
    dsldpconfig {
      security = dpsec_host;
    }   
  } { 
  }
}

Kann das der Grund sein, warum die Box nicht keine Verbindungen mehr annimmt?

Mir springt da insbesondere die Zeile
security = dpsec_host;
ins Auge.
Sollte da nicht
security = dpsec_firewall
stehen?


Edit:
Ich glaube, ich habe inzwischen auch die Lösung gefunden:
Wenn ich anstelle von
-M /var/tmp/ar7_infile
schreibe
-m /var/tmp/ar7_infile
werden die o.g. Werte unverändert aus der ar7.cfg im Flash übernommen.

Bei einem configfile scheint 'allcfgconv' zu erwatzen, dass bestimmte Werte gesetzt sind. Andernfalls werden wohl default Werte verwendet.
Bei einem diff file werden anscheinend wirklich nur die enthaltenen Werte überschreiben.
Wenn das input file allerdings gar keine Einträge für den Bereich ar7cfg enthält, wird dieser unverändert aus der Datei im Flash übernommen.
Soweit zumindest meine Beobachtungen.