[Interop-dev] hello new subscribers

[Matthias Schiffer]

On 05/31/2015 03:09 PM, Nemesis wrote:
> On 05/26/2015 02:16 AM, Matthias Schiffer wrote:
>> On 05/19/2015 06:18 PM, L. Aaron Kaplan wrote:
> [...]
>>> But... this being said, now it's your turn for the new members to this list to speak up!
>>> Do you want to briefly introduce yourselves?
>>> What brought you here? What motivates you? What do you want to see done? What do you want to contribute?
>>>
>>>
>>> Thanks,
>>> Aaron.
>> Hello interop-dev!
>>
>> I'm Matthias (NeoRaider on Github / in IRC) from the Freifunk project of
>> Lübeck, Germany. Frederico suggested me to join the list at the Wireless
>> Community Weekend in Berlin last week.
>>
>> I'm one of the core developers of the Gluon firmware framework used by
>> many German Freifunk communities. As we're also developing visualization
>> systems in and around Gluon, we're in the constant process of inventing,
>> refining and extending information formats like those NetJSON tries to
>> define. The other Gluon core developer Nils, who has joined this list as
>> well, is the original author of the ffmap and MeshViewer projects used
>> by many Freifunk communities for visualization. Long story short, we'd
>> love to make our tools more interoperable by making Gluon emit NetJSON
>> and add NetJSON support to ffmap/MeshViewer :)
> 
> Welcome you all, I think we are all very happy to have you on board.
> 
>> You can see parts of our current data formats at [1] and [2] (look for
>> the entry "68:72:51:20:db:cc" to see the current version, most nodes
>> aren't updated to the latest Gluon version yet). Some information in our
>> current format is redundant as we're trying to provide backwards
>> compatiblity for at least a few Gluon versions. We're also currently
>> replacing the alfred/batadv-vis-internal topology information format
>> with an own extensible JSON format (to make it independent of alfred and
>> generally more flexible).
>>
>> As you can see, many parts of our "nodeinfo" and "statistics" are
>> already similar to the "Network Device Configuration" and "Device
>> Monitoring" NetJSON objects. For the parts that aren't, I hope we'll
>> find time soon to think up proposals how to extend NetJSON to support
>> all of our usecases :)
>>
>> Matthias
>>
>>
>> [1] http://metameute.de/~freifunk/alfred/nodeinfo.json
>> [2] http://metameute.de/~freifunk/alfred/statistics.json
> 
> Amazing to notice you came up with a format that is not too different
> from the NetworkDevice, which is a synthesis of the data one can get
> from ubus, nodewatcher-agent, openwifi map and the nodeshot API.
> 
> Well the next thing is to start using it in the real world. We'll be
> doing that in the next couple of months, hopefully if other people do it
> we can gather feedback and talk about it in person at the battlemesh and
> CCC.
> 
> Federico
> 

We now have the first few nodes using our new topology format online.
The current output can be found at

http://metameute.de/~freifunk/alfred/neighbours.json

As you can see, our format has some important differences from the
Network Graph format in NetJSON: each "record" only shows the topology
as seen from a single node, all nodes' records together are required to
see the whole topology. This difference is natural as in the metrics we
use (batman-adv TQ, WLAN signal/noise levels), only information about a
node's direct neighbourhood is available. It doesn't match the Network
Routes format well either, as our format doesn't contain information
about the chosen routes to distant nodes either.

Some other notes about differences between our formats and the NetJSON
draft:

* Our formats always contain a node_id attribute, so for
statistics/neighbours the corresponding nodeinfo can be found
* The Network Graph format doesn't contain any information about the
specific interfaces a link belongs to on nodes with multiple interfaces,
that might be especially interesting when there are different interface
types (different WLAN bands/channels, wired, VPN tunnel, ...)
* I find it a bit strange that Network Routes can be included in a
Device Configuration. Is this supposed to contain static routes only?
Otherwise, including this into Device Monitoring would be more appropriate
* I won't go much into detail about differences between nodeinfo and
Device Configuration. Much information in the Device Configuration
example looks much too verbose in my eyes. Especially the interface
configuration parts contain many attributes that aren't very useful
(have just been copied from the netifd output?)
* The traffic information in our statistics format is supplied by
batman-adv over the ethtool interface. It contains some interesting data
like the amount of management traffic, and discerns forwarded and
locally transmitted/received traffic, but no interface-specific information
* The monitoring format shouldn't contain any information about
interfaces not used for meshing. This is important so "monitoring"
doesn't turn into "surveillance" when someone uses a single OpenWrt
system both as a community mesh node and a private router (which is
something we plan to support with Gluon some time in the future)

Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.funkfeuer.at/pipermail/interop-dev/attachments/20150531/64184754/attachment.sig>