Antwort: Re: [B.A.T.M.A.N.] Antwort: Re: [PATCH] batman-adv: handle race condition for claims also in batadv_bla_rx

2019-07-02 Thread Andreas Pape
Hi Sven,

sorry for my late reply, but I finally found some time for testing. I used 
batman-adv version 2017.2
without this patch and I do not see any negative effects on the way bla 
works in my testsetup.
Therefore this patch doesn't seem to make sense anymore.

Sven Eckelmann  schrieb am 09.06.2019 13:28:24:

> Von: Sven Eckelmann 
> An: b.a.t.m.a.n@lists.open-mesh.org
> Kopie: andreas pape , simon wunderlich 
> 
> Datum: 09.06.2019 13:28
> Betreff: Re: [B.A.T.M.A.N.] Antwort: Re: [PATCH] batman-adv: handle 
> race condition for claims also in batadv_bla_rx
> 
> On Wednesday, 10 May 2017 07:45:50 CEST Andreas Pape wrote:
> [...]
> > I have to admit that I did not retest this with the current master or
> > version 2017.0.1. I simply
> > integrated the patch and I can at least confirm that bla works as 
reliable
> > as in the 2014.4 case with
> > this patch. I agree that this is no proof that this patch is still 
really
> > needed. I think I'll remove it
> > from my test setup and come back with my results.
> 
> What is the state of the tests?
> 
> Kind regards,
>Sven[Anhang "signature.asc" gelöscht von Andreas Pape/Pyr/DE/
> Phoenix Contact] 

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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] batman-adv: is it possible to increase mtu size for batman-adv interfaces?

2017-06-19 Thread Andreas Pape
Hi,

currently the mtu size of batman-adv soft-interfaces is limited to
ETH_DATA_LEN (1500 bytes) in function batadv_hardif_min_mtu as far as I
understand.

A comment in this function states that batman-adv "does not support MTUs
bigger than ETH_DATA_LEN". Is there a specific reason for this or would it
be possible to increase the MTU size to something like 1518 by simply
replacing all limitations to ETH_DATA_LEN with a higher value?

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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] Antwort: Re: [PATCH] batman-adv: prevent adding of loop detection mac addresses to global tt

2017-06-01 Thread Andreas Pape
Hi Simon,

>
> I was thinking, if we implement it like this we may still have problems
if an
> older batman-adv version is adding the ba:be mac addresses locally.
> This could
> create a problem, because the transmitted tt table is not added
completely,
> thus the CRC will not match and will lead to a "TT request/response
loop".
>
> What do you think? Maybe we should only add it for the speedy join case,
but
> accept it if a node really added these mac addresses locally?

I'm afraid I haven't understood the speedy join mechanism / use case good
enough
to make a good proposal here, but I'm volunteering for testing if someone
else
has a better solution then my rough approach ;-)

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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] [PATCH] batman-adv: prevent adding of loop detection mac addresses to global tt

2017-06-01 Thread Andreas Pape
This patch prevents that entries in the global translation table are generated
for mac addresses used by loop detection frames.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/translation-table.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/batman-adv/translation-table.c 
b/net/batman-adv/translation-table.c
index e75b493..ca1e0f7 100644
--- a/net/batman-adv/translation-table.c
+++ b/net/batman-adv/translation-table.c
@@ -1618,8 +1618,10 @@ static bool batadv_tt_global_add(struct batadv_priv 
*bat_priv,
struct batadv_tt_common_entry *common;
u16 local_flags;

-   /* ignore global entries from backbone nodes */
-   if (batadv_bla_is_backbone_gw_orig(bat_priv, orig_node->orig, vid))
+   /* ignore global entries from backbone nodes or
+* adding of entries related to loop detect frames */
+   if (batadv_bla_is_backbone_gw_orig(bat_priv, orig_node->orig, vid) ||
+   batadv_bla_is_loopdetect_mac(tt_addr))
return true;

tt_global_entry = batadv_tt_global_hash_find(bat_priv, tt_addr, vid);
--
1.7.0.4



..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] Antwort: Re: MAC addresses of loop detect frames in global translation-table

2017-06-01 Thread Andreas Pape
> Von: Linus Lüssing 
> An: The list for a Better Approach To Mobile Ad-hoc Networking
> 
> Datum: 31.05.2017 16:20
> Betreff: Re: [B.A.T.M.A.N.] MAC addresses of loop detect frames in
> global translation-table
> Gesendet von: "B.A.T.M.A.N" 
>
> On Wed, May 31, 2017 at 03:39:23PM +0200, Simon Wunderlich wrote:
> > Hi Andreas,
> >
> > yes, those are loop detection packets. Preventing these entries
> from the local
> > translation table has been implemented only recently. We can
potentially do
> > the same for global addresses as well, it just hasn't been done so
> far ... at
> > least I don't see a reason prevening us from that. It is probably
added by
> > "speedy join" in the first place.
>
> This was the case at least for me. Andreas, do yours have the
> temporary flag set, too?
>
If I remember it correctly they are shown as "regular" MAC addresses
without any
special flags set (like any real mac address of existing devices). In the
meantime
I kick these entries in batadv_tt_global_add. But if you are interested I
could
revert my firmware and give a more precise answer.

> I'm wondering why these packets end up in the mesh in the first
> place. (Preventing things as late as in tt_gobal_add() / on
> mesh receiving nodes seems like a workaround?)
>
> Regards, Linus

Best 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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] MAC addresses of loop detect frames in global translation-table

2017-05-31 Thread Andreas Pape
Hello,

I stumbled across some weired MAC addresses starting with ba:be in the
global translation-table when running batman-adv-2017.0.1. I run my setup
with bla enabled.

Most of the entries in the global tt of my devices consist of these mac
addresses. Looking through the code they come from frames which seem to be
used for loop detection. Adding such MAC addresses to the local tt is
prevented with the help of the batadv_bla_is_loopdetect_mac function. I
wonder why adding these macs to the global tt is not prevented in a
simliar way. Would it be possible to add a corresponding check to
batadv_tt_global_add to prevent these macs from being added to the global
tt? Or is there a specific reason why these mac addresses must occur in
the global tt and which I have not understood so far?

Best 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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] Memory leakage

2017-05-18 Thread Andreas Pape
Hi,

as far as I could figure out via bisect commit [1] causes a memory leakage
as the way how skbs are
consumed / freed has been changed since I first developed this patch. This
happens in a setup using
bla and when the mesh links between mesh nodes sharing a common backbone
become
very weak and unstable.

I think the line with the "return NET_RX_DROP;" needs to be replaced by
"goto skb_free;".
How is the correct procedure to change this? As this patch has already
been committed to
the git repo I guess I should send a new patch or is a new version of the
old patch necessary?

Best regards,
Andreas


[1]:
https://git.open-mesh.org/batman-adv.git/commitdiff/bfe2a1971f43ef540ef0440d319542fa7d41d81f



..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] Antwort: Re: [PATCH] batman-adv: handle race condition for claims also in batadv_bla_rx

2017-05-09 Thread Andreas Pape
Hi Simon,

> Von: Simon Wunderlich 
> An: Andreas Pape 
> Kopie: b.a.t.m.a.n@lists.open-mesh.org
> Datum: 09.05.2017 17:50
> Betreff: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: handle race
> condition for claims also in batadv_bla_rx
>
> On Friday, April 28, 2017 10:26:10 PM CEST Simon Wunderlich wrote:
> > From: Andreas Pape 
> >
> > Like in the case of the patch for batadv_bla_tx to handle a race
> > condition when claiming a mac address for bla, a similar situation
> > can occur when claiming is triggered via batadv_bla_rx. This patch
> > solves this with a similar approach as for batadv_bla_tx.
> >
> > Signed-off-by: Andreas Pape 
>
> Hi Andreas,
>
> thanks again for the patch - in general, I think this looks good,
although I
> don't follow completely where you saw that. Can you describe the
scenario a
> little more?
>
> We usually don't process packets from the mesh sent by nodes on the same
LAN
> segment - we look at the originator and check the BLA group using
> batadv_check_claim_group().
>
> There are two things which we could improve documentation-wise:
>
> 1.) Have some kernel doc  batadv_tt_local_has_timed_out - we want to
have
> kerneldoc for every new function we add.
>

Sorry, I will add that if this patch really turns out to be useful (see
2.).

> 2.) Describe the scenario in a comment in batadv_bla_rx(). I find the
comment
> not too convincing, see above.
>

As in my earlier patches I use a setup which needs bla. Up to recently I
experimented with
batman-adv-2014.4 and I struggled a lot with looping packets. At least for
version 2014.4
I found out that the patches I mailed last year where not sufficient to
prevent looping
packets between the mesh and the common Ethernet backbone completely under
all conditions. By enabling the debugging
I found that the looping packets always correlated with the claiming of
devices. I got rid of the
looping packets (error message from the kernel "received packet with own
mac address as source address")almost
completely after adding this additional patch. I now only get the kernel
error message about
receiving packets with own mac address sometimes when a mesh node is added
to the network for very few packets
which is ok for my application. But without this patch in 2014.4 I got
these messages randomly during notmal operation of the network.

I have to admit that I did not retest this with the current master or
version 2017.0.1. I simply
integrated the patch and I can at least confirm that bla works as reliable
as in the 2014.4 case with
this patch. I agree that this is no proof that this patch is still really
needed. I think I'll remove it
from my test setup and come back with my results.

Thanks for the feedback and best 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: Ulrich Leidecker, Christoph Leifer
__
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.
___


Re: [B.A.T.M.A.N.] batctl: Work around uclibc collision for __unused

2016-09-15 Thread Andreas Pape
On Sun,  4 Sep 2016 20:23:31 +0200
Sven Eckelmann  wrote:

> uclibc on 64 bit systems uses struct members called __unused. These
> conflict with the definition of __unused in batctl. Such a conflict
> results in a build error because the struct member will be replaced with
> the __attribute__((unused)).
>
> This can be avoided by renaming it to the Linux kernel name
> "__maybe_unused".
>
> Signed-off-by: Sven Eckelmann 

Tested-by: Andreas Pape 


..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] Antwort: Re: batctl: problem with #define __unused in main.h

2016-09-15 Thread Andreas Pape
Hi Sven,

this patch works for me. Sorry for not finding your patch in patchwork
myself.
Stupid question: how and where do I reply with Tested-by?

Best regards,
Andreas


Sven Eckelmann  schrieb am 15.09.2016 11:19:33:

> Von: Sven Eckelmann 
> An: b.a.t.m.a.n@lists.open-mesh.org
> Kopie: Andreas Pape 
> Datum: 15.09.2016 11:19
> Betreff: Re: [B.A.T.M.A.N.] batctl: problem with #define __unused in
main.h
>
> On Donnerstag, 15. September 2016 11:00:03 CEST Andreas Pape wrote:
> > Hello
> >
> > when trying to compile the latest batctl code from the git repository
I
> > run into a compiler error
> > (gcc 4.8.5 and eglibc-2.18) .
>
>
> Please test https://patchwork.open-mesh.org/patch/16673/ (and reply with
a
> Tested-by: Andreas Pape ) when it works.
>
> Kind regards,
>Sven[Anhang "signature.asc" gelöscht von Andreas Pape/Pyr/DE/
> Phoenix Contact]


..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] batctl: problem with #define __unused in main.h

2016-09-15 Thread Andreas Pape
Hello

when trying to compile the latest batctl code from the git repository I
run into a compiler error
(gcc 4.8.5 and eglibc-2.18) .

As far as I could figure out the problem is caused by the define of
__unused in main.h. In my case
I use the libnl-3.2.25 to compile the code. The libnl header files include
the netdb.h header file
which uses __unused as an element of a struct. The define in the main.h of
the batctl code leads to a
compiler error. Renaming the define in main.h to something like __unused_
and corresponding
changes in the batctl code using __unused solves the compile time issue.
But due to my lack
of knowledge I don't know if this breaks the code On my devices batctl
seems to work properly
after changing this, but before sending a patch, I would like to ask you
guys first ;-)


Best 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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] [PATCH] batctl: optchar variable uses wrong type

2016-09-15 Thread Andreas Pape
The variable "optchar" used char instead of int leading to a non
working batctl tp command as the while loop parsing the tp
arguments with the getopt command is only left via the "default"
case leaving the tp subcommand unusable. Using type char also
lead to a compiler warning.

Signed-off-by: Andreas Pape 
---
 tp_meter.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tp_meter.c b/tp_meter.c
index 7fe0d56..10dc2b9 100644
--- a/tp_meter.c
+++ b/tp_meter.c
@@ -395,7 +395,7 @@ int tp_meter(char *mesh_iface, int argc, char **argv)
int ret = EXIT_FAILURE;
int found_args = 1, read_opt = USE_BAT_HOSTS;
uint32_t time = 0;
-   char optchar;
+   int optchar;
struct nl_sock *listen_sock = NULL;
struct tp_result result = {
.error = 0,
--
1.7.0.4



..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] Antwort: [PATCH v7 0/5] batman-adv: prevent multiple ARP replies sent by gateways if dat enabled

2016-09-07 Thread Andreas Pape
Hello Sven,

thanks for updating the patchset. I am currently a little bit "cut off",
as the current batman-adv version does not compile anymore without a lot
of effort under the old kernel version I use. Therefore I started the work
of updating the kernel version on my devices. I think I will be able to
run the current batman version on my devices soon.

Am I expected to do anything else concerning the patchset? Sorry for my
lack of experience about how such an open source project works but as you
might have noticed this is the first time that I tried to contribute some
stuff.

Best regards,
Andreas


-"B.A.T.M.A.N"  schrieb: -
An: b.a.t.m.a.n@lists.open-mesh.org
Von: Sven Eckelmann
Gesendet von: "B.A.T.M.A.N"
Datum: 05.09.2016 13:24
Betreff: [B.A.T.M.A.N.] [PATCH v7 0/5] batman-adv: prevent multiple ARP replies 
sent by gateways if dat enabled

Hi,

this should actually should have ended in the cover letter:

The v7 version is just a rebased version of v6 [1] because Marek noticed that
these patches don't apply anymore.

Kind regards,
Sven

[1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-July/015858.html


[Anhang 'signature.asc' entfernt von Andreas Pape/Phoenix Contact]


..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] [PATCH v6 3/5] batman-adv: drop unicast packets from other backbone gw

2016-07-03 Thread Andreas Pape
Additional dropping of unicast packets received from another backbone gw of
the same backbone network before being forwarded to the same backbone again
is necessary. It was observed in a test setup that in rare cases these
frames lead to looping unicast traffic backbone->mesh->backbone.

Signed-off-by: Andreas Pape 
Acked-by: Simon Wunderlich 
---
 net/batman-adv/routing.c |   25 ++---
 1 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 2bc9645..1511abe 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -877,14 +877,16 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
struct batadv_priv *bat_priv = netdev_priv(recv_if->soft_iface);
struct batadv_unicast_packet *unicast_packet;
struct batadv_unicast_4addr_packet *unicast_4addr_packet;
-   u8 *orig_addr;
-   struct batadv_orig_node *orig_node = NULL;
+   u8 *orig_addr, *orig_addr_gw;
+   struct batadv_orig_node *orig_node = NULL, *orig_node_gw = NULL;
int check, hdr_size = sizeof(*unicast_packet);
enum batadv_subtype subtype;
-   bool is4addr;
+   bool is4addr, is_gw;
+   struct ethhdr *ethhdr;

unicast_packet = (struct batadv_unicast_packet *)skb->data;
unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data;
+   ethhdr = eth_hdr(skb);

is4addr = unicast_packet->packet_type == BATADV_UNICAST_4ADDR;
/* the caller function should have already pulled 2 bytes */
@@ -907,6 +909,23 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,

/* packet for me */
if (batadv_is_my_mac(bat_priv, unicast_packet->dest)) {
+   /* If this is a unicast packet from another backgone gw,
+* drop it.
+*/
+   orig_addr_gw = ethhdr->h_source;
+   orig_node_gw = batadv_orig_hash_find(bat_priv, orig_addr_gw);
+   if (orig_node_gw) {
+   is_gw = batadv_bla_is_backbone_gw(skb, orig_node_gw,
+ hdr_size);
+   batadv_orig_node_put(orig_node_gw);
+   if (is_gw) {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "Dropped unicast pkt received from 
another backbone gw %pM.\n",
+  orig_addr_gw);
+   return NET_RX_DROP;
+   }
+   }
+
if (is4addr) {
subtype = unicast_4addr_packet->subtype;
batadv_dat_inc_counter(bat_priv, subtype);
--
1.7.0.4



..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] [PATCH v6 2/5] batman-adv: prevent duplication of ARP replies when DAT is used

2016-07-03 Thread Andreas Pape
If none of the backbone gateways in a bla setup has already knowledge of
the mac address searched for in an incoming ARP request from the backbone
an address resolution via the DHT of DAT is started. The gateway can send
several ARP requests to different DHT nodes and therefore can get several
replies. This patch assures that not all of the possible ARP replies are
returned to the backbone by checking the local DAT cache of the gateway.
If there is an entry in the local cache the gateway has already learned
the requested address and there is no need to forward the additional reply
to the backbone.
Furthermore it is checked if this gateway has claimed the source of the ARP
reply and only forwards it to the backbone if it has claimed the source or
if there is no claim at all.

Signed-off-by: Andreas Pape 
Acked-by: Simon Wunderlich 
---
 net/batman-adv/distributed-arp-table.c |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index c0346c8..6c2e774 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -1191,6 +1191,7 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
__be32 ip_src, ip_dst;
u8 *hw_src, *hw_dst;
bool dropped = false;
+   struct batadv_dat_entry *dat_entry = NULL;
unsigned short vid;

if (!atomic_read(&bat_priv->distributed_arp_table))
@@ -1210,12 +1211,41 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
hw_dst = batadv_arp_hw_dst(skb, hdr_size);
ip_dst = batadv_arp_ip_dst(skb, hdr_size);

+   /* If ip_dst is already in cache and has the right mac address,
+* drop this frame if this ARP reply is destined for us because it's
+* most probably an ARP reply generated by another node of the DHT.
+* We have most probably received already a reply earlier. Delivering
+* this frame would lead to doubled receive of an ARP reply.
+*/
+   dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_src, vid);
+   if (dat_entry && batadv_compare_eth(hw_src, dat_entry->mac_addr)) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled ARP reply 
removed: ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4]; dat_entry: %pM-%pI4\n",
+  hw_src, &ip_src, hw_dst, &ip_dst,
+  dat_entry->mac_addr, &dat_entry->ip);
+   dropped = true;
+   goto out;
+   }
+
/* Update our internal cache with both the IP addresses the node got
 * within the ARP reply
 */
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);
batadv_dat_entry_add(bat_priv, ip_dst, hw_dst, vid);

+   /* If BLA is enabled, only forward ARP replies if we have claimed the
+* source of the ARP reply or if no one else of the same backbone has
+* already claimed that client. This prevents that different gateways
+* to the same backbone all forward the ARP reply leading to multiple
+* replies in the backbone.
+*/
+   if (!batadv_bla_check_claim(bat_priv, hw_src, vid)) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Device %pM claimed by another backbone gw. Drop ARP 
reply.\n",
+  hw_src);
+   dropped = true;
+   goto out;
+   }
+
/* if this REPLY is directed to a client of mine, let's deliver the
 * packet to the interface
 */
@@ -1228,6 +1258,8 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
 out:
if (dropped)
kfree_skb(skb);
+   if (dat_entry)
+   batadv_dat_entry_put(dat_entry);
/* if dropped == false -> deliver to the interface */
return dropped;
 }
--
1.7.0.4



..
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: Ulrich Leidecker, Christoph Leifer
__
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

[B.A.T.M.A.N.] [PATCH v6 4/5] batman-adv: changed debug messages for easier bla debugging

2016-07-03 Thread Andreas Pape
Some of the bla debug messages are extended and additional messages are
added for easier bla debugging. Some debug messages introduced with the
dat changes in prior patches of this patch series have been changed to
be more compliant to other existing debug messages.

Acked-by: Simon Wunderlich 
Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   18 ++
 net/batman-adv/routing.c   |2 +-
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 825f40d..7ec11ac 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -716,8 +716,8 @@ static void batadv_bla_add_claim(struct batadv_priv 
*bat_priv,
goto claim_free_ref;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_add_claim(): changing ownership for %pM, vid 
%d\n",
-  mac, BATADV_PRINT_VID(vid));
+  "bla_add_claim(): changing ownership for %pM, vid %d 
to gw %pM\n",
+  mac, BATADV_PRINT_VID(vid), backbone_gw->orig);

spin_lock_bh(&claim->backbone_gw->crc_lock);
claim->backbone_gw->crc ^= crc16(0, claim->addr, ETH_ALEN);
@@ -1241,10 +1241,13 @@ static void batadv_bla_purge_claims(struct batadv_priv 
*bat_priv,
continue;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_purge_claims(): %pM, vid %d, time 
out\n",
+  "bla_purge_claims(): timed out.\n");
+
+purge_now:
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_purge_claims(): %pM, vid %d\n",
   claim->addr, claim->vid);

-purge_now:
batadv_handle_unclaim(bat_priv, primary_if,
  claim->backbone_gw->orig,
  claim->addr, claim->vid);
@@ -1788,6 +1791,13 @@ bool batadv_bla_rx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* possible optimization: race for a claim */
/* No claim exists yet, claim it for us!
 */
+
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_rx(): Unclaimed MAC %pM found. Claim it. Local: 
%s\n",
+  ethhdr->h_source,
+  batadv_is_my_client(bat_priv,
+  ethhdr->h_source, vid) ?
+  "yes" : "no");
batadv_handle_claim(bat_priv, primary_if,
primary_if->net_dev->dev_addr,
ethhdr->h_source, vid);
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 1511abe..79fae64 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -920,7 +920,7 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
batadv_orig_node_put(orig_node_gw);
if (is_gw) {
batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "Dropped unicast pkt received from 
another backbone gw %pM.\n",
+  "recv_unicast_packet(): Dropped 
unicast pkt received from another backbone gw %pM.\n",
   orig_addr_gw);
return NET_RX_DROP;
}
--
1.7.0.4



..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] [PATCH v6 5/5] batman-adv: handle race condition for claims between gateways

2016-07-03 Thread Andreas Pape
Consider the following situation which has been found in a test setup:
Gateway B has claimed client C and gateway A has the same backbone
network as B. C sends a broad- or multicast to B and directly after
this packet decides to send another packet to A due to a better TQ
value. B will forward the broad-/multicast into the backbone as it is
the responsible gw and after that A will claim C as it has been
chosen by C as the best gateway. If it now happens that A claims C
before it has received the broad-/multicast forwarded by B (due to
backbone topology or due to some delay in B when forwarding the
packet) we get a critical situation: in the current code A will
immediately unclaim C when receiving the multicast due to the
roaming client scenario although the position of C has not changed
in the mesh. If this happens the multi-/broadcast forwarded by B
will be sent back into the mesh by A and we have looping packets
until one of the gateways claims C again.
In order to prevent this, unclaiming of a client due to the roaming
client scenario is only done after a certain time is expired after
the last claim of the client. 100 ms are used here, which should be
slow enough for big backbones and slow gateways but fast enough not
to break the roaming client use case.

Acked-by: Simon Wunderlich 
Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 7ec11ac..07fc153 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1905,10 +1905,22 @@ bool batadv_bla_tx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* if yes, the client has roamed and we have
 * to unclaim it.
 */
-   batadv_handle_unclaim(bat_priv, primary_if,
- primary_if->net_dev->dev_addr,
- ethhdr->h_source, vid);
-   goto allow;
+   if (batadv_has_timed_out(claim->lasttime, 100)) {
+   /* only unclaim if the last claim entry is
+* older than 100 ms to make sure we really
+* have a roaming client here.
+*/
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming 
client %pM detected. Unclaim it.\n",
+  ethhdr->h_source);
+   batadv_handle_unclaim(bat_priv, primary_if,
+ primary_if->net_dev->dev_addr,
+ ethhdr->h_source, vid);
+   goto allow;
+   } else {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race 
for claim %pM detected. Drop packet.\n",
+  ethhdr->h_source);
+   goto handled;
+   }
}

/* check if it is a multicast/broadcast frame */
--
1.7.0.4



..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] [PATCH v6 0/5] Optimizations for setups running dat and bla

2016-07-03 Thread Andreas Pape
This patchset introduces optimizations for batman-adv in setups having several
gateways into a common (switched) Ethernet backbone network especially if dat
is additionally enabled.

Using the current implementation with bla and dat enabled, several problems
can be observed in a real setup:
1. Multiplication of ARP replies from dat enabled gateways and dat enabled
mesh nodes leading to an "ARP reply storm" in the common backbone network.
2. In rare corner cases bla does not fully prevent looping of unicast frames
in the direction Backbone --> mesh --> backbone and looping of multicast
frames in the direction mesh --> backbone --> mesh.
The latter can lead to temporary confusion in the switched backbone resulting
in packet loss and communication timeouts.

The observed problems are solved by introduction of additional rules for the
dat handling, bla packet forwarding and bla claiming/unclaiming of clients.

v6:
 - rebased the patchset
 - removed snooping of all ip traffic

v5:
 - changed function name to batadv_bla_check_claim
 - put added include file in alphabetical order
 - added check to exclude ip address 0.0.0.0 from snooping

v4:
 - removed unnecessary include in soft-interface.c
 - solved issue with double-use and refcounting of pointers in routing.c

v3:

 - rebased patchset
 - moved snooping of ip addresses for dat speed up into separate function
 - removed "patch of a patch"
 - removed automatic claiming during check of a claim
 - fixed issues of the patchset not being compiled due to chosen batman
options

Kind regards,
Andreas

Andreas Pape (5):
  batman-adv: prevent multiple ARP replies sent by gateways if dat
enabled
  batman-adv: prevent duplication of ARP replies when DAT is used
  batman-adv: drop unicast packets from other backbone gw
  batman-adv: changed debug messages for easier bla debugging
  batman-adv: handle race condition for claims between gateways

 net/batman-adv/bridge_loop_avoidance.c |   87 +---
 net/batman-adv/bridge_loop_avoidance.h |   11 
 net/batman-adv/distributed-arp-table.c |   47 +
 net/batman-adv/routing.c   |   25 -
 4 files changed, 159 insertions(+), 11 deletions(-)



..
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: Ulrich Leidecker, Christoph Leifer
__
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.
___


[B.A.T.M.A.N.] [PATCH v6 1/5] batman-adv: prevent multiple ARP replies sent by gateways if dat enabled

2016-07-03 Thread Andreas Pape
If dat is enabled it must be made sure that only the backbone gw which has
claimed the remote destination for the ARP request answers the ARP request
directly if the MAC address is known due to the local dat table. This
prevents multiple ARP replies in a common backbone if more than one
gateway already knows the remote mac searched for in the ARP request.

Signed-off-by: Andreas Pape 
Acked-by: Simon Wunderlich 
---
 net/batman-adv/bridge_loop_avoidance.c |   49 
 net/batman-adv/bridge_loop_avoidance.h |   11 +++
 net/batman-adv/distributed-arp-table.c |   15 ++
 3 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index e4f7494..825f40d 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -2046,3 +2046,52 @@ out:
batadv_hardif_put(primary_if);
return 0;
 }
+
+#ifdef CONFIG_BATMAN_ADV_DAT
+/**
+ * batadv_bla_check_claim - check if address is claimed
+ *
+ * @bat_priv: the bat priv with all the soft interface information
+ * @addr: mac address of which the claim status is checked
+ * @vid: the VLAN ID
+ *
+ * addr is checked if this address is claimed by the local device itself.
+ *
+ * Return: true if bla is disabled or the mac is claimed by the device,
+ * false if the device addr is already claimed by another gateway
+ */
+bool batadv_bla_check_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)
+   return ret;
+
+   /* 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.
+*/
+   if (claim) {
+   if (!batadv_compare_eth(claim->backbone_gw->orig,
+   primary_if->net_dev->dev_addr))
+   ret = false;
+   batadv_claim_put(claim);
+   }
+
+   batadv_hardif_put(primary_if);
+   return ret;
+}
+#endif
diff --git a/net/batman-adv/bridge_loop_avoidance.h 
b/net/batman-adv/bridge_loop_avoidance.h
index 0f01dae..9dddebc 100644
--- a/net/batman-adv/bridge_loop_avoidance.h
+++ b/net/batman-adv/bridge_loop_avoidance.h
@@ -47,6 +47,10 @@ void batadv_bla_update_orig_address(struct batadv_priv 
*bat_priv,
 void batadv_bla_status_update(struct net_device *net_dev);
 int batadv_bla_init(struct batadv_priv *bat_priv);
 void batadv_bla_free(struct batadv_priv *bat_priv);
+#ifdef CONFIG_BATMAN_ADV_DAT
+bool batadv_bla_check_claim(struct batadv_priv *bat_priv, u8 *addr,
+   unsigned short vid);
+#endif

 #define BATADV_BLA_CRC_INIT0
 #else /* ifdef CONFIG_BATMAN_ADV_BLA */
@@ -112,6 +116,13 @@ static inline void batadv_bla_free(struct batadv_priv 
*bat_priv)
 {
 }

+static inline
+bool batadv_bla_check_claim(struct batadv_priv *bat_priv, u8 *addr,
+   unsigned short vid)
+{
+   return true;
+}
+
 #endif /* ifdef CONFIG_BATMAN_ADV_BLA */

 #endif /* ifndef _NET_BATMAN_ADV_BLA_H_ */
diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index fa76465..c0346c8 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -43,6 +43,7 @@
 #include 
 #include 

+#include "bridge_loop_avoidance.h"
 #include "hard-interface.h"
 #include "hash.h"
 #include "log.h"
@@ -1005,6 +1006,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_check_claim(bat_priv,
+   dat_entry->mac_addr, vid)) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Device %pM claimed by another backbone gw. 
Don't send ARP reply!",
+  dat_entry->mac_addr);
+   ret = true;
+   goto out;
+   }
+
skb_new = arp_create(ARPOP_REPLY, ETH_P_AR

Re: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

2016-06-13 Thread Andreas Pape
"B.A.T.M.A.N"  schrieb am
20.05.2016 15:51:38:

> Von: Antonio Quartulli 
> An: The list for a Better Approach To Mobile Ad-hoc Networking
> 
> Datum: 20.05.2016 15:52
> Betreff: Re: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat
> by snooping received ip traffic
> Gesendet von: "B.A.T.M.A.N" 
>
> On Fri, May 06, 2016 at 10:58:23AM +0200, Andreas Pape wrote:
> > Speeding up dat address lookup is achieved by snooping all incoming ip
> > traffic. This especially increases the propability in bla setups that
> > a gateway into a common backbone network already has a fitting dat
entry
> > to answer incoming ARP requests directly coming from the backbone
> > network thus further reducing ARP traffic in the mesh.
>
> Any IP packet can't be sent if an ARP "handshake" has not been
performed. This
> means that when you are snooping an IP packet you have already snooped
an ARP
> packet slightly before. In which case do we really win something ?
>
In case of a static mesh ("static" in terms of non-moving mesh nodes and
when the mesh nodes almost always use the same backbone gateways for a
common
wired backbone) we gain nothing by snooping every packet.
The idea came up when I started experimenting with more dynamic setups
where the mesh nodes move around with several gateways into a common
wired backbone. In this case routing becomes more dynamically and it is
not assured that the traffic from/for a mesh node is always routed via
the same gateway which has already snooped the arp traffic.

> On top of that, don't you think that snooping *every* packet will badly
affect
> the performance ? Have you tried measuring the difference ?
>
I'm aware that this has an impact. I can try to measure the difference
using
my devices but these results of course are related to the hardware I use.
I'm lacking experience if such results can be used to generalize a
conclusion.

On the other hand this "feature" was not the root cause to post this
patchset. More important for me is the prevention of the "arp reply
storms" and the temporary loops between backbone network and the mesh
because this generates trouble in my application.
If it increases the propability for acceptance I don't care to remove
the ip source address snooping from the patchset.

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


Re: [B.A.T.M.A.N.] [PATCH v5 0/6] Optimizations for setups running dat and bla

2016-06-13 Thread Andreas Pape
Hi Sven,

thanks for the feedback. I just realized that I forgot to rebase the
patchset before sending it. Could this be the cause?
When I try to apply the patches locally to a fresh cloned batman-adv
repository, the patches succeeded but some hunks succeed with some
offset or fuzz only due to the missing rebase.
> Doesn't seem to apply:
>
> $ git describe
> v2016.2-50-g3ce003c
> $ git am ~/bundle-11-datbla.mbox
> Applying: batman-adv: prevent multiple ARP replies sent by
> gateways if dat enbled
> error: patch failed: net/batman-adv/distributed-arp-table.c:43
> error: net/batman-adv/distributed-arp-table.c: patch does not apply
> Patch failed at 0001 batman-adv: prevent multiple ARP replies
> sent by gateways if dat enbled
> The copy of the patch that failed is found in:
.git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am
--abort".
>
> Btw. there seems to be an "a" missing in "enabled" of the Subject
> of the first patch :)
>
Will be corrected as there's another version obviously necessary ...;-)

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


[B.A.T.M.A.N.] [PATCH v5 4/6] batman-adv: drop unicast packets from other backbone gw

2016-06-10 Thread Andreas Pape
Additional dropping of unicast packets received from another backbone gw of
the same backbone network before being forwarded to the same backbone again
is necessary. It was observed in a test setup that in rare cases these
frames lead to looping unicast traffic backbone->mesh->backbone.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/routing.c |   25 ++---
 1 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index e3857ed..667e2cd 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -861,14 +861,16 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
struct batadv_priv *bat_priv = netdev_priv(recv_if->soft_iface);
struct batadv_unicast_packet *unicast_packet;
struct batadv_unicast_4addr_packet *unicast_4addr_packet;
-   u8 *orig_addr;
-   struct batadv_orig_node *orig_node = NULL;
+   u8 *orig_addr, *orig_addr_gw;
+   struct batadv_orig_node *orig_node = NULL, *orig_node_gw = NULL;
int check, hdr_size = sizeof(*unicast_packet);
enum batadv_subtype subtype;
-   bool is4addr;
+   bool is4addr, is_gw;
+   struct ethhdr *ethhdr;

unicast_packet = (struct batadv_unicast_packet *)skb->data;
unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data;
+   ethhdr = eth_hdr(skb);

is4addr = unicast_packet->packet_type == BATADV_UNICAST_4ADDR;
/* the caller function should have already pulled 2 bytes */
@@ -891,6 +893,23 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,

/* packet for me */
if (batadv_is_my_mac(bat_priv, unicast_packet->dest)) {
+   /* If this is a unicast packet from another backgone gw,
+* drop it.
+*/
+   orig_addr_gw = ethhdr->h_source;
+   orig_node_gw = batadv_orig_hash_find(bat_priv, orig_addr_gw);
+   if (orig_node_gw) {
+   is_gw = batadv_bla_is_backbone_gw(skb, orig_node_gw,
+ hdr_size);
+   batadv_orig_node_put(orig_node_gw);
+   if (is_gw) {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "Dropped unicast pkt received from 
another backbone gw %pM.\n",
+  orig_addr_gw);
+   return NET_RX_DROP;
+   }
+   }
+
if (is4addr) {
subtype = unicast_4addr_packet->subtype;
batadv_dat_inc_counter(bat_priv, subtype);
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH v5 5/6] batman-adv: changed debug messages for easier bla debugging

2016-06-10 Thread Andreas Pape
Some of the bla debug messages are extended and additional messages are
added for easier bla debugging. Some debug messages introduced with the
dat changes in prior patches of this patch series have been changed to
be more compliant to other existing debug messages.

Acked-by: Simon Wunderlich 
Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   18 ++
 net/batman-adv/routing.c   |2 +-
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index cd2d74b..2ccce6e 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -715,8 +715,8 @@ static void batadv_bla_add_claim(struct batadv_priv 
*bat_priv,
goto claim_free_ref;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_add_claim(): changing ownership for %pM, vid 
%d\n",
-  mac, BATADV_PRINT_VID(vid));
+  "bla_add_claim(): changing ownership for %pM, vid %d 
to gw %pM\n",
+  mac, BATADV_PRINT_VID(vid), backbone_gw->orig);

spin_lock_bh(&claim->backbone_gw->crc_lock);
claim->backbone_gw->crc ^= crc16(0, claim->addr, ETH_ALEN);
@@ -1240,10 +1240,13 @@ static void batadv_bla_purge_claims(struct batadv_priv 
*bat_priv,
continue;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_purge_claims(): %pM, vid %d, time 
out\n",
+  "bla_purge_claims(): timed out.\n");
+
+purge_now:
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_purge_claims(): %pM, vid %d\n",
   claim->addr, claim->vid);

-purge_now:
batadv_handle_unclaim(bat_priv, primary_if,
  claim->backbone_gw->orig,
  claim->addr, claim->vid);
@@ -1787,6 +1790,13 @@ bool batadv_bla_rx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* possible optimization: race for a claim */
/* No claim exists yet, claim it for us!
 */
+
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_rx(): Unclaimed MAC %pM found. Claim it. Local: 
%s\n",
+  ethhdr->h_source,
+  batadv_is_my_client(bat_priv,
+  ethhdr->h_source, vid) ?
+  "yes" : "no");
batadv_handle_claim(bat_priv, primary_if,
primary_if->net_dev->dev_addr,
ethhdr->h_source, vid);
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 667e2cd..7eeae86 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -904,7 +904,7 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
batadv_orig_node_put(orig_node_gw);
if (is_gw) {
batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "Dropped unicast pkt received from 
another backbone gw %pM.\n",
+  "recv_unicast_packet(): Dropped 
unicast pkt received from another backbone gw %pM.\n",
   orig_addr_gw);
return NET_RX_DROP;
}
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH v5 6/6] batman-adv: handle race condition for claims between gateways

2016-06-10 Thread Andreas Pape
Consider the following situation which has been found in a test setup:
Gateway B has claimed client C and gateway A has the same backbone
network as B. C sends a broad- or multicast to B and directly after
this packet decides to send another packet to A due to a better TQ
value. B will forward the broad-/multicast into the backbone as it is
the responsible gw and after that A will claim C as it has been
chosen by C as the best gateway. If it now happens that A claims C
before it has received the broad-/multicast forwarded by B (due to
backbone topology or due to some delay in B when forwarding the
packet) we get a critical situation: in the current code A will
immediately unclaim C when receiving the multicast due to the
roaming client scenario although the position of C has not changed
in the mesh. If this happens the multi-/broadcast forwarded by B
will be sent back into the mesh by A and we have looping packets
until one of the gateways claims C again.
In order to prevent this, unclaiming of a client due to the roaming
client scenario is only done after a certain time is expired after
the last claim of the client. 100 ms are used here, which should be
slow enough for big backbones and slow gateways but fast enough not
to break the roaming client use case.

Acked-by: Simon Wunderlich 
Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 2ccce6e..4c3b294 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1904,10 +1904,22 @@ bool batadv_bla_tx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* if yes, the client has roamed and we have
 * to unclaim it.
 */
-   batadv_handle_unclaim(bat_priv, primary_if,
- primary_if->net_dev->dev_addr,
- ethhdr->h_source, vid);
-   goto allow;
+   if (batadv_has_timed_out(claim->lasttime, 100)) {
+   /* only unclaim if the last claim entry is
+* older than 100 ms to make sure we really
+* have a roaming client here.
+*/
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming 
client %pM detected. Unclaim it.\n",
+  ethhdr->h_source);
+   batadv_handle_unclaim(bat_priv, primary_if,
+ primary_if->net_dev->dev_addr,
+ ethhdr->h_source, vid);
+   goto allow;
+   } else {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race 
for claim %pM detected. Drop packet.\n",
+  ethhdr->h_source);
+   goto handled;
+   }
}

/* check if it is a multicast/broadcast frame */
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH v5 3/6] batman-adv: prevent duplication of ARP replies when DAT is used

2016-06-10 Thread Andreas Pape
If none of the backbone gateways in a bla setup has already knowledge of
the mac address searched for in an incoming ARP request from the backbone
an address resolution via the DHT of DAT is started. The gateway can send
several ARP requests to different DHT nodes and therefore can get several
replies. This patch assures that not all of the possible ARP replies are
returned to the backbone by checking the local DAT cache of the gateway.
If there is an entry in the local cache the gateway has already learned
the requested address and there is no need to forward the additional reply
to the backbone.
Furthermore it is checked if this gateway has claimed the source of the ARP
reply and only forwards it to the backbone if it has claimed the source or
if there is no claim at all.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index 998a4b8..e7b054a 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -1244,6 +1244,7 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
__be32 ip_src, ip_dst;
u8 *hw_src, *hw_dst;
bool dropped = false;
+   struct batadv_dat_entry *dat_entry = NULL;
unsigned short vid;

if (!atomic_read(&bat_priv->distributed_arp_table))
@@ -1263,12 +1264,41 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
hw_dst = batadv_arp_hw_dst(skb, hdr_size);
ip_dst = batadv_arp_ip_dst(skb, hdr_size);

+   /* If ip_dst is already in cache and has the right mac address,
+* drop this frame if this ARP reply is destined for us because it's
+* most probably an ARP reply generated by another node of the DHT.
+* We have most probably received already a reply earlier. Delivering
+* this frame would lead to doubled receive of an ARP reply.
+*/
+   dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_src, vid);
+   if ((dat_entry) && (batadv_compare_eth(hw_src, dat_entry->mac_addr))) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled ARP reply 
removed: ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4]; dat_entry: %pM-%pI4\n",
+  hw_src, &ip_src, hw_dst, &ip_dst,
+  dat_entry->mac_addr, &dat_entry->ip);
+   dropped = true;
+   goto out;
+   }
+
/* Update our internal cache with both the IP addresses the node got
 * within the ARP reply
 */
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);
batadv_dat_entry_add(bat_priv, ip_dst, hw_dst, vid);

+   /* If BLA is enabled, only forward ARP replies if we have claimed the
+* source of the ARP reply or if no one else of the same backbone has
+* already claimed that client. This prevents that different gateways
+* to the same backbone all forward the ARP reply leading to multiple
+* replies in the backbone.
+*/
+   if (!batadv_bla_check_claim(bat_priv, hw_src, vid)) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Device %pM claimed by another backbone gw. Drop ARP 
reply.\n",
+  hw_src);
+   dropped = true;
+   goto out;
+   }
+
/* if this REPLY is directed to a client of mine, let's deliver the
 * packet to the interface
 */
@@ -1281,6 +1311,8 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
 out:
if (dropped)
kfree_skb(skb);
+   if (dat_entry)
+   batadv_dat_entry_put(dat_entry);
/* if dropped == false -> deliver to the interface */
return dropped;
 }
--
1.7.0.4



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

[B.A.T.M.A.N.] [PATCH v5 2/6] batman-adv: speed up dat by snooping received ip traffic

2016-06-10 Thread Andreas Pape
Speeding up dat address lookup is achieved by snooping all incoming ip
traffic. This especially increases the propability in bla setups that
a gateway into a common backbone network already has a fitting dat entry
to answer incoming ARP requests directly coming from the backbone
network thus further reducing ARP traffic in the mesh.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   55 
 net/batman-adv/distributed-arp-table.h |9 +-
 net/batman-adv/soft-interface.c|3 ++
 3 files changed, 66 insertions(+), 1 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index b752f8d..998a4b8 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -362,6 +363,60 @@ out:
batadv_dat_entry_put(dat_entry);
 }

+/**
+ * batadv_dat_entry_check - check and update a dat entry
+ * @bat_priv: the bat priv with all the soft interface information
+ * @skb: socket buffer
+ * @vid: VLAN identifier
+ *
+ * snoops incoming socket buffer for dat cache updates, if dat is enabled.
+ * Can be called from other modules.
+ */
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
+   unsigned short vid)
+{
+   struct vlan_ethhdr *vhdr = NULL, tmp_vhdr;
+   struct ethhdr *ethhdr = NULL;
+   struct iphdr *iphdr = NULL, tmp_iphdr;
+
+   if (!atomic_read(&bat_priv->distributed_arp_table))
+   return;
+
+   ethhdr = eth_hdr(skb);
+
+   switch (ntohs(ethhdr->h_proto)) {
+   case ETH_P_IP:
+   iphdr = skb_header_pointer(skb, ETH_HLEN, sizeof(tmp_iphdr),
+  &tmp_iphdr);
+   break;
+   case ETH_P_8021Q:
+   vhdr = skb_header_pointer(skb, 0, sizeof(tmp_vhdr),
+ &tmp_vhdr);
+   if (!vhdr)
+   return;
+   if (ntohs(vhdr->h_vlan_encapsulated_proto) != ETH_P_IP)
+   return;
+   iphdr = skb_header_pointer(skb, sizeof(tmp_vhdr),
+  sizeof(tmp_iphdr),
+  &tmp_iphdr);
+   break;
+   }
+
+   if (!iphdr)
+   return;
+   /* don't add source address 0.0.0.0, which can occur during
+* dhcp discover or request.
+*/
+   if (ntohl(iphdr->saddr) == 0)
+   return;
+
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Snooped IP address: %pI4 %pM (vid: %d)\n",
+  &iphdr->saddr, ethhdr->h_source,
+  BATADV_PRINT_VID(vid));
+   batadv_dat_entry_add(bat_priv, iphdr->saddr, ethhdr->h_source, vid);
+}
+
 #ifdef CONFIG_BATMAN_ADV_DEBUG

 /**
diff --git a/net/batman-adv/distributed-arp-table.h 
b/net/batman-adv/distributed-arp-table.h
index 813ecea..cf1b93c 100644
--- a/net/batman-adv/distributed-arp-table.h
+++ b/net/batman-adv/distributed-arp-table.h
@@ -80,7 +80,8 @@ batadv_dat_init_own_addr(struct batadv_priv *bat_priv,
 int batadv_dat_init(struct batadv_priv *bat_priv);
 void batadv_dat_free(struct batadv_priv *bat_priv);
 int batadv_dat_cache_seq_print_text(struct seq_file *seq, void *offset);
-
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
+   unsigned short vid);
 /**
  * batadv_dat_inc_counter - increment the correct DAT packet counter
  * @bat_priv: the bat priv with all the soft interface information
@@ -173,6 +174,12 @@ static inline void batadv_dat_inc_counter(struct 
batadv_priv *bat_priv,
 {
 }

+static inline
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
+   unsigned short vid)
+{
+}
+
 #endif /* CONFIG_BATMAN_ADV_DAT */

 #endif /* _NET_BATMAN_ADV_DISTRIBUTED_ARP_TABLE_H_ */
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 81665b1..a86748f 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -442,6 +442,9 @@ void batadv_interface_rx(struct net_device *soft_iface,
goto dropped;
}

+   /* Snoop incoming traffic for dat update */
+   batadv_dat_entry_check(bat_priv, skb, vid);
+
/* skb->dev & skb->pkt_type are set here */
skb->protocol = eth_type_trans(skb, soft_iface);

--
1.7.0.4



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

[B.A.T.M.A.N.] [PATCH v5 1/6] batman-adv: prevent multiple ARP replies sent by gateways if dat enbled

2016-06-10 Thread Andreas Pape
If dat is enabled it must be made sure that only the backbone gw which has
claimed the remote destination for the ARP request answers the ARP request
directly if the MAC address is known due to the local dat table. This
prevents multiple ARP replies in a common backbone if more than one
gateway already knows the remote mac searched for in the ARP request.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   49 
 net/batman-adv/bridge_loop_avoidance.h |   11 +++
 net/batman-adv/distributed-arp-table.c |   15 ++
 3 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 748a9ea..cd2d74b 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -2045,3 +2045,52 @@ out:
batadv_hardif_put(primary_if);
return 0;
 }
