fff-network: Fix incorrect IPv6 syntax in functions #69

fbl · 2021-01-09T00:01:16+01:00

fbl commented

2021-01-09 00:01:16 +01:00

Some of our network helper functions did require the use of an invalid
ipv6 prefix syntax to function correctly.

Specifically, if all 64 bits of the prefix are given, the caller has to
omit one colon for our assemble-functions to work properly. Therefore
the prefix '2001:db8:1:2::/64' had to be written as '2001:db8:1:2:/64'.

Also, our functions did not allow to specify the suffix with leading
colons.

This changes the behaviour of these functions to accept properly
formatted IPv6 prefixes and suffixes. All calls to these functions are
adjusted accordingly.

There is one notebly exeption: The incorrect prefix syntax in hoodfiles
cannot be adjusted yet, because that would break devices with using
older firmware. To keep compatibility with older firmware versions, the
hoodfiles prefix syntax is not yet adjusted, and a special case is added
to configurehood to allow the use of the old incorrect syntax.

While this new solution still is kind of hacky and does things that
should actually be done by a proper address parser, it does at least fix
the before mentioned problems.

Fixes: #27

Signed-off-by: Fabian Bläse fabian@blaese.de

Some of our network helper functions did require the use of an invalid ipv6 prefix syntax to function correctly. Specifically, if all 64 bits of the prefix are given, the caller has to omit one colon for our assemble-functions to work properly. Therefore the prefix '2001:db8:1:2::/64' had to be written as '2001:db8:1:2:/64'. Also, our functions did not allow to specify the suffix with leading colons. This changes the behaviour of these functions to accept properly formatted IPv6 prefixes and suffixes. All calls to these functions are adjusted accordingly. There is one notebly exeption: The incorrect prefix syntax in hoodfiles cannot be adjusted yet, because that would break devices with using older firmware. To keep compatibility with older firmware versions, the hoodfiles prefix syntax is not yet adjusted, and a special case is added to configurehood to allow the use of the old incorrect syntax. While this new solution still is kind of hacky and does things that should actually be done by a proper address parser, it does at least fix the before mentioned problems. Fixes: #27 Signed-off-by: Fabian Bläse <fabian@blaese.de>

fbl commented

2021-01-09 00:02:15 +01:00

Untested for now.

fbl added the

RFC

WIP

labels 2021-01-09 00:02:32 +01:00

adschm added the

packages/fff

label 2021-01-09 00:37:07 +01:00

adschm commented

2021-01-09 00:43:50 +01:00

Mich wundert enorm, dass es hier scheinbar auch in OpenWrt keine fertigen Funktionen für sowas gibt. Ich konnte zumindest keine finden ...

fbl commented

2021-01-09 11:16:09 +01:00

Das was wir da tun ist halt auch ziemlicher Pfusch. Zeichenersetzung ist dafür halt absolut nicht das richtige Werkzeug..

Aber irgendwo müsste OpenWrt tatsächlich irgendwas dafür haben, was es dann für ip6assign her nehmen kann.

Das was wir da tun ist halt auch ziemlicher Pfusch. Zeichenersetzung ist dafür halt absolut nicht das richtige Werkzeug.. Aber irgendwo müsste OpenWrt tatsächlich irgendwas dafür haben, was es dann für ip6assign her nehmen kann.

fbl force-pushed syntaxfix from ec0c638038 to daab44944e

2021-01-09 11:21:36 +01:00

Compare

fbl commented

2021-01-09 11:21:50 +01:00

Changes:

Bump PKG_RELEASEs

Changes: * Bump PKG_RELEASEs

fbl commented

2021-01-11 12:35:40 +01:00

Aber irgendwo müsste OpenWrt tatsächlich irgendwas dafür haben, was es dann für ip6assign her nehmen kann.

Wird bei OpenWrt alles im netifd gemacht, wo es passende Werkzeuge gibt, um Prefix und Suffix ordentlich zusammen zu setzen.

> Aber irgendwo müsste OpenWrt tatsächlich irgendwas dafür haben, was es dann für ip6assign her nehmen kann. Wird bei OpenWrt alles im netifd gemacht, wo es passende Werkzeuge gibt, um Prefix und Suffix ordentlich zusammen zu setzen.

adschm commented

2021-01-13 17:59:34 +01:00

Ich bin gerade auf folgendes aufmerksam geworden:

https://github.com/openwrt/openwrt/blob/master/package/network/utils/owipcalc/src/owipcalc.c

Die Package besteht aus genau einem c-File, sollte also winzig sein.

Damit können wir IP-Adressen zusammensetzen mit Befehlen wie:

owipcalc fdff::1/64 add ::aa:bb

Ergibt: fdff::aa:bc/64

Habe das gerade auf meinem OpenWrt-AP ausprobiert (Package per opkg installiert).

Auch wenn es da natürlich auch Bugs geben kann, ist es denke ich immer noch besser als mit unseren String-Manipulationen. Ich werde hierfür einen alternativen Patch bauen.

Ich bin gerade auf folgendes aufmerksam geworden: https://github.com/openwrt/openwrt/blob/master/package/network/utils/owipcalc/src/owipcalc.c Die Package besteht aus genau einem c-File, sollte also winzig sein. Damit können wir IP-Adressen zusammensetzen mit Befehlen wie: `owipcalc fdff::1/64 add ::aa:bb` Ergibt: `fdff::aa:bc/64` Habe das gerade auf meinem OpenWrt-AP ausprobiert (Package per opkg installiert). Auch wenn es da natürlich auch Bugs geben kann, ist es denke ich immer noch besser als mit unseren String-Manipulationen. Ich werde hierfür einen alternativen Patch bauen.

fbl commented

2021-01-14 00:02:04 +01:00

Aaah ja. Genau so was wollte ich wie gesagt eigentlich mal schreiben. In diesem C-Code wird die Adresse ordentlich geparsed und dann in ordentlichen Datenstrukturen zusammen gebaut, so wie das eigentlich sollte.

Dummerweise sagt die Anzahl der C-Dateien quasi nichts über die resultierende Größe eines Programms aus.

https://openwrt.org/packages/pkgdata_owrt18_6/owipcalc sagt, dass es etwa 4kB "installed size" hat. Bleibt die Frage, wie viel das squashfs da noch wegoptimiert bekommt.

Aaah ja. Genau so was wollte ich wie gesagt eigentlich mal schreiben. In diesem C-Code wird die Adresse ordentlich geparsed und dann in ordentlichen Datenstrukturen zusammen gebaut, so wie das eigentlich sollte. Dummerweise sagt die Anzahl der C-Dateien quasi nichts über die resultierende Größe eines Programms aus. https://openwrt.org/packages/pkgdata_owrt18_6/owipcalc sagt, dass es etwa 4kB "installed size" hat. Bleibt die Frage, wie viel das squashfs da noch wegoptimiert bekommt.

adschm commented

2021-01-14 00:04:21 +01:00

Siehe #77

Ich habe dort bewusst nur replaced und nicht die Input-Syntax angefasst.

Siehe #77 Ich habe dort bewusst nur replaced und _nicht_ die Input-Syntax angefasst.

fbl referenced this pull request

2021-01-14 00:11:31 +01:00

treewide/fff-network: use upstream functions for IP concatenation and MAC bit flipping #77

fbl commented

2021-01-27 12:30:51 +01:00

Da #77 eine deutlich schönere Lösung ist, ist dieser PR obsolet.

fbl closed this pull request