it-admin

Big Brother and Ndisuio.sys
A new Internet phenomenon?
By Red Squirrel

Ndisuio.sys, a very mysterious system file is present in Windows XP and is a driver for wireless things such as wi-fi and bluetooth. However, there have been many issues with this file downloading immense amounts of data and perhaps causing activity that is "big brother"ish.

The fact that hardly any information on this file downloading data is available by Microsoft makes things quite suspicious about it. It has even been noted that it looked as if it was transferring data to major companies like Comcast, Road Runner, Time Warner, BTC and Verizon.

The good news is, it turns out this file duplicates data that is sent/received, so wherever you go, it will also transfer the data to that file but it does not leave the computer/network so it's not spyware. So it's not as much of a big brother situation then it looks like. It simply performs internal communication tasks and stands for NDIS user I/O, hence, NDISUIO. NDISUIO is also used as a driver by many developers as it makes certain wireless network tasks easier such as implementing it for 802.11x connections. Some firewalls also use it as it can get the data in order to filter it.

But duplicating this data can hog resources for no reason, so disabling it is the best thing to do. The data rate of this file's received data is huge, so that indicates that the data transfer is not over the Internet, but locally. So it's just a duplicate of network activity but because it's local everything transfers faster but uses more resources then casual internet usage as there's more data involved at a given time span of 1 second, for example.

To disable this file, go to the control panel, administration tools, services, Wireless Zero Configuration, double click and disable it. This file is probably required to run if you use any linksys wireless devices.

Because I use win2k and not XP I have never experienced anything with this file myself, so this is only a summary of what this file does and what it is for and not based on my own experience but researched information.

-Red Squirrel
IceTeks Owner


Here are a few links having to do with this file:

This was a thread here at Iceteks discussing about this file's strange network behavior.
http://www.iceteks.com/forums/show.php/showtopic/1290

NDIS User Mode I/O (NDISUIO) Version Dependencies
http://www.ndis.com/pcakb/KB01010301.htm

DHCP Does Not Obtain a New Address When EAP Reauthenticates Across Access Points with IP Subnets That Differ
http://support.microsoft.com/default.aspx?kbid=822596

NDIS User-mode I/O Driver
http://msdn.microsof...fndisuser-modeiodriver.asp

The browser service maintains a list of the domain name or workgroup name the computer is in, and the protocol being used for each computer on the network segment being served by the computer running the browser service. On each network segment, a master browser is elected from the group of computers located on the segment that are running the browser service.

The master browser is responsible for collecting host or server announcements, which are sent as datagrams every 12 minutes by each server on the network segment of the master browser. The master browser instructs the potential browsers for each network segment to become backup browsers. The backup browser on a given network segment provides a browse list to the client computers located in the same segment.

NOTE: In a Windows NT domain structure, the primary domain controller (PDC) is always selected as the domain master browser. Only the PDC can be a domain master browser. If a PDC is not present, a domain master browser is not available and you are unable to obtain browse lists from workgroups other than the workgroup you are located in.

On a given network segment, there is only one master browser. All domain controllers other than the PDC are designated as backup browsers. Additionally, one backup browser is allocated for every 32 computers on the network segment.

In a workgroup configuration containing Windows NT Workstation-based computers, there is always one master browser. If there are at least two Windows NT Workstation-based computers in the workgroup, there is also one backup browser. For every 32 Windows NT Workstation-based computers in the workgroup, there is another backup browser.

If there is not a domain controller present on a given network segment, then an election process is started that chooses a master browser and backup browser from the computers on the segment using the following order of priority:

Windows 2000 Server
Windows 2000 Professional
Microsoft Windows NT 4.0 Server Enterprise Edition
Microsoft Windows NT 4.0 Server
Microsoft Windows NT 4.0 Workstation
Microsoft Windows 98
Microsoft Windows 95
Microsoft Windows for Workgroups 3.11
Domain Master Browser Role
Because the browser service is bound by broadcast segments and each master browser maintains its own separate list, there must be a way to merge these lists into a single domain-wide list. This functionality is provided by the domain master browser that is the PDC for the domain. This functionality is not required for network protocols other than Transmission Control Protocol/Internet Protocol (TCP/IP).

