Altes Neues Forum!

Wichtig: dieses Forum ist wieder aktiv, weil das alte neue leider nicht mehr läuft.

Ev. Gemeindenzentrum Bingerbrück

43 Beiträge / 0 neu
Letzter Beitrag
#1 11. November 2015 - 15:01
Stefan
Bild des Benutzers Stefan

Ev. Gemeindenzentrum Bingerbrück

Die aktuelle Installation ist nicht durchdacht und funktioniert so nicht. Ich möchte versuchen, die Aufgabenstellung vor Ort mal etwas zu strukturieren:

Aufgaben im Gemeindezentrum:

1. Verteilung des internen Netzes aus dem Gemeindebüro in den Innenhof/bis zum Internetcafe

2. Versorgung des Wohnheims im GZ selbst und in der Bingerbrücker Str.

3. Nutzung des Kirchturms als Backbone-Relay (Richtung Waschbär, Richtung Innenstadt, Richtung MüSa)

Mein Vorschlag:

zu 1)

Hans Günther hat ja schon ein Kabel Richtung Innenhof verlegt. Dort bauen wir den 4300er als AP für das INTERNE Netz des GZ auf. Damit wäre der Innenhof, die Cafeteria/Besprechnugsraum versorgt. Ausserdem versorgt der eine wlan-bridge auf dem Turm. Wir hätten dann quasi einen LAN-Port auf dem Kirchturm.

Dort können wir dann mit einem weiteren Router das Internetcafe versorgen (Dort also auch einen LAN-Port bereitstellen)

zu 2)

mit dem dann auf dem Turm Vorhandenen "LAN-Port" können wir ein Freifunk-Netz bereitstellen, das Richtung Bingerbrückerstrasse/Internetcafe/Innenhof zielt

zu 3)

Als Relay Position können, müssen wir aber den LAN-Port nicht nutzen. Ist ja ein "Backbone-Relay"

 

Dies wäre einfach mit Openwrt auf dem 4300er und zwei 841ern aufm Turm getan (Geräteteil GZ)

Was wir dann da selbst an Hardware aufstellen für das Backbone Relay haben wir ja auch schon klar.

Im Thread "Flüchtlinge in BiBrü" müsste nurnoch diskutiert werden, wie wir den Standort an das Backbone im Kirchturm anbinden. Und das Thema ist ja eigentlich ganz einfach.

 

11. November 2015 - 16:59
Manuel
Bild des Benutzers Manuel

Würde ich komplett anders machen und getrennt sehen. Ich muss gestehen, die Vernetzung von Büro zu Internetcafe hat wenig mit Freifunk zu tun und fällt eigentlich nicht in unseren Bereich. Das muss gewartet werden und stabil laufen, wir sind keine Dienstleister und können keine ständige Funktion gewährleisten.

Mein Vorschlag:

- 4300er mit Gluon ans Ende vom Kabelkanal, 841er im Büro evtl weg (Client-Netz auf 4300er ist aktuell deaktiviert!)
- Im Turm eine LocoM2 mit Gluon, sonst nix
- Gegenstelle Waschbär ebenfalls die Loco auf Gluon
- Vernetzung Büro mit Cafe komplett unabhängig davon, z.B. 2 Picostations

Je weniger Geräte wir verbauen desto besser und einfacher.

11. November 2015 - 18:09 (Antwort auf #2)
Stefan
Bild des Benutzers Stefan

unten im GZ findet kein Freifunk statt, das ist alles GZ-Netz (4300er als AP im Hof). Den Freifunk-Uplink holen wir uns mit einem openwrt-841er als client im GZ-Netz sozusagen auf den Turm und erst ab da wird freigefunkt.

Wir haben einen Kirchturm, den wir nach belieben fürs backbone nutzen können, einen funktionierenden Uplink in die Unterkunft und die Gemeinde ihr WLAN.

Und sie lebten lange und glücklich bis ans Ende Ihrer Tage... :)

11. November 2015 - 18:04
Stefan
Bild des Benutzers Stefan

Ich war eben nochmal da und werde das morgen umsetzen.

Gerätebedarf unserseits: Die M2 die schon hängt (wird auf Gluon geflasht, ebenso die Gegenstelle), optional eine zweite Richtung reinrunter

Gerätebedarf GZ: 4300er (originalfirmware), 3x841er (openwrt)

Erfordert also lediglich den Umbau/Reflash der bereits vorhandenen Geräte und wir haben wesentlich weniger Frequenzüberlappung.

@olli: Hast du die originalen Antennen noch?

11. November 2015 - 20:06
Manuel
Bild des Benutzers Manuel

