Hallo zusammen,
ich richte wieder einmal mit vielen Fragen an euch alle...
Einige Monate sind nun ins Land gegangen und in der Tat wurde auch etwas zustande gebracht, was man sich ursprünglich einmal zum Ziel gesetzt hatte: Freifunk-Support in IPFire. Viele von euch haben sich positiv dazu geäußert und fanden es begrüßenswert, dass dies zustande kommt, da die aktuellen Installationen einige Unzulänglichkeiten aufweisen.
Es gab bisher zwei ISO-Images mit dem aktuellen Entwicklungsstand. Feedback dazu: Quasi null. Auf Emails auf dieser Liste und auf persönliche Emails oder SMS wird nicht mehr geantwortet. Jetzt fragen wir uns natürlich, ob wir uns mit diesem Projekt auf dem richtigen Weg befinden, oder ob wir unsere Zeit verschwenden.
Hier gibt es (noch einmal) den letzten Entwicklungsstand. Das ist voll funktionsfähig, aber muss getestet werden und kann sicherlich noch einige Verbesserungen vertragen. Die Installationsanweisungen sind die gleichen wie zuvor.
http://people.ipfire.org/~ms/branches/batman/ipfire-2.17.i586-full-core88.is...
Ich erwarte von euch nun dringlichst Stellung zu beziehen: Ist dieses Projekt noch relevant für euch? Gibt es möglicherweise irgendwelche andere und bessere Optionen? Falls ja ist das kein Problem, aber sicherlich eine Sache, die man einmal kommunizieren kann.
Beste Grüße, -Michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Moin, für mich ist das absolut relevant, sonst hätte ich die Liste nicht abboniert. Ich muss mal sehen dass ich ein Testsystem finde, ich möchte das nicht unbedingt direkt auf mein Produktivsystem packen.
Grüße JJX
Am 09.03.2015 um 23:53 schrieb Michael Tremer:
Hallo zusammen,
ich richte wieder einmal mit vielen Fragen an euch alle...
Einige Monate sind nun ins Land gegangen und in der Tat wurde auch etwas zustande gebracht, was man sich ursprünglich einmal zum Ziel gesetzt hatte: Freifunk-Support in IPFire. Viele von euch haben sich positiv dazu geäußert und fanden es begrüßenswert, dass dies zustande kommt, da die aktuellen Installationen einige Unzulänglichkeiten aufweisen.
Es gab bisher zwei ISO-Images mit dem aktuellen Entwicklungsstand. Feedback dazu: Quasi null. Auf Emails auf dieser Liste und auf persönliche Emails oder SMS wird nicht mehr geantwortet. Jetzt fragen wir uns natürlich, ob wir uns mit diesem Projekt auf dem richtigen Weg befinden, oder ob wir unsere Zeit verschwenden.
Hier gibt es (noch einmal) den letzten Entwicklungsstand. Das ist voll funktionsfähig, aber muss getestet werden und kann sicherlich noch einige Verbesserungen vertragen. Die Installationsanweisungen sind die gleichen wie zuvor.
http://people.ipfire.org/~ms/branches/batman/ipfire-2.17.i586-full-core88.is...
Ich erwarte von euch nun dringlichst Stellung zu beziehen: Ist dieses Projekt noch relevant für euch? Gibt es möglicherweise irgendwelche andere und bessere Optionen? Falls ja ist das kein Problem, aber sicherlich eine Sache, die man einmal kommunizieren kann.
Beste Grüße, -Michael
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hi,
schön von dir zu hören.
Ein paar mehr Tester brauchen wir aber schon noch. Vielleicht könnt ihr die Werbetrommel in euren lokalen Communities noch einmal rühren...
-Michael
On Tue, 2015-03-10 at 00:05 +0100, JJX wrote:
Moin, für mich ist das absolut relevant, sonst hätte ich die Liste nicht abboniert. Ich muss mal sehen dass ich ein Testsystem finde, ich möchte das nicht unbedingt direkt auf mein Produktivsystem packen.
Grüße JJX
Am 09.03.2015 um 23:53 schrieb Michael Tremer:
Hallo zusammen,
ich richte wieder einmal mit vielen Fragen an euch alle...
Einige Monate sind nun ins Land gegangen und in der Tat wurde auch etwas zustande gebracht, was man sich ursprünglich einmal zum Ziel gesetzt hatte: Freifunk-Support in IPFire. Viele von euch haben sich positiv dazu geäußert und fanden es begrüßenswert, dass dies zustande kommt, da die aktuellen Installationen einige Unzulänglichkeiten aufweisen.
Es gab bisher zwei ISO-Images mit dem aktuellen Entwicklungsstand. Feedback dazu: Quasi null. Auf Emails auf dieser Liste und auf persönliche Emails oder SMS wird nicht mehr geantwortet. Jetzt fragen wir uns natürlich, ob wir uns mit diesem Projekt auf dem richtigen Weg befinden, oder ob wir unsere Zeit verschwenden.
Hier gibt es (noch einmal) den letzten Entwicklungsstand. Das ist voll funktionsfähig, aber muss getestet werden und kann sicherlich noch einige Verbesserungen vertragen. Die Installationsanweisungen sind die gleichen wie zuvor.
http://people.ipfire.org/~ms/branches/batman/ipfire-2.17.i586-full-core88.is...
Ich erwarte von euch nun dringlichst Stellung zu beziehen: Ist dieses Projekt noch relevant für euch? Gibt es möglicherweise irgendwelche andere und bessere Optionen? Falls ja ist das kein Problem, aber sicherlich eine Sache, die man einmal kommunizieren kann.
Beste Grüße, -Michael
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Moin, weit kam ich nicht beim testen, denn im Webinterface kommt auf der Freifunk Seite nur folgendes: No such file or directory at /srv/web/ipfire/cgi-bin/freifunk.cgi line 382.
Grüße JJX
Hi,
ja wie bereits zuvor erwähnt müssen die JSON-Dateien mit den Informationen der Freifunk-Communities nach /var/ipfire/freifunk/networks kopiert werden. Die findet ihr hier: https://github.com/ffrl/FF-IPFire
Git könnt ihr nachinstallieren mit: pakfire install git
Dann das Repo klonen und die Dateien da hin kopieren wo sie hin sollen.
-Michael
On Thu, 2015-03-12 at 04:48 +0100, JJX wrote:
Moin, weit kam ich nicht beim testen, denn im Webinterface kommt auf der Freifunk Seite nur folgendes: No such file or directory at /srv/web/ipfire/cgi-bin/freifunk.cgi line 382.
Grüße JJX
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hallo
Um es Allen einfacher zu machen habe ich mal eine Schritt-für-Schritt-Installationsanleitung geschrieben mit welcher man eine IPFire-Freifunk-Testmaschine installieren kann.
Bitte verteilt diese Anleitung in Euren Gruppen/Foren/Mailinglisten/Newsgroups oder was auch immer da wir Tester brauchen!
Gruß Daniel
Voraussetzung ist ein i686-PC-System mit min 1GB RAM, 2GB HDD, drei Netzwerkkarten. Sowie Linux-Grundkenntnisse.
*Schritt 1: ISO laden*
http://people.ipfire.org/~ms/branches/batman/ipfire-2.17.i586-full-core88.is... http://people.ipfire.org/%7Ems/branches/batman/ipfire-2.17.i586-full-core88.iso
Dieses bitte auf eine CD brennen.
*Schritt 2: IPFire installieren*
Also von der CD booten und dem Dialog folgen.
Bei Unklarheiten einfach mal hier rein schauen.
http://wiki.ipfire.org/en/installation/start
*Schritt 3: Das Batmanmodul austauschen.*
Bei IPFire ist zunächst das Batman-adv 2014.1.0 aktiv. Alle Communities die noch 2013.4.0 benutzen, müssen dieses erst in Betrieb nehmen.
Dazu bitte diese drei (Zeilenumbruch beachten!) Kommandos nacheinander auf der Konsole absetzen:
mv /lib/modules/3.14.33-ipfire/kernel/net/batman-adv/batman-adv.ko /lib/modules/3.14.33-ipfire/kernel/net/batman-adv/batman-adv-2014.1.0.ko.off
mv /lib/modules/3.14.33-ipfire/kernel/net/batman-adv/batman-adv-2013.4.0.ko.off /lib/modules/3.14.33-ipfire/kernel/net/batman-adv/batman-adv.ko
depmod -a
*Schritt 4: json-Files laden*
Die json-Files beinhalten die Informationen über die verschiedenen Communities und müssen zunächst geladen werden und in einen bestimmten Ordner kopiert werden.
pakfire install git
cd /var/
mkdir /var /ipfire/freifunk/networks
cp /var/freifunk-ipfire/sites/* /var/ipfire/freifunk/networks
*Schritt 5: Communitiy auswählen und Freifunk aktivieren*
Am Webif (https://ip-adresse:444 https://ip-adresse:444/) anmelden.
Unter der Rubrik Netzwerk den Punkt Freifunk auswählen.
Die gewünschte Community auswählen, den Haken bei „Freifunk aktivieren“ setzen und auf speichern klicken. Bei Communities wo ein Host noch manuell registriert werden muss bitte auf „Register host“ klicken und den Anweisungen folgen.
*Schritt 6: Ein Netzwerkinterface mit dem Freifunk-Netzwerk verbinden*
Auf der Konsole editieren wir die Datei //var/ipfire/ethernet/settings/ und fügen folgende Zeilen am Ende hinzu:
FREIFUNK1:DEV:mesh0
FREIFUNK1_MACADDR=MAC-Adresse Netzwerkadapters
*Schritt 7: Firewall-Regeln erstellen*
Auf der Konsole editieren wir die Datei //etc/sysconfig/rc.local/ und fügen folgende Zeilen am Ende hinzu:
iptables -A CUSTOMFORWARD -i bat0 -j ACCEPT
iptables -A CUSTOMFORWARD -o bat0 -j ACCEPT
iptables -A CUSTOMFORWARD -i mesh0 -j ACCEPT
iptables -A CUSTOMFORWARD -o mesh0 -j ACCEPT
iptables -A CUSTOMFORWARD -i batvpn0 -j ACCEPT
iptables -A CUSTOMFORWARD -o batvpn0 -j ACCEPT
*_Bei Schritt 6 und 7 bitte unbedingt die Groß-/Kleinschreibung beachten_!*
*Schritt 8: reboot*
Fertig, nun fällt auf dem konfigurierten Netzwerkinterface Freifunk raus. An Diesen kann nun Entweder ein Client direkt angeschlossen werden oder mehrere mithilfe eines handelsüblichen Netzwerk-Switch. Auch ein handelsüblicher WLAN-AP kann angeschlossen werden. Dieser muss dann die SSID der gewählten Community bekommen und das WLAN unverschlüsselt zur Verfügung stellen.
Es muss und sollte kein Freifunk-Router angeschlossen werden, da Dieser dann versucht einen Tunnel durch den schon vorhandenen Tunnel aufzubauen.
Hi
Seit einiger Zeit betreibe ich Zuhause nun schon einen Freifunk-Router (TP-LINK WA901) an meinem VDSL50 Anschluß. Performance-einbußen oder gar Bandbreitenengpässe gab es dort nie. Die 50MBit down und 10MBit up haben immer locker ausgereicht.
Kürzlich nahm ich zusätzlich noch einen zweiten in Betrieb. Diesmal an einem DSL6000 (6000 KBit down / 512 KBit up) Anschlluß in Betrieb. Da es sich in diesem Fall nicht um einen TP-Link handelte sondern um eine IPFire-ff-testinstallation beobachtete ich das System genauer.
Zu meiner Verwunderung stellt ich fest das die permanent benötigte Bandbreite (ohne aktive Clients) doch deutlich über dem liegt was ich ursprünglich annahm. Ich habe unterschiedliche Communities getestet.
Bei Freifunk Münster liegt die permanent benötigte Bandbreite bei: 10-20 KByte/s (80-160 KBit)Up und down
Bei Freifunk Ruhrgebiet liegt die permanent benötigte Bandbreite bei: 40-70 KByte/s (320-520 KBit) Up und down
Mit Freifunk Ruhrgebiet ist ein DSL6000 Anschluß schon deutlich ausgelastet, an größere Uploads, wie zb ein Bild per Mail verschicken, sollte man besser nicht denken. Natürlich ist im Downstream noch reichlich Luft aber was nützt das wenn der Upload voll ist?
Einen DSL3000 oder gar DSL2000 Anschluß würde ich mit der Inbetriebnahme eines Freifunk-Router praktisch Ausschalten.
Wie gesagt das sind Messwerte ohne einen einzigen aktiven Client dahinter!
Ist das normal? Kann das mal jemand mal gegenchecken, bitte! Gibt es Möglichkeiten die benötigte Bandbreite zu reduzieren?
Zur Veranschaulichung habe ich mal eine RRD-Graphik angehängt. Erläuterung: Bis 11 Uhr FF-Münster. Ab 11 Uhr FF-Ruhrgebiet
Gruß Daniel
Moin,
Ist das normal? Kann das mal jemand mal gegenchecken, bitte! Gibt es Möglichkeiten die benötigte Bandbreite zu reduzieren?
Hallo Daniel, das ist normal. Der Grund dafür ist das Freifunk als Grundidee ein Mesh-Netz hat. Gluon basierte Firmwares nutzen dafür das BATMAN Protokoll (Infos: [1][2]). BATMAN sendet dabei periodisch einen Broadcast Paket an alle Knoten in Reichweite. Diese verteilen die Broadcasts auch noch weiter. Da sich die Knoten über den VPN Tunnel zu den Gateways alle gegenseitig sehen können, obwohl sie nicht alle in direkter Nachbarschaft stehen, erhält jeder Knoten alle Broadcast Pakete. Dadurch steigt die Anzahl der Broadcasts mit der Anzahl der Knoten nicht linear(!). Die Freifunker bezeichnen das als "Grundrauschen" und es hängt wie gesagt von der Größe der Community ab, Münster hat deswegen ein deutlich kleineres Grundrauschen als das Ruhrgebiet oder das Rheinland. Innerhalb der Freifunk Communities wird versucht die Problemstellung des Grundrauschens zu lösen oder zu reduzieren. Zum Beispiel könnte man größere Communitys in kleinere Aufsplitten. Eine Grundlegende Lösung für das Problem gibt es aber noch nicht.
Gruß, Jens Sandmann Freifunk Münster
[1] http://wiki.freifunk.net/B.A.T.M.A.N. [2] http://de.software.wikia.com/wiki/B.A.T.M.A.N.
Hallo Jens
Danke für die schnelle Antwort.
Dieser Fakt war mir schon bewusst. Trotzdem danke das Du das nochmal so ausführlich hier beschrieben hast. Eine nähere Betrachtung der beiden Systeme brachte jedoch zu Tage, dass das "Grundrauschen" bei dem TP-Link System Zuhause wesentlich geringer ist als bei dem IPFire-FF-Testsystem.
Nun stellt sich die Frage wo kommt der Unterschied her? Scheinbar ist etwas wesendliches Anders.
Zum Vergleich: Mein Freifunkrouter (Freifunk Ruhrgebiet) Zuhause macht im Schnitt 16KB/s (128 kbit/s) Upload und 50KB/s (400 kbit/s) Download. Das IPFire-FF-Testsystem (Freifunk Ruhrgebiet) macht im Schnitt 40-70 KByte/s (320-520 KBit) Up und down.
Dabei fällt mir zum Einen sofort auf, dass Zuhause der Traffic asynchron ist und auf dem Testsystem nicht. Und zum Anderen, dass der Traffic Zuhause auch geringer ist obwohl die gleiche Community konfiguriert ist.
Hat dazu jemand Ideen?
Gruß Daniel
Am 23.03.2015 um 13:29 schrieb Jens Sandmann:
Moin,
Ist das normal? Kann das mal jemand mal gegenchecken, bitte! Gibt es Möglichkeiten die benötigte Bandbreite zu reduzieren?
Hallo Daniel, das ist normal. Der Grund dafür ist das Freifunk als Grundidee ein Mesh-Netz hat. Gluon basierte Firmwares nutzen dafür das BATMAN Protokoll (Infos: [1][2]). BATMAN sendet dabei periodisch einen Broadcast Paket an alle Knoten in Reichweite. Diese verteilen die Broadcasts auch noch weiter. Da sich die Knoten über den VPN Tunnel zu den Gateways alle gegenseitig sehen können, obwohl sie nicht alle in direkter Nachbarschaft stehen, erhält jeder Knoten alle Broadcast Pakete. Dadurch steigt die Anzahl der Broadcasts mit der Anzahl der Knoten nicht linear(!). Die Freifunker bezeichnen das als "Grundrauschen" und es hängt wie gesagt von der Größe der Community ab, Münster hat deswegen ein deutlich kleineres Grundrauschen als das Ruhrgebiet oder das Rheinland. Innerhalb der Freifunk Communities wird versucht die Problemstellung des Grundrauschens zu lösen oder zu reduzieren. Zum Beispiel könnte man größere Communitys in kleinere Aufsplitten. Eine Grundlegende Lösung für das Problem gibt es aber noch nicht.
Gruß, Jens Sandmann Freifunk Münster
[1] http://wiki.freifunk.net/B.A.T.M.A.N. [2] http://de.software.wikia.com/wiki/B.A.T.M.A.N.
Hallo zusammen,
das liegt daran, das nicht wie von mir mal vorgeschlagen B.A.T.M.A.N. ADV Legacy sondern das normale ADV installiert wurde.
Dieses hat keinen "Split-Horizon" Patch, wodurch die Leitung symmetrisch, statt asymmetrisch ausgelastet wird.
Da wir in unserer Firmware (Gluon) ausschließlich MIT Split-Horizon arbeiten, sind die Client Router (Kunststoffkisten) von dieser Last nicht betroffen!
Im IPFire wurde nun eine Integration gemacht, wie sie nur auf unseren B.A.T.M.A.N. Gateway Servern in Verwendung ist, die jedoch mittels symmetrischer Gigabit-Verbindung ans Internet angebunden sind.
Für den Client ist der Rebroadcast, der dazu führt, im Übrigen auch vollkommen unnötig und verstopft nur die Leitung, ohne positive Errungenschaften mit sich zu bringen.
FYI, das Legacy findet sich dort: https://github.com/freifunk-gluon/batman-adv-legacy
Beste Grüße
Chris
Am 23. März 2015 um 14:37 schrieb Daniel Weismüller < daniel.weismueller@ipfire.org>:
Hallo Jens
Danke für die schnelle Antwort.
Dieser Fakt war mir schon bewusst. Trotzdem danke das Du das nochmal so ausführlich hier beschrieben hast. Eine nähere Betrachtung der beiden Systeme brachte jedoch zu Tage, dass das "Grundrauschen" bei dem TP-Link System Zuhause wesentlich geringer ist als bei dem IPFire-FF-Testsystem.
Nun stellt sich die Frage wo kommt der Unterschied her? Scheinbar ist etwas wesendliches Anders.
Zum Vergleich: Mein Freifunkrouter (Freifunk Ruhrgebiet) Zuhause macht im Schnitt 16KB/s (128 kbit/s) Upload und 50KB/s (400 kbit/s) Download. Das IPFire-FF-Testsystem (Freifunk Ruhrgebiet) macht im Schnitt 40-70 KByte/s (320-520 KBit) Up und down.
Dabei fällt mir zum Einen sofort auf, dass Zuhause der Traffic asynchron ist und auf dem Testsystem nicht. Und zum Anderen, dass der Traffic Zuhause auch geringer ist obwohl die gleiche Community konfiguriert ist.
Hat dazu jemand Ideen?
Gruß Daniel
Am 23.03.2015 um 13:29 schrieb Jens Sandmann:
Moin,
Ist das normal? Kann das mal jemand mal gegenchecken, bitte!
Gibt es Möglichkeiten die benötigte Bandbreite zu reduzieren?
Hallo Daniel, das ist normal. Der Grund dafür ist das Freifunk als Grundidee ein Mesh-Netz hat. Gluon basierte Firmwares nutzen dafür das BATMAN Protokoll (Infos: [1][2]). BATMAN sendet dabei periodisch einen Broadcast Paket an alle Knoten in Reichweite. Diese verteilen die Broadcasts auch noch weiter. Da sich die Knoten über den VPN Tunnel zu den Gateways alle gegenseitig sehen können, obwohl sie nicht alle in direkter Nachbarschaft stehen, erhält jeder Knoten alle Broadcast Pakete. Dadurch steigt die Anzahl der Broadcasts mit der Anzahl der Knoten nicht linear(!). Die Freifunker bezeichnen das als "Grundrauschen" und es hängt wie gesagt von der Größe der Community ab, Münster hat deswegen ein deutlich kleineres Grundrauschen als das Ruhrgebiet oder das Rheinland. Innerhalb der Freifunk Communities wird versucht die Problemstellung des Grundrauschens zu lösen oder zu reduzieren. Zum Beispiel könnte man größere Communitys in kleinere Aufsplitten. Eine Grundlegende Lösung für das Problem gibt es aber noch nicht.
Gruß, Jens Sandmann Freifunk Münster
[1] http://wiki.freifunk.net/B.A.T.M.A.N. [2] http://de.software.wikia.com/wiki/B.A.T.M.A.N.
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hallo Chris
Wir haben damals schon ausführlich über dieses Thema gesprochen. Nach wie vor stellt sich die Frage warum Freifunk auf batman-adv 2013.4 gepatcht bleibt und nicht auf 2014 wechselt aber diese Diskussion möchte ich nicht wieder aufleben lassen.
Als erste Idee bietet sich an das man das batman-adv-lagacy kernel modul für IPFire baut und das verwendete batman-adv 2013.4 dagegen austauscht.
Nun stolpere ich allerdings schon bei der offiziellen Changelog. https://github.com/freifunk-gluon/batman-adv-legacy/blob/master/CHANGELOG
Laut Dieser sind nur Kernels zwischen 2.16.29 - 3.12 unterstützt.
IPFire ist aktuell bei Kernel 3.14 und Keiner kann sagen wie lange noch. Die Kernelentwicklung geht stetig weiter und unter Anderem deckt IPFire ein wesentliche breiteres Spektrum an Hardware ab und muss Dieses auch abdecken.
Gibt es auf Freifunkseite schon Erfahrungen mit neueren Kernelversionen?
Gruß Daniel
Am 23.03.2015 um 14:56 schrieb Chris Bischoff:
Hallo zusammen,
das liegt daran, das nicht wie von mir mal vorgeschlagen B.A.T.M.A.N. ADV Legacy sondern das normale ADV installiert wurde.
Dieses hat keinen "Split-Horizon" Patch, wodurch die Leitung symmetrisch, statt asymmetrisch ausgelastet wird.
Da wir in unserer Firmware (Gluon) ausschließlich MIT Split-Horizon arbeiten, sind die Client Router (Kunststoffkisten) von dieser Last nicht betroffen!
Im IPFire wurde nun eine Integration gemacht, wie sie nur auf unseren B.A.T.M.A.N. Gateway Servern in Verwendung ist, die jedoch mittels symmetrischer Gigabit-Verbindung ans Internet angebunden sind.
Für den Client ist der Rebroadcast, der dazu führt, im Übrigen auch vollkommen unnötig und verstopft nur die Leitung, ohne positive Errungenschaften mit sich zu bringen.
FYI, das Legacy findet sich dort: https://github.com/freifunk-gluon/batman-adv-legacy
Beste Grüße
Chris
Am 23. März 2015 um 14:37 schrieb Daniel Weismüller <daniel.weismueller@ipfire.org mailto:daniel.weismueller@ipfire.org>:
Hallo Jens Danke für die schnelle Antwort. Dieser Fakt war mir schon bewusst. Trotzdem danke das Du das nochmal so ausführlich hier beschrieben hast. Eine nähere Betrachtung der beiden Systeme brachte jedoch zu Tage, dass das "Grundrauschen" bei dem TP-Link System Zuhause wesentlich geringer ist als bei dem IPFire-FF-Testsystem. Nun stellt sich die Frage wo kommt der Unterschied her? Scheinbar ist etwas wesendliches Anders. Zum Vergleich: Mein Freifunkrouter (Freifunk Ruhrgebiet) Zuhause macht im Schnitt 16KB/s (128 kbit/s) Upload und 50KB/s (400 kbit/s) Download. Das IPFire-FF-Testsystem (Freifunk Ruhrgebiet) macht im Schnitt 40-70 KByte/s (320-520 KBit) Up und down. Dabei fällt mir zum Einen sofort auf, dass Zuhause der Traffic asynchron ist und auf dem Testsystem nicht. Und zum Anderen, dass der Traffic Zuhause auch geringer ist obwohl die gleiche Community konfiguriert ist. Hat dazu jemand Ideen? Gruß Daniel Am 23.03.2015 um 13:29 schrieb Jens Sandmann: Moin, Ist das normal? Kann das mal jemand mal gegenchecken, bitte! Gibt es Möglichkeiten die benötigte Bandbreite zu reduzieren? Hallo Daniel, das ist normal. Der Grund dafür ist das Freifunk als Grundidee ein Mesh-Netz hat. Gluon basierte Firmwares nutzen dafür das BATMAN Protokoll (Infos: [1][2]). BATMAN sendet dabei periodisch einen Broadcast Paket an alle Knoten in Reichweite. Diese verteilen die Broadcasts auch noch weiter. Da sich die Knoten über den VPN Tunnel zu den Gateways alle gegenseitig sehen können, obwohl sie nicht alle in direkter Nachbarschaft stehen, erhält jeder Knoten alle Broadcast Pakete. Dadurch steigt die Anzahl der Broadcasts mit der Anzahl der Knoten nicht linear(!). Die Freifunker bezeichnen das als "Grundrauschen" und es hängt wie gesagt von der Größe der Community ab, Münster hat deswegen ein deutlich kleineres Grundrauschen als das Ruhrgebiet oder das Rheinland. Innerhalb der Freifunk Communities wird versucht die Problemstellung des Grundrauschens zu lösen oder zu reduzieren. Zum Beispiel könnte man größere Communitys in kleinere Aufsplitten. Eine Grundlegende Lösung für das Problem gibt es aber noch nicht. Gruß, Jens Sandmann Freifunk Münster [1] http://wiki.freifunk.net/B.A.T.M.A.N. [2] http://de.software.wikia.com/wiki/B.A.T.M.A.N. _______________________________________________ SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org <mailto:SIG-Freifunk-de@lists.ipfire.org> http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hi Daniel,
das ist das Changelog vom batman, nicht vom Legacy, betrifft entsprechend alle Versionen, auch die derzeit im IPFire eingesetzte Version!
Die neueren Versionen Compat 15, sind noch nicht für ausreichend stabil befunden worden, weshalb derzeit noch nicht allgemein gewechselt wird.
Wenn Du nach meiner persönlichen Meinung fragst; ich selber habe in allen Servern Auto-Restarts für Kernel Panic und oops drin, da batman in undefinierten Kombinationen zwischendrin mal abstürzt.
Grüße
Chris
Am 23. März 2015 um 15:40 schrieb Daniel Weismüller < daniel.weismueller@ipfire.org>:
Hallo Chris
Wir haben damals schon ausführlich über dieses Thema gesprochen. Nach wie vor stellt sich die Frage warum Freifunk auf batman-adv 2013.4 gepatcht bleibt und nicht auf 2014 wechselt aber diese Diskussion möchte ich nicht wieder aufleben lassen.
Als erste Idee bietet sich an das man das batman-adv-lagacy kernel modul für IPFire baut und das verwendete batman-adv 2013.4 dagegen austauscht.
Nun stolpere ich allerdings schon bei der offiziellen Changelog. https://github.com/freifunk-gluon/batman-adv-legacy/blob/master/CHANGELOG
Laut Dieser sind nur Kernels zwischen 2.16.29 - 3.12 unterstützt.
IPFire ist aktuell bei Kernel 3.14 und Keiner kann sagen wie lange noch. Die Kernelentwicklung geht stetig weiter und unter Anderem deckt IPFire ein wesentliche breiteres Spektrum an Hardware ab und muss Dieses auch abdecken.
Gibt es auf Freifunkseite schon Erfahrungen mit neueren Kernelversionen?
Gruß Daniel
Am 23.03.2015 um 14:56 schrieb Chris Bischoff:
Hallo zusammen,
das liegt daran, das nicht wie von mir mal vorgeschlagen B.A.T.M.A.N. ADV Legacy sondern das normale ADV installiert wurde.
Dieses hat keinen "Split-Horizon" Patch, wodurch die Leitung symmetrisch, statt asymmetrisch ausgelastet wird.
Da wir in unserer Firmware (Gluon) ausschließlich MIT Split-Horizon arbeiten, sind die Client Router (Kunststoffkisten) von dieser Last nicht betroffen!
Im IPFire wurde nun eine Integration gemacht, wie sie nur auf unseren B.A.T.M.A.N. Gateway Servern in Verwendung ist, die jedoch mittels symmetrischer Gigabit-Verbindung ans Internet angebunden sind.
Für den Client ist der Rebroadcast, der dazu führt, im Übrigen auch vollkommen unnötig und verstopft nur die Leitung, ohne positive Errungenschaften mit sich zu bringen.
FYI, das Legacy findet sich dort: https://github.com/freifunk-gluon/batman-adv-legacy
Beste Grüße
Chris
Am 23. März 2015 um 14:37 schrieb Daniel Weismüller < daniel.weismueller@ipfire.org>:
Hallo Jens
Danke für die schnelle Antwort.
Dieser Fakt war mir schon bewusst. Trotzdem danke das Du das nochmal so ausführlich hier beschrieben hast. Eine nähere Betrachtung der beiden Systeme brachte jedoch zu Tage, dass das "Grundrauschen" bei dem TP-Link System Zuhause wesentlich geringer ist als bei dem IPFire-FF-Testsystem.
Nun stellt sich die Frage wo kommt der Unterschied her? Scheinbar ist etwas wesendliches Anders.
Zum Vergleich: Mein Freifunkrouter (Freifunk Ruhrgebiet) Zuhause macht im Schnitt 16KB/s (128 kbit/s) Upload und 50KB/s (400 kbit/s) Download. Das IPFire-FF-Testsystem (Freifunk Ruhrgebiet) macht im Schnitt 40-70 KByte/s (320-520 KBit) Up und down.
Dabei fällt mir zum Einen sofort auf, dass Zuhause der Traffic asynchron ist und auf dem Testsystem nicht. Und zum Anderen, dass der Traffic Zuhause auch geringer ist obwohl die gleiche Community konfiguriert ist.
Hat dazu jemand Ideen?
Gruß Daniel
Am 23.03.2015 um 13:29 schrieb Jens Sandmann:
Moin,
Ist das normal? Kann das mal jemand mal gegenchecken, bitte!
Gibt es Möglichkeiten die benötigte Bandbreite zu reduzieren?
Hallo Daniel, das ist normal. Der Grund dafür ist das Freifunk als Grundidee ein Mesh-Netz hat. Gluon basierte Firmwares nutzen dafür das BATMAN Protokoll (Infos: [1][2]). BATMAN sendet dabei periodisch einen Broadcast Paket an alle Knoten in Reichweite. Diese verteilen die Broadcasts auch noch weiter. Da sich die Knoten über den VPN Tunnel zu den Gateways alle gegenseitig sehen können, obwohl sie nicht alle in direkter Nachbarschaft stehen, erhält jeder Knoten alle Broadcast Pakete. Dadurch steigt die Anzahl der Broadcasts mit der Anzahl der Knoten nicht linear(!). Die Freifunker bezeichnen das als "Grundrauschen" und es hängt wie gesagt von der Größe der Community ab, Münster hat deswegen ein deutlich kleineres Grundrauschen als das Ruhrgebiet oder das Rheinland. Innerhalb der Freifunk Communities wird versucht die Problemstellung des Grundrauschens zu lösen oder zu reduzieren. Zum Beispiel könnte man größere Communitys in kleinere Aufsplitten. Eine Grundlegende Lösung für das Problem gibt es aber noch nicht.
Gruß, Jens Sandmann Freifunk Münster
[1] http://wiki.freifunk.net/B.A.T.M.A.N. [2] http://de.software.wikia.com/wiki/B.A.T.M.A.N.
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hi,
kurz mal eingestreut: Philip sagte uns, dass es Pläne gibt, die eine Einführung von batman-adv 2014 in der Zeit von Januar bis März zu vollziehen. Das war im Dezember. Es sollte bereits einige Gateways gegeben haben, die mit batman-adv 2014 liefen und ein Parallelnetz sollte entstehen. Der "Split-Horizon"-Patch, der von den Batman-Entwicklern (auch aus guten Gründen) abgelehnt wurde, sollte damit dann nicht mehr nötig sein.
Jetzt ist ja März. Wie ist denn der Stand von dem Projekt? Die ganze Diskussion um batman-adv 2013 können wir uns demnach ja ohnehin knicken.
-Michael
On Mon, 2015-03-23 at 15:48 +0100, Chris Bischoff wrote:
Hi Daniel,
das ist das Changelog vom batman, nicht vom Legacy, betrifft entsprechend alle Versionen, auch die derzeit im IPFire eingesetzte Version!
Die neueren Versionen Compat 15, sind noch nicht für ausreichend stabil befunden worden, weshalb derzeit noch nicht allgemein gewechselt wird.
Wenn Du nach meiner persönlichen Meinung fragst; ich selber habe in allen Servern Auto-Restarts für Kernel Panic und oops drin, da batman in undefinierten Kombinationen zwischendrin mal abstürzt.
Grüße
Chris
Am 23. März 2015 um 15:40 schrieb Daniel Weismüller daniel.weismueller@ipfire.org: Hallo Chris
Wir haben damals schon ausführlich über dieses Thema gesprochen. Nach wie vor stellt sich die Frage warum Freifunk auf batman-adv 2013.4 gepatcht bleibt und nicht auf 2014 wechselt aber diese Diskussion möchte ich nicht wieder aufleben lassen. Als erste Idee bietet sich an das man das batman-adv-lagacy kernel modul für IPFire baut und das verwendete batman-adv 2013.4 dagegen austauscht. Nun stolpere ich allerdings schon bei der offiziellen Changelog. https://github.com/freifunk-gluon/batman-adv-legacy/blob/master/CHANGELOG Laut Dieser sind nur Kernels zwischen 2.16.29 - 3.12 unterstützt. IPFire ist aktuell bei Kernel 3.14 und Keiner kann sagen wie lange noch. Die Kernelentwicklung geht stetig weiter und unter Anderem deckt IPFire ein wesentliche breiteres Spektrum an Hardware ab und muss Dieses auch abdecken. Gibt es auf Freifunkseite schon Erfahrungen mit neueren Kernelversionen? Gruß Daniel Am 23.03.2015 um 14:56 schrieb Chris Bischoff: > Hallo zusammen, > > > das liegt daran, das nicht wie von mir mal vorgeschlagen > B.A.T.M.A.N. ADV Legacy sondern das normale ADV installiert > wurde. > > > Dieses hat keinen "Split-Horizon" Patch, wodurch die Leitung > symmetrisch, statt asymmetrisch ausgelastet wird. > > > Da wir in unserer Firmware (Gluon) ausschließlich MIT > Split-Horizon arbeiten, sind die Client Router > (Kunststoffkisten) von dieser Last nicht betroffen! > > > Im IPFire wurde nun eine Integration gemacht, wie sie nur > auf unseren B.A.T.M.A.N. Gateway Servern in Verwendung ist, > die jedoch mittels symmetrischer Gigabit-Verbindung ans > Internet angebunden sind. > > > Für den Client ist der Rebroadcast, der dazu führt, im > Übrigen auch vollkommen unnötig und verstopft nur die > Leitung, ohne positive Errungenschaften mit sich zu > bringen. > > > FYI, das Legacy findet sich > dort: https://github.com/freifunk-gluon/batman-adv-legacy > > > Beste Grüße > > > Chris > > > > > > > > Am 23. März 2015 um 14:37 schrieb Daniel Weismüller > <daniel.weismueller@ipfire.org>: > Hallo Jens > > Danke für die schnelle Antwort. > > Dieser Fakt war mir schon bewusst. Trotzdem danke > das Du das nochmal so ausführlich hier beschrieben > hast. > Eine nähere Betrachtung der beiden Systeme brachte > jedoch zu Tage, dass das "Grundrauschen" bei dem > TP-Link System Zuhause wesentlich geringer ist als > bei dem IPFire-FF-Testsystem. > > Nun stellt sich die Frage wo kommt der Unterschied > her? Scheinbar ist etwas wesendliches Anders. > > Zum Vergleich: > Mein Freifunkrouter (Freifunk Ruhrgebiet) Zuhause > macht im Schnitt 16KB/s (128 kbit/s) Upload und > 50KB/s (400 kbit/s) Download. > Das IPFire-FF-Testsystem (Freifunk Ruhrgebiet) macht > im Schnitt 40-70 KByte/s (320-520 KBit) Up und down. > > Dabei fällt mir zum Einen sofort auf, dass Zuhause > der Traffic asynchron ist und auf dem Testsystem > nicht. > Und zum Anderen, dass der Traffic Zuhause auch > geringer ist obwohl die gleiche Community > konfiguriert ist. > > Hat dazu jemand Ideen? > > Gruß > Daniel > > > > Am 23.03.2015 um 13:29 schrieb Jens Sandmann: > > Moin, > > Ist das normal? Kann das mal jemand > mal gegenchecken, bitte! > Gibt es Möglichkeiten die benötigte > Bandbreite zu reduzieren? > Hallo Daniel, das ist normal. Der Grund > dafür ist das Freifunk als > Grundidee ein Mesh-Netz hat. Gluon basierte > Firmwares nutzen dafür das > BATMAN Protokoll (Infos: [1][2]). BATMAN > sendet dabei periodisch einen > Broadcast Paket an alle Knoten in > Reichweite. Diese verteilen die > Broadcasts auch noch weiter. Da sich die > Knoten über den VPN Tunnel zu > den Gateways alle gegenseitig sehen können, > obwohl sie nicht alle in > direkter Nachbarschaft stehen, erhält jeder > Knoten alle Broadcast > Pakete. Dadurch steigt die Anzahl der > Broadcasts mit der Anzahl der > Knoten nicht linear(!). Die Freifunker > bezeichnen das als > "Grundrauschen" und es hängt wie gesagt von > der Größe der Community ab, > Münster hat deswegen ein deutlich kleineres > Grundrauschen als das > Ruhrgebiet oder das Rheinland. Innerhalb der > Freifunk Communities wird > versucht die Problemstellung des > Grundrauschens zu lösen oder zu > reduzieren. Zum Beispiel könnte man größere > Communitys in kleinere > Aufsplitten. Eine Grundlegende Lösung für > das Problem gibt es aber noch > nicht. > > Gruß, > Jens Sandmann > Freifunk Münster > > [1] http://wiki.freifunk.net/B.A.T.M.A.N. > [2] > http://de.software.wikia.com/wiki/B.A.T.M.A.N. > > > > _______________________________________________ > SIG-Freifunk-de mailing list > SIG-Freifunk-de@lists.ipfire.org > http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de > >
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hallo Michael,
es wird vorläufig keine neuere batman Version in Dienst gebracht werden.
Frühestens dann, wenn Team Gluon eine jüngere Version als stable freigeben würde, würden wir uns Gedanken über einen Umstieg machen, aber das war und ist nicht absehbar.
Die Gluon Legacy Patches, insbesondere Split Horizon, sind doch nur nicht gemerged worden, weil es keine Änderungen sind die allgemein im batman jeder brauchen würde.
Mir persönlich war und ist das auch egal, ob ihr nun die Legacy Version implementiert oder auch nicht, allerdings ist die batman Implementierung, wie bereits vor geraumer Zeit gesagt, dann nicht zu gebrauchen, da die WAN Leitungen zu stark belastet werden.
Ich hatte nun lediglich noch einmal auf den Grund aufmerksam gemacht, da danach gefragt wurde, bin dann nun aber auch wieder raus, da ich im Gegensatz zur Annahme nicht das geringste Interesse an einer Grundsatzdiskussion habe.
Bis dann dann
Chris
Am 23. März 2015 um 16:54 schrieb Michael Tremer michael.tremer@ipfire.org :
Hi,
kurz mal eingestreut: Philip sagte uns, dass es Pläne gibt, die eine Einführung von batman-adv 2014 in der Zeit von Januar bis März zu vollziehen. Das war im Dezember. Es sollte bereits einige Gateways gegeben haben, die mit batman-adv 2014 liefen und ein Parallelnetz sollte entstehen. Der "Split-Horizon"-Patch, der von den Batman-Entwicklern (auch aus guten Gründen) abgelehnt wurde, sollte damit dann nicht mehr nötig sein.
Jetzt ist ja März. Wie ist denn der Stand von dem Projekt? Die ganze Diskussion um batman-adv 2013 können wir uns demnach ja ohnehin knicken.
-Michael
On Mon, 2015-03-23 at 15:48 +0100, Chris Bischoff wrote:
Hi Daniel,
das ist das Changelog vom batman, nicht vom Legacy, betrifft entsprechend alle Versionen, auch die derzeit im IPFire eingesetzte Version!
Die neueren Versionen Compat 15, sind noch nicht für ausreichend stabil befunden worden, weshalb derzeit noch nicht allgemein gewechselt wird.
Wenn Du nach meiner persönlichen Meinung fragst; ich selber habe in allen Servern Auto-Restarts für Kernel Panic und oops drin, da batman in undefinierten Kombinationen zwischendrin mal abstürzt.
Grüße
Chris
Am 23. März 2015 um 15:40 schrieb Daniel Weismüller daniel.weismueller@ipfire.org: Hallo Chris
Wir haben damals schon ausführlich über dieses Thema gesprochen. Nach wie vor stellt sich die Frage warum Freifunk auf batman-adv 2013.4 gepatcht bleibt und nicht auf 2014 wechselt aber diese Diskussion möchte ich nicht wieder aufleben lassen. Als erste Idee bietet sich an das man das batman-adv-lagacy kernel modul für IPFire baut und das verwendete batman-adv 2013.4 dagegen austauscht. Nun stolpere ich allerdings schon bei der offiziellen Changelog.https://github.com/freifunk-gluon/batman-adv-legacy/blob/master/CHANGELOG
Laut Dieser sind nur Kernels zwischen 2.16.29 - 3.12 unterstützt. IPFire ist aktuell bei Kernel 3.14 und Keiner kann sagen wie lange noch. Die Kernelentwicklung geht stetig weiter und unter Anderem deckt IPFire ein wesentliche breiteres Spektrum an Hardware ab und muss Dieses auch abdecken. Gibt es auf Freifunkseite schon Erfahrungen mit neueren Kernelversionen? Gruß Daniel Am 23.03.2015 um 14:56 schrieb Chris Bischoff: > Hallo zusammen, > > > das liegt daran, das nicht wie von mir mal vorgeschlagen > B.A.T.M.A.N. ADV Legacy sondern das normale ADV installiert > wurde. > > > Dieses hat keinen "Split-Horizon" Patch, wodurch die Leitung > symmetrisch, statt asymmetrisch ausgelastet wird. > > > Da wir in unserer Firmware (Gluon) ausschließlich MIT > Split-Horizon arbeiten, sind die Client Router > (Kunststoffkisten) von dieser Last nicht betroffen! > > > Im IPFire wurde nun eine Integration gemacht, wie sie nur > auf unseren B.A.T.M.A.N. Gateway Servern in Verwendung ist, > die jedoch mittels symmetrischer Gigabit-Verbindung ans > Internet angebunden sind. > > > Für den Client ist der Rebroadcast, der dazu führt, im > Übrigen auch vollkommen unnötig und verstopft nur die > Leitung, ohne positive Errungenschaften mit sich zu > bringen. > > > FYI, das Legacy findet sich > dort: https://github.com/freifunk-gluon/batman-adv-legacy > > > Beste Grüße > > > Chris > > > > > > > > Am 23. März 2015 um 14:37 schrieb Daniel Weismüller > <daniel.weismueller@ipfire.org>: > Hallo Jens > > Danke für die schnelle Antwort. > > Dieser Fakt war mir schon bewusst. Trotzdem danke > das Du das nochmal so ausführlich hier beschrieben > hast. > Eine nähere Betrachtung der beiden Systeme brachte > jedoch zu Tage, dass das "Grundrauschen" bei dem > TP-Link System Zuhause wesentlich geringer ist als > bei dem IPFire-FF-Testsystem. > > Nun stellt sich die Frage wo kommt der Unterschied > her? Scheinbar ist etwas wesendliches Anders. > > Zum Vergleich: > Mein Freifunkrouter (Freifunk Ruhrgebiet) Zuhause > macht im Schnitt 16KB/s (128 kbit/s) Upload und > 50KB/s (400 kbit/s) Download. > Das IPFire-FF-Testsystem (Freifunk Ruhrgebiet) macht > im Schnitt 40-70 KByte/s (320-520 KBit) Up und down. > > Dabei fällt mir zum Einen sofort auf, dass Zuhause > der Traffic asynchron ist und auf dem Testsystem > nicht. > Und zum Anderen, dass der Traffic Zuhause auch > geringer ist obwohl die gleiche Community > konfiguriert ist. > > Hat dazu jemand Ideen? > > Gruß > Daniel > > > > Am 23.03.2015 um 13:29 schrieb Jens Sandmann: > > Moin, > > Ist das normal? Kann das mal jemand > mal gegenchecken, bitte! > Gibt es Möglichkeiten die benötigte > Bandbreite zu reduzieren? > Hallo Daniel, das ist normal. Der Grund > dafür ist das Freifunk als > Grundidee ein Mesh-Netz hat. Gluon basierte > Firmwares nutzen dafür das > BATMAN Protokoll (Infos: [1][2]). BATMAN > sendet dabei periodisch einen > Broadcast Paket an alle Knoten in > Reichweite. Diese verteilen die > Broadcasts auch noch weiter. Da sich die > Knoten über den VPN Tunnel zu > den Gateways alle gegenseitig sehen können, > obwohl sie nicht alle in > direkter Nachbarschaft stehen, erhält jeder > Knoten alle Broadcast > Pakete. Dadurch steigt die Anzahl der > Broadcasts mit der Anzahl der > Knoten nicht linear(!). Die Freifunker > bezeichnen das als > "Grundrauschen" und es hängt wie gesagt von > der Größe der Community ab, > Münster hat deswegen ein deutlich kleineres > Grundrauschen als das > Ruhrgebiet oder das Rheinland. Innerhalb der > Freifunk Communities wird > versucht die Problemstellung des > Grundrauschens zu lösen oder zu > reduzieren. Zum Beispiel könnte man größere > Communitys in kleinere > Aufsplitten. Eine Grundlegende Lösung für > das Problem gibt es aber noch > nicht. > > Gruß, > Jens Sandmann > Freifunk Münster > > [1] http://wiki.freifunk.net/B.A.T.M.A.N. > [2] > http://de.software.wikia.com/wiki/B.A.T.M.A.N. > > > > _______________________________________________ > SIG-Freifunk-de mailing list > SIG-Freifunk-de@lists.ipfire.org >http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
> >
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hallo,
ich muss trotzdem dann aber noch einmal ein bisschen zu zwei Themenbereichen ausholen:
Mir geht es jetzt erst einmal gar nicht darum, welche Community welche Version von BATMAN einsetzt. Was mich aber schon sehr enttäuscht ist, wie diese "Zusammenarbeit" hier funktioniert. Nämlich in meinen Augen gar nicht mehr. Chris sagt jetzt, dass es diese Pläne zur Migration überhaupt nicht gegeben hat. Philip antwortet seit mehreren Wochen weder hier auf der Liste, noch auf private Emails oder SMS. Wenn das so die Art ist wie ihr in euren Communities miteinander umgeht, dann soll das euch überlassen sein. Ich habe da schon ein größeres Problem mit. So geht man erstens nicht mit Menschen um und zweitens kommen wir hier überhaupt nicht weiter in diesem Projekt. Das stottert irgendwie seit Ende letzten Jahres nur noch vor sich hin und einen Dialog sind wir offenbar nicht im Stande zu führen.
Seit langer Zeit sind technische Fragen offen. Die Personen, die sich dazu einmal bereit erklärt haben bei der eigentlichen Umsetzung des Projekts mitzuwirken ziehen sich "heraus" und die Testbeteiligung ist mager, obwohl auf den Informationskanälen der Communities dafür geworben worden sein soll. Entgegen bekräftigen andere immer wieder, dass doch eigentlich großes Interesse daran besteht das Projekt umzusetzen.
Jetzt gibt es eine zumindest brauchbare Implementierung, die exakt der Roadmap wie im Dezember mit Philip besprochen entspricht. Meiner persönlichen Auffassung nach funktioniert diese auch. Einiges ist noch zu tun, weil die Implementierung noch nicht fertig ist, aber ein Meilenstein ist da. Wie soll es dann nun damit weitergehen?
Ich fände es schön, wenn wir nun endlich mal zu einem Punkt kommen, an dem wir Farbe bekennen. Ich wäre am Ende nicht traurig, wenn wir hier nun zum Schluss kommen, dass das Projekt nicht mehr weiter fortgesetzt werden kann, soll, oder wird. Jedoch ist es doch so keine Grundlage auf der ich gern weiter arbeiten möchte. Das soll aber nicht heißen, dass ich mich dafür aussprechen möchte die Kooperation einzustellen, sondern ich möchte gern, dass wenn sie weiter statt finden soll, sie auch den Namen Kooperation verdient hat.
Ich würde mich freuen, wenn ihr vielleicht auch einmal eure Seite dazu schildern würdet.
Gegen Ende der Woche plane ich einen kurzen Bericht über den Status dieses Projektes auf unserem Development-Blog zu veröffentlichen. Es wäre schön, wenn dieser nicht nur einseitig wäre.
Beste Grüße, -Michael
On Mon, 2015-03-23 at 18:28 +0100, Chris Bischoff wrote:
Hallo Michael,
es wird vorläufig keine neuere batman Version in Dienst gebracht werden.
Frühestens dann, wenn Team Gluon eine jüngere Version als stable freigeben würde, würden wir uns Gedanken über einen Umstieg machen, aber das war und ist nicht absehbar.
Die Gluon Legacy Patches, insbesondere Split Horizon, sind doch nur nicht gemerged worden, weil es keine Änderungen sind die allgemein im batman jeder brauchen würde.
Mir persönlich war und ist das auch egal, ob ihr nun die Legacy Version implementiert oder auch nicht, allerdings ist die batman Implementierung, wie bereits vor geraumer Zeit gesagt, dann nicht zu gebrauchen, da die WAN Leitungen zu stark belastet werden.
Ich hatte nun lediglich noch einmal auf den Grund aufmerksam gemacht, da danach gefragt wurde, bin dann nun aber auch wieder raus, da ich im Gegensatz zur Annahme nicht das geringste Interesse an einer Grundsatzdiskussion habe.
Bis dann dann
Chris
Am 23. März 2015 um 16:54 schrieb Michael Tremer michael.tremer@ipfire.org: Hi,
kurz mal eingestreut: Philip sagte uns, dass es Pläne gibt, die eine Einführung von batman-adv 2014 in der Zeit von Januar bis März zu vollziehen. Das war im Dezember. Es sollte bereits einige Gateways gegeben haben, die mit batman-adv 2014 liefen und ein Parallelnetz sollte entstehen. Der "Split-Horizon"-Patch, der von den Batman-Entwicklern (auch aus guten Gründen) abgelehnt wurde, sollte damit dann nicht mehr nötig sein. Jetzt ist ja März. Wie ist denn der Stand von dem Projekt? Die ganze Diskussion um batman-adv 2013 können wir uns demnach ja ohnehin knicken. -Michael On Mon, 2015-03-23 at 15:48 +0100, Chris Bischoff wrote: > Hi Daniel, > > > das ist das Changelog vom batman, nicht vom Legacy, betrifft > entsprechend alle Versionen, auch die derzeit im IPFire eingesetzte > Version! > > > Die neueren Versionen Compat 15, sind noch nicht für ausreichend > stabil befunden worden, weshalb derzeit noch nicht allgemein > gewechselt wird. > > > Wenn Du nach meiner persönlichen Meinung fragst; ich selber habe in > allen Servern Auto-Restarts für Kernel Panic und oops drin, da batman > in undefinierten Kombinationen zwischendrin mal abstürzt. > > > > > Grüße > > > Chris > > > > > > > > > > Am 23. März 2015 um 15:40 schrieb Daniel Weismüller > <daniel.weismueller@ipfire.org>: > Hallo Chris > > Wir haben damals schon ausführlich über dieses Thema > gesprochen. > Nach wie vor stellt sich die Frage warum Freifunk auf > batman-adv 2013.4 gepatcht bleibt und nicht auf 2014 wechselt > aber diese Diskussion möchte ich nicht wieder aufleben lassen. > > Als erste Idee bietet sich an das man das batman-adv-lagacy > kernel modul für IPFire baut und das verwendete batman-adv > 2013.4 dagegen austauscht. > > Nun stolpere ich allerdings schon bei der offiziellen > Changelog. > https://github.com/freifunk-gluon/batman-adv-legacy/blob/master/CHANGELOG > > Laut Dieser sind nur Kernels zwischen 2.16.29 - 3.12 > unterstützt. > > IPFire ist aktuell bei Kernel 3.14 und Keiner kann sagen wie > lange noch. Die Kernelentwicklung geht stetig weiter und unter > Anderem deckt IPFire ein wesentliche breiteres Spektrum an > Hardware ab und muss Dieses auch abdecken. > > Gibt es auf Freifunkseite schon Erfahrungen mit neueren > Kernelversionen? > > Gruß > Daniel > > > > Am 23.03.2015 um 14:56 schrieb Chris Bischoff: > > > Hallo zusammen, > > > > > > das liegt daran, das nicht wie von mir mal vorgeschlagen > > B.A.T.M.A.N. ADV Legacy sondern das normale ADV installiert > > wurde. > > > > > > Dieses hat keinen "Split-Horizon" Patch, wodurch die Leitung > > symmetrisch, statt asymmetrisch ausgelastet wird. > > > > > > Da wir in unserer Firmware (Gluon) ausschließlich MIT > > Split-Horizon arbeiten, sind die Client Router > > (Kunststoffkisten) von dieser Last nicht betroffen! > > > > > > Im IPFire wurde nun eine Integration gemacht, wie sie nur > > auf unseren B.A.T.M.A.N. Gateway Servern in Verwendung ist, > > die jedoch mittels symmetrischer Gigabit-Verbindung ans > > Internet angebunden sind. > > > > > > Für den Client ist der Rebroadcast, der dazu führt, im > > Übrigen auch vollkommen unnötig und verstopft nur die > > Leitung, ohne positive Errungenschaften mit sich zu > > bringen. > > > > > > FYI, das Legacy findet sich > > dort: https://github.com/freifunk-gluon/batman-adv-legacy > > > > > > Beste Grüße > > > > > > Chris > > > > > > > > > > > > > > > > Am 23. März 2015 um 14:37 schrieb Daniel Weismüller > > <daniel.weismueller@ipfire.org>: > > Hallo Jens > > > > Danke für die schnelle Antwort. > > > > Dieser Fakt war mir schon bewusst. Trotzdem danke > > das Du das nochmal so ausführlich hier beschrieben > > hast. > > Eine nähere Betrachtung der beiden Systeme brachte > > jedoch zu Tage, dass das "Grundrauschen" bei dem > > TP-Link System Zuhause wesentlich geringer ist als > > bei dem IPFire-FF-Testsystem. > > > > Nun stellt sich die Frage wo kommt der Unterschied > > her? Scheinbar ist etwas wesendliches Anders. > > > > Zum Vergleich: > > Mein Freifunkrouter (Freifunk Ruhrgebiet) Zuhause > > macht im Schnitt 16KB/s (128 kbit/s) Upload und > > 50KB/s (400 kbit/s) Download. > > Das IPFire-FF-Testsystem (Freifunk Ruhrgebiet) macht > > im Schnitt 40-70 KByte/s (320-520 KBit) Up und down. > > > > Dabei fällt mir zum Einen sofort auf, dass Zuhause > > der Traffic asynchron ist und auf dem Testsystem > > nicht. > > Und zum Anderen, dass der Traffic Zuhause auch > > geringer ist obwohl die gleiche Community > > konfiguriert ist. > > > > Hat dazu jemand Ideen? > > > > Gruß > > Daniel > > > > > > > > Am 23.03.2015 um 13:29 schrieb Jens Sandmann: > > > > Moin, > > > > Ist das normal? Kann das mal jemand > > mal gegenchecken, bitte! > > Gibt es Möglichkeiten die benötigte > > Bandbreite zu reduzieren? > > Hallo Daniel, das ist normal. Der Grund > > dafür ist das Freifunk als > > Grundidee ein Mesh-Netz hat. Gluon basierte > > Firmwares nutzen dafür das > > BATMAN Protokoll (Infos: [1][2]). BATMAN > > sendet dabei periodisch einen > > Broadcast Paket an alle Knoten in > > Reichweite. Diese verteilen die > > Broadcasts auch noch weiter. Da sich die > > Knoten über den VPN Tunnel zu > > den Gateways alle gegenseitig sehen können, > > obwohl sie nicht alle in > > direkter Nachbarschaft stehen, erhält jeder > > Knoten alle Broadcast > > Pakete. Dadurch steigt die Anzahl der > > Broadcasts mit der Anzahl der > > Knoten nicht linear(!). Die Freifunker > > bezeichnen das als > > "Grundrauschen" und es hängt wie gesagt von > > der Größe der Community ab, > > Münster hat deswegen ein deutlich kleineres > > Grundrauschen als das > > Ruhrgebiet oder das Rheinland. Innerhalb der > > Freifunk Communities wird > > versucht die Problemstellung des > > Grundrauschens zu lösen oder zu > > reduzieren. Zum Beispiel könnte man größere > > Communitys in kleinere > > Aufsplitten. Eine Grundlegende Lösung für > > das Problem gibt es aber noch > > nicht. > > > > Gruß, > > Jens Sandmann > > Freifunk Münster > > > > [1] http://wiki.freifunk.net/B.A.T.M.A.N. > > [2] > > http://de.software.wikia.com/wiki/B.A.T.M.A.N. > > > > > > > > _______________________________________________ > > SIG-Freifunk-de mailing list > > SIG-Freifunk-de@lists.ipfire.org > > http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de > > > > > > > > > _______________________________________________ > SIG-Freifunk-de mailing list > SIG-Freifunk-de@lists.ipfire.org > http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hi,
ich kann Dir nur nach bestem Wissen und Gewissen hier ein paar Fragen beantworten.
Egal ob nun 2013.4.0, die ominöse 2013.5.0, oder eine echte Compat 15 - wenn Du eine offizielle Version einsetzt die nicht gepatcht ist, dann verstopft das die Leitung.
Für batman compat 14 gibt es dafür das legacy repo, für die compat 15 "nur" Patches im Tree des Gluon, z.B. no_rebroadcast (Split Horizon):
https://github.com/freifunk-gluon/gluon/blob/master/patches/packages/routing...
Irgendwann wird mal migriert werden, dafür gibt es aktuell aber weder eine Planung, noch einen definierten Zeitpunkt, ohne no_rebroadcast verstopft batman dann aber auch in der compat 15 den upload der asymmetrischen Clientanbindung...
Insgesamt ist das Thema und das Wissen aber auch nicht neu, das hatte ich bereits vor Monaten als Problem benannt!
Beste Grüße
Chris
Am 23. März 2015 um 19:52 schrieb Michael Tremer michael.tremer@ipfire.org :
Hallo,
ich muss trotzdem dann aber noch einmal ein bisschen zu zwei Themenbereichen ausholen:
Mir geht es jetzt erst einmal gar nicht darum, welche Community welche Version von BATMAN einsetzt. Was mich aber schon sehr enttäuscht ist, wie diese "Zusammenarbeit" hier funktioniert. Nämlich in meinen Augen gar nicht mehr. Chris sagt jetzt, dass es diese Pläne zur Migration überhaupt nicht gegeben hat. Philip antwortet seit mehreren Wochen weder hier auf der Liste, noch auf private Emails oder SMS. Wenn das so die Art ist wie ihr in euren Communities miteinander umgeht, dann soll das euch überlassen sein. Ich habe da schon ein größeres Problem mit. So geht man erstens nicht mit Menschen um und zweitens kommen wir hier überhaupt nicht weiter in diesem Projekt. Das stottert irgendwie seit Ende letzten Jahres nur noch vor sich hin und einen Dialog sind wir offenbar nicht im Stande zu führen.
Seit langer Zeit sind technische Fragen offen. Die Personen, die sich dazu einmal bereit erklärt haben bei der eigentlichen Umsetzung des Projekts mitzuwirken ziehen sich "heraus" und die Testbeteiligung ist mager, obwohl auf den Informationskanälen der Communities dafür geworben worden sein soll. Entgegen bekräftigen andere immer wieder, dass doch eigentlich großes Interesse daran besteht das Projekt umzusetzen.
Jetzt gibt es eine zumindest brauchbare Implementierung, die exakt der Roadmap wie im Dezember mit Philip besprochen entspricht. Meiner persönlichen Auffassung nach funktioniert diese auch. Einiges ist noch zu tun, weil die Implementierung noch nicht fertig ist, aber ein Meilenstein ist da. Wie soll es dann nun damit weitergehen?
Ich fände es schön, wenn wir nun endlich mal zu einem Punkt kommen, an dem wir Farbe bekennen. Ich wäre am Ende nicht traurig, wenn wir hier nun zum Schluss kommen, dass das Projekt nicht mehr weiter fortgesetzt werden kann, soll, oder wird. Jedoch ist es doch so keine Grundlage auf der ich gern weiter arbeiten möchte. Das soll aber nicht heißen, dass ich mich dafür aussprechen möchte die Kooperation einzustellen, sondern ich möchte gern, dass wenn sie weiter statt finden soll, sie auch den Namen Kooperation verdient hat.
Ich würde mich freuen, wenn ihr vielleicht auch einmal eure Seite dazu schildern würdet.
Gegen Ende der Woche plane ich einen kurzen Bericht über den Status dieses Projektes auf unserem Development-Blog zu veröffentlichen. Es wäre schön, wenn dieser nicht nur einseitig wäre.
Beste Grüße, -Michael
On Mon, 2015-03-23 at 18:28 +0100, Chris Bischoff wrote:
Hallo Michael,
es wird vorläufig keine neuere batman Version in Dienst gebracht werden.
Frühestens dann, wenn Team Gluon eine jüngere Version als stable freigeben würde, würden wir uns Gedanken über einen Umstieg machen, aber das war und ist nicht absehbar.
Die Gluon Legacy Patches, insbesondere Split Horizon, sind doch nur nicht gemerged worden, weil es keine Änderungen sind die allgemein im batman jeder brauchen würde.
Mir persönlich war und ist das auch egal, ob ihr nun die Legacy Version implementiert oder auch nicht, allerdings ist die batman Implementierung, wie bereits vor geraumer Zeit gesagt, dann nicht zu gebrauchen, da die WAN Leitungen zu stark belastet werden.
Ich hatte nun lediglich noch einmal auf den Grund aufmerksam gemacht, da danach gefragt wurde, bin dann nun aber auch wieder raus, da ich im Gegensatz zur Annahme nicht das geringste Interesse an einer Grundsatzdiskussion habe.
Bis dann dann
Chris
Am 23. März 2015 um 16:54 schrieb Michael Tremer michael.tremer@ipfire.org: Hi,
kurz mal eingestreut: Philip sagte uns, dass es Pläne gibt, die eine Einführung von batman-adv 2014 in der Zeit von Januar bis März zu vollziehen. Das war im Dezember. Es sollte bereits einige Gateways gegeben haben, die mit batman-adv 2014 liefen und ein Parallelnetz sollte entstehen. Der "Split-Horizon"-Patch, der von den Batman-Entwicklern (auch aus guten Gründen) abgelehnt wurde, sollte damit dann nicht mehr nötig sein. Jetzt ist ja März. Wie ist denn der Stand von dem Projekt? Die ganze Diskussion um batman-adv 2013 können wir uns demnach ja ohnehin knicken. -Michael On Mon, 2015-03-23 at 15:48 +0100, Chris Bischoff wrote: > Hi Daniel, > > > das ist das Changelog vom batman, nicht vom Legacy, betrifft > entsprechend alle Versionen, auch die derzeit im IPFire eingesetzte > Version! > > > Die neueren Versionen Compat 15, sind noch nicht für ausreichend > stabil befunden worden, weshalb derzeit noch nicht allgemein > gewechselt wird. > > > Wenn Du nach meiner persönlichen Meinung fragst; ich selber habe in > allen Servern Auto-Restarts für Kernel Panic und oops drin, da batman > in undefinierten Kombinationen zwischendrin mal abstürzt. > > > > > Grüße > > > Chris > > > > > > > > > > Am 23. März 2015 um 15:40 schrieb Daniel Weismüller > <daniel.weismueller@ipfire.org>: > Hallo Chris > > Wir haben damals schon ausführlich über dieses Thema > gesprochen. > Nach wie vor stellt sich die Frage warum Freifunk auf > batman-adv 2013.4 gepatcht bleibt und nicht auf 2014 wechselt > aber diese Diskussion möchte ich nicht wieder aufleben lassen. > > Als erste Idee bietet sich an das man das batman-adv-lagacy > kernel modul für IPFire baut und das verwendete batman-adv > 2013.4 dagegen austauscht. > > Nun stolpere ich allerdings schon bei der offiziellen > Changelog. >https://github.com/freifunk-gluon/batman-adv-legacy/blob/master/CHANGELOG
> > Laut Dieser sind nur Kernels zwischen 2.16.29 - 3.12 > unterstützt. > > IPFire ist aktuell bei Kernel 3.14 und Keiner kann sagen wie > lange noch. Die Kernelentwicklung geht stetig weiter und unter > Anderem deckt IPFire ein wesentliche breiteres Spektrum an > Hardware ab und muss Dieses auch abdecken. > > Gibt es auf Freifunkseite schon Erfahrungen mit neueren > Kernelversionen? > > Gruß > Daniel > > > > Am 23.03.2015 um 14:56 schrieb Chris Bischoff: > > > Hallo zusammen, > > > > > > das liegt daran, das nicht wie von mir mal vorgeschlagen > > B.A.T.M.A.N. ADV Legacy sondern das normale ADV installiert > > wurde. > > > > > > Dieses hat keinen "Split-Horizon" Patch, wodurch die Leitung > > symmetrisch, statt asymmetrisch ausgelastet wird. > > > > > > Da wir in unserer Firmware (Gluon) ausschließlich MIT > > Split-Horizon arbeiten, sind die Client Router > > (Kunststoffkisten) von dieser Last nicht betroffen! > > > > > > Im IPFire wurde nun eine Integration gemacht, wie sie nur > > auf unseren B.A.T.M.A.N. Gateway Servern in Verwendung ist, > > die jedoch mittels symmetrischer Gigabit-Verbindung ans > > Internet angebunden sind. > > > > > > Für den Client ist der Rebroadcast, der dazu führt, im > > Übrigen auch vollkommen unnötig und verstopft nur die > > Leitung, ohne positive Errungenschaften mit sich zu > > bringen. > > > > > > FYI, das Legacy findet sich > > dort: https://github.com/freifunk-gluon/batman-adv-legacy > > > > > > Beste Grüße > > > > > > Chris > > > > > > > > > > > > > > > > Am 23. März 2015 um 14:37 schrieb Daniel Weismüller > > <daniel.weismueller@ipfire.org>: > > Hallo Jens > > > > Danke für die schnelle Antwort. > > > > Dieser Fakt war mir schon bewusst. Trotzdem danke > > das Du das nochmal so ausführlich hier beschrieben > > hast. > > Eine nähere Betrachtung der beiden Systeme brachte > > jedoch zu Tage, dass das "Grundrauschen" bei dem > > TP-Link System Zuhause wesentlich geringer ist als > > bei dem IPFire-FF-Testsystem. > > > > Nun stellt sich die Frage wo kommt der Unterschied > > her? Scheinbar ist etwas wesendliches Anders. > > > > Zum Vergleich: > > Mein Freifunkrouter (Freifunk Ruhrgebiet) Zuhause > > macht im Schnitt 16KB/s (128 kbit/s) Upload und > > 50KB/s (400 kbit/s) Download. > > Das IPFire-FF-Testsystem (Freifunk Ruhrgebiet) macht > > im Schnitt 40-70 KByte/s (320-520 KBit) Up und down. > > > > Dabei fällt mir zum Einen sofort auf, dass Zuhause > > der Traffic asynchron ist und auf dem Testsystem > > nicht. > > Und zum Anderen, dass der Traffic Zuhause auch > > geringer ist obwohl die gleiche Community > > konfiguriert ist. > > > > Hat dazu jemand Ideen? > > > > Gruß > > Daniel > > > > > > > > Am 23.03.2015 um 13:29 schrieb Jens Sandmann: > > > > Moin, > > > > Ist das normal? Kann das mal jemand > > mal gegenchecken, bitte! > > Gibt es Möglichkeiten die benötigte > > Bandbreite zu reduzieren? > > Hallo Daniel, das ist normal. Der Grund > > dafür ist das Freifunk als > > Grundidee ein Mesh-Netz hat. Gluon basierte > > Firmwares nutzen dafür das > > BATMAN Protokoll (Infos: [1][2]). BATMAN > > sendet dabei periodisch einen > > Broadcast Paket an alle Knoten in > > Reichweite. Diese verteilen die > > Broadcasts auch noch weiter. Da sich die > > Knoten über den VPN Tunnel zu > > den Gateways alle gegenseitig sehen können, > > obwohl sie nicht alle in > > direkter Nachbarschaft stehen, erhält jeder > > Knoten alle Broadcast > > Pakete. Dadurch steigt die Anzahl der > > Broadcasts mit der Anzahl der > > Knoten nicht linear(!). Die Freifunker > > bezeichnen das als > > "Grundrauschen" und es hängt wie gesagt von > > der Größe der Community ab, > > Münster hat deswegen ein deutlich kleineres > > Grundrauschen als das > > Ruhrgebiet oder das Rheinland. Innerhalb der > > Freifunk Communities wird > > versucht die Problemstellung des > > Grundrauschens zu lösen oder zu > > reduzieren. Zum Beispiel könnte man größere > > Communitys in kleinere > > Aufsplitten. Eine Grundlegende Lösung für > > das Problem gibt es aber noch > > nicht. > > > > Gruß, > > Jens Sandmann > > Freifunk Münster > > > > [1] http://wiki.freifunk.net/B.A.T.M.A.N. > > [2] > > http://de.software.wikia.com/wiki/B.A.T.M.A.N. > > > > > > > > _______________________________________________ > > SIG-Freifunk-de mailing list > > SIG-Freifunk-de@lists.ipfire.org > > http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de > > > > > > > > > _______________________________________________ > SIG-Freifunk-de mailing list > SIG-Freifunk-de@lists.ipfire.org > http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Für mich ist es auch interessant. Ich habe die Mail mal auf die ML unserer Community weiter geleitet. Wir sammeln die Ergebnisse und ich sende sie dann auf die ML.
Gruß jan
Am 09.03.2015 um 23:53 schrieb Michael Tremer:
Hallo zusammen,
ich richte wieder einmal mit vielen Fragen an euch alle...
Einige Monate sind nun ins Land gegangen und in der Tat wurde auch etwas zustande gebracht, was man sich ursprünglich einmal zum Ziel gesetzt hatte: Freifunk-Support in IPFire. Viele von euch haben sich positiv dazu geäußert und fanden es begrüßenswert, dass dies zustande kommt, da die aktuellen Installationen einige Unzulänglichkeiten aufweisen.
Es gab bisher zwei ISO-Images mit dem aktuellen Entwicklungsstand. Feedback dazu: Quasi null. Auf Emails auf dieser Liste und auf persönliche Emails oder SMS wird nicht mehr geantwortet. Jetzt fragen wir uns natürlich, ob wir uns mit diesem Projekt auf dem richtigen Weg befinden, oder ob wir unsere Zeit verschwenden.
Hier gibt es (noch einmal) den letzten Entwicklungsstand. Das ist voll funktionsfähig, aber muss getestet werden und kann sicherlich noch einige Verbesserungen vertragen. Die Installationsanweisungen sind die gleichen wie zuvor.
http://people.ipfire.org/~ms/branches/batman/ipfire-2.17.i586-full-core88.is...
Ich erwarte von euch nun dringlichst Stellung zu beziehen: Ist dieses Projekt noch relevant für euch? Gibt es möglicherweise irgendwelche andere und bessere Optionen? Falls ja ist das kein Problem, aber sicherlich eine Sache, die man einmal kommunizieren kann.
Beste Grüße, -Michael
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hi,
bei mir kommt gar kein Webinterface. netstat -tulpn zeigt auch keinen offenen Port 80 oder 443 an. Offen sind ledglich die Ports für DNS und NTP
Der Prozess httpd läuft allerdings. Muss ich das Webinterface irgendwie erst aktivieren?
Gruß Jan
Hi,
das webif ist immer erreichbar unter https://ip-adresse:444 Gruß Daniel
Am 12.03.2015 um 10:18 schrieb Jan-Marten Brüggemann:
Hi,
bei mir kommt gar kein Webinterface. netstat -tulpn zeigt auch keinen offenen Port 80 oder 443 an. Offen sind ledglich die Ports für DNS und NTP
Der Prozess httpd läuft allerdings. Muss ich das Webinterface irgendwie erst aktivieren?
Gruß Jan
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
--- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. http://www.avast.com
-
Chris Bischoff -
Daniel Weismüller -
Jan-Marten Brüggemann -
Jens Sandmann -
JJX -
Michael Tremer