Re: [B.A.T.M.A.N.] Still looping packets in bla setup

[Simon Wunderlich <sw@simonwunderlich.de>]

[-- Attachment #1: Type: text/plain, Size: 5363 bytes --]

Hi Andreas,

On Friday 19 February 2016 11:58:47 Andreas Pape wrote:
> Hello Simon,
> 
> I'm still working with my IT department to be able to send the patches in
> a way compliant to the documentation provided by Sven. In the meantime I
> reworked the patches, but I am still struggling with the e-mail client
> issue.
> Nevertheless if I apply all the patches I sent earlier (except Patch 4/4
> as it was meaningless) I still have 3 problems :
> 1. I have sometimes looping unicast packets in the direction backbone ->
> mesh -> backbone. Dropping all unicast traffic received from another
> backbone gw and destined to be forwarded to the backbone again as you
> suggested this in an earlier mail solves this issue. Shall I provide an
> according patch?

I think that is a good idea.

> Shall I add a "Suggested-by" referring to you?

If you want, you can add a "Reported-by", although I don't need any credit 
here. I don't know if there is something like Suggested-by in Linux.

> I feel a
> little bit uncomforable with this patch as it seems to be something more
> like a workaround.

Well, we also drop the broadcast traffic when it comes from another backbone. So 
I don't think this is a workaround. BLA consists of a lot of rules after all 
...

> The question I cannot answer yet is why the other
> backbone gws send traffic via the mesh which could be sent via the
> backbone?

That is a good quesiton indeed. I think this can only be answered if you 
inspect the unicast packet and its source and destination as well as 
translation table state and bridge port state (brctl showmacs). This might 
give a clue what is going on ... If its not a DAT packet, that is.

> 2. Although having the patch for 1. applied, the backbone gateways send
> claim frames for the devices of their own backbone in rare cases from time
> to time. I could send a patch for this as it is rather easy to check with
> the help of the local tt table (batadv_is_my_client) if it is reasonable
> to send a claim frame for these devices. Again, this patch looks more like
> a workaround to me as I also cannot explain what really triggers the
> generation of these claim frames.

I don't think this is the right way to solve it - if a client has roamed to 
another device in the mesh, a gateway MUST send a claim. However 
batadv_is_my_client would probably return true, suggesting that the client is 
local although it is not local anymore.

The problem probably needs to be fixed somewhere else.

> 3. I see again in rare cases looping multicasts for traffic
> mesh->backbone->mesh. If I look at the bla debug messages in these cases I
> see, that a backbone gw holding the claim for the source of the multicast
> frame thinks that the client belonging to the source address has "roamed"
> from another mesh node into the backbone network although it didn't. From
> this I conclude that another backbone gw has forwarded the multicast into
> the backbone although it shoudn't have done this (having found no claim
> for the client or erroneously also holding a claim). In this case the
> backbone gateways seem to be out-of-sync about the actual claim status for
> that client. This effect only lasts a very short time, as the gateway
> which found the "roaming" client unclaims it and within a few milliseconds
> (depending on the traffic generated by the client) another backbone gw (or
> the same) claims the client again. Of course then the looping of the
> multicast traffic from the client stops. In my case the sender of the
> multicast was the bridge interface br0 of a remote mesh node itself. The
> bat0 softinterface was added to that bridge. The looping multicast then
> gave me a "bat0: received packet with own address as source address"
> message. Furthermore that bat0 interface sent a claim frame for the mac of
> the own bridge (whch is obvious as bat0 received a message from the mesh
> with a mac address not claimed yet....). This claim frame then produces
> another "bat0: received packet ..." message.
> I currently have no workaround for this 3rd issue as all I can image to
> prevent this will break the "roaming client" scenario for bla. I could
> even live with this problem as it happens quite seldomly and as it is
> "self-healing", but it tells my that there might be a sync issue. Do you
> think that my 1st and 2nd point could also relate to the same problem?
> In the meantime I looked through the code for hours but I am not able to
> find something that could explain the observed problem.

Hmm ... that sounds strange. I don't know if this is related to the your first 
two points since we are talking about multicast here and the other points were 
about unicast.

I think the main question here is - if the packet came from the mesh, why 
wasn't there a claim frame? 

Maybe two questions could help: 
 * does this happen in the first minutes after starting/restarting the mesh? 
There is some initial time for bla gateway nodes to detect each other, 
although this should happen quite fast.
 * Do you have some unusual high amount of broadcast/multicast (e.g. 
streaming, fieldbus protocol, etc)?

What might help is to get dumps from the hard interface as well as the bat0 
soft interface and check the corresponding packets when this problem happens. 
Not sure if this helps and how easy it is to capture dumps ...

Cheers,
     Simon

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]