Samba Wartezeit bei Zugriff

max93

Well-Known Member
Hallo!

Seit einiger Zeit habe ich folgenden Effekt und so langsam nervt mich der: Samba (3.0.23d,1) ist auf einem FreeBSD 6.1(-p11) Server installiert und funktioniert eigentlich auch ordentlich (mit einer kleinen Einschränkung). Am Windows PC habe ich eine Freigabe vom FreeBSD Server als Netzlaufwerk gemountet und eigentlich habe ich den ganzen Tag den Explorer offen (natürlich minimiert, damit er nicht im Weg ist). Wenn ich den Explorer aber in den Vordergrund hole, dann werden im linken Ordnerbaum alle Laufwerke bis exklusive dem Netzlaufwerk sofort angezeigt. Nach ~ 2,5 Sekunden erscheint dann erst die Zeile mit dem Netzlaufwerk und der ganze Rest, der noch unterhalb kommt. Danach kann ich den Explorer minimieren und wieder hervorholen ohne Wartezeit. Wenn er aber ein paar Minuten minimiert war, dann passiert es wieder. Dieses Verhalten habe ich auch von einem 2. Windows PC aus.

Dieses Verhalten habe ich erst seitdem der Server komplett umgezogen ist. Vorher war das ein P3 mit gemächlichen 500 MHz und 4 IDE Platten unter FreeBSD 5.4 mit einem etwas älteren Samba 3. Die neue Hardware ist ein P4 mit 2400 MHz und 2 SATA II Platten an einem 3ware RAID Controller. Den Umzug habe ich gleich genutzt FreeBSD auf 6.1 zu aktualisieren und für Samba war zu dem Zeitpunkt um 1 Nummer hinter dem zweiten Punkt aktueller (also von 3.0.20 auf 3.0.21 oder so). Seit diesem Tag habe ich dieses komische Verhalten.

Es mag sein, dass 2,5 Sekunden nicht viel sind und man könnte mir vorwerfen, dass ich kleinlich bin, aber seltsam ist es allemal. Wenn jetzt von mir jemand einen Samba Server bekommt, der das gleiche Verhalten an den Tag legt, dann wird er mich Fragen, ob FreeBSD schon dafür geeignet ist...

Ich habe jetzt mal mit tcpdump mitgeschnitten was so passiert, wenn ich den Explorer in den Vordergrund hole. Interessant ist die Wartezeit zwischen 18:41:14.632613 und 18:41:16.911673 und die Tatsache, dass die 3 UDP Broadcasts nicht beantwortet werden (Client hat die IP 192.168.77.12, Server die .10, .1 ist für beide der Default Gateway - ein Router mit pfSense):

Code:
listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
18:41:14.507262 arp who-has 192.168.77.1 tell 192.168.77.12
18:41:14.516998 IP 192.168.77.12 > 192.168.77.10: ICMP echo request, id 768, seq 4352, length 40
18:41:14.517017 IP 192.168.77.10 > 192.168.77.12: ICMP echo reply, id 768, seq 4352, length 40
18:41:14.517248 IP 192.168.77.12.1405 > 192.168.77.10.445: S 2241608081:2241608081(0) win 65535 <mss 1460,nop,nop,sackOK>
18:41:14.517271 IP 192.168.77.10.445 > 192.168.77.12.1405: S 3647356387:3647356387(0) ack 2241608082 win 65535 <mss 1460,sackOK,eol>
18:41:14.517372 IP 192.168.77.12.1405 > 192.168.77.10.445: . ack 1 win 65535
18:41:14.518000 IP 192.168.77.12.1405 > 192.168.77.10.445: P 1:138(137) ack 1 win 65535
18:41:14.519695 IP 192.168.77.10.445 > 192.168.77.12.1405: P 1:108(107) ack 138 win 65535
18:41:14.522495 IP 192.168.77.12 > 192.168.77.10: ICMP echo request, id 768, seq 4608, length 40
18:41:14.522510 IP 192.168.77.10 > 192.168.77.12: ICMP echo reply, id 768, seq 4608, length 40
18:41:14.628935 IP 192.168.77.12.1405 > 192.168.77.10.445: P 138:384(246) ack 108 win 65428
18:41:14.631579 IP 192.168.77.10.445 > 192.168.77.12.1405: P 108:236(128) ack 384 win 65535
18:41:14.631934 IP 192.168.77.12.1405 > 192.168.77.10.445: P 384:512(128) ack 236 win 65300
18:41:14.632613 IP 192.168.77.10.445 > 192.168.77.12.1405: P 236:500(264) ack 512 win 65535
18:41:14.665540 IP 192.168.77.12.137 > 192.168.77.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
18:41:14.843689 IP 192.168.77.12.1405 > 192.168.77.10.445: . ack 500 win 65036
18:41:15.406246 IP 192.168.77.12.137 > 192.168.77.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
18:41:16.156323 IP 192.168.77.12.137 > 192.168.77.255.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
18:41:16.907400 IP 192.168.77.12.1405 > 192.168.77.10.445: P 512:800(288) ack 500 win 65036
18:41:16.911673 IP 192.168.77.10.445 > 192.168.77.12.1405: P 500:634(134) ack 800 win 65535
18:41:16.912022 IP 192.168.77.12.1405 > 192.168.77.10.445: P 800:932(132) ack 634 win 64902
18:41:16.912147 IP 192.168.77.10.445 > 192.168.77.12.1405: P 634:738(104) ack 932 win 65535
18:41:16.912396 IP 192.168.77.12.1405 > 192.168.77.10.445: P 932:1064(132) ack 738 win 64798

