B.A.T.M.A.N November 2014

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

19 participants
48 discussions

[B.A.T.M.A.N.] wired only gigabit / 10 gigabit batman-adv mesh
by Mehul Sharma 28 Nov '14

28 Nov '14

Ok this is my 3rd attempt to see if this message makes it to the list :) .... during the attempts i have had the opportunity to understand some aspects clearly, thanks to the nice documentation and comments in the code. Hi Marek, Thanks for the explanation. One of the aims of the project (i.e the network part of it) is to use a mix of topologies (wired ethernet) with out the use of external switches (eg. top of the rack) / routers to connect machines (servers). The idea is to increase the bandwidth, increase the link utilization, bring about multiple paths to deal with link failures & also hop reduction to some sectors of the cluster. I am able to do this now with: 1) standard bridge + stp 2) standard bridge with no stp + logic to stop and forward traffic depending on the paths taken, hops involved and link utilization -- this is a hack on top of the ebtables and ip tables with code monitoring across the network. 3) use layer 3 OSPF or OLSR + layer 2 on top of it using meshed TINC VPN 4) proxy arp with separate forward / reverse rules (i.e separate routing tables / policy routing) + layer 2 tinc mesh on top of it The bottom line I am looking for something standard & flexible. Point 1, is standard and stable but not the flexibility i am looking for. Eg. with stp on, it puts a link (ethx device) in blocked mode where it detects a loop, to me this is a waste of a valid 10 gigabit or gigabit link which will only be utilized when a fail over happens. I would like to see more utilization of the link. So, i hacked up step 2, it would have been great if i had a majority of my time dedicated to it to build a kind of automation logic, but otherwise it is a manual time consuming setup. Point 3 works also but i would like to avoid pushing layer 2 over layer 3. Point 4, also works well, but i have to spend time convincing people that it is not arp-poisoning but rather arp-sweetening :) and most don't get that part :) (even if i tell them that your actual network (layer 2) will never see the communication at layer 3 below it. So, here i am, after years for some weird reason went back to the olsr page to see if there were some optimizations so that i could try / use it in place of ospf, and i came across batman-adv (it had been a while since i had done some deep dive wireless stuff), and quite frankly i could not believe it (i found it to have the best logic for next generation mesh networks ... others are entitled to their feelings / opinions). I took a look at the logic and architecture and got the feeling it had the potential to work in many ways better on wired ethernet than on wireless networks (due to the the wireless layer 1 link, frequency switching, CSMA and related complexities) .... i would like to continue the feeling for the sake of positivity and intuition :) What i saw (which could be my assumptive beliefs) was that batman-adv: 1) Most importantly could help in link utilization -- i read about network wide multi link optimizations [ alternating and bonding + alternating] 2) Path fail over -- use another path if the one it is currently using cannot be reached or another hop gets added. 3) Ease of setup -- adding the ethx devices to bat0 and adding bat0 to the bridge where other tap devices (virtual machines) and ethernet devices of existing wired network are present. 4) migration of non mesh clients, which might work for virtual machine migrations as well (not sure) 5) multicast, default gateway optimizations and wired back-bone loop prevention Yes, i understand that transmit quality (pertaining to link quality) is one of the main things batman-adv depends on for wireless networks (here i don't mean it might be checking quality of every link but instead checking if it sent / received certain internal packets within a certain time duration) , may be something of that nature for wired networks could be obtained by looking at hops involved per interface to reach the target and then setting penalty to that interface which has more hops (i think batman-adv might already be doing this). When compared with the bridge forwarding table look ups and then the actual forwarding, batman-adv's new network wide optimizations with maintaining separate routing table / list for separate interfaces involved in the mesh should not be a deterrent to speed, from my understanding the encapsulation of the ethernet frame into a batman-adv header may be an area of slow down comparatively (but then again this is done in kernel so speed should not be an issue especially with server cores involved). Just some thoughts, intuitive assumptions which may be totally wrong :) ..... i look forward to understanding more. Thanks & Best Regards, Mehul On Sun, Nov 16, 2014 at 1:08 AM, Marek Lindner <mareklindner(a)neomailbox.ch> wrote: Hi, > Good Afternoon from Boston. I really love Batman-Adv ... > brilliant layer 2 functionality. > > I want to use batman-adv in a wired (gigabit and 10-gigabit) only mesh and > wanted to know your insights. makes me happy to hear you love our project. Typically, we communicate via our public mailing list allowing various sources to chime in at any point. Since I don't see any reason for privacy I am cc'ing the mailing list in my answer. > The example case scenario is as follows: > > 1) 4 to 6 AMD servers with 6 10-Gigabit NICs each. > > 2) 2 or 3 10-Gigabit NICs used for batman-adv, which are then connected > in ring or torus topology directly (no external switch involved) > > 3) the remaining interfaces on the server are connected to the LAN > (switches, routers etc) > > 4) the virtual machine (qemu-kvm) tap interfaces, the physical > non-batman-adv ethernet and bat0 interfaces are put in a bridge (brctl), so > now we have the ability for virtual machines, wired hosts on the lan to go > via batman-adv and talk to each other. > > Is there any, down size to doing this? I see at the most 2 - 100 servers in > one network.... > > From what i understand: > > 1) that the live migration of virtual machines (qemu-kvm) will be seen > just as a migrating non-mesh client so my assumption is that live migration > should work from that perspective. Also, what if the tap interfaces of the > virtual machines are given to bat0 itself (if it might help in live > migration / increasing throughput) ? > > 2) The MTU if set for 1500 or 9000 or higher (eg barman-adv reads -- > "define ETHERMTU ETH_DATA_LEN") would be taken automatically by batman-adv > and anything below 1500 would be fragmented, which gives me the idea that > higher MTUs would not be a problem for batman-adv to handle. > > 3) There is no restriction to the number of clients in batman-adv. > > am i somewhat close in understanding batman-adv? .... apologies if not... > > Also would layer 2 forwarding by batman-adv would be close, same or better > when compared to bridge (linux brctl) packet forwarding? > > I have built converged-unified distributed qemu-kvm system (all metadata > less design, with web-interface and cli, quite the opposite of vmware and > open-stack type centralized approaches) and was in the preliminary stage of > looking at the possibility of integrating batman-adv into the design. > > Your input will be valuable for me to give server and desktop > virtualization a mesh architecture on top of already distributed design. I keep your description intact to allow other people to comment as well. Before we dive into the batman-adv details I'd like to understand what advantage batman-adv brings to the table in your scenario. The batman-adv project aims to facilitate layer2 routing in primarily wireless setups with dynamically changing links due to link quality changes or links being modified in an uncontrolled fashion (community mesh network). While batman-adv also is able to run on wired backbones this never was the main target and bears a number of drawbacks compared to other technologies. A simple example to picture this: The standard Linux bridge (configurable via brctl) does not run any link layer protocol to estimate the quality of one link compared to another. This will give you huge advantages in terms of overhead with the cost of all links being treated equal. While this work fine on an all-wired setup it represents an unacceptable trade-off for wireless networks. >From what I can gather you are not running wireless but high throughput wired links. What has brought you to batman-adv ? Cheers, Marek

