[RFC,4/4] add package fff-tunneldigger-testing

Submitted by Robert Langhammer on April 5, 2016, 12:31 p.m.

Details

Message ID 1459859465-2158-5-git-send-email-rlanghammer@web.de
State Superseded, archived
Headers show

Commit Message

Robert Langhammer April 5, 2016, 12:31 p.m. 
Signed-off-by: Robert Langhammer <rlanghammer@web.de>
---
 src/packages/fff/fff-tunneldigger-testing/Makefile |  42 ++++++
 .../files/etc/hotplug.d/iface/60-tunnelstart       |   6 +
 .../files/usr/lib/micron.d/fff-tunnelstart         |   1 +
 .../files/usr/sbin/tunnelstart                     | 156 +++++++++++++++++++++
 src/packages/fff/fff/Makefile                      |   3 +-
 5 files changed, 207 insertions(+), 1 deletion(-)
 create mode 100644 src/packages/fff/fff-tunneldigger-testing/Makefile
 create mode 100644 src/packages/fff/fff-tunneldigger-testing/files/etc/hotplug.d/iface/60-tunnelstart
 create mode 100644 src/packages/fff/fff-tunneldigger-testing/files/usr/lib/micron.d/fff-tunnelstart
 create mode 100755 src/packages/fff/fff-tunneldigger-testing/files/usr/sbin/tunnelstart

Patch hide | download patch | download mbox 

diff --git a/src/packages/fff/fff-tunneldigger-testing/Makefile b/src/packages/fff/fff-tunneldigger-testing/Makefile
new file mode 100644
index 0000000..55212d3
--- /dev/null
+++ b/src/packages/fff/fff-tunneldigger-testing/Makefile
@@ -0,0 +1,42 @@ 
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=fff-tunneldigger-testing
+PKG_VERSION:=1
+PKG_RELEASE:=1
+
+PKG_BUILD_DIR:=$(BUILD_DIR)/fff-tunneldigger-testing
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/fff-tunneldigger-testing
+    SECTION:=base
+    CATEGORY:=Freifunk
+    TITLE:= Freifunk-Franken tunneldigger
+    URL:=http://www.freifunk-franken.de
+    DEPENDS:=+tunneldigger +fff-tunneldigger
+endef
+
+define Package/fff-tunneldigger-testing/description
+    This is a temporarily package and will be removed 
+    after testing stage.
+endef
+
+define Build/Prepare
+       echo "all: " > $(PKG_BUILD_DIR)/Makefile
+endef
+
+define Build/Configure
+       # nothing
+endef
+
+define Build/Compile
+       # nothing
+endef
+
+define Package/fff-tunneldigger-testing/install
+    # nothing
+endef
+
+$(eval $(call BuildPackage,fff-tunneldigger-testing))
+
+
diff --git a/src/packages/fff/fff-tunneldigger-testing/files/etc/hotplug.d/iface/60-tunnelstart b/src/packages/fff/fff-tunneldigger-testing/files/etc/hotplug.d/iface/60-tunnelstart
new file mode 100644
index 0000000..460ca32
--- /dev/null
+++ b/src/packages/fff/fff-tunneldigger-testing/files/etc/hotplug.d/iface/60-tunnelstart
@@ -0,0 +1,6 @@ 
+#!/bin/sh 
+[ "$ACTION" = "ifup" -a "$INTERFACE" = "wan" ] && {
+	sleep 3
+	sh /usr/sbin/tunnelstart
+}
+
diff --git a/src/packages/fff/fff-tunneldigger-testing/files/usr/lib/micron.d/fff-tunnelstart b/src/packages/fff/fff-tunneldigger-testing/files/usr/lib/micron.d/fff-tunnelstart
new file mode 100644
index 0000000..44c7acc
--- /dev/null
+++ b/src/packages/fff/fff-tunneldigger-testing/files/usr/lib/micron.d/fff-tunnelstart
@@ -0,0 +1 @@ 
+*/5 * * * * sleep $(/usr/bin/random 0 29); sh /usr/sbin/tunnelstart
diff --git a/src/packages/fff/fff-tunneldigger-testing/files/usr/sbin/tunnelstart b/src/packages/fff/fff-tunneldigger-testing/files/usr/sbin/tunnelstart
new file mode 100755
index 0000000..4c15cb5
--- /dev/null
+++ b/src/packages/fff/fff-tunneldigger-testing/files/usr/sbin/tunnelstart
@@ -0,0 +1,156 @@ 
+#!/bin/sh
+
+SERVER="no"
+#SERVERNAME="--servername--"
+
+project="fff"
+
+test_ipv4_host1="keyserver.freifunk-franken.de" # Freifunk-Franken keyserver
+test_ipv4_host2="8.8.8.8"        # Google DNS
+test_ipv6_host1="heise.de"       # heise Zeitschriftenverlag
+
+if [ "$SERVER" = "no" ]; then
+	test -f /tmp/started || exit
+fi
+
+# Only do something with fastd when the router has internet connection
+if ping -w5 -c3 "$test_ipv4_host1" &>/dev/null || 
+   ping -w5 -c3 "$test_ipv4_host2" &>/dev/null ||
+   ping6 -w5 -c3 "$test_ipv6_host1" &>/dev/null; then
+	mac=$(awk '{ mac=toupper($1); gsub(":", "", mac); print mac }' /sys/class/net/br-mesh/address 2>/dev/null)
+	if [ "$SERVER" = "no" ]; then
+		hostname=$(cat /proc/sys/kernel/hostname)
+
+		if [ "$hostname" = "OpenWrt" ]; then
+			hostname=""
+		fi
+
+		if [ "$hostname" = "" ]; then
+			hostname=$mac
+		fi
+	else
+		hostname=$SERVERNAME
+	fi
+
+
+		if [ ! -d /etc/fastd ]; then
+			mkdir /etc/fastd
+		fi
+
+		if [ ! -d /etc/fastd/$project ]; then
+			mkdir /etc/fastd/$project
+			mkdir /tmp/fastd_${project}_peers
+			ln -s /tmp/fastd_${project}_peers /etc/fastd/$project/peers
+			echo "#!/bin/sh" > /etc/fastd/$project/up.sh
+			echo "ip link set up dev ${project}VPN" >> /etc/fastd/$project/up.sh
+			echo "echo enable > /sys/devices/virtual/net/${project}VPN/batman_adv/no_rebroadcast" >> /etc/fastd/$project/up.sh
+			echo "batctl if add ${project}VPN" >> /etc/fastd/$project/up.sh
+			chmod +x /etc/fastd/$project/up.sh
+			secret=$(fastd --generate-key 2>&1 | grep -i secret | awk '{ print $2 }')
+			echo "include peers from \"/etc/fastd/$project/peers\";" >> /etc/fastd/${project}/${project}.conf
+			echo "log to syslog level warn;" >> /etc/fastd/${project}/${project}.conf
+			echo "method \"null\";" >> /etc/fastd/${project}/${project}.conf
+#			http://lists.nord-west.net/pipermail/freifunk-ol-dev/2013-July/000322.html
+#			echo "bind 0.0.0.0:10000;" >> /etc/fastd/${project}/${project}.conf
+			echo "interface \"${project}VPN\";" >> /etc/fastd/${project}/${project}.conf
+			echo "mtu 1426;" >> /etc/fastd/${project}/${project}.conf
+			echo "secret \"$secret\";" >> /etc/fastd/${project}/${project}.conf
+			echo "on up \"/etc/fastd/${project}/up.sh\";" >> /etc/fastd/${project}/${project}.conf
+			echo "secure handshakes no;" >> /etc/fastd/${project}/${project}.conf
+		fi
+
+		if [ ! -d /tmp/fastd_${project}_peers ]; then
+			mkdir /tmp/fastd_${project}_peers
+		fi	
+
+		pubkey=$(fastd -c /etc/fastd/$project/$project.conf --show-key --machine-readable)
+		lat=$(uci get system.@system[0].latitude)
+		long=$(uci get system.@system[0].longitude)
+
+#		register
+		wget -T15 "http://keyserver.freifunk-franken.de/${project}/geo.php?mac=$mac&name=$hostname&port=$port&key=$pubkey&lat=$lat&long=$long" -O /tmp/fastd_${project}_output
+
+		filenames=$(awk '/^####/ { gsub(/^####/, "", $0); gsub(/.conf/, "", $0); print $0; }' /tmp/fastd_${project}_output)
+		for file in $filenames; do
+			awk "{ if(a) print }; /^####$file.conf$/{a=1}; /^$/{a=0};" /tmp/fastd_${project}_output | sed 's/ float;/;/g' > /etc/fastd/$project/peers/$file
+			echo 'float yes;' >> /etc/fastd/$project/peers/$file
+		done
+
+		# Wir holen uns die Conf fuer l2tp  us den peers des fastd
+		# Dort finden wir die IPs unserer GWs
+		# Die Ports rechnen wir aus den Fastd-ports aus +10000
+
+		CONF="/etc/config/tunneldigger"
+		CONFTMP="/tmp/tunneldigger.conf.tmp"
+		>$CONFTMP
+		count=1
+		PEERS=$(ls /etc/fastd/fff/peers)
+
+		for peer in $PEERS
+		   do
+		      NAME=$(cat /etc/fastd/fff/peers/$peer | grep name | cut -f2 -d "\"")
+		      IP=$(cat /etc/fastd/fff/peers/$peer | grep ipv4 | cut -f2 -d "\"")
+		      PORT=$(cat /etc/fastd/fff/peers/$peer | grep ipv4 | cut -f5 -d " " | tr -dc 0-9)
+		      PORT=$((PORT + 10000))
+		      MAC=$(uci get network.mesh.macaddr)
+		      UUID=_$(cat /proc/sys/kernel/hostname)@$MAC
+		      echo "config broker
+	list address '$IP:$PORT'
+	option uuid '$UUID'
+	option interface 'l2tp$count'
+	option enabled '1'
+	option hook_script '/etc/tunneldigger.hook'
+        " >> $CONFTMP
+		      count=$((count + 1))
+		   done
+		
+		# Hat sich was geaendert?
+		if [diff $CONFTMP $CONF &>/dev/null ]; then 		
+			#die  Broker haben sich geaendert
+			/etc/init.d/tunneldigger stop
+			# pid-files aufräumen
+			rm /var/run/tunneldigger* 2>/dev/null
+			cp $CONFTMP $CONF
+		fi
+
+
+# Jetzt haben wir alle noetigeb Infos eingesammelt
+		# Wir starten den tunneldigger, wenn er schon läuft machts nichts
+		/etc/init.d/tunneldigger start
+		# Startlink anlegen 
+		[ -f /etc/rc.d/S90tunneldigger ] || ln -s ../init.d/tunneldigger /etc/rc.d/S90tunneldigger
+		
+		# tunneldigger bekommt 15s Zeit die Tunnel auf zu bauen
+		sleep 15
+		
+		if [ "ls -d /sys/devices/virtual/net/l2tp* &>/dev/null" ]; then
+			
+			# l2tunnel sind an, fastd stoppen falls er läuft
+			[ -d /sys/devices/virtual/net/fffVPN  ] && kill -SIGTERM $(cat /var/run/fastd.$project.pid)
+		else
+			#die l2tunnel sind nicht an gegangen -> fallback to fastd
+
+#			fire up fastd
+			if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep $project)" = "" ]; then
+				/bin/rm /var/run/fastd.$project.pid 2>/dev/null
+				fastd -c /etc/fastd/$project/$project.conf -d --pid-file /var/run/fastd.$project.pid
+			fi
+
+			#reload
+			kill -HUP $(cat /var/run/fastd.$project.pid)
+ 
+			# tunneldigger ausschalten
+			/etc/init.d/tunneldigger stop
+             		# pid-files aufraumen
+                	rm /var/run/tunneldigger* 2>/dev/null
+			# Startlink loeschen
+			[ -f /etc/rc.d/S90tunneldigger ] && rm /etc/rc.d/S90tunneldigger
+		fi
+
+else
+	echo "Der Router kann keine Verbindung zum Fastdserver aufbauen"
+	echo "$0 macht nichts!"
+fi
+
+exit 0
+# vim: noexpandtab
diff --git a/src/packages/fff/fff/Makefile b/src/packages/fff/fff/Makefile
index d914872..4fbcf30 100644
--- a/src/packages/fff/fff/Makefile
+++ b/src/packages/fff/fff/Makefile
@@ -20,7 +20,8 @@  define Package/fff-base
              +fff-uradvd \
              +fff-batman-adv-legacy \
              +fff-firewall\
