Prev: Uninstall NDIS Lightweight filter driver vista
Next: The intall process of NDIS IM driver hangs in vista sp1
From: HimaNshu on 5 Jan 2009 06:45
Hi,
I want to modify, GPRS packets in Windows Mobile 5.0.
I have modify Passthru,
--> WAN medium is added to array
--> I have implemented,
--> ndisMChars.WanSendHandler = MiniportSendWan;
--> ndisPChars.WanSendCompleteHandler =
ProtocolSendCompleteWan;
--> ndisPChars.WanReceiveHandler = ProtocolReceiveWan;

and able to load the with PASS\ASYNCMAC1 also try to query some TAPI
oid,
OID_TAPI_PROVIDER_INITIALIZE, OID_TAPI_GET_DEV_CAPS...
then after it never call any send or receive functions and also not
even query OIDs.
And never get connected with GPRS...

Please tell me the right way to create IM driver for WAN driver.

Thanks in advance
Himanshu
From: Maxim S. Shatskih on 5 Jan 2009 13:13
> --> ndisMChars.WanSendHandler = MiniportSendWan;
> --> ndisPChars.WanSendCompleteHandler =
> ProtocolSendCompleteWan;
> --> ndisPChars.WanReceiveHandler = ProtocolReceiveWan;

Now note that, with encrypted VPN or even encrypted serial traffic, your driver will see _encrypted_ data without the chances of modifying it.

> Please tell me the right way to create IM driver for WAN driver.

For WinCE 4.2 when I was playing with this, it was impossible except by hooking the "custom ARP" interface between TCPSTK and PPP DLLs.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: HimaNshu on 6 Jan 2009 07:30
Thanks Maxim,

If you see this thread,
http://groups.google.co.in/group/microsoft.public.windowsce.embedded/browse_thread/thread/fc2617166aa2e834?hl=en&ie=UTF-8&q=WAN+IM+driver+wince#81bda34d25b46e2d

they are able to plug IM Driver and able to capture GPRS packet. Do
you have any idea how it works? He got the PPP frame

For me we are not going to establish connection over VPN so it will
not be encrypted.

Yes, you are right that is not possible to plug hook between TCP/IP
and PPP layer, I have to capture above TCP stack (Using LSP) or below
PPP (Using IM Driver).
Above TCP will not help me, because only data will be there not IP
header.

That's I am looking for IM Driver for AsynMac and PPP...

If I check the log PPP layer doing query for
OID_TAPI_PROVIDER_INITIALIZE and it gets the return value as NULL
pointer so I think TAPI is not initialized

I have checked AsynMac code in Platform Builder 5.0, TAPI initializing
code is there that part I should not do I should just pass that query
using NdisRequest() to below layer same as in PASSTHRU driver

Is there any modification I should do to initialize TAPI in IM
Driver...?
Please check the log as below,

2/1/2009 00:51:01:12875 ---> MiniportQueryInformation
0x00010116:OID_GEN_VENDOR_DRIVER_VERSION
2/1/2009 00:51:01:12878 <--- MiniportQueryInformation InfoBuff 0x0,
BtWrtn 0, pulBtNeed 0
2/1/2009 00:51:01:12879 ---> MiniportQueryInformation
0x00010113:OID_GEN_MAC_OPTIONS
2/1/2009 00:51:01:12882 <--- MiniportQueryInformation InfoBuff 0x17,
BtWrtn 4, pulBtNeed 0
2/1/2009 00:51:01:12884 ---> MiniportQueryInformation
0x04010102:OID_WAN_CURRENT_ADDRESS
2/1/2009 00:51:01:12887 <--- MiniportQueryInformation InfoBuff
0x59534120, BtWrtn 6, pulBtNeed 0
2/1/2009 00:51:01:12888 ---> MiniportQueryInformation
0xfd010100:OID_PNP_CAPABILITIES
2/1/2009 00:51:01:12889 ---> MiniportDevicePnPEvent: pBinding 00770030
event 5
2/1/2009 00:51:01:12891 ---> ProtocolBindAdapter PIMD\ASYNCMAC1
2/1/2009 00:51:01:12893 <--- ProtocolBindAdapter: pBinding 00770030,
status 0
2/1/2009 00:51:02:13736 ---> MiniportQueryInformation
0x07030118:OID_TAPI_PROVIDER_INITIALIZE
2/1/2009 00:51:02:13737 <--- MiniportQueryInformation InfoBuff 0x0,
BtWrtn 0, pulBtNeed 0
2/1/2009 00:51:02:14024 ---> MiniportDevicePnPEvent: pBinding 00770030
event 5
2/1/2009 00:51:02:14177 ---> MiniportQueryInformation
0x07030110:OID_TAPI_GET_DEV_CAPS
2/1/2009 00:51:02:14178 <--- MiniportQueryInformation InfoBuff 0x0,
BtWrtn 0, pulBtNeed 0
2/1/2009 00:51:02:14187 ---> MiniportQueryInformation
0x07030110:OID_TAPI_GET_DEV_CAPS
2/1/2009 00:51:02:14189 <--- MiniportQueryInformation InfoBuff 0x0,
BtWrtn 0, pulBtNeed 0
2/1/2009 00:51:02:14194 ---> MiniportQueryInformation
0x07030110:OID_TAPI_GET_DEV_CAPS
2/1/2009 00:51:02:14195 <--- MiniportQueryInformation InfoBuff 0x0,
BtWrtn 0, pulBtNeed 0
2/1/2009 00:51:02:14200 ---> MiniportQueryInformation
0x07030110:OID_TAPI_GET_DEV_CAPS
2/1/2009 00:51:02:14201 <--- MiniportQueryInformation InfoBuff 0x0,
BtWrtn 0, pulBtNeed 0
2/1/2009 00:51:02:14206 ---> MiniportQueryInformation
0x07030110:OID_TAPI_GET_DEV_CAPS
2/1/2009 00:51:02:14207 <--- MiniportQueryInformation InfoBuff 0x0,
BtWrtn 0, pulBtNeed 0
2/1/2009 00:51:02:14214 ---> MiniportQueryInformation
0x07030110:OID_TAPI_GET_DEV_CAPS
2/1/2009 00:51:02:14215 <--- MiniportQueryInformation InfoBuff 0x0,
BtWrtn 0, pulBtNeed 0

