[maint] batman-adv: fix TT sync flag inconsistencies

  This patch fixes an issue in the translation table code potentially
leading to a TT Request + Response storm. The issue may occur for nodes
involving BLA and an inconsistent configuration of the batman-adv AP
isolation feature. However, since the new multicast optimizations, a
single, malformed packet may lead to a mesh-wide, persistent
Denial-of-Service, too.

The issue occurs because nodes are currently OR-ing the TT sync flags of
all originators announcing a specific MAC address via the
translation table. When an intermediate node now receives a TT Request
and wants to answer this on behave of the destination node then this
intermediate node now responds with an altered flag field and broken
CRC. The next OGM of the real destination will lead to a CRC mismatch
and triggering a TT Request and Response again.

Furthermore, the OR-ing is currently never undone as long as at least
one originator announcing the according MAC address remains, leading to
the potential persistency of this issue.

This patch fixes this issue by storing the flags used in the CRC
calculation on a a per TT orig entry basis to be able to respond with
the correct, original flags in an intermediate TT Response for one
thing. And to be able to correctly unset sync flags once all nodes
announcing a sync flag vanish for another.

Fixes: fa614fd04692 ("batman-adv: fix tt_global_entries flags update")
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
---
 net/batman-adv/translation-table.c | 62 ++++++++++++++++++++++++++++++--------
 net/batman-adv/types.h             |  2 ++
 2 files changed, 51 insertions(+), 13 deletions(-)
  

On Fri, Jun 23, 2017 at 05:48:26PM +0200, Linus Lüssing wrote:
> Fixes: fa614fd04692 ("batman-adv: fix tt_global_entries flags update")
> Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>

Reported-by: Simon Wunderlich <sw@simonwunderlich.de>
  

On Fri, Jun 23, 2017 at 05:48:26PM +0200, Linus Lüssing wrote:
> [...]
> This patch fixes this issue by storing the flags used in the CRC
> calculation on a a per TT orig entry basis to be able to respond with
> the correct, original flags in an intermediate TT Response for one
> thing. And to be able to correctly unset sync flags once all nodes
> announcing a sync flag vanish for another.
> 
> Fixes: fa614fd04692 ("batman-adv: fix tt_global_entries flags update")
> [...]

By the way, I was able to reliably reproduce the issue within
network namespaces with following two scrips (with the latter
running the former):

https://metameute.de/~tux/batman-adv/setup-batman-netns.sh
https://metameute.de/~tux/batman-adv/test-batman-bla.sh

The scripts create a simple three node topology like:

A === B === C
      |     |
      -------
         |
         c

A, B, C are connected in a line topology, B and C share the same
BLA backbone. There is only one host, c, in the upper mesh layer.

The scripts turn on the extended isolation just on B for a few
seconds via the isolation mark / ebtables and then disables it
again.

So, in the end, the local translation table for B and C looks
sane again, with no wifi or isolation flag. However A continues
sending TT Requests while receiving invalid TT Responses for C.

(I used "batctl tracedump" to check, as "batctl log" unfortunately
does not work with network namespaces yet)


After applying this patch, the endless TT Requests/Replies do
not appear for me anymore. And the global translation table on
all three nodes looks fine again, too (that is the isolation flag
is gone again as it is supposed to while it wrongfully persisted
for A without this patch).

Regards, Linus
  

