Appendix F: Browser Traffic

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Browser Announcements

Each computer that has a server component, including Windows for Workgroups, Windows 95, and Windows NT Workstations and Servers, will announce themselves to the Browse Master for their local domain or workgroup. This announcement is then added to the list of server computers on the network. There are numerous announcement types, including host, workgroup and local master. Following is information about common browser announcement types:

Delivery Tips

Display frame 16 in "BDCBOOT.CAP".

Host Announcements

A computer with a server component will initiate a browser announcement to its local browse master indicating it has the capabilities of receiving client connection requests. This announcement is a frame of 243 bytes.

In the NBT section of the frame, the Destination name is workgroup <1D>. This is an announcement to the local browse master for local client's domain/workgroup that it is available as a server to be browsed.

The final 33 bytes represent the browser portion of the frame. It contains:

  • Command of Host Announcement.

  • The Announcement Interval (progresses to 12 minutes).

  • Name is the computer name to be added to the browse list.

  • Flags to indicate the server type, such as Windows for Workgroups, Windows 95, Windows NT Workstation or Windows NT Server.

Upon initialization, there may be multiple Host Announcement frames broadcast, each specifying the host as a browser workstation, a browser server, a domain controller, or as a potential browser server.

Once the host has started up, and remained running, a host announcement message will be broadcast every 12 minutes to refresh its name in the browse list.

Announcement Requests

Once a browser computer has initialized, it must determine who is the master browser for its domain or workgroup. This is done with an Announcement Request that is approximately 220 bytes in size. This request is broadcast on the local subnet to the NetBIOS name domain <1D>. When the master browser detects this Announcement Request, it responds with a Local Master Announcement (covered below).

Additionally, when a new master browser computer initializes, it initiates two Announcement Request messages to force server announcements from local hosts. These announcement requests are each ~220 bytes.

In the NBT section of the frame, the Destination name varies.

  • One request is to workgroup <00>, and is an announcement to the local clients to announce their presence. This is done if the master browser list is empty.

  • Another Announcement Request is delivered to <01><02>_MSBROWSE_<02><01>. This request forces other local master browsers to announce their domain or workgroup to the new master browser.

The final portion represents the browser portion of the frame. It contains the browser command, Announcement Request, and the Reply System Name (the local host name).

Delivery Tips

Display frames 51-52 in "BDCBOOT.CAP".

Local Master Announcements

Whenever a browser client initializes and attempts to find a master browser, it broadcasts an Announcement Request message. The master browser then responds with a Local Master Announcement. This announcement is a frame of approximately 250 bytes.

In the NBT section of the frame, the Destination name workgroup <1E>. This is an announcement as the local browse master, and for local clients to request elections if necessary.

The remainder of the frame represents the browser portion. It contains:

  • Command of Local Master Announcement.

  • Announcement Interval (progresses to 12 minutes).

  • Name is the local master browser name.

  • Flags to indicate the server type, such as a Domain Controller, a Windows NT Workstation and Windows NT Server computer, a potential browser, and a master browser.

Upon initialization as a master browser, there will be a Local Master Announcement frame broadcast, and it will be repeated every 12 minutes as the master browser remains running.

Also, each computer functioning as a master browser will initiate a local master announcement to local browse masters in other domains announcing itself as a browse master.

Workgroup Announcements

When a master browser has been elected, it must announces itself as the master browser for the domain/workgroup. As it does this, it announces its workgroup or domain. This is how a master browser learns of other master browsers on the local subnet. This announcement is a frame of ~250 bytes.

In the NBT section of the frame, the Destination name is <01><02>_MSBROWSE_<02><01>. This is an announcement to other local browse masters in other domains announcing this domain. By doing this announcement, each master browser learns the other domains/workgroups on the local subnet.

The final portion of the message represents the browser portion of the frame. It contains:

  • Command of Workgroup Announcement.

  • Announcement Interval (which progresses to 15 minutes).

  • Name is the name of the workgroup or domain.

  • Flags that announce as a Domain Enum, to indicate this is a domain or workgroup announcement.

Once the master browser has been running, it repeats this announcement every 15 minutes to refresh the domain in with all local master browsers.

Browser Elections

One of the first things a computer does upon initializing is find the local master browser. This is done by issuing an Announcement Request to domain <1D>.

If a local master browser cannot be found, or if the initializing computer is a Windows NT Server with the capability of becoming the master browser, an election is performed to determine who should function as the master browser.

When an election is performed, the host that initiated the election sends an Election frame, indicating it is forcing an election. It then broadcasts another message with its election criteria. All browser computers receive this election frame, and if a host has a higher election criteria, it responds with an election packet with its criteria.

Each host will delay in responding for a period of time. This "backoff" time (which is shorter on servers and longer on workstations) allows hosts that are more likely to become the master browser (domain controllers) to respond more quickly than a host less likely to become the master browser (workstation computers). When the host with the highest election criteria responds, no others will respond, as they know they will not win the election.

Delivery Tips

Display frames 72-73 and 78-80 in "BDCBOOT.CAP".

Election Packets

A browser election packet is ~225 bytes in size.

In the NBT section of the frame, the Destination name is workgroup <1E>. This is an announcement to the local browse master for clients to request elections.

The remainder of the frame represents the browser portion. It contains:

  • Command of Election.

  • Election criteria, which includes all data necessary to determine the master browser, such as operating system, current browsing role, and if the client is a WINS client.

  • The system up time and host name. These are used in the event multiple computer have the same election criteria. The system that has been running the longest would become the master browser, and in the event of a tie, then it would use the name that comes first alphabetically.

In the event of a PDC being shutdown, and a new master browser needing to be elected, the process may take as few as six messages, and as little as four seconds.

Subnet Browsing

In a WAN environment, it is very common to have a single domain that is separated by routers. While this is beneficial to reduce broadcast traffic on the entire network, it makes browsing more difficult, as browsing relies on broadcast messages. In a TCP/IP WAN, is it possible to browse an entire domain, even though subnets are separated by IP routers. WINS makes browsing much easier.

As already discussed, on each subnet, one computer from each domain is elected as the local master browser. Normally, in a WAN, these would remain as separate browsing entities. But with WINS, WAN-wide browsing is possible. As each subnet's master browser initializes, it queries the WINS server for the Domain Master Browser. This is accomplished with a query on the NetBIOS name domain <1B>. This name is registered by the primary domain controller of each domain at initialization time. The WINS server responds to this query with the IP address of the primary domain controller.

Each master browser then sends a Master Announcement to the Domain Master Browser to notify it as a master browser for the domain. This frame is approximately 220 bytes in size, and is directed to the domain master browser. In the NBT header, the destination NetBIOS name is domainmaster <00>.

The master browser then sends two NetServerEnum API call to the domain master browser to retrieve a list of domains and workgroups that the domain master browser has learned about, and a list of servers in the local domain. The domain master browser then makes a similar request (two NetServerEnums) to the master browser to retrieve the list of domains on its subnet, and any local servers.

This process is repeated every 15 minutes to keep the list of domains and local browser computers up to date.

Browser Queries

In order for clients to successfully display a browse list, for example when using File Manager, they first need to know where to get the list of servers. This is retrieved from a Backup Browser.

Delivery Tips

Display frames 69 and 70 in "BOOTWFW.CAP".

Finding Backup Browsers

The first step in the process is for the client to determine the master browser for its local subnet. This is done by sending a GetBackupListReq call to the NetBIOS name domain <1D>. In a WINS environment, if there is no response to the <1D> query, this request is sent to the WINS server, querying on the NetBIOS name domain <1B>. A Domain Master Browser initializes this name with a WINS server so that clients can browse resources on subnets without any local master browser for that domain. The properties of this frame are:

  • Approximately 215 bytes in size.

  • In the NBT section of the frame, the Destination name is domain <1D>. This is the address the clients use to request browse lists from the master browser of the subnet. Only the master browser registers this name.

  • In the browser portion of the frame, the browser command is listed as Get Backup List Request.

The master browser will respond with a list of backup browsers for the local subnet. This is accomplished with a Get Backup List Response frame. This message properties are:

  • A minimum 227 bytes in size, and will vary depending upon the number of entries included.

  • It is a directed response at both the MAC and IP layers (not broadcast).

  • In the NBT header, the Source Name is the computer name of the master browser, and the Destination Name is the computer name of the requesting client computer.

  • The browser data includes the command Get Backup List Response.

  • A list of all the backup browsers for the domain/workgroup on the local subnet.

Delivery Tips

Display frames 71-79 in "BOOTWFW.CAP".

Retrieving a Browse List

Once the client has received a listing of backup browsers from the master browser, it randomly selects three servers from the list, and caches them. When it needs to browse, it randomly selects one of the three cached names, and completes the following sequence of events with the selected backup browser computer:

  • Establish a TCP session.

  • Establish a NetBIOS session.

  • SMB protocol negotiation.

  • Establish a null session to IPC$.

Delivery Tips

Display frames 80-83 in "BOOTWFW.CAP".

The client then sends an API to the backup browser requesting a browse list. If the client is a Windows NT client, the conversation is completed via a NetBIOS session and RPC calls. If the client is a Windows for Workgroups or Windows 95 client, the request is completed using a NetServerEnum API call.

The details of the NetServerEnum API call frame are:

  • The size will vary, depending upon SMB enhancements, such as Unicode support.

  • Directed send at both physical and IP layers.

  • TCP "Acknowledgement field significant" and Push flags are set.

  • SMB Command of Transact.

  • SMB Path Name of \PIPE\LANMAN which calls the NetServerEnum API.

The backup browser will respond differently depending upon the request from the client. For Windows for Workgroups, it responds with a listing of domains and workgroups available in one frame, then another to display the computers in the local domain. For Windows 95, it responds with a listing of computers in the local domain or workgroup. These frames have the same basic properties as the request from the client, with the difference being the data returned to the client from the backup browser.

Delivery Tips

Display frames 87-100 in "BOOTWFW.CAP".

Once the client has received the browse list from the backup server, viewing resources can take place. The first step is to display a list of resources the appropriate computer. This is done by completing the following sequence of events with the selected computer:

  • Establish a TCP session.

  • Establish a NetBIOS session.

  • SMB protocol negotiation.

  • Establish a validated session to IPC$.

Delivery Tips

Display frames 101 and 102 in "BOOTWFW.CAP".

If the client is a Windows for Workgroups, the request is completed using a NetShareEnum API call. If the client is a Windows 95 or Windows NT client, the call is carried out over RPC calls. The details of the NetShareEnum API call frame are:

  • The size will be approximately 150 bytes.

  • Directed send at both physical and IP layers.

  • TCP "Acknowledgement field significant" and Push flags are set.

  • SMB Command of Transact.

  • SMB Path Name of \PIPE\LANMAN which calls the NetShareEnum API.

The server will then respond with at least one frame that returns the list of shared resources available. For example, on a Windows NT Server with 20 sharenames, one frame was used to return the list, and this frame was 786 bytes in size. This session is then terminated.

The client may then choose to connect to one of the resources on the server. If so, the next section will cover the traffic generated to establish a file session.