Am 2017-08-15 um 14:12 schrieb Markus Kittenberger:
my 2 cents are that bridges without WDS already cause ipv4 problems and not only issues with ipv6, so they should never have been used.

Unfortunately i fear there are still quite a few of them in our network.

Definitely all firmware builds of Backfire-Vienna use isolated wlan interfaces with olsr routing only, but there may be some devices out there that use bridge mode nevertheless, while still maintaining the described setup. IPv4 will work well on those, while IPv6 will not (as described previously).

But these firmwares carry a much more relevant design flaw: active external-to-external NAT for IPv4 because of the missing exclusion of RCF1918 and APIPA ranges. So if 'Masquerading' is active for the zone 0xFF and that zone contains several interfaces with public IP addresses, that problem will occur - incoming traffic with a destination behind the other IP will not be forwarded correctly.

Screenshots - Problem:



Screenshots - Should-be:



lg Markus

On Tue, Aug 15, 2017 at 12:07 PM, Erich N. Pekarek <er...@pekarek.at <mailto:er...@pekarek.at>> wrote:

    Hi!
    Am 2017-08-15 um 11:43 schrieb Matthias Šubik:

        let me have a guess ...

    Let me guess a bit further...

            On 11 Aug 2017, at 15:37, Gui Iribarren
            <g...@altermundi.net <mailto:g...@altermundi.net>> wrote:

            On 11/08/17 13:43, Christian Pock wrote:

        ...


                For some reason, not all routers running olsr2 are
                reachable via IPv6. As far as we found out, this is
                related to the  setting "WDS bridge" on
                Ubiquiti-Antennas running AirOS 6 or earlier (with
                must be enabled). So in case there's a node listed in
                the "olsr2 cloud", a missing WDS-bridge-enabled
                setting could cause that the node is not available
                (highlighted blue in the listing and map).

            yeah, "WDS" must always be enabled on all bridges (in some
            AirOs
            versions is called "Transparent bridge mode") or funny
            things happen in
            IPv6 world

        I don’t know AirOS, but I guess if disabled, it filters
        ethernet multicast, this kills neighbour discovery, which is
        essential for normal IPv6 operation.
        If you debug IPv6, please take into account the subtile
        differences between IPv4 and IPv6 on layer two.

    Multicast is not the only problem. Since AirOS is used in bridged
    mode, you'd then have 'foreign' MAC addresses leaving the Wireless
    Interface.
    This is, what WDS is usually for: it resembles 4-address mode,
    that rewrites packets.

    The effect of using a non-WDS-bridge would be, that ip neigh show
    would list the neighbours correctly, but all of them will be STALE
    in the first place.
    If you try to ping them, you will fail, which will be represented
    by a FAILED link in die neighbour table.
    The funny thing is, that you could still ping6 the link local
    address from a direct 1 hop neighbour.

    So you may be lead to believe it's a mere multicast problem. But
    debugging that, you will see, that proxying the multicast won't help.
    The problem resides in NDP failing to resolve devices behind the
    bridge, since it will only discover the wrong originator MAC -
    that is the one of the AP on non-WDS-enabled devices.


        TL;DR: ARP reachability is not v6 reachability.

    Full Ack.


        just a little reminder,
        Matthias


        --
        Wien mailing list
        Wien@lists.funkfeuer.at <mailto:Wien@lists.funkfeuer.at>
        https://lists.funkfeuer.at/mailman/listinfo/wien
        <https://lists.funkfeuer.at/mailman/listinfo/wien>
        Best regards

    Erich


    --
    Wien mailing list
    Wien@lists.funkfeuer.at <mailto:Wien@lists.funkfeuer.at>
    https://lists.funkfeuer.at/mailman/listinfo/wien
    <https://lists.funkfeuer.at/mailman/listinfo/wien>


br
erich
--
Wien mailing list
Wien@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/wien

Antwort per Email an