Causes for unusual RAS State Transition

Platform: Windows CE 5.0, ARMV4I

I have a wireless interface stack that works well on other platforms
but on this one particular platform we are seeing RAS drop the
connection as soon as RAS reports state RASCS_Authenticated. We
typically see a RAS state transition to RASCS_Connected from
RASCS_Authenticated, instead we get RASCS_Disconnected. I have the
serial driver instrumented so know that there is not a COM event being
reported with EV_RLSD, EV_RING, EV_ERR, or EV_POWER.

I have not been able to get the SAMPLE TSPI to work, nor get a
replacement UNIMODEM to install. I have been able to replace ASYNCMAC
with my own so know for certain that the line is being torn down due
to some code forcing a state transition to LINECALLSTATE_IDLE.

Since the device is a commercial device I cannot change or instrument
the OS, nor is there any debug serial output.

Any thoughts as to reasons that RAS would behave like this?

Mark
Tue Jul 08 11:24:01 PDT 2008

Further Information:
I instrumented ASYNCMAC futher to report the OID's. During the course
of the connection attempt ASYNCMAC receives:
OID_TAPI_GET_DEV_CONFIG (4 times)
OID_WAN_GET_INFO
OID_TAPI_TRANSLATE_ADDRESS (2 times)
OID_TAPI_OPEN
OID_TAPI_MAKE_CALL
(limeMakeCall returns success here)
OID_TAPI_GET_ID (2 times)
OID_WAN_GET_LINK_INFO

Then MpSetInfo calls lineDrop
I get OID_GET_STATUS_INFO and then the call is disconnected.

Mark
Tue Jul 08 13:54:20 PDT 2008

Further Info:
The MpSetInfo is from a OID_TAPI_DROP command. The only place the appears
to use this is NdisTapiCallDrop which is called from Ndis TapiHangup. That
in turn can be called from pppMacDial or pppMac_Call_Close. The
pppMac_CallClose path splits more times. However, even if I block in the
OID_TAPI_DROP other calls into the ASYNCMAC driver on other threads cause
the connection to drop anyway. So at this point it appears as if the
OID_TAPI_DROP command is just cleanup from a higher level call.