1 0

[B.A.T.M.A.N.] [PATCHv9 0/4] Multicast optimizations for bridges
by Linus Lüssing 26 Nov '14

26 Nov '14

This patchset enables the usage of the batman-adv multicast optimizations for scenarios involving bridges on top of e.g. bat0, too. Along come two more patches adding according debugging facilities to make it possible for the user to check why the multicast optimizations might not work ideally to give hints about what they might change about their topology. The fourth one alters the forwarding behaviour for IGMP and MLD reports. For one thing this reduces overhead (especially for IGMPv3/MLDv2 reports). But more importantly this is necessary to make the optimizations work in bridged scenarios at all. For more details see: http://www.open-mesh.org/projects/batman-adv/wiki/Multicast-optimizations-l… Also note, that with PATCH 4/4 multicast optimizations do not build for kernels < 2.6.35 (net/mld.h didn't exist back then): If there are actually brave souls out there running such ancient end-of-life kernels, it is suggested to build batman-adv with the multicast-compile-time option disabled. Multicast optimizations for bridges does not half any benefits for kernels < 3.17 anyways. Cheers, Linus Changes in v9: - PATCH 1/4: * fix: added compat code for pr_warn_once() * compat fix for bridge export stubs: fixes compile error with kernels < 3.16 without bridge (snooping) support - PATCH 2/4: * perform updates of variables within bat_priv->mcast.querier_ipv{4,6} individually (there's a new, third member in 4/4 which shouldn't be overriden) * PATCH 4/4: NEW Changes in v8 (thanks to Simon's suggestions): - PATCH 2/3: * print shadowing status log of an appearing and shadowing querier, too (the bridge-querier-existence call has an additional 10s delay to ensure reports had their time to arrive - the bridge-querier-port call doesn't have that) - PATCH 3/3: * changing debugfs output from "+" and "-" to "U/4/6" and "." * fixing "no querier present" logic (introduced in [PATCHv7 3/3]) Changes in v7 (thanks to Simon's suggestions): - PATCH 2/3: * renaming old/new_querier to old/new_state * slightly extended kerneldoc of batadv_mcast_querier_log() * removing words "good" and "bad" from debug output * simplified batadv_mcast_flags_log() * assignment instead of memset in batadv_mcast_mla_tvlv_update() and batadv_softif_init_late() * simple struct member assignments instead of one complex struct assigment * removing unnecessary memcmp's * substituting return statement for an if-block in batadv_mcast_querier_log() and batadv_mcast_bridge_log() * print "Unsnoopables(U)-flag" instead of just "U-flag" - PATCH 3/3: * use bat_priv values instead of querying bridge ABI in batadv_mcast_flags_print_header() Changes in v6: * New PATCH 2/3 inserted, moving logging to separate patch * More verbose logging added to PATCH 2/3: Bridge and querier state changes are logged too * upper case to lower case for kernel doc of batadv_mcast_flags_open (PATCH 2/3) * Adding note to kernel doc of batadv_mcast_get_bridge about increased refcount (PATCH 1/3) * Printing some lines about current bridge and querier state to debugfs too (PATCH 3/3) Changes in v5 (PATCH 2/2 only): * s/dat_cache/mcast_flags/ in kerneldoc (copy&paste error) Changes in v4 (PATCH 2/2 only): * initial {ad,e}dition of this patch Changes in v3 (PATCH 1/2 only): * Removed "RFC" tag in title again: The stubs and new export are upstream in net-next and therefore going to be included in 3.17 * Added some debug output: * Two warning messages: -> Old kernel version or no bridge IGMP/MLD snooping compiled * New batman-adv log-level "mcast": -> Logging mcast flag changes (a third debugging facility, a new table for debugfs for a global mcast flag overview will be added in a separate patch later as discussed with Simon) Changes in v2 (PATCH 1/2 only): * fetching local (= on this same kernel) multicast listeners from the bridge instead of the bat0 interface if a bridge is present - just like ip addresses and routes should be used from br0, the same goes for multicast listeners * beautification of batadv_mcast_mla_br_addr_cpy(), now using already present functions from the kernel instead of own, hackish approach * changed names of some goto-labels (not using "skip" anymore) * using new, third bridge multicast export (because this export is not upstream yet, I've added the "RFC" in the title): br_multicast_has_querier_anywhere() * adding compat stubs for two bridge multicast exports, to make batman-adv compile- and usable even if a 3.16 kernel was compiled without bridge code - the stubs are supposed to be upstream in the bridge code in 3.17 (therefore just 'compat') * updated kerneldocs for batadv_mcast_mla_bridge_get() and batadv_mcast_mla_softif_get() * The two sentences in the commit message starting with "Queriers: ..." were slightly modified to include the third bridge multicast export