-	     +fff-tunneldigger	
+	     +fff-tunneldigger\	
+	     +fff-tunneldigger-testing	
 endef
 
 define Package/fff-base/description

Comments

Tim Niemeyer April 5, 2016, 8:19 p.m. 
Hi

Am Dienstag, den 05.04.2016, 14:31 +0200 schrieb Robert Langhammer:
> Signed-off-by: Robert Langhammer <rlanghammer@web.de>
> ---
>  src/packages/fff/fff-tunneldigger-testing/Makefile |  42 ++++++
>  .../files/etc/hotplug.d/iface/60-tunnelstart       |   6 +
>  .../files/usr/lib/micron.d/fff-tunnelstart         |   1 +
>  .../files/usr/sbin/tunnelstart                     | 156 +++++++++++++++++++++
>  src/packages/fff/fff/Makefile                      |   3 +-
>  5 files changed, 207 insertions(+), 1 deletion(-)
>  create mode 100644 src/packages/fff/fff-tunneldigger-testing/Makefile
>  create mode 100644 src/packages/fff/fff-tunneldigger-testing/files/etc/hotplug.d/iface/60-tunnelstart
>  create mode 100644 src/packages/fff/fff-tunneldigger-testing/files/usr/lib/micron.d/fff-tunnelstart
>  create mode 100755 src/packages/fff/fff-tunneldigger-testing/files/usr/sbin/tunnelstart
> 
> diff --git a/src/packages/fff/fff-tunneldigger-testing/Makefile b/src/packages/fff/fff-tunneldigger-testing/Makefile
> new file mode 100644
> index 0000000..55212d3
> --- /dev/null
> +++ b/src/packages/fff/fff-tunneldigger-testing/Makefile
> @@ -0,0 +1,42 @@
> +include $(TOPDIR)/rules.mk
> +
> +PKG_NAME:=fff-tunneldigger-testing
> +PKG_VERSION:=1
> +PKG_RELEASE:=1
> +
> +PKG_BUILD_DIR:=$(BUILD_DIR)/fff-tunneldigger-testing
> +
> +include $(INCLUDE_DIR)/package.mk
> +
> +define Package/fff-tunneldigger-testing
> +    SECTION:=base
> +    CATEGORY:=Freifunk
> +    TITLE:= Freifunk-Franken tunneldigger
> +    URL:=http://www.freifunk-franken.de
> +    DEPENDS:=+tunneldigger +fff-tunneldigger
Hier stimmt was nicht.

fff-tunneldigger-testing hängt von tunneldigger und fff-tunneldigger ab.
Klingt logisch. Aber fff hängt von fff-tunneldigger ab, welches von
tunneldigger abhängt.
Letztlich wird aber fff-tunneldigger-testing nicht gewählt.

> +endef
> +
> +define Package/fff-tunneldigger-testing/description
> +    This is a temporarily package and will be removed 
> +    after testing stage.

Wenn das nur temporär ist, wo soll die Funktionalität dann später mal
hin? Weiter: Warum entfernst du fastd, wenn dieses nur testing ist?

Ich würde vorschlagen, dass der Inhalt dieses Packages mit in das
fff-tunneldigger kommt. Ich vermute mal, da soll es auch langfristig
hin.

Dann bauen wir fff-tunneldigger und fff-fastd so, dass sie beide
parallel im Image sein können und beide nicht die Vorherschaft
übernehmen.
Ein neues Package "fff-vpn" hängt dann von fff-tunneldigger und
fff-fastd ab. Als Config-Option kann man da drin die default VPN Technik
wählen. fff-vpn aktiviert dann beim firstboot entweder tunneldigger oder
fastd und kann idealerweise mit einem kleinen Befehl zwischen den VPNs
umschalten oder vllt sogar beides gleichzeitig aktivieren?

Tim

> +endef
> +
> +define Build/Prepare
> +       echo "all: " > $(PKG_BUILD_DIR)/Makefile
> +endef
> +
> +define Build/Configure
> +       # nothing
> +endef
> +
> +define Build/Compile
> +       # nothing
> +endef
> +
> +define Package/fff-tunneldigger-testing/install
> +    # nothing
> +endef
> +
> +$(eval $(call BuildPackage,fff-tunneldigger-testing))
> +
> +
> diff --git a/src/packages/fff/fff-tunneldigger-testing/files/etc/hotplug.d/iface/60-tunnelstart b/src/packages/fff/fff-tunneldigger-testing/files/etc/hotplug.d/iface/60-tunnelstart
> new file mode 100644
> index 0000000..460ca32
> --- /dev/null
> +++ b/src/packages/fff/fff-tunneldigger-testing/files/etc/hotplug.d/iface/60-tunnelstart
> @@ -0,0 +1,6 @@
> +#!/bin/sh 
> +[ "$ACTION" = "ifup" -a "$INTERFACE" = "wan" ] && {
> +	sleep 3
> +	sh /usr/sbin/tunnelstart
> +}
> +
> diff --git a/src/packages/fff/fff-tunneldigger-testing/files/usr/lib/micron.d/fff-tunnelstart b/src/packages/fff/fff-tunneldigger-testing/files/usr/lib/micron.d/fff-tunnelstart
> new file mode 100644
> index 0000000..44c7acc
> --- /dev/null
> +++ b/src/packages/fff/fff-tunneldigger-testing/files/usr/lib/micron.d/fff-tunnelstart
> @@ -0,0 +1 @@
> +*/5 * * * * sleep $(/usr/bin/random 0 29); sh /usr/sbin/tunnelstart
> diff --git a/src/packages/fff/fff-tunneldigger-testing/files/usr/sbin/tunnelstart b/src/packages/fff/fff-tunneldigger-testing/files/usr/sbin/tunnelstart
> new file mode 100755
> index 0000000..4c15cb5
> --- /dev/null
> +++ b/src/packages/fff/fff-tunneldigger-testing/files/usr/sbin/tunnelstart
> @@ -0,0 +1,156 @@
> +#!/bin/sh
> +
> +SERVER="no"
> +#SERVERNAME="--servername--"
> +
> +project="fff"
> +
> +test_ipv4_host1="keyserver.freifunk-franken.de" # Freifunk-Franken keyserver
> +test_ipv4_host2="8.8.8.8"        # Google DNS
> +test_ipv6_host1="heise.de"       # heise Zeitschriftenverlag
> +
> +if [ "$SERVER" = "no" ]; then
> +	test -f /tmp/started || exit
> +fi
> +
> +# Only do something with fastd when the router has internet connection
> +if ping -w5 -c3 "$test_ipv4_host1" &>/dev/null || 
> +   ping -w5 -c3 "$test_ipv4_host2" &>/dev/null ||
> +   ping6 -w5 -c3 "$test_ipv6_host1" &>/dev/null; then
> +	mac=$(awk '{ mac=toupper($1); gsub(":", "", mac); print mac }' /sys/class/net/br-mesh/address 2>/dev/null)
> +	if [ "$SERVER" = "no" ]; then
> +		hostname=$(cat /proc/sys/kernel/hostname)
> +
> +		if [ "$hostname" = "OpenWrt" ]; then
> +			hostname=""
> +		fi
> +
> +		if [ "$hostname" = "" ]; then
> +			hostname=$mac
> +		fi
> +	else
> +		hostname=$SERVERNAME
> +	fi
> +
> +
> +		if [ ! -d /etc/fastd ]; then
> +			mkdir /etc/fastd
> +		fi
> +
> +		if [ ! -d /etc/fastd/$project ]; then
> +			mkdir /etc/fastd/$project
> +			mkdir /tmp/fastd_${project}_peers
> +			ln -s /tmp/fastd_${project}_peers /etc/fastd/$project/peers
> +			echo "#!/bin/sh" > /etc/fastd/$project/up.sh
> +			echo "ip link set up dev ${project}VPN" >> /etc/fastd/$project/up.sh
> +			echo "echo enable > /sys/devices/virtual/net/${project}VPN/batman_adv/no_rebroadcast" >> /etc/fastd/$project/up.sh
> +			echo "batctl if add ${project}VPN" >> /etc/fastd/$project/up.sh
> +			chmod +x /etc/fastd/$project/up.sh
> +			secret=$(fastd --generate-key 2>&1 | grep -i secret | awk '{ print $2 }')
> +			echo "include peers from \"/etc/fastd/$project/peers\";" >> /etc/fastd/${project}/${project}.conf
> +			echo "log to syslog level warn;" >> /etc/fastd/${project}/${project}.conf
> +			echo "method \"null\";" >> /etc/fastd/${project}/${project}.conf
> +#			http://lists.nord-west.net/pipermail/freifunk-ol-dev/2013-July/000322.html
> +#			echo "bind 0.0.0.0:10000;" >> /etc/fastd/${project}/${project}.conf
> +			echo "interface \"${project}VPN\";" >> /etc/fastd/${project}/${project}.conf
> +			echo "mtu 1426;" >> /etc/fastd/${project}/${project}.conf
> +			echo "secret \"$secret\";" >> /etc/fastd/${project}/${project}.conf
> +			echo "on up \"/etc/fastd/${project}/up.sh\";" >> /etc/fastd/${project}/${project}.conf
> +			echo "secure handshakes no;" >> /etc/fastd/${project}/${project}.conf
> +		fi
> +
> +		if [ ! -d /tmp/fastd_${project}_peers ]; then
> +			mkdir /tmp/fastd_${project}_peers
> +		fi	
> +
> +		pubkey=$(fastd -c /etc/fastd/$project/$project.conf --show-key --machine-readable)
> +		lat=$(uci get system.@system[0].latitude)
> +		long=$(uci get system.@system[0].longitude)
> +
> +#		register
> +		wget -T15 "http://keyserver.freifunk-franken.de/${project}/geo.php?mac=$mac&name=$hostname&port=$port&key=$pubkey&lat=$lat&long=$long" -O /tmp/fastd_${project}_output
> +
> +		filenames=$(awk '/^####/ { gsub(/^####/, "", $0); gsub(/.conf/, "", $0); print $0; }' /tmp/fastd_${project}_output)
> +		for file in $filenames; do
> +			awk "{ if(a) print }; /^####$file.conf$/{a=1}; /^$/{a=0};" /tmp/fastd_${project}_output | sed 's/ float;/;/g' > /etc/fastd/$project/peers/$file
> +			echo 'float yes;' >> /etc/fastd/$project/peers/$file
> +		done
> +
> +		# Wir holen uns die Conf fuer l2tp  us den peers des fastd
> +		# Dort finden wir die IPs unserer GWs
> +		# Die Ports rechnen wir aus den Fastd-ports aus +10000
> +
> +		CONF="/etc/config/tunneldigger"
> +		CONFTMP="/tmp/tunneldigger.conf.tmp"
> +		>$CONFTMP
> +		count=1
> +		PEERS=$(ls /etc/fastd/fff/peers)
> +
> +		for peer in $PEERS
> +		   do
> +		      NAME=$(cat /etc/fastd/fff/peers/$peer | grep name | cut -f2 -d "\"")
> +		      IP=$(cat /etc/fastd/fff/peers/$peer | grep ipv4 | cut -f2 -d "\"")
> +		      PORT=$(cat /etc/fastd/fff/peers/$peer | grep ipv4 | cut -f5 -d " " | tr -dc 0-9)
> +		      PORT=$((PORT + 10000))
> +		      MAC=$(uci get network.mesh.macaddr)
> +		      UUID=_$(cat /proc/sys/kernel/hostname)@$MAC
> +		      echo "config broker
> +	list address '$IP:$PORT'
> +	option uuid '$UUID'
> +	option interface 'l2tp$count'
> +	option enabled '1'
> +	option hook_script '/etc/tunneldigger.hook'
> +        " >> $CONFTMP
> +		      count=$((count + 1))
> +		   done
> +		
> +		# Hat sich was geaendert?
> +		if [diff $CONFTMP $CONF &>/dev/null ]; then 		
> +			#die  Broker haben sich geaendert
> +			/etc/init.d/tunneldigger stop
> +			# pid-files aufräumen
> +			rm /var/run/tunneldigger* 2>/dev/null
> +			cp $CONFTMP $CONF
> +		fi
> +
> +
> +# Jetzt haben wir alle noetigeb Infos eingesammelt
> +		# Wir starten den tunneldigger, wenn er schon läuft machts nichts
> +		/etc/init.d/tunneldigger start
> +		# Startlink anlegen 
> +		[ -f /etc/rc.d/S90tunneldigger ] || ln -s ../init.d/tunneldigger /etc/rc.d/S90tunneldigger
> +		
> +		# tunneldigger bekommt 15s Zeit die Tunnel auf zu bauen
> +		sleep 15
> +		
> +		if [ "ls -d /sys/devices/virtual/net/l2tp* &>/dev/null" ]; then
> +			
> +			# l2tunnel sind an, fastd stoppen falls er läuft
> +			[ -d /sys/devices/virtual/net/fffVPN  ] && kill -SIGTERM $(cat /var/run/fastd.$project.pid)
> +		else
> +			#die l2tunnel sind nicht an gegangen -> fallback to fastd
> +
> +#			fire up fastd
> +			if [ "$(/sbin/ifconfig -a | grep -i ethernet | grep $project)" = "" ]; then
> +				/bin/rm /var/run/fastd.$project.pid 2>/dev/null
> +				fastd -c /etc/fastd/$project/$project.conf -d --pid-file /var/run/fastd.$project.pid
> +			fi
> +
> +			#reload
> +			kill -HUP $(cat /var/run/fastd.$project.pid)
> + 
> +			# tunneldigger ausschalten
> +			/etc/init.d/tunneldigger stop
> +             		# pid-files aufraumen
> +                	rm /var/run/tunneldigger* 2>/dev/null
> +			# Startlink loeschen
> +			[ -f /etc/rc.d/S90tunneldigger ] && rm /etc/rc.d/S90tunneldigger
> +		fi
> +
> +else
> +	echo "Der Router kann keine Verbindung zum Fastdserver aufbauen"
> +	echo "$0 macht nichts!"
> +fi
> +
> +exit 0
> +# vim: noexpandtab
> diff --git a/src/packages/fff/fff/Makefile b/src/packages/fff/fff/Makefile
> index d914872..4fbcf30 100644
> --- a/src/packages/fff/fff/Makefile
> +++ b/src/packages/fff/fff/Makefile
> @@ -20,7 +20,8 @@ define Package/fff-base
>               +fff-uradvd \
>               +fff-batman-adv-legacy \
>               +fff-firewall\
> -	     +fff-tunneldigger	
> +	     +fff-tunneldigger\	
> +	     +fff-tunneldigger-testing	
>  endef
>  
>  define Package/fff-base/description
> -- 
> 2.8.0.rc3
>
Robert Langhammer April 5, 2016, 9:54 p.m. 
Hallo Tim,


Am 05.04.2016 um 22:19 schrieb Tim Niemeyer:
> Hi
>
> Am Dienstag, den 05.04.2016, 14:31 +0200 schrieb Robert Langhammer:
>> +define Package/fff-tunneldigger-testing
>> +    SECTION:=base
>> +    CATEGORY:=Freifunk
>> +    TITLE:= Freifunk-Franken tunneldigger
>> +    URL:=http://www.freifunk-franken.de
>> +    DEPENDS:=+tunneldigger +fff-tunneldigger
> Hier stimmt was nicht.
>
> fff-tunneldigger-testing hängt von tunneldigger und fff-tunneldigger ab.
> Klingt logisch. Aber fff hängt von fff-tunneldigger ab, welches von
> tunneldigger abhängt.
> Letztlich wird aber fff-tunneldigger-testing nicht gewählt.
Genau, da habe ich vorhin schon viel gelernt.
>
>> +endef
>> +
>> +define Package/fff-tunneldigger-testing/description
>> +    This is a temporarily package and will be removed 
>> +    after testing stage.
> Wenn das nur temporär ist, wo soll die Funktionalität dann später mal
> hin? Weiter: Warum entfernst du fastd, wenn dieses nur testing ist?
>
> Ich würde vorschlagen, dass der Inhalt dieses Packages mit in das
> fff-tunneldigger kommt. Ich vermute mal, da soll es auch langfristig
> hin.
>
> Dann bauen wir fff-tunneldigger und fff-fastd so, dass sie beide
> parallel im Image sein können und beide nicht die Vorherschaft
> übernehmen.
> Ein neues Package "fff-vpn" hängt dann von fff-tunneldigger und
> fff-fastd ab. Als Config-Option kann man da drin die default VPN Technik
> wählen. fff-vpn aktiviert dann beim firstboot entweder tunneldigger oder
> fastd und kann idealerweise mit einem kleinen Befehl zwischen den VPNs
> umschalten oder vllt sogar beides gleichzeitig aktivieren?
>
> Tim
Ich denke auch, dass wir da hin kommen sollten. Mir gefällt die Idee,
das offen und modular zu machen, dann kann jeder der mag seine
VPN-Lösung einbauen.

Im Moment ist es so, dass nur wenige Gateways einen Broker haben und ich
versucht habe darauf dynamisch zu reagieren. Ich wollte nicht im
fff-fastd irgend was einbauen, was wir später nicht mehr brauchen und
diese Art hier den tunneldigger zu konfigurieren werden wir auch nicht
übernehmen. Das ist absolut keine gute Lösung. Darum dieses package, das
erst mal eine fall-back Lösung ist mit bevorzugtem l2tp.
 
Wir haben hier in der Hasberg Hood bis jetzt 5 l2tunnel. Da können wir
eigentlich noch keine Aussage treffen, ob l2tp überhaupt eine stabile
Alternative ist, und wir die Sache richtig einbauen sollten.
Die Idee ist, mit einer Firmware für Interessierte, die man einfach nur
flasht und wenn l2tp nicht geht fastd macht, noch ein paar Tunnel mehr
zu bekommen. 
Dann können wir sehen, was die Gateways machen.

Falls wir uns dafür entscheiden l2tp auf zu nehmen und wir einen Weg
haben die Broker an die Router zu verteilen (irgend ein keyxchange ) ist
das fff-tunneldigger schnell gebaut

Wie müssen die Einrückungen sein? Tabs oder nur einheitlich?

Sory wegen dem Wlanslovenia Patch. Mir ist es nicht gelungen den
einzuspielen, Fehlermeldungen. Da ich mich mit git noch nicht so gut
auskenne, habe ich einfach deine Anleitung nochmal abgetippt. Dann ging es.

Testen von Vars in "" ist klar. Das kommt von copy and paste ohne
Hirnaktivität. Danke!

Robert

>
Christian Dresel April 6, 2016, 4:20 a.m. 
Guten Morgen

