using alfred (or other means) to collect link data
I'm looking for a way to collect link data between nodes. My google-fu has failed me on how to get node-to-node data like latency or throughput etc. Is there any model built in to batman-adv/alfred to poll this data? I only really finding the batvis data which is just returning metric. I'm mostly wanting to see how traffic is flowing, where links are being more heavily used especially if those are not shortest paths (suggests I have something to fix) and to keep track of a sort of high water mark to metric ratio. ie, this link has done 260Mbps with the link metric <=1.2 in the last 48 hours and it's currently doing 105Mbps at 1.08 metric. my current plan is to run scripts to find 1 hop neighbors and either so an arp-scan or find IP and ping directly on a schedule and store that in alfred or just push it up to my database but this is a little brute-forcy considering batman-adv is doing some of this work to create the route metric in the first place. Any advice appreciated. Thanks.
zero hop penalty interface?
Hi all. I'm struggling to find an answer to this specific question about path selection. I'm looking at building a prototype mesh out of the banana pi BPI-R3. That's a dual band wifi 6/6e router that runs open-wrt. 1x 2.4Ghz and 1x5-6Ghz. I would build this as a quasi-dual radio mesh. ie, I want to favor the 5-6Ghz radio and add a large hop penalty to the 2.4Ghz so that it's only used for backup. The 2.4Ghz is a fraction the speed of the 5-6Ghz. What I'm considering is that as I saturate the 'single radio mesh' that the 5-6Ghz radios is essentially making since 2.4Ghz is purposely high-cost, I may want to add a second unit starting from the main uplink out as a secondary mesh, then linking both units together via 2.5-5GbE ports on the device. The question is, can I make the hop penalty zero so the mesh treats this pair of routers basically as one? for instance data comes into node10a's 5Ghz radio, I'd like that to try to go across the 'zero cost' ethernet and exit via node10b's 5Ghz radio to make this effectively a dual radio mesh. Ultimately the same would be true of the 2.4Ghz but again, that's ideally for backup meshing as it should look like an expensive hop.
Re: Passing VID-aware ethernet frames on plain batX interfaces
I see value in both methods, but for my use case I'm most interested in bat0 as the 'fabric' so the batman-adv nodes don't need any additional configuration to carry the VLANs. so, based on the previous statement, is the way to make bat0 agnostic about VLANs to create a bridge br0 and put bat0 in br0 and then make a br0.10 vlan interface? On Fri, Sep 11, 2020 at 6:50 AM Sven Eckelmann wrote: > > On Friday, 11 September 2020 14:48:19 CEST Sven Eckelmann wrote: > > On Friday, 11 September 2020 14:19:59 CEST Alessandro Bolletta wrote: > > > So you mean that it is not feasible to create a (single) linux network > > > interface that let me send traffic on the batman-adv network in an > > > untagged or tagged way, though the same interface I mean? > > > > batman-adv is depending on the Linux code telling it what VLAN it should > > handle (through ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid). So something > > like the 8021q driver or the bridge code for vlans. Only when this was done, > > it will also handle the addresses in TT. So no, bat0 is not enough to > > transport something like an ethernet frame tagged as vlan1. You also need > > bat0.1 (assuming this is the vlan interface for VID 1). But it is then not > > really relevant for it whether the data was send through bat0.1 or was > > somehow > > else tagged and then put into bat0. > > Btw. why are you now using VLANs on top of bat0 - weren't you trying before to > have multiple mesh clouds by using VLAN (or VLAN-like) technologies below > bat0? > > Kind regards, > Sven
Re: KASAN: slab-out-of-bounds Read in bitmap_ip_ext_cleanup
On Mon, Jan 20, 2020 at 02:19:31PM +0100, Christian Brauner wrote:
> On Sun, Jan 19, 2020 at 05:35:01PM -0800, syzbot wrote:
> > syzbot has bisected this bug to:
> >
> > commit d68dbb0c9ac8b1ff52eb09aa58ce6358400fa939
> > Author: Christian Brauner
> > Date: Thu Jun 20 23:26:35 2019 +
> >
> > arch: handle arches who do not yet define clone3
> >
> > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1456fed1e0
> > start commit: 09d4f10a net: sched: act_ctinfo: fix memory leak
> > git tree: net
> > final crash:https://syzkaller.appspot.com/x/report.txt?x=1656fed1e0
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1256fed1e0
> > kernel config: https://syzkaller.appspot.com/x/.config?x=7e89bd00623fe71e
> > dashboard link: https://syzkaller.appspot.com/bug?extid=6491ea8f6dddbf04930e
> > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141af959e0
> > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1067fa85e0
> >
> > Reported-by: syzbot+6491ea8f6dddbf049...@syzkaller.appspotmail.com
> > Fixes: d68dbb0c9ac8 ("arch: handle arches who do not yet define clone3")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> This bisect seems bogus.
>
Yeah. József Kadlecsik already fixed the bug in a different thread. It
was reported as seven different bugs so there was a bunch of threads for
it.
regards,
dan carpenter
Batman-adv behind bridge to wireless?
I'm considering a certain deployment model here and wanted to get some expert input. The design would be -batman-adv router (could be raspberry pi, or pcengines, etc) -1,2,3 etc complete radio devices doing 802.11s or dynamic WDS etc with that radio interface bridged to an ethernet port connected to the batman-adv router. This might be called 'radio on a stick'. an example might be 2 mikrotik omnitik ac devices on different channels, each with their 5Ghz radio configured as ap-bridge with dynamic WDS, those WDS interfaces would be bridged with horizon (to eliminate loops) and 1 ethernet interface w/o horizon. Those interfaces would connect to the batman-adv router. mikrotik has an hwmp based mesh, but it's primitive and I don't want nodes responding to other nodes in that mesh, I want batman-adv magic in the mix. I might utilize this interface but with a 1 hop limit so it works a lot like a horizon bridge without using horizon. this design appears as ptp links plugged into a switch and has no opportunity for loops. Each batman-adv router can broadcast and each other batman-adv will receive that through the bridge because it doesn't have horizon set, but the A and C devices that are 'bridged' by B can't because those interfaces share horizon on B, or the hop limit depending on the interface used. I'm thinking that solves any issues batman-adv might have with putting the 'switch/hub' of sorts in the middle. One thing I'm trying to solve here is the classic single radio mesh issue of halves bandwidth, as well as having link health in the mix without taking an interface offline. I'd rather have 2% packet loss on an interface that have 100% packet loss. additionally, this is for a hybrid mesh design where there is a ~50 node mesh with 2-3 backhauls to a mesh entry point on a tower, and then likely a 'midspan' link or two with high capacity radios to reduce hop count. finally, this allows me to use off-the-shelf devices with pole mounts etc for this while running the batman-adv router on the ground in an appropriate container. A raspberry pi4 would be a great router for this and I could use VLANs up the feed ethernet link. Thoughts?
Re: [B.A.T.M.A.N.] What is link throughput used for?
Thanks Sven. Very helpful. On Sat, Jul 7, 2018 at 2:04 PM, Sven Eckelmann wrote: > On Samstag, 7. Juli 2018 21:31:16 CEST dan wrote: >> How is this used? Where's the documentation? > > https://www.open-mesh.org/projects/batman-adv/wiki/BATMAN_V + linked pages > > Kind regards, > Sven > > >
[B.A.T.M.A.N.] What is link throughput used for?
I'm not finding a document describing how link throughput is used in routing decisions but I see in 2016.1 setting this value (and the default of learning it) are described: Throughput override Available since: batman-adv 2016.1 Defines the throughput value to be used by B.A.T.M.A.N. V when estimating the link throughput for all neighbors connected to this interface. If the value is set to 0 then batman-adv will try to estimate the throughput by itself by either querying the WiFi driver or the Ethernet interface. B.A.T.M.A.N. IV ignores the setting entirely. cat /sys/class/net/eth0/batman_adv/throughput_override 0.0 MBit How is this used? Where's the documentation? Thanks.
Re: [B.A.T.M.A.N.] where is batman-adv on multicast? specifically IPTV
I'm not brave enough to test :) I'm still evaluating batman-adv for this deployment model and haven't even setup real hardware to test yet. I think that I can live with a separate VLAN and PIM multicast routing if need be plus I'd probably be running whichever batman-adv version is in-kernel on ubuntu so that upgrades are more seamless so I would imagine quite a long time until these patches make it in. On Sun, May 27, 2018 at 4:08 PM, Linus Lüssing wrote: > Hi Dan, > > On Sat, May 26, 2018 at 07:43:03PM -0600, dan wrote: > [...] >> I see that if there is just one listener, then it basically becomes a >> unicast stream. But what if I have multiple sites (lets say 10) and >> at 2 sites there are 1 listener each. >> >> does this mean that all 10 sites will get the broadcast? or that just >> the 2 sites that have listeners will get the broadcast? > > Currently, if 2 (or more) batman-adv nodes have 1 listener each (for > the same multicast group) then the packet will be flooded. Meaning all > nodes in the mesh will receive it. > > I currently have two more patches for batman-adv open for further > testing to allow not just multicast-to-unicast conversion to a > single destination, but a multicast-to-multi-unicast conversion, too. > They are currently burried in here: > > https://github.com/freifunk-gluon/gluon/pull/1357 > > If you are interested and brave enough to try them then let me > know how that goes for you :-). > > Regards, Linus
[B.A.T.M.A.N.] where is batman-adv on multicast? specifically IPTV
you may have seen my other posts about wISP service for batman-adv. I'm looking at how batman-adv can handle multicast the design is batman-adv running over PtP wireless links and then PtMP access radios bridged in. I'm looking at the multicast-optimizations page but I'm unclear on something. I see that if there is just one listener, then it basically becomes a unicast stream. But what if I have multiple sites (lets say 10) and at 2 sites there are 1 listener each. does this mean that all 10 sites will get the broadcast? or that just the 2 sites that have listeners will get the broadcast? I'm not sure how old that page is or if anything has evolved. The goal here would be to only send a stream to a site if there were at least 1 listener. I could also potentially have a device at each site handling PIM for multicast, but I haven't dived into how that would work on batman-adv or if I'd have to run a separaet VLAN between each PIM router outside of batman-adv.
[B.A.T.M.A.N.] how to avoid loops, unusual config
Ok, so I'm trying to mock up a very simple network design and I'm having trouble getting 'out of the box' nodes APU2C4 with 3 ethernet ports all ports ethx native vlan ethx.11 mesh vlan bat0(eth0.11, eth1.11, eth2.11) <- so I can transport the mesh only on configured interfaces and leave the 'native' ethernet port accessible to non-mesh devices br0(eth0,eth1,eth2,bat0) <- gets everything on the mesh. And the issue is.. If I plug a point to point radio between nodes on eth0 node0.eth0 <> eth0.node1 I'm creating a layer2 link which is bridged into the mesh on both node0 and node1, so that's the direct link AND bat0 which is a loop. I'm reading on bridge loop avoidance, is this as simple as turning that on with: #batctl bl 1 This is a proof of concept for wISP service the goal being to have a node with a very basic configuration and have all port's native VLAN be usable to non-mesh-aware devices which includes point-to-point radios and point-to-multipoint access radios. I just can't get out of the ptp radio causing a loop and I need to be able to access the ptp radio interfaces on an untagged vlan. I have considered managing the ptp radios on separate vlans and NOT having the eth0 interface in bat0 eth0.11 mesh eth0.12 master ptp radio eth0.13 slave ptp radio on node0 br0(bat0,eth1,eth2,eth0.12) on node1 br0(bat0,eth1,eth2,eth0.13) which I think solves the bridge loop issue *but* it means I have to rely on the ptp radio supporting setting it's management interface to a vlan. The irony is that the cheapest radios support this, and the highest end radios have dedicated management ports so I can ignore this, but in the middle of the road radios don't. So this is not ideal on that front as well as it's a more complicated design and means the mesh nodes aren't a standard config. Thoughts?
Re: [B.A.T.M.A.N.] sanity check please
Sven, I'm not actually concerned with the performance here, it's good enough *if* this is actually realistic and not a weird effect of the virtual environment. ALL of my gear is limited by a 1Gbps port and I also basically trapped all the VMs and virtio ethernet devices to a single CPU. It's just going to cost me $400-$500 in hardware purchases to take the next step. On Fri, May 11, 2018 at 12:06 AM, Sven Eckelmann wrote: > On Donnerstag, 10. Mai 2018 01:43:56 CEST dan wrote: > [...] >> I'm running iperf3 with VM1 the server and VM3 the client >> >> VM1 >> iperf3 -s >> VM3 >> iperf3 -c 192.168.5.1 -b 1M -t 60 -P 1 >> >> output is 1.75Gbits >> >> -P 99 >> >> output is 831Mbps >> >> >> -P 99 *BUT* hitting the 'native' LAN address of 192.168.1.1 (each VM >> has an ens18 on this network) >> >> 4.8Gbps >> >> -P 99 from VM2 >> >> ~1.67Gbps > [...] > > Please make sure that you are *not* using fragmented packets and that you have > the flow dissector support enabled for batman-adv unicast packets [1]. And > check your RPS/XPS settings. > > Kind regards, > Sven > > [1] https://patchwork.open-mesh.org/cover/17240/
[B.A.T.M.A.N.] sanity check please
I'm trying to see how many bits I can push across batman-adv. My test setup is 1 Proxmox host with 3 ubuntu 16.04 VM's. VM1 bat0 (ens19) 192.168.5.1/24 VM2 bat0 (ens19,ens20) 192.168.5.2/24 VM3 bat0 (ens20) 192.168.5.3/24 So VM1 and VM3 are on different 'physical' network segments. I'm running iperf3 with VM1 the server and VM3 the client VM1 iperf3 -s VM3 iperf3 -c 192.168.5.1 -b 1M -t 60 -P 1 output is 1.75Gbits -P 99 output is 831Mbps -P 99 *BUT* hitting the 'native' LAN address of 192.168.1.1 (each VM has an ens18 on this network) 4.8Gbps -P 99 from VM2 ~1.67Gbps So I am definitely putting batman-adv in the way and it's having a clear impact of throughput. I've also double checked that killing VM2 breaks the connection. Based on the number of retries and how they compound with more parallel streams, and that the only substantial CPU used here is iperf3 in the VM and virtio on the host, the virtio nic is the bottleneck. Hardware network should likely perform better. Ultimate goal here is to basically replicate the concept of SPB but with a small batman-adv node instead of a switch to replace and OSPF/MPLS/VPLS wISP network. I am running bat0 at mtu 1400 so I wouldn't have to switch out from linux bridges in prox but I don't expect that to have a substantial effect, maybe a couple % difference. Has anyone else performed similar tests on hardware/wired connections? There would be point-to-point half-duplex and full duplex wireless links but no multipoint 'wifi' style links. I've also added an 8021q vlan 8 on top of bat0 (ie bat0.8, tagged) and batman-adv seems quite happy to transport this VLAN. VM2 does NOT have the vlan config on bat0. I'm pretty happy with the results here, hoping I'm not missing some obvious "In a VM you get abnormally high performance and low CPU" situation. Seeing >1G is great, my maximum links have 1G ports so that's the bar. I'm hoping to compare notes with someone before spending the cash on the hardware to do a field test. That platform would likely be the PCEngines APU2 and/or soekris or other hardened x86 device with 3+ ethernet ports.
[B.A.T.M.A.N.] [bug report] batman-adv: Ignore invalid batadv_v_gw during netlink send
Hello Sven Eckelmann,
The patch 011c935fceae: "batman-adv: Ignore invalid batadv_v_gw
during netlink send" from Feb 19, 2018, leads to the following static
checker warning:
net/batman-adv/bat_iv_ogm.c:2745 batadv_iv_gw_dump_entry()
warn: missing error code here? 'batadv_neigh_ifinfo_get()' failed.
'ret' = '0'
net/batman-adv/bat_iv_ogm.c
2719 /**
2720 * batadv_iv_gw_dump_entry() - Dump a gateway into a message
2721 * @msg: Netlink message to dump into
2722 * @portid: Port making netlink request
2723 * @seq: Sequence number of netlink message
2724 * @bat_priv: The bat priv with all the soft interface information
2725 * @gw_node: Gateway to be dumped
2726 *
2727 * Return: Error code, or 0 on success
^^^
This is sort of out of date.
2728 */
2729 static int batadv_iv_gw_dump_entry(struct sk_buff *msg, u32 portid, u32
seq,
2730 struct batadv_priv *bat_priv,
2731 struct batadv_gw_node *gw_node)
2732 {
2733 struct batadv_neigh_ifinfo *router_ifinfo = NULL;
2734 struct batadv_neigh_node *router;
2735 struct batadv_gw_node *curr_gw;
2736 int ret = 0;
2737 void *hdr;
2738
2739 router = batadv_orig_router_get(gw_node->orig_node,
BATADV_IF_DEFAULT);
2740 if (!router)
2741 goto out;
2742
2743 router_ifinfo = batadv_neigh_ifinfo_get(router,
BATADV_IF_DEFAULT);
2744 if (!router_ifinfo)
2745 goto out;
These two were obviously changed from -EINVAL to 0 intentionally, but it
causes a static checker warning. What really helps me when I'm
reviewing error codes is if they're explicit:
if (!router_ifinfo) {
ret = 0;
goto out;
}
2746
2747 curr_gw = batadv_gw_get_selected_gw_node(bat_priv);
2748
2749 hdr = genlmsg_put(msg, portid, seq, &batadv_netlink_family,
2750NLM_F_MULTI, BATADV_CMD_GET_GATEWAYS);
2751 if (!hdr) {
2752 ret = -ENOBUFS;
^^
The commit message sort of implies that only -EMSGSIZE and 0 are valid
returns but -ENOBUFS is also valid.
2753 goto out;
2754 }
2755
2756 ret = -EMSGSIZE;
^^^
2757
2758 if (curr_gw == gw_node)
2759 if (nla_put_flag(msg, BATADV_ATTR_FLAG_BEST)) {
2760 genlmsg_cancel(msg, hdr);
2761 goto out;
2762 }
2763
Anyway, the code seems fine and I've marked it as a false positive so
it doesn't really require any action from you. I just wanted you to
know my thinking here.
regards,
dan carpenter
Re: [B.A.T.M.A.N.] Simple Multicast on Batman-Adv
awesome. On Wed, Jan 17, 2018 at 5:20 PM, Linchieh, Alex wrote: > That resolved it. Thank you Dan! > > -Original Message- > From: B.A.T.M.A.N [mailto:b.a.t.m.a.n-boun...@lists.open-mesh.org] On Behalf > Of dan > Sent: Wednesday, January 17, 2018 4:57 PM > To: The list for a Better Approach To Mobile Ad-hoc Networking > Subject: Re: [B.A.T.M.A.N.] Simple Multicast on Batman-Adv > > I dont see you setting MTU on enp0s3. > > On Wed, Jan 17, 2018 at 4:41 PM, Linchieh, Alex > wrote: >> Hello, >> >> I am having some issues getting simple multicast to work under batman-adv >> (2017.4). >> >> I have isolated the system as much as I can to reduce any uncertainties >> associated with wlan. My test environment consists of 4 virtual machines >> (ubuntu server 17.10) that are connected to each other via an internal >> ethernet network. I have been able to get the bat0 interface working over >> the ethernet interface (enp0s3). I am able to get the devices to ping >> eachother over the batman mesh as well as send iperf test data via TCP and >> UDP unicast modes. However I have not been able to get multicast running >> properly over the bat0 interface. >> >> The commands I am using to initialize batman-adv on each of the virtual >> machines are as follows: >> >> Sudo modprobe batman-adv >> Sudo ifconfig enp0s3 up >> Sudo batctl if add enp0s3 >> Sudo ifconfig bat0 192.168.14.x/24 where "x" is replaced with a number >> depending on the VM >> Sudo route add -host 239.255.10.10 bat0 >> >> I am using iperf in order to generate multicast traffic from the iperf >> client (192.168.14.1), and the iperf servers (192.168.2, 3, 4). The client >> which generates multicast data is able to "connect" to the multicast address >> and send data. Iperf also shows that the servers are able to subscribe to >> the multicast address however this is as far as I can get because the >> multicast data does not appear to ever reach the subscribers. When I use tcp >> dump to monitor the bat0 interfaces on these devices, I can see outgoing >> multicast traffic from the multicast sender, however the bat0 interface on >> the multicast receivers does not show anything, so it looks like none of the >> multicast traffic seems to be reaching any of the subscribers (or perhaps >> the multicast subscribers aren't able to communicate that they are >> subscribed to the multicast address). >> >> I have tested this with "batctl mm" set to both enabled and disabled. In >> addition, when I try to run "batctl mf" it says that I am not connected to a >> mesh (even though I am). >> >> I have also duplicated this test using just the internal Ethernet network >> (static IP addresses, batman disabled) and muilticast seems to work fine. >> This leads me to believe that there is something with batman-adv that I am >> overlooking. >> >> If anyone could shed some light on enabling multicast on batman that would >> be greatly appreciated. >> >> Thanks, >> Alex >> >>
Re: [B.A.T.M.A.N.] Simple Multicast on Batman-Adv
I dont see you setting MTU on enp0s3. On Wed, Jan 17, 2018 at 4:41 PM, Linchieh, Alex wrote: > Hello, > > I am having some issues getting simple multicast to work under batman-adv > (2017.4). > > I have isolated the system as much as I can to reduce any uncertainties > associated with wlan. My test environment consists of 4 virtual machines > (ubuntu server 17.10) that are connected to each other via an internal > ethernet network. I have been able to get the bat0 interface working over the > ethernet interface (enp0s3). I am able to get the devices to ping eachother > over the batman mesh as well as send iperf test data via TCP and UDP unicast > modes. However I have not been able to get multicast running properly over > the bat0 interface. > > The commands I am using to initialize batman-adv on each of the virtual > machines are as follows: > > Sudo modprobe batman-adv > Sudo ifconfig enp0s3 up > Sudo batctl if add enp0s3 > Sudo ifconfig bat0 192.168.14.x/24 where "x" is replaced with a number > depending on the VM > Sudo route add -host 239.255.10.10 bat0 > > I am using iperf in order to generate multicast traffic from the iperf client > (192.168.14.1), and the iperf servers (192.168.2, 3, 4). The client which > generates multicast data is able to "connect" to the multicast address and > send data. Iperf also shows that the servers are able to subscribe to the > multicast address however this is as far as I can get because the multicast > data does not appear to ever reach the subscribers. When I use tcp dump to > monitor the bat0 interfaces on these devices, I can see outgoing multicast > traffic from the multicast sender, however the bat0 interface on the > multicast receivers does not show anything, so it looks like none of the > multicast traffic seems to be reaching any of the subscribers (or perhaps the > multicast subscribers aren't able to communicate that they are subscribed to > the multicast address). > > I have tested this with "batctl mm" set to both enabled and disabled. In > addition, when I try to run "batctl mf" it says that I am not connected to a > mesh (even though I am). > > I have also duplicated this test using just the internal Ethernet network > (static IP addresses, batman disabled) and muilticast seems to work fine. > This leads me to believe that there is something with batman-adv that I am > overlooking. > > If anyone could shed some light on enabling multicast on batman that would be > greatly appreciated. > > Thanks, > Alex > >
Re: [B.A.T.M.A.N.] 11ac throughput on mesh links
1/6 connection rate speed is pretty typical in 80Mhz channels unless you are in a very truly clean environment and your walls aren't reflective etc etc. This is why MIMO/MU-MIMO is such a big thing and you don't have that going for you. That’s not a Batman-adv thing. You should try 20 and 40 MHz channels and see how that works out. Also, the tx rate is very low. I’m not sure how accurate this test is or if uses some ack or something that would rely on the tax. I would try an iperf test between nodes to get a more accuarate number. Also, are there other radios? On Sun, Dec 31, 2017 at 6:41 AM, Daniel Ghansah wrote: > I am testing an implementation of > batman-adv, alfred, 802.11s, 11ac. > In this implementation I have my mesh interface on the 5GHz radio > (qca9882), Using LEDE/Openwrt 17.01.04 > > I am getting > > root@Daniel Node:~# batctl tp 9c:b7:93:e3:56:e4 > Test duration 10020ms. > Sent 142966836 Bytes. > Throughput: 13.61 MB/s (114.15 Mbps) > is this inline with what everyone has seen. That data rate established is > high however the throughput is very low > > root@Daniel Node:~# iw mesh0 station dump > Station 9c:b7:93:e3:56:e4 (on mesh0) > inactive time: 100 ms > rx bytes: 75007154 > rx packets: 910406 > tx bytes: 968480244 > tx packets: 635811 > tx retries: 0 > tx failed: 7 > rx drop misc: 15 > signal: -45 dBm > signal avg: -44 dBm > Toffset:18446744061225933893 us > tx bitrate: 6.0 MBit/s > rx bitrate: 650.0 MBit/s VHT-MCS 7 80MHz short GI VHT-NSS 2 > rx duration:10763380 us > mesh llid: 44135 > mesh plid: 29835 > mesh plink: ESTAB > mesh local PS mode: ACTIVE > mesh peer PS mode: ACTIVE > mesh non-peer PS mode: ACTIVE > authorized: yes > authenticated: yes > associated: yes > preamble: long > WMM/WME:yes > MFP:no > TDLS peer: no > DTIM period:2 > beacon interval:100 > short slot time:yes > connected time: 12825 seconds > > What may I be doing wrong?
Re: [B.A.T.M.A.N.] Can b.a.t.m.a.n. be configured to ARP for unknown clients?
> We know that the transtable_local inactivity/removal timer value can be > extended, and we will probably do that, but we would also like to know if it > is possible to have b.a.t.m.a.n. ARP for the removed client in this case. We > prefer this approach, rather than arbitrarily changing the tt_local timer to > some value which may not work well in some other customer's > network/application. I know that there is a statistically valid underlying > assumption with this 10 minute inactivity timer on transtable_local, that > clients will typically be "chatty". But again, that is not the case in this > application, which is a very common one in the industry in which we operate, > where clients are very often fixed devices which only respond to explicit > queries or commands. This is a new product and protocol for us, and this > could beg the question of whether or not b.a.t.man.-based meshing is the > right solution in this type of application. We believe it can be; it would > just be helpful if we can configure it to ARP in this type of scenario. > > Can you please comment on how this might be possible (config or otherwise)? > > Thanks very much, > Robert Bates just a note, devices based on arduino with wifi or ethernet shields/interfaces often behave this way, and MANY IoT devices do based on other microcontrollers as a means to save battery. So this is going to be an increasingly common situation.
Re: [B.A.T.M.A.N.] batman on top of vlan?
thanks. Just to clarify, batman-adv 32 bytes, so to stack vlans qinq I need 32+4+4 so 1540 yes? On Sun, Aug 20, 2017 at 12:55 AM, Sven Eckelmann wrote: > On Mittwoch, 16. August 2017 09:43:34 CEST dan wrote: >> Can batman operate on top of a vlan? For example, a wireless link >> with MTU of 1532 to accommodate both batman and the vlan. Plugs into >> the batman-adv box on eth0, configure eth0.10 and add eth0.10 to bat0. > > It should work. batman-adv is not too picky about what is used below it. It > must be able to transport ethernet frames and it must allow things like > broadcasts. We could go here into more details but it wouldn't help us to > answer the question. At least 802.1Q should not influence the behavior in any > significant way and should therefore not be a problem. > > Kind regards, > Sven
Re: [B.A.T.M.A.N.] can batman-adv carry a vlan?
@sven, thanks, that's exactly what I needed to know. On Sun, Aug 20, 2017 at 12:51 AM, Sven Eckelmann wrote: > On Sonntag, 20. August 2017 08:45:38 CEST Sven Eckelmann wrote: >> 802.3Q VLAN header > > Sorry, meant 802.1Q. > > > Kind regards, > Sven
Re: [B.A.T.M.A.N.] wired performance
On Sun, Aug 20, 2017 at 8:05 AM, Andrew Lunn wrote: >> And there is currently no special batman-adv support for the flow >> dissector [1] in the kernel. This could be also a reason why multiple flows >> are not distributed well to different cores when you enable RPS/XPS. It is >> not >> yet know whether this will actually be helpful but at least someone >> interested >> could do same research and implement a proof-of-concept patches for further >> testing. > > Hi Sven > > DSA just added a patch to help with flow dissectors. Maybe it can be > generalized and made to work for BATMAN as well? > > commit 43e665287f931a167cd2eea3387efda901bff0ce > Author: John Crispin > Date: Wed Aug 9 14:41:19 2017 +0200 > > net-next: dsa: fix flow dissection > > RPS and probably other kernel features are currently broken on some if not > all DSA devices. The root cause of this is that skb_hash will call the > flow_dissector. At this point the skb still contains the magic switch > header and the skb->protocol field is not set up to the correct 802.3 > value yet. By the time the tag specific code is called, removing the > header > and properly setting the protocol an invalid hash is already set. In the > case of the mt7530 this will result in all flows always having the same > hash. Ok, maybe virtualbox specific slowness then. I'm running batman-adv 2015.2 on ubuntu kernel 4.4.0, so a little out of date. I'm actually wanting to target something embedded, like a pc-engines APU2c4. It has 3 onboard ethernets and I can add up to 8 more via pci-e. But that has a 1Ghz CPU (quad core) and being stuck on 1 core 1/4ers the potential. The test network I'm designing is handling wireless PtP backhauls and having batman-adv make all tower sites look like a single switch, almost list a replacement for shortest path bridging. 1Gbps would be the real base line performance here. I have another question on the list about running on top of vlans, specifically do to something like router-on-a-stick with a wisp specific PoE switch and running a vlan across backhaul links and putting those vlans in batman-adv. That way I don't have issue accessing the ptp link interfaces themselves.
Re: [B.A.T.M.A.N.] wired performance
2 hops on full duplex links I'm getting 464Mbps. There is some loss at each hop and I'm not sure why. Could be virtualbox and resource contension that isn't showing up in task manager and/or top on the vm's. is this to be expected? On Sat, Aug 19, 2017 at 12:25 PM, dan wrote: > I'm only able to test in virtualbox at the moment. > > I have a 3.1Ghz i5 and I'm able to do iperf across a batman-adv > network (nodes A-B-C with A and C not directly connected). > > iperf between a<>b is ~1Gbps, A<>C is ~560Mbps and B has 1 core hit > 100% by ksoftirqd. > > So it looks like I'm stuck in a single thread. > > I'm going to add a 4th node and do a double hop A<>D iperf and see > what happens. full duplex interfaces here so I don't think I'll see a > big drop in the next test. > > On Wed, Aug 16, 2017 at 9:39 AM, dan wrote: >> Anyone done any performance testing over wired links? ie, if two >> ethernet ports are gigabit and are added to bat0, what kind of >> throughput is expected across these interfaces and how much CPU is >> needed to get up near wire-speed?
Re: [B.A.T.M.A.N.] wired performance
I'm only able to test in virtualbox at the moment. I have a 3.1Ghz i5 and I'm able to do iperf across a batman-adv network (nodes A-B-C with A and C not directly connected). iperf between a<>b is ~1Gbps, A<>C is ~560Mbps and B has 1 core hit 100% by ksoftirqd. So it looks like I'm stuck in a single thread. I'm going to add a 4th node and do a double hop A<>D iperf and see what happens. full duplex interfaces here so I don't think I'll see a big drop in the next test. On Wed, Aug 16, 2017 at 9:39 AM, dan wrote: > Anyone done any performance testing over wired links? ie, if two > ethernet ports are gigabit and are added to bat0, what kind of > throughput is expected across these interfaces and how much CPU is > needed to get up near wire-speed?
[B.A.T.M.A.N.] can batman-adv carry a vlan?
Can batman-adv carry a vlan? For example, 2 mesh nodes are directly connected via eth0 on both devices. bat0 contains eth0 on both devices. Can a bat0.20 vlan be created on each side and will batman-adv pass traffic assuming 1532 MTU is set?
[B.A.T.M.A.N.] batman on top of vlan?
Can batman operate on top of a vlan? For example, a wireless link with MTU of 1532 to accommodate both batman and the vlan. Plugs into the batman-adv box on eth0, configure eth0.10 and add eth0.10 to bat0. This is meant to solve a specific issue of needing non-batman-adv access to the radio web-ui's on the native/untagged vlan1 thanks.
[B.A.T.M.A.N.] wired performance
Anyone done any performance testing over wired links? ie, if two ethernet ports are gigabit and are added to bat0, what kind of throughput is expected across these interfaces and how much CPU is needed to get up near wire-speed?
Re: [B.A.T.M.A.N.] how well does batman-adv scale
I don't think it's CPU that's the issue, it's WLAN overhead. Too many nodes is too much overhead traffic. The web is telling me there is an upper limit of a 'basic' cluster of about 300, and if you add some multicast filtering you can hit maybe 1500. OGM's are eventually going to saturate the network though. That makes me think you should be looking at small clouds and some other 'routing' protocol to connect those clusters together. Maybe do an OSPF ring linking up the batman-adv clouds. On Wed, Apr 26, 2017 at 10:06 AM, fuumind wrote: > Hi Jens! > > By 'sufficient power', do you mean processing power to handle overhead > traffic? I'm imagining a network which primarily connects WLANs. > > Clouds of batman-adv networks sounds like a good idea. Any idea about > how to implement the interfaces between these clouds? How big should > they be allowed to grow before forming a new cloud? > > fuumind > > > ons 2017-04-26 klockan 17:10 +0200 skrev jens: >> i think this could scale , but you will need sufficient power / >> ethernet >> capacities at the nodes. >> >> and the biggest problem may be that these endpoints make much noise >> on >> the layer2 level. >> (disovery protocolls and stuff like this) >> >> you could easily imagine what would happen if you have a layer2 >> switch >> with 10 ports. >> >> i think that most of the time you will not do this, and implement >> some >> sort of routing between some clouds of batman-adv networks. >> >> >> >> On 26.04.2017 16:20, fuumind wrote: >> > >> > Hi list! >> > >> > Been lurking for almost a year on the battlemesh list and recently >> > joined here as well. >> > >> > I'm curious about how well batman-adv scales. Would a network of 10 >> > 000 >> > nodes work well? What about 100 000 nodes or 1 000 000? >> > >> > Thanks! >> > fuumind >> >
Re: [B.A.T.M.A.N.] how well does batman-adv scale
I can't see how it could scale. Each node needs a table of all other nodes to calculate the cost for each path. This is a LOT of data and each node rebroadcasts it's neighbor's information so the more neighbors, the more rebroadcasting. Maybe if you had a long string of nodes with each node only seeing 1-2 other nodes, it might scale up higher, but that's not the point of mesh networking. It really means that under idea circumstances, overhead is going to scale up with node count by percent. So a few nodes is low overhead, but 50 nodes might be as much as 50% and so on. This is a critical flaw in batman-adv to scale up. Requiring each node to know all other nodes. If this rule could be changed to have batman-adv only keep track of gateway nodes and nodes in the path to a gateway, then it could scale vastly further. On Wed, Apr 26, 2017 at 9:10 AM, jens wrote: > i think this could scale , but you will need sufficient power / ethernet > capacities at the nodes. > > and the biggest problem may be that these endpoints make much noise on > the layer2 level. > (disovery protocolls and stuff like this) > > you could easily imagine what would happen if you have a layer2 switch > with 10 ports. > > i think that most of the time you will not do this, and implement some > sort of routing between some clouds of batman-adv networks. > > > > On 26.04.2017 16:20, fuumind wrote: >> Hi list! >> >> Been lurking for almost a year on the battlemesh list and recently >> joined here as well. >> >> I'm curious about how well batman-adv scales. Would a network of 10 000 >> nodes work well? What about 100 000 nodes or 1 000 000? >> >> Thanks! >> fuumind >> > > -- > make the world nicer, please use PGP encryption >
Re: [B.A.T.M.A.N.] Distributing Data using BATMAN-Multicast
iperf can generate multicast traffic. On Thu, Feb 16, 2017 at 5:35 AM, Shantanoo Desai wrote: > Hello all, > > > I have developed a Multicast based Data Distribution protocol and would > like to compare it with Batman's Multicast feature. I know how to enable > the multicast on the the mesh interface but is there any tool or utility > I can use to send data over the Mesh network ? scp of sftp won't work > since there is no multicast or broadcasting present in them. > > I would like to compare how quick can data be disseminated in a Batman > enabled Mesh network versus the protocol that I have developed over an > adhoc network consisting of multiple Raspberry Pis. > > > Any hints would be suggested. > > > Thanks, > > > Shan > > > -- > Shantanoo Desai > > MSc. Communication & Information Tech. > > Bremen, Germany >
[B.A.T.M.A.N.] throughput on wired interfaces?
Anyone know what the throughput capacity of batman-adv is? To be more specific, if I have gigabit ethernet interfaces in bat0 on a number of nodes, will batman-adv cause a significant drop in throughput when relaying traffic or cause a significant increase in latency? What about 10G?
[B.A.T.M.A.N.] bat0 trunk vlans?
Assuming MTU is great enough (1528 right? 1500+24 batman-adv+4 VLAN), can the bat0 interface act as trunk for VLANs? 2 Nodes: bat0: eth1 bridge0: eth0|bat0 device connected to node1-eth0 tags vlan20, does that traverse the bat0 mesh and come out node2-eth0 with tag in-tact? Does it traverse node1-eth0 at all? I have another post on how to manage PtP radios in-line a batman-adv link, wondering if I can configure them to a management VLAN bat0-eth0 native vlan bat1-eth0.10 <- radio interface vlan10 ... and if so, how does that effect the possibility of trunking VLANs across bat0. in theory, bat0 fully encapsulates packets entering node1-eth0 so the VLAN is invisible 'outside' batman-adv encapsulation so bat-eth0.10 should work, but I just don't know how batman-adv handles VLANs... thanks
Re: [B.A.T.M.A.N.] how to hand ptp links and still access radio management interfaces
Will that work? bat0 is untagged bat0 contains eth0 bat1 is for management bat1 contains eth0.10 I thought that bat0 could trunk VLANs if the MTU is 1528? (1500 + 24 batman-adv overhead + 4 VLAN) So which wins? If bat0 has a VLAN10 traversing it, but eth0.10 is in bat0, then something breaks. On Wed, Feb 1, 2017 at 10:57 AM, fboehm wrote: > I didn't test the following. So I could be totally wrong :) > > Airfiber allows to configure VLAN for the management traffic. That means you > can activate VLAN100 on the Airfiber device and create interface eth1.100 at > the Batman-router. > > Kinda like you described in your 2nd sketch. The main difference is that now > the Airfiber management traffic is VLAN tagged and the Batman mesh-traffic > remains untagged. > > Bridging eth1.100 with bat0 should make the Airfiber device available > everywhere in your network. Which isn't necessarily desired. > > Franz > > Am 2017-02-01 um 15:17 schrieb dan: >> >> I'm trying to figure out the best way to handle this: >> >> (bat0-eth1) <===> PTP Radio1 ~~~ PTP Radio2 <===> (eth1-bat0) >> (eth1 is in bat0) >> >> These radios only have 1 interface (ie, no management interface) so I >> have to handle their configuration by assigning an IP to the same >> interface I want to connect into batman-adv. >> >> I considered: >> bat0-bridge-eth1 <===> PTP Radio1 ~~~ PTP Radio2 <===> >> eth1-bridge-bat0 >> but this means the link isn't in the mesh >> >> I don't know if this would work: >> bat0-bridge-eth1 <===> PTP Radio1 ~~~ PTP Radio2 <===> >> eth1-bridge-bat0 >> (bat0-eth1.10)(bat0-eth1.10) >> because I don't know if the eth1.10 vlan will be touched by the >> bridge, or if it will work with bat0 this way. >> >> The purpose here is to use higher end radios like a ubiquiti airfiber >> 5x to reduce hop-counts and increase capacity. >> >> Any thoughts? >> >
[B.A.T.M.A.N.] how to hand ptp links and still access radio management interfaces
I'm trying to figure out the best way to handle this: (bat0-eth1) <===> PTP Radio1 ~~~ PTP Radio2 <===> (eth1-bat0) (eth1 is in bat0) These radios only have 1 interface (ie, no management interface) so I have to handle their configuration by assigning an IP to the same interface I want to connect into batman-adv. I considered: bat0-bridge-eth1 <===> PTP Radio1 ~~~ PTP Radio2 <===> eth1-bridge-bat0 but this means the link isn't in the mesh I don't know if this would work: bat0-bridge-eth1 <===> PTP Radio1 ~~~ PTP Radio2 <===> eth1-bridge-bat0 (bat0-eth1.10)(bat0-eth1.10) because I don't know if the eth1.10 vlan will be touched by the bridge, or if it will work with bat0 this way. The purpose here is to use higher end radios like a ubiquiti airfiber 5x to reduce hop-counts and increase capacity. Any thoughts?
[B.A.T.M.A.N.] wire throughput?
Does anyone have any numbers or a link to some performance metrics of batman-adv on wired interfaces? I have a little project and I want to see how batman-adv will work in place of RSTP for making a ring network (or multiple rings). How close to wire-speed can batman-adv get on 1Gbps full duplex ethernet links. What I'm really looking for is using batman-adv as a SPB alternative providing transparent layer2 connectivity with not only redundant paths, but best paths.
Re: [B.A.T.M.A.N.] [bug report] batman-adv: make the TT CRC logic VLAN specific
On Fri, Dec 02, 2016 at 05:34:39PM +0100, Sven Eckelmann wrote: > On Mittwoch, 30. November 2016 22:53:27 CET Dan Carpenter wrote: > > Hello Antonio Quartulli, > > > > The patch 7ea7b4a14275: "batman-adv: make the TT CRC logic VLAN > > specific" from Jul 30, 2013, leads to the following static checker > > warning: > [...] > > net/batman-adv/translation-table.c:3313 batadv_send_my_tt_response() > > error: uninitialized symbol 'tt_change'. > > Thank you very much for your excellent report. Antonio seems to be busy > at the moment but Simon already forwarded [1] your suggestion to David. > > Small question - what static checker reported that? I would usually guess > smatch when I see your name but at least it was not reproducible with the > current smatch from http://repo.or.cz/w/smatch.git It's some unreleased Smatch stuff I'm working on. (Very buggy). regards, dan carpenter
[B.A.T.M.A.N.] [bug report] batman-adv: make the TT CRC logic VLAN specific
Hello Antonio Quartulli,
The patch 7ea7b4a14275: "batman-adv: make the TT CRC logic VLAN
specific" from Jul 30, 2013, leads to the following static checker
warning:
net/batman-adv/translation-table.c:3294 batadv_send_my_tt_response()
error: uninitialized symbol 'tt_change'.
net/batman-adv/translation-table.c
3282 if (!full_table) {
3283 spin_lock_bh(&bat_priv->tt.last_changeset_lock);
3284
3285 tt_len = bat_priv->tt.last_changeset_len;
3286 tvlv_len = batadv_tt_prepare_tvlv_local_data(bat_priv,
3287
&tvlv_tt_data,
3288 &tt_change,
3289 &tt_len);
3290 if (!tt_len)
3291 goto unlock;
This should probably be changed to:
if (!tt_len || !tvlv_len)
goto unlock;
There seems to be an assumption that "tt_len" is set to zero on the
error path? That's another way to fix this, I suppose.
3292
3293 /* Copy the last orig_node's OGM buffer */
3294 memcpy(tt_change, bat_priv->tt.last_changeset,
3295 bat_priv->tt.last_changeset_len);
3296 spin_unlock_bh(&bat_priv->tt.last_changeset_lock);
3297 } else {
See also:
net/batman-adv/translation-table.c:3313 batadv_send_my_tt_response()
error: uninitialized symbol 'tt_change'.
regards,
dan carpenter
[B.A.T.M.A.N.] MTU for batman-adv w/ vlans?
I'm not 100% clear on how batman-adv works with vlans, so excuse me if I've taken a wrong path. I have a small 2 radio mesh node with 1 ethernet port for non-mesh access. wlan0 and wlan1 in bat0, bat0 and eth0 in mesh-bridge. MTU is 1532 on WLAN0. If I want a VLAN to pass through the eth0 interface as if it were trunk, what needs to be done? my thought was, increase WLAN0 MTU to 1536 and eth0 to 1504 will that work? or do I need to create a vlan bat0.1 and eth0.1 and bridge them? Thanks
[B.A.T.M.A.N.] 802.1x on top of batman-adv
any consideration to making a batman-adv 802.1x interface? or anyone tested successfully using hostapd for wireless and wired clients and 802.1x? Combining batman-adv's layer2 mesh and some NAC would be very handy.
Re: [B.A.T.M.A.N.] good dual radio node?
Gui, may I ask how you use the nodes? Is it in production or just a hobby? I run a wireless ISP and I have a number of areas that no one has tried to get into because the traditional star topology wont work (valleys, heavily treed, lots of switchbacks). I have enough people wanting service that I should be able to get at least 2 uplinks from any single node throughout these areas. I've been trying to put together a dual radio mesh out of alix or routerboard hardware but I'm hitting $200 per node which is too much. This TPLink looks like a good option, add an external enclosure and some 7-8dBi omnis should be under $100! I'm just not sure if these are 'production' quality, do you have any failure rate for these in an outdoor enclosure? On Wed, Oct 15, 2014 at 8:15 AM, Gui Iribarren wrote: > Wdr3500 consumes about 3w to 5w, depending on traffic/cpu (no usb) > accepts input voltage up to 24v (undocumented) > Original PSU is 12v x 1a > > Wdr3600 does not accept 24v (we burned 1 out and we didn't try again) > > Mounted outdoors, on weatherproof enclosures. > > USB radios? Mmmh... been there, done that: Here Be Dragons. You've been > warned (google "ath9k_htc issues") :) > > Cheers! > > On October 15, 2014 7:51:04 AM CDT, dan wrote: >>GUI, what's the input voltage? and amperage on the power supply? >> >>On Wed, Oct 15, 2014 at 6:49 AM, dan wrote: >>> TL-WDR3500/TL-WDR3600 pretty interesting! Also has USB, might take >>an >>> additional radio. >>> >>> Are you mounting these outdoors or indoor? >>> >>> These are cheap enough, I could do a 3 radio mesh +2.4Ghz hotspot >>> >>> On Wed, Oct 15, 2014 at 1:55 AM, Gui Iribarren >>wrote: >>>> Tplink wdr3500, we've deployed more than 100, running nice with >>barrierbreaker >>>> tplink wdr3600 is identical, but with gigabit ethernet >>>> in some places, one or the other will be easier to find >>(availability) and cheaper. >>>> Tplink wdr4300 is like wdr3600 but with 3x3 on one of the bands >>(5ghz IIRC) so it has an extra, single-band antenna >>>> >>>> HTH, >>>> cheers! >>>> >>>> On October 14, 2014 7:34:56 PM CDT, dan wrote: >>>>>Anyone have any recommendations for a good dual radio mesh node for >>>>>batman-adv that won't break the bank? I'm looking at having wired >>>>>clients, but two mesh radios to keep throughput high. 802.11n >>radios >>>>>also required. >>>>> >>>>>Thanks! >>>> >
Re: [B.A.T.M.A.N.] good dual radio node?
GUI, what's the input voltage? and amperage on the power supply? On Wed, Oct 15, 2014 at 6:49 AM, dan wrote: > TL-WDR3500/TL-WDR3600 pretty interesting! Also has USB, might take an > additional radio. > > Are you mounting these outdoors or indoor? > > These are cheap enough, I could do a 3 radio mesh +2.4Ghz hotspot > > On Wed, Oct 15, 2014 at 1:55 AM, Gui Iribarren wrote: >> Tplink wdr3500, we've deployed more than 100, running nice with >> barrierbreaker >> tplink wdr3600 is identical, but with gigabit ethernet >> in some places, one or the other will be easier to find (availability) and >> cheaper. >> Tplink wdr4300 is like wdr3600 but with 3x3 on one of the bands (5ghz IIRC) >> so it has an extra, single-band antenna >> >> HTH, >> cheers! >> >> On October 14, 2014 7:34:56 PM CDT, dan wrote: >>>Anyone have any recommendations for a good dual radio mesh node for >>>batman-adv that won't break the bank? I'm looking at having wired >>>clients, but two mesh radios to keep throughput high. 802.11n radios >>>also required. >>> >>>Thanks! >>
Re: [B.A.T.M.A.N.] good dual radio node?
TL-WDR3500/TL-WDR3600 pretty interesting! Also has USB, might take an additional radio. Are you mounting these outdoors or indoor? These are cheap enough, I could do a 3 radio mesh +2.4Ghz hotspot On Wed, Oct 15, 2014 at 1:55 AM, Gui Iribarren wrote: > Tplink wdr3500, we've deployed more than 100, running nice with barrierbreaker > tplink wdr3600 is identical, but with gigabit ethernet > in some places, one or the other will be easier to find (availability) and > cheaper. > Tplink wdr4300 is like wdr3600 but with 3x3 on one of the bands (5ghz IIRC) > so it has an extra, single-band antenna > > HTH, > cheers! > > On October 14, 2014 7:34:56 PM CDT, dan wrote: >>Anyone have any recommendations for a good dual radio mesh node for >>batman-adv that won't break the bank? I'm looking at having wired >>clients, but two mesh radios to keep throughput high. 802.11n radios >>also required. >> >>Thanks! >
[B.A.T.M.A.N.] good dual radio node?
Anyone have any recommendations for a good dual radio mesh node for batman-adv that won't break the bank? I'm looking at having wired clients, but two mesh radios to keep throughput high. 802.11n radios also required. Thanks!
[B.A.T.M.A.N.] mikrotik routers + openwrt + batman-adv *or* alix apu1c
mikrotik) Is anyone running/testing any mikrotik gear such as the rb911 or rb912, rb922, rb433, etc w/ openwrt and batman-adv? I'm considering a multi-radio mesh node and I think this platform might be priced well enough. I do fixed wireless broadband but am looking at reaching into some heavily wooded areas that nothing else can penetrate. The rb922 in particular has an 5Ghz 'ac radio and mini-pcie that can take a second 5Ghz 'ac radio. That makes for a really great dual 802.11'ac radio w/ gigabit port and PoE ethernet to run a cable into the customer's house. An RB433 can take 2 'ac radios and a 900Mhz radio which you could artificially increase the cost on for a lower throughput tree-penetrating backup link to be placed every x number of hops. The rb922 version would be a sub $200 high performance mesh node. alix) now, the alix apu1c is a 2 mini-pcie box with dual 1Ghz x86 CPUs ready to run debian and has 3 gigabit ethernet ports. This would be a nice 'edge' node with 1 or 2 of those gigabit ports dedicated to backhaul radios. *** So, the concept is that clients wouldn't actually be on wireless and batman-adv would just be handling distribution. Clients would be wired up ethernet to a PoE injector. This dual radio mesh should only add latency at each hop as a result, though the obvious link quality and capacity are taken into account. I can bring in 20-200Mbps of service but can't penetrate the trees for more than a few houses on the edge. I could do two links to reachable homes and have any number (throughput limited) of clients connect w/ the redundant path. Thoughts?
Re: [B.A.T.M.A.N.] QoS in BATMAN-adv
How is your progress? I'm wondering how you are doing the QoS w/ batman-adv.. If this were routed you could use tc or tcng to prioritize DSCP tags, but I don't see that as an option w/ batman-adv. I'd be really curious about this. I'm exploring batman-adv mesh nodes for extremely dense forested neighborhoods* where my traditional fixed wireless systems can't reach. The catch here is how to handle QoS. With so many potential radios and changing hops I want the radio's queue to prioritize and haven't gotten deep enough into batman-adv to figure out how this might be done. *looking at mikrotik's rb912 in 5Ghz + R11e-5GacD mini-pcie radios for a single device (running openwrt), two radio node and running the ethernet into the client w/ POE injector. No clients would be on the wireless interfaces, just backhaul.
Re: [B.A.T.M.A.N.] question about min_t() casting in batadv_hardif_min_mtu()
On Thu, Jan 30, 2014 at 02:59:07PM +0100, Antonio Quartulli wrote: > > But why don't dev_set_mtu() check for the argument to be larger than > 68bytes? Isn't that a general requirement? I'm not a networking person. It sounds reasonable to me that we could use add a better minimum check there but why is it 68 bytes? regards, dan carpenter
[B.A.T.M.A.N.] question about min_t() casting in batadv_hardif_min_mtu()
Hello Batman devs,
I always worry when I see people do min_t(int, foo, bar) and there are
a couple cases which concern me in batman.
Changing the mtu is allowed for people who have admin rights in their
namespace. In other words we check:
if (!ns_capable(net->user_ns, CAP_NET_ADMIN))
as opposed to:
if (!capable(net->user_ns, CAP_NET_ADMIN))
So mtu has security implications.
net/batman-adv/hard-interface.c
240 int batadv_hardif_min_mtu(struct net_device *soft_iface)
241 {
242 struct batadv_priv *bat_priv = netdev_priv(soft_iface);
243 const struct batadv_hard_iface *hard_iface;
244 int min_mtu = ETH_DATA_LEN;
245
246 rcu_read_lock();
247 list_for_each_entry_rcu(hard_iface, &batadv_hardif_list, list) {
248 if ((hard_iface->if_status != BATADV_IF_ACTIVE) &&
249 (hard_iface->if_status !=
BATADV_IF_TO_BE_ACTIVATED))
250 continue;
251
252 if (hard_iface->soft_iface != soft_iface)
253 continue;
254
255 min_mtu = min_t(int, hard_iface->net_dev->mtu, min_mtu);
^^^
Ok. This is fine because dev_set_mtu() will not allow negative mtus.
256 }
257 rcu_read_unlock();
258
259 atomic_set(&bat_priv->packet_size_max, min_mtu);
260
261 if (atomic_read(&bat_priv->fragmentation) == 0)
262 goto out;
263
264 /* with fragmentation enabled the maximum size of internally
generated
265 * packets such as translation table exchanges or tvlv
containers, etc
266 * has to be calculated
267 */
268 min_mtu = min_t(int, min_mtu, BATADV_FRAG_MAX_FRAG_SIZE);
^^^
Still fine.
269 min_mtu -= sizeof(struct batadv_frag_packet);
^
I worry that this could be negative.
270 min_mtu *= BATADV_FRAG_MAX_FRAGMENTS;
271 atomic_set(&bat_priv->packet_size_max, min_mtu);
^^^
Could a negative cause problems here?
272
273 /* with fragmentation enabled we can fragment external packets
easily */
274 min_mtu = min_t(int, min_mtu, ETH_DATA_LEN);
^^^
min_mtu would still be negative here.
275
276 out:
277 return min_mtu - batadv_max_header_len();
278 }
regards,
dan carpenter
Re: [B.A.T.M.A.N.] [PATCH] batman-adv: Remove unused variable
On Wed, Feb 06, 2013 at 11:10:22PM +0100, Antonio Quartulli wrote: > Hi Emil, > > On Wed, Feb 06, 2013 at 10:59:05 +0100, Emil Goode wrote: > > Hi Antonio, > > > > If it is easier I can keep an eye on when the commit lands in the > > net-next tree and then resend a modified version of the patch. > > Or do you want me to resend it now? > > > > Well, that commit should be merged in net-next after the next merge window. > > You can resend it now, but be sure to CC Stephen Rothwell > (the linux-next maintainer) and to clearly state that > the > patch is for linux-next. > It doesn't go through Stephen Rothwell. It goes through Andrew Morton and it should be CC'd to Sasha Levin. regards, dan carpenter
[B.A.T.M.A.N.] any progress or info on available throughput based routing?
I have been watching batman-adv for quite a while. I really love the progress that the devs have made and the concepts are great. I think the holy grail of mesh routing protocols is to handle 3 characteristics of routes and route choice per packet type, possibly using DSCP/TOS values or something. Those 3 characteristics are link quality, latency, and available throughput. And the multiple routing tables would be so that services requiring low latency can be routed on lowest latency routes, that may not have a lot of throughput, and bulk traffic can be routed through paths that have more available throughput. I have seen posts discussing interest in adding such features and I am interested to do some reading on this subject as it pertains to batman-adv. Is there anything out there? I couldn't find anything on the site.
Re: [B.A.T.M.A.N.] Batman with Ubiquiti SDK
I would be very interested in this, especially if the GUI is patched to do you can enable batman-adv on an interface from there. I would point out that airos doesn't support ad-hoc mode in the GUI and doesn't do ad-hoc on airmax interfaces. On Apr 30, 2012, at 11:21 AM, Mitar wrote: > Hi! > > On Sun, Apr 29, 2012 at 10:27 AM, fboehm wrote: >> what Ubiquiti products are you using? > > Rocket, NanoBridges, Bullets. Probably we will use all types sooner or > later. :-) > >> I am asking because the Airmax products >> have been upgraded to kernel 2.6.32 recently. Integrating Batman would be >> much easier now. > > Great! > >> Unfortunately the SDK is only available on request since >> some time. > > I do not see this a problem. You request, you get, you distribute. GPL. :-) > > > Mitar
Re: [B.A.T.M.A.N.] [RFC] ELP
On Fri, Apr 6, 2012 at 11:19 AM, Andrew Lunn wrote: >> disclaimer: I am an end user, not a dev. I run a wISP (no mesh right >> now, ringed). Also, this is an evolved version of other ideas I >> posted here. > > Hi Dan > > Are you talking about point to point links using highly directional > antennas, or a bunch of omni directional systems all on the same > channel interfering with each other? > > I've not yet looked at the details of what you said, but i get the > feeling you are thinking about the first? Is that right? > > Andrew Andrew, ideally all link types. If you are going to select path based on both TQ AND capacity, or you are going to adjust TQ based on the current criteria as well as capacity, all links matter right? Highly directional p2p links are usually much more predictable than the AdHoc cloud, so I would say the local AdHoc cloud is the target. I have been looking at how to get the throughput on adhoc clouds but it seems that most wireless adapters 'monitor' mode is exclusive, it would take the link down to monitor the connection. In adhoc, the local nodes throughput isn't so important, because two other clients might be saturating the airwaves. Need to listen to all traffic on the waves to see capacity. If it was easy, someone else would have already done it right ;)
Re: [B.A.T.M.A.N.] [RFC] ELP
> > but this is a big change. We have lost TQ, but gained unicast to the > specific originator we want the metric for. We no longer need to send > probe packets, so have less overhead, but depend on there being some > traffic in order that minstral can do its thing. > > If we send unicast probe packets, and combine it with minstral: > > The quality of packets send using unicast at X Mbps. > > We have no choice on X, Minstral decides it. This is in fact good, > since the real data also get X. We have a metric based on (TQ, X). How > we actually determine X is interesting. TQ is a moving window > average. Can we do the same for X? Minstral will already be doing some > averaging, so maybe just use the latest value? > > So far, we have no idea about available capacity of the link: > > Determine X from Minstral. Send a burst of packets forcing them to be > sent at rate X and without retries. Time how long it takes to send the > packets. Compare this with the theoretical time needed, assuming no > congestion, to calculate a congestion factor C. > > You now can build a metric based on (TQ, X, C). But you have more > overhead, because you need a burst of unicast packets, and a lot more > complexity, but you have an idea of the free capacity of the link. > > Andrew disclaimer: I am an end user, not a dev. I run a wISP (no mesh right now, ringed). Also, this is an evolved version of other ideas I posted here. So here is my thought. How can you possibly test a wireless link for quality and capacity without sending enough data to stress the link? I do a lot of statistical work on historical product movement and sales, so I am trying to apply some lessons learned there to this problem. The only way to know capacity is to measure it. You cannot measure nothing, that is 'null', and generating traffic to measure decreases capacity/increases overhead. My train of thought here says that you must use historical data and statistics. For this period of time x (5 seconds?), interface y transfered the aggregate amount of data z and latency to the next node in the path was L. later, x and y are unchanged but z is higher and L spikes. later x and y are unchanged but z in low and L is similar to the first entry. Keep these high water marks around and lower them when the history shows them to be invalid. >From this we can statistically say that interface y is able to transfer z before L spikes. This is theoretical capacity of the connection. obviously, this is over wireless links so these are dynamic numbers that must be adjusted within some timeframe to changing conditions. I find that most wireless links maintain good latency until they reach a breaking point and then the latency collapses. it hits a wall. In the wISP world, I pre-test links and configure the radios modulation to the highest stable value. The link might negotiate at MCS15 but collapses at anything over MCS13. I do not rely on auto-adjustments here. The phenomenon of fresnel zone echo can make a link look great until data is transfered, then the echos from fresnel zone infractions destroys the link. The only way to know what is on the link is to push data across it. When I do this test, I can negatively effect other clients on the radio. This is a necessary evil for me and my tests are brief and infrequent. If batman-adv is able to take these sort of measurements, or is able to read the results of a helper application that does the math, then it stands to reason that these numbers could be read by a helper application and the maximum modulation of a radio could be set with userspace utils (like iw) to fit the calculation to further stabilize the link. You can nudge the values up periodically to test with. If a link is MCS2 per the calculations, nudge it up to MCS3 and let the algorythm do its magic. If it still thinks that 19.5Mb is optimal we can bring the mod back down to MCS2 (via helper app), if it shows as good we will leave it at MCS3 for a while then nudge it up to MCS4. Never jump up from MCS2 to 4 because the link might completely collapse. rinse, repeat.
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
> Watching the interface queue would be very interesting for other features as > well but turns out to be hard in practice. A while ago Simon and others tried > to improve the interface alternating / bonding by monitoring the fill status > of the queue. But the wifi stack does not report the fill status. Even if it > did we don't know what is going on in the hardware. > Another issue I suspect is that in AdHoc networks, the channel might be saturated by two other nodes. A third node may not be able to receive the tx from one of the first two nodes and theirfor wouldn't know how saturated the channel was. > > We still have the problem that some links might be idle, therefore we will > have to generate traffic before we can evaluate these links. > > Sounds very similar to the problem above: Without traffic we can't be sure > about the possible throughput. > > Thanks for the flowers! :-) > Still, we have some work ahead of us. Throughput based routing is a hot topic > we want to work on. All ideas are welcome. > > Cheers, > Marek > In AdHoc networks, every node that is using the same channel would need to know every other nodes current throughput on that interface so know how saturated the channel was, at least in it's vacinity. The node would basically need to track the MACs that it could see in 1 hop and then request the throughput from those nodes to see what is in use 'on the air'. That is going to be difficult, or very expensive in overhead pulling the throughput from visible nodes and adding up to determine channel saturation and capabilities... As far as the issue of having to generate traffic to know where to route traffic, maybe reverse the train of thought. Initially assume that all links are quite similar. Maybe an 'N' node will have a different default than a 'G' node, ethernet, etc. Then adjust down from the assumed average. you might assume that all of your nodes with a certain type of interface have the potential for the same throughput, but if a node begins dropping TQ when a link gets saturated, then for some period of time we know what the link is capable of delivering. This may not be true for very long so this downward adjustment should swing up to the baseline over time. Consistent traffic will keep the known maximum populated, light traffic will let the node drift back to average. Track this over time. If a loaded node is routinely having the throughput number brought down to 75, then we can adjust the node's default to 75. If the node becomes more capable because of some environmental change that we are not aware of, it will still transfer at full speed, then the history will show that this has been swinging UP from 75 to 85. Adjust the default number for the node based on the trends. If we store that TQ dropped at throughput X 15 times in the last 3 days, we should adjust our throughput number to just below that point as the default. If that changes, then the recent history will reflect it and the default will be changed back to the interface type default. If we manually assign a node to a certain default speed from some known values then we have a baseline. certain things might be initially assumable. half duplex links are 70/30 to rx/tx (from receiver's perspective). 100Mb aggregate means 70Mb for our purposes full duplex links are 100/100. 100Mb really means 100Mb here. assuming a connection level of MCS12 instead of max: single stream N 20mhz is 65Mb H/D * .7 =45 dual stream N is 130 H/D * .7 =91 G is 27Mb * .7 =19 Ethernet is 100Mb * 1 =100 Gigabit is 1000Mb * 1 = 1000 set the wireless G interface on a node to 19, the ethernet to 100. If historically, we see that the link falls apart at about 16Mb, we need to adjust the default. this might be some process that sits outside of batman-adv. batman-adv should handle distributing the throughput numbers, but another daemon could handle the math and updating the throughput numbers. This would allow batman-adv to stay pure as far as interfaces go. The helper daemon could handle the differences between using ifconfig, ethtool, iw etc to determine throughput.
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
On Mon, Apr 2, 2012 at 3:32 AM, Marek Lindner wrote: > On Monday, April 02, 2012 00:23:36 dan wrote: >> I am making some assumptions. I assume that the link will at some >> point become saturated. If we simply track the maximum then we can >> advertise an available amount. > > This will result in a metric optimizing paths for the highest throughput ever > recorded. In reality one can easily observe many links with variable > throughput. Sometimes you get a spike of high throughput although the average > speed is lower. Or your wifi environment changes with a negative impact on the > throughput. True. maybe not keep the maximum. Maybe watch the interface queue and measure the throughput when frames start to get queued. Updated the 'max' speed whenever an interface starts to queue frames. > > >> How do we identify this? Well, if the C radio has historically >> transfered 10Mb (on the interface closest to the gateway) and we have >> tracked it, we can take the current 5Mb away from that an see that >> there is 5Mb remaining. This does also assume that a specific >> interface has a consistent speed. > > That is not a safe assumption. maybe its ok to assume that an interface has a consistent speed for some period of time... > > >> I don't suggest making throughput the #1 route selection method, only >> what would be used if similar quality links where available. in this >> case, A<>B and A<>F are very similar quality so we would use >> available throughput in the decision making. Have a tunable threshold >> for TQ vs TQ before this load balancing is taken into account. > > Interesting idea. Have to think about this a little bit. > > >> I have another though on how to determine maximum speed but it is more >> 'destructive' >> Have batman-adv do a test on each link for tx, rx, and bi-directional >> and store the results and consider these the interfaces potential. >> Also identify if an interface is FD or HD. retest on an interval, >> and/or when the TQ on a link is consistently worse than when tested >> last. If the test was thorough enough, it would be able to identify >> at what throughput ping times and packet loss spike and have an >> effective 'safe' maximum vs absolute maximum. > > Yes, we still have the "costly" way of detecting the link throughput > ourselves. What do you think about the idea of asking the wifi rate algorithm > for the link speed ? I am a wisp. In my experience, the wifi sync rate isn't reliable. In perfect conditions yes, but when there is fresnel zone incursion on a wireless link, the algorythm can't take into account reflected signal as noise because they dont exist yet. Not until you start transfering data does the signal get reflected back (as noise) and the radio has to adjust the rate down. Problem is that this happens after you have dropped 5% of your packets, which would drop the TQ on the link and it would be effectively down until. Now the data stops, reflections stop, link changes speed back up and very light use (pings, OGMs) travel safely and TQ rises. Rinse and repeat. > > Regards, > Marek I wish I had a really great solution to this. I dont really have anything to complain about, batman-adv is already a mile ahead of the next best mesh routing protocal :)
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
> This approach bears some drawbacks: We can only assess the maximum throughput > by saturating the link. Saturating the link isn't what we really want to do > because it means nobody else can use the link to transfer data. > Furthermore, what if nobody transmits anything whithin your interval ? The > counters won't increase and the link will be considered "bad" ? > > Regards, > Marek I am making some assumptions. I assume that the link will at some point become saturated. If we simply track the maximum then we can advertise an available amount. This might be tunable to a % of actual if trying to avoid saturating a link is a goal. Here is an example Y | A---B---C---D---E---X \ / F---G---H---I every node A-I has an equal amount of bandwidth available. All the links are the same quality and have the same connection rate. (lets say 10Mb aggregate) A is looking for the best route to X, which is the gateway. TQ says that A<>X via B and A<>X via F are good, but A<>X via B has a slightly lower TQ because it is once less hop. The catch here is that Y is sending traffic through C at a rate of 5Mb aggregate. This means that in our route selection, A<>X via B is identified as the best path because TQ sees clean links with very little packet loss. Y is not sending at a rate that saturates C so performance is still good and TQ is still good. We should have a mechanism that identifies that although A<>B and A<>F are both good paths, I should prefer to route through A>F>G>H>I>E>X because the most restrictive available bandwidth in 10Mb while on A>B>C>D>E>F>X path, the C node can only provide 5Mb aggregate speed. How do we identify this? Well, if the C radio has historically transfered 10Mb (on the interface closest to the gateway) and we have tracked it, we can take the current 5Mb away from that an see that there is 5Mb remaining. This does also assume that a specific interface has a consistent speed. Each node could simply ask the next node closest to the gateway the available speed on the path. Each node would offer the lowest speed available, either the upstream nodes advertised speed or it's own. Since batman-adv only really cares about routing to the next neighbor with ideal TQ then this method plays right into the batman-adv system. I don't suggest making throughput the #1 route selection method, only what would be used if similar quality links where available. in this case, A<>B and A<>F are very similar quality so we would use available throughput in the decision making. Have a tunable threshold for TQ vs TQ before this load balancing is taken into account. Send the throughput information frequently so that as a node takes on routes due to available bandwidth, it is less likely to be routed through. I would add that it is probably a good idea to try to lock in a route sourced from a single source else the routes might jump around. If a client device is downloading at a high speed, once batman-adv has selected a route, it should stick with it for that client for some period unless the TQ on the link plummets. Else a route might jump back and forth between two paths because as one path gets more saturated, the other will start looking very interesting and switch, creating a swinging pattern. I have another though on how to determine maximum speed but it is more 'destructive' Have batman-adv do a test on each link for tx, rx, and bi-directional and store the results and consider these the interfaces potential. Also identify if an interface is FD or HD. retest on an interval, and/or when the TQ on a link is consistently worse than when tested last. If the test was thorough enough, it would be able to identify at what throughput ping times and packet loss spike and have an effective 'safe' maximum vs absolute maximum.
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
> > That sounds like a nice start! > I'm not sure, though, if that number includes retransmissions and/or > unacknowledged frames. > IIRC i think i've seen that TX number grow in an interface with such a > lossy link that was just sending traffic (trying to reach the distant > ap) but getting nothing in return (ap couldn't hear me) > > So far, with openwrt and ath9k / ath9k_htc, i've found the "tx > bitrate" (or MCS level) a fair indicator of the link capacity. > if it says "65.0 MBit/s MCS 7" i cannot tell exactly how much goodput > it will have, but i can be pretty confident that it will be better > than when it says "6.5 MBit/s MCS 1" Good point on ifconfigs potential limitations. One issue with using the wireless sync rate is that fresnel zone infractions will allow you to sync at one rate but for the link to fall apart as the throughput grows. I have seen a 130Mb link degrade to 54Mb as soon as it started passing significant traffic.
Re: [B.A.T.M.A.N.] [OT] ruci / Was: link alternation when radios are not on batman-adv router?
2012/3/31 Nicolás Echániz : > on status between repo and nodes. > 5) can always revert nodes or the whole network to any previous state > (provided by mercurial), as long as you keep a useful commit Thanks for the comments and suggestion. I will definitely check this out. I think I am going to use the mikrotik rb751 flashed to openwrt for the supernode tests. They have 5 ethernet ports that can be addressed individually as well as wireless that I can bridge in for client access. Picostations for the standard nodes and for the radio interfaces on the supernode. I'll do 2.4Ghz for all local meshing and 5Ghz for the links between supernodes and the backhauls.
Re: [B.A.T.M.A.N.] any throughput mechanism or plans?
> > Hello Dan, > > there is not such mechanism in batman-adv right now. It is a really good idea > and we already started to think about that during WBMv5. Personally, I'm > applying to the GSOC2012 and I'm proposing something similar. > > I also think that packet loss is not the correct way to go. > > Regarding your idea, how would you measure the maximum throughput? An easy way might be to just pull the info from ifconfig on a timer: eth0 RX bytes:2841699391 (2.6 GiB) TX bytes:2681928474 (2.4 GiB) + 5 seconds RX bytes:2842069649 (2.6 GiB) TX bytes:2682282969 (2.4 GiB) =RX of 361.5Kb, TX of 346.2Kb just update a value for the MAX of both as they change Compare the stored value to the last 5 second interval so see what amount of the connection is available. In my case, I have a 20Mb/10Mb connection so I have 19.3Mb/9.3Mb available. If I know the connection speed (reliably) then I should be able to statically assign this. Otherwise it should just be based on historical observations. Wireless links are unpredictable so we have to rely on observation while wired or higher end backhaul links are more predictable so it may be best just use a set value. It would be better if we could get total throughput on the wireless link if possible. I would think it would be useful to identify 1/2 duplex vs full duplex. 1/2 duplex should be the aggregate of the rx and tx with some ratio applied (70/30 by default for dl vs ul, this should be tunable) and full duplex wouldn't have a ratio applied.. devices like an SAF freemile or Ubiquiti AirFibre are full duplex, so SAF = 100Mb FD and AirFibre could be 700Mb FD. I am assuming that each node knows which direction is upload and which is download but that might not be true unless the gateway config was used... I'm not sure if that would be another type of advertisement or what.
[B.A.T.M.A.N.] any throughput mechanism or plans?
I can't see anything in my reading on this. Is there a mechanism to identify throughput between two nodes? or between a client and a destination for the purpose of routing through the highest throughput path? For instance, track the maximum throughput on each interface over time. Compare it to the current throughput on the interface and send what is leftover as 'available throughput' with the TQ each node. Now instead of adding up the numbers as with TQ, just take the min. Take the lowest throughput along the path and have a node be able to utilize the highest throughput path that has acceptable TQ. As a node's interface gets loaded up (vs observed maximum) it will inform it's neighbors in the same way it informs them of the TQ of each interface and then the neighbors can choose to route around if there is a good alternate path. Basically, I'm thinking that TQ isn't the only or most optimal way to route simply because available throughput should be considered somehow. As far as I can tell, a 56k link with .001% packet loss is better than a 54Mb link with .1% packet loss, though both are solid interfaces and the 54Mb link should be prefered heavily over the 56k link. The 56k link probably will start dropping packets once it is saturated, but one client might run up against slow ACKs keeping the remote server from sending enough data to saturate the connection so the client could be getting a very slow connection while a 54Mb link sits virtually unused.
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
On Sat, Mar 31, 2012 at 12:11 PM, Guido Iribarren wrote: > On Sat, Mar 31, 2012 at 12:45 PM, Dan Denson wrote: >> I think I understand. Basically, so long as two interfaces both have a path >> the to destination of acceptable quality, it will send the packets out the >> interface that did not receive the packets. Hop count doesn't have a direct >> effect, we don't really care about hop count, only about link quality. >> >> Is that the case? >> >> >> If hop count doesn't really matter, how do I identify my high quality, high >> capacity backhauls? > > In batworld, by their high TQ (= AFAIU lack of packet loss to destination.) > no capacity involved in the calculations. > > (but devs might correct me if i'm being too shortsighted!) according to the docs, capacity is not used in the calculation. It is assumed that lowest TQ is always the best route. Hop count adds a default '10' to the TQ which is adjustable. I figure this means that I can give a supernode a lower hop cost than the default 10 which should slide the TQ in favor of using this node as the optimal path. I also infer that this means that picostations running batman-adv that are part of the supernode 'cluster' are going to also add a hop penalty to the TQ. From what I can tell though, link aggregation only cares if a interaces/links have an acceptable TQ, not an equal TQ, though I suspect that two picos in a supernode config would end up providing the same hop count and similar TQ anyway, assuming solid wireless links.
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
> batman-adv makes no difference between ethernet or radio interfaces, > they are all simply just interfaces that somehow link to other > batman-adv nodes (with some -or zero- packet loss) > so link alternation would work the same: if packet comes in through > radio, and batman-adv can reach the destination through the ethernet > port (it doesn't matter if that implies hopping through more > batman-adv nodes) it will prefer sending it through this "alternate" > path (alternate in the sense it doesn't use the same interface the > packet came in) So how does hop count come into play or does it? Is it just the connection quality that is considered? > A long thread earlier this month was particularly clarifying on the subject. > https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2012-March/006351.html > Thanks, I'll check that out > Yes. in addition you might also be interested in interface bonding, > which is not enabled by default but can be activated after > understanding a few caveats. it's documented on batctl manpage online. I read up on bonding, I think that leaving the dynamic interface alternation is more ideal but I think I'll play with it. > > If picostations are only connected point-to-point to each other, and > there are no other clients sending traffic to them (except the > supernodes), then interface alternating won't take advantage of the > "faster dual link connection" > You must use interface bonding to achieve that. > > Interface alternating would be useful, for example, if picostation2 > from supernode2 was receiving a radio transmission from a distant > supernode3 (not pictured) destined at supernode1. Then, instead of > trying to relay the packets through that same picostation2, it would > use picostation1 to send them and avoid reusing the same interface. > > Cheers! > > Guido I think I understand. Basically, so long as two interfaces both have a path the to destination of acceptable quality, it will send the packets out the interface that did not receive the packets. Hop count doesn't have a direct effect, we don't really care about hop count, only about link quality. Is that the case? If hop count doesn't really matter, how do I identify my high quality, high capacity backhauls?
[B.A.T.M.A.N.] question about frag_can_reassemble()
Hi Sven, I had a question about the code in frag_can_reassemble(). net/batman-adv/unicast.h 51 52 merged_size = (skb->len - sizeof(*unicast_packet)) * 2; ^^ 53 merged_size += sizeof(struct unicast_packet) + uneven_correction; 54 55 return merged_size <= mtu; 56 } Can the skb->len be less than sizeof(*unicast_packet) (ie 20 bytes)? If "len" is less than 10 then we would return false but if it's over 10 then we would return true. Roughly. regards, dan carpenter
Re: [B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
sorry if I wasnt clear, ill explain in-line: >If i got your setup right, you plan to flash openwrt on all the >nanostations that belong to the supernode, but install batman-adv only >on the 'central' router, with a single eth nic. >In that case, batman-adv has no (manual or automatic) way of >alternating the different paths (or even knowing which packet came >trough which radio). ok, this is where I was unclear. You are correct that only the router that is part of the 'supernode' runs batman-adv (at least in the described scenario). I didn't know if batman-adv was tracking connections to each node or tracking interfaces. >You should use vlans for that (i'm not sure about the performance), or >run batman-adv on each individual radio, including both the wlan and >eth0 in bat0. ok, this is an option I had considered, but I'm worried that link alternation wont be an option as the radios only have a single radio and the alternate path is through a completely different radio/device connected via ethernet. As far as vlans are concerned, are you saying to have a vlan on the router for each attached picostation and then set the picostations ethernet interface to match that vlan? Then I can add all the vlans to bat0? Alternatively, some of my options for the router have enough ethernet ports to forgo the vlans. >This last choice will allow packets being relayed along the backbone >to skip passing through every central router on hops. They would >instead get switched directly between nanostations belonging to the >same supernode (unless, of course, the packet's destination is indeed >that 'central' router) sure, but by hoping through individual nanostations, the packets are going to take a single channel. Then the second link between nodes is really just failover, right? maybe if you could clarify this for me. for link alternating, do the two nodes need to be one hop neighbors? according to docs, link alternating works in this scenario, where both links are good: node1_Link1node2_Link1 node1_Link2node2_Link2 but what about this: node1_Link1--node3_Link1--node2_Link1 node1_Link2--node4_Link2--node2_Link2 will node1 and node2 still have link alternation? This is basically what the central router + picostations with the picostations running batman-adv would look like supernode1---picostation1-picostation1supernode2 supernode1---picostation2-picostation2supernode2 so supernode2 is then a 3 hop neighbor to supernode1. So will link alternation work here? Lets just say that supernode1 has the backhaul and supernode2 has nothing except it's link to supernode1. Ideally, SN2 gets the faster, dual link connection to SN1. If not, then back to the dedicated ports/vlan option supernode1-bat0-vlan1-vlan1-picostation1-picostation1-vlan1-vlan1-bat0-supernode2 supernode1-bat0-vlan2-vlan2-picostation2-picostation2-vlan2-vlan2-bat0-supernode2 (vlan1 and vlan2 are interchangable with eth1 and eth2 in this example) now SN1 sees SN2 is a single hop neighbor, and then I would expect that link alternating would work. in the scenario with dedicated ethernet ports or vlans are used to connect the picostations, the supernode acts like a single device as far as the mesh is concerned in the scenario where the picostations run batman-adv as well as the router (which might just be a switch at that point) then the supernode is just a node cluster where ethernet is the L2 transport instead of adhoc wireless.
[B.A.T.M.A.N.] link alternation when radios are not on batman-adv router?
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.
[B.A.T.M.A.N.] [patch] batman-adv: remove extra negation in gw_out_of_range()
There is a typo here where an extra '!' made the check to the opposite of what was intended. Signed-off-by: Dan Carpenter diff --git a/net/batman-adv/gateway_client.c b/net/batman-adv/gateway_client.c index 9373a14..24403a7 100644 --- a/net/batman-adv/gateway_client.c +++ b/net/batman-adv/gateway_client.c @@ -695,7 +695,7 @@ bool gw_out_of_range(struct bat_priv *bat_priv, } neigh_old = find_router(bat_priv, orig_dst_node, NULL); - if (!!neigh_old) + if (!neigh_old) goto out; if (curr_tq_avg - neigh_old->tq_avg > GW_THRESHOLD)
Re: [B.A.T.M.A.N.] FWD: batman: potential null dereference
On Mon, Mar 08, 2010 at 04:15:30PM +0100, Sven Eckelmann wrote:
> Andrew Lunn wrote:
> > Does somebody have time to look at this?
> > - Forwarded message from Dan Carpenter -
> [...]
> > drivers/staging/batman-adv/routing.c
> > 88 } else if ((orig_node->router == NULL) && (neigh_node !=
> > NULL)) { ^
> > 89
> > 90 bat_dbg(DBG_ROUTES,
> > 91 "Adding route towards: %pM (via %pM)\n",
> > 92 orig_node->orig, neigh_node->addr);
> > 93 hna_global_add_orig(orig_node, hna_buff,
> > hna_buff_len); 94
> > 95 /* route changed */
> > 96 } else {
> > 97 bat_dbg(DBG_ROUTES, "Changing route towards: %pM
> > (now via %pM - was via %pM)\n", orig_node->orig, neigh_node->addr,
> > orig_node->router->addr);
> >^^^
> > 98 }
> >
> > This could fail if debugging is enabled and neigh_node is null.
>
> It looks a little bit like checked with clang's static analyzer. This
> analyzer
> has problems to track constraints at all. This means that it doesn't catch
> the
> update_routes constraint "orig_node->router != neigh_node".
>
> But I am also not good at tracking that kind of constraints and reported this
> or a similar "bug" in batmand a while ago.
>
> So it is not a real bug, but maybe not easy to read.
>
Yeah. I see what you mean...
regards,
dan carpenter
> Best regards,
> Sven
[B.A.T.M.A.N.] Plug-ins
Hi Guys, Just wondering if there are any plans to introduce a plug-in interface to BATMAN? I am especially keen to see a Nameservice plugin, or any other service advertisement-type plugin. Cheers, Dan
[B.A.T.M.A.N.] List Language
Hi Guys, At the risk of making myself unpopular at this early stage, could I make a request that all posts to this list be made in English? I am extremely interested in this new routing protocol - as I was in OLSR. I've spent a lot of time trying to translate German with google translator to get a better understanding of OLSR. I'd rather not have to go through that again with B.A.T.M.A.N.! The mailing list info page does list English as the list language, and http://www.open-mesh.net seems to be entirely in English too. If B.A.T.M.A.N. lives up to it's promise, it will be the best mesh protocol yet seen. I would like to see it become popular outside of Europe as soon as possible. Having this list in English will help that happen. Cheers, Dan Flett
[B.A.T.M.A.N.] Testing
Hi all Seeing as how this list is pretty new, I figure it wouldn't be too rude to send a test message first. Happy BATMAN to you all! Dan
