Kernel Bug mit openvpn

[mehle]

Gut möglich dass freetz an dem Problem nicht ganz unschuldig ist...

Dies ist sehr gut möglich. Ich hatte bis vor kurzem auch den TAP Modus aktiv und ich habe jetzt die gleichen oben beschriebenen Probleme.

Interessant dabei ist, daß ich nicht einmal ein Ping durch den Tunnel schicken kann.

ABER: wenn ich openvpn von Hand starte oder aus dem Startskript den brctl-Aufruf aus start() entferne, kann ich pingen.

Ich habe aber kein Test gemacht, ob die TAP Konfig ohne dem brctl-Aufruf stabil ist.

Ciao
Stephan

[Pace]

Ich vermute mal dass der WLAN-Fehler etwas mit der Brücke zu tun hat.
Daher bleibt der Fehler auch weg wenn man die Brücke der Interfaces weglässt...

Ich weiß nicht ob ich dich richtg verstanden habe:
Geht es bei dir, wenn du openvpn von hand startest ?
Ist dann die Brücke auch aktiv ?

[mehle]

@Pace: ich kann deine Frage leider nicht beantworten, da ich den Zwang zur Brücke nie hatte und damit nie getestet habe - bei meiner Einsatzumgebung ist TAP oder TUN egal, ebenso ob brctl aufgerufen wurde oder nicht.

Ich wollte das mit dem brctl nur mal in die Runde werfen, da ich sehr überrascht war, daß meine Verbindung ohne dem brctl-Aufruf sauber funktioniert hatte.

Nun bin ich aber auf den TUN mode umgestiegen und habe meine TAP Konfig weggeschmissen.

Ciao
Stephan

[MaxMuster]

@mehle: Wenn du die Brücke nutzt, ohne sie zu benötigen, ist es eigentlich nicht verwunderlich, wenn es ohne "brctl" läuft , denn dann wird das tap einfach nicht zum "lan" Interface gebrückt...

In dem Script war übrigens ein Fehler drin, der bei mehr als einem tap zu Problemen führte, Patch dazu im Ticket 383

ich habe nach einem Update auch Probleme mit OpenVPN im Bridge-Modus....
die Verbindung kommt einfach nicht zustande

Könntest du dazu mal genaueres Schreiben?
In wie fern ist das mit dem hier genannten Kernel-Problemen verbunden?
Von wo nach wo wird die Verbindung aufgebaut, mit welcher Konfig? Ist die Box Server?
Wie wird in dem Fall die Portweiterleitung gemacht?

Jörg

[Pace]

Hab nun verschiedenes probiert:

-aktuelle freetz-devel-3099
-mit Labor AiO
-mit replace-Kernel

Leider immernoch der gleiche Bug...

Da verschluckt sich wohl der (von AVM anscheinend veränderte) Atheros WLAN-Treiber an irgendeinem Broadcast-Paket aus dem VPN, das ja per Brücke verbunden ist...

Wer hat eine Idee, was man da tun könnte?
Drauf hoffen dass das in ner zukünftigen FW wieder anderst wird will ich nicht unbedingt, und ich bräuchte das bridged-VPN für gleich mehrere Boxen, an denen das jetzt nicht meh geht :/

[MaxMuster]

Gibt es denn eine "ähnliche" AVM-FW für die Box, mit der das geht?
Dann könnte man ja mal versuchen, den älteren Treiber stattdessen zu laden, sofern die Kernelversion die gleiche geblieben ist??

Jörg

[Pace]

Gibt es denn eine "ähnliche" AVM-FW für die Box, mit der das geht?
Dann könnte man ja mal versuchen, den älteren Treiber stattdessen zu laden, sofern die Kernelversion die gleiche geblieben ist??

Gute Idee !
Angeblich ging es ja noch mit der 54.04.59 (hab es selbst nichth getestet, aber oben war ja die Aussage).

Ich kenne mich dafür leider zu wenig aus.
Weiß jemand eine Möglichkeit den WLAN-Treiber-Teil aus der 59er FW zu extrahieren?
Vllt könnte man das ja als Patch im config-Menü anbieten...

Viele Grüße,
Patrick

[Matthy]

Ich habe tatsächlich mal versucht die WLAN-Treiber aus der 59er zu extrahieren und in der 67er einzusetzen. Das ging eher schlecht als recht. Ich habe es nur geschafft, dass es scheinbar im WEP-Modus lief, obwohl eigentlich WPA eingestellt war. OpenVPN hatte ich damit dann aber nicht probiert.
Zwischen den Versionen hat sich noch mehr geändert (hostapd-Konfiguration), so dass ich es dann aufgegeben habe, da es mir dann doch zu eklig war.
Inzwischen benutze ich eine TUN-Konfiguration, damit OpenVPN wenigstens "irgendwie" funktioniert. Ich wäre aber auch weiterhin an einem echten Fix interessiert, auch wenn es evtl. nur die Leute von AVM fixen können.

[matze1985]

Wenn ich das jetzt richtig mitbekommen habe (ich habe mehr halb mitgelesen), dann passiert der Bug, wenn man ein TAP Netzwerk nutzt _und_ dieses per brctl ins lokale Netz birgded.

