14 Apr, 2008

5 commits


26 Mar, 2008

2 commits


21 Mar, 2008

2 commits


06 Mar, 2008

2 commits


24 Feb, 2008

1 commit


20 Feb, 2008

1 commit


01 Feb, 2008

4 commits


29 Jan, 2008

13 commits


25 Jan, 2008

3 commits


21 Jan, 2008

1 commit

  • When packets are flood-forwarded to multiple output devices, the
    bridge-netfilter code reuses skb->nf_bridge for each clone to store
    the bridge port. When queueing packets using NFQUEUE netfilter takes
    a reference to skb->nf_bridge->physoutdev, which is overwritten
    when the packet is forwarded to the second port. This causes
    refcount unterflows for the first device and refcount leaks for all
    others. Additionally this provides incorrect data to the iptables
    physdev match.

    Unshare skb->nf_bridge by copying it if it is shared before assigning
    the physoutdev device.

    Reported, tested and based on initial patch by
    Jan Christoph Nordholz .

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     

12 Jan, 2008

1 commit

  • 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

    Signed-off-by: Patrick McHardy
    Signed-off-by: David S. Miller

    Patrick McHardy
     

17 Dec, 2007

1 commit

  • Assigning a valid random address to bridge device solves problems
    when bridge device is brought up before adding real device to bridge.
    When the first real device is added to the bridge, it's address
    will overide the bridges random address.

    Note: any device added to a bridge must already have a valid
    ethernet address.
    br_add_if -> br_fdb_insert -> fdb_insert -> is_valid_ether_addr

    Signed-off-by: Stephen Hemminger
    Signed-off-by: David S. Miller

    Stephen Hemminger
     

07 Dec, 2007

1 commit

  • WARNING: vmlinux.o(.init.text+0x204e2): Section mismatch: reference to .exit.text:br_fdb_fini (between 'br_init' and 'br_fdb_init')

    Signed-off-by: Andrew Morton
    Signed-off-by: David S. Miller

    Andrew Morton
     

29 Nov, 2007

2 commits


20 Nov, 2007

1 commit