Pocket PC Networking, AutoBind and Transparent Local Proxies

by **U2VhbiBIb3dhcnRo** » Thu, 20 Oct 2005 02:45:08 GMT

[Sorry if you've seen this before, but I was directed to repost this here
instead of its original location].

Folks,

We're trying to develop an application for Windows Mobile 5 that uses an LSP
to redirect connections (particularly those from IE) to a local proxy, which
munges the traffic in various ways and sends it out over the network.
There's a corresponding proxy on the Internet that un-munges the data and
passes it along to the content server as if we were never there.

This approach seems to work fine on earlier Windows Mobile platforms (e.g.,
Pocket PC 2003), but we're running into trouble with Windows Mobile 5. It
seems that our connections to the local proxy aren't getting through: we
either get a host unreachable error or a timeout, depending on the network
configuration. Having done a bit of digging, we suspect that this might be
caused by the new AutoBind LSP that ships with WM5. It appears that this
LSP, working in conjunction with the Connection Manager and IE, is
automatically binding IE's sockets to a particular interface corresponding to
a "real" network connection. That is, when IE calls bind, the socket gets
bound to a real IP address, like 169.x.y.z (for ActiveSync) or 10.191.0.4
(for an Ethernet connection on our LAN). Thus, when we try to connect to
127.0.0.1, the real network interface to which the socket is bound doesn't
know what to do--hence the timeouts and errors.

When we use a test program, which doesn't use the Connection Manager, our
sockets don't get bound to a particular interface when we call bind()--the
address returned by getsockname() is 0.0.0.0--and connections are redirected
to the local proxy without difficulty.

Can anyone confirm our analysis of what's going on?

More importantly, is there any reasonable way to make an application like
ours work on WM5? Assuming we're not grossly misunderstanding what's
happening, the AutoBind functionality would seem to make redirecting
connections to a local proxy difficult for anyone.

Thanks in advance for any assistance you can provide.

by **Ajay Agrawal** » Thu, 20 Oct 2005 17:26:12 GMT

Can you provide information on how did you install your LSP?

Since you are facing this problem, I would assume that you must have been
installed on top of LSP chain.
I have fixed similar problem by installing your LSP on the top of SSL LSP.
You would need to ignore Autobind and DTPT lsp.

Thanks,
-Ajay
-------------------------------------------

by **Omar [MS]** » Thu, 27 Oct 2005 04:09:50 GMT

You analysis is pretty much correct.
For sockets which are explicitly bound to a specific interface you should be
able to avoid the problem.
A couple of solutions you may want to consider are:
If you have an LSP (which is on top of autobind) you can try to forcibly
bind the socket before autobind determines that it should bind it somewhere.
You could install your LSP below autobind and intercept its bind and
setsockopt calls which bind the socket to a specific interface.

Thanks,
- Omar

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send
email directly to this alias. This alias is for newsgroup purposes only.

by **U2VhbiBIb3dhcnRo** » Thu, 27 Oct 2005 04:21:03 GMT

hanks for the response. You are correct that we are installing on top of
the LSP chain, above AutoBind and DTPT. We will try your suggestion, but
have some concerns:

1) From the documentation I've seen, it sounds like AutoBind provides some
significant functionality in WM5. Won't ignoring it have harmful side
effects?

2) Ditto for DTPT--will removing it break network access via desktop
passthrough?

3) We did a quick test, assembling an LSP chain that did not include
AutoBind and DTPT, but things still didn't work. This may be the result of
an error on our part, however, so we're still investigating.

Since my original post, we have tried a couple workarounds. In particular,
we've tried binding the listen port in our proxy to the specific interface
that AutoBind seems to be binding IE connections to, but we still can't
redirect: we still get timeouts (for simulated ethernet in the emulator) or
host unreachable errors (using ActiveSync for network access).

It's interesting to note that when we modify our test program to explicitly
bind to the same interface (via an ordinary call to bind), redirection works
fine. It seems that the automatic binding performed by the AutoBind LSP is
in some way stronger than an ordinary bind. Also, when we modify our test
program to use the Connection Manager API (which seems to trigger AutoBind),
it performs just like IE and redirection fails.

Any thoughts? We've been pounding our heads against the wall on this one
for a while now, but haven't had any flashes of inspiration.

Thanks...

