headers
William Law | 8 Feb 2006 22:34
Picon

accessing domain or standard based DFS with CIFS 1.40 + mount.cifs 1.8 + 2.6.15.3 kernel

Hi,

I'm using RHEL4 with the latest stable kernel as of yesterday, 2.6.15.3
with the new CIFS code(s) because I couldn't get this to work with the
older versions, either.

We have a domain based MS-DFS root and a stand alone MS-DFS duplicate of
the same root.  I can successfully mount the share if I point to the
stand alone root or the shares that are used for the domain based root,
but not the domain root itself.  I'm using the syntax mount -t cifs
//servername/sharename /mnt/sharename -o user=username.

It appears that domain based dfs is not supported, and that is fine -
but I did want to confirm this.  Anyway, the real problem is that with
any of the roots, I can not get past the initial mount point.  Changing
to another directory is successful, but when I do ls, I just get the
same listing as the mounted root - I can't get past the initial level!

A separate issue is that I haven't been able to test or try to use the
Kerberos support.  I've tried using mount -t cifs //servername/sharename
/mnt/sharename -o sec=krb5 but I just get the help.  Yeah, I did compile
the experimental options into  the kernel module.  I'm hoping that they
syntax is wrong, but I honestly don't have a clue.  I'm attaching a
separate message that I have posted to samba and cifs-clients about
smbclient, where I am having similar but not exactly the same problems.
We'd really like to be able to mount these shares from our linux nodes.

Any help would be greatly appreciated!

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vijaya Bhaskar V | 9 Feb 2006 06:28
Picon

Linux CIFS client

Hi All,
I have couple of questions regarding the Linux CIFS client
Where can i get the Linux CIFS client source code?
Also please let me know is it portable to other Operating systems?
 
Thanks,
Bhasvij
 
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Permalink | Reply | 1 comment |
headers
Steven French | 9 Feb 2006 06:59
Picon
Favicon

Re: Linux CIFS client

The most up to date version of the Linux cifs client is on kernel.org (downloadable via git from linux-2.6.git tree). Currently cifs in mainline 2.6.16-rc2 Linux kernel matches the version in the development tree.

It has been backported to earlier 2.6 kernels (and there is an older version for 2.4). It has also been ported to user space as a library although I currently don't have a version of that on the download site.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Vijaya Bhaskar V <bhasvij <at> gmail.com>


          Vijaya Bhaskar V <bhasvij <at> gmail.com>
          Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com <at> lists.samba.org

          02/08/2006 11:28 PM

To
linux-cifs-client <at> lists.samba.org

cc

Subject
[linux-cifs-client] Linux CIFS client

Hi All,
I have couple of questions regarding the Linux CIFS client
Where can i get the Linux CIFS client source code?
Also please let me know is it portable to other Operating systems?

Thanks,
Bhasvij
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Permalink | Reply | 0 comments |
headers
Steven Scholz | 13 Feb 2006 14:46
Picon
Favicon

Re: 1.40 cifs tar.gz on project download

Steven,

> I put a 1.40 tar.gz for the cifs kernel code on
> http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40.tar.gz

It looks like cifs_writepages() in fs/cifs/file.c in no longer wrapped
in CONFIG_CIFS_EXPERIMENTAL in your recent 1.40 releases.

This is bad.

On embedded systems with no "Support for paging of anonymous memory
(swap)" the build (and insmod) will fail with

*** Warning: "pagevec_lookup_tag" [fs/cifs/cifs.ko] undefined!
*** Warning: "__pagevec_release" [fs/cifs/cifs.ko] undefined!

In earlier releases (1.39) cifs_writepages() was wrapped in
CONFIG_CIFS_EXPERIMENTAL. Thus I could build cifs without experimental
stuff, i.e. without calls of pagevec functions.

As I wrote in a previous mail IMHO functions in cifs that need swap
support should be wrapped in #ifdef's, i.e. compiled in conditionally.
So either use CONFIG_CIFS_EXPERIMENTAL or (which I think is better)
CONFIG_SWAP directly.

Would you like patch?

--
Steven Scholz
Permalink | Reply | 4 comments |
headers
Steven Scholz | 13 Feb 2006 15:37
Picon
Favicon