Die smb.conf ohne Kommentare:

Code:
[global]
   workgroup = GAMBLERTRUPP
   server string = TYAN
   security = share
   load printers = no
   log file = /var/log/samba/log.%m
   max log size = 256
   socket address = 192.168.77.10
   socket options = IPTOS_LOWDELAY TCP_NODELAY
   interfaces = 192.168.77.10
   bind interfaces only = yes
   local master = yes
   os level = 33
   domain master = no
   preferred master = yes
   dns proxy = no
   display charset = ISO8859-15
   unix charset = ISO8859-15
   dos charset = CP1252
[homes]
   comment = TYAN-HOME
   create mask = 0644
   directory mask = 0755
   browseable = no
   writable = yes
[daten]
   comment = Tyan-Daten
   path = /mnt/data/smb
   read only = yes
   guest ok = yes

uname -a:
FreeBSD tyan.gamblers.local 6.1-RELEASE-p11 FreeBSD 6.1-RELEASE-p11 #0: Tue Dec 12 20:29:49 CET 2006 root@tyan.gamblers.local:/usr/obj/usr/src/sys/FILESERVER i386

An den TCP Parametern von FreeBSD habe ich noch nicht herumgeschraubt (hier vermute ich das Problem auch gar nicht). Größere Dateitransfers vom und zum Server laufen auch per SMB ganz normal (also etwa 75% von den 100 Mbit, obwohl der Windows PC eine Realtek Karte hat). Auf dem FreeBSD Server läuft kein Paketfilter und er ist zu den Zeitpunkten jeweils gelangweilt. Die Platten werden nicht in den Idle Modus versetzt, daran kann es auch nicht liegen.

Falls noch irgendwer eine Idee hat, bitte her damit und fragt nach Infos, bis der Dreck hergeht. Ich hoffe ja, dass ich nur eine Option in der smb.conf flasch/gar nicht gesetzt habe...

Danke & Ciao.
Markus Mann
];-)
 
Dein tcpdump stimmt mit den Angaben unter:
http://support.microsoft.com/kb/314053
überein. Es werden vergeblich 3 NetBIOS-Broadcasts (NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST) (BcastNameQueryCount) ausgesandt. Das Timeout für die NetBIOS-Broadcasts (BcastQueryTimeout) beträgt 750 Millisekunden.

Kontrolliere mit nbtstat die Namensauflösung per NetBIOS-Broadcasts (Mehr Infos zu nbtstat findest Du in der Volltextsuche der Windows Hilfe).
 
Kontrolliere bitte Deine smb.conf mit testparm:
http://wiki.bsdforen.de/index.php/Samba_PDC#Kontrolle

Ich sehe, dass bei Dir der NetBIOS-Name für den Samba-Rechner fehlt (netbios name= mySambaServer)! Siehe auch:
http://wiki.bsdforen.de/index.php/Samba_PDC#smb.conf

nbtstat -c auf dem Windows-Rechner sollte Dir den NetBIOS-Name sowie die IP-Adresse des Samba-Rechners auflisten. Die Sekunden werden von 600 auf 0 heruntergezählt (Alle 10 Minuten veröffentlichen alle Windows-Rechner per NetBIOS-Broadcast ihr NetBIOS-Name sowie IP-Adresse).
 
Hallo!

Kontrolliere bitte Deine smb.conf mit testparm

Das findet keine Fehler (leider, wäre aber zu einfach gewesen):

Code:
root@tyan:~# testparm
Load smb config files from /usr/local/etc/smb.conf
Processing section "[daten]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

[global]
        dos charset = CP1252
        unix charset = ISO8859-15
        display charset = ISO8859-15
        workgroup = GAMBLERTRUPP
        server string = TYAN
        interfaces = em0
        bind interfaces only = Yes
        security = SHARE
        log file = /var/log/samba/log.%m
        max log size = 256
        socket options = IPTOS_LOWDELAY TCP_NODELAY
        load printers = No
        os level = 33
        preferred master = Yes
        domain master = Yes
        socket address = 192.168.77.10

[daten]
        comment = Tyan Daten
        (...)

Ich sehe, dass bei Dir der NetBIOS-Name für den Samba-Rechner fehlt (netbios name= mySambaServer)!
Das ist mir gestern Abend beim Weitersuchen auch aufgefallen und das habe ich auch nachgeholt. Interessanterweise taucht der Parameter oben in der "global"-Sektion von testparm nicht mehr auf, als ob er wieder rausfallen würde (weil der Netbios Name mit dem DNS-Namen übereinstimmt bzw. mit server name gesetzt wurde?).

