Anleitung: SSH (Dropbear) und Etherwake auf der FRITZ!Box

[chapolote]

Wow, schnelle Antwort

Hab die Reihenfolge vertauscht, hab's eigentlich genau so gemacht, wie Du's beschrieben hast: Cursor an die richtige Stelle gesetzt und dann i gedrückt.
Warum das trotzdem nicht funktioniert, ist mir trotzdem noch ein Rätsel....

Vielleicht hat noch jmd eine andere Idee, auch wenn wohl der Weg über eine virtuelle Netzwerkarte eleganter ist. (man lernt ja nur, wenn man auch weiß, was man falsch gemacht hat )

Was ich auch nicht verstehe: warum ist über den telnet-Befehl:
cd /var/flash
vi ar7.cfg
die ar7.cfg offensichtlich leer, wenn ich aber die Konfiguration in den FBEditor lese hat der ar7.cfg Abschnitt sehr wohl Inhalt, auch wenn der komplette forwarding-Bereich unauffindbar bleibt???

O.K., werd jetzt erst mal ein Recover der 7170 starten, alles wieder anlegen , dann mit der virtuellen Netzwerkkarte.
Als Weiterleitung müßte ja dann reichen: TCP Port 22 auf Port 22 von 192.168.178.253, ist das richtig so?

Danke und Gruß,
Joe

 

[jojo-schmitz]

Weil ar7.cfg (wie auch aller anderen Datien in /var/flash) nicht wirklich Dateien sind, sondern Devices. 'nvi' trägt dem Rechnung, indem es diese in eine temporäre Datei ausliest, diese verändert und dann deren Inhalt wieder in das Device schreibt.

Ja genau, mit der Weiterleitung solle es gehen. Dieser Trick ist nötig, da dass Web Interface eine Weiterleitung auf interne Adressen verhindert.

Tschö, Jojo

 

[chapolote]

Mist aber auch, ich weiß das doch eigentlich... wie konnt ich das nur vergessen.
D.h. ich kann mir das Recover-Prozedere ja sparen....
Vielen Dank nochmal

 

[chapolote]

Sorry, wollt trotzdem nochmal kurz nachhaken:
Ist das jetzt normal, daß nach einer Änderung der ar7.cfg Konfigurationseinstellungen verloren gehen, oder ist das nur bei mir so?

 

[jojo-schmitz]

Reset auf Werkseinstellung und/oder Einspielen der zuvor gesicherten Einstellungen sollte ausreichen.

Nein, normal ist das mit den verlorengegangenen Einstellungen nicht.

 

[chapolote]

So, nach einigen Anlaufschwierigkeiten scheint jetzt alles zu funktionieren, vielen Dank an alle guten Geister hier!!!!!!!!!!!!!!!!!

Ich würde mich jetzt gerne für die Hilfe hier revanchieren und mal ein upgedates HowTo in einem neuen Thread verfassen.

Dazu bräuchte ich aber noch Hilfe in 2 Punkten:

1. es kann ja vorkommen, daß die debug.cfg in /var/flash noch nicht existiert. Das Erstellen mittels echo > /var/flash/debug.cfg stellt ja ansich kein Problem dar, deshalb könnte man das ja auch in die install.sh mit aufnehmen. Der Code müßte meiner Ansicht nach so heißen:

echo -n -e "\Erstelle debug.cfg ...\t\t\t\t\t\t\t" && echo > /var/flash/debug.cfg && echo "[DONE]" || exit

Ist das erstens richtig so und zweitens: was passiert bei diesem Befehl, falls doch schon eine debug.cfg existiert? Weiter gedacht: sollte es bei einer schon existierenden debug.cfg zu Konflikten oder einem Abbruch kommen, wie könnte dann eine if-Abfrage aussehen?

2. zumindest bei der 7170 mit FW ...49 bzw LaborFW ...99 funktioniert der Aufruf von ./startpc so nicht mehr. D.h. ich mußte in der input.cfg das Erzeugen der startpc folgendermaßen ändern:

