[v3,3/3] gateway.d: Add scripts for network configuration

Submitted by Fabian Blaese on April 23, 2019, 4:09 p.m.

Details

Message ID 20190423160908.28420-3-fabian@blaese.de
State Superseded
Headers show

Commit Message

Fabian Blaese April 23, 2019, 4:09 p.m. 
This adds scripts to configure vlan and client network.
This also adds sysctl settings to enable forwarding.

Note:
Devices specific properties are sourced from fff-network package.
This creates a dependency on fff-boardname and fff-network.
These properties should be located elsewhere in the future.

Signed-off-by: Fabian Bläse <fabian@blaese.de>
---
Changes in v3:
- Rename 10-vlan to 20-vlan
- Rename 20-network-client to 30-network-client
- Source necessary uci functions and board properties
- Add dependency on fff-boardname and fff-network
---
 src/packages/fff/fff-gateway/Makefile         |  1 +
 .../fff-gateway/files/etc/gateway.d/20-vlan   | 47 ++++++++++++
 .../files/etc/gateway.d/30-network-client     | 71 +++++++++++++++++++
 .../files/etc/sysctl.d/60-fff-gateway.conf    |  5 ++
 4 files changed, 124 insertions(+)
 create mode 100644 src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan
 create mode 100644 src/packages/fff/fff-gateway/files/etc/gateway.d/30-network-client
 create mode 100644 src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf

Patch hide | download patch | download mbox 

diff --git a/src/packages/fff/fff-gateway/Makefile b/src/packages/fff/fff-gateway/Makefile
index 7c1dd55..f9ef8cc 100644
--- a/src/packages/fff/fff-gateway/Makefile
+++ b/src/packages/fff/fff-gateway/Makefile
@@ -13,6 +13,7 @@  define Package/fff-gateway
 	CATEGORY:=Freifunk
 	TITLE:= Freifunk-Franken gateway configuration
 	URL:=https://www.freifunk-franken.de
+	DEPENDS:=+fff-boardname +fff-network
 endef
 
 define Package/fff-gateway/description
diff --git a/src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan b/src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan
new file mode 100644
index 0000000..c789df3
--- /dev/null
+++ b/src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan
@@ -0,0 +1,47 @@ 
+#load uci functions
+. /lib/functions.sh
+
+#load board specific properties
+BOARD="$(uci get board.model.name)"
+. /etc/network.$BOARD
+
+
+configure() {
+	add_vlan() {
+		local vlan="$1"
+		local ports=$(uci get gateway.$vlan.ports)
+		local name="$SWITCHDEV"_$vlan
+
+		uci set network.$name='switch_vlan'
+		uci set network.$name.device="$(uci get network.$SWITCHDEV.name)"
+		uci set network.$name.vlan="$vlan"
+		uci set network.$name.ports="$CPUPORT $ports"
+	}
+
+	remove_vlan() {
+		local name="$1"
+
+		local switchdev=$(echo $name | cut -d_ -f1)
+		local vlan=$(echo $name | cut -d_ -f2)
+
+		# only remove vlans not present in gateway config
+		if ! uci -q get gateway.$vlan > /dev/null; then
+			# remove switch_vlan
+			uci del network.$name
+		fi
+	}
+
+	config_load network
+	config_foreach remove_vlan switch_vlan
+
+	config_load gateway
+	config_foreach add_vlan vlan
+}
+
+apply() {
+	uci commit network
+}
+
+revert() {
+	uci revert network
+}
diff --git a/src/packages/fff/fff-gateway/files/etc/gateway.d/30-network-client b/src/packages/fff/fff-gateway/files/etc/gateway.d/30-network-client
new file mode 100644
index 0000000..3ccc14f
--- /dev/null
+++ b/src/packages/fff/fff-gateway/files/etc/gateway.d/30-network-client
@@ -0,0 +1,71 @@ 
+#load board specific properties
+BOARD="$(uci get board.model.name)"
+. /etc/network.$BOARD
+
+
+configure() {
+	# ipaddr
+	#remove old ipaddr
+	uci -q del network.mesh.ipaddr
+	#set new ipaddr
+	if ipaddr=$(uci -q get gateway.@client[0].ipaddr); then
+		for ip in $ipaddr; do
+			uci add_list network.mesh.ipaddr=$ip
+		done
+	else
+		echo "WARNING: No client ipaddr set!"
+	fi
+	#put interface routes from set addresses into fff table
+	uci set network.mesh.ip4table='fff'
+
+	# ip6addr
+	#remove old ip6addr
+	for ip in $(uci get network.mesh.ip6addr); do
+		if echo "$ip" | grep -v -e "fdff:" -e "fe80::1/64" > /dev/null; then
+			uci del_list network.mesh.ip6addr="$ip"
+		fi
+	done
+	#set new ip6addr
+	if ip6addr=$(uci -q get gateway.@client[0].ip6addr); then
+		for ip in $ip6addr; do
+			uci add_list network.mesh.ip6addr=$ip
+		done
+	else
+		echo "WARNING: No client ip6addr set!"
+	fi
+	#put interface routes from set addresses into fff table
+	uci set network.mesh.ip6table='fff'
+
+	# dhcp
+	uci -q del dhcp.mesh.start
+	uci -q del dhcp.mesh.limit
+	if dhcp_start=$(uci -q get gateway.@client[0].dhcp_start); then
+		uci set dhcp.mesh=dhcp
+		uci set dhcp.mesh.interface=mesh
+		uci set dhcp.mesh.start=$dhcp_start
+		uci set dhcp.mesh.limit=$(uci -q get gateway.@client[0].dhcp_limit)
+	else
+		echo "WARNING: No DHCP range start and/or limit set!"
+	fi
+
+	# set interface
+	#remove all eth interfaces
+	ifaces=$(uci get network.mesh.ifname | sed -e "s/ *eth\d\.\d//g" -e "s/ *eth\d//g" -e "s/^ //")
+	if vlan=$(uci -q get gateway.@client[0].vlan); then
+		uci set network.mesh.ifname="${SWITCHDEV}.$vlan $ifaces"
+	elif iface=$(uci -q get gateway.@client[0].iface); then
+		uci set network.mesh.ifname="$iface $ifaces"
+	else
+		echo "WARNING: No Interface for client specified"
+	fi
+}
+
+apply() {
+	uci commit network
+	uci commit dhcp
+}
+
+revert() {
+	uci revert network
+	uci revert dhcp
+}
diff --git a/src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf b/src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf
new file mode 100644
index 0000000..62bda1b
--- /dev/null
+++ b/src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf
@@ -0,0 +1,5 @@ 
+# Enable forwarding
+net.ipv4.conf.all.forwarding=1
+net.ipv4.ip_forward=1
+net.ipv6.conf.all.forwarding=1
+net.ipv6.conf.default.forwarding=1

Comments

Adrian Schmutzler April 23, 2019, 10:33 p.m. 
Hallo Fabian,

wenn ich mir ansehe, was dieser Patch so tut, möchte ich ihn eigentlich ungern so in die Firmware tun, sondern lieber auf die neue Netzwerk-Config umbauen.

Rein formal ist im Moment zwar nur der CPUPORT noch ungeklärt. Auf der anderen Seite warte ich aber auch nur noch auf das Review von Robert zwecks Patch 3/14, dann hätte ich das applied.

Bei diesem Patch wäre es dann so, dass man den applied und dann relativ gleich danach massiv umbaut. Das finde nicht unbedingt erstrebenswert.

Wenn du keine Lust hast, das selber umzubauen, könnte ich auch einen RFC-Patch schicken, der die notwendigen Änderungen enthält. Das meiste sollte ich ja ohnehin schon mal überlegt/vorgeschlagen haben.

Beste Grüße

Adrian



> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of
> Fabian Bläse
> Sent: Dienstag, 23. April 2019 18:09
> To: franken-dev@freifunk.net
> Subject: [PATCH v3 3/3] gateway.d: Add scripts for network configuration
> 
> This adds scripts to configure vlan and client network.
> This also adds sysctl settings to enable forwarding.
> 
> Note:
> Devices specific properties are sourced from fff-network package.
> This creates a dependency on fff-boardname and fff-network.
> These properties should be located elsewhere in the future.
> 
> Signed-off-by: Fabian Bläse <fabian@blaese.de>
> ---
> Changes in v3:
> - Rename 10-vlan to 20-vlan
> - Rename 20-network-client to 30-network-client
> - Source necessary uci functions and board properties
> - Add dependency on fff-boardname and fff-network
> ---
>  src/packages/fff/fff-gateway/Makefile         |  1 +
>  .../fff-gateway/files/etc/gateway.d/20-vlan   | 47 ++++++++++++
>  .../files/etc/gateway.d/30-network-client     | 71 +++++++++++++++++++
>  .../files/etc/sysctl.d/60-fff-gateway.conf    |  5 ++
>  4 files changed, 124 insertions(+)
>  create mode 100644 src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan
>  create mode 100644 src/packages/fff/fff-gateway/files/etc/gateway.d/30-
> network-client
>  create mode 100644 src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-
> gateway.conf
> 
> diff --git a/src/packages/fff/fff-gateway/Makefile b/src/packages/fff/fff-
> gateway/Makefile
> index 7c1dd55..f9ef8cc 100644
> --- a/src/packages/fff/fff-gateway/Makefile
> +++ b/src/packages/fff/fff-gateway/Makefile
> @@ -13,6 +13,7 @@ define Package/fff-gateway
>  	CATEGORY:=Freifunk
>  	TITLE:= Freifunk-Franken gateway configuration
>  	URL:=https://www.freifunk-franken.de
> +	DEPENDS:=+fff-boardname +fff-network
>  endef
> 
>  define Package/fff-gateway/description
> diff --git a/src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan
> b/src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan
> new file mode 100644
> index 0000000..c789df3
> --- /dev/null
> +++ b/src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan
> @@ -0,0 +1,47 @@
> +#load uci functions
> +. /lib/functions.sh
> +
> +#load board specific properties
> +BOARD="$(uci get board.model.name)"
> +. /etc/network.$BOARD
> +
> +
> +configure() {
> +	add_vlan() {
> +		local vlan="$1"
> +		local ports=$(uci get gateway.$vlan.ports)
> +		local name="$SWITCHDEV"_$vlan
> +
> +		uci set network.$name='switch_vlan'
> +		uci set network.$name.device="$(uci get
> network.$SWITCHDEV.name)"
> +		uci set network.$name.vlan="$vlan"
> +		uci set network.$name.ports="$CPUPORT $ports"
> +	}
> +
> +	remove_vlan() {
> +		local name="$1"
> +
> +		local switchdev=$(echo $name | cut -d_ -f1)
> +		local vlan=$(echo $name | cut -d_ -f2)
> +
> +		# only remove vlans not present in gateway config
> +		if ! uci -q get gateway.$vlan > /dev/null; then
> +			# remove switch_vlan
> +			uci del network.$name
> +		fi
> +	}
> +
> +	config_load network
> +	config_foreach remove_vlan switch_vlan
> +
> +	config_load gateway
> +	config_foreach add_vlan vlan
> +}
> +
> +apply() {
> +	uci commit network
> +}
> +
> +revert() {
> +	uci revert network
> +}
> diff --git a/src/packages/fff/fff-gateway/files/etc/gateway.d/30-network-client
> b/src/packages/fff/fff-gateway/files/etc/gateway.d/30-network-client
> new file mode 100644
> index 0000000..3ccc14f
> --- /dev/null
> +++ b/src/packages/fff/fff-gateway/files/etc/gateway.d/30-network-client
> @@ -0,0 +1,71 @@
> +#load board specific properties
> +BOARD="$(uci get board.model.name)"
> +. /etc/network.$BOARD
> +
> +
> +configure() {
> +	# ipaddr
> +	#remove old ipaddr
> +	uci -q del network.mesh.ipaddr
> +	#set new ipaddr
> +	if ipaddr=$(uci -q get gateway.@client[0].ipaddr); then
> +		for ip in $ipaddr; do
> +			uci add_list network.mesh.ipaddr=$ip
> +		done
> +	else
> +		echo "WARNING: No client ipaddr set!"
> +	fi
> +	#put interface routes from set addresses into fff table
> +	uci set network.mesh.ip4table='fff'
> +
> +	# ip6addr
> +	#remove old ip6addr
> +	for ip in $(uci get network.mesh.ip6addr); do
> +		if echo "$ip" | grep -v -e "fdff:" -e "fe80::1/64" > /dev/null; then
> +			uci del_list network.mesh.ip6addr="$ip"
> +		fi
> +	done
> +	#set new ip6addr
> +	if ip6addr=$(uci -q get gateway.@client[0].ip6addr); then
> +		for ip in $ip6addr; do
> +			uci add_list network.mesh.ip6addr=$ip
> +		done
> +	else
> +		echo "WARNING: No client ip6addr set!"
> +	fi
> +	#put interface routes from set addresses into fff table
> +	uci set network.mesh.ip6table='fff'
> +
> +	# dhcp
> +	uci -q del dhcp.mesh.start
> +	uci -q del dhcp.mesh.limit
> +	if dhcp_start=$(uci -q get gateway.@client[0].dhcp_start); then
> +		uci set dhcp.mesh=dhcp
> +		uci set dhcp.mesh.interface=mesh
> +		uci set dhcp.mesh.start=$dhcp_start
> +		uci set dhcp.mesh.limit=$(uci -q get
> gateway.@client[0].dhcp_limit)
> +	else
> +		echo "WARNING: No DHCP range start and/or limit set!"
> +	fi
> +
> +	# set interface
> +	#remove all eth interfaces
> +	ifaces=$(uci get network.mesh.ifname | sed -e "s/ *eth\d\.\d//g" -e "s/
> *eth\d//g" -e "s/^ //")
> +	if vlan=$(uci -q get gateway.@client[0].vlan); then
> +		uci set network.mesh.ifname="${SWITCHDEV}.$vlan $ifaces"
> +	elif iface=$(uci -q get gateway.@client[0].iface); then
> +		uci set network.mesh.ifname="$iface $ifaces"
> +	else
> +		echo "WARNING: No Interface for client specified"
> +	fi
> +}
> +
> +apply() {
> +	uci commit network
> +	uci commit dhcp
> +}
> +
> +revert() {
> +	uci revert network
> +	uci revert dhcp
> +}
> diff --git a/src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf
> b/src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf
> new file mode 100644
> index 0000000..62bda1b
> --- /dev/null
> +++ b/src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-gateway.conf
> @@ -0,0 +1,5 @@
> +# Enable forwarding
> +net.ipv4.conf.all.forwarding=1
> +net.ipv4.ip_forward=1
> +net.ipv6.conf.all.forwarding=1
> +net.ipv6.conf.default.forwarding=1
> --
> 2.21.0
Fabian Blaese April 24, 2019, 8:30 a.m. 
On 24.04.19 00:33, Adrian Schmutzler wrote:
> Hallo Fabian,
> 
> wenn ich mir ansehe, was dieser Patch so tut, möchte ich ihn eigentlich ungern so in die Firmware tun, sondern lieber auf die neue Netzwerk-Config umbauen.
So genau hab ich mir die neue Netzwerk-Config noch nicht angesehen, aber abgesehen vom CPUPORT (der da dummerweise grade in dem Package drin ist) ist das doch komplett unabhängig davon..?

> Rein formal ist im Moment zwar nur der CPUPORT noch ungeklärt. Auf der anderen Seite warte ich aber auch nur noch auf das Review von Robert zwecks Patch 3/14, dann hätte ich das applied.
> 
> Bei diesem Patch wäre es dann so, dass man den applied und dann relativ gleich danach massiv umbaut. Das finde nicht unbedingt erstrebenswert.
So kommt man aber wenigstens vorwärts.
Bitte lass uns da jetzt nicht nochmal irgendwas neues dazwischen mischen, was dieses Patchset u.U. nochmal etwas durcheinander bringt, sondern eins nach dem anderen angehen.
Sonst wird die Gatewayfirmware nie fertig.

Insgesamt stützt sich die Gateway Variante nur auf das configurenetwork für die initiale Interface-Konfiguration. (fdff, etc.)
Das braucht es imho aber eigentlich gar nicht, zumal es später sowieso von der eigenen Konfiguration überschrieben wird.
Wenn man nichts vorher konfiguriert, müsste der Router glaube ich auf jedem Interface mit seiner Link Local Adresse erreichbar sein.

Gruß
Fabian
Adrian Schmutzler April 24, 2019, 11:10 a.m. 
Hallo Fabian,

 

mein Patchset schafft die komplette configurenetwork und die network.* Files ab, worüber ich ausgesprochen glücklich bin und was ich für einen großen Fortschritt halte.

 

Das mit dem vorwärts kommen ist halt so eine Sache:

Dieser Patch hier lag zuletzt einen Monat rum, bevor die v3 kam. Das ist kein Vorwurf, aber die Gatewayfirmware als Ganzes ist ja unbestreitbar ein langfristiges Projekt.

Ich finde es daher nicht zielführend, jetzt für einen undefinierten, längeren Zeitraum jegliche Umbauten quasi zu verbieten, nur damit für das Einbauen der Gatewayfirmware weniger Aufwand betrieben werden muss. Weiterhin ist es ja so, dass die Umstellung für fff-network fertig ist, man also in jedem Fall den Gatewayfirmware-Patch dann direkt nach dem Merge des fff-network nochmal umbauen müsste. Das würde ich es schon lieber „gleich richtig“ machen.

 

(Ich könnte ja jetzt auch beleidigt sein und zum Thema „eines nach dem anderen“ darauf hinweisen, dass man mir nach dem letzten Release den configurenetwork-Patch in Aussicht gestellt hat, auf den ich insgesamt über ein Jahr warte.)

 

Gerade beim Einführen der Gatewayfirmware in das offizielle Repo erhoffe ich mir zudem, dass man dabei gerade versucht, das Ganze dann auch langfristig durchdacht zu machen (zum Beispiel sowas wie das gateway.d …), und nicht einfach alles reinwirft, damit es erst mal da ist. Sonst kann ja auch jeder weiter lokal vor sich hinpfriemeln. Klar kann man auch mal einen Kompromiss machen, aber jetzt da ein überholtes System neu einzubauen, nur um schneller fertig zu sein, wissend, dass man es dann gleich wieder umbauen muss, finde ich nicht zielführend.

 

Zuletzt sei noch angemerkt, dass es ja auch gar nicht so schwierig ist, den einen betroffenen Patch hier jetzt gleich umzubauen, sodass er zum neuen System passt. Es geht im Prinzip nur um den einen Patch, dazu kommt dann vll. noch eine Zeile bei den babel-Sachen und ggf. beim Hoodfile, aber das ist alles überschaubar. Auch dein VLAN-Setup aus der /etc/config/gateway, was ja so oder so größtenteils redundant zur initialen Konfiguration ist, wird genauso funktionieren.

 

Ich werde auch gerne den Fortschritt der Gatewayfirmware beschleunigen und den Patch entsprechend überarbeiten, dass er zum neuen System passt. Die Patches 1/3 und 2/3 sind ja soweit fertig.

 

Beste Grüße

 

Adrian

 

From: Fabian Bläse [mailto:fabian@blaese.de] 
Sent: Mittwoch, 24. April 2019 10:30
To: Adrian Schmutzler <mail@adrianschmutzler.de>; franken-dev@freifunk.net
Subject: Re: [PATCH v3 3/3] gateway.d: Add scripts for network configuration

 

 

On 24.04.19 00:33, Adrian Schmutzler wrote: 
> Hallo Fabian, 
> 
> wenn ich mir ansehe, was dieser Patch so tut, möchte ich ihn eigentlich ungern so in die Firmware tun, sondern lieber auf die neue Netzwerk-Config umbauen.

So genau hab ich mir die neue Netzwerk-Config noch nicht angesehen, aber abgesehen vom CPUPORT (der da dummerweise grade in dem Package drin ist) ist das doch komplett unabhängig davon..?

> Rein formal ist im Moment zwar nur der CPUPORT noch ungeklärt. Auf der anderen Seite warte ich aber auch nur noch auf das Review von Robert zwecks Patch 3/14, dann hätte ich das applied.

> 
> Bei diesem Patch wäre es dann so, dass man den applied und dann relativ gleich danach massiv umbaut. Das finde nicht unbedingt erstrebenswert.

So kommt man aber wenigstens vorwärts. 
Bitte lass uns da jetzt nicht nochmal irgendwas neues dazwischen mischen, was dieses Patchset u.U. nochmal etwas durcheinander bringt, sondern eins nach dem anderen angehen.

Sonst wird die Gatewayfirmware nie fertig. 

Insgesamt stützt sich die Gateway Variante nur auf das configurenetwork für die initiale Interface-Konfiguration. (fdff, etc.)

Das braucht es imho aber eigentlich gar nicht, zumal es später sowieso von der eigenen Konfiguration überschrieben wird.

Wenn man nichts vorher konfiguriert, müsste der Router glaube ich auf jedem Interface mit seiner Link Local Adresse erreichbar sein.

Gruß 
Fabian
Adrian Schmutzler April 24, 2019, 12:06 p.m. 
War einfacher umzubauen als gedacht ….

 

From: franken-dev [mailto:franken-dev-bounces@freifunk.net] On Behalf Of Adrian Schmutzler
Sent: Mittwoch, 24. April 2019 13:11
To: 'Fabian Bläse' <fabian@blaese.de>; franken-dev@freifunk.net
Subject: RE: [PATCH v3 3/3] gateway.d: Add scripts for network configuration

 

Hallo Fabian,

 

mein Patchset schafft die komplette configurenetwork und die network.* Files ab, worüber ich ausgesprochen glücklich bin und was ich für einen großen Fortschritt halte.

 

Das mit dem vorwärts kommen ist halt so eine Sache:

Dieser Patch hier lag zuletzt einen Monat rum, bevor die v3 kam. Das ist kein Vorwurf, aber die Gatewayfirmware als Ganzes ist ja unbestreitbar ein langfristiges Projekt.

Ich finde es daher nicht zielführend, jetzt für einen undefinierten, längeren Zeitraum jegliche Umbauten quasi zu verbieten, nur damit für das Einbauen der Gatewayfirmware weniger Aufwand betrieben werden muss. Weiterhin ist es ja so, dass die Umstellung für fff-network fertig ist, man also in jedem Fall den Gatewayfirmware-Patch dann direkt nach dem Merge des fff-network nochmal umbauen müsste. Das würde ich es schon lieber „gleich richtig“ machen.

 

(Ich könnte ja jetzt auch beleidigt sein und zum Thema „eines nach dem anderen“ darauf hinweisen, dass man mir nach dem letzten Release den configurenetwork-Patch in Aussicht gestellt hat, auf den ich insgesamt über ein Jahr warte.)

 

Gerade beim Einführen der Gatewayfirmware in das offizielle Repo erhoffe ich mir zudem, dass man dabei gerade versucht, das Ganze dann auch langfristig durchdacht zu machen (zum Beispiel sowas wie das gateway.d …), und nicht einfach alles reinwirft, damit es erst mal da ist. Sonst kann ja auch jeder weiter lokal vor sich hinpfriemeln. Klar kann man auch mal einen Kompromiss machen, aber jetzt da ein überholtes System neu einzubauen, nur um schneller fertig zu sein, wissend, dass man es dann gleich wieder umbauen muss, finde ich nicht zielführend.

 

Zuletzt sei noch angemerkt, dass es ja auch gar nicht so schwierig ist, den einen betroffenen Patch hier jetzt gleich umzubauen, sodass er zum neuen System passt. Es geht im Prinzip nur um den einen Patch, dazu kommt dann vll. noch eine Zeile bei den babel-Sachen und ggf. beim Hoodfile, aber das ist alles überschaubar. Auch dein VLAN-Setup aus der /etc/config/gateway, was ja so oder so größtenteils redundant zur initialen Konfiguration ist, wird genauso funktionieren.

 

Ich werde auch gerne den Fortschritt der Gatewayfirmware beschleunigen und den Patch entsprechend überarbeiten, dass er zum neuen System passt. Die Patches 1/3 und 2/3 sind ja soweit fertig.

 

Beste Grüße

 

Adrian

 

From: Fabian Bläse [mailto:fabian@blaese.de] 
Sent: Mittwoch, 24. April 2019 10:30
To: Adrian Schmutzler <mail@adrianschmutzler.de <mailto:mail@adrianschmutzler.de> >; franken-dev@freifunk.net <mailto:franken-dev@freifunk.net> 
Subject: Re: [PATCH v3 3/3] gateway.d: Add scripts for network configuration

 

 

On 24.04.19 00:33, Adrian Schmutzler wrote: 
> Hallo Fabian, 
> 
> wenn ich mir ansehe, was dieser Patch so tut, möchte ich ihn eigentlich ungern so in die Firmware tun, sondern lieber auf die neue Netzwerk-Config umbauen.

So genau hab ich mir die neue Netzwerk-Config noch nicht angesehen, aber abgesehen vom CPUPORT (der da dummerweise grade in dem Package drin ist) ist das doch komplett unabhängig davon..?

> Rein formal ist im Moment zwar nur der CPUPORT noch ungeklärt. Auf der anderen Seite warte ich aber auch nur noch auf das Review von Robert zwecks Patch 3/14, dann hätte ich das applied.

> 
> Bei diesem Patch wäre es dann so, dass man den applied und dann relativ gleich danach massiv umbaut. Das finde nicht unbedingt erstrebenswert.

So kommt man aber wenigstens vorwärts. 
Bitte lass uns da jetzt nicht nochmal irgendwas neues dazwischen mischen, was dieses Patchset u.U. nochmal etwas durcheinander bringt, sondern eins nach dem anderen angehen.

Sonst wird die Gatewayfirmware nie fertig. 

Insgesamt stützt sich die Gateway Variante nur auf das configurenetwork für die initiale Interface-Konfiguration. (fdff, etc.)

Das braucht es imho aber eigentlich gar nicht, zumal es später sowieso von der eigenen Konfiguration überschrieben wird.

Wenn man nichts vorher konfiguriert, müsste der Router glaube ich auf jedem Interface mit seiner Link Local Adresse erreichbar sein.

Gruß 
Fabian
Fabian Blaese April 24, 2019, 3:59 p.m. 
Hallo Adrian,

On 24.04.19 13:10, Adrian Schmutzler wrote:
> mein Patchset schafft die komplette configurenetwork und die network.* Files ab, worüber ich ausgesprochen glücklich bin und was ich für einen großen Fortschritt halte.
Ob ich das gut finde oder nicht kann ich jetzt grade nicht beantworten, da müsste ich erstmal deine Patches angucken. Sind ja immer 14! Stück.

> Das mit dem vorwärts kommen ist halt so eine Sache:
> 
> Dieser Patch hier lag zuletzt einen Monat rum, bevor die v3 kam. Das ist kein Vorwurf, aber die Gatewayfirmware als Ganzes ist ja unbestreitbar ein langfristiges Projekt.
> 
> Ich finde es daher nicht zielführend, jetzt für einen undefinierten, längeren Zeitraum jegliche Umbauten quasi zu verbieten, nur damit für das Einbauen der Gatewayfirmware weniger Aufwand betrieben werden muss. Weiterhin ist es ja so, dass die Umstellung für fff-network fertig ist, man also in jedem Fall den Gatewayfirmware-Patch dann direkt nach dem Merge des fff-network nochmal umbauen müsste. Das würde ich es schon lieber „gleich richtig“ machen.
Stimmt, das ist ärgerlich. Bin leider nicht früher dazu gekommen :-(

> (Ich könnte ja jetzt auch beleidigt sein und zum Thema „eines nach dem anderen“ darauf hinweisen, dass man mir nach dem letzten Release den configurenetwork-Patch in Aussicht gestellt hat, auf den ich insgesamt über ein Jahr warte.)
Könntest du, hättest damit aber dennoch irgendwie unrecht, denn dieses Patchset hat mit deinem letzten so gut wie nichts mehr zu tun...

> Gerade beim Einführen der Gatewayfirmware in das offizielle Repo erhoffe ich mir zudem, dass man dabei gerade versucht, das Ganze dann auch langfristig durchdacht zu machen (zum Beispiel sowas wie das gateway.d …), und nicht einfach alles reinwirft, damit es erst mal da ist. Sonst kann ja auch jeder weiter lokal vor sich hinpfriemeln. Klar kann man auch mal einen Kompromiss machen, aber jetzt da ein überholtes System neu einzubauen, nur um schneller fertig zu sein, wissend, dass man es dann gleich wieder umbauen muss, finde ich nicht zielführend.
Jo. Aber wenn wir uns an jedem Patch an Kleinigkeiten so lange aufhalten, bis es absolut perfekt ist, dann sitzen wir irgendwann mit einer v27 da, bei der dann keiner mehr überblickt, was eigentlich geändert wurde.
Wir sind noch relativ am Anfang des Entwicklungsprozesses "Gatewayfirmware", das wird schon noch etwas dauern, bis das fertig ist. Und bis dahin wird sich sowieso noch einiges hin und her schieben.
Wichtig ist halt immer, dass die Architektur passt, wie andere es auf dieser Mailingliste schon häufiger mal eingebracht haben.

> Zuletzt sei noch angemerkt, dass es ja auch gar nicht so schwierig ist, den einen betroffenen Patch hier jetzt gleich umzubauen, sodass er zum neuen System passt. Es geht im Prinzip nur um den einen Patch, dazu kommt dann vll. noch eine Zeile bei den babel-Sachen und ggf. beim Hoodfile, aber das ist alles überschaubar. Auch dein VLAN-Setup aus der /etc/config/gateway, was ja so oder so größtenteils redundant zur initialen Konfiguration ist, wird genauso funktionieren.
Das kann ich halt wie gesagt aktuell nicht bewerten, ich hab das Patchset mangels Zeit noch nicht angesehen.
Aber wenn es einfach ist, dann könntest du das ja auch noch mit in dein Patchset aufnehmen. Dann hat man die Änderungen zusammen und nicht in irgendeiner v27 bei einem Patch, der mit dieser Änderung eigentlich nichts zu tun hat.

> Ich werde auch gerne den Fortschritt der Gatewayfirmware beschleunigen und den Patch entsprechend überarbeiten, dass er zum neuen System passt. Die Patches 1/3 und 2/3 sind ja soweit fertig.
Danke.

Insgesamt sollten wir da jetzt vielleicht auch nicht allzu viel Zeit darauf verwerten zu Diskutieren, was jetzt zuerst kommt.
Die Abhängigkeit zu fff-network ist eh nur klein und sollte in Zukunft sowieso weg.
Eigentlich sind das ja wie ich schon in der Commit Message geschrieben habe nur die Geräteeigenschaften.

Gruß
Fabian
Adrian Schmutzler April 24, 2019, 4:39 p.m. 
Hallo Fabian,

 

ich beschränke das jetzt mal auf den technischen Teil:

 

> Wichtig ist halt immer, dass die Architektur passt, wie andere es auf dieser Mailingliste schon häufiger mal eingebracht haben.

 

Genau, mir geht es um die Architektur. Ich will nicht jetzt nochmal auf etwas aufbauen, was ich (und scheinbar auch andere) unpraktisch finde(n) und loswerden will/wollen.

 

> Aber wenn es einfach ist, dann könntest du das ja auch noch mit in dein Patchset aufnehmen. Dann hat man die Änderungen zusammen und nicht in irgendeiner v27 bei einem Patch, der mit dieser Änderung eigentlich nichts zu tun hat.

 

Mein Patchset ist fertig und komplett reviewed. Dein Patch 3/3 ist nicht reviewed und funktioniert nicht, da er einen CPUPORT braucht, den es nicht gibt.

Du möchtest jetzt aber, dass mein fertiges Patchset darauf warten muss, dass dein Patch 3/3 repariert und reviewed wird. Danach soll mein fertiges Patchset durch einen zu reviewenden Patch ergänzt werden, der deinen Patch dann wieder ändert. Und bis das fertig ist, gibt es dann bestimmt schon den nächsten Patch, der so wichtig ist, dass er monatelang rumliegt und alle anderen Projekte blockiert.

 

Umgekehrt kann mein Patchset jetzt sofort applied werden, und ich habe bereits eine v4 deines 3/3 geschickt, die funktioniert und einfach reviewed werden könnte.

 

Am Ende muss bei einem Projekt, bei dem es unterschiedliche Komponenten gibt, halt immer irgendjemand umbauen. Und ich finde es nicht unfair, wenn da der gewinnt, der schneller fertig ist. Zudem es wie zuvor beschrieben hier auch noch einfacher ist, deinen Patch zu ändern. Und wenn dir der Umbau des einen Patches schon so schwerfällt, dann überlege mal, wie es meine Entwicklungsarbeit aufhält, wenn ich jetzt ewig auf die vierzehn Patches warten muss. 

 

Eigentlich möchte ich das fertige Patchset und deine 1/3 und 2/3 heute in den master einwerfen. Liegt alles schon fertig in meinem Repo.

 

Grüße

 

Adrian

 

 

From: Fabian Bläse [mailto:fabian@blaese.de] 
Sent: Mittwoch, 24. April 2019 18:00
To: Adrian Schmutzler <mail@adrianschmutzler.de>; franken-dev@freifunk.net
Subject: Re: [PATCH v3 3/3] gateway.d: Add scripts for network configuration

 

Hallo Adrian, 

On 24.04.19 13:10, Adrian Schmutzler wrote: 
> mein Patchset schafft die komplette configurenetwork und die network.* Files ab, worüber ich ausgesprochen glücklich bin und was ich für einen großen Fortschritt halte.

Ob ich das gut finde oder nicht kann ich jetzt grade nicht beantworten, da müsste ich erstmal deine Patches angucken. Sind ja immer 14! Stück.

> Das mit dem vorwärts kommen ist halt so eine Sache: 
> 
> Dieser Patch hier lag zuletzt einen Monat rum, bevor die v3 kam. Das ist kein Vorwurf, aber die Gatewayfirmware als Ganzes ist ja unbestreitbar ein langfristiges Projekt.

> 
> Ich finde es daher nicht zielführend, jetzt für einen undefinierten, längeren Zeitraum jegliche Umbauten quasi zu verbieten, nur damit für das Einbauen der Gatewayfirmware weniger Aufwand betrieben werden muss. Weiterhin ist es ja so, dass die Umstellung für fff-network fertig ist, man also in jedem Fall den Gatewayfirmware-Patch dann direkt nach dem Merge des fff-network nochmal umbauen müsste. Das würde ich es schon lieber „gleich richtig“ machen.

Stimmt, das ist ärgerlich. Bin leider nicht früher dazu gekommen :-( 

> (Ich könnte ja jetzt auch beleidigt sein und zum Thema „eines nach dem anderen“ darauf hinweisen, dass man mir nach dem letzten Release den configurenetwork-Patch in Aussicht gestellt hat, auf den ich insgesamt über ein Jahr warte.)

Könntest du, hättest damit aber dennoch irgendwie unrecht, denn dieses Patchset hat mit deinem letzten so gut wie nichts mehr zu tun...

> Gerade beim Einführen der Gatewayfirmware in das offizielle Repo erhoffe ich mir zudem, dass man dabei gerade versucht, das Ganze dann auch langfristig durchdacht zu machen (zum Beispiel sowas wie das gateway.d …), und nicht einfach alles reinwirft, damit es erst mal da ist. Sonst kann ja auch jeder weiter lokal vor sich hinpfriemeln. Klar kann man auch mal einen Kompromiss machen, aber jetzt da ein überholtes System neu einzubauen, nur um schneller fertig zu sein, wissend, dass man es dann gleich wieder umbauen muss, finde ich nicht zielführend.

Jo. Aber wenn wir uns an jedem Patch an Kleinigkeiten so lange aufhalten, bis es absolut perfekt ist, dann sitzen wir irgendwann mit einer v27 da, bei der dann keiner mehr überblickt, was eigentlich geändert wurde.

Wir sind noch relativ am Anfang des Entwicklungsprozesses "Gatewayfirmware", das wird schon noch etwas dauern, bis das fertig ist. Und bis dahin wird sich sowieso noch einiges hin und her schieben.

Wichtig ist halt immer, dass die Architektur passt, wie andere es auf dieser Mailingliste schon häufiger mal eingebracht haben.

> Zuletzt sei noch angemerkt, dass es ja auch gar nicht so schwierig ist, den einen betroffenen Patch hier jetzt gleich umzubauen, sodass er zum neuen System passt. Es geht im Prinzip nur um den einen Patch, dazu kommt dann vll. noch eine Zeile bei den babel-Sachen und ggf. beim Hoodfile, aber das ist alles überschaubar. Auch dein VLAN-Setup aus der /etc/config/gateway, was ja so oder so größtenteils redundant zur initialen Konfiguration ist, wird genauso funktionieren.

Das kann ich halt wie gesagt aktuell nicht bewerten, ich hab das Patchset mangels Zeit noch nicht angesehen. 
Aber wenn es einfach ist, dann könntest du das ja auch noch mit in dein Patchset aufnehmen. Dann hat man die Änderungen zusammen und nicht in irgendeiner v27 bei einem Patch, der mit dieser Änderung eigentlich nichts zu tun hat.

> Ich werde auch gerne den Fortschritt der Gatewayfirmware beschleunigen und den Patch entsprechend überarbeiten, dass er zum neuen System passt. Die Patches 1/3 und 2/3 sind ja soweit fertig.

Danke. 

Insgesamt sollten wir da jetzt vielleicht auch nicht allzu viel Zeit darauf verwerten zu Diskutieren, was jetzt zuerst kommt.

Die Abhängigkeit zu fff-network ist eh nur klein und sollte in Zukunft sowieso weg. 
Eigentlich sind das ja wie ich schon in der Commit Message geschrieben habe nur die Geräteeigenschaften. 

Gruß 
Fabian
Tim Niemeyer May 8, 2019, 7:45 p.m. 
Am Dienstag, den 23.04.2019, 18:09 +0200 schrieb Fabian Bläse:
> This adds scripts to configure vlan and client network.
> This also adds sysctl settings to enable forwarding.
> 
> Note:
> Devices specific properties are sourced from fff-network package.
> This creates a dependency on fff-boardname and fff-network.
> These properties should be located elsewhere in the future.
> 
> Signed-off-by: Fabian Bläse <fabian@blaese.de>
> ---
> Changes in v3:
> - Rename 10-vlan to 20-vlan
> - Rename 20-network-client to 30-network-client
> - Source necessary uci functions and board properties
> - Add dependency on fff-boardname and fff-network
> ---
>  src/packages/fff/fff-gateway/Makefile         |  1 +
>  .../fff-gateway/files/etc/gateway.d/20-vlan   | 47 ++++++++++++
>  .../files/etc/gateway.d/30-network-client     | 71
> +++++++++++++++++++
>  .../files/etc/sysctl.d/60-fff-gateway.conf    |  5 ++
>  4 files changed, 124 insertions(+)
>  create mode 100644 src/packages/fff/fff-
> gateway/files/etc/gateway.d/20-vlan
>  create mode 100644 src/packages/fff/fff-
> gateway/files/etc/gateway.d/30-network-client
>  create mode 100644 src/packages/fff/fff-
> gateway/files/etc/sysctl.d/60-fff-gateway.conf
> 
> diff --git a/src/packages/fff/fff-gateway/Makefile
> b/src/packages/fff/fff-gateway/Makefile
> index 7c1dd55..f9ef8cc 100644
> --- a/src/packages/fff/fff-gateway/Makefile
> +++ b/src/packages/fff/fff-gateway/Makefile
> @@ -13,6 +13,7 @@ define Package/fff-gateway
>  	CATEGORY:=Freifunk
>  	TITLE:= Freifunk-Franken gateway configuration
>  	URL:=https://www.freifunk-franken.de
> +	DEPENDS:=+fff-boardname +fff-network
>  endef
>  
>  define Package/fff-gateway/description
> diff --git a/src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan 
> b/src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan
> new file mode 100644
> index 0000000..c789df3
> --- /dev/null
> +++ b/src/packages/fff/fff-gateway/files/etc/gateway.d/20-vlan
> @@ -0,0 +1,47 @@
> +#load uci functions
> +. /lib/functions.sh
> +
> +#load board specific properties
> +BOARD="$(uci get board.model.name)"
> +. /etc/network.$BOARD
> +
> +
> +configure() {
> +	add_vlan() {
> +		local vlan="$1"
> +		local ports=$(uci get gateway.$vlan.ports)
> +		local name="$SWITCHDEV"_$vlan
> +
> +		uci set network.$name='switch_vlan'
> +		uci set network.$name.device="$(uci get
> network.$SWITCHDEV.name)"
> +		uci set network.$name.vlan="$vlan"
> +		uci set network.$name.ports="$CPUPORT $ports"
> +	}
> +
> +	remove_vlan() {
> +		local name="$1"
> +
> +		local switchdev=$(echo $name | cut -d_ -f1)
> +		local vlan=$(echo $name | cut -d_ -f2)
> +
> +		# only remove vlans not present in gateway config
> +		if ! uci -q get gateway.$vlan > /dev/null; then
> +			# remove switch_vlan
> +			uci del network.$name
> +		fi
> +	}
> +
> +	config_load network
> +	config_foreach remove_vlan switch_vlan
> +
> +	config_load gateway
> +	config_foreach add_vlan vlan
> +}
> +
> +apply() {
> +	uci commit network
> +}
> +
> +revert() {
> +	uci revert network
> +}
> diff --git a/src/packages/fff/fff-gateway/files/etc/gateway.d/30-
> network-client b/src/packages/fff/fff-gateway/files/etc/gateway.d/30-
> network-client
> new file mode 100644
> index 0000000..3ccc14f
> --- /dev/null
> +++ b/src/packages/fff/fff-gateway/files/etc/gateway.d/30-network-
> client
> @@ -0,0 +1,71 @@
> +#load board specific properties
> +BOARD="$(uci get board.model.name)"
> +. /etc/network.$BOARD
> +
> +
> +configure() {
> +	# ipaddr
> +	#remove old ipaddr
> +	uci -q del network.mesh.ipaddr
> +	#set new ipaddr
> +	if ipaddr=$(uci -q get gateway.@client[0].ipaddr); then
> +		for ip in $ipaddr; do
> +			uci add_list network.mesh.ipaddr=$ip
> +		done
> +	else
> +		echo "WARNING: No client ipaddr set!"
> +	fi
> +	#put interface routes from set addresses into fff table
> +	uci set network.mesh.ip4table='fff'
> +
> +	# ip6addr
> +	#remove old ip6addr
> +	for ip in $(uci get network.mesh.ip6addr); do
> +		if echo "$ip" | grep -v -e "fdff:" -e "fe80::1/64" >
> /dev/null; then
> +			uci del_list network.mesh.ip6addr="$ip"
> +		fi
> +	done
> +	#set new ip6addr
> +	if ip6addr=$(uci -q get gateway.@client[0].ip6addr); then
> +		for ip in $ip6addr; do
> +			uci add_list network.mesh.ip6addr=$ip
> +		done
> +	else
> +		echo "WARNING: No client ip6addr set!"
> +	fi
> +	#put interface routes from set addresses into fff table
> +	uci set network.mesh.ip6table='fff'
> +
> +	# dhcp
> +	uci -q del dhcp.mesh.start
> +	uci -q del dhcp.mesh.limit
> +	if dhcp_start=$(uci -q get gateway.@client[0].dhcp_start);
> then
> +		uci set dhcp.mesh=dhcp
> +		uci set dhcp.mesh.interface=mesh
> +		uci set dhcp.mesh.start=$dhcp_start
> +		uci set dhcp.mesh.limit=$(uci -q get gateway.@client
> [0].dhcp_limit)
> +	else
> +		echo "WARNING: No DHCP range start and/or limit
> set!"
> +	fi
> +
> +	# set interface
> +	#remove all eth interfaces
> +	ifaces=$(uci get network.mesh.ifname | sed -e "s/
> *eth\d\.\d//g" -e "s/ *eth\d//g" -e "s/^ //")
> +	if vlan=$(uci -q get gateway.@client[0].vlan); then
> +		uci set network.mesh.ifname="${SWITCHDEV}.$vlan
> $ifaces"
> +	elif iface=$(uci -q get gateway.@client[0].iface); then
> +		uci set network.mesh.ifname="$iface $ifaces"
> +	else
> +		echo "WARNING: No Interface for client specified"
> +	fi
Mit diesem Abschnitt bin ich noch nicht ganz glücklich, da es z.B.
nicht möglich ist ein Client-Netz auf ein VLAN raus zu schicken und
gleichzeitig auf ein hartes Interface.

Kurz noch Verständnisfragen:
- Wenn das Client-Netz tagged raus soll, dann kann ich bei den Geräten
mit Switch in dem vlan einfach das 't' hinzufügen?
- Wenn das Client-Netz tagged raus soll, ich aber kein Switch im Gerät
habe, geht es nicht?

Ich denke meine Anmerkung oben, sowie die Verständnisfragen sind
erstmal nur Corner-Cases, die bei Bedarf ggfs anderweitig gepatch
werden können. In dem Sinne, wäre es nett, wenn du noch kurz meine
Fragen beantwortest und ansonsten:
Reviewed-by: Tim Niemeyer <tim@tn-x.org>

Tim


> +}
> +
> +apply() {
> +	uci commit network
> +	uci commit dhcp
> +}
> +
> +revert() {
> +	uci revert network
> +	uci revert dhcp
> +}
> diff --git a/src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-
> gateway.conf b/src/packages/fff/fff-gateway/files/etc/sysctl.d/60-
> fff-gateway.conf
> new file mode 100644
> index 0000000..62bda1b
> --- /dev/null
> +++ b/src/packages/fff/fff-gateway/files/etc/sysctl.d/60-fff-
> gateway.conf
> @@ -0,0 +1,5 @@
> +# Enable forwarding
> +net.ipv4.conf.all.forwarding=1
> +net.ipv4.ip_forward=1
> +net.ipv6.conf.all.forwarding=1
> +net.ipv6.conf.default.forwarding=1
Tim Niemeyer May 8, 2019, 7:49 p.m. 
Am Mittwoch, den 24.04.2019, 10:30 +0200 schrieb Fabian Bläse:
> 
> On 24.04.19 00:33, Adrian Schmutzler wrote:
> > Hallo Fabian,
> > 
> > wenn ich mir ansehe, was dieser Patch so tut, möchte ich ihn
> > eigentlich ungern so in die Firmware tun, sondern lieber auf die
> > neue Netzwerk-Config umbauen.
Aktuell schwebt mir vor, dass wir erstmal die Gateway-Firmware vorran
bringen und dann gffs das configure-network soweit ausdünnen, dass nur
noch das notwendige drin ist, was es unbedingt für die Gateway-Firmware 
braucht. Darauf kann dann gern auch die Node-Firmware aufsetzen.

> 
> So genau hab ich mir die neue Netzwerk-Config noch nicht angesehen,
> aber abgesehen vom CPUPORT (der da dummerweise grade in dem Package
> drin ist) ist das doch komplett unabhängig davon..?
> 
> > Rein formal ist im Moment zwar nur der CPUPORT noch ungeklärt. Auf
> > der anderen Seite warte ich aber auch nur noch auf das Review von
> > Robert zwecks Patch 3/14, dann hätte ich das applied.
> > 
> > Bei diesem Patch wäre es dann so, dass man den applied und dann
> > relativ gleich danach massiv umbaut. Das finde nicht unbedingt
> > erstrebenswert.
> 
> So kommt man aber wenigstens vorwärts.
> Bitte lass uns da jetzt nicht nochmal irgendwas neues dazwischen
> mischen, was dieses Patchset u.U. nochmal etwas durcheinander bringt,
> sondern eins nach dem anderen angehen.
> Sonst wird die Gatewayfirmware nie fertig.
Ack. So hatten wir das auch damals auf den Entwickler-Treffen
besprochen. Der Deal war V2 fertig zu machen und dann endlich die
Gateway-Firmware anzugehen.

> 
> Insgesamt stützt sich die Gateway Variante nur auf das
> configurenetwork für die initiale Interface-Konfiguration. (fdff,
> etc.)
> Das braucht es imho aber eigentlich gar nicht, zumal es später
> sowieso von der eigenen Konfiguration überschrieben wird.
> Wenn man nichts vorher konfiguriert, müsste der Router glaube ich auf
> jedem Interface mit seiner Link Local Adresse erreichbar sein.
Ja, das ist bei OpenWRT normalerweise so, jedoch mit der Unschönheit,
dass gern die falsche MAC verwendet wird. Daher findet man den Knoten
dann nicht anhand der aufgedruckten MAC.

Tim

> Gruß
> Fabian
>
Fabian Blaese May 8, 2019, 8:06 p.m. 
Hallo Tim,

On 08.05.19 21:45, Tim Niemeyer wrote:
> Am Dienstag, den 23.04.2019, 18:09 +0200 schrieb Fabian Bläse:
>> +	# set interface
>> +	#remove all eth interfaces
>> +	ifaces=$(uci get network.mesh.ifname | sed -e "s/
>> *eth\d\.\d//g" -e "s/ *eth\d//g" -e "s/^ //")
>> +	if vlan=$(uci -q get gateway.@client[0].vlan); then
>> +		uci set network.mesh.ifname="${SWITCHDEV}.$vlan
>> $ifaces"
>> +	elif iface=$(uci -q get gateway.@client[0].iface); then
>> +		uci set network.mesh.ifname="$iface $ifaces"
>> +	else
>> +		echo "WARNING: No Interface for client specified"
>> +	fi
> Mit diesem Abschnitt bin ich noch nicht ganz glücklich, da es z.B.
> nicht möglich ist ein Client-Netz auf ein VLAN raus zu schicken und
> gleichzeitig auf ein hartes Interface.
Stimmt, das geht damit nicht.
Mir fällt jetzt spontan auch nichts ein, wie man das gut umsetzen könnte.
Im Endeffekt müsste dann switchdev + interface in das network.mesh.ifname...

> 
> Kurz noch Verständnisfragen:
> - Wenn das Client-Netz tagged raus soll, dann kann ich bei den Geräten
> mit Switch in dem vlan einfach das 't' hinzufügen?
Genau.

> - Wenn das Client-Netz tagged raus soll, ich aber kein Switch im Gerät
> habe, geht es nicht?
Doch. Einfach Interface.VLAN in ifname stecken.
OpenWRT legt das VLAN dann ggf. passend an.

Gruß
Fabian
Tim Niemeyer May 8, 2019, 8:17 p.m. 
Am Mittwoch, den 24.04.2019, 18:39 +0200 schrieb Adrian Schmutzler:
> Hallo Fabian,
>  
> ich beschränke das jetzt mal auf den technischen Teil:
>  
> > Wichtig ist halt immer, dass die Architektur passt, wie andere es
> auf dieser Mailingliste schon häufiger mal eingebracht haben.
>  
> Genau, mir geht es um die Architektur. Ich will nicht jetzt nochmal
> auf etwas aufbauen, was ich (und scheinbar auch andere) unpraktisch
> finde(n) und loswerden will/wollen.
>  
> > Aber wenn es einfach ist, dann könntest du das ja auch noch mit in
> dein Patchset aufnehmen. Dann hat man die Änderungen zusammen und
> nicht in irgendeiner v27 bei einem Patch, der mit dieser Änderung
> eigentlich nichts zu tun hat.
>  
> Mein Patchset ist fertig und komplett reviewed. Dein Patch 3/3 ist 
Ich habe großen Respekt vor dem Reviewer und natürlich auch vor deiner
Arbeit.. Ich habe mich gerade gefragt, warum ich keine Ahnung habe, um
was es in deinem Patchset geht. Ich habe die letzten Wochen immer nur
sporadisch in die Liste reingeschaut. Meistens ging es um irgendwelche
"Node" Sachen, die mich weniger interessiert haben. Da ich wenig Zeit
habe, habe ich diese daher liegen gelassen. Ich habe von keinem Konzept
gehört, welches das configurenetwork ordentlich umbaut. Das wundert
mich, weil das configurenetwork kommt von mir und da wäre es nur fair
einbezogen zu werden. Aber sei es drum. Ich habe gerade versucht das
Patchset anzuschauen, aber.. Das ist ja sowas von durchwachsen. Tut mir
leid, 
a) dass ist zu groß
b) ich finde kein Einstiegspunkt
c) die Patchversionen sind alle durchgewürfelt und es gibt keine
sauberen Threads. Mal ist der Coverletter in 0/x (wo er hin gehört)
manchmal in 3/x .. Wie soll ich das mit meiner wenigen Zeit denn
schaffen da den Überblick zu behalten?

Ja, das configure-network ist ein gewachsenes Konstrukt. Am Anfang war
die Architektur davon noch ok, weil es einfach war und wenig gemacht
hat. Mitunter kamen immer mehr Sachen dazu und wir haben jetzt ein
Biest. So etwas kann einer alleine nicht mal eben über Nacht umbauen.
Selbst wenn einer allein ein Patchset schreiben kann, dann hängt er
damit einen Großteil der anderen Entwickler einfach mal ebenso ganz
direkt ab. Solche großen Änderungen müssen besprochen werden und müssen
mitwachsen. So etwas dauert bei unseren Ressourcen kurz gesagt ewig.

Letztlich höre ich bei dir, Adrian, viel Frust raus. Vermutlich hast du
viel Zeit in das Patchset gesteckt, und ich freue mich auch total, dass
du dir die Arbeit gemacht hast. Leider braust du mit dieser Motivation
aktuell volle kanne gegen unser ewiges Ressourcen Problem. Du musst uns
einfach viel mehr Zeit geben deine Arbeit zu verstehen. Es geht beim
gemeinsamen entwickeln leider nicht nur darum ein Patchset zu bauen,
sondern man muss die anderen Entwickler auch abholen und mitnehmen. Bei
mir hast du das nicht geschafft und bei Fabian offenbar auch nicht. Das
führt jetzt zu einem Konflikt. Nun hast du inzwischen scheinbar leider
so viel Frust aufgebaut, dass du wohl die Segel gestrichen hast.
Schade, aber kann ich auch irgendwie verstehen. Ich wollte eine Zeit
lang auch einfach nur weg rennen. Sicherlich wäre es gut gewesen, wenn
die Entwickler und die interessierten sich mal am Tisch zusammen
gehockt hätten. Da hättest du z.B. die Gelegenheit gehabt deine
Vorstellungen für den Umbau von configure-network mal vorzustellen (am
besten bevor der Patch fertig ist), und so die anderen Leute abzuholen.

Hingegen bei der Gateway-Firmware, reden wir alle seit Jahren von
nichts anderem mehr. Da tauchen viele verschiedene Ideen auf, die
reifen und die werden besprochen (oft (leider) auch Abseits der
Mailingliste). Daher, auch wenn es mir um deine Arbeit in dem Patchset
leid tut, hat das für mich eindeutig Vorrang.

Auch bezüglich der Priorität liegt die Gateway-Firmware im Moment
vorne: Wir brauchen die an vielen Standorten, haben aber nichts. Das
configure-network ist hässlich, aber funktioniert.
 

> nicht reviewed und funktioniert nicht, da er einen CPUPORT braucht,
> den es nicht gibt.
Das ist ein ernstzunehmendes Problem.. Hmm..

Tim

> Du möchtest jetzt aber, dass mein fertiges Patchset darauf warten
> muss, dass dein Patch 3/3 repariert und reviewed wird. Danach soll
> mein fertiges Patchset durch einen zu reviewenden Patch ergänzt
> werden, der deinen Patch dann wieder ändert. Und bis das fertig ist,
> gibt es dann bestimmt schon den nächsten Patch, der so wichtig ist,
> dass er monatelang rumliegt und alle anderen Projekte blockiert.
>  
> Umgekehrt kann mein Patchset jetzt sofort applied werden, und ich
> habe bereits eine v4 deines 3/3 geschickt, die funktioniert und
> einfach reviewed werden könnte.
>  
> Am Ende muss bei einem Projekt, bei dem es unterschiedliche
> Komponenten gibt, halt immer irgendjemand umbauen. Und ich finde es
> nicht unfair, wenn da der gewinnt, der schneller fertig ist. Zudem es
> wie zuvor beschrieben hier auch noch einfacher ist, deinen Patch zu
> ändern. Und wenn dir der Umbau des einen Patches schon so
> schwerfällt, dann überlege mal, wie es meine Entwicklungsarbeit
> aufhält, wenn ich jetzt ewig auf die vierzehn Patches warten muss.
>  
> Eigentlich möchte ich das fertige Patchset und deine 1/3 und 2/3
> heute in den master einwerfen. Liegt alles schon fertig in meinem
> Repo.
>  
> Grüße
>  
> Adrian
>  
>  
> From: Fabian Bläse [mailto:fabian@blaese.de] 
> Sent: Mittwoch, 24. April 2019 18:00
> To: Adrian Schmutzler <mail@adrianschmutzler.de>; franken-dev@freifun
> k.net
> Subject: Re: [PATCH v3 3/3] gateway.d: Add scripts for network
> configuration
>  
> Hallo Adrian,
> On 24.04.19 13:10, Adrian Schmutzler wrote: 
> > mein Patchset schafft die komplette configurenetwork und die
> network.* Files ab, worüber ich ausgesprochen glücklich bin und was
> ich für einen großen Fortschritt halte.
> Ob ich das gut finde oder nicht kann ich jetzt grade nicht
> beantworten, da müsste ich erstmal deine Patches angucken. Sind ja
> immer 14! Stück.
> > Das mit dem vorwärts kommen ist halt so eine Sache: 
> > 
> > Dieser Patch hier lag zuletzt einen Monat rum, bevor die v3 kam.
> Das ist kein Vorwurf, aber die Gatewayfirmware als Ganzes ist ja
> unbestreitbar ein langfristiges Projekt.
> > 
> > Ich finde es daher nicht zielführend, jetzt für einen
> undefinierten, längeren Zeitraum jegliche Umbauten quasi zu
> verbieten, nur damit für das Einbauen der Gatewayfirmware weniger
> Aufwand betrieben werden muss. Weiterhin ist es ja so, dass die
> Umstellung für fff-network fertig ist, man also in jedem Fall den
> Gatewayfirmware-Patch dann direkt nach dem Merge des fff-network
> nochmal umbauen müsste. Das würde ich es schon lieber „gleich
> richtig“ machen.
> Stimmt, das ist ärgerlich. Bin leider nicht früher dazu gekommen :-(
> > (Ich könnte ja jetzt auch beleidigt sein und zum Thema „eines nach
> dem anderen“ darauf hinweisen, dass man mir nach dem letzten Release
> den configurenetwork-Patch in Aussicht gestellt hat, auf den ich
> insgesamt über ein Jahr warte.)
> Könntest du, hättest damit aber dennoch irgendwie unrecht, denn
> dieses Patchset hat mit deinem letzten so gut wie nichts mehr zu
> tun...
> > Gerade beim Einführen der Gatewayfirmware in das offizielle Repo
> erhoffe ich mir zudem, dass man dabei gerade versucht, das Ganze dann
> auch langfristig durchdacht zu machen (zum Beispiel sowas wie das
> gateway.d …), und nicht einfach alles reinwirft, damit es erst mal da
> ist. Sonst kann ja auch jeder weiter lokal vor sich hinpfriemeln.
> Klar kann man auch mal einen Kompromiss machen, aber jetzt da ein
> überholtes System neu einzubauen, nur um schneller fertig zu sein,
> wissend, dass man es dann gleich wieder umbauen muss, finde ich nicht
> zielführend.
> Jo. Aber wenn wir uns an jedem Patch an Kleinigkeiten so lange
> aufhalten, bis es absolut perfekt ist, dann sitzen wir irgendwann mit
> einer v27 da, bei der dann keiner mehr überblickt, was eigentlich
> geändert wurde.
> Wir sind noch relativ am Anfang des Entwicklungsprozesses
> "Gatewayfirmware", das wird schon noch etwas dauern, bis das fertig
> ist. Und bis dahin wird sich sowieso noch einiges hin und her
> schieben.
> Wichtig ist halt immer, dass die Architektur passt, wie andere es auf
> dieser Mailingliste schon häufiger mal eingebracht haben.
> > Zuletzt sei noch angemerkt, dass es ja auch gar nicht so schwierig
> ist, den einen betroffenen Patch hier jetzt gleich umzubauen, sodass
> er zum neuen System passt. Es geht im Prinzip nur um den einen Patch,
> dazu kommt dann vll. noch eine Zeile bei den babel-Sachen und ggf.
> beim Hoodfile, aber das ist alles überschaubar. Auch dein VLAN-Setup
> aus der /etc/config/gateway, was ja so oder so größtenteils redundant
> zur initialen Konfiguration ist, wird genauso funktionieren.
> Das kann ich halt wie gesagt aktuell nicht bewerten, ich hab das
> Patchset mangels Zeit noch nicht angesehen. 
> Aber wenn es einfach ist, dann könntest du das ja auch noch mit in
> dein Patchset aufnehmen. Dann hat man die Änderungen zusammen und
> nicht in irgendeiner v27 bei einem Patch, der mit dieser Änderung
> eigentlich nichts zu tun hat.
> > Ich werde auch gerne den Fortschritt der Gatewayfirmware
> beschleunigen und den Patch entsprechend überarbeiten, dass er zum
> neuen System passt. Die Patches 1/3 und 2/3 sind ja soweit fertig.
> Danke.
> Insgesamt sollten wir da jetzt vielleicht auch nicht allzu viel Zeit
> darauf verwerten zu Diskutieren, was jetzt zuerst kommt.
> Die Abhängigkeit zu fff-network ist eh nur klein und sollte in
> Zukunft sowieso weg. 
> Eigentlich sind das ja wie ich schon in der Commit Message
> geschrieben habe nur die Geräteeigenschaften.
> Gruß 
> Fabian
>
Fabian Blaese May 9, 2019, 9:13 a.m. 
Auf dieses Patchset gibt es bisher ein Review und eine nichttriviale Kritik.

Ich möchte mit dem applien hier noch ein wenig warten.
Wer noch Anmerkungen dazu hat möge sich bitte möglichst zeitnah melden.

Ansonsten würde ich auch diesen Patch übernehmen und Änderungen am (oder in Bezug auf) configurenetwork wie Diskutiert etwas nach hinten verschieben.

Gruß
Fabian
Fabian Blaese May 9, 2019, 9:19 a.m. 
Hallo Tim,

On 08.05.19 21:49, Tim Niemeyer wrote:
> Am Mittwoch, den 24.04.2019, 10:30 +0200 schrieb Fabian Bläse:
>> Insgesamt stützt sich die Gateway Variante nur auf das
>> configurenetwork für die initiale Interface-Konfiguration. (fdff,
>> etc.)
>> Das braucht es imho aber eigentlich gar nicht, zumal es später
>> sowieso von der eigenen Konfiguration überschrieben wird.
>> Wenn man nichts vorher konfiguriert, müsste der Router glaube ich auf
>> jedem Interface mit seiner Link Local Adresse erreichbar sein.
> Ja, das ist bei OpenWRT normalerweise so, jedoch mit der Unschönheit,
> dass gern die falsche MAC verwendet wird. Daher findet man den Knoten
> dann nicht anhand der aufgedruckten MAC.
Was hier "falsch" ist, darüber kann man sich streiten.
Der Hersteller hat halt nicht die "richtige" von den MAC Adressen aufgedruckt. ;-)

IPv6 hat aber einen Multicast Mechanismus mit dem man alle Hosts auf einem Link erreicht. Dieser lässt sich prima dazu ausnutzen die richtige IP herauszufinden.
Einfach n ping an ff02::1, dann antworten alle Geräte auf dem gleichen Link. Kann man ja mit in die Dokumentation schreiben.

Gruß
Fabian
Fabian Blaese May 9, 2019, 9:26 a.m. 
Hallo zusammen,

On 08.05.19 22:17, Tim Niemeyer wrote:
> Am Mittwoch, den 24.04.2019, 18:39 +0200 schrieb Adrian Schmutzler:
>> nicht reviewed und funktioniert nicht, da er einen CPUPORT braucht,
>> den es nicht gibt.
> Das ist ein ernstzunehmendes Problem.. Hmm..
Jo, der wäre noch wichtig.
Ich hatte mir das urspünglich mal so vorgestellt, dass man die configurenetwork-Magie und die aktuell im gleichen Paket liegenden Portinformationen teilt.
Wenn man das Skript aber sowieso umbauen oder gar los werden möchte, erscheint mir Adrians Vorschlag mit ein extra Skript, dass den CPU-Port per Switch-Case festlegt, sinnvoll. (siehe [1])

Ich bin mir noch nicht ganz sicher, wie man das sinnvoll in Pakete verpackt.
Also falls jemand Vorschläge hat... :-)

Gruß
Fabian

[1] https://lists.freifunk.net/mailman/private/franken-dev-freifunk.net/2019-April/015473.html
Adrian Schmutzler May 9, 2019, 10:47 a.m. 
Ihr könnt auch einfach die /etc/board.json nutzen, die direkt aus den board.d Files von OpenWrt erstellt wird und statisch ist.

 

Dort in node switch/switch0/roles nach dem Eintrag mit role=lan suchen und dort den Port mit t aus den roles auslesen.

Die Datei liegt auf jedem Router rum. Würde aber ein Code-Monster …

 

Inspiration gibt’s in der /bin/config_generate, mit der OpenWrt die /etc/config/network erstellt.

 

Grüße

 

Adrian

 

From: Fabian Bläse [mailto:fabian@blaese.de] 
Sent: Donnerstag, 9. Mai 2019 11:27
To: Tim Niemeyer <tim@tn-x.org>; Adrian Schmutzler <mail@adrianschmutzler.de>; franken-dev@freifunk.net
Subject: Re: [PATCH v3 3/3] gateway.d: Add scripts for network configuration

 

Hallo zusammen, 

On 08.05.19 22:17, Tim Niemeyer wrote: 
> Am Mittwoch, den 24.04.2019, 18:39 +0200 schrieb Adrian Schmutzler: 
>> nicht reviewed und funktioniert nicht, da er einen CPUPORT braucht, 
>> den es nicht gibt. 
> Das ist ein ernstzunehmendes Problem.. Hmm.. 
Jo, der wäre noch wichtig. 
Ich hatte mir das urspünglich mal so vorgestellt, dass man die configurenetwork-Magie und die aktuell im gleichen Paket liegenden Portinformationen teilt.

Wenn man das Skript aber sowieso umbauen oder gar los werden möchte, erscheint mir Adrians Vorschlag mit ein extra Skript, dass den CPU-Port per Switch-Case festlegt, sinnvoll. (siehe [1])

Ich bin mir noch nicht ganz sicher, wie man das sinnvoll in Pakete verpackt. 
Also falls jemand Vorschläge hat... :-) 

Gruß 
Fabian 

[1] https://lists.freifunk.net/mailman/private/franken-dev-freifunk.net/2019-April/015473.html
Tim Niemeyer May 9, 2019, 2:38 p.m. 
Hi Fabian

Am 9. Mai 2019 11:19:10 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>:
>Hallo Tim,
>
>On 08.05.19 21:49, Tim Niemeyer wrote:
>> Am Mittwoch, den 24.04.2019, 10:30 +0200 schrieb Fabian Bläse:
>>> Insgesamt stützt sich die Gateway Variante nur auf das
>>> configurenetwork für die initiale Interface-Konfiguration. (fdff,
>>> etc.)
>>> Das braucht es imho aber eigentlich gar nicht, zumal es später
>>> sowieso von der eigenen Konfiguration überschrieben wird.
>>> Wenn man nichts vorher konfiguriert, müsste der Router glaube ich
>auf
>>> jedem Interface mit seiner Link Local Adresse erreichbar sein.
>> Ja, das ist bei OpenWRT normalerweise so, jedoch mit der Unschönheit,
>> dass gern die falsche MAC verwendet wird. Daher findet man den Knoten
>> dann nicht anhand der aufgedruckten MAC.
>Was hier "falsch" ist, darüber kann man sich streiten.
>Der Hersteller hat halt nicht die "richtige" von den MAC Adressen
>aufgedruckt. ;-)

