On 18/03/15 11:45, Andreas Pape wrote:
> In the meantime I digged a little deeper into this. DAT as such works but 
> has some side effects on the backbone network in a setup like mine with 
> several mesh nodes connected to the same backbone network and bla enabled. 
> I see two main issues:
> 
> 1. The original broadcast ARP request sent by the PC is looping back into 
> the backbone network. As far as I have figured out this comes from the 
> encapsulation of the original ARP broadcast into a BATADV_UNICAST_4ADDR 
> frame, which is not handled by the bla code responsible for preventing 
> looping broadcasts as for bla this is a unicast frame.

Good point.

> 2. All ARP replies are forwarded into the backbone by all possible 
> gateways. If a gateway gets responses of up to 3 remote dat candidates, 
> the total number of seen arp replies becomes 3 times the number of 
> gateways used.
> 

This is probably a consequence of point 1, right ?

> I am not sure, if this is specific to the old kernel version I used, but I 
> tried to overcome the two mentioned points with the following measures:
> 1. drop BATADV_UNICAST_4ADDR DHT_GET frames received from another gateway 
> as long as we cannot answer the forwarded arp request.
> 2. make sure, that only a gateway which has claimed the src mac of an arp 
> reply forwards this reply to the backbone network
> 3. drop received arp replies as soon as we have a local dat entry for the 
> src mac of the arp reply. In this case it is most likely that the device 
> has already sent a reply.
> 
> With these measures I see a "clean" arp request / reply behaviour in the 
> backbone network. As a further improvement I added the snooping of all 
> incoming IP traffic on the mesh soft interface. I use the src mac and src 
> IP to update the local dat cache. I wanted to achieve as low arp 
> request/reply and connected broadcast traffic in the mesh as possible.
> 
> If there is interest I could send a patch file to the mailing list with 
> the changes based on the batman-adv git master. But I warn you in front: I 
> am not a very skilled kernel programmer nor do I have any experience in 
> using git ;-) 

I am not I understand 100% your proposed solution, but a patch is worth
thousand words :)
Please do send it..and don't worry about your skill, everybody has to start!

Regards,

-- 
Antonio Quartulli