Retail Products:

Winsock LSP conflicts explained

Background on LSP chain links

Winsock LSP architecture is like a chain, first link is the network application and the last link is the TCP/IP stack. In the middle there are the LSP links, when there’s only one LSP then there’s no problem because the flow is: Application->LSP->Stack. In case we have two LSPs (I never saw three LSPs in a chain, although it’s possible) the flow is: Application->LSP1->LSP2->Stack.

Background on IFS vs Non IFS LSP

This topic is covered in depth in the article: IFS vs Non IFS LSP in this part I will summarize only the background needed for this article. Because Non IFS LSP gives out a converted I/O handle it can be anywhere within the chain, if we look at the example in the last section then a Non IFS LSP can be either LSP1 or LSP2, there’s no limitation. However IFS LSP gives out special XFS handles which are the real OS handles which means that it must be closest to the network stack, refering to the example from the last section it means that an IFS LSP can only be LSP2.

Conflicts because of requirement of position

Some LSPs “demand” to be at a certain location, they must be first, or last and not because of architectual requirements (IFS LSP), and when placed in a wrong location because of other LSP they don’t work because the programmer decided they will not work.

Conflicts because of bad installer

Some LSP installer are just poorly written and they don’t know how to handle another LSP in the stack, or they just layer over all providers (because it’s the easiest thing to do, but not the smartest) resulting in a number of wierd LSP chains which kill the network stack.

Conflicts because of installer race condition

This conflicts occurs because of two installers, each trying to position the LSP at certain location, for example both try to place the LSP at first or last resulting in a never ending race condition (I’m assuming the installers are OK).

Conflicts because of misplaced IFS LSP

This is an easy one, placing IFS LSP as the first LSP will kill the network, this can occur due to any one of the three last sections.

LSP Bypass

This is not a conflict per se, what it means is that LSP1 will bypass LSP2 when creating the LSP chain (it will install directly over TCP/IP base providers and position itself as the top chain (this is a more complex information which is not covered here)).

Conflict resolution

When people ask me how to resolve LSP conflict I give the same answer:

  • Some LSPs just can’t work together.
  • Conflict resolution is done case by case, there’s no silver bullet solution.

At Komodia we have a protocol to investigate 3rd party LSP in order to find the best solution to resolve a conflict, but my best advise is: You don’t install two Anti Virus products, you don’t install two Firewall products then don’t install two LSPs, before you install your LSP detect if the system already have a LSP installed and alert the user (if you are aggresive you can remove it yourself).