(Das "und" ist deshalb wichtig, da bei mir TAP läuft, aber ich es nicht bridge)

Tritt der Fehler denn auch auf, wenn ihr das Interface über die ar7.cfg ins lokale Netz birgded?

[Pace]

Korrekt!

Ob es auch passiert wenn die Brücke über die ar7.cfg erfolgt kann ich nicht sagen, muss ich heute mal testen...
Obwohl: Die tap-devices werden doch erst vom startenden openvpn angelegt. Wenn ich die in die ar7 eintrage geht das doch gar nicht, oder?

[MaxMuster]

... doch, das geht (ich meine, das macht der "multid").

Jörg

[matze1985]

Vielleicht sollte das mal jemand über die ar7.cfg testen, dass wäre wenigestens ein workaround ohne Einschränkungen, erklärt aber leider den Fehler noch nicht wirklich.

[dridders]

Ah, hier ist das Problem Wie hier beschrieben tritt die Problematik auch schon ohne freetz auf. Voraussetzung ist einfach ein OpenVPN-TAP das zum Interface LAN hinzugefügt wird. Der Reboot erfolgt dann schneller als man gucken kann sobald ein Paket vom WLAN aus über die Bridge geht. Geht da keins raus hat man kein Problem. Derzeit ist mein WLAN auch aktiv, OpenVPN aktiv, etc, nur ich hänge per Strippe an der Box und am WLAN hängt nichts. Läuft stabil seit Stunden. Würde ich jetzt auf WLAN umschalten hätte ich keine Sekunde Zeit bis zum Reboot. Zum serielle Konsole abgreifen is die Box leider noch was zu neu, per Telnet gibts keine einzige Meldung mehr.

[matze1985]

Ist bei euch denn das WLAN auch in der bridge?

[dridders]

Das ist Voraussetzung damit der Reboot kommt. Es müssen eth0, ath0 und tap0 in der Bridge sein, und dann ein Paket von ath0 kommen das über tap0 raus soll (oder evtl. umgekehrt, lässt sich ja schlecht sagen). Die Existenz in der Bridge allein ist aber noch nicht das Problem, erst wenn sie auch genutzt wird. Ich kann übers WLAN z.B. auf die Box selbst auch wunderbar zugreifen, obwohl WLAN und OpenVPN in der Bridge sind. Wehe aber ich schicke ein Paket das nicht an die Box geht.

[matze1985]

Was passiert, wenn ihr das WLAN aus der Bridge nehment, also ein eingenes Netz für WLAN betreibt, dass kann man ja in der AVM-FW so einstellen.

Edit: Was bedeuten die Interfaces eingentlich genau, Was sind ath0, wifi0, wdsdw1 [, wdsdw2, wdsdw3 , wdsdw4], welches ist denn wirklich WLAN davon?

[dridders]

Frisch getestet. Wenn ichs WLAN in ein separates Netz packe und die Bridge entferne, dann entfernt die Fritz als erstes Mal das ganze LAN-Interface, es bleiben dann nur noch die Einzel-Interfaces. Ich hab dann manuell ein neues LAN-Interface aufgemacht und tap0 + eth0 dran gehängt. Ergebnis: Pakete die über WLAN rein kommen gehen (je nach Routing) über tap0 auch raus. NAT gibts da allerdings keins, die Routen müssen also auf der anderen Seite vom Tunnel entsprechend angepasst sein. Abstürze: nö.
ATH0 ist das eigentliche Interface das von ipconfig genutzt werden kann. wifi0 ist irgend eine Art "Verwaltungsinterface" die der Atheros-Treiber mit sich bringt. Ist bei den Atheros-Karten auf dem PC das gleiche. Die wd... hm... gute Frage. Tauchen aber nie in einer Bridge auf und haben auch nie eine Adresse. Könnten evtl. für die einzelnen anmeldbaren WDS-Repeater reserviert sein. Teste ich vielleicht die Tage mal.

[Pace]

Gut, der Stand ist also dass es genau dann nicht geht wenn WLAN (ath0) und OpenVPN TAP-Device (tap0) in einer Brücke (lan) sind und auch eine Kommunikation zwischen diesen interfaces erfolgt!

Mein Problem ist leider nur dass ich genau das brauche

Mir fällt leider nichts mehr ein, was man noch testen könnte um der genauen Ursache auf den Grund zu gehen.
Ein workaround der die Brücke von tap0 und ath0 inkl Kommunikation zwischen den Beiden zulässt würde mir schon ungemein helfen :/

[dougi]

Status Quo?

Habe selber leider nix neues zu dem Thema

[Pace]

Ich leider auch nicht :/

Klar ist dass das Problem wohl aus dem modifizierten WLAN Treiber von AVM kommt.
Ein Workaround fällt mir leider keiner ein.

Meint ihr es könnte was nutzen mal die Fehlerbeschreibung an AVM zu senden ?
Nicht einmal als Reklamation, mehr als Hinweis auf einen möglichen Bug.

Hat jemand Erfahrung damit ob oder wie die auf sowas reagieren ?