summaryrefslogtreecommitdiffstats
path: root/net/802
diff options
context:
space:
mode:
authorPatrick McHardy <kaber@trash.net>2008-01-11 18:02:18 -0800
committerDavid S. Miller <davem@davemloft.net>2008-01-11 18:02:18 -0800
commit2948d2ebbb98747b912ac6d0c864b4d02be8a6f5 (patch)
tree64e0eec6a3a2c91345d5eb7a00193e94782c2db9 /net/802
parent0ff4d77bd9fe86ca1bc7f44839d79f8a349a62f0 (diff)
downloadlinux-2948d2ebbb98747b912ac6d0c864b4d02be8a6f5.tar.gz
linux-2948d2ebbb98747b912ac6d0c864b4d02be8a6f5.tar.bz2
linux-2948d2ebbb98747b912ac6d0c864b4d02be8a6f5.zip
[NETFILTER]: bridge: fix double POST_ROUTING invocation
The bridge code incorrectly causes two POST_ROUTING hook invocations for DNATed packets that end up on the same bridge device. This happens because packets with a changed destination address are passed to dst_output() to make them go through the neighbour output function again to build a new destination MAC address, before they will continue through the IP hooks simulated by bridge netfilter. The resulting hook order is: PREROUTING (bridge netfilter) POSTROUTING (dst_output -> ip_output) FORWARD (bridge netfilter) POSTROUTING (bridge netfilter) The deferred hooks used to abort the first POST_ROUTING invocation, but since the only thing bridge netfilter actually really wants is a new MAC address, we can avoid going through the IP stack completely by simply calling the neighbour output function directly. Tested, reported and lots of data provided by: Damien Thebault <damien.thebault@gmail.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/802')
0 files changed, 0 insertions, 0 deletions