3 7

[B.A.T.M.A.N.] problems while patching vde 2.3.2
by Lucas Aimaretto 25 Nov '14

25 Nov '14

Hi all, I'm trying to patch VDE just as suggested in [1] but I'm having trouble. I've downloaded VDE 2.3.2 from here [2] and the patches from here [1]. I'm doing the following: lucas@test:~/batman-adv/ script/vde$ tar zxvf vde2-2.3.2.tar.gz lucas@test:~/batman-adv/script/vde$ patch vde2-2.3.2/src/vde_switch/port.c < vde2-2.3.2_colour.patch patching file vde2-2.3.2/src/vde_switch/port.c patching file vde2-2.3.2/src/vde_switch/port.c Hunk #1 FAILED at 68. 1 out of 1 hunk FAILED -- saving rejects to file vde2-2.3.2/src/vde_switch/port.c.rej What is it that I'm doing wrong? Any hint is appreciated ... Regards! Lucas [1] - http://www.open-mesh.org/projects/open-mesh/wiki/Emulation [2] - http://sourceforge.net/projects/vde/files/vde2/2.3.2/ -- "Antes teníamos hambre y mirábamos el reloj para saber qué hora era. Ahora miramos el reloj para saber si tenemos hambre." -- Ernesto Sábato

3 4

[B.A.T.M.A.N.] kernel BUG at net/core/skbuff.c:100
by Philipp Psurek 25 Nov '14

25 Nov '14

