[Gelöst] Adam2 "Dauer" verlängern?

[vice_pres]

Hi,

Gibts eigentlich irgendeine Chance die Zeit in der ADAM2 antwortet zu verlängern? Meine Testbox steht remote an meiner VM (mit IP-Steckdose - Ein/Ausschalten ist kein Problem) - aber egal was für einen Switch ich dazwischenhänge (und der ist nötig) - ich bekomm es nicht hin, ein Recover zu machen. Ich hab selbst mal nen 10mbit Hub an den eigentlichen Switch gehangen und an den Hub die Box... Da die Pakete vom letzten Switch mit VLan versehen werden ist es wahrscheinlich einfach echt zu knapp...

Daher war die Überlegung - wenn es denn überhaupt geht - das Zeitfenster fürs ADAM2 zu verlängern. Viel Hoffnung habe ich aber nicht

Gruß
Peter

 

[Ernest015]

Eine Möglichkeit wäre, einen Dauerping auf die FTP-Adresse zu senden:

Ein "DOS"-Fenster öffnen und dort den Befehl: ping -t 192.168.178.1 ausführen.
Das Recover kann dann normal und parallel dazu gestartet werden.

mfg

 

[dieguteFrauWaas]

Hilft dieser Beitrag evtl. weiter?

Die Idee ist, via Dauerping und Aufruf des Adam2-Interfaces des Bootloaders diesen aus der normalen (kurzen) Abarbeitung seiner Schritte rauszureißen. Danach hat man alle Zeit der Werlt, das Recover-Programm zu starten.

 

[vice_pres]

Leider nein - der Ping reicht nicht, mit einem einzigen Switch (und ich habe 8 Stück probiert) habe ich es geschafft ein einzigen Ping vom ADAM2 zu bekommen, aber das hat auch nicht gereicht.

Müsste also wirklich von Box-Seite aus passieren (wenn überhaupt möglich)

 

[koyaanisqatsi]

Mein Trick:
Fang Adam mit telnet ein!
Hab ich mal irgendwo gelesen (wehavemorefun oder so) und hat super funktioniert.
Also:
Auf Windows oder Linuxseite ein
telnet 192.168.178.1 21 <---<<< wie war nochmal der FTP-Port?
Telnet hält Adam fest solang wie du willst

 

[vice_pres]

Das nützt leider alles nichts...

Ich muss wenn dann die Zeit verlängern in der ADAM2 überhaupt auf ein erstes Kommando hört - aufgrund des Taggings etc... für den ersten Verbindungsaufbau ist die Dauer zu knapp. Ich bekomme GARKEIN Connect zum ADAM2 - also nützt auch kein telnet o.ä. was. Es muss wenn auf der Box gesetzt sein und die Zeit von 5 auf 10 Sekunden verlängern o.ä.

Aber ich vermute das geht einfach nicht... Ich hab auch nach intensiver Suche nichts gefunden

Gruß
Peter

 

[MaxMuster]

Wenn nix anderes hilft (und weil es ja eine Testbox ist ;-)): Ergänze die um eine serielle Schnittstelle. Wenn du dort nach dem Starten "Return" drückst, bleibt die Box im Urlader...

 

[vice_pres]

Das mit der Seriellen Schnittstelle wäre noch ne Möglichkeit, wobei ich da das nächste mal etwas mehr Zeit mitbringen muss wenn ich in der Nähe der Box bin... Wobei ich mich da (mangels Erfahrung an der Fritz) ja Frage ob es reicht dann Enter zu drücken und den Rest vom Recover Tool machen zu lassen oder ob ich das recover dann von Hand machen muss. Hat da jemand Erfahrung?

Auf der anderen Seite ist die 3270v3 dafür wahrscheinlich doch etwas Schade
Dann heissts halt:
A) Nicht zerflashen
B) zusätzliche NIC einbauen die auf LAN 1 der Box geht
C) Serielle Schnittstelle anbringen

Wenn es also keinen Weg gibt werde ich mich aber wahrscheinlich für Variante B entscheiden - vorallem weil ich mir dann keinen ablöten muss

 

[koyaanisqatsi]

Was ist den so lahm bei dir? Die VM?
Ich glaub ich versteh dein Problem nicht so ganz.
Dann versuchs doch über cmd.exe.
Aufjedenfall echte Hardware die weniger Latenz hat.

 

[RalfFriedl]

Gibts eigentlich irgendeine Chance die Zeit in der ADAM2 antwortet zu verlängern?

Die Frage nat natürlich nichts mit Freetz zu tun.

Meine Testbox steht remote an meiner VM

Was genau soll das heißen?
Die Box ist ca. 5 Sekunden im ADAM2 erreichbar, das sollte für jeden Switch reichen, um die Verbindung zu erkennen.

Da die Pakete vom letzten Switch mit VLan versehen werden ist es wahrscheinlich einfach echt zu knapp

Die Pakete sollten gar nicht mit VLAN versehen werden, sonst helfen Dir auch 50 Sekunden nicht weiter.

 

[MaxMuster]