The PDC has is also responsible for connecting to its primary Windows Internet Name Service (WINS) server every 12 minutes to obtain a list of all the DomainName type <1b> entries that are registered by the PDCs throughout the enterprise. This is done by issuing an MSRPC R_WinsGetBrowserNames request. These names, along with the workgroup announcement datagrams collected by the master browsers throughout the WAN, build the full list of domain and workgroup names. The names discovered by workgroup announcements take precedence over those obtained from WINS. These domain and workgroup names also contain the name of the server registering any given computer in the browse list. In the event that a WINS server is not available, or it is not registered, the client's browser requests the list of servers from the computer that registered the name. This operation is done on behalf of the client by its browser and is called a double-hop.

The PDC merges all the lists gathered by the master browsers on each segment across the WAN. Every 12 minutes, the master browser connects to the PDC to obtain the domain-wide list. The list is obtained by first issuing a NetServerEnum request with a flag of 0xFFFFFFFF. This request retrieves the complete list of servers within the domain. The master browser then issues the same request with a flag of 0x8000000, which requests all of the domain and workgroup names.

To signal the PDC to retrieve the list collected by this master browser, the master browser sends the PDC a directed master announcement frame over User Datagram Protocol (UDP) port 138. This signals the PDC to immediately connect to the master browser and retrieve its list. This communication is also performed with two NetServerEnum requests. First, a NetServerEnum request with flag 0x40000000 is issued to request the local list of servers collected by the master browser. Then, a NetServerEnum request with flag 0xC0000000 is sent to retrieve the local workgroup announcement frames sent by the master browser of other domains or workgroups on its segment. Each backup browser on the segment issues a NetServerEnum request with flags of 0xFFFFFFFF and x80000000 at 12-minute intervals to obtain the complete list of servers, domains, and workgroup names.

Registration And Propagation Time
Because the browser service relies on server broadcasts, its communication is connectionless and by definition unreliable. When a server starts, it immediately sends a host announcement frame. This process is repeated at 4 minutes and again at 8 minutes. The process is then repeated every 12 minutes thereafter.

Allowing for the loss of a few datagram frames, it is reasonable to expect that the network segment's master browser will add a given computer's name to the browse list within 12 minutes after startup. Beyond this point, connection-oriented traffic is used and the sequences are more deterministic. Within 12 minutes, the segment's master browser will connect to the PDC to obtain the domain-wide list, and at the same time the PDC will connect to the master browser and learn of the new server.

Master browsers on remote segments also connect to the PDC at 12-minute intervals and soon learn of a new server. Within 12 minutes of the remote master browser learning of a new computer's name, all the backup browsers connect to their master browser. At this point, all browsers on a remote segment know about the new server. In a multi-segment WAN environment, the maximum amount of time it should take for all clients within the domain to see the new computer is 48 minutes (12 + 12 + 12 + 12). On a network on which broadcasts and network usage are well within safe parameters, this period should average approximately one-half as long (24 minutes).

Removing computers from the browse list may take more time. To allow for lost datagram frames, the master browser does not remove a server from its list until 3 announcement periods have passed. If the server is not shut down gracefully or if network connectivity is lost, the server can remain in the master browser's list for up to 36 minutes. After this time, the PDC is notified to remove the server name. The same communication flow follows to remove a server's name. Within 12 minutes, a master browser on a remote segment obtains the domain-wide list from the PDC, and within 12 minutes each backup browser connects to the master browser. This process can take as long as 72 minutes to finish (36 + 12 + 12 + 12). If the server is shut down gracefully, the browser sends a single Host Announcement frame indicating that it is no longer acting as a server. Upon receipt of this datagram, the master browser immediately removes the server from its local list. On a network on which broadcasts and network usage are well within safe parameters, this period should average approximately one-half as long (36 minutes).

