B.A.T.M.A.N August 2018

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

6 participants
19 discussions

[B.A.T.M.A.N.] [PATCH maint] batman-adv: Avoid probe ELP information leak
by Sven Eckelmann 05 Sep '18

05 Sep '18

The probe ELPs for WiFi interfaces are expanded to contain at least BATADV_ELP_MIN_PROBE_SIZE bytes. This is usually a lot more than the number of bytes which the template ELP packet requires. These extra padding bytes were not initialized and thus could contain data which were previously stored at the same location. It is therefore required to set it to some predefined or random values to avoid leaking private information from the system transmitting these kind of packets. Fixes: bedcadfaa92b ("batman-adv: ELP - send unicast ELP packets for throughput sampling") Signed-off-by: Sven Eckelmann <sven(a)narfation.org> --- net/batman-adv/bat_v_elp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/batman-adv/bat_v_elp.c b/net/batman-adv/bat_v_elp.c index 71c20c1d..e103c759 100644 --- a/net/batman-adv/bat_v_elp.c +++ b/net/batman-adv/bat_v_elp.c @@ -241,7 +241,7 @@ batadv_v_elp_wifi_neigh_probe(struct batadv_hardif_neigh_node *neigh) * the packet to be exactly of that size to make the link * throughput estimation effective. */ - skb_put(skb, probe_len - hard_iface->bat_v.elp_skb->len); + skb_put_zero(skb, probe_len - hard_iface->bat_v.elp_skb->len); batadv_dbg(BATADV_DBG_BATMAN, bat_priv, "Sending unicast (probe) ELP packet on interface %s to %pM\n", -- 2.18.0

2 3

Re: [B.A.T.M.A.N.] Paper "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms "
by Sven Eckelmann 03 Sep '18

03 Sep '18

On Montag, 13. August 2018 04:24:08 CEST ligang.liu(a)mail.sim.ac.cn wrote: [...] > I'm so sorry for late reply, because I was in vocation last week. No problem. But please change your reply style [2]. It is not very helpful when I first have to open my old mail to find out what you've added to the text and what was my original text :) > Thank you very much for your concern on our work. > > First of all, I have to say that the batman-adv V has performed very good in our recent tests. > The main reason why it performed poor when we tested it is the cfg80211 bug. > When we made the test in Jan. we did not know about the cfg80211 uninitialization bug. > We never thought of this kind of bug at that time, which is far beyond our scope. Thanks for checking that. In the light of this and the other problems mentioned in my mail, it would be a good idea to retract the paper with the wrong information and revisit the topic with a new paper. I would be really interested in your results and the overhead comparison - but when comparing the different B.A.T.M.A.N. algorithm versions instead of bugs in other components. This paper now could cause problems when other research use it as base for their own research - not noticing that this paper is flawed. @kekegai@smart-com.org: Are you handling the retraction of CSCloud/EdgeCom 2018 conference papers [1]? > I noticed this problem in the mail-list until in June. > > Recently, I tried to fix the bug by modified the cfg80211 source code, ref https://patchwork.kernel.org/patch/10449857/ [...] > Some tests have revealed that V has very good performance, at least not bad than IV. > We will report our results after more careful tests. Thanks > Here is my response of your questions. > > ************************************************************************************** > * What is OpenWrt 1703? (you've referenced a batman-adv config tutorial here > and there is no such version as OpenWrt 1703) > > ANS: > The base OpenWrt we used was built near in Sep. 2017, with > git clone https://git.lede-project.org/source.git > > I think the OpenWrt version should be LEDE 17.01.03 No, this would *not* result in LEDE 17.01.3 (released in Oct 3, 2017) - because you would have to specify the correct branch branch (actually the correct tag). The work on the stable versions v17.01.x was separated from the rest of the development with the branch created on on 2017-01-16. And your commands will neither use the separate branch or the actual commit - it will just use whatever master is at that time. Rather bad when somebody wants to understand how to reproduce the results of your experiment. Please make sure in your revisited paper that you make correct statements about the used software (LEDE vs. OpenWrt, git tags or actual git version's, applied patches, used feed versions, ...). Btw. there was just an actual OpenWrt release (after v15.05.1): 18.06.0 [3]. And also make sure that you're references are actually about the software. Right now your paper makes wrong statements about that kind of stuff. * don't call it OpenWRT when it is LEDE * don't name it 1703 when there is no such version and you've actually used the development branch * don't add a reference for OpenWRT 1703 which is then pointing to an unrelated config tutorial on open-mesh.org Having these incorrect statements in your paper doesn't make it look like it is of high quality. And this also causes problems when other try to use your paper as base for their own research. > ************************************************************************************** > * When did you want to contact the authors of the B.A.T.M.A.N. V > implementation in batman-adv about your findings? > > ANS: > I have tried to contact the community by sending a email to the mail-list, > with a title "What's the exact definition of expected_throughput in BATMAN-ADV V?". > In that email, I described my concern that the value of the expected_throughput was confused, > and asked for help. > > Unfortunately there are no response from there. There was no such mail on the mailing list [4]. Please make sure that you followed our requirements for this list [5] (no HTML mails). And please use shorter, more concrete subjects than that. But it seems that you never contacted the batman-adv developers via the mailing list about the other problems. > ************************************************************************************** > * How did you solve the cfg80211 bug which returns uninitialized (random) > data when asked for the expected throughput of a station? Maybe you remember > that the expected throughput is *the value* which B.A.T.M.A.N. V needs to > calculate routes. > > ANS: > Our test was done in Jan. 2018 and the paper was submitted in Feb. 2018. > At that time, I even had not realized that the problem of expected_throughput > was from cfg80211 bug. So your paper therefore (without you noticing) doesn't compare B.A.T.M.A.N. IV vs. B.A.T.M.A.N. V but still tries to establish the narrative that B.A.T.M.A.N. V is worse. > ************************************************************************************** > * What batman-adv version was used? > > ANS: > I think the version of batman-adv is 2017.3 > because the source file in OpenWrt named as: > batman-adv-2017.3 > batctl-2017.3 This already shows that you did not use LEDE 17.01.3 - because this version did never include that particular batman-adv release. You were more likely on some random LEDE development branch commit. > > ************************************************************************************** > * Did you use the openwrt-routing feed (which exact version) for > batctl+batman-adv or how did you build it? > > ANS: > Here are the main scripts. > git clone https://git.lede-project.org/source.git > ./scripts/feeds update -a > ./scripts/feeds install -a > > make download V=s > make V=99 > > At last I flushed the generated 2 files: > lede-ar71xx-generic-uImage-lzma.bin > lede-ar71xx-generic-root.squashfs These instruction will result in different version depending on when you run them. Neither the used LEDE commit is specified here nor the used feed commit. > ************************************************************************************** > * Did you generate graphs for the chosen best next hop and how it changes > over time in comparison to B.A.T.M.A.N. IV? > > ANS: > I had checked the route by batctl ping -R xxx.xxx.xxx.xxx > Unfortunately, we did not record and compare the route between IV and V. I am currently assuming that the chosen routes were wrong because of the cfg80211 bug [6]. Your brief tests with the fixed cfg80211 seem to suggest this but no way to check this now. Kind regards, Sven > [1] https://ieeexplore.ieee.org/document/8421863/ [2] https://en.wikipedia.org/wiki/Posting_style#Interleaved_style [3] https://github.com/openwrt/openwrt/releases/tag/v18.06.0 [4] https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/ [5] https://www.open-mesh.org/projects/open-mesh/wiki/MailingList [6] https://patchwork.kernel.org/patch/10449857/

