B.A.T.M.A.N

b.a.t.m.a.n@lists.open-mesh.org

15 participants
4308 discussions

Start a nNew thread

[B.A.T.M.A.N.] drop dhcp batman-adv
by Gioacchino Mazzurco 19 Sep '11

19 Sep '11

Hey all! I am looking for a way to drop dhcp packets forwarding with batman-adv there is some way to do that ?

3 3

[B.A.T.M.A.N.] Demo and tests with a virtual network
by clownix＠clownix.net 18 Sep '11

18 Sep '11

Hello, I have updated the cloonix tool to help b.a.t.m.a.n demo making there is a simple automated demo of ospf/quagga included. For b.a.t.m.a.n I would recommend to use the UML techno, KVM eats more ressources and LXC should not work for b.a.m.a.n because it uses the host's kernel. If any of you creates a batman demo with cloonix one day, please send it to me so that it gets in cloonix mainline. Version is cloonix-10.09 at http://clownix.net Regards Vincent Perrier

1 0

[B.A.T.M.A.N.] lxc and batman
by clownix＠clownix.net 15 Sep '11

15 Sep '11

Hello, I was wondering if the batman code in the kernel make batman not compatible with lxc. Lxc are the linux containers that permit to have virtual machines with the least overhead (native speed) but those machines use the host's kernel. If you know openvz, lxc is the same technology. It would be nice to be able to have lxc compatible with batman so as to test big networks on a single machine. Vincent

2 5

[B.A.T.M.A.N.] machine emulation tool
by clownix＠clownix.net 07 Sep '11

07 Sep '11

Hello, There is a tool to emulate lots of machines in a network based on either uml, kvm or lxc container techno, this tool is called cloonix and used by the quagga team (and olsr people). The version 10 is availlable and may be usefull to test batman big topologies. The default machine for the tool is the openwrt but buildroot and debian machines are very easy to create with a script included in the tool. See all this at clownix.net. Vincent Perrier

2 2

[B.A.T.M.A.N.] batman-adv and coovachilli
by Filippo Sallemi 03 Sep '11

03 Sep '11

Hi all, I've a little problem and i need a confirm from you. I have 2 mesh node (gateway) with this configuration: lan is a bridge with bat0 and wlan0 with node1 ip 10.0.1.1 netmask 255.0.0.0 and node2 ip 10.0.2.1 netmask 255.0.0.0 wan : eth0 msh : wlan1 and 3 mesh gatway (client) whit this configuration lan is a bridge with eth0 bat0 and wlan1 with dhcp msh is wlan1 on each gateway nodes run an istance of coovachilli that create new interface tun0 ahead br-lan and when coovachilli start deconfig br-lan and assign the ip of br-lan to tun0. all other node are simple client. Now the problem is that when coovachilli is not running i'm able to ping node1 from node2 and viceversa but when coovachilli is running i'm unable to comunicate with other node with ip addres not in the same subnet. I think that the problem is tun0 interface that block all traffic o something. I have tried to use tap device but the problem is not resolved. Suggest? -- Filippo Sallemi

2 1

[B.A.T.M.A.N.] [PATCH 00/24] net: Remove unnecessary OOM logging messages
by Joe Perches 30 Aug '11

30 Aug '11

