layer3: move from fixed address to fixed hostname #80

Open
jkimmel wants to merge 2 commits from jkimmel/firmware:fdff into master
Owner

Add "local.fff.community" hostname that resolves to the local router.
All possible addresses are made available to provide multiple fallbacks:

  • client ipv4 and ipv6 addresses
  • peer_ip and peer_ip6 addresses
  • fdff::1/64 on first boot and after factory reset

The moment any ipv6 network is configured, all occurrences of the
fixed fdff::/64 network are removed.

Fixes #76

Signed-off-by: Johannes Kimmel fff@bareminimum.eu

Add "local.fff.community" hostname that resolves to the local router. All possible addresses are made available to provide multiple fallbacks: - client ipv4 and ipv6 addresses - peer_ip and peer_ip6 addresses - fdff::1/64 on first boot and after factory reset The moment any ipv6 network is configured, all occurrences of the fixed fdff::/64 network are removed. Fixes #76 Signed-off-by: Johannes Kimmel <fff@bareminimum.eu>
jkimmel added the
feature
layer3
packages/fff
labels 2021-01-19 09:17:42 +01:00
Author
Owner

So, hab das mal eben zusammengezimmert, damit wir mal eine Diskussionsgrundlage haben.
Der Patch implementiert meinen Vorschlag zunaechst fdff::/64 zu behalten, aber sofort zu loeschen, sobald ein ordentliches IPv6 Netz konfiguriert ist.

Außerdem zeigt local.fff.community ab jetzt immer auf den lokalen Router. Dabei wird nach dem flashen und factory reset auf fdff::1 aufgeloest. Danach wird versucht aus den client ips und den peer_ips moeglichst alles zusammen zu sammeln, damit moeglichst viel antworten dabei sind, von denen hoffentlich eine funktioniert.

Dazu musste noch die dhcpv6 option eingeschalten werden. Damit ist es auch moeglich einen IPv6-only router mit wirklich minimaler config zu bauen.


Eine kleine Falle ist leider noch uebrig, die mir beim testen aufgefallen ist:
Mit leerer peer_ip6 und WAN-Zugriff wird leider wieder unter Umstaenden eine falsche Source IP gewaehlt. Abhilfe schafft die peer_ip6 zu setzen, damit auf dem Babelinterface eine Globale Adresse liegt. Dann wird diese auch genommen.
Eventuell sollte man also da auch ein Fallback in der Zukunft generieren.


(Minimale) Beispielconfig fuer IPv6-only zum testen (funktioniert prima hier):

config gateway 'meta'
	option config_version '1'
	option peer_ip6 '2a0b:f4c0:stuv:wxyz::'

config vlan '1'
	option comment 'client'
	## t: tagged. CPU-Port wird automatisch hinzugefügt.
	option ports '1 2 3 4'

config vlan '100'
	option comment 'babel'
	option ports '0t'

config vlan '2'
	option comment 'wan'
	option ports '0'

config client
	option vlan '1'
	list ip6addr '2a0b:f4c0:stuv:wxyz::/64'

config dns
	list server 'fd43:5602:29bd:ffff:1:1:1:64'

config babelpeer
	option vlan '100'


In /etc/config/dhcp werden dann pro IP so ein eintrag angelegt:

...

config domain
	option ip '2a0b:f4c0:stuv:wxyz::'
	option name 'local.fff.community

...
So, hab das mal eben zusammengezimmert, damit wir mal eine Diskussionsgrundlage haben. Der Patch implementiert meinen Vorschlag zunaechst `fdff::/64` zu behalten, aber sofort zu loeschen, sobald ein ordentliches IPv6 Netz konfiguriert ist. Außerdem zeigt `local.fff.community` ab jetzt immer auf den lokalen Router. Dabei wird nach dem flashen und factory reset auf `fdff::1` aufgeloest. Danach wird versucht aus den client ips und den peer_ips moeglichst alles zusammen zu sammeln, damit moeglichst viel antworten dabei sind, von denen hoffentlich eine funktioniert. Dazu musste noch die `dhcpv6` option eingeschalten werden. Damit ist es auch moeglich einen IPv6-only router mit wirklich minimaler config zu bauen. --- Eine kleine Falle ist leider noch uebrig, die mir beim testen aufgefallen ist: Mit leerer `peer_ip6` und `WAN`-Zugriff wird leider wieder unter Umstaenden eine falsche Source IP gewaehlt. Abhilfe schafft die `peer_ip6` zu setzen, damit auf dem Babelinterface eine Globale Adresse liegt. Dann wird diese auch genommen. Eventuell sollte man also da auch ein Fallback in der Zukunft generieren. --- (Minimale) Beispielconfig fuer IPv6-only zum testen (funktioniert prima hier): ```uci config gateway 'meta' option config_version '1' option peer_ip6 '2a0b:f4c0:stuv:wxyz::' config vlan '1' option comment 'client' ## t: tagged. CPU-Port wird automatisch hinzugefügt. option ports '1 2 3 4' config vlan '100' option comment 'babel' option ports '0t' config vlan '2' option comment 'wan' option ports '0' config client option vlan '1' list ip6addr '2a0b:f4c0:stuv:wxyz::/64' config dns list server 'fd43:5602:29bd:ffff:1:1:1:64' config babelpeer option vlan '100' ``` --- In `/etc/config/dhcp` werden dann pro IP so ein eintrag angelegt: ``` ... config domain option ip '2a0b:f4c0:stuv:wxyz::' option name 'local.fff.community ... ```
ChristianD reviewed 2021-01-19 16:16:52 +01:00
@ -30,0 +30,4 @@
set dhcp.client.dhcpv6='server'
add dhcp domain
set dhcp.@domain[-1].ip="fdff::"
Member

