On Tue, May 10, 2011 at 10:40 PM, Roland Bless
<roland.bless@kit.edu> wrote:
Hi Dave,
On 11.05.2011 05:32, Dave Taht wrote:
> 1) in a wireshark analysis, the %interface part is lost
But your wireshark is listening on some specific interface,
isn't it?
No. It is listening on the wildcard interface. Of which there are 8.
This interface is your context then and link locals are
unique on that particular link (which is assured by
Duplicate Address Detection).
I wouldn't be so sure in the case of link-local addresses and vlans and bridges. At least: I'm no longer sure...
After digging into the code in openwrt (very) late last night I spotted this in base-files/files/lib/network/config.sh
config_get macaddr "$config" macaddr
[ -x /usr/sbin/brctl ] && {
ifconfig "br-$config" 2>/dev/null >/dev/null && {
local newdevs devices
config_get devices "$config" device
for dev in $(sort_list "$devices" "$iface"); do
append newdevs "$dev"
done
uci_set_state network "$config" device "$newdevs"
$DEBUG ifconfig "$iface" 0.0.0.0
$DEBUG do_sysctl "net.ipv6.conf.$iface.disable_ipv6" 1
$DEBUG brctl addif "br-$config" "$iface"
# Bridge existed already. No further processing necesary
} || {
local stp
config_get_bool stp "$config" stp 0
$DEBUG brctl addbr "br-$config"
$DEBUG brctl setfd "br-$config" 0
$DEBUG ifconfig "$iface" 0.0.0.0
$DEBUG do_sysctl "net.ipv6.conf.$iface.disable_ipv6" 1
$DEBUG brctl addif "br-$config" "$iface"
$DEBUG brctl stp "br-$config" $stp
$DEBUG ifconfig "br-$config" up
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....
Each wlan has a unique MAC id, and thus I hope will create a unique bridge id EUI-64.
And as for why it disables ipv6 on the underlying interface...
Are you facing the problem from the
switch's perspective (e.g., that you can determine the receiving
i/f from the destination address of received packets) or from another
another device's perspective?
routers' perspective.
> 2) we have 2^64 possible choices for fe80 addresses. I don't see what
> having them all be the same buys me.
You can assign an individual fe80:: address to an interface, e.g.,
fe80::b101 for bridge one interface 1, fe80::b102 bridge one
interface 2 etc. if that helps. But be aware that it may create
address collisions in case you have two such bridges on the same
link :-( Therefore, using (modified) EUI-64 addresses within the
64-bit seems to be a good choice.
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....
> 3) It worries me in the babel routing protocol
Sorry, I didn't study the spec so far. What is the
particular problem there? Maybe there is a problem
with the assumptions in the protocol.
It's a new RFC. Could be. It's a neat protocol tho.
> 4) My bridges are misbehaving over ipv6 in the general case and I'm
> willing to grasp at straws.
What is that misbehavior? That a bridge is using the same link local
address on each of its links? That's ok as long as its unique on that
particular on-link subnet.
They be misbehaving - multicast weirdnesses.
Regards,
Roland