nfs über openvpn/wlan - discard oversize frame

[kazcor]

Hallo Welt,

ich hab gerade zu Haus mein WLAN mal wieder aktiviert, um das neue Note unabhängig vom Kabel zu haben. Dazu also erstmal im Router WEP aktiviert (mehr kann die Karte im Note nicht), dann auf beiden Seiten (Note/Server) openvpn aufgesetzt (mit tap, fast ungeändert das tls-office/home Beispiel), pf etwas gekitzelt und alles funktioniert. Fast alles jedenfalls. Die Konstruktion sieht also bisher wie folgt aus:
Notebook ----> Router ---> Server

Wenn ich jetzt versuche, was per NFS vom Server zu mounten, funktioniert das zwar, beim Kopieren grösserer Dateien (>=64k) bricht das ganze jedoch zusammen und ich erhalte:

ipw0: discard oversize frame (ether type 800 flags 3 len 1518 > max 1514)

Das Problem scheint also erstmal am wireless interface zu hängen. Habe das noch nicht ohne openvpn ausprobiert - da das ganze aber darüber läuft, müsste es doch reichen tap0 bzw. openvpn auf beiden Seiten bzgl. mtu anzupassen und dann sollte ipw0 Ruhe geben. Also hab ich auf beiden Seiten in der OpenVPN config eingetragen:

link-mtu 1514

Danach wird auch in der Tat auf beiden Seiten tap0 auf eine MTU von 1440 gesetzt (warum auch immer) und ipw0 gondelt weiter bei 1500. Das Problem besteht aber weiterhin.

Bevor ich jetzt hier 200 Konfigurationsdateien anhänge erstmal die Frage, ob jemand einen spontanen Einfall hat, woran es liegen könnte. Der Server hängt per 100 MBit und das Note mit 11MBit am Router - aber das sollte der doch geregelt bekommen?

Dank & Grüße,
kaz

 

[morromett]

Ähnliches Problem aber mit einer anderen NIC, siehe Link:

http://www.freebsd.org/cgi/query-pr.cgi?pr=55542

 

[MrFixit]

/me too.

Hatte ebenfalls lange Zeit NFS ueber OpenVPN und bfe(4) bzw. iwi(4) laufen. Mit bfe(4) gab es nie Probleme, bei iwi(4) hat das ab und an geklemmt. Nach dem Durchstarten von wpa und vpn gings dann meistens wieder.

 

[kazcor]

Danke für eure Antworten. Das Problem lag zum Glück nicht am Treiber, sondern wirklich an meiner unvollständigen OpenVPN Konfig.

In openvpn(8) wird geraten, bei möglichen MTU basierten Problemen folgende Parameter anzugeben (für tap):

link-mtu 1500
fragment 1300
mssfix

Ich schätze mal im Endeffekt lag es am Senden umfragmentierter Pakete, wobei nun mit Frament die Paketgrösse auf 1300 beschränkt ist und via mssfix darüber laufende TCP Verbindungen das Limit ebenfalls aufgezwungen bekommen. Optimale Werte lassen sich mit der Option

mtu-test

initial herausfinden.