B.A.T.M.A.N January 2014

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

21 participants
62 discussions

Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
by Antonio Quartulli 22 Jan '14

22 Jan '14

On 22/01/14 01:29, cmsv wrote: > > > On 01/21/2014 07:20 PM, Antonio Quartulli wrote: >> On 22/01/14 01:14, cmsv wrote: >>> >>> >>> On 01/21/2014 07:06 PM, Antonio Quartulli wrote: >>>> On 22/01/14 01:00, Antonio Quartulli wrote: >>>>> On 21/01/14 21:01, cmsv wrote: >>>>>> Yes i understand that but it keeps on increasing. >>>>>> [ 28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too >>>>>> small (1546) to handle the transport of batman-adv packets. Packets >>>>>> going over this interface will be fragmented on layer2 which could >>>>>> impact the performance. Setting the MTU to 1560 would solve the problem. >>>>> >>>>> Have you tried applying this patch before testing it once again? >>>>> >>>>> http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af0… >>>>> >>>> >>>> Actually this patch is already part of the batman-adv package in openwrt. >>>> Therefore the question turns in: did you update the batman-adv package >>>> before performing your second test? >>> >>> the second test was done today and yesterday's i updated bataman-adv. >> >> Yes but we are creating confusion. > Maybe. Lets see. >> >> In the second test you *enabled* network coding, therefore it is normal >> that the overhead grew up. This happens because NC uses more bytes for >> its header. > > > In both tests NC was enabled. I have NC enabled by default before and > after the update. > In fact is all tests NC is enabled by default and i undestand the > increase to 1546 but to 1560 it surprised me. > Should i still see the increase to 1560 or should it stayed at 1546 > which would be 1532 ? > > [Please don't remove the batman-adv mailing list from the CC field.] The first test you have performed was without the patch that fixes the value reported in that message. Now that the patch is applied you have to see 1560 when NC is enabled and 1532 when it is disabled. Can you confirm? cheers, -- Antonio Quartulli

3 3

Re: [B.A.T.M.A.N.] batman-adv 2014.0.0 released
by Antonio Quartulli 22 Jan '14

22 Jan '14

On 22/01/14 01:14, cmsv wrote: > > > On 01/21/2014 07:06 PM, Antonio Quartulli wrote: >> On 22/01/14 01:00, Antonio Quartulli wrote: >>> On 21/01/14 21:01, cmsv wrote: >>>> Yes i understand that but it keeps on increasing. >>>> [ 28.600000] batman_adv: bat0: The MTU of interface adhoc0 is too >>>> small (1546) to handle the transport of batman-adv packets. Packets >>>> going over this interface will be fragmented on layer2 which could >>>> impact the performance. Setting the MTU to 1560 would solve the problem. >>> >>> Have you tried applying this patch before testing it once again? >>> >>> http://git.open-mesh.org/batman-adv.git/commit/746d6436f88899a79c1cb3b27af0… >>> >> >> Actually this patch is already part of the batman-adv package in openwrt. >> Therefore the question turns in: did you update the batman-adv package >> before performing your second test? > > the second test was done today and yesterday's i updated bataman-adv. Yes but we are creating confusion. In the second test you *enabled* network coding, therefore it is normal that the overhead grew up. This happens because NC uses more bytes for its header. If you disable NC the suggested value should go back to 1532. Cheers, -- Antonio Quartulli

1 0

Re: [B.A.T.M.A.N.] [RFC 0/5] Export Minstrel best API information via get_station()
by Antonio Quartulli 21 Jan '14

21 Jan '14

