Anfragen mit Koordinaten erst an den KeyXchange senden, wenn Kontaktadresse gesetzt #62

New Issue

mantis-bot · 2021-01-05T14:01:55+01:00

mantis-bot commented

2021-01-05 14:01:55 +01:00

Um eine fehlerhafte Konfiguration ohne Kontaktadresse zu verhindern, sollte die Anfrage mit Koordinaten erst an den KeyXchange gesendet werden, wenn auch eine Kontaktadresse gesetzt ist.

Somit wird verhindert keine Kontaktadresse einzutragen.

Reported by: fbl
Submitted on: 2020-10-12
Imported from: https://mantis.freifunk-franken.de/view.php?id=0000146

Um eine fehlerhafte Konfiguration ohne Kontaktadresse zu verhindern, sollte die Anfrage mit Koordinaten erst an den KeyXchange gesendet werden, wenn auch eine Kontaktadresse gesetzt ist. Somit wird verhindert keine Kontaktadresse einzutragen. Reported by: fbl Submitted on: 2020-10-12 Imported from: https://mantis.freifunk-franken.de/view.php?id=0000146

fbl was assigned by mantis-bot

2021-01-05 14:01:55 +01:00

fbl added the

mantis

label 2021-01-05 14:24:07 +01:00

fbl added the

RFC

label 2021-01-05 15:53:03 +01:00

fbl commented

2021-01-30 23:33:13 +01:00

Hat hierzu jemand eine Meinung?

adschm commented

2021-01-30 23:35:55 +01:00

Ich finde das eine sehr gute Idee.

ChristianD commented

2021-01-31 00:04:59 +01:00

Gegen zentrale Kontrolle

adschm commented

2021-01-31 00:06:17 +01:00

Ist ja keine zentrale Kontrolle. Die Funktion ist auf dem Router implementiert.

ChristianD commented

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

lass ich gelten wenn es nicht default an ist sondern vom User expliziet aktiviert werden muss.

adschm commented

2021-01-31 00:17:13 +01:00

Hä? Wenn ich eine Schutzvorkehrung dagegen baue, dass jemand einen Router aufstellt, ohne die Kontaktadresse einzugeben, dann macht es doch keinerlei Sinn, wenn der faule Nutzer diese Schutzfunktion vorher aktivieren muss?

adschm commented

2021-01-31 00:19:10 +01:00

Die Teilnahme am FFF-Netz setzt das Hinterlegen einer Kontaktadresse voraus. Ist die nicht gesetzt, dann kriegt man kein (Auto-)Netz. Eigentlich hätte man das von Anfang an so bauen müssen.

SebaBe commented

2023-01-05 11:35:41 +01:00

Ich bin auch dafür.
Man kann zwar nicht prüfen, ob die Kontaktadresse korrekt ist, aber die Hinweiswirkung, dass dieses Feld nicht optional ist, reicht schon mal.

Falls das noch ins WebIF kommt, am besten mandatory und optional Zeilen kennzeichnen, zB mit nem *

Ich bin auch dafür. Man kann zwar nicht prüfen, ob die Kontaktadresse korrekt ist, aber die Hinweiswirkung, dass dieses Feld nicht optional ist, reicht schon mal. Falls das noch ins WebIF kommt, am besten mandatory und optional Zeilen kennzeichnen, zB mit nem *

fbl added this to the next-feature milestone 2023-01-05 11:52:55 +01:00

adschm commented

2023-01-05 16:07:56 +01:00

~~Was mir gerade noch einfällt: Das führt dann dazu, dass alle Knoten mit Reset (v.a. wenn dies aus Versehen/magisch von selbst passiert) im Monitoring als offline erscheinen.~~

Das ist ggf. ein nicht zu unterschätzender Malus. Vom Standpunkt der Usability finde ich es schon ganz praktisch, wenn man im Monitoring von diesen Knoten erkennen kann, dass sie angeschaltet sind und kommunizieren (im Gegensatz zu einem Knoten, der sich komplett aufgehängt hat). Entsprechend gibt es ja auch den Hinweis "Reset!" im Monitoring.

~~Oder habe ich hier einen Denkfehler?~~

Update: Unsinn, es geht hier ja um den KeyXchange, nicht um das Monitoring.

~~Was mir gerade noch einfällt: Das führt dann dazu, dass alle Knoten mit Reset (v.a. wenn dies aus Versehen/magisch von selbst passiert) im Monitoring als offline erscheinen.~~ ~~Das ist ggf. ein nicht zu unterschätzender Malus. Vom Standpunkt der Usability finde ich es schon ganz praktisch, wenn man im Monitoring von diesen Knoten erkennen kann, dass sie angeschaltet sind und kommunizieren (im Gegensatz zu einem Knoten, der sich komplett aufgehängt hat). Entsprechend gibt es ja auch den Hinweis "Reset!" im Monitoring.~~ ~~Oder habe ich hier einen Denkfehler?~~ Update: Unsinn, es geht hier ja um den KeyXchange, nicht um das Monitoring.

SebaBe commented

2023-01-05 16:18:48 +01:00

Sollten diese Knoten im Monitoring nicht online in der Trainstation landen?

Wenn ich es richtig verstanden habe, will man doch nur verhindern, dass die Nodes ohne Kontaktadressen eine Hood vom keyXchange bekommen?!

Sollten diese Knoten im Monitoring nicht online in der Trainstation landen? Wenn ich es richtig verstanden habe, will man doch nur verhindern, dass die Nodes ohne Kontaktadressen eine Hood vom keyXchange bekommen?!

adschm commented

2023-01-05 16:34:31 +01:00

Sollten diese Knoten im Monitoring nicht online in der Trainstation landen?

Wenn ich es richtig verstanden habe, will man doch nur verhindern, dass die Nodes ohne Kontaktadressen eine Hood vom keyXchange bekommen?!

Richtig, ich habe nicht richtig gelesen. Was ich geschrieben habe ist Unsinn.

> Sollten diese Knoten im Monitoring nicht online in der Trainstation landen? > > Wenn ich es richtig verstanden habe, will man doch nur verhindern, dass die Nodes ohne Kontaktadressen eine Hood vom keyXchange bekommen?! Richtig, ich habe nicht richtig gelesen. Was ich geschrieben habe ist Unsinn.

Sign in to join this conversation.