Commit 444fc8fc authored by Herbert Xu's avatar Herbert Xu Committed by David S. Miller

[IPV4]: Fix "Proxy ARP seems broken"

Meelis Roos <mroos@linux.ee> wrote:
> RK> My firewall setup relies on proxyarp working.  However, with 2.6.14-rc3,
> RK> it appears to be completely broken.  The firewall is 212.18.232.186,
> 
> Same here with some kernel between 14-rc2 and 14-rc3 - no reposnse to
> ARP on a proxyarp gateway. Sorry, no exact revison and no more debugging
> yet since it'a a production gateway.

The breakage is caused by the change to use the CB area for flagging
whether a packet has been queued due to proxy_delay.  This area gets
cleared every time arp_rcv gets called.  Unfortunately packets delayed
due to proxy_delay also go through arp_rcv when they are reprocessed.

In fact, I can't think of a reason why delayed proxy packets should go
through netfilter again at all.  So the easiest solution is to bypass
that and go straight to arp_process.

This is essentially what would've happened before netfilter support
was added to ARP.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 496a22b0
...@@ -697,12 +697,6 @@ void arp_send(int type, int ptype, u32 dest_ip, ...@@ -697,12 +697,6 @@ void arp_send(int type, int ptype, u32 dest_ip,
arp_xmit(skb); arp_xmit(skb);
} }
static void parp_redo(struct sk_buff *skb)
{
nf_reset(skb);
arp_rcv(skb, skb->dev, NULL, skb->dev);
}
/* /*
* Process an arp request. * Process an arp request.
*/ */
...@@ -922,6 +916,11 @@ out: ...@@ -922,6 +916,11 @@ out:
return 0; return 0;
} }
static void parp_redo(struct sk_buff *skb)
{
arp_process(skb);
}
/* /*
* Receive an arp request from the device layer. * Receive an arp request from the device layer.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment