xt_gateway locks up

xt_gateway locks up

[Jan Engelhardt]

Hi Sam,


just for the fun of it, I tried:

	iptables -t mangle -A PREROUTING -m gateway --nexthop 10.10.96.1

and it locked up hard (not even sysrq-b was possible).
I am not sure why that happened - it does work properly in -t filter -A 
OUTPUT, though. I'll experiment a bit.
The codebase I am on is at 
http://dev.computergmbh.de/wsvn/misc_kernel/xt_gateway/

Re: xt_gateway locks up

[Amin Azez]

* Jan Engelhardt wrote, On 21/10/07 23:14:
> Hi Sam,
> 
> 
> just for the fun of it, I tried:
> 
> 	iptables -t mangle -A PREROUTING -m gateway --nexthop 10.10.96.1
> 
> and it locked up hard (not even sysrq-b was possible).
> I am not sure why that happened - it does work properly in -t filter -A 
> OUTPUT, though. I'll experiment a bit.
> The codebase I am on is at 
> http://dev.computergmbh.de/wsvn/misc_kernel/xt_gateway/


Thanks for reporting this.
Is it a regular lock up or just a one off?

I would think it doesn't make sense to use it in pre-routing as no
gateway will be set.

Sam

Re: xt_gateway locks up

[Amin Azez]

* Jan Engelhardt wrote, On 21/10/07 23:14:
> Hi Sam,
> 
> 
> just for the fun of it, I tried:
> 
> 	iptables -t mangle -A PREROUTING -m gateway --nexthop 10.10.96.1
> 
> and it locked up hard (not even sysrq-b was possible).
> I am not sure why that happened - it does work properly in -t filter -A 
> OUTPUT, though. I'll experiment a bit.
> The codebase I am on is at 
> http://dev.computergmbh.de/wsvn/misc_kernel/xt_gateway/

Yeah, my match function was very verbose:

{
        const struct ipt_gateway_info *info = matchinfo;
        const struct iphdr *iph = skb->nh.iph;

        return (  !!(info->flags & IPT_GATEWAY_INV) ^
                ( skb && skb->dst && skb->dst->neighbour &&
...

It assumes that IF skb->dst is set, that it is a neighbour table entry.

Your code is:

	dst = skb->dst;
	if ((neigh = dst->neighbour) == NULL)
		return false;


It doesn't consider that skb->dst may be NULL, which it will in PRE_ROUTING.

Sam

Re: xt_gateway locks up

[Jan Engelhardt]

On Oct 26 2007 15:08, Amin Azez wrote:
>It assumes that IF skb->dst is set, that it is a neighbour table entry.
>
>Your code is:
>
>	dst = skb->dst;
>	if ((neigh = dst->neighbour) == NULL)
>		return false;
>
>
>It doesn't consider that skb->dst may be NULL, which it will in PRE_ROUTING.

That's because Patrick said it cannot be NULL :-)
http://marc.info/?l=netfilter-devel&m=118105659716253&w=2

Of course, an oops in an interrupt handler ain't that funny..

Re: xt_gateway locks up

[Jan Engelhardt]

On Oct 26 2007 16:10, Amin Azez wrote:
>>
>> That's because Patrick said it cannot be NULL :-)
>> http://marc.info/?l=netfilter-devel&m=118105659716253&w=2
>>
>> Of course, an oops in an interrupt handler ain't that funny..
>
>Indeed.
>
>But he was right in the planned useful case, are you using it in 
>pre-routing on bridging or something? I can't work out why you would 
>want to use it in PRE_ROUTING, i.e. before a gateway is set, unless you 
>are setting a gateway in pre-routing too. You're not storing a route in 
>the conntrack are you?

No. The experiment behind this was to:

	-t nat -A PREROUTING -i eth1 -d <address of eth0> -p tcp \
	--dport 80 -j REDIRECT --to-port 8000

i.e. that all packets destined for <public ip>:80 go to an alternate 
port. But if eth0 has a dynamic address, that is going to be hard. So 
the idea I had was to match with

	-t nat -A PREROUTING \
	-m gateway --nexthop 127.0.0.1 -p tcp --dport 80

because the routing code would decide so when it sees that the IPv4 
destination <public ip> is actually a 'local' target (ip r l table 
local).