Re: 1.40 cifs tar.gz on project download

Steven,

> On embedded systems with no "Support for paging of anonymous memory
> (swap)" the build (and insmod) will fail with
> 
> *** Warning: "pagevec_lookup_tag" [fs/cifs/cifs.ko] undefined!
> *** Warning: "__pagevec_release" [fs/cifs/cifs.ko] undefined!

BTW:
Excuse my ignorance. I have no deep inside neither into fs nor mm stuff.
But why do we need pagevec_lookup_tag() at all?
No other fs driver needs it. (At least a "grep -r" didn't show it.)
Other fs drivers work without swap support.
Maybe it's possible to implement writepages() without
pagevec_lookup_tag() ...
But again: I have no deeper understanding of the fs internas.

--
Steven Scholz
Permalink | Reply | 3 comments |
headers
Steven Scholz | 13 Feb 2006 15:46
Picon
Favicon

Re: 1.40 cifs tar.gz on project download

Steven French wrote:
> 
> This is probably closer to what you want:
>       http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40a-2.6.13.tar.gz
> There are two minor, but important fixes that are not in the various 1.40a
> tar.gz's (that are in the cifs development tree, and hopefully mainline
> soon as soon as Linus gets back)
> 
> The one line fix removing the set which can go off the end of the stack in
> transport.c (iov[1].len = 0)  and the set of the default wsize to 52K (for
> servers which support large write X) are not in the various
> cifs1.40a.tar.gz

Did you mean this one?

