Re: CFR: bridge locking

From: Lars Eggert (larse_at_ISI.EDU)
Date: 08/20/03

  • Next message: Daniel C. Sobral: "Re: CFR: bridge locking" 
    Date: Wed, 20 Aug 2003 10:29:33 -0700
To: Sam Leffler <sam@errno.com>

    Sam Leffler wrote:

    > http://www.freebsd.org/~sam/bridge.patch
    >
    > This patch adds locking and also overhauls the bridge code some to do
    > things like replace explicit numbers with #defines and cleanup the
    > debugging code.

    This is only mildly related, but maybe someone feels like looking at
    this in addition to your locking changes...

    I have a PR about the bridge code sitting at
    http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/41632; the latest patch
    is at http://www.isi.edu/larse/software/bridge.patch

    It does two things:

    1. Disables bridging for IPv6. This is probably too aggressive,
        since bridging is only problematic for link-local packets, but it
        makes a routed IPv6 configuration coexist with a bridged IPv4 one.

        A much better fix would be an overhaul of the bridge code so that
        each bridge has a single link-local address, instead of one per
        physical interface. (Similar to how it should/must only have one IPv4
        address, but link-locals are auto-assigned.) Essentially, make
        a bridge set its own pseudo interface.

    2. It forwards a copy of bridged packets to bpfs attached to interfaces
        in the bridge set that have no carrier. This makes dhcpd work on an
        interface of a bridge set that is unplugged.

        Again, a much better fix would be to have bridge sets show up as
        pseudo interfaces that dhcpd's bpf can then listen on.

    I think you mentioned in the past that NetBSD (OpenBSD?) has bridge code
    that implements the pseudo-device approach?

    Lars

    PS: I needed both these changes for our Soekris-based "rent-a-subnet"
    box: http://www.isi.edu/tethernet/ 

    -- 
Lars Eggert <larse@isi.edu>           USC Information Sciences Institute

  • Next message: Daniel C. Sobral: "Re: CFR: bridge locking"

    Relevant Pages

    • RE: [PATCH][RFC] net/bridge: add basic VEPA support
      ... The bridge code really consists of two parts: ... a new driver for just VEPA. ... The forwarding table is still needed and used on inbound traffic to ...
      (Linux-Kernel)
    • Re: RFC: if_bridge
      ... > I am looking for testers and code review for if_bridge, ... bridge interface itself. ... locking the real interface and then trying to lock the bridge. ... there should be a global bridge-list shared/exclusive lock ...
      (freebsd-hackers)
    • Re: RFC: if_bridge
      ... > I am looking for testers and code review for if_bridge, ... bridge interface itself. ... locking the real interface and then trying to lock the bridge. ... there should be a global bridge-list shared/exclusive lock ...
      (freebsd-net)
    • UPDATE: New Mozilla SpiderMonkey bridge code release
      ... The bridge code has undergone its final large renovation. ... Javascript objects in real-time from both Delphi/Kylix and script. ...
      (borland.public.delphi.thirdpartytools.general)
    • Re: CFR: bridge locking
      ... >> This patch adds locking and also overhauls the bridge code some to do ... It forwards a copy of bridged packets to bpfs attached to interfaces ... > in the bridge set that have no carrier. ...
      (freebsd-arch)