Hi all, I hope, You can help me debug this issue. I’m running batman-adv 2014.3.0 included in 3.16.7 linux. Something provokes kernel panic on the VM. It might be a modified or regular packet. The crash occurs at “prime time” but the machine is not under heavy load. I hope you can localize the error. I provide you with some crash dumps from a vmcore dump. Please tell me if you need more or there is something I should do to provide you with more information about this issue. Thank you all for B.A.T.M.A.N.-adv! Best regards Philipp crash 7.0.7 KERNEL: /usr/src/linux-3.16.7-gentoo/vmlinux DUMPFILE: vmcore_20141118174414 CPUS: 1 DATE: Tue Nov 18 16:17:01 2014 UPTIME: 16:30:32 LOAD AVERAGE: 0.19, 0.22, 0.25 TASKS: 124 NODENAME: wolke RELEASE: 3.16.7-gentoo VERSION: #1 SMP Mon Nov 17 03:44:22 CET 2014 MACHINE: x86_64 (2593 Mhz) MEMORY: 511.6 MB PANIC: "kernel BUG at net/core/skbuff.c:100!" PID: 2012 COMMAND: "fastd" TASK: ffff880019c411a0 [THREAD_INFO: ffff880019200000] CPU: 0 STATE: TASK_RUNNING (PANIC) crash> bt PID: 2012 TASK: ffff880019c411a0 CPU: 0 COMMAND: "fastd" #0 [ffff88001fc03980] machine_kexec at ffffffff8103a34e #1 [ffff88001fc039e0] crash_kexec at ffffffff810be503 #2 [ffff88001fc03ab0] oops_end at ffffffff81005fc8 #3 [ffff88001fc03ae0] die at ffffffff81006463 #4 [ffff88001fc03b10] do_trap at ffffffff81002e12 #5 [ffff88001fc03b70] do_error_trap at ffffffff8100316d #6 [ffff88001fc03c30] do_invalid_op at ffffffff8100394b #7 [ffff88001fc03c40] invalid_op at ffffffff817f385e [exception RIP: skb_panic+94] RIP: ffffffff817eb99d RSP: ffff88001fc03cf8 RFLAGS: 00010296 RAX: 000000000000008b RBX: ffff8800100ccee0 RCX: 0000000000000092 RDX: 0000000000000062 RSI: 0000000000000046 RDI: 0000000000000246 RBP: ffff88001fc03d18 R8: 0000000000000000 R9: 0000000000000000 R10: 00000000000001ed R11: 0000000000000006 R12: 0000000000000564 R13: ffff88001fc03da0 R14: ffff880013fd9100 R15: ffff880005948062 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #8 [ffff88001fc03d20] skb_put at ffffffff81611bb1 #9 [ffff88001fc03d30] batadv_frag_skb_buffer at ffffffffa002fdfa [batman_adv] #10 [ffff88001fc03d90] batadv_recv_frag_packet at ffffffffa003a213 [batman_adv] #11 [ffff88001fc03dd0] batadv_batman_skb_recv at ffffffffa0033e95 [batman_adv] #12 [ffff88001fc03e10] __netif_receive_skb_core at ffffffff81621962 #13 [ffff88001fc03e80] __netif_receive_skb at ffffffff81621e91 #14 [ffff88001fc03ea0] process_backlog at ffffffff81621f7e #15 [ffff88001fc03ef0] net_rx_action at ffffffff81622731 #16 [ffff88001fc03f50] __do_softirq at ffffffff81053ef8 #17 [ffff88001fc03fb0] do_softirq_own_stack at ffffffff817f3a5c --- <IRQ stack> --- #18 [ffff880019203d10] do_softirq_own_stack at ffffffff817f3a5c [exception RIP: tun_get_user+1056] RIP: ffffffffa001d8f0 RSP: 0000000000000001 RFLAGS: 7fff00000586 RAX: ffffffff816210b4 RBX: ffff880019203d58 RCX: ffff8800193dc780 RDX: 0000000000000000 RSI: ffff8800193dc780 RDI: 0000000000000586 RBP: ffffffff81620de4 R8: ffff880019203d88 R9: ffff8800193dc780 R10: ffff8800193dc780 R11: ffffffff81054135 R12: ffff880019203d58 R13: 0000000000000586 R14: ffff88001932b900 R15: 0000000000000000 ORIG_RAX: ffff880019203e38 CS: 7fff018d3a90 SS: 0000 bt: WARNING: possibly bogus exception frame #19 [ffff880019203e40] tun_chr_aio_write at ffffffffa001de0b [tun] #20 [ffff880019203e70] do_sync_write at ffffffff8115c665 #21 [ffff880019203f00] vfs_write at ffffffff8115d38a #22 [ffff880019203f40] sys_write at ffffffff8115d89a #23 [ffff880019203f80] system_call_fastpath at ffffffff817f1f29 RIP: 00007fef80cbe37d RSP: 00007fff018d3bd0 RFLAGS: 00000206 RAX: 0000000000000001 RBX: ffffffff817f1f29 RCX: 00000000000000b4 RDX: 0000000000000586 RSI: 00000000016e9ba0 RDI: 0000000000000009 RBP: 0000000000000586 R8: 00007fef80ca7400 R9: 00007fff018d31d8 R10: 00007fff018d391f R11: 0000000000000293 R12: 00000000016e9358 R13: 0000000000000001 R14: 00000000016e9b90 R15: 00000000016e13a0 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b crash> log […] [59432.101578] skbuff: skb_over_panic: text:ffffffffa002fdfa len:1464 put:1380 head:ffff88000596f800 data:ffff88000596f862 tail:0x61a end:0x2c0 dev:fastd0 [59432.101901] ------------[ cut here ]------------ [59432.102014] kernel BUG at net/core/skbuff.c:100! [59432.102125] invalid opcode: 0000 [#1] SMP [59432.102225] Modules linked in: xt_nat batman_adv libcrc32c tun iptable_nat nf_nat_ipv4 nf_nat ipip crc32c_intel [59432.102490] CPU: 0 PID: 2012 Comm: fastd Not tainted 3.16.7-gentoo #1 [59432.102519] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [59432.102519] task: ffff880019c411a0 ti: ffff880019200000 task.ti: ffff880019200000 [59432.102519] RIP: 0010:[<ffffffff817eb99d>] [<ffffffff817eb99d>] skb_panic+0x5e/0x60 [59432.102519] RSP: 0018:ffff88001fc03cf8 EFLAGS: 00010296 [59432.102519] RAX: 000000000000008b RBX: ffff8800100ccee0 RCX: 0000000000000092 [59432.102519] RDX: 0000000000000062 RSI: 0000000000000046 RDI: 0000000000000246 [59432.102519] RBP: ffff88001fc03d18 R08: 0000000000000000 R09: 0000000000000000 [59432.102519] R10: 00000000000001ed R11: 0000000000000006 R12: 0000000000000564 [59432.102519] R13: ffff88001fc03da0 R14: ffff880013fd9100 R15: ffff880005948062 [59432.102519] FS: 00007fef8196a700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 [59432.102519] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [59432.102519] CR2: 00007f5c610ac000 CR3: 0000000019352000 CR4: 00000000000006f0 [59432.102519] Stack: [59432.102519] ffff88000596f862 000000000000061a 00000000000002c0 ffff8800193dc000 [59432.102519] ffff88001fc03d28 ffffffff81611bb1 ffff88001fc03d88 ffffffffa002fdfa [59432.102519] ffff8800193aa168 ffff88000594804e ffff88001fc03d78 ffff8800100ccee0 [59432.102519] Call Trace: [59432.102519] <IRQ> [59432.102519] [59432.102519] [<ffffffff81611bb1>] skb_put+0x41/0x50 [59432.102519] [<ffffffffa002fdfa>] batadv_frag_skb_buffer+0x25a/0x410 [batman_adv] [59432.102519] [<ffffffffa003a213>] batadv_recv_frag_packet+0x183/0x200 [batman_adv] [59432.102519] [<ffffffffa0033e95>] batadv_batman_skb_recv+0xd5/0x110 [batman_adv] [59432.102519] [<ffffffff81621962>] __netif_receive_skb_core+0x222/0x730 [59432.102519] [<ffffffff81621e91>] __netif_receive_skb+0x21/0x70 [59432.102519] [<ffffffff81621f7e>] process_backlog+0x9e/0x170 [59432.102519] [<ffffffff81622731>] net_rx_action+0x141/0x240 [59432.102519] [<ffffffff81053ef8>] __do_softirq+0xe8/0x280 [59432.102519] [<ffffffff817f3a5c>] do_softirq_own_stack+0x1c/0x30 [59432.102519] <EOI> [59432.102519] [59432.102519] [<ffffffff81054135>] do_softirq+0x55/0x60 [59432.102519] [<ffffffff816210b4>] netif_rx_ni+0x34/0x70 [59432.102519] [<ffffffffa001d8f0>] tun_get_user+0x420/0x840 [tun] [59432.102519] [<ffffffffa001de0b>] tun_chr_aio_write+0x7b/0xa0 [tun] [59432.102519] [<ffffffff8115c665>] do_sync_write+0x55/0x90 [59432.102519] [<ffffffff8115d38a>] vfs_write+0xba/0x1f0 [59432.102519] [<ffffffff8115d89a>] SyS_write+0x4a/0xa0 [59432.102519] [<ffffffff817f1f29>] system_call_fastpath+0x16/0x1b [59432.102519] Code: 00 00 48 89 44 24 10 8b 87 c0 00 00 00 48 89 44 24 08 48 8b 87 d0 00 00 00 48 c7 c7 30 67 a3 81 48 89 04 24 31 c0 e8 0d 8b ff ff <0f> 0b 55 48 89 f8 48 8b 57 30 48 89 e5 48 8b 0f 5d 80 e5 80 48 [59432.102519] RIP [<ffffffff817eb99d>] skb_panic+0x5e/0x60 [59432.102519] RSP <ffff88001fc03cf8> crash> ps PID PPID CPU TASK ST %MEM VSZ RSS COMM 0 0 0 ffffffff81c16480 RU 0.0 0 0 [swapper/0] 1 0 0 ffff88001f140000 IN 0.3 4232 1508 init 2 0 0 ffff88001f1408d0 IN 0.0 0 0 [kthreadd] 3 2 0 ffff88001f1411a0 IN 0.0 0 0 [ksoftirqd/0] 5 2 0 ffff88001f142340 IN 0.0 0 0 [kworker/0:0H] 7 2 0 ffff88001f1434e0 IN 0.0 0 0 [rcu_sched] 8 2 0 ffff88001f143db0 IN 0.0 0 0 [rcu_bh] 9 2 0 ffff88001f144680 IN 0.0 0 0 [migration/0] 10 2 0 ffff88001f144f50 IN 0.0 0 0 [khelper] 11 2 0 ffff88001f145820 IN 0.0 0 0 [kdevtmpfs] 12 2 0 ffff88001f1460f0 IN 0.0 0 0 [netns] 16 2 0 ffff88001f3408d0 IN 0.0 0 0 [writeback] 18 2 0 ffff88001f341a70 IN 0.0 0 0 [crypto] 20 2 0 ffff88001f342c10 IN 0.0 0 0 [bioset] 22 2 0 ffff88001f343db0 IN 0.0 0 0 [kblockd] 48 2 0 ffff88001f3469c0 IN 0.0 0 0 [ata_sff] 51 2 0 ffff88001f345820 IN 0.0 0 0 [khubd] 53 2 0 ffff88001f347290 IN 0.0 0 0 [md] 56 2 0 ffff88001f340000 IN 0.0 0 0 [cfg80211] 69 2 0 ffff88001f344680 IN 0.0 0 0 [rpciod] 74 2 0 ffff88001f342340 IN 0.0 0 0 [kswapd0] 78 2 0 ffff88001f147290 IN 0.0 0 0 [fsnotify_mark] 80 2 0 ffff8800000808d0 IN 0.0 0 0 [nfsiod] 117 2 0 ffff88001f3434e0 IN 0.0 0 0 [acpi_thermal_pm] 734 2 0 ffff88001f2260f0 IN 0.0 0 0 [scsi_eh_0] 735 2 0 ffff88001f2269c0 IN 0.0 0 0 [scsi_tmf_0] 737 2 0 ffff88001f224f50 IN 0.0 0 0 [scsi_eh_1] 739 2 0 ffff88001f223db0 IN 0.0 0 0 [scsi_tmf_1] 774 2 0 ffff88001a3d7290 IN 0.0 0 0 [kpsmoused] 781 2 0 ffff88001a3d4f50 IN 0.0 0 0 [ipv6_addrconf] 785 2 0 ffff88001a3d60f0 IN 0.0 0 0 [deferwq] 869 2 0 ffff88001f32cf50 IN 0.0 0 0 [kjournald] 1053 1 0 ffff88001f329a70 IN 0.6 36576 2916 systemd-udevd 1110 2 0 ffff88001f32e0f0 IN 0.0 0 0 [kworker/0:1H] 1493 1 0 ffff880019c47290 IN 0.3 4240 1544 acpid 1514 1 0 ffff880019c460f0 IN 0.4 17752 2316 crond 1860 1 0 ffff88001f32ac10 IN 7.9 749452 41644 ntop 1861 1 0 ffff88001f32d820 IN 7.9 749452 41644 ntop 1862 1 0 ffff88001f3291a0 IN 7.9 749452 41644 ntop 1863 1 0 ffff880019c43db0 IN 7.9 749452 41644 ntop 1864 1 0 ffff880019c45820 IN 7.9 749452 41644 ntop 1865 1 0 ffff880019c41a70 IN 7.9 749452 41644 ntop 1866 1 0 ffff880019c408d0 IN 7.9 749452 41644 ntop 1885 1 0 ffff880019c44f50 IN 7.9 749452 41644 ntop 1886 1 0 ffff880019c434e0 IN 7.9 749452 41644 ntop 1890 1 0 ffff880019c40000 IN 0.6 41536 3200 sshd 1935 1 0 ffff88001a39d820 IN 0.4 14232 2072 agetty 1939 1 0 ffff88001a398000 IN 7.9 749452 41644 ntop 1963 2 0 ffff88001037c680 IN 0.0 0 0 [kworker/u2:1] > 2012 1 0 ffff880019c411a0 RU 0.5 179496 2836 fastd 2028 2 0 ffff88001f225820 IN 0.0 0 0 [bat_events] 2043 1 0 ffff88001f224680 IN 0.5 11904 2664 alfred 2044 1 0 ffff88001f227290 IN 0.8 51388 3992 sudo 2045 2044 0 ffff88001f2211a0 IN 0.4 8684 1860 batadv-vis 2046 2043 0 ffff88001f221a70 IN 0.8 51388 3980 sudo 2047 2046 0 ffff88001f2208d0 IN 0.3 8484 1592 alfred 2093 1 0 ffff88001a399a70 IN 2.4 43536 12344 dhcpd 2133 1 0 ffff88001f222340 IN 0.3 7336 1692 vnstatd 2177 1 0 ffff88001f32b4e0 IN 7.5 177112 39340 named 2178 1 0 ffff88001f32e9c0 IN 7.5 177112 39340 named 2179 1 0 ffff88001f32bdb0 IN 7.5 177112 39340 named 2180 1 0 ffff88001f3288d0 IN 7.5 177112 39340 named 2230 1 0 ffff88001f220000 IN 4.5 300988 23680 apache2 2232 2230 0 ffff880019c42c10 IN 1.3 227520 6716 apache2 2247 2230 0 ffff880019c44680 IN 11.9 1066408 62252 apache2 2248 2230 0 ffff880019c469c0 IN 11.9 1066408 62524 apache2 2251 2230 0 ffff88001f32a340 IN 11.9 1066408 62524 apache2 2252 2230 0 ffff88001f344f50 IN 11.9 1066408 62524 apache2 2253 2230 0 ffff88001f3411a0 IN 11.9 1066408 62524 apache2 2254 2230 0 ffff88001a3991a0 IN 11.9 1066408 62524 apache2 2255 2230 0 ffff88001a39b4e0 IN 11.9 1066408 62524 apache2 2256 2230 0 ffff88001a2ed820 IN 11.9 1066408 62524 apache2 2257 2230 0 ffff88001a2ef290 IN 11.9 1066408 62524 apache2 2258 2230 0 ffff88001a2ecf50 IN 11.9 1066408 62524 apache2 2259 2230 0 ffff88001a2e9a70 IN 11.9 1066408 62524 apache2 2260 2230 0 ffff88001a2ec680 IN 11.9 1066408 62524 apache2 2261 2230 0 ffff88001a2e91a0 IN 11.9 1066408 62524 apache2 2262 2230 0 ffff88001a2ee0f0 IN 11.9 1066408 62524 apache2 2263 2230 0 ffff88001a2e88d0 IN 11.9 1066408 62524 apache2 2264 2230 0 ffff88001a2e8000 IN 11.9 1066408 62524 apache2 2265 2230 0 ffff88001a2ea340 IN 11.9 1066408 62524 apache2 2266 2230 0 ffff88001a2eac10 IN 11.9 1066408 62524 apache2 2267 2230 0 ffff88001a2eb4e0 IN 11.9 1066408 62524 apache2 2268 2230 0 ffff88001a2ebdb0 IN 11.9 1066408 62524 apache2 2269 2230 0 ffff88001a3d2c10 IN 11.9 1066408 62524 apache2 2270 2230 0 ffff88001a3d08d0 IN 11.9 1066408 62524 apache2 2271 2230 0 ffff88001a3d2340 IN 11.9 1066408 62524 apache2 2272 2230 0 ffff88001a3d1a70 IN 11.9 1066408 62524 apache2 2273 2230 0 ffff88001a3d11a0 IN 11.9 1066408 62252 apache2 2274 2230 0 ffff88001a3d0000 IN 11.9 1066408 62252 apache2 2275 2230 0 ffff88001a3d3db0 IN 11.9 1066408 62252 apache2 2276 2230 0 ffff88001a3d5820 IN 11.9 1066408 62252 apache2 2277 2230 0 ffff88001a3d69c0 IN 11.9 1066408 62252 apache2 2278 2230 0 ffff880000081a70 IN 11.9 1066408 62252 apache2 2279 2230 0 ffff880000082340 IN 11.9 1066408 62252 apache2 2280 2230 0 ffff880000082c10 IN 11.9 1066408 62252 apache2 2281 2230 0 ffff8800000834e0 IN 11.9 1066408 62252 apache2 2282 2230 0 ffff880000083db0 IN 11.9 1066408 62252 apache2 2283 2230 0 ffff880000084680 IN 11.9 1066408 62252 apache2 2284 2230 0 ffff880000084f50 IN 11.9 1066408 62252 apache2 2285 2230 0 ffff880000085820 IN 11.9 1066408 62252 apache2 2286 2230 0 ffff8800000860f0 IN 11.9 1066408 62252 apache2 2287 2230 0 ffff880000087290 IN 11.9 1066408 62524 apache2 2288 2230 0 ffff8800000811a0 IN 11.9 1066408 62524 apache2 2289 2230 0 ffff880000080000 IN 11.9 1066408 62524 apache2 2290 2230 0 ffff880013f18000 IN 11.9 1066408 62524 apache2 2291 2230 0 ffff8800000869c0 IN 11.9 1066408 62252 apache2 2292 2230 0 ffff880013f188d0 IN 11.9 1066408 62252 apache2 2293 2230 0 ffff880013f191a0 IN 11.9 1066408 62252 apache2 2294 2230 0 ffff880013f19a70 IN 11.9 1066408 62252 apache2 2295 2230 0 ffff880013f1a340 IN 11.9 1066408 62252 apache2 2296 2230 0 ffff880013f1ac10 IN 11.9 1066408 62252 apache2 2297 2230 0 ffff880013f1b4e0 IN 11.9 1066408 62252 apache2 2298 2230 0 ffff880013f1bdb0 IN 11.9 1066408 62252 apache2 2299 2230 0 ffff880013f1c680 IN 11.9 1066408 62252 apache2 2300 2230 0 ffff880013f1cf50 IN 11.9 1066408 62252 apache2 2301 2230 0 ffff880013f1d820 IN 11.9 1066408 62252 apache2 2302 2230 0 ffff880013f1e0f0 IN 11.9 1066408 62252 apache2 2318 1 0 ffff880013ff88d0 IN 0.5 11904 2680 runmap 4410 2 0 ffff88001a39f290 IN 0.0 0 0 [kworker/0:2] 5335 2 0 ffff88001037f290 IN 0.0 0 0 [kworker/u2:0] 6096 2 0 ffff88001037e0f0 IN 0.0 0 0 [kworker/0:1] 7792 2 0 ffff88001a39bdb0 IN 0.0 0 0 [kworker/0:0] 8412 2318 0 ffff88001037ac10 IN 0.2 4220 1308 sleep crash> files PID: 2012 TASK: ffff880019c411a0 CPU: 0 COMMAND: "fastd" ROOT: / CWD: / FD FILE DENTRY INODE TYPE PATH 0 ffff88001f35f100 ffff88001a776c00 ffff880019a53440 CHR /dev/pts/0 1 ffff88001f35f100 ffff88001a776c00 ffff880019a53440 CHR /dev/pts/0 2 ffff88001f35f100 ffff88001a776c00 ffff880019a53440 CHR /dev/pts/0 3 ffff88001935f300 ffff88001a7076c0 ffff88001f14fce0 CHR /dev/urandom 5 ffff88001935f700 ffff880019a96600 ffff88001a77dbb0 SOCK UNIX 6 ffff88001935f900 ffff880019a96900 ffff88001a77d930 SOCK UNIX 7 ffff88001935f400 ffff880019a94f00 ffff88001a74fd40 UNKN [eventpoll] 8 ffff88001935f100 ffff880019a94e40 ffff88001a77d6b0 SOCK UDP 9 ffff880019376200 ffff88001a7ed0c0 ffff88001a3fba48 CHR /dev/net/tun # batctl -v batctl gentoo-2014.3.0 [batman-adv: 2014.3.0] # fastd -v fastd v16 # batctl if fastd0: active