--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
 <at>  <at>  -498,7 +498,6  <at>  <at>  SendReceive2(const unsigned int xid, str
else
	*pRespBufType = CIFS_SMALL_BUFFER;
	iov[0].iov_len = receive_len + 4;
-	iov[1].iov_len = 0;

	dump_smb(midQ->resp_buf, 80);
	/* convert the length into a more usable form */

Not sure if I understood correctly. Do we need the line "iov[1].iov_len
= 0;". Or do we have to remove that line?

--
Steven Scholz
Permalink | Reply | 1 comment |
headers
Dave Kleikamp | 13 Feb 2006 15:56
Picon
Favicon

Re: 1.40 cifs tar.gz on project download

On Mon, 2006-02-13 at 15:37 +0100, Steven Scholz wrote:
> Steven,
> 
> > On embedded systems with no "Support for paging of anonymous memory
> > (swap)" the build (and insmod) will fail with
> > 
> > *** Warning: "pagevec_lookup_tag" [fs/cifs/cifs.ko] undefined!
> > *** Warning: "__pagevec_release" [fs/cifs/cifs.ko] undefined!
> 
> BTW:
> Excuse my ignorance. I have no deep inside neither into fs nor mm stuff.
> But why do we need pagevec_lookup_tag() at all?
For better performance, cifs is sending multiple page cache pages to the
server in a single request.
> No other fs driver needs it. (At least a "grep -r" didn't show it.)
cifs is leading edge technology.  :-)  Actually, reiser4 uses these too,
but it isn't in the mainline kernel yet.
> Other fs drivers work without swap support.
> Maybe it's possible to implement writepages() without
> pagevec_lookup_tag() ...
It may be possible, but not optimal.  This isn't an issue in the
mainline kernel, but only when building the latest cifs code on older
kernels.
> But again: I have no deeper understanding of the fs internas.
--

-- 
David Kleikamp
IBM Linux Technology Center
Permalink | Reply | 2 comments |
headers
Steven Scholz | 13 Feb 2006 16:01
Picon
Favicon

Re: 1.40 cifs tar.gz on project download

Dave,

>> But why do we need pagevec_lookup_tag() at all?
> For better performance, cifs is sending multiple page cache pages to the
> server in a single request.
>> No other fs driver needs it. (At least a "grep -r" didn't show it.)
> cifs is leading edge technology.  :-)  Actually, reiser4 uses these too,
> but it isn't in the mainline kernel yet.

Ah. Ok. Understood.

>> Other fs drivers work without swap support.
>> Maybe it's possible to implement writepages() without
>> pagevec_lookup_tag() ...
> It may be possible, but not optimal.  This isn't an issue in the
> mainline kernel, but only when building the latest cifs code on older
> kernels.

Ok. So if I remove cifs_writepages() (cause I have no swap) then
cifs_writepage() will be used instead which is less efficient but should
work well. Right?

--
Steven Scholz
Permalink | Reply | 1 comment |
headers
Steven French | 13 Feb 2006 17:23
Picon
Favicon

Re: Plaintext password exchange with the kernel cifs module

> decided to go only the plaintext password way. I tested my server with the
> smb kernel module an it worked (at least the password part). Now I wanted
> to test the server with the cifs kernel module and I observed, that the
> server receives always a somewhat encrypted password (I think it gets
> encrypted with SMBencrypt(), because I receive a 24 byte value. The
> server correctly sends 0x01 as security mode in the Negotiate message).
> I saw that you did a lot of work for the cifs module so I decided to
> ask you directly if it is intended that the module sends an encrypted
> pwd even if the server requested a plaintext pwd.

It would be very easy to support.

I decided to turn off plain text passwords (and lanman passwords) as they are so insecure and users might not realize when a rogue server would be "downgraded" to force plain text from the client (or very weak passwords). I don't know if that is the right decision - I am second guessing that since lanman hash is necessary for finish up of support for os/2 and windows 95 and there are some valid cases in which the physical network is secure and plain text passwords to the server might be ok. Perhaps the best alternative is add a

CONFIG_WEAK_PASSWORDS

in make menuconfig, and put the lanman and plain text password support in that ifdef (mostly in fs/cifs/connect.c, although I have been toying with a new ntlmssp.c which might contain a session setup rewrite - as session setup for cifs is verbose and could use cleaning up as well as the needed fixes for ntlmv2). In addition if "CONFIG_WEAK_PASSWORDS" is set, cifs could export a /proc/fs/cifs/AllowWeakPasswords which would default to one (perhaps set to zero would mean NTLMv2 or Kerberos only, since NTLMv2 is close to complete although Kerberos is not, set to one would indicate allow ntlm or ntlmv2 or kerberos, two would indicate allow lanman or ntlmv or ntlmv2 or kerveros, 3 would be allow plain text etc.)

Thoughts?


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Permalink | Reply | 0 comments |
headers
Steven French | 13 Feb 2006 17:27
Picon
Favicon

Re: 1.40 cifs tar.gz on project download

Yes - You have to remove that line - there is a path in which iov array is only length one so setting iov[1] would be bad.

Note that cifs_writepages is easily removed which is harmless for older kernels and has no functional difference (other than the drop from 52K to 4K writes can slow sequential writes down by perhaps 5-40% at least to lightly loaded servers; the actual difference depends on lots of factors including the network speed)




Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Steven Scholz <steven.scholz <at> imc-berlin.de>


          Steven Scholz <steven.scholz <at> imc-berlin.de>

          02/13/2006 08:46 AM

To
Steven French/Austin/IBM <at> IBMUS

cc
linux-cifs-client <at> lists.samba.org

Subject
Re: [linux-cifs-client] 1.40 cifs tar.gz on project download

Steven French wrote:
>
> This is probably closer to what you want:
>       http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40a-2.6.13.tar.gz
> There are two minor, but important fixes that are not in the various 1.40a
> tar.gz's (that are in the cifs development tree, and hopefully mainline
> soon as soon as Linus gets back)
>
> The one line fix removing the set which can go off the end of the stack in
> transport.c (iov[1].len = 0)  and the set of the default wsize to 52K (for
> servers which support large write X) are not in the various
> cifs1.40a.tar.gz

Did you mean this one?

--- a/fs/cifs/transport.c
+++ b/fs/cifs/transport.c
<at> <at> -498,7 +498,6 <at> <at> SendReceive2(const unsigned int xid, str
else
*pRespBufType = CIFS_SMALL_BUFFER;
iov[0].iov_len = receive_len + 4;
- iov[1].iov_len = 0;

dump_smb(midQ->resp_buf, 80);
/* convert the length into a more usable form */

Not sure if I understood correctly. Do we need the line "iov[1].iov_len
= 0;". Or do we have to remove that line?

--
Steven Scholz

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
https://lists.samba.org/mailman/listinfo/linux-cifs-client
Permalink | Reply | 0 comments |

Gmane