Re: [OpenWrt-Devel] [RFC openwrt-routing] batman-adv: Split batadv proto in meshif and hardif part
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- agree on the current mess, and congratulations on working on it :) have you considered, to simplify backwards compatibility, to keep proto "batadv" as it currently is (hardif) and naming "batadv_mesh" the new proto? Am 24. Februar 2019 13:51:13 GMT-03:00 schrieb Sven Eckelmann : >batman-adv allows to configure three different objects: > >* batadv hardif > > - network interface used by batadv meshif to transport the batman-adv >packets > - its master interface is set to the batadv meshif > >* batadv (meshif/softif) > > - virtual interface that emulates a normal 802.3 interface on top > - encapsulates traffic and forwards it via the batadv hardifs > >* batadv vlan > > - potential VLAN ID on top of batadv meshif > - allows filtering of traffic from specific VIDs > >While batadv vlan objects were already represented as an own proto >"batadv_vlan", the batadv meshif could never be fully configured using >/etc/config/network. Instead, parts of its configuration were stored in >/etc/config/batman_adv and some in the interfaces with the "batadv" >proto. > >To increase the confusion, the "batadv" proto wasn't used to define the >batadv meshif but to identify batadv (slave) hardifs. The batman-adv >meshifs were also never created directly but only when a hardif was >configured. The actual modification of the configuration settings was >then >applied using a hotplug script hack. The batadv meshif network >interface >could therefore only be created when an hardif was available and not >manipulated with ifup/ifdown. Also `/etc/init.d/network reload` didn't >modify the batadv meshif interface configuration correctly. > >The "batadv" is now renamed to "batadv_hardif" and a new "batadv" proto >is >used to configure the main (meshif) network interface with all its >configuration. > >A simple network configuration with WiFi & ethernet interfaces and >static >IP on top of bat0 would look like: > > # batadv meshif bat0 > config interface 'bat0' > option proto 'batadv' > option routing_algo 'BATMAN_IV' > option aggregated_ogms 1 > option ap_isolation 0 > option bonding 0 > option fragmentation 1 > #option gw_bandwidth '1/2000' > option gw_mode 'off' > #option gw_sel_class 20 > option log_level 0 > option orig_interval 1000 > option bridge_loop_avoidance 1 > option distributed_arp_table 1 > option multicast_mode 1 > option network_coding 0 > option hop_penalty 30 > option isolation_mark '0x/0x' > ># add *single* wifi-iface with network bat0_hardif_wlan as hardif to >bat0 > config interface 'bat0_hardif_wlan' > option mtu '1536' > option proto 'batadv_hardif' > option master 'bat0' > # option ifname is filled out by the wifi-iface > > # add eth0 as hardif to bat0 > config interface 'bat0_hardif_eth0' > option proto 'batadv_hardif' > option master 'bat0' > option ifname 'eth0' > option mtu '1536' > > # configure IP on bat0 > config interface 'bat0_lan' > option ifname 'bat0' > option proto 'static' > option ipaddr '192.168.1.1' > option netmask '255.255.255.0' > option ip6assign '60' > >Signed-off-by: Sven Eckelmann >--- >Cc: Matthias Schiffer >Cc: openwrt-devel@lists.openwrt.org >Cc: Gui Iribarren >Cc: Moritz Warning > >Changes depend on https://github.com/openwrt-routing/packages/pull/451 >--- > batman-adv/Makefile | 2 +- > batman-adv/files/etc/config/batman-adv| 20 > .../files/etc/hotplug.d/net/99-batman-adv | 12 -- > .../etc/uci-defaults/99-migrate-batadv_hardif | 97 +++ > batman-adv/files/lib/batman-adv/config.sh | 69 --- > batman-adv/files/lib/netifd/proto/batadv.sh | 112 +++--- > .../files/lib/netifd/proto/batadv_hardif.sh | 40 +++ > 7 files changed, 235 insertions(+), 117 deletions(-) > delete mode 100644 batman-adv/files/etc/config/batman-adv > delete mode 100644 batman-adv/files/etc/hotplug.d/net/99-batman-adv >create mode 100755 >batman-adv/files/etc/uci-defaults/99-migrate-batadv_hardif > delete mode 100644 batman-adv/files/lib/batman-adv/config.sh > create mode 100755 batman-adv/files/lib/netifd/proto/batadv_hardif.sh > >diff --git a/batman-adv/Makefile b/batman-adv/Makefile >index 82af6c7..b250888 100644 >--- a/batman-adv/Makefile >+++ b/batman-adv/Makefile >@@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk > PKG_NAME:=batman-adv > > PKG_VERSION:=2019.0 >-PKG_RELEASE:=2 >+PKG_RELEASE:=3 >PKG_HASH:=3e97d8a771cdbd7b2df42c52b88e071eaa58b5d28eb4e17a4b13b6698debbdc0 > > PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz >diff --git
[OpenWrt-Devel] RFC: merge LibreMesh packages into OpenWrt?
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hello folks, we're always looking for ways to get LibreMesh "closer to upstream", and one (old) idea is merging somehow our packages into OpenWrt. (i remember briefly talking this with jow at battlemeshv8 in Porto, but in the end, we lime-devs never actually looked up on how that would happen, until now) Currently we maintain a custom feed git repo at https://github.com/libremesh/lime-packages and what we would like to achieve in the end is that those packages become available in the official downloads.openwrt.org servers, basically. as far as i understand, we have two options (in decreasing order of desirability): 1) make a proposal (PR against this[0]) to include a new feed in feeds.conf.default, uncommented so that the packages inside are by default compiled and published along with other packages (luci, routing, telephony...) 2) alternatively, make a series of pull requests adding each of "our" packages to the standard "packages" feed https://git.openwrt.org/feed/packages.git is there any other option i'm missing, or caveat regarding those two that would help us decide? (i.e. would a PR against feeds.conf.default be acceptable?) [0]: https://github.com/openwrt/openwrt/blob/master/feeds.conf.default --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