2 14

[B.A.T.M.A.N.] [PATCH maint] batman-adv: avoid NULL dereferences and fix if check
by Antonio Quartulli 17 Nov '14

17 Nov '14

Gateway having bandwidth_down equal to zero are not accepted at all and so never added to the Gateway list. For this reason checking the bandwidth_down member in batadv_gw_out_of_range() is useless. This is probably a copy/paste error and this check was supposed to be "!gw_node" only. Moreover, the way the check is written now may also lead to a NULL dereference. Fix this by rewriting the if-condition properly. Introduced by 0853ec7fafe0a195754454832993c6b35e22b842 ("batman-adv: tvlv - gateway download/upload bandwidth container") Signed-off-by: Antonio Quartulli <antonio(a)meshcoding.com> Reported-by: David Binderman <dcb314(a)hotmail.com> --- This patch makes "batman-adv: avoid NULL dereferences and clarify if check" obsolete. gateway_client.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gateway_client.c b/gateway_client.c index bcc3e0c..27649e8 100644 --- a/gateway_client.c +++ b/gateway_client.c @@ -811,7 +811,7 @@ bool batadv_gw_out_of_range(struct batadv_priv *bat_priv, goto out; gw_node = batadv_gw_node_get(bat_priv, orig_dst_node); - if (!gw_node->bandwidth_down == 0) + if (!gw_node) goto out; switch (atomic_read(&bat_priv->gw_mode)) { -- 1.8.5.5

2 1

[B.A.T.M.A.N.] Current OpenWrt build
by Jay Brussels 16 Nov '14

16 Nov '14

Antonio, I am planning to start programming Ubiquiti and TP-Link Routers in two weeks for a very large BATMAN mesh deployment. Although many patches I have seen on this list involves multicast traffic I have seen some others. Is the current OpenWrt release stable enough for deployment or are there some "must have" patches requiring a build from scratch for a successful deployment? Jay Brussels President DSL Express 954-757-3254 jay(a)dslx.net -----Original Message----- From: B.A.T.M.A.N [mailto:b.a.t.m.a.n-bounces@lists.open-mesh.org] On Behalf Of Krishnathiepan Rasanayagam Sent: Wednesday, November 12, 2014 6:51 AM To: The list for a Better Approach To Mobile Ad-hoc Networking Subject: Re: [B.A.T.M.A.N.] Threads in batman-adv yep. i should have :) now only freading it out. sorry thanks alot for replying :) On Wed, Nov 12, 2014 at 2:47 PM, Antonio Quartulli <antonio(a)meshcoding.com> wrote: > > > On 12/11/14 09:19, Krishnathiepan Rasanayagam wrote: >> Hi All, >> >> Has anyone considered using threads in batman-adv? > > did you mean kthread? I don't think this would bring any real benefit. > You should probably read/understand the rest of the networking stack > in the linux kernel to understand how incoming/outgoing packets are handled. > >> is is possible to use fork() send.c file? > > fork() is a function that is supposed to be used in *userspace* to > create a new *process*. > This is neither available nor conceptually possible in kernel space. > > Maybe you should read a bit more about what you can do and what you > cannot do while developing a kernel module? :) > > -- > Antonio Quartulli > -- Best regards, Krishna.