+
+#ifdef CONFIG_BATMAN_ADV_DAT
+/**
+ * batadv_bla_check_claim - check if address is claimed
+ *
+ * @bat_priv: the bat priv with all the soft interface information
+ * @addr: mac address of which the claim status is checked
+ * @vid: the VLAN ID
+ *
+ * addr is checked if this address is claimed by the local device itself.
+ *
+ * Return: true if bla is disabled or the mac is claimed by the device,
+ * false if the device addr is already claimed by another gateway
+ */
+bool batadv_bla_check_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)
+   return ret;
+
+   /* 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.
+*/
+   if (claim) {
+   if (!batadv_compare_eth(claim->backbone_gw->orig,
+   primary_if->net_dev->dev_addr))
+   ret = false;
+   batadv_claim_put(claim);
+   }
+
+   batadv_hardif_put(primary_if);
+   return ret;
+}
+#endif
diff --git a/net/batman-adv/bridge_loop_avoidance.h 
b/net/batman-adv/bridge_loop_avoidance.h
index 0f01dae..9dddebc 100644
--- a/net/batman-adv/bridge_loop_avoidance.h
+++ b/net/batman-adv/bridge_loop_avoidance.h
@@ -47,6 +47,10 @@ void batadv_bla_update_orig_address(struct batadv_priv 
*bat_priv,
 void batadv_bla_status_update(struct net_device *net_dev);
 int batadv_bla_init(struct batadv_priv *bat_priv);
 void batadv_bla_free(struct batadv_priv *bat_priv);
+#ifdef CONFIG_BATMAN_ADV_DAT
+bool batadv_bla_check_claim(struct batadv_priv *bat_priv, u8 *addr,
+   unsigned short vid);
+#endif

 #define BATADV_BLA_CRC_INIT0
 #else /* ifdef CONFIG_BATMAN_ADV_BLA */
@@ -112,6 +116,13 @@ static inline void batadv_bla_free(struct batadv_priv 
*bat_priv)
 {
 }

+static inline
+bool batadv_bla_check_claim(struct batadv_priv *bat_priv, u8 *addr,
+   unsigned short vid)
+{
+   return true;
+}
+
 #endif /* ifdef CONFIG_BATMAN_ADV_BLA */

 #endif /* ifndef _NET_BATMAN_ADV_BLA_H_ */
diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index 278800a..b752f8d 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -43,6 +43,7 @@
 #include 
 #include 

+#include "bridge_loop_avoidance.h"
 #include "hard-interface.h"
 #include "hash.h"
 #include "originator.h"
@@ -1003,6 +1004,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_check_claim(bat_priv,
+   dat_entry->mac_addr, vid)) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Device %pM claimed by another backbone gw. 
Don't send ARP reply!",
+  dat_entry->mac_addr);
+   ret = true;
+   goto out;
+   }
+
skb_new = arp_create(ARPOP_REPLY, ETH_P_AR

[B.A.T.M.A.N.] [PATCH v5 0/6] Optimizations for setups running dat and bla

2016-06-10 Thread Andreas Pape
This patchset introduces optimizations for batman-adv in setups having several
gateways into a common (switched) Ethernet backbone network especially if dat
is additionally enabled.

Using the current implementation with bla and dat enabled, several problems
can be observed in a real setup:
1. Multiplication of ARP replies from dat enabled gateways and dat enabled
mesh nodes leading to an "ARP reply storm" in the common backbone network.
2. In rare corner cases bla does not fully prevent looping of unicast frames
in the direction Backbone --> mesh --> backbone and looping of multicast
frames in the direction mesh --> backbone --> mesh.
The latter can lead to temporary confusion in the switched backbone resulting
in packet loss and communication timeouts.

The observed problems are solved by introduction of additional rules for the
dat handling, bla packet forwarding and bla claiming/unclaiming of clients.

v5:
 - changed function name to batadv_bla_check_claim
 - put added include file in alphabetical order
 - added check to exclude ip address 0.0.0.0 from snooping

v4:
 - removed unnecessary include in soft-interface.c
 - solved issue with double-use and refcounting of pointers in routing.c

v3:

 - rebased patchset
 - moved snooping of ip addresses for dat speed up into separate function
 - removed "patch of a patch"
 - removed automatic claiming during check of a claim
 - fixed issues of the patchset not being compiled due to chosen batman
options

Kind regards,
Andreas

Andreas Pape (6):
  batman-adv: prevent multiple ARP replies sent by gateways if dat
enbled
  batman-adv: speed up dat by snooping received ip traffic
  batman-adv: prevent duplication of ARP replies when DAT is used
  batman-adv: drop unicast packets from other backbone gw
  batman-adv: changed debug messages for easier bla debugging
  batman-adv: handle race condition for claims between gateways

 net/batman-adv/bridge_loop_avoidance.c |   87 ---
 net/batman-adv/bridge_loop_avoidance.h |   11 
 net/batman-adv/distributed-arp-table.c |  102 
 net/batman-adv/distributed-arp-table.h |9 +++-
 net/batman-adv/routing.c   |   25 +++-
 net/batman-adv/soft-interface.c|3 +
 6 files changed, 225 insertions(+), 12 deletions(-)



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


[B.A.T.M.A.N.] Antwort: Re: [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

2016-05-20 Thread Andreas Pape
"B.A.T.M.A.N"  schrieb am
19.05.2016 21:45:53:

> Von: Linus Lüssing 
> An: The list for a Better Approach To Mobile Ad-hoc Networking
> 
> Datum: 19.05.2016 21:47
> Betreff: Re: [B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat
> by snooping received ip traffic
> Gesendet von: "B.A.T.M.A.N" 
>
> On Fri, May 06, 2016 at 10:58:23AM +0200, Andreas Pape wrote:
> > +void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct
> sk_buff *skb,
> > + unsigned short vid)
> > +{
> [...]
> > +   if (iphdr) {
> > +  batadv_dbg(BATADV_DBG_DAT, bat_priv,
> > +"Snooped IP address: %pI4 %pM (vid: %d)\n",
> > +&iphdr->saddr, ethhdr->h_source,
> > +BATADV_PRINT_VID(vid));
> > +  batadv_dat_entry_add(bat_priv, iphdr->saddr,
> > + ethhdr->h_source, vid);
> > +   }
>
> Not sure whether it is necessary, or whether there is a check
> somewhere later within DAT. But should we exclude some
> iphdr->saddr or ethhdr->h_source addresses? For instance a
> DHCPDISCOVER usually has a zero-ip address.

I think you have a good point here. Excluding especially
ip addresses like zero-ip address seems reasonable. Although
I think that this isn't a problem as long as no one is sending
arp requests for such ip addresses, filling the dat table with
unreasonable entries isn't a smart idea either. I will add some
additional tests here for reasonable ip addresses for the next
version of the patchset.

Thanks and 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.
___


[B.A.T.M.A.N.] Antwort: Re: [PATCH v4 1/6] batman-adv: prevent multiple ARP replies sent by gateways if dat enbled

2016-05-20 Thread Andreas Pape
Hi Simon,

Simon Wunderlich  schrieb am 18.05.2016 14:32:09:

> Von: Simon Wunderlich 
> An: Andreas Pape 
> Datum: 18.05.2016 14:32
> Betreff: Re: Antwort: Re: [B.A.T.M.A.N.] [PATCH v4 1/6] batman-adv:
> prevent multiple ARP replies sent by gateways if dat enbled
>
> Hi Andreas,
>
> On Wednesday 18 May 2016 09:50:21 Andreas Pape wrote:
> > > Von: Simon Wunderlich 
> > > An: b.a.t.m.a.n@lists.open-mesh.org
> > > Kopie: Andreas Pape 
> > > Datum: 13.05.2016 19:37
> > > Betreff: Re: [B.A.T.M.A.N.] [PATCH v4 1/6] batman-adv: prevent
> > > multiple ARP replies sent by gateways if dat enbled
> > >
> > > On Thursday 12 May 2016 08:31:32 Andreas Pape wrote:
> > > > @@ -1003,6 +1004,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)) {
> > > > + batadv_dbg(BATADV_DBG_DAT, bat_priv,
> > > > +   "Device %pM claimed by another backbone gw. Don't
send
> >
> > ARP
> >
> > > reply!",
> > >
> > > > +   dat_entry->mac_addr);
> > > > + ret = true;
> > > > + goto out;
> > > > +  }
> > > > +
> > >
> > > There is still my question/comment pending for this from your
PATCHv2.
> >
> > I'll
> >
> > > quote:
> > >
> > > I  would agree to Antonio that sending a claim is not necessary, and
> >
> > might
> >
> > > actually lead to bad choices of the outgoing backbone gateway. After
> >
> > all, at
> >
> > > this point any "random" backbone gateway may answer to this request,
> >
> > just
> >
> > > because it has the DAT entry, but maybe may actually not be able to
> >
> > reach the
> >
> > > client via the mesh.
>
>
> looks like your reply didn't go to the mailing list, not sure if
> this was your
> intention. Anyway ...
>

That wasn't my intention. It was just my fault;-). Sorry, if you receive
this
twice. I once again forgot to disable html support in my e-mail client...

> >
> > I removed the automatic claim in function
batadv_bla_handle_local_claim
> > but
> > obviously missed to change the comment here accordingly:-( I haven't
had
> > much
> > time recently to work on this and did not spent enough time to work
> > through
> > the new version of the patchset in a way I should have done
>
> Ah right, I missed that point, and was merely checking my old comments
...
> sorry, I should have checked better too.
>
> >
> > Perhaps it might be a also a good idea to rename the function to
something
> > which cannot be mixed easily with the function batadv_handle_claim.
What
> > about
> > the name batadv_bla_check_claim?
>
> Yes, definitely! We should rename it. check_claim sounds good to me.
>
If there are no other objections I will change the name as discussed in my

next attempt.

> Thanks a lot,
>   Simon

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


[B.A.T.M.A.N.] Antwort: [PATCH-maintv2] batman-adv: replace WARN with rate limited output on non-existing VLAN

2016-05-20 Thread Andreas Pape
Hi,

this is a point I also stumbled across. In my use case the problem is a
little bit
more difficult.
I use a setup with bat interfaces bridged to ethernet interfaces and my
mesh nodes
shall forward layer2 transparently network traffic from the wired network
into the
mesh.

My problem now is that among the layer2 traffic there are also vlan tagged
frames
whereas the bat interface isn't member of the vlan to be forwarded itself.

More specific in my case the frames use vlan id 0 and are tagged mainly
due to the
reason to guarantee some QoS in the wired network.

Yes, I know one might argue what reason QoS priority tagging has in mesh
setups, but
these frames are not generated by my devices but I have to forward them
"as they are".

As far as I understood the code, these frames do not only lead to the WARN
messages
(and there I welcome Simon's patch) but also lead to a drop of the tagged
packets
(correct ?). If I understood this correctly I would prefer that batman
would handle
vlan tagged packets on layer 2 like an unmanaged switch does: still
forward such
packets according to the mac header.

What do you think?

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


[B.A.T.M.A.N.] [PATCH v4 5/6] batman-adv: changed debug messages for easier bla debugging

2016-05-11 Thread Andreas Pape
Some of the bla debug messages are extended and additional messages are
added for easier bla debugging. Some debug messages introduced with the
dat changes in prior patches of this patch series have been changed to
be more compliant to other existing debug messages.

Acked-by: Simon Wunderlich 
Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   18 ++
 net/batman-adv/routing.c   |2 +-
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 2f46ce9..c426327 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -715,8 +715,8 @@ static void batadv_bla_add_claim(struct batadv_priv 
*bat_priv,
goto claim_free_ref;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_add_claim(): changing ownership for %pM, vid 
%d\n",
-  mac, BATADV_PRINT_VID(vid));
+  "bla_add_claim(): changing ownership for %pM, vid %d 
to gw %pM\n",
+  mac, BATADV_PRINT_VID(vid), backbone_gw->orig);

spin_lock_bh(&claim->backbone_gw->crc_lock);
claim->backbone_gw->crc ^= crc16(0, claim->addr, ETH_ALEN);
@@ -1240,10 +1240,13 @@ static void batadv_bla_purge_claims(struct batadv_priv 
*bat_priv,
continue;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_purge_claims(): %pM, vid %d, time 
out\n",
+  "bla_purge_claims(): timed out.\n");
+
+purge_now:
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_purge_claims(): %pM, vid %d\n",
   claim->addr, claim->vid);

-purge_now:
batadv_handle_unclaim(bat_priv, primary_if,
  claim->backbone_gw->orig,
  claim->addr, claim->vid);
@@ -1787,6 +1790,13 @@ bool batadv_bla_rx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* possible optimization: race for a claim */
/* No claim exists yet, claim it for us!
 */
+
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_rx(): Unclaimed MAC %pM found. Claim it. Local: 
%s\n",
+  ethhdr->h_source,
+  batadv_is_my_client(bat_priv,
+  ethhdr->h_source, vid) ?
+  "yes" : "no");
batadv_handle_claim(bat_priv, primary_if,
primary_if->net_dev->dev_addr,
ethhdr->h_source, vid);
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 667e2cd..7eeae86 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -904,7 +904,7 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
batadv_orig_node_put(orig_node_gw);
if (is_gw) {
batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "Dropped unicast pkt received from 
another backbone gw %pM.\n",
+  "recv_unicast_packet(): Dropped 
unicast pkt received from another backbone gw %pM.\n",
   orig_addr_gw);
return NET_RX_DROP;
}
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH v4 6/6] batman-adv: handle race condition for claims between gateways

2016-05-11 Thread Andreas Pape
Consider the following situation which has been found in a test setup:
Gateway B has claimed client C and gateway A has the same backbone
network as B. C sends a broad- or multicast to B and directly after
this packet decides to send another packet to A due to a better TQ
value. B will forward the broad-/multicast into the backbone as it is
the responsible gw and after that A will claim C as it has been
chosen by C as the best gateway. If it now happens that A claims C
before it has received the broad-/multicast forwarded by B (due to
backbone topology or due to some delay in B when forwarding the
packet) we get a critical situation: in the current code A will
immediately unclaim C when receiving the multicast due to the
roaming client scenario although the position of C has not changed
in the mesh. If this happens the multi-/broadcast forwarded by B
will be sent back into the mesh by A and we have looping packets
until one of the gateways claims C again.
In order to prevent this, unclaiming of a client due to the roaming
client scenario is only done after a certain time is expired after
the last claim of the client. 100 ms are used here, which should be
slow enough for big backbones and slow gateways but fast enough not
to break the roaming client use case.

Acked-by: Simon Wunderlich 
Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index c426327..0790cbc 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1904,10 +1904,22 @@ bool batadv_bla_tx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* if yes, the client has roamed and we have
 * to unclaim it.
 */
-   batadv_handle_unclaim(bat_priv, primary_if,
- primary_if->net_dev->dev_addr,
- ethhdr->h_source, vid);
-   goto allow;
+   if (batadv_has_timed_out(claim->lasttime, 100)) {
+   /* only unclaim if the last claim entry is
+* older than 100 ms to make sure we really
+* have a roaming client here.
+*/
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming 
client %pM detected. Unclaim it.\n",
+  ethhdr->h_source);
+   batadv_handle_unclaim(bat_priv, primary_if,
+ primary_if->net_dev->dev_addr,
+ ethhdr->h_source, vid);
+   goto allow;
+   } else {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race 
for claim %pM detected. Drop packet.\n",
+  ethhdr->h_source);
+   goto handled;
+   }
}

/* check if it is a multicast/broadcast frame */
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH v4 4/6] batman-adv: drop unicast packets from other backbone gw

2016-05-11 Thread Andreas Pape
Additional dropping of unicast packets received from another backbone gw of
the same backbone network before being forwarded to the same backbone again
is necessary. It was observed in a test setup that in rare cases these
frames lead to looping unicast traffic backbone->mesh->backbone.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/routing.c |   25 ++---
 1 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index e3857ed..667e2cd 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -861,14 +861,16 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
struct batadv_priv *bat_priv = netdev_priv(recv_if->soft_iface);
struct batadv_unicast_packet *unicast_packet;
struct batadv_unicast_4addr_packet *unicast_4addr_packet;
-   u8 *orig_addr;
-   struct batadv_orig_node *orig_node = NULL;
+   u8 *orig_addr, *orig_addr_gw;
+   struct batadv_orig_node *orig_node = NULL, *orig_node_gw = NULL;
int check, hdr_size = sizeof(*unicast_packet);
enum batadv_subtype subtype;
-   bool is4addr;
+   bool is4addr, is_gw;
+   struct ethhdr *ethhdr;

unicast_packet = (struct batadv_unicast_packet *)skb->data;
unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data;
+   ethhdr = eth_hdr(skb);

is4addr = unicast_packet->packet_type == BATADV_UNICAST_4ADDR;
/* the caller function should have already pulled 2 bytes */
@@ -891,6 +893,23 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,

/* packet for me */
if (batadv_is_my_mac(bat_priv, unicast_packet->dest)) {
+   /* If this is a unicast packet from another backgone gw,
+* drop it.
+*/
+   orig_addr_gw = ethhdr->h_source;
+   orig_node_gw = batadv_orig_hash_find(bat_priv, orig_addr_gw);
+   if (orig_node_gw) {
+   is_gw = batadv_bla_is_backbone_gw(skb, orig_node_gw,
+ hdr_size);
+   batadv_orig_node_put(orig_node_gw);
+   if (is_gw) {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "Dropped unicast pkt received from 
another backbone gw %pM.\n",
+  orig_addr_gw);
+   return NET_RX_DROP;
+   }
+   }
+
if (is4addr) {
subtype = unicast_4addr_packet->subtype;
batadv_dat_inc_counter(bat_priv, subtype);
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH v4 1/6] batman-adv: prevent multiple ARP replies sent by gateways if dat enbled

2016-05-11 Thread Andreas Pape
If dat is enabled it must be made sure that only the backbone gw which has
claimed the remote destination for the ARP request answers the ARP request
directly if the MAC address is known due to the local dat table. This
prevents multiple ARP replies in a common backbone if more than one
gateway already knows the remote mac searched for in the ARP request.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   49 
 net/batman-adv/bridge_loop_avoidance.h |   11 +++
 net/batman-adv/distributed-arp-table.c |   15 ++
 3 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 748a9ea..2f46ce9 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -2045,3 +2045,52 @@ out:
batadv_hardif_put(primary_if);
return 0;
 }
+
+#ifdef CONFIG_BATMAN_ADV_DAT
+/**
+ * batadv_bla_handle_local_claim - check if address is claimed
+ *
+ * @bat_priv: the bat priv with all the soft interface information
+ * @addr: mac address of which the claim status is checked
+ * @vid: the VLAN ID
+ *
+ * addr is checked if this address is claimed by the local device itself.
+ *
+ * Return: true if bla is disabled or the mac is claimed by the device,
+ * false if the device addr is already claimed by another gateway
+ */
+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)
+   return ret;
+
+   /* 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.
+*/
+   if (claim) {
+   if (!batadv_compare_eth(claim->backbone_gw->orig,
+   primary_if->net_dev->dev_addr))
+   ret = false;
+   batadv_claim_put(claim);
+   }
+
+   batadv_hardif_put(primary_if);
+   return ret;
+}
+#endif
diff --git a/net/batman-adv/bridge_loop_avoidance.h 
b/net/batman-adv/bridge_loop_avoidance.h
index 0f01dae..cc07be9 100644
--- a/net/batman-adv/bridge_loop_avoidance.h
+++ b/net/batman-adv/bridge_loop_avoidance.h
@@ -47,6 +47,10 @@ void batadv_bla_update_orig_address(struct batadv_priv 
*bat_priv,
 void batadv_bla_status_update(struct net_device *net_dev);
 int batadv_bla_init(struct batadv_priv *bat_priv);
 void batadv_bla_free(struct batadv_priv *bat_priv);
+#ifdef CONFIG_BATMAN_ADV_DAT
+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr,
+  unsigned short vid);
+#endif

 #define BATADV_BLA_CRC_INIT0
 #else /* ifdef CONFIG_BATMAN_ADV_BLA */
@@ -112,6 +116,13 @@ static inline void batadv_bla_free(struct batadv_priv 
*bat_priv)
 {
 }

+static inline
+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr,
+  unsigned short vid)
+{
+   return true;
+}
+
 #endif /* ifdef CONFIG_BATMAN_ADV_BLA */

 #endif /* ifndef _NET_BATMAN_ADV_BLA_H_ */
diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index 278800a..c11f035 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -48,6 +48,7 @@
 #include "originator.h"
 #include "send.h"
 #include "translation-table.h"
+#include "bridge_loop_avoidance.h"

 static void batadv_dat_purge(struct work_struct *work);

@@ -1003,6 +1004,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)) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Device %pM claimed by another backbone gw. 
Don't send ARP reply!",
+  dat_entry->mac_addr);
+   ret = true;
+   goto out;
+  

[B.A.T.M.A.N.] [PATCH v4 3/6] batman-adv: prevent duplication of ARP replies when DAT is used

2016-05-11 Thread Andreas Pape
If none of the backbone gateways in a bla setup has already knowledge of
the mac address searched for in an incoming ARP request from the backbone
an address resolution via the DHT of DAT is started. The gateway can send
several ARP requests to different DHT nodes and therefore can get several
replies. This patch assures that not all of the possible ARP replies are
returned to the backbone by checking the local DAT cache of the gateway.
If there is an entry in the local cache the gateway has already learned
the requested address and there is no need to forward the additional reply
to the backbone.
Furthermore it is checked if this gateway has claimed the source of the ARP
reply and only forwards it to the backbone if it has claimed the source or
if there is no claim at all.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index 309daf1..53c5cb6 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -1239,6 +1239,7 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
__be32 ip_src, ip_dst;
u8 *hw_src, *hw_dst;
bool dropped = false;
+   struct batadv_dat_entry *dat_entry = NULL;
unsigned short vid;

if (!atomic_read(&bat_priv->distributed_arp_table))
@@ -1258,12 +1259,41 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
hw_dst = batadv_arp_hw_dst(skb, hdr_size);
ip_dst = batadv_arp_ip_dst(skb, hdr_size);

+   /* If ip_dst is already in cache and has the right mac address,
+* drop this frame if this ARP reply is destined for us because it's
+* most probably an ARP reply generated by another node of the DHT.
+* We have most probably received already a reply earlier. Delivering
+* this frame would lead to doubled receive of an ARP reply.
+*/
+   dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_src, vid);
+   if ((dat_entry) && (batadv_compare_eth(hw_src, dat_entry->mac_addr))) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled ARP reply 
removed: ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4]; dat_entry: %pM-%pI4\n",
+  hw_src, &ip_src, hw_dst, &ip_dst,
+  dat_entry->mac_addr, &dat_entry->ip);
+   dropped = true;
+   goto out;
+   }
+
/* Update our internal cache with both the IP addresses the node got
 * within the ARP reply
 */
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);
batadv_dat_entry_add(bat_priv, ip_dst, hw_dst, vid);

+   /* If BLA is enabled, only forward ARP replies if we have claimed the
+* source of the ARP reply or if no one else of the same backbone has
+* already claimed that client. This prevents that different gateways
+* to the same backbone all forward the ARP reply leading to multiple
+* replies in the backbone.
+*/
+   if (!batadv_bla_handle_local_claim(bat_priv, hw_src, vid)) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Device %pM claimed by another backbone gw. Drop ARP 
reply.\n",
+  hw_src);
+   dropped = true;
+   goto out;
+   }
+
/* if this REPLY is directed to a client of mine, let's deliver the
 * packet to the interface
 */
@@ -1276,6 +1306,8 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
 out:
if (dropped)
kfree_skb(skb);
+   if (dat_entry)
+   batadv_dat_entry_put(dat_entry);
/* if dropped == false -> deliver to the interface */
return dropped;
 }
--
1.7.0.4



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

[B.A.T.M.A.N.] [PATCH v4 2/6] batman-adv: speed up dat by snooping received ip traffic

2016-05-11 Thread Andreas Pape
Speeding up dat address lookup is achieved by snooping all incoming ip
traffic. This especially increases the propability in bla setups that
a gateway into a common backbone network already has a fitting dat entry
to answer incoming ARP requests directly coming from the backbone
network thus further reducing ARP traffic in the mesh.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   50 
 net/batman-adv/distributed-arp-table.h |9 +-
 net/batman-adv/soft-interface.c|3 ++
 3 files changed, 61 insertions(+), 1 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index c11f035..309daf1 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -362,6 +363,55 @@ out:
batadv_dat_entry_put(dat_entry);
 }

+/**
+ * batadv_dat_entry_check - check and update a dat entry
+ * @bat_priv: the bat priv with all the soft interface information
+ * @skb: socket buffer
+ * @vid: VLAN identifier
+ *
+ * snoops incoming socket buffer for dat cache updates, if dat is enabled.
+ * Can be called from other modules.
+ */
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
+   unsigned short vid)
+{
+   struct vlan_ethhdr *vhdr = NULL, tmp_vhdr;
+   struct ethhdr *ethhdr = NULL;
+   struct iphdr *iphdr = NULL, tmp_iphdr;
+
+   if (!atomic_read(&bat_priv->distributed_arp_table))
+   return;
+
+   ethhdr = eth_hdr(skb);
+
+   switch (ntohs(ethhdr->h_proto)) {
+   case ETH_P_IP:
+   iphdr = skb_header_pointer(skb, ETH_HLEN, sizeof(tmp_iphdr),
+  &tmp_iphdr);
+   break;
+   case ETH_P_8021Q:
+   vhdr = skb_header_pointer(skb, 0, sizeof(tmp_vhdr),
+ &tmp_vhdr);
+   if (!vhdr)
+   return;
+   if (ntohs(vhdr->h_vlan_encapsulated_proto) != ETH_P_IP)
+   return;
+   iphdr = skb_header_pointer(skb, sizeof(tmp_vhdr),
+  sizeof(tmp_iphdr),
+  &tmp_iphdr);
+   break;
+   }
+
+   if (!iphdr)
+   return;
+
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Snooped IP address: %pI4 %pM (vid: %d)\n",
+  &iphdr->saddr, ethhdr->h_source,
+  BATADV_PRINT_VID(vid));
+   batadv_dat_entry_add(bat_priv, iphdr->saddr, ethhdr->h_source, vid);
+}
+
 #ifdef CONFIG_BATMAN_ADV_DEBUG

 /**
diff --git a/net/batman-adv/distributed-arp-table.h 
b/net/batman-adv/distributed-arp-table.h
index 813ecea..cf1b93c 100644
--- a/net/batman-adv/distributed-arp-table.h
+++ b/net/batman-adv/distributed-arp-table.h
@@ -80,7 +80,8 @@ batadv_dat_init_own_addr(struct batadv_priv *bat_priv,
 int batadv_dat_init(struct batadv_priv *bat_priv);
 void batadv_dat_free(struct batadv_priv *bat_priv);
 int batadv_dat_cache_seq_print_text(struct seq_file *seq, void *offset);
-
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
+   unsigned short vid);
 /**
  * batadv_dat_inc_counter - increment the correct DAT packet counter
  * @bat_priv: the bat priv with all the soft interface information
@@ -173,6 +174,12 @@ static inline void batadv_dat_inc_counter(struct 
batadv_priv *bat_priv,
 {
 }

+static inline
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
+   unsigned short vid)
+{
+}
+
 #endif /* CONFIG_BATMAN_ADV_DAT */

 #endif /* _NET_BATMAN_ADV_DISTRIBUTED_ARP_TABLE_H_ */
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 81665b1..a86748f 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -442,6 +442,9 @@ void batadv_interface_rx(struct net_device *soft_iface,
goto dropped;
}

+   /* Snoop incoming traffic for dat update */
+   batadv_dat_entry_check(bat_priv, skb, vid);
+
/* skb->dev & skb->pkt_type are set here */
skb->protocol = eth_type_trans(skb, soft_iface);

--
1.7.0.4



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

[B.A.T.M.A.N.] [PATCH v4 0/6] batman-adv: Optimizations for setups running dat and bla

2016-05-11 Thread Andreas Pape
This patchset introduces optimizations for batman-adv in setups having several
gateways into a common (switched) Ethernet backbone network especially if dat
is additionally enabled.

Using the current implementation with bla and dat enabled, several problems
can be observed in a real setup:
1. Multiplication of ARP replies from dat enabled gateways and dat enabled
mesh nodes leading to an "ARP reply storm" in the common backbone network.
2. In rare corner cases bla does not fully prevent looping of unicast frames
in the direction Backbone --> mesh --> backbone and looping of multicast
frames in the direction mesh --> backbone --> mesh.
The latter can lead to temporary confusion in the switched backbone resulting
in packet loss and communication timeouts.

The observed problems are solved by introduction of additional rules for the
dat handling, bla packet forwarding and bla claiming/unclaiming of clients.

v4:
 - removed unnecessary include in soft-interface.c
 - solved issue with double-use and refcounting of pointers in routing.c

v3:

 - rebased patchset
 - moved snooping of ip addresses for dat speed up into separate function
 - removed "patch of a patch"
 - removed automatic claiming during check of a claim
 - fixed issues of the patchset not being compiled due to chosen batman
options

Kind regards,
Andreas

Andreas Pape (6):
  batman-adv: prevent multiple ARP replies sent by gateways if dat
enbled
  batman-adv: speed up dat by snooping received ip traffic
  batman-adv: prevent duplication of ARP replies when DAT is used
  batman-adv: drop unicast packets from other backbone gw
  batman-adv: changed debug messages for easier bla debugging
  batman-adv: handle race condition for claims between gateways

 net/batman-adv/bridge_loop_avoidance.c |   87 ++---
 net/batman-adv/bridge_loop_avoidance.h |   11 
 net/batman-adv/distributed-arp-table.c |   97 
 net/batman-adv/distributed-arp-table.h |9 +++-
 net/batman-adv/routing.c   |   25 +++-
 net/batman-adv/soft-interface.c|3 +
 6 files changed, 220 insertions(+), 12 deletions(-)



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


[B.A.T.M.A.N.] [PATCHv3 6/6] batman-adv: handle race condition for claims between gateways

2016-05-06 Thread Andreas Pape
Consider the following situation which has been found in a test setup:
Gateway B has claimed client C and gateway A has the same backbone
network as B. C sends a broad- or multicast to B and directly after
this packet decides to send another packet to A due to a better TQ
value. B will forward the broad-/multicast into the backbone as it is
the responsible gw and after that A will claim C as it has been
chosen by C as the best gateway. If it now happens that A claims C
before it has received the broad-/multicast forwarded by B (due to
backbone topology or due to some delay in B when forwarding the
packet) we get a critical situation: in the current code A will
immediately unclaim C when receiving the multicast due to the
roaming client scenario although the position of C has not changed
in the mesh. If this happens the multi-/broadcast forwarded by B
will be sent back into the mesh by A and we have looping packets
until one of the gateways claims C again.
In order to prevent this, unclaiming of a client due to the roaming
client scenario is only done after a certain time is expired after
the last claim of the client. 100 ms are used here, which should be
slow enough for big backbones and slow gateways but fast enough not
to break the roaming client use case.

Acked-by: Simon Wunderlich 
Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index c426327..0790cbc 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1904,10 +1904,22 @@ bool batadv_bla_tx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* if yes, the client has roamed and we have
 * to unclaim it.
 */
-   batadv_handle_unclaim(bat_priv, primary_if,
- primary_if->net_dev->dev_addr,
- ethhdr->h_source, vid);
-   goto allow;
+   if (batadv_has_timed_out(claim->lasttime, 100)) {
+   /* only unclaim if the last claim entry is
+* older than 100 ms to make sure we really
+* have a roaming client here.
+*/
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming 
client %pM detected. Unclaim it.\n",
+  ethhdr->h_source);
+   batadv_handle_unclaim(bat_priv, primary_if,
+ primary_if->net_dev->dev_addr,
+ ethhdr->h_source, vid);
+   goto allow;
+   } else {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race 
for claim %pM detected. Drop packet.\n",
+  ethhdr->h_source);
+   goto handled;
+   }
}

/* check if it is a multicast/broadcast frame */
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCHv3 5/6] batman-adv: changed debug messages for easier bla debugging

2016-05-06 Thread Andreas Pape
Some of the bla debug messages are extended and additional messages are
added for easier bla debugging. Some debug messages introduced with the
dat changes in prior patches of this patch series have been changed to
be more compliant to other existing debug messages.

Acked-by: Simon Wunderlich 
Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   18 ++
 net/batman-adv/routing.c   |2 +-
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 2f46ce9..c426327 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -715,8 +715,8 @@ static void batadv_bla_add_claim(struct batadv_priv 
*bat_priv,
goto claim_free_ref;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_add_claim(): changing ownership for %pM, vid 
%d\n",
-  mac, BATADV_PRINT_VID(vid));
+  "bla_add_claim(): changing ownership for %pM, vid %d 
to gw %pM\n",
+  mac, BATADV_PRINT_VID(vid), backbone_gw->orig);

