freifunk-franken
/
firmware
9
7
Fork 13
Code Issues 48 Pull Requests 7 Releases 17 Wiki Activity

fff-layer3: Add latency to nodewatcher #193

Closed
ChristianD wants to merge 1 commits from ChristianD/firmware:nodewatcherlatency into master
pull from: ChristianD/firmware:nodewatcherlatency
merge into: freifunk-franken:master
Conversation 11 Commits 1 Files Changed 1 +19
ChristianD commented 2021-12-28 19:53:34 +01:00
Member
Copy Link

This patch add the latency to ping.freifunk-franken.de to the nodewatcher data.

Signed-off-by: Christian Dresel freifunk@dresel.systems

This patch add the latency to ping.freifunk-franken.de to the nodewatcher data. Signed-off-by: Christian Dresel <freifunk@dresel.systems>
rohammer commented 2021-12-28 23:20:41 +01:00
Member
Copy Link

Hi Cristian,
funktionieren sollte es, solange man das busybox ping benutzt.

Warum nochmal eine Abhängigkeit in fff-layer3? Es gibt doch schon eine in fff-variant-layer3.

Hi Cristian, funktionieren sollte es, solange man das busybox ping benutzt. Warum nochmal eine Abhängigkeit in fff-layer3? Es gibt doch schon eine in fff-variant-layer3.
ChristianD commented 2021-12-29 07:17:48 +01:00
Author
Member
Copy Link

Hallo Robert

Ja mit Busybox Ping bin ich auch drüber gestolpert aber das ist ja bei unseren Routern ja so drinnen also muss es so sein.

Ich war mir unsicher in welches Paket das ganze soll, hab mich dann schlussendlich für das fff-layer3 entschieden da es hier mMn am besten passt und wenn dort der Nodewatcher verwendet wird, sollte mMn auch die Abhängigkeit zum nodewatcher hier mit rein oder?

Gruß

Christian

Hallo Robert Ja mit Busybox Ping bin ich auch drüber gestolpert aber das ist ja bei unseren Routern ja so drinnen also muss es so sein. Ich war mir unsicher in welches Paket das ganze soll, hab mich dann schlussendlich für das fff-layer3 entschieden da es hier mMn am besten passt und wenn dort der Nodewatcher verwendet wird, sollte mMn auch die Abhängigkeit zum nodewatcher hier mit rein oder? Gruß Christian
rohammer commented 2021-12-29 11:23:20 +01:00
Member
Copy Link

Hi Christian,

der nodewatcher ist kein notwendiges package und wird deshalb im metapackage fff-variant-layer3 ausgewählt. Kein package ist vom nodewatcher wirklich abhängig. Es ist eine zusätzliche Funktionalität. Und da ist es wesentlich übersichtlicher, wenn es nur die eine Stelle gibt, an der man den nodewatcher ein und aus machen kann.
Unser dependency tree ist schon verknotet genug. S. ./tools/dep-tree | dot -Tx11

Gruss Robert

Hi Christian, der nodewatcher ist kein notwendiges package und wird deshalb im metapackage fff-variant-layer3 ausgewählt. Kein package ist vom nodewatcher wirklich abhängig. Es ist eine zusätzliche Funktionalität. Und da ist es wesentlich übersichtlicher, wenn es nur die eine Stelle gibt, an der man den nodewatcher ein und aus machen kann. Unser dependency tree ist schon verknotet genug. S. `./tools/dep-tree | dot -Tx11` Gruss Robert
ChristianD commented 2021-12-29 12:03:43 +01:00
Author
Member
Copy Link

Hi Robert

Jetzt wo ich nochmal überlege, ich glaube du hast recht. Wir hatten uns mal geeinigt, das man eine Abhängigkeit nur macht wenn das Paket gar nicht ohne dem anderen funktioniert. Das ist hier ja nicht der Fall, es liegt dann halt nur ne File sinnlos rum.

Von daher tendiere ich jetzt auch eher zum rausnehmen

Gruß

Christian

Hi Robert Jetzt wo ich nochmal überlege, ich glaube du hast recht. Wir hatten uns mal geeinigt, das man eine Abhängigkeit nur macht wenn das Paket gar nicht ohne dem anderen funktioniert. Das ist hier ja nicht der Fall, es liegt dann halt nur ne File sinnlos rum. Von daher tendiere ich jetzt auch eher zum rausnehmen Gruß Christian
fbl added the
layer3
 label 2021-12-30 18:05:40 +01:00
ChristianD commented 2022-01-01 09:47:34 +01:00
Author
Member
Copy Link

