<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 2017-08-15 um 14:12 schrieb Markus
Kittenberger:<br>
</div>
<blockquote type="cite"
cite="mid:CAKNLPNKKUawPoj+9Vkrc8pCBKmnQP66brBJRyCGxjrJjGZ1qeA@mail.gmail.com">
<div dir="ltr">
<div>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.<br>
<br>
</div>
Unfortunately i fear there are still quite a few of them in our
network.<br>
</div>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
Screenshots - Problem:<br>
<br>
<img src="cid:part1.A40CBE30.8E3065C7@pekarek.at" alt=""><br>
<br>
Screenshots - Should-be:<br>
<img src="cid:part2.7A476734.E2788394@pekarek.at" alt=""><br>
<br>
<blockquote type="cite"
cite="mid:CAKNLPNKKUawPoj+9Vkrc8pCBKmnQP66brBJRyCGxjrJjGZ1qeA@mail.gmail.com">
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr">lg Markus</div>
</div>
</div>
<br>
<div class="gmail_quote">On Tue, Aug 15, 2017 at 12:07 PM, Erich
N. Pekarek <span dir="ltr"><<a
href="mailto:erich@pekarek.at" target="_blank"
moz-do-not-send="true">erich@pekarek.at</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi!<span
class=""><br>
Am 2017-08-15 um 11:43 schrieb Matthias Šubik:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
let me have a guess ...<br>
</blockquote>
</span>
Let me guess a bit further...<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11 Aug 2017, at 15:37, Gui Iribarren <<a
href="mailto:gui@altermundi.net" target="_blank"
moz-do-not-send="true">gui@altermundi.net</a>>
wrote:<br>
<br>
On 11/08/17 13:43, Christian Pock wrote:<br>
</blockquote>
...<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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).<br>
</blockquote>
yeah, "WDS" must always be enabled on all bridges (in
some AirOs<br>
versions is called "Transparent bridge mode") or funny
things happen in<br>
IPv6 world<br>
</blockquote>
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.<br>
If you debug IPv6, please take into account the subtile
differences between IPv4 and IPv6 on layer two.<br>
</blockquote>
</span>
Multicast is not the only problem. Since AirOS is used in
bridged mode, you'd then have 'foreign' MAC addresses
leaving the Wireless Interface.<br>
This is, what WDS is usually for: it resembles 4-address
mode, that rewrites packets.<br>
<br>
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.<br>
If you try to ping them, you will fail, which will be
represented by a FAILED link in die neighbour table.<br>
The funny thing is, that you could still ping6 the link
local address from a direct 1 hop neighbour.<br>
<br>
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.<br>
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.<span
class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
TL;DR: ARP reachability is not v6 reachability.<br>
</blockquote>
</span>
Full Ack.<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">
<br>
just a little reminder,<br>
Matthias<br>
<br>
<br>
--<br>
Wien mailing list<br>
<a href="mailto:Wien@lists.funkfeuer.at" target="_blank"
moz-do-not-send="true">Wien@lists.funkfeuer.at</a><br>
<a
href="https://lists.funkfeuer.at/mailman/listinfo/wien"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.funkfeuer.at/mai<wbr>lman/listinfo/wien</a><br>
</span>
Best regards<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote>
<span class="HOEnZb"><font color="#888888">
Erich</font></span>
<div class="HOEnZb">
<div class="h5"><br>
<br>
--<br>
Wien mailing list<br>
<a href="mailto:Wien@lists.funkfeuer.at" target="_blank"
moz-do-not-send="true">Wien@lists.funkfeuer.at</a><br>
<a
href="https://lists.funkfeuer.at/mailman/listinfo/wien"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.funkfeuer.at/mai<wbr>lman/listinfo/wien</a></div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
br<br>
erich<br>
</body>
</html>