> Robert <rlanghammer@web.de> hat am 5. April 2016 um 23:54 geschrieben:
> 
> Hallo Tim,
> 
> Am 05.04.2016 um 22:19 schrieb Tim Niemeyer:
> > Hi
> >
> > Am Dienstag, den 05.04.2016, 14:31 +0200 schrieb Robert Langhammer:
> >> +define Package/fff-tunneldigger-testing
> >> + SECTION:=base
> >> + CATEGORY:=Freifunk
> >> + TITLE:= Freifunk-Franken tunneldigger
> >> + URL:=http://www.freifunk-franken.de
> >> + DEPENDS:=+tunneldigger +fff-tunneldigger
> > Hier stimmt was nicht.
> >
> > fff-tunneldigger-testing hängt von tunneldigger und fff-tunneldigger ab.
> > Klingt logisch. Aber fff hängt von fff-tunneldigger ab, welches von
> > tunneldigger abhängt.
> > Letztlich wird aber fff-tunneldigger-testing nicht gewählt.
> Genau, da habe ich vorhin schon viel gelernt.
> >
> >> +endef
> >> +
> >> +define Package/fff-tunneldigger-testing/description
> >> + This is a temporarily package and will be removed 
> >> + after testing stage.
> > Wenn das nur temporär ist, wo soll die Funktionalität dann später mal
> > hin? Weiter: Warum entfernst du fastd, wenn dieses nur testing ist?
> >
> > Ich würde vorschlagen, dass der Inhalt dieses Packages mit in das
> > fff-tunneldigger kommt. Ich vermute mal, da soll es auch langfristig
> > hin.
> >
> > Dann bauen wir fff-tunneldigger und fff-fastd so, dass sie beide
> > parallel im Image sein können und beide nicht die Vorherschaft
> > übernehmen.
> > Ein neues Package "fff-vpn" hängt dann von fff-tunneldigger und
> > fff-fastd ab. Als Config-Option kann man da drin die default VPN Technik
> > wählen. fff-vpn aktiviert dann beim firstboot entweder tunneldigger oder
> > fastd und kann idealerweise mit einem kleinen Befehl zwischen den VPNs
> > umschalten oder vllt sogar beides gleichzeitig aktivieren?
> >
> > Tim
> Ich denke auch, dass wir da hin kommen sollten. Mir gefällt die Idee,
> das offen und modular zu machen, dann kann jeder der mag seine
> VPN-Lösung einbauen.
> 
> Im Moment ist es so, dass nur wenige Gateways einen Broker haben und ich
> versucht habe darauf dynamisch zu reagieren. Ich wollte nicht im

Kann man dieses dynamische reagieren dann nicht ins fff-vpn einbauen?

Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
wenn nein schalte auf fastd um
mehr muss dieses fff-vpn ja schon fast nicht tun.

Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen Tunneldigger
verwenden will (warum auch immer) und man ist flexibel und deckt alles ab was
bisher hier so genannt wurde. Wenn man es weiter spinnt kann man auch noch
anzeigen machen zu welchen GW man verbunden ist usw... 

> fff-fastd irgend was einbauen, was wir später nicht mehr brauchen und
> diese Art hier den tunneldigger zu konfigurieren werden wir auch nicht
> übernehmen. Das ist absolut keine gute Lösung. Darum dieses package, das
> erst mal eine fall-back Lösung ist mit bevorzugtem l2tp.
> 
> Wir haben hier in der Hasberg Hood bis jetzt 5 l2tunnel. Da können wir
> eigentlich noch keine Aussage treffen, ob l2tp überhaupt eine stabile
> Alternative ist, und wir die Sache richtig einbauen sollten.
> Die Idee ist, mit einer Firmware für Interessierte, die man einfach nur

ich würde schon eher sagen das soll in unsere Hauptfirmware. Es gibt ja bereits
eine "Firmware für interessierte" du siehst ja wie extrem stark die genutzt
wird... *Ironie* ;)

mfg

Christian

> flasht und wenn l2tp nicht geht fastd macht, noch ein paar Tunnel mehr
> zu bekommen. 
> Dann können wir sehen, was die Gateways machen.
> 
> Falls wir uns dafür entscheiden l2tp auf zu nehmen und wir einen Weg
> haben die Broker an die Router zu verteilen (irgend ein keyxchange ) ist
> das fff-tunneldigger schnell gebaut
> 
> Wie müssen die Einrückungen sein? Tabs oder nur einheitlich?
> 
> Sory wegen dem Wlanslovenia Patch. Mir ist es nicht gelungen den
> einzuspielen, Fehlermeldungen. Da ich mich mit git noch nicht so gut
> auskenne, habe ich einfach deine Anleitung nochmal abgetippt. Dann ging es.
> 
> Testen von Vars in "" ist klar. Das kommt von copy and paste ohne
> Hirnaktivität. Danke!
> 
> Robert
> 
> >
> 
> -- 
> franken-dev mailing list
> franken-dev@freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
Tim Niemeyer April 6, 2016, 6:13 a.m. 
Hi

Am 5. April 2016 23:54:02 MESZ, schrieb Robert <rlanghammer@web.de>:
>Hallo Tim,
>
>
>Am 05.04.2016 um 22:19 schrieb Tim Niemeyer:
>> Hi
>>
>> Am Dienstag, den 05.04.2016, 14:31 +0200 schrieb Robert Langhammer:
>>> +define Package/fff-tunneldigger-testing
>>> +    SECTION:=base
>>> +    CATEGORY:=Freifunk
>>> +    TITLE:= Freifunk-Franken tunneldigger
>>> +    URL:=http://www.freifunk-franken.de
>>> +    DEPENDS:=+tunneldigger +fff-tunneldigger
>> Hier stimmt was nicht.
>>
>> fff-tunneldigger-testing hängt von tunneldigger und fff-tunneldigger
>ab.
>> Klingt logisch. Aber fff hängt von fff-tunneldigger ab, welches von
>> tunneldigger abhängt.
>> Letztlich wird aber fff-tunneldigger-testing nicht gewählt.
>Genau, da habe ich vorhin schon viel gelernt.
>>
>>> +endef
>>> +
>>> +define Package/fff-tunneldigger-testing/description
>>> +    This is a temporarily package and will be removed 
>>> +    after testing stage.
>> Wenn das nur temporär ist, wo soll die Funktionalität dann später mal
>> hin? Weiter: Warum entfernst du fastd, wenn dieses nur testing ist?
>>
>> Ich würde vorschlagen, dass der Inhalt dieses Packages mit in das
>> fff-tunneldigger kommt. Ich vermute mal, da soll es auch langfristig
>> hin.
>>
>> Dann bauen wir fff-tunneldigger und fff-fastd so, dass sie beide
>> parallel im Image sein können und beide nicht die Vorherschaft
>> übernehmen.
>> Ein neues Package "fff-vpn" hängt dann von fff-tunneldigger und
>> fff-fastd ab. Als Config-Option kann man da drin die default VPN
>Technik
>> wählen. fff-vpn aktiviert dann beim firstboot entweder tunneldigger
>oder
>> fastd und kann idealerweise mit einem kleinen Befehl zwischen den
>VPNs
>> umschalten oder vllt sogar beides gleichzeitig aktivieren?
>>
>> Tim
>Ich denke auch, dass wir da hin kommen sollten. Mir gefällt die Idee,
>das offen und modular zu machen, dann kann jeder der mag seine
>VPN-Lösung einbauen.
>
>Im Moment ist es so, dass nur wenige Gateways einen Broker haben und
>ich
>versucht habe darauf dynamisch zu reagieren. Ich wollte nicht im
>fff-fastd irgend was einbauen, was wir später nicht mehr brauchen und
>diese Art hier den tunneldigger zu konfigurieren werden wir auch nicht
>übernehmen. Das ist absolut keine gute Lösung. Darum dieses package,
>das
>erst mal eine fall-back Lösung ist mit bevorzugtem l2tp.
> 
>Wir haben hier in der Hasberg Hood bis jetzt 5 l2tunnel. Da können wir
>eigentlich noch keine Aussage treffen, ob l2tp überhaupt eine stabile
>Alternative ist, und wir die Sache richtig einbauen sollten.
>Die Idee ist, mit einer Firmware für Interessierte, die man einfach nur
>flasht und wenn l2tp nicht geht fastd macht, noch ein paar Tunnel mehr
>zu bekommen. 
>Dann können wir sehen, was die Gateways machen.
>
>Falls wir uns dafür entscheiden l2tp auf zu nehmen und wir einen Weg
>haben die Broker an die Router zu verteilen (irgend ein keyxchange )
>ist
>das fff-tunneldigger schnell gebaut
>
>Wie müssen die Einrückungen sein? Tabs oder nur einheitlich?

Ich orientiere mich an den Sachen, die schon in der Datei sind.

Sowohl Spaces als auch Tabs haben ihre Vor und Nachteile. Afaik haben wir das aber sogar mal diskutiert und die meisten hatten sich für Spaces ausgesprochen, bis das Argument mit den bash here scripten (cat <<<eof ..) kam.

>Sory wegen dem Wlanslovenia Patch. Mir ist es nicht gelungen den
>einzuspielen, Fehlermeldungen. Da ich mich mit git noch nicht so gut
>auskenne, habe ich einfach deine Anleitung nochmal abgetippt. Dann ging
>es.

Ja, kein Problem. Is ja kein Ding.

Meld dich, wenn du irgendwo mit git nicht klar kommst. Hilfe gibts in der Community immer :)

Tim

>Testen von Vars in "" ist klar. Das kommt von copy and paste ohne
>Hirnaktivität. Danke!
>
>Robert
>
>>
>
>
>
>
>------------------------------------------------------------------------
Robert Langhammer April 6, 2016, 8:09 a.m. 
Hallo,

On 06.04.2016 06:20, Christian Dresel wrote:
> Guten Morgen
>
> Kann man dieses dynamische reagieren dann nicht ins fff-vpn einbauen?
>
> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
> wenn nein schalte auf fastd um
> mehr muss dieses fff-vpn ja schon fast nicht tun.
>
> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen Tunneldigger
> verwenden will (warum auch immer) und man ist flexibel und deckt alles ab was
> bisher hier so genannt wurde. Wenn man es weiter spinnt kann man auch noch
> anzeigen machen zu welchen GW man verbunden ist usw... 
>
> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es gibt ja bereits
> eine "Firmware für interessierte" du siehst ja wie extrem stark die genutzt
> wird... *Ironie* ;)
Ja, und es steckt viel Wahrheit drin, die man gern vergisst, wenn man am
Router rum bastelt.
Eigentlich will keiner der Routeraufsteller gefragt werden, ob er lieber
fastd oder l2tp verwenden möchte, es muss gehen.
Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil auf den
Gateways fastd sehr viel CPU braucht und man sich von l2tp Verbesserung
erhofft.
Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre gut,
wenn ich am Gateway sagen kann, ich biete diesen oder jenen Tunnel an
und die Router bekommen das mitgeteilt und machen.

Hier ist immer wieder vom dezentralen keyXchange die Rede, der diese
Informationen verteilen würde. Gibt es dazu schon etwas zum schlau machen?

Robert
> mfg
>
> Christian
>
>> -- 
>> franken-dev mailing list
>> franken-dev@freifunk.net
>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
Moexe April 6, 2016, 8:39 a.m. 
Hi

