gmane.org.freifunk.batman

Re: [PATCHv3 2/3] batman-adv: Receive fragmented packets and merge

Martin Hundebøll — 2013-05-23T05:07:49

Hi Antonio,

Thanks for your carefull reviews!

On 2013-05-21 21:10, Antonio Quartulli wrote:

True.


I would say so, yes, since batadv_send_skb_packet() will add an ethernet 
header to the packet before transmitting it.


Will do so and send another revision...

[PATCH] batman-adv: forward late OGMs from best nexthop

Simon Wunderlich — 2013-05-22T18:46:17

From: Simon Wunderlich <simon-2BnEqQcu77q1Z/+hSey0Gg< at >public.gmane.org>

When a packet is received from another node first and later from the
best next hop, this packet is dropped. However the first OGM was sent
with the BATADV_NOT_BEST_NEXT_HOP flag and thus dropped by neighbors.
The late OGM from the best neighbor is then dropped because it is a
duplicate.

If this situation happens constantly, a node might end up not forwarding
the "valid" OGMs anymore, and nodes behind will starve from not getting
valid OGMs.

Fix this by changing the is_duplicate behaviour: It will only mark
duplicates which are received for the same neighbor. OGMs which are not
from the best next hop will be dropped within batadv_iv_ogm_forward()
anyway. Therefore, late OGMs are forwarded now and not dropped as
duplicates.

Signed-off-by: Simon Wunderlich <simon-2BnEqQcu77q1Z/+hSey0Gg< at >public.gmane.org>
Signed-off-by: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ< at >public.gmane.org>
---
 bat_iv_ogm.c |   16 ++++++++--------
 1 file chang

Re: (no subject)

Antonio Quartulli — 2013-05-21T19:56:26

Sorry but git-send-email fooled me. Subject was supposed to be:

pull request for net: batman-adv 2013-05-21

Regards,

(no subject)

Antonio Quartulli — 2013-05-21T19:53:54

Hello David,

this is another small patch for net/linux-3.10. It is preventing a double free
of the bat_counters in case of mesh initialisation failure.

Sorry for sending such small pull requests (I guess this is not that bad since
they target net :-)), but these are small glitches we are finding while testing
new features.

Please pull or let me know if there is any problem.

Thanks a lot,
Antonio


The following changes since commit 3ccfc1b1d2fa78f8ece83646027982916fcc794b:

  Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless (2013-05-20 14:05:22 -0700)

are available in the git repository at:


  git://git.open-mesh.org/linux-merge.git tags/batman-adv-fix-for-davem

for you to fetch changes up to f69ae770e74df420fbcf93aae81b30a5dcc73b7d:

  batman-adv: Avoid double freeing of bat_counters (2013-05-21 21:34:36 +0200)

----------------------------------------------------------------
Included change:
- fix double free in case of failure during mesh initialisation

Re: [PATCHv3 3/3] batman-adv: Fragment and send skbs larger than mtu

Antonio Quartulli — 2013-05-21T19:19:26

here we are copying the data right after the Fragment header. However I am not
sure we are accessing aligned memory because:

ETH_HLEN + header_size = 14 + 20 = 34

To speed up the copy, wouldn't it be better to allocate ETH_HLEN +
header_size + IP_ALIGN bytes like we do for other packets? (you can use
netdev_alloc_skb_ip_align() like we do somewhere else).

In this way the memcpy will access a 4bytes aligned memory (if I am not wrong).

Can somebody else comment on this?



if mtu is unsigned (int), why not using unsigned (int) inside the min_t
function?


Like int he previous patch: do we really need to count ETH_HLEN? (I'm not sure
about this)

Thanks again :)

Re: [PATCHv3 2/3] batman-adv: Receive fragmented packets and merge

Antonio Quartulli — 2013-05-21T19:10:11

I guess here you forgot to remove the ETH_LEN from the total_size computation.


and here should ETH_HLEN be counted in the amount of bytes sent?

Moreover we are always avoiding third person in kernel doc ("Returns" should be
"Return" and so on..) and you should not put () (in the kernel doc).


Cheers,

[PATCHv3 2/3] batman-adv: Receive fragmented packetsand merge

Martin Hundebøll — 2013-05-21T10:48:18

Fragments arriving at their destination are buffered for later merge.
Merged packets are passed to the main receive function as had they never
been fragmented.