Wenn du die Vernetzung GZ->Cafe machen möchtest, spricht da von meiner Seite nix dagegen, aber Freifunk Bingen kann dafür keinen Support, Gewährleistung oder Haftung anbieten.

Die zwei 4300er wurden - zusammen mit den zwei Locos - von mir in Rechnung gestellt, was damit passiert kann der Eigentümer natürlich frei entscheiden.
Allerdings sind die 841er und die dritte Loco aus Privatbesitz und eigentlich nicht dafür vorgesehen, das Internetcafe zu versorgen und können an anderen Stellen durchaus gut gebraucht werden.

Die Freifunk-Installation würde funktionieren, indem wir den 841er im Büro abbauen, den 4300er mit Gluon außen (oder in der Nähe) aufhängen, und die Locos auf Gluon geflasht werden. Also bleiben zwei 841er übrig, die eigentlich zurück an ihre Besitzer gehen sollten.

Das Internetcafe mit Freifunk zu versorgen wäre eine andere Geschichte.

11. November 2015 - 21:36 (Antwort auf #5)
Stefan
Bild des Benutzers Stefan

Also lassen wir die Schranz-Installation wie sie ist (und die Leute oben ohne wirklich funktionierendes Inet) und du machst das dann ... nächste Woche... vielleicht? Mach es bitte nicht unnötig kompliziert!

Ich baue das morgen so um, das es funktioniert. Die Geräte für den Ausbau ihres Netzes bezahlt die Kirchengemeinde, dann sind ja alles Sachen wieder bei Ihrem rechtmäßigen Besitzer. Den 4300er, der dann sogesehen "freigestellt" wäre, kann dann ja oben noch verbaut werden, die zwei 841er gehen zurück und alles ist gut.

Das die GZ-Strecke in deren Verantwortung liegt habe ich Hans-Günter deutlich gesagt. Ich baue das auf, dokumentiere es und übergebe es ihm. So ganz einfach als Privatperson. Wenn die läuft, bleibt uns halt auch der Krichturm als Mountpoint für den Backbone erhalten.

12. November 2015 - 8:11
ruben
Bild des Benutzers ruben

von mir aus bau, wenn es danach mal läuft und wir nicht ständig da hin müssen soll es mir recht sein.

Ganz verstanden habe ich den Aufbau nicht, aber aufgrund der begrenzten Zeit und weil ich es schon wichtig fände, dass das WLAN aufm Berg mal läuft, hau rein.

Wie das mit Updates für OpenWRT ist etc. weiß ich nicht...

12. November 2015 - 9:36
Manuel
Bild des Benutzers Manuel

Das hier scheint der Fehler auf dem 06er zu sein:
Wed Nov 11 20:25:21 2015 kern.err kernel: [180190.260000] ath: phy0: Failed to stop TX DMA, queues=0x00a!
Thu Nov 12 04:08:33 2015 kern.err kernel: [207982.660000] ath: phy0: Failed to stop TX DMA, queues=0x002!
Thu Nov 12 07:22:11 2015 kern.err kernel: [219600.850000] ath: phy0: Failed to stop TX DMA, queues=0x002!

Gibt dazu auch eine Issue bei Gluon: https://github.com/freifunk-gluon/gluon/issues/130
Der Knoten Ist grade wieder online, Signalqualität sehr gut. Ich mach den mal auf beta.

12. November 2015 - 17:23
Stefan
Bild des Benutzers Stefan

So, ich habe jetzt umgebaut.

Der 4300er ist weg (bzw. umgewidmet, entsprechend muss ein neuer 4300er beschafft und der KG in Rechnung gestellt werden).

Der 04er heisst jetzt ffbin-bingerbrueck-uplink und hängt hinter einfachverglasung mit direktem blick auf den turm, quasi direkt via kabel an den speedport angebunden. Der 06er taucht nicht in der karte auf.

Also die Verbindung hoch zum Turm kann besser nicht werden.

13. November 2015 - 17:00
Mollinger
Bild des Benutzers Mollinger

irgendwie ist jetzt gar nix mehr online

13. November 2015 - 17:37
Stefan
Bild des Benutzers Stefan

Tja, ich war heute da und habe den 06er abgebaut. Die Nanostation ist beim flashen abgeraucht (ja, ich hab alle möglichen reset-wege versucht und tftp flash, etc.) Kann jemand einen seriellen Adapter bauen/hat einen usb/serial converter? das wäre die letzte Möglichkeit). Ich denke das Ding müssen wir abschreiben.

