about ROUTE target

about ROUTE target

[Toshihiro Sonoda]

Hi, 

I want to re-route the packet to tunneling device in spite of the
packet's destination address. I know the ipt_ROUTE target, so
I set up the iptables and tunneling device in the following environment.


[ local pc]- LAN ->[  router ] <- WAN -> [ target pc ]   

LAN's network is 192.168.7.0/24.
WAN's network is 192.168.1.0/24.

LAN side IP address of the router is  192.168.7.1.
WAN side IP address of the router is 192.168.1.2.
target pc IP address is 192.168.1.3.

router is 2.4.18 kernel and I did p-o-m for ipt_ROUTE to the router.

I set the following command on the router.

# modprobe ip_gre
# iptunnel add tundev mode gre remote 192.168.1.3
# ifoconfig tundev 192.168.1.2
#
# modprobe ipt_ROUTE
# iptables -t nat -A PREROUTING -p icmp -j ROUTE --iface tundev

and I executed  "ping" to anather pc(ex, 192.168.1.10) on the local pc.

# ping 192.168.1.10

then, router(linux) was freezed.
 
I confirmed that ipt_route_target(), which is in "ipt_ROUTE.c", hook function 
in the ROUTE target was called in the router's linux kernel,
and ipgre_tunnel_xmit() in gre's tunneling device(ip_gre.c) was called.

But, the at the IPTUNNLE_XMIT() called in the ipgre_tunnel_xmit(), linux 
was freezed.

Do I mistake how to use the ROUTE target ?

thanks for your advice.

-
T.Sono

Re: about ROUTE target

[Cédric de Launois]

> I confirmed that ipt_route_target(), which is in "ipt_ROUTE.c", hook function 
> in the ROUTE target was called in the router's linux kernel,
> and ipgre_tunnel_xmit() in gre's tunneling device(ip_gre.c) was called.
> 
> But, the at the IPTUNNLE_XMIT() called in the ipgre_tunnel_xmit(), linux 
> was freezed.
> 
> Do I mistake how to use the ROUTE target ?

It seems you found a bug. I'll take a look to this problem as soon as
possible. Thanks for having reported this bug.

Cédric de Launois

Re: about ROUTE target

[Toshihiro Sonoda]

Hi, Launois.

In the following case, while ipt_ROUTE action, which is
the ipt_route_target(), is processing, another netfiter action is called.
Is it able to call one netfiter action during processing another one?

ROUTE action is called when PRE_ROUTING rule is matched, after
that, in the PRE_ROUTING action, OUTPUT and POST_ROUTING
is called. so, nf_hook_slow() is nested.

Is that ok??

thanks for your advice.


> > I confirmed that ipt_route_target(), which is in "ipt_ROUTE.c", hook function
> > in the ROUTE target was called in the router's linux kernel,
> > and ipgre_tunnel_xmit() in gre's tunneling device(ip_gre.c) was called.
> >
> > But, the at the IPTUNNLE_XMIT() called in the ipgre_tunnel_xmit(), linux
> > was freezed.
> >
> > Do I mistake how to use the ROUTE target ?
>
> It seems you found a bug. I'll take a look to this problem as soon as
> possible. Thanks for having reported this bug.
>
> Cédric de Launois
>
>
>
>

Re: about ROUTE target

[Cédric de Launois]

> In the following case, while ipt_ROUTE action, which is
> the ipt_route_target(), is processing, another netfiter action is called.
> Is it able to call one netfiter action during processing another one?
> 
> ROUTE action is called when PRE_ROUTING rule is matched, after
> that, in the PRE_ROUTING action, OUTPUT and POST_ROUTING
> is called. so, nf_hook_slow() is nested.
> 
> Is that ok??

I could not reproduce the bug. I'm using here a kernel 2.4.19.
I also tested your configuration in a User-Mode Linux, running
a kernel 2.4.18, but I didn't get any problem.

However, I traced the journey of a packet matching the ROUTE
target. Function nf_hook_slow() is effectively nested as you
said (see the backtrace below). But this behaviour is the same as the
one of the ipt_MIRROR target (ROUTE target was based on its code), 
which works well.
I don't know if this behaviour is desirable. Anyway, I don't know
about a method to avoid it.

Maybe someone on the mailing list can help us ?

Here is the backtrace of the packet :

