How to bind io-net module to an interface.

QNX Newsgroups (Archives) qnx.ddk
1

By default. io-net load only one ethernet driver instance and one
TCP/IP stack for multiple Ethernet interface. If we wish to intercept
packet for select interface,
Can we bind our network filter (develop in-house) to the selected
interface ?.
(so we don’t need to do pass-though packet for unselected interface).

  1. Same question for new protocol.
    Can we bind QNX TCP/IP stack to the first Ethernet Interface and Our
    IP Emulation stack to the second interface ?. How ?.
    ( We have some critical application running on top of our stack ).

Thanks
David

2

david_n wrote:

By default. io-net load only one ethernet driver instance and one
TCP/IP stack for multiple Ethernet interface. If we wish to intercept
packet for select interface,
Can we bind our network filter (develop in-house) to the selected
interface ?.
(so we don’t need to do pass-though packet for unselected interface).

  1. Same question for new protocol.
    Can we bind QNX TCP/IP stack to the first Ethernet Interface and Our
    IP Emulation stack to the second interface ?. How ?.
    ( We have some critical application running on top of our stack ).

I don’t know how to bind the TCPIP protocol to just one interface using
a single instance of io-net, but it is possible to create one instance
of io-net for each Ethernet interface. If you are using PCI devices:
io-net -ddriver_name pci=0 -ptcpip
io-net -ddriver_name pci=1 -i2 -ptcpip prefix=/sock2

An application can change the SOCK environment variable to talk to both
stacks through the socket API. If SOCK is empty or not defined, the
first stack will be used. If SOCK=/sock2, the second stack is used.

The -i option specifies the io-net instance. In the above example you
would have to entries under /dev for io-net:
/dev/io-net (first io-net)
/dev/io-net2 (io-net with -i2)

You would also have /dev/socket and /sock2/dev/socket entries.

I’m not sure if this is what you wanted, but I hope it helps,
Gilles

3

Hi Gilles
Thanks a lot for your help. This can be one of the solution. The main
objective to to intercept only packet for a selected interface. Yes,
if we can not bind our network filter to a selected interface (suing
the current architecture (one io-net instance), we will go with
multiple io-net instance.
David_n

4

david_n wrote:

Hi Gilles
Thanks a lot for your help. This can be one of the solution. The main
objective to to intercept only packet for a selected interface. Yes,

When your filter gets a packet, one of the fields in it’s rx_up function
is the interface endpoint. Can’t you just check if it’s the interface
you are interested in? If it is, process the packet, if it’s not, just
send it up by calling the io-net’s tx_up().

Regards,
Gilles

5

Sorry Gilles. I’m quite busy the late few days. Have no time to check
the forum.
Yes. I know we can use parameters from rx_up/tx_down to separate
traffic. However, packet still in/out through our network module. In
term of stability, if we can completty separate the traffic, it will
be better. Worst case senario:if our network filter crashed. Only
one interface down, other still running… We can still access to the
card and looking at the problem. We dicuss this solution in the pass
and found that we may have some trouble in case the module got into
trouble.
Thanks.
David

6

david_n wrote:

Sorry Gilles. I’m quite busy the late few days. Have no time to check
the forum.
Yes. I know we can use parameters from rx_up/tx_down to separate
traffic. However, packet still in/out through our network module. In
term of stability, if we can completty separate the traffic, it will
be better. Worst case senario:if our network filter crashed. Only
one interface down, other still running… We can still access to the
card and looking at the problem. We dicuss this solution in the pass
and found that we may have some trouble in case the module got into
trouble.

I don’t think registering the module on only one of the interfaces would
help very much in terms of stability. If your filter did something
“bad”, the other interface would also go down.

Your filter is part of the io-net process, so if your filter does
anything “bad” (e.g. referencing a bad pointer, corrupting memory,
etc…) either it will crash immediately, or it will cause a different
io-net module to eventually crash, but of which bring down the whole
io-net process.

Running two instances of io-net (one for each interface) would be the
only way to allow the other interface to continue running if your filter
crashes.

Regards,
Gilles

7

True, filter is part of io-net process and it can bring down the whole
io-net process if the filter “crashed”.
one instance of io-net for each interface would be the best solution
to resolve the stability issue.
Regards,
VanChi.