[VxW] Testing my NAT implementation with VxWorks TCP/IP

[Shankar Vasudevan]

Hi all,

I have a NAT implementation and i need to test this with the VxWorks IPv4 stack. What i need to do is plug this NAT module in between the VxWorks TCP/IP stack and the device driver. The packets from the driver should go thru the NAT module to the IPv4 and packets from the IPv4 should go only via the NAT module to the device driver.

Any suggestions, how i can do this ? If I use mux APIs, the NAT module will get only a copy of the packets and hence the VxWorks stack will also get the untranslated packets. Pls correct me if am wrong.

Is there any hook calls where i can insert this NAT module inbetween VxWorks IPv4 and the device driver ?

Thanks for your help !

Best Regards,
shankar

[shafi]

yes, you have got a hook.
In incoming direction, you can tap the packet using
ipFilterHook(). Check this filter hook library,
it will help you to get raw IP packet and you can
avoid the packet from further going to TCP/IP stack.

problem you will face is the hook you add will run
under tNetTask context. I always faced the problem
with this task. It is so sensitive that if you block
while doing NAT'ing in hook or even for slight delay,
it may hang entire system..

Also there is no hook for outgoing direction from IP.
However you can hack through that ifnet structure..

HTH...
_shafi

"Shankar Vasudevan" <shan...@runbox.com> wrote in message news:<mailman.60.107884...@csg.lbl.gov>...

[Victor]

Hi,Shankar

You can use ipFilterHookAdd( ) to plug your NAT mddule, then NAT
module can check each IP packets from lower level device.

Good luck
Victor

"Shankar Vasudevan" <shan...@runbox.com> wrote in message news:<mailman.60.107884...@csg.lbl.gov>...

[Shankar Vasudevan]

Hi Shafi,

yeah the ipFilterHook has this disadvantage. what if I do the following ?

register as SNARF in mux and take all pkts and translate them and re-inject them into
vxworks ipv4 by calling its call back routine i.e ipReceiveRtn ?

and on the outgoing side, if i register with MUX for OUTPUT-filter and i do the trans and writ it out myself ?

will this have any side-effect ?

Thanks for the Help !

best Regards,
Shankar

> yes, you have got a hook.
> In incoming direction, you can tap the packet using
> ipFilterHook(). Check this filter hook library,
> it will help you to get raw IP packet and you can
> avoid the packet from further going to TCP/IP stack.
>
> problem you will face is the hook you add will run
> under tNetTask context. I always faced the problem
> with this task. It is so sensitive that if you block
> while doing NAT'ing in hook or even for slight delay,
> it may hang entire system..
>
> Also there is no hook for outgoing direction from IP.
> However you can hack through that ifnet structure..
>
>
> HTH...
> _shafi
>
>
>

> "Shankar Vasudevan" <shan...@runbox.com> wrote in message news:<mailman.60.107884...@csg.lbl.gov>...
> > Hi all,
> >
> > I have a NAT implementation and i need to test this with the VxWorks IPv4 stack. What i need to do is plug this NAT module in between the VxWorks TCP/IP stack and the device driver. The packets from the driver should go thru the NAT module to the IPv4 and packets from the IPv4 should go only via the NAT module to the device driver.
> >
> > Any suggestions, how i can do this ? If I use mux APIs, the NAT module will get only a copy of the packets and hence the VxWorks stack will also get the untranslated packets. Pls correct me if am wrong.
> >
> > Is there any hook calls where i can insert this NAT module inbetween VxWorks IPv4 and the device driver ?
> >
> > Thanks for your help !
> >
> > Best Regards,
> > shankar

> _______________________________________________
> VxWorks Users Group mailing list
> VxWe...@lbl.gov
> http://www-csg.lbl.gov/vxworks/
>

[shafi]

Hi Shankar,
Again there is a problem over there.
If you do it this way you have to add this functionality on all the
interfaces you have it on your box and both incoming and outgoing
directions. It will not be good design for scalability when new
interfaces add or removed. On otherhand, advantage with filter hooks
or hacks at IP level is that it is a common point for all the packets
from all interfaces. And translation is to do at IP level only.
So that had an advantage there. any kind of interface (including PPP
where there is no mux concept) can be added or moved without affecting
the desing. better do it at IP level and using hook.
I had done it with high priority thread at hook level...

HTH,
_shafi
PS: Also that MUX OUTPUT-FILTER has problems, I could never make it work,
properly...

"Shankar Vasudevan" <shan...@runbox.com> wrote in message news:<mailman.62.107891...@csg.lbl.gov>...