Naja.. Die Argumentation is nicht so dolle..


>IPv6 hat aber einen Multicast Mechanismus mit dem man alle Hosts auf
>einem Link erreicht. Dieser lässt sich prima dazu ausnutzen die
>richtige IP herauszufinden.
>Einfach n ping an ff02::1, dann antworten alle Geräte auf dem gleichen
>Link. Kann man ja mit in die Dokumentation schreiben.

Ja ist klar. Aber ist unpraktikabel (z.B. wenn man viele Hosts im L2 Netz hat) und wir haben ja bereits ne Lösung dafür gehabt. Das sollten wir einfach nicht kaputt machen.

Tim

>Gruß
>Fabian
Tim Niemeyer May 9, 2019, 2:42 p.m. 
Hi

Am 9. Mai 2019 11:26:52 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>:
>Hallo zusammen,
>
>On 08.05.19 22:17, Tim Niemeyer wrote:
>> Am Mittwoch, den 24.04.2019, 18:39 +0200 schrieb Adrian Schmutzler:
>>> nicht reviewed und funktioniert nicht, da er einen CPUPORT braucht,
>>> den es nicht gibt.
>> Das ist ein ernstzunehmendes Problem.. Hmm..
>Jo, der wäre noch wichtig.
>Ich hatte mir das urspünglich mal so vorgestellt, dass man die
>configurenetwork-Magie und die aktuell im gleichen Paket liegenden
>Portinformationen teilt.
>Wenn man das Skript aber sowieso umbauen oder gar los werden möchte,
>erscheint mir Adrians Vorschlag mit ein extra Skript, dass den CPU-Port
>per Switch-Case festlegt, sinnvoll. (siehe [1])

