TT-Flags

Note: This page documents internal stuff of batman-adv. It describes the internal state representation of client entries in translation tables. Read with care

Flags overview

This section describes the flags used in the TT code, what they mean and where they are used. There are 3 possible locations where the flags field is used:

OGM: there is a flag field within each of the tt_change structs which are sent along with the OGM frames.
tt_global: these structs are stored in the global hash table and represent the mapping which originator hosts which client.
tt_local: these structs are stored in the local hash table and represent the the clients which the own node hosts.

Name	used in	Description
TT_CLIENT_DEL	OGM	The TT_CLIENT_DEL flag is used in the OGM tt_change entries to distinguish whether the entry should be added (no DEL flag set) or deleted (DEL flag set). It is also set to pass add/deletion information between functions internally.
TT_CLIENT_ROAM	OGM, tt_global	The TT_CLIENT_ROAM flag is used to announce in an OGM tt_change entry that a client is deleted because of roaming. The node which receives this entry may still send traffic to this node, which will re-route it to the new destination, until an OGM from the new node now hosting the client is received. The tt_global entry with the old node for this client is then replaced with the new entry. Other than thise case, whenever a node receives a Roaming_Advertisement packet, it will add a new tt_global entry which will create a new route to this client. This tt_global entry is marked with the TT_CLIENT_ROAM flag so that it can be eventually deleted if no node will claim the client afterwards (with an ADD event)
TT_CLIENT_WIFI	OGM, tt_local, tt_global	The TT_CLIENT_WIFI flag is used to announce that this client is a WiFi client. This information is used for the AP isolation feature.
TT_CLIENT_ISOLA	OGM, tt_local, tt_global	The TT_CLIENT_ISOLA flag is used to announce that packets sent by this client were marked with the isolation mark when received on the soft-interface. A node receiving packets from this client has to mark the related skbs with the configured isolation mark before delivering them to its own soft-interface. Moreover two clients marked with this flag cannot exchange packets over the mesh network (this behavior is part of the extended isolation).
TT_CLIENT_NOPURGE	tt_local	The private TT_CLIENT_NOPURGE is used to mark a local client to not be purged. This is only used for the address of the mesh soft interface, which should always be announced and never deleted/purged.
TT_CLIENT_NEW	tt_local	The private TT_CLIENT_NEW flag is used to mark clients which have been added to the local list, but not yet announced within an OGM.
TT_CLIENT_PENDING	tt_local	The private TT_CLIENT_PENDING flag is set for local entries which should be removed. These entries are not removed immediately, but when the next OGM is sent, to keep the information sent with the OGM or tt_requests consistent.
TT_CLIENT_TEMP	tt_global	This flag is used to mark a client that has not been advertised by any node yet, but it has already been detected to be part of the network.

Changes within in bridge loop avoidance II

In blaII, a tt_global struct is extend to not only contain one originator entry which announces the client, but a list of originators. Each originator in this list announces the same client, which may happen if these originators are connected to the same backbone network where this client is located.

Mesh nodes on the same backbone gateway ignore each others tt announcements (tt updates, roaming advertisements, etc) and can therefore have the same local list.

This extension also affects the flag handling, which will be explained for each flag in detail in this section.

The tt_local as well as the tt_global struct keep their flag fields as before. The flags in the tt_global struct are valid for all originators within its list.

TT_CLIENT_DEL

As this flag is only used in OGM and for internal function handling, there is no change.

TT_CLIENT_ROAM

For OGM handling, there is no change - the TT_CLIENT_ROAM flag is sent along with a TT_CLIENT_DEL flag when a client has been removed because of roaming.

For internal use, there are some changes: If we receive a TT_CLIENT_DEL change with TT_CLIENT_ROAM flag set, we remove the originator from the tt_global originator list if there is another entry left - we can still use the other originator to reach our client. If there is only one originator left in the tt_global originator list, we set the TT_CLIENT_ROAM flag and start the timeout procedure. If we receive an ADD for this client in time, we remove the previous originator and add the new originator in the list. If no ADD is received and the timeout is hit, the tt_global entry is deleted.

Example:

Client X moves from LAN 1 (nodes A and B) to LAN 2 (nodes C and D). Node C and node D will send roaming advertisements to node A and B respectively. Node A and B will then send a tt_change with TT_CLIENT_DEL and TT_CLIENT_ROAM flag for X. Nodes C and D will send a tt_change without TT_CLIENT_DEL (therefore an ADD) to announce that they added X.

Depending on the order of arrival of the OGMs at node E, we have different behaviours.

Example1: order of arrival: DEL from A, ADD from C, DEL from B, ADD from D

DEL from A: A is removed from the tt_global originator list for X, only B remains.
ADD from C: C is added to the tt_global originator list for X, now containing B and C
DEL from B: B is removed from the tt_global originator list for X, only C remains.
ADD from D: D is added to the tt_global originator list for X, now containing C and D

Example2: order of arrival: DEL from A, DEL from B, ADD from C, ADD from D

DEL from A: A is removed from the tt_global originator list for X, only B remains.
DEL from B: B is NOT removed from the tt_global originator list for X, it remains but TT_CLIENT_ROAM flag is set for this tt_global entry, and the timer is started.
ADD from C: C is added to the tt_global originator list for X, B is deleted, the TT_CLIENT_ROAM flag is cleared and the timer is stopped. The list now contains C.
ADD from D: D is added to the tt_global originator list for X, now containing C and D

TT_CLIENT_WIFI

The flag is added whenever a node announced this client as WIFI client. In a backbone gateway, it might be possible that only one node sees this client as WiFi client where as the other nodes receive its frames only via Ethernet through the bridge. However, this client is still to be treated as WiFi client.

As a WiFi client can never become an Ethernet client again (the MAC address is connected to the NIC), we never clear this flag even if a node can not see this client directly as WiFi client.

TT_CLIENT_NOPURGE, TT_CLIENT_NEW, TT_CLIENT_PENDING

No changes here.