> Am 06.04.2016 um 10:09 schrieb Robert Langhammer <rlanghammer@web.de>:
> 
> Hallo,
> 
>> On 06.04.2016 06:20, Christian Dresel wrote:
>> Guten Morgen
>> 
>> Kann man dieses dynamische reagieren dann nicht ins fff-vpn einbauen?
>> 
>> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
>> wenn nein schalte auf fastd um
>> mehr muss dieses fff-vpn ja schon fast nicht tun.
>> 
>> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen Tunneldigger
>> verwenden will (warum auch immer) und man ist flexibel und deckt alles ab was
>> bisher hier so genannt wurde. Wenn man es weiter spinnt kann man auch noch
>> anzeigen machen zu welchen GW man verbunden ist usw... 
>> 
>> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es gibt ja bereits
>> eine "Firmware für interessierte" du siehst ja wie extrem stark die genutzt
>> wird... *Ironie* ;)
> Ja, und es steckt viel Wahrheit drin, die man gern vergisst, wenn man am
> Router rum bastelt.
> Eigentlich will keiner der Routeraufsteller gefragt werden, ob er lieber
> fastd oder l2tp verwenden möchte, es muss gehen.
> Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil auf den
> Gateways fastd sehr viel CPU braucht und man sich von l2tp Verbesserung
> erhofft.
> Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre gut,
> wenn ich am Gateway sagen kann, ich biete diesen oder jenen Tunnel an
> und die Router bekommen das mitgeteilt und machen.
Sehe ich genauso.
> 
> Hier ist immer wieder vom dezentralen keyXchange die Rede, der diese
> Informationen verteilen würde. Gibt es dazu schon etwas zum schlau machen?
> 
Hier gibt's schon was: 

https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement

Grüße 

Moexe
> Robert
>> mfg
>> 
>> Christian
>> 
>>> -- 
>>> franken-dev mailing list
>>> franken-dev@freifunk.net
>>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> 
> -- 
> franken-dev mailing list
> franken-dev@freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
Christian Dresel April 6, 2016, 9:11 a.m. 
Hi

dann seh ich das richtig das wir praktisch alle 3 der gleichen Meinung sind:

"Der Router soll anhand des Gateways auswählen was er nutzt, der User soll
keinen (oder vllt. über einen "Expertenmodus" im WebUI?) Einfluss darauf haben"

Was haltet ihr dann von der Idee das so zu lösen wie ich es jetzt aus den ganzen
Meinungen zusammen gesammelt habe:

Es gibt ein fff-vpn Packages, dieses prüft was der Gateway unterstützt und
aktiviert dann (über die /usr/sbin/fastdstart was fff-fastd anlegt bzw.
/usr/sbin/l2tpstart was das fff-tunneldigger anlegt) das richtige.
/usr/sbin/l2tpstart macht im Prinzip das gleiche wie das fastdstart mit
keyxchange und bimmbalabim nur das es eben l2tp startet und fastd "blockiert"
(wie auch immer das am Ende aussieht oder nutzt man doch beides pararell wenn
beides von den GWs untersützt wird?). Bevorzugt nutzt es l2tp weil es besser
ist.

Oder lagert man das ganze "Prüfe ob Internet und Keyxchange Gedöns Daten ziehen
und abgleichen" ins fff-vpn aus und startet dann nur noch das entsprechende
fff-fastdstart oder fff-tunneldigger aus dem fff-vpn? Gefällt mir fast noch
besser ist mir gerade gekommen die Idee muss man nochmal drüber nachdenken ob
das $"so einfach"$ ist.

Sollten wir feststellen "ou l2tp ist kaputt das können wir nicht nutzten weil
wegen scheiße" stellen wir es an den Gateways ab und die Router springen alle
automatisch auf fastd um.

Gibt es noch weitere Meinungen zu diesen vorgehen?

mfg

Christian

> 
>     Moexe <moexe@freifunk-franken-hassfurt.de> hat am 6. April 2016 um 10:39
> geschrieben:
> 
> 
>     Hi
> 
>     > Am 06.04.2016 um 10:09 schrieb Robert Langhammer <rlanghammer@web.de>:
>     >
>     > Hallo,
>     >
>     >> On 06.04.2016 06:20, Christian Dresel wrote:
>     >> Guten Morgen
>     >>
>     >> Kann man dieses dynamische reagieren dann nicht ins fff-vpn einbauen?
>     >>
>     >> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
>     >> wenn nein schalte auf fastd um
>     >> mehr muss dieses fff-vpn ja schon fast nicht tun.
>     >>
>     >> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen
>     >> Tunneldigger
>     >> verwenden will (warum auch immer) und man ist flexibel und deckt alles
>     >> ab was
>     >> bisher hier so genannt wurde. Wenn man es weiter spinnt kann man auch
>     >> noch
>     >> anzeigen machen zu welchen GW man verbunden ist usw...
>     >>
>     >> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es gibt ja
>     >> bereits
>     >> eine "Firmware für interessierte" du siehst ja wie extrem stark die
>     >> genutzt
>     >> wird... *Ironie* ;)
>     > Ja, und es steckt viel Wahrheit drin, die man gern vergisst, wenn man am
>     > Router rum bastelt.
>     > Eigentlich will keiner der Routeraufsteller gefragt werden, ob er lieber
>     > fastd oder l2tp verwenden möchte, es muss gehen.
>     > Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil auf den
>     > Gateways fastd sehr viel CPU braucht und man sich von l2tp Verbesserung
>     > erhofft.
>     > Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre gut,
>     > wenn ich am Gateway sagen kann, ich biete diesen oder jenen Tunnel an
>     > und die Router bekommen das mitgeteilt und machen.
>     Sehe ich genauso.
>     >
>     > Hier ist immer wieder vom dezentralen keyXchange die Rede, der diese
>     > Informationen verteilen würde. Gibt es dazu schon etwas zum schlau
>     > machen?
>     >
>     Hier gibt's schon was:
> 
>     https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement
> 
>     Grüße
> 
>     Moexe
>     > Robert
>     >> mfg
>     >>
>     >> Christian
>     >>
>     >>> --
>     >>> franken-dev mailing list
>     >>> franken-dev@freifunk.net
>     >>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>     >
>     > --
>     > franken-dev mailing list
>     > franken-dev@freifunk.net
>     > http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>     --
>     franken-dev mailing list
>     franken-dev@freifunk.net
>     http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>
Alex Gutfried April 6, 2016, 9:27 a.m. 
Bevor wir diese Firmware veröffentlichen muss aber sicher gestellt werden
das annähernd alle GWs den l2tp broker eingerichtet haben.
Okay wenn keiner da ist, nutzen alle fastd doch wenn ein Gateway den Broker
hat verbinden sich alle Router (mit aktueller Firmware) mit diesen einen
Server. Hm da macht sie gw selection auch nicht mehr viel. ;)
Am 06.04.2016 11:12 vorm. schrieb "Christian Dresel" <fff@chrisi01.de>:

> Hi
>
> dann seh ich das richtig das wir praktisch alle 3 der gleichen Meinung
> sind:
>
> "Der Router soll anhand des Gateways auswählen was er nutzt, der User soll
> keinen (oder vllt. über einen "Expertenmodus" im WebUI?) Einfluss darauf
> haben"
>
> Was haltet ihr dann von der Idee das so zu lösen wie ich es jetzt aus den
> ganzen Meinungen zusammen gesammelt habe:
>
> Es gibt ein fff-vpn Packages, dieses prüft was der Gateway unterstützt und
> aktiviert dann (über die /usr/sbin/fastdstart was fff-fastd anlegt bzw.
> /usr/sbin/l2tpstart was das fff-tunneldigger anlegt) das richtige.
> /usr/sbin/l2tpstart macht im Prinzip das gleiche wie das fastdstart mit
> keyxchange und bimmbalabim nur das es eben l2tp startet und fastd
> "blockiert" (wie auch immer das am Ende aussieht oder nutzt man doch beides
> pararell wenn beides von den GWs untersützt wird?). Bevorzugt nutzt es l2tp
> weil es besser ist.
>
> Oder lagert man das ganze "Prüfe ob Internet und Keyxchange Gedöns
> Daten ziehen und abgleichen" ins fff-vpn aus und startet dann nur noch das
> entsprechende fff-fastdstart oder fff-tunneldigger aus dem fff-vpn? Gefällt
> mir fast noch besser ist mir gerade gekommen die Idee muss man nochmal
> drüber nachdenken ob das $"so einfach"$ ist.
>
> Sollten wir feststellen "ou l2tp ist kaputt das können wir nicht nutzten
> weil wegen scheiße" stellen wir es an den Gateways ab und die Router
> springen alle automatisch auf fastd um.
>
> Gibt es noch weitere Meinungen zu diesen vorgehen?
>
> mfg
>
> Christian
>
> Moexe <moexe@freifunk-franken-hassfurt.de> hat am 6. April 2016 um 10:39
> geschrieben:
>
>
> Hi
>
> > Am 06.04.2016 um 10:09 schrieb Robert Langhammer <rlanghammer@web.de>:
> >
> > Hallo,
> >
> >> On 06.04.2016 06:20, Christian Dresel wrote:
> >> Guten Morgen
> >>
> >> Kann man dieses dynamische reagieren dann nicht ins fff-vpn einbauen?
> >>
> >> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
> >> wenn nein schalte auf fastd um
> >> mehr muss dieses fff-vpn ja schon fast nicht tun.
> >>
> >> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen
> Tunneldigger
> >> verwenden will (warum auch immer) und man ist flexibel und deckt alles
> ab was
> >> bisher hier so genannt wurde. Wenn man es weiter spinnt kann man auch
> noch
> >> anzeigen machen zu welchen GW man verbunden ist usw...
> >>
> >> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es gibt ja
> bereits
> >> eine "Firmware für interessierte" du siehst ja wie extrem stark die
> genutzt
> >> wird... *Ironie* ;)
> > Ja, und es steckt viel Wahrheit drin, die man gern vergisst, wenn man am
> > Router rum bastelt.
> > Eigentlich will keiner der Routeraufsteller gefragt werden, ob er lieber
> > fastd oder l2tp verwenden möchte, es muss gehen.
> > Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil auf den
> > Gateways fastd sehr viel CPU braucht und man sich von l2tp Verbesserung
> > erhofft.
> > Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre gut,
> > wenn ich am Gateway sagen kann, ich biete diesen oder jenen Tunnel an
> > und die Router bekommen das mitgeteilt und machen.
> Sehe ich genauso.
> >
> > Hier ist immer wieder vom dezentralen keyXchange die Rede, der diese
> > Informationen verteilen würde. Gibt es dazu schon etwas zum schlau
> machen?
> >
> Hier gibt's schon was:
>
> https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement
>
> Grüße
>
> Moexe
> > Robert
> >> mfg
> >>
> >> Christian
> >>
> >>> --
> >>> franken-dev mailing list
> >>> franken-dev@freifunk.net
> >>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> >
> > --
> > franken-dev mailing list
> > franken-dev@freifunk.net
> > http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> --
> franken-dev mailing list
> franken-dev@freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>
>
> --
> franken-dev mailing list
> franken-dev@freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>
>
Alex Gutfried April 6, 2016, 9:31 a.m. 
Oder aber es wird zuerst die gw selection angeschaut und dann für den
ausgewählten server individuell entschieden ob l2tp oder fastd.
Ist das möglich?
Am 06.04.2016 11:27 vorm. schrieb "Alex Gutfried" <alexgutfried@gmail.com>:

> Bevor wir diese Firmware veröffentlichen muss aber sicher gestellt werden
> das annähernd alle GWs den l2tp broker eingerichtet haben.
> Okay wenn keiner da ist, nutzen alle fastd doch wenn ein Gateway den
> Broker hat verbinden sich alle Router (mit aktueller Firmware) mit diesen
> einen Server. Hm da macht sie gw selection auch nicht mehr viel. ;)
> Am 06.04.2016 11:12 vorm. schrieb "Christian Dresel" <fff@chrisi01.de>:
>
>> Hi
>>
>> dann seh ich das richtig das wir praktisch alle 3 der gleichen Meinung
>> sind:
>>
>> "Der Router soll anhand des Gateways auswählen was er nutzt, der User
>> soll keinen (oder vllt. über einen "Expertenmodus" im WebUI?) Einfluss
>> darauf haben"
>>
>> Was haltet ihr dann von der Idee das so zu lösen wie ich es jetzt aus den
>> ganzen Meinungen zusammen gesammelt habe:
>>
>> Es gibt ein fff-vpn Packages, dieses prüft was der Gateway unterstützt
>> und aktiviert dann (über die /usr/sbin/fastdstart was fff-fastd anlegt bzw.
>> /usr/sbin/l2tpstart was das fff-tunneldigger anlegt) das richtige.
>> /usr/sbin/l2tpstart macht im Prinzip das gleiche wie das fastdstart mit
>> keyxchange und bimmbalabim nur das es eben l2tp startet und fastd
>> "blockiert" (wie auch immer das am Ende aussieht oder nutzt man doch beides
>> pararell wenn beides von den GWs untersützt wird?). Bevorzugt nutzt es l2tp
>> weil es besser ist.
>>
>> Oder lagert man das ganze "Prüfe ob Internet und Keyxchange Gedöns
>> Daten ziehen und abgleichen" ins fff-vpn aus und startet dann nur noch das
>> entsprechende fff-fastdstart oder fff-tunneldigger aus dem fff-vpn? Gefällt
>> mir fast noch besser ist mir gerade gekommen die Idee muss man nochmal
>> drüber nachdenken ob das $"so einfach"$ ist.
>>
>> Sollten wir feststellen "ou l2tp ist kaputt das können wir nicht nutzten
>> weil wegen scheiße" stellen wir es an den Gateways ab und die Router
>> springen alle automatisch auf fastd um.
>>
>> Gibt es noch weitere Meinungen zu diesen vorgehen?
>>
>> mfg
>>
>> Christian
>>
>> Moexe <moexe@freifunk-franken-hassfurt.de> hat am 6. April 2016 um 10:39
>> geschrieben:
>>
>>
>> Hi
>>
>> > Am 06.04.2016 um 10:09 schrieb Robert Langhammer <rlanghammer@web.de>:
>> >
>> > Hallo,
>> >
>> >> On 06.04.2016 06:20, Christian Dresel wrote:
>> >> Guten Morgen
>> >>
>> >> Kann man dieses dynamische reagieren dann nicht ins fff-vpn einbauen?
>> >>
>> >> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
>> >> wenn nein schalte auf fastd um
>> >> mehr muss dieses fff-vpn ja schon fast nicht tun.
>> >>
>> >> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen
>> Tunneldigger
>> >> verwenden will (warum auch immer) und man ist flexibel und deckt alles
>> ab was
>> >> bisher hier so genannt wurde. Wenn man es weiter spinnt kann man auch
>> noch
>> >> anzeigen machen zu welchen GW man verbunden ist usw...
>> >>
>> >> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es gibt
>> ja bereits
>> >> eine "Firmware für interessierte" du siehst ja wie extrem stark die
>> genutzt
>> >> wird... *Ironie* ;)
>> > Ja, und es steckt viel Wahrheit drin, die man gern vergisst, wenn man am
>> > Router rum bastelt.
>> > Eigentlich will keiner der Routeraufsteller gefragt werden, ob er lieber
>> > fastd oder l2tp verwenden möchte, es muss gehen.
>> > Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil auf den
>> > Gateways fastd sehr viel CPU braucht und man sich von l2tp Verbesserung
>> > erhofft.
>> > Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre gut,
>> > wenn ich am Gateway sagen kann, ich biete diesen oder jenen Tunnel an
>> > und die Router bekommen das mitgeteilt und machen.
>> Sehe ich genauso.
>> >
>> > Hier ist immer wieder vom dezentralen keyXchange die Rede, der diese
>> > Informationen verteilen würde. Gibt es dazu schon etwas zum schlau
>> machen?
>> >
>> Hier gibt's schon was:
>>
>> https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement
>>
>> Grüße
>>
>> Moexe
>> > Robert
>> >> mfg
>> >>
>> >> Christian
>> >>
>> >>> --
>> >>> franken-dev mailing list
>> >>> franken-dev@freifunk.net
>> >>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>> >
>> > --
>> > franken-dev mailing list
>> > franken-dev@freifunk.net
>> > http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>> --
>> franken-dev mailing list
>> franken-dev@freifunk.net
>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>>
>>
>> --
>> franken-dev mailing list
>> franken-dev@freifunk.net
>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>>
>>
Christian Dresel April 6, 2016, 10:10 a.m. 
Hi

das ist wohl das klassische "Henne-Ei" Problem. Die Gatewaybetreiber stellen
erst um wenn es nötig ist, die Firmwarebauer erst wenn alle Gateways umgestellt
sind. Irgendwer muss ausbrechen und mit dem Umbau der Firmware ist das einfacher
und in meinen Augen "logischer" ;)

- Es werden eh nicht auf einen schlag alle Router in einer Hood geupdatet, das
kommt erst nach und nach
- Wenn sich dann ein Gateway irgendwann langweilt weil niemand mehr fastd
verwendet gibt es 2 Möglichkeiten:
1) Der Gatewaybetreiber stellt dann doch irgendwann um
2) Der Gatewaybetreiber hat wohl kein Interesse mehr das Gateway zu betreiben ;)

Das ganze an die Gatewayselection koppeln gefällt mir nicht wirklich auch wenn
es u.U. denkbar wäre (man kann am Router auslesen welches GW in der Selection
gewählt wurde und prüfen ob das l2tp kann und dann nur verbinden wenn es
kann...).

Da alle l2tp Gateways auch noch im fastd VPN hängen, sollte auch nicht die
Situation entstehen das ein Router l2tp macht aber in der Gatewayselection ein
unereichbares Gateway hat, der Weg sollte in diesem Fall sein:

GW1: nur fastd
GW2: fastd und l2tp

Router hat nur eine l2tp zu GW2 aber in der Gatewayselection GW1 stehen, er
erreicht dieses GW zwar nicht direkt aber über l2tp das GW2 und dort durch den
fastd VPN müsste er dann GW1 erreichen, gut man hat doppelten Traffic und einen
Hop mehr, die Situation sollte man schon vermeiden da gilt dann aber wieder:

Die Gatewaybetreiber einer Hood sollten sich absprechen (sollten sie eh immer,
nicht nur in diesem Fall), wenn sie das nicht machen entsteht halt so was
unschönes, ich sehe das aber nicht als unser ("Firmwareentwickler") Problem an.

mfg

Christian 