Manuel hat noch eine, evt. könnte ich die morgen montieren, ansonsten Montag abend.

13. November 2015 - 19:32 (Antwort auf #11)
Steve

Hallo Stefan,

Wenn du noch einen USB-Serial Adapter sucht, sowas nutze ich hier für meine Telefonanlage.

Es ist ein FTDI USB-Serial-Adapter; (siehe Anlage)

aktueller Treiberdownload:

http://www.ftdichip.com/Drivers/VCP.htm

Bei Bedarf einfach melden.

Gruß

Steve

 

 

Bilder: 
13. November 2015 - 20:18
ruben
Bild des Benutzers ruben

Warum ist der uplink denn offline?

13. November 2015 - 21:02 (Antwort auf #13)
Stefan
Bild des Benutzers Stefan

Aargh. Hans hat am Speedport gebastelt, als ich weg bin... die Baustelle macht mich feddich!

14. November 2015 - 14:17
Manuel
Bild des Benutzers Manuel

So, wie auch immer du's geschafft hast Stefan, die Nanostation so zu bricken - sie funktioniert wieder.
Eine Anleitung schreibe ich die Tage, habe nämlich nichts dazu im Netz gefunden.

Bitte Termin mit HG ausmachen, ich komme auf jeden Fall mit.

14. November 2015 - 16:00 (Antwort auf #15)
Stefan
Bild des Benutzers Stefan

Durch ganz banales Flashen mit dem Nanostation-Gluon. Das müssen wir unbedingt auch noch irgendwo dokumentieren, daß da das "Bullet" Image verwendet werden sollte.

Respekt fürs unbricken!

Termin im GZ: Montag, 17:30 Uhr

16. November 2015 - 9:50
Mollinger
Bild des Benutzers Mollinger

Hab heute frei und komm dann auch mal um 17:30Uhr vorbei

16. November 2015 - 14:35
Stefan
Bild des Benutzers Stefan

Der Termin heute abend hat sich erledigt: Wir waren eben da, haben einen Fehler in der Verkabelung beseitigt und die Nanostation montiert. Wie es aussieht läuft jetzt alles, Ich wage mal vorsichtig, die Baustelle für beendet zu erklären :)

16. November 2015 - 15:40
ruben
Bild des Benutzers ruben

Warum gibt es ein 01er und einen waschbär die mit dem turm meshen?

16. November 2015 - 16:22 (Antwort auf #19)
Stefan
Bild des Benutzers Stefan

Weil die Loco im Turm beide erreciht. mein Vorschlag: Client Netz auf der Station am Waschbär abstellen, der 4300er ist ja via Kabel angebunden.

15. Dezember 2015 - 17:36
ruben
Bild des Benutzers ruben

Mindenstens eine loco m2 soll noch auf den turm, damit könnte sich das nahemesh verbinden, über drk und sanderweg.
Eine zweite richtung innenstadt hätte erstmal keine gegenstelle und ist damit noch überflüssig.
Stefan wollte auch noch was erledigen, man könnte die baustellen verbinden...

Wer kontaktiert hans günter? Wann haben leute die interesse haben zeit?

20. Dezember 2015 - 13:53
ruben
Bild des Benutzers ruben

Also Montag oder Dienstag Abend soll da aufgebaut werden, Stefan ruft Hans an.

Die LocoM2 im Sanderweg hängt.

21. Dezember 2015 - 10:02
Mollinger
Bild des Benutzers Mollinger

Loco hab ich gestern geflashed und konfiguriert. Muss nur noch in den Turm

21. Dezember 2015 - 11:24
Stefan
Bild des Benutzers Stefan

Heute (Mo, 21,12,) abend um 18Uhr habe ich einen Termin, um das Ding zu hängen. @Mollinger: bitte meld Dich mal bei mir, am besten via Fon.

21. Dezember 2015 - 20:46
ruben
Bild des Benutzers ruben

Ich habe einen kurzen Artikel zum Aufbau geschrieben https://www.freifunk-bingen.de/news/das-mesh-%C3%BCber-die-nahe-wird-gr%...

21. Januar 2016 - 16:07
ruben
Bild des Benutzers ruben

Am kommenden Montag den 25.01. treffen wir uns um 17h zum Umbau im Turm.

25. Januar 2016 - 21:20
ruben
Bild des Benutzers ruben

Das war nix. Die Kommunikation war offensichtlich schlecht. Meine Idee dazu, mehr ins Forum schreiben, ich komme, ich komme nicht, ich bin da, ..

Ansonsten scheint der Uplink am Gemeindebüro schon ein Nadelöhr zu sein, Oliver misst gerade mit iperf, evtl. wäre da eine gute Position für einen offloader.

Ansonsten bräuchten wir wohl einen neuen Termin.

25. Januar 2016 - 21:52
realprogrammer
Bild des Benutzers realprogrammer

Machen die Messungen so wie ich sie gemacht hab Sinn? Den Uplink kriegen wir mit nem Offloader (Fujitsu Futro S550-2) gepimpt, damit bekomme ich eine50 Mbit-Leitung ausgenutzt. Bei nem 841er ohne Offloader ist bei 7 Mbit down Schluss.

Die Verbindung zum Turm sollten wir nochmal optimieren ...

Speedtest.net-Messung (direkt vor ffbin-evkirche-buero-uplink): ca. 5 Mbit up/5 Mbit down

iperf-Messungen (zwischen ffbin-evkirche-buero-uplink und ffbin-evkirche-turm-sw):

UDP:

root@ffbin-evkirche-turm-sw:~# iperf -u -V -s
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 160 KByte (default)
------------------------------------------------------------
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 52551
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 5.437 ms 1/ 892 (0.11%)
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 48611
[ 3] 0.0- 9.0 sec 1.13 MBytes 1.05 Mbits/sec 4.380 ms 91/ 894 (10%)
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 49307
[ 3] 0.0-19.0 sec 2.39 MBytes 1.05 Mbits/sec 3.887 ms 79/ 1785 (4.4%)
read failed: Connection refused
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 60885
[ 3] 0.0-19.8 sec 2.47 MBytes 1.04 Mbits/sec 5.304 ms 23/ 1785 (1.3%)
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 42489
[ 3] 0.0-39.0 sec 4.88 MBytes 1.05 Mbits/sec 4.087 ms 83/ 3566 (2.3%)
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 55839
[ 3] 0.0-39.1 sec 4.63 MBytes 995 Kbits/sec 12.979 ms 257/ 3563 (7.2%)
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 48355
[ 3] 0.0-58.7 sec 7.29 MBytes 1.04 Mbits/sec 16.637 ms 152/ 5349 (2.8%)
read failed: Connection refused
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 56221
[ 3] 0.0-59.7 sec 7.17 MBytes 1.01 Mbits/sec 7.827 ms 237/ 5351 (4.4%)
read failed: Connection refused
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54313
[ 3] 0.0-79.6 sec 9.54 MBytes 1.01 Mbits/sec 10.106 ms 324/ 7132 (4.5%)
read failed: Connection refused
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 53807
[ 3] 0.0-79.1 sec 9.90 MBytes 1.05 Mbits/sec 8.580 ms 64/ 7126 (0.9%)
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 53819
[ 3] 0.0-120.2 sec 13.9 MBytes 970 Kbits/sec 55.108 ms 781/10697 (7.3%)
[ 3] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 47634
[ 3] 0.0-119.0 sec 13.1 MBytes 921 Kbits/sec 14.130 ms 1341/10659 (13%)
read failed: Connection refused

 

TCP:

root@ffbin-evkirche-turm-sw:~# iperf -V -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54587
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.3 sec 4.88 MBytes 3.99 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54588
[ 4] 0.0-10.1 sec 4.38 MBytes 3.63 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54589
[ 4] 0.0-20.6 sec 10.9 MBytes 4.44 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54590
[ 4] 0.0-23.9 sec 7.38 MBytes 2.59 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54591
[ 4] 0.0-42.3 sec 6.63 MBytes 1.31 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54592
[ 4] 0.0-47.6 sec 3.38 MBytes 595 Kbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54593
[ 4] 0.0-61.1 sec 16.1 MBytes 2.21 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54594
[ 4] 0.0-63.7 sec 11.4 MBytes 1.50 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54595
[ 4] 0.0-78.5 sec 21.4 MBytes 2.28 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54596
[ 4] 0.0-80.6 sec 24.3 MBytes 2.53 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54598
[ 4] 0.0-120.6 sec 47.1 MBytes 3.28 Mbits/sec
[ 4] local fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76 port 5001 connected with fd37:b4dc:4b1e:0:62e3:27ff:fe76:df02 port 54599
[ 4] 0.0-123.6 sec 24.4 MBytes 1.65 Mbits/sec

Messskipt (auf ffbin-evkirche-buero-uplink unter ~/iperf.sh):

#!/bin/ash
local TARGET="fd37:b4dc:4b1e:0:6a72:51ff:fe36:c76"
for DURATION in "10" "10" "20" "20" "40" "40" "60" "60" "80" "80" "120" "120";
do
iperf -t $DURATION -V -c $TARGET
done

25. Januar 2016 - 22:28
Stefan
Bild des Benutzers Stefan

schicker test... wie erklärst du dir den unterschied im durchsatz zwischen udp und tcp? sollte doch eigentlich andersrum sein wegen protocol overhead und so... ich würde daraus schliessen, das es nicht um die "System-Leistungsfähigkeit" der gegenstellen geht (tcp: "na, dann versuch ich es halt nochmal" / udp: "wech is wech"). Interessant wären noch die Paket-Drops auf den interfaces bei dem test.

25. Januar 2016 - 22:45 (Antwort auf #29)
realprogrammer
Bild des Benutzers realprogrammer

Einen wirklichen Reim kann ich mir aus dem Test nicht machen, außer das da mehr durchgehen sollte.

Paketverlust steht bei den UDP-Tests in den Ergebnissen [ 3] 0.0-120.2 sec ... 781/10697 (7.3%) <- 7,3 % Paketverlust.

30. Januar 2016 - 17:16
realprogrammer
Bild des Benutzers realprogrammer

So, ich hab jetzt einen Offloader für das Büro fertig gemacht und zwei 5 GHz-Router zum Testen der Verbindungsqualität in den Turm liegen auch noch rum.

Wollen wir es diese Woche nochmal angehen? Wer hätte Zeit und Lust?

30. Januar 2016 - 18:37
ruben
Bild des Benutzers ruben

Ich kann die Woche nur nach 18h, muss lange arbeiten, dann könnte ich mitkommen.

10. Februar 2016 - 15:27
ruben
Bild des Benutzers ruben

Wird nix heute, Manuel hat keine Zeit.

12. Februar 2016 - 12:52
ruben
Bild des Benutzers ruben

Laut dem Artikel sollte ein 1043er fürs fastd/Uplink ausreichend sein https://freifunk-goettingen.de/2015/07/freifunk-im-freibad-rosdorf-hat-s... Version 2 hat einen 720MHz Prozessor und 64MB Ram https://wiki.openwrt.org/toh/tp-link/tl-wr1043nd

12. Februar 2016 - 20:46 (Antwort auf #34)
realprogrammer
Bild des Benutzers realprogrammer

Die Anzahl der eingeloggten Clients heißt ja noch nix. Wenn ein Großteil nur Messaging nutzt langen die ca. 14 Mbit locker, welche ich maximal durch nen 1043er bekomme. Außerdem hat der Anschluss net viel mehr geboten an Bandbreite. Wenn aber mehr Bandbreite vorhanden ist, dann sollte man es den Leuten ermöglichen die zu nutzen.

Am Waschbär wird das Internet intensiver als im Freibad genutzt ...

Gibt es schon einen neuen Termin?

12. Februar 2016 - 23:53
ruben
Bild des Benutzers ruben

Nein, @manuel wann hättest du zeit?

13. Februar 2016 - 12:15
Manuel
Bild des Benutzers Manuel

das wüsste ich auch gerne...

Ich sage mal vorsichtig Sonntag ab 14 Uhr, Montag & Dienstag ab 17 Uhr.

Ich mach gleich einen Plan, poste ihn hier rein und bereite so viel vor wie es geht. 

18. Februar 2016 - 7:42
ruben
Bild des Benutzers ruben

Wir Treffen uns am Samstag Mittag. Die genaue Uhrzeit kommt noch.
Der Plan evtl. auch. Ziel wird es sein nur noch ein Gerät pro Kanal im Kirchturm zu haben.

20. Februar 2016 - 7:42
ruben
Bild des Benutzers ruben

Also 14h geht es in Bingerbrück los.

20. Februar 2016 - 8:54
ruben
Bild des Benutzers ruben

ein artikel zu offloadern und verschlüsselung im freifunknetz http://bremen.freifunk.net/blog/2016/02/16/performance-und-offloader.html

29. März 2016 - 13:17
ruben
Bild des Benutzers ruben

was ist mit der loco richtung so los? hat jemand eine ahnung?

29. März 2016 - 15:08
Manuel
Bild des Benutzers Manuel

Nein, keine Ahnung.. Müsste jemand hoch, bei mir sieht's diese Woche schlecht aus.

Wenn jemand hoch geht: bitte 1-2 SSH-Keys Eintragen!

29. März 2016 - 18:21 (Antwort auf #42)
realprogrammer
Bild des Benutzers realprogrammer

Bei mir sieht es diese Woche auch schlecht aus, frühstens am Wochenende. Ich würde mal nächste Woche Dienstag anpeilen, dann ist auch Hans vor Ort.