Den Vorschlag möchte ich gern erstmal sehen. Allerdings wäre es mir wichtig, dass dieser leserlich (oder anders medial) aufbereitet ist, mir fehlen Zeit und nerven mich durch tausend kaputte mail threads zu wühlen. Hinzu kommt, dass das vermutlich in dem riesen Patchset drin ist. Das musste vermutlich in ganz kleine Brocken gebracht werden, mit einer abgesprochenen und gemeinsamen Linie. Ähnlich wie es für die Gateway Patches läuft.

>Ich bin mir noch nicht ganz sicher, wie man das sinnvoll in Pakete
>verpackt.
>Also falls jemand Vorschläge hat... :-)
>
>Gruß
>Fabian
>
>[1]
>https://lists.freifunk.net/mailman/private/franken-dev-freifunk.net/2019-April/015473.html

Da komme ich grad nicht ran.

Tim
Fabian Blaese May 9, 2019, 2:43 p.m. 
Hallo Tim,

On 09.05.19 16:38, Tim Niemeyer wrote:
>> IPv6 hat aber einen Multicast Mechanismus mit dem man alle Hosts auf
>> einem Link erreicht. Dieser lässt sich prima dazu ausnutzen die
>> richtige IP herauszufinden.
>> Einfach n ping an ff02::1, dann antworten alle Geräte auf dem gleichen
>> Link. Kann man ja mit in die Dokumentation schreiben.
> 
> Ja ist klar. Aber ist unpraktikabel (z.B. wenn man viele Hosts im L2 Netz hat) und wir haben ja bereits ne Lösung dafür gehabt. Das sollten wir einfach nicht kaputt machen.
Ein unkonfiguriertes Gateway sollte man halt nicht an ein Netz mit anderen Hosts stecken..
Die Lösung die wir bisher haben ist auch nicht RFC konform, da das ULA Netz eigentlich gewürfelt werden müsste.

