Fritz!Box 7390 feste IP via Telnet

[c0mrade]

Folgendes habe ich vor:

- feste IP vergeben (172.19.14.xxx)
- feste Subnetzmaske vergeben (225.225.225.0)
- DHCP-Server deaktivieren

Das ganze habe ich nun in der ar7.cfg via nvi geändert und anschließend ein reboot durchgeführt:

Folge vorgehen habe ich durchgeführt:

- cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
- nvi /var/tmp/ar7.cfg
-> Via "i" die Edition aktiviert und die Ar7.cfg nach Wünschen geändert
-> Nach änderung via "Esc" "Umschalt" "ZZ" gespeichert (hoffe der Befehl habe ich noch richtig im Kopf)
- cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg
-> Config via "ar7cfgchanged" geladen
- reboot (Ist dieser hier notwendig)

(Woran liegt hier der unterschied zwischen "cat" und "cp"?)

Nach Neustart funktioniert alles nach meinen Vorstellungen...

Nun zu meinem eigentlichen Problem... Ich verstehe noch nicht ganz ob diese Einstellungen Werkseinstellung-Resistenz sind?!
Sollte es so sein, dann habe ich vermutlich einen Fehler in meiner Logik Nach WE sind die Einstellungen verschwunden...

Sollte es so sein das diese Einstellung nach einem WE wieder verschwinden... würde mich interessieren wie ich meinem plan umsetzen könnte.

[doc456]

Hallo und Willkommen im Forum!

(Woran liegt hier der unterschied zwischen "cat" und "cp"?)

bei cp wird oft eine neue Datei erstellt, anstatt den Ursprung zu kopieren und das geht im Flash nicht, da schreibgeschützt. Mit cat können Dateien in andere Dateien kopiert werden, oder auch mehrere Dateien in eine andere.

Ich verstehe noch nicht ganz ob diese Einstellungen Werkseinstellung-Resistenz sind?!

Nein, sind sie nicht!

[c0mrade]

bei cp wird oft eine neue Datei erstellt, anstatt den Ursprung zu kopieren und das geht im Flash nicht, da schreibgeschützt. Mit cat können Dateien in andere Dateien kopiert werden, oder auch mehrere Dateien in eine andere.

Das ist verständlich... soweit habe ich garnicht gedacht! Also das der Flash dahinter steckt!

-> Wie könnte ich es den hinbekommen, dass meine Änderungen auch Werkseinstellung-Resistenz sind?

[doc456]

Entweder du kopierst dir die debug.cfg auf einen USB-Stick und/oder du machst eine Sicherung. Anders is nich...

[RudatNet]

Wäre auch gelegentlich ganz schön dumm, wenn man das Werksreset-Resistent machen würde.
Irgendwann weiß man einfach nicht mehr, welche internen Änderungen man gemacht hat, oder der Bediener/Besitzer ändert sich und kann sich nur noch wundern.

[c0mrade]

Wäre auch gelegentlich ganz schön dumm, wenn man das Werksreset-Resistent machen würde.
Irgendwann weiß man einfach nicht mehr, welche internen Änderungen man gemacht hat, oder der Bediener/Besitzer ändert sich und kann sich nur noch wundern.

-> Ich habe eine Testbox die ich des öfteren auf WE setzen muss... mich nervt es nur, dass ich jedesmal einige Standartdinge meines Netzwerkes ändern muss (Zeitaufwand)

Warum ich auf den Gedanken gestoßen bin,...
Ich habe das was ich vorhabe bereits gesehen! Leider weiß ich nicht wie dies verwirklicht wurde. Also müsste es nach meinem Wissen irgendeine Lösung geben?!

Was meinst du genau mit USB-Stick kopieren?

-> Ich bin gerade wieder auf das Freetz-System gestoßen! leider bin ich nicht mehr so ganz auf dem aktuellen Stand... Existiert das System auch für aktuelle FW der 7390?

[doc456]

Was meinst du genau mit USB-Stick kopieren?

Na so:

cat /var/flash/debug.cfg > /var/tmp/debug.cfg
cp /var/tmp/debug.cfg /var/media/ftp/<deinusbstick>

