Novell redirector hates IOCTL_REDIR_QUERY_PATH_EX

NTFSD
1

Hi all,

I’m trying to figure out why the Novell redirector (NCfilter.sys)packaged in the Novell Client 2 SP1 for Windows does not want to respond to a IOCTL_REDIR_QUERY_PATH or IOCTL_REDIR_QUERY_PATH_EX given a pathname such as this:

\TWENC-NOVELL\SYS\PUBLIC\test

It keeps returning this error code:
C00000CC STATUS_BAD_NETWORK_NAME

which according to MS’s docs means that it cannot find the specified share name (in this case sys). The interesting thing is that in filetest this path (\TWENC-NOVELL\SYS\PUBLIC\test) opens just fine with a normal create, so I know that the share is valid. Also a comparison of the exact same thing to a windows share works just fine.

If anybody has any ideas your help is much appreciated.

Thanks,
Matt

2

Normally this IOCTL is sent by MUP.sys. Are you trying to send this IOCTL from your driver? I am quite sure that you cannot send IOCTL_REDIR_QUERY_PATH_EX, as device is unnamed and only MUP knows DEVICE_OBJECT. Google for "MUP Changes in Microsoft Windows Vista
". It might help you in understanding how it works in Vista+ OSes.

Regards,
Bronislav Gabrhelik

3

One thing you could do to figure out why there is a failure is to set a
bp in WinDbg on the redirectors entry point for the IOCtl. Step into the
code and see what’s happening … of course you’ll have to enjoy assembly!

Pete

On 12/14/2010 3:11 PM, xxxxx@xythos.com wrote:

Normally this IOCTL is sent by MUP.sys. Are you trying to send this IOCTL from your driver? I am quite sure that you cannot send IOCTL_REDIR_QUERY_PATH_EX, as device is unnamed and only MUP knows DEVICE_OBJECT. Google for "MUP Changes in Microsoft Windows Vista
". It might help you in understanding how it works in Vista+ OSes.

Regards,
Bronislav Gabrhelik

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

4

Assembly is our native tongue :). It turns out that Novell’s NcUncFltDeviceControlDispath that handles IOCTL_REDIR_QUERY_PATH_EX calls into NcUncFltIsNovellPath with the “\TWENC-NOVELL\SYS\PUBLIC\test” path, which of course returns TRUE because this is indeed a novell server. The dispatch routine then returns the said error code and a DbgPrint message that reads “NcUncFltIsNovellPath determined “\TWENC-NOVELL\SYS\PUBLIC\test” is a Novell server.”

It is still unclear why they would actively fail the ioctl just because the path is on the novell server.

5

On 12/15/2010 6:57 AM, xxxxx@bitarmor.com wrote:

Assembly is our native tongue :). It turns out that Novell’s NcUncFltDeviceControlDispath that handles IOCTL_REDIR_QUERY_PATH_EX calls into NcUncFltIsNovellPath with the “\TWENC-NOVELL\SYS\PUBLIC\test” path, which of course returns TRUE because this is indeed a novell server. The dispatch routine then returns the said error code and a DbgPrint message that reads “NcUncFltIsNovellPath determined “\TWENC-NOVELL\SYS\PUBLIC\test” is a Novell server.”

Can you not see where the failure status is received from within the
dispatch routine?

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

6

The failure status is generated in the dispatch routine based on the output of NcUncFltIsNovellPath. Something like this:

if (NcUncFltIsNovellPath(Path))
{
Status = STATUS_BAD_NETWORK_NAME;

IoCompleteRequest();
}

7

On 12/15/2010 9:50 AM, xxxxx@bitarmor.com wrote:

The failure status is generated in the dispatch routine based on the output of NcUncFltIsNovellPath. Something like this:

if (NcUncFltIsNovellPath(Path))
{
Status = STATUS_BAD_NETWORK_NAME;

IoCompleteRequest();
}

That’s what I am saying, can you step into that routine and see why it
is failing?

Though there could be something even prior to this call which is
directing it down this path of failure.

Pete

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

8

Well, the purpose of NcUncFltIsNovellPath is somewhat obvious. It takes in a network path and checks to see if it’s on a novell server (I believe they call down to the redirector to find that out). It returns TRUE if it is on a novell server or FALSE otherwise. In our case, the path is indeed on a novell server, so TRUE is returned. They then fail the redirect request because of this.

I think we received further insight into this behavior. It seems to be related to performance optimization on Novell’s side. They want requests to known novell path to fail quickly, which would cause the connection to immediately go directly through novell client without an noticeable delay.

9

xxxxx@bitarmor.com wrote:

Well, the purpose of NcUncFltIsNovellPath is somewhat obvious. It takes in
a network path and checks to see if it’s on a novell server (I believe they
call down to the redirector to find that out). It returns TRUE if it is on
a novell server or FALSE otherwise. In our case, the path is indeed on a
novell server, so TRUE is returned. They then fail the redirect request
because of this.

I think we received further insight into this behavior. It seems to be
related to performance optimization on Novell’s side. They want requests
to known novell path to fail quickly, which would cause the connection to
immediately go directly through novell client without an noticeable delay.

The code path being described where NCUncFilter reaches the point of
invoking NcUncFltIsNovellPath is something that happens when
NCUncFilter is filtering an IOCTL_REDIR_QUERY_PATH_EX IRP which was
about to be passed to the Microsoft MRxSMB redirector.

The purpose is exactly as stated; to preemptively fail
IOCTL_REDIR_QUERY_PATH/_EX requests which MUP would have continued to
send to MRXSMB even after Novell’s redirector (NCFSD) knows the
particular server named is an Novell server the machine has an
established NCP connection to. To try and avoid (for the customer’s
benefit) the potential NetBIOS and other Microsoft name resolution
delays that will occur when this known Novell name/path continues to
be sent to MRxSMB.

(There are also IRP_MJ_CREATE cases which are filtered in the same
manner, since there are also create requests which will continue to
hit MRxSMB for names the Novell redirector already has established NCP
connections with.)

But just to be clear, this is not something expected to behave as
“Novell redirector is failing access to \FOO\SHARE with
STATUS_BAD_NETWORK_NAME because NcUncFltIsNovellPath is returning TRUE
for a known Novell path”.

NcUncFltIsNovellPath is being called because NCUncFilter has
intercepted the UNC path being sent /to MRxSMB/, and it’s the
IOCTL_REDIR_QUERY_PATH/_EX request /to MRxSMB/ which is being
preemptively failed with STATUS_BAD_NETWORK_NAME.

When an IOCTL_REDIR_QUERY_PATH/_EX with this UNC path is actually
being sent /to the Novell redirector/ (NCFSD on Windows 6.x, NWFS on
Windows 5.x), the described NCUncFilter code wouldn’t have engaged
because the IRP wasn’t being sent to MRxSMB.

If a quick workaround is needed, note that setting the “UNC Path
Filter” to “Off” in the “Advanced Settings” tab of the “Novell Client
Properties” will disable the involved NCUncFilter drivers, such that
MUP interaction with the installed redirectors will occur without any
preemptive failures injected by NCUncFilter.

Alan Adams
Novell Client CPR Group
xxxxx@novell.com

Novell
Making IT Work As One
www.novell.com

Upgrade to OES Community
http://www.novell.com/communities/coolsolutions/upgradetooes/

10

Alan,

Thanks for the tip on the advanced settings, that is helping me out. One question. Could you tell me if the Novell file servers support or ever supported alternative data streams on files and directories? For example, using somefile.txt:foo to store an alternate data stream in the somefile.txt file, or somedir:foo to store an alternative stream in a directory.

Thanks,
Matt

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alan Adams
Sent: Monday, December 20, 2010 9:26 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Novell redirector hates IOCTL_REDIR_QUERY_PATH_EX

xxxxx@bitarmor.com wrote:

Well, the purpose of NcUncFltIsNovellPath is somewhat obvious. It
takes in a network path and checks to see if it’s on a novell server
(I believe they call down to the redirector to find that out). It
returns TRUE if it is on a novell server or FALSE otherwise. In our
case, the path is indeed on a novell server, so TRUE is returned. They
then fail the redirect request because of this.

I think we received further insight into this behavior. It seems to be
related to performance optimization on Novell’s side. They want
requests to known novell path to fail quickly, which would cause the
connection to immediately go directly through novell client without an noticeable delay.

The code path being described where NCUncFilter reaches the point of invoking NcUncFltIsNovellPath is something that happens when NCUncFilter is filtering an IOCTL_REDIR_QUERY_PATH_EX IRP which was about to be passed to the Microsoft MRxSMB redirector.

The purpose is exactly as stated; to preemptively fail IOCTL_REDIR_QUERY_PATH/_EX requests which MUP would have continued to send to MRXSMB even after Novell’s redirector (NCFSD) knows the particular server named is an Novell server the machine has an established NCP connection to. To try and avoid (for the customer’s
benefit) the potential NetBIOS and other Microsoft name resolution delays that will occur when this known Novell name/path continues to be sent to MRxSMB.