Aber ja, man kann natürlich dennoch weiterhin versuchen unsere Lösung beizubehalten.

Gruß
Fabian
Fabian Blaese May 9, 2019, 2:52 p.m. 
Hallo Tim,

On 09.05.19 16:42, Tim Niemeyer wrote:
> Am 9. Mai 2019 11:26:52 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>:
>> Jo, der wäre noch wichtig.
>> Ich hatte mir das urspünglich mal so vorgestellt, dass man die
>> configurenetwork-Magie und die aktuell im gleichen Paket liegenden
>> Portinformationen teilt.
>> Wenn man das Skript aber sowieso umbauen oder gar los werden möchte,
>> erscheint mir Adrians Vorschlag mit ein extra Skript, dass den CPU-Port
>> per Switch-Case festlegt, sinnvoll. (siehe [1])
> 
> Den Vorschlag möchte ich gern erstmal sehen. Allerdings wäre es mir wichtig, dass dieser leserlich (oder anders medial) aufbereitet ist, mir fehlen Zeit und nerven mich durch tausend kaputte mail threads zu wühlen. Hinzu kommt, dass das vermutlich in dem riesen Patchset drin ist. Das musste vermutlich in ganz kleine Brocken gebracht werden, mit einer abgesprochenen und gemeinsamen Linie. Ähnlich wie es für die Gateway Patches läuft.
Der Vorschlag ist ganz kurz, da nur eine einzige Datei mit einem einzigen Switch-Case.

>> [1]
>> https://lists.freifunk.net/mailman/private/franken-dev-freifunk.net/2019-April/015473.html
> 
> Da komme ich grad nicht ran.
Verdammt. Da is ja immer noch ein Passwort drauf.
Du suchst nach "[PATCH v4 1/2] fff-network: Provide script with CPUPORT" von Adrian.

Gruß
Fabian
Fabian Blaese May 9, 2019, 5:36 p.m. 
In Kombination mit Adrians Lösung für den CPUPORT muss hier dann noch das neue functions-Script von Adrian gesourced werden.
Ich würde das, falls es keine Einwände gibt, noch fix beim Applien mit rein nehmen.

. /lib/functions/fff/cpuport

Gruß
Fabian

