Hello everyone.

I am currently trying to set up yanic for the Freifunk Aachen community.

In this community we have divided the network into multiple segments to keep the broadcast domain size managable etc. The monitoring server (which does among other tasks nodeinfo collection) has a bridge interface for each of our segments. As the seperation of segments is only a technical and not a social divide, we want to display all nodes from all segments on our map. Until now we used hopglass-server which is able to listen to multiple interfaces at the same time. This is not possible with yanic (Or is it? If so: Problem solved, all that remains is maybe a documentation fix?)

We cannot just bridge all these bridge interfaces together, as this would break stuff on the network side (hazy on the details but I think batman-adv bridge-loop-avoidance gets confused there).

I see the following solutions:

• Run one instance of Yanic on each of these bridges. A downstream script can then merge together the resulting nodes.json files to have one big file we can feed to our map.
  ** Downside: Having one config file per segment is kind of annoying when one wants to do global changes.
  ** Downside: Yet another work step when adding new segments (setting up a new yanic instance instead of changing e.g. a flag).
  ** Downside: One cannot use convenience features like the built-in webserver etc. anymore
  ** Upside: Would work right now without code changes. Having the merge script upstream would be kind of neat still.

• Add a configuration option similar to the one in hopglass-server where yanic can collect info from multiple interfaces at the same time.
  ** Downside: No idea how hard this is to implement.
  ** Upside: No additional data-plumbing required, everything should just work for the user.
  ** Upside: Network operators can change segments spontaneously or maybe even in an automated fashion.

If you have other ideas, I am open for input.

Thanks for your consideration!

My latest update to gluon-radv-filterd sends MAC address of the selcted gateway via the "statistics.gateway6" attribute. Would be great if that would make it into the nodes.json.

Disclaimer: It hasn't been merged to Gluon yet, so the name of the attribute could change. However, having an overview of whether the feature works by showing the selected gateway in the nodes.json would certainly help merging. 😊

A Graph here would be cool:
https://map.ffhb.de/#!v:m;n:f4f26d706d9e
or
https://map.ffhb.de/#!v:m;l:c04a00be7d1c-14cc20ba7487

(meshviewer could work with ID and Hostname ...)

i would like to use the golang-lib logrus for this issue.
https://github.com/sirupsen/logrus

There is a race condition:

--- FAIL: TestStart (0.03s)
        Error Trace:    internal_test.go:51
	Error:      	Not equal: 
	            	expected: 1
	            	actual: 0
        Error Trace:    internal_test.go:55
	Error:      	Not equal: 
	            	expected: 2
	            	actual: 3
FAIL
FAIL	github.com/FreifunkBremen/yanic/output	0.048s