#0  dev_queue_xmit (skb=0xa1050980) at dev.c:1011
#1  0xa00bdd6d in ip_finish_output2 (skb=0xa1050980) at ip_output.c:173
#2  0xa00b2a66 in nf_hook_slow (pf=2, hook=4, skb=0xa1050980, indev=0x0,
outdev=0xa08be000, 
    okfn=0xa00bdcf0 <ip_finish_output2>) at netfilter.c:493
#3  0xa00bdcc4 in ip_finish_output (skb=0x0) at
/usr/src/uml/linux/include/linux/list.h:112
#4  0xa00e8680 in do_ip_send (skb=0x0) at ip_gre.c:672
#5  0xa00b2a66 in nf_hook_slow (pf=2, hook=3, skb=0xa1050980, indev=0x0,
outdev=0xa08be000, 
    okfn=0xa00e8650 <do_ip_send>) at netfilter.c:493
#6  0xa00e7ac4 in ipgre_tunnel_xmit (skb=0xa1050980, dev=0xa08e8800) at
ip_gre.c:886
#7  0xa00abf96 in dev_queue_xmit (skb=0xa104d5e0) at dev.c:1044
#8  0xa28cf494 in ip_direct_send (skb=0xa104d5e0) at ipt_ROUTE.c:99
#9  0xa28cf26e in ipt_route_target (pskb=0xa1050980, hooknum=0,
in=0xa08be000, out=0x0, targinfo=0xa28d10d0, 
    userinfo=0x0) at ipt_ROUTE.c:193
#10 0xa28b62dd in ipt_do_table (pskb=0xa018baf4, hook=0, in=0xa08be000,
out=0x0, table=0xa1050980, userdata=0x0)
    at ip_tables.c:363
#11 0xa28c67cd in ip_nat_rule_find (pskb=0xa018baf4, hooknum=0,
in=0xa08be000, out=0x0, ct=0xa074e1c0, 
    info=0xa074e290) at ip_nat_rule.c:279
#12 0xa28c615b in ip_nat_fn (hooknum=0, pskb=0xa018baf4, in=0xa08be000,
out=0x0, okfn=0xa00ba280 <ip_rcv_finish>)
    at ip_nat_standalone.c:106
#13 0xa00b2769 in nf_iterate (head=0xa01d22e0, skb=0xa018baf4, hook=0,
indev=0xa08be000, outdev=0x0, 
    i=0xa018bad4, okfn=0xa00ba280 <ip_rcv_finish>) at netfilter.c:350
#14 0xa00b2a22 in nf_hook_slow (pf=2, hook=0, skb=0xa104d5e0,
indev=0xa08be000, outdev=0x0, 
    okfn=0xa00ba280 <ip_rcv_finish>) at netfilter.c:484
#15 0xa00ba024 in ip_rcv (skb=0xa104d5e0, dev=0xa08be000, pt=0xa0193398)
    at /usr/src/uml/linux/include/linux/list.h:112
#16 0xa00ac66f in net_rx_action (h=0xa01ab610) at dev.c:1509

Cédric

Re: about ROUTE target

[Toshihiro Sonoda]