Jedenfalls weiß ich jetzt in welche Richtung ich forschen muss: Ich muss meinen Server dazu bringen Netbios Anfragen auch zu beantworten. Er scheint sich überhaupt nur für das Subnetz 192.168.77.10 (also die IP des Servers alleine) verantwortlich zu fühlen:

Code:
root@tyan:~# tail -6 /var/log/samba/log.nmbd
[2007/01/01 15:16:08, 0] nmbd/nmbd_become_lmb.c:become_local_master_stage2(396)
  *****

  Samba name server TYAN is now a local master browser for workgroup GAMBLERTRUPP on subnet 192.168.77.10

  *****

nbtstat -c auf dem Windows-Rechner sollte Dir den NetBIOS-Name sowie die IP-Adresse des Samba-Rechners auflisten.
Dort wird nur die IP des Clients selbst angezeigt, der Server ist hier nicht vertreten (außer 10 Minuten lang, wenn der Name eben zuvor (per Netbios over TCP vermutlich?) aufgelöst wurde). Das scheint damit zusammen zu hängen, dass er glaubt in einem /32 Netz zu stecken bzw. sich für Broadcasts an .255 nicht zuständig fühlt und selbst keine Broadcasts schickt.

Beim Binden an eine einzelne IP (wegen Jails) mache ich wohl einen Fehler und muss mich in diese Richtung nochmal schlau machen oder ich habe wieder einen Dienst gefunden, der sich nicht vernünftig an eine einzelne IP binden lässt.

(15 Minuten später...):

Wenn ich die Parameter weglasse, die die Dienste nur an eine IP-Adresse binden, dann klappt das mit dem regelmäßigen Announcen und die Denkpause fällt weg. *heul* Ich will doch Samba nur an eine IP binden, ich habe ja gar nichts gegen die Broadcasts. Nützt es was, wenn man das als Bug reported oder wird man mich beim Samba Projekt gar nicht richtig verstehen?

Jedenfalls Danke, Ciao & ein gutes neues Jahr!
Markus Mann
];-)
 
weil der Netbios Name mit dem DNS-Namen übereinstimmt bzw. mit server name gesetzt wurde?).
Gemäss man smb.conf:
http://www.freebsd.org/cgi/man.cgi?...ath=FreeBSD+6.1-RELEASE+and+Ports&format=html
greift Samba bei nicht gesetzter "NetBIOS name="-Option auf den DNS-Name zurück.

Beim Binden an eine einzelne IP (wegen Jails) mache ich wohl einen Fehler
Samba steckten schon andere in eine Jail:
http://www.bsdforen.de/showthread.php?t=3485

Ich an deiner Stelle würde die Zeilen:
Code:
interfaces = em0
bind interfaces only = Yes
socket address = 192.168.77.10
socket options = IPTOS_LOWDELAY TCP_NODELAY

durch die Zeilen:
Code:
interfaces = 192.168.77.10/255.255.255.0
bind interfaces only = Yes
ersetzen. Begründung: man smb.conf und dieses Mail vom Samba-Gründer:
http://lists.samba.org/archive/samba/1997-November/004810.html
 
Hallo!

Gemäss man smb.conf:
http://www.freebsd.org/cgi/man.cgi?...ath=FreeBSD+6.1-RELEASE+and+Ports&format=html
greift Samba bei nicht gesetzter "NetBIOS name="-Option auf den DNS-Name zurück.
Erklärt aber noch nicht warum er bei testparm rausfällt, obwohl er gesetzt ist...

Samba steckten schon andere in eine Jail:
Will ich ja gar nicht. Ich möchte Samba "nur" an 1 IP binden und trotzdem das "übliche" Verhalten. Außerdem hat mich jetzt ein wenig der Ehrgeiz gepackt und möchte wissen, was diese Unschönheit auslöst.

durch die Zeilen:
Code:
interfaces = 192.168.77.10/255.255.255.0
bind interfaces only = Yes
ersetzen.
Danke, das versuche ich noch.

Übrigens hatte ich gestern Abend das Problem immer noch, obwohl ich socket, socket options, interfaces und bind interfaces only einfach mal ganz auskommentiert hatte (aber da habe ich gerade nicht mitgeschnitten und bin dann ins Bett gegangen). Das werde ich Heute nochmal genauer untersuchen. Ich habe aber nach dieser Konfigurationsänderung NBT Broadcasts gesehen, nbtstat -c am Client hat aber trotzdem die Adresse nicht gewusst.

Wenn es mich weiter nervt, werde ich nochmal testweise auf einer anderen Platte ein frisches System aufsetzen und nachschauen, ob das auch dieses Verhalten zeigt (ohne Alias IP-Adressen, vielleicht liegt es ja auch daran).

Vielen Dank für deine Hilfe!

Ciao.
Markus Mann
];-)
 
Solved

Hallo!

Nach dem letzten Update auf samba-3.0.25,1 ist das Problem plötzlich weg. Ganz ohne Konfigurationsänderung. Einfach weg.

Ciao.
Markus Mann
];-)
 
Back
Top