spin_lock_bh(&claim->backbone_gw->crc_lock);
claim->backbone_gw->crc ^= crc16(0, claim->addr, ETH_ALEN);
@@ -1240,10 +1240,13 @@ static void batadv_bla_purge_claims(struct batadv_priv 
*bat_priv,
continue;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_purge_claims(): %pM, vid %d, time 
out\n",
+  "bla_purge_claims(): timed out.\n");
+
+purge_now:
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_purge_claims(): %pM, vid %d\n",
   claim->addr, claim->vid);

-purge_now:
batadv_handle_unclaim(bat_priv, primary_if,
  claim->backbone_gw->orig,
  claim->addr, claim->vid);
@@ -1787,6 +1790,13 @@ bool batadv_bla_rx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* possible optimization: race for a claim */
/* No claim exists yet, claim it for us!
 */
+
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_rx(): Unclaimed MAC %pM found. Claim it. Local: 
%s\n",
+  ethhdr->h_source,
+  batadv_is_my_client(bat_priv,
+  ethhdr->h_source, vid) ?
+  "yes" : "no");
batadv_handle_claim(bat_priv, primary_if,
primary_if->net_dev->dev_addr,
ethhdr->h_source, vid);
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 1ef0735..99186da 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -916,7 +916,7 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
if (orig_node &&
batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) {
batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "Dropped unicast pkt received from another 
backbone gw %pM.\n",
+  "recv_unicast_packet(): Dropped unicast pkt 
received from another backbone gw %pM.\n",
   orig_addr);
batadv_orig_node_put(orig_node);
return NET_RX_DROP;
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCHv3 2/6] batman-adv: speed up dat by snooping received ip traffic

2016-05-06 Thread Andreas Pape
Speeding up dat address lookup is achieved by snooping all incoming ip
traffic. This especially increases the propability in bla setups that
a gateway into a common backbone network already has a fitting dat entry
to answer incoming ARP requests directly coming from the backbone
network thus further reducing ARP traffic in the mesh.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   50 
 net/batman-adv/distributed-arp-table.h |9 +-
 net/batman-adv/soft-interface.c|4 ++
 3 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index c11f035..58cb488 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -362,6 +363,55 @@ out:
batadv_dat_entry_put(dat_entry);
 }

+/**
+ * batadv_dat_entry_check - check and update a dat entry
+ * @bat_priv: the bat priv with all the soft interface information
+ * @skb: socket buffer
+ * @vid: VLAN identifier
+ *
+ * snoops incoming socket buffer for dat cache updates, if dat is enabled.
+ * Can be called from other modules.
+ */
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
+   unsigned short vid)
+{
+   struct vlan_ethhdr *vhdr = NULL, tmp_vhdr;
+   struct ethhdr *ethhdr = NULL;
+   struct iphdr *iphdr = NULL, tmp_iphdr;
+
+   if (!atomic_read(&bat_priv->distributed_arp_table))
+   return;
+
+   ethhdr = eth_hdr(skb);
+
+   switch (ntohs(ethhdr->h_proto)) {
+   case ETH_P_IP:
+   iphdr = skb_header_pointer(skb, ETH_HLEN, sizeof(tmp_iphdr),
+  &tmp_iphdr);
+   break;
+   case ETH_P_8021Q:
+   vhdr = skb_header_pointer(skb, 0, sizeof(tmp_vhdr),
+ &tmp_vhdr);
+   if (!vhdr)
+   break;
+   if (ntohs(vhdr->h_vlan_encapsulated_proto) == ETH_P_IP) {
+   iphdr = skb_header_pointer(skb, sizeof(tmp_vhdr),
+  sizeof(tmp_iphdr),
+  &tmp_iphdr);
+   }
+   break;
+   }
+
+   if (iphdr) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Snooped IP address: %pI4 %pM (vid: %d)\n",
+  &iphdr->saddr, ethhdr->h_source,
+  BATADV_PRINT_VID(vid));
+   batadv_dat_entry_add(bat_priv, iphdr->saddr,
+ethhdr->h_source, vid);
+   }
+}
+
 #ifdef CONFIG_BATMAN_ADV_DEBUG

 /**
diff --git a/net/batman-adv/distributed-arp-table.h 
b/net/batman-adv/distributed-arp-table.h
index 813ecea..cf1b93c 100644
--- a/net/batman-adv/distributed-arp-table.h
+++ b/net/batman-adv/distributed-arp-table.h
@@ -80,7 +80,8 @@ batadv_dat_init_own_addr(struct batadv_priv *bat_priv,
 int batadv_dat_init(struct batadv_priv *bat_priv);
 void batadv_dat_free(struct batadv_priv *bat_priv);
 int batadv_dat_cache_seq_print_text(struct seq_file *seq, void *offset);
-
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
+   unsigned short vid);
 /**
  * batadv_dat_inc_counter - increment the correct DAT packet counter
  * @bat_priv: the bat priv with all the soft interface information
@@ -173,6 +174,12 @@ static inline void batadv_dat_inc_counter(struct 
batadv_priv *bat_priv,
 {
 }

+static inline
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, struct sk_buff *skb,
+   unsigned short vid)
+{
+}
+
 #endif /* CONFIG_BATMAN_ADV_DAT */

 #endif /* _NET_BATMAN_ADV_DISTRIBUTED_ARP_TABLE_H_ */
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 81665b1..1f1742a 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -442,6 +443,9 @@ void batadv_interface_rx(struct net_device *soft_iface,
goto dropped;
}

+   /* Snoop incoming traffic for dat update */
+   batadv_dat_entry_check(bat_priv, skb, vid);
+
/* skb->dev & skb->pkt_type are set here */
skb->protocol = eth_type_trans(skb, soft_iface);

--
1.7.0.4



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

[B.A.T.M.A.N.] [PATCHv3 4/6] batman-adv: drop unicast packets from other backbone gw

2016-05-06 Thread Andreas Pape
Additional dropping of unicast packets received from another backbone gw of
the same backbone network before being forwarded to the same backbone again
is necessary. It was observed in a test setup that in rare cases these
frames lead to looping unicast traffic backbone->mesh->backbone.

Acked-by: Simon Wunderlich 
Signed-off-by: Andreas Pape 
---
 net/batman-adv/routing.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index ae850f2..1ef0735 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -864,9 +864,11 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
int check, hdr_size = sizeof(*unicast_packet);
enum batadv_subtype subtype;
bool is4addr;
+   struct ethhdr *ethhdr;

unicast_packet = (struct batadv_unicast_packet *)skb->data;
unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data;
+   ethhdr = eth_hdr(skb);

is4addr = unicast_packet->packet_type == BATADV_UNICAST_4ADDR;
/* the caller function should have already pulled 2 bytes */
@@ -906,6 +908,20 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
}
}

+   /* If this is a unicast packet from another backgone gw,
+* drop it.
+*/
+   orig_addr = ethhdr->h_source;
+   orig_node = batadv_orig_hash_find(bat_priv, orig_addr);
+   if (orig_node &&
+   batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "Dropped unicast pkt received from another 
backbone gw %pM.\n",
+  orig_addr);
+   batadv_orig_node_put(orig_node);
+   return NET_RX_DROP;
+   }
+
if (batadv_dat_snoop_incoming_arp_request(bat_priv, skb,
  hdr_size))
goto rx_success;
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCHv3 3/6] batman-adv: prevent duplication of ARP replies when DAT is used

2016-05-06 Thread Andreas Pape
If none of the backbone gateways in a bla setup has already knowledge of
the mac address searched for in an incoming ARP request from the backbone
an address resolution via the DHT of DAT is started. The gateway can send
several ARP requests to different DHT nodes and therefore can get several
replies. This patch assures that not all of the possible ARP replies are
returned to the backbone by checking the local DAT cache of the gateway.
If there is an entry in the local cache the gateway has already learned
the requested address and there is no need to forward the additional reply
to the backbone.
Furthermore it is checked if this gateway has claimed the source of the ARP
reply and only forwards it to the backbone if it has claimed the source or
if there is no claim at all.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   32 
 1 files changed, 32 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index 58cb488..f025c69 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -1239,6 +1239,7 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
__be32 ip_src, ip_dst;
u8 *hw_src, *hw_dst;
bool dropped = false;
+   struct batadv_dat_entry *dat_entry = NULL;
unsigned short vid;

if (!atomic_read(&bat_priv->distributed_arp_table))
@@ -1258,12 +1259,41 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
hw_dst = batadv_arp_hw_dst(skb, hdr_size);
ip_dst = batadv_arp_ip_dst(skb, hdr_size);

+   /* If ip_dst is already in cache and has the right mac address,
+* drop this frame if this ARP reply is destined for us because it's
+* most probably an ARP reply generated by another node of the DHT.
+* We have most probably received already a reply earlier. Delivering
+* this frame would lead to doubled receive of an ARP reply.
+*/
+   dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_src, vid);
+   if ((dat_entry) && (batadv_compare_eth(hw_src, dat_entry->mac_addr))) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled ARP reply 
removed: ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4]; dat_entry: %pM-%pI4\n",
+  hw_src, &ip_src, hw_dst, &ip_dst,
+  dat_entry->mac_addr, &dat_entry->ip);
+   dropped = true;
+   goto out;
+   }
+
/* Update our internal cache with both the IP addresses the node got
 * within the ARP reply
 */
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);
batadv_dat_entry_add(bat_priv, ip_dst, hw_dst, vid);

+   /* If BLA is enabled, only forward ARP replies if we have claimed the
+* source of the ARP reply or if no one else of the same backbone has
+* already claimed that client. This prevents that different gateways
+* to the same backbone all forward the ARP reply leading to multiple
+* replies in the backbone.
+*/
+   if (!batadv_bla_handle_local_claim(bat_priv, hw_src, vid)) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Device %pM claimed by another backbone gw. Drop ARP 
reply.\n",
+  hw_src);
+   dropped = true;
+   goto out;
+   }
+
/* if this REPLY is directed to a client of mine, let's deliver the
 * packet to the interface
 */
@@ -1276,6 +1306,8 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
 out:
if (dropped)
kfree_skb(skb);
+   if (dat_entry)
+   batadv_dat_entry_put(dat_entry);
/* if dropped == false -> deliver to the interface */
return dropped;
 }
--
1.7.0.4



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

[B.A.T.M.A.N.] [PATCHv3 0/6] batman-adv: Optimizations for setups running dat and bla

2016-05-06 Thread Andreas Pape
This patchset introduces optimizations for batman-adv in setups having several
gateways into a common (switched) Ethernet backbone network especially if dat
is additionally enabled.

Using the current implementation with bla and dat enabled, several problems
can be observed in a real setup:
1. Multiplication of ARP replies from dat enabled gateways and dat enabled
mesh nodes leading to an "ARP reply storm" in the common backbone network.
2. In rare corner cases bla does not fully prevent looping of unicast frames
in the direction Backbone --> mesh --> backbone and looping of multicast
frames in the direction mesh --> backbone --> mesh.
The latter can lead to temporary confusion in the switched backbone resulting
in packet loss and communication timeouts.

The observed problems are solved by introduction of additional rules for the
dat handling, bla packet forwarding and bla claiming/unclaiming of clients.

v3:

 - rebased patchset
 - moved snooping of ip addresses for dat speed up into separate function
 - removed "patch of a patch"
 - removed automatic claiming during check of a claim
 - fixed issues of the patchset not being compiled due to chosen batman
options

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


[B.A.T.M.A.N.] [PATCHv3 1/6] batman-adv: prevent multiple ARP replies sent by gateways if dat enbled

2016-05-06 Thread Andreas Pape
If dat is enabled it must be made sure that only the backbone gw which has
claimed the remote destination for the ARP request answers the ARP request
directly if the MAC address is known due to the local dat table. This
prevents multiple ARP replies in a common backbone if more than one
gateway already knows the remote mac searched for in the ARP request.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   49 
 net/batman-adv/bridge_loop_avoidance.h |   11 +++
 net/batman-adv/distributed-arp-table.c |   15 ++
 3 files changed, 75 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 748a9ea..2f46ce9 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -2045,3 +2045,52 @@ out:
batadv_hardif_put(primary_if);
return 0;
 }
+
+#ifdef CONFIG_BATMAN_ADV_DAT
+/**
+ * batadv_bla_handle_local_claim - check if address is claimed
+ *
+ * @bat_priv: the bat priv with all the soft interface information
+ * @addr: mac address of which the claim status is checked
+ * @vid: the VLAN ID
+ *
+ * addr is checked if this address is claimed by the local device itself.
+ *
+ * Return: true if bla is disabled or the mac is claimed by the device,
+ * false if the device addr is already claimed by another gateway
+ */
+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)
+   return ret;
+
+   /* 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.
+*/
+   if (claim) {
+   if (!batadv_compare_eth(claim->backbone_gw->orig,
+   primary_if->net_dev->dev_addr))
+   ret = false;
+   batadv_claim_put(claim);
+   }
+
+   batadv_hardif_put(primary_if);
+   return ret;
+}
+#endif
diff --git a/net/batman-adv/bridge_loop_avoidance.h 
b/net/batman-adv/bridge_loop_avoidance.h
index 0f01dae..cc07be9 100644
--- a/net/batman-adv/bridge_loop_avoidance.h
+++ b/net/batman-adv/bridge_loop_avoidance.h
@@ -47,6 +47,10 @@ void batadv_bla_update_orig_address(struct batadv_priv 
*bat_priv,
 void batadv_bla_status_update(struct net_device *net_dev);
 int batadv_bla_init(struct batadv_priv *bat_priv);
 void batadv_bla_free(struct batadv_priv *bat_priv);
+#ifdef CONFIG_BATMAN_ADV_DAT
+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr,
+  unsigned short vid);
+#endif

 #define BATADV_BLA_CRC_INIT0
 #else /* ifdef CONFIG_BATMAN_ADV_BLA */
@@ -112,6 +116,13 @@ static inline void batadv_bla_free(struct batadv_priv 
*bat_priv)
 {
 }

+static inline
+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr,
+  unsigned short vid)
+{
+   return true;
+}
+
 #endif /* ifdef CONFIG_BATMAN_ADV_BLA */

 #endif /* ifndef _NET_BATMAN_ADV_BLA_H_ */
diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index 278800a..c11f035 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -48,6 +48,7 @@
 #include "originator.h"
 #include "send.h"
 #include "translation-table.h"
+#include "bridge_loop_avoidance.h"

 static void batadv_dat_purge(struct work_struct *work);

@@ -1003,6 +1004,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)) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
+  "Device %pM claimed by another backbone gw. 
Don't send ARP reply!",
+  dat_entry->mac_addr);
+   ret = true;
+   goto out;
+  

Re: [B.A.T.M.A.N.] [PATCH] batman-adv: ELP - use new ethtool_link_get_ksettings API

2016-03-14 Thread Andreas Pape
Hi everybody,

"B.A.T.M.A.N"  schrieb am
29.02.2016 03:23:42:

> Von: Marek Lindner 
> An: b.a.t.m.a.n@lists.open-mesh.org
> Kopie: Antonio Quartulli 
> Datum: 29.02.2016 03:24
> Betreff: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: ELP - use new
> ethtool_link_get_ksettings API
> Gesendet von: "B.A.T.M.A.N" 
>
> On Sunday, February 28, 2016 10:44:30 Sven Eckelmann wrote:
> > From: Antonio Quartulli 
> >
> > The ethtool API is changing in linux-4.6 and the B.A.T.M.A.N. V
> > code has to be changed accordingly.
> >
> > Fixes: 5c3245172c01 ("batman-adv: ELP - compute the metric based on
the
> > estimated throughput") Signed-off-by: Antonio Quartulli

> > [s...@narfation.org: Added compat code for
__ethtool_get_link_ksettings]
> > Signed-off-by: Sven Eckelmann 
> > ---
> > resend of "RFC v2" as patch with my Signed-off-by added
> >
> >  compat-include/linux/ethtool.h | 62
> > ++ net/batman-adv/bat_v_elp.c
  |
> > 12 
> >  2 files changed, 68 insertions(+), 6 deletions(-)
> >  create mode 100644 compat-include/linux/ethtool.h
>
> Applied in revision 3515604.
>
> Thanks,
> Marek

This patch breaks compatibility with older kernels (2.6.32 in my case ;-).

Is this intended? If I try to compile this I get

/compat-include/linux/ethtool.h:49: error: implicit declaration of
function '__ethtool_get_settings'

I stumbled across this when I tried to update and test my patches for dat
and bla due to the feedback I received after I updated the master branch.

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


[B.A.T.M.A.N.] Antwort: Re: [PATCHv2 1/7] batman-adv: prevent multiple ARP replies sent by gateways if dat enabled

2016-03-03 Thread Andreas Pape
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 

[B.A.T.M.A.N.] Antwort: Re: Antwort: Re: Antwort: Re: [PATCHv2 2/7] batman-adv: speed up dat by snooping received ip traffic

2016-03-02 Thread Andreas Pape
Sven Eckelmann  schrieb am 02.03.2016 11:23:21:


> > switch (ntohs(ethhdr->h_proto)) {
> > case ETH_P_IP:
> > if (unlikely(!pskb_may_pull(skb, sizeof(struct
iphdr
> > goto dropped;
> > iphdr = (struct iphdr *)(skb->data + ETH_HLEN);
> > /* snoop incoming traffic for dat update using the
source
> > mac
> >  * and source ip to speed up dat.
> >  */
> > batadv_dat_entry_check(bat_priv, iphdr->saddr,
> >ethhdr->h_source, vid);
>
> I doubt that you should drop the data. You new feature is just a nice
> enhancement but should not decide whether packet is valid or not. This
is why
> I told you about skb_header_pointer. Maybe it would also be better to
move
> your stuff in an extra function and avoid to add extra stuff in the
softif
> loop check. Maybe I will even move the softif loop check in an extra
function
> which would be named in a way that doesn't sound like you should add
your
> stuff there :)

Ooops.. Of course you are right about not dropping the packet here!
Further more
I will follow your suggestion to move this into a separate function to not
mix two different things.

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


[B.A.T.M.A.N.] Antwort: Re: Antwort: Re: [PATCHv2 2/7] batman-adv: speed up dat by snooping received ip traffic

2016-03-01 Thread Andreas Pape
Hello Sven,

Sven Eckelmann  schrieb am 01.03.2016 17:02:57:

> You definitely have to check the size for the IP header. The vlan
ethernet
> header check is a different playground and mostly unrelated to your
problem.
>

If I understood you correctly I am supposed to implement something like
this:

switch (ntohs(ethhdr->h_proto)) {
case ETH_P_IP:
if (unlikely(!pskb_may_pull(skb, sizeof(struct iphdr
goto dropped;
iphdr = (struct iphdr *)(skb->data + ETH_HLEN);
/* snoop incoming traffic for dat update using the source
mac
 * and source ip to speed up dat.
 */
batadv_dat_entry_check(bat_priv, iphdr->saddr,
   ethhdr->h_source, vid);
break;
case ETH_P_8021Q:
if (unlikely(!pskb_may_pull(skb, sizeof(struct
vlan_ethhdr
goto dropped;
vhdr = (struct vlan_ethhdr *)(skb->data + ETH_HLEN);

if (vhdr->h_vlan_encapsulated_proto != ethertype) {
/* snoop incoming traffic for dat update also for
vlan
 * tagged frames.
 */
if (ntohs(vhdr->h_vlan_encapsulated_proto) ==
ETH_P_IP) {
iphdr = (struct iphdr *)(vhdr + 1);
batadv_dat_entry_check(bat_priv,
iphdr->saddr,
   vhdr->h_source,
vid);
}
break;
}
Correctly understood?

Looking through the code of this function batadv_interface_rx leads me to
another
question: Am I right that skb->data is pointing to the beginning of the
mac
layer 2 header of the packet at that point in time as it isn't advanced to
the beginning of the layer 3 header by calling eth_type_trans yet(which is
called
a few lines later)?

> Btw. you can skip this check when you just use skb_header_pointer to
access
> the IPv4 header. It will return NULL when the data cannot be accessed.
It
> will also take care of copying data out of the fragments in your
temporary
> "buffer" when the bytes are not in the main buffer of the skb. You just
have
> to prepare a large enough buffer on the stack and only use the returned
> pointer.
>
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.
___


[B.A.T.M.A.N.] Antwort: Re: Antwort: Re: [Patchv2 0/7] batman-adv: Optimizations for setups running dat and bla

2016-03-01 Thread Andreas Pape
Hello Sven,

Sven Eckelmann  schrieb am 27.02.2016 12:40:46:

>
> Hopefully, Antonio+Simon will find some time next week to add some more
> feedback about the way their batman-adv subfeatures (DAT+BLA) are
affected by
> your patchset.
>

I will fix your findings in the next version of the patchset. But I think
I will
wait sending it until I get more feedback if the patches are a good idea
or if
they break something I have not understood so far. From my own tests I am
pretty
sure that the ideas behind patch 1/7, 4/7 and 7/7 bring a significant
improvement.

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


[B.A.T.M.A.N.] Antwort: Re: [PATCHv2 2/7] batman-adv: speed up dat by snooping received ip traffic

2016-03-01 Thread Andreas Pape
Hello Sven,


Sven Eckelmann  schrieb am 26.02.2016 17:00:49:

> Von: Sven Eckelmann 
> An: b.a.t.m.a.n@lists.open-mesh.org
> Kopie: Andreas Pape , Marek Lindner
> 
> Datum: 26.02.2016 17:00
> Betreff: Re: [B.A.T.M.A.N.] [PATCHv2 2/7] batman-adv: speed up dat
> by snooping received ip traffic
>
> On Friday 26 February 2016 14:18:17 Andreas Pape wrote:
> > Speeding up dat address lookup is achieved by snooping all incoming ip
> > traffic. This especially increases the propability in bla setups that
> > a gateway into a common backbone network already has a fitting dat
entry
> > to answer incoming ARP requests directly coming from the backbone
> > network thus further reducing ARP traffic in the mesh.
> >
> > Signed-off-by: Andreas Pape 
> > ---
> [...]
> > switch (ntohs(ethhdr->h_proto)) {
> > +   case ETH_P_IP:
> > +  iphdr = (struct iphdr *)(skb->data + ETH_HLEN);
> > +  /* snoop incoming traffic for dat update using the source mac
> > +   * and source ip to speed up dat.
> > +   */
> > +  batadv_dat_entry_check(bat_priv, iphdr->saddr,
> > +   ethhdr->h_source, vid);
> > +  break;
> > case ETH_P_8021Q:
> >vhdr = (struct vlan_ethhdr *)skb->data;
> >
> > -  if (vhdr->h_vlan_encapsulated_proto != ethertype)
> > +  if (vhdr->h_vlan_encapsulated_proto != ethertype) {
> > + /* snoop incoming traffic for dat update also for vlan
> > +  * tagged frames.
> > +  */
> > + if (vhdr->h_vlan_encapsulated_proto == ETH_P_IP) {
> > +iphdr = (struct iphdr *)(vhdr +
> > +  sizeof(struct vlan_ethhdr));
> > +batadv_dat_entry_check(bat_priv, iphdr->saddr,
> > + vhdr->h_source, vid);
> > + }
>
> Where is the code to check that there is enough data for the iphdr
> (pskb_may_pull)? Same question goes to Marek for his initial change in
> 48628bb9419f ("batman-adv: softif bridge loop avoidance") that
introduced the
> vhdr->vlan_ethhdr check
>

I will leave this to the result of the discussion in [1] which you started
and will not handle this in the next version of my patchset. Correct?

Kind regards,
Andreas

[1]
https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-February/014506.html


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


[B.A.T.M.A.N.] Antwort: Re: [Patchv2 0/7] batman-adv: Optimizations for setups running dat and bla

2016-02-27 Thread Andreas Pape
Hi Sven,

I just pressed the send button too early for my last mail ;-).

First of all I want to thank you for your valuable review. Please be
patient as this is my first attempt
to contribute to a linux project and I am still lacking some linux know
how.

Kind regards,
Andreas

Sven Eckelmann  schrieb am 26.02.2016 17:20:54:

> Von: Sven Eckelmann 
> An: b.a.t.m.a.n@lists.open-mesh.org
> Kopie: Andreas Pape 
> Datum: 26.02.2016 17:21
> Betreff: Re: [B.A.T.M.A.N.] [Patchv2 0/7] batman-adv: Optimizations
> for setups running dat and bla
>
> On Friday 26 February 2016 14:16:38 Andreas Pape wrote:
> > This patchset introduces optimizations for batman-adv in setups having
> > several gateways into a common (switched) Ethernet backbone network
> > especially if dat is additionally enabled.
> [...]
>
> See my other comments directly to the patches. Please try to set the
> in-reply-to of the patches to the message-id of the cover letter.
Otherwise
> the messages aren't correctly threaded on the mailinglist [1].
>
> And you can set the version number of the patch directly using
> git-format-patch:
>
> git format-patch -v 2 origin/master
>
> I haven't done the complete build_test run but at least a quick test
against
> 4.4 only. The result is attached.
>
> Kind regards,
>Sven
>
>
> [1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-February/
> thread.html
> [Anhang "build-test_andreas-pape_bla-fixes.mbox" gelöscht von
> Andreas Pape/Phoenix Contact] [Anhang "signature.asc" gelöscht von
> Andreas Pape/Phoenix Contact]


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


[B.A.T.M.A.N.] Antwort: Re: [Patchv2 0/7] batman-adv: Optimizations for setups running dat and bla

2016-02-27 Thread Andreas Pape
Sven Eckelmann  schrieb am 26.02.2016 17:20:54:

> See my other comments directly to the patches. Please try to set the
> in-reply-to of the patches to the message-id of the cover letter.
Otherwise
> the messages aren't correctly threaded on the mailinglist [1].
>

Is there a way to generate the cover letter also with git send-email? As I
did
not know how to generate it, I used claws as a separate e-mail client.

> And you can set the version number of the patch directly using
> git-format-patch:
>
> git format-patch -v 2 origin/master
>
> I haven't done the complete build_test run but at least a quick test
against
> 4.4 only. The result is attached.
>
> Kind regards,
>Sven
>

I used checkpatch.pl of linux 4.5 rc5 and checked each patch seperately
without open
issues. These things with bracket alignment etc. start driving me crazy.
Looks as if I don't
use a proper editor. Can you recommend one to use before sending patches?

>
> [1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2016-February/
> thread.html
> [Anhang "build-test_andreas-pape_bla-fixes.mbox" gelöscht von
> Andreas Pape/Phoenix Contact] [Anhang "signature.asc" gelöscht von
> Andreas Pape/Phoenix Contact]


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


[B.A.T.M.A.N.] [PATCHv2 7/7] batman-adv: handle race condition for claims between gateways

2016-02-26 Thread Andreas Pape
Consider the following situation which has been found in a test setup:
Gateway B has claimed client C and gateway A has the same backbone
network as B. C sends a broad- or multicast to B and directly after
this packet decides to send another packet to A due to a better TQ
value. B will forward the broad-/multicast into the backbone as it is
the responsible gw and after that A will claim C as it has been
chosen by C as the new gateway. If it now happens that A claims C
before it has received the broad-/multicast forwarded by B (due to
backbone topology or due to some delay in B when forwarding the
packet) we get a critical situation: in the current code A will
immediately unclaim C when receiving the multicast due to the
roaming client scenario although the position of C has not changed
in the mesh. If this happens the multi-/broadcast forwarded by B
will be sent back into the mesh by A and we have looping packets
until one of the gateways claims C again.
In order to prevent this, unclaiming of a client due to the roaming
client scenario is only done after a certain time is expired after
the last claim of the client. 100 ms are used here, which should be
slow enough for big backbones and slow gateways but fast enough not
to break the roaming client use case.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 32a6168..98f0dd9 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1764,10 +1764,22 @@ int batadv_bla_tx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* if yes, the client has roamed and we have
 * to unclaim it.
 */
-   batadv_handle_unclaim(bat_priv, primary_if,
- primary_if->net_dev->dev_addr,
- ethhdr->h_source, vid);
-   goto allow;
+   if (batadv_has_timed_out(claim->lasttime, 100)) {
+   /* only unclaim if the last claim entry is
+* older than 100 ms to make sure we really
+* have a roaming client here.
+*/
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming 
client %pM detected. Unclaim it.\n",
+  ethhdr->h_source);
+   batadv_handle_unclaim(bat_priv, primary_if,
+ primary_if->net_dev->dev_addr,
+ ethhdr->h_source, vid);
+   goto allow;
+   } else {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race 
for claim %pM detected. Drop packet.\n",
+  ethhdr->h_source);
+   goto handled;
+   }
}

/* check if it is a multicast/broadcast frame */
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCHv2 6/7] batman-adv: bugfix for dat optimiziation patch

2016-02-26 Thread Andreas Pape
Make sure that claiming of devices due to dat handling is only done
for non-local mac addresses. As dat is handled after the normal bla
code this does not break the roaming client scenario for bla.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   18 --
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 739f80f..32a6168 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1959,13 +1959,19 @@ bool batadv_bla_handle_local_claim(struct batadv_priv 
*bat_priv,
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);
+   /* If there is no claim, claim the device
+* but only if this isn't a mac address
+* out of the local tt
+*/
+   if (!batadv_is_my_client(bat_priv, addr, vid)) {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_handle_local_claim(): 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);
+   batadv_handle_claim(bat_priv, primary_if,
+   primary_if->net_dev->dev_addr,
+   addr, vid);
+   }
}

 out:
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCHv2 5/7] batman-adv: changed debug messages for easier bla debugging

2016-02-26 Thread Andreas Pape
Some of the bla debug messages are extended and additional messages are
added for easier bla debugging. Some debug messages introduced with the
dat changes in prior patches of this patch series have been changed to
be more compliant to other existing debug messages.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   22 --
 net/batman-adv/routing.c   |2 +-
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 07dba86..739f80f 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -675,8 +675,8 @@ static void batadv_bla_add_claim(struct batadv_priv 
*bat_priv,
goto claim_free_ref;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_add_claim(): changing ownership for %pM, vid 
%d\n",
-  mac, BATADV_PRINT_VID(vid));
+  "bla_add_claim(): changing ownership for %pM, vid %d 
to gw %pM\n",
+  mac, BATADV_PRINT_VID(vid), backbone_gw->orig);

spin_lock_bh(&claim->backbone_gw->crc_lock);
claim->backbone_gw->crc ^= crc16(0, claim->addr, ETH_ALEN);
@@ -1196,10 +1196,13 @@ static void batadv_bla_purge_claims(struct batadv_priv 
*bat_priv,
continue;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_purge_claims(): %pM, vid %d, time 
out\n",
+  "bla_purge_claims(): timed out.\n");
+
+purge_now:
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_purge_claims(): %pM, vid %d\n",
   claim->addr, claim->vid);

-purge_now:
batadv_handle_unclaim(bat_priv, primary_if,
  claim->backbone_gw->orig,
  claim->addr, claim->vid);
@@ -1647,9 +1650,16 @@ int batadv_bla_rx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* possible optimization: race for a claim */
/* No claim exists yet, claim it for us!
 */
+
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_rx(): Unclaimed MAC %pM found. Claim it. Local: 
%s\n",
+  ethhdr->h_source,
+  batadv_is_my_client(bat_priv,
+  ethhdr->h_source, vid) ?
+  "yes" : "no");
batadv_handle_claim(bat_priv, primary_if,
-   primary_if->net_dev->dev_addr,
-   ethhdr->h_source, vid);
+   primary_if->net_dev->dev_addr,
+   ethhdr->h_source, vid);
goto allow;
}

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 606fd22..5ac55e4 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -905,7 +905,7 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
orig_node = batadv_orig_hash_find(bat_priv, orig_addr);
if (batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) {
batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "Dropped unicast pkt received from another 
backbone gw %pM.\n",
+  "recv_unicast_packet(): Dropped unicast pkt 
received from another backbone gw %pM.\n",
   orig_addr);

return NET_RX_DROP;
--
1.7.0.4



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

[B.A.T.M.A.N.] [PATCHv2 2/7] batman-adv: speed up dat by snooping received ip traffic

2016-02-26 Thread Andreas Pape
Speeding up dat address lookup is achieved by snooping all incoming ip
traffic. This especially increases the propability in bla setups that
a gateway into a common backbone network already has a fitting dat entry
to answer incoming ARP requests directly coming from the backbone
network thus further reducing ARP traffic in the mesh.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   18 ++
 net/batman-adv/distributed-arp-table.h |9 -
 net/batman-adv/soft-interface.c|   22 +-
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index a9152e7..0f899b9 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -362,6 +362,24 @@ out:
batadv_dat_entry_put(dat_entry);
 }

+/**
+ * batadv_dat_entry_check - check and update a dat entry
+ * @bat_priv: the bat priv with all the soft interface information
+ * @ip: ipv4 to add/edit
+ * @mac_addr: mac address to assign to the given ipv4
+ * @vid: VLAN identifier
+ *
+ * checks additionally, if dat is enabled. can be called from other modules.
+ */
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip,
+   u8 *mac_addr, unsigned short vid)
+{
+   if (!atomic_read(&bat_priv->distributed_arp_table))
+   return;
+
+   batadv_dat_entry_add(bat_priv, ip, mac_addr, vid);
+}
+
 #ifdef CONFIG_BATMAN_ADV_DEBUG

 /**
diff --git a/net/batman-adv/distributed-arp-table.h 
b/net/batman-adv/distributed-arp-table.h
index 813ecea..e1b4848 100644
--- a/net/batman-adv/distributed-arp-table.h
+++ b/net/batman-adv/distributed-arp-table.h
@@ -80,7 +80,8 @@ batadv_dat_init_own_addr(struct batadv_priv *bat_priv,
 int batadv_dat_init(struct batadv_priv *bat_priv);
 void batadv_dat_free(struct batadv_priv *bat_priv);
 int batadv_dat_cache_seq_print_text(struct seq_file *seq, void *offset);
-
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip,
+   u8 *mac_addr, unsigned short vid);
 /**
  * batadv_dat_inc_counter - increment the correct DAT packet counter
  * @bat_priv: the bat priv with all the soft interface information
@@ -173,6 +174,12 @@ static inline void batadv_dat_inc_counter(struct 
batadv_priv *bat_priv,
 {
 }

+static inline
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip,
+   u8 *mac_addr, unsigned short vid)
+{
+}
+
 #endif /* CONFIG_BATMAN_ADV_DAT */

 #endif /* _NET_BATMAN_ADV_DISTRIBUTED_ARP_TABLE_H_ */
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 0710379..f031781 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -390,6 +391,7 @@ void batadv_interface_rx(struct net_device *soft_iface,
__be16 ethertype = htons(ETH_P_BATMAN);
struct vlan_ethhdr *vhdr;
struct ethhdr *ethhdr;
+   struct iphdr *iphdr;
unsigned short vid;
bool is_bcast;

@@ -412,11 +414,29 @@ void batadv_interface_rx(struct net_device *soft_iface,
ethhdr = eth_hdr(skb);

switch (ntohs(ethhdr->h_proto)) {
+   case ETH_P_IP:
+   iphdr = (struct iphdr *)(skb->data + ETH_HLEN);
+   /* snoop incoming traffic for dat update using the source mac
+* and source ip to speed up dat.
+*/
+   batadv_dat_entry_check(bat_priv, iphdr->saddr,
+  ethhdr->h_source, vid);
+   break;
case ETH_P_8021Q:
vhdr = (struct vlan_ethhdr *)skb->data;

-   if (vhdr->h_vlan_encapsulated_proto != ethertype)
+   if (vhdr->h_vlan_encapsulated_proto != ethertype) {
+   /* snoop incoming traffic for dat update also for vlan
+* tagged frames.
+*/
+   if (vhdr->h_vlan_encapsulated_proto == ETH_P_IP) {
+   iphdr = (struct iphdr *)(vhdr +
+   sizeof(struct vlan_ethhdr));
+   batadv_dat_entry_check(bat_priv, iphdr->saddr,
+  vhdr->h_source, vid);
+   }
break;
+   }

/* fall through */
case ETH_P_BATMAN:
--
1.7.0.4



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

[B.A.T.M.A.N.] [PATCHv2 4/7] batman-adv: drop unicast packets from other backbone gw

2016-02-26 Thread Andreas Pape
Additional dropping of unicast packets received from another backbone gw of
the same backbone network before being forwarded to the same backbone again
is necessary. It was observed in a test setup that in rare cases these
frames lead to looping unicast traffic backbone->mesh->backbone.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/routing.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 4dd646a..606fd22 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -854,9 +854,11 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
int check, hdr_size = sizeof(*unicast_packet);
enum batadv_subtype subtype;
bool is4addr;
+   struct ethhdr *ethhdr;

unicast_packet = (struct batadv_unicast_packet *)skb->data;
unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data;
+   ethhdr = eth_hdr(skb);

is4addr = unicast_packet->packet_type == BATADV_UNICAST_4ADDR;
/* the caller function should have already pulled 2 bytes */
@@ -896,6 +898,19 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
}
}

+   /* If this is a unicast packet from another backgone gw,
+* drop it.
+*/
+   orig_addr = ethhdr->h_source;
+   orig_node = batadv_orig_hash_find(bat_priv, orig_addr);
+   if (batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "Dropped unicast pkt received from another 
backbone gw %pM.\n",
+  orig_addr);
+
+   return NET_RX_DROP;
+   }
+
if (batadv_dat_snoop_incoming_arp_request(bat_priv, skb,
  hdr_size))
goto rx_success;
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCHv2 3/7] batman-adv: prevent duplication of ARP replies when DAT is used

2016-02-26 Thread Andreas Pape
If none of the backbone gateways in a bla setup has already knowledge of
the mac address searched for in an incoming ARP request from the backbone
it must be prevented that multiple ARP replies are generated and returned
to the backbone by the dat address resolution mechanism of other dat
enabled nodes of the mesh.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   65 +++-
 1 files changed, 64 insertions(+), 1 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index 0f899b9..f60fccb 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -1081,6 +1081,8 @@ bool batadv_dat_snoop_incoming_arp_request(struct 
batadv_priv *bat_priv,
u8 *hw_src;
struct sk_buff *skb_new;
struct batadv_dat_entry *dat_entry = NULL;
+   struct batadv_unicast_4addr_packet *unicast_4addr_packet;
+   struct batadv_orig_node *orig_node = NULL;
bool ret = false;
unsigned short vid;
int err;
@@ -1104,8 +1106,38 @@ bool batadv_dat_snoop_incoming_arp_request(struct 
batadv_priv *bat_priv,
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);

dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_dst, vid);
-   if (!dat_entry)
+   if (!dat_entry) {
+   /* Check if this is a 4addr unicast DAT_DHT_GET frame from
+* another backbone gw of the same backbone. If yes, drop
+* it as this leads to multiplication of arp requests in bla
+* setups as long as there is no dat_entry fo this answer.
+* In this case better drop the DHT_GET. Normal bla code
+* doesn't take care of these packets as they are tunneled
+* via unicast.
+*/
+   unicast_4addr_packet =
+   (struct batadv_unicast_4addr_packet *)skb->data;
+   orig_node =
+   batadv_orig_hash_find(bat_priv,
+ unicast_4addr_packet->src);
+   if (orig_node) {
+   if ((unicast_4addr_packet->u.packet_type ==
+BATADV_UNICAST_4ADDR) &&
+(unicast_4addr_packet->subtype ==
+ BATADV_P_DAT_DHT_GET) &&
+(batadv_bla_is_backbone_gw(skb, orig_node,
+   hdr_size))) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled 
ARP request removed: ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4]; originator: 
%pM\n",
+  hw_src, &ip_src,
+  batadv_arp_hw_dst(skb, hdr_size),
+  &ip_dst, unicast_4addr_packet->src);
+   ret = true;
+   }
+   batadv_orig_node_put(orig_node);
+   }
+
goto out;
+   }

skb_new = arp_create(ARPOP_REPLY, ETH_P_ARP, ip_src,
 bat_priv->soft_iface, ip_dst, hw_src,
@@ -1204,6 +1236,7 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
__be32 ip_src, ip_dst;
u8 *hw_src, *hw_dst;
bool dropped = false;
+   struct batadv_dat_entry *dat_entry = NULL;
unsigned short vid;

if (!atomic_read(&bat_priv->distributed_arp_table))
@@ -1223,12 +1256,40 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
hw_dst = batadv_arp_hw_dst(skb, hdr_size);
ip_dst = batadv_arp_ip_dst(skb, hdr_size);

+   /* If ip_dst is already in cache and has the right mac address,
+* drop this frame if this ARP reply is destined for us. We have
+* most probably received already a reply from someone else. Delivering
+* this frame would lead to doubled receive of an ARP reply.
+*/
+   dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_src, vid);
+   if ((dat_entry) && (batadv_compare_eth(hw_src, dat_entry->mac_addr))) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled ARP reply 
removed: ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4]; dat_entry: %pM-%pI4\n",
+  hw_src, &ip_src, hw_dst, &ip_dst,
+  dat_entry->mac_addr, &dat_entry->ip);
+   dropped = true;
+   goto out;
+   }
+
/* Update our internal cache with both the IP addresses the node got
 * within the ARP reply
 */
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);
batadv_dat_entry_add(bat_priv, ip_dst, hw_dst, vid);

+   /* If BLA is enabled, only forward ARP replies if we have claim

[B.A.T.M.A.N.] [PATCHv2 1/7] batman-adv: prevent multiple ARP replies sent by gateways if dat enabled

2016-02-26 Thread Andreas Pape
If dat is enabled it must be made sure that only the backbone gw which has
claimed the remote destination for the ARP request answers the ARP request
directly if the MAC address is known due to the local dat table. This
prevents multiple ARP replies in a common backbone if more than one
gateway already knows the remote mac searched for in the ARP request.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   59 
 net/batman-adv/bridge_loop_avoidance.h |9 +
 net/batman-adv/distributed-arp-table.c |   15 
 3 files changed, 83 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 0a6c8b8..07dba86 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1906,3 +1906,62 @@ out:
batadv_hardif_put(primary_if);
return 0;
 }
+
+/**
+ * batadv_bla_handle_local_claim - check if address is claimed and claim it
+ *  if it isn't
+ * @bat_priv: the bat priv with all the soft interface information
+ * @addr: mac address of which the claim status is checked
+ * @vid: the VLAN ID
+ *
+ * addr is checked if this address is claimed by the local device itself.
+ * If the address is not claimed at all, claim it.
+ *
+ * Return: true if bla is disabled or the mac is claimed by the device,
+ * false if the device addr is already claimed by another gateway
+ */
+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;
+
+   /* 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;
+*/
+   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);
+   }
+
+out:
+   if (claim)
+   batadv_claim_put(claim);
+   if (primary_if)
+   batadv_hardif_put(primary_if);
+   return ret;
+}
diff --git a/net/batman-adv/bridge_loop_avoidance.h 
b/net/batman-adv/bridge_loop_avoidance.h
index 579f0fa..ddf6b9d 100644
--- a/net/batman-adv/bridge_loop_avoidance.h
+++ b/net/batman-adv/bridge_loop_avoidance.h
@@ -46,6 +46,8 @@ void batadv_bla_update_orig_address(struct batadv_priv 
*bat_priv,
 void batadv_bla_status_update(struct net_device *net_dev);
 int batadv_bla_init(struct batadv_priv *bat_priv);
 void batadv_bla_free(struct batadv_priv *bat_priv);
+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr,
+  unsigned short vid);

 #define BATADV_BLA_CRC_INIT0
 #else /* ifdef CONFIG_BATMAN_ADV_BLA */
@@ -111,6 +113,13 @@ static inline void batadv_bla_free(struct batadv_priv 
*bat_priv)
 {
 }

+static inline
+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr,
+  unsigned short vid)
+{
+   return true;
+}
+
 #endif /* ifdef CONFIG_BATMAN_ADV_BLA */

 #endif /* ifndef _NET_BATMAN_ADV_BLA_H_ */
diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index e96d7c7..a9152e7 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -48,6 +48,7 @@
 #include "originator.h"
 #include "send.h"
 #include "translation-table.h"
+#include "bridge_loop_avoidance.h"

 static void batadv_dat_purge(struct work_struct *work);

@@ -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
+* destinat

[B.A.T.M.A.N.] [Patchv2 0/7] batman-adv: Optimizations for setups running dat and bla

2016-02-26 Thread Andreas Pape
This patchset introduces optimizations for batman-adv in setups having several 
gateways into a common (switched) Ethernet backbone network especially if dat 
is additionally enabled.

Using the current implementation with bla and dat enabled, several problems can 
be observed in a real setup:
1. Multiplication of ARP replies from dat enabled gateways and dat enabled mesh 
nodes leading to an "ARP reply storm" in the common backbone network.
2. In rare corner cases bla does not fully prevent looping of unicast frames in 
the direction backbone --> mesh --> backbone and looping of multicast frames in 
the direction mesh --> backbone --> mesh.
The latter can lead to temporary confusion in the switched backbone resulting 
in packet loss and communication timeouts.

The observed problems are solved by introduction of additional rules for the 
dat handling, bla packet forwarding and bla claiming/unclaiming of clients.


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


[B.A.T.M.A.N.] Antwort: Re: [PATCH 1/7] batman-adv: prevent multiple ARP replies sent by gateways if dat enabled

2016-02-25 Thread Andreas Pape
Hello Sven,

Sven Eckelmann  schrieb am 25.02.2016 11:30:01:


> I will answer to the first patch only because this patchset doesn't have
a
> cover letter. But it is about the whole patchset.
>
> First thing: Good that you could convince the IT department that you
have to
> use git-send-email as alternative mailer.
>
> I have not checked the actual content of the patchset ("This patch
makes" in
> the commit messages looks odd) but just started the build_test [1] on
your
> patchset. It looks like your patchset doesn't build in some
configurations.
> See the attached mail for more details.
>

I wasn't aware that there is something like the build_test to be used
before
sending patches But I'm willing to learn.

Is there a documentation available how I can use this myself for testing
before
making another attempt to send the patches (including a cover letter)?

In my buildenvironment using an older kernel I have no issues. But of
course
I did not test every possible configuration

> And the test run without your patches looked good [2].
>
> Kind regards,
>Sven
>
> [1] https://git.open-mesh.org/build_test.git
> [2] https://lists.open-mesh.org/pipermail/linux-merge/2016-February/
> 002983.html
> [Anhang "build-test_andreas-pape_bla-fixes.mbox" gelöscht von
> Andreas Pape/Phoenix Contact] [Anhang "signature.asc" gelöscht von
> Andreas Pape/Phoenix Contact]


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


[B.A.T.M.A.N.] [PATCH 7/7] batman-adv: handle race condition for claims between gateways

2016-02-24 Thread Andreas Pape
This patch is crucial for prevention of looping broadcast or multicast
packets in a bla setup. Consider the following situation: Gateway B
has claimed client C and gateway A has the same backbone network as B.
C sends a broad- or multicast to B and directly after this packet
decides to send another packet to A due to a better TQ value. B will
forward the multicast into the backbone as it is the responsible gw
and A will claim C as it has been chosen by C as the best gateway.
If it now happens that A claims C before it has received the multicast
forwarded by B (due to backbone topology or some delay in B) we get
a critical situation: in the current code A will immediately unclaim
C if the multicast is received due to the roaming client scenario
although the position of C has not changed in the mesh. If this
happens the broadcast will be sent back into the mesh and we have a
loop until one of the gateways claims C again.
In order to prevent this, unclaiming of a client due to the roaming
client scenario is only done after a certain time is expired after
the last claim of the client. 100 ms are used here, which should be
slow enough for big backbones and slow gateways but fast enough not
to break the roaming client use case.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   20 
 1 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 6311ca2..7afddd9 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1761,10 +1761,22 @@ int batadv_bla_tx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* if yes, the client has roamed and we have
 * to unclaim it.
 */
-   batadv_handle_unclaim(bat_priv, primary_if,
- primary_if->net_dev->dev_addr,
- ethhdr->h_source, vid);
-   goto allow;
+   if (batadv_has_timed_out(claim->lasttime, 100)) {
+   /* only unclaim if the last claim entry is
+* older than 100 ms to make sure we really
+* have a roaming client here.
+*/
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Roaming 
client %pM detected. Unclaim it.\n",
+  ethhdr->h_source);
+   batadv_handle_unclaim(bat_priv, primary_if,
+ primary_if->net_dev->dev_addr,
+ ethhdr->h_source, vid);
+   goto allow;
+   } else {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_tx(): Race 
for claim %pM detected. Drop packet.\n",
+  ethhdr->h_source);
+   goto handled;
+   }
}

/* check if it is a multicast/broadcast frame */
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH 6/7] batman-adv: bugfix for dat optimization patch

2016-02-24 Thread Andreas Pape
Make sure that claiming of devices due to dat handling is only done
for non-local mac addresses. As dat is handled after the normal bla
code this should not break the roaming client scenario for dat.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   18 --
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 9e53fba..6311ca2 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1956,13 +1956,19 @@ bool batadv_bla_handle_local_claim(struct batadv_priv 
*bat_priv, uint8_t *addr,
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);
+   /* If there is no claim, claim the device
+* but only if this isn't a mac address
+* out of the local tt
+*/
+   if (!batadv_is_my_client(bat_priv, addr, vid)) {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+  "bla_handle_local_claim(): 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);
+   batadv_handle_claim(bat_priv, primary_if,
+   primary_if->net_dev->dev_addr, addr, 
vid);
+   }
}

 out:
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH 4/7] batman-adv: drop unicast packets from backbone gw

2016-02-24 Thread Andreas Pape
This patch drops unicast packets received from another backbone gw of
the same backbone network before they are forwarded to the common
backbone again. It was observed in a test setup that in rare cases
these frames lead to looping unicast traffic backbone->mesh->backbone.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/routing.c |   15 +++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 4dd646a..992b6cc 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -854,9 +854,11 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
int check, hdr_size = sizeof(*unicast_packet);
enum batadv_subtype subtype;
bool is4addr;
+   struct ethhdr *ethhdr;

unicast_packet = (struct batadv_unicast_packet *)skb->data;
unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data;
+   ethhdr = eth_hdr(skb);

is4addr = unicast_packet->packet_type == BATADV_UNICAST_4ADDR;
/* the caller function should have already pulled 2 bytes */
@@ -896,6 +898,19 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
}
}

+   /* If this is a unicast packet from another backgone gw,
+* drop it.
+*/
+   orig_addr = ethhdr->h_source;
+   orig_node = batadv_orig_hash_find(bat_priv, orig_addr);
+   if (batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) {
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+   "Dropped unicast pkt received from another 
backbone gw %pM.\n",
+   orig_addr);
+
+   return NET_RX_DROP;
+   }
+
if (batadv_dat_snoop_incoming_arp_request(bat_priv, skb,
  hdr_size))
goto rx_success;
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH 5/7] batman-adv: changed debug messages for easier bla debugging

2016-02-24 Thread Andreas Pape
Some of the bla debug messages are changed and additional messages are
added for easier bla debugging. Some debug messages introduced with
the dat changes in prior patches have been changed to be more compliant
to other existing debug messages.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   19 +--
 net/batman-adv/routing.c   |3 ++-
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 6c29ec2..9e53fba 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -675,8 +675,8 @@ static void batadv_bla_add_claim(struct batadv_priv 
*bat_priv,
goto claim_free_ref;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_add_claim(): changing ownership for %pM, vid 
%d\n",
-  mac, BATADV_PRINT_VID(vid));
+  "bla_add_claim(): changing ownership for %pM, vid %d 
to gw %pM\n",
+  mac, BATADV_PRINT_VID(vid), backbone_gw->orig);

spin_lock_bh(&claim->backbone_gw->crc_lock);
claim->backbone_gw->crc ^= crc16(0, claim->addr, ETH_ALEN);
@@ -1196,10 +1196,13 @@ static void batadv_bla_purge_claims(struct batadv_priv 
*bat_priv,
continue;

batadv_dbg(BATADV_DBG_BLA, bat_priv,
-  "bla_purge_claims(): %pM, vid %d, time 
out\n",
-  claim->addr, claim->vid);
+   "bla_purge_claims(): timed out.\n");

 purge_now:
+   batadv_dbg(BATADV_DBG_BLA, bat_priv,
+   "bla_purge_claims(): %pM, vid %d\n",
+   claim->addr, claim->vid);
+
batadv_handle_unclaim(bat_priv, primary_if,
  claim->backbone_gw->orig,
  claim->addr, claim->vid);
