netdev - Re: e1000 driver and samba

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 19 Sep 2007 10:53:01 -0400
From:	"L F" <lfabio.linux@...il.com>
To:	"Tantilov, Emil S" <emil.s.tantilov@...el.com>
Cc:	"Florian Weimer" <fweimer@....de>,
	"Urs Thuermann" <urs@...ogud.escape.de>,
	"Bill Fink" <billfink@...dspring.com>,
	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	"James Chapman" <jchapman@...alix.com>, netdev@...r.kernel.org
Subject: Re: e1000 driver and samba

Well,
the issue seems to have gone away as of this morning, but I am
somewhat unsure as to why.
Placement of some things were modified so as to allow shorter cables.
Now there are 3' CAT6 cables everywhere except for the 15' cable
between the two switches. All the cables are new, high quality
'tested' cables from a company nearby.
The server is now running 2.6.22.6 with the 7.6.5 e1000 driver from
intel.com and samba 3.0.26-1 ... and it seems to work. Samba will not
disconnect, even with all 8 clients running unreasonable read/write
loads and CRC and MD5 checksums of the transferred files all match.
The issue therefore seems to have gone away, but the reason why still
escapes me. I cannot believe that CAT5 cables under 10' in length were
causing it, because if that were the case
1) it would've shown itself, I presume, from the beginning
2) I could name dozens of different locations which would be having
the same problems
Samba 3.0.25 was definitely part of the problem and I sent a nice
nastygram to the debian maintainers, because -testing is not
-unstable, last I checked.
As to samba having any sort of data integrity capability, to the best
of my knowledge that has never been the case.
To answer further questions: I checked for file integrity with
CRC/CRC32/MD5 checksum utilities. They used to fail fairly
consistently, they have been fine all this morning.
Here is my samba config, for reference, comments etc. stripped.

[global]
   workgroup = WORKGROUP
   server string = %h server
   wins support = yes
   dns proxy = yes
   name resolve order = host wins bcast
   log level = 1
   max log size = 1000
   syslog = 0
   panic action = /usr/share/samba/panic-action %d
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   invalid users = root
   passwd program = /usr/bin/passwd %u
   passwd chat = *Enter\snew\sUNIX\spassword:* %n\n
*Retype\snew\sUNIX\spassword:* %n\n .
   socket options = TCP_NODELAY IPTOS_LOWDELAY
   domain master = yes
[backups]
   comment = Backup Share
   path = /var/archive/backups
   browseable = yes
   writeable = no
   guest ok = no
   write list = samba
   force user = samba
[downloads]
   comment = Downloads Share
   path = /var/archive/downloads
   browseable = yes
   writeable = no
   guest ok = no
   read list = samba
   write list = samba
   force user = samba

There is nothing there that I would deem unusual. Since the transition
to 2.6 kernels I have been omitting the buffer statements in the
socket options.
I have one further question: what should I be doing with the TSO and
flow control? As of now, TSO is on but flow control is off.
I'd like to thank everyone who helped and I'll be trying to see if the
realtek integrated NIC works next.

Luigi Fabio
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html