Serva Troubleshooting

1 Nothing Seems to Work

No errors, everything looks fine but there is not traffic at all or some particular protocol appears non-responsive?
Time to check your Firewall

2 Cryptic Binding Errors

The process of offering an IP service involves a binding call where the server application tells the OS its intentions of using a particular "socket".
A socket is a network abstraction characterized by a unique combination of the following:

  1. Protocol: A transport protocol (e.g., TCP, UDP), raw IP, or others.
  2. Local Socket Address: Local Network Address and Port Number
  3. Remote Socket Address: Remote Network Address (only required for established TCP sockets)

When an application tries to use a particular socket already used by some other process it usually triggers an OS error.

i.e. Calling Serva on a Vista PC trying to offer SNTP services on every available IP it gives:

The former error tell us specifically where the problem is located but if we call Serva trying to offer SNTP services on just only one IP (i.e. the OS says:

In this particular case the error message is a bit more cryptic not telling us much about who causes the error. On these situations we can just turn Serva services off one-by-one and pinpoint the protocol is causing trouble.
A more methodic approach requires of a command console session running:

>netstat –ao

In this case we also come to the conclusion SNTP was the Serva offending service. As we can see on the next image the UDP protocol/port 123 pair was already offered on every available interface (IP= of our PC while Serva was trying to bind exactly the same parameters.

The Process ID was 1504, invoking the task manager we can find who is PID=1504; in this case it was W32Time (Windows Time Service)
We can stop W32Time running a command console as administrator by typing

>net stop w32time 

Stopping W32Time frees the taken socket resources. We can now call Serva with the SNTP service on and we'll see that the previous error is gone.
In order to leave everything as it was before we stop Serva and run

>net start w32time  

This was just a troubleshooting example, other protocols and other binding errors can be handled in a similar way.


3 Multi-homed hosts and Serva's bound outgoing traffic

When Serva (running on a multi-homed host) binds a protocol to an specific interface IP, it does bind the "listening" and the "talking". But Microsoft does not behave like Linux here; it is known that the binding to an specific IP when sending packets is only honored under Vista and later OSs (with some obscure exceptions). Former OSs (Win2K, XP, etc) have an extra routing layer added by the OS that can finally alter the interface chosen for packet delivery. The way to "solve" this situation (if necessary) involves user defined static routes.