1. 29 2月, 2016 4 次提交
    • A
      batman-adv: OGMv2 - implement originators logic · 9323158e
      Antonio Quartulli 提交于
      Add the support for recognising new originators in the
      network and rebroadcast their OGMs.
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      9323158e
    • A
      batman-adv: OGMv2 - add basic infrastructure · 0da00359
      Antonio Quartulli 提交于
      This is the initial implementation of the new OGM protocol
      (version 2). It has been designed to work on top of the
      newly added ELP.
      
      In the previous version the OGM protocol was used to both
      measure link qualities and flood the network with the metric
      information. In this version the protocol is in charge of
      the latter task only, leaving the former to ELP.
      
      This means being able to decouple the interval used by the
      neighbor discovery from the OGM broadcasting, which revealed
      to be costly in dense networks and needed to be relaxed so
      leading to a less responsive routing protocol.
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      0da00359
    • L
      batman-adv: ELP - creating neighbor structures · 162bd64c
      Linus Luessing 提交于
      Initially developed by Linus during a 6 months trainee study
      period in Ascom (Switzerland) AG.
      Signed-off-by: NLinus Luessing <linus.luessing@web.de>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      162bd64c
    • L
      batman-adv: ELP - adding basic infrastructure · d6f94d91
      Linus Luessing 提交于
      The B.A.T.M.A.N. protocol originally only used a single
      message type (called OGM) to determine the link qualities to
      the direct neighbors and spreading these link quality
      information through the whole mesh. This procedure is
      summarized on the BATMAN concept page and explained in
      details in the RFC draft published in 2008.
      
      This approach was chosen for its simplicity during the
      protocol design phase and the implementation. However, it
      also bears some drawbacks:
      
       *  Wireless interfaces usually come with some packet loss,
          therefore a higher broadcast rate is desirable to allow
          a fast reaction on flaky connections.
          Other interfaces of the same host might be connected to
          Ethernet LANs / VPNs / etc which rarely exhibit packet
          loss would benefit from a lower broadcast rate to reduce
          overhead.
       *  It generally is more desirable to detect local link
          quality changes at a faster rate than propagating all
          these changes through the entire mesh (the far end of
          the mesh does not need to care about local link quality
          changes that much). Other optimizations strategies, like
          reducing overhead, might be possible if OGMs weren't
          used for all tasks in the mesh at the same time.
      
      As a result detecting local link qualities shall be handled
      by an independent message type, ELP, whereas the OGM message
      type remains responsible for flooding the mesh with these
      link quality information and determining the overall path
      transmit qualities.
      
      Developed by Linus during a 6 months trainee study period in
      Ascom (Switzerland) AG.
      Signed-off-by: NLinus Luessing <linus.luessing@web.de>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      d6f94d91
  2. 10 2月, 2016 18 次提交
  3. 02 2月, 2016 4 次提交
  4. 09 1月, 2016 4 次提交
  5. 16 12月, 2015 5 次提交
  6. 28 8月, 2015 1 次提交
  7. 25 8月, 2015 3 次提交
  8. 15 8月, 2015 1 次提交
    • L
      batman-adv: Fix potential synchronization issues in mcast tvlv handler · 8a4023c5
      Linus Lüssing 提交于
      So far the mcast tvlv handler did not anticipate the processing of
      multiple incoming OGMs from the same originator at the same time. This
      can lead to various issues:
      
      * Broken refcounting: For instance two mcast handlers might both assume
        that an originator just got multicast capabilities and will together
        wrongly decrease mcast.num_disabled by two, potentially leading to
        an integer underflow.
      
      * Potential kernel panic on hlist_del_rcu(): Two mcast handlers might
        one after another try to do an
        hlist_del_rcu(&orig->mcast_want_all_*_node). The second one will
        cause memory corruption / crashes.
        (Reported by: Sven Eckelmann <sven@narfation.org>)
      
      Right in the beginning the code path makes assumptions about the current
      multicast related state of an originator and bases all updates on that. The
      easiest and least error prune way to fix the issues in this case is to
      serialize multiple mcast handler invocations with a spinlock.
      
      Fixes: 60432d75 ("batman-adv: Announce new capability via multicast TVLV")
      Signed-off-by: NLinus Lüssing <linus.luessing@c0d3.blue>
      Signed-off-by: NMarek Lindner <mareklindner@neomailbox.ch>
      Signed-off-by: NAntonio Quartulli <antonio@meshcoding.com>
      8a4023c5