Feature #373: Add configuration interface for hardif settings - batctl - Open Mesh

Actions

Copy link

Feature #373

closed

Add configuration interface for hardif settings

Added by Sven Eckelmann over 5 years ago. Updated over 5 years ago.

Status:

Closed

Priority:

Normal

Assignee:

batman-adv developers

Target version:

batman-adv - 2019.3

Start date:

02/25/2019

Due date:

% Done:

Estimated time:

Description

Following two commits introduced per hardif settings in batman-adv but never exposed the netlink or sysfs interface via batctl:

a4b88af77e28 ("batman-adv: ELP - adding basic infrastructure")
c513176e4b7a ("batman-adv: add throughput override attribute to hard_ifaces")

We need something to configure them via batctl to make sure that users can actually change them when sysfs is going away. This will also be used later by OpenWrt to have this configuration in the network configuration.

I don't have a good idea how this command interface should look like but here are two possible ways ("[...] mark the optional argument that is only required when you set the value"):

batctl -m "${batadv_meshif}" hardif "${hardif}" elp_interval ["${elp_interval}"]
batctl -m "${batadv_meshif}" hardif "${hardif}" throughput_override ["${throughput_override}"]

batctl -m "${batadv_meshif}" elp_interval "${hardif}" ["${elp_interval}"]
batctl -m "${batadv_meshif}" throughput_override "${hardif}" ["${throughput_override}"]

Please provide some input regarding the format which we should use here.

Actions

Copy link

Updated by Sven Eckelmann over 5 years ago

This document here must also be updated when this is implemented: Tweaking

Actions

Copy link

Updated by Sven Eckelmann over 5 years ago

Status changed from New to Resolved
Target version set to 2019.3

Series is available at https://patchwork.open-mesh.org/project/b.a.t.m.a.n./list/?series=270

Actions

Copy link

Updated by Sven Eckelmann over 5 years ago

Status changed from Resolved to In Progress

There is now some controversial about the stuff which I tried to get answered beforehand (4 months ago) in this ticket. https://lists.open-mesh.org/mailman3/hyperkitty/list/b.a.t.m.a.n@lists.open-mesh.org/message/MIHNCVSL4FQM22BZCISC5PF77NRVVS75/

I have therefore marked the patches as "changes requested" and now want some actual information how this should be implemented.

Actions

Copy link

Updated by Sven Eckelmann over 5 years ago

Here are discussion log from IRC

[2019-06-17 02:49:02] <marec> ecsv: what do you mean with tree structured ?
[2019-06-17 02:49:43] <marec> something similar to iw and iproute ?
[2019-06-17 02:50:29] <marec> T_X: as sven pointed out, the 'hardif' term has been around since forever
[2019-06-17 02:53:04] <marec> T_X: I don't mind renaming to something else if there are good ideas (slave isn't too bad), however - are you ready to make that happen everywhere ?
[2019-06-17 02:53:58] <marec> T_X: all docs (manpages, wiki, articles, etc) and tool (batctl openwrt init, etc) would need to be touched
[2019-06-17 02:54:18] <marec> ideally at the same time otherwise we'd end up with slaves and hardifs ..
[2019-06-17 02:55:24] <marec> $ batctl [-m <mesh-iface>|-s <slave-iface>] multicast_fanout <int> <<<<< is that a real case ? mcast_fanout exist per hardif and per mesh ?
[2019-06-17 07:59:56] <ecsv> marec: yes, something similar to what iw does. it starts with batctl (of course) as root node. and then you have the nodes for the different object types
[2019-06-17 07:59:56] <ecsv> hardif (please discuss a different term when you prefer something - shorter or more specific)
[2019-06-17 07:59:56] <ecsv> meshif (please discuss a different term when you prefer something - shorter or more specific)
[2019-06-17 07:59:56] <ecsv> vlan
[2019-06-17 08:00:20] <ecsv> and after that you can specify the actual thing you are talking about. for example for hardif: eth0
[2019-06-17 08:00:27] <ecsv> and for meshif something like bat0
[2019-06-17 08:00:33] <marec> right
[2019-06-17 08:00:36] <ecsv> or for vlan something like bat08
[2019-06-17 08:00:39] <ecsv> bat0.8
[2019-06-17 08:00:52] <ecsv> and after that are the commands which are allowed for this specific object type
[2019-06-17 08:00:59] <ecsv> ping for meshif
[2019-06-17 08:01:03] <ecsv> or ap_isolation for vlan
[2019-06-17 08:01:05] <ecsv> and so on
[2019-06-17 08:01:13] <marec> batctl could treat batX like iw treats 'phyX' ?
[2019-06-17 08:01:24] <marec> phyX is not always mandatory to type
[2019-06-17 08:01:36] <marec> only when the situation is not obvious
[2019-06-17 08:01:36] <ecsv> yes
[2019-06-17 08:02:32] <marec> ok, I got that and I like it
[2019-06-17 08:02:45] <marec> is there something T_X does not agree with ?
[2019-06-17 08:03:21] <ecsv> he seems to have prefered this -s to specify the slave/hardif interface
[2019-06-17 08:03:43] <ecsv> (at least I understood him this way)
[2019-06-17 08:04:16] <ecsv> and then there is the open question how we actually name the hardif/slave or meshif/... things
[2019-06-17 09:30:29] <ordex> I also like the tree structured command. when we start adding more flags the command gets more complicated and harder to understand imho
[2019-06-17 09:32:04] <ordex> therefore better the "ip route style", rather than having more -s/-m/-chachacha

Actions

Copy link