Hi Thomas, [added batman-adv mailing list to the CC] On 21/01/14 14:52, Thomas Hühn wrote: > Hi Antonio, > > I like you idea of making use of information from different layers to try to enhance wireless communication. > It seems reasonable for me to start exporting and further using/experimenting with that rate, where minstrel estimates the maximum throughput. > But on closer inspection, it might also be of certain interest (maybe not batman in particular) to use the most robust rate, which both Minstrels version do also have an estimate. > So what do you think about exporting the whole sorted rate table structure (struct ieee80211_sta_rates) instead of extracting the single max thr. rate ? > Thank you very much for your feedback! I like your idea about opening this change a bit more and allow other modules to use the same information. However the ieee80211_sta_rates structure you mentioned is mac80211 private and it does not carry any data about the probability of success (which is a Minstrel specific value and for this reason it is not present in this ieee80211 generic structure). Assuming that we want to keep the new exported data Minstrel specific (we really want this), we could extend the station_info to carry a *set* of "cfg80211_minstrel_rate_info" objects (new struct introduced within this patchset) which could represent the sorted rate table. However I am not sure how this table can be used once exported, since the only thing having a meaning is the order. Other than that I don't see what a module could do with it (other than choosing the first entry). Instead of exporting the whole rate table, should we only report those rates that have a particular meaning for Minstrel? I think Minstrel is the only component having enough information about which rate is meaningful and which not. What do you think? This could be done by exporting several cfg80211_minstrel_rate_info, e.g. - max_throughput_rate - most_robust_rate - ... (I used random names here) Cheers, > Greetings Thomas > > > On 21.01.2014, at 12:09, Antonio Quartulli <antonio(a)meshcoding.com> wrote: > >> Hello list, >> >> we (as batman-adv developers) are currently working on a new version of the >> our routing protocol which is going to use some Minstrel internal information >> to compute the metric. >> In particular I am interested in the currently selected bitrate (which Minstrel >> selected because it "maximises the throughput") and it's probability of success. >> >> To achieve so I am proposing here a change to the get_station API. >> This change is supposed to export the needed information only if the current >> driver is using the Minstrel (or Minstrel HT) RC algorithm. >> >> Patch 1 introduced the change in get_station() >> Patch 2 add a new rate_control API used to query the RC algorithm and retrieve >> the information. Then it fills the sinfo object. >> Patch 3 and 4 are implementing this rate_control API in minstrel and minstrel_ht >> Patch 5 exports the get_station API in order to allow other modules to use it. >> >> >> I already had a discussion with Johannes about this patch being not generic >> enough and really focussed on Minstrel only. >> >> However this change will just >> introduce a new exported capability in the station_info object: if the driver >> does not support it (e.g. it does not use Minstrel) then we simply won't have >> this information (like we already do with other capabilities). >> >> >> Cheers, >> >> p.s. I may need to add some more kerneldoc >> >> >> Antonio Quartulli (5): >> cfg80211: export minstrel best rate information through get_station() >> mac80211: export minstrel best rate information in set_sta_info() >> mac80211: minstrel - implement get_minstrel_best_rate() API >> mac80211: minstrel_ht - implement get_minstrel_best_rate() API >> cfg80211: implement cfg80211_get_station >> >> include/net/cfg80211.h | 28 ++++++++++++++++++++++++++++ >> include/net/mac80211.h | 15 +++++++++++++++ >> net/mac80211/cfg.c | 15 +++++++++++++++ >> net/mac80211/rc80211_minstrel.c | 12 ++++++++++++ >> net/mac80211/rc80211_minstrel_ht.c | 30 ++++++++++++++++++++++++++++++ >> net/wireless/nl80211.c | 22 ++++++++++++++++++++++ >> 6 files changed, 122 insertions(+) >> >> -- >> 1.8.5.3 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in >> the body of a message to majordomo(a)vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Antonio Quartulli

1 0

[B.A.T.M.A.N.] [PATCH linux-next] net: batman-adv: use "__packed __aligned(2)" for each structure instead of "__packed(2)" region
by Chen Gang 20 Jan '14

20 Jan '14

Unfortunately, not all compilers assumes the structures within a pack region also need be packed (e.g. metag), so need add a pack explicitly to satisfy all compilers. The related error (under metag with allmodconfig): MODPOST 2952 modules ERROR: "__compiletime_assert_431" [net/batman-adv/batman-adv.ko] undefined! ERROR: "__compiletime_assert_432" [net/batman-adv/batman-adv.ko] undefined! ERROR: "__compiletime_assert_429" [net/batman-adv/batman-adv.ko] undefined! ERROR: "__compiletime_assert_428" [net/batman-adv/batman-adv.ko] undefined! ERROR: "__compiletime_assert_423" [net/batman-adv/batman-adv.ko] undefined! Signed-off-by: Chen Gang <gang.chen.5i5j(a)gmail.com> --- net/batman-adv/packet.h | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/net/batman-adv/packet.h b/net/batman-adv/packet.h index 0a381d1..9206b48 100644 --- a/net/batman-adv/packet.h +++ b/net/batman-adv/packet.h @@ -154,7 +154,6 @@ enum batadv_tvlv_type { BATADV_TVLV_ROAM = 0x05, }; -#pragma pack(2) /* the destination hardware field in the ARP frame is used to * transport the claim type and the group id */ @@ -162,8 +161,7 @@ struct batadv_bla_claim_dst { uint8_t magic[3]; /* FF:43:05 */ uint8_t type; /* bla_claimframe */ __be16 group; /* group id */ -}; -#pragma pack() +} __packed __aligned(2); /** * struct batadv_ogm_packet - ogm (routing protocol) packet @@ -281,7 +279,6 @@ struct batadv_icmp_packet_rr { * misalignment of the payload after the ethernet header. It may also lead to * leakage of information when the padding it not initialized before sending. */ -#pragma pack(2) /** * struct batadv_unicast_packet - unicast packet for network payload @@ -300,7 +297,7 @@ struct batadv_unicast_packet { /* "4 bytes boundary + 2 bytes" long to make the payload after the * following ethernet header again 4 bytes boundary aligned */ -}; +} __packed __aligned(2); /** * struct batadv_unicast_4addr_packet - extended unicast packet @@ -316,7 +313,7 @@ struct batadv_unicast_4addr_packet { /* "4 bytes boundary + 2 bytes" long to make the payload after the * following ethernet header again 4 bytes boundary aligned */ -}; +} __packed __aligned(2); /** * struct batadv_frag_packet - fragmented packet @@ -347,7 +344,7 @@ struct batadv_frag_packet { uint8_t orig[ETH_ALEN]; __be16 seqno; __be16 total_size; -}; +} __packed __aligned(2); /** * struct batadv_bcast_packet - broadcast packet for network payload @@ -368,7 +365,7 @@ struct batadv_bcast_packet { /* "4 bytes boundary + 2 bytes" long to make the payload after the * following ethernet header again 4 bytes boundary aligned */ -}; +} __packed __aligned(2); /** * struct batadv_coded_packet - network coded packet @@ -404,9 +401,8 @@ struct batadv_coded_packet { uint8_t second_orig_dest[ETH_ALEN]; __be32 second_crc; __be16 coded_len; -}; +} __packed __aligned(2); -#pragma pack() /** * struct batadv_unicast_tvlv - generic unicast packet with tvlv payload -- 1.7.11.7

3 5

[B.A.T.M.A.N.] [PATCH] batadv-vis: don't leak socket fd in get_if_mac()
by Matthias Schiffer 20 Jan '14

20 Jan '14

