Hello all

Thax for the suggestions if any.


The work is meant for Windows CE. Some of the questions are generic to
all of Windows.

Ethernet, WAN
=============

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 new hook
function addresses.
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 addresses etc.
might cause system exceptions in CE. doen't it?).

2. If yes, then Ethernet is okay. Meaning, it sits between tcpip and
Ndis

3. But for WAN cases in CE, TCP/IP talks to PPP(No Ethernet emulation
like NT/2K).
PPP is a NDIS protocol driver in CE.
So how do you hook this driver between these 2 protocols drivers?

3. If its not possible, Does a TDI driver type work in WAN case?


Bluetooth
=========

In case of bluetooth, different profiles use different stack paths( at
least in CE )

Examples

1. A Serial port application goes thru RFCOMM to L2CAP
2. PAN NDIS driver goes to L2CAP directly. (I think TCP/IP talks to
PNDIS).
3. LAN access profile goes thru TCP/UDP --> IP --> PPP ---> RFCOMM
---> L2CAP.

How would one control bluetooth activities?

a. Since more than 90% of the data flow goes thru L2CAP(rare cases
hit HCI directly), Is there a way to develop a driver just above
L2CAP and analyze the packets? Of course this may not be the useful
place for encrypted packets, but we can control some.

b. HCI Stack Extension Layer could be a solution?. If we develop
one of this over L2CAP, could we selectively block the traffic?

c. Any kind of hooking filter or TDI driver is helpful for this
traffic?


Thanks for the help and suggestions.

Ganesan

Packect Filters/Drivers by Steve

Steve
Tue Nov 02 14:34:12 CST 2004

Ganesan,

Just a reminder in case you didn't see my previous
replies, our DNE
(www.deterministicnetworks.com/Products/dne.asp) product
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).


Steve
>-----Original Message-----
>Hello all
>
>Thax for the suggestions if any.
>
>
>The work is meant for Windows CE. Some of the questions
are generic to
>all of Windows.
>
>Ethernet, WAN
>=============
>
>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
new hook
>function addresses.
> 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
addresses etc.
>might cause system exceptions in CE. doen't it?).
>
>2. If yes, then Ethernet is okay. Meaning, it sits
between tcpip and
>Ndis
>
>3. But for WAN cases in CE, TCP/IP talks to PPP(No
Ethernet emulation
>like NT/2K).
> PPP is a NDIS protocol driver in CE.
> So how do you hook this driver between these 2
protocols drivers?
>
>3. If its not possible, Does a TDI driver type work in
WAN case?
>
>
>Bluetooth
>=========
>
>In case of bluetooth, different profiles use different
stack paths( at
>least in CE )
>
>Examples
>
> 1. A Serial port application goes thru RFCOMM to L2CAP
> 2. PAN NDIS driver goes to L2CAP directly. (I think
TCP/IP talks to
>PNDIS).
> 3. LAN access profile goes thru TCP/UDP --> IP -->
PPP ---> RFCOMM
>---> L2CAP.
>
>How would one control bluetooth activities?
>
> a. Since more than 90% of the data flow goes thru
L2CAP(rare cases
>hit HCI directly), Is there a way to develop a driver
just above
>L2CAP and analyze the packets? Of course this may not be
the useful
>place for encrypted packets, but we can control some.
>
> b. HCI Stack Extension Layer could be a solution?. If
we develop
>one of this over L2CAP, could we selectively block the
traffic?
>
> c. Any kind of hooking filter or TDI driver is
helpful for this
>traffic?
>
>
>Thanks for the help and suggestions.
>
>Ganesan
>.
>

Re: Packect Filters/Drivers by Thomas

Thomas
Tue Nov 02 16:38:42 CST 2004

No, Steve, I think we have all missed most of your DNE advertisements! They
are fairly prolific. I know that if I promoted my products as blatantly as
you do that no one would notice either.

Instead of simply advertising your product's merits, at least provide some
useful information in your adds.

Thomas F. Divine

"Steve Jackowski" <stevej@deterministicnetworks.com> wrote in message
news:13fa01c4c11b$4fe65770$a501280a@phx.gbl...
> Ganesan,
>
> Just a reminder in case you didn't see my previous
> replies, our DNE
> (www.deterministicnetworks.com/Products/dne.asp) product
> 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).
>
>
> Steve
>>-----Original Message-----
>>Hello all
>>
>>Thax for the suggestions if any.
>>
>>
>>The work is meant for Windows CE. Some of the questions
> are generic to
>>all of Windows.
>>
>>Ethernet, WAN
>>=============
>>
>>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
> new hook
>>function addresses.
>> 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
> addresses etc.
>>might cause system exceptions in CE. doen't it?).
>>
>>2. If yes, then Ethernet is okay. Meaning, it sits
> between tcpip and
>>Ndis
>>
>>3. But for WAN cases in CE, TCP/IP talks to PPP(No
> Ethernet emulation
>>like NT/2K).
>> PPP is a NDIS protocol driver in CE.
>> So how do you hook this driver between these 2
> protocols drivers?
>>
>>3. If its not possible, Does a TDI driver type work in
> WAN case?
>>
>>
>>Bluetooth
>>=========
>>
>>In case of bluetooth, different profiles use different
> stack paths( at
>>least in CE )
>>
>>Examples
>>
>> 1. A Serial port application goes thru RFCOMM to L2CAP
>> 2. PAN NDIS driver goes to L2CAP directly. (I think
> TCP/IP talks to
>>PNDIS).
>> 3. LAN access profile goes thru TCP/UDP --> IP -->
> PPP ---> RFCOMM
>>---> L2CAP.
>>
>>How would one control bluetooth activities?
>>
>> a. Since more than 90% of the data flow goes thru
> L2CAP(rare cases
>>hit HCI directly), Is there a way to develop a driver
> just above
>>L2CAP and analyze the packets? Of course this may not be
> the useful
>>place for encrypted packets, but we can control some.
>>
>> b. HCI Stack Extension Layer could be a solution?. If
> we develop
>>one of this over L2CAP, could we selectively block the
> traffic?
>>
>> c. Any kind of hooking filter or TDI driver is
> helpful for this
>>traffic?
>>
>>
>>Thanks for the help and suggestions.
>>
>>Ganesan
>>.
>>