Because a server's browser role is defined dynamically with periodic elections, determining the flow of communication used to provide the browse list to a specific client computer can be difficult. If a master browser is shut down gracefully, the master browser forces an election for a new master browser during shutdown. If the backup browser that wins the election has been present on the network long enough to receive a complete browse list, it starts as a master browser with a fully populated browse list, and browse functionality continues on the network segment without interruption.

If a server that was acting as the master browser is not shut down gracefully or if the master browser's force election request datagram is lost, there may be a delay before browse functionality is available on the network segment. An election of a new master browser is caused if a client computer requests a browse list and is unable to locate a master browser. It may take up to 12 minutes for a backup browser to discover that no master browser is present, depending on network usage.

Name Resolution Requirements
Name resolution across the domain is critical for the distributed browsing model to operate. All computers across the WAN that are potential master browsers must be able to resolve the DomainName type <1b> entry for the PDC. After a potential master browser receives a positive response to the query for a PDC, the master browser must also be able to resolve the computer name type <00> entry of the PDC. The PDC must be able to resolve the names of all computers that are potential master browsers in order to be able to connect to them. The PDC listens for directed master announcements from the master browsers on UDP port

This announcement triggers the PDC to resolve the computer name type <00> of the master browser, and to request the browse list maintained by the master.

Once a browse list is presented to a client computer, the client computer must resolve the NetBIOS name entry of any computer listed in order to view shared resources. Therefore, all client computers must be able to resolve the Internet Protocol (IP) address of all computers in the domain. In most networks configurations, this means that the distributed WINS infrastructure must be working properly.

The problem is on the machine you are trying to connect to.
Simple file sharing uses the guest account on the machine you are connecting
to.
This requires that the Guest account is:

1) Enabled; and
2) Granted permissions to log in across the network.

Starting with (1):

The option to turn the Guest account on and off from the control panel is
mis-labeled. It does not actually disable the account when you turn it off
here. It just sets an option on the account called Deny Local Logon. What
is required is that the guest account is active behind the scenes, which is
what is required for network access.

On XP-Pro:
R-click 'My Computer' | Manage | Local Users and Groups | Users
Check the Guest account does not have a red X on it.
If it does, then double-click the Guest account and un-check 'Account is
Disabled'.

XP Home is missing some essential tools to manipulate user accounts and
permissions. So on XP-Home, we need to use a command. ( This will work on
both XP-Home and XP-Pro ) :

Go to a command prompt ( not start | run ), and type:

net user guest

The output should contain a line like this:

Account active Yes

If it shows the account is not active, then type:

net user guest /active:yes

( It can remain off in the user control panel app, so long as it is enables
as per the above. )

Now, on to (2).
( This is the cause of your error. )

On XP-Pro, start | Run | secpol.msc
Local Policies | User Rights Assignments

Double-click the policy "Access this computer from the network".

Add the 'Everyone' group if it's not there:
'Add User or group' button;
Click 'Advanced' button;
Click 'Find Now'
Select 'Everyone' on the list, and OK all the way out.

Now double-click the policy "Deny access to this computer from the network".
Remove the Guest account if it's listed there.

OK your way out of there.
That should grant the necessary permissions.


For XP-Home,

Download and install the Windows 2003 Server Resource Kit Tools:
http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

To run it, go to:
Start | All Programs | Windows Resource Kit Tools | Command Shell.

A command prompt window will open.
Type these commands, be carefull to use capital letters exactly as shown:

net user guest /active:yes

( this enables the guest account, necessary for XP-Home Simple File
Sharing )

ntrights +r SeNetworkLogonRight -u Guest

( This grants the user 'Guest' the rights to log on across the network )

ntrights -r SeDenyNetworkLogonRight -u Guest

( This ensures the Guest account is not explicitly prohibited from accessing
the machine across the network. )

Then check this worked by using these commands:

showpriv SeNetworkLogonRight
showpriv SeDenyNetworkLogonRight

Ensure the Guest account is listed in the first, and not in the second.