Hi, Launois. Thanks for your comments and trial.
but, I feel sad, because I can not use ROUTE . (T_T;

I tried linux 2.4.19, too, but the result was same.
I cannot trace in kernel, because linux is freezed.

If you can, let me know how to config your environment on
linux 2.4.18 or 19. I want to try ROUTE on the just your
same environmet.

And, at one more time, I explain my detail environment.

[local pc] <-LAN-> [ router ] <-WAN->[ target pc]

LAN: 192.168.7.0/24
WAN: 192.168.1.0/24
[local-pc]
  eth0: 192.168.7.2
[router]
  eth1: 192.168.7.1(LAN interface)
  eth0: 192.168.1.2(WAN interface)
[target pc]
 eth0: 192.168.1.3

on the router, I did following command.

# modprobe ip_gre
# iptunnel add tundev mode gre remote 192.168.1.3
# ifconfig tundev 192.168.1.2
# iptables -t nat -A POSTROUTING -o eth0 \
                   -s 192.168.7.0/24 -j MASQUERADE
# iptables -t nat -A PREROUTING -p icmp -j ROUTE --iface tundev

and I executed the "ping " command from the [local pc] to another pc

# ping 192.168.1.10

mmm.. I don't know why you can, but i cannot.



> > In the following case, while ipt_ROUTE action, which is
> > the ipt_route_target(), is processing, another netfiter action is called.
> > Is it able to call one netfiter action during processing another one?
> >
> > ROUTE action is called when PRE_ROUTING rule is matched, after
> > that, in the PRE_ROUTING action, OUTPUT and POST_ROUTING
> > is called. so, nf_hook_slow() is nested.
> >
> > Is that ok??
>
> I could not reproduce the bug. I'm using here a kernel 2.4.19.
> I also tested your configuration in a User-Mode Linux, running
> a kernel 2.4.18, but I didn't get any problem.
>
> However, I traced the journey of a packet matching the ROUTE
> target. Function nf_hook_slow() is effectively nested as you
> said (see the backtrace below). But this behaviour is the same as the
> one of the ipt_MIRROR target (ROUTE target was based on its code),
> which works well.
> I don't know if this behaviour is desirable. Anyway, I don't know
> about a method to avoid it.
>
> Maybe someone on the mailing list can help us ?
>
> Here is the backtrace of the packet :
>
> #0  dev_queue_xmit (skb=0xa1050980) at dev.c:1011
> #1  0xa00bdd6d in ip_finish_output2 (skb=0xa1050980) at ip_output.c:173
> #2  0xa00b2a66 in nf_hook_slow (pf=2, hook=4, skb=0xa1050980, indev=0x0,
> outdev=0xa08be000,
>     okfn=0xa00bdcf0 <ip_finish_output2>) at netfilter.c:493
> #3  0xa00bdcc4 in ip_finish_output (skb=0x0) at
> /usr/src/uml/linux/include/linux/list.h:112
> #4  0xa00e8680 in do_ip_send (skb=0x0) at ip_gre.c:672
> #5  0xa00b2a66 in nf_hook_slow (pf=2, hook=3, skb=0xa1050980, indev=0x0,
> outdev=0xa08be000,
>     okfn=0xa00e8650 <do_ip_send>) at netfilter.c:493
> #6  0xa00e7ac4 in ipgre_tunnel_xmit (skb=0xa1050980, dev=0xa08e8800) at
> ip_gre.c:886
> #7  0xa00abf96 in dev_queue_xmit (skb=0xa104d5e0) at dev.c:1044
> #8  0xa28cf494 in ip_direct_send (skb=0xa104d5e0) at ipt_ROUTE.c:99
> #9  0xa28cf26e in ipt_route_target (pskb=0xa1050980, hooknum=0,
> in=0xa08be000, out=0x0, targinfo=0xa28d10d0,
>     userinfo=0x0) at ipt_ROUTE.c:193
> #10 0xa28b62dd in ipt_do_table (pskb=0xa018baf4, hook=0, in=0xa08be000,
> out=0x0, table=0xa1050980, userdata=0x0)
>     at ip_tables.c:363
> #11 0xa28c67cd in ip_nat_rule_find (pskb=0xa018baf4, hooknum=0,
> in=0xa08be000, out=0x0, ct=0xa074e1c0,
>     info=0xa074e290) at ip_nat_rule.c:279
> #12 0xa28c615b in ip_nat_fn (hooknum=0, pskb=0xa018baf4, in=0xa08be000,
> out=0x0, okfn=0xa00ba280 <ip_rcv_finish>)
>     at ip_nat_standalone.c:106
> #13 0xa00b2769 in nf_iterate (head=0xa01d22e0, skb=0xa018baf4, hook=0,
> indev=0xa08be000, outdev=0x0,
>     i=0xa018bad4, okfn=0xa00ba280 <ip_rcv_finish>) at netfilter.c:350
> #14 0xa00b2a22 in nf_hook_slow (pf=2, hook=0, skb=0xa104d5e0,
> indev=0xa08be000, outdev=0x0,
>     okfn=0xa00ba280 <ip_rcv_finish>) at netfilter.c:484
> #15 0xa00ba024 in ip_rcv (skb=0xa104d5e0, dev=0xa08be000, pt=0xa0193398)
>     at /usr/src/uml/linux/include/linux/list.h:112
> #16 0xa00ac66f in net_rx_action (h=0xa01ab610) at dev.c:1509
>
> Cédric
>
>
>
>