From: Steve Jackowski (stevej_at_deterministicnetworks.com)
Date: Tue, 2 Nov 2004 12:34:12 -0800
Just a reminder in case you didn't see my previous
replies, our DNE
supports all interfaces on CE, WAN, Bluetooth, the
cradle, etc, support various tunnels, and lets you
develop cross-platform plugins. You can even develop and
debug on a standard Windows platform, then just recompile
and run on CE/PocketPC (or Linux, Solaris, etc).
>Thax for the suggestions if any.
>The work is meant for Windows CE. Some of the questions
are generic to
>all of Windows.
>Assumptions about NDIS hook filter driver:
> a. Ndis Hook driver resides between Tcpip.sys and
Ndis.sys (in NT/2K
> b. Replace NDIS.SYS function pointers(addresses) with
> c. So NDIS.SYS calls these new functions and new ones
can call the
>original functions etc.
>1. Under windows CE is this Ndis hook driver possible?
> (I guess YES. but usually replacing the NDIS.SYS
>might cause system exceptions in CE. doen't it?).
>2. If yes, then Ethernet is okay. Meaning, it sits
between tcpip and
>3. But for WAN cases in CE, TCP/IP talks to PPP(No
> PPP is a NDIS protocol driver in CE.
> So how do you hook this driver between these 2
>3. If its not possible, Does a TDI driver type work in
>In case of bluetooth, different profiles use different
stack paths( at
>least in CE )
> 1. A Serial port application goes thru RFCOMM to L2CAP
> 2. PAN NDIS driver goes to L2CAP directly. (I think
TCP/IP talks to
> 3. LAN access profile goes thru TCP/UDP --> IP -->
PPP ---> RFCOMM
>How would one control bluetooth activities?
> a. Since more than 90% of the data flow goes thru
>hit HCI directly), Is there a way to develop a driver
>L2CAP and analyze the packets? Of course this may not be
>place for encrypted packets, but we can control some.
> b. HCI Stack Extension Layer could be a solution?. If
>one of this over L2CAP, could we selectively block the
> c. Any kind of hooking filter or TDI driver is
helpful for this
>Thanks for the help and suggestions.