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 ...
- 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