On 09.05.19 16:52, Fabian Bläse wrote:
> Hallo Tim,
> 
> On 09.05.19 16:42, Tim Niemeyer wrote:
>> Am 9. Mai 2019 11:26:52 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>:
>>> Jo, der wäre noch wichtig.
>>> Ich hatte mir das urspünglich mal so vorgestellt, dass man die
>>> configurenetwork-Magie und die aktuell im gleichen Paket liegenden
>>> Portinformationen teilt.
>>> Wenn man das Skript aber sowieso umbauen oder gar los werden möchte,
>>> erscheint mir Adrians Vorschlag mit ein extra Skript, dass den CPU-Port
>>> per Switch-Case festlegt, sinnvoll. (siehe [1])
>>
>> Den Vorschlag möchte ich gern erstmal sehen. Allerdings wäre es mir wichtig, dass dieser leserlich (oder anders medial) aufbereitet ist, mir fehlen Zeit und nerven mich durch tausend kaputte mail threads zu wühlen. Hinzu kommt, dass das vermutlich in dem riesen Patchset drin ist. Das musste vermutlich in ganz kleine Brocken gebracht werden, mit einer abgesprochenen und gemeinsamen Linie. Ähnlich wie es für die Gateway Patches läuft.
> Der Vorschlag ist ganz kurz, da nur eine einzige Datei mit einem einzigen Switch-Case.
> 
>>> [1]
>>> https://lists.freifunk.net/mailman/private/franken-dev-freifunk.net/2019-April/015473.html
>>
>> Da komme ich grad nicht ran.
> Verdammt. Da is ja immer noch ein Passwort drauf.
> Du suchst nach "[PATCH v4 1/2] fff-network: Provide script with CPUPORT" von Adrian.
> 
> Gruß
> Fabian
>
Tim Niemeyer May 9, 2019, 6 p.m. 
Moin

Ja, mach.

Tim

Am 9. Mai 2019 19:36:48 MESZ schrieb "Fabian Bläse" <fabian@blaese.de>:
>In Kombination mit Adrians Lösung für den CPUPORT muss hier dann noch
>das neue functions-Script von Adrian gesourced werden.
>Ich würde das, falls es keine Einwände gibt, noch fix beim Applien mit
>rein nehmen.
>
>. /lib/functions/fff/cpuport
>
>Gruß
>Fabian
>
>On 09.05.19 16:52, Fabian Bläse wrote:
>> Hallo Tim,
>> 
>> On 09.05.19 16:42, Tim Niemeyer wrote:
>>> Am 9. Mai 2019 11:26:52 MESZ schrieb "Fabian Bläse"
><fabian@blaese.de>:
>>>> Jo, der wäre noch wichtig.
>>>> Ich hatte mir das urspünglich mal so vorgestellt, dass man die
>>>> configurenetwork-Magie und die aktuell im gleichen Paket liegenden
>>>> Portinformationen teilt.
>>>> Wenn man das Skript aber sowieso umbauen oder gar los werden
>möchte,
>>>> erscheint mir Adrians Vorschlag mit ein extra Skript, dass den
>CPU-Port
>>>> per Switch-Case festlegt, sinnvoll. (siehe [1])
>>>
>>> Den Vorschlag möchte ich gern erstmal sehen. Allerdings wäre es mir
>wichtig, dass dieser leserlich (oder anders medial) aufbereitet ist,
>mir fehlen Zeit und nerven mich durch tausend kaputte mail threads zu
>wühlen. Hinzu kommt, dass das vermutlich in dem riesen Patchset drin
>ist. Das musste vermutlich in ganz kleine Brocken gebracht werden, mit
>einer abgesprochenen und gemeinsamen Linie. Ähnlich wie es für die
>Gateway Patches läuft.
>> Der Vorschlag ist ganz kurz, da nur eine einzige Datei mit einem
>einzigen Switch-Case.
>> 
>>>> [1]
>>>>
>https://lists.freifunk.net/mailman/private/franken-dev-freifunk.net/2019-April/015473.html
>>>
>>> Da komme ich grad nicht ran.
>> Verdammt. Da is ja immer noch ein Passwort drauf.
>> Du suchst nach "[PATCH v4 1/2] fff-network: Provide script with
>CPUPORT" von Adrian.
>> 
>> Gruß
>> Fabian
>>
Fabian Blaese May 12, 2019, 11:46 a.m. 
Hallo zusammen,

plant noch jemand Rückmeldung zu diesem Patchset? (Und hat es bisher nur aus Zeit oder Motivationsmangel nicht geschafft drüber zu schauen)?
Liegt ja jetzt doch schon etwas länger..

Im Moment hat dieser Patch nur ein Review.

Gruß
Fabian
Robert Langhammer May 12, 2019, 8:03 p.m. 
Hallo Fabian,

das Sourcen von /etc/network.$BOARD hast du ja wieder rein genommen. Für
den CPUPORT wird dann noch Adrians Script gesourced. Hab ich das so
richtig rausgelesen aus dem Berg an Mails?

Den sed-Wurm  könnte man auch etwas stutzen. Probier mal sed 's/eth[^ ]*
//g'

Grüße Robert

Am 12.05.19 um 13:46 schrieb Fabian Bläse:
> Hallo zusammen,
>
> plant noch jemand Rückmeldung zu diesem Patchset? (Und hat es bisher nur aus Zeit oder Motivationsmangel nicht geschafft drüber zu schauen)?
> Liegt ja jetzt doch schon etwas länger..
>
> Im Moment hat dieser Patch nur ein Review.
>
> Gruß
> Fabian
>
Fabian Blaese May 12, 2019, 8:52 p.m. 
Hallo Robert,

On 12.05.19 22:03, robert wrote:
> das Sourcen von /etc/network.$BOARD hast du ja wieder rein genommen. Für den CPUPORT wird dann noch Adrians Script gesourced. Hab ich das so richtig rausgelesen aus dem Berg an Mails?
Genau.

> Den sed-Wurm  könnte man auch etwas stutzen. Probier mal sed 's/eth[^ ]* //g'
Da sehe ich grade eh noch ein Problem. VLANs mit mehrstelliger ID werden davon nicht erfasst.
Ich bau nochmal eine v4. Danke für den Vorschlag.

Gruß
Fabian
Adrian Schmutzler May 15, 2019, 2:43 p.m. 
Hallo,

FYI:

> das Sourcen von /etc/network.$BOARD hast du ja wieder rein genommen. Für den CPUPORT wird dann noch Adrians Script gesourced. Hab ich das so richtig rausgelesen aus dem Berg an Mails?

Ich habe auch lange überlegt, wie man das mit dem CPUPORT am besten macht. Ich habe mich jetzt dafür entschieden, das CPUPORT Skript komplett wieder raus zu werfen und einfach den User den CPU-Port mit den Ports setzen zu lassen. Der User muss die anderen Ports ohnehin irgendwo raussuchen, wenn er sie zuweisen will. Da kann er dabei auch den CPU-Port mitnehmen.
Zudem gibt es einzelne Geräte (C7v2 mit zweitem eth am Switch), wo man dann den zweiten CPU-Port trotzdem eintragen müsste usw., was auch nicht gerade konsistent ist.
Ich finde das einfacher und klarer, wenn das der User selbst macht. Und es deckt sich mit dem, was man manuell auch in /etc/config/network machen würde. Das ganze CPU-Port-Herausfinden kann man sich sparen.

Nur als Kommentar ...

Grüße

Adrian
Fabian Blaese May 15, 2019, 9:27 p.m. 
Hallo Adrian,

On 15.05.19 16:43, Adrian Schmutzler wrote:
> Zudem gibt es einzelne Geräte (C7v2 mit zweitem eth am Switch), wo man dann den zweiten CPU-Port trotzdem eintragen müsste usw., was auch nicht gerade konsistent ist.
Das halte ich nach wie vor für einen Fehler, dass das überhaupt so gemacht wurde. Ich bin mir relativ sicher, dass der C7v2 auch mit einem CPU Port im Switch funktioniert, analog zu allen anderen Geräten.
Möglicherweise war da damals ein Bug im OpenWRT für dieses Gerät.

Ich finde die Lösung mit dem Switch-Case Skript eigentlich gar nicht schlecht..

Gruß
Fabian
Adrian Schmutzler May 15, 2019, 10:01 p.m. 
Hallo Fabian,

 

theoretisch kann man natürlich auch alle Ports nur an eth0 oder eth1 hängen, ja.

Dann wirft man halt das zweite eth weg.

Wenn man zwei Netze für wan und lan hat will man aber halt u.U. jeweils ein eth pro Netz. In der Praxis ist das aber wahrscheinlich nur relevant, wenn du am WAN und am LAN in Richtung Gbps gehst und dann zwischen denen routen willst.

 

Grüße

 

Adrian

 

From: Fabian Bläse [mailto:fabian@blaese.de] 
Sent: Mittwoch, 15. Mai 2019 23:27
To: Adrian Schmutzler <mail@adrianschmutzler.de>; franken-dev@freifunk.net
Subject: Re: [PATCH v3 3/3] gateway.d: Add scripts for network configuration

 

Hallo Adrian, 

On 15.05.19 16:43, Adrian Schmutzler wrote: 
> Zudem gibt es einzelne Geräte (C7v2 mit zweitem eth am Switch), wo man dann den zweiten CPU-Port trotzdem eintragen müsste usw., was auch nicht gerade konsistent ist.

Das halte ich nach wie vor für einen Fehler, dass das überhaupt so gemacht wurde. Ich bin mir relativ sicher, dass der C7v2 auch mit einem CPU Port im Switch funktioniert, analog zu allen anderen Geräten.

Möglicherweise war da damals ein Bug im OpenWRT für dieses Gerät. 

Ich finde die Lösung mit dem Switch-Case Skript eigentlich gar nicht schlecht.. 

Gruß 
Fabian
Fabian Blaese May 15, 2019, 10:06 p.m. 
On 16.05.19 00:01, mail@adrianschmutzler.de wrote:
> theoretisch kann man natürlich auch alle Ports nur an eth0 oder eth1 hängen, ja.
> 
> Dann wirft man halt das zweite eth weg.
Jo, das machen wir auch bei allen Geräten außer dem C7v2 so. ;-)

> Wenn man zwei Netze für wan und lan hat will man aber halt u.U. jeweils ein eth pro Netz. In der Praxis ist das aber wahrscheinlich nur relevant, wenn du am WAN und am LAN in Richtung Gbps gehst und dann zwischen denen routen willst.
Da das Interface zur CPU als Vollduplex ausgelegt ist [sein müsste], ist selbst Gigabit in eine Richtung kein Problem. Nur mit Vollduplex Gigabit wird es dann eng.
Dafür sind die Büchsen aber sowieso allesamt zu langsam. Das einzige Gerät welches überhaupt 1GBit/s Routing in eine Richtung schafft, das mir auf die schnelle einfällt, ist der Edgerouter X. Und der hat nur ein CPU Interface.. ;-)

Gruß
Fabian