.........keep querying OID_TAPI_GET_DEV_CAPS.......


Anybody else input also will help to find the direction...currently I
am total struck with OID_TAPI_PROVIDER_INITIALIZE,
OID_TAPI_GET_DEV_CAPS...

Himanshu
From: Maxim S. Shatskih on 6 Jan 2009 10:52
> Yes, you are right that is not possible to plug hook between TCP/IP
> and PPP layer, I have to capture above TCP stack (Using LSP) or below
> PPP (Using IM Driver).

Correct.

Sorry, my experience is limited to WinCE 4.2 5 years ago, so, probably I'm not much help here.

I can only tell you that, in 4.2, you could not plug your IM between TCP and PPP. Only below PPP, i.e. between PPP and the MAC driver. For VPNs, this means encrypted data.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

From: David R. Cattley on 6 Jan 2009 22:08
> they are able to plug IM Driver and able to capture GPRS packet. Do
> you have any idea how it works? He got the PPP frame

The PPP frame is available to an IM driver bound between an NDISWAN Miniport
(ASYNCMAC in this case or perhaps PPTP/L2TP) and the PPP 'protocol' driver
in Windows CE. However, there are many details of building such an IM
driver that are different from building a connectionless IM driver like
PASSTHRU.

The first detail is that the packet handling is completely different. The
WAN packet specific handlers MiniportWanSend() and ProtocolWanReceive() must
be registered instead of MiniportSend() and ProtocolRecieve(). The
ProtocolWanReceive() handler format is not specifically documented but you
can see its prototype in NDIS.H via the type WAN_RECEIVE_HANDLER. There are
corresponding NdisMWanXxx() routines and NdisWanXxx() routines for packet
transfer, completion, and return. Remember also that the packet format is
the NDIS_WAN_PACKET. For PPP it will contain 'simple HDLC framing'. For
SLIP, it will just be an IP packet. You do not need to worry about the old
RAS framing on Windows CE since it does not support it (just PPP and SLIP).

Second, all of the rules of an NDISWAN (legacy) miniport apply. Legacy WAN
miniports are 'serialized' miniports and you should become very familiar
with the restrictions of WAN miniports, especially how they process 'frames'
(packets). The mechanism is completely different than connectionless
miniports.

Third, the 'binding' is to a WAN Miniport but each WAN Miniport may at any
given time support multiple WAN (TAPI) Line Devices and may have multiple
'connections'. Since Windows Mobile support multiple APNs (simultaneous PPP
connections to more than one Cellular APN via ASYNCMAC), you must be
careful to undestand how to correlate packets to 'connections' if your
driver needs this capability.

Fourth, the interaction between the TAPI mechanism and the NDISWAN line
indications can be rather tricky. The TCPSTK.DLL will 'name' the interface
based on the TAPI line name (with some adjustments which differ by CE
version). To determine the IP interface name, you must monitor and track
the TAPI OIDs and capture some identifiers (LineId, CallId, etc.) to
associate the resulting ConnectionWrapperId/NdisLinkHandle/NdisLinkContext
values in the NDIS_MAC_LINE_UP/NDIS_MAC_LINE_DOWN status structures.

The PPP implementation is available in the shared source for CE 5.0 and CE
6.0. I think it is in ./PRIVATE/WINCEOS/COMM/PPP/.... You can gain
quite a bit of insight into how it works on CE by reading through the
sources. The WM5x implementations are similar enough to the CE 5.0 code as
to give you a good idea of what is going on.

> For me we are not going to establish connection over VPN so it will
> not be encrypted.

This is often handled by parsing the PPP packets during link negotiation to
ensure that link compression and encryption options are NAKed. Note too
that you must ensure that IP header compression is disabled as well since
otherwise you may not have enough data to reconstruct the IP header.

> Is there any modification I should do to initialize TAPI in IM
> Driver...?

That depends on what your driver needs to do. If all you need to do is
watch (PPP) packets, then, you should be able to simply pass the TAPI OIDs
through without change.

> ........keep querying OID_TAPI_GET_DEV_CAPS.......

The best thing to do is build a simple IM driver on CE5 Platform Builder and
'debug' with the shared source for PPP.DLL until you get the basics working.
When that is working, move to WM.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development


 |  Next  |  Last
Pages: 1 2 3
Prev: Uninstall NDIS Lightweight filter driver vista
Next: The intall process of NDIS IM driver hangs in vista sp1