echo "ether-wake -i $wolinterface $wolmac" > ./startpc

Ist dies 7170-spezifisch oder gilt diese neue Syntax für alle Boxen mit aktueller Firmware?

Wäre für Antworten dankbar und würd mich dann daran machen, ein aktuelles HowTo mit modifizierten Files zu erstellen.

Danke und Gruß,
Joe

 

[jojo-schmitz]

Ist das erstens richtig so

Ich glaube schon, möchte es aber aus nachvollziebaren Gründen (s.u.) nicht ausprobieren. Das 'echo' kannst Du weglassen. Sicherer wäre

mknode /var/flash/debug.cfg c 240 98

das würde eine existierended debug.cfg nicht überschreiben

zweitens: was passiert bei diesem Befehl, falls doch schon eine debug.cfg existiert?

Sie wird überschrieben, geleert, als leere 'Datei' neu angelegt.

Weiter gedacht: sollte es bei einer schon existierenden debug.cfg zu Konflikten oder einem Abbruch kommen, wie könnte dann eine if-Abfrage aussehen?

echo -n -e "\Erstelle debug.cfg ...\t\t\t\t\t\t\t" &&
  [ -c /var/flash/debug.cfg ] &&
  > /var/flash/debug.cfg
  && echo "[DONE]"
  || exit

oder eben

echo -n -e "\Erstelle debug.cfg ...\t\t\t\t\t\t\t" &&
  mknode /var/flash/debug.cfg c 240 98
  && echo "[DONE]"
  || exit

Ist dies 7170-spezifisch oder gilt diese neue Syntax für alle Boxen mit aktueller Firmware?

(etherwake vs. ether-wake)
Ist für alle neueren FWs so.

Tschö, Jojo

 

[chapolote]

Ok, wenn ich das also richtig verstanden habe, beläßt der Befehl mknode alles beim alten, wenn schon die debug.cfg existiert und macht kommentarlos im Installationsscript weiter. Somit bliebe also alles, was in der debug.cfg steht erhalten.
Später im Script heißt es aber:

cat $output > $debug

D.h. doch, daß die debug.cfg dadurch sowieso frisch geschrieben wird, zumindest hab ich als Linux-Greenhorn die Kommandozeilenreferenz so verstanden. D.h. die User sollten so oder so darauf hingewiesen werden, daß alle vorher gemachten Mods verloren gehen.

Nochmals zu ether-wake vs etherwake:

Kann man davon ausgehen, daß alle Boxen mit Kernel 2.6 nur noch auf ether-wake ansprechen und alle älteren auf etherwake? Man könnte dann natürlich eine schöne Abfrage einbauen.
Leider hab ich zwar rausgefunden, daß man über uname -r die Kernelversion auslesen kann, aber ich komm nicht dahinter, wie dann so eine Abfrage aussehen müßte...
Naja, dann könnt ich ja alternativ immer noch zwei verschiedene Installations-Pakete anbieten.

Gruß, Joe

 

[jojo-schmitz]

Spare Dir die Arbeit, The-Construct erledigt das alles (und noch mehr)

Das Scipt hier rettet den alten Inhalt der debug.cfg, bevor es eine Neue schreibt. (das kann The-Construct übrigens auch)

 

[RalfFriedl]

Leider hab ich zwar rausgefunden, daß man über uname -r die Kernelversion auslesen kann, aber ich komm nicht dahinter, wie dann so eine Abfrage aussehen müßte...

if [ "$(uname -r)" = "2.6.XX" ]; then
   XX
else
   XX
if

Für XX noch das passende einsetzen.

 

[chapolote]

Spare Dir die Arbeit, The-Construct erledigt das alles (und noch mehr)

Das Scipt hier rettet den alten Inhalt der debug.cfg, bevor es eine Neue schreibt. (das kann The-Construct übrigens auch)

