22 Mar, 2014

1 commit

  • With this patch a multicast packet is not always simply flooded anymore,
    the behaviour for the following cases is changed to reduce
    unnecessary overhead:

    If all nodes within the horizon of a certain node have signalized
    multicast listener announcement capability then an IPv6 multicast packet
    with a destination of IPv6 link-local scope (excluding ff02::1) coming
    from the upstream of this node...

    * ...is dropped if there is no according multicast listener in the
    translation table,
    * ...is forwarded via unicast if there is a single node with interested
    multicast listeners
    * ...and otherwise still gets flooded.

    Signed-off-by: Linus Lüssing
    Signed-off-by: Marek Lindner
    Signed-off-by: Antonio Quartulli

    Linus Lüssing
     

12 Jan, 2014

1 commit


09 Jan, 2014

3 commits

  • If a broadcast packet is coming from a client marked as
    isolated, then mark the skb using the isolation mark so
    that netfilter (or any other application) can recognise
    them.

    The mark is written in the skb based on the mask value:
    only bits set in the mask are substitued by those in the
    mark value

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     
  • A client sending packets which mark matches the value
    configured via sysfs has to be identified as isolated using
    the TT_CLIENT_ISOLA flag.

    The match is mask based, meaning that only bits set in the
    mask are compared with those in the mark value.

    If the configured mask is equal to 0 no operation is
    performed.

    Such flag is then advertised within the classic client
    announcement mechanism.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     
  • As suggested by checkpatch, remove all the references to the
    FSF address since the kernel already has one reference in
    its documentation.

    In this way it is easier to update it in case of future
    changes.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     

23 Oct, 2013

1 commit

  • The local translation table size is limited by what can be
    transferred from one node to another via a full table request.

    The number of entries fitting into a full table request depend
    on whether the fragmentation is enabled or not. Therefore this
    patch introduces a max table size check and refuses to add
    more local clients when that size is reached. Moreover, if the
    max full table packet size changes (MTU change or fragmentation
    is disabled) the local table is downsized instantaneously.

    Signed-off-by: Marek Lindner
    Acked-by: Antonio Quartulli

    Marek Lindner
     

20 Oct, 2013

1 commit

  • Instead of unconditionally removing all the TT entries
    served by a given originator, make tt_global_orig_del()
    remove only entries matching a given VLAN identifier
    provided as argument.

    If such argument is negative all the global entries
    served by the originator are removed.

    This change is used into the BLA code to purge entries
    served by a newly discovered Backbone node, but limiting
    the operation only to those connected to the VLAN where the
    backbone has been discovered.

    Cc: Simon Wunderlich
    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     

19 Oct, 2013

2 commits


12 Oct, 2013

2 commits


10 Oct, 2013

2 commits


29 May, 2013

1 commit


19 Jan, 2013

1 commit


15 Nov, 2012

1 commit

  • tt_poss_change is a node-wide flag which tells whether the node is in a roaming
    state (a client recently moved to/away from it) in order to let it apply special
    re-routing rules. However this flag does not give a clear idea of the current
    state because it is not possible to understand *which client* is actually
    involved in the roaming. For this reason a better approach has been chosen:
    instead of using a node-wide variable, the roaming state is now given by a
    per-tt_entry ROAM flag which, in case of packet coming through the node, tells
    the node whether the real destination is in roaming state or not.

    With this flag change, batadv_check_unicast_ttvn() has also been rearranged in
    order to better fit the new re-routing logic and to be much more readable.

    Signed-off-by: Antonio Quartulli

    Antonio Quartulli
     

29 Oct, 2012

1 commit

  • in case of client roaming a new global entry is added while a corresponding
    local one is still present. In this case the node can safely pass the WIFI flag
    from the local to the global entry.

    This change is required to let the AP-isolation correctly working in case of
    roaming: if a generic WIFI client C roams from node A to B, A adds a global
    entry for C without adding any WIFI flag. The latter will be set only later,
    once A has received C's advertisement from B. In this time period the
    AP-Isolation (if enabled) would not correctly work since C is not marked as
    WIFI, so allowing it to communicate with other WIFI clients.

    Signed-off-by: Antonio Quartulli

    Antonio Quartulli
     

