Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 20 von 33

Thema: NFS auf 7390 funktioniert nicht

  1. #1
    IPPF-Fortgeschrittener
    Registriert seit
    18.03.2006
    Beiträge
    53

    NFS auf 7390 funktioniert nicht

    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:
    Code:
    /var/media/ftp/uStor01 *(rw,insecure,no_subtree_check,async,nohide)
    Meine hosts.allow:
    Code:
    ALL:192.168.178.0/255.255.255.0
    Meine hosts.deny ist leer.

    Auf dem Client habe ich folgenden Eintrag in der fstab:
    Code:
    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?

  2. #2
    Semi-Moderator Avatar von olistudent
    Registriert seit
    19.10.2004
    Ort
    Kaiserslautern
    Beiträge
    14.745
    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
    Router: Fritz!Box Fon WLAN 7570, 7390, 7320, 7270, 3170
    Anbindung: T-Online DSL 16.000 RAM

    Visit ##fritzbox on Freenode for help
    Spenden für Freetz

  3. #3
    IPPF-Fortgeschrittener
    Registriert seit
    18.03.2006
    Beiträge
    53
    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.

  4. #4
    IPPF-Fortgeschrittener
    Registriert seit
    18.03.2006
    Beiträge
    53
    Wenn ich den nfs server auf der Box neustarte, habe ich folgende Meldungen im syslog:
    Code:
    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.

  5. #5
    IPPF-Fortgeschrittener Avatar von capt_bluebaer
    Registriert seit
    10.05.2007
    Beiträge
    72
    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.
    Captain Bluebaer

    FritzBox FON WLAN 7390, 84.04.91freetz-1.2-stable
    callmonitor, dnsmasq, dropbear, iptables, nfsserver, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol, mc, screen
    FritzBox FON WLAN 7170, FW 29.04.70 freetz-devel-3366, WDS Basis
    bluez-utils, callmonitor, dnsmasq, dropbear, iptables, knfs, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol
    FritzBox WLAN 3030, FW 21.04.15ds-0.2.9, WDS Repeater
    dropbear, syslogd
    Provider: Telekom Call & Surf 16 MBit/s

  6. #6
    Semi-Moderator Avatar von olistudent
    Registriert seit
    19.10.2004
    Ort
    Kaiserslautern
    Beiträge
    14.745
    Habt ihr mal probiert, ob sich mit "replace kernel" was ändert?

    Gruß
    Oliver
    Router: Fritz!Box Fon WLAN 7570, 7390, 7320, 7270, 3170
    Anbindung: T-Online DSL 16.000 RAM

    Visit ##fritzbox on Freenode for help
    Spenden für Freetz

  7. #7
    IPPF-Fortgeschrittener Avatar von capt_bluebaer
    Registriert seit
    10.05.2007
    Beiträge
    72
    Leider das Gleiche.
    Captain Bluebaer

    FritzBox FON WLAN 7390, 84.04.91freetz-1.2-stable
    callmonitor, dnsmasq, dropbear, iptables, nfsserver, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol, mc, screen
    FritzBox FON WLAN 7170, FW 29.04.70 freetz-devel-3366, WDS Basis
    bluez-utils, callmonitor, dnsmasq, dropbear, iptables, knfs, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol
    FritzBox WLAN 3030, FW 21.04.15ds-0.2.9, WDS Repeater
    dropbear, syslogd
    Provider: Telekom Call & Surf 16 MBit/s

  8. #8
    IPPF-Fortgeschrittener
    Registriert seit
    18.03.2006
    Beiträge
    53
    @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.

  9. #9
    IPPF-Fortgeschrittener Avatar von capt_bluebaer
    Registriert seit
    10.05.2007
    Beiträge
    72
    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.
    Captain Bluebaer

    FritzBox FON WLAN 7390, 84.04.91freetz-1.2-stable
    callmonitor, dnsmasq, dropbear, iptables, nfsserver, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol, mc, screen
    FritzBox FON WLAN 7170, FW 29.04.70 freetz-devel-3366, WDS Basis
    bluez-utils, callmonitor, dnsmasq, dropbear, iptables, knfs, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol
    FritzBox WLAN 3030, FW 21.04.15ds-0.2.9, WDS Repeater
    dropbear, syslogd
    Provider: Telekom Call & Surf 16 MBit/s

  10. #10
    IPPF-Fan Avatar von abraXxl
    Registriert seit
    09.01.2007
    Beiträge
    239
    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"
    Code:
    ...
    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"
    Code:
    ...
    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
    Code:
    ...
    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"
    Code:
    ...
    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:
    Code:
    /*... */
        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)
    Geändert von abraXxl (11.06.2011 um 10:22 Uhr)
    Fragen richtig stellen - Fehler richtig reporten - kein Support per PN - Fragen gehören ins Forum
    Router: 1&1 DSL16000+ VoIP 7390 Freetz-Devel running/7570-82+optware+compcache
    Asus WL500gP(128MB rework) Openwrt Backfire 10.03 usbroot Außenposten 1: Speedport W500V mit wrt500v
    Serieller Terminal und Zockmachine: Commodore 128D Blech jiffydos+1541Ultimate

  11. #11
    IPPF-Urgestein
    Registriert seit
    22.04.2007
    Beiträge
    12.234
    Versuche es mal mit "strace -v ls", dann wird auch genau angezeigt, was der readdir Aufruf liefert.

  12. #12
    IPPF-Fan Avatar von abraXxl
    Registriert seit
    09.01.2007
    Beiträge
    239
    Danke für den Tipp mit "strace -v".

    Mein Testcase sieht jetzt so aus:
    Code:
    # 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":
    Code:
    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":
    Code:
    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.
    Angehängte Dateien Angehängte Dateien
    Fragen richtig stellen - Fehler richtig reporten - kein Support per PN - Fragen gehören ins Forum
    Router: 1&1 DSL16000+ VoIP 7390 Freetz-Devel running/7570-82+optware+compcache
    Asus WL500gP(128MB rework) Openwrt Backfire 10.03 usbroot Außenposten 1: Speedport W500V mit wrt500v
    Serieller Terminal und Zockmachine: Commodore 128D Blech jiffydos+1541Ultimate

  13. #13
    IPPF-Urgestein
    Registriert seit
    22.04.2007
    Beiträge
    12.234
    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?

  14. #14
    IPPF-Fan Avatar von abraXxl
    Registriert seit
    09.01.2007
    Beiträge
    239
    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.
    Fragen richtig stellen - Fehler richtig reporten - kein Support per PN - Fragen gehören ins Forum
    Router: 1&1 DSL16000+ VoIP 7390 Freetz-Devel running/7570-82+optware+compcache
    Asus WL500gP(128MB rework) Openwrt Backfire 10.03 usbroot Außenposten 1: Speedport W500V mit wrt500v
    Serieller Terminal und Zockmachine: Commodore 128D Blech jiffydos+1541Ultimate

  15. #15
    IPPF-Urgestein
    Registriert seit
    22.04.2007
    Beiträge
    12.234
    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?

  16. #16
    IPPF-Fortgeschrittener Avatar von capt_bluebaer
    Registriert seit
    10.05.2007
    Beiträge
    72
    Zitat Zitat von abraXxl Beitrag anzeigen
    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.
    Captain Bluebaer

    FritzBox FON WLAN 7390, 84.04.91freetz-1.2-stable
    callmonitor, dnsmasq, dropbear, iptables, nfsserver, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol, mc, screen
    FritzBox FON WLAN 7170, FW 29.04.70 freetz-devel-3366, WDS Basis
    bluez-utils, callmonitor, dnsmasq, dropbear, iptables, knfs, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol
    FritzBox WLAN 3030, FW 21.04.15ds-0.2.9, WDS Repeater
    dropbear, syslogd
    Provider: Telekom Call & Surf 16 MBit/s

  17. #17
    IPPF-Fan Avatar von abraXxl
    Registriert seit
    09.01.2007
    Beiträge
    239
    Mit den Infos von capt_balubaer scheidet NFS-File-Caching clientseitig (erst seit 2.6.30) im Kernel aus.
    Geändert von abraXxl (05.07.2011 um 12:08 Uhr)
    Fragen richtig stellen - Fehler richtig reporten - kein Support per PN - Fragen gehören ins Forum
    Router: 1&1 DSL16000+ VoIP 7390 Freetz-Devel running/7570-82+optware+compcache
    Asus WL500gP(128MB rework) Openwrt Backfire 10.03 usbroot Außenposten 1: Speedport W500V mit wrt500v
    Serieller Terminal und Zockmachine: Commodore 128D Blech jiffydos+1541Ultimate

  18. #18
    IPPF-Fan Avatar von abraXxl
    Registriert seit
    09.01.2007
    Beiträge
    239
    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.
    Geändert von abraXxl (06.07.2011 um 00:00 Uhr)
    Fragen richtig stellen - Fehler richtig reporten - kein Support per PN - Fragen gehören ins Forum
    Router: 1&1 DSL16000+ VoIP 7390 Freetz-Devel running/7570-82+optware+compcache
    Asus WL500gP(128MB rework) Openwrt Backfire 10.03 usbroot Außenposten 1: Speedport W500V mit wrt500v
    Serieller Terminal und Zockmachine: Commodore 128D Blech jiffydos+1541Ultimate

  19. #19
    Semi-Moderator Avatar von kriegaex
    Registriert seit
    07.11.2006
    Ort
    Großraum Nürnberg
    Beiträge
    2.930
    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:
    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:
    nfs-2.6.17.zip
    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.
    Alexander Kriegisch

    Antworten dauern momentan, ich bin kaum aktiv wegen beruflicher Inanspruchnahme.

    Fritz!Box Fon WLAN 7270 v1, Firmware 54.04.88, freetz-1.2-stable , Kernel 2.6.19.2 (Original AVM), Busybox 1.18.5, USB-Root
    Im Schrank: Fritz!Box Fon WLAN 7170, Speedport W701V, Fritz!Box Fon WLAN 7113
    1&1 DSL 16.000 inkl. VoIP

    Spenden für Freetz
    Wer guten Support will, braucht eine aussagekräftige Signatur! So geht's...
    Bitte keine privaten Support-Anfragen, frühestens nach 36 h ohne Antwort eine Hinweis-Nachricht.


  20. #20
    IPPF-Fortgeschrittener Avatar von capt_bluebaer
    Registriert seit
    10.05.2007
    Beiträge
    72
    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.
    Angehängte Dateien Angehängte Dateien
    Captain Bluebaer

    FritzBox FON WLAN 7390, 84.04.91freetz-1.2-stable
    callmonitor, dnsmasq, dropbear, iptables, nfsserver, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol, mc, screen
    FritzBox FON WLAN 7170, FW 29.04.70 freetz-devel-3366, WDS Basis
    bluez-utils, callmonitor, dnsmasq, dropbear, iptables, knfs, knockd, openvpn, privoxy, stunnel, syslogd, tor, wol
    FritzBox WLAN 3030, FW 21.04.15ds-0.2.9, WDS Repeater
    dropbear, syslogd
    Provider: Telekom Call & Surf 16 MBit/s

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. [Problem] 7390 Fax am Analogen Anschluss, funktioniert nicht
    Von Nappi16 im Forum FRITZ!Box Fon: Telefonie
    Antworten: 7
    Letzter Beitrag: 28.07.2014, 16:21
  2. Fritz!Box 7390 - Festnetztelefonie funktioniert nicht
    Von The69thEye im Forum FRITZ!Box Fon: Telefonie
    Antworten: 19
    Letzter Beitrag: 06.09.2013, 20:02
  3. AVM 7390 - Priorisierung Anwendungen funktioniert nicht
    Von masteroe im Forum FRITZ!Box Fon: Telefonie
    Antworten: 2
    Letzter Beitrag: 31.05.2011, 09:36
  4. Antworten: 9
    Letzter Beitrag: 15.04.2011, 09:16
  5. Telefon funktioniert nicht an der FB 7390
    Von champ1708 im Forum Vodafone VoIP (ehemals Arcor)
    Antworten: 6
    Letzter Beitrag: 09.11.2010, 13:46

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •