NFS auf 7390 funktioniert nicht

[MikeCC]

Hallo,

habe auf eine FritzBox 7390 aufgerüstet und den aktuellen Trunk (84.04.91freetz-devel-7060) aufgespielt.

Leider funktioniert meine NFS Freigabe nicht.
Meine exports:

/var/media/ftp/uStor01 *(rw,insecure,no_subtree_check,async,nohide)

Meine hosts.allow:

ALL:192.168.178.0/255.255.255.0

Meine hosts.deny ist leer.

Auf dem Client habe ich folgenden Eintrag in der fstab:

192.168.178.1:/var/media/ftp/uStor01	/mnt/HomeServer	nfs user,rw,hard,intr,nolock,rsize=8192,wsize=8192,vers=3,proto=udp	0	0

Diese Konfiguration hat mit meiner alten 7270 hervorragend funktionert. (Trunk: 7270_v2_04.88freetz-devel-6337)

Mit meiner neuen 7390 verschwinden alle aufgelisteten Dateien im MountPoint nach kurzer Zeit....sie werden einfach nicht mehr angezeigt.

Sehr seltsam!
Hat da jemand zufällig einen Reim drauf?

 

[olistudent]

Du kannst den Share mounten? Aber nach einiger Zeit (Minuten? Stunden?) sind die Dateien verschwunden? Aber der Share wird noch als gemountet aufgeführt? Was passiert wenn du neu mountest? Steht was im Syslog?

Gruß
Oliver

 

[MikeCC]

Mounten geht wunderbar.
Das Verhalten ist schwierig zu beschreiben.
Beim ersten Zugriff auf den MountPoint werden die Dateien und Verzeichnisse korrekt dargestellt.
Wenn ich dann ein Verzeichnis öffnen möchte, ist alles auf einmal weg...auch im MountPoint werden keine Dateien und Verzeichnisse mehr aufgelistet.
Der Share wird dann noch als gemountet aufgeführt.
Wenn ich neu mounte geht das Spiel von vorne los.

Im Syslog auf der Box und auf dem Client steht nichts.

 

[MikeCC]

Wenn ich den nfs server auf der Box neustarte, habe ich folgende Meldungen im syslog:

Kernel does not have pseudo root support.
May 29 21:32:12 fritz daemon.warn mountd[13782]: NFS v4 mounts will be disabled unless fsid=0
May 29 21:32:12 fritz daemon.warn mountd[13782]: is specfied in /etc/exports file.

 

[capt_bluebaer]

Das Verhalten habe ich auch bei mir festgestellt. Wenn man in einem "leeren" Verzeichnis eine neue Datei erstellt, wird der Verzeichnisinhalt gelistet. Dann beginnt das Spielchen von vorne.
Erstelle ich aber einen NFS-Mount von meinem Kathrein-UFS910-Receiver (Kernel 2.6.17) auf die 7390 ist alles OK, die Mountpoints werden immer korrekt angezeigt. Muß deshalb wohl irgendwie an den PC-Clients liegen (alle mit 2.6.36-er Kernel), allerdings habe ich das Verhalten mit diesen Clients nicht, wenn ich auf einen PC-NFS-Server zugreiffe. Die PC's haben die nfs-utils 1.2.3 installiert, genauso wie die Fritzbox. Die Fritzbox zeigte das Verhalten aber auch schon mit nfs-utils-1.2.0.

 

[olistudent]

Habt ihr mal probiert, ob sich mit "replace kernel" was ändert?

Gruß
Oliver

 

[capt_bluebaer]

Leider das Gleiche.

 

[MikeCC]

@capt_bluebaer
Aber wieso hatte ich dieses Verhalten nicht mit meiner 7270 Fritzbox mit Freetz 7270_v2_04.88freetz-devel-6337?
Dort hat der NFS Zugriff mit exakt dem selben Client wunderbar funktioniert.
Deswegen glaube ich nicht, dass es an dem Client liegt, sondern an Freetz.

 

[capt_bluebaer]

Mit meiner 7170 und den gleichen Clients hatte ich auch nie Probleme. Da ich aber mindestens einen Client habe, der auch keine Probleme mit der 7390 hat, glaube ich nicht, daß es nur an Freetz liegt, eher an der Kombination Freetz/Kernel-2.6.19. Bin jetzt aber nicht informiert, was für ein Kernel in der 7270 werkelt, ist es ein anderer, sehe ich da auf jeden Fall Unterschiede.

 

[abraXxl]

Ein kleines Update:
* Das Problem kann ich hier reproduzieren, mit oder ohne ersetztem Kernel, selbst wenn ich die Funktionalität als Modul ins Image erzwinge.
* In meinem Testcase passiert folgendes:
1."mount"
2. erstes "ls" zeigt 182 (+zwei . und ..) dateien und dirs -
3. zweites "ls" zeigt keine dateien
4. Direktzugriff auf eine Datei mit bekannten Dateinamen geht mit "file", "grep" und "ls -l"
5. "umount"

Die strace-Ausgabe dazu ist interessant:
Erfolgreiches "ls"

...
16807 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
16807 fcntl64(3, F_GETFD)               = 0x1 (flags FD_CLOEXEC)
16807 getdents64(3, /* 184 entries */, 32768) = 9680
16807 getdents64(3, /* 0 entries */, 32768) = 0
16807 close(3)                          = 0
16807 fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 8), ...}) = 0
16807 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb76b2000
16807 write(1, "001 desce037.mid.mp3\t\t\t\t\t-bully2"..., 39) = 39
16807 write(1, "001 desce038.mid.mp3\t\t\t\t\t-bully3"..., 39) = 39
...
16807 write(1, "008 desce045.mid.mp3\t\t\t\t\tc6e460d"..., 70) = 70
16807 close(1)                          = 0
16807 munmap(0xb76b2000, 4096)          = 0
16807 close(2)                          = 0
16807 exit_group(0)  = ?

Nicht erfolgreiches "ls"

...
16809 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
16809 fcntl64(3, F_GETFD)               = 0x1 (flags FD_CLOEXEC)
16809 getdents64(3, /* 184 entries */, 32768) = 9680
16809 getdents64(3, /* 0 entries */, 32768) = 0
16809 close(3)                          = 0
16809 close(1)                          = 0
16809 close(2)                          = 0
16809 exit_group(0)                     = ?

Wie man sieht liefert der Syscall "getdents64()" scheinbar alle 182 + 2 (., ..) Einträge zurück, jedoch werden sie nicht angezeigt. Was vermuten lässt, dass diese nicht sinnvolle Daten enthalten sondern wahrscheinlich leer (\000) sind und "ls" in d .
Warum ist mir erstmal schleierhaft.

ltrace bestätigt dies:
Erfolgreiches ls

...
opendir("/mnt")                                                                                     = 0x09f84200
readdir64(0x09f84200)                                                                               = 0x09f84218
readdir64(0x09f84200)                                                                               = 0x09f84230
readdir64(0x09f84200)                                                                               = 0x09f84248
strlen("lost+found")                                                                                = 10
malloc(11)                                                                                          = 0x09f80e80
memcpy(0x09f80e80, "lost+found", 11)                                                                = 0x09f80e80
readdir64(0x09f84200)                        
...
closedir(0x09ef84200)

Nicht erfolgreiches "ls"

...
opendir("/mnt")                                                                                     = 0x09ef5200
readdir64(0x09ef5200)                                                                               = 0x09ef5218
readdir64(0x09ef5200)                                                                               = 0x09ef5230
readdir64(0x09ef5200)                                                                               = NULL
closedir(0x09ef5200)
...

Da das Busybox ls die selben Ausgaben macht hier der relevante Teil aus busybox-1.18.4/coreutils/ls.c:

/*... */
    dir = warn_opendir(path);
    if (dir == NULL) {
        exit_code = EXIT_FAILURE;
        return NULL;    /* could not open the dir */
    }
    dn = NULL;
    nfiles = 0;
/*... */
    while ((entry = readdir(dir)) != NULL) {
        char *fullname;

        /* are we going to list the file- it may be . or .. or a hidden file */
        if (entry->d_name[0] == '.') {
            if ((!entry->d_name[1] || (entry->d_name[1] == '.' && !entry->d_name[2]))
             && !(all_fmt & DISP_DOT)
            ) {
                continue;
            }
            if (!(all_fmt & DISP_HIDDEN))
                continue;
        }
/* ... */
    }
    closedir(dir);
/*... */

Intern wird das readdir(dir) wohl von der libc auf den syscall dirents64() um gemapt. "." und ".." sind vorhanden jedoch sind die Datenstructuren für alle weiteren Verzeichnisse leer bzw. nicht vohanden = NULL.

Der Client war ein Ubuntu Lucid 32bit mit 2.6.32 Distribution-Kernel.
Bei einem weiteren Client mit Debian Broken/Unstable 2.6.38.2, lies schon den ersten "ls" fehlschlagen, der Direktzugriff funktioniert jedoch weiterhin.

Mit Vermutungen bin ich noch vorsichtig. Ich bin mir nicht sicher wo das Problem liegen könnte. Hier mal ein paar Ideen die aus meinem Kopf fallen bevor ich in Bett falle:
- Hat sich das was in neueren Kernel-Versionen geändert?
- Gibt es Kernelbugs ihn 2.6.19 die nur mips (be) betreffen? (bei mipsel geht es doch?)
- Was passiert bei niedriegeren Kernelversionen beim Client? (<2.6.28 )
- Was enthält der zugehörige Netzwerktraffic (Wireshark/Tcpdump)

 

[RalfFriedl]

Versuche es mal mit "strace -v ls", dann wird auch genau angezeigt, was der readdir Aufruf liefert.

 

[abraXxl]

Danke für den Tipp mit "strace -v".

Mein Testcase sieht jetzt so aus:

# ls -la
drwxr-xr-x    6 openvpn  root          8192 Jun 12 14:14 .
drwxr-xr-x    1 ftpuser  users         2048 Jan  1  2000 ..
drwxr-xr-x    2 root     root          4096 Jun 12 14:13 dir-a
drwxr-xr-x    2 root     root          4096 Jun 12 14:13 dir-b
drwxr-xr-x    2 root     root          4096 Jun 12 14:13 dir-c
-rw-r--r--    1 root     root            36 Jun 12 14:14 file-a
-rw-r--r--    1 root     root            43 Jun 12 14:14 file-b
-rw-r--r--    1 root     root            50 Jun 12 14:14 file-c
drwx------    2 root     root         16384 Jun 10 20:12 lost+found

Ich habe noch einmal "ls" ausgeführt mit strace. Hier die Spuren:

Funktionierendes erstes "ls":

15947 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
15947 fcntl64(3, F_GETFD)               = 0x1 (flags FD_CLOEXEC)
15947 getdents64(3, {{d_ino=2, d_off=1, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=2, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=11, d_off=3, d_type=DT_DIR, d_reclen=32, d_name="lost+found"} {d_ino=23089, d_off=4, d_type=DT_DIR, d_reclen=32, d_name="dir-a"} {d_ino=15393, d_off=5, d_type=DT_DIR, d_reclen=32, d_name="dir-b"} {d_ino=30785, d_off=6, d_type=DT_DIR, d_reclen=32, d_name="dir-c"} {d_ino=12, d_off=7, d_type=DT_REG, d_reclen=32, d_name="file-a"} {d_ino=13, d_off=8, d_type=DT_REG, d_reclen=32, d_name="file-b"} {d_ino=14, d_off=9, d_type=DT_REG, d_reclen=32, d_name="file-c"}}, 32768) = 272
15947 getdents64(3, {}, 32768)          = 0
15947 close(3)                          = 0
15947 fstat64(1, {st_dev=makedev(0, 11), st_ino=5, st_mode=S_IFCHR|0600, st_nlink=1, st_uid=1000, st_gid=5, st_blksize=1024, st_blocks=0, st_rdev=makedev(136, 2), st_atime=2011/06/12-14:15:37, st_mtime=2011/06/12-14:15:37, st_ctime=2011/06/12-13:56:23}) = 0
15947 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7756000
15947 write(1, "dir-a  dir-b  dir-c  file-a  file-b  file-c  lost+found\n", 56) = 56
15947 close(1)                          = 0
15947 munmap(0xb7756000, 4096)          = 0
15947 close(2)                          = 0
15947 exit_group(0)                     = ?

