[v2] batman-adv: Allow promiscuous reception of unicast packets
Commit Message
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(-)
Comments
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
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
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
>
@@ -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);
}