(There are also IRP_MJ_CREATE cases which are filtered in the same manner, since there are also create requests which will continue to hit MRxSMB for names the Novell redirector already has established NCP connections with.)

But just to be clear, this is not something expected to behave as “Novell redirector is failing access to \FOO\SHARE with STATUS_BAD_NETWORK_NAME because NcUncFltIsNovellPath is returning TRUE for a known Novell path”.

NcUncFltIsNovellPath is being called because NCUncFilter has intercepted the UNC path being sent /to MRxSMB/, and it’s the IOCTL_REDIR_QUERY_PATH/_EX request /to MRxSMB/ which is being preemptively failed with STATUS_BAD_NETWORK_NAME.

When an IOCTL_REDIR_QUERY_PATH/_EX with this UNC path is actually being sent /to the Novell redirector/ (NCFSD on Windows 6.x, NWFS on Windows 5.x), the described NCUncFilter code wouldn’t have engaged because the IRP wasn’t being sent to MRxSMB.

If a quick workaround is needed, note that setting the “UNC Path Filter” to “Off” in the “Advanced Settings” tab of the “Novell Client Properties” will disable the involved NCUncFilter drivers, such that MUP interaction with the installed redirectors will occur without any preemptive failures injected by NCUncFilter.

Alan Adams
Novell Client CPR Group
xxxxx@novell.com

Novell
Making IT Work As One
www.novell.com

Upgrade to OES Community
http://www.novell.com/communities/coolsolutions/upgradetooes/

NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

Matt White wrote:

> Thanks for the tip on the advanced settings, that is helping me out. One question.
> Could you tell me if the Novell file servers support or ever supported alternative
> data streams on files and directories? For example, using somefile.txt:foo to
> store an alternate data stream in the somefile.txt file, or somedir:foo to store
> an alternative stream in a directory.

Technically the Novell server-side file system (NSS) does support
alternate data streams (ADS), so the capability to store and access
ADS on a Novell server is there from that perspective.

But the Novell NCP protocol being used by client workstations has no
provision for accessing ADS, so neither the Novell Client for Windows
7 nor previous Novell Client for Windows XP/2003 have any support for
the Windows file system concept of ADS.

Its a desired and often requested feature, but I’m not aware of any
ETA on when the NCP protocol might be updated to support alternate
data stream access.

Alan Adams
Novell Client CPR Group
xxxxx@novell.com

Novell
Making IT Work As One
www.novell.com

Upgrade to OES Community
http://www.novell.com/communities/coolsolutions/upgradetooes/

12

Alan,

Maybe you or somebody else can answer this, but it seems that on the Novell redirector, if I open a handle to a file with FILE_NO_INTERMEDIATE_BUFFERING set and FILE_READ access requested and full sharing, a subsequent create of another handle requesting FILE_READ and FILE_WRITE access and full sharing fails with STATUS_ACCESS_DENIED. Removal of the FILE_NO_INTERMEDIATE_BUFFERING flag on the first create causes both handles to be opened just fine. Any reason for this? This is semantically different from MS’s redirector because this works just fine.

Secondly, in the case described above (if we ignore the FILE_NO_INTERMEDIATE_BUFFERING issue), if I do not specify FILE_SHARE_WRITE on the 2nd handle, even though the first handle requested no write access, I get STATUS_SHARING_VIOLATION. This is also different behavior from the MS redirector, which allows this behavior.

Thanks,
Matt

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alan Adams
Sent: Thursday, December 30, 2010 1:18 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Novell redirector hates IOCTL_REDIR_QUERY_PATH_EX

Matt White wrote:

> Thanks for the tip on the advanced settings, that is helping me out. One question.
> Could you tell me if the Novell file servers support or ever supported
> alternative data streams on files and directories? For example, using
> somefile.txt:foo to store an alternate data stream in the somefile.txt
> file, or somedir:foo to store an alternative stream in a directory.

Technically the Novell server-side file system (NSS) does support alternate data streams (ADS), so the capability to store and access ADS on a Novell server is there from that perspective.

But the Novell NCP protocol being used by client workstations has no provision for accessing ADS, so neither the Novell Client for Windows
7 nor previous Novell Client for Windows XP/2003 have any support for the Windows file system concept of ADS.

Its a desired and often requested feature, but I’m not aware of any ETA on when the NCP protocol might be updated to support alternate data stream access.

Alan Adams
Novell Client CPR Group
xxxxx@novell.com

Novell
Making IT Work As One
www.novell.com

Upgrade to OES Community
http://www.novell.com/communities/coolsolutions/upgradetooes/

—
NTFSD is sponsored by OSR

For our schedule of debugging and file system seminars (including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer