Bug #295
closedalfred doesn't start if link-local address doesn't match interface mac address
0%
Description
I noticed this on a ubiquiti bullet m5 when using its ethernet interface in bat0. The bat0 interface is part of a bridge, and in recent LEDE (e.g. , reboot-1444-g1bb914d) the bridge's mac address is not matched by its link-local address. Alfred tries to bind that address, fails and exits. Or something. alfred_2016.2-0_mips_34kc.ipk If the eth0 interface is part of the bridge and not the bat0 interface, then the link-local and mac address match and alfred works fine.
# /etc/init.d/alfred restart /etc/init.d/alfred: waiting 30 secs for br-pub address... /etc/init.d/alfred: starting alfred /etc/init.d/alfred: starting batadv-vis can't connect to unix socket: Connection refused
Manually changing the bridge mac address to match the link-local address allows alfred to start. Also /etc/init.d/network restart ; /etc/init.d/alfred/restart sometimes works. Maybe alfred shouldn't assume it can compute the expected link-local address from the mac address.
Updated by Sven Eckelmann over 7 years ago
- Assignee set to Simon Wunderlich
This is a requirement of alfred. Otherwise the best path calculation of alfred (using the batman-adv TQ) and the synchronization will not work correctly.
@Simon Wunderlich: What is you opinion about it?
Updated by Simon Wunderlich over 7 years ago
Yes, we expect that the IPv6 link local address matches the interfaces MAC - many assumptions within alfred are built on that fact.
I'm not sure if this is actually in a standard, but all my boxes work like that. If more recent LEDE builds don't do that any more, I would expect a bug in LEDE here.
Updated by Simon Wunderlich over 7 years ago
- Status changed from New to Rejected
Updated by Sven Eckelmann over 7 years ago
To clarify it: alfred requires RFC4862 stateless link local addresses (which are formed via the mac address) and not ones generated via RFC4941