Hi!
Ubiquiti provides OpenWrt based SDK for their firmware. To my
information, it contains some proprietary madwifi-based WiFi drivers
with some older OpenWrt version. My question is how it would be
possible to run Batman on top of their firmware (thus not latest
OpenWrt). As Batman is in kernel, is is enough kernel-backwards
compatible to be able to run also on older (2.6) kernel versions? For
olsrd it is much simpler: you just install olsrd package and this is
it.
Mitar
I have an interesting hardware setup I'd like to explore.
Basically, I would like to take commodity ubiquiti and/or openmesh
hardware and build a mesh with two different node types, some having
just 1 radio and others having multiple radios, a standard node and a
super node.
the standard node is:
a picostation flashed to openwrt running batman-adv and running the
radio in Ad-Hoc mode. Alternately an OM2P flashed to openwrt. This
is the basic client radio
the super node is:
a group of picostations or nanostations, flashed openwrt in adhoc
mode, but acting only as the L2 transport with a router at the center
running batman-adv.
The idea is that the super nodes have multiple radios in multiple
channels and can take advantage of link alternation allowing super
nodes to keep much higher bandwidth between them while the standard
nodes are cheap. The 'router' MIGHT also have a radio for client
access (unifi station flashed to openwrt maybe, or an ALIX board)
The supernode will have more CPU and also be the target of
backhaul/shorthaul links to cut down on hop count. The main router
would also be a batman-adv device, probably an x86 server, and would
be the border router for the mesh.
some questions,
I know that the supernodes will have higher throughput capabilities
due to dual mesh radios, but how will batman-adv know this or how
would I tell it? Is the internal mechanism for determining the best
path going to take this into account? Is there a way to identify a
supernode as being a better path above and beyond the automatic
batman-adv mechanisms?
Is having separate radios connected to a batman-adv router going to
behave how I presume? That multiple node2node connections will be
identified and the links be alternated when appropriate?
If the supernodes have 2 mesh radios, 1 in 5Ghz and 1 in 2.4Ghz, then
the standard nodes will only be able to connect to the 2.4Ghz channel
which might make it inappropriate to do link alternating on these two
links because of the shared traffic. Should batman-adv automatically
stop alternating the tx/rx on these links when one of the channels
starts to get saturated?
some other info:
the supernodes may have a link directly to the main distribution
point, but may also be linked just to another supernode and not to the
main distribution point, or possibly both.
the supernodes are likely to have more than 2 mesh radios as some of
these could be direction antennas. A supernode might have 3x 2.4Ghz
radios for mesh, 2x 5Ghz radios for mesh, and a 2.4Ghz radio for
non-mesh clients. These would most likely all be connected to a
switch port and only be on a single ethernet interface as far as
batman-adv is concerned.
As much as I'm happy to see LWN links sprinkled through the kernel by the
dozen, this one in particular reflects a very old state of reality; the
associated comment is now incorrect. So just delete it.
Signed-off-by: Jonathan Corbet <corbet(a)lwn.net>
diff --git a/net/batman-adv/main.c b/net/batman-adv/main.c
index 083a299..c91f35b 100644
--- a/net/batman-adv/main.c
+++ b/net/batman-adv/main.c
@@ -57,9 +57,6 @@ static int __init batman_init(void)
recv_handler_init();
bat_iv_init();
-
- /* the name should not be longer than 10 chars - see
- * http://lwn.net/Articles/23634/ */
bat_event_workqueue = create_singlethread_workqueue("bat_events");
if (!bat_event_workqueue)
commit 2c995ff892313009e336ecc8ec3411022f5b1c39 upstream.
skb_linearize(skb) possibly rearranges the skb internal data and then changes
the skb->data pointer value. For this reason any other pointer in the code that
was assigned skb->data before invoking skb_linearise(skb) must be re-assigned.
In the current tt_query message handling code this is not done and therefore, in
case of skb linearization, the pointer used to handle the packet header ends up
in pointing to poisoned memory. The packet is then dropped but the
translation-table mechanism is corrupted.
Signed-off-by: Antonio Quartulli <ordex(a)autistici.org>
Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
---
Hello,
the patch committed upstream already contains Cc: stable(a)vger.kernel.org but
that patch does apply only on 3.5, 3.4 and 3.3.
This patch is a backport for kernel versions 3.1 and 3.2
Thank you,
Antonio
net/batman-adv/routing.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/batman-adv/routing.c b/net/batman-adv/routing.c
index 0f32c81..55136e5 100644
--- a/net/batman-adv/routing.c
+++ b/net/batman-adv/routing.c
@@ -1246,6 +1246,8 @@ int recv_tt_query(struct sk_buff *skb, struct hard_iface *recv_if)
/* packet needs to be linearised to access the TT changes */
if (skb_linearize(skb) < 0)
goto out;
+ /* skb_linearize() possibly changed skb->data */
+ tt_query = (struct tt_query_packet *)skb->data;
if (is_my_mac(tt_query->dst))
handle_tt_response(bat_priv, tt_query);
--
1.7.9.4
Hello people,
this is the second version of the Speedy Join feature.
Since version v1 I changed a few things:
- indentation and style has been fixed taking into consideration Sven's
suggestions
- Old patch 4 has been removed. TT flags do not really need to be carry along
with the tt_entry in a roaming_adv packet. (at least this is not needed for
the purpose of this feature). A roaming client will be marked as ROAM on the
new mesh node and therefore it will be already purged if nobody claims it.
Thank you,
Antonio
this is another set of patches I'd like to see included in net-next/linux-3.6.
Here you have some more patches aimed to clean our namespace, a minor cleanup
for the vis code that eliminates a useless intermediate buffer used to
provide the output and two other minor cleanups for the TranslationTable code.
Tell me if there is any problem!
Thank you,
Antonio
The following changes since commit 160eb5a6b14ca2eab5c598bdbbb24c24624bad34:
ipv4: Kill early demux method return value. (2012-06-27 22:01:22 -0700)
are available in the git repository at:
git://git.open-mesh.org/linux-merge.git tags/batman-adv-for-davem
for you to fetch changes up to 42d0b044b7c9e5821f1bf3e2b4ea7861417c11c2:
batman-adv: Prefix main defines with BATADV_ (2012-06-28 08:45:05 +0200)
----------------------------------------------------------------
Included changes:
- another batch of patches meant to clean batman-adv namespace
- deletion of an obsolete intermediate buffer used in the visualization code to
print the output
- TT code cleanups
----------------------------------------------------------------
Antonio Quartulli (2):
batman-adv: clear ADD+DEL (and viceversa) events in the same orig-interval
batman-adv: beautify tt_global_add() argument list
Sven Eckelmann (16):
batman-adv: Prefix unicast local static functions with batadv_
batman-adv: Prefix vis local static functions with batadv_
batman-adv: Prefix main local static functions with batadv_
batman-adv: Prefix remaining function like macros with batadv_
batman-adv: Directly print to seq_file in vis
batman-adv: Prefix local defines with BATADV_
batman-adv: Prefix debugfs defines with BATADV_
batman-adv: Prefix sysfs defines with BATADV_
batman-adv: Prefix bridge_loop_avoidance defines with BATADV_
batman-adv: Prefix gateway defines with BATADV_
batman-adv: Prefix icmp_socket defines with BATADV_
batman-adv: Prefix packet defines with BATADV_
batman-adv: Prefix types defines with BATADV_
batman-adv: Prefix unicast defines with BATADV_
batman-adv: Prefix vis defines with BATADV_
batman-adv: Prefix main defines with BATADV_
net/batman-adv/bat_debugfs.c | 34 +--
net/batman-adv/bat_debugfs.h | 2 +-
net/batman-adv/bat_iv_ogm.c | 125 ++++++----
net/batman-adv/bat_sysfs.c | 228 +++++++++--------
net/batman-adv/bat_sysfs.h | 4 +-
net/batman-adv/bitarray.c | 20 +-
net/batman-adv/bitarray.h | 4 +-
net/batman-adv/bridge_loop_avoidance.c | 24 +-
net/batman-adv/bridge_loop_avoidance.h | 2 +-
net/batman-adv/gateway_client.c | 32 +--
net/batman-adv/gateway_common.c | 26 +-
net/batman-adv/gateway_common.h | 6 +-
net/batman-adv/hard-interface.c | 50 ++--
net/batman-adv/icmp_socket.c | 6 +-
net/batman-adv/icmp_socket.h | 2 +-
net/batman-adv/main.c | 91 +++----
net/batman-adv/main.h | 101 ++++----
net/batman-adv/originator.c | 34 +--
net/batman-adv/packet.h | 12 +-
net/batman-adv/ring_buffer.c | 4 +-
net/batman-adv/routing.c | 32 +--
net/batman-adv/send.c | 6 +-
net/batman-adv/soft-interface.c | 24 +-
net/batman-adv/translation-table.c | 163 +++++++-----
net/batman-adv/translation-table.h | 4 +-
net/batman-adv/types.h | 19 +-
net/batman-adv/unicast.c | 37 +--
net/batman-adv/unicast.h | 4 +-
net/batman-adv/vis.c | 422 ++++++++++++++------------------
net/batman-adv/vis.h | 2 +-
30 files changed, 780 insertions(+), 740 deletions(-)
On Tue, Jun 26, 2012 at 11:18:29PM +0200, Sven Eckelmann wrote:
> I am not 100% sure because I haven't checked the code, but couldn't it be
> the case that we send random bits inside reserved at the moment? At least
> I cannot remember the part of the code that initialized reserver to any
> specific value. That would make the change incompatible with older
> batman-adv version.
Damn, that's true! It is not initialised anywhere....
What if I append a new field to the roam_adv_packet struct? Old version will
ignore it and there is no size check to drop packets longer than expected.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
Hello people,
this feature was proposed some time ago but then many changes were needed and
I took my time to refine the code :-).
Speedy Join enables new client to communicates with other hosts in the network
before being announced by its own mesh node.
In the current implementation a new client has to wait until the first OGM after
its join is sent out and only then it can start communicating with other
clients. However it could be the case that the originator interval is set to an
high value (e.g. 10 secs), which means that the client has to wait a long period
before becoming active. This would lead to several malfunctions like DHCP
timeouts.
This patchset faces this problem by letting nodes in the network "learn" about
the new client by means of its broadcast packets (the client will most likely
send a DHCP or an ARP request upon connection).
This new version composed by 5 patches. 1/5 adds the refcounting to the
tt_orig_list_entry structure, 2/5 generalises already existent code, 3/5 enables
roaming_adv packet to carry flags (this is needed to correctly make the new
client roam), 4/5 adds the code needed to handle the "temporary" clients and,
finally, 5/5 adds an hook for detecting new clients in the RX path.
Thank you!
Antonio
On Tue, Jun 26, 2012 at 11:14:27PM +0200, Sven Eckelmann wrote:
> You can just invert the atomic_dec_and_test and use a return to avoid the
> weird comment.
Right. Thank you!
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara