Simon Wunderlich sw@simonwunderlich.de schrieb am 12.02.2016 14:04:23:
Von: Simon Wunderlich sw@simonwunderlich.de An: Andreas Pape APape@phoenixcontact.com Kopie: The list for a Better Approach To Mobile Ad-hoc Networking b.a.t.m.a.n@lists.open-mesh.org Datum: 12.02.2016 14:04 Betreff: Re: Antwort: Re: Re: [B.A.T.M.A.N.] Antwort: Re: Looping unicast packets when using BLA
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 ...
I would like to prevent duplicated packets as much as possible, even if they are unicast packets normally harmlexs for typical PC hardware. But I know of enough small embedded devices (sensors and stuff like that) which don't like that.....
- 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. :)
I've just sent the patches. They have the state of my "experiments" last year. That means that your latest proposal is not integrated yet. I quickly updated my devices in my test setup and it looks good (no looping arp requests or multiple replies seen so far).
Regards, Andreas
.................................................................. PHOENIX CONTACT ELECTRONICS GmbH
Sitz der Gesellschaft / registered office of the company: 31812 Bad Pyrmont USt-Id-Nr.: DE811742156 Amtsgericht Hannover HRB 100528 / district court Hannover HRB 100528 Geschäftsführer / Executive Board: Roland Bent, Dr. Martin Heubeck ___________________________________________________________________ Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren, jegliche anderweitige Verwendung sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. ---------------------------------------------------------------------------------------------------- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___________________________________________________________________