> Alex Gutfried <alexgutfried@gmail.com> hat am 6. April 2016 um 11:31
> geschrieben:
> 
> Oder aber es wird zuerst die gw selection angeschaut und dann für den
> ausgewählten server individuell entschieden ob l2tp oder fastd.
>  Ist das möglich?
> Am 06.04.2016 11:27 vorm. schrieb "Alex Gutfried" <alexgutfried@gmail.com>:
> > Bevor wir diese Firmware veröffentlichen muss aber sicher gestellt werden
> > das annähernd alle GWs den l2tp broker eingerichtet haben.
> >  Okay wenn keiner da ist, nutzen alle fastd doch wenn ein Gateway den Broker
> > hat verbinden sich alle Router (mit aktueller Firmware) mit diesen einen
> > Server. Hm da macht sie gw selection auch nicht mehr viel. ;)
> > 
> > Am 06.04.2016 11:12 vorm. schrieb "Christian Dresel" <fff@chrisi01.de>:
> > > Hi
> > > 
> > > dann seh ich das richtig das wir praktisch alle 3 der gleichen Meinung
> > > sind:
> > > 
> > > "Der Router soll anhand des Gateways auswählen was er nutzt, der User soll
> > > keinen (oder vllt. über einen "Expertenmodus" im WebUI?) Einfluss darauf
> > > haben"
> > > 
> > > Was haltet ihr dann von der Idee das so zu lösen wie ich es jetzt aus den
> > > ganzen Meinungen zusammen gesammelt habe:
> > > 
> > > Es gibt ein fff-vpn Packages, dieses prüft was der Gateway unterstützt und
> > > aktiviert dann (über die /usr/sbin/fastdstart was fff-fastd anlegt bzw.
> > > /usr/sbin/l2tpstart was das fff-tunneldigger anlegt) das richtige.
> > > /usr/sbin/l2tpstart macht im Prinzip das gleiche wie das fastdstart mit
> > > keyxchange und bimmbalabim nur das es eben l2tp startet und fastd
> > > "blockiert" (wie auch immer das am Ende aussieht oder nutzt man doch
> > > beides pararell wenn beides von den GWs untersützt wird?). Bevorzugt nutzt
> > > es l2tp weil es besser ist. 
> > > 
> > > Oder lagert man das ganze "Prüfe ob Internet und Keyxchange Gedöns Daten
> > > ziehen und abgleichen" ins fff-vpn aus und startet dann nur noch das
> > > entsprechende fff-fastdstart oder fff-tunneldigger aus dem fff-vpn?
> > > Gefällt mir fast noch besser ist mir gerade gekommen die Idee muss man
> > > nochmal drüber nachdenken ob das $"so einfach"$ ist.
> > > 
> > > Sollten wir feststellen "ou l2tp ist kaputt das können wir nicht nutzten
> > > weil wegen scheiße" stellen wir es an den Gateways ab und die Router
> > > springen alle automatisch auf fastd um.
> > > 
> > > Gibt es noch weitere Meinungen zu diesen vorgehen? 
> > > 
> > > mfg
> > > 
> > > Christian
> > > 
> > > > Moexe <moexe@freifunk-franken-hassfurt.de> hat am 6. April 2016 um 10:39
> > > > geschrieben:
> > > > 
> > > > Hi
> > > > 
> > > > > Am 06.04.2016 um 10:09 schrieb Robert Langhammer <rlanghammer@web.de>:
> > > > > 
> > > > > Hallo,
> > > > > 
> > > > >> On 06.04.2016 06:20, Christian Dresel wrote:
> > > > >> Guten Morgen
> > > > >> 
> > > > >> Kann man dieses dynamische reagieren dann nicht ins fff-vpn einbauen?
> > > > >> 
> > > > >> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
> > > > >> wenn nein schalte auf fastd um
> > > > >> mehr muss dieses fff-vpn ja schon fast nicht tun.
> > > > >> 
> > > > >> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen
> > > > >> Tunneldigger
> > > > >> verwenden will (warum auch immer) und man ist flexibel und deckt
> > > > >> alles ab was
> > > > >> bisher hier so genannt wurde. Wenn man es weiter spinnt kann man auch
> > > > >> noch
> > > > >> anzeigen machen zu welchen GW man verbunden ist usw... 
> > > > >> 
> > > > >> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es gibt
> > > > >> ja bereits
> > > > >> eine "Firmware für interessierte" du siehst ja wie extrem stark die
> > > > >> genutzt
> > > > >> wird... *Ironie* ;)
> > > > > Ja, und es steckt viel Wahrheit drin, die man gern vergisst, wenn man
> > > > > am
> > > > > Router rum bastelt.
> > > > > Eigentlich will keiner der Routeraufsteller gefragt werden, ob er
> > > > > lieber
> > > > > fastd oder l2tp verwenden möchte, es muss gehen.
> > > > > Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil auf
> > > > > den
> > > > > Gateways fastd sehr viel CPU braucht und man sich von l2tp
> > > > > Verbesserung
> > > > > erhofft.
> > > > > Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre gut,
> > > > > wenn ich am Gateway sagen kann, ich biete diesen oder jenen Tunnel an
> > > > > und die Router bekommen das mitgeteilt und machen.
> > > > Sehe ich genauso.
> > > > > 
> > > > > Hier ist immer wieder vom dezentralen keyXchange die Rede, der diese
> > > > > Informationen verteilen würde. Gibt es dazu schon etwas zum schlau
> > > > > machen?
> > > > > 
> > > > Hier gibt's schon was: 
> > > > 
> > > > https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement
> > > > 
> > > > Grüße 
> > > > 
> > > > Moexe
> > > > > Robert
> > > > >> mfg
> > > > >> 
> > > > >> Christian
> > > > >> 
> > > > >>> -- 
> > > > >>> franken-dev mailing list
> > > > >>> franken-dev@freifunk.net
> > > > >>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > > 
> > > > > -- 
> > > > > franken-dev mailing list
> > > > > franken-dev@freifunk.net
> > > > > http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > -- 
> > > > franken-dev mailing list
> > > > franken-dev@freifunk.net
> > > > http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > --
> > >  franken-dev mailing list
> > >  franken-dev@freifunk.net
> > >  http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
Alex Gutfried April 6, 2016, 10:31 a.m. 
Alles klar :)
Dann lassd es uns angehen :)
Haßberge ist gerüstet! :-D
Am 06.04.2016 12:10 nachm. schrieb "Christian Dresel" <fff@chrisi01.de>:

> Hi
>
> das ist wohl das klassische "Henne-Ei" Problem. Die Gatewaybetreiber
> stellen
> erst um wenn es nötig ist, die Firmwarebauer erst wenn alle Gateways
> umgestellt
> sind. Irgendwer muss ausbrechen und mit dem Umbau der Firmware ist das
> einfacher
> und in meinen Augen "logischer" ;)
>
> - Es werden eh nicht auf einen schlag alle Router in einer Hood geupdatet,
> das
> kommt erst nach und nach
> - Wenn sich dann ein Gateway irgendwann langweilt weil niemand mehr fastd
> verwendet gibt es 2 Möglichkeiten:
> 1) Der Gatewaybetreiber stellt dann doch irgendwann um
> 2) Der Gatewaybetreiber hat wohl kein Interesse mehr das Gateway zu
> betreiben ;)
>
> Das ganze an die Gatewayselection koppeln gefällt mir nicht wirklich auch
> wenn
> es u.U. denkbar wäre (man kann am Router auslesen welches GW in der
> Selection
> gewählt wurde und prüfen ob das l2tp kann und dann nur verbinden wenn es
> kann...).
>
> Da alle l2tp Gateways auch noch im fastd VPN hängen, sollte auch nicht die
> Situation entstehen das ein Router l2tp macht aber in der Gatewayselection
> ein
> unereichbares Gateway hat, der Weg sollte in diesem Fall sein:
>
> GW1: nur fastd
> GW2: fastd und l2tp
>
> Router hat nur eine l2tp zu GW2 aber in der Gatewayselection GW1 stehen, er
> erreicht dieses GW zwar nicht direkt aber über l2tp das GW2 und dort durch
> den
> fastd VPN müsste er dann GW1 erreichen, gut man hat doppelten Traffic und
> einen
> Hop mehr, die Situation sollte man schon vermeiden da gilt dann aber
> wieder:
>
> Die Gatewaybetreiber einer Hood sollten sich absprechen (sollten sie eh
> immer,
> nicht nur in diesem Fall), wenn sie das nicht machen entsteht halt so was
> unschönes, ich sehe das aber nicht als unser ("Firmwareentwickler")
> Problem an.
>
> mfg
>
> Christian
>
> > Alex Gutfried <alexgutfried@gmail.com> hat am 6. April 2016 um 11:31
> > geschrieben:
> >
> > Oder aber es wird zuerst die gw selection angeschaut und dann für den
> > ausgewählten server individuell entschieden ob l2tp oder fastd.
> >  Ist das möglich?
> > Am 06.04.2016 11:27 vorm. schrieb "Alex Gutfried" <
> alexgutfried@gmail.com>:
> > > Bevor wir diese Firmware veröffentlichen muss aber sicher gestellt
> werden
> > > das annähernd alle GWs den l2tp broker eingerichtet haben.
> > >  Okay wenn keiner da ist, nutzen alle fastd doch wenn ein Gateway den
> Broker
> > > hat verbinden sich alle Router (mit aktueller Firmware) mit diesen
> einen
> > > Server. Hm da macht sie gw selection auch nicht mehr viel. ;)
> > >
> > > Am 06.04.2016 11:12 vorm. schrieb "Christian Dresel" <fff@chrisi01.de
> >:
> > > > Hi
> > > >
> > > > dann seh ich das richtig das wir praktisch alle 3 der gleichen
> Meinung
> > > > sind:
> > > >
> > > > "Der Router soll anhand des Gateways auswählen was er nutzt, der
> User soll
> > > > keinen (oder vllt. über einen "Expertenmodus" im WebUI?) Einfluss
> darauf
> > > > haben"
> > > >
> > > > Was haltet ihr dann von der Idee das so zu lösen wie ich es jetzt
> aus den
> > > > ganzen Meinungen zusammen gesammelt habe:
> > > >
> > > > Es gibt ein fff-vpn Packages, dieses prüft was der Gateway
> unterstützt und
> > > > aktiviert dann (über die /usr/sbin/fastdstart was fff-fastd anlegt
> bzw.
> > > > /usr/sbin/l2tpstart was das fff-tunneldigger anlegt) das richtige.
> > > > /usr/sbin/l2tpstart macht im Prinzip das gleiche wie das fastdstart
> mit
> > > > keyxchange und bimmbalabim nur das es eben l2tp startet und fastd
> > > > "blockiert" (wie auch immer das am Ende aussieht oder nutzt man doch
> > > > beides pararell wenn beides von den GWs untersützt wird?). Bevorzugt
> nutzt
> > > > es l2tp weil es besser ist.
> > > >
> > > > Oder lagert man das ganze "Prüfe ob Internet und Keyxchange Gedöns
> Daten
> > > > ziehen und abgleichen" ins fff-vpn aus und startet dann nur noch das
> > > > entsprechende fff-fastdstart oder fff-tunneldigger aus dem fff-vpn?
> > > > Gefällt mir fast noch besser ist mir gerade gekommen die Idee muss
> man
> > > > nochmal drüber nachdenken ob das $"so einfach"$ ist.
> > > >
> > > > Sollten wir feststellen "ou l2tp ist kaputt das können wir nicht
> nutzten
> > > > weil wegen scheiße" stellen wir es an den Gateways ab und die Router
> > > > springen alle automatisch auf fastd um.
> > > >
> > > > Gibt es noch weitere Meinungen zu diesen vorgehen?
> > > >
> > > > mfg
> > > >
> > > > Christian
> > > >
> > > > > Moexe <moexe@freifunk-franken-hassfurt.de> hat am 6. April 2016
> um 10:39
> > > > > geschrieben:
> > > > >
> > > > > Hi
> > > > >
> > > > > > Am 06.04.2016 um 10:09 schrieb Robert Langhammer <
> rlanghammer@web.de>:
> > > > > >
> > > > > > Hallo,
> > > > > >
> > > > > >> On 06.04.2016 06:20, Christian Dresel wrote:
> > > > > >> Guten Morgen
> > > > > >>
> > > > > >> Kann man dieses dynamische reagieren dann nicht ins fff-vpn
> einbauen?
> > > > > >>
> > > > > >> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
> > > > > >> wenn nein schalte auf fastd um
> > > > > >> mehr muss dieses fff-vpn ja schon fast nicht tun.
> > > > > >>
> > > > > >> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen
> > > > > >> Tunneldigger
> > > > > >> verwenden will (warum auch immer) und man ist flexibel und deckt
> > > > > >> alles ab was
> > > > > >> bisher hier so genannt wurde. Wenn man es weiter spinnt kann
> man auch
> > > > > >> noch
> > > > > >> anzeigen machen zu welchen GW man verbunden ist usw...
> > > > > >>
> > > > > >> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es
> gibt
> > > > > >> ja bereits
> > > > > >> eine "Firmware für interessierte" du siehst ja wie extrem stark
> die
> > > > > >> genutzt
> > > > > >> wird... *Ironie* ;)
> > > > > > Ja, und es steckt viel Wahrheit drin, die man gern vergisst,
> wenn man
> > > > > > am
> > > > > > Router rum bastelt.
> > > > > > Eigentlich will keiner der Routeraufsteller gefragt werden, ob er
> > > > > > lieber
> > > > > > fastd oder l2tp verwenden möchte, es muss gehen.
> > > > > > Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil
> auf
> > > > > > den
> > > > > > Gateways fastd sehr viel CPU braucht und man sich von l2tp
> > > > > > Verbesserung
> > > > > > erhofft.
> > > > > > Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre
> gut,
> > > > > > wenn ich am Gateway sagen kann, ich biete diesen oder jenen
> Tunnel an
> > > > > > und die Router bekommen das mitgeteilt und machen.
> > > > > Sehe ich genauso.
> > > > > >
> > > > > > Hier ist immer wieder vom dezentralen keyXchange die Rede, der
> diese
> > > > > > Informationen verteilen würde. Gibt es dazu schon etwas zum
> schlau
> > > > > > machen?
> > > > > >
> > > > > Hier gibt's schon was:
> > > > >
> > > > >
> https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement
> > > > >
> > > > > Grüße
> > > > >
> > > > > Moexe
> > > > > > Robert
> > > > > >> mfg
> > > > > >>
> > > > > >> Christian
> > > > > >>
> > > > > >>> --
> > > > > >>> franken-dev mailing list
> > > > > >>> franken-dev@freifunk.net
> > > > > >>>
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > > >
> > > > > > --
> > > > > > franken-dev mailing list
> > > > > > franken-dev@freifunk.net
> > > > > >
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > > --
> > > > > franken-dev mailing list
> > > > > franken-dev@freifunk.net
> > > > >
> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > --
> > > >  franken-dev mailing list
> > > >  franken-dev@freifunk.net
> > > >  http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>
Jan Kraus April 6, 2016, 4:14 p.m. 
Hi,

