Auto-Registrierung neue Knoten für Münster

Off-Topic. Siehe dazu hier: Fragen zur Anonymität des Knotenbetreibers

Das zu entscheiden liegt nicht alleine bei mir. Ich würde einfach vorschlagen das beim nächsten Treffen am Mittwoch zu bequatschen und gemeinsam einen Entschluss zu fassen.

Die eMail-Adresse des Absenders muß nicht zwingend korrekt sein … Ja, klar ist eine Kontaktmöglichkeit wünschenswert. Da würde ich aber eher das luci-Formular als Blocker (keine irgendwas at irgendwas eingegben?) konfigurieren denn auf zeitraubende eMail setzen …

Mir war es halt wichtig hier mal ein möglichst großes Meinungsbild zu sammeln, insbesondere von denen die Mittwoch dann nicht vor Ort sind.

Das wir jetzt zügig eine sinnvolle Entscheidung treffen sehe ich genau so.

Hmm … gerade in dem Kontext ist weniger Info eventuell sogar noch besser.
Je weniger Daten vorhanden sind desto weniger kann auch angefragt werden und ggf. fälschlicherweise auf einen Knotenbetreiber zurückgeführt werden.

Haben wir heute in der Warpzone diskutiert:

Ergebnis: Wir machen Autoregistrierung (einstimmig)
Aber: Statt nur in einer Blacklist zu schauen, wollen wir „gute“ Keys einsammeln um im Krisenfällen wieder auf Whitelisting umstellen zu können.

Damit wir dies auch machen können brauchen wir weiterhin die Mail vom Nutzer.
Diese soll nicht an info@ gehen sondern an registrierung@
Dort soll ein Autoresponder laufen, der nett antwortet („Willkommen“, Infos, Links).
Somit können wir von Black auf Whitelisting umstellen, wenn wir es müssen.
Ob wir aus der Mail dann noch den Key extrahieren - alles noch herauszufinden.

Und: Wir glaube das wir es nicht brauchen werden. :wink:

Beschlossen und verkündet
@void, @FanLin, @sandzwerg, @vax, @MPW, @paulinsche

3 „Gefällt mir“

Geht doch! Dann machen wir uns bald™ an die Umsetzung.

Ist das schon fertig programmiert? Ich würde dann anfangen ein paar Knoten umzuziehen.

Nein ist noch keiner zu gekommen

Die Konfiguration der Server ist jetzt durch.

Auf den Servern werden jetzt alle Nodes anommen die nicht explizit geblacklistet wurden.

2 „Gefällt mir“

Top! Danke für die Arbeit, @void.

1 „Gefällt mir“

Muss ich gleich mal ausprobieren! Bin durch: autoupgrade bei zwei Knoten erfolgreich durch: ffwaf-baui1 und ffwaf-baui2 sind jetzt an Freifunk Münster angeschlossen.

Kurze Frage (offtopic): wie komme ich am einfachsten an die IP Adressen der Knoten?

Gute Frage! Ich glaub das geht nicht wenn ich @FanLin richtig verstanden habe. Das wäre schon gut.

Die IP-Adressen der Knoten stehen in den Alfred Daten. Zumindest im Ruhrgebiet ist das so.

Gibt es den einen Alfred in Münster?

Oder gibt es eine andere Möglichkeit mit einem entfernten Node Kontakt aufzunehmen.

Ja. Alfred gibt es in Münster; die Daten werden derzeit aber nicht öffentlich gemacht.
An einer Lösung, um Kontakt mit entfernten Nodes aufzunehmen, wird gearbeitet

Du möchtest die globale IP(v6)-Adresse eines Nodes ermitteln von dem Du nur die MAC-Adresse weisst? Richtig?

Zur Not reicht mir das auch.

Versuch mal, von einem Node aus, folgendes:

ping nodename.nodes.ffms

Wichtig! Den Nodenamen nur in Kleinschrift.

Leider klappt das noch nicht bei allen Nodes. Alfred mixt manchmal die Reihenfolge der Adressen in seiner Ausgabe. Unser Skript wird aber zeitnah angepasst, damit alles wieder korrekt funktioniert.

