AN006. Using Device Server Toolkit with Windows Firewall (XP/SP2)

Top  Previous  Next

 

What's in this Application Note

 

This Application Note explains how to use  TibboDevice Server Toolkit (DST) on PCs running Windows XP with Service Pack2 (XP/SP2). One of the new components included in the SP2 is a Windows Firewall. Unless setup correctly, the Firewall will prevent certain features of DST software from operating properly.

 

This Application Note assumes that you are running DST version 3.56 (or later one). This version had certain adjustments made to enable DST use under Windows Firewall.

 

Contents:

 

- Using auto-discovery access mode of  DS Manager with Windows Firewall

- Manual way of making the auto-discovery mode work

- Why Windows Firewall needs configuration for auto-discovery to work

- Opening the Firewall for DS data connections

 

Using auto-discovery access mode of DS Manager with Windows Firewall

 

One difference you will immediately notice after XP2 is installed and the Firewall is enabled is that the DS Manager can no longer find local Device Servers in the auto-discovery access mode (address book mode continues to operate properly). You can find an explanation on why this is happening later in this Note.

 

Once you run the DS Manager (or click Refresh in the auto-discovery mode), and provided that your Firewall is using default configuration, you will get this warning message:

 

an006_auto_warning

This message means that Windows Firewall has detected certain network activity that is currently not allowed. Application name is "Run DLL as an App" and, believe it or not, this is how Windows sees the DS Manager (yes, DS Manager is a "DLL" but Windows should be smart enough to understand its "real name".... alas, it isn't that smart). Click Unblock and the DS Manager will be able to auto-discover local Device Servers again.

 

If, when you run the DS Manager (click Refresh), the warning is not displayed (and the DS Manager is still unable to find Device Servers) then this may be because the Firewall is not allowing "exceptions" and/or firewall notifications are not enabled.

 

Run the Firewall (Start--> Control Panel--> Windows Firewall) and make sure that Don't allow exceptions checkbox is unchecked (clear):

 

an006_enable_exceptions

Next, click on the Exceptions tab and make sure that Display a notification when Windows Firewall blocks a program checkbox is checked:

 

an006_enable_notifications

 

After you "unblock" the DS Manager the Firewall puts it into the list of "exceptions" i.e. programs whose traffic is allowed to pass through the Firewall:

 

an006_unblocked_dsm

 

Manual way of making the auto-discovery mode work

 

Same result can be achieved by telling the Firewall which port on the PC should be opened. To do this click on the Exceptions tab of the Windows Firewall dialog, then press Add Port... button- Edit a port dialog will open:

 

an006_add_port

 

Input any meaningful name into the Name textbox (i.e. "DSMan bcast"- this is because what we are opening here is a port for DS Manager's auto-discovery broadcasts to work). In the Port number textbox input 65534- this is the port number that must be opened on your PC. Finally, select UDP- this is a protocol the DS Manager is using to find Device Servers on the network. Click OK when finished.

 

New entry will appear in the list of exceptions and the DS Manager will start working properly:

 

an006_bcast_enabled

 

Why Windows Firewall needs configuration for auto-discovery to work

 

This section explains why auto-discovery access mode will work only after you configure the Windows Firewall properly while address book access mode will require no adjustment to the Firewall setup. You can happily skip this section if you are not that interested to know.

 

In the auto-discovery access mode the DS Manager finds Device Servers on the network by sending Echo (X) command as UDP broadcast. Every Tibbo Device that receives this broadcast will respond to it and the DS Manager will build a list of available Device Servers basing on received responses.

 

Trouble with Windows Firewall arises because the Firewall cannot link received responses to the broadcast sent from the PC. So, from the Firewall's point of view these responses are individual incoming UDP "connections" and by defaults the firewall blocks any incoming connection unless it is explicitly allowed. By unblocking "Run DLL as an App" or manually opening UDP port 65534 you let the responses from Device Servers to pass through. Port 65534 is the port from which the DS Manager is sending its broadcasts and to which all local Device Servers send their replies.

 

Contrary to what you'd probably expected, Windows Firewall does not interfere with DS Manager's operation in the address book access mode. This is because in this mode the DS Manager sends Echo (X) command individually to each DS in the device list (no broadcasts are used at all). When replies are received from Device Servers the Firewall is able to link those replies to the requests that were sent by the DS Manager earlier. The Firewall then assumes that these were outgoing connections initiated by a program on the PC and doesn't block incoming replies.      

 

Opening the Firewall for DS data connections

 

Windows Firewall monitors all incoming connections and that means that if your DS is supposed to connect to the VSP on the PC (or directly to your application) then a specific port (to which the DS will be connecting) must be opened on the Firewall.

 

For example, if you know that the DS will be opening a TCP connection to the VSP "COM3" with listening port number 1001 then you need to "open" this port in the Firewall. Use Add port... feature to do this:

 

an006_data_port

 

Notice, that you only need to open ports if your DS is going to connect to your PC. If it is the VSP (or application) on your PC that is going to connect to the DS then you don't need to setup the Firewall. This is because the Firewall doesn't block any connections that originate from within the PC.