I think you’ve been confused. Let’s start from beginning…
Do you need to do a “Filter” or a “Producer (+ converter)” ?
It depends. If you did a Filter, ALL the packets will go through you.
Packets comming in from other ethernet card will goes to your filter
FIRST, then tx_up()'d to tcpip stack (by your filter).
A Filter is idealy for inspecting all the traffic through the system.
Or you want to modify packets based on where they are from/to,
and informations in the packet.
The “draw back” of Filter of cause, is it add extra process on
A “Producer” is a packet generater. The “tcpip stack” is a packet
generater who is generating “ip” type packet. A ethernet driver
is a packet generater who is generating “en” type packet. You can
see tcpip stack will have no idea what is a “en” packet, so there is
a “en <–> ip” converter between these 2. It is the converter understand
ethernet frame, knowing that first 14 byte is the ethernet header,
and to feed a packet into stack, it need to took the 14 bytes off.
Also, in case a type “ip” packet want to goes out, the converter
will inspect the address, prepare the proper 14 bytes ether header
and pass it down to ether driver.
The good part of a “producer”, is that it will pose itself as an
“interface” to tcpip stack (those you can see from netstat -ni).
That means the stack could assign IP address to it, and ONLY
packets need to go through that producer would passed to
So, filter or producer is really depends on what you are trying
If you choose “producer”, do you need a converter? Now,
if you make your producer generate “en” packets, then you
don’t, the exist “en <–> ip” converter would pick up your
packet and (after strip off the 14 bytes ether head) pass it
to stack. That is basically “devn-fd.so” doing. It “fack up”
the ether head, but simply write the packets it got on to
If for some reason, you don’t wish to fack up the ether
head; Or you really need to do something while doing
the “xyz” type to “ip” convertion, you then need to have
your own “xyz <—> ip” converter. Cause you are the
only one knowing what is a “xyz” packet.
A “filter” is exactly the same as a producer, only during
registration, it regist itself as a REG_FILTER* instead
Murtaza Amiji <firstname.lastname@example.org> wrote in message
Some more questions regarding a filter that sits below IP:
Can I use it to mimic some of the features of a driver such providing a
way to register multiple network interfaces, providing a way for user to
configure the network address with ifconfig, collecting stats on packets
Can a filter stop the flow of packets from the IP stack. In other
the driver beneath the filter can notify the filter of link failures. Can
filter do something about it.
Where can i find an example code for a filter ?
“Sean Boudreau” <> email@example.com> > wrote in message
news:b0ruup$s7t$> firstname.lastname@example.org> …
Murtaza Amiji <> email@example.com> > wrote:
“Sreekanth” <> firstname.lastname@example.org> > wrote in message
news:b0q0k7$fhm$> email@example.com> …
Instead of a network driver you could probably consider writing a
filter(Although you are not doing any filtering).You could register
“below ip”(ip_ip) so that the Ip layer sends the packets to you
vice versa).By the way how do you plan to communicate to the other
from your custom driver? through some kind of IPC ?
I plan to use devctl() to communicate between my driver and the driver
it. My guess is I am going to have to write a custom driver that can
advertise itself and have control on the flow of packets from the IP
However, if all this can be done with a filter then I’m all for it.
If I write a filter, can a filter be registered in the /dev namespace
can use the devctl().
io-net will create an entry under /dev/io-net for you. Any devctl() on
device will be passed to the devctl func you register with io-net.
Also, can a filter interface with another driver tha
is not part of the io-net framework.
You’d have to use some sort of IPC.
On a seperate note, if a network driver registers with io-net (using
io_net_registrant_t) with a top type of “ip” then can it receive IP
directly from the stack ? Can it also send IP packets directly to the
in the receive path ?
You can’t have two producers directly above / below each other. What
you propose above would put you beside the stack.