Remove all the site-specific OOM messages because they duplicate the MM subsystem generic OOM message. Saves ~.2% (~2.5kb) of code/text in an x86 defconfig $ size net/built-in.o*defconfig text data bss dec hex filename 1506772 58652 34928 1600352 186b60 net/built-in.o.new.defconfig 1509144 58652 34928 1602724 1874a4 net/built-in.o.old.defconfig $ size net/built-in.o*allyesconfig text data bss dec hex filename 7655361 275361 2062352 9993074 987b72 net/built-in.o.new.allyesconfig 7667400 275649 2064024 10007073 98b221 net/built-in.o.old.allyesconfig Joe Perches (24): 802: Remove unnecessary OOM logging messages 9p: Remove unnecessary OOM logging messages atm: Remove unnecessary OOM logging messages ax25: Remove unnecessary OOM logging messages batman-adv: Remove unnecessary OOM logging messages netfilter: Remove unnecessary OOM logging messages net: Remove unnecessary OOM logging messages ceph: Remove unnecessary OOM logging messages decnet: Remove unnecessary OOM logging messages econet: Remove unnecessary OOM logging messages iucv: Remove unnecessary OOM logging messages mac80211: Remove unnecessary OOM logging messages netrom: Remove unnecessary OOM logging messages rds: Remove unnecessary OOM logging messages rfkill: Remove unnecessary OOM logging messages rose: Remove unnecessary OOM logging messages sched: Remove unnecessary OOM logging messages sctp: Remove unnecessary OOM logging messages sunrpc: Remove unnecessary OOM logging messages tipc: Remove unnecessary OOM logging messages wanrouter: Remove unnecessary OOM logging messages wireless: Remove unnecessary OOM logging messages x25: Remove unnecessary OOM logging messages net: Remove unnecessary OOM logging messages net/802/tr.c | 1 - net/9p/client.c | 7 +---- net/9p/trans_virtio.c | 6 +---- net/atm/lec.c | 4 +-- net/atm/mpc.c | 17 ++++---------- net/atm/mpoa_caches.c | 8 +----- net/ax25/ax25_dev.c | 5 +-- net/ax25/ax25_out.c | 8 +++--- net/ax25/ax25_route.c | 5 +-- net/batman-adv/hard-interface.c | 5 +--- net/batman-adv/main.c | 2 - net/batman-adv/originator.c | 16 +++---------- net/batman-adv/soft-interface.c | 4 +-- net/batman-adv/vis.c | 4 +-- net/bridge/netfilter/ebt_ulog.c | 7 ++--- net/can/af_can.c | 6 +--- net/ceph/messenger.c | 5 +--- net/ceph/msgpool.c | 6 +---- net/core/dev.c | 25 ++++++---------------- net/core/flow.c | 4 +-- net/core/pktgen.c | 5 +--- net/decnet/dn_neigh.c | 6 ----- net/econet/af_econet.c | 4 +-- net/ipv4/netfilter/ipt_CLUSTERIP.c | 1 - net/ipv4/netfilter/ipt_ULOG.c | 4 +-- net/ipv4/netfilter/nf_nat_snmp_basic.c | 22 +----------------- net/ipv6/netfilter/nf_conntrack_reasm.c | 7 ++--- net/iucv/iucv.c | 5 +-- net/mac80211/agg-rx.c | 19 +--------------- net/mac80211/agg-tx.c | 35 +++++++----------------------- net/mac80211/debugfs.c | 3 ++ net/mac80211/ht.c | 6 +---- net/mac80211/mesh.c | 5 +-- net/mac80211/mlme.c | 17 ++++---------- net/mac80211/spectmgmt.c | 6 +---- net/mac80211/tx.c | 17 ++++---------- net/mac80211/util.c | 11 ++------- net/mac80211/work.c | 6 +--- net/netfilter/ipset/ip_set_core.c | 4 +-- net/netfilter/ipvs/ip_vs_core.c | 5 +-- net/netfilter/ipvs/ip_vs_ctl.c | 18 +++++---------- net/netfilter/ipvs/ip_vs_dh.c | 5 +-- net/netfilter/ipvs/ip_vs_lblc.c | 9 ++----- net/netfilter/ipvs/ip_vs_lblcr.c | 13 +++-------- net/netfilter/ipvs/ip_vs_proto.c | 5 +-- net/netfilter/ipvs/ip_vs_sh.c | 5 +-- net/netfilter/ipvs/ip_vs_wrr.c | 5 +-- net/netfilter/nf_conntrack_core.c | 5 +--- net/netfilter/nfnetlink_log.c | 7 +---- net/netfilter/xt_IDLETIMER.c | 2 - net/netfilter/xt_hashlimit.c | 5 +--- net/netrom/af_netrom.c | 8 +----- net/rds/ib_rdma.c | 1 - net/rds/iw_rdma.c | 8 +------ net/rds/iw_send.c | 8 +----- net/rfkill/rfkill-regulator.c | 1 - net/rose/af_rose.c | 1 - net/sched/act_api.c | 6 +--- net/sched/sch_atm.c | 1 - net/sctp/protocol.c | 3 -- net/socket.c | 5 +--- net/sunrpc/auth_gss/gss_krb5_crypto.c | 10 +------- net/sunrpc/auth_gss/gss_krb5_mech.c | 2 - net/sunrpc/backchannel_rqst.c | 9 ++----- net/sunrpc/clnt.c | 3 -- net/sunrpc/rpc_pipe.c | 3 +- net/sunrpc/rpcb_clnt.c | 2 - net/sunrpc/xprtrdma/svc_rdma.c | 8 +----- net/sunrpc/xprtrdma/transport.c | 5 +--- net/sunrpc/xprtrdma/verbs.c | 14 ------------ net/sunrpc/xprtsock.c | 5 +--- net/tipc/link.c | 4 +-- net/wanrouter/wanmain.c | 8 +------ net/wireless/lib80211_crypt_ccmp.c | 2 - net/wireless/lib80211_crypt_tkip.c | 4 --- net/wireless/lib80211_crypt_wep.c | 4 --- net/wireless/util.c | 5 +-- net/x25/x25_dev.c | 10 +++----- 78 files changed, 137 insertions(+), 415 deletions(-) -- 1.7.6.405.gc1be0

2 2

Re: [B.A.T.M.A.N.] Comments on Lifenet?
by Sven Eckelmann 27 Aug '11

27 Aug '11