4 8

[B.A.T.M.A.N.] [PATCHv2 0/2] fixes for multicast counter imbalances
by Linus Lüssing 16 Nov '14

16 Nov '14

The following two patches fix critical bugs with the counter tracking the number of nodes with no multicast optimizations support. Mesh networks from batman-adv version 2014.2.0 or later are potentially affected and might kill kittens (or at least kills downloads of cat pictures you try to do over IPv6). Cheers, Linus Changelog v2: - PATCH 1/2: * changed author email - PATCH 2/2: * new

2 4

Re: [B.A.T.M.A.N.] wired only 10 gigabit batman-adv mesh
by Marek Lindner 16 Nov '14

16 Nov '14

Hi, > Good Afternoon from Boston. I really love Batman-Adv ... > brilliant layer 2 functionality. > > I want to use batman-adv in a wired (gigabit and 10-gigabit) only mesh and > wanted to know your insights. makes me happy to hear you love our project. Typically, we communicate via our public mailing list allowing various sources to chime in at any point. Since I don't see any reason for privacy I am cc'ing the mailing list in my answer. > The example case scenario is as follows: > > 1) 4 to 6 AMD servers with 6 10-Gigabit NICs each. > > 2) 2 or 3 10-Gigabit NICs used for batman-adv, which are then connected > in ring or torus topology directly (no external switch involved) > > 3) the remaining interfaces on the server are connected to the LAN > (switches, routers etc) > > 4) the virtual machine (qemu-kvm) tap interfaces, the physical > non-batman-adv ethernet and bat0 interfaces are put in a bridge (brctl), so > now we have the ability for virtual machines, wired hosts on the lan to go > via batman-adv and talk to each other. > > Is there any, down size to doing this? I see at the most 2 - 100 servers in > one network.... > > From what i understand: > > 1) that the live migration of virtual machines (qemu-kvm) will be seen > just as a migrating non-mesh client so my assumption is that live migration > should work from that perspective. Also, what if the tap interfaces of the > virtual machines are given to bat0 itself (if it might help in live > migration / increasing throughput) ? > > 2) The MTU if set for 1500 or 9000 or higher (eg barman-adv reads -- > "define ETHERMTU ETH_DATA_LEN") would be taken automatically by batman-adv > and anything below 1500 would be fragmented, which gives me the idea that > higher MTUs would not be a problem for batman-adv to handle. > > 3) There is no restriction to the number of clients in batman-adv. > > am i somewhat close in understanding batman-adv? .... apologies if not... > > Also would layer 2 forwarding by batman-adv would be close, same or better > when compared to bridge (linux brctl) packet forwarding? > > I have built converged-unified distributed qemu-kvm system (all metadata > less design, with web-interface and cli, quite the opposite of vmware and > open-stack type centralized approaches) and was in the preliminary stage of > looking at the possibility of integrating batman-adv into the design. > > Your input will be valuable for me to give server and desktop > virtualization a mesh architecture on top of already distributed design. I keep your description intact to allow other people to comment as well. Before we dive into the batman-adv details I'd like to understand what advantage batman-adv brings to the table in your scenario. The batman-adv project aims to facilitate layer2 routing in primarily wireless setups with dynamically changing links due to link quality changes or links being modified in an uncontrolled fashion (community mesh network). While batman-adv also is able to run on wired backbones this never was the main target and bears a number of drawbacks compared to other technologies. A simple example to picture this: The standard Linux bridge (configurable via brctl) does not run any link layer protocol to estimate the quality of one link compared to another. This will give you huge advantages in terms of overhead with the cost of all links being treated equal. While this work fine on an all-wired setup it represents an unacceptable trade-off for wireless networks. From what I can gather you are not running wireless but high throughput wired links. What has brought you to batman-adv ? Cheers, Marek

