Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 02 7月, 2012 2 次提交
  3. 28 6月, 2012 5 次提交
  5. 26 6月, 2012 2 次提交
  7. 25 6月, 2012 5 次提交
  9. 23 6月, 2012 2 次提交
    • A
      batman-adv: fix race condition in TT full-table replacement · 8b8e4bc0
      由 Antonio Quartulli 提交于 
      bug introduced with cea194d90b11aff7fc289149e4c7f305fad3535a

In the current TT code, when a TT_Response containing a full table is received
from an originator, first the node purges all the clients for that originator in
the global translation-table and then merges the newly received table.
During the purging phase each client deletion is done by means of a call_rcu()
invocation and at the end of this phase the global entry counter for that
originator is set to 0. However the invoked rcu function decreases the global
entry counter for that originator by one too and since the rcu invocation is
likely to be postponed, the node will end up in first setting the counter to 0
and then decreasing it one by one for each deleted client.

This bug leads to having a wrong global entry counter for the related node, say
X. Then when the node with the broken counter will answer to a TT_REQUEST on
behalf of node X, it will create faulty TT_RESPONSE that will generate an
unrecoverable situation on the node that asked for the full table recover.

The non-recoverability is given by the fact that the node with the broken
counter will keep answering on behalf of X because its knowledge about X's state
(ttvn + tt_crc) is correct.

To solve this problem the counter is not explicitly set to 0 anymore and the
counter decrement is performed right before the invocation of call_rcu().
Signed-off-by: NAntonio Quartulli <ordex@autistici.org>
      8b8e4bc0
    • M
      batman-adv: only drop packets of known wifi clients · 5870adc6
      由 Marek Lindner 提交于 
      bug introduced with 59b699cd

If the source or destination mac address of an ethernet packet
could not be found in the translation table the packet was
dropped if AP isolation was turned on. This behavior would
make it impossible to send broadcast packets over the mesh as
the broadcast address will never enter the translation table.
Signed-off-by: NMarek Lindner <lindner_marek@yahoo.de>
Acked-by: NAntonio Quartulli <ordex@autistici.org>
      5870adc6
  11. 21 6月, 2012 8 次提交
  13. 19 6月, 2012 5 次提交
  15. 14 5月, 2012 2 次提交
    • A
      batman-adv: unset the TT_CLIENT_PENDING flag if the new local entry already exists · 521251f2
      由 Antonio Quartulli 提交于 
      When trying to add a new tt_local_entry, if such entry already exists, we have
to ensure that the TT_CLIENT_PENDING flag is not set, otherwise the entry will
be deleted soon.
Reported-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NAntonio Quartulli <ordex@autistici.org>
      521251f2
    • A
      batman-adv: improve unicast packet (re)routing · 3275e7cc
      由 Antonio Quartulli 提交于 
      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: NAntonio Quartulli <ordex@autistici.org>
      3275e7cc
  17. 11 5月, 2012 1 次提交
  19. 18 4月, 2012 1 次提交
  21. 11 4月, 2012 3 次提交
  23. 11 3月, 2012 1 次提交
  25. 28 2月, 2012 1 次提交
  27. 17 2月, 2012 2 次提交