Re: [B.A.T.M.A.N.] Antwort: Re: Re: Antwort: Re: Looping unicast packets when using BLA

[Simon Wunderlich <sw@simonwunderlich.de>]

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

Hi Andreas,

On Friday 12 February 2016 11:40:21 Andreas Pape wrote:
> > > [...]
> > > using dat in combination with bla:
> > > 1.Broadcast ARP requests from the backbone network are handled by each
> > > gateway, leading to multiple dat adress resoultions in parallel.
> > 
> > That shouldn't be a problem on its own.
> 
> I think I wasn't precise enough concerning this point. I meant the effect,
> that
> a broadcast ARP coming from a common backbone reaches all gateways. If now
> accidentally
> several gateways can already answer that request due to dat, then the
> current code sends
> an arp reply from each gateway being able to answer. This broadcast does
> not even reach
> the mesh if all gateways can answer the request (as far as I have
> understood the code).
> Therefore broadcast handling in the mesh layer does not solve this
> problem.

Yes, we may have multiple gateways answering with an ARP reply. But how is 
this a problem? It is redundant, yes, but its just a unicast sent back. I 
don't see this a s problem yet ...

> 
> > > 2. As dat uses tunneling of broadcasts in special batman-adv unicast
> > > frames, the current bla code does not seem to prevent these broadcasts
> > > from reaching the backone network as it is done for normal broadcast
> > > coming from the mesh and heading for the backbone.
> > > Both effects together lead to a multiplication of arp requests and
> > > replies. My patch of last year tried to address this.
> > 
> > Hm, I see. I just checked the code and it seems we fixed this issue
> > for speedy
> > join in the mean time (affecting TT), but for bla the problem is still
> > present.
> > 
> > Wouldn't it be sufficient to add something like a check for backbones (
> > batadv_bla_is_backbone_gw) into batadv_recv_unicast_packet() and drop
> 
> packets
> 
> > if they came from the same backbone?
> 
> That's a good question. This is something I did not dare to do last year
> because
> I cannot foresee possible negative implications. Perhaps someone more
> experienced with
> batman-adv routing should answer this. Therefore I focussed on fixing this
> for the DAT ARP handling only.
> But doing so as you propose would most likely have the positive side
> effect that I will get rid
> of the looping unicast packets in my backbone network, too. But as
> mentioned in my prior mail
> I think this looping unicast packets might have another cause. The
> question is: why does
> a gateway forward a unicast packet received via the mesh with a
> destination mac behind
> an originator somewhere else in the mesh (that originator is not connected
> to the same backbone) to
> its own backbone? If this only can happen if the entry in the global tt
> expires (like a mac adress
> table expires in a switch and the switch starts broadcasting incoming
> packets to all ports), then
> I would think blocking all unicast traffic coming from another backbone gw
> of the same backbone network
> is the smartest and easiest solution.

Yeah, agreed. There shouldn't be any unicast messages to be sent among 
gateways through the mesh. We probably should not only avoid the receiving (as 
I suggested only), but also sending DAT requests to other gateways on the same 
backbone. The check should be similar and simple ... After all, if there is 
another gateway capable of answering, it will also receive the request and 
doesn't need it passed from somebody else on the same backbone.

Regarding the TT question/expiration, as a receiver we don't check the 
destination address and just accept the packet for receiption. But as I said, 
packets among gateways on the same backbone shouldn't be sent or received.

> 
> > I have found your patch from last year. Would you like to rebase/split
> 
> your
> 
> > patch to address the remaining issues? That would help us a lot. Please
> 
> also
> 
> > put a proper patch message. I promise to be more responsive this time.
> :
> :)
> 
> I'm trying to split my last year's patch into logical seperate pieces,
> update them
> to be compliant to the latest master branch of the batman-adv.git
> repositor and will
> mail them for further discussion.

Cool, thanks! I'm looking forward to it. :)

Cheers,
     Simon

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