On Wednesday 21 November 2012 16:08:37 liu muye wrote:
> Thank you so much for your suggestions. Yes, we are using batman-adv. The
> one running as a kernel module.
> Just a few quick follow up questions.
>
> Our goal is to build an ad hoc mesh network. Each node may not have IP
> address. I can use batctl ping functionality to ping my peer with MAC
> address. Just wondering if I can send data packet to my peers with MAC
> address.
Of course. This is the raw socket stuff I've mentioned before. Just bind a raw
socket to your bat0 device and sent ethernet frames between your nodes (mac
address as source/destionation). An easy example is rawsend [1].
But it is propably easier to use an actual transport protocol for communication.
> I have noticed the packet.h file in the batctl source code contains several
> C structures. One of them is
>
> struct batadv_unicast_packet {
> struct batadv_header header;
> uint8_t ttvn; /* destination translation table version number */
> uint8_t dest[ETH_ALEN];
> } __packed;
>
> To send my data packet, I have to use this C structure. Is that correct?
> and where to look up the value for ttvn?
No, this is internal stuff used for the tunneling. Don't try to create packets
from userspace with this format as you would have to implement a complete
batman-adv replacement. And you still would have to create a valid ethernet
packet followed by the unicast header anyway. So better use raw sockets
when you just want to sent ethernet frames between bat0 devices of different
nodes.
Kind regards,
Sven
[1] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/attachments/20111206/52f0…https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2011-December/005865.html
Thank you so much for your suggestions. Yes, we are using batman-adv.
The one running as a kernel module.
Just a few quick follow up questions.
Our goal is to build an ad hoc mesh network. Each node may not have IP
address. I can use batctl ping functionality to ping my peer with MAC
address. Just wondering if I can send data packet to my peers with MAC
address.
I have noticed the packet.h file in the batctl source code contains
several C structures. One of them is
struct batadv_unicast_packet {
struct batadv_header header;
uint8_t ttvn; /* destination translation table version number */
uint8_t dest[ETH_ALEN];
} __packed;
To send my data packet, I have to use this C structure. Is that
correct? and where to look up the value for ttvn?
Thanks for your time
Have a nice day
This is Muye, I am a university student. Currently, we have a mesh
network project using B.A.T.M.A.N.
We are trying to establish wireless communication between each
B.A.T.M.A.N client so that they can share information through the mesh
network.
Specifically, we want to write an application on top of the
B.A.T.M.A.N using socket in order to transmit the data packet from one
B.A.T.M.A.N client to other B.A.T.M.A.N client. For example, unicast
or multicast.
Would you please give us some advices on how to write such
application. I have looked at the batctl ping and tcpdump source code,
but I was not able to send data packet using the similar mechanism.
We greatly appreciate any of your suggestions.
On Wednesday 21 November 2012 13:49:48 ajeet singh wrote:
[...]
> 1: Does it support the FullMAC devices like AR6003?
batman-adv doesn't care about the wifi device mac implementation. It just has
to be a working implementation (aka working implementation in the mode you are
using). I don't know whether the IBSS mode of AR6003 is broken or not.
> 2: Is it possible to support gateway or bridge to extend the IBBS or to
> provide internet access?
I don't understand your question. I though you wanted to use batman-adv to
"extend" the IBSS.
Kind regards,
Sven
Hello,
I have recently discovered batman-adv and am very interesting in
getting it running on a custom embedded linux board we are developing.
I have a couple of questions:
1. Will batman-adv work over 802.15.4 ?
I have a microchip MRF24J40 802.15.4 module integrated on my linux
board (3.7.0-rc6), and can bring up wpan-phy0 and lowpan0 interfaces.
2. Can batman-adv work with either of these interfaces ?
I tried configuring these interfaces using 'batctl' but it complains
that they are an unsupported type.
'iwconfig' reports these interfaces as having 'no wireless extensions'
which I suspect is the issue.
Please let me know if running b.a.t.m.a.n. over 802.15.4 is feasible.
Thanks,
-Randy
Hey folks,
Marek once asked on the IRC channel about our project,
Mitar also asked for a proper introduction [0]
And i get the feeling it would be nice to describe a small real world
batman-adv implementation
i've seen many times mails from people doing simulations or whatnot, to
decide if batman-adv works as expected... and i guess they would appreciate
reading about live use cases :)
So here it goes,
this thing started back in february 2012 [1] in Cordoba with Nico Echaniz
et al
Shortly after DeltaLibre followed, replicating the model. From the very
beginning we aimed at building the cheapest possible, performant
multi-radio mesh node.
Ten months later, although there's still room for improvement, we are very
happy looking back at the path that took us here :). Starting with the
decision of choosing batman-adv, as explained in a spanish reply to Esteban
Municio [2]
===translation===
2012/9/10 Esteban Municio <emunicio en gmail.com>:
> Was there any reason why you chose batman-adv over other protocol?
Layer 2! no subnet configuration, "Just Works", it's easy to forget
batman-adv
is down there doing all the magic - A routing protocol that stays out of
your way, is priceless.
> which were your main issues working with batman-adv?
With batman-adv... almost none :)
Main difficulties until now were on phy level (interference) or layer 1
(hardware, drivers, firmware)
With batman-adv, we bumped into 2 or 3 bugs, reported to the mailing list,
and received prompt solutions
thanks to the daily work that the developers put into it.
Last version 2012.3.0 includes all those fixes.
Pending issues are a strange behaviour where avahi packets are lost (can't
assure batman-adv is the culprit)
and an open ticket[3] about adding RAs mangling support to gw_mode,
extending the DHCPv4 segmentation logic to SLAAC networks as well.
As it is today, you can't put 2 ipv6 gateways doing SLAAC in the same
batman-adv cloud.
So far is not a showstopper for us, but we would love to be able to do that.
======
(for the record, that "strange avahi behaviour" seems solved with the CRC
broadcast fixes in 2012.4.0 :D)
Some numbers: with the hardware[4] we are using (TL-MR3220 and WN722N),
throughput in point-to-point links maxes out at 30 or 40mbps respectively,
on MISO HT20
With our dual-radio mesh nodes, we can sustain that transfer speed over 3
hops, using channels 1 and 11 for alternating interfaces.
Given the small size of the networks, a longer path is currently not
possible, but when using a single radio, or interfering channels, that same
path throughput quickly drops to about 6 mbps, as predicted by the models.
This is not news for many, but as said in the beginning of the email, i see
some folks "doubting" about the performance, or overhead, of batman-adv...
In tests we made, over a single hop (that is, from A to C as in A --> B
--> C where point to point links reach ~30mbps), static routing reached
30mbps +/- 0.5mbps, and using batman-adv 29mbps +/- 0.5mbps
A real bargain for the bat-benefits :)
(i'm really sorry i can't provide supporting charts and logs ATM, collecting
them would delay this email even further, and it's been months already
since I have this email forgotten in drafts folder :( )
To easily share, publish and keep track of config tweaks between our
networks we setup a hg repo [5][6]
and eventually added bat-graphs for some basic context. [7]
That can't possibly be maintained at a larger scale, but still proves
incredibly useful at research stages.
It has been used by an independent group (Gabriel Tolon et al) to
compatibilize its equipments with DeltaLibre network at their lab, then
bring the nodes into the region, plug, and Just Worked, with little
intervention on our part.
We pull the overlays with a bash hack named ruci[8]
and use that too to push and stage experimental configs to the whole
network without fear of locking us out because of a config mistake or typo.
(i'm aware this has been addressed by multiple solutions, but ruci was born
back in february while we didn't have a decent internet access to research
previous art - we have changed tactics since then, trying to integrate with
the rest of the movements :) )
Finally, some obligatory pictures [9] of representative (..?) nodes
last months' smokeping stats [10] and cacti [11]
and as a bonus, a crude video [12] filmed by Al Cano from guifi.net while
visiting DeltaLibre back in May, enjoying seamless roaming along 6 nodes
while literally navigating through the batman-adv mesh :)
In QuintanaLibre (Quintana is a mountains *small* town with <500 habitants)
you can spot kids using their OLPC netbooks while sitting in a
(resting) horse' back.
With almost no cellphone signal nor landlines whatsoever, you can imagine
how much they appreciate having a WCN at their town.
All this can't possibly express how grateful we are with you batpeople, but
I hope it gives a glimpse ;)
Cheers!
Gui
[0]: http://wlan-si.net/lists/arc/nodewatcher/2012-08/msg00005.html
[1]: http://blog.altermundi.net/article/timeline-february-september-2012/
[2]:
http://listas.altermundi.net/pipermail/redeslibres/2012-October/001438.html
[3]: http://www.open-mesh.org/issues/159
[4]: http://docs.altermundi.net/MiniMaxi/Hardware
[5]: https://bitbucket.org/guidoi/deltalibre-configs
[6]: https://bitbucket.org/nicoechaniz/quintanalibre-configs
[7]:
https://bitbucket.org/guidoi/deltalibre-configs/src/tip/files/deltalibre_20…
[8]: https://bitbucket.org/guidoi/ruci/
[9]: http://blog.altermundi.net/article/algunas-imagenes-de-deltalibre/
[10]: http://ping.deltalibre.org.ar/
[11]: http://graficas.deltalibre.org.ar/
[12]:
http://es.wiki.guifi.net/wiki/Archivo:Paseo_en_canoa_conectado_a_BATMAN-adv…
Hello David,
this should be our last batch of patches intended for net-next/linux-3.8.
In this patchset we have patches 7,8/10 by Sven Eckelmann which improve the crc
computation on broadcast packets (in the Bridge Loop Avoidance component) by
using crc32c and by avoiding the entire linearisation of the skb! Then, patch
4/10 introduces a new debugfs file which exports the compatibility version so
that users having different batman-adv releases can understand whether they can
or cannot communicate.
Patch 10/10 removes the packed attribute for the unicast message type and adds
"#pragma pack(2)" (again, this is just part of our intermediate changes which do
not break compatibility. The real restructure will come later..).
The others are cleanups or small code refactoring.
Let me know if there is any problem!
Thank you,
Antonio
The following changes since commit 3594698a1fb8e5ae60a92c72ce9ca280256939a7:
net: Make CAP_NET_BIND_SERVICE per user namespace (2012-11-18 20:33:37 -0500)
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 15401e33ef94d4f251c42e8228e6c387327f38f8:
batman-adv: Use packing of 2 for all headers before an ethernet header (2012-11-19 09:14:11 +0100)
----------------------------------------------------------------
Included changes:
- Increase batman-adv version
- Bridge Loop Avoidance: compute checksum (using crc32) on skb fragments instead
of linearising it
- sort the sysfs documentation
- export the compatibility version via debugfs
- some other minor cleanups
----------------------------------------------------------------
Antonio Quartulli (2):
batman-adv: support array of debugfs general attributes
batman-adv: export compatibility version via debugfs
Marek Lindner (1):
batman-adv: sysfs documentation should keep alphabetical order
Martin Hundebøll (1):
batman-adv: Add wrapper to look up neighbor and send skb
Simon Wunderlich (2):
batman-adv: fix bla compare function
batman-adv: Fix broadcast duplist for fragmentation
Sven Eckelmann (4):
batman-adv: Mark best gateway in transtable_global debugfs
batman-adv: Add function to calculate crc32c for the skb payload
batman-adv: Start new development cycle
batman-adv: Use packing of 2 for all headers before an ethernet header
.../ABI/testing/sysfs-class-net-batman-adv | 11 +-
Documentation/ABI/testing/sysfs-class-net-mesh | 40 +++---
net/batman-adv/Kconfig | 1 +
net/batman-adv/bridge_loop_avoidance.c | 36 +++--
net/batman-adv/bridge_loop_avoidance.h | 6 +-
net/batman-adv/debugfs.c | 46 ++++--
net/batman-adv/main.c | 46 ++++++
net/batman-adv/main.h | 4 +-
net/batman-adv/packet.h | 16 ++-
net/batman-adv/routing.c | 45 ++----
net/batman-adv/send.c | 33 +++++
net/batman-adv/send.h | 3 +
net/batman-adv/translation-table.c | 155 +++++++++++----------
net/batman-adv/types.h | 2 +-
net/batman-adv/unicast.c | 8 +-
net/batman-adv/vis.c | 35 ++---
16 files changed, 293 insertions(+), 194 deletions(-)