babeld: Add pending patch for src_plen assignments

This introduces the pending upstream fix and a patch to change
babeld version.

This applies the naming scheme as for batman-adv:

openwrt-PKG_VERSION-PKG_REVISION

e.g. openwrt-1.9.1-2

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>

---

The babel patches are build for the 1.9.1 as present in openwrt-19.07
branch. Since there were some Makefile adjustments not backported to
our firmware, I'm not 100 % sure they apply there.

I tested this with my firmware on running device.
---
 ...nclude-PKG_RELEASE-in-babeld-version.patch |  32 +++++
 .../0012-babeld-Add-src_plen-patch.patch      | 109 ++++++++++++++++++
 2 files changed, 141 insertions(+)
 create mode 100644 feed_patches/routing/0011-babeld-Include-PKG_RELEASE-in-babeld-version.patch
 create mode 100644 feed_patches/routing/0012-babeld-Add-src_plen-patch.patch

Hey Adrian,

danke dafür.

Ich würde Upstream auf jeden Fall bevorzugen, falls das noch rechtzeitig fertig wird.
Bis wir es tatsächlich brauchen, würde ich mein Review gerne aufschieben..

Gruß
Fabian

Hallo Adrian,

gefällt mir,
Reviewed-by: Fabian Bläse <fabian@blaese.de>

Etwas kosmetisches hab ich aber noch: Mir gefällt die Versionsnummer irgendwie nicht.
Es ist ja ein babeld, kein openwrt.

Ich würde folgendes vorschlagen: babeld-$(PKG_VERSION)+openwrt$(PKG_RELEASE)
Wenn du damit einverstanden bist, würd ich das auch einfach fix beim applien anpassen, da sich bisher sonst keiner zu diesem Patch geäußert hat.

Gruß
Fabian

