[OpenAFS] Re: strange issue with openafs on windows

Wed, 23 Sep 2009 09:17:31 -0700

--0015175770ea508c190474410db5
Content-Type: text/plain; charset=UTF-8

Here is a follow up to this last issue.

We found that the clients with openafs could reach servers that had netbios
over tcp enabled, but could NOT find them when the server did not have that
turned on. This seems bizarre. Why would a client with openafs not be able
to find a server that did not have netbt enabled  -- and yet all clients
without afs can find them just fine?

On Wed, Sep 16, 2009 at 9:27 AM, David Bear <David.Bear@asu.edu> wrote:

> We have noted that there is some strange side effect to openafs on windows.
> Breifly, here is the scenario.
>
> Assume: 3 windows file servers -- srv1, srv2, srv3.
>
> Assume: openafs 1.5.58, 1.5.59 and 1.5.60 clients are installed on windows
> XP, sp3.
>
> found on XP clients with openafs that they were not able to make smb
> connections to srv2, but were able to make connections to srv1 and srv3. The
> error was something like path not found. Connection attempts were made using
> BOTH single host (netbios) name, aka \\srv2 AND FQDN, aka \\srv2.asu.edu.
> Note that srv2 would respond to pings, both by IP address and FQDN. FQDN
> requests were resolved from DNS.
>
> If we removed openafs from the windows clients, they were able to make smb
> connections find to srv2.If we loaded openafs back on the system, they again
> failed.
>
> Later we were able to talk with ther server administrator for srv2 and
> found that netbios of tcp was disable on that system. After he enabled it,
> the systems again were happy making connections to srv to even with openafs
> installed.
>
> I send Jeff Altman a message relating part of this tale and he correctly
> stated that it was a name resolution issue. However, the issue seems more
> complex. First, why does existence of openafs cause the client to fail to
> resolve srv2 by name? what could it possibly have to do with name resolution
> on the client. Note that netbios of tcp IS enabled on the client. Second,
> since the comon failure requires BOTH openafs on the client AND TCP over
> netbios NOT be installed on they server, how does NETBIOS ont he server
> affect the way the client is able to resolve the name? It seems that openafs
> forces some difference in the way the server name is resolved in the smb
> conversation the client generates. Why would netbios on the server affect
> they the client resolves the name?
>
> Finally, if the native file system driver version of openafs that does not
> require the microsoft smb server would fix this kind of strange issue, it
> seems that moving to that version with all due speed would be in everyone's
> best interest.... when it becomes available.
>
> --
> David Bear
> College of Public Programs at ASU
> 602-464-0424
>

-- 
David Bear
College of Public Programs at ASU
602-494-0424

--0015175770ea508c190474410db5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Here is a follow up to this last issue. We found that the clients wi=
th openafs could reach servers that had netbios over tcp enabled, but could=
 NOT find them when the server did not have that turned on. This seems biza=
rre. Why would a client with openafs not be able to find a server that did =
not have netbt enabled=C2=A0 -- and yet all clients without afs can find th=
em just fine? 
 <div class=3D"gmail_quote">On Wed, Sep 16, 2009 at 9:27 AM, David Bear =
&lt;<a href=3D"mailto:David.Bear@asu.edu">David.Bear@asu.=
edu</a>&gt; wrote: <blockquote class=3D"gmail_quote" style=3D"bor=
der-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-=
left: 1ex;">
We have noted that there is some strange side effect to openafs on windows.=
 Breifly, here is the scenario. Assume: 3 windows file servers -- sr=
v1, srv2, srv3. Assume: openafs 1.5.58, 1.5.59 and 1.5.60 clients ar=
e installed on windows XP, sp3.

found on XP clients with openafs that they were not able to make smb co=
nnections to srv2, but were able to make connections to srv1 and srv3. The =
error was something like path not found. Connection attempts were made usin=
g BOTH single host (netbios) name, aka \\srv2 AND FQDN, aka \\<a href=3D"ht=
tp://srv2.asu.edu" target=3D"_blank">srv2.asu.edu</a>. Note that srv2 would=
 respond to pings, both by IP address and FQDN. FQDN requests were resolved=
 from DNS.

If we removed openafs from the windows clients, they were able to make =
smb connections find to srv2.If we loaded openafs back on the system, they =
again failed. Later we were able to talk with ther server administra=
tor for srv2 and found that netbios of tcp was disable on that system. Afte=
r he enabled it, the systems again were happy making connections to srv to =
even with openafs installed.

I send Jeff Altman a message relating part of this tale and he correctl=
y stated that it was a name resolution issue. However, the issue seems more=
 complex. First, why does existence of openafs cause the client to fail to =
resolve srv2 by name? what could it possibly have to do with name resolutio=
n on the client. Note that netbios of tcp IS enabled on the client. Second,=
 since the comon failure requires BOTH openafs on the client AND TCP over n=
etbios NOT be installed on they server, how does NETBIOS ont he server affe=
ct the way the client is able to resolve the name? It seems that openafs fo=
rces some difference in the way the server name is resolved in the smb conv=
ersation the client generates. Why would netbios on the server affect they =
the client resolves the name?

Finally, if the native file system driver version of openafs that does =
not require the microsoft smb server would fix this kind of strange issue, =
it seems that moving to that version with all due speed would be in everyon=
e&#39;s best interest.... when it becomes available. 

 -- David Bear College of Public Programs at ASU 602-464-0424<=
br>
</blockquote></div> -- David Bear Co=
llege of Public Programs at ASU 602-494-0424

--0015175770ea508c190474410db5--