Re: Packect Filters/Drivers by nonsense64

nonsense64
Wed Nov 03 09:53:17 CST 2004

I wish I could tell my company, go and buy this product. Only
difference is I will be FIRED!!! :)

Its also very interesting and a good experience to write SIMPLE
drivers/filters.

As you go lower in the compter architecture, the problem will be
documentation is less and most of the books cover just the simple
basics.

Take it easy Mr.Steve. There will be lot of people to buy your
software.

Ganesan


"Thomas F. Divine [DDK MVP]" <tdivine@NOpcausaSPAM.com> wrote in message news:<uEg7#ySwEHA.2116@TK2MSFTNGP14.phx.gbl>...
> No, Steve, I think we have all missed most of your DNE advertisements! They
> are fairly prolific. I know that if I promoted my products as blatantly as
> you do that no one would notice either.
>
> Instead of simply advertising your product's merits, at least provide some
> useful information in your adds.
>
> Thomas F. Divine
>
> "Steve Jackowski" <stevej@deterministicnetworks.com> wrote in message
> news:13fa01c4c11b$4fe65770$a501280a@phx.gbl...
> > Ganesan,
> >
> > Just a reminder in case you didn't see my previous
> > replies, our DNE
> > (www.deterministicnetworks.com/Products/dne.asp) product
> > 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).
> >
> >
> > Steve
> >>-----Original Message-----
> >>Hello all
> >>
> >>Thax for the suggestions if any.
> >>
> >>
> >>The work is meant for Windows CE. Some of the questions
> are generic to
> >>all of Windows.
> >>
> >>Ethernet, WAN
> >>=============
> >>
> >>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
> new hook
> >>function addresses.
> >> 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
> addresses etc.
> >>might cause system exceptions in CE. doen't it?).
> >>
> >>2. If yes, then Ethernet is okay. Meaning, it sits
> between tcpip and
> >>Ndis
> >>
> >>3. But for WAN cases in CE, TCP/IP talks to PPP(No
> Ethernet emulation
> >>like NT/2K).
> >> PPP is a NDIS protocol driver in CE.
> >> So how do you hook this driver between these 2
> protocols drivers?
> >>
> >>3. If its not possible, Does a TDI driver type work in
> WAN case?
> >>
> >>
> >>Bluetooth
> >>=========
> >>
> >>In case of bluetooth, different profiles use different
> stack paths( at
> >>least in CE )
> >>
> >>Examples
> >>
> >> 1. A Serial port application goes thru RFCOMM to L2CAP
> >> 2. PAN NDIS driver goes to L2CAP directly. (I think
> TCP/IP talks to
> >>PNDIS).
> >> 3. LAN access profile goes thru TCP/UDP --> IP -->
> PPP ---> RFCOMM
> >>---> L2CAP.
> >>
> >>How would one control bluetooth activities?
> >>
> >> a. Since more than 90% of the data flow goes thru
> L2CAP(rare cases
> >>hit HCI directly), Is there a way to develop a driver
> just above
> >>L2CAP and analyze the packets? Of course this may not be
> the useful
> >>place for encrypted packets, but we can control some.
> >>
> >> b. HCI Stack Extension Layer could be a solution?. If
> we develop
> >>one of this over L2CAP, could we selectively block the
> traffic?
> >>
> >> c. Any kind of hooking filter or TDI driver is
> helpful for this
> >>traffic?
> >>
> >>
> >>Thanks for the help and suggestions.
> >>
> >>Ganesan
> >>.
> >>

Re: Packect Filters/Drivers by Maxim

Maxim
Wed Nov 03 14:48:39 CST 2004

> Take it easy Mr.Steve. There will be lot of people to buy your
> software.

Do you know the Steve's price? :)

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com



Re: Packect Filters/Drivers by nonsense64

nonsense64
Thu Nov 04 10:35:22 CST 2004

I just saw it. Earlier I didn't notice the link with Steve's
response..
Looks like their product work with several platforms. It costs a lot.
And a lot of companies use them.

"No need to learn how to build CE drivers" is one of bullets about
about DNE product.

Exactly the opposite of what I am doing. I only have know driver, rest
is not tough (because done by some other company, packet states ,
detect attacks etc.).

I guess didn't say anything wrong. Also I don't mind, if some one is
trying to sell their products here. I am new to discussions anyway.

Sorry Steve, Hopefully I have not offended you.

Hope I will get some answers(suggestions) for my questions.

ganesan





"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message news:<uHOR7ZewEHA.2012@TK2MSFTNGP15.phx.gbl>...
> > Take it easy Mr.Steve. There will be lot of people to buy your
> > software.
>
> Do you know the Steve's price? :)