On 02.10.19 00:11, Adrian Schmutzler wrote:
> This introduces the pending upstream fix and a patch to change
> babeld version.
> 
> This applies the naming scheme as for batman-adv:
> 
> openwrt-PKG_VERSION-PKG_REVISION
> 
> e.g. openwrt-1.9.1-2
> 
> Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
> 
> ---
> 
> The babel patches are build for the 1.9.1 as present in openwrt-19.07
> branch. Since there were some Makefile adjustments not backported to
> our firmware, I'm not 100 % sure they apply there.
> 
> I tested this with my firmware on running device.
> ---
>  ...nclude-PKG_RELEASE-in-babeld-version.patch |  32 +++++
>  .../0012-babeld-Add-src_plen-patch.patch      | 109 ++++++++++++++++++
>  2 files changed, 141 insertions(+)
>  create mode 100644 feed_patches/routing/0011-babeld-Include-PKG_RELEASE-in-babeld-version.patch
>  create mode 100644 feed_patches/routing/0012-babeld-Add-src_plen-patch.patch
> 
> diff --git a/feed_patches/routing/0011-babeld-Include-PKG_RELEASE-in-babeld-version.patch b/feed_patches/routing/0011-babeld-Include-PKG_RELEASE-in-babeld-version.patch
> new file mode 100644
> index 00000000..e85acf08
> --- /dev/null
> +++ b/feed_patches/routing/0011-babeld-Include-PKG_RELEASE-in-babeld-version.patch
> @@ -0,0 +1,32 @@
> +From a5e29f8520ba2dc65af47153980ec3401e18757b Mon Sep 17 00:00:00 2001
> +From: Adrian Schmutzler <freifunk@adrianschmutzler.de>
> +Date: Mon, 30 Sep 2019 17:09:10 +0200
> +Subject: [PATCH 1/2] babeld: Include PKG_RELEASE in babeld version
> +
> +This will account for custom patches added, as otherwise version
> +would stay the same.
> +
> +Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
> +---
> + babeld/Makefile | 5 +++++
> + 1 file changed, 5 insertions(+)
> +
> +diff --git a/babeld/Makefile b/babeld/Makefile
> +index 022d0b8..cc266ce 100644
> +--- a/babeld/Makefile
> ++++ b/babeld/Makefile
> +@@ -48,6 +48,11 @@ MAKE_FLAGS+= \
> + 	CFLAGS="$(TARGET_CFLAGS)" \
> + 	LDLIBS="" \
> + 
> ++define Build/Configure
> ++	echo "openwrt-$(PKG_VERSION)-$(PKG_RELEASE)" > $(PKG_BUILD_DIR)/version
> ++	$(Build/Configure/Default)
> ++endef
> ++
> + define Package/babeld/install
> + 	$(INSTALL_DIR) $(1)/usr/sbin
> + 	$(INSTALL_BIN) $(PKG_BUILD_DIR)/babeld $(1)/usr/sbin/
> +-- 
> +2.20.1
> +
> diff --git a/feed_patches/routing/0012-babeld-Add-src_plen-patch.patch b/feed_patches/routing/0012-babeld-Add-src_plen-patch.patch
> new file mode 100644
> index 00000000..50352854
> --- /dev/null
> +++ b/feed_patches/routing/0012-babeld-Add-src_plen-patch.patch
> @@ -0,0 +1,109 @@
> +From 74a1488696ccc375a57236f15bcbd90e1ec76b77 Mon Sep 17 00:00:00 2001
> +From: Adrian Schmutzler <freifunk@adrianschmutzler.de>
> +Date: Mon, 30 Sep 2019 16:52:28 +0200
> +Subject: [PATCH 2/2] babeld: Add src_plen patch
> +
> +This patch is currently pending upstream.
> +
> +Babeld version (babeld -V) won't indicate the change!
> +
> +Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
> +---
> + babeld/Makefile                               |  2 +-
> + ...nments-which-break-v4mapped-encoding.patch | 71 +++++++++++++++++++
> + 2 files changed, 72 insertions(+), 1 deletion(-)
> + create mode 100644 babeld/patches/0001-Remove-src_plen-assignments-which-break-v4mapped-encoding.patch
> +
> +diff --git a/babeld/Makefile b/babeld/Makefile
> +index cc266ce..cc1598b 100644
> +--- a/babeld/Makefile
> ++++ b/babeld/Makefile
> +@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
> + 
> + PKG_NAME:=babeld
> + PKG_VERSION:=1.9.1
> +-PKG_RELEASE:=1
> ++PKG_RELEASE:=2
> + 
> + PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
> + PKG_SOURCE_URL:=https://www.irif.fr/~jch/software/files/
> +diff --git a/babeld/patches/0001-Remove-src_plen-assignments-which-break-v4mapped-encoding.patch b/babeld/patches/0001-Remove-src_plen-assignments-which-break-v4mapped-encoding.patch
> +new file mode 100644
> +index 0000000..089e35f
> +--- /dev/null
> ++++ b/babeld/patches/0001-Remove-src_plen-assignments-which-break-v4mapped-encoding.patch
> +@@ -0,0 +1,71 @@
> ++From 36121c1e67fb5a60a35fed0faa37297cd97c9ffc Mon Sep 17 00:00:00 2001
> ++From: =?UTF-8?q?Fabian=20Bl=C3=A4se?= <fabian@blaese.de>
> ++Date: Thu, 19 Sep 2019 01:16:46 +0200
> ++Subject: [PATCH] Remove src_plen assignments which break v4mapped encoding
> ++MIME-Version: 1.0
> ++Content-Type: text/plain; charset=UTF-8
> ++Content-Transfer-Encoding: 8bit
> ++
> ++These assignments were introduced in f8bce04, probably
> ++to ensure that src_plen doesn't contain any leftovers from
> ++earlier revisions when source specific wasn't done via sub-TLVs.
> ++
> ++This however breaks v4mapped encoding as a prefix length of 0
> ++for IPv4 routes is represented as src_plen = 96. This offset is
> ++already added outside of the affected functions and therefore
> ++gets overwritten by this assignment.
> ++
> ++Both functions contain an additional check if the message contains
> ++ipv4 addresses, but as this check is only executed if the message has
> ++a source-specific sub-TLV, the offset isn't added for non source-specific
> ++routes.
> ++
> ++Because the offset is already added outside of the subtlv parsing
> ++functions, this additional check is also removed, as it would otherwise
> ++break IPv4 source specifics by adding the IPv4 offset two times.
> ++
> ++Signed-off-by: Fabian Bläse <fabian@blaese.de>
> ++---
> ++ message.c | 8 --------
> ++ 1 file changed, 8 deletions(-)
> ++
> ++diff --git a/message.c b/message.c
> ++index 0f6ca19d..78f9aa93 100644
> ++--- a/message.c
> +++++ b/message.c
> ++@@ -137,8 +137,6 @@ parse_update_subtlv(struct interface *ifp, int metric, int ae,
> ++         }
> ++     }
> ++ 
> ++-    *src_plen = 0;
> ++-
> ++     while(i < alen) {
> ++         type = a[i];
> ++         if(type == SUBTLV_PAD1) {
> ++@@ -170,8 +168,6 @@ parse_update_subtlv(struct interface *ifp, int metric, int ae,
> ++                                 len - 1, src_prefix);
> ++             if(rc < 0)
> ++                 goto fail;
> ++-            if(ae == 1)
> ++-                (*src_plen) += 96;
> ++         } else {
> ++             debugf("Received unknown%s Update sub-TLV %d.\n",
> ++                    (type & 0x80) != 0 ? " mandatory" : "", type);
> ++@@ -305,8 +301,6 @@ parse_request_subtlv(int ae, const unsigned char *a, int alen,
> ++ {
> ++     int type, len, i = 0;
> ++ 
> ++-    *src_plen = 0;
> ++-
> ++     while(i < alen) {
> ++         type = a[0];
> ++         if(type == SUBTLV_PAD1) {
> ++@@ -336,8 +330,6 @@ parse_request_subtlv(int ae, const unsigned char *a, int alen,
> ++                                 len - 1, src_prefix);
> ++             if(rc < 0)
> ++                 goto fail;
> ++-            if(ae == 1)
> ++-                (*src_plen) += 96;
> ++         } else {
> ++             debugf("Received unknown%s Route Request sub-TLV %d.\n",
> ++                    ((type & 0x80) != 0) ? " mandatory" : "", type);
> +-- 
> +2.20.1
> +
>

Hallo Fabian,

die Versionsnummer entspricht einer vergleichbaren Lösung, die in openwrt-routing für batman-adv verwendet wird:

https://github.com/openwrt-routing/packages/commit/542a63720f922e19b497b1d59508eae21eca42d6#diff-5fcfc24627955255c973271d0858be1c

Es ist also quasi die openwrt-Variante von der Version.

Ich bin dafür, dass hier auch so zu machen, dann passt es zum Rest von openwrt-routing. Wenn du es ändern willst, ist es mir auch wurscht, aber dann bitte mit nem eigenen Commit.

Beste Grüße

Adrian

Hi

eigentlich wollte ich ja sagen, eigentlich ist es mir egal. Das Problem
dann haben wir wieder "einer so einer so und einem isses egal" -> auch doof.

Also dieses Openwrt-1.9.1-2 gefällt mir mal gar nicht auch wenn es
OpenWRT so macht (warum auch immer...). Wir haben hier ja kein OpenWRT
sondern ein babeld vor uns, also soll das auch mit babeld anfangen.

Fabians Idee mit babeld-$(PKG_VERSION)+openwrt$(PKG_RELEASE) finde ich
schon nicht schlecht, noch besser finde ich aber:

babeld-$(PKG_VERSION)+fff$(PKG_RELEASE)

immerhin ist das ja kein Patch von Openwrt sondern von uns, also darf da
auch fff rein oder?

Ich kann notfalls aber auch mit Fabian seiner Lösung leben, die
Openwrt-1.9.1 sagt mir allerdings nicht wirklich zu und bin ich eher
dagegen die zu verwenden.

Gruß

Christian

On 10.11.19 20:52, mail@adrianschmutzler.de wrote:
> Hallo Fabian,
> 
> die Versionsnummer entspricht einer vergleichbaren Lösung, die in openwrt-routing für batman-adv verwendet wird:
> 
> https://github.com/openwrt-routing/packages/commit/542a63720f922e19b497b1d59508eae21eca42d6#diff-5fcfc24627955255c973271d0858be1c
> 
> Es ist also quasi die openwrt-Variante von der Version.
> 
> Ich bin dafür, dass hier auch so zu machen, dann passt es zum Rest von openwrt-routing. Wenn du es ändern willst, ist es mir auch wurscht, aber dann bitte mit nem eigenen Commit.
> 
> Beste Grüße
> 
> Adrian
>

Hallo Christian,

>  Wir haben hier ja kein OpenWRT 
> sondern ein babeld vor uns, also soll das auch mit babeld anfangen. 

Naja, die Logik ist, dass der Name des Produkts ja nicht in der Versionsnummer vorkommen soll. Bei "uname -r" steht ja auch nicht "Linux" drin. Das openwrt gibt an, dass es sich hierbei um eine durch OpenWrt veränderte Version handelt. (Was natürlich mit Fabians Variante prinzipiell genauso ausgedrückt wird).

> Fabians Idee mit babeld-$(PKG_VERSION)+openwrt$(PKG_RELEASE) finde ich 
> schon nicht schlecht, noch besser finde ich aber: 
> babeld-$(PKG_VERSION)+fff$(PKG_RELEASE) 
> immerhin ist das ja kein Patch von Openwrt sondern von uns, also darf da 
> auch fff rein oder? 

Naja, streng genommen führt unser Patch ja nur einen Patch für das openwrt-routing ein. Wir haben ja gar keine eigene Package babel in unserer Firmware.

Mir ist das aber tatsächlich egal, ich habe den Patch halt so gebaut, dass ich den ohne Änderungen auch gleich bei openwrt-routing submitten kann. So gesehen ist meine Lösung näher am Upstream. ;-)

Man könnte aber natürlich auch überlegen, einfach upstream eine vernünftigere Versionsnummer z.B. entsprechend Fabians Vorschlag einzuführen.

Beste Grüße

Adrian

Hallo nochmal,

 

ich habe gerade einen Patch bei openwrt-routing eingereicht, um dort die Versionsnummern für batman-adv etc. zu ändern:

 

https://github.com/openwrt-routing/packages/pull/529

 

So far: openwrt-2019.4-1

Now: 2019.4-openwrt-1

 

Ich denke, das wird nicht allzu lange dauern, und würde das Ergebnis dort abwarten. Danach könnte man dann entsprechend den Version-String für babeld anpassen (da babeld ja offenbar tatsächlich den Namen mit in die Version schreibt, könnte man dann z.B.

babeld-1.9.1-openwrt-2

oder

babeld-1.9.1-fff-2

machen.

 

Falls es kein neues Babeld Release gibt, würde ich den eigentlichen Patch nämlich auch so in openwrt-routing submitten.

 

Grüße

 

Adrian

Hallo Adrian,

On 11.11.19 12:21, Adrian Schmutzler wrote:
> Hallo Christian,
> 
>>  Wir haben hier ja kein OpenWRT 
>> sondern ein babeld vor uns, also soll das auch mit babeld anfangen. 
> 
> Naja, die Logik ist, dass der Name des Produkts ja nicht in der Versionsnummer vorkommen soll. Bei "uname -r" steht ja auch nicht "Linux" drin. Das openwrt gibt an, dass es sich hierbei um eine durch OpenWrt veränderte Version handelt. (Was natürlich mit Fabians Variante prinzipiell genauso ausgedrückt wird).
Warum stehts dann in babeld normalerweise drin?

Normalerweise geben Kommandozeilentools bei "--version" immer in irgendeiner Form Name + Version aus.

Mit uname -r fragst du ja explizit nur die Version ab, so eine Unterscheidung hat babeld nicht. Und mit uname -sr bekommt man sehr wohl den Namen mit dazu.
Vergleiche auch: "bird --version", "batctl -v", "systemd --version", "ssh -V", "openssl version", "nginx -v", "ip -V", ... (um nur einige zu nennen.. :D)
Siehe auch: https://www.gnu.org/prep/standards/standards.html#g_t_002d_002dversion

Wenn von einem anderen Projekt nochmal etwas an Software verändert wird, resultiert das normalerweise auch in einer Versionsnummer analog zu meiner. Jedenfalls bei allem, was ich so kenne. Siehe Debian:
"linux-image-amd64    4.19+105+deb10u1"

Aber eigentlich geht es mir darum gar nicht. (siehe unten)

>> Fabians Idee mit babeld-$(PKG_VERSION)+openwrt$(PKG_RELEASE) finde ich 
>> schon nicht schlecht, noch besser finde ich aber: 
>> babeld-$(PKG_VERSION)+fff$(PKG_RELEASE) 
>> immerhin ist das ja kein Patch von Openwrt sondern von uns, also darf da 
>> auch fff rein oder? 
> 
> Naja, streng genommen führt unser Patch ja nur einen Patch für das openwrt-routing ein. Wir haben ja gar keine eigene Package babel in unserer Firmware.
fff gefällt mir sehr gut, schließlich ist das ja trotzdem unser Patch, auch wenn das dann mit unserem buildscript in openwrt-routing einfließt.

> Mir ist das aber tatsächlich egal, ich habe den Patch halt so gebaut, dass ich den ohne Änderungen auch gleich bei openwrt-routing submitten kann. So gesehen ist meine Lösung näher am Upstream. ;-)
Eigentlich ist es mir genauso egal, mir gefällt aber nicht, dass
- die Abwandlung (openwrt) vor der Originalversionsnummer steht, nicht dahinter (was halt tatsächlich irgendwie suggeriert, dass man es mit einem openwrt zu tun hat..)
- im nodewatcher nicht mehr ersichtlich wird, dass babeld eingesetzt wird und nicht irgendein anderer Daemon

Zumindest zweiteres ist mir schon einigermaßen wichtig.

Randnotiz: Was ist denn hier "upstream"? Näher an der Originalversionsnummer, die babeld pflegt, ist das nämlich gar nicht.. ;-)

> Man könnte aber natürlich auch überlegen, einfach upstream eine vernünftigere Versionsnummer z.B. entsprechend Fabians Vorschlag einzuführen.
Eigentlich würde ich hoffen, dass das möglichst bald upstream geht und wir (und v.a. openwrt) da nicht an so fundamentalem Kram rumpfuschen müssen.

Wir sollten die Entwicklung jetzt aber nicht wegen solchem Kleinkram ausbremsen.
Der Patch soll so bleiben, wie er jetzt ist. Ich sende dann nochmal was, um das anzupassen. Dort kann man dann ggf. diskutieren.
Ein Review hat es ja schon von mir.

Gruß
Fabian

hi

On 11.11.19 13:14, Fabian Bläse wrote:

> Wir sollten die Entwicklung jetzt aber nicht wegen solchem Kleinkram ausbremsen.

+1

> Der Patch soll so bleiben, wie er jetzt ist. Ich sende dann nochmal was, um das anzupassen. Dort kann man dann ggf. diskutieren.

Einverstanden

Gruß

Christian

applied.