Skip to content
Snippets Groups Projects
  1. Apr 08, 2019
    • Sven Eckelmann's avatar
      gluon-mesh-batman-adv: Save if metrics chose neighbor as own best nexthop · cef21e58
      Sven Eckelmann authored
      
      The commit ee63ed42fe6c ("gluon-mesh-batman-adv: List neighbors with
      non-best direct link") removed the check whether a neighbor has the
      BATADV_ATTR_FLAG_BEST set. But consumers may still want to filter out or
      mark neighbors which don't have this flag set. To assist with such a
      feature, enhance the neighbor object with an extra boolean "best" attribute
      which stores whether the BATADV_ATTR_FLAG_BEST was found or not.
      
      Reported-by: default avatarVincent Wiemann <webmaster@codefetch.de>
      cef21e58
    • Sven Eckelmann's avatar
      gluon-mesh-batman-adv: List neighbors with non-best direct link · ec72d30b
      Sven Eckelmann authored
      Links between two direct neighbors are not always the best route between
      these devices. The flag BATADV_ATTR_FLAG_BEST would not be set for these
      originator entries and the respondd module would just ignore this entry.
      
      This causes missing links in meshviewer and similar tools. And when the
      link quality is nearly equal and but fluctuates slightly, these links will
      from time to time appear and disappear on the map.
      
      Fixes: 2e0e24a9 ("announce neighbours using alfred/gluon-announce")
      ec72d30b
  2. Mar 16, 2019
    • Sven Eckelmann's avatar
      gluon-mesh-batman-adv: Only use local TT to count non-wifi clients (#1676) · b850fff7
      Sven Eckelmann authored
      
      The amount of local wifi clients is currently counted by two different
      ways:
      
      * asking the kernel wifi layer for the number of of clients on 2.4GHz and
        5GHz band
      * asking batman-adv for the number of non-timed out entries in the local
        translation table with WiFi flag
      
      The number of wifi24+wifi5 and the number of TT wifi client counts are
      reported via respondd to various consumers. The ffrgb meshviewer is
      displaying these values as:
      
      * 2,4 GHz: wifi24
      * 5 GHz: wifi5
      * other: (TT local wifi+non-wifi clients) - (wifi24 + wifi5)
      
      But the local translation table is holding entries much longer than the
      wifi layer. It can therefore easily happen that a wifi client disappears in
      the kernel wifi layer and batman-adv still has the entry stored in the
      local TT.
      
      The ffrgb meshviewer would then show this count in the category "other".
      This often results in confusions because "other" is usually for ethernet
      clients. And nodes with a frequently disappearing larger group of clients
      (near bus stations or larger intersections) often show most clients under
      the group "other" even when this devices doesn't have a LAN ethernet port.
      
      It is better for presentation to calculate the number of total wifi clients
      by summing up wifi24 + wifi5. And getting the number of total clients (non
      wifi + wifi) by adding the result of the previous calculation to the sum of
      non-wifi client in the local batman-adv translation table.
      
      Fixes: 89a9d813 ("gluon-mesh-batman-adv-core: Announce client count by frequency")
      Reported-by: default avatarPascal Wettin <p.wettin@gmx.de>
      b850fff7
  3. Feb 17, 2019
  4. Nov 18, 2018
  5. Nov 17, 2018
  6. Sep 01, 2018
  7. Dec 27, 2017
  8. Sep 21, 2017
  9. Apr 12, 2017
Loading