@@ -1647,9 +1650,13 @@ int batadv_bla_rx(struct batadv_priv *bat_priv, struct 
sk_buff *skb,
/* possible optimization: race for a claim */
/* No claim exists yet, claim it for us!
 */
+
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "bla_rx(): Unclaimed MAC 
%pM found. "
+   "Claim it. Local: %s\n",
+   ethhdr->h_source, batadv_is_my_client(bat_priv, 
ethhdr->h_source, vid) ? "yes" : "no");
batadv_handle_claim(bat_priv, primary_if,
-   primary_if->net_dev->dev_addr,
-   ethhdr->h_source, vid);
+   primary_if->net_dev->dev_addr,
+   ethhdr->h_source, vid);
goto allow;
}

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 992b6cc..64b2e16 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -905,7 +905,8 @@ int batadv_recv_unicast_packet(struct sk_buff *skb,
orig_node = batadv_orig_hash_find(bat_priv, orig_addr);
if (batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) {
batadv_dbg(BATADV_DBG_BLA, bat_priv,
-   "Dropped unicast pkt received from another 
backbone gw %pM.\n",
+   "recv_unicast_packet(): Dropped unicast pkt 
received "
+   "from another backbone gw %pM.\n",
orig_addr);

return NET_RX_DROP;
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH 3/7] batman-adv: prevent duplication of ARP replies when DAT is used

2016-02-24 Thread Andreas Pape
This patch covers the case of a bla setup with enabled dat if none of the
common gateways of the same backbone has already knowledge of the searched
ip address and therefore has to ask via dat some of the other mesh nodes.
A broadcast arp request is coming from the backbone and each backbone
gateway starts an address resolution via other dat mesh nodes. In this
case it should be prevented that multiple answers from dat enabled mesh
nodes reach the backbone gateways leading to multiple replies in a common
backbone again.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   63 +++-
 1 files changed, 62 insertions(+), 1 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index fe46a3d..53149e2 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -1081,6 +1081,8 @@ bool batadv_dat_snoop_incoming_arp_request(struct 
batadv_priv *bat_priv,
u8 *hw_src;
struct sk_buff *skb_new;
struct batadv_dat_entry *dat_entry = NULL;
+   struct batadv_unicast_4addr_packet *unicast_4addr_packet;
+   struct batadv_orig_node *orig_node = NULL;
bool ret = false;
unsigned short vid;
int err;
@@ -1104,8 +1106,35 @@ bool batadv_dat_snoop_incoming_arp_request(struct 
batadv_priv *bat_priv,
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);

dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_dst, vid);
-   if (!dat_entry)
+   if (!dat_entry) {
+   /* Check if this is a 4addr unicast DAT_DHT_GET frame from
+* another backbone gw of the same backbone. If yes, drop
+* it as this leads to multiplication of arp requests in bla
+* setups as long as there is no dat_entry fo this answer.
+* In this case better drop the DHT_GET. Normal bla code
+* doesn't take care of these packets as they are tunneled
+* via unicast.
+*/
+   unicast_4addr_packet =
+   (struct batadv_unicast_4addr_packet *)skb->data;
+   orig_node =
+   batadv_orig_hash_find(bat_priv, 
unicast_4addr_packet->src);
+   if (orig_node) {
+   if ((unicast_4addr_packet->u.packet_type == 
BATADV_UNICAST_4ADDR) &&
+   (unicast_4addr_packet->subtype == 
BATADV_P_DAT_DHT_GET) &&
+   (batadv_bla_is_backbone_gw(skb, orig_node, 
hdr_size))) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled 
ARP request removed: "
+   "ARP MSG = [src: %pM-%pI4 dst: 
%pM-%pI4]; originator: %pM\n",
+   hw_src, &ip_src,
+   batadv_arp_hw_dst(skb, hdr_size), 
&ip_dst,
+   unicast_4addr_packet->src);
+   ret = true;
+   }
+   batadv_orig_node_put(orig_node);
+   }
+
goto out;
+   }

skb_new = arp_create(ARPOP_REPLY, ETH_P_ARP, ip_src,
 bat_priv->soft_iface, ip_dst, hw_src,
@@ -1204,6 +1233,7 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
__be32 ip_src, ip_dst;
u8 *hw_src, *hw_dst;
bool dropped = false;
+   struct batadv_dat_entry *dat_entry = NULL;
unsigned short vid;

if (!atomic_read(&bat_priv->distributed_arp_table))
@@ -1223,12 +1253,41 @@ bool batadv_dat_snoop_incoming_arp_reply(struct 
batadv_priv *bat_priv,
hw_dst = batadv_arp_hw_dst(skb, hdr_size);
ip_dst = batadv_arp_ip_dst(skb, hdr_size);

+   /* If ip_dst is already in cache and has the right mac address,
+* drop this frame if this ARP reply is destined for us. We have
+* most probably received already a reply from someone else. Delivering
+* this frame would lead to doubled receive of an ARP reply.
+*/
+   dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_src, vid);
+   if ((dat_entry) && (batadv_compare_eth(hw_src, dat_entry->mac_addr))) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled ARP reply 
removed: "
+   "ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4]; dat_entry: 
%pM-%pI4\n",
+   hw_src, &ip_src, hw_dst, &ip_dst, dat_entry->mac_addr,
+   &dat_entry->ip);
+   dropped = true;
+   goto out;
+   }
+
/* Update our internal cache with both the IP addresses the node got
 * within the ARP reply
 */
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);

[B.A.T.M.A.N.] [PATCH 2/7] batman-adv: speed up dat by snooping received ip traffic

2016-02-24 Thread Andreas Pape
This patch speeds up dat by snooping all incoming ip traffic instead
of only relying on ARP handling. This increases especially the
propability that a gateway into a backbone network already has a fitting
dat entry to answer incoming ARP requests directly coming from the
backbone network.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   18 ++
 net/batman-adv/distributed-arp-table.h |8 +++-
 net/batman-adv/soft-interface.c|   22 +-
 3 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index aab9548..fe46a3d 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -362,6 +362,24 @@ out:
batadv_dat_entry_put(dat_entry);
 }

+/**
+ * batadv_dat_entry_check - check and update a dat entry
+ * @bat_priv: the bat priv with all the soft interface information
+ * @ip: ipv4 to add/edit
+ * @mac_addr: mac address to assign to the given ipv4
+ * @vid: VLAN identifier
+ *
+ * checks additionally, if dat is enabled. can be called from other modules.
+ */
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip,
+u8 *mac_addr, unsigned short vid)
+{
+   if (!atomic_read(&bat_priv->distributed_arp_table))
+   return;
+
+   batadv_dat_entry_add(bat_priv, ip, mac_addr, vid);
+}
+
 #ifdef CONFIG_BATMAN_ADV_DEBUG

 /**
diff --git a/net/batman-adv/distributed-arp-table.h 
b/net/batman-adv/distributed-arp-table.h
index 813ecea..a2ab16b 100644
--- a/net/batman-adv/distributed-arp-table.h
+++ b/net/batman-adv/distributed-arp-table.h
@@ -80,7 +80,8 @@ batadv_dat_init_own_addr(struct batadv_priv *bat_priv,
 int batadv_dat_init(struct batadv_priv *bat_priv);
 void batadv_dat_free(struct batadv_priv *bat_priv);
 int batadv_dat_cache_seq_print_text(struct seq_file *seq, void *offset);
-
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip,
+u8 *mac_addr, unsigned short vid);
 /**
  * batadv_dat_inc_counter - increment the correct DAT packet counter
  * @bat_priv: the bat priv with all the soft interface information
@@ -173,6 +174,11 @@ static inline void batadv_dat_inc_counter(struct 
batadv_priv *bat_priv,
 {
 }

+void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip,
+u8 *mac_addr, unsigned short vid)
+{
+}
+
 #endif /* CONFIG_BATMAN_ADV_DAT */

 #endif /* _NET_BATMAN_ADV_DISTRIBUTED_ARP_TABLE_H_ */
diff --git a/net/batman-adv/soft-interface.c b/net/batman-adv/soft-interface.c
index 0710379..affd370 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -390,6 +391,7 @@ void batadv_interface_rx(struct net_device *soft_iface,
__be16 ethertype = htons(ETH_P_BATMAN);
struct vlan_ethhdr *vhdr;
struct ethhdr *ethhdr;
+   struct iphdr *iphdr;
unsigned short vid;
bool is_bcast;

@@ -412,11 +414,29 @@ void batadv_interface_rx(struct net_device *soft_iface,
ethhdr = eth_hdr(skb);

switch (ntohs(ethhdr->h_proto)) {
+   case ETH_P_IP:
+   iphdr = (struct iphdr *)(skb->data + ETH_HLEN);
+   /* snoop incoming traffic for dat update using the source mac
+* and source ip to speed up dat.
+*/
+   batadv_dat_entry_check(bat_priv, iphdr->saddr, ethhdr->h_source,
+   vid);
+   break;
case ETH_P_8021Q:
vhdr = (struct vlan_ethhdr *)skb->data;

-   if (vhdr->h_vlan_encapsulated_proto != ethertype)
+   if (vhdr->h_vlan_encapsulated_proto != ethertype) {
+   /* snoop incoming traffic for dat update also for vlan
+* tagged frames.
+*/
+   if (vhdr->h_vlan_encapsulated_proto == ETH_P_IP) {
+   iphdr = (struct iphdr *)(vhdr +
+   sizeof(struct vlan_ethhdr));
+   batadv_dat_entry_check(bat_priv, iphdr->saddr,
+   vhdr->h_source, vid);
+   }
break;
+   }

/* fall through */
case ETH_P_BATMAN:
--
1.7.0.4



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

[B.A.T.M.A.N.] [PATCH 1/7] batman-adv: prevent multiple ARP replies sent by gateways if dat enabled

2016-02-24 Thread Andreas Pape
This patch makes sure that only the backbone gw which has claimed the
remote destination for the ARP request answers the ARP request directly
if the MAC address is known due to the local DAT table. This prevents
multiple ARP replies in a common backbone if more than one gateway
already knows the remote mac searched for in the ARP request.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   59 
 net/batman-adv/bridge_loop_avoidance.h |8 
 net/batman-adv/distributed-arp-table.c |   15 
 3 files changed, 82 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c 
b/net/batman-adv/bridge_loop_avoidance.c
index 0a6c8b8..6c29ec2 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1906,3 +1906,62 @@ out:
batadv_hardif_put(primary_if);
return 0;
 }
+
+/**
+ * batadv_bla_handle_local_claim
+ * @bat_priv: the bat priv with all the soft interface information
+ * @addr: mac address of which the claim status is checked
+ * @vid: the VLAN ID
+ *
+ * addr is checked if this address is claimed by the local device itself.
+ * If the address is not claimed at all, claim it.
+ *
+ * Return: true if bla is disabled or the mac is claimed by the device,
+ * false if the device addr is already claimed by another gateway
+ */
+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, uint8_t *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;
+
+   /* 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;
+*/
+   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);
+   }
+
+out:
+   if (claim)
+   batadv_claim_put(claim);
+   if (primary_if)
+   batadv_hardif_put(primary_if);
+   return ret;
+}
diff --git a/net/batman-adv/bridge_loop_avoidance.h 
b/net/batman-adv/bridge_loop_avoidance.h
index 579f0fa..c6d498b 100644
--- a/net/batman-adv/bridge_loop_avoidance.h
+++ b/net/batman-adv/bridge_loop_avoidance.h
@@ -46,6 +46,8 @@ void batadv_bla_update_orig_address(struct batadv_priv 
*bat_priv,
 void batadv_bla_status_update(struct net_device *net_dev);
 int batadv_bla_init(struct batadv_priv *bat_priv);
 void batadv_bla_free(struct batadv_priv *bat_priv);
+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr,
+   unsigned short vid);

 #define BATADV_BLA_CRC_INIT0
 #else /* ifdef CONFIG_BATMAN_ADV_BLA */
@@ -111,6 +113,12 @@ static inline void batadv_bla_free(struct batadv_priv 
*bat_priv)
 {
 }

+bool batadv_bla_handle_local_claim(struct batadv_priv *bat_priv, u8 *addr,
+   unsigned short vid)
+{
+   return true;
+}
+
 #endif /* ifdef CONFIG_BATMAN_ADV_BLA */

 #endif /* ifndef _NET_BATMAN_ADV_BLA_H_ */
diff --git a/net/batman-adv/distributed-arp-table.c 
b/net/batman-adv/distributed-arp-table.c
index e96d7c7..aab9548 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -48,6 +48,7 @@
 #include "originator.h"
 #include "send.h"
 #include "translation-table.h"
+#include "bridge_loop_avoidance.h"

 static void batadv_dat_purge(struct work_struct *work);

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

[B.A.T.M.A.N.] Antwort: Re: Still looping packets in bla setup

2016-02-21 Thread Andreas Pape
 stuff and sometimes some ARPs. I use normal IPv4
communication
to the webinterfaces of my nodes and some normal pings (a packet a
second).
The nodes itself have IPv6 enabled although I don't use IPv6 but only IPv4
addressing.
The multicasts in question are for destination mac 33:33:00:00:00:01
(IPv6) and are
sent each 10 seconds by the IPv6 Linux stack.

> What might help is to get dumps from the hard interface as well as the
bat0
> soft interface and check the corresponding packets when this
problemhappens.
> Not sure if this helps and how easy it is to capture dumps ...
>
> Cheers,
>  Simon[Anhang "signature.asc" gelöscht von Andreas Pape/Phoenix
Contact]


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


[B.A.T.M.A.N.] Still looping packets in bla setup

2016-02-19 Thread Andreas Pape
Hello Simon,

I'm still working with my IT department to be able to send the patches in
a way compliant to the documentation provided by Sven. In the meantime I
reworked the patches, but I am still struggling with the e-mail client
issue.
Nevertheless if I apply all the patches I sent earlier (except Patch 4/4
as it was meaningless) I still have 3 problems :
1. I have sometimes looping unicast packets in the direction backbone ->
mesh -> backbone. Dropping all unicast traffic received from another
backbone gw and destined to be forwarded to the backbone again as you
suggested this in an earlier mail solves this issue. Shall I provide an
according patch? Shall I add a "Suggested-by" referring to you? I feel a
little bit uncomforable with this patch as it seems to be something more
like a workaround. The question I cannot answer yet is why the other
backbone gws send traffic via the mesh which could be sent via the
backbone?
2. Although having the patch for 1. applied, the backbone gateways send
claim frames for the devices of their own backbone in rare cases from time
to time. I could send a patch for this as it is rather easy to check with
the help of the local tt table (batadv_is_my_client) if it is reasonable
to send a claim frame for these devices. Again, this patch looks more like
a workaround to me as I also cannot explain what really triggers the
generation of these claim frames.
3. I see again in rare cases looping multicasts for traffic
mesh->backbone->mesh. If I look at the bla debug messages in these cases I
see, that a backbone gw holding the claim for the source of the multicast
frame thinks that the client belonging to the source address has "roamed"
from another mesh node into the backbone network although it didn't. From
this I conclude that another backbone gw has forwarded the multicast into
the backbone although it shoudn't have done this (having found no claim
for the client or erroneously also holding a claim). In this case the
backbone gateways seem to be out-of-sync about the actual claim status for
that client. This effect only lasts a very short time, as the gateway
which found the "roaming" client unclaims it and within a few milliseconds
(depending on the traffic generated by the client) another backbone gw (or
the same) claims the client again. Of course then the looping of the
multicast traffic from the client stops. In my case the sender of the
multicast was the bridge interface br0 of a remote mesh node itself. The
bat0 softinterface was added to that bridge. The looping multicast then
gave me a "bat0: received packet with own address as source address"
message. Furthermore that bat0 interface sent a claim frame for the mac of
the own bridge (whch is obvious as bat0 received a message from the mesh
with a mac address not claimed yet). This claim frame then produces
another "bat0: received packet ..." message.
I currently have no workaround for this 3rd issue as all I can image to
prevent this will break the "roaming client" scenario for bla. I could
even live with this problem as it happens quite seldomly and as it is
"self-healing", but it tells my that there might be a sync issue. Do you
think that my 1st and 2nd point could also relate to the same problem?
In the meantime I looked through the code for hours but I am not able to
find something that could explain the observed problem.

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


Re: [B.A.T.M.A.N.] [PATCH 2/4] batman-adv: Speed up dat by snooping received ip traffic

2016-02-16 Thread Andreas Pape
> > @@ -412,11 +414,28 @@ void batadv_interface_rx(struct net_device
> > *soft_iface,
> > ethhdr = eth_hdr(skb);
> >
> > switch (ntohs(ethhdr->h_proto)) {
> > +   case ETH_P_IP:
> > +   iphdr = (struct iphdr *)(skb->data + ETH_HLEN);
> > +   /* snoop incoming traffic for dat update using the
source
> > mac
> > +* and source ip to speed up dat.
> > +* Question: does this break the fundamental idea of
> > dat
> > +*/
>
> That is a really good question, although it doesn't belong in the code
;)
>

I know, but I was myself unsure if this is a good idea and wanted to
provoke a discussion about this ;-)

> @Antonio, CC'ing you since this is more a design question/proposal
> and you may
> have thought about this yet.
>
> Basically, doing this change means that we will put a lot of IP
addresses in
> our cache which are not in our local network - typically, all Internet
IP
> addresses along with the gateway backbone. Also these addresses
willnever be
> requested by ARP and are therefore practically just littering our cache.
They
> are purged after 5 minutes so the impact may be reasonable, but still
...
>

I agree that performance and especially consumption of RAM is an issue
here
depending on the network size

> Maybe there is a way to limit the entries to local networks? Also (and
in
> general), should we have an upper limit how many entries we store in
DAT?
> After applying this patch, doing a subnet ping scan can deplete the RAM
in
> small routers I'm afraid. :)
>
> (even now, that would be possible with fake ARP replies I guess)
>
> Also, why don't you check the ip destination as well while at it?
>
I only tried to check the source addresses with the gateways of a bla
setup
in mind. The goal was to increase the possiblity that already the gateway
can
answer the arp request. In this case only the traffic traveling from mesh
to
backbone is relevant. One could also snoop destination addresse for
traffic from
backbone to mesh, but do you think that this adds an extra benefit of
addtional
information except risking another decrease in forwarding performance ?

> Cheers,
>   Simon
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.
___


[B.A.T.M.A.N.] Antwort: Re: [PATCH 3/4] batman-adv: prevent duplication of ARP replies in BLA setups when DAT does address resolution

2016-02-16 Thread Andreas Pape
Simon Wunderlich  schrieb am 15.02.2016 09:27:02:

> Von: Simon Wunderlich 
> An: b.a.t.m.a.n@lists.open-mesh.org
> Kopie: Andreas Pape , Antonio Quartulli
> 
> Datum: 15.02.2016 09:27
> Betreff: Re: [B.A.T.M.A.N.] [PATCH 3/4] batman-adv: prevent
> duplication of ARP replies in BLA setups when DAT does address
resolution
>
> On Friday 12 February 2016 14:53:31 Andreas Pape wrote:
> > From 2cc1e9eb153d0c2d64cb0fb0747063ba63472925 Mon Sep 17 00:00:00 2001
> > From: Andreas Pape 
> > Date: Fri, 12 Feb 2016 13:19:25 +0100
> > Subject: [PATCH 3/4] batman-adv: prevent duplication of ARP replies in
BLA
> > setups when DAT does address resolution
> >
> > This patch covers the case of a bla setup with enabled dat if none of
the
> > common gateways of the
> > same backbone has already knowledge of the searched ip address and
> > therefore has to ask via DAT some
> > of the other mesh nodes. A broadcast arp request is coming
> > from the backbone and each backbone gateway starts an address
resolution
> > via other DAT mesh nodes.
> > In this case it should be prevented, that multiple answers from DAT
> > enabled mesh nodes reach the
> > backbone gateways leading to multiple replies in a common backbone
again.
>
> I think this approach and its methods as implented are good. However I
think
> we should generalize this case and forbid UNICAST/UNICAST4ADDR between
> backbone gateways, as discussed in the other thread.
>
> What do you think, or does anyone else have opinions?

From my limited experience with batman-adv I would welcome to forbid
UNICAST/UNICAST4ADDR traffic between backbone gateways as this fixes a
problem
I see temporarily in my setup which is not covered by my proposed patches
so far.

However this patch tried to address also a possible multiplication of ARP
replies, if
several backbone gateways forward ARP requests to nodes deep in the mesh
for dat
address resolution. As far as I understand this process, these nodes
answer the
requests independently and more important, the replies then don't come
from other
backbone gateways but from the nodes in the mesh. Therefore blocking the
unicast
traffic between backbone gateways doesn't necessarily solve the ARP reply
multiplication
completely.

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


[B.A.T.M.A.N.] Antwort: Re: [PATCH 1/4] batman-adv: Prevent mutliple ARP replies sent by gateways in bla setups with dat enabled

2016-02-15 Thread Andreas Pape
Hi Simon

was this the only patch which cannot be applied? What about the others I
sent? I am still working on the e-mail client issue 

Kind regards,
Andreas

Simon Wunderlich  schrieb am 15.02.2016 09:50:18:

> Von: Simon Wunderlich 
> An: b.a.t.m.a.n@lists.open-mesh.org
> Kopie: Andreas Pape 
> Datum: 15.02.2016 09:50
> Betreff: Re: [B.A.T.M.A.N.] [PATCH 1/4] batman-adv: Prevent mutliple
> ARP replies sent by gateways in bla setups with dat enabled
>
> On Friday 12 February 2016 14:51:32 Andreas Pape wrote:
> > From 2b90abdf53e9ab09d9acfd141c7225de1ae16719 Mon Sep 17 00:00:00 2001
> > From: Andreas Pape 
> > Date: Fri, 12 Feb 2016 10:05:57 +0100
> > Subject: [PATCH 1/4] batman-adv: Prevent mutliple ARP replies sent by
> > gateways in bla setups with dat enabled
> >
> > This patch shall make sure that only the backbone gw which has claimed
the
> > remote
> > destination for the ARP request answers the ARP request directly if
the
> > MAC address
> > is known due to the local DAT table. This prevents multiple ARP
replies in
> > a common
> > backbone if more than one gateway already knows the remote mac
searched
> > for in the
> > ARP request.
>
> This patch looks good in general. I can not apply it though, please
check the
> links that Sven posted how to set up your mail client to send patches.
Also,
> the commit message seems to have too long lines. Usually your git client