Funktionierendes Beispiel: ping fanlin-nanmen.nodes.ffms
Nicht funktionierendes Beispiel: ping fanlin-beibao.nodes.ffms

1 „Gefällt mir“

Das ist ganz einfach (wenn man die Bildunsgvorschrift kennt).

Ein Beispiel.

Aus dem Graph die MAC Adresse eines Nodes besorgen:

ffwaf-baui1 / e8:94:f6:62:56:94

+02h auf das Most Significant Byte addieren, ergibt

ea:94:f6:62:56:94

Bildungsvorschrift: Prefix + erster Teil MAC + fffe + zweiter Teil MAC

2a03:2260:115:: + ea:94:f6 + fffe + 62:56:94

ergibt

2a03:2260:115::ea94:f6ff:fe62:5694

Test:

# ping 2a03:2260:115::ea94:f6ff:fe62:5694
PING 2a03:2260:115::ea94:f6ff:fe62:5694 (2a03:2260:115:0:ea94:f6ff:fe62:5694): 56 data bytes
64 bytes from 2a03:2260:115:0:ea94:f6ff:fe62:5694: seq=0 ttl=64 time=83.307 ms
64 bytes from 2a03:2260:115:0:ea94:f6ff:fe62:5694: seq=1 ttl=64 time=62.205 ms
64 bytes from 2a03:2260:115:0:ea94:f6ff:fe62:5694: seq=2 ttl=64 time=38.799 ms
--- 2a03:2260:115::ea94:f6ff:fe62:5694 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 38.799/61.437/83.307 ms

$ links -dump http://[2a03:2260:115::ea94:f6ff:fe62:5694]/cgi-bin/status
                                  ffwaf-baui1

  Model: TP-Link TL-WR841N/ND v9
 Firmware release: 2014.4-4.1exp20150206

 17:29:21 up 2 days,  2:59,  load average: 0.13, 0.16, 0.28

 6: br-client: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
     link/ether e8:94:f6:62:56:94 brd ff:ff:ff:ff:ff:ff
     inet6 fd68:e2ea:a53:0:ea94:f6ff:fe62:5694/64 scope global dynamic
        valid_lft 86371sec preferred_lft 14371sec
     inet6 2a03:2260:115:0:ea94:f6ff:fe62:5694/64 scope global dynamic
        valid_lft 86371sec preferred_lft 14371sec
     inet6 fe80::ea94:f6ff:fe62:5694/64 scope link
        valid_lft forever preferred_lft forever

              total         used         free       shared      buffers
 Mem:         28860        25868         2992            0         1864
 -/+ buffers:              24004         4856
 Swap:            0            0            0

 Filesystem           1K-blocks      Used Available Use% Mounted on
 /dev/root                 2304      2304         0 100% /rom
 /dev/mtdblock3             640       236       404  37% /overlay

Neighbours

  wlan0

 Joined IBSS 02:d1:11:37:fc:38 (on wlan0)
         SSID: 02:d1:11:37:fc:38
         freq: 2412


 Station ea:e1:28:bb:45:e6 (on wlan0)
         inactive time:  10 ms
         rx bytes:       2953569707
         rx packets:     17269374
         tx bytes:       264361656
         tx packets:     1494896
         tx retries:     266539
         tx failed:      9
         signal:         -55 [-62, -56] dBm
         signal avg:     -55 [-62, -56] dBm
         tx bitrate:     240.0 MBit/s MCS 13 40MHz short GI
         rx bitrate:     270.0 MBit/s MCS 15 40MHz
         authorized:     yes
         authenticated:  yes
         preamble:       long
         WMM/WME:        yes
         MFP:            no
         TDLS peer:      no


VPN status

 fastd running for 183532.162 seconds
 There are 3 peers configured, of which 0 are connected:

 mesh_vpn_backbone_peer_fusselkater: not connected
 mesh_vpn_backbone_peer_fanlin: not connected
 mesh_vpn_backbone_peer_commander1024: not connected

3 „Gefällt mir“