Virtuelle Netzwerkkarte von the-construct.com funktioniert nicht richtig !?!?

  • Unsere Website ist morgen von 07:00 bis 12:00 UTC aufgrund von Wartungsarbeiten nicht verfügbar. Wir entschuldigen uns für etwaige Unannehmlichkeiten.
kawamoto schrieb:
Geht das auch mit dem FBEditor ??? Damit kann ich umgehen. ( hehehehehe)

Leider nicht.

kawamoto schrieb:
Oder wenn ich die debug.cfg komplett leer mache , und dann das hier mache...
http://www.ip-phone-forum.de/showpost.php?p=605290&postcount=10
könnte das gehen ?

Wenn du das mit dem FBEditor hinbekommst würde es klappen. Wäre die beste Lösung.
Dann könntest du neben OpenVPN auch den ifconfig Teil aus der debug.cfg entfernen. Wie das geht hab ich oben ja schon beschrieben.
 
Boahhhhh....

Erst mal vielen Dank für die Anleitung.
Aber ob ich mich da rantraue , weiß ich noch nicht.
Wenn ich aber das pseudo imgae von the-construct.com zum leeren der
debug.cfg ausführe, dann ist die doch ratzekahl leer , oder.... !?

Danach dann mit dem FBEditor an die ar7.cfg ran , und die änderung rein.
Dann hätte ich doch auch alles !?

Und wenn ich dann doch OpenVPN haben will , einfach wieder ein pseudo image
von the-construct.com das alles in der debug.cfg beibehält , und nur OpenVPN
mit draufsetzt. Sollte doch funktionieren. Und hat den positiven Nebeneffekt, dass
ich dann endlich meine Box nochmal komplett hochziehen kann.

Was meinst Du ???

EDIT:
=====

Wenn ich das clear_debug.image ausführe , wird doch alles in der debug.cfg gelöscht?
Dann muß ich doch nur
1. Den LCR wieder aufspielen
2. Ein Pseudo Image mit virt. Netzwerkkarte und OpenVPN und AVM international wieder drauf.

Dann sollte ich doch alles haben, oder....?
Wie Du oben geschrieben hast , sollte das image jetzt nach der Webseiten änderung das richtige sein.
" Wenn ich das alles richtig verstanden habe " !?

Gruß
Andreas
 
Zuletzt bearbeitet:
So , kurzer Bericht was ich alles gemacht habe.

1. Das File clear_debug.image ausgeführt. Dann war die debug.cfg LEER
2. Den LCR neu aufgesetzt
3. Neue pseudo files auf www.the-construct.com erstellt. Diese waren
- AVM international ( da noch fw 14.04.01)
- virtuelle Netzwerkkarte
- OpenVPN Server
4. Alles nochmals mit telnet more /var/flash/debug.cfg kontrolliert ;-)

Dann stand da:

Code:
# more /var/flash/debug.cfg


# enable international settings
sed "s/LKZ 0/LKZ 1/g" /usr/www/all/html/de/fon/sip1.js > /var/tmp/sip1.js
chmod 444 /var/tmp/sip1.js
mount -o bind /var/tmp/sip1.js /usr/www/all/html/de/fon/sip1.js

# set hostname to fritz.box
hostname fritz.box


# set hostname to fritz.box
hostname fritz.box

# make FBF accessable from the internet (192.168.178.253)
sleep 10
ifconfig eth0:1 192.168.178.253 netmask 255.255.255.0 broadcast 192.168.178.255
up

#>>TSB: LCR Updater Installer
cat > /var/tmp/tsbinstaller << 'EOF_TSBINSTALLER'
#!/bin/sh
# LCR Updater - Voll automatisches Least Cost Routing f³r die AVM Fritzbox
# Copyright 2006 Harald Becker - www.Telefonsparbuch.de / Alle Rechte vorbehalte
n
TSBfileLogMsg=/var/tmp/tsbinstall.log
--More--


Man beachte:
-------------
ifconfig eth0:1 192.168.178.253 netmask 255.255.255.0 broadcast 192.168.178.255
up

Bis jetzt geht alles , incl. OpenVPN...... Und das ging noch nie so richtig.
Ich werde in den nächsten Tagen mal berichten , ob das alles geholfen hat.
Zumindest kenne ich jetzt 1-2 telnet Befehle !!!

Danke an alle , un gute Nacht ( gähnn......)
 
olistudent schrieb:
...
Gehen eigentlich bei einem reconnect alle virtuellen Interfaces verloren die nich in der ar7.cfg stehen? Ich denke nicht, oder?
Nein, zumindest die von OpenVPN angelegten tun Interfaces gehen nicht verloren. Bei einem reconnect wird auch die Routingtabelle nicht geändert.
Dies passiert nach meiner Beobachtung lediglich beim Einschalten von WLAN (nicht beim Ausschalten).