[c0mrade]

Ok... aber ich verstehe dann noch nicht ganz, was mir das bei einem Reset bringt?
Ich habe anschließend die Debug auf dem Stick, aber was mache ich nach einem Reset?

[doc456]

Na dann wieder vom Stick in den Flash kopieren...

[KunterBunter]

Folgendes habe ich vor:

- feste IP vergeben (172.19.14.xxx)
- feste Subnetzmaske vergeben (225.225.225.0)

Die IP-Adresse ist nur ungewöhnlich, aber die Subnetzmaske ist bestimmt falsch. Wenigstens das erste Oktett sollte 255. sein.

[doc456]

@KunterBunter, vermutlich hektische Tippfehler. Selbst dann ist es kein Klasse B-Netz...

[c0mrade]

Also ich habe jetzt eine Lösung... eigentlich ganz einfahc und genau das was ich möchte:

Meine debug.cfg

cd /var/falsh
nvi debug.cfg

(sleep 30; ifconfig lan:1 172.19.14.153 netmask 255.255.255.0 broadcast 172.19.14.129 up)
echo clear_id 87 > /proc/tffs

Nu Kann ich soviel Werkseinstellungen laden wie ich nur möchte!

Leider habe ich nun ein ganz anderes Problem. Ich würde gerne via Telnet auf die gleiche Art meine IP Routen hinterlegen:

cd /var/falsh
nvi debug.cfg

(sleep 30; ifconfig lan:1 172.19.14.153 netmask 255.255.255.0 broadcast 172.19.14.129 up)
route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.19.14.129  
echo clear_id 87 > /proc/tffs

Leider funktioniert dies Technik nicht ganz -> Er spuckt mir fehler aus, das der Gateway nicht übereinstimmt...
-> Klar, er Prüft diesen ja auch nicht von meiner virtuelle Schnittstelle (lan:1)

Problem: Hat jemand eine Lösung wie ich das beheben kann?

[sf3978]

cd /var/falsh

cd /var/falsh
nvi debug.cfg

(sleep 30; ifconfig lan:1 172.19.14.153 netmask 255.255.255.0 broadcast 172.19.14.129 up)
route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.19.14.129  
echo clear_id 87 > /proc/tffs

Leider funktioniert dies Technik nicht ganz -> Er spuckt mir fehler aus, das der Gateway nicht übereinstimmt...

Ist das Absicht mit Subnet "172.16", als gw die boadcast-Adresse und dann noch aus "172.19"? Das Verzeichnis "falsh" oder "flash", ... ... ? Die netmasks?

[c0mrade]

Ist das Absicht mit Subnet "172.16", als gw die boadcast-Adresse und dann noch aus "172.19"? Das Verzeichnis "falsh" oder "flash", ... ... ? Die netmasks?

- Ja das ist absicht mit "172.19"
- Natürlich /var/flash

Stimmt alles genau so wie es hier steht

[RalfFriedl]

cd /var/falsh
nvi debug.cfg

(sleep 30; ifconfig lan:1 172.19.14.153 netmask 255.255.255.0 broadcast 172.19.14.129 up)
route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.19.14.129  
echo clear_id 87 > /proc/tffs

Leider funktioniert dies Technik nicht ganz -> Er spuckt mir fehler aus, das der Gateway nicht übereinstimmt...
-> Klar, er Prüft diesen ja auch nicht von meiner virtuelle Schnittstelle (lan:1)

Es wäre nett, wenn Du die Fehlermeldungen im Wortlaut wiedergeben würdest und nicht mit dem, was Du für sinngemäß hältst. Es erleichtert es den anderen, Dir zu helfen, und letztlich willst Du Hilfe.

Die .129 als Broadcast ist durchaus ungewöhnlich. Bist Du sicher, dass das stimmt?
Ansonsten hat der Fehler nichts mit lan:1 zu tun, sondern damit, dass Du als Gateway die Broadcast-Adresse angegeben hast. Was soll das Deiner Meinung nach bezwecken?

[c0mrade]

Ich muss mich verbessern...

Folgendes meine ich bzw. steht in der debug:

(sleep 30; ifconfig lan:1 172.19.14.153 netmask 255.255.255.0 broadcast 172.19.14.255 up)
echo clear_id 87 > /proc/tffs

-> Wenn ich nun keine Schreibfehler mehr habe soll folgendes passieren bzw. passiert auch...

- FB Startet und wartet 30 sec

- Legt anschließend eine virtuelle Schnittstelle (lan:1) an

- enfernt die Modding-Warnung

Nun möchte ich eigentlich nichts anderes als eine Statische IPv4-Routing hinterlegen:

Die wie Folgt aussehen soll:
Netwerk: 172.19.14.128
Subnetzmaske: 255.255.255.0
Gateway: 172.19.14.129

-> Leider bekomme ich immer die Meldung: route: SIOCADDRT: Network is unreachable

[RalfFriedl]

Die 30 Sekunden zu warten ist vermutlich unnötig, beim Ausführen von debug.cfg sollte das Netzwerk bereits konfiguriert sein. Die Klammern um die Zeile mit sleep sind auch unnötig.

Zu Deiner Konfiguration:
Eigene IP: 172.19.14.153/24 mit Broadcast 172.19.14.255. Die Broadcast Adresse ist der Default und braucht nicht angegeben zu werden.
Die gewünscht Route ist jetzt nicht mehr 172.16.0.0/12 gw 172.19.14.129, was nach der Änderung der Broadcast Adresse funktionieren würde, sondern 172.19.14.128/24 gw 172.19.14.129. Da ist das Problem vermutlich, dass die .128 nicht zur Netzwerk-Maske passt.

Entweder bekommst Du selbst heraus, was für eine Konstellation Du da hast und warum die ganzen seltsamen Adressen, oder Du lieferst mehr Informationen.

[c0mrade]

Ok...

ich habe nun folgenden geändert:

sleep 30; ifconfig lan:1 172.19.14.153 netmask 255.255.255.0 broadcast 172.19.14.255 up
echo clear_id 87 > /proc/tffs

wenn ich nun folgendenden Befehle ausführe (und ich dich richtig verstanden habe) um eine Statische IPv4-Routing zu hinterlegen bekomme ich fehlermeldungen:

route add 172.19.14.128 netmask 255.255.255.0 gw 172.19.14.129
Fehler: route: netmask 000000ff and host route conflict

oder bei

route add 172.16.0.0 netmask 255.254.0.0 gw 172.19.14.129
Fehler: route: netmask 0001ffff and host route conflict

oder bei

route add 172.16.0.0 netmask 255.240.0.0 gw 172.19.14.129
Fehler: route: netmask 000fffff and host route conflict

Nur verstehe ich nicht ganz warum der Fehler kommt!

-> Hintergrund: Keine Ahnung ich habe nur diese 3 möglichkeiten von unserer IT genannt bekommen! Laut aussage sollte eigentlich nur eine hinterlegt werden und das ist : route add 172.16.0.0 netmask 255.240.0.0 gw 172.19.14.129

Das mit dem Broadcast... naja keine ahnung! vermutlich leichtsins fehler... wenn man nachdenkt ist es ja logisch und sau peinlich


Der befehl: route add 172.16.0.0 gw 172.19.14.129 funktioniert
Allerdings legt er folgendes an:

Destination: 172.16.0.0
Gateway: 172.19.14.129
Genmask: 255.255.255.255
Flags: UGH
Metric: 0
Ref: 0
Use: 0
Iface: lan

[c0mrade]

Nun habe ich die Lösung gefunden:

sleep 30; ifconfig lan:1 172.19.14.153 netmask 255.255.255.0 broadcast 172.19.14.255 up
route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.19.14.129
echo clear_id 87 > /proc/tffs

[RalfFriedl]

route add 172.16.0.0 netmask 255.240.0.0 gw 172.19.14.129
Fehler: route: netmask 000fffff and host route conflict

Es muss heißen

route add -net 172.16.0.0 netmask 255.240.0.0 gw 172.19.14.129

Es kann sein, dass andere route-Programme so schlau sind und das -net selbst einsetzen, wenn man netmask angibt.