On Friday 26 August 2011 15:32:37 Hrushi Mehendale wrote: > Hi Sven, > > Thank you very much for your frank comments about the code. Another comment about your mail: Don't send html to the mailing list... it will be dropped. > Hopefully, with help from experienced programmers such as you and many > others whom we may not even know, we would be able to improve the code > quality. The prototype is just out of our research lab and as you pointed > out, the code needs to be fine tuned now. Apart from building the prototype, > majority of our efforts have been spent on porting LifeNet across different > hardware and OS platforms, in order to validate our baseline claims of > hardware and OS interoperability. I doubt that it has something to do with fine tuning. There are just simple things which you should not do: For example accessing memory after you free'd the memory region. > Do you have any suggestions for us to facilitate better interaction with the > community, particularly to make sure LifeNet adhers to best programming > practices / standards? A nasty comment would be: learn coding But honestly, you should get in contact with good kernel programmer which can work for you. It is not a "community" thing, but understanding what you are actually doing. I think those papers are a good example. You seem to understand your problem and try to find a solution. But the problem is that you are not the persons which understand the actual implementation stuff. So maybe there is a operating system department at your university which has experienced people and can help to implement your ideas. Not that I have a problem with research code... but selling it to organisations and knowing that it has ugly bugs seems not to be a good idea (at least from my point of view). Kind regards, Sven

2 3

[B.A.T.M.A.N.] Avahi/zeroconf on batman-adv 2011.1.0
by Max Ip 26 Aug '11

26 Aug '11

Hi, I have batman-adv 2011.1.0 on two machines connected via wifi in adhoc mode. As expected the bat0 virtual interface can be configured to set an ipv4 address. I used ifconfig bat0 10.42.43.1 and ifcondif bat0 10.42.43.2 on two machines. However, the documentation says that bat0 can be assigned Avahi/zeroconf. Could anyone give me an idea how to assign via Avahi/zeroconf. Max

2 1

[B.A.T.M.A.N.] A case for batman-11s
by Javier Cardona 25 Aug '11

25 Aug '11

Hi batman developers, Clara Gnos suggested that I write to the list to make a case for batman + 802.11s integration. As you probably know, 802.11s is the upcoming wireless mesh standard from IEEE. The current version of the draft was approved by the IEEE 802 Executive Committee in July and will be ratified next month. open80211s (http://o11s.org) is an open implementation of 802.11s that's in the kernel mainline since 2.6.26. 802.11s uses HWMP as its default routing (path selection, in 11s-speak) protocol. All 11s implementations must support this default, and this is what's implemented in open80211s. The 11s spec also defines an extensible framework to support other path selection protocols and custom metrics. open80211s supports these by providing userspace hooks for custom path selection daemons. Which brings me to the main point of my e-mail: is anyone out there interested in porting batman's path selection algorithm into open80211s? The benefits: 1. By being based on a standard, you'll know you won't be colliding with other layer 2 technologies (for instance, no need to define your own ethertype) 2. You can leverage most of open80211s, from test tools to wireshark patches. 3. By being integrated in the kernel's 802.11 stack, you can take advantage of the development that's taking place there, from encrypted management frames to HT support. 4. You can reach out to a larger development community and raise awareness about batman. 5. A big problem in mesh adoption on Linux is not the mesh protocol itself but the absence of simple to use configuration tools (e.g. no mesh support in ConnMan, NetworkManager, etc.). By providing a unified wireless mesh framework we increase the likelihood of having some support at the distro level. and last, but not least... 6. You'll be able to say authoritatively that batman is X times more efficient than HWMP (pick any X greater than 1 :) Anyway, that was just a thought. If anyone is interested let me know. Cheers, Javier -- Javier Cardona cozybit Inc. http://www.cozybit.com

4 6

Re: [B.A.T.M.A.N.] A case for batman-11s
by Andrew Lunn 25 Aug '11

25 Aug '11

On Thu, Aug 25, 2011 at 09:36:14AM +0800, Yeoh Chun-Yeow wrote: > Hi, all, > > Although batman-adv is a layer 2 routing that works across multiple access > technologies (not so sure about other technologies, because it mainly use > for WiFi), but it only make senses if we configure the wireless interface > operating in adhoc or adhocdemo mode. If we configure the wireless interface > as Infrastructure mode, all the traffic will go to the AP first, even if we > can direct communicate between the two STAs. > > Correct me if I am wrong. Ideally, you have BATMAN on the AP as well as the STA. So you never do STA->AP->STA hops between BATMAN nodes, you only do a STA->AP BATMAN hop followed by a AP->STA BATMAN hop. Performing two BATMAN hops means BATMAN knows the transmit quality of each of the two wireless hop, not the combined transmit quality of the STA->AP->STA path. So BATMAN running on the AP can then decide if it makes sense to take a different path. There is code to enforce this, i.e. blocking STA->AP->STA transfers, in the development tree and it has been push upstream to be included in the mainline kernel. Andrew

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N