> should limit those to ~72 characters per line (I'm not sure about the
actual
> limit)
>
> >
> > Signed-off-by: Andreas Pape 
> > ---
> >  net/batman-adv/bridge_loop_avoidance.c |   58
> > 
> >  net/batman-adv/bridge_loop_avoidance.h |6 +++
> >  net/batman-adv/distributed-arp-table.c |   14 
> >  3 files changed, 78 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/batman-adv/bridge_loop_avoidance.c
> > b/net/batman-adv/bridge_loop_avoidance.c
> > index 0a6c8b8..c70363d 100644
> > --- a/net/batman-adv/bridge_loop_avoidance.c
> > +++ b/net/batman-adv/bridge_loop_avoidance.c
> > @@ -1906,3 +1906,61 @@ out:
> > batadv_hardif_put(primary_if);
> > return 0;
> >  }
> > +
> > +/**
> > + * batadv_check_local_claim
>
> You should put a short description here, like
>
> batadv_check_local_claim - check if the address has been claimed by the
local
> backbone
>
> > + * @bat_priv: the bat priv with all the soft interface information
> > + * @addr: mac address of which the claim status is checked
> > + * @vid: the VLAN ID
> > + *
> > + * batadv_check_local_claim:
>
> Please remove the repetition of the function name
>
> > + * addr is checked if this address is claimed by the local device
itself.
> > + * If the address is not claimed at all, claim it.
> > + * returns true if bla is disabled or the mac is claimed by the
device
> > + * returns false if the device addr is already claimed by another
gateway
> > + */
>
> Should put Return: and then describe the return values. Please checkthe
other
> functions for reference.
>
> kerneldoc is parsed automatically and must therefore be in the right
format.
>
> > +bool batadv_bla_check_local_claim(struct batadv_priv *bat_priv,
uint8_t
> > *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)) {
>
> You can save an intendation by doing a return here immediately
>
> > +
> > +   primary_if = batadv_primary_if_get_selected(bat_priv);
> > +   if (!primary_if)
> > +   return ret;
>
> I'd prefer a goto here. If we have other stuff to clean up when we
> change this
> function later, we may forget that this is not done because we used
return
> 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;
> > +*/
> > +   if (claim) {
> > +   if
(!batadv_compare

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

2016-02-12 Thread Andreas Pape
Simon Wunderlich  schrieb am 12.02.2016 14:04:23:

> Von: Simon Wunderlich 
> An: Andreas Pape 
> Kopie: The list for a Better Approach To Mobile Ad-hoc Networking
> 
> 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.

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

[B.A.T.M.A.N.] [PATCH 4/4] batman-adv: free skb when dropping broadcast packet received from another backbone gw

2016-02-12 Thread Andreas Pape
From 1cf69fc5b7ffac3193ad8fa4439586c865c5acab Mon Sep 17 00:00:00 2001
From: Andreas Pape 
Date: Fri, 12 Feb 2016 14:00:53 +0100
Subject: [PATCH 4/4] batman-adv: free skb when dropping broadcast packet
received from another backbone gw

skb should be freed in batadv_recv_bcast_packet if packet shall be dropped
due to
reception from another backbone gateway of the same backbone.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/routing.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 4dd646a..128ed28 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -1104,8 +1104,10 @@ int batadv_recv_bcast_packet(struct sk_buff *skb,
/* don't hand the broadcast up if it is from an originator
 * from the same backbone.
 */
-   if (batadv_bla_is_backbone_gw(skb, orig_node, hdr_size))
-   goto out;
+   if (batadv_bla_is_backbone_gw(skb, orig_node, hdr_size)) {
+   kfree_skb(skb);
+   goto rx_success;
+   }

if (batadv_dat_snoop_incoming_arp_request(bat_priv, skb,
hdr_size))
goto rx_success;
--
1.7.0.4



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


[B.A.T.M.A.N.] [PATCH 3/4] batman-adv: prevent duplication of ARP replies in BLA setups when DAT does address resolution

2016-02-12 Thread Andreas Pape
From 2cc1e9eb153d0c2d64cb0fb0747063ba63472925 Mon Sep 17 00:00:00 2001
From: Andreas Pape 
Date: Fri, 12 Feb 2016 13:19:25 +0100
Subject: [PATCH 3/4] batman-adv: prevent duplication of ARP replies in BLA
setups when DAT does address resolution

This patch covers the case of a bla setup with enabled dat if none of the
common gateways of the
same backbone has already knowledge of the searched ip address and
therefore has to ask via DAT some
of the other mesh nodes. A broadcast arp request is coming
from the backbone and each backbone gateway starts an address resolution
via other DAT mesh nodes.
In this case it should be prevented, that multiple answers from DAT
enabled mesh nodes reach the
backbone gateways leading to multiple replies in a common backbone again.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   56
+++-
 1 files changed, 55 insertions(+), 1 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c
b/net/batman-adv/distributed-arp-table.c
index 4e64e6c..22976fb 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -1080,6 +1080,8 @@ bool batadv_dat_snoop_incoming_arp_request(struct
batadv_priv *bat_priv,
u8 *hw_src;
struct sk_buff *skb_new;
struct batadv_dat_entry *dat_entry = NULL;
+   struct batadv_unicast_4addr_packet *unicast_4addr_packet;
+   struct batadv_orig_node *orig_node = NULL;
bool ret = false;
unsigned short vid;
int err;
@@ -1103,8 +1105,31 @@ bool batadv_dat_snoop_incoming_arp_request(struct
batadv_priv *bat_priv,
batadv_dat_entry_add(bat_priv, ip_src, hw_src, vid);

dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_dst, vid);
-   if (!dat_entry)
+   if (!dat_entry) {
+   /* Check if this is a 4addr unicast DAT_DHT_GET frame from
+* another backbone gw of the same backbone. If yes, drop
+* it as this leads to multiplication of arp requests in
bla setups
+* as long as there is no dat_entry fo this answer. In
this
+* case better drop the DHT_GET. Normal bla code doesn't
take care of
+* these packets as they are tunneled via unicast.
+*/
+   unicast_4addr_packet = (struct batadv_unicast_4addr_packet
*)skb->data;
+   orig_node = batadv_orig_hash_find(bat_priv,
unicast_4addr_packet->src);
+   if (orig_node) {
+   if ((unicast_4addr_packet->u.packet_type ==
BATADV_UNICAST_4ADDR) &&
+   (unicast_4addr_packet->subtype ==
BATADV_P_DAT_DHT_GET) &&
+   (batadv_bla_is_backbone_gw(skb,
orig_node, hdr_size))) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv,
"Doubled ARP request removed: "
+   "ARP MSG = [src: %pM-%pI4
dst: %pM-%pI4]; originator: %pM\n",
+   hw_src, &ip_src,
batadv_arp_hw_dst(skb, hdr_size), &ip_dst,
+ unicast_4addr_packet->src);
+   ret = true;
+   }
+   batadv_orig_node_put(orig_node);
+   }
+
goto out;
+   }

skb_new = arp_create(ARPOP_REPLY, ETH_P_ARP, ip_src,
 bat_priv->soft_iface, ip_dst, hw_src,
@@ -1203,6 +1228,7 @@ bool batadv_dat_snoop_incoming_arp_reply(struct
batadv_priv *bat_priv,
__be32 ip_src, ip_dst;
u8 *hw_src, *hw_dst;
bool dropped = false;
+   struct batadv_dat_entry *dat_entry = NULL;
unsigned short vid;

if (!atomic_read(&bat_priv->distributed_arp_table))
@@ -1222,12 +1248,38 @@ bool batadv_dat_snoop_incoming_arp_reply(struct
batadv_priv *bat_priv,
hw_dst = batadv_arp_hw_dst(skb, hdr_size);
ip_dst = batadv_arp_ip_dst(skb, hdr_size);

+   /* If ip_dst is already in cache and has the right mac address,
+* drop this frame if this ARP reply is destined for us. We have
+* most probably received already a reply from someone else.
Delivering
+* this frame would lead to doubled receive of an ARP reply.
+*/
+   dat_entry = batadv_dat_entry_hash_find(bat_priv, ip_src, vid);
+   if ((dat_entry) && (batadv_compare_eth(hw_src,
dat_entry->mac_addr))) {
+   batadv_dbg(BATADV_DBG_DAT, bat_priv, "Doubled ARP reply
removed: "
+   "ARP MSG = [src: %pM-%pI4 dst: %pM-%pI4];
dat_entry: %pM-%pI4\n",
+   hw_src, &ip_src, hw_dst, &ip_dst,
dat_entry->mac_addr, &dat_entry->ip);
+   dropped = true;
+   goto out;
+   }
+
/* Update our internal cache with both the IP ad

[B.A.T.M.A.N.] [PATCH 2/4] batman-adv: Speed up dat by snooping received ip traffic

2016-02-12 Thread Andreas Pape
From cc88159dcf18f4b8310414d2d71635fad76bf5bb Mon Sep 17 00:00:00 2001
From: Andreas Pape 
Date: Fri, 12 Feb 2016 11:03:10 +0100
Subject: [PATCH 2/4] batman-adv: Speed up dat by snooping received ip
traffic

This patch shall speed up dat by snooping all incoming ip traffic instead
of only relying on ARP handling. This shall especially increase the
probability
that a gateway into a backbone network already has a fitting dat entry to
answer
incoming arp requests directly coming from the backbone network.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/distributed-arp-table.c |   18 ++
 net/batman-adv/distributed-arp-table.h |8 +++-
 net/batman-adv/soft-interface.c|   21 -
 3 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/net/batman-adv/distributed-arp-table.c
b/net/batman-adv/distributed-arp-table.c
index 93893bf..4e64e6c 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -362,6 +362,24 @@ out:
batadv_dat_entry_put(dat_entry);
 }

+/**
+ * batadv_dat_entry_check - check and update a dat entry
+ * @bat_priv: the bat priv with all the soft interface information
+ * @ip: ipv4 to add/edit
+ * @mac_addr: mac address to assign to the given ipv4
+ * @vid: VLAN identifier
+ *
+ * checks additionally, if dat is enabled. can be called from other
modules.
+ */
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip,
+u8 *mac_addr, unsigned short vid)
+{
+   if(!atomic_read(&bat_priv->distributed_arp_table))
+   return;
+
+   batadv_dat_entry_add(bat_priv, ip, mac_addr, vid);
+}
+
 #ifdef CONFIG_BATMAN_ADV_DEBUG

 /**
diff --git a/net/batman-adv/distributed-arp-table.h
b/net/batman-adv/distributed-arp-table.h
index 813ecea..a2ab16b 100644
--- a/net/batman-adv/distributed-arp-table.h
+++ b/net/batman-adv/distributed-arp-table.h
@@ -80,7 +80,8 @@ batadv_dat_init_own_addr(struct batadv_priv *bat_priv,
 int batadv_dat_init(struct batadv_priv *bat_priv);
 void batadv_dat_free(struct batadv_priv *bat_priv);
 int batadv_dat_cache_seq_print_text(struct seq_file *seq, void *offset);
-
+void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip,
+u8 *mac_addr, unsigned short vid);
 /**
  * batadv_dat_inc_counter - increment the correct DAT packet counter
  * @bat_priv: the bat priv with all the soft interface information
@@ -173,6 +174,11 @@ static inline void batadv_dat_inc_counter(struct
batadv_priv *bat_priv,
 {
 }

+void batadv_dat_entry_check(struct batadv_priv *bat_priv, __be32 ip,
+u8 *mac_addr, unsigned short vid)
+{
+}
+
 #endif /* CONFIG_BATMAN_ADV_DAT */

 #endif /* _NET_BATMAN_ADV_DISTRIBUTED_ARP_TABLE_H_ */
diff --git a/net/batman-adv/soft-interface.c
b/net/batman-adv/soft-interface.c
index 0710379..41d7987 100644
--- a/net/batman-adv/soft-interface.c
+++ b/net/batman-adv/soft-interface.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -390,6 +391,7 @@ void batadv_interface_rx(struct net_device
*soft_iface,
__be16 ethertype = htons(ETH_P_BATMAN);
struct vlan_ethhdr *vhdr;
struct ethhdr *ethhdr;
+   struct iphdr *iphdr;
unsigned short vid;
bool is_bcast;

@@ -412,11 +414,28 @@ void batadv_interface_rx(struct net_device
*soft_iface,
ethhdr = eth_hdr(skb);

switch (ntohs(ethhdr->h_proto)) {
+   case ETH_P_IP:
+   iphdr = (struct iphdr *)(skb->data + ETH_HLEN);
+   /* snoop incoming traffic for dat update using the source
mac
+* and source ip to speed up dat.
+* Question: does this break the fundamental idea of
dat
+*/
+   batadv_dat_entry_check(bat_priv, iphdr->saddr,
ethhdr->h_source, vid);
+   break;
case ETH_P_8021Q:
vhdr = (struct vlan_ethhdr *)skb->data;

-   if (vhdr->h_vlan_encapsulated_proto != ethertype)
+   if (vhdr->h_vlan_encapsulated_proto != ethertype) {
+   /* snoop incoming traffic for dat update also for
vlan
+* tagged frames.
+* Question: does this break the fundamental idea
of dat
+*/
+   if (vhdr->h_vlan_encapsulated_proto == ETH_P_IP) {
+   iphdr = (struct iphdr *)(vhdr +
sizeof(struct vlan_ethhdr));
+   batadv_dat_entry_check(bat_priv,
iphdr->saddr, vhdr->h_source, vid);
+   }
break;
+   }

/* fall through */
case ETH_P_BATMAN:
--
1.7.0.4



..
PHOENIX CONTACT ELECTRONICS GmbH

Sitz der Gesellschaft / registered office of the

[B.A.T.M.A.N.] [PATCH 1/4] batman-adv: Prevent mutliple ARP replies sent by gateways in bla setups with dat enabled

2016-02-12 Thread Andreas Pape
From 2b90abdf53e9ab09d9acfd141c7225de1ae16719 Mon Sep 17 00:00:00 2001
From: Andreas Pape 
Date: Fri, 12 Feb 2016 10:05:57 +0100
Subject: [PATCH 1/4] batman-adv: Prevent mutliple ARP replies sent by
gateways in bla setups with dat enabled

This patch shall make sure that only the backbone gw which has claimed the
remote
destination for the ARP request answers the ARP request directly if the
MAC address
is known due to the local DAT table. This prevents multiple ARP replies in
a common
backbone if more than one gateway already knows the remote mac searched
for in the
ARP request.

Signed-off-by: Andreas Pape 
---
 net/batman-adv/bridge_loop_avoidance.c |   58

 net/batman-adv/bridge_loop_avoidance.h |6 +++
 net/batman-adv/distributed-arp-table.c |   14 
 3 files changed, 78 insertions(+), 0 deletions(-)

diff --git a/net/batman-adv/bridge_loop_avoidance.c
b/net/batman-adv/bridge_loop_avoidance.c
index 0a6c8b8..c70363d 100644
--- a/net/batman-adv/bridge_loop_avoidance.c
+++ b/net/batman-adv/bridge_loop_avoidance.c
@@ -1906,3 +1906,61 @@ out:
batadv_hardif_put(primary_if);
return 0;
 }
+
+/**
+ * batadv_check_local_claim
+ * @bat_priv: the bat priv with all the soft interface information
+ * @addr: mac address of which the claim status is checked
+ * @vid: the VLAN ID
+ *
+ * batadv_check_local_claim:
+ * addr is checked if this address is claimed by the local device itself.
+ * If the address is not claimed at all, claim it.
+ * returns true if bla is disabled or the mac is claimed by the device
+ * returns false if the device addr is already claimed by another gateway
+ */
+bool batadv_bla_check_local_claim(struct batadv_priv *bat_priv, uint8_t
*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)) {
+
+   primary_if = batadv_primary_if_get_selected(bat_priv);
+   if (!primary_if)
+   return ret;
+
+   /* 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;
+*/
+   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, "No claim
found for %pM. Claim mac for us.\n",
+   search_claim.addr);
+
+   batadv_handle_claim(bat_priv,
+  primary_if,
+ primary_if->net_dev->dev_addr, addr,
+  vid);
+   }
+   }
+
+   if (claim)
+   batadv_claim_put(claim);
+   if (primary_if)
+   batadv_hardif_put(primary_if);
+   return ret;
+}
diff --git a/net/batman-adv/bridge_loop_avoidance.h
b/net/batman-adv/bridge_loop_avoidance.h
index 579f0fa..84c31bc 100644
--- a/net/batman-adv/bridge_loop_avoidance.h
+++ b/net/batman-adv/bridge_loop_avoidance.h
@@ -46,6 +46,7 @@ void batadv_bla_update_orig_address(struct batadv_priv
*bat_priv,
 void batadv_bla_status_update(struct net_device *net_dev);
 int batadv_bla_init(struct batadv_priv *bat_priv);
 void batadv_bla_free(struct batadv_priv *bat_priv);
+bool batadv_bla_check_local_claim(struct batadv_priv *bat_priv, u8 *addr,
unsigned short vid);

 #define BATADV_BLA_CRC_INIT0
 #else /* ifdef CONFIG_BATMAN_ADV_BLA */
@@ -111,6 +112,11 @@ static inline void batadv_bla_free(struct batadv_priv
*bat_priv)
 {
 }

+bool batadv_bla_check_local_claim(struct batadv_priv *bat_priv, u8 *addr,
unsigned short vid)
+{
+   return true;
+}
+
 #endif /* ifdef CONFIG_BATMAN_ADV_BLA */

 #endif /* ifndef _NET_BATMAN_ADV_BLA_H_ */
diff --git a/net/batman-adv/distributed-arp-table.c
b/net/batman-adv/distributed-arp-table.c
index e96d7c7..93893bf 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -48,6 +48,7 @@
 #include "originator.h"
 #include "send.h"
 #include "translation-table.h"
+#include "bridge_loop_avoidance.h"

 static void batadv_dat_purge(struct work_struct *work);

@@ -1000,6 +1001,19 @@ bool batadv_dat_snoop_outgoing_arp_request(struct
batadv_priv *bat_priv,
goto out;
}

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

2016-02-12 Thread Andreas Pape
Hi Simon,


Simon Wunderlich  schrieb am 11.02.2016 12:08:25:

> Von: Simon Wunderlich 
> An: Andreas Pape 
> Kopie: The list for a Better Approach To Mobile Ad-hoc Networking
> , "B.A.T.M.A.N"  boun...@lists.open-mesh.org>
> Datum: 11.02.2016 12:08
> Betreff: Re: Re: [B.A.T.M.A.N.] Antwort: Re: Looping unicast packets
> when using BLA
>
> Hi Andreas,
>
> On Thursday 11 February 2016 10:19:07 Andreas Pape wrote:
> > Hi,
> >
> > I want to give a short feedback concerning my attempt to use
> > batman-adv-2016.0 instead of to older version I used first.
> >
> > Unfortunately, using batman-adv-2016.0 does not solve my problem. I
can
> > still see claim frames sent by the mesh gateways into the common
backbone
> > network for MAC addresses out of the common backbone network itself. I
> > enabled again both bla and dat support. Furthermore I have also still
> > problems with DAT, because there are multiple ARP replies visible in
the
> > backbone network coming out of the mesh.
> >
> > That reminds me that I have forgotten to mention in my earlier mail,
that
> > I did not test with the original batman-adv-2014.4.0 first but with a
> > version having the patch applied I sent to the mailing list in March
last
> > year concerning possible fixes for dat in bla setups. If I remember it
> > correctly I think there were two main issues in batman-adv-2014.4.0
when
> > 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.
>
> > 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.

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

> >
> > Good news is that disabling dat in batman-adv-2016.0 seems to solve my
> > observed issues (in strange ways even the observed erroneous claim
frames
> > in the backbone network). But I think dat is a clever feature to
> > reduce broadcast load in the mesh network. Wouldn

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

2016-02-11 Thread Andreas Pape
Hi,

I want to give a short feedback concerning my attempt to use
batman-adv-2016.0 instead of to older version I used first.

Unfortunately, using batman-adv-2016.0 does not solve my problem. I can
still see claim frames sent by the mesh gateways into the common backbone
network for MAC addresses out of the common backbone network itself. I
enabled again both bla and dat support. Furthermore I have also still
problems with DAT, because there are multiple ARP replies visible in the
backbone network coming out of the mesh.

That reminds me that I have forgotten to mention in my earlier mail, that
I did not test with the original batman-adv-2014.4.0 first but with a
version having the patch applied I sent to the mailing list in March last
year concerning possible fixes for dat in bla setups. If I remember it
correctly I think there were two main issues in batman-adv-2014.4.0 when
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.
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.

Good news is that disabling dat in batman-adv-2016.0 seems to solve my
observed issues (in strange ways even the observed erroneous claim frames
in the backbone network). But I think dat is a clever feature to
reduce broadcast load in the mesh network. Wouldn't it be useful to dig a
little bit deeper into the combined use of dat and bla? I would volunteer
for testing and providing ideas for improving the behaviour.

Or do you think that I have an issue with my old 2.6.32 kernel?

Best regards,
Andreas



"B.A.T.M.A.N"  schrieb am
09.02.2016 08:01:27:

> Von: Andreas Pape 
> An: Simon Wunderlich 
> Kopie: b.a.t.m.a.n@lists.open-mesh.org
> Datum: 09.02.2016 08:01
> Betreff: [B.A.T.M.A.N.] Antwort: Re: Looping unicast packets when using
BLA
> Gesendet von: "B.A.T.M.A.N" 
>
> Hi Simon,
>
> thanks for the quick reply.
>
> Simon Wunderlich  schrieb am 08.02.2016 13:29:55:
>
> > Von: Simon Wunderlich 
> > An: b.a.t.m.a.n@lists.open-mesh.org
> > Kopie: Andreas Pape 
> > Datum: 09.02.2016 07:20
> > Betreff: Re: [B.A.T.M.A.N.] Looping unicast packets when using BLA
> >
> > Hi Andreas,
> >
> > On Monday 08 February 2016 12:35:35 Andreas Pape wrote:
> > > Hello
> > >
> > > I have a problem in my mesh setup which is quite similiar to Bug#216
> of
> > > the bug tracker.
> > > I'm using batman-adv 2014.4.0 in a BLA setup consisting of 3 Mesh
> Nodes
> > > (A, B, C) connected to the same backone network via a common switch
> and a
> > > mesh node D connected to an end device E. I ping that single mesh
node
> D
> > > and the connected end device E from a PC which is connected to the
> same
> > > switch as the three Nodes A to C. BLA is compiled and enabled.
> >
> > First of all, did you test v2016.0? v2014.4.0 is pretty old, the bug
was
>
> > created and closed in 2015 after all ...
>
> I just restarted my last year's work to test batman-adv and was a little
> bit lazy to update to the latests version as my devices use a fairly old
> kernel version 2.6.32. And the update to 2014.4.0 early last year only
> worked with Marek's help (issue in the compat code).
>
> But before making further assumptions, I'll start with the update first.
> In the meantime I am pretty sure, that the problem does not come from
the
> bla code as such. I changed the code in batadv_bla_rx in the repsective
> part as follows:
>
> ether_addr_copy(search_claim.addr, ethhdr->h_source);
> search_claim.vid = vid;
> claim = batadv_claim_hash_find(bat_priv, &search_claim);
>
> if (!claim) {
> /* possible optimization: race for a claim */
> /* No claim exists yet, claim it for us!
>  */
>
> if (!batadv_is_my_client(bat_priv, ethhdr->h_source,
vid))
> {
> batadv_handle_claim(bat_priv, primary_if,
> primary_if->net_dev->dev_addr,
> ethhdr->h_source, vid);
> goto allow;
> } else {
> printk("not claimed: %pM \n", ethhdr->h_source);
> goto handled;
> }
> }

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

2016-02-08 Thread Andreas Pape
Hi Simon,

thanks for the quick reply.

Simon Wunderlich  schrieb am 08.02.2016 13:29:55:

> Von: Simon Wunderlich 
> An: b.a.t.m.a.n@lists.open-mesh.org
> Kopie: Andreas Pape 
> Datum: 09.02.2016 07:20
> Betreff: Re: [B.A.T.M.A.N.] Looping unicast packets when using BLA
>
> Hi Andreas,
>
> On Monday 08 February 2016 12:35:35 Andreas Pape wrote:
> > Hello
> >
> > I have a problem in my mesh setup which is quite similiar to Bug#216
of
> > the bug tracker.
> > I'm using batman-adv 2014.4.0 in a BLA setup consisting of 3 Mesh
Nodes
> > (A, B, C) connected to the same backone network via a common switch
and a
> > mesh node D connected to an end device E. I ping that single mesh node
D
> > and the connected end device E from a PC which is connected to the
same
> > switch as the three Nodes A to C. BLA is compiled and enabled.
>
> First of all, did you test v2016.0? v2014.4.0 is pretty old, the bug was

> created and closed in 2015 after all ...

I just restarted my last year's work to test batman-adv and was a little
bit lazy to update to the latests version as my devices use a fairly old
kernel version 2.6.32. And the update to 2014.4.0 early last year only
worked with Marek's help (issue in the compat code).

But before making further assumptions, I'll start with the update first.
In the meantime I am pretty sure, that the problem does not come from the
bla code as such. I changed the code in batadv_bla_rx in the repsective
part as follows:

ether_addr_copy(search_claim.addr, ethhdr->h_source);
search_claim.vid = vid;
claim = batadv_claim_hash_find(bat_priv, &search_claim);

if (!claim) {
/* possible optimization: race for a claim */
/* No claim exists yet, claim it for us!
 */

if (!batadv_is_my_client(bat_priv, ethhdr->h_source, vid))
{
batadv_handle_claim(bat_priv, primary_if,
primary_if->net_dev->dev_addr,
ethhdr->h_source, vid);
goto allow;
} else {
printk("not claimed: %pM \n", ethhdr->h_source);
goto handled;
}
}

I did this yesterday in a "quick-and-dirty" way and restarted my pingtest,
which ran until this morning without looping packets. But I did not notice
until now that I did not only prevent the claiming of MAC addresses from
the own backbone but I also dropped the packets causing the claim to be
triggered! That tells me that the original code in batadv_bla_rx is most
likely OK and that my problem comes from somewhere else (e.g. ping request
from PC to device E enters gateway A and is forwarded to gateway B via the
mesh. But gateway B does not forward it to mesh node D but sends the
packet via the linux bridge and my eth0 interface to the backbone
network).

But before digging deeper into this, I'll make a try with 2016.0 and see
if the problem is solved there.

>
> >
> > From time to time I see looping unicast packets in my backbone
network.
> > This unicast looping starts directly after one of the nodes A to C
claimed
> > the mac address of my PC. The looping telegram is then the ping
request
> > sent by the PC. I have a wireshark recording made in my backbone via
port
> > mirroring of one of the switch ports where a mesh node is connected to
> > which shows this behaviour.
>
> Is it really the ping packet looping? If yes, which nodes are part of
the
> loop? Normally we only see broadcast packets looping. In #216 it was
also
> broadcast packets where we have seen duplicates, and this was more a
locking
> problem leading to creation of the same packets again and again.
>
> >
> > I am not sure if I understood bla correctly but isn't it nonsense that
a
> > bla backbone gateway claims MAC addresses from its own backbone (i.e.
the
> > one it is directly connected to via its ethernet port)?
>
> Yes, that appears to be nonsense indeed. Do you happen to have DAT
enabled?
> There were also some problems with that which are fixed by now.

DAT is enabled. But my problem starts with a gratuitous arp containing a
claim and not a multiplication of normal arp requests or repsonses.

>
> >
> > A simple change in batadv_bla_rx seems to solve this problem: add an
> > additional check before claiming a new mac address: if this address is
> > already known from the tt local table (via command
batadv_is_my_client)
> > don't claim it.
> >
> > This seems to solve my problem as far as I have tested so far. Any
> > thoughts about that?
>
> This will prevent roaming from on of your nodes connec

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

2016-02-08 Thread Andreas Pape
Hello

I have a problem in my mesh setup which is quite similiar to Bug#216 of
the bug tracker.
I'm using batman-adv 2014.4.0 in a BLA setup consisting of 3 Mesh Nodes
(A, B, C) connected to the same backone network via a common switch and a
mesh node D connected to an end device E. I ping that single mesh node D
and the connected end device E from a PC which is connected to the same
switch as the three Nodes A to C. BLA is compiled and enabled.

From time to time I see looping unicast packets in my backbone network.
This unicast looping starts directly after one of the nodes A to C claimed
the mac address of my PC. The looping telegram is then the ping request
sent by the PC. I have a wireshark recording made in my backbone via port
mirroring of one of the switch ports where a mesh node is connected to
which shows this behaviour.

I am not sure if I understood bla correctly but isn't it nonsense that a
bla backbone gateway claims MAC addresses from its own backbone (i.e. the
one it is directly connected to via its ethernet port)?

A simple change in batadv_bla_rx seems to solve this problem: add an
additional check before claiming a new mac address: if this address is
already known from the tt local table (via command batadv_is_my_client)
don't claim it.

This seems to solve my problem as far as I have tested so far. Any
thoughts about that?

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


[B.A.T.M.A.N.] Antwort: Re: [PATCH] batman-adv: bugfix for kernel crash in batadv_tt_local_table_free

2015-03-19 Thread Andreas Pape
Hi Antonio,

I saw the crash, but only in the case when I add the non-IP traffic using 
VLAN ID 0. No interface of the mesh node is part of that VLAN, i.e. I 
don't use further virtual VLAN interfaces on my mesh node. This VLAN 
traffic shall only be transparently forwarded over the mesh which - by the 
way - works flawlessly. 

As soon as I remove the WLAN interface from bat0 (batctl if del ath0) I 
get the following crash report:

/ # Unable to handle kernel paging request for data at address 0x0020
Faulting instruction address: 0xc99c35a4
Oops: Kernel access of bad area, sig: 11 [#1]
MPC831x RDB
Modules linked in: batman_adv crc32c umac ath_dev(P) ath_rate_atheros(P) 
ath_dfs(P) ath_hal(P) asf(P) adf t23xsec2 t23xrm spi_mpc8xxx ipv6
NIP: c99c35a4 LR: c99c8ca4 CTR: c00253ac
REGS: c654ddd0 TRAP: 0300   Tainted: P(2.6.32.26-svn1313)
MSR: 9032   CR: 84002082  XER: 2000
DAR: 0020, DSISR: 2000
TASK = c68680e0[1105] 'bat_events' THREAD: c654c000
GPR00: 0020 c654de80 c68680e0  8000 c0355078 c797f3e5 
0080
GPR08: 0001  0001  44002088 100d5bc0 07ffa000 

GPR16: fa3fdfef      0002 
07e958b0
GPR24:  0174 c7b14320 c6d382c0   00200200 

NIP [c99c35a4] batadv_softif_vlan_free_ref+0x18/0x98 [batman_adv]
LR [c99c8ca4] batadv_tt_free+0xc0/0x30c [batman_adv]
Call Trace:
[c654de80] [c99c6690] batadv_tt_local_entry_free_ref+0x38/0x48 
[batman_adv] (unreliable)
[c654de90] [c99c8ca4] batadv_tt_free+0xc0/0x30c [batman_adv]
[c654dec0] [c99bdfb8] batadv_mesh_free+0x54/0x8c [batman_adv]
[c654dee0] [c99c34e8] batadv_softif_free+0x20/0x40 [batman_adv]
[c654df00] [c01fa2f0] netdev_run_todo+0x1a4/0x244
[c654df30] [c0206888] rtnl_unlock+0x10/0x20
[c654df40] [c01fad48] unregister_netdev+0x24/0x38
[c654df60] [c99c36cc] batadv_softif_destroy_finish+0x50/0x64 [batman_adv]
[c654df80] [c0031d44] worker_thread+0x108/0x1b0
[c654dfc0] [c0035ca0] kthread+0x78/0x7c
[c654dff0] [c0011444] kernel_thread+0x4c/0x68
Instruction dump:
4e800020 480088f1 7fe3fb78 3be0 48008935 4bd8 9421fff0 7c0802a6
93e1000c 7c7f1b78 90010014 38030020 <7d200028> 3129 7d20012d 40a2fff4
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 180 seconds..


If I add the "if (vlan)" check, this doesn't happen anymore. The other 
thing which prevents the crash is not using the VLAN ID 0 traffic. 

Regards,
Andreas


"B.A.T.M.A.N"  schrieb am 
19.03.2015 17:01:33:

> Von: Antonio Quartulli 
> An: b.a.t.m.a.n@lists.open-mesh.org, 
> Datum: 19.03.2015 17:03
> Betreff: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: bugfix for kernel 
> crash in batadv_tt_local_table_free
> Gesendet von: "B.A.T.M.A.N" 
> 
> Hi Andreas,
> 
> On 19/03/15 16:46, Andreas Pape wrote:
> > This missing check lead to a kernel crash when a hard_if is removed on 
a 
> > node forwarding
> > untagged and tagged traffic (VLANID 0) to and from the mesh network.
> > 
> 
> Did you actually see the crash? if so, can you please report the 
stacktrace?
> 
> When creating bat0 (untagged interface), a "fake" vlan object is created
> with vid = BATADV_NO_FLAGS, therefore in this context the object "vlan"
> should never be NULL because there is always an object to retrieve.
> 
> Cheers,
> 
> > Signed-off-by: Andreas Pape 
> > ---
> >  translation-table.c |6 --
> >  1 files changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/translation-table.c b/translation-table.c
> > index b20812b..4d3ab8d 100644
> > --- a/translation-table.c
> > +++ b/translation-table.c
> > @@ -1143,8 +1143,10 @@ static void batadv_tt_local_table_free(struct 
> > batadv_priv *bat_priv)
> > /* decrease the reference held for this vlan 
*/
> > vlan = batadv_softif_vlan_get(bat_priv,
> >  tt_common_entry->vid);
> > -   batadv_softif_vlan_free_ref(vlan);
> > -   batadv_softif_vlan_free_ref(vlan);
> > +   if (vlan) {
> > +   batadv_softif_vlan_free_ref(vlan);
> > +   batadv_softif_vlan_free_ref(vlan);
> > +   }
> > 
> > batadv_tt_local_entry_free_ref(tt_local);
> > }
> > 
> 
> -- 
> Antonio Quartulli
> 
> [Anhang "signature.asc" gelöscht von Andreas Pape/Phoenix Contact] 


..
PHOENIX CONTACT ELECTRONICS GmbH

Sitz der Gesellschaft / registered office of the company: 31812 Bad Pyrmont
USt-Id-Nr.: DE811742156
Amtsgericht Hannover HRB 100528 / distric

[B.A.T.M.A.N.] [PATCH] batman-adv: bugfix for kernel crash in batadv_tt_local_table_free

2015-03-19 Thread Andreas Pape
This missing check lead to a kernel crash when a hard_if is removed on a 
node forwarding
untagged and tagged traffic (VLANID 0) to and from the mesh network.

Signed-off-by: Andreas Pape 
---
 translation-table.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/translation-table.c b/translation-table.c
index b20812b..4d3ab8d 100644
--- a/translation-table.c
+++ b/translation-table.c
@@ -1143,8 +1143,10 @@ static void batadv_tt_local_table_free(struct 
batadv_priv *bat_priv)
/* decrease the reference held for this vlan */
vlan = batadv_softif_vlan_get(bat_priv,
 tt_common_entry->vid);
-   batadv_softif_vlan_free_ref(vlan);
-   batadv_softif_vlan_free_ref(vlan);
+   if (vlan) {
+   batadv_softif_vlan_free_ref(vlan);
+   batadv_softif_vlan_free_ref(vlan);
+   }
 
batadv_tt_local_entry_free_ref(tt_local);
}
-- 
1.7.0.4


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


[B.A.T.M.A.N.] [PATCH] dat optimization test

2015-03-19 Thread Andreas Pape
From e0b37ee6d7d82648768dc98a95c3a61d7edf86dd Mon Sep 17 00:00:00 2001
From: Andreas Pape 
Date: Wed, 18 Mar 2015 11:03:22 +0100
Subject: [PATCH] dat optimization test


Signed-off-by: Andreas Pape 
---
 bridge_loop_avoidance.c |   60 +
 bridge_loop_avoidance.h |6 +++
 distributed-arp-table.c |   85 
++-
 distributed-arp-table.h |7 +++-
 routing.c   |6 ++-
 soft-interface.c|   17 -
 6 files changed, 175 insertions(+), 6 deletions(-)

diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c
index 6927589..bdc8ac9 100644
--- a/bridge_loop_avoidance.c
+++ b/bridge_loop_avoidance.c
@@ -1712,3 +1712,63 @@ out:
batadv_hardif_free_ref(primary_if);
return 0;
 }
+
+/**
+ * batadv_check_local_claim
+ * @bat_priv: the bat priv with all the soft interface information
+ * @addr: mac address of which the claim status is checked
+ * @vid: the VLAN ID
+ *
+ * batadv_check_local_claim:
+ * addr is checked if this address is claimed by the local device itself.
+ * If the address is not claimed at all, claim it.
+ * returns true if bla is disabled or the mac is claimed by the device
+ * returns false if the device addr is already claimed by another gateway
+ */
+bool batadv_check_local_claim(struct batadv_priv *bat_priv, uint8_t 
*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)) {
+
+   primary_if = batadv_primary_if_get_selected(bat_priv);
+   if (!primary_if)
+   return ret;
+
+   /* First look if the mac address is is already 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.
+*/
+   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
+* Question: is this likey to happen?
+*/
+   batadv_dbg(BATADV_DBG_BLA, bat_priv, "No claim 
found for %pM. Claim mac for us.\n",
+   search_claim.addr);
+
+   batadv_handle_claim(bat_priv,
+  primary_if,
+ primary_if->net_dev->dev_addr, addr,
+  vid);
+   }
+   }
+
+   if (claim)
+   batadv_claim_free_ref(claim);
+   if (primary_if)
+   batadv_hardif_free_ref(primary_if);
+   return ret;
+}
diff --git a/bridge_loop_avoidance.h b/bridge_loop_avoidance.h
index 43c985d..85f6ecb 100644
--- a/bridge_loop_avoidance.h
+++ b/bridge_loop_avoidance.h
@@ -37,6 +37,7 @@ void batadv_bla_update_orig_address(struct batadv_priv 
*bat_priv,
struct batadv_hard_iface *oldif);
 int batadv_bla_init(struct batadv_priv *bat_priv);
 void batadv_bla_free(struct batadv_priv *bat_priv);
