HP Rp7410 Configuring and Troubleshooting MS DFS links in an HP CIFS Server (S - Page 9

How it works

Page 9 highlights

If we click on the folder 'linka', we are also successful. Figure 5: Contents of 'linka' So, we have demonstrated that by connecting to a single HP CIFS Server, 'rkm-nt' we are able to actually access files on completely independent servers. How it works The mechanism behind this is interesting. What actually happens behind the scenes is this. Client connects to a HP CIFS Server share that is hosting MS DFS links, and attempts to access one of these links for the first time (for instance, clicking on 'linka' in the Explorer window open to the 'dfsroot' share on rkm-nt). HP CIFS Server recognizes that this is a MS DFS link, and returns an ERROR to the client. The error that is returned is NT_STATUS_PATH_NOT_COVERED. An MS DFS aware client (such as Windows/XP) recognizes this special error code as a signal that the resource is a MS DFS link. This triggers the client to send an NT_TRANSACT2 request for a MS DFS referral. HP CIFS Server responds to this NT_TRANSACT2 request with a MS DFS referral which contains the server and share name the client should refer to. The client uses this information to make a direct connection to the \\server\sharename in the referral, and from that point on the client works directly with the referred server. The following two screen snapshots from an Ethereal4 trace of the client 'mccallevo'. Clicking on the 'linkb' directory in the 'dfsroot' share on the HP CIFS Server 'rkm-nt' illustrates the network traffic which supports this transaction.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21

If we click on the folder ‘linka’, we are also successful.
Figure 5: Contents of 'linka'
So, we have demonstrated that by connecting to a single HP CIFS Server, ‘rkm-nt’ we are able to
actually access files on completely independent servers.
How it works
The mechanism behind this is interesting.
What actually happens behind the scenes is this.
Client connects to a HP CIFS Server share that is hosting MS DFS links, and attempts to access one of
these links for the first time (for instance, clicking on ‘linka’ in the Explorer window open to the
‘dfsroot’ share on rkm-nt).
HP CIFS Server recognizes that this is a MS DFS link, and returns an ERROR to the client.
The error
that is returned is NT_STATUS_PATH_NOT_COVERED.
An MS DFS aware client (such as
Windows/XP) recognizes this special error code as a signal that the resource is a MS DFS link.
This
triggers the client to send an NT_TRANSACT2 request for a MS DFS referral.
HP CIFS Server responds to this NT_TRANSACT2 request with a MS DFS referral which contains the
server and share name the client should refer to.
The client uses this information to make a direct connection to the \\server\sharename in the referral,
and from that point on the client works directly with the referred server.
The following two screen snapshots from an Ethereal4 trace of the client ‘mccallevo’.
Clicking on the
‘linkb’ directory in the ‘dfsroot’ share on the HP CIFS Server ‘rkm-nt’ illustrates the network traffic
which supports this transaction.