Do I need a converter ?

QNX Newsgroups (Archives) qdn.public.ddk.network
1

Hi,

I am writing a customer network driver which will be an UP producer for the
TCP/IP stack. This driver will interface with yet another driver to
send/receive packets over the physical layer.

In the transmit path, I would like the customer driver to receive IP
packets from the IP stack without any conversion or filtering done to them.
Is this possible ? Can I avoid writing a converter or do I need a dummy
converter that relays packets to my driver.

In the receive path, the custom driver for the most part will receive
packets in IP format. Can it talk directly to the IP stack to deliver the
packet to the stack or do I need a dummy converter.

Also, does anyone know where I can find example code for writing a simple
converter ?. The Network DDK mentions very little about it.

Thanks

  • Murtaza
2

Instead of a network driver you could probably consider writing a
filter(Although you are not doing any filtering).You could register as
“below ip”(ip_ip) so that the Ip layer sends the packets to you directly(and
vice versa).By the way how do you plan to communicate to the other driver
from your custom driver? through some kind of IPC ?

Sreekanth

“Murtaza Amiji” <murti@yahoo.com> wrote in message
news:b0piuo$1d0$1@inn.qnx.com…

Hi,

I am writing a customer network driver which will be an UP producer for
the
TCP/IP stack. This driver will interface with yet another driver to
send/receive packets over the physical layer.

In the transmit path, I would like the customer driver to receive IP
packets from the IP stack without any conversion or filtering done to
them.
Is this possible ? Can I avoid writing a converter or do I need a dummy
converter that relays packets to my driver.

In the receive path, the custom driver for the most part will receive
packets in IP format. Can it talk directly to the IP stack to deliver the
packet to the stack or do I need a dummy converter.

Also, does anyone know where I can find example code for writing a simple
converter ?. The Network DDK mentions very little about it.

Thanks

  • Murtaza
3

“Sreekanth” <nospam@nospam.com> wrote in message
news:b0q0k7$fhm$1@inn.qnx.com…

Instead of a network driver you could probably consider writing a
filter(Although you are not doing any filtering).You could register as
“below ip”(ip_ip) so that the Ip layer sends the packets to you
directly(and
vice versa).By the way how do you plan to communicate to the other driver
from your custom driver? through some kind of IPC ?

I plan to use devctl() to communicate between my driver and the driver below
it. My guess is I am going to have to write a custom driver that can also
advertise itself and have control on the flow of packets from the IP stack.
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 so I
can use the devctl(). Also, can a filter interface with another driver that
is not part of the io-net framework.

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 packets
directly from the stack ? Can it also send IP packets directly to the stack
in the receive path ?

4

Murtaza Amiji <murti@yahoo.com> wrote:

“Sreekanth” <> nospam@nospam.com> > wrote in message
news:b0q0k7$fhm$> 1@inn.qnx.com> …
Instead of a network driver you could probably consider writing a
filter(Although you are not doing any filtering).You could register as
“below ip”(ip_ip) so that the Ip layer sends the packets to you
directly(and
vice versa).By the way how do you plan to communicate to the other driver
from your custom driver? through some kind of IPC ?

I plan to use devctl() to communicate between my driver and the driver below
it. My guess is I am going to have to write a custom driver that can also
advertise itself and have control on the flow of packets from the IP stack.
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 so I
can use the devctl().

io-net will create an entry under /dev/io-net for you. Any devctl() on that
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 packets
directly from the stack ? Can it also send IP packets directly to the stack
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.

-seanb

5

Some more questions regarding a filter that sits below IP:

  1. 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
    tx/rx, etc.

  2. Can a filter stop the flow of packets from the IP stack. In other words,
    the driver beneath the filter can notify the filter of link failures. Can a
    filter do something about it.

  3. Where can i find an example code for a filter ?

Thanks

  • Murtaza

“Sean Boudreau” <seanb@node25.ott.qnx.com> wrote in message
news:b0ruup$s7t$1@nntp.qnx.com…

Murtaza Amiji <> murti@yahoo.com> > wrote:
“Sreekanth” <> nospam@nospam.com> > wrote in message
news:b0q0k7$fhm$> 1@inn.qnx.com> …
Instead of a network driver you could probably consider writing a
filter(Although you are not doing any filtering).You could register as
“below ip”(ip_ip) so that the Ip layer sends the packets to you
directly(and
vice versa).By the way how do you plan to communicate to the other
driver
from your custom driver? through some kind of IPC ?

I plan to use devctl() to communicate between my driver and the driver
below
it. My guess is I am going to have to write a custom driver that can
also
advertise itself and have control on the flow of packets from the IP
stack.
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 so
I
can use the devctl().

io-net will create an entry under /dev/io-net for you. Any devctl() on
that
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
packets
directly from the stack ? Can it also send IP packets directly to the
stack
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.

-seanb
\

6

If you register as a filter all the ip packets(i.e., if you register as
below ip ) are passed through your module(both directions).You could operate
on the packets and even prevent them going up or down.I didn’t quite
understand the second part of second question "the driver beneath the filter
can notify the filter of link failures. Can a filter do something about it
".Are you planning to prevent link failures going upto the IP stack? Check
out the IPfilter module for example code of a filter.

Hope it helps

Sreekanth

“Murtaza Amiji” <murti@yahoo.com> wrote in message
news:b13m80$b98$1@inn.qnx.com…

Some more questions regarding a filter that sits below IP:

  1. 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
    tx/rx, etc.

  2. Can a filter stop the flow of packets from the IP stack. In other
    words,
    the driver beneath the filter can notify the filter of link failures. Can
    a
    filter do something about it.

  3. Where can i find an example code for a filter ?

Thanks

  • Murtaza

“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:b0ruup$s7t$> 1@nntp.qnx.com> …
Murtaza Amiji <> murti@yahoo.com> > wrote:
“Sreekanth” <> nospam@nospam.com> > wrote in message
news:b0q0k7$fhm$> 1@inn.qnx.com> …
Instead of a network driver you could probably consider writing a
filter(Although you are not doing any filtering).You could register
as
“below ip”(ip_ip) so that the Ip layer sends the packets to you
directly(and
vice versa).By the way how do you plan to communicate to the other
driver
from your custom driver? through some kind of IPC ?

I plan to use devctl() to communicate between my driver and the driver
below
it. My guess is I am going to have to write a custom driver that can
also
advertise itself and have control on the flow of packets from the IP
stack.
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
so
I
can use the devctl().

io-net will create an entry under /dev/io-net for you. Any devctl() on
that
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
packets
directly from the stack ? Can it also send IP packets directly to the
stack
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.

-seanb


\

7

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
every packet.

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
producer.

So, filter or producer is really depends on what you are trying
to do.

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
/dev/serX.

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
of REG_PRODUCER*.

-xtang


Murtaza Amiji <murti@yahoo.com> wrote in message
news:b13m80$b98$1@inn.qnx.com…

Some more questions regarding a filter that sits below IP:

  1. 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
    tx/rx, etc.

  2. Can a filter stop the flow of packets from the IP stack. In other
    words,
    the driver beneath the filter can notify the filter of link failures. Can
    a
    filter do something about it.

  3. Where can i find an example code for a filter ?

Thanks

  • Murtaza

“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:b0ruup$s7t$> 1@nntp.qnx.com> …
Murtaza Amiji <> murti@yahoo.com> > wrote:
“Sreekanth” <> nospam@nospam.com> > wrote in message
news:b0q0k7$fhm$> 1@inn.qnx.com> …
Instead of a network driver you could probably consider writing a
filter(Although you are not doing any filtering).You could register
as
“below ip”(ip_ip) so that the Ip layer sends the packets to you
directly(and
vice versa).By the way how do you plan to communicate to the other
driver
from your custom driver? through some kind of IPC ?

I plan to use devctl() to communicate between my driver and the driver
below
it. My guess is I am going to have to write a custom driver that can
also
advertise itself and have control on the flow of packets from the IP
stack.
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
so
I
can use the devctl().

io-net will create an entry under /dev/io-net for you. Any devctl() on
that
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
packets
directly from the stack ? Can it also send IP packets directly to the
stack
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.

-seanb


\

8

Thank you for this great information. It doesn’t seem like a “filter” is
what I need to implement. This is what I gathered from your input. Correct
me if I am wrong, and I also have a question below.

It appears that what I need to implement is an ethernet “like” network
device driver but unlike an ethernet driver, my driver will transmit and
receive IP packets. I therefore need to implement a producer. Moreover, I
need the ability to assign IP address to the physical interfaces this driver
will support, a yet another reason for implementing a producer.

However, I have come to realize from one of the posts here that two
producers (a driver that also produces IP packets in the UP direction, and a
TCP/IP stack that producers IP packets in DOWN direction) cannot be stacked
on one another. Thus, I may need to implement a “dummy” converter, one that
will be a pass-through for IP packets.

Assuming the above is true, can I write a producer and a “dummy” conveter in
one module (one .so file) or I need two seperate modules. In either case,
do you happen to have a code snippet for writing a simple pass-through
converter.

Thank you for your help.

  • Murtaza

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:b14u4g$ltu$1@nntp.qnx.com…

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
every packet.

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
producer.

So, filter or producer is really depends on what you are trying
to do.

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
/dev/serX.

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
of REG_PRODUCER*.

-xtang


Murtaza Amiji <> murti@yahoo.com> > wrote in message
news:b13m80$b98$> 1@inn.qnx.com> …
Some more questions regarding a filter that sits below IP:

  1. 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
    tx/rx, etc.

  2. Can a filter stop the flow of packets from the IP stack. In other
    words,
    the driver beneath the filter can notify the filter of link failures.
    Can
    a
    filter do something about it.

  3. Where can i find an example code for a filter ?

Thanks

  • Murtaza

“Sean Boudreau” <> seanb@node25.ott.qnx.com> > wrote in message
news:b0ruup$s7t$> 1@nntp.qnx.com> …
Murtaza Amiji <> murti@yahoo.com> > wrote:
“Sreekanth” <> nospam@nospam.com> > wrote in message
news:b0q0k7$fhm$> 1@inn.qnx.com> …
Instead of a network driver you could probably consider writing a
filter(Although you are not doing any filtering).You could register
as
“below ip”(ip_ip) so that the Ip layer sends the packets to you
directly(and
vice versa).By the way how do you plan to communicate to the other
driver
from your custom driver? through some kind of IPC ?

I plan to use devctl() to communicate between my driver and the
driver
below
it. My guess is I am going to have to write a custom driver that
can
also
advertise itself and have control on the flow of packets from the IP
stack.
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
so
I
can use the devctl().

io-net will create an entry under /dev/io-net for you. Any devctl()
on
that
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
packets
directly from the stack ? Can it also send IP packets directly to
the
stack
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.

-seanb




\

9

Murtaza Amiji <murti@yahoo.com> wrote in message
news:b16aqq$cit$1@inn.qnx.com…

Thank you for this great information. It doesn’t seem like a “filter” is
what I need to implement. This is what I gathered from your input.
Correct
me if I am wrong, and I also have a question below.

It appears that what I need to implement is an ethernet “like” network
device driver but unlike an ethernet driver, my driver will transmit and
receive IP packets. I therefore need to implement a producer. Moreover,
I
need the ability to assign IP address to the physical interfaces this
driver
will support, a yet another reason for implementing a producer.

However, I have come to realize from one of the posts here that two
producers (a driver that also produces IP packets in the UP direction, and
a
TCP/IP stack that producers IP packets in DOWN direction) cannot be
stacked
on one another. Thus, I may need to implement a “dummy” converter, one
that
will be a pass-through for IP packets.

Yes. two producers can’t not connect, and yes, you will need a “dummy”
converter
is you decided NOT TO fake up ethernet frame so that you can take advantage
of
already exist “ip <-> en” converter.