I want to increase the test coverage (after #44 , #62 and #63 - and after Breminale) over 80 %.

commit: 9720835

Yanic crashes with the error message "fatal error: concurrent map iteration and write".

Last output: https://gist.github.com/yayachiken/0043ef2b5fd01acc4d17b7f06678f963

No idea what circumstances cause this. It already happened twice though. When restarting, yanic is able to run fine again. Becuase the crash only happened twice now I have no idea how much time usually passes between crashes, but in this case it was a couple of hours.

713 Knoten (644 online, 7 neu, 40 verschwunden)

Checklist:

• I mentioned the community
• I mentioned the database type
• I added a link to the visualization of the collected data

https://map.freifunk.in-kiel.de

It looks like the database (a secound influxdb on my homeserver - ipv6/ssl) slow down the collection and create wrong data.

Node specific data should be remove from the InfluxDB after some days.

Du sagst es doch selbst: Du flutest das Netz etwas.

Ab der nächsten Gluon-Version wird es außerdem eine Verzögerung von bis
zu 10 Sekunden bei der Beantwortung von Multicast-Anfragen geben [1], um
diese Netz-Flutung zu vermeiden. Spätestens dann macht es keinen Sinn
mehr, alle 5 Sekunden zu fragen.

Ich würde die Unicast-Nachfrage daher schon sehr begrüßen.

Viele Grüße,
Jan-Philipp

[1]
freifunk-gluon/gluon@9a06a98

Interpreting load is always relative to the number of CPU cores of the device being monitored. Recently more devices with multiple cores have turned up and meaningful graphs need to take that into account.

Therefore I'd recommend exporting nproc to the time series databases.

i would like to use https://github.com/mitchellh/mapstructure in that plugins.

blocked by #63 - should be upstream first

A separate measurement in InfluxDB should be filled periodically with the number of devices tagged by the firmware version.

Checklist:

• I mentioned the community
• I mentioned the database type
• I added a link to the visualization of the collected data
  https://mesh.freifunknord.de

This looks like we finally have a reasonable implementation that provides the code infrastructure to fulfill all tasks. If yanic proves itself stable and useful I will consider dropping hopglass-server development in favor of yanic.

A similar story can be told for the ffrgb-meshviewer, however yanic+ffrgb-meshviewer are missing some features that hopglass+hopglass-server provide. I am currently working on merging all the internal improvements of ffrgb-meshviewer into hopglass while preserving all features.

Required additions to meshviewer nodes.json v2 and meshviewer graph.json to support all features of hopglass:

• bidirectional links in graph.json (could be reduced to bidirectional tq numbers)
• link attribute "type" in graph.json is a string that can currently be
  • "fastd" or "tunnel": a fastd vpn link
  • "l2tp": l2tp vpn link
  • "other": a cable / Mesh on LAN / WAN link
• all airtime data provided by a current gluon master router has to be forwarded to nodes.json
• nexthop has to be forwarded to nodes.json
• gateway and nexthop MACs have to be resolved to their nodeids (could be moved to client)

I'll update this issue when I remember another required change or there are new required changes to support all features of hopglass.

HopGlass will probably catch up with your changes before this gets implemented.

Also when ffrgb-meshviewer and all features of hopglass are in one release and yanic supports all those features I see no reason to continue developing hopglass and ffrgb-meshviewer as two projects.

I want a comment from you (@genofire) if you think this is feasable and if you are ready to support these features. A exact format should be agreed on, although as long as it contains all the required data HopGlass can be adapted.

We use Yanic. Our Meshviewer doesn't show the map but an error message (Cannot read property 'forEach' of undefined). It seems the graph.json or nodes.json is broken. Is there any tool to validate this? I could not find the error.

I updated our installation to the latest master with the refactored filters but I have some problems with them.

1. no_owner was renamed to noowner. The documentation still says it should be no_owner.

panic: filter configuration errors: [unknown filter: no_owner]

2. blacklist and sites complain about invalid configuration but they are defines as shown in the documentation.

[nodes.output.meshviewer-ffrgb.filter]
blacklist = ["98ded0c5e0c0","ec086b6135da"]
sites = ["ffwi"]

panic: filter configuration errors: [unable to initialize filter blacklist: invalid configuration, array of strings expected]

panic: filter configuration errors: [unable to initialize filter sites: invalid configuration, array of strings expected]

Config

[influxdb]
enable   = true
address  = "http://localhost:8086"
database = "ffhb"
username = ""
password = ""
# cleaning data of measurement node,
#   which are older than 7d
delete_after = "7d"
#   how often run the cleaning
delete_interval = "1h"

Version
016e2dc

Description
Influxdb lost more then all data after 7 days :(
But this habben just on some nodes not on every one.

The upcoming gluon version will likely have multidomain support. The nomenclature is that a site is an aggregate of multiple domains.

In addition to site_code the system object in nodeinfo needs to parse the domain_code, which separates different meshes.

I assume it suffices to add the DomainCode here:

// System struct
type System struct {
	SiteCode string `json:"site_code,omitempty"`
	DomainCode string `json:"domain_code,omitempty"`
}

Editorconfig allows basic settings for editor (with or without plugins http://editorconfig.org/ ).
Behavior like newline, end of line, indent_style, indent_size for different files.

Please suggest new names for this sofware - one name per comment. Use 👍 and 👎 to place your votes.

maybe at the output/meshviewer it is enough

If one node goes offline the links to other nodes should be removed.

For golang's version with 1.7 and before it could be fixed with this patch

diff --git a/cmd/respond-collector/main.go b/cmd/respond-collector/main.go
index d40d073..5d4be75 100644
--- a/cmd/respond-collector/main.go
+++ b/cmd/respond-collector/main.go
@@ -57,8 +57,7 @@ func main() {

        if config.Webserver.Enable {
                log.Println("starting webserver on", config.Webserver.Bind)
-               srv := webserver.New(config.Webserver.Bind, config.Webserver.Webroot)
-               go srv.Close()
+               webserver.New(config.Webserver.Bind, config.Webserver.Webroot)
        }

        // Wait for INT/TERM

inject data into a other database

• maybe it is usefull after #104 (there is ip-address binding)

Node is offline and links are still provided

if yanic is just for receiving respondd pks, like [database.connection.respondd]

• implement after #104 and #120.

https://packagecloud.io/FreifunkBremen/yanic/ exists now.
Next step would be to create debian package with travis:

https://docs.travis-ci.com/user/deployment/packagecloud/

it would be nice to be able to allow self-signed certificates for the database connectors like influxdb

Expected Behavior

the connection should simply work

Current Behavior

there's a panic because of the self-signed certificate

Possible Solution

allow self-signed certificates either by default or by choice

Context

connection to influxdb should be encrypted, without the need for some "official" CA

Your Environment

influxdb 1.5.x
yanic current (what is installed by go get -v -u github.com/FreifunkBremen/yanic)

Now and then we are having nodes with incomplete geo locations.

e.g. one of longitude or latitude is missing completely
missing dot in longitude or latitude

Could yanic remove those incomplete/unrealistic geo locations?

Memory usage is always really high. I think it is disk usage and not RAM.

A load average of 0.0 does not show up in meshviewer.json, probably because it's being treated as 0, Null, False etc.

Idea: Add feature to write collected logs to ElasticSearch

I know that i am explain so much things really complicated.

Let's improve together the documentation:
https://yanic.gitbooks.io/documentation/

What do you thought? @corny
Did we want use it? Do you like access?

Add wireless typ of link in graph.json
There is already vpn in a link of the graph.json -> a wifi type would also be cool.
So there are all three options of interfaces implementet.

For the https://nilsschneider.net/2016/04/10/babel-in-gluon.html yanic needs to send multicast on an own interface. Unicasts need to be send on the vpn interfaces, where yanic also needs to listen for the unicast answer.

http://netjson.org/rfc.html

Structure will be definied with https://github.com/ffrgb/meshviewer together.

Follow

• https://github.com/ffrgb/meshviewer/issues/87
• https://github.com/freifunk-gluon/gluon/wiki/Roadmap

Right now yanic does only recognize meshvpn links from fastd.
It would be nice to support more meshvpn software like tunneldigger or wireguard.

How can we workaround this?

kindly regards

For displaying diagrammes like the secound here: https://ffhb.de/map/node.html?id=66:6a:b3:8a:49:80

Neighbours count maybe seperate after:

• vpn
• physical
  • ethernat
  • wifi
    • wifi 2.4 Ghz
    • wifi 5 Ghz

• Repository
• Doku
• cmd's
• go imports

https://github.com/ffrgb/meshviewer/issues/159

Hey everyone,
Since a few months, I'm working an respondd on our supernodes.
This worked out merely shitty, but got done yesterday.
Except for one server.
As it turns out, that server is the only one of ours having more than 4gb of free ram...

As the logs put it:

Jan 31 16:31:10 the_ yanic[26127]: 2018/01/31 16:31:10 unable to decode response from [fe80::1c3b:e7ff:fee0:414b%bat0]:1001 json: cannot unmarshal number 5932621824 into Go struct field Memory.free of type uint32

I see two options;
but as much as I love the idea to put the internal memory under load in order to make a node pop up in our map, I think it would be more saner to solve this problem in code.

I'm not sure, if it was worth the waste of memory just to show memory stats on a bigger scale with such a high precision. The alternative would be to cap the respondd-client in order to lie about the free memory so that the limit of a uint32 would not be exceeded.

What do you think?

Im Meshviewer wird ausgegeben, dass Knoten, welche Uplink haben, keinen Uplink haben.
Bsp.: http://onffhb.de/meshviewer/#!v:m;n:60e32776e3e8 vs. http://marklohe-jam-buero.nodes.ffhb.de