Santosh Kumar
|
Ability to send IP packets through a specific Interface
|
Santosh Kumar
07/13/2008 10:46 PM
post10441
|
Ability to send IP packets through a specific Interface
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 sending an IP/UDP packet through a specific ethernet Interface via sendmsg
interface bypassing the routing table. Are there any requests previously made to add this support in io-pkt?
2. If the answer to question1 is No, then I would want like to put in efforts to add this feature into io-pkt. Can
someone point me in the right directions? I have already downloaded the source code, am able to compile and have setup
my debug environment. I want to know if there are any pitfalls or things with io-pkt I need to be aware of that could
create some issues. As such I am beginning to compare IPV6 code and IPv4 code to see if I can fit things in just like
what IPV6 does since this feature is already supported in IPV6.
Any help or pointers would be highly appreciated.
Thanks,
Santosh
|
|
|
Sean Boudreau(deleted)
|
Re: Ability to send IP packets through a specific Interface
|
Sean Boudreau(deleted)
07/14/2008 3:28 PM
post10495
|
Re: Ability to send IP packets through a specific Interface
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 sending an IP/UDP packet through a specific ethernet Interface via
sendmsg interface bypassing the routing table. Are there any requests previously made to add this support in io-pkt?
>
There was one request recently but I suspect it was from your group.
You may be able to use the MSG_DONTROUTE flag to send() / sendmsg()
but this may not work over ethernet as the arp entry needs to be
cloned from the interface route.
You can get the interface a packet is received on with the IP_RECVIF
socket option and recvmsg().
> 2. If the answer to question1 is No, then I would want like to put in efforts to add this feature into io-pkt. Can
someone point me in the right directions? I have already downloaded the source code, am able to compile and have setup
my debug environment. I want to know if there are any pitfalls or things with io-pkt I need to be aware of that could
create some issues. As such I am beginning to compare IPV6 code and IPv4 code to see if I can fit things in just like
what IPV6 does since this feature is already supported in IPV6.
That's a good start. Take a look at the wiki for general pointers
and post any specific questions you may be having trouble with.
-seanb
|
|
|
Santosh Kumar
|
Re: Ability to send IP packets through a specific Interface
|
Santosh Kumar
07/17/2008 10:28 PM
post10686
|
Re: Ability to send IP packets through a specific Interface
Thank you Sean. Ill keep you posted and get back to you if I need any clarifications related to design.
|
|
|
Santosh Kumar
|
Re: Ability to send IP packets through a specific Interface
|
Santosh Kumar
07/17/2008 11:28 PM
post10688
|
Re: Ability to send IP packets through a specific Interface
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...
View Full Message
|
|
|
Sean Boudreau(deleted)
|
Re: Ability to send IP packets through a specific Interface
|
Sean Boudreau(deleted)
07/18/2008 9:21 AM
post10701
|
Re: Ability to send IP packets through a specific Interface
On Thu, Jul 17, 2008 at 11:28:09PM -0400, Santosh Kumar wrote:
> 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.
If you're refering to '#ifdef _KERNEL' in headers it's to hide
stuff from normal userland. The 'kernel' stuff is only needed
by io-pkt, drivers, lsm modules.
>
> 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?
The NetBSD kernel malloc(), free() take 3 and 2 args respectively.
Under the covers they end up calling the normal libc malloc(), free()
in io-pkt.
>
> 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.
Your build environment should look to the stage first so there's
probably no need ti install them anywhere else.
>
> 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.
Like you said this is only executed if MSG_DONTROUTE is specified.
I'll leave it up to you to decide your own precedence rules when
both MSG_DONTROUTE and IP_PKTINFO are specified.
-seanb
|
|
|
Santosh Kumar
|
Re: Ability to send IP packets through a specific Interface
|
Santosh Kumar
07/18/2008 11:11 PM
post10764
|
Re: Ability to send IP packets through a specific Interface
Hi Sean,
Thank you for your response on the previous questions I asked. I was able to send packets on a specific interface and
receive it successfully on the other end using IP_PKTINFO!. The only thing that was missing is the source address. I was
sending a RAW IP packet withOUT HDRINCL option set. At the receiving end the the IP packet had an IP address of 0.0.0.0
.
I tried to look for the code that sets it and I found that the source address is set from contents of struct inpcb *inp
; variable. I tried to figure out who fills the variable. For raw option I found out that raw_connect function did this.
But I couldn't locate which function did the job of setting the source IP address. Any idea how to set that or which
function does this job?
Thanks,
Santosh
|
|
|
Sean Boudreau(deleted)
|
Re: Ability to send IP packets through a specific Interface
|
Sean Boudreau(deleted)
07/21/2008 10:45 AM
post10802
|
Re: Ability to send IP packets through a specific Interface
On Fri, Jul 18, 2008 at 11:11:41PM -0400, Santosh Kumar wrote:
> Hi Sean,
>
> Thank you for your response on the previous questions I asked. I was able to send packets on a specific interface and
receive it successfully on the other end using IP_PKTINFO!. The only thing that was missing is the source address. I was
sending a RAW IP packet withOUT HDRINCL option set. At the receiving end the the IP packet had an IP address of 0.0.0.0
.
>
> I tried to look for the code that sets it and I found that the source address is set from contents of struct inpcb *
inp; variable. I tried to figure out who fills the variable. For raw option I found out that raw_connect function did
this. But I couldn't locate which function did the job of setting the source IP address. Any idea how to set that or
which function does this job?
>
> Thanks,
> Santosh
It looks to be set by this block of code from around line 522
of netinet/ip_output.c.
-seanb
/*
* If source address not specified yet, use address
* of outgoing interface.
*/
if (in_nullhost(ip->ip_src)) {
xifa = &ia->ia_ifa;
if (xifa->ifa_getifa != NULL)
ia = ifatoia((*xifa->ifa_getifa)(xifa, &ro->ro_dst));
ip->ip_src = ia->ia_addr.sin_addr;
}
|
|
|
Santosh Kumar
|
Re: Ability to send IP packets through a specific Interface
|
Santosh Kumar
07/22/2008 3:55 AM
post10837
|
Re: Ability to send IP packets through a specific Interface
Works now.
I had another question regarding triggering of arp message in case there are no arp entries. I was expecting arp packet
generation on the same interface I tried sending IP packet through but that doesnt seem to be the case. Seems like I
have to do something in that section too. Right?
Would QNX be interested in supporting this feature? Its not full RFC 2292 for IPV4 implementation but I think it would
be useful for routing and link management type of applications. Let me know and I'd be happy to provide the updated
sources.
Thanks,
Santosh
> On Fri, Jul 18, 2008 at 11:11:41PM -0400, Santosh Kumar wrote:
> > Hi Sean,
> >
> > Thank you for your response on the previous questions I asked. I was able to
> send packets on a specific interface and receive it successfully on the other
> end using IP_PKTINFO!. The only thing that was missing is the source address.
> I was sending a RAW IP packet withOUT HDRINCL option set. At the receiving
> end the the IP packet had an IP address of 0.0.0.0.
> >
> > I tried to look for the code that sets it and I found that the source
> address is set from contents of struct inpcb *inp; variable. I tried to
> figure out who fills the variable. For raw option I found out that raw_connect
> function did this. But I couldn't locate which function did the job of
> setting the source IP address. Any idea how to set that or which function does
> this job?
> >
> > Thanks,
> > Santosh
>
> It looks to be set by this block of code from around line 522
> of netinet/ip_output.c.
>
> -seanb
>
>
> /*
> * If source address not specified yet, use address
> * of outgoing interface.
> */
> if (in_nullhost(ip->ip_src)) {
> xifa = &ia->ia_ifa;
> if (xifa->ifa_getifa != NULL)
> ia = ifatoia((*xifa->ifa_getifa)(xifa, &ro->ro_dst));
> ip->ip_src = ia->ia_addr.sin_addr;
> }
|
|
|
|