Re: [B.A.T.M.A.N.] [PATCH 3/3] batman-adv: Add sequence number and duplicate checks for unicasts

Re: [B.A.T.M.A.N.] [PATCH 3/3] batman-adv: Add sequence number and duplicate checks for unicasts

[Sven Eckelmann]

[-- Attachment #1: Type: Text/Plain, Size: 283 bytes --]

On Sunday 07 November 2010 17:46:01 Linus Lüssing wrote:
>  /* this file is included by batctl which needs these defines */
> -#define COMPAT_VERSION 12
> +#define COMPAT_VERSION 13\

Please increase that to 14. 13 is already used in linux 2.6.37(-rc1)

Best regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[B.A.T.M.A.N.] batman-adv: promisc destination reception

[Linus Lüssing]

Hi everyone!

I've recently been wondering, if promiscuous packet reception could be used to
enhance the probability of receiving data packets. The idea behind it is, to
not feel bothered by the broadcast characteristic of WiFi but instead utilising
this fact (it's a little bit inspired by COPE which also "exploits the broadcast
property of radios instead of hiding it under an artificial abstraction"[1]).

The good thing about batman-adv is, that it is running in kernelspace and we have
batman packet headers around the data already, so we are technically able to have
a glance at all the packets we are receiving on the WiFi interface (which would
not be doable in userspace on embedded devices).

The following rather simple patches are adding sequence numbers and duplicate
checks for unicast data packets as well as the possiblity to receive unicast
packets promiscuously on the final destination node. Especially in circular
topologies like [2], this boosts the probability of reception from 53.1441%
to ~99.7937% for instance with no additional packet overhead needed despite the
unicast sequence numbers + originator address.

With the planned neighbor discovery protocol and the 2-hop-neighbourhood
information it provides, the probability could be boosted even further, even in
non-circular topologies.


However, I'm still having quite some difficulties with getting the desired
effect in a VM setup. I'm not quite sure yet if this is an issue of these few
patches, the setup configuration(, the hash-implementation in the trunk) or a routing
issue. See the setup details below.

Cheers, Linus

[1]: XORs in the air: practical wireless network coding
by: Sachin Katti, Hariharan Rahul, Wenjun Hu, Dina Katabi, Muriel Médard, Jon
Crowcroft
[2]: http://x-realis.dyndns.org/freifunk/circle-promisc-13-nodes.png

-----
I've tried to test and validate the assumptions in the following three node
topology (with a "hub/broadcast" nature on C's links at least)

A  -- 90% -- B
  \         /
  90%    60%
     \   /
      C

Where I'd expect to have (0.9 * 0.9)^2 = 0.6561 sucessful icmp replies with
ping without the patches, and ((0.9 * 0.9) + (1 - 0.9 * 0.9) * 0.6)^2 = 0.853776
sucessful icmp replies with ping and with the patches.

For the actual setup, I've started three VMs, with A and B having two
interfaces, vmtap1 and vmtap2, vmtap4 and vmtap5 and C having just one, vmtap7.
They're bridged like this:
---
mesh0           8000.7a538525c787       no              vmtap1
                                                        vmtap4
mesh1           8000.1a48b2e5ec2d       no              vmtap2
                                                        vmtap5
                                                        vmtap7
---
and "brctl setageing mesh0/1 0" to simulate a hub.

I simulated the link qualities stated above with tc inside of the VMs:
ssh vm1 "sudo tc qdisc add dev eth1 root netem loss 10%"
ssh vm1 "sudo tc qdisc add dev eth2 root netem loss 10%"
ssh vm2 "sudo tc qdisc add dev eth2 root netem loss 40%"

What I further did, is setting the hop penalty to 0, to force C to only send to
B via A and to force B to only send to C via A too and to avoid tc's flakiness,
which resulted to one-hop-connections between C and B quite often. I verified,

However, when I'm now trying to ping from B to C now, C receives B's icmp
sucessfully but B does not receive the reply.

My first guess was, the first thing that seemed odd to me was, that the
hash_find() in check_duplicate() returned NULL quite often on B according to
some printk()s, resulting in dropped packets - but that turned out to be the own
packet from B which was just sent and now also received promiscuously right away
again.

Well, probably I'm just having something in the patches or setup wrong, I'm
going to do some more tests with some more printk()s. However, if someone can
spot something weird or would like to test the patches already, I'd be happy
about any feedback :).

[B.A.T.M.A.N.] [PATCH 1/3] batman-adv: Allow promiscuous reception of unicast packets

[Linus Lüssing]

From: Linus Lüssing <linus.luessing@ascom.ch>

A very mobile node may want to enable this to increase the probability
of unicast data reception on the last hop, especially when such a mobile
node moves towards the sender.

The mobile node needs to place its hard-interfaces utilized by
batman-adv into promisc-mode to let this optimization take effect. Be
aware, that doing so will cost your devices more processing power.

It also increases the probability of succesful reception a lot, if there
are (multiple) shorter, alternate but slightly "worse" paths, too. As
WiFi is a broadcast medium, there can be a quite good chance to receive
a packet from one of the nodes on the path to the receiver already.

Luckily batman-adv is running in kernelspace, therefore it does not make
much of a performance difference, even on embedded devices.

To let this feature take effect, place your WiFi interface in
promiscuous mode (e.g. 'ip link set wlan0 promisc on'/'ifconfig wlan0
promisc').

Signed-off-by: Linus Lüssing <linus.luessing@ascom.ch>
---
 routing.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/routing.c b/routing.c
index e75337d..b61821a 100644
--- a/routing.c
+++ b/routing.c
@@ -1124,7 +1124,7 @@ static int check_unicast_packet(struct sk_buff *skb, int hdr_size)
 
 	/* not for me */
 	if (!is_my_mac(ethhdr->h_dest))
-		return -1;
+		return 1;
 
 	return 0;
 }
@@ -1214,8 +1214,10 @@ int recv_unicast_packet(struct sk_buff *skb, struct batman_if *recv_if)
 {
 	struct unicast_packet *unicast_packet;
 	int hdr_size = sizeof(struct unicast_packet);
+	int check_ret;
 
-	if (check_unicast_packet(skb, hdr_size) < 0)
+	check_ret = check_unicast_packet(skb, hdr_size);
+	if (check_ret < 0)
 		return NET_RX_DROP;
 
 	unicast_packet = (struct unicast_packet *)skb->data;
@@ -1226,6 +1228,9 @@ int recv_unicast_packet(struct sk_buff *skb, struct batman_if *recv_if)
 		return NET_RX_SUCCESS;
 	}
 
+	if (check_ret)
+		return NET_RX_DROP;
+
 	return route_unicast_packet(skb, recv_if, hdr_size);
 }
 
@@ -1235,9 +1240,10 @@ int recv_ucast_frag_packet(struct sk_buff *skb, struct batman_if *recv_if)
 	struct unicast_frag_packet *unicast_packet;
 	int hdr_size = sizeof(struct unicast_frag_packet);
 	struct sk_buff *new_skb = NULL;
-	int ret;
+	int ret, check_ret;
 
-	if (check_unicast_packet(skb, hdr_size) < 0)
+	check_ret = check_unicast_packet(skb, hdr_size);
+	if (check_ret < 0)
 		return NET_RX_DROP;
 
 	unicast_packet = (struct unicast_frag_packet *)skb->data;
@@ -1259,6 +1265,9 @@ int recv_ucast_frag_packet(struct sk_buff *skb, struct batman_if *recv_if)
 		return NET_RX_SUCCESS;
 	}
 
