Wi-Fi disconnects when cradled

Hi,

I notice our Wi-Fi product tends to drop it's connection to the AP when we
cradle the devcie.

Is this new behavior expected with Windows Mobile 5.0? The connection
resumes when the device is uncradled.

Thanks,

Gary

Ryan
Thu Aug 18 11:15:17 CDT 2005

This is the expected behavior. When DTPT (Desktop Passthrough) is active
via ActiveSync, all other network adapters are unbound. When the device is
uncradled, all adapters are rebound.

Ryan
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"Gary Cuevas" <GaryCuevas@discussions.microsoft.com> wrote in message
news:E80E567F-1F3E-4D7B-A2A1-991C7F1A48C2@microsoft.com...
> Hi,
>
> I notice our Wi-Fi product tends to drop it's connection to the AP when we
> cradle the devcie.
>
> Is this new behavior expected with Windows Mobile 5.0? The connection
> resumes when the device is uncradled.
>
> Thanks,
>
> Gary

GaryCuevas
Thu Aug 18 12:53:19 CDT 2005

Thanks, Ryan.

Is there a way to disable this feature in WM 5.0, via an API call or a
registry setting?

Also, our Lead Wi-Fi Engineer is wondering about the rationale behind this
behavior.

Thanks,

Gary

"Ryan Ward (MSFT)" wrote:

> This is the expected behavior. When DTPT (Desktop Passthrough) is active
> via ActiveSync, all other network adapters are unbound. When the device is
> uncradled, all adapters are rebound.
>
> Ryan
> --
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Use of included script samples are subject to the terms specified at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Gary Cuevas" <GaryCuevas@discussions.microsoft.com> wrote in message
> news:E80E567F-1F3E-4D7B-A2A1-991C7F1A48C2@microsoft.com...
> > Hi,
> >
> > I notice our Wi-Fi product tends to drop it's connection to the AP when we
> > cradle the devcie.
> >
> > Is this new behavior expected with Windows Mobile 5.0? The connection
> > resumes when the device is uncradled.
> >
> > Thanks,
> >
> > Gary
>
>
>

coreyb
Thu Aug 18 14:18:09 CDT 2005

------=_NextPart_0001_2BA5263B
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Unforunately there is no way to disable this behavior as it presents a
potential security risk to the device, host desktop PC and to any networks
the host PC is connected to.

DTPT's purpose is to allow the device to have access to the host PC's
networks. If other connections are present when a DTPT connection is
active, then malicious parties could transfer spoofed packets to the device
that would seem to be coming from the desktop. This would allow them to
attack the DTPT service itself or to trick the device into responding to
these packets on the DTPT interface and then in turn on the host PC's
networks.

In addition, DTPT uses a 169.254.X.X address in order to not conflict with
any addresses the host machine might already have. No traffic would be
routed over that adapter if any other network were present.

I hope that fully answers your questions, Feel free to email me directly
if you would like to address the specifics of your situation and potential
workarounds.
-Corey
------=_NextPart_0001_2BA5263B
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Unforunately there is no way to disable this behavior as it presents a potential security risk to the device, host desktop PC and to any networks the host PC is connected to.
\par
\par DTPT's purpose is to allow the device to have access to the host PC's networks. If other connections are present when a DTPT connection is active, then malicious parties could transfer spoofed packets to the device that would seem to be coming from the desktop. This would allow them to attack the DTPT service itself or to trick the device into responding to these packets on the DTPT interface and then in turn on the host PC's networks.
\par
\par In addition, DTPT uses a 169.254.X.X address in order to not conflict with any addresses the host machine might already have. No traffic would be routed over that adapter if any other network were present.
\par
\par I hope that fully answers your questions, Feel free to email me directly if you would like to address the specifics of your situation and potential workarounds.
\par -Corey
\par }
------=_NextPart_0001_2BA5263B--

GaryCuevas
Thu Aug 18 19:15:04 CDT 2005

Thanks, we appreciate the detailed reply.

Gary

"Corey Burke [MS]" wrote:

> Unforunately there is no way to disable this behavior as it presents a
> potential security risk to the device, host desktop PC and to any networks
> the host PC is connected to.
>
> DTPT's purpose is to allow the device to have access to the host PC's
> networks. If other connections are present when a DTPT connection is
> active, then malicious parties could transfer spoofed packets to the device
> that would seem to be coming from the desktop. This would allow them to
> attack the DTPT service itself or to trick the device into responding to
> these packets on the DTPT interface and then in turn on the host PC's
> networks.
>
> In addition, DTPT uses a 169.254.X.X address in order to not conflict with
> any addresses the host machine might already have. No traffic would be
> routed over that adapter if any other network were present.
>
> I hope that fully answers your questions, Feel free to email me directly
> if you would like to address the specifics of your situation and potential
> workarounds