Karp0tes zweites "ls":

15957 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3
15957 fcntl64(3, F_GETFD)               = 0x1 (flags FD_CLOEXEC)
15957 getdents64(3, {{d_ino=2, d_off=1, d_type=DT_DIR, d_reclen=24, d_name="."} {d_ino=2, d_off=2, d_type=DT_DIR, d_reclen=24, d_name=".."} {d_ino=0, d_off=3, d_type=DT_UNKNOWN, d_reclen=32, d_name="lost+found"} {d_ino=0, d_off=4, d_type=DT_UNKNOWN, d_reclen=32, d_name="dir-a"} {d_ino=0, d_off=5, d_type=DT_UNKNOWN, d_reclen=32, d_name="dir-b"} {d_ino=0, d_off=6, d_type=DT_UNKNOWN, d_reclen=32, d_name="dir-c"} {d_ino=0, d_off=7, d_type=DT_UNKNOWN, d_reclen=32, d_name="file-a"} {d_ino=0, d_off=8, d_type=DT_UNKNOWN, d_reclen=32, d_name="file-b"} {d_ino=0, d_off=9, d_type=DT_UNKNOWN, d_reclen=32, d_name="file-c"}}, 32768) = 272
15957 getdents64(3, {}, 32768)          = 0
15957 close(3)                          = 0
15957 close(1)                          = 0
15957 close(2)                          = 0
15957 exit_group(0)                     = ?

Wie man sieht ist beim zweiten "ls" die Inode- und Datei-Typ-Information falsch: d_ino=0 und d_type=DT_UNKNOWN für alle Einträge des NFS-Mounts ausser für . und ..

Darauf hin habe ich mit tcpdump mit geschnitten, was beim "ls" auf das Verzeichnis passiert(siehe Anhang). Das Ergebnis ist frustierend, da beim zweiten "ls" keine NFS-Pakete zwischen Client und Server (7390) versendet werden. Das sieht IMO nach einem komischen Clientproblem aus oder AVM hat in den 2.6.19.2 Sourcen irgendwas verändert, was das Verhalten des NFS-Servers in unbekannter Weise verändert und den Client irritiert.

Als nächstes würde ich mir mal einen Diff der Kernelsourcen von 2.6.19 zwischen einer Box mit funktionierendem Kernel-Space-nfsd und der 7390 anschauen wollen. 7[25]70 vs 7390. Ich bin für weitere Vorschläge jedoch offen.

 

[RalfFriedl]

Ich habe mir die Datei nicht angeschaut, aber wenn Du schreibst, dass beim zweiten Mal nichts übertragen wird, dann gibt es da auch nichts zu sehen. Das spricht dafür, dass der Client das Ergebnis zwischenspeichert, aber falsch. Andererseits sollte der Client das Ergebnis nicht zu lange speichern, weil in der Zwischenzeit sich das Verzeichnis geändert haben könnte.

Was für einen Client verwendest Du? Kannst Du einen anderen Client testen?

 

[abraXxl]

Jo, das mit dem Caching habe ich mir schon gedacht daher die Vermutungen am Ende von #12.
Ich habe, wie ich in #1 schrieb, einen 2.6.32 Distributionskernel aus Ubuntu 10.4 LTS und eine Self-Compiled 2.6.38.2 x84_64 getestet.

Sorry, ich vergass, Wegen der Cachingvermutung habe ich die Mount-Optionen "noac" und "nofsc" auch durch permutiert.
noac = no attribute caching
nofsc = no file caching (Filecaching für NFS und SMB/CIFS ist seit 2.6.30 im Kernel)

Da diese keine Besserung zeigten bin ich mir nicht sicher ob es ggf. am Client liegt, daher die zweite Vermutung in #12.
Zusätzlich haben ja die 7270 und 7570 auch 2.6.19.2, wie die derzeitig stabile 7390er FW und dort geht aus eigener Erfahrung mit obigen Clients NFS ganz gut.
Anders ist auf jedenfall die Endianess 7x70(mipsel) und 7390 (mips big endian). Ein schnelles googlen nach Kernel-Bugs brachte keine Treffer mit starker Evidenz dahingend.
Daher die Vermutung ob AVM im Kernel selbst etwas vermurkst hat.

 