Das ganze funktioniert so natürlich manchmal nicht. Was ich hier kaum noch habe und deshalb nicht bedacht habe:
Bei WAN Anschluss geht der Ping natürlich aufn WAN raus.

Das ganze funktioniert so natürlich manchmal nicht. Was ich hier kaum noch habe und deshalb nicht bedacht habe: Bei WAN Anschluss geht der Ping natürlich aufn WAN raus.
ChristianD commented 2022-03-07 15:43:48 +01:00
Author
Member
Copy Link

ich hab hier nochmal drüber nachgedacht. Ich hätte das auf jeden Fall sehr gerne drinnen und ich tendiere aktuell dazu es konfigurierbar über die /etc/config/fff zu machen wohin die Pings gehen. Dann kann man flexibel aggieren wo man hin pingen will und wo man es selbst bei diesen Standort für sinnvoll erachtet

Einwände? Bessere Ideen?

ich hab hier nochmal drüber nachgedacht. Ich hätte das auf jeden Fall sehr gerne drinnen und ich tendiere aktuell dazu es konfigurierbar über die /etc/config/fff zu machen wohin die Pings gehen. Dann kann man flexibel aggieren wo man hin pingen will und wo man es selbst bei diesen Standort für sinnvoll erachtet Einwände? Bessere Ideen?
fbl commented 2022-03-07 19:45:17 +01:00
Owner
Copy Link

Wenn das ping-target konfigurierbar, und das ganze Ding standardmäßig komplett deaktiviert ist: Keine Einwände.

Wieso besteht eine Abhängigkeit zu fff-nodewatcher? Es wird doch überhaupt keine Funktionalität von fff-nodewatcher benutzt, sondern nur optional für fff-nodewatcher bereitgestellt.

Wenn das ping-target konfigurierbar, und das ganze Ding standardmäßig komplett deaktiviert ist: Keine Einwände. Wieso besteht eine Abhängigkeit zu fff-nodewatcher? Es wird doch überhaupt keine Funktionalität von fff-nodewatcher benutzt, sondern nur optional für fff-nodewatcher bereitgestellt.
fbl added the
feature
 label 2022-03-07 19:45:27 +01:00
ChristianD commented 2022-03-07 20:17:50 +01:00
Author
Member
Copy Link

Wenn das ping-target konfigurierbar, und das ganze Ding standardmäßig komplett deaktiviert ist: Keine Einwände.

dann werde ich das die Tage mal so basteln

Wieso besteht eine Abhängigkeit zu fff-nodewatcher? Es wird doch überhaupt keine Funktionalität von fff-nodewatcher benutzt, sondern nur optional für fff-nodewatcher bereitgestellt.

das hat Robert oben schon angemerkt, ist natürlich quatsch.

> Wenn das ping-target konfigurierbar, und das ganze Ding standardmäßig komplett deaktiviert ist: Keine Einwände. dann werde ich das die Tage mal so basteln > Wieso besteht eine Abhängigkeit zu fff-nodewatcher? Es wird doch überhaupt keine Funktionalität von fff-nodewatcher benutzt, sondern nur optional für fff-nodewatcher bereitgestellt. das hat Robert oben schon angemerkt, ist natürlich quatsch.
ChristianD force-pushed nodewatcherlatency from 646bf2fa5b to d945b83736 2022-03-10 19:55:25 +01:00 Compare
ChristianD force-pushed nodewatcherlatency from d945b83736 to 6de5271b20 2022-03-10 19:56:37 +01:00 Compare
ChristianD commented 2022-03-11 09:56:42 +01:00
Author
Member
Copy Link

Habs überarbeitet:

  • Abhängigkeit entfernt
  • konfigurbar über /etc/config/fff
  • Daten nur senden, wenn auch konfiguriert
Habs überarbeitet: * Abhängigkeit entfernt * konfigurbar über /etc/config/fff * Daten nur senden, wenn auch konfiguriert
rohammer reviewed 2022-03-11 14:33:47 +01:00
src/packages/fff/fff-layer3/files/usr/lib/nodewatcher.d/90-latency.sh
@ -0,0 +1,19 @@
#!/bin/sh
ipv4dest=$(uci -q get fff.latency.ipv4)
ipv6dest=$(uci -q get fff.latency.ipv6)
rohammer commented 2022-03-11 14:33:47 +01:00
Member
Copy Link

Es gibt doch ein /etc/config/nodewatcher. Dort wäre das doch besser aufgehoben.

In fff ist das nicht so schön.

Robert

Es gibt doch ein /etc/config/nodewatcher. Dort wäre das doch besser aufgehoben. In fff ist das nicht so schön. Robert
ChristianD commented 2022-03-11 15:16:29 +01:00
Author
Member
Copy Link