You then want to make a producer to produce “my_type” (note, “ip”, “en” type
are
already used. don’t use it) packet. And then you have a “dummp converter” to
convert “my_type <-> ip”, which basically it just pass through.

Assuming the above is true, can I write a producer and a “dummy” conveter
in
one module (one .so file) or I need two seperate modules. In either case,
do you happen to have a code snippet for writing a simple pass-through
converter.

Yes, you can regist both producer and coverter in one .so, just call the
registration
function twice. A pass through converter is just the same as a producer, it
calls
tx_up() in rx_up(), and tx_down() in rx_down().

Advaced Hint :slight_smile:, you can even cut more, say you have:

converter_hdl returned from converter registion
producer_hdl returned from producer registion.

Once you producer have a npkt to send up, it can actually do:

producer_tx_up() {
if (tx_up(converter_hdl, npkt, off, sub, producer_cell,
producer_endpoint, producer_iface) == 0)
producer_tx_done(producer_hdl, npkt
}

Note it calling tx_up() with “converter_hdl” instead of “producer_hdl”,
which means the packet won’t go to the converter_rx_up(), and then
tx_up() again into stack. It will go direct to the stack as if
converter_tx_up() called tx_up().

Same happens in converter_rx_down() that when it got an npkt from
stack, it won’t need to tx_down(), but directly call into producer transmit
function (since they are in one module)…

-xtang

10

This will get me started. Thank you!!.

  • Murtaza

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:b16d1s$mai$1@nntp.qnx.com…

Murtaza Amiji <> murti@yahoo.com> > wrote in message
news:b16aqq$cit$> 1@inn.qnx.com> …
Thank you for this great information. It doesn’t seem like a “filter”
is
what I need to implement. This is what I gathered from your input.
Correct
me if I am wrong, and I also have a question below.

It appears that what I need to implement is an ethernet “like” network
device driver but unlike an ethernet driver, my driver will transmit and
receive IP packets. I therefore need to implement a producer.
Moreover,
I
need the ability to assign IP address to the physical interfaces this
driver
will support, a yet another reason for implementing a producer.

However, I have come to realize from one of the posts here that two
producers (a driver that also produces IP packets in the UP direction,
and
a
TCP/IP stack that producers IP packets in DOWN direction) cannot be
stacked
on one another. Thus, I may need to implement a “dummy” converter, one
that
will be a pass-through for IP packets.

Yes. two producers can’t not connect, and yes, you will need a “dummy”
converter
is you decided NOT TO fake up ethernet frame so that you can take
advantage
of
already exist “ip <-> en” converter.

You then want to make a producer to produce “my_type” (note, “ip”, “en”
type
are
already used. don’t use it) packet. And then you have a “dummp converter”
to
convert “my_type <-> ip”, which basically it just pass through.

Assuming the above is true, can I write a producer and a “dummy”
conveter
in
one module (one .so file) or I need two seperate modules. In either
case,
do you happen to have a code snippet for writing a simple pass-through
converter.

Yes, you can regist both producer and coverter in one .so, just call the
registration
function twice. A pass through converter is just the same as a producer,
it
calls
tx_up() in rx_up(), and tx_down() in rx_down().

Advaced Hint > :slight_smile:> , you can even cut more, say you have:

converter_hdl returned from converter registion
producer_hdl returned from producer registion.

Once you producer have a npkt to send up, it can actually do:

producer_tx_up() {
if (tx_up(converter_hdl, npkt, off, sub, producer_cell,
producer_endpoint, producer_iface) == 0)
producer_tx_done(producer_hdl, npkt
}

Note it calling tx_up() with “converter_hdl” instead of “producer_hdl”,
which means the packet won’t go to the converter_rx_up(), and then
tx_up() again into stack. It will go direct to the stack as if
converter_tx_up() called tx_up().

Same happens in converter_rx_down() that when it got an npkt from
stack, it won’t need to tx_down(), but directly call into producer
transmit
function (since they are in one module)…

-xtang