[PATCH] ncpfs, kernel 2.4.18

[PATCH] ncpfs, kernel 2.4.18

[David Jander]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]


This fixes a bug with Novell Netware Servers (in my case 3.12) sending error 
messages (and annoying beeps) to the console each time a linux client 
accesses de root directory of a volume. Please comment !
Please send replies with CC to me, since I am not subscribed to lkml.

-- 
David Jander
Protonic Holland.
e-mail: david.jander@protonic.nl

[-- Attachment #2: linux-2.4.18-ncpfix.patch --]
[-- Type: text/plain, Size: 481 bytes --]

--- linux-2.4.18/fs/ncpfs/ncplib_kernel.c	Fri Dec 21 18:41:55 2001
+++ linux-2.4.18-ncpfix/fs/ncpfs/ncplib_kernel.c	Fri Apr  4 13:12:03 2003
@@ -272,6 +272,12 @@
 	__u32 dirent = NCP_FINFO(dir)->dirEntNum;
 	int result;
 
+	DPRINTK("NCPFS : ncp_optain_info for: %s\n",path);
+	if(path==NULL)
+	{
+		printk(KERN_ERR "ncp_obtain_info: Invalid path %s!\n",path);
+		return -EINVAL;
+	}
 	if (target == NULL) {
 		printk(KERN_ERR "ncp_obtain_info: invalid call\n");
 		return -EINVAL;

Re: [PATCH] ncpfs, kernel 2.4.18

[Petr Vandrovec]

On  4 Apr 03 at 13:24, David Jander wrote:

> This fixes a bug with Novell Netware Servers (in my case 3.12) sending error 
> messages (and annoying beeps) to the console each time a linux client 
> accesses de root directory of a volume. Please comment !
> Please send replies with CC to me, since I am not subscribed to lkml.

What they say? It is completely legal to use NULL path in ncp_obtain_info,
and in reality ncp_obtain_mtime() in fs/ncpfs/dir.c uses NULL path 
explicitly (and it also checks for 'ncp_is_server_root(inode)', at least
in 2.5.66 and 2.4.19). See ncp_add_handle_path, it contains code which
converts NULL path to no path at all.

Do not you just have loaded some misguided antivirus software on your server? 
ncpfs uses inode based addressing scheme, where files are accessed by their 
numbers instead of name. Only thing which accesses files by name are 
validating functions, for converting name to number, and unlink (because of 
4.x servers crash when unlink by inode is invoked on NFS namespace).
                                                        Petr Vandrovec
                                                        

Re: [PATCH] ncpfs, kernel 2.4.18

[David Jander]

On Friday 04 April 2003 13:45, Petr Vandrovec wrote:
> What they say? It is completely legal to use NULL path in ncp_obtain_info,
> and in reality ncp_obtain_mtime() in fs/ncpfs/dir.c uses NULL path
> explicitly (and it also checks for 'ncp_is_server_root(inode)', at least
> in 2.5.66 and 2.4.19). See ncp_add_handle_path, it contains code which
> converts NULL path to no path at all.
>
> Do not you just have loaded some misguided antivirus software on your
> server? ncpfs uses inode based addressing scheme, where files are accessed
> by their numbers instead of name. Only thing which accesses files by name
> are validating functions, for converting name to number, and unlink
> (because of 4.x servers crash when unlink by inode is invoked on NFS
> namespace). Petr Vandrovec

I don't use any anti-virus software, but from what you say, I may conclude the 
following:
When listing a directory with "ls", the function ncp_obtain_info() is called 
once for each entry in that directory, plus one time for the directory itself 
and (presumably) one time for the directory therunder (".." ?).
If you do this for a volume-root, you are trying to get the Original 
Name-Space of a directory under the volume, which makes the Netware-3.12 
server bark.
The error I am getting on the server goes like this: 
"GetOriginalNameSpace could not find the originating name space. DOS name was 
assumed. Use vrepair to fix this!"
If NULL paths are legal, then the problem lies elsewere (of course it does !).
If you could give me some pointers on where to look, I'll try to find out how 
to make ncpfs not call ncp_obtain_info() for the directory under a volume. 
Putting the check directly into ncp_obtain_info() doesn't seem a good place 
to me....

BTW, I am also having another problem with listing the directory contents of 
the directory where the Novell Server was mounted. I don't know if I will 
have time to get to the ground of this though, since it looks like a problem 
with the driver not handling i-nodes correctly with newer kernels. I get this 
behaviour:
-------------- CUT HERE ---------------------
linux:/mnt/Novell # ls -l
ls: .: Stale NFS file handle
linux:/mnt/Novell # cd ..
linux:/mnt # ls -l Novell/
ls: Novell/.: Stale NFS file handle
total 3
drwxr-xr-x    7 root     root          143 Feb 19 20:43 ..
drwxrwxr-x    1 david    users         512 Dec 31  1985 cdroms
drwxrwxr-x    1 david    users         512 Dec 31  1985 dataflex
drwxrwxr-x    1 david    users         512 Dec 31  1985 engineer
drwxrwxr-x    1 david    users         512 Dec 31  1985 programs
drwxrwxr-x    1 david    users         512 Dec 31  1985 sys
drwxrwxr-x    1 david    users         512 Dec 31  1985 sys1
linux:/mnt #
-------------- CUT HERE -----------------------

Thanks for the reaction...

-- 
David Jander

Re: [PATCH] ncpfs, kernel 2.4.18

[Petr Vandrovec]

On  4 Apr 03 at 14:33, David Jander wrote:

> When listing a directory with "ls", the function ncp_obtain_info() is called 
> once for each entry in that directory, plus one time for the directory itself 
> and (presumably) one time for the directory therunder (".." ?).
> If you do this for a volume-root, you are trying to get the Original 
> Name-Space of a directory under the volume, which makes the Netware-3.12 
> server bark.
> The error I am getting on the server goes like this: 
> "GetOriginalNameSpace could not find the originating name space. DOS name was 
> assumed. Use vrepair to fix this!"

Did you tried vrepair? ;-) What namespaces do you use? OS2+DOS? In that case,
can you (after you upgrade/downgrade kernel, see below) try adding -o noos2
option to the ncpmount command line, and recheck whether problem persist or
not? 

> BTW, I am also having another problem with listing the directory contents of 
> the directory where the Novell Server was mounted. I don't know if I will 
> have time to get to the ground of this though, since it looks like a problem 
> with the driver not handling i-nodes correctly with newer kernels. I get this 
> behaviour:
> -------------- CUT HERE ---------------------
> linux:/mnt/Novell # ls -l
> ls: .: Stale NFS file handle

Are you sure that you are using stock 2.4.18 kernel? This bug was introduced
by RedHat's updates, and then it found its way to 2.4.19. It should be
fixed in 2.4.20. And maybe that it will also fix error message you are
seeing on server...

There is one suspicious thing - ncp_lookup_volume lookups directory entry
always in DOS namespace, although other namespace might be used after
that. It does not cause any problems on NW4/NW5/NW6, but maybe your
NW3.12 is too picky about that. So if simple upgrading your kernel to 2.4.20
will not help, try patch below. But it needs testing with all NetWare
versions, as documentation talks about magic value 'Jn' in 4th/5th byte
of request. If 'Jn' is supported even on NW3.11, it would be better
to use bytes 22, 0, server->name_space[volnum], 'J', 'n' in the request, 
as we do not want case sensitive volume names even under NFS namespace.
And from documentation it is not clear whether dirEntNum is returned when
there is no Jn signature in request.
						Petr Vandrovec
						vandrove@vc.cvut.cz



--- linux/fs/ncpfs/ncplib_kernel.c.orig	2003-03-31 18:58:30.000000000 +0200
+++ linux/fs/ncpfs/ncplib_kernel.c	2003-04-04 15:16:20.000000000 +0200
@@ -568,12 +568,17 @@
 
 	DPRINTK("ncp_lookup_volume: looking up vol %s\n", volname);
 
+	server->name_space[volnum] = ncp_get_known_namespace(server, volnum);
+
+	DPRINTK("lookup_vol: namespace[%d] = %d\n",
+		volnum, server->name_space[volnum]);
+
 	ncp_init_request(server);
 	ncp_add_byte(server, 22);	/* Subfunction: Generate dir handle */
-	ncp_add_byte(server, 0);	/* DOS namespace */
-	ncp_add_byte(server, 0);	/* reserved */
-	ncp_add_byte(server, 0);	/* reserved */
-	ncp_add_byte(server, 0);	/* reserved */
+	ncp_add_byte(server, server->name_space[volnum]);	/* Src & dst namespace */
+	ncp_add_byte(server, 0);	/* reserved or dst namespace if 'Jn' is below */
+	ncp_add_byte(server, 0);	/* reserved or 'J' (or 'n'?) */
+	ncp_add_byte(server, 0);	/* reserved or 'n' (or 'J'?) */
 
 	ncp_add_byte(server, 0);	/* faked volume number */
 	ncp_add_dword(server, 0);	/* faked dir_base */
@@ -586,15 +591,11 @@
 		return result;
 	}
 	memset(target, 0, sizeof(*target));
-	target->DosDirNum = target->dirEntNum = ncp_reply_dword(server, 4);
+	target->dirEntNum = ncp_reply_dword(server, 0);
+	target->DosDirNum = ncp_reply_dword(server, 4);
 	target->volNumber = volnum = ncp_reply_byte(server, 8);
 	ncp_unlock_server(server);
 
-	server->name_space[volnum] = ncp_get_known_namespace(server, volnum);
-
-	DPRINTK("lookup_vol: namespace[%d] = %d\n",
-		volnum, server->name_space[volnum]);
-
 	target->nameLen = strlen(volname);
 	memcpy(target->entryName, volname, target->nameLen+1);
 	target->attributes = aDIR;