[RalfFriedl]

NFS selbst ist auf der Leitung Big-Endian, und es gibt mit Sicherheit genug Big-Endian Linux-Systeme, dass ein derartiger Fehler im normalen Kernel aufgefallen wäre. Es kann natürlich sein, dass aufgrund von AVM-Eigenheiten der Server etwas sendet, das den Client durcheinander bringt.

Es gab hier letztens einen Userspace NFS-Server für die Box. Willst Du den mal ausprobieren?

 

[capt_bluebaer]

Daher die Vermutung ob AVM im Kernel selbst etwas vermurkst hat.

Das könnte man doch 'rausbekommen, die AVM-Sourcen stehen doch zur Verfügung, und wie ich in Beitrag #7 schrieb, ist das Verhalten mit "Replace Kernel" identisch.
Vielleicht hilft die Info nochmal weiter (siehe Beitrag 5): Ich habe jetzt auch mal den Nachfolger des oben beschriebenen Sat-Receivers getestet, den UFS912 mit einem 2.6.23-Kernel als Client. Und siehe da - er verursacht den gleichen Fehler wie meine PCs. Also muß sich da irgendwas zwischen den NFS-Clients der Kernel 2.6.17 und 2.6.23 verändert haben, worauf der 2.6.19er Server unterschiedlich reagiert.

 

[abraXxl]

Mit den Infos von capt_balubaer scheidet NFS-File-Caching clientseitig (erst seit 2.6.30) im Kernel aus.

 

[abraXxl]

Ich habe mal von Hand den Userspace NFS-Server unfs3 übersetzt, dieser hat diese Client Probleme nicht. Jedoch ist mir dabei aufgefallen, dass multid auf der 7390-91 port 2049/udp (Standard NFS) belegt. Dies ist jedoch nicht Ursache für das NFS Problem, da wenn multid mit "multid -s" vor dem starten des Kernelspace NFS Servers gestoppt wird, treten die bekannt Problem auch auf.

 

[kriegaex]

Wollte nicht mal jemand Kernel-Sourcen vergleichen?

Ich habe mal die jeweils enthaltenen Kernel-Unterverzeichnisse "fs" zwischen 7270_v1 (fritzbox7270-source-files-04.86.tar.gz) und 7390 (fritz_box_fon_wlan_7390_source_files.04.84.tar.gz) verglichen. Direkt in nfs, nfs_common, nfsd gibt es keine Unterschiede, lediglich in fuse/file.c, fuse/dir.c, fat/misc.c, jffs2/readinode.c. Patch von 7270 auf 7390 anbei. Ob das etwas bringt, weiß ich nicht, ich bin kein Kernel-Hacker und habe auch nicht versucht, den Quellcode zu verstehen:
Anhang anzeigen kernel-2.6.19.2_fs_diff_7270v1_7390.patch.txt
Vermutlich bringt Euch das nicht weiter, da ja NFS nicht unter FUSE läuft. Egal, es ist dokumentiert.

Wenn man sich nun die Linux-Client-Seite anschaut und, wie oben empfohlen, mal auf die NFS-Änderungen zwischen 2.6.17 und 2.6.23 fokussiert, sieht man da schon mehr Unterschiede, teils durch Refactoring, teils andere. Vielleicht hat jemand Lust, die anzuschauen. Ich hänge hier keinen Diff an, sondern die vollen Verzeichnisse fs/nfs, fs/nfs_common (direkt von kernel.org), so daß man bequem selbst in WinMerge o.ä. einen Diff anschauen kann:
Anhang anzeigen nfs-2.6.17.zip
Anhang anzeigen nfs-2.6.23.zip
Wenn man die Linux-Version, ab der es im NFS-Client kracht, noch weiter eingrenzen könnte, wäre das gut. Vielleicht kann jemand auf dem Kathrein-Receiver oder auch auf dem PC mal alle Kernels zwischen .17 und .23 durchprobieren, gern auch Unterversionen. Das sollte den Diff kleiner machen und uns Hinweise geben, wo man etwas auf einen älteren Stand zurückpatchen könnte. Sollte Upstream etwas falsch sein, könnte man das weiter melden.

 

[capt_bluebaer]

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.