"Ajay Agrawal" wrote:

by **Ajay Agrawal** » Thu, 27 Oct 2005 13:44:01 GMT

es, you right! There might be some side effects. I am also not sure of
that!
I would say this is just a work around for time being, till MSFT (or WE)
come up with some solution.

Please also look at the other post with subject " LSP on WinCE4.2 (extremely
painful)" and "LSP
on the top of Autobind_lsp" at "microsoft.public.pocketpc.developer".

Thanks,
-Ajay
---------------------------------------------------------------------------------
"Sean Howarth" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

by **Ajay Agrawal** » Thu, 27 Oct 2005 18:00:24 GMT

Just want to add here, after removing Autobind_lsp and DTPT, I did not see
any issue as such. I was still able to connect using pasthru usnig
Activesync. I tested IE and outlook was working. So not sure what other
issue may arise if Autobind / DTPT are removed.
-Ajay

"Ajay Agrawal" < XXXX@XXXXX.COM > wrote in message
news:% XXXX@XXXXX.COM ...

by **U2VhbiBIb3dhcnRo** » Tue, 01 Nov 2005 09:04:02 GMT

hanks for the reponse. We've tried layering beneath AutoBind, but above
DTPT, and redirection now works. That's the good news.

The bad news is that we're not seeing an ioctl/setsockopt that looks like it
might be coming from AutoBind. In fact, it doesn't look like the interface
is getting bound at all: getsockname() returns 0.0.0.0. Superficially, it
appears as though our layering beneath AutoBind has somehow broken it. Are
there any tricks or caveats we should be aware of? Does the AutoBind LSP
make any assumptions about who is underneath it?

Thanks again.

"Omar [MS]" wrote:

by **U2VhbiBIb3dhcnRo** » Tue, 01 Nov 2005 09:06:02 GMT

Thanks for the additional info. We were mostly worried that disabling
AutoBind might cause problems in multi-homed network scenarios and cause
traffic to go out over the "wrong" interface. We also found that passthrough
worked when DTPT was removed--I have no idea what was happening there...

by **Omar [MS]** » Tue, 01 Nov 2005 15:20:34 GMT

don't think autobind cares who is below it.
Are using an application which is using Connection Manager? Autobind will
only do a bind if ConnMgr tells it to bind a particular process to a
particular ip interface. So you need some app using ConnMgr API's so that
ConnMgr tells autobind to do a hard-bind.

Thanks,
- Omar

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Please do not send email directly to this alias. This alias is for
newsgroup purposes only.

"Sean Howarth" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...

by **U2VhbiBIb3dhcnRo** » Wed, 02 Nov 2005 03:47:03 GMT

Thanks again. The applications we're testing against (Pocket IE and our own
test app) use ConnMgr, and we see the hard bind (via getsockname()) when
we're not layered below AB. For now, we'll assume that we're not installed
and/or layered properly and go from there--hopefully it's something
straightforward.

by **U2VhbiBIb3dhcnRo** » Sat, 05 Nov 2005 13:00:01 GMT

K, we've been able to get things working using the WM 5 emulator: we see the
ioctl generated by AutoBind, and by blocking it, we're able to prevent the
connection from being hard-bound to the network interface.

However, when we try to load our LSP on an actual device, it never runs. In
previous releases, our application loaded the LSP manually when it ran at
boot time. For WM 5, we're trying to install the LSP the recommended way via
the registry, but it doesn't seem like our DLL is ever invoked.

Any thoughts as to why this might be happening? Does the system do any
logging in the process of loading LSPs that might give us a clue? The weird
thing is that it works perfectly in the emulator, but we just can't get it to
happen on an actual device.

"Omar [MS]" wrote:

Pocket PC Networking, AutoBind and Transparent Local Proxies

Pocket PC Networking >> AutoBind and Transparent Local Proxies

Pocket PC Networking >> AutoBind and Transparent Local Proxies

Pocket PC Networking >> AutoBind and Transparent Local Proxies

AutoBind and Transparent Local Proxies

AutoBind and Transparent Local Proxies

AutoBind and Transparent Local Proxies

AutoBind and Transparent Local Proxies

AutoBind and Transparent Local Proxies

AutoBind and Transparent Local Proxies

AutoBind and Transparent Local Proxies

AutoBind and Transparent Local Proxies