1. 11 3月, 2012 1 次提交
  2. 17 2月, 2012 2 次提交
  3. 22 8月, 2011 1 次提交
  4. 20 6月, 2011 1 次提交
    • 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
  5. 30 5月, 2011 4 次提交
  6. 08 5月, 2011 1 次提交
  7. 02 5月, 2011 1 次提交
  8. 18 4月, 2011 1 次提交
  9. 05 3月, 2011 8 次提交
  10. 12 2月, 2011 2 次提交
  11. 11 2月, 2011 1 次提交
    • S
      batman-adv: Use successive sequence numbers for fragments · c2f7f0e7
      Sven Eckelmann 提交于
      The two fragments of an unicast packet must have successive sequence numbers to
      allow the receiver side to detect matching fragments and merge them again. The
      current implementation doesn't provide that property because a sequence of two
      atomic_inc_return may be interleaved with another sequence which also changes
      the variable.
      
      The access to the fragment sequence number pool has either to be protected by
      correct locking or it has to reserve two sequence numbers in a single fetch.
      The latter one can easily be done by increasing the value of the last used
      sequence number by 2 in a single step. The generated window of two currently
      unused sequence numbers can now be scattered across the two fragments.
      Reported-by: NLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      c2f7f0e7
  12. 08 2月, 2011 1 次提交
  13. 31 1月, 2011 3 次提交
    • S
      batman-adv: Update copyright years · 64afe353
      Sven Eckelmann 提交于
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      64afe353
    • S
      batman-adv: Calculate correct size for merged packets · ae361ce1
      Sven Eckelmann 提交于
      The routing algorithm must be able to decide if a fragment can be merged with
      the missing part and still be passed to a forwarding interface. The fragments
      can only differ by one byte in case that the original payload had an uneven
      length. In that situation the sender has to inform all possible receivers that
      the tail is one byte longer using the flag UNI_FRAG_LARGETAIL.
      
      The combination of UNI_FRAG_LARGETAIL and UNI_FRAG_HEAD flag makes it possible
      to calculate the correct length for even and uneven sized payloads.
      
      The original formula missed to add the unicast header at all and forgot to
      remove the fragment header of the second fragment. This made the results highly
      unreliable and only useful for machines with large differences between the
      configured MTUs.
      Reported-by: NRussell Senior <russell@personaltelco.net>
      Reported-by: NMarek Lindner <lindner_marek@yahoo.de>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      ae361ce1
    • S
      batman-adv: Create roughly equal sized fragments · 5c77d8bb
      Sven Eckelmann 提交于
      The routing algorithm must know how large two fragments are to be able to
      decide that it is safe to merge them or if it should resubmit without waiting
      for the second part. When these two fragments have a too different size, it is
      not possible to guess right in every situation.
      
      The user could easily configure the MTU of the attached cards so that one
      fragment is forwarded and the other one is added to the fragments table to wait
      for the missing part.
      
      For even sized packets, it is possible to split it so that the resulting
      packages are equal sized by ignoring the old non-fragment header at the
      beginning of the original packet.
      
      This still creates different sized fragments for uneven sized packets.
      Reported-by: NRussell Senior <russell@personaltelco.net>
      Reported-by: NMarek Lindner <lindner_marek@yahoo.de>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      5c77d8bb
  14. 14 1月, 2011 1 次提交
    • J
      batman-adv: Even Batman should not dereference NULL pointers · ed7809d9
      Jesper Juhl 提交于
      There's a problem in net/batman-adv/unicast.c::frag_send_skb().
      dev_alloc_skb() allocates memory and may fail, thus returning NULL. If
      this happens we'll pass a NULL pointer on to skb_split() which in turn
      hands it to skb_split_inside_header() from where it gets passed to
      skb_put() that lets skb_tail_pointer() play with it and that function
      dereferences it. And thus the bat dies.
      
      While I was at it I also moved the call to dev_alloc_skb() above the
      assignment to 'unicast_packet' since there's no reason to do that
      assignment if the memory allocation fails.
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NSven Eckelmann <sven@narfation.org>
      ed7809d9
  15. 17 12月, 2010 1 次提交
  16. 30 11月, 2010 11 次提交