Thank you Sean. Ill keep you posted and get back to you if I need any clarifications related to design.

Hi Sean,

1. There seem to be two separate sets of definitions for kernel mode and non-kernel mode. It is not clear to me as to 
why this is required. I would like to know. The kernel option seems to refer to RFC2292 very clearly but the other 
definitions seem to make a comment on supporting RFC3542 which is an extension. Seems like it doesnt matter which one is
 used as far as implementation is concerned. Since I plan to implement the IP_PKTINFO option to start off with,  I 
intend to model things closely to how IPV6 has implemented it. I would take care to see that it can be extentded to 
include other features of RFC to IPV4.

2. Im was little confused with the malloc and free being macroed. I see from comments that some form of memory 
management is implemented. Im curious to know what the scheme and why it was required. Is there some documentation on 
this?

3. Upon compiling and installing, there is a whole bunch of header files and binaries generated in the staging area. I 
finally intend to Integrate io-pkt and the libraries into our development environment. Should all header files produced 
in the staging area  replace  similar files in my development environment? Need some guidance on that.

4. I see an issue in the ip_output function implemented in ip_output.c:

Following code bothers me a little bit:
      if (flags & IP_ROUTETOIF) {
		if (
#ifndef __QNXNTO__
		    (ia = ifatoia(ifa_ifwithladdr(sintosa(dst)))) == 0
#else
		    (ia = ifatoia((ifa_ifwithladdr)(sintosa(dst), bounddevice))) == 0
#endif
		    ) {
			ipstat.ips_noroute++;
			error = ENETUNREACH;
			goto bad;
		}
		ifp = ia->ia_ifp;
		mtu = ifp->if_mtu;
		ip->ip_ttl = 1;
#ifdef __QNXNTO__
		if (bounddevice)
			ip->ip_ttl = 64;
#endif
	}

It seems like, if we enable the MSG_DONTROUTE flag in sendmsg function call, this piece of code gets executed. It seems 
like this piece of code will try and figure out one interface based on destination IP address, whichever matches first 
from the if_addrlist queue. 

I want to confirm the following: 

When I implement the IP_PKTINFO control message that specifies the outgoing interface I am interested to go out on, I 
would need to bypass this check after checking if the control option has been enabled, since I already know the 
interface. Let me know if I am missing something or if there are some more adjustments that I might need to make.

Thanks,
Santosh    
> On Sun, Jul 13, 2008 at 10:46:37PM -0400, Santosh Kumar wrote:
> > Hi,
> > 
> > Im not sure if this thread should be under general or under technology forum
> , so I am posting this one under both.
> > 
> > RFC 2292 is currently supported by io-pkt. However, this RFC is only 
> applicable for IPV6. In particular, I am interested in the section 5 aspects 
> but want to achieve this for IPV4 packets. Section 5. I am providing a brief 
> excerpt of the functionality this section covers.
> > 
> > "There are four pieces of information that an application can specify
> >    for an outgoing packet using ancillary data:
> > 
> >        1.  the source IP address,
> >        2.  the outgoing interface index,
> >        3.  the outgoing hop limit, and
> >        4.  the next hop address.
> > 
> >    Three similar pieces of information can be returned for a received
> >    packet as ancillary data:
> > 
> >        1.  the destination IP address,
> >        2.  the arriving interface index, and
> >        3.  the arriving hop limit."	
> > 
> > My question is:
> > 1. This particular ability has always been provided on Linux. We have 
> decided to use QNX instead of Linux but currently am facing a roadblock to 
> port some features of Linux we were using and one of them is related to the 
> feature mentioned above. In particular, I'm interested in...