Issues for LSPs that connect to local host


As discussed in my previous post, the autobind_lsp performs
hard binding.  This will cause issues for LSPs that need to connect to
localhost.  

About hard binding:

Hard binding is a per socket TCP options specified by:
    WSAIoctl(..., SIO_UCAST_IF,..). 

Once a socket is hard bound, all data on that socket must be
sent/received from the same adapter.  In hard binding, the loop back
adapter is a distinct adapter. 

When does hard binding cause a problem?

Hard binding causes a problem when you want your LSP to
connect to local host after a hard bind has occurred. In this case, you do not
want the hard binding to occur.  

Example of common failure:

        step 1) App:
connect (10.10.10.10)
        step 2) autobind_lsp:
bind  (10.10.10.10)
        step 3) autobind_lsp:
WSAIoctl(…, SIO_UCAST_IF, …)
        step 4) autobind_lsp:
connect (10.10.10.10)
        step 5)
YourProxy_LSP: connect_to_your_proxy_server  (127.0.0.1:1080)

step 5) Will fail since your socket is already hard bound to
adapter 10.10.10.10. 

The work around:

A work around is to layer your LSP under autobind, and 
not propagate the SIO_UCAST_IF IOCTLs to the next LSP in the stack.


When you should use the work around:

This work around should only be used for sockets on which
your LSP is explicitly proxying all data to a component you control. If
your LSP is not doing this, the workaround should not be used.

[Author: Igor Dvorkin]

Comments (7)
  1. Ajay Agrawal says:

    I created a new LSP chain like this:-
    Autobind->myLSP->SSL->DTPT->base.

    In order to load my LSP in the last, I have created Order Key for Autobind and SSL, so that myLSP loads last and my chain is on the top.

    But in this case I see Autobind is not getting loaded by Device.exe, though I see it loaded by connmgr. Is it expected behavior?

    I did not see SIO_UCAST_IF in WSPIoctl() of myLSP?

    Any idea? What I am missing here?

    Thanks,
    -Ajay

  2. Nisha George says:

    Hi Igor,

    I am an LSP beginner.We are trying to develop an LSP taht would block certain applications from sending out TCP/IP data.Basically we want to block the connect in certain specific situations.The target devices are PocketPC 2003, CE 4.2, CE 5.0 amd WM5.0.Could you provide info on how to go about this ?I am a bit confused as to how the application chooses the specific chain on which my LSP is sitting.This doubt as we have no way to modify applications as the solution has to cater to any third party application which the user wishes to block.Writing a winsock wrapper also seems a bit far fetched.Could you please mention your contact mail-id ?

    Thanx in advance,

    Nisha

  3. Svat says:

    Hello Igor,
    You are well known through forums as LSP specialist so could you
    please drop any idea about following LSP issue.
    When installed at Windows smartphone 4.2 (Motorolla MPx220 or emulator)
    it conflicts with default e-mail client (tmail.exe) with following
    error:
    The following errors occurred while sending and receiving mail:
    An error occurred while downloading messages.Verify that you have
    network coverage and that your account information is correct and then try again.

    With any other network application (OPERA, MSN Messenger…) LSP
    works fine without any unexpected errors.
    Could you please advise solution or possible cause of this error.

    Thanks for your time and sorry for disturbing.

  4. Igor Dvorkin [MS] says:

    Svat – Are you getting this error when trying to use a POP provider that uses TLS? If so, your LSP has likely

    interfered with the SSLLSP. You can verify this by checking if a setsockopt (..SO_SECURE..) ends up going through your LSP.

    Nisha – most applications don’t specify what LSP to use. In this case, the first chain in the catalog, that meets the protocol/af/type triplet is used.

    Ajay – I believe your error is caused by a broken installer.

  5. Rich Letsinger says:

    Igor,

    I’m creating an LSP that proxies data so I need to intercept these SIO_UCAST_IF messages. However, I do not know if I will be proxying data for a socket until the connect call gives me the destination address. In most situations I’m seeing the WSPIoctl call before the WSPConnect. So at the time of the ioctl, I don’t know if I should propogate the call or not.

    My first thought is to block the message initially. Then, if I determine I won’t be proxying data on a given socket, go ahead and re-issue the ioctl call from the WSPConnect method. But if the socket is overlapped, I end up in an unpleasantly complicated situation. Suggestions?

    Thanks,

    Rich

  6. jason zhang says:

    igor,

    if it is possible mylsp just donot pass the bind() operation down to the lower LSP chain?

    in this case, I think autobind do not have chance to action.

  7. cenet says:

    Jason,

    It is not clear from your question whether you are layered below or above autobind.

    If you are above autobind the bind is not being called by the app anyway–autobind will do that below you when it sees the connect call.

    If you are below autobind–then you can block bind but there are issues with that, in that you probably won’t know the bind was called by the app or by autobind, and you probably don’t want to block the user’s bind operation. Also you’ll still have to block the WSAIoctl call.

Comments are closed.

Skip to main content