4 12

[B.A.T.M.A.N.] [PATCH v2 0/7] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available
by Marek Lindner 29 Aug '18

29 Aug '18

Under normal circumstances B.A.T.M.A.N. V retrieves the neighbor throughput values to populate its metric tables from the various drivers such as WiFi throughput tables and Ethernet throughput.. Whenever the interface drivers do not export link throughput information manual overrides become necessary. To further automate and thus better support these setups, ELP may call the batman-adv throughput meter to schedule a throughput estimation to be used to populate the metric table. v2: * added sysfs attribute to configure tp meter test duration * fixed null pointer dereference in TP meter packet sending routine * fixed storing the measured throughput in the correct variable * checkpatch/kerneldoc/sparse/smatch cleanup Antonio Quartulli (3): batman-adv: tp_meter - prevent concurrent tp_meter sessions by using workqueue batman-adv: tp_meter - don't check for existing session batman-adv: tp_meter - add option to perform one-hop test Marek Lindner (4): batman-adv: tp_meter - allow up to 10 queued sessions batman-adv: tp_meter - add caller distinction batman-adv: ELP - use tp meter to estimate the throughput if otherwise not available batman-adv: ELP - add throughput meter test duration attribute .../ABI/testing/sysfs-class-net-batman-adv | 7 + include/uapi/linux/batadv_packet.h | 2 + net/batman-adv/bat_v.c | 1 + net/batman-adv/bat_v_elp.c | 66 ++- net/batman-adv/bat_v_elp.h | 21 + net/batman-adv/main.c | 10 +- net/batman-adv/main.h | 7 +- net/batman-adv/netlink.c | 3 +- net/batman-adv/routing.c | 6 +- net/batman-adv/sysfs.c | 3 + net/batman-adv/tp_meter.c | 463 +++++++++++------- net/batman-adv/tp_meter.h | 11 +- net/batman-adv/types.h | 36 ++ 13 files changed, 438 insertions(+), 198 deletions(-) -- 2.17.0

