Re: [PATCH] ebtables dst cache overflow/SNAT fix

Oops! My bad. You're right, the function doesn't exist in stock kernels. It
comes from the dead gateway detection patch (http://www.ssi.bg/~ja/routes-2.4.26-9.diff).

Here I thought I had done my homework... :)

That's probably why you're not seeing the problem.

Aside from that routes patch, is there any other way skb->dst could be set
going into br_nf_pre_routing_finish()?

Thanks,
Scott

On Wed, 22 Sep 2004, Bart De Schuymer wrote:

>>Date: Wed, 22 Sep 2004 22:52:25 +0200
>>From: Bart De Schuymer <[email protected]>
>>To: Scott Yoder <syoder-/[email protected]>
>>Cc: [email protected]
>>Subject: Re: [Ebtables-devel] [PATCH] ebtables dst cache overflow/SNAT fix
>>
>>On Wednesday 22 September 2004 22:09, Scott Yoder wrote:
>>> The SNAT rule I used in the lab:
>>>
>>> iptables -t nat -I POSTROUTING -s ! 192.168.100.1 -j SNAT --to 192.168.88.1
>>>
>>> In the field where this problem was discovered the routers were simply
>>> SNAT'ing for customers in a bridge group.
>>>
>>> The field routers were running 2.4.26 with ebtables-brnf-6_vs_2.4.26.
>>> I've also tested 2.4.27 with ebtables-brnf-7_vs_2.4.27 but I see the same
>>> problem.
>>>
>>> I noticed that with the SNAT rule, packets received on a bridge port
>>> passed through net/ipv4/netfilter/ip_nat_core.c:ip_nat_route_input().
>>
>>That function doesn't exist.
>>I earlier tested it with kernel 2.6.8.1 and couldn't trigger it. I now tested
>>it with 2.4.24 and couldn't trigger it either. I use the rule I mentioned and
>>I of course check the traffic to see if the SNAT happened.
>>You seem to be SNATing to another subnet, does it have something to do with
>>that?
>>
>>cheers,
>>Bart
>>


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php