Fragments are forwarded without merging if the MTU of the outgoing
interface is smaller than the size of the merged packet.

Signed-off-by: Martin Hundebøll <martin-SHBFXCSm21MJGwgDXS7ZQA< at >public.gmane.org>
---

v2:
update copyright years
remove () and uppercase beginnings from kernel doc
use hlist_for_entry_safe() in batadv_frag_clear_list()
merge batadv_frag_clear_orig() and batadv_frag_check_orig()
update some kernel doc with return values
remove "inline" from static function in .c file
rename lists of fragments to "chain"
remove type in kernel doc
remove initialization from "curr" and "new" in insert_packet()
rename "curr" and "new" to "frag_entry_{curr,new}"
rename packet to frag_packet
change return description in kernel doc for batadv_frag_merge_packets()
fix return value on failure in pskb_expand_head() in merge_packets()
add kernel doc for c

[PATCHv3 3/3] batman-adv: Fragment and send skbslarger than mtu

Martin Hundebøll — 2013-05-21T10:48:19

Non-broadcast packets larger than MTU are fragmented and sent with
an encapsulating header. Up to 16 fragments are supported, which are
sent in reverse order on the wire to allow minimal memory copying when
creating fragments.

Signed-off-by: Martin Hundebøll <martin-SHBFXCSm21MJGwgDXS7ZQA< at >public.gmane.org>
---

v2:
change commit message to explain the reverse order of packets
remove parentheses and capital letters from kernel doc
merge return statement for batadv_frag_create()
add spaces around *-multiplication
add kernel doc for FRAG_TX counters and frag_seqno

v3:
fix the use of ETH_HLEN when creating fragments
remove ETH_HLEN when checking whether to fragment a packet

 fragmentation.c  | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 fragmentation.h  |   3 ++
 send.c           |  21 ++++++++--
 soft-interface.c |   7 ++++
 types.h          |   6 +++
 5 files changed, 152 insertions(+), 4 deletions(-)

diff --git a/fragmentation.c b/fragmentation.c
index 8f47af7..b7f374a 100644
--- a/fragm

[PATCHv3 0/3] Fragmentation version 2

Martin Hundebøll — 2013-05-21T10:48:16

These are the second revision of a few patches to remove the current fragmentation code and replace it with a new version that supports more packet types and more fragments per packet, thus allowing bigger payloads.

The patches are based on current master and are meant for the next big bump in compat number. Revision 3 is changed according to Antonios review.

Martin Hundebøll (3):
  batman-adv: Remove old fragmentation code
  batman-adv: Receive fragmented packets and merge
  batman-adv: Fragment and send skbs larger than mtu

 Makefile.kbuild         |   2 +-
 distributed-arp-table.c |  11 +-
 fragmentation.c         | 485 ++++++++++++++++++++++++++++++++++++++++++++++++
 fragmentation.h         |  50 +++++
 hard-interface.c        |   1 -
 main.c                  |   8 +-
 main.h                  |   9 +
 originator.c            |  19 +-
 packet.h                |  41 ++--
 routing.c               | 145 ++++++---------
 routing.h               |   4 +-
 send.c                  | 195 ++++++++++++++++++-

[PATCHv3 1/3] batman-adv: Remove old fragmentationcode

Martin Hundebøll — 2013-05-21T10:48:17

Remove the existing fragmentation code before adding the new version
and delete unicast.{h,c}.

batadv_unicast_send_skb() is moved to send.c and renamed to
batadv_send_skb_unicast().

fragmentation entry in sysfs (bat_priv->fragmentation) is kept for use in
the new fragmentation code.

BATADV_UNICAST_FRAG packet type is renamed to BATADV_FRAG for use in the
new fragmentation code.

Signed-off-by: Martin Hundebøll <martin-SHBFXCSm21MJGwgDXS7ZQA< at >public.gmane.org>
---

v2:
 unmangle function names with 4addr_unicast
 correctly indent kernel doc

v3:
 add line before return statement in batadv_send_skb_prepare_unicast()

 Makefile.kbuild         |   1 -
 distributed-arp-table.c |  11 +-
 hard-interface.c        |   1 -
 main.c                  |   4 -
 originator.c            |   9 -
 packet.h                |  16 --
 routing.c               |  86 +--------
 routing.h               |   2 -
 send.c                  | 174 ++++++++++++++++++
 send.h                  |  36 ++++
 soft-interface.c        |   4 +-
 ty

Fwd: Re: [Freifunk.luebeck-devel] [Freifunk-Bonn] Oncompat version 15 in the Freifunk-KBU network

Jan Luehr — 2013-05-19T13:27:39

Hello,

sorry for forwarding - mail got filtered...

Betreff: Re: [Freifunk.luebeck-devel] [Freifunk-Bonn] [B.A.T.M.A.N.] On 
compat version 15 in the Freifunk-KBU network
Datum: Sun, 19 May 2013 14:49:45 +0200
Von: Jan Lühr <ff-AZFU/thigg6zQB+pC5nmwQ< at >public.gmane.org>
An: "Allgemeine Mailingliste zum Freifunk Köln, Bonn und Umgebung" 
<freifunk-bonn-q6ZjaXuubFi9DNP9GERekoEcw8ps7dj6< at >public.gmane.org>
CC: The list for a Better Approach To Mobile Ad-hoc Networking 
<b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r< at >public.gmane.org>, 
freifunk.luebeck-devel-JsS6xtS4dxH1vcKNnN/DQhvVK+yQ3ZXh< at >public.gmane.org



Hello,

Am 19.05.2013 um 12:40 schrieb Simon Wunderlich:

(...)

Thanks for your detailed answer - I'll cut some parts for better readability.

(...)

(...) - yes, I know. Theses nodes are quite old. I guess this somewhat illustrates the upcoming situation.


Thanks for the details. I understand your reasons for changing the protocol - and I'm perfectly fine with that. I know that manets are an area of

Re: On compat version 15 in the Freifunk-KBU network

Marek Lindner — 2013-05-19T13:05:40

Hi,

Simon answered most of the raised points already but I'd like to emphasize 
this statement a litte:



Recently, we discussed a stable release policy on IRC with T_X as you might 
have seen. We (as batman developers) are very much in favor of longterm stable 
release maintained by someone. You could backport kernel support or even 
critical fixes. We will surely help anyone willing to take on this task. The 
respository can be hosted on open-mesh.org and you can even write 
announcements to let others know about your work.

Of course, you can also host it elsewhere and do all the work on your own but 
then it will be harder for others to find your work.

Cheers,
Marek

Re: [PATCHv4] batman-adv: use htons when possible

Simon Wunderlich — 2013-05-19T11:52:25

Looks good, using htons is a lot better. :)

Acked-by: Simon Wunderlich <siwu-MaAgPAbsBIVS8oHt8HbXEIQuADTiUCJX< at >public.gmane.org>

[PATCHv4] batman-adv: use htons when possible

Antonio Quartulli — 2013-05-19T10:55:16

When comparing a network ordered value with a constant, it
is better to convert the constant at compile time by means
of htons() instead of converting the value at runtime using
ntohs().

This refactoring may slightly improve the code performance.

Moreover substitute __constant_htons() with htons() since
the latter increase readability and it is smart enough to be
as efficient as the former

Signed-off-by: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ< at >public.gmane.org>
---

v2:
- patch rebased on top of
"batman-adv: use VLAN_ETH_HLEN instead of sizeof(struct vlan_eth_hdr)"

v3:
- use __constant* for vlan_insert_tag() argument

v4:
- use htons instead of __constant_htons

 bridge_loop_avoidance.c | 12 ++++++------
 gateway_client.c        | 14 +++++++-------
 hard-interface.c        |  2 +-
 send.c                  |  4 ++--
 soft-interface.c        |  4 ++--
 5 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/bridge_loop_avoidance.c b/bridge_loop_avoidance.c
index 9e691b0..ab537ec 100644
---

Alfred Open Beta

Simon Wunderlich — 2013-05-19T10:50:34

To those of you who actively follow the recent discussions it may come to no
big surprise that it was decided to remove the vis functionality from the
batman-adv kernel module in a not so distant future (with the next
compatibility bump). There always has been a debate whether or not such
functionality belongs into the kernel or not. The in-kernel solution bears the
disadvantage of being rather inflexible because every change has to go through
the official Linux channels. With the growing interest in flooding the network
with arbitrary data in addition to the visualization data realizing a solution
in user-space became the obvious choice.