4 26

[B.A.T.M.A.N.] Wiki-Page "BATMAN and Dynamic VLANs with NPS Radius Server"
by Sven Eckelmann 19 Aug '18

19 Aug '18

Hi, what should this new page [1] be? It is categorized under "Open-Mesh" "WikiStart » Gettingstarted » Contribute" - which doesn't make any sense. It doesn't correctly use the textile wiki syntax. It starts with "I want to share my experience..." but then doesn't explain anything. It is just a raw dump of some config files without any actual context. I also don't see why this RADIUS (NPS), hostapd and OpenWrt configuration has any relevance for the Open-Mesh wiki. It seems to be written in a way which completely ignores the rest of the wiki content. I will delete this page when it isn't cleaned up, rewritten to be relevant for the wiki, placed correctly and linked in an appropriate place. Kind regards, Sven [1] https://www.open-mesh.org/projects/open-mesh/wiki/BATMAN_and_Dynamic_VLANs_…

1 0

Re: [B.A.T.M.A.N.] Fw: What's the exact definition of expected_throughput in BATMAN-ADV V?
by Sven Eckelmann 14 Aug '18

14 Aug '18

Hi, please don't contact me privately about batman-adv (unless you have a really, really, really, really good reason for that and explain the reason for that in the mail). At least Cc the official mailing list b.a.t.m.a.n(a)lists.open-mesh.org On Dienstag, 14. August 2018 05:32:48 CEST heishuihe2008(a)163.com wrote: [...] > I'm the author of paper "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms". Thank you very much for your comments on our work. > > I am sorry for some wrong statements in the discussed paper. Actually I'm new in OpenWRT/LEDE development and have much misunderstanding on it. The problem is now that the paper with the wrong statements, graphs and conclusions is now published by IEEE. Thus my proposal to retract it and prepare a new paper which doesn't contain the flaws. [...] > The following is the email I tried to send before. Just for reference. > > I'll continue to work on the batman-adv algorithms and report our result to the community. [...] > 发件人： heishuihe2008(a)163.com > 发送时间： 2018-03-22 16:29 > 收件人： b.a.t.m.a.n > 主题： What's the exact definition of expected_throughput in BATMAN-ADV V? > Dear all, > > I'm working on a wireless mesh network based on 802.11. > > When I tried to test the BATMAN-ADV V, I got very poor performance compared to version IV. > > I guessed the reason was V had much more management costs than IV. As we now know - most likely not the main contributor. But we will only know it when proper tests have been done. > Recently I found that the throughput metric was not reliable, probably. > The expected_throughput value from cfg80211_get_station is different from the one with batctl tp. > Which one is the correct? Depends on what you actually consider correct. cfg80211_get_station should provide a similar value as `batctl tp` for single hop tests with only a single possible link. The first one is done by the driver (actually the rate control minstrel in many cases) and is hopefully correctly implemented. Unfortunately, some driver do it completely wrong and return the PHY rate and some don't implement it at all. batctl tp on the other hand is currently not used for the metric. It uses a minimal stream protocol to transfer data from the current host to the specified host. It doesn't have to be a neighbor and you cannot specify which path it takes. The specified host will acknowledge the received data and the sender can calculate the successfully transmitted bytes using that. In its current form, it is not useful for B.A.T.M.A.N. V and can only be used for minimal performance tests in the mesh. > Does it mean the wireless driver does't support expected_throughput? Cannot say this for sure. The driver has to be checked. But your output suggest that you are using minstrel_ht - which provides an implementation for expected_throughput. But many kernel versions contain a cfg80211_get_station which isn't correctly initializing the sinfo structure - thus returning uninitialized expected_throughput values in some situations. > How to get the correct expected_throughput from wireless driver？ In which context? From userspace from a shell maybe? Check the output of `iw dev wlan0 station dump` and search for "expected throughput". If it isn't there than either your driver doesn't support it, your 'iw' doesn't support it or it didn't return a valid value (for unknown reasons). If you want to get it it via `iw` but instead via nl80211, then please use the NL80211_STA_INFO_EXPECTED_THROUGHPUT attribute which is sometimes returned for a NL80211_CMD_GET_STATION request [1]. > So I'm wondering that what's the exact definition of expected_throughput? I hope Antonio or Felix can provide a better definition. But I would say it is: The expected throughput is the number of kilobits per second a user will probably transfer (measured on the layers above wifi) when sending data directly to this host. This information is calculated based on the past experience of the driver (actually the rate control algorithm). > And what's the difference from tx/rx bitrate? TX/RX bitrate is the raw wifi bitrate. It is much higher than the expected throughput in most cases because it doesn't contains correction factors for packet loss, IFS/aggregation and so on. And it is just the info about a single frame which was received/transmitted - not a more complex value calculated based on the statistics gathered from the past transfers. Kind regards, Sven [1] https://git.kernel.org/pub/scm/linux/kernel/git/jberg/iw.git/tree/station.c… [2] https://patchwork.kernel.org/patch/10449857/

