1. 20 6月, 2011 3 次提交
    • A
      batman-adv: protect the local and the global trans-tables with rcu · 7683fdc1
      Antonio Quartulli 提交于
      The local and the global translation-tables are now lock free and rcu
      protected.
      Signed-off-by: NAntonio Quartulli <ordex@autistici.org>
      Acked-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      7683fdc1
    • A
      batman-adv: improved roaming mechanism · cc47f66e
      Antonio Quartulli 提交于
      With the current client announcement implementation, in case of roaming,
      an update is triggered on the new AP serving the client. At that point
      the new information is spread around by means of the OGM broadcasting
      mechanism. Until this operations is not executed, no node is able to
      correctly route traffic towards the client. This obviously causes packet
      drops and introduces a delay in the time needed by the client to recover
      its connections.
      
      A new packet type called ROAMING_ADVERTISEMENT is added to account this
      issue.
      
      This message is sent in case of roaming from the new AP serving the
      client to the old one and will contain the client MAC address. In this
      way an out-of-OGM update is immediately committed, so that the old node
      can update its global translation table. Traffic reaching this node will
      then be redirected to the correct destination utilising the fresher
      information. Thus reducing the packet drops and the connection recovery
      delay.
      Signed-off-by: NAntonio Quartulli <ordex@autistici.org>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      cc47f66e
    • A
      batman-adv: improved client announcement mechanism · a73105b8
      Antonio Quartulli 提交于
      The client announcement mechanism informs every mesh node in the network
      of any connected non-mesh client, in order to find the path towards that
      client from any given point in the mesh.
      
      The old implementation was based on the simple idea of appending a data
      buffer to each OGM containing all the client MAC addresses the node is
      serving. All other nodes can populate their global translation tables
      (table which links client MAC addresses to node addresses) using this
      MAC address buffer and linking it to the node's address contained in the
      OGM. A node that wants to contact a client has to lookup the node the
      client is connected to and its address in the global translation table.
      
      It is easy to understand that this implementation suffers from several
      issues:
       - big overhead (each and every OGM contains the entire list of
         connected clients)
       - high latencies for client route updates due to long OGM trip time and
         OGM losses
      
      The new implementation addresses these issues by appending client
      changes (new client joined or a client left) to the OGM instead of
      filling it with all the client addresses each time. In this way nodes
      can modify their global tables by means of "updates", thus reducing the
      overhead within the OGMs.
      
      To keep the entire network in sync each node maintains a translation
      table version number (ttvn) and a translation table checksum. These
      values are spread with the OGM to allow all the network participants to
      determine whether or not they need to update their translation table
      information.
      
      When a translation table lookup is performed in order to send a packet
      to a client attached to another node, the destination's ttvn is added to
      the payload packet. Forwarding nodes can compare the packet's ttvn with
      their destination's ttvn (this node could have a fresher information
      than the source) and re-route the packet if necessary. This greatly
      reduces the packet loss of clients roaming from one AP to the next.
      Signed-off-by: NAntonio Quartulli <ordex@autistici.org>
      Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      a73105b8
  2. 30 5月, 2011 1 次提交
  3. 08 5月, 2011 3 次提交
  4. 02 5月, 2011 1 次提交
  5. 18 4月, 2011 3 次提交
  6. 05 3月, 2011 17 次提交
  7. 31 1月, 2011 1 次提交
  8. 16 1月, 2011 1 次提交
    • S
      batman-adv: Use "__attribute__" shortcut macros · aa0adb1a
      Sven Eckelmann 提交于
      Linux 2.6.21 defines different macros for __attribute__ which are also
      used inside batman-adv. The next version of checkpatch.pl warns about
      the usage of __attribute__((packed))).
      
      Linux 2.6.33 defines an extra macro __always_unused which is used to
      assist source code analyzers and can be used to removed the last
      existing __attribute__ inside the source code.
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      aa0adb1a
  9. 17 12月, 2010 1 次提交
  10. 30 11月, 2010 6 次提交
  11. 21 10月, 2010 1 次提交
  12. 21 9月, 2010 2 次提交
    • S
      Staging: batman-adv: Use refcnt to track usage count of batman_if · 47f621dd
      Sven Eckelmann 提交于
      get_batman_if_by_netdev and get_active_batman_if may leak data from the
      rcu protected list of interfaces. The rcu protected list of all gateway
      nodes leaks the actual data outside the read-side critical area. This is
      not valid as we may free the data using a call_rcu created callback
      after we unlock using rcu_read_unlock. A workaround is to provide a
      reference count to be sure that the memory isn't freed to early.
      
      It is currently only to implement the already existing functionality and
      doesn't provide the full tracking of all usage cases.
      
      Additionally, we must hardif_hold inside the
      rcu_read_lock()..rcu_read_unlock() before we attach to the structure
      which "leaks" it. When another function now removed it from its usage
      context (primary_if, usage on stack, ...) then we must hardif_put it. If
      it is decremented to zero then we can issue the call_rcu to the freeing
      function. So "put" is not allowed inside an rcu_read_lock.
      Signed-off-by: NSven Eckelmann <sven.eckelmann@gmx.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      47f621dd
    • S
      Staging: batman-adv: Use synchronize_rcu instead of call_rcu · 16f9530e
      Sven Eckelmann 提交于
      It is recommended [1] to use synchronize_rcu to simplify the code -
      especially when otherwise extra locking is needed to protect other code
      from picking stale elements. It also protects us for emitting to many
      callbacks which may results in OOM conditions.
      
      The only reason not to use it, would be in performance critical sections
      or when we are not allowed to block.
      
      [1] Documentation/RCU/checklist.txt
      Signed-off-by: NSven Eckelmann <sven.eckelmann@gmx.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      16f9530e