+bool batadv_check_local_claim(struct batadv_priv *bat_priv, uint8_t 
*addr, unsigned short vid);
 
 #define BATADV_BLA_CRC_INIT0
 #else /* ifdef CONFIG_BATMAN_ADV_BLA */
@@ -103,6 +104,11 @@ static inline void batadv_bla_free(struct batadv_priv 
*bat_priv)
 {
 }
 
+bool batadv_check_local_claim(struct batadv_priv *bat_priv, uint8_t 
*addr, unsigned short vid)
+{
+   return true;
+}
+
 #endif /* ifdef CONFIG_BATMAN_ADV_BLA */
 
 #endif /* ifndef _NET_BATMAN_ADV_BLA_H_ */
diff --git a/distributed-arp-table.c b/distributed-arp-table.c
index 107ad62..69b4484 100644
--- a/distributed-arp-table.c
+++ b/distributed-arp-table.c
@@ -23,6 +23,7 @@
 #include "main.h"
 #include "hash.h"
 #include "distributed-arp-table.h"
+#include "bridge_loop_avoidance.h"
 #include "hard-interface.h"
 #include "originator.h"
 #include "send.h"
@@ -327,6 +328,24 @@ out:
batadv_dat_entry_free_ref(dat_entry);
 }
 
+/**
+ * batadv_dat_entry_check - check and update a dat entry
+ * @bat_priv: the bat priv with all the soft interface information
+ * @ip: ipv4 to add/edit
+ * @mac_addr: mac address to assign to the given ipv4
+ * @vid: VLAN identifier
+ *
+ * checks additionally, if dat is enabled. can be called from other 
modules.
+ */
+void batadv_dat_entry_check(struct batadv_pri

Re: [B.A.T.M.A.N.] DAT broken in 2014.4.0?

2015-03-18 Thread Andreas Pape
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.
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.

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 ;-) 

Regards,
Andreas

"B.A.T.M.A.N"  schrieb am 
13.03.2015 15:35:53:

> Von: Andreas Pape 
> An: The list for a Better Approach To Mobile Ad-hoc Networking 
> , 
> Datum: 13.03.2015 15:57
> Betreff: Re: [B.A.T.M.A.N.] DAT broken in 2014.4.0?
> Gesendet von: "B.A.T.M.A.N" 
> 
> Hello Antonio,
> 
> my mesh nodes use a wlan interface in adhoc mode as the only hard_if in 
> bat0. bat0 is bridged to a Linux bridge br0 together with the Ethernet 
> interface eth0. The wlan interface ath0 is not part of that bridge. The 
> only interface having an ip address assigned is the bridge br0.
> 
> As mentioned I use 6 mesh nodes of that described setup of which 3 are 
> only accessible via the mesh (eth0 interface not connected to any other 
> Ethernet device) and 3 devices are connected with their eth Interfaces 
to 
> the same Ethernet switch. The Windows PC is also connected to that same 
> switch.
> 
> I am using batman-adv 2014.4.0 in combination with a fairly old Linux 
> kernel 2.6.32.26 on an embedded device. If I enable BLA and DAT and send 
a 
> ping from the Windows PC to one of the mesh nodes which is not connected 

> to the Ethernet backbone, I see a multiplication of the ARP request sent 

> by the PC and even a higher amount of corresponding ARP replies in the 
> backbone network of which I am not sure, how much of them are really 
sent 
> by the mesh node being the original destination for the ARP request. 
> Furthermore I get lots of "bat0: received packet with own address as 
> source address" and some "eth0: received " kernel log messages in 
that 
> case as soon as the PC sends the first broadcast ARP request (after the 
> mentioned arp -d command). 
> 
> If I disable DAT on all of my 6 devices the ARP telegrams being visible 
in 
> the backbone network look normal to me. There is only one broadcast ARP 
> request from the PC and only one ARP reply.
> 
> In the meantime I enabled dat debug messages on one of my gateways 
between 
> the ethernet backbone and the mesh. After clearing the ARP cache of the 
PC 
> by the arp -d command, I see the following output of batctl l
> 
> Parsing outgoing ARP REQUEST
> ARP MSG : [src:  - 192.168.0.50 dst: 00:00:00:00:00:00 - 
> 192.168.0.101]
> Entry updated 192.168.0.50 
> ARP request replied locally
> ARP Request for 192.168.0.101: fallback prevented
> Parsing incoming ARP REPLY
> ARP MSG: [src:  - 192.168.0.101 dst:  
> - 192.168.0.50]
> * encapsulated within a UNICAST packet
> Entry updated: 192.168.0.101 
> Entry updated: 192.168.0.50 
> 
> followed by a flood of additional messages of similiar kind. From this 
> logging and from what I understood so far about bla and dat from 
> open-mesh.org and a short look into the source code I conclude, that the 

> gateway knew already 

Re: [B.A.T.M.A.N.] DAT broken in 2014.4.0?

2015-03-13 Thread Andreas Pape
Hello Antonio,

my mesh nodes use a wlan interface in adhoc mode as the only hard_if in 
bat0. bat0 is bridged to a Linux bridge br0 together with the Ethernet 
interface eth0. The wlan interface ath0 is not part of that bridge. The 
only interface having an ip address assigned is the bridge br0.

As mentioned I use 6 mesh nodes of that described setup of which 3 are 
only accessible via the mesh (eth0 interface not connected to any other 
Ethernet device) and 3 devices are connected with their eth Interfaces to 
the same Ethernet switch. The Windows PC is also connected to that same 
switch.

I am using batman-adv 2014.4.0 in combination with a fairly old Linux 
kernel 2.6.32.26 on an embedded device. If I enable BLA and DAT and send a 
ping from the Windows PC to one of the mesh nodes which is not connected 
to the Ethernet backbone, I see a multiplication of the ARP request sent 
by the PC and even a higher amount of corresponding ARP replies in the 
backbone network of which I am not sure, how much of them are really sent 
by the mesh node being the original destination for the ARP request. 
Furthermore I get lots of "bat0: received packet with own address as 
source address" and some "eth0: received " kernel log messages in that 
case as soon as the PC sends the first broadcast ARP request (after the 
mentioned arp -d command). 

If I disable DAT on all of my 6 devices the ARP telegrams being visible in 
the backbone network look normal to me. There is only one broadcast ARP 
request from the PC and only one ARP reply.

In the meantime I enabled dat debug messages on one of my gateways between 
the ethernet backbone and the mesh. After clearing the ARP cache of the PC 
by the arp -d command, I see the following output of batctl l

Parsing outgoing ARP REQUEST
ARP MSG : [src:  - 192.168.0.50 dst: 00:00:00:00:00:00 - 
192.168.0.101]
Entry updated 192.168.0.50 
ARP request replied locally
ARP Request for 192.168.0.101: fallback prevented
Parsing incoming ARP REPLY
ARP MSG: [src:  - 192.168.0.101 dst:  
- 192.168.0.50]
* encapsulated within a UNICAST packet
Entry updated: 192.168.0.101 
Entry updated: 192.168.0.50 

followed by a flood of additional messages of similiar kind. From this 
logging and from what I understood so far about bla and dat from 
open-mesh.org and a short look into the source code I conclude, that the 
gateway knew already the mac the PC was looking for ("ARP request replied 
locally") and did not forward it as a broadcast into the mesh. 
Nevertheless the gateway received an ARP reply from the mesh. I guess the 
original ARP request broadcast was forwarded at least by one of the 
remaining two backbone gateways into the mesh and a reply was sent by 
someone else (another mesh node with enabled dat or the mesh node being 
searched for).

This leads me to the question if using dat and a bla setup in combination 
is considered by design and if this should work or if dat is only 
reasonable to be used when a backbone network has a single gateway into 
the mesh (as depicted in the dat wiki on open-mesh.org) only. 

Thanks for the support and regards,
Andreas



Von:Antonio Quartulli 
An: The list for a Better Approach To Mobile Ad-hoc Networking 
, 
Datum:  13.03.2015 13:22
Betreff:Re: [B.A.T.M.A.N.] DAT broken in 2014.4.0?
Gesendet von:   "B.A.T.M.A.N" 



Hi Andreas,

so far we don't have any known DAT regression in 2014.4.0.

Could you please provide a more detailed description about your setup
including how the nodes have their bridges configured and what
interfaces have been added to batman-adv?

Thanks!

On 13/03/15 08:28, Andreas Pape wrote:
> Is there a known issue conerning the DAT functionality in batman-adv 
> 2014.4.0?
> 
> I have got a problem with looping ARP packets / multiplication of ARP 
> packets causing ARP storms in a setup with enabled DAT and BLA. My setup 

> consists of 6 mesh nodes of which 3 are connected to the same backbone 
> network. I connected a PC to the backbone which has an open ssh 
connection 
> to one ot the mesh nodes not connected to the backbone network directly. 

> Using arp -d to delete the ARP cache of the Windows PC forces the PC to 
> send an ARP request to the mesh node used for the ssh session. I can 
then 
> see multiple copies of that ARP request in the backbone in a wireshark 
> recording and also multiple ARP replies from the mesh node. 
> Sometimes also BLA gratuitous ARP telegrams seem to be looping, but it's 

> easier to force this behaviour with regular ARPs (via arp -d on a PC). 
> Non-ARP telegrams don't seem to be affected and except the waste of 
> bandwith in the mesh and backbone I don't have problems with normal 
> network communication in the mesh.
> 
> I could provide the mentioned wireshark recordings made in the backbone 
> network with a switch using port mirroring if someon

[B.A.T.M.A.N.] DAT broken in 2014.4.0?

2015-03-13 Thread Andreas Pape
Is there a known issue conerning the DAT functionality in batman-adv 
2014.4.0?

I have got a problem with looping ARP packets / multiplication of ARP 
packets causing ARP storms in a setup with enabled DAT and BLA. My setup 
consists of 6 mesh nodes of which 3 are connected to the same backbone 
network. I connected a PC to the backbone which has an open ssh connection 
to one ot the mesh nodes not connected to the backbone network directly. 
Using arp -d to delete the ARP cache of the Windows PC forces the PC to 
send an ARP request to the mesh node used for the ssh session. I can then 
see multiple copies of that ARP request in the backbone in a wireshark 
recording and also multiple ARP replies from the mesh node. 
Sometimes also BLA gratuitous ARP telegrams seem to be looping, but it's 
easier to force this behaviour with regular ARPs (via arp -d on a PC). 
Non-ARP telegrams don't seem to be affected and except the waste of 
bandwith in the mesh and backbone I don't have problems with normal 
network communication in the mesh.

I could provide the mentioned wireshark recordings made in the backbone 
network with a switch using port mirroring if someone explains how to 
provide such a file to the mailing list (I guess simple attachments are 
not allowed?).

If I disable DAT, everything looks fine again, i.e. no duplicated ARP 
telegrams anymore (except for a few ARP replies from the mesh node which 
are received twice, which could be a race for claiming the device?)..

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


[B.A.T.M.A.N.] Antwort: Re: Antwort: Re: Antwort: Antwort: Re: Antwort: Re: Question concerning batman-adv bug #173 "Mesh packets on bat0"

2015-02-19 Thread Andreas Pape
I started with a freshly unpacked source code of the 2014.4.0 release and 
applied only  your latest patch. 

As expected from the tests done so far with the old kernel effectively not 
calling netdev_set_master allows the usage of the latest batman-adv 
version in combination with older kernels (at least the 2.6.32 I tested 
with).

I think this patch is worth to be integrated into the next batman-adv 
version.

Regards,
Andreas


"B.A.T.M.A.N"  schrieb am 
19.02.2015 10:40:34:

> Von: Marek Lindner 
> An: The list for a Better Approach To Mobile Ad-hoc Networking 
> , 
> Datum: 19.02.2015 10:42
> Betreff: Re: [B.A.T.M.A.N.] Antwort: Re: Antwort: Antwort: Re: 
> Antwort: Re: Question concerning batman-adv bug #173 "Mesh packets on 
bat0"
> Gesendet von: "B.A.T.M.A.N" 
> 
> On Thursday, February 19, 2015 09:31:08 Andreas Pape wrote:
> > the problem seems to be a little bit more complex. Your latest patch 
does 
> > not solve the problem.
> > 
> > But I found out, that commenting out the following line in your patch 
> > makes bat0 work:
> > 
> > slave->master = master;
> > 
> > But as this is the core of "enslaving" a device to a master device, 
this 
> > breaks the complete concept behind this I guess (I'm not a skilled 
kernel 
> > developer). From this I conclude that there might be a bug somewhere 
> > deeper in the kernel version I use.  I don't want to give up too 
early, 
> > but it looks a little bit as if this "enslaving concept using rtnl" 
might 
> > not be usable in these older kernels. What do you think?
> 
> Please try the attached patch instead. This time we are replacing 
> the function 
> with our own function doing nothing at all. The net_dev->master 
> variable seems 
> to be reserved for interface bonding and shouldn't be touched at allon 
these 
> ancient kernels.
> 
> Cheers,
> Marek
> [Anhang "0001-batman-adv-ignore-netdev_set_master-calls-on-
> kernels.patch" gelöscht von Andreas Pape/Phoenix Contact] [Anhang 
> "signature.asc" gelöscht von Andreas Pape/Phoenix Contact] 


Re: [B.A.T.M.A.N.] Antwort: Re: Antwort: Antwort: Re: Antwort: Re: Question concerning batman-adv bug #173 "Mesh packets on bat0"

2015-02-19 Thread Andreas Pape
Hi Marek,

the problem seems to be a little bit more complex. Your latest patch does 
not solve the problem.

But I found out, that commenting out the following line in your patch 
makes bat0 work:

slave->master = master;

But as this is the core of "enslaving" a device to a master device, this 
breaks the complete concept behind this I guess (I'm not a skilled kernel 
developer). From this I conclude that there might be a bug somewhere 
deeper in the kernel version I use.  I don't want to give up too early, 
but it looks a little bit as if this "enslaving concept using rtnl" might 
not be usable in these older kernels. What do you think?

Regards,
Andreas



[B.A.T.M.A.N.] Antwort: Re: Antwort: Antwort: Re: Antwort: Re: Question concerning batman-adv bug #173 "Mesh packets on bat0"

2015-02-18 Thread Andreas Pape
Hi Marek,

I reverted the changes step by step starting with patch 
0002-remove-netdev_calls.patch, as patch 1 did not help and patch 3 
containes in compat.h and soft-interface.c, I tried out myself earlier 
today.

The essential call is in patch 2 as assumed. As soon as I add the 
netdev_master_upper_dev_link call again to the compilable code, the 
problem starts to occur (mesh doesn't work as soon as bat0 is added to the 
bridge, ogm packets can be seen at bat0). It seems that this call behaves 
in older kernels different compared to newer ones.

I haven't tried to add all the other excluded parts again except for the 
netdev_master_upper_dev_link call. If you are interested I can test this 
tomorrow, too.

Regards,
Andreas



[B.A.T.M.A.N.] Antwort: Antwort: Re: Antwort: Re: Question concerning batman-adv bug #173 "Mesh packets on bat0"

2015-02-18 Thread Andreas Pape
Hi Marek,

good news: the sum of the three patches you sent solved the problem as far 
as I have tested yet. Now bat0 works in combination with the bridge and 
also ethernet traffic is bridged into the mini-mesh setup I use correctly. 
Furthermore there are no ogm messages visible anymore at bat0 (with the 
command batctl td bat0).

Do you see a chance to add these changes to the compatibility code for 
older kernels (I guess for kernels < 2.6.39)?

Thanks for the excellent help,
Andreas



[B.A.T.M.A.N.] Antwort: Re: Antwort: Re: Question concerning batman-adv bug #173 "Mesh packets on bat0"

2015-02-18 Thread Andreas Pape
>At this point the mesh is working to your expectation ? Can you transport 

>payload across the mesh ? If so, this is a deviation from #173 - wouldn't 
you 
>agree ?

Before adding bat0 to the bridge br0 I can communicate via the mesh 
interface. I configured ip addresses for the bat0 interfaces on my devices 
and the ping worked without problems. But I understood from #173 that 
pinging was possible in that case, too. I'm referring to #173 because I 
can see the ogm messages received via wlan also at the bat0 interface, 
which was not the case in 2013.1.0 and earlier - if I remember my tests 
correctly...

In the meantime I found out that not only batman-adv stops receiving the 
ogm messages at ath0 but also the wpa_supplicant does not receive EAPOL 
frames any more as soon as bat0 is attached to the bridge br0 if I try to 
use WPA with the mesh interface (wpa_supplicant -i ath0). But I can see 
the EAPOL frames at the bridge interface br0 (via batctl td br0). Strange.

I'll come back to you as soon as I have tested your latest patches.

Thanks for your support,
Andreas





[B.A.T.M.A.N.] Antwort: Re: Question concerning batman-adv bug #173 "Mesh packets on bat0"

2015-02-18 Thread Andreas Pape
Hi,

I adapted your patch to batman-adv-2014.4.0 without success. I got the 
additional issue that with the patched version of batman-adv I was not 
able to destroy the virtual wireless interface anymore used fot the adhoc 
connection over which I try to use batman-adv (error message was: 
unregister_netdevice: waiting for ath0 to become free). 

With the unpatched 2014.4.0 I did the following test on two of my devices:

1. created a virtual wireless interface ath0 in adhoc mode
2. iwconfig ath0 essid TEST
3. iwconfig ath0 channel 40
4. ifconfig ath0 up
5. batctl if add ath0

After this the two devices connected and I could see the repective 
neighbor via the batctl o command on both devices. So far so good. 
But I can see via batctl td bat0 OGM packets sent with the MAC address of 
the wlan interface of the device itself and also from the neigbour this 
device is connected to via wlan. Is this OK?

6. Generating a bridge interface via brctl addbr br0
7. add bat0 interface to bridge via brctl addif br0 bat0

As soon as I do this, the batadv_batman_skb_recv isn't called anymore 
(I've put a printk at the beginning of that function for debugging). 
Furthermore batctl o shows that the mesh communication starts timing out 
(last seen time for the originator/neighbor exceeds the ogm send interval 
and increases continuously).

The interesting point in this state is, that batctl td bat0 still shows 
the reception of ogm messages from the neighbour and from the own wlan 
interface as mentioned above.

As mentioned I use a kernel version 2.6.32.26 and batman-adv/batctl 
versions up to 2013.1.0 work with the same configuration steps. 

Thanks for the support,
Andreas





Von:Marek Lindner 
An: The list for a Better Approach To Mobile Ad-hoc Networking 
, 
Datum:  18.02.2015 12:28
Betreff:Re: [B.A.T.M.A.N.] Question concerning batman-adv bug #173 
"Mesh   packets on bat0"
Gesendet von:   "B.A.T.M.A.N" 



On Wednesday, February 18, 2015 08:35:49 Andreas Pape wrote:
> I'm interested if there is any progress concerning the bug entry #173 (
> http://www.open-mesh.org/issues/173). 
> 
> I'm currently observing something similiar on an embedded system running 

> an older kernel 2.6.32.26. Batman-adv versions up to 2013.1.0 work 
> flawlessly out of the box. All newer versions show the phenomenon 
> described in bug #173. 
> In my case I found out, that the batadv_batman_skb_recv function is 
never 
> called again as soon as I add bat0 to the bridge interface I use. 
> If I use the bat0 interface outside a bridge, everything works fine up 
to 
> the latest version I tested (which was 2014.4.0) even with the old 
kernel 
> version. 

Can you please try the attached patch and check whether it makes any 
difference? If the symptoms are the same, please provide step-by-step 
instructions how you create / configure your interfaces.

Thanks,
Marek
[Anhang "0001-do-not-call-master-netdev_ops-ndo_init.patch" gelöscht von 
Andreas Pape/Phoenix Contact] [Anhang "signature.asc" gelöscht von Andreas 
Pape/Phoenix Contact] 



[B.A.T.M.A.N.] Question concerning batman-adv bug #173 "Mesh packets on bat0"

2015-02-17 Thread Andreas Pape
Hello everybody, 

I'm interested if there is any progress concerning the bug entry #173 (
http://www.open-mesh.org/issues/173). 

I'm currently observing something similiar on an embedded system running 
an older kernel 2.6.32.26. Batman-adv versions up to 2013.1.0 work 
flawlessly out of the box. All newer versions show the phenomenon 
described in bug #173. 
In my case I found out, that the batadv_batman_skb_recv function is never 
called again as soon as I add bat0 to the bridge interface I use. 
If I use the bat0 interface outside a bridge, everything works fine up to 
the latest version I tested (which was 2014.4.0) even with the old kernel 
version. 

Regards, 
Andreas Pape