NFS auf 7390 funktioniert nicht

[riden666]

Hey Leute,

gibt es inzwischen eine Lösung für das Problem?
Leider musste ich feststellen das NFS über eine FB-7390 (84.05.22) nicht funktioniert. Die Box verwende ich als Switch,
NFS läuft auf einem Solaris-Server.

Nutzt man NFS per TCP ( -o tcp ) funktioniert es, die Box scheint UDP nicht zu mögen.
Ersetze ich meine FB gegen ein Switch funzt alles. Den Fehler würde ich also nicht in Linux suchen, da es mit Solaris auch nicht klappt.

Es ist schon traurig, dass ein Gerät in der Preisklasse nicht mal das Switching beherrscht. :-(

 

[sharbich]

Hallo Ihr Lieben,

da ich per NFS auf meine externe Festplatte zugreifen möchte und dort die Homeverzeichnisse für die Userzertifikate persistend gespeichert habe, funktioniert nun auch die Anmeldung über Dropbear an die Box nicht mehr. Nach dem Handshake friert beim Willkommensbildschirm von Freetz die Sitzung ein.

Samba möchte ich nicht einsetzen weil es beim Dateizugriff zu langsam ist.

Ich kann auch nicht auf eine andere Version wechseln, weil dann die iptables Module nicht mehr laufen. Warum wurde das Ticket 1401 zur Version 1.2.1 geschlossen obwohl es soviele Abhängigkeiten gibt?

Lieben Gruß von Stefan

 

[sharbich]

Ich habe einige Live- und Rettungs-CDs verschiederer Distros in einer VirtualBox ausprobiert und kann das jetzt weiter eingrenzen:
Kernel 2.6.21.1 ist noch OK, die Verzeichnisse werden auch nach mehrfachen Aufruf korrekt gelistet
Kernel 2.6.22.6 ist nicht mehr OK, wie oben beschrieben beim ersten ls noch OK, beim zweiten folgt eine leere Ausgabe.
Ich habe dazu eine Diff der beiden Verzeichnisse nfs und nfs-common erstellt. Vielleicht kann sich das ja mal jemand anschauen, ich muß da passen, das ist zu hoch für mich.

Ganz nebenbei habe ich nochmal eine strategische Frage, auch wenn ich persönlich noch die 04.91 nutze (w.g. iptables/nat und eigenen Kernel mit advanced routing / multiple routing tables): Lohnt sich der Aufwand überhaupt noch? Ich hatte mal die 05.05 mit 2.6.28 drauf und damit schien NFS-betreffend alles OK zu sein.

Also ich würde es mir wünschen, weil ab der 05.05er die iptables Module nicht mehr geladen werden.

Lieben Gruß von Stefan

 

[capt_bluebaer]

Es geht!!!

@sharbich, danke Deiner Nachfrage hier, somit bekam ich es während der kalten Ostertage wenigstens nicht mit der Langeweile zu tun.
Erst hatte ich eine Client-basierte Lösung im Auge weil ich es für leichter hielt, es reichte ein Einzeilen-Patch im nfs-client. Funktionierte aber nur bis Kernel 2.6.36 (das waren die mit einem ls), darüberhinaus war Schluß mit Lustig weil es zu viele Änderungen gab (besonders nfsv4 glaube ich). Ganz nebenbei hielte ich diese Lösung für keine saubere, es wäre wahrscheinlich für einige Clients auch unmöglich gewesen, diese zu patchen.
Also mußte der nfsd auf der FB gepatched werden, hatte ja schon die Vermutung, daß es am Kernel lag. Angefangen mit dem Auslagern der Module und den Vanilla-Sources des Kernel 2.6.19, bei denen ich auf das gleiche Problem stiess, nahm ich mir diese aus dem 2.6.20 Kernel - ein paar struct-Anpassungen und es lief. Schliesslich Module wieder in Kernel - alles OK!
Getestet habe ich als Client 2.6.17, 2.6.31, 2.6.32 sowie 3.2.1, ein Test mit einem 3.7 bzw. 3.8 folgt in Kürze. Bei allen keine Probleme mit mehrfachen ls oder "F5"-Aktualisierungen in Datei-Browsern, das gemountete Verzeichnis verhält sich wie ein lokales. Ein Netboot von der FB mit tftpboot/nfs-Kombination funktioniert auch ohne Probleme.
Ich bitte um ausgiebige Test, vielleicht habe ich noch was übersehen. Natürlich habe ich nicht alle möglichen Optionen testen können.
Im Anhang befindet sich ein Diff für den nfsd-patch. Wer Lust hat, kann ja mal die Ursache für den Bug im 2.6.19 suchen.
Ob und wie man das ins SVN übernehmen kann, weiß ich nicht - da müßte sich event. jemand um kümmern, der sich damit auskennt.
Btw., AVM muß ich aufgrund meiner Tests in Schutz nehmen, die haben diesbezüglich nicht den Kernel vermurkst. Übel nehme ich denen nur die skbuf-Sache in den neuen FWs, aber das ist ein anderes Thema.

 

[sharbich]

Hallo Ihr Lieben,

könnt Ihr mir einen Tip geben wie ich die nfsd.diff.txt Datei in der Stabilen Version 1.2 einbinden kann? Das wäre echt super.

Lieben Gruß von Stefan

 

[capt_bluebaer]

Hi,
Patch in Dein Freetz-Wurzelverzeichnis kopieren, dann

cd <DeinHomeVerzeichnis>/freetz-stable-1.2
mv nfsd.diff.txt nfsd.diff
patch -p0 < nfsd.diff

Falls noch nicht geschehen, in Menuconfig die Option "Replace Kernel" aktivieren, sonst kompilierst Du zwar einen mit korrektem NFSD-Daemon, flashst aber den von AVM mit den bekannten Problemen.
Dann make und Image flashen.
Afaik funktioniert das aber nur mit einer Umgebung für den 2.6.19 Kernel bzw. der 04er Firmware, bei Revs mit 05er FW gehts natürlich nicht.

 

[olistudent]

Hast du die Änderungen per Hand aus dem Code übertragen? Es wäre schön, wenn du ein paar Upstream Changesets benennen könntest... (http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/fs/nfsd?h=linux-2.6.21.y)

Gruß
Oliver

 

[sharbich]

Hallo capt_bluebaer,

super, endlich.

Auch bei mir klappt es. Ich greife mit Ubuntu Kernel 3.2.0-40-generic i686 auf den NFS-Server zu. D.h. iptables, conntrack, nhipt und nfs funktioniert. Genau was ich brauche.

Lieben Gruß von Stefan

 

[capt_bluebaer]

@sharbich,
genau die von Dir aufgeführten Pakete sowie Source-Routing/iproute2 halten mich davon ab, auf die 05er FW umzusteigen.
Schön, dass auch bei Dir läuft.

@olistudent,
da meine c-Kenntnisse doch eher bescheiden, wenn nicht sogar dürftig sind, habe ich die nfsd-Sourcen komplett aus dem 2.6.20er Kernel direkt in den AVM-Kernel kopiert, Compiler-Fehler beim Bauen manuell repariert und dann den Diff erstellt, frei nach dem Motto "Trial and Error" - Ergebnis siehe Beitrag #24.

Trotzdem nochmal Danke für den Link - den kannte ich bisher noch garnicht, sieht interessant aus und hat mich angespornt, den betreffenden Changeset zu finden.
Hier ist die Punktlandung (datiert 26.01.2007), alle vorherigen brachten nicht die Lösung:
nfsd-fs
nfsd-include
Die Diffs lassen sich direkt auf den AVM-Kernel anwenden, ich habe das aber gleich nochmal in ein File gebracht (Anhang).
Jetzt aber die Frage an die Spezialisten:
Kann mir jemand anhand des Changesets erklären, was die Ursache für die "leeren" Verzeichnisse war? Aus den Erläuterungen werde ich nicht schlau.
Und zweitens, noch viel interessanter, warum funktioniert es ohne Patch auf der 7270/mipsel/little endian wie hier von einigen Usern bestätigt wurde?

 

[sharbich]

Hallo capt_bluebaer,

ich bin total ratlos. Nachdem ich die Stabile Version neu erstellt habe kann ich machen was ich will, es funktioniert einfach nicht mehr. Mehmals replacekernel aktiviert und deaktiviert. make dirclean, Patch neu installiert. Alles, aber wirklich alles ausprobiert, ohne ein einzigen Erfolg. Es ist zu verzweifeln.

Lieben Gruß von Stefan

 

[capt_bluebaer]

Hallo sharbich,

1. Was funktioniert nicht, Problem wie hier beschrieben oder irgendwas anderes?
2. Gibt es beim Befehl "patch -p0 < nfsd.diff" irgendwelche Fehler? Poste doch mal die Ausgabe.
3. Hast Du die richtige Rev (04er FW)?

Nach einem dirclean mußt Du erstmal ein Image bauen, damit die Kernel-Quellen entpackt werden. Dann wendest Du den Patch an.
Führst Du dann ein "make" aus, wird m.W. kein neuer Kernel gebaut, sondern der aus dem ersten Image gebaute benutzt.
Vor dem "make" also ein "make kernel-menuconfig" aufrufen, dann gehst Du direkt auf "Exit" und bestätigst die Abfrage nach dem Speichern der Config.
Dann sollte es mit einem "make" klappen, man kann bei der Ausgabe auch sehen, dass der nfsd neu gebaut wird.

 

[olistudent]

Danke fürs Raussuchen. Ich hab den Patch ans Ticket angehängt.

Gruß
Oliver

 

[sharbich]

Hallo capt_bluebaer,

ich hatte vergessen noch dem Patch noch make kernel-menuconfig auszuführen, um dann mit make die FW zu erstellen, dass war der Fehler. Vielen Dank für den Tipp.

Lieben Gruß von Stefan