+	if (check_ret)
+		return NET_RX_DROP;
+
 	return route_unicast_packet(skb, recv_if, hdr_size);
 }
 
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 2/3] batman-adv: Generic sequence number checking for data packets

[Linus Lüssing]

From: Linus Lüssing <linus.luessing@ascom.ch>

This reduces the size of recv_bcast_packet, increasing its readability.
It further introduces a generic function for duplicate checking for data
packets (which might later be used for multicast or promiscous unicast
packet handling or other packets).

Signed-off-by: Linus Lüssing <linus.luessing@ascom.ch>
---
 originator.c |    2 +-
 routing.c    |   86 +++++++++++++++++++++++++++++++++++----------------------
 types.h      |   10 +++++--
 3 files changed, 61 insertions(+), 37 deletions(-)

diff --git a/originator.c b/originator.c
index 8930446..e888416 100644
--- a/originator.c
+++ b/originator.c
@@ -147,7 +147,7 @@ struct orig_node *get_orig_node(struct bat_priv *bat_priv, uint8_t *addr)
 	memcpy(orig_node->orig, addr, ETH_ALEN);
 	orig_node->router = NULL;
 	orig_node->hna_buff = NULL;
-	orig_node->bcast_seqno_reset = jiffies - 1
+	orig_node->bcast_seqno_state.seqno_reset = jiffies - 1
 					- msecs_to_jiffies(RESET_PROTECTION_MS);
 	orig_node->batman_seqno_reset = jiffies - 1
 					- msecs_to_jiffies(RESET_PROTECTION_MS);
diff --git a/routing.c b/routing.c
index b61821a..761fd84 100644
--- a/routing.c
+++ b/routing.c
@@ -1129,6 +1129,55 @@ static int check_unicast_packet(struct sk_buff *skb, int hdr_size)
 	return 0;
 }
 
+static inline int check_duplicate(struct bat_priv *bat_priv, uint8_t *orig,
+				  uint32_t seqno, uint8_t packet_type)
+{
+	struct orig_node *orig_node;
+	struct seqno_state *seqno_state;
+	int32_t seq_diff;
+	int ret = 1;
+
+	spin_lock_bh(&bat_priv->orig_hash_lock);
+	orig_node = ((struct orig_node *)
+		     hash_find(bat_priv->orig_hash, compare_orig, choose_orig,
+			       orig));
+
+	switch (packet_type) {
+		case BAT_BCAST:
+			seqno_state = &orig_node->bcast_seqno_state;
+			break;
+		default:
+			goto out;
+	}
+
+	if (orig_node == NULL)
+		goto out;
+
+	/* check whether the packet is a duplicate */
+	if (get_bit_status(seqno_state->bits,
+			   seqno_state->last_seqno,
+			   seqno))
+		goto out;
+
+	seq_diff = seqno - seqno_state->last_seqno;
+
+	/* check whether the packet is old and the host just restarted. */
+	if (window_protected(bat_priv, seq_diff,
+			     &seqno_state->seqno_reset))
+		goto out;
+
+	/* mark broadcast in flood history, update window position
+	 * if required. */
+	if (bit_get_packet(bat_priv, seqno_state->bits, seq_diff, 1))
+		seqno_state->last_seqno = seqno;
+
+	ret = 0;
+
+out:
+	spin_unlock_bh(&bat_priv->orig_hash_lock);
+	return ret;
+}
+
 int route_unicast_packet(struct sk_buff *skb, struct batman_if *recv_if,
 			 int hdr_size)
 {
@@ -1275,11 +1324,10 @@ int recv_ucast_frag_packet(struct sk_buff *skb, struct batman_if *recv_if)
 int recv_bcast_packet(struct sk_buff *skb, struct batman_if *recv_if)
 {
 	struct bat_priv *bat_priv = netdev_priv(recv_if->soft_iface);
-	struct orig_node *orig_node;
 	struct bcast_packet *bcast_packet;
 	struct ethhdr *ethhdr;
 	int hdr_size = sizeof(struct bcast_packet);
-	int32_t seq_diff;
+	int ret;
 
 	/* drop packet if it has not necessary minimum size */
 	if (unlikely(!pskb_may_pull(skb, hdr_size)))
@@ -1308,39 +1356,11 @@ int recv_bcast_packet(struct sk_buff *skb, struct batman_if *recv_if)
 	if (bcast_packet->ttl < 2)
 		return NET_RX_DROP;
 
-	spin_lock_bh(&bat_priv->orig_hash_lock);
-	orig_node = ((struct orig_node *)
-		     hash_find(bat_priv->orig_hash, compare_orig, choose_orig,
-			       bcast_packet->orig));
-
-	if (orig_node == NULL) {
-		spin_unlock_bh(&bat_priv->orig_hash_lock);
+	ret = check_duplicate(bat_priv, bcast_packet->orig,
+			      ntohl(bcast_packet->seqno), BAT_BCAST);
+	if (ret)
 		return NET_RX_DROP;
-	}
 
-	/* check whether the packet is a duplicate */
-	if (get_bit_status(orig_node->bcast_bits,
-			   orig_node->last_bcast_seqno,
-			   ntohl(bcast_packet->seqno))) {
-		spin_unlock_bh(&bat_priv->orig_hash_lock);
-		return NET_RX_DROP;
-	}
-
-	seq_diff = ntohl(bcast_packet->seqno) - orig_node->last_bcast_seqno;
-
-	/* check whether the packet is old and the host just restarted. */
-	if (window_protected(bat_priv, seq_diff,
-			     &orig_node->bcast_seqno_reset)) {
-		spin_unlock_bh(&bat_priv->orig_hash_lock);
-		return NET_RX_DROP;
-	}
-
-	/* mark broadcast in flood history, update window position
-	 * if required. */
-	if (bit_get_packet(bat_priv, orig_node->bcast_bits, seq_diff, 1))
-		orig_node->last_bcast_seqno = ntohl(bcast_packet->seqno);
-
-	spin_unlock_bh(&bat_priv->orig_hash_lock);
 	/* rebroadcast packet */
 	add_bcast_packet_to_list(bat_priv, skb);
 
diff --git a/types.h b/types.h
index 2678ce1..87eb780 100644
--- a/types.h
+++ b/types.h
@@ -49,6 +49,12 @@ struct batman_if {
 	struct rcu_head rcu;
 };
 
+struct seqno_state {
+	unsigned long seqno_reset;
+	uint32_t last_seqno;
+	TYPE_OF_WORD bits[NUM_WORDS];
+};
+
 /**
  *	orig_node - structure for orig_list maintaining nodes of mesh
  *	@primary_addr: hosts primary interface address
@@ -73,7 +79,6 @@ struct orig_node {
 	uint8_t tq_own;
 	int tq_asym_penalty;
 	unsigned long last_valid;
-	unsigned long bcast_seqno_reset;
 	unsigned long batman_seqno_reset;
 	uint8_t gw_flags;
 	uint8_t flags;
@@ -81,11 +86,10 @@ struct orig_node {
 	int16_t hna_buff_len;
 	uint32_t last_real_seqno;
 	uint8_t last_ttl;
-	TYPE_OF_WORD bcast_bits[NUM_WORDS];
-	uint32_t last_bcast_seqno;
 	struct list_head neigh_list;
 	struct list_head frag_list;
 	unsigned long last_frag_packet;
+	struct seqno_state bcast_seqno_state;
 	struct {
 		uint8_t candidates;
 		struct neigh_node *selected;
-- 
1.7.1

[B.A.T.M.A.N.] [PATCH 3/3] batman-adv: Add sequence number and duplicate checks for unicasts

[Linus Lüssing]

From: Linus Lüssing <linus.luessing@ascom.ch>

When a node is set in promiscuous mode it might receive a unicast data
packet more than once. Therefore sequence number checking is required.

Signed-off-by: Linus Lüssing <linus.luessing@ascom.ch>
---
 originator.c     |    2 ++
 packet.h         |    4 +++-
 routing.c        |   11 ++++++++++-
 soft-interface.c |    1 +
 types.h          |    2 ++
 unicast.c        |    6 ++++++
 6 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/originator.c b/originator.c
index e888416..d71a59f 100644
--- a/originator.c
+++ b/originator.c
@@ -147,6 +147,8 @@ struct orig_node *get_orig_node(struct bat_priv *bat_priv, uint8_t *addr)
 	memcpy(orig_node->orig, addr, ETH_ALEN);
 	orig_node->router = NULL;
 	orig_node->hna_buff = NULL;
+	orig_node->ucast_seqno_state.seqno_reset = jiffies - 1
+					- msecs_to_jiffies(RESET_PROTECTION_MS);
 	orig_node->bcast_seqno_state.seqno_reset = jiffies - 1
 					- msecs_to_jiffies(RESET_PROTECTION_MS);
 	orig_node->batman_seqno_reset = jiffies - 1
diff --git a/packet.h b/packet.h
index b49fdf7..fe60fae 100644
--- a/packet.h
+++ b/packet.h
@@ -32,7 +32,7 @@
 #define BAT_UNICAST_FRAG 0x06
 
 /* this file is included by batctl which needs these defines */
-#define COMPAT_VERSION 12
+#define COMPAT_VERSION 13
 #define DIRECTLINK 0x40
 #define VIS_SERVER 0x20
 #define PRIMARIES_FIRST_HOP 0x10
@@ -98,7 +98,9 @@ struct icmp_packet_rr {
 struct unicast_packet {
 	uint8_t  packet_type;
 	uint8_t  version;  /* batman version field */
+	uint8_t  orig[6];
 	uint8_t  dest[6];
+	uint32_t seqno;
 	uint8_t  ttl;
 } __attribute__((packed));
 
diff --git a/routing.c b/routing.c
index 761fd84..9a2d41f 100644
--- a/routing.c
+++ b/routing.c
@@ -1146,6 +1146,9 @@ static inline int check_duplicate(struct bat_priv *bat_priv, uint8_t *orig,
 		case BAT_BCAST:
 			seqno_state = &orig_node->bcast_seqno_state;
 			break;
+		case BAT_UNICAST:
+			seqno_state = &orig_node->ucast_seqno_state;
+			break;
 		default:
 			goto out;
 	}
@@ -1261,9 +1264,10 @@ int route_unicast_packet(struct sk_buff *skb, struct batman_if *recv_if,
 
 int recv_unicast_packet(struct sk_buff *skb, struct batman_if *recv_if)
 {
+	struct bat_priv *bat_priv = netdev_priv(recv_if->soft_iface);
 	struct unicast_packet *unicast_packet;
 	int hdr_size = sizeof(struct unicast_packet);
-	int check_ret;
+	int ret, check_ret;
 
 	check_ret = check_unicast_packet(skb, hdr_size);
 	if (check_ret < 0)
@@ -1271,6 +1275,11 @@ int recv_unicast_packet(struct sk_buff *skb, struct batman_if *recv_if)
 
 	unicast_packet = (struct unicast_packet *)skb->data;
 
+	ret = check_duplicate(bat_priv, unicast_packet->orig,
+			      ntohl(unicast_packet->seqno), BAT_UNICAST);
+	if (ret)
+		return NET_RX_DROP;
+
 	/* packet for me */
 	if (is_my_mac(unicast_packet->dest)) {
 		interface_rx(recv_if->soft_iface, skb, recv_if, hdr_size);
diff --git a/soft-interface.c b/soft-interface.c
index e16c61b..3a97d59 100644
--- a/soft-interface.c
+++ b/soft-interface.c
@@ -596,6 +596,7 @@ struct net_device *softif_create(char *name)
 	atomic_set(&bat_priv->batman_queue_left, BATMAN_QUEUE_LEN);
 
 	atomic_set(&bat_priv->mesh_state, MESH_INACTIVE);
+	atomic_set(&bat_priv->ucast_seqno, 1);
 	atomic_set(&bat_priv->bcast_seqno, 1);
 	atomic_set(&bat_priv->hna_local_changed, 0);
 
diff --git a/types.h b/types.h
index 87eb780..98261d0 100644
--- a/types.h
+++ b/types.h
@@ -89,6 +89,7 @@ struct orig_node {
 	struct list_head neigh_list;
 	struct list_head frag_list;
 	unsigned long last_frag_packet;
+	struct seqno_state ucast_seqno_state;
 	struct seqno_state bcast_seqno_state;
 	struct {
 		uint8_t candidates;
@@ -136,6 +137,7 @@ struct bat_priv {
 	atomic_t orig_interval;		/* uint */
 	atomic_t hop_penalty;		/* uint */
 	atomic_t log_level;		/* uint */
+	atomic_t ucast_seqno;
 	atomic_t bcast_seqno;
 	atomic_t bcast_queue_left;
 	atomic_t batman_queue_left;
diff --git a/unicast.c b/unicast.c
index 7b9385b..def2588 100644
--- a/unicast.c
+++ b/unicast.c
@@ -323,6 +323,12 @@ int unicast_send_skb(struct sk_buff *skb, struct bat_priv *bat_priv)
 	unicast_packet->ttl = TTL;
 	/* copy the destination for faster routing */
 	memcpy(unicast_packet->dest, orig_node->orig, ETH_ALEN);
+	/* copy the originator */
+	memcpy(unicast_packet->orig, bat_priv->primary_if->net_dev->dev_addr,
+	       ETH_ALEN);
+	/* set unicast sequence number */
+	unicast_packet->seqno =
+		htonl(atomic_inc_return(&bat_priv->ucast_seqno));
 
 	if (atomic_read(&bat_priv->fragmentation) &&
 	    data_len + sizeof(struct unicast_packet) >
-- 
1.7.1

Re: [B.A.T.M.A.N.] [PATCH 3/3] batman-adv: Add sequence number and duplicate checks for unicasts

[Linus Lüssing]

Ah, thanks, oki doki.

I'm rectracting my Signed-off-by for now anyway, as I couldn't
validate their effect yet. However, any feedback if this idea
might or might not possibly work / make sense anyway is very
welcome :).

Cheers, Linus

On Sun, Nov 07, 2010 at 05:03:29PM +0100, Sven Eckelmann wrote:
> On Sunday 07 November 2010 17:46:01 Linus Lüssing wrote:
> >  /* this file is included by batctl which needs these defines */
> > -#define COMPAT_VERSION 12
> > +#define COMPAT_VERSION 13\
> 
> Please increase that to 14. 13 is already used in linux 2.6.37(-rc1)
> 
> Best regards,
> 	Sven

[B.A.T.M.A.N.] batman-adv promisc mode, further notes and recomendations

[Linus Lüssing]

Hi,

After some discussions on IRC we've decided to skip the sequence
number checking for now and to not care about forwarding a packet
to the higher layers more than once. Usually, higher layer protocols
are in charge and should be capable of detecting and coping not only
with lost, but also duplicate packets. I'm not aware of any protocol
which might have any difficulties with this (if you know one, please
let me know). If you have special, "custom" protocol which is not able
to cope with it, then you're adviced to not activate the promisc-mode
on that node's interface.

I also did some further testing on how usable such a feature on
embedded devices is. Smaller, less powerful devices like the Fonera
2.0 can have some performance decreases in a very busy, noisy mesh
neighborhood. All other scenarios and more performant devices should
be fine with the promisc mode, however feel free to do your own
measurments to find out if this promisc-mode feature is suitable
and benefitial for you (and share your experiences :) ).

Cheers,
Linus

[B.A.T.M.A.N.] [PATCHv2] batman-adv: Allow promiscuous reception of unicast packets

[Linus Lüssing]

This commits adds the possibility for the final destination node to also
receive and accept unicast data packets promiscuously already from an
arbitrary previous hop along the path, and not only the last previous hop.

This feature is especially useful in the following two scenarios:

Firstly, a very mobile node moving towards the sender along the hop path
benefits from this as for such a mobility pattern the reception probability
increases, no matter how slow the topology convergence speed is.

It also increases the probability of succesful reception a lot, if there
are (multiple) shorter, alternate but slightly "worse" paths, too (like
in a circular topology). As WiFi is a broadcast medium, there can be a
quite good chance to receive a packet from one of the nodes on the path
to the receiver already.

On smaller embedded devices, I would advice to run your own measurements
before activating this feature. Depending on wifi chipset
and driver as well as cpu, this can negatively affect your throughput.

To let this feature take effect, place your WiFi interface in
promiscuous mode (e.g. 'ip link set wlan0 promisc on'/'ifconfig wlan0
promisc').

Also note, that higher layers might receive a data packet more than
once. So if you have a special higher layer protocol that cannot deal
with that, then do not activate the promisc mode on this node.

Signed-off-by: Linus Lüssing <linus.luessing@ascom.ch>
---
 routing.c |   17 +++++++++++++----
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/routing.c b/routing.c
index 9f31167..082eb59 100644
--- a/routing.c
+++ b/routing.c
@@ -1127,7 +1127,7 @@ static int check_unicast_packet(struct sk_buff *skb, int hdr_size)
 
 	/* not for me */
 	if (!is_my_mac(ethhdr->h_dest))
-		return -1;
+		return 1;
 
 	return 0;
 }
@@ -1217,8 +1217,10 @@ int recv_unicast_packet(struct sk_buff *skb, struct batman_if *recv_if)
 {
 	struct unicast_packet *unicast_packet;
 	int hdr_size = sizeof(struct unicast_packet);
+	int check_ret;
 
-	if (check_unicast_packet(skb, hdr_size) < 0)
+	check_ret = check_unicast_packet(skb, hdr_size);
+	if (check_ret < 0)
 		return NET_RX_DROP;
 
 	unicast_packet = (struct unicast_packet *)skb->data;
@@ -1229,6 +1231,9 @@ int recv_unicast_packet(struct sk_buff *skb, struct batman_if *recv_if)
 		return NET_RX_SUCCESS;
 	}
 
+	if (check_ret)
+		return NET_RX_DROP;
+
 	return route_unicast_packet(skb, recv_if, hdr_size);
 }
 
@@ -1238,9 +1243,10 @@ int recv_ucast_frag_packet(struct sk_buff *skb, struct batman_if *recv_if)
 	struct unicast_frag_packet *unicast_packet;
 	int hdr_size = sizeof(struct unicast_frag_packet);
 	struct sk_buff *new_skb = NULL;
-	int ret;
+	int ret, check_ret;
 
-	if (check_unicast_packet(skb, hdr_size) < 0)
+	check_ret = check_unicast_packet(skb, hdr_size);
+	if (check_ret < 0)
 		return NET_RX_DROP;
 
 	unicast_packet = (struct unicast_frag_packet *)skb->data;
@@ -1262,6 +1268,9 @@ int recv_ucast_frag_packet(struct sk_buff *skb, struct batman_if *recv_if)
 		return NET_RX_SUCCESS;
 	}
 
+	if (check_ret)
+		return NET_RX_DROP;
+
 	return route_unicast_packet(skb, recv_if, hdr_size);
 }
 
-- 
1.7.1

Re: [B.A.T.M.A.N.] [PATCHv2] batman-adv: Allow promiscuous reception of unicast packets

[Marek Lindner]

On Wednesday 10 November 2010 01:48:13 Linus Lüssing wrote:
> Firstly, a very mobile node moving towards the sender along the hop path
> benefits from this as for such a mobility pattern the reception probability
> increases, no matter how slow the topology convergence speed is.

Would you mind explaining why you think it helps for mobile nodes in the 
scenario you mention ?
If I understand it correctly it helps for data originating from a non-mobile 
node traveling towards the mobile node but this is less critical (assuming the 
mobile node has a higher orig interval). For data originating at the mobile 
node traveling towards the non-mobile node it will only help if both nodes are 
single hop neighbors.

Regards,
Marek

[B.A.T.M.A.N.] Antwort: Re: [PATCHv2] batman-adv: Allow promiscuous reception of unicast packets

[Linus Luessing]

Marek Lindner <lindner_marek@yahoo.de> schrieb am 10.11.2010 12:06:18:

> [Bild entfernt] 
> 
> Re: [B.A.T.M.A.N.] [PATCHv2] batman-adv: Allow promiscuous reception
> of unicast packets
> 
> Marek Lindner 
> 
> an:
> 
> The list for a Better Approach To Mobile Ad-hoc Networking, Linus 
Lüssing
> 
> 10.11.2010 12:08
> 
> [Bild entfernt] 
> 
> Von:
> 
> Marek Lindner <lindner_marek@yahoo.de>
> 
> An:
> 
> "The list for a Better Approach To Mobile Ad-hoc Networking" 
> <b.a.t.m.a.n@lists.open-mesh.org>, Linus Lüssing 
<linus.luessing@ascom.ch>
> 
> On Wednesday 10 November 2010 01:48:13 Linus Lüssing wrote:
> > Firstly, a very mobile node moving towards the sender along the hop 
path
> > benefits from this as for such a mobility pattern the reception 
probability
> > increases, no matter how slow the topology convergence speed is.
> 
> Would you mind explaining why you think it helps for mobile nodes in the 

> scenario you mention ?
> If I understand it correctly it helps for data originating from a 
non-mobile 
> node traveling towards the mobile node but this is less critical 
> (assuming the 
> mobile node has a higher orig interval).
Correct, I was assuming equal intervals ;). Yes, this is usually not 
critical, but just
found it note worthy anyway, that you could possibly move towards the 
sender along the
path as fast as you wish without losing the stream from the sender, being 
independent
of the receivers OGM interval.

> For data originating at the mobile 
> node traveling towards the non-mobile node it will only help if 
bothnodes are 
> single hop neighbors.
That's not what I've been claiming afaik :). And if both nodes are just 
one hop away, then
you don't have any advantage of this promisc-reception anyway.

Hope that paragraph did not cause too much confusion, if you think there's 
something misleading
in it, I can change it, no problem.

> 
> Regards,
> Marek

Cheers,
Linus

Re: [B.A.T.M.A.N.] Antwort: Re: [PATCHv2] batman-adv: Allow promiscuous reception of unicast packets

[Linus Lüssing]

Hi there,

Hmm, okay, and I made some further measurements. In typical
scenarios with "default" settings, I unfortunately could not
really get a reliability improvement. The thing is, due to the
multicast rate of 1MBit/s in common wifi drivers, I wasn't able to
put the devices close enough for the promisc-reception to take
effect without BATMAN switching to the direct, shorter path.
So I ended up setting the multicast rate to 48mbit/s and
could get a reliability improvement from 14.5% packet loss down to
about 9.5%. But of course, such a high multicast rate is not
feasible.

So it'd be ok to ommit this patch, unless/until someone might have some
further ideas to get the promisc-idea usable.

Cheers, Linus

On Wed, Nov 10, 2010 at 04:38:15PM +0100, Linus Luessing wrote:
> Marek Lindner <lindner_marek@yahoo.de> schrieb am 10.11.2010 12:06:18:
> 
> > [Bild entfernt] 
> > 
> > Re: [B.A.T.M.A.N.] [PATCHv2] batman-adv: Allow promiscuous reception
> > of unicast packets
> > 
> > Marek Lindner 
> > 
> > an:
> > 
> > The list for a Better Approach To Mobile Ad-hoc Networking, Linus 
> Lüssing
> > 
> > 10.11.2010 12:08
> > 
> > [Bild entfernt] 
> > 
> > Von:
> > 
> > Marek Lindner <lindner_marek@yahoo.de>
> > 
> > An:
> > 
> > "The list for a Better Approach To Mobile Ad-hoc Networking" 
> > <b.a.t.m.a.n@lists.open-mesh.org>, Linus Lüssing 
> <linus.luessing@ascom.ch>
> > 
> > On Wednesday 10 November 2010 01:48:13 Linus Lüssing wrote:
> > > Firstly, a very mobile node moving towards the sender along the hop 
> path
> > > benefits from this as for such a mobility pattern the reception 
> probability
> > > increases, no matter how slow the topology convergence speed is.
> > 
> > Would you mind explaining why you think it helps for mobile nodes in the 
> 
> > scenario you mention ?
> > If I understand it correctly it helps for data originating from a 
> non-mobile 
> > node traveling towards the mobile node but this is less critical 
> > (assuming the 
> > mobile node has a higher orig interval).
> Correct, I was assuming equal intervals ;). Yes, this is usually not 
> critical, but just
> found it note worthy anyway, that you could possibly move towards the 
> sender along the
> path as fast as you wish without losing the stream from the sender, being 
> independent
> of the receivers OGM interval.
> 
> > For data originating at the mobile 
> > node traveling towards the non-mobile node it will only help if 
> bothnodes are 
> > single hop neighbors.
> That's not what I've been claiming afaik :). And if both nodes are just 
> one hop away, then
> you don't have any advantage of this promisc-reception anyway.
> 
> Hope that paragraph did not cause too much confusion, if you think there's 
> something misleading
> in it, I can change it, no problem.
> 
> > 
> > Regards,
> > Marek
> 
> Cheers,
> Linus
>