Durch ein "killall -HUP openvpn2" werden die Routen zwar neu erstellt. Dannach muss man aber noch einmal den ping timeout abwarten, bis sich die Clients neu connecten.
 
Wieder Fehler im Script?

shadow000 schrieb:
Das Script hatte vor ein paar Wochen einen kleinen Fehler, eigentlich sollte es jetzt aber gehen?!
Du könntest versuchen, dir das Interface manuell in die ar7.cfg einzutragen.
Daszu einfach unter lan:0 noch ein lan:1 anlegen

Wenn ich mir aktuell ein Pseudo-Image erstellen lasse, enthält dies wieder die eth0:1 Einstellung:


Code:
...
# make FBF accessable from the internet (192.168.178.253)
sleep 10
ifconfig eth0:1 192.168.178.253 netmask 255.255.255.0 broadcast 192.168.178.255 up
...

Sollte das Script auf lan:1 geändert werden?

Grüße,
Jürgen
 
jaja schrieb:
Sollte das Script auf lan:1 geändert werden?
Laut Informationen, die ich hier im Forum bekommen habe (die, da alles so funktioniert wie ich mir das vorstelle, anscheinend korrekt ist):

Entweder lan:1 in ar7.cfg oder eth0:1 in debug.cfg.

Tschö, Jojo
 
Zuletzt bearbeitet:
Schade, denn ich habe immer noch ein ähnliches Problem, wie von kawamoto beschrieben: Nach einem Tag ist der Zugriff von außen weg, vermutlich weil (wie maceis sagt) nach dem täglichen Einschalten von WLAN die Routingtabellen neu erstellt werden.

Grüße,
Jürgen
 
jaja schrieb:
Schade, denn ich habe immer noch ein ähnliches Problem, wie von kawamoto beschrieben: Nach einem Tag ist der Zugriff von außen weg, vermutlich weil (wie maceis sagt) nach dem täglichen Einschalten von WLAN die Routingtabellen neu erstellt werden.
Kann ich so nicht bestätigen, ich lasse WLAN per Nachtabschaltung Nachts de- und Morgens reaktivieren (und komme zwischendurch der Zwangstrennung zuvor) und habe bisher keine Schwierigkeiten mit Zugriff von aussen.

Tschö, Jojo
 
jaja schrieb:
Schade, denn ich habe immer noch ein ähnliches Problem, wie von kawamoto beschrieben: Nach einem Tag ist der Zugriff von außen weg, vermutlich weil (wie maceis sagt) nach dem täglichen Einschalten von WLAN die Routingtabellen neu erstellt werden.

Grüße,
Jürgen
Dann versuch doch mal mit dem FBEditor folgenden Abschnitt in die ar7.cfg einzufügen:
Code:
...
        } {
                name = "lan:1";
                dhcp = no;
                ipaddr = 192.168.178.253;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
        }
Und zwar nach dem Abschnitt mit lan:0.

MfG Oliver
 
jojo-schmitz schrieb:
Kann ich so nicht bestätigen, ich lasse WLAN per Nachtabschaltung Nachts de- und Morgens reaktivieren (und komme zwischendurch der Zwangstrennung zuvor) und habe bisher keine Schwierigkeiten mit Zugriff von aussen.
Die Zwangstrennung (bzw. das Zuvorkommen) habe ich auch und macht bei mir keine Probleme. Die Nachtschaltung habe ich nicht aktiviert und kann daher auch keine Aussage dazu machen. Lediglich wenn ich das WLAN über das Webinterface manuell einschalte sind anschließend die von OpenVPN eingerichteten Routen weg.
Ich habe auch in der ar7.cfg eine Portweiterleitung auf ein lokales Interface der FritzBox eingerichtet (Port 22/tcp für SSH). Damit habe ich keinerlei Probleme (zum Glück, denn sonst wäre es bitter).
 
wenn ihr auf nummer sicher gehen wollt dann bleibt eigentlich nur die lösung mit der ar7.cfg.
das ist allerdings nicht ohne risiko, schon bei tabulatoren statt leerzeichen hängt die box in einer reboot schleife...
ob eth0:1 oder lan:1 ist übrigens völlig egal, hauptsache kein schon von der box benutztes interface.
 
Kleiner Zwischenbericht:
===================

Seit ich die Änderungen wie hier beschrieben durchgeführt habe,

http://www.ip-phone-forum.de/showpost.php?p=605522&postcount=23

scheint mein Problem behoben zu sein :)

Danke an alle , die mir geholfen haben !!!

EDIT:
Läuft seit 2 Tagen stabil. Also war es das fehlerhafte/alte script von the-construct.com!
Is ja auch egal. Fehler gefunden und behoben. Nochmals danke an alle !!! ;-)
 
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.