Re: [B.A.T.M.A.N.] [PATCH maint] batman-adv: Fix TT sync flags for intermediate TT responses

[me <me@irrelefant.net>]

I recently did a little experimentation on finding the "bad" (gluon)
nodes from a perspective of the vpn gateways with help of the tool
tshark. To document those procedure a little, I'll write it down in this
mail.

Starting point: we have a trace of the mesh-vpn interface from gateway
with the MAC 88:e6:40:20:50:01 which is named foo.pcap. (~10 sec)

As gluon nodes do not use the "isolation" flag of the translation
tables, the isolation flag is a good indicator to find affected packets.
Because the flag is only obviously only inside the TT response packets,
we need to filter for those. "(batadv.tvlv.tt.flags.type == 0x4) &&
(batadv.tvlv.tt.change.flags.isolate == 1)"

The next issue, when we use only the filters above is, that we see
forwarded responses twice, so we add a filter to only see the incomming
responses. To which node the response is forwarded is not really
important as those nodes are not the affected ones. So we add the filter
"(eth.dst == 88:e6:40:20:50:01)" to filter the packets directly
designated for us.

Now we can get the nexthop from which we are receiving the bad packets
by observing "eth.src". To sum it up, the following command is useful
for us:

tshark -r foo.pcap  -Y "(batadv.tvlv.tt.flags.type == 0x4) \
  && (batadv.tvlv.tt.change.flags.isolate == 1) \
  && (eth.dst == 88:e6:40:20:50:01)" \
  -e "eth.src" -Tfields | sort | uniq -c | sort -n

In my case, the output looks like this:

      2 2e:3a:10:c2:4e:5f
      2 88:e6:40:20:20:01
      5 88:e6:40:20:40:01
      9 ba:50:eb:56:50:97
     11 12:b7:57:22:e7:9f
     68 88:e6:40:20:70:01
    129 9e:b9:ba:ee:7e:9f
    194 96:c5:90:5a:1e:6f
    216 6e:34:7f:a4:90:a7
    338 88:e6:40:20:60:01

So we received 974 bad packets in the capture time. The MACs
88:e6:40:XX:XX:XX are the MACs of the other gateways, so we do not
consider them for now, as our aim is to find the bad freifunk routers
connected to this gateway.

Lets focus for now on the node 96:c5:90:5a:1e:6f. We now want to figure
out, which node is the originating node of the TT responses. So the
first idea would be to use the "batadv.unicast_tvlv.src" field of the
packages from 96:c5:90:5a:1e:6f. But this is not the originating node of
the response as intermediate nodes (which maybe answer the query) will
send the responses on behalf of the node for which they are answering.
So from "batadv.unicast_tvlv.src" we only receive the information, which
node was the target of the corresponding request and not which node
answered. But this information is valuable also as the bad node has to
be in the path between our nextnode (96:c5:90:5a:1e:6f) and the query
target. We may use this command:

tshark -r foo.pcap  -Y "(batadv.tvlv.tt.flags.type == 0x4) \
  && (batadv.tvlv.tt.change.flags.isolate == 1) \
  && (eth.dst == 88:e6:40:20:50:01) \
  && (eth.src == 96:c5:90:5a:1e:6f)" \
  -e "batadv.unicast_tvlv.src" -Tfields | sort | uniq -c | sort -n

In my dump the result of the command is:

      1 7a:25:0e:c4:c1:93
      2 02:a8:70:84:9d:fb
    191 4a:87:fc:b6:1d:fb

The interpretation of the result is, that there are 3 nodes which for
which we receive bad packets from the nextnode. So the bad node has to
somewhere between 96:c5:90:5a:1e:6f and one of the three nodes.

Kind regards,
Leonardo Mörlein