directing smbc_opendir(url) to an explicit interface

Thu Nov 13 06:42:37 GMT 2003

[Very verbose response, but I wrote it while at the conference and this 
stuff is on my mind anyway.]

On Wed, Nov 12, 2003 at 07:58:11PM -0800, David Wuertele wrote:
> I want to clarify something I said: there are two workgroups, both
> called WORKGROUP, disjoint from each other.  They are not necessarily
> sets of "B" nodes, which the appendix implies is the purpose of the
> "?BROADCAST=" context qualifier.

Geez I love CIFS...

Okay, let me go back to the first message...

On Wed, Nov 12, 2003 at 07:45:21PM -0800, David Wuertele wrote:
:
>   http://www.ietf.org/internet-drafts/draft-crhertel-smb-url-05.txt
> 
> (is that the latest version?)

Yes.  It's current (check the dates at the top of the draft).

> it says that there is something called an "nbt_context":
:

Yes.  We could not think of any other way to provide NBT context
information as part of the URL.  The problem is that the URL string should
be unambiguous (as much as possible).  That means that a given NetBIOS
name should (as much as possible) have the same meaning no matter who
types in the URL, or where they type it in.  That, of course, is nearly
impossible.  :)

Being able to specify things like the NBNS address, the node type, and the
workgroup mean that you can transmit NBT context from one user to another
when you transmit the URL string.  By keeping track of the context, you 
can provide best-effort at consistency of meaning.

> If I'm reading this right, it says that I can write two URLs thusly:
> 
>   smb://WORKGROUP?BROADCAST=192.168.0.255
>   smb://WORKGROUP?BROADCAST=192.168.1.255

Ah...  Yes, you can do that.  The intent, though, is to specify to which
broadcast address a name query should be sent.  It's there because you can
also specify a NBNS (unicast) address for resolution.

> The first is a request to list the servers on the WORKGROUP living on
> my eth0 subnet, and the second is a request to list the servers on the
> WORKGROUP living on my eth1 subnet.  Is this correct?

Not really, no... though that would be the practical result assuming the 
default for the user agent is not "P" mode.

In fact, the above is in multiple steps.  First, resolve the name 
"WORKGROUP" as either a <20>, <1D>, or <1B> name.  If broadcast mode is 
used (that is B, M, or H mode) then try both the <20> name and the <1D>
name.  In point-to-point mode you'd try <20> and <1B>.  Also in broadcast 
mode, you would use the broadcast address given in the URL.

Once the name is resolved you decide what to do with it.  If it was a 
Master Browser name (a <1B> or <1D> name) then you would query it for the 
list of servers (NetServerEnum2).

Oh, and then repeat the process for the second URL.

So, as you noted in your second message, it's not exactly that the 
BROADCAST=IP field tells the user agent which interface to use.  It only 
specifies to which broadcast address the broadcast name queries should be 
sent.

> There might be an LMB on 192.168.0.255, but then again there might not
> (for example, maybe there are only P nodes on that subnet, and the
> WINS server is on a remote subnet).

Right.

So you also need to specify the IP address of the NBNS.  If (as you said)  
the two subnets you listed represent two scopes then they will not have
the same NBNS.  There may be no NBNS, or just one, or two separate ones
but if they shared the same scope then they would share the same
workgroup as well.  (In this case, given the problem description.)

> I still want to request a list of the servers in an explicit
> WORKGROUP, and the only way I see to specify one or the other is by
> using the BROADCAST qualifier.  But it doesn't seem quite right, since
> the broadcast address of my eth0 is not necessarily common to all
> hosts in the workgroup WORKGROUP that happens to partially occupy the
> same subnet as eth0.

Ummm... Not sure what you mean here.

What I can say is that

  smb://WORKGROUP?BROADCAST=<IP>;NBNS=<IP>

should (in theory) work.  It does not specify the interface (you can't do 
that in a URL) but it does specify the scope for name queries.  It is the 
Name Service that "defines" the virtual NetBIOS LAN so that should work.

> So some other member of the WORKGROUP I can see from eth0 might
> actually be on 192.168.77.255, in which case they would never use
> smb://WORKGROUP?BROADCAST=192.168.0.255 to request a list of the
> servers in that workgroup.

Specifying the broadcast address does not limit name resolution to B mode.  
If you are using smb.conf, the configuration parameters there are the 
defaults.  You can override them using the context values.

MAJOR CAVEAT:  I don't think libsmbclient implements the v05 draft format.

> They would use
> smb://WORKGROUP?BROADCAST=192.168.77.255, which shouldn't be a problem
> because their NBT resolver logic should understand that just fine.
> But it points out that this URL for requesting the list of servers in
> WORKGROUP is not unique, nor is it portable between subnets.

Hmmm... Not sure again what you mean here.  The format you give above 
would perform a directed broadcast.  If the routers allow it, the name 
query would result in the IP address of the LMB on the remote subnet (if 
there is one).  If the routers don't allow it, then you get back nothing.

---

Okay, this is all in my book but here's what needs to be done in the 
software to get the list of servers in a workgroup:

1) Resolve the workgroup name ("WORKGROUP") to an IP address.  In the SMB 
   URL you don't know whether the name is a workgroup name or a server
   name based on the URL form.  It could be smb://SERVER

   So:
   If you are sending a broadcast query (B mode) query for:
     name<20>  -- as if it were a server service name
     name<1D>  -- an LMB name
   If you are sending a point-to-point query (P mode) query for:
     name<20>  -- as if it were a server service name
     name<1B>  -- a DMB name

2) Based on the result:
     If it's a <20> name then list the available shares.
       (NetShareEnum or NetrShareEnum)
     If it's a <1B> or <1D> name then query for the list of servers.
       (NetServerEnum2  ... there may be an equivalent RPC)
     If it's both then the network is misconfigured (hard but not 
       impossible to do), in which case the server name takes precedence
       unless the user agent can display both the list of servers and the
       list of shares on the server.

Things to keep in mind:
  - In order for a workgroup to be "present" on a subnet, there must be an 
    LMB for that workgroup on that subnet.
  - LMBs cannot be found by querying a WINS server.  WINS servers (and 
    Samba's nmbd, which must be compatible) deny knowledge of <1D> names.
  - LMBs must be found using broadcast mode name resolution.
  - DMBs can be found by querying the NBNS (WINS server).
  - There's no point in sending a broadcast query for a DMB since the DMB 
    will also be the local LMB.  If sending a broadcast, just query for
    the LMB name.

Geez I love CIFS...

Chris -)-----

-- 
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/     -)-----   Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/   -)-----   ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/     -)-----   crh at ubiqx.mn.org
OnLineBook -- http://ubiqx.org/cifs/    -)-----   crh at ubiqx.org