[Gelöst] ar7.cfg - Bridging Änderungen werden zurückgesetzt?!?

andiling · 10 Aug 2015

Hallo,

ich möchte in der ar7.cfg unter brinterfaces - interfaces noch ein tap device hinzufügen.

Wenn ich das mit nvi /var/flash/ar7.cfg tue und dann ar7cfgchanged aufrufe hält das bis zum nächsten Neustart, wenn ich stattdessen sofort neu starte funktioniert das auch beim nächsten Neustart aber ab dem zweiten Reboot ist der Eintrag wieder weg.

Das tap device wird beim Start per rc.custom Skript angelegt. Kann es sein, dass das System von AVM vorher die ar7.cfg überprüft und vermeintlich obsolete Dinge entfernt? Wenn ja, wie kann ich das verhindern?

Danke für einen Wegweiser...

Gruss,

Andreas

PeterPawn · 10 Aug 2015

Warum fügst Du das tap-Device nicht nach dem Anlegen manuell zur entsprechenden Bridge hinzu?

Es kann zwar sein, daß dann der dsld (der sollte sich mit den diversen Interface-Abschnitten der ar7.cfg befassen) bei einem Neustart seinerseits wieder die vorhergehende Konfiguration verwendet (der baut m.W. die Brigdes neu auf), aber dann trägst Du eben parallel zum Anlegen das auch noch in der ar7.cfg nach (wenn nötig). Allerdings solltest Du derweil den ctlmgr beenden und erst anschließend wieder neu starten.

Also:

- TAP-Device anlegen
- mit brctl einbinden
- ctlmgr stoppen
- ar7.cfg (automatisch) editieren und TAP-Device zu brinterfaces hinzufügen
- ctlmgr starten

müßte eigentlich klappen/ausreichen. Ansonsten kannst Du ja auch "onlinechanged" überwachen (/var/onlinechanged wird aber nicht mehr berücksichtigt, keine Ahnung, seit wann das so ist und im Moment auch keine Lust, rückwärts zu suchen) und dann bei "online" jeweils prüfen, ob das TAP-Device in der Bridge ist (ist ja sicherlich OpenVPN oder SoftEtherVPN

) und da braucht es vermutlich ohnehin die Online-Verbindung, damit das funktioniert. Auch könnte der Neustart des SoftEther-Servers bei "online" vermutlich ohnehin keine so ganz schlechte Idee sein ... wobei das ein wenig davon abhängen wird, welche Protokolle man am Ende benutzen will.

andiling · 10 Aug 2015

Jupp, es geht hier um SoftEther (der Thread hat mich aus Interesse gepackt).

- Das tap device legt der Server beim Start an (dagegen habe zumindest ich keine Einwände bzw wollte dem nicht zuvorkommen)
- Bei brctl bekomme ich die Fehlermeldung "bridge lan: Device or resource busy", klappt aber auch ohne
- Einen Neustart von dsld oder SoftEther überlebt die Einstellungen, d.h. alles funktioniert weiterhin und der tap_vpn ist nach wie vor in der ar7.cfg an gewünschter Stelle.
- Den SoftEther Server muss ich auch nicht neustarten nachdem ar7cfgchanged ausgeführt wurde.

Nur halt der Reboot...!?!?

PeterPawn · 10 Aug 2015

Meines Wissens (alles nur deduktiv und muß keinesfalls stimmen) setzt der ctlmgr anhand des "Betriebsmodus" der Box die Bridges zurück beim Start, die "originale Konfiguration" für diese Szenarien steht irgendwo in den OSS-Quellen in einem Header-File (für den Switch) herum.

Wer da auf diesem Weg an der Umkonfiguration alles beteiligt ist (ob nun dsld oder kdsld oder ctlmgr - mehr dürften es eigentlich, abgesehen von ein paar AVM-Treibern für den ifx_switch-Baustein, nicht sein), weiß ich aber auch nicht mehr ... da ist ständig Bewegung in der Firmware und jede Erkenntnis (die ja auch nur auf der Basis von Indizien entstehen kann) ist eher ein Schnappschuß als dauerhaftes Wissen.

andiling · 10 Aug 2015

Also kurz gesagt was man auch diesbezüglich in der ar7.cfg ändert, es hat sowieso keinen Bestand und wird wann auch immer wieder in den Ursprungszustand versetzt...

PeterPawn · 10 Aug 2015