Prinzipiell hast du recht,

Prinzipiell will ich aber eigentlich alles, was ein User konfiguriert mal auf /etc/config/fff zusammen gefasst haben, siehe auch hier:

#118 (comment)

wir sollten uns da mal auf einen Konsens einigen sonst stolpern wir da ständig drüber ;)

Prinzipiell hast du recht, Prinzipiell will ich aber eigentlich alles, was ein User konfiguriert mal auf /etc/config/fff zusammen gefasst haben, siehe auch hier: https://git.freifunk-franken.de/freifunk-franken/firmware/issues/118#issuecomment-2558 wir sollten uns da mal auf einen Konsens einigen sonst stolpern wir da ständig drüber ;)
fbl commented 2022-03-11 15:24:35 +01:00
Owner
Copy Link

/etc/config/nodewatcher ist aktuell nicht update-sicher.

/etc/config/nodewatcher ist aktuell nicht update-sicher.
rohammer commented 2022-03-11 15:34:55 +01:00
Member
Copy Link

Ich waere dafuer das zu aendern. Hatte da mal interfaces drin blacklisted. Nervt schon, wenn das jedesmal weg ist.

Ich waere dafuer das zu aendern. Hatte da mal interfaces drin blacklisted. Nervt schon, wenn das jedesmal weg ist.
fbl commented 2022-03-11 17:27:43 +01:00
Owner
Copy Link

Dafür müssten wir allerdings erstmal sämtliche Parameter dort entfernen, die nicht dafür vorgesehen sind, persistent zu sein (mesh_interface, die vorgegebenen Interfaces für black- und whitelist, status_text_file und data_file).

Dafür müssten wir allerdings erstmal sämtliche Parameter dort entfernen, die nicht dafür vorgesehen sind, persistent zu sein (mesh_interface, die vorgegebenen Interfaces für black- und whitelist, status_text_file und data_file).
ChristianD commented 2022-03-11 18:11:47 +01:00
Author
Member
Copy Link

#118 (comment)

ich verweise nochmal darauf. Wollen wir jetzt vom User einstellbare config an einer Stelle haben oder nicht? Das ist mMn erstmal die grundlegende Frage.

https://git.freifunk-franken.de/freifunk-franken/firmware/issues/118#issuecomment-2558 ich verweise nochmal darauf. Wollen wir jetzt vom User einstellbare config an einer Stelle haben oder nicht? Das ist mMn erstmal die grundlegende Frage.
fbl commented 2022-03-15 13:15:18 +01:00
Owner
Copy Link

Auch wenn dies später möglicherweise eine Migration erforderlich macht: Ich würde das aktuell mal zurückstellen und erstmal in config/fff liegen lassen. Wie wir das langfristig bauen wollen, können wir in #118 weiter verfolgen.

Auch wenn dies später möglicherweise eine Migration erforderlich macht: Ich würde das aktuell mal zurückstellen und erstmal in config/fff liegen lassen. Wie wir das langfristig bauen wollen, können wir in #118 weiter verfolgen.
fbl removed the
layer3
 label 2022-03-15 13:14:03 +01:00
fbl commented 2022-03-15 13:16:15 +01:00
Owner
Copy Link

Acked-by: Fabian Bläse <fabian@blaese.de>

`Acked-by: Fabian Bläse <fabian@blaese.de>`
fbl added this to the 20220405-beta milestone 2022-03-15 13:16:21 +01:00
fbl commented 2022-03-25 13:57:56 +01:00
Owner
Copy Link

Auf meinen staging tree applied.

Auf meinen staging tree applied.
fbl closed this pull request 2022-03-25 13:57:56 +01:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
RFC

   
RFT

   
WIP

   
blocked

   
bsp

touching bsp files or adding devices

  
bug

Something is not working

  
build/scripts/tools

touching buildscript or other tools

  
duplicate

This issue or pull request already exists

  
feature

New feature

  
fixed

Issue that got resolved

  
layer3

only for layer3 FW

  
mantis

Imported from mantis

  
more details required

Reported information is insufficient to debug the issue

  
needs changes

   
node

only for node FW

  
packages/fff

touching our packages

  
rejected

Rejected or won't fix

  
security

   
trivial

simple non-functional changes that are mostly matter of taste

  
upstream

touching upstream version, build or feed patches

No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
Milestone
Clear milestone
No items
No Milestone
20220405-beta
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: freifunk-franken/firmware#193
No description provided.
Delete Branch "ChristianD/firmware:nodewatcherlatency"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?