Re: Porting NDIS intermediate driver to Linux
J de Boyne Pollard
PA> AFAIK, no. It is a Windoze bloatware thing; we don't need this in
Linux.
Please don't let silly knee-jerk prejudice inhibit actual
correctness. Pretty much all operating systems that support Internet
protocols have protocol stacks of some form. The clue is in the name
"TCP/IP". It stands for "TCP over IP". That's a stack of two
protocols, Transmission Control Protocol layered over Internet
Protocol. Hence similarly "UDP/IP" and indeed "ICMP/IP". Linux has a
networking stack, just like most other internetwork-capable operating
systems have. The solution domain largely models the problem domain
in this respect. Your favourite WWW search engine should be able to
quickly turn up M. Tim Jones' anatomical outline of it and Jonathan
Sevy's walkthrough of it. And that's just for starters.
Rainer Weikusat
> t> So, is there such a thing as stack?
> PA> AFAIK, no. It is a Windoze bloatware thing; we don't need this in
> Linux.
>
> Please don't let silly knee-jerk prejudice inhibit actual
> correctness. Pretty much all operating systems that support Internet
> protocols have protocol stacks of some form.
The question was related to a network interface driver. That's a
different 'stack' (if any).
alberto
We mustn't confuse protocol stacks with driver stacks. Linux doesn't
have the concept of driver stacks, it's a Windows thing.
Still, if you Google for "Linux Packet Filtering", you'll get more
information than you'll probably need!
Alberto.
On Dec 30, 10:59 am, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET>
wrote:
tanix
>t> So, is there such a thing as stack?
>
>PA> AFAIK, no. It is a Windoze bloatware thing; we don't need this in
>Linux.
>
>Please don't let silly knee-jerk prejudice inhibit actual
>correctness. Pretty much all operating systems that support Internet
>protocols have protocol stacks of some form.
I hope so.
:--}
Otherwise...
> The clue is in the name
>"TCP/IP". It stands for "TCP over IP". That's a stack of two
>protocols, Transmission Control Protocol layered over Internet
>Protocol. Hence similarly "UDP/IP" and indeed "ICMP/IP". Linux has a
>networking stack,
Cool. That is what I want to hear.
The next question is can I insert my NDIS driver equivalent
into the stack?
Yes or no.
> just like most other internetwork-capable operating
>systems have. The solution domain largely models the problem domain
>in this respect.
I like that one.
:--}
> Your favourite WWW search engine should be able to
>quickly turn up M. Tim Jones' anatomical outline of it and Jonathan
>Sevy's walkthrough of it.
Thanx for the pointers. But I am already talking here.
If you have some info, ideas, suggestions, fine.
> And that's just for starters.
--
Programmer's Goldmine collections:
Tens of thousands of code examples and expert discussions on
C++, MFC, VC, ATL, STL, templates, Java, Python, Javascript,
organized by major topics of language, tools, methods, techniques.
tanix
Well, my issue is basically can I have an equivalent of the NDIS
intermediate driver (protocol and miniport ends) in Linux.
Basically, NDIS intermediate driver is just fine with me.
I does guarantees me that I can do what I want to and that is
intercept any and all traffic and to be able to drop/allow
any of it depending on what updates to rule set the app dynamically
supplies to driver.
I need to be able to intercept the traffic from any app
and I need to control which traffic is to be allowed.
That's the whole point of it.
tanix
>
>We mustn't confuse protocol stacks with driver stacks. Linux doesn't
>have the concept of driver stacks, it's a Windows thing.
>
>Still, if you Google for "Linux Packet Filtering", you'll get more
>information than you'll probably need!
Well, I was trying to get some feedback here.
Looks like I do not have as much control under Linux as I have
under windows.
I need pending queues for all unknown traffic and with these tables
there is no such a concept. If you start some operation and it turns
out it may result in some unknown traffic, I'd like you to be able
to continue if you respond fast enough from the user level app, so
the app that generates this traffic isn't even aware that something
happened in terms of you creating new rules while it is simply
waiting for some traffic.
So, I need to have control over those queues, such as setting the
timeout times or deleting some entries on the queues and things
like that.
I do not see how this could be done with these tables.
>Alberto.
>
>
>On Dec 30, 10:59=A0am, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET>
>wrote:
>> t> So, is there such a thing as stack?
>>
>> PA> AFAIK, no. It is a Windoze bloatware thing; we don't need this in
>> Linux.
>>
>> Please don't let silly knee-jerk prejudice inhibit actual
>> correctness. =A0Pretty much all operating systems that support Internet
>> protocols have protocol stacks of some form. The clue is in the name
>> "TCP/IP". =A0It stands for "TCP over IP". =A0That's a stack of two
>> protocols, Transmission Control Protocol layered over Internet
>> Protocol. =A0Hence similarly "UDP/IP" and indeed "ICMP/IP". =A0Linux has =
>a
>> networking stack, just like most other internetwork-capable operating
>> systems have. =A0The solution domain largely models the problem domain
>> in this respect. =A0Your favourite WWW search engine should be able to
>> quickly turn up M. Tim Jones' anatomical outline of it and Jonathan
>> Sevy's walkthrough of it. =A0And that's just for starters.
Rainer Weikusat
> In article <69101f33-41d6-4a0f...@t12g2000vbk.googlegroups.com>, alberto <amor...@ieee.org> wrote:
>>
>>We mustn't confuse protocol stacks with driver stacks. Linux doesn't
>>have the concept of driver stacks, it's a Windows thing.
>>
>>Still, if you Google for "Linux Packet Filtering", you'll get more
>>information than you'll probably need!
>
> Well, I was trying to get some feedback here.
>
> Looks like I do not have as much control under Linux as I have
> under windows.
>
> I need pending queues for all unknown traffic and with these tables
> there is no such a concept. If you start some operation and it turns
> out it may result in some unknown traffic, I'd like you to be able
> to continue if you respond fast enough from the user level app, so
> the app that generates this traffic isn't even aware that something
> happened in terms of you creating new rules while it is simply
> waiting for some traffic.
What you basically want is to hook in the communication path between
some 'network protocol' and a device driver. Provided that IP is OK
for you, it should be possible to implement what you want to have with
a custom netfilter extension module providing a new target. This would
then need a single rule which 'redirects' some or all traffic to your
'target', which could then police it in arbitrary ways internally.
tanix
Well, we'd have to dig deeper into this thing.
But I still fail to see how can I implement the queues
for the unknown packets (traffic for which there are no rules).
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>>ta...@mongo.net (tanix) writes:
[...]
>>> I need pending queues for all unknown traffic and with these tables
>>> there is no such a concept. If you start some operation and it turns
>>> out it may result in some unknown traffic, I'd like you to be able
>>> to continue if you respond fast enough from the user level app, so
>>> the app that generates this traffic isn't even aware that something
>>> happened in terms of you creating new rules while it is simply
>>> waiting for some traffic.
>>
>>What you basically want is to hook in the communication path between
>>some 'network protocol' and a device driver. Provided that IP is OK
>>for you, it should be possible to implement what you want to have with
>>a custom netfilter extension module providing a new target. This would
>>then need a single rule which 'redirects' some or all traffic to your
>>'target', which could then police it in arbitrary ways internally.
>
> Well, we'd have to dig deeper into this thing.
> But I still fail to see how can I implement the queues
> for the unknown packets (traffic for which there are no rules).
With a catch-all rule, ie, one which just specifies a target (-j
<something>). But coming to think of it, the better idea might be to
extend the 'traffic control facility' (usually used for QoS). Some
user-level information about that is available here:
This is extensible in form of modules, too, although lesser used,
presumably, because of the extraordinarily poor documentation (there
is also a tc manpage). This would enable you to attach a so-called
'qdisc' (queueing discipline) to an interface which could basically
enforce an arbitrary 'communication policy' directly above the device
driver itself.
tanix
Thanx. I looked into that thing, and from what I saw so far, is WOW!
This is going to be a grand headache to port to from NDIS based
approach.
Yes, generality seems to be supreme and performance is probably
the best you can manage. But the amount of heeadaches you are going
to experience is something else.
>This is extensible in form of modules, too, although lesser used,
>presumably, because of the extraordinarily poor documentation (there
>is also a tc manpage). This would enable you to attach a so-called
>'qdisc' (queueing discipline) to an interface which could basically
>enforce an arbitrary 'communication policy' directly above the device
>driver itself.
Well, I just started to think what it all means in terms of porting
the intermediate NDIS driver and it almost cracked my head to even
think about this.
Basically, it can not be ported.
You'd have to rewrite the driver's end of your app and forget about
the very concept of driver, and forget about everything even
remotely related to it.
Quite dissapointing, I'd say.
That's probably at least a 3 month project, if you are lucky,
just to handle the "driver" end of it and completely remodel
your app so it generates all these insane marks, lil do I care
if they exist.
Tough.
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> wrote:
>>ta...@mongo.net (tanix) writes:
[tc]
>>This is extensible in form of modules, too, although lesser used,
>>presumably, because of the extraordinarily poor documentation (there
>>is also a tc manpage). This would enable you to attach a so-called
>>'qdisc' (queueing discipline) to an interface which could basically
>>enforce an arbitrary 'communication policy' directly above the device
>>driver itself.
>
> Well, I just started to think what it all means in terms of porting
> the intermediate NDIS driver and it almost cracked my head to even
> think about this.
Assuming that has a remotely sane structure, meaning, there is some
'entry point' the protocol module sitting above it uses to hand over
frames to it and some 'exit point' where frames supposed to be
transmitted again leave it, with 'some processing logic' in between,
it shouldn't be that difficult: Only the entry and exit points need
major adaptions. All of the tc stuff, that is, the qdisc, just
provides a way to hook your code into the network stack such that it
can police traffic. You don't need to care for any of the existing
queueing disciplines except insofar they might be useful as code
examples. Also, there is no reason to use the data channel for control
communication except if that happened to be convenient. A so-called
'character device', basically, a file an application can open to send
data to some kernel code and receive data from it, might be a better
choice.
Kaz Kylheku
> I need to be able to intercept the traffic from any app
> and I need to control which traffic is to be allowed.
Smells like a fine-grained security policy: SELinux.
Maxim S. Shatskih
> major adaptions.
No. The in-memory representation of a packet can also be different a lot.
For instance, in Windows/NDIS it is _discontiguous_ (this is done to allow the protocols to add headers by chaining one more buffer at front).
IIRC in Linux it is not so, the packets are allocated by the lowest level, with the size being calculated at the highest level (to include all headers). So, the packets are contiguous.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Rainer Weikusat
>> it shouldn't be that difficult: Only the entry and exit points need
>> major adaptions.
>
> No. The in-memory representation of a packet can also be different a
> lot.
Not really, since they necessarily contain data in the same format
somewhere.
> For instance, in Windows/NDIS it is _discontiguous_ (this is done to
> allow the protocols to add headers by chaining one more buffer at
> front).
Haunted by mbufs, I presume. But a single block of memory can be
treated as a list with only one element.
> IIRC in Linux it is not so, the packets are allocated by the lowest
> level, with the size being calculated at the highest level (to
> include all headers).
'packet' is a somewhat ill-defined term in this context. And your
statement cannot possibly ever make any sense in the way you wrote it,
since data is received 'at the highest level' (that would be the
socket interface) and then travels to the lowest (the device
driver). For this to be possible, buffer space must obviously be
allocated before 'the lowest level' is reached. But this is completely
tangential to the original question and while I am willing to try to
help someone even though this is difficult in absence of any details,
I am not willing to hold entry-level lectures on 'Linux networking' to
an audience of people likely unwilling to listen.
Maxim S. Shatskih
> treated as a list with only one element.
Correct, but not vice versa.
So, old-style Linux code, which treats each packet as contiguous memory area, can be ported to NDIS in an easy way. Backward port is harder, at least if you will not go on with the perf-losing option of flattening all packets.
Anyway: I know that FreeBSD has a framework (IIRC called "ipf") to inject packet filters to the kernel code, which is more or less similar to Vista+ WFP and NDIS6 filters. So, I also expect Linux to have one.
I would suggest the OP to study both _modern_ (not 2.2) Linux mainstream (not exotic and unfashionable in the Linux world) facilities and NDIS6 filtering. Probably it is not a hard task to write the filtering driver portable across the two.