Ich würde sagen, ja ... wobei ich auch schon (allerdings früher) eine zusätzliche Brigde konfiguriert hatte (nur WLAN, separiert vom LAN), die durchaus persistent war. Ich finde gerade die Header-Datei nicht (eigentlich habe ich keine Lust zu suchen, es ist eindeutig zu warm

) und mir ist so, als ob es "nur" die Standard-Bridge "lan" betreffen würde. Da die m.W. auch "abgeräumt" und neu eingerichtet wird unter bestimmten Umständen (was wohl kein Member "überlebt"), braucht es schon das nachträgliche Aufnehmen eines Interfaces ... egal wer es am Ende veranlaßt.

Mein Vorschlag wäre der Blick in die Quellen (ich kann auch meilenweit daneben liegen, wenn die Bridge-Konfiguration unabhängig von der Switch-Konfiguration erfolgen sollte, das ist ja auch bei verschiedenen Modellen unterschiedlich gelöst) und/oder der Test, wann denn die Änderungen an der ar7.cfg rückgängig gemacht werden, wenn Du nach den Änderungen durch Dich ein Reboot auslöst.

Wenn dann beim nächsten Mal noch die geänderte Konfiguration aktiv ist, während in der ar7.cfg schon wieder die "originale" steht, passiert es wohl irgendwann nach dem Start des dsld ... ist eben alles nur Deduktion. Meiner Ansicht nach schreibt die Firmware da eben die "bekannten" Bridges (lan, notfall-ip, guest) neu und läßt aber unbekannte Bridges unangetastet - so meine Interpretation.

Aber auch da ist eben "panta rhei" das Motto ... die noch vor einiger Zeit in der Firmware zu findenden umfangreichen Kollektionen an "dsldmode"-Einstellungen (so jedenfalls meine Erinnerung) sind inzwischen wieder auf fünf mögliche Werte zurückgestutzt worden.

andiling · 10 Aug 2015

Ob und was im laufenden Betrieb evtl. das Bridging zu nichte macht wird sich herausstellen.

Im Moment bekomme ich das nach #2 so in der rc.custom hin, dass es nach dem Start funktioniert.

Code:

#!/bin/sh
mount -o bind /dev /var/media/ftp/FRITZ/rootfs/dev
chroot /var/media/ftp/FRITZ/rootfs /usr/sbin/vpnserver start
ctlmgr -s
cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
sed -i 's/interfaces = "eth0"/interfaces = "tap_vpn", "eth0"/' /var/tmp/ar7.cfg
cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg
ctlmgr

DANKE!

ChAoS · 12 Aug 2015

nur "mal so kurz dazwischengefunkt"

Also ich habe sicher eine etwas andere Konfiguration als ihr, aber bin auch auf den Punkt des automatischen "neuaufbaus" gestoßen.

Erst habe ich den SoftEther hub mit der Box internen Brücke lan gebrückt. Soweit lief auch alles super nur VPN User konnten zwar alles im Netz erreichen aber die Box selber nicht. Da ich das für VOIP aber interessant finde

muss das auch gelöst werden!

Laut SoftEther liegt das an einer Beschränkung im Linux.

Also wollte ich Softether auf einen dedizierten Port der 7490 legen.

Dazu habe ich in der ar7.cfg eine neue Bridge angelegt und eth3 da mit rein genommen. Aus der bridge "lan" habe ich dafür eth3 rausgenommen.

Problem 1 war: die neue Bridge bekommt die selbe Mac wie die bridge lan. Das ließ sich per skript mit ifconfig neuebridge down - ifconfig neuebridge hw ether=00:00..., ifconfig neuebridge up vor dem Start von SoftEther lösen.

Problem 2 war: die WLAN clients hatten Probleme VPN Clients zu erreichen - also komplett umgedacht und alle eth s außer eth 0 der neuen Bridge hinzugefügt.

Seitdem läuft alles BIS AUF:

nach einem Neustart:

die neuebridge bleibt tatsächlich so erhalten und es funktioniert alles
die bridge "lan" wird mit eth0, eth1, eth2 und eth3 neu gebunden

komischerweise gibts aber keinen loop und alles funktioniert

Also funktioniert der Zugriff von außen auf die Box jetzt so:

Externer PC---->VPN zu SoftEther----->VirtualHub von SoftEther---->Bridge von SoftEther------>neuebridge in der box---->Phys. eth3----->externer switch---->Phys. eth0---->box's interne bridge "lan" mit der richtigen IP

LG

PeterPawn · 12 Aug 2015

Bei aller Mühe verstehe ich nur Bahnhof ... ein Config-File und ein Console-Log sagt mehr als tausend Worte. Schon die Frage, wo am Ende die Interfaces eth0-3 versammelt sind (in der "lan"-Bridge oder in der eigens dafür angelegten), geht für mich aus dem Text nicht mehr klar hervor, da hilft ein "brctl show" wahnsinnig.

ChAoS · 12 Aug 2015

da hilft ein "brctl show"

ergebnis:

Code:

root@fritz:/var/mod/root# brctl show
brctl: invalid argument 'show' to 'brctl'
root@fritz:/var/mod/root#

ar7.cfg:

Code:

.......
        brinterfaces {
                name = "lan";
                dhcp = no;
                ipaddr = 192.168.123.123;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth0"[COLOR=#ff0000], "eth1", "eth2", "eth3"[/COLOR];
                dhcpenabled = no;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                no_dnsd_static = no;
                is_guest = no;
                is_hotspot = no;
        } {
                name = "lan:0";
                dhcp = no;
                ipaddr = 169.254.1.1;
                netmask = 255.255.0.0;
                dstipaddr = 0.0.0.0;
                dhcpenabled = yes;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                no_dnsd_static = no;
                is_guest = no;
                is_hotspot = no;
        } [COLOR=#0000ff]{
                name = "softetherlan";
                dhcp = no;
                ipaddr = 10.0.123.123;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth3", "eth1", "eth2", "wlan", "plc";
                dhcpenabled = no;
                dhcpstart = 0.0.0.0;
                dhcpend = 0.0.0.0;
                no_dnsd_static = no;
                is_guest = no;
                is_hotspot = no;
        } [/COLOR]{
                name = "guest";
....................

das in rot wird automatisch hinzugefügt nach einem Neustart.
Das in blau habe ich manuell eingetragen. Das blaue wird auch genau so ausgeführt

startsoftether.sh

Code:

#!/bin/sh
sleep 60
ifconfig softetherlan down
sleep 1
ifconfig softetherlan hw ether 00:12:34:56:78:ff
sleep 1
ifconfig softetherlan up
sleep 2
chroot /var/media/ftp/SoftEtherRoot/ /usr/sbin/vpnserver start

Die sleeps habe ich zur Sicherheit eingebaut. der erste (60 Sekunden) war erforderlich, da das Skript durch die debug.cfg wohl zu früh gestartet wurde - mit dem Sleep funktionierte es dann zuverlässig...

ifconfig:

Code:

 ifconfig
adsl      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:2000  Metric:1
          RX packets:303005 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2400144 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:149938272 (142.9 MiB)  TX bytes:1969057187 (1.8 GiB)

ath0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

ath1      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

dsl       Link encap:Point-to-Point Protocol
          inet addr:192.168.xxx.xxx  P-t-P:192.168.xxx.xxx  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:294088 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2375505 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:139880939 (133.4 MiB)  TX bytes:1874834573 (1.7 GiB)

softetherlan   Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:10.xxx.xxx.xxx  Bcast:10.xxx.xxx.xxx  Mask:255.255.255.0
          inet6 addr: XXXXXXXXXXXXXXXX/64 Scope:Link
          UP BROADCAST RUNNING PROMISC ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:1953387 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2037660 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1541259433 (1.4 GiB)  TX bytes:1658171048 (1.5 GiB)

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:124899 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31657 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:30419961 (29.0 MiB)  TX bytes:15817179 (15.0 MiB)

eth1      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:5209 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1957587 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:241897 (236.2 KiB)  TX bytes:1568554214 (1.4 GiB)

eth2      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth3      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:1918953 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2044195 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1538183338 (1.4 GiB)  TX bytes:1632900096 (1.5 GiB)

guest     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:172.31.xxx.xxx  Bcast:172.31.xxx.xxx  Mask:255.255.255.0
          inet6 addr: xxxxxxxxxxxxxxxx/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:368 (368.0 B)

guest4    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

guest5    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lan       Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:192.168.xxx.xxx  Bcast:192.168.xxx.xxx  Mask:255.255.255.0
          inet6 addr: xxxxxxxxxxxxxxx/64 Scope:Link
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:99675 errors:0 dropped:0 overruns:0 frame:0
          TX packets:31653 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:10475959 (9.9 MiB)  TX bytes:15752857 (15.0 MiB)

lan:0     Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          inet addr:169.254.1.1  Bcast:169.254.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:63970 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63970 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4786386 (4.5 MiB)  TX bytes:4786386 (4.5 MiB)

wasp      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:94750 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1995351 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:10746262 (10.2 MiB)  TX bytes:1611905699 (1.5 GiB)

wlan      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:37158 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1956909 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5172087 (4.9 MiB)  TX bytes:1602826653 (1.4 GiB)

wlan_guest Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
          UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

da hilft ein "brctl show" wahnsinnig.

wahnsinnig??? Nein, eher krank

Ich teste halt gerade mal die Möglichkeiten aus

die teilweise verrückten IPs stammen natürlich jetzt aus dem "Zensurpool"

andiling · 12 Aug 2015

Warum machst Du es denn so kompliziert bzw. abweichend von dem sicherlich gängigeren Verfahren wie ich es hier angewendet habe?

ChAoS · 12 Aug 2015

gute Frage,

ich habe leider weder über google oder sonst wie auf die Schnelle herausfinden können, wie man ein tap interface auf der box erstellt... dann hätte ich sicherlich das auch so versucht. (das war nämlich meine erste Idee - nach dem Tipp von kh_tsang im Softether Forum).

Wie gesagt, ich hatte zuerst softether mit der Brücke lan gebrückt und testweise auch mal mit eth0 - soweit funktionierte es wie erwartet, nur ließ sich die IP der Fritz Box nicht von den VPN clients erreichen.

Da ich dann nicht herausgefunden habe, wie ich ein TAP if manuell einrichte (das Adminpanel von SoftEther stößt dabei auf einen Fehler) fand ich schneller heraus, wie ich eine weitere Bridge einrichte und den Verkehr über den externen Switch leitete.

Dass meine "Methode" kompliziert und wahrscheinlich auch sehr sehr ungewöhnlich ist stelle ich keineswegs in Frage. Nur fiel mir gestern Abend nichts anderes ein....

Gerne lasse ich mich belehren, wie es einfacher geht

PeterPawn · 12 Aug 2015

Das "show"-Kommando von "brctl" ist optional bei der Busybox ... man braucht also ein passendes Binary - das hat mal als ernsthafter "FRITZ!Box-Modder" aber ohnehin bei der Hand bzw. im NAND-Flash abgelegt.

Die Frage bleibt ja trotzdem, welche Interfaces denn da nun wie gebridged sind ... denn daß ein Interface nicht Member in zwei verschiedenen Bridges sein kann, postuliere ich einfach mal; müßte das allerdings tatsächlich erst einmal testen -> da ist die Anzeige mit einem funktionierenden Applet dann sicherlich einfacher.

andiling · 12 Aug 2015

Du legst das tap device in Softether an und der Fehler verschwindet von alleine sobald es unter brinterfaces eingebunden ist, PeterPawn hat das ja in #2 beschrieben. Das Ganze funktioniert natürlich nur wenn Du dev in das rootfs bringst.

ChAoS · 12 Aug 2015

@peter
ich hatte mich vor vielen vielen jahren mal etwas gelegentlich mit modding der allerersten fbfwlan befasst. Also daraus schließe ich, dass das, was wirklich gerade greift mit brctl show ausgelesen werden sollte und man sich gar keineswegs darauf beruhen sollte, was in der ar7.cfg steht?!?
also steht für mich an die quellen von brctl zu laden und für die box zu kompilieren? das wird bei mir wieder ein paar Tage Projekt

@andiling
also nen symlink von /var/media/ftp/SoftEtherRoot/dev nach /dev machen? (bzw anders herum, je nachdem wie man es liest)...
hast du denn bereits getestet ob deine VPN clients von außen direkt z.B. auf das Webinterface deiner Box kommen??? Weil das war ja im Endeffekt der Anstoß meines exorbitant komplizierten Denkens....

danke und LG

andiling · 12 Aug 2015

Ja, getestet und läuft... ;-)

PeterPawn · 12 Aug 2015

@Chaos:
Eine Busybox mit der Freetz-Toolchain zu bauen braucht nur zwei Dinge (der alte Spruch aus der Werbung waren drei): einen schnellen Rechner und/oder etwas Geduld.

Ansonsten ist das in 5 Minuten angeworfen und wird dann irgendwann fertig ... je nachdem, ob man die Download-Toolchain verwendet oder selbst eine baut, braucht es mehr oder weniger Zeit.

ChAoS · 12 Aug 2015

@andiling wenn das so funktioniert favorisiere ich natürlich dann deine Lösung, da ich mir ein 2tes LAN Kabel von der FBF zum Switch spare
ich weiß ich nerve, aber wie hast du jetzt genau das tap angelegt und was muss ich tun damit es persistant bleibt? Du schriebst zuerst in der rc.custom (die es bei mir nicht gibt) und dann meintest du hingegen wieder mit dem SoftEther Tool.

@Peter habs geschafft (und bin stolz drauf)

Code:

root@fritz:/usr/sbin# ./brctl show
bridge name     bridge id               STP enabled     interfaces
lan             8000.xxxxxxxxxxxx       no              eth0
e3lan           8000.xxxxxxxxxxxx       no              eth3
                                                        eth1
                                                        eth2
                                                        wlan
guest           8000.xxxxxxxxxxxx       no              wlan_guest
root@fritz:/usr/sbin#

demnach wird wirklich ausgeführt, was meine Intension war. Aber das erfordert halt ein 2tes LAN Kabel zum Switch...

andiling · 12 Aug 2015

In der Shell führst Du das zunächst aus (Zielpfad anpassen): mount -o bind /dev /var/media/ftp/FRITZ/rootfs/dev

Im SoftEther Server Manager kannst Du ja dann unter Local Bridge Setting Deinen virtual Hub mit einem neuen tap device verbinden, unter Status wird wohl erstmal Fehler stehen.

Zurück in der Shell kannst Du mit ifconfig überprüfen ob das device angelegt wurde (tap_name). Alles weitere geht nach #2 wobei für mich die Modifikation der ar7.cfg ausreichend ist. Wenn das klappt, ist die Fehlermeldung im Server Manager auch weg.

Das Ganze ist bei mir allerdings nicht von Dauer, deswegen wird die Prozedur (das Skript in #7) bei jedem Boot durchgeführt. Die Reihenfolge ist wichtig: Zuerst dev, dann server starten, dann ar7.cfg modifizieren. Dazu gibt es ja bekanntermaßen genügend Wege, unter anderem die debug.cfg. Ich habe das zum Test auf zwei verschiedenen Boxen am Laufen, die eine seit gestern unangerührt, die andere heute diverse Male neu gestartet. Es funktioniert bei mir bisher zuverlässig.

Am Rande noch: Der SoftEther Server hat auch noch was sich SecureNAT nennt, wenn Du den nutzt, kannst Du Dir das ganze bridging sparen. (Du hast allerdings dann ein eigenes Subnet und einen eigenen DHCP Server für die Clients und wohl keine Verbindung auf Level2-Basis)

ChAoS · 12 Aug 2015

ihr habt recht:

a) ich war blind in #2 und #7 steht alles *schäm*
b) scheint es mit dem tap zu gehen

habs jetzt temporär am laufen. Bin grad nicht on site, mach alles aus der Ferne. Nach einem LAN-Loop *ups* und einer zum glück einfach rebooteten box scheint es zu laufen...

werd heute Abend dann das Feintuning machen und nochmal berichten...
dann kann ich mir das "von hinten durch die brust ins auge" sparen
Ganz fettes Danke nochmal für Info und Geduld

LG
Dirk

EDIT:
So, hab gerade das Projekt scheinbar abgeschlossen - dank euch

also, die ar7.cfg hat jetzt wieder ihren Originalzustand. Vorm Start des VPNServers per chroot wird das /dev in der chroot Umgebung eingeblendet, dann der VPN Server gestartet, er erzeugt das tap_se_1 und das wird dann nach 5 weiteren Sekunden mit brctl in die bridge lan mit aufgenommen.

Code:

root@fritz:/# brctl show
bridge name     bridge id               STP enabled     interfaces
lan             8000.xxxxxxxxxxxx       no              eth0
                                                        eth1
                                                        eth2
                                                        eth3
                                                        wlan
                                                        tap_se_1
guest           8000.xxxxxxxxxxxx     no              wlan_guest
root@fritz:/#

habe getestet, der vpnserver überlebt jedenfalls auch ein "neu verbinden" aus dem webif und die Box is von außen erreichbar... also jetzt sieht alles wirklich sauber aus

Danke nochmals

[Gelöst] ar7.cfg - Bridging Änderungen werden zurückgesetzt?!?

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

IPPF-Urgestein

IPPF-Promi

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Promi

Neuer User

IPPF-Urgestein

IPPF-Promi

Neuer User

IPPF-Promi

IPPF-Urgestein

Neuer User

IPPF-Promi

Neuer User

Statistik des Forums