wir sollten nur vermeiden, das zu einem GW 2 Tunnel aufgebaut werden.
Das wäre der Performance vermutlich nicht dienlich.

Grüße Jan

Am Mittwoch, den 06.04.2016, 12:10 +0200 schrieb Christian Dresel:
> Hi
> 
> das ist wohl das klassische "Henne-Ei" Problem. Die Gatewaybetreiber stellen
> erst um wenn es nötig ist, die Firmwarebauer erst wenn alle Gateways umgestellt
> sind. Irgendwer muss ausbrechen und mit dem Umbau der Firmware ist das einfacher
> und in meinen Augen "logischer" ;)
> 
> - Es werden eh nicht auf einen schlag alle Router in einer Hood geupdatet, das
> kommt erst nach und nach
> - Wenn sich dann ein Gateway irgendwann langweilt weil niemand mehr fastd
> verwendet gibt es 2 Möglichkeiten:
> 1) Der Gatewaybetreiber stellt dann doch irgendwann um
> 2) Der Gatewaybetreiber hat wohl kein Interesse mehr das Gateway zu betreiben ;)
> 
> Das ganze an die Gatewayselection koppeln gefällt mir nicht wirklich auch wenn
> es u.U. denkbar wäre (man kann am Router auslesen welches GW in der Selection
> gewählt wurde und prüfen ob das l2tp kann und dann nur verbinden wenn es
> kann...).
> 
> Da alle l2tp Gateways auch noch im fastd VPN hängen, sollte auch nicht die
> Situation entstehen das ein Router l2tp macht aber in der Gatewayselection ein
> unereichbares Gateway hat, der Weg sollte in diesem Fall sein:
> 
> GW1: nur fastd
> GW2: fastd und l2tp
> 
> Router hat nur eine l2tp zu GW2 aber in der Gatewayselection GW1 stehen, er
> erreicht dieses GW zwar nicht direkt aber über l2tp das GW2 und dort durch den
> fastd VPN müsste er dann GW1 erreichen, gut man hat doppelten Traffic und einen
> Hop mehr, die Situation sollte man schon vermeiden da gilt dann aber wieder:
> 
> Die Gatewaybetreiber einer Hood sollten sich absprechen (sollten sie eh immer,
> nicht nur in diesem Fall), wenn sie das nicht machen entsteht halt so was
> unschönes, ich sehe das aber nicht als unser ("Firmwareentwickler") Problem an.
> 
> mfg
> 
> Christian 
> 
> > Alex Gutfried <alexgutfried@gmail.com> hat am 6. April 2016 um 11:31
> > geschrieben:
> > 
> > Oder aber es wird zuerst die gw selection angeschaut und dann für den
> > ausgewählten server individuell entschieden ob l2tp oder fastd.
> >  Ist das möglich?
> > Am 06.04.2016 11:27 vorm. schrieb "Alex Gutfried" <alexgutfried@gmail.com>:
> > > Bevor wir diese Firmware veröffentlichen muss aber sicher gestellt werden
> > > das annähernd alle GWs den l2tp broker eingerichtet haben.
> > >  Okay wenn keiner da ist, nutzen alle fastd doch wenn ein Gateway den Broker
> > > hat verbinden sich alle Router (mit aktueller Firmware) mit diesen einen
> > > Server. Hm da macht sie gw selection auch nicht mehr viel. ;)
> > > 
> > > Am 06.04.2016 11:12 vorm. schrieb "Christian Dresel" <fff@chrisi01.de>:
> > > > Hi
> > > > 
> > > > dann seh ich das richtig das wir praktisch alle 3 der gleichen Meinung
> > > > sind:
> > > > 
> > > > "Der Router soll anhand des Gateways auswählen was er nutzt, der User soll
> > > > keinen (oder vllt. über einen "Expertenmodus" im WebUI?) Einfluss darauf
> > > > haben"
> > > > 
> > > > Was haltet ihr dann von der Idee das so zu lösen wie ich es jetzt aus den
> > > > ganzen Meinungen zusammen gesammelt habe:
> > > > 
> > > > Es gibt ein fff-vpn Packages, dieses prüft was der Gateway unterstützt und
> > > > aktiviert dann (über die /usr/sbin/fastdstart was fff-fastd anlegt bzw.
> > > > /usr/sbin/l2tpstart was das fff-tunneldigger anlegt) das richtige.
> > > > /usr/sbin/l2tpstart macht im Prinzip das gleiche wie das fastdstart mit
> > > > keyxchange und bimmbalabim nur das es eben l2tp startet und fastd
> > > > "blockiert" (wie auch immer das am Ende aussieht oder nutzt man doch
> > > > beides pararell wenn beides von den GWs untersützt wird?). Bevorzugt nutzt
> > > > es l2tp weil es besser ist. 
> > > > 
> > > > Oder lagert man das ganze "Prüfe ob Internet und Keyxchange Gedöns Daten
> > > > ziehen und abgleichen" ins fff-vpn aus und startet dann nur noch das
> > > > entsprechende fff-fastdstart oder fff-tunneldigger aus dem fff-vpn?
> > > > Gefällt mir fast noch besser ist mir gerade gekommen die Idee muss man
> > > > nochmal drüber nachdenken ob das $"so einfach"$ ist.
> > > > 
> > > > Sollten wir feststellen "ou l2tp ist kaputt das können wir nicht nutzten
> > > > weil wegen scheiße" stellen wir es an den Gateways ab und die Router
> > > > springen alle automatisch auf fastd um.
> > > > 
> > > > Gibt es noch weitere Meinungen zu diesen vorgehen? 
> > > > 
> > > > mfg
> > > > 
> > > > Christian
> > > > 
> > > > > Moexe <moexe@freifunk-franken-hassfurt.de> hat am 6. April 2016 um 10:39
> > > > > geschrieben:
> > > > > 
> > > > > Hi
> > > > > 
> > > > > > Am 06.04.2016 um 10:09 schrieb Robert Langhammer <rlanghammer@web.de>:
> > > > > > 
> > > > > > Hallo,
> > > > > > 
> > > > > >> On 06.04.2016 06:20, Christian Dresel wrote:
> > > > > >> Guten Morgen
> > > > > >> 
> > > > > >> Kann man dieses dynamische reagieren dann nicht ins fff-vpn einbauen?
> > > > > >> 
> > > > > >> Prüfe ob fff-tunneldigger funktioniert wenn ja nutzt es
> > > > > >> wenn nein schalte auf fastd um
> > > > > >> mehr muss dieses fff-vpn ja schon fast nicht tun.
> > > > > >> 
> > > > > >> Im WebUI noch einen Haken wo man fastd erzwingen kann wer keinen
> > > > > >> Tunneldigger
> > > > > >> verwenden will (warum auch immer) und man ist flexibel und deckt
> > > > > >> alles ab was
> > > > > >> bisher hier so genannt wurde. Wenn man es weiter spinnt kann man auch
> > > > > >> noch
> > > > > >> anzeigen machen zu welchen GW man verbunden ist usw... 
> > > > > >> 
> > > > > >> ich würde schon eher sagen das soll in unsere Hauptfirmware. Es gibt
> > > > > >> ja bereits
> > > > > >> eine "Firmware für interessierte" du siehst ja wie extrem stark die
> > > > > >> genutzt
> > > > > >> wird... *Ironie* ;)
> > > > > > Ja, und es steckt viel Wahrheit drin, die man gern vergisst, wenn man
> > > > > > am
> > > > > > Router rum bastelt.
> > > > > > Eigentlich will keiner der Routeraufsteller gefragt werden, ob er
> > > > > > lieber
> > > > > > fastd oder l2tp verwenden möchte, es muss gehen.
> > > > > > Die Initiative kam hier in Haßfurt von den Gateway Leuten, weil auf
> > > > > > den
> > > > > > Gateways fastd sehr viel CPU braucht und man sich von l2tp
> > > > > > Verbesserung
> > > > > > erhofft.
> > > > > > Ich denke, wir sollten es von dieser Seite her anpacken. Es wäre gut,
> > > > > > wenn ich am Gateway sagen kann, ich biete diesen oder jenen Tunnel an
> > > > > > und die Router bekommen das mitgeteilt und machen.
> > > > > Sehe ich genauso.
> > > > > > 
> > > > > > Hier ist immer wieder vom dezentralen keyXchange die Rede, der diese
> > > > > > Informationen verteilen würde. Gibt es dazu schon etwas zum schlau
> > > > > > machen?
> > > > > > 
> > > > > Hier gibt's schon was: 
> > > > > 
> > > > > https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement
> > > > > 
> > > > > Grüße 
> > > > > 
> > > > > Moexe
> > > > > > Robert
> > > > > >> mfg
> > > > > >> 
> > > > > >> Christian
> > > > > >> 
> > > > > >>> -- 
> > > > > >>> franken-dev mailing list
> > > > > >>> franken-dev@freifunk.net
> > > > > >>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > > > 
> > > > > > -- 
> > > > > > franken-dev mailing list
> > > > > > franken-dev@freifunk.net
> > > > > > http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > > -- 
> > > > > franken-dev mailing list
> > > > > franken-dev@freifunk.net
> > > > > http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
> > > > --
> > > >  franken-dev mailing list
> > > >  franken-dev@freifunk.net
> > > >  http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net