Wenn du damit leben kannst, dass sie für eine bestimmte Dauer nicht "von selbst" startet, kannst du im Bootloader die Variable "autoload" auf "no" setzen.
Dann wartet die Box allerdings "unendlich", bis du es wieder zurück setzt...

In der Shell (Telnet/ssh/RudiShell ...)

echo "autoload no" > /proc/sys/urlader/environment
reboot

Dann was auch immer mit FTP machen, dann (im ftp auf der Box):

ftp> quote SETENV autoload yes
200 SETENV command successful
ftp> quote REBOOT
221 Thank you for using the FTP service on ADAM2
ftp> by
221 Goodbye.

EDIT Vorher sicher gehen, dass die Box auch die richtige IP im FTP hat:

cat  /proc/sys/urlader/environment | grep my_ipaddress

 

[vice_pres]

Ich bekomme in den ~5 Sekunden _keinen einzigen_ Ping auf die 192.168.178.1 hin und ein recover schlägt ebenso fehl.

Grund dürfte das Konstrukt mit aktivem VLAN sein das ich aber definitiv nicht auflösen kann. Da die NIC an der das VLAN hängt dediziert nur für die VMs ist gibt es keine Möglichkeit auf dem Host das Recover durchzuführen. Ich gehe aber auch nicht davon aus, dass es mehr bringt: Die Aushandlung, MAC-Caching und VLAN Tagging dürften auf Switch Ebene dazwischenhauen... Der Link kommt und geht nämlich während der 5 Sekunden mehrfach, ist also nicht eine durchgehend konstante Verbindung. Das Re-/Ent-taggen der Pakete auf Hypervisor Ebene ist zwar sicherlich nicht so super "On Top" - wäre aber auch bei echter Hardware mit VLAN Tagging der Fall da über die eine NIC mehrere VLANs angesprochen werden

Edit:

Die Frage nat natürlich nichts mit Freetz zu tun.

Das ist richtig - da hier aber sicherlich der ein oder andere seine Box schonmal zerflasht hat bin ich davon ausgegangen, dass hier auch passende Antworten kommen.

Die Pakete sollten gar nicht mit VLAN versehen werden, sonst helfen Dir auch 50 Sekunden nicht weiter.

Das ist falsch - denn wenn ich die Pakete nicht Tagge kommen sie am anderen Ende nicht an. Das ist ja der Sinn und Zweck von Vlan und durchaus richtig so. Schließlich komme ich ja auf die Box drauf wenn sie gebootet ist...

 

[vice_pres]

Siehe oben, sorry für den Doppelpost!

 

[MaxMuster]

Die Pakete zur Box müssen von der VM aus vielleicht in einem bestimmten VLAN sein und da ggf. getagged werden.
Das "Beinchen" zur FB muss aber untagged in dem (V)LAN sein, in dem das 192.168.178.0-er Netz ist.

 

[vice_pres]

Also,

Das VLAN ist auf jedenfall richtig wie es ist - denn ich komme ja auf die Box drauf und auf das 2. Vlan das den Gastnetzzugang der "richtigen" Box bereitstellt. Das ist also aussen vor.

Aber davon abgesehen:
Sollte my_ipaddress nicht 192.168.178.1 zurückgeben?

root@fritz:/var/mod/root# cat  /proc/sys/urlader/environment | grep my_ipaddress
my_ipaddress    169.254.143.1

Edit:
Und das wars auch... woher zum Teufel kommt denn diese blöde my_ipaddress? Die Box hat bis heute mittag erst gefühlte 5 Minuten gelaufen (und lag die letzten Monate im Schrank) - recover geht auch durchs vlan durch. Also kann ich jetzt remote Basteln. Und seh wieder aus wie der letzte Depp

 

[MaxMuster]

Das ist die IP unter der die Box im Adam zu erreichen ist (solange das Recover nicht einen neue IP vergeben hat).
Damit wäre es vielleicht klar, warum du 192.168.178.1 nicht erreichst ;-).

Wenn das Recover die Box findet, setzt es die IP auf eine "im eigenen Netz", i.d.R. also auf 192.168.178.1.
Du kannst dort ja mal 192.168.178.1 reinschreiben:

echo "my_ipaddress 192.168.178.1" > /proc/sys/urlader/environment

EDIT

... woher zum Teufel kommt denn diese blöde my_ipaddress?

Wie gesagt, recover setzt die IP auf eine im eigenen Netz. Wenn das also mal lief, wenn der PC zuvor keinen DHCP fand ...

 

[koyaanisqatsi]

Das ist schön, gratulation zum erfolgreichen Fehlergrabbing.

 

[vice_pres]

Ich hatte es ja schon umgesetzt und erfolgreich recovert... Blödes Teil.

Vielen Dank

 

[olistudent]

Sieht mir nach einer IP aus, die Windows vergibt, wenn kein DHCP antwortet. Recover setzt, wie Jörg schon schrieb, die IP der Box dann in das Subnet...

Es gibt übrigens Tools wie tools/recover-eva. Die können eine Box mit einem bestimmten Paket suchen bzw. deren Adresse rausfinden.

Gruß
Oliver