Project Home
Project Home
Trackers
Trackers
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - QNX4 IP route questions: (2 Items)
   
QNX4 IP route questions  
Hi Everyone,

 

I'm running QNX 4.25 with TCP/IP toolkit 4.25.

 

I have a situation where I have two ethernet interfaces on my QNX4 host,
each on its own IP subnet (call them subnets X and Y).  Ultimately, both of
these subnets can reach a third subnet (Z) via IP routers on subnets X and
Y.  My TCP-based software on my QNX4 host must talk to a third-party device
(with a single fixed IP address) resident on subnet Z.

 

The dilemma is that my QNX4 host must choose an exit interface in order to
reach the third-party device on subnet Z.  Either ethernet interface is fine
under normal conditions.  So I could configure a default route or a specific
static route on my QNX4 host telling it that in order to reach subnet Z, it
should go via the router on subnet X.  But now what happens if that ethernet
link fails.  I need my QNX4 host to use my other ethernet interface, i.e. I
need my QNX4 host to send my outgoing packets to the router on subnet Y in
order to reach subnet Z.

 

I assumed that I could use the 'route' command to add two default routes (or
two subnet Z static routes) with different metrics (i.e. preferences) such
that the QNX4 IP networking stack would try the "primary" route first, then
the "secondary" route if the primary had failed.

 

Unfortunately, any time I attempted to add a second route to the same
destination (either a second default route, or a second route specifically
to subnet Z), the 'route' command failed with an EEXIST error.

 

Am I doing something wrong, or does the QNX4 networking stack indeed only
support a single route to a given destination?

 

I am considering various solution approaches:

1.       Run 'routed' on my QNX4 host, and convince the administrator of the
routers to run RIP on them.

2.       Find (or write) a QNX4 host implementation of the ICMP Router
Discovery Protocol, and convince the administrator of the routers to run the
ICMP Router Discovery Protocol on them.

3.       Write my own QNX4 program that dynamically manipulates the QNX4 IP
routing table using the SIOCADDRT/SIOCDELRT ioctls based on some
still-to-be-determined criteria for picking the best route.  (E.g. my
program could periodically ping the routers and/or destination host and
change the routing table if the current route wasn't working.  This is a
somewhat ugly solution, but I may have no other choice.)

 

Any advice?

 

If I choose to go with dynamically manipulating the routing table (for
Solution 2 or Solution 3 above), is the SIOCADDRT/SIOCDELRT mechanism still
the best API for this?  This mechanism uses an old paradigm for specifying
the route destination and does not support classless IP routing (a.k.a.
CIDR).  I.e. I can't specify a route such as 192.168.1.0/23.  Nevertheless,
there are indications that the actual IP routing table might use the newer
Berkeley radix tree implementation, that *does* support classless routing.
Thus I'm wondering if there is a newer API somewhere that I don't know
about.  Is there?

 

 

Thanks for any help anyone can offer!

 

Walt Wimer

TCSA, Inc.

 

Re: QNX4 IP route questions  
I asked:

     “If I choose to go with dynamically manipulating the routing table (for Solution 2 or Solution 3 above), is the 
SIOCADDRT/SIOCDELRT mechanism still the best API for this?  This mechanism uses an old paradigm for specifying the route
 destination and does not support classless IP routing (a.k.a. CIDR).  I.e. I can’t specify a route such as 192.168.1.0
/23.  Nevertheless, there are indications that the actual IP routing table might use the newer Berkeley radix tree 
implementation, that *does* support classless routing.  Thus I’m wondering if there is a newer API somewhere that I don
’t know about.  Is there?”

Some Google research suggests that the answer to this particular question may potentially be found in the FreeBSD 
route(4) man page.  The newer API uses a special socket with protocol family PF_ROUTE.  Routing information is read and 
written via a message protocol to/from such a socket.  Here’s an excerpt from the FreeBSD route(4) man page (found via 
Google):

ROUTE(4)                    BSD Kernel Interfaces Manual                       ROUTE(4)

NAME
     route -- kernel packet forwarding database

SYNOPSIS
     #include <sys/types.h>
     #include <sys/time.h>
     #include <sys/socket.h>
     #include <net/if.h>
     #include <net/route.h>

     int
     socket(PF_ROUTE, SOCK_RAW, int family);

DESCRIPTION
     FreeBSD provides some packet routing facilities.  The kernel maintains a
     routing information database, which is used in selecting the appropriate
     network interface when transmitting packets.

     A user process (or possibly multiple co-operating processes) maintains
     this database by sending messages over a special kind of socket.  This
     supplants fixed size ioctl(2)'s used in earlier releases.  Routing table
     changes may only be carried out by the super user.

     The operating system may spontaneously emit routing messages in response
     to external events, such as receipt of a re-direct, or failure to locate
     a suitable route for a request.  The message types are described in
     greater detail below.



Walt