Hi Antonio,
+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv,
u8 *addr, unsigned short vid)
+{
- struct batadv_bla_claim search_claim;
- struct batadv_bla_claim *claim = NULL;
- struct batadv_hard_iface *primary_if = NULL;
- bool ret = true;
- if (!atomic_read(&bat_priv->bridge_loop_avoidance))
return ret;
- primary_if = batadv_primary_if_get_selected(bat_priv);
- if (!primary_if)
goto out;
do you really need this goto here ? I think you can just return ret.
This way you can avoid the blind initialization of claim and primary_if and you can also remove the 'out' label at all.
I tried to "copy" the coding style of other functions. But in this case you are right that this is senseless here.
- /* First look if the mac address is claimed */
- ether_addr_copy(search_claim.addr, addr);
- search_claim.vid = vid;
- claim = batadv_claim_hash_find(bat_priv, &search_claim);
- /* If there is a claim and we are not owner of the claim,
- return false;
no need for the ';' here :)
- */
- if (claim) {
if (!batadv_compare_eth(claim->backbone_gw->orig,
primary_if->net_dev->dev_addr))
ret = false;
- } else {
/* If there is no claim, claim the device */
batadv_dbg(BATADV_DBG_BLA, bat_priv,
"Handle claim locally for currently not claimed mac
%pM.\n",
search_claim.addr);
batadv_handle_claim(bat_priv, primary_if,
primary_if->net_dev->dev_addr, addr, vid);
- }
...
@@ -1000,6 +1001,20 @@ bool batadv_dat_snoop_outgoing_arp_request
(struct batadv_priv *bat_priv,
goto out; }
/* If BLA is enabled, only send ARP replies if we have claimed
* the destination for the ARP request or if no one else of
* the backbone gws belonging to our backbone has claimed the
* destination.
*/
if (!batadv_bla_handle_local_claim(bat_priv,
dat_entry->mac_addr, vid)) {
I like the approach you take to fix this issue, however I don't
understand why
you want to "manually" claim a client.
This was meant to be something like a safety measure. DAT and BLA tables are not synchronized and can timeout separately, right? What, if a client address is still available in DAT but the client is not claimed anymore. In this case I think that claiming the client might be a good idea. I misused DAT here to make sure that the claim table is up to date. In my test setup running DAT and BLA on a number of backbone gateways I still have problems with looping packets (although having all of my patches applied). The problems have become significantly less often but from time to time there are still some occurring. In all of these cases clients from the mesh have been unclaimed somehow or they have been considered as having roamed to the backbone (for an unknown reason the workaround in patch 7/7 did not work in that case).
If I recall correctly, a backbone node will try to claim a client only if the latter tries to use such node to
enter
the LAN. In this situation the client may never use this backbone to enter the LAN (i.e. bad metric towards this node) and therefore we are forcing a claim that is
not
correct.
Simon, what do you think ?
Imho it is ok to *not* reply to the ARP request is the client is not
claimed,
but I don't understand why claiming it now.
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.
Are you sure this footer does not conflict with the GPL ? Not sure how important this is, but I'd rather not send it along with patches. However, if you use git-send-email this footer should not appear at all.
That's a good point. Indeed, I used git send-email. The footer is automatically applied by our e-mail server if e-mails leave our company network. Therefore my current problem is that I cannot prevent it. But it says "may contain" and "if you are not the intended recipient". In this case it's clear that it does not contain any confidential or proprietary information by the gpl nature of your project and you (i.e. the mailing list) are the intended recipient.
Thanks for the feedback and kind 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. ___________________________________________________________________