1 0

[B.A.T.M.A.N.] Paper "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms "
by Sven Eckelmann 11 Aug '18

11 Aug '18

Hi, Just saw your paper "Performance Evaluation of BATMAN-adv Wireless Mesh Network Routing Algorithms" [1]. Some small questions: * What is OpenWrt 1703? (you've referenced a batman-adv config tutorial here and there is no such version as OpenWrt 1703) * When did you want to contact the authors of the B.A.T.M.A.N. V implementation in batman-adv about your findings? * How did you solve the cfg80211 bug which returns uninitialized (random) data when asked for the expected throughput of a station? Maybe you remember that the expected throughput is *the value* which B.A.T.M.A.N. V needs to calculate routes. * What batman-adv version was used? * Did you use the openwrt-routing feed (which exact version) for batctl+batman-adv or how did you build it? * Did you generate graphs for the chosen best next hop and how it changes over time in comparison to B.A.T.M.A.N. IV? Kind regards, Sven [1] https://ieeexplore.ieee.org/document/8421863/

2 3

[B.A.T.M.A.N.] [PATCH v4 0/7] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available
by Marek Lindner 07 Aug '18

07 Aug '18

Under normal circumstances B.A.T.M.A.N. V retrieves the neighbor throughput values to populate its metric tables from the various drivers such as WiFi throughput tables and Ethernet throughput.. Whenever the interface drivers do not export link throughput information manual overrides become necessary. To further automate and thus better support these setups, ELP may call the batman-adv throughput meter to schedule a throughput estimation to be used to populate the metric table. v4: * read tp measurement result only once v3: * fix ELP tp meter result computation * use batadv_has_timed_out() instead of custom implementation * set ELP tp meter test duration to 1000ms in patch #6 * add comment explaining periodic scheduling v2: * added sysfs attribute to configure tp meter test duration * fixed null pointer dereference in TP meter packet sending routine * fixed storing the measured throughput in the correct variable * checkpatch/kerneldoc/sparse/smatch cleanup Antonio Quartulli (3): batman-adv: tp_meter - prevent concurrent tp_meter sessions by using workqueue batman-adv: tp_meter - don't check for existing session batman-adv: tp_meter - add option to perform one-hop test Marek Lindner (4): batman-adv: tp_meter - allow up to 10 queued sessions batman-adv: tp_meter - add caller distinction batman-adv: ELP - use tp meter to estimate the throughput if otherwise not available batman-adv: ELP - add throughput meter test duration attribute .../ABI/testing/sysfs-class-net-batman-adv | 7 + include/uapi/linux/batadv_packet.h | 2 + net/batman-adv/bat_v.c | 1 + net/batman-adv/bat_v_elp.c | 69 ++- net/batman-adv/bat_v_elp.h | 21 + net/batman-adv/main.c | 10 +- net/batman-adv/main.h | 7 +- net/batman-adv/netlink.c | 3 +- net/batman-adv/routing.c | 6 +- net/batman-adv/sysfs.c | 3 + net/batman-adv/tp_meter.c | 465 +++++++++++------- net/batman-adv/tp_meter.h | 11 +- net/batman-adv/types.h | 36 ++ 13 files changed, 443 insertions(+), 198 deletions(-) -- 2.18.0

1 7

[B.A.T.M.A.N.] [PATCH v3 0/7] B.A.T.M.A.N. V - fallback to tp meter estimation if throughput otherwise not available
by Marek Lindner 04 Aug '18

04 Aug '18

Under normal circumstances B.A.T.M.A.N. V retrieves the neighbor throughput values to populate its metric tables from the various drivers such as WiFi throughput tables and Ethernet throughput.. Whenever the interface drivers do not export link throughput information manual overrides become necessary. To further automate and thus better support these setups, ELP may call the batman-adv throughput meter to schedule a throughput estimation to be used to populate the metric table. v3: * fix ELP tp meter result computation * use batadv_has_timed_out() instead of custom implementation * set ELP tp meter test duration to 1000ms in patch #6 * add comment explaining periodic scheduling v2: * added sysfs attribute to configure tp meter test duration * fixed null pointer dereference in TP meter packet sending routine * fixed storing the measured throughput in the correct variable * checkpatch/kerneldoc/sparse/smatch cleanup Antonio Quartulli (3): batman-adv: tp_meter - prevent concurrent tp_meter sessions by using workqueue batman-adv: tp_meter - don't check for existing session batman-adv: tp_meter - add option to perform one-hop test Marek Lindner (4): batman-adv: tp_meter - allow up to 10 queued sessions batman-adv: tp_meter - add caller distinction batman-adv: ELP - use tp meter to estimate the throughput if otherwise not available batman-adv: ELP - add throughput meter test duration attribute .../ABI/testing/sysfs-class-net-batman-adv | 7 + include/uapi/linux/batadv_packet.h | 2 + net/batman-adv/bat_v.c | 1 + net/batman-adv/bat_v_elp.c | 69 ++- net/batman-adv/bat_v_elp.h | 21 + net/batman-adv/main.c | 10 +- net/batman-adv/main.h | 7 +- net/batman-adv/netlink.c | 3 +- net/batman-adv/routing.c | 6 +- net/batman-adv/sysfs.c | 3 + net/batman-adv/tp_meter.c | 467 +++++++++++------- net/batman-adv/tp_meter.h | 11 +- net/batman-adv/types.h | 36 ++ 13 files changed, 445 insertions(+), 198 deletions(-) -- 2.18.0

3 9

[B.A.T.M.A.N.] [PATCH 00/17] pull request for net-next: batman-adv 2016-10-27
by Simon Wunderlich 04 Aug '18

04 Aug '18

Hi David, this is our first feature pull request for batman-adv (mostly containing code cleanup stuff), there are at least two more to come. Please pull or let me know of any problem! Thank you, Simon The following changes since commit 29fbff8698fc0ac1a1d74584b258e0bf18b469f9: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2016-10-13 21:40:23 -0700) are available in the git repository at: git://git.open-mesh.org/linux-merge.git tags/batadv-next-for-davem-20161027 for you to fetch changes up to 4c7da0f6dbcde2431d773ce03cde5e7abede54e0: batman-adv: Avoid precedence issues in macros (2016-10-19 08:37:54 +0200) ---------------------------------------------------------------- This code cleanup patchset includes the following changes (chronological order): - bump version strings, by Simon Wunderlich - README updates/clean up, by Sven Eckelmann (4 patches) - Code clean up and restructuring by Sven Eckelmann (2 patches) - Kerneldoc fix in forw_packet structure, by Linus Luessing - Remove unused argument in dbg_arp, by Antonio Quartulli - Add support to build batman-adv without wireless, by Linus Luessing - Restructure error handling for is_ap_isolated, by Markus Elfring - Remove unused initialization in various functions, by Sven Eckelmann - Use better names for fragment and gateway list heads, by Sven Eckelmann (2 patches) - Convert to octal permissions for files, by Sven Eckelmann - Avoid precedence issues for some macros, by Sven Eckelmann ---------------------------------------------------------------- Antonio Quartulli (1): batman-adv: remove unsed argument from batadv_dbg_arp() function Linus Lüssing (2): batman-adv: fix batadv_forw_packet kerneldoc for list attribute batman-adv: Allow selecting BATMAN V if CFG80211 is not built Markus Elfring (1): batman-adv: Less function calls in batadv_is_ap_isolated() after error detection Simon Wunderlich (1): batman-adv: Start new development cycle Sven Eckelmann (12): batman-adv: Add B.A.T.M.A.N. V sysfs files to README batman-adv: Add network_coding and mcast sysfs files to README batman-adv: Add dat, mcast, nc and neighbor debugfs files to README batman-adv: Document new nc, mcast and tpmeter log levels batman-adv: Remove unused function batadv_hash_delete batman-adv: Move batadv_sum_counter to soft-interface.c batman-adv: Remove unused batadv_icmp_user_cmd_type batman-adv: Remove needless init of variables on stack batman-adv: Use proper name for fragments list head batman-adv: Use proper name for gateway list head batman-adv: Use octal permissions instead of macros batman-adv: Avoid precedence issues in macros Documentation/networking/batman-adv.txt | 35 ++++++++++++---------- net/batman-adv/Kconfig | 2 +- net/batman-adv/bat_iv_ogm.c | 6 ++-- net/batman-adv/bat_v.c | 8 ++--- net/batman-adv/bat_v_ogm.c | 4 +-- net/batman-adv/debugfs.c | 26 ++++++++-------- net/batman-adv/distributed-arp-table.c | 17 ++++------- net/batman-adv/fragmentation.c | 18 +++++------ net/batman-adv/fragmentation.h | 2 +- net/batman-adv/gateway_client.c | 9 +++--- net/batman-adv/hash.h | 30 ------------------- net/batman-adv/icmp_socket.c | 5 ++-- net/batman-adv/log.c | 4 +-- net/batman-adv/log.h | 12 ++++---- net/batman-adv/main.c | 2 +- net/batman-adv/main.h | 27 ++--------------- net/batman-adv/network-coding.c | 8 ++--- net/batman-adv/originator.c | 10 +++---- net/batman-adv/packet.h | 12 +------- net/batman-adv/send.c | 2 +- net/batman-adv/soft-interface.c | 21 +++++++++++++ net/batman-adv/sysfs.c | 53 ++++++++++++++------------------- net/batman-adv/translation-table.c | 25 +++++++--------- net/batman-adv/types.h | 16 +++++----- 24 files changed, 149 insertions(+), 205 deletions(-)

7 35

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N August 2018