Wie meinst Du das....
Die ganze Arbeit des HowTo's oder nur, daß ich's jetzt perfekt machen wollte?

Prinzipiell hast Du ja recht, The-Construct ist ne tolle Sache, nur nicht eben für Leute, die auch gerne ein wenig davon verstehen wollen, was da passiert...

 

[jojo-schmitz]

Na die Arbeit ein Das Script zu verbessern.

The Consruct verwendet übrigens:

KERNEL_VERSION=`uname -r | grep 2.6`
if [ -z "${KERNEL_VERSION} ]
then
  KERNEL_VERSION=linux24
  ETHERWAKE=etherwake
else
  KERNEL_VERSION=linux26
  ETHERWAKE=ether-wake
fi

Die Unterscheidung ist auch wichtig um die richtigen Binaries für busybox und dropbear zu laden.

 

[chapolote]

Ha, jetzt macht's ja langsam richtig Spaß....

Auf die Idee, in den Code von The-Construct reinzugucken hätt ich eigentlich auch selber kommen können

Dann versuch ich mal einen modifizierten Code zu erstellen und post ihn dann hier.
Vielleicht würdet ihr dann mal drüberschauen, weil testen kann ich's ja eigentlich nicht wirklich, da ich keine Box mit altem Kernel hab...

Bis später dann...

 

[chapolote]

So, Jojo hat doch recht gehabt...

Hab mich auf's wesentliche konzentriert und - hoffentlich - ein anständiges Tutorial verfasst. Die oben diskutierten Ideen stehen nicht in den Dateien, sondern sind erklärt.

Ich hoffe das hilft so manchem Newbie auf die Sprünge (so wie mir eben auch)... :spocht:

Hier sind meine Ergüsse zu finden

Gruß,
Joe

 

[JojoS]

da die neue Laborfirmware ja jetzt einen Zugang per https eingebaut hat wäre ein WOL über eine Seite in der FB eine schöne Sache. Lässt sich das Web Interface mit den cgi Scripts 'einfach' erweitern?

 

[fred.labosch]

Leider wird mir mit ps kein dropbear angezeigt. Manuell kann ich mit './' starten. Dann wird es auch unter den Prozessen gelistet.

kann mir bitte jemand sagen warum dropbear nicht ausgeführt wird?
manuell gehts ja auch...*rolleyes*

 

[wichard]

Hast Du schon mal versucht, in der debug.cfg dropbear und Co. ebenfalls mit "./" bzw. mit kompletter Pfadangabe aufzurufen?


Gruß,
Wichard

 

[fred.labosch]

Allerdings. Auch mit "sh".

Alle anderen Schritte bis dahin werden offensichtlich ausgeführt. Jedenfalls liegen die Dateien im /tmp Verzeichnis.

Alle Dateien sind als auführbar markiert. Ausser die debug.cfg. Muss sie aber nicht. Lässt sich trotzdem mit sh ausführen, mit ./ aber nicht (Permission denied).

 

[thiesy]

hallo,
hat schon mal jemand versucht, einen Computer mit etherwake zu wecken, der mit einem Biospasswort geschützt wird?
Der Computer startet bis zur Bioseingabe, und fragt nach currrent Passwort?
Nun hab ich diese option gesehen:
Options:
-b Send wake-up packet to the broadcast address
-i iface Use interface ifname instead of the default "eth0"
-p pass Append the four or six byte password PW to the packet
aber sobald ich diese option mit angebe kommt die Meldung:
# ether-wake: Unable to read the Wake-On-LAN pass
Ich hatte es in die start_pc geschrieben:
ether-wake -i eth0 -p dudu 01:0F:5C:A9:0A:6D
falls jemand einen Vorschlag hat, wie es junktionieren könnte, immer her damit.
MfG thiesy

 

[wichard]

Das Etherwake-Password und das BIOS-Password haben meines Wissens nichts miteinander zu tun. Da hilft es wohl nur, das BIOS-Passwort auszuschalten.


Gruß,
Wichard