Leaking an fd every time get_if_mac() is called causes a batadv-vis server process to hit the open file limit in a matter of hours when it is as low as 1024 (which it is on OpenWRT). Reported-by: Jan-Philipp Litza <janphilipp(a)litza.de> Signed-off-by: Matthias Schiffer <mschiffer(a)universe-factory.net> --- vis/vis.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/vis/vis.c b/vis/vis.c index dcb4db4..7a8e780 100644 --- a/vis/vis.c +++ b/vis/vis.c @@ -96,7 +96,7 @@ static uint8_t *str_to_mac(char *str) static int get_if_mac(char *ifname, uint8_t *mac) { struct ifreq ifr; - int sock; + int sock, ret; strncpy(ifr.ifr_name, ifname, IFNAMSIZ); @@ -105,7 +105,11 @@ static int get_if_mac(char *ifname, uint8_t *mac) return -1; } - if (ioctl(sock, SIOCGIFHWADDR, &ifr) == -1) { + ret = ioctl(sock, SIOCGIFHWADDR, &ifr); + + close(sock); + + if (ret == -1) { fprintf(stderr, "can't get MAC address: %s\n", strerror(errno)); return -1; } -- 1.8.5.3

3 3

[B.A.T.M.A.N.] [PATCHv3 maint] batman-adv: fix potential kernel paging error for unicast transmissions
by Linus Lüssing 20 Jan '14

20 Jan '14

batadv_send_skb_prepare_unicast(_4addr) might reallocate the skb's data. If it does then our ethhdr pointer is not valid anymore in batadv_send_skb_unicast(), resulting in a kernel paging error. Fixing this by refetching the ethhdr pointer after the potential reallocation. Introduced-by: b46c60b9e1ee7a1909c542413a85875a750955d6 ("batman-adv: improve unicast packet (re)routing") Signed-off-by: Linus Lüssing <linus.luessing(a)web.de> --- Changes v3: * now rebased on maint * added "Introduced-by" * removed "NOTE TO..." paragraph (still can't be applied as is to kernels < 3.9) send.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/send.c b/send.c index b0a3d76..50df184 100644 --- a/send.c +++ b/send.c @@ -281,6 +281,10 @@ static int batadv_send_skb_unicast(struct batadv_priv *bat_priv, goto out; } + /* skb->data might have been reallocated by + * batadv_send_skb_prepare_unicast* + */ + ethhdr = eth_hdr(skb); unicast_packet = (struct batadv_unicast_packet *)skb->data; /* inform the destination node that we are still missing a correct route -- 1.7.10.4

1 0

[B.A.T.M.A.N.] [PATCHv2 next] batman-adv: fix potential kernel paging error for unicast transmissions
by Linus Lüssing 19 Jan '14

19 Jan '14

batadv_send_skb_prepare_unicast(_4addr) might reallocate the skb's data. If it does then our ethhdr pointer is not valid anymore in batadv_send_skb_unicast(), resulting in a kernel paging error. Fixing this by refetching the ethhdr pointer after the potential reallocation. ~~~ NOTE TO LINUX STABLE MAINTAINERS: For kernels < 3.9 you will need an additional skb_reset_mac_header(skb) call in the beginning of batadv_send_skb_unicast(). For kernels >= 3.9 this is not necessary thanks to: "net: reset mac header in dev_start_xmit()" (6d1ccff627) ~~~ Signed-off-by: Linus Lüssing <linus.luessing(a)web.de> --- Note: this patch shouldn't be used in an off-tree module on kernels < 3.9 without the compat hunk provided by: "batman-adv: use vlan_/eth_hdr() instead of skb->data in interface_tx path" send.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/send.c b/send.c index 579f5f0..8b312e3 100644 --- a/send.c +++ b/send.c @@ -279,6 +279,10 @@ static int batadv_send_skb_unicast(struct batadv_priv *bat_priv, goto out; } + /* skb->data might have been reallocated by + * batadv_send_skb_prepare_unicast* + */ + ethhdr = eth_hdr(skb); unicast_packet = (struct batadv_unicast_packet *)skb->data; /* inform the destination node that we are still missing a correct route -- 1.7.10.4

1 0

[B.A.T.M.A.N.] eth_hdr/skb_reset_mac_header changes
by Linus Lüssing 19 Jan '14

19 Jan '14

Changes v5: Added Antonio's simpler compat code suggestion (thanks!)

2 3

[B.A.T.M.A.N.] eth_hdr/skb_reset_mac_header changes
by Linus Lüssing 18 Jan '14

18 Jan '14

Changes for v4: * removed one newline which slipped in with v3 * split the v3 patch in two ones

1 2

[B.A.T.M.A.N.] Barrier breaking kmod-batman-adv package
by tjhowse 18 Jan '14

18 Jan '14

Not sure if this is appropriate for this list, but I'm trying to get batman-adv running on the latest bleeding edge barrier breaker r39286 but kmod-batman-adv is not available from the package repo. When I was setting up a r38816-based router a few months ago and I didn't have to set up the build environment and whatnot, just opkg install kmod-batman-adv. Anyone know why it's not available anymore? I'm working on creating an updated system image using batman-adv 2014 for the purpose of future-proofery. Thanks, Travis.

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

B.A.T.M.A.N January 2014