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.
Beschlossen und verkündet
@void, @FanLin, @sandzwerg, @vax, @MPW, @paulinsche
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.
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?
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
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