On Friday, June 23, 2017 5:48:26 PM HKT Linus Lüssing wrote:
> @@ -1946,6 +1977,7 @@ batadv_tt_global_dump_subentry(struct sk_buff *msg,
> u32 portid, u32 seq, struct batadv_tt_orig_list_entry *orig, bool best)
>  {
> +       u16 flags = (common->flags & (~BATADV_TT_SYNC_MASK)) | orig->flags;

Why do we need to output the combined global (partially masked) and the flags 
propagated by originator ? Shouldn't writing orig->flags be what we want ?

Cheers,
Marek
  

Hi Marek,

Thanks for having a first glance at this patch!

On Sat, Jul 01, 2017 at 11:34:37PM +0800, Marek Lindner wrote:
> On Friday, June 23, 2017 5:48:26 PM HKT Linus Lüssing wrote:
> > @@ -1946,6 +1977,7 @@ batadv_tt_global_dump_subentry(struct sk_buff *msg,
> > u32 portid, u32 seq, struct batadv_tt_orig_list_entry *orig, bool best)
> >  {
> > +       u16 flags = (common->flags & (~BATADV_TT_SYNC_MASK)) | orig->flags;
> 
> Why do we need to output the combined global (partially masked) and the flags 
> propagated by originator ? Shouldn't writing orig->flags be what we want ?

I thought it'd be helpful to be able to look at the sync flags
on a per originator basis. So that users can more easily spot nodes with
broken flags and can take action sooner.

Next to Simon's report we have had two more, independent reporters
stumbling over the same issue later. This would help people to more
easily identify which nodes and maybe what kind of nodes are usually
sending broken packets. Parsing the "batctl log" for that is also
possible for this, but not as easy as looking at "batctl tg". And
"batctl log" isn't available in a batman-adv default build anyway.

Does that make sense?

Regards, Linus
  

On Sat, Jul 01, 2017 at 11:34:37PM +0800, Marek Lindner wrote:
> On Friday, June 23, 2017 5:48:26 PM HKT Linus Lüssing wrote:
> > @@ -1946,6 +1977,7 @@ batadv_tt_global_dump_subentry(struct sk_buff *msg,
> > u32 portid, u32 seq, struct batadv_tt_orig_list_entry *orig, bool best)
> >  {
> > +       u16 flags = (common->flags & (~BATADV_TT_SYNC_MASK)) | orig->flags;
> 
> Why do we need to output the combined global (partially masked) and the flags 
> propagated by originator ? Shouldn't writing orig->flags be what we want ?

With this patch orig->flags only stores the TT SYNC bits.
Everything other flag in there is always 0. So printing just orig->flags
would only display the isolation and wireless flag and would omit
the roaming and temporary flag.

Compare with:

@@ -1723,7 +1753,8 @@ static bool batadv_tt_global_add(struct batadv_priv *bat_priv,
        }
 add_orig_entry:
        /* add the new orig_entry (if needed) or update it */
-       batadv_tt_global_orig_entry_add(tt_global_entry, orig_node, ttvn);
+       batadv_tt_global_orig_entry_add(tt_global_entry, orig_node, ttvn,
+                                       flags & BATADV_TT_SYNC_MASK);

---

Regards, Linus
  

On Saturday, July 1, 2017 6:47:11 PM HKT Linus Lüssing wrote:
> On Sat, Jul 01, 2017 at 11:34:37PM +0800, Marek Lindner wrote:
> > On Friday, June 23, 2017 5:48:26 PM HKT Linus Lüssing wrote:
> > > @@ -1946,6 +1977,7 @@ batadv_tt_global_dump_subentry(struct sk_buff
> > > *msg,
> > > u32 portid, u32 seq, struct batadv_tt_orig_list_entry *orig, bool best)
> > > {
> > > +       u16 flags = (common->flags & (~BATADV_TT_SYNC_MASK)) |
> > > orig->flags;
> > 
> > Why do we need to output the combined global (partially masked) and the
> > flags  propagated by originator ? Shouldn't writing orig->flags be what
> > we want ?
> I thought it'd be helpful to be able to look at the sync flags
> on a per originator basis. So that users can more easily spot nodes with
> broken flags and can take action sooner.

Yeah, makes sense. Needed some help from Antonio to not get lost in the TT 
flags jungle.

Cheers,
Marek
  

On Sat, Jul 01, 2017 at 07:34:56PM +0200, Linus Lüssing wrote:
> On Sat, Jul 01, 2017 at 11:34:37PM +0800, Marek Lindner wrote:
> > On Friday, June 23, 2017 5:48:26 PM HKT Linus Lüssing wrote:
> > > @@ -1946,6 +1977,7 @@ batadv_tt_global_dump_subentry(struct sk_buff *msg,
> > > u32 portid, u32 seq, struct batadv_tt_orig_list_entry *orig, bool best)
> > >  {
> > > +       u16 flags = (common->flags & (~BATADV_TT_SYNC_MASK)) | orig->flags;
> > 
> > Why do we need to output the combined global (partially masked) and the flags 
> > propagated by originator ? Shouldn't writing orig->flags be what we want ?
> 
> With this patch orig->flags only stores the TT SYNC bits.
> Everything other flag in there is always 0. So printing just orig->flags
> would only display the isolation and wireless flag and would omit
> the roaming and temporary flag.
> 
> Compare with:
> 
> @@ -1723,7 +1753,8 @@ static bool batadv_tt_global_add(struct batadv_priv *bat_priv,
>         }
>  add_orig_entry:
>         /* add the new orig_entry (if needed) or update it */
> -       batadv_tt_global_orig_entry_add(tt_global_entry, orig_node, ttvn);
> +       batadv_tt_global_orig_entry_add(tt_global_entry, orig_node, ttvn,
> +                                       flags & BATADV_TT_SYNC_MASK);

Linus,

each originator announces flags covered by BATADV_TT_REMOTE_MASK (0x00FF),
however you are extracting only those covered by BATADV_TT_SYNC_MASK (0x00F0).

Am I wrong or this is preventing the other 4 REMOTE flags (0x000F) to be set in
tt_global_entry->common->flags (because you always filter them out when updating
the entry)?


Cheers,
  

Hi Antonio,

Thanks for looking at it, too :-).

On Mon, Jul 03, 2017 at 12:08:01PM +0800, Antonio Quartulli wrote:
> [...]
> 
> Linus,
> 
> each originator announces flags covered by BATADV_TT_REMOTE_MASK (0x00FF),
> however you are extracting only those covered by BATADV_TT_SYNC_MASK (0x00F0).
> 
> Am I wrong or this is preventing the other 4 REMOTE flags (0x000F) to be set in
> tt_global_entry->common->flags (because you always filter them out when updating
> the entry)?

Hm, as far as I can tell, the ROAM flag is still set here:
http://elixir.free-electrons.com/linux/latest/source/net/batman-adv/translation-table.c#L787

And unset here:
http://elixir.free-electrons.com/linux/latest/source/net/batman-adv/translation-table.c#L1720

And the TEMP flag is unset here:
http://elixir.free-electrons.com/linux/latest/source/net/batman-adv/translation-table.c#L1702

And is set... hm, ok, was the TEMP flag set by the now deleted
"common->flags |= flags;"?

But then I'm confused, how would the TEMP flag have worked before
patch fa614fd04692? Or was that patch not only supposed to fix the
WIFI but also the TEMP flag?

If so, what would you prefer, should I replace the
"common->flags |= flags" with something like a
"common->flags |= flags & (~BATADV_TT_SYNC_MASK)"? Or would you
prefer setting the TEMP flag somewhere else explicitly, similarly
like we seemingly handle the ROAM flag explicitly, too?

Regards, Linus
  

On Wed, Jul 05, 2017 at 07:59:40AM +0200, Linus Lüssing wrote:
> If so, what would you prefer, should I replace the
> "common->flags |= flags" with something like a
> "common->flags |= flags & (~BATADV_TT_SYNC_MASK)"? Or would you
> prefer setting the TEMP flag somewhere else explicitly, similarly
> like we seemingly handle the ROAM flag explicitly, too?

Went with the former approach to keep the change less invasive.

Regards, Linus