Bugzilla – Bug 745
OLSR does not respond to link or address notifications
Last modified: 2016-01-19 18:45:28 EST
Follow up of bug 735. This comment #13 from bug 735 describes a suggested path forward, mirroring what has been done in AODV (In reply to comment #9) > I think there need to be a couple of things done still to finish this off: > > 1) these methods are null in OlsrRoutingProtocol I can say what they are doing in AODV model: > void > RoutingProtocol::NotifyInterfaceUp (uint32_t i) > {} if not loopback, open socket, add address to m_socketAddresses and connect to MAC layer notifications. > void > RoutingProtocol::NotifyInterfaceDown (uint32_t i) > {} disconnect from MAC layer notifications, close socket and erase record from m_socketAddresses. > void > RoutingProtocol::NotifyAddAddress (uint32_t interface, Ipv4InterfaceAddress > address) > {} if this is the only address of this interface, open socket and add it to m_socketAddresses. > void > RoutingProtocol::NotifyRemoveAddress (uint32_t interface, Ipv4InterfaceAddress > address) > {} if this interface is used by AODV, close socket and erase it from m_socketAddresses. If interface still has addresses, open socket and add it to m_socketAddresses using new 0-th address. > What should be the behavior for AddAddress or NotifyInterfaceUp? If a new > interface or a zeroth address on an interface being added, should we add to > m_socketAddresses and open a new socket? The logic above is somehow arbitrary and I am neutral about reproducing it in OLSR or not.
This is not a bug, it's a possible enhancement. I am reluctant to work on it, it seems rather superfluous. (In reply to comment #0) > > I can say what they are doing in AODV model: > > > void > > RoutingProtocol::NotifyInterfaceUp (uint32_t i) > > {} > > if not loopback, open socket, add address to m_socketAddresses and connect to > MAC layer notifications. Sounds good. > > > void > > RoutingProtocol::NotifyInterfaceDown (uint32_t i) > > {} > > disconnect from MAC layer notifications, close socket and erase record from > m_socketAddresses. RFC 3626 does not help with these interface up/down issues. It might make sense also to delete some data from the OLSR state, for instance neighbor tuples using that interface, two-hop neighbors reachable by those removed neighbors, and recompute MPR set and routing table. > > > void > > RoutingProtocol::NotifyAddAddress (uint32_t interface, Ipv4InterfaceAddress > > address) > > {} > > if this is the only address of this interface, open socket and add it to > m_socketAddresses. Not sure what are the implications for OLSR of an interface with multiple addresses. It probably just doesn't make sense, as it might require sending multiple HELLOs from the same interface at the same time, each HELLO with a different source address. > > > void > > RoutingProtocol::NotifyRemoveAddress (uint32_t interface, Ipv4InterfaceAddress > > address) > > {} > > if this interface is used by AODV, close socket and erase it from > m_socketAddresses. If interface still has addresses, open socket and add it to > m_socketAddresses using new 0-th address. > > > What should be the behavior for AddAddress or NotifyInterfaceUp? If a new > > interface or a zeroth address on an interface being added, should we add to > > m_socketAddresses and open a new socket? > > The logic above is somehow arbitrary and I am neutral about reproducing it in > OLSR or not.
*** Bug 703 has been marked as a duplicate of this bug. ***