1 0

[B.A.T.M.A.N.] [PATCH] net: set name_assign_type in alloc_netdev()
by Simon Wunderlich 16 Nov '14

16 Nov '14

From: Tom Gundersen <teg(a)jklm.no> Extend alloc_netdev{,_mq{,s}}() to take name_assign_type as argument, and convert all users to pass NET_NAME_UNKNOWN. Coccinelle patch: @@ expression sizeof_priv, name, setup, txqs, rxqs, count; @@ ( -alloc_netdev_mqs(sizeof_priv, name, setup, txqs, rxqs) +alloc_netdev_mqs(sizeof_priv, name, NET_NAME_UNKNOWN, setup, txqs, rxqs) | -alloc_netdev_mq(sizeof_priv, name, setup, count) +alloc_netdev_mq(sizeof_priv, name, NET_NAME_UNKNOWN, setup, count) | -alloc_netdev(sizeof_priv, name, setup) +alloc_netdev(sizeof_priv, name, NET_NAME_UNKNOWN, setup) ) v9: move comments here from the wrong commit Signed-off-by: Tom Gundersen <teg(a)jklm.no> Reviewed-by: David Herrmann <dh.herrmann(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [sw: added compat code] Signed-off-by: Simon Wunderlich <sw(a)simonwunderlich.de> --- compat.h | 14 ++++++++++++++ soft-interface.c | 2 +- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/compat.h b/compat.h index ed5b815..d218426 100644 --- a/compat.h +++ b/compat.h @@ -446,4 +446,18 @@ static int __batadv_interface_kill_vid(struct net_device *dev, __be16 proto,\ #endif /* < KERNEL_VERSION(3, 16, 0) */ +#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) + +/* alloc_netdev() was defined differently before 2.6.38 */ +#undef alloc_netdev +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 38) +#define alloc_netdev(sizeof_priv, name, name_assign_type, setup) \ + alloc_netdev_mq(sizeof_priv, name, setup, 1) +#else +#define alloc_netdev(sizeof_priv, name, name_assign_type, setup) \ + alloc_netdev_mqs(sizeof_priv, name, setup, 1, 1) +#endif /* nested < KERNEL_VERSION(2, 6, 38) */ + +#endif /* < KERNEL_VERSION(3, 17, 0) */ + #endif /* _NET_BATMAN_ADV_COMPAT_H_ */ diff --git a/soft-interface.c b/soft-interface.c index 9bf382d..cfc2cd2 100644 --- a/soft-interface.c +++ b/soft-interface.c @@ -933,7 +933,7 @@ struct net_device *batadv_softif_create(const char *name) int ret; soft_iface = alloc_netdev(sizeof(struct batadv_priv), name, - batadv_softif_init_early); + NET_NAME_UNKNOWN, batadv_softif_init_early); if (!soft_iface) return NULL; -- 1.9.1

2 1

[B.A.T.M.A.N.] [PATCH] batctl: add missing break
by Antonio Quartulli 16 Nov '14

16 Nov '14

Reaported-by: Coverity Scan Signed-off-by: Antonio Quartulli <antonio(a)meshcoding.com> --- tcpdump.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tcpdump.c b/tcpdump.c index ad5469b..71e2dd9 100644 --- a/tcpdump.c +++ b/tcpdump.c @@ -839,6 +839,7 @@ static void parse_eth_hdr(unsigned char *packet_buff, ssize_t buff_len, int read case BATADV_UNICAST_4ADDR: if (dump_level & DUMP_TYPE_BATUCAST) dump_batman_4addr(packet_buff, buff_len, read_opt, time_printed); + break; case BATADV_UNICAST_TVLV: if ((dump_level & DUMP_TYPE_BATUCAST) || (dump_level & DUMP_TYPE_BATUTVLV)) -- 2.1.3

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N November 2014