<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi David,</p>
<p>danke für die Erklärung, jetzt kann ich es nachvollziehen ;)</p>
<p>Jap, services.ffda.io wäre wirklich klasse. Kann gerne mit auf
meinen internen Webserver, die paar MB hab ich auch noch frei ;)<br>
</p>
<p>Schönen Abend zusammen!<br>
</p>
<div class="moz-cite-prefix">On 15.03.2017 21:28, David Bauer wrote:<br>
</div>
<blockquote
cite="mid:5fefa127-a21e-5847-f18c-bb7a1acb9f53@david-bauer.net"
type="cite">
<pre wrap="">Hallo Daniel,
die Firewall lässt selektiv einzelne Pakete wie ARP oder DHCP durch.
Welche das genau sind, ist im Gluon Paket
"gluon-ebtables-filter-multicast" [1] festgelegt.
Autodiscovery wäre sicher eine super Sache für sowas. Eine
Übersichtsseite a la "services.ffda.io" wäre wohl was, damit die
Services wenigstens unkompliziert gefunden werden können. :)
[1]
<a class="moz-txt-link-freetext" href="https://github.com/freifunk-gluon/gluon/tree/master/package/gluon-ebtables-filter-multicast">https://github.com/freifunk-gluon/gluon/tree/master/package/gluon-ebtables-filter-multicast</a>
Schöne Grüße
David
Am 2017-03-15 um 21:12 schrieb Daniel:
</pre>
<blockquote type="cite">
<pre wrap="">Hallo Marco,
danke für deine Mail und für die Infos!
Genau, Broadcasts zu unterbinden macht Sinn. Zum Verständnis: Wie werden
ARP-Requests, die ja auch Broadcasts sind, vom regulären "Rauschen" (wie
z. B. die Broadcasts des Minecraft-Servers) unterschieden? ARPs müssen
ja weitergeleitet werden, damit das Netz auf Layer 2 funktionieren kann.
Richtig, die "korrekte" Vorgehensweise ist eigentlich das manuelle
Propagieren der IP oder (besser) des Hostnames. Ich habe das
Broadcast-Thema getestet, weil es cool gewesen wäre, den Server auch
ohne bekannte IP-Daten "sichtbar" zu haben.
Jap, bei den Treffen war ich vor einiger Zeit schonmal (lange vor dem
Umzug in die neuen Räume - die kenne ich noch nicht), allerdings fehlt
mir momentan die Zeit, noch einen Termin in meinen Kalender zu packen
:-/ Würde mich natürlich freuen wenn das trotzdem klappen würde.
Gruß
Daniel
On 15.03.2017 14:22, Marco Holz wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hallo Daniel,
schön, dass Du die verschiedenen Dienste ausprobierst!
Ich weiß leider nicht, ob Dir schon über einen anderen Kanal geantwortet
wurde, daher hier noch einmal die Kurzfassung:
Wie Du schon richtig vermutet hast, ist das Verhalten von uns so
gewollt, um unnötigen Datenverkehr zu vermeiden. Viele normale
Anwendungen nutzen Broadcasts genau wie der Minecraft-Server, um ihre
Existenz im lokalen Netz au announcen.
Bei Minecraft kann man, wenn ich richtig informiert bin, Server auch
direkt via IP-Adresse oder Domain adressieren. Diese Lösung würde ich
hier vorziehen. Wenn Du magst, bist Du herzlich zu einem unserer
Freifunk-Treffen eingeladen. Gerne können wir dort noch einmal über
deine Ideen sprechen und Dir - sofern sich dafür eine Mehrheit findet -
auch eine entsprechende Domain (ich denke da an etwas wie z.B.
minecraft.ffda.io) zur Verfügung stellen.
Viele Grüße
Marco
On 13.03.2017 19:51, Daniel wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hallo Liste,
ich teste gerade verschiedene Dienste innerhalb des Freifunk-Netzes, um
zu sehen wie tauglich sie für die Nutzung sind. Welche dann tatsächlich
angeboten werden werde ich dann noch sehen...
Wie auch immer, diese Woche ist Minecraft an der Reihe. Momentan
betreibe ich einen Server. Dieser soll idealerweise auch innerhalb des
FF-Netzes über die Multiplayer-Funktion sichtbar sein. Der Entwickler
hat dies nun so gelöst, dass der Server einen Broadcast verschickt und
so den Dienst auf seiner IP bekannt macht. Ich habe ein kleines
Python-Script gebastelt, das diesen Broadcast in Form eines kleinen
UDP-Pakets alle 30 Sekunden sendet.
Dieser Broadcast scheint aber am Client (befindet sich an einem anderen
Node als der Server) nicht anzukommen bzw. am Node nicht weitergeleitet
zu werden. Auch in Wireshark ist er nicht sichbar. Ein anderes Gerät,
das sich am selben Node wie auch der Server befindet, sieht den
Broadcast allerdings.
Nun meine Frage: Ist das by-design so oder habe ich irgendwo einen
Fehler gemacht? Es wäre durchaus nachvollziehbar wenn Broadcasts nicht
durch das ganze Netz gehen würden, wobei das bei den ARP-Requests ja
auch funktioniert. Kann mir das jemand erklären?
Danke und Gruß
Daniel
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>