because we can …
kleines script das im loop läuft und aus einer Datei Zeile für Zeile eine ssid ausliesst und damit ein AP bespielt, die Datei wird initial gefüllt … ist ein shell script das so direkt auf den Knoten laufen kann
… schöne Grüße vom #ffwcwhttps://twitter.com/hashtag/ffwcw
Für den Fall das jemand Spass am Gerät haben möchte …
#!/bin/sh
# script to use AP SSID as twitter alike local tweet broadcaster
# !because we can! - greetings from Freifunk Wireless Comunity Weekend 2016
# TP Link mostly allow >= 8 AP/ mesh_node (iw phy0 info)
#
# milestone : making if , get it up and sending ssid works
#
# todo logic for resources to ssid foo change :
# suggesting some kind of http available pad in raw format
# some fancy logic with wget/curl to get some stuff later
# actually changing from this file
#time in seconds to change
next=10
# open AP
foomac=42:42:$(iwinfo | grep Acc |head -n1 |grep -oE '[^ ]+$' |cut -d":" -f 3-6)
iw phy0 interface add twitterer type managed
ifconfig twitterer hw ether $foomac
ifconfig twitterer up
# initial fill a file with some lines
cat > /tmp/foofile << EOL
mystinky litte ssid
nazis stinken
yay #ffwcw2016
c-base blinky blinky
EOL
while true; do
oldssid=initial
while read line ; do
# limit line to 32 specific characters
newssid=$(echo $line |grep -E '[a-z_\-\d]+$' |cut -c1-32|sed s/" "/"_"/g)
cat > /tmp/twitterer_minimal_hostapd.conf << EOL
interface=twitterer
driver=nl80211
ssid=$newssid
channel=1
EOL
# check if hostapd is running
if [ $(ps | grep hostapd | grep twitterer | wc -l) = 0 ]; then
hostapd -B /tmp/twitterer_minimal_hostapd.conf
fi
HUP_NEEDED=1
if [ $HUP_NEEDED == 1 ]; then
killall -HUP hostapd # Send HUP to all hostapd um die neue SSID zu laden
fi
sleep $next
oldssid=$newssid
done < /tmp/foofile
done
jemand den Befehl zu hand um das zu bridgen in die client bridge brctl addif br-client twitterer tut nicht
Es geht eher um das Microbloggingkonzept von Twitter als um einen echten Twitterclient. Hierfür wird einfach die SSID mit dern entsprechenden Nachricht ausgestrahlt. Fertig ist das Statement.
Ja, es kostet eigentlich nur unnötig Airtime und ist total unprofessionell, ABER: Spaß kostet Und was wäre Freifunk ohne Spaß?
ja, @Sheogorath hat das schon ganz gut erfasst, wie man die foofile (in diesem Beispiel) füllt, ist jedem selber überlassen und die airtime is minimal … man könnt ja sogar das iface in die client bridge hängen …
Ich habe nun verstanden, dass das Script eigentlich nur ein MOTD-file sequentiell herauspiped als SSID.
So schön, so gut.
Aber wozu?
Ich wüsste zumindest spontan keinen Client, der permanent die SSIDs so aus der Luft fangen und wieder zusammensetzen würde, dass jemand mit dem Ergebnis etwas anfangen könnte.
(Abgesehen davon dass sich mir der Sinn dieser Art von Broadcasts nicht erschließt, wenn man doch sowieso ein offenes freies Netz hat, über das Broadcasts besser geschickt werden können.)
@MPW ich vermute die behalten die connection, da die ja MAC basiert ist, allerdings wird der not_work_manager da verwirrt werden … weil der lieber und automatisch zu bekannten netzen connected
Da irgendwelche wichtigen/weltbewegenden Informationen zu broadcasten an ein Publikum, das eigentlich gar nicht solches sucht, sondern sich solche Listen nur aus purem akuten Bedarf anzeigen lassen möchte: Hat was von Umweltverschmutzung.
So wie man auch mit Lärm die Umwelt verschmutzt, wenn man glaubt, der eigene Musikgeschmack sei so großartig, dass man mit offenen KFZ-Seitenscheiben die Mitmenschen durch Beschallung zu erfreuen glaubt.
(Ich behaupte, dass das Publikum davon im harmlosesten Fall nur genervt ist.)
Früher hätte man behauptet, Leute, die sich über vorsätzliche Ruhestörung beschweren seien Spießer.
Ich halte es nicht für „Spaß“ oder „lustig“, auf einem shared Medium aus purer Langeweile Sachen herauszupusten, die auch noch Mitmenschen potentiell in der Usability von Geräten (ja, es gibt embedded Devices, die schlecht sind) behindern.
In diesem Fall, wenn die Liste der „verfügbaren SSID“ künstlich mit Jux-Strings aufgebläht wird „weil man es kann“.
Ich hoffe schlicht, dass das in Niveau ist, auf das sich nicht zu viele Freifunkende begeben.
Wenn ich jezz blub schreib, blähste den artikel dann hier weiter mit heißer luft auf?
Merkste was?
Viell willste aber auch dein eig Axiom? Ein thread der mehr wie 2 @adorfer comments enthält is inhaltlich am ende. Das empfind ich als sehr schade, und hab ich so schon mehrfach erlebt.
Ich merke, dass Du mit persönlichen Angriffen arbeitest, statt Dich einer sachlichen Diskussion zu stellen.
Wünschenswert fände ich es, wenn Du inhaltlich darauf eingehen würdest, ob es sinnvoll ist, Text-Dateien als wechselnde SSID zu broadcasten.
Denn selbst wenn es technisch möglich und sicher auch nicht verboten ist, möchte ich schlicht davon abraten, dieses zu tun.
Aber ich lasse mich gern eines besseren belehren, dass es sinnvolle Anwendungsszenarien gibt und dass keine negativen Reaktionen zu erwarten sind (nur wie würde man es messen/mitbekommen, wenn da $NACHBAR an seinem Smart-TV oder der Wifi-Körperfettwaage verzweifelt beim Setup, weil da bereits Dutzende (?) von anderen SSIDs in der Luft hängen, weil z.B. der EmbeddedClient ein zu großes Monitoring-Interval hat…
Das ist natürlich spekulativ. Aber darauf würde ich es schlicht nicht ankommen lassen, wenn wir uns doch zur Aufgabe gemacht haben, möglichst viele Menschen ohne (oder mit niedrigsten) Barrieren ins Netz zu bringen.
Ich habe den Sinn jetzt nicht verstanden. Wenn es keinen gibt, dann klärt mich bitte dahingehend auf. Nur aus „Spass am Gerät“ kann ich natürlich allerhand Dinge tun, z.B. Wettervorhersagen per SSID posten oder die aktuelle Uhrzeit oder die Gewinnzahlen sämtlicher weltweiter Lotterien.
Es werden also Twitter-Nachrichten per SSID gepostet. Wenn man jetzt nur kurz vorbei kommt, bekommt man also genau eine mit. Bei aufeinander folgenden Nachrichten mit Bezug zu einander fehlt also jede Menge. Ich versteh’s nicht.
„Because we can“ kann ich auch diverse andere Dinge tun.
Ich bin verwirrt.
Um mal einen Hauch von Freifunk hier einziehen zu lassen:
Ich glaube, die Clients fliegen raus. Zumindest wären sonst die inzwischen teilwweise verwendeten SSID-Wechsel bei Verlust des Uplinks sinnlos („_OFFLINE“-SSIDs). Die sollen ja gerade die Verbindung trennen und den Client dazu bewegen, sich einen anderen AP zu suchen, der die normale SSID ausstrahlt.
Insofern kann man bei ständigem SSID-Wechsel keinen normalen Netzbetrieb fahren und hat einen reinen Broadcaster, der mit SSIDs um sich wirft. Ob das gut ist? Nur weil man es kann?
Denke auch, dass man mit etwas grep-sed-cut-tail-Magie sinnvollere Dinge machen koennte, glaube aber auch nicht an den Untergang des Abendlandes wenn der eine oder andere mal fuer ein paar Stunden idiotische SSIDs broadcastet.
@adorfer: Das ist/war sicher eines dieser Projekte, die man enthusiastisch angeht und wenn sie fertig, auch gleich gegessen sind. Viel gelernt und abgelegt, braucht man keine grossen Wellen drum machen.
Ok, dann habe ich es hoffentlich verstanden.
Ich war fälschlich davon ausgegangen, dass einem das Ergebnis irgendwas bringt, was irgendwie „Spass“ macht.
Aber wenn es keinen Nutzwert gibt abgesehen davon, ein wenig über den hostapd zu lernen.
Wobei dieser Seitenkanal durchaus sinnvoll nutzbar wäre, wenn man doch InBand Informationen übertragen könnte, wenn man mal DFS implementieren wollte, insbesondere für 5GHz.
Und was wäre Freifunk ohne Spaß? 
