Issues for LSPs that connect to local host

re: Issues for LSPs that connect to local host

Ajay Agrawal — Wed, 07 Dec 2005 13:51:01 GMT

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

re: Issues for LSPs that connect to local host

Nisha George — Fri, 16 Dec 2005 11:43:05 GMT

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

re: Issues for LSPs that connect to local host

Svat — Tue, 17 Jan 2006 12:10:54 GMT

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.

re: Issues for LSPs that connect to local host

Igor Dvorkin [MS] — Sat, 04 Mar 2006 04:14:16 GMT

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.

re: Issues for LSPs that connect to local host

Rich Letsinger — Tue, 16 May 2006 01:39:57 GMT

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

re: Issues for LSPs that connect to local host

jason zhang — Fri, 20 Oct 2006 22:22:21 GMT

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.

re: Issues for LSPs that connect to local host

cenet — Wed, 25 Oct 2006 20:33:55 GMT

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.