A new, more general user-space daemon which takes over the old vis
functionality and much more, called A.L.F.R.E.D. (Almighty Lightweight Fact
Remote Exchange Daemon) came to life. Alfred is capable of distributing
information over your mesh network in a decentralized fashion, for example
graph information for vis, but also any other data which appears to be useful
- like

Re: On compat version 15 in the Freifunk-KBU network

Simon Wunderlich — 2013-05-19T10:40:07

Hello yanosz,

On Sun, May 19, 2013 at 10:52:01AM +0200, Jan Lühr wrote:

Thanks for your feedback. Yes, we are preparing a compat bump (actually for a long time now) and it's good to discuss it. :)


We are very well aware that a compat change is a huge burden especially on community networks, which have
more troubles to reach all nodes. But the compat change was designed to stop "bumping" the whole network
all the time but upgrading/adding features individually. More on that below.

Btw, it's interesting that you use compat version 13  - only one release had that included, and we are
on compat 14 for quite some time ...

[1] http://www.open-mesh.org/projects/batman-adv/wiki/Compatversion

Actually, that is one of the main design targets. We are aware that with our current packet type design,
we cannot change even parts of the protocol without breaking compatibility. This has bothered us for quite
some time and we have worked on solutions to prevent compat bumps as good as possible. We have introduced
diff

Re: [PATCHv3] batman-adv: use __constant_htons when possible

Antonio Quartulli — 2013-05-19T10:27:14

After discussing with Simon, we realised that using __constant_htons is useless
since htons is smart enough to be as efficient as his brother __constant*.

Therefore this patch will be re-arranged to use htons only.
It will still remove some ntohs and make use of htons at their place.


Cheers,

On compat version 15 in the Freifunk-KBU network

Jan Lühr — 2013-05-19T08:52:01

Hello folks,

I'd like to give some thought's for the upcoming batman-adv release, especially on compat version 15. This somewhat summarizes my discussion with T_X on the wireless community weekend (WCW -- 2013-05-10 - 2013-05-12). As some of you may know already, we're running a small freifunk network in western Germany (Köln-Bonn-area) - about ~100 nodes in total; ~40 are online at the moment.
It's not my intention to bash on batman-adv in general or to start flame-wars (like: batman-adv vs. olsr or something else) - I'd like to provide some statement on the impact of the upcoming protocol changes.

1. The upcoming protocol change appears to be painful - we have no suitable migration strategy.
Compat version 14 and 15 will be incompatible. Nodes will loose mesh connectivity (to older nodes). Since we cannot upgrade all nodes at once, we'll have to run different networks in parallel.
In fact, we're running two networks at the moment (compat 13 and 14). We aren't able to upgrade the existing compat 13 nodes

[PATCHv2] batman-adv: create common header for ICMPpackets

Antonio Quartulli — 2013-05-18T12:56:57

From: Antonio Quartulli <antonio-2BnEqQcu77q1Z/+hSey0Gg< at >public.gmane.org>

the icmp and the icmp_rr packets share the same initial
fields since they use the same code to be processed and
forwarded.

Extract the common fields and put them into a separate
struct so that future ICMP packets can be easily added
without bloating the packet definition.

However, keep the seqno field outside of the newly created
common header because future ICMP types may require a
bigger sequence number space.

This change breaks compatibility due to fields reordering
in the ICMP headers.

Signed-off-by: Antonio Quartulli <antonio-2BnEqQcu77q1Z/+hSey0Gg< at >public.gmane.org>
---


v2:
- merge of
[PATCH 1/2] batman-adv: simplify ICMP packet structures
and
[PATCH 2/2] batman-adv: move seqno field outside of the common ICMP header

- reword commit subject and message
- rename the new member from "ih" to "icmph"



 icmp_socket.c | 22 +++++++++++-----------
 main.c        |  4 ++--
 packet.h      | 38 ++++++++++++++++++++++++++++---------

Re: [PATCH] batctl: fix typos in error messages

Marek Lindner — 2013-05-18T10:53:09

Applied in revision 2f65f34.

Thanks,
Marek

Re: [PATCH] batman-adv: use VLAN_ETH_HLEN instead ofsizeof(struct vlan_eth_hdr)

Marek Lindner — 2013-05-18T10:14:01

Applied in revision 925be3e.

Thanks,
Marek