fdff::1 oder?

fdff::1 oder?
Owner

und ggf. /64?

und ggf. /64?
Author
Owner

@ChristianD jop, hast recht. Hatte ich auf dem Testrouter schon gefixt und dann vermutlich vergessen. Danke.

@ChristianD jop, hast recht. Hatte ich auf dem Testrouter schon gefixt und dann vermutlich vergessen. Danke.
jkimmel marked this conversation as resolved
jkimmel force-pushed fdff from a8aa00f665 to 4048f3e10e 2021-01-19 21:26:26 +01:00 Compare
Author
Owner
  • Rebased
  • fdff::1 statt fdff::
  • Eintraege werden als autogeneriert markiert und auch nur diese wieder ersetzt, um keine Nutzereintraege kaputt zu machen
* Rebased * `fdff::1` statt `fdff::` * Eintraege werden als autogeneriert markiert und auch nur diese wieder ersetzt, um keine Nutzereintraege kaputt zu machen
jkimmel force-pushed fdff from 4048f3e10e to 85523da612 2021-01-19 21:29:38 +01:00 Compare
jkimmel force-pushed fdff from 85523da612 to da58223533 2021-01-19 21:48:50 +01:00 Compare
jkimmel force-pushed fdff from da58223533 to 0484f6d697 2021-02-20 11:24:52 +01:00 Compare
jkimmel force-pushed fdff from 0484f6d697 to 493208b00b 2021-02-20 12:30:13 +01:00 Compare
Author
Owner

So.. rebased und gerade nochmal getestet. Die Kiste war immer mit local.fff.community erreichbar. Nach einem factory reset hat es auf fdff::1 gezeigt. Nachdem ich dann ne minimale config reingebaut habe, war das Geraet auch sofort unter der richtigen Adresse erreichbar.

Also bitte noch einmal testen und nachdenken, ob wir die Loesung so wollen. Wer testen moechte, aber nicht in der Lage ist selbst die Firmware zu bauen, bitte Bescheid geben.

So.. rebased und gerade nochmal getestet. Die Kiste war immer mit `local.fff.community` erreichbar. Nach einem factory reset hat es auf `fdff::1` gezeigt. Nachdem ich dann ne minimale config reingebaut habe, war das Geraet auch sofort unter der richtigen Adresse erreichbar. Also bitte noch einmal testen und nachdenken, ob wir die Loesung so wollen. Wer testen moechte, aber nicht in der Lage ist selbst die Firmware zu bauen, bitte Bescheid geben.
jkimmel added a new dependency 2021-02-20 12:35:24 +01:00
Owner

Bei mir funktioniert fdff::1 grundsätzlich nicht ordentlich (keine Ahnung warum), während die MAC-basierten Adressen fdff::aabb:ccdd:eeff gut (=normal) funktionieren.

Entsprechend würde ein default auf fdff::1 bei mir zu größeren Problemen bei der Installation führen (klar, ich kann mir da behelfen, aber ich frage mich, ob sonst noch jemand dieses Problem hat).

Bei mir funktioniert fdff::1 grundsätzlich nicht ordentlich (keine Ahnung warum), während die MAC-basierten Adressen fdff::aabb:ccdd:eeff gut (=normal) funktionieren. Entsprechend würde ein default auf fdff::1 bei mir zu größeren Problemen bei der Installation führen (klar, ich kann mir da behelfen, aber ich frage mich, ob sonst noch jemand dieses Problem hat).
adschm closed this pull request 2021-02-20 13:15:44 +01:00
adschm reopened this pull request 2021-02-20 13:15:48 +01:00
jkimmel added 1 commit 2021-02-20 14:11:24 +01:00
a3ad66f074 fff-dhcp: blacklist A record after factory reset
To speed up name resolution, blacklist the A record for
local.fff.community by pointing to 0.0.0.0.

Without this, dnsmasq can't answer to A lookups and clients might time
out waiting for a reply.

Signed-off-by: Johannes Kimmel <fff@bareminimum.eu>
Author
Owner

Ab jetzt wird zusaetzlich noch der der A Record zu local.fff.community blockiert. Mein Testsystem laeuft ohne ansonstenten staendig in timeouts. Das Problem besteht allerdings nicht, wenn eine ordentliche IP konfiguriert ist. Deshalb existiert der Eintrag auch nur solange nichts anderes konfiguriert wurde.

Ab jetzt wird zusaetzlich noch der der `A` Record zu `local.fff.community` blockiert. Mein Testsystem laeuft ohne ansonstenten staendig in timeouts. Das Problem besteht allerdings nicht, wenn eine ordentliche IP konfiguriert ist. Deshalb existiert der Eintrag auch nur solange nichts anderes konfiguriert wurde.
fbl removed a dependency 2021-12-30 17:26:23 +01:00
fbl reviewed 2021-12-30 17:47:26 +01:00
@ -28,2 +22,4 @@
#set new ip6addr
if ip6addr=$(uci -q get gateway.@client[0].ip6addr); then
#remove old ip6addr
uci delete network.client.ip6addr
Owner

Das hier darf nicht ins if rutschen, sonst werden die Adressen nicht entfernt, wenn keine ip6addr im /etc/config/gateway angegeben sind.

Das hier darf nicht ins if rutschen, sonst werden die Adressen nicht entfernt, wenn keine ip6addr im /etc/config/gateway angegeben sind.
This pull request has changes conflicting with the target branch.
  • src/packages/fff/fff-dhcp/Makefile
  • src/packages/fff/fff-layer3-config/Makefile
  • src/packages/fff/fff-layer3-config/files/etc/layer3.d/30-network-client
Sign in to join this conversation.
No description provided.