22 Aug, 2011

1 commit


20 Jun, 2011

1 commit

  • 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: Antonio Quartulli
    Signed-off-by: Marek Lindner
    Signed-off-by: Sven Eckelmann

    Antonio Quartulli
     

30 May, 2011

4 commits


08 May, 2011

1 commit


02 May, 2011

1 commit


18 Apr, 2011

1 commit


07 Mar, 2011

1 commit


05 Mar, 2011

8 commits


12 Feb, 2011

3 commits


11 Feb, 2011

1 commit

  • 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: Linus Lüssing
    Signed-off-by: Sven Eckelmann

    Sven Eckelmann
     

09 Feb, 2011

1 commit


08 Feb, 2011

1 commit

  • We access the data inside the skbs of two fragments directly using memmove
    during the merge. The data of the skb could span over multiple skb pages. An
    direct access without knowledge about the pages would lead to an invalid memory
    access.

    Signed-off-by: Sven Eckelmann
    [lindner_marek@yahoo.de: Move return from function to the end]
    Signed-off-by: Marek Lindner

    Sven Eckelmann
     

31 Jan, 2011

3 commits

  • Signed-off-by: Sven Eckelmann

    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: Russell Senior
    Reported-by: Marek Lindner
    Signed-off-by: Sven Eckelmann

    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: Russell Senior
    Reported-by: Marek Lindner
    Signed-off-by: Sven Eckelmann

    Sven Eckelmann
     

14 Jan, 2011

1 commit

  • 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: Jesper Juhl
    Signed-off-by: Sven Eckelmann

    Jesper Juhl
     

17 Dec, 2010

1 commit

  • B.A.T.M.A.N. (better approach to mobile ad-hoc networking) is a routing
    protocol for multi-hop ad-hoc mesh networks. The networks may be wired or
    wireless. See http://www.open-mesh.org/ for more information and user space
    tools.

    Signed-off-by: Sven Eckelmann
    Signed-off-by: David S. Miller

    Sven Eckelmann