<br><br><div class="gmail_quote">On Tue, May 10, 2011 at 10:40 PM, Roland Bless <span dir="ltr"><<a href="mailto:roland.bless@kit.edu">roland.bless@kit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Dave,<br>
<div class="im"><br>
On 11.05.2011 05:32, Dave Taht wrote:<br>
> 1) in a wireshark analysis, the %interface part is lost<br>
<br>
</div>But your wireshark is listening on some specific interface,<br>
isn't it? </blockquote><div><br>No. It is listening on the wildcard interface. Of which there are 8.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
This interface is your context then and link locals are<br>
unique on that particular link (which is assured by<br>
Duplicate Address Detection). </blockquote><div><br>I wouldn't be so sure in the case of link-local addresses and vlans and bridges. At least: I'm no longer sure...<br><br>After digging into the code in openwrt (very) late last night I spotted this in base-files/files/lib/network/config.sh<br>
<br> config_get macaddr "$config" macaddr<br> [ -x /usr/sbin/brctl ] && {<br> ifconfig "br-$config" 2>/dev/null >/dev/null && {<br>
local newdevs devices<br> config_get devices "$config" device<br> for dev in $(sort_list "$devices" "$iface"); do<br>
append newdevs "$dev"<br> done<br> uci_set_state network "$config" device "$newdevs"<br>
$DEBUG ifconfig "$iface" 0.0.0.0<br> $DEBUG do_sysctl "net.ipv6.conf.$iface.disable_ipv6" 1<br> $DEBUG brctl addif "br-$config" "$iface"<br>
# Bridge existed already. No further processing necesary<br> } || {<br> local stp<br> config_get_bool stp "$config" stp 0<br>
$DEBUG brctl addbr "br-$config"<br> $DEBUG brctl setfd "br-$config" 0<br> $DEBUG ifconfig "$iface" 0.0.0.0<br>
$DEBUG do_sysctl "net.ipv6.conf.$iface.disable_ipv6" 1<br> $DEBUG brctl addif "br-$config" "$iface"<br> $DEBUG brctl stp "br-$config" $stp<br>
$DEBUG ifconfig "br-$config" up<br><br>it looks like I can "prepend" rather than "append" in order to get the wlan* interface first in the bridge (rather than eth*), or defer bridge creation until the other interfaces are brought up....<br>
<br>Each wlan has a unique MAC id, and thus I hope will create a unique bridge id EUI-64.<br><br>And as for why it disables ipv6 on the underlying interface...<br><br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Are you facing the problem from the<br>
switch's perspective (e.g., that you can determine the receiving<br>
i/f from the destination address of received packets) or from another<br>
another device's perspective?<br>
<div class="im"><br></div></blockquote><div>routers' perspective. <br></div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> 2) we have 2^64 possible choices for fe80 addresses. I don't see what<br>
> having them all be the same buys me.<br>
<br>
</div>You can assign an individual fe80:: address to an interface, e.g.,<br>
fe80::b101 for bridge one interface 1, fe80::b102 bridge one<br>
interface 2 etc. if that helps. But be aware that it may create<br>
address collisions in case you have two such bridges on the same<br>
link :-( Therefore, using (modified) EUI-64 addresses within the<br>
64-bit seems to be a good choice.<br>
<div class="im"><br></div></blockquote><div><br>I think using ::b101 is a bad idea. EUI-64 is the way to go. I wanted to use up the extra 52 bits though in some sane manner....<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> 3) It worries me in the babel routing protocol<br>
<br>
</div>Sorry, I didn't study the spec so far. What is the<br>
particular problem there? Maybe there is a problem<br>
with the assumptions in the protocol.<br>
<div class="im"><br></div></blockquote><div><br>It's a new RFC. Could be. It's a neat protocol tho.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> 4) My bridges are misbehaving over ipv6 in the general case and I'm<br>
> willing to grasp at straws.<br>
<br>
</div>What is that misbehavior? That a bridge is using the same link local<br>
address on each of its links? That's ok as long as its unique on that<br>
particular on-link subnet.<br>
<br></blockquote><div><br>They be misbehaving - multicast weirdnesses.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Regards,<br>
<font color="#888888"> Roland<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Dave Täht<br>SKYPE: davetaht<br>US Tel: 1-239-829-5608<br><a href="http://the-edge.blogspot.com" target="_blank">http://the-edge.blogspot.com</a> <br>