23 Aug, 2012

1 commit

  • With the current TT mechanism a new client joining the network is not
    immediately able to communicate with other hosts because its MAC address has not
    been announced yet. This situation holds until the first OGM containing its
    joining event will be spread over the mesh network.

    This behaviour can be acceptable in networks where the originator interval is a
    small value (e.g. 1sec) but if that value is set to an higher time (e.g. 5secs)
    the client could suffer from several malfunctions like DHCP client timeouts,
    etc.

    This patch adds an early detection mechanism that makes nodes in the network
    able to recognise "not yet announced clients" by means of the broadcast packets
    they emitted on connection (e.g. ARP or DHCP request). The added client will
    then be confirmed upon receiving the OGM claiming it or purged if such OGM
    is not received within a fixed amount of time.

    Signed-off-by: Antonio Quartulli

    Antonio Quartulli
     

02 Jul, 2012

2 commits


28 Jun, 2012

1 commit


21 Jun, 2012

2 commits


19 Jun, 2012

1 commit


14 May, 2012

1 commit

  • In case of a client X roaming from a generic node A to another node B, it is
    possible that a third node C gets A's OGM but not B's. At this point in time, if
    C wants to send data to X it will send a unicast packet destined to A. The
    packet header will contain A's last ttvn (C got A's OGM and so it knows it).

    The packet will travel towards A without being intercepted because the ttvn
    contained in its header is the newest for A.

    Once A will receive the packet, A's state will not report to be in a "roaming
    phase" (because, after a roaming, once A sends out its OGM, all the changes are
    committed and the node is considered not to be in the roaming state anymore)
    and it will match the ttvn carried by the packet. Therefore there is no reason
    for A to try to alter the packet's route, thus dropping the packet because the
    destination client is not there anymore.

    However, C is well aware that it's routing information towards the client X is
    outdated as it received an OGM from A saying that the client roamed away.
    Thanks to this detail, this patch introduces a small change in behaviour: as
    long as C is in the state of not knowing the new location of client X it will
    forward the traffic to its last known location using ttvn-1 of the destination.
    By using an older ttvn node A will be forced to re-route the packet.
    Intermediate nodes are also allowed to update the packet's destination as long
    as they have the information about the client's new location.

    Signed-off-by: Antonio Quartulli

    Antonio Quartulli
     

11 May, 2012

1 commit


11 Apr, 2012

1 commit


17 Feb, 2012

1 commit


22 Aug, 2011

5 commits


08 Jul, 2011

1 commit

  • To keep transtable consistency among all the nodes, an originator must
    not send not yet announced clients within a full table TT_RESPONSE.
    Instead, deleted client have to be kept in the table in order to be sent
    within an immediate TT_RESPONSE. In this way all the nodes in the
    network will always provide the same response for the same request.

    All the modification are committed at the next ttvn increment event.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     

05 Jul, 2011

1 commit

  • The tt_local_entry structure now has a 'flags' field. This helps to
    unify the flags format to all the client related structures (tt_global_entry
    and tt_change). The 'never_purge' field is now encoded in the 'flags' one.
    To optimise the usage of this field, its length has been increased to 16bit
    in order to use the eight leading bits (from 0 to 7) to store flags that
    have to be sent on the wire, while the eight ending ones are used for local
    computation only.

    Moreover 'enum tt_change_flags' is now called 'enum tt_client_flags' and the
    defined values apply to the tt_local_entry, tt_global_entry and the tt_change
    'flags' field.

    Signed-off-by: Antonio Quartulli
    Signed-off-by: Marek Lindner

    Antonio Quartulli
     

20 Jun, 2011

2 commits

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

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

    Antonio Quartulli
     

30 May, 2011

1 commit


08 May, 2011

1 commit


12 Feb, 2011

1 commit