- Info - freifunk-vogtland.net

Firmware NanoStation loco M2
by eric.dietrich＠gmx.de 30 Dec '19

30 Dec '19

Hallo Freunde, für einen weiteren Standort habe ich eine NanoStation loco M2 hier. Leider lehnt die Firmware ein FFV-Softwareupdate ab. Typ: NanoStation loco M2 / XW.v6.1.7 / Build: 32555 Habt Ihr mit dem Typ schon Erfahrungen gesammelt habe ich irgendwas falsch gemacht? Habe eigentlich alles was es mit loco M2 gibt ausprobiert sowohl stable als auch exp. Wenn ihr noch eine Idee habt, wäre ich euch dankbar. Viele Grüße, Eric Eric Dietrich Waldstraße 12 08328 Stützengrün Tel: 0173 3737715

4 5

Tweet von Freifunk Darmstadt auf Twitter
by Enno M. 22 Dec '19

22 Dec '19

Hi, Wenn jemand noch einen Freifunk Konten sucht. Grüße Freifunk Darmstadt (@FreifunkDA) 22.12.19, 15:50 Momentan ist das Gerät (inklusive Netzteil) für unter 70€ zu haben: notebooksbilliger.de/aruba+instant+… #freifunk twitter.com/FreifunkDA/sta… Die Twitter App downloaden Von meinem iPhone gesendet

1 0

Tweet von Freifunk Darmstadt auf Twitter
by Enno M. 17 Dec '19

17 Dec '19

Hi, Vielleicht eine Alternative für UniFi Knoten? Freifunk Darmstadt (@FreifunkDA) 17.12.19, 11:47 Mit dem Aruba AP-303 werden wir bald auch ein modernes IPQ40xx Gerät für die Deckenmontage in die Liste unserer Hardware-Empfehlungen aufnehmen können. IPQ4029 - 128M Flash - 512M RAM - 802.3af/at PoE #freifunk pic.twitter.com/3IIeebExS6 Grüße Enno Von meinem iPhone gesendet

1 0

FFV Treffen - PhoSaigon am 17.12.2019 (Plauen)
by Sven Eckelmann 17 Dec '19

17 Dec '19

Hi, am Dienstag gegen 18 Uhr ist wieder Treffen im PhoSaigon [1,2]. Gruesse, Sven [1] https://www.freizeitkalender.eu/out/show/id/909819 [2] https://pad.freifunk.net/p/vogtland_freifunk_-_Treffen

1 1

Freifunkknoten Wema-Turm
by Alexander Heidenreich 02 Dec '19

02 Dec '19

Hi, ich kann ab sofort in das Büro und hab gleich mal den Rundumblick festgehalten: https://nc1.adminteam6.de/index.php/s/YfY7bXAbcC8ZzRm Ich würde erst einmal etwas ausbauen und dann können wir darüber nachdenken was wir dort hin bauen. Ich dachte an irgendwas in der Klasse Nano-Station. Voraussichtlich im Januar kommen 1GBit Uplink. Weiss jemand was so 90° Öffnungswinkel hat? Davon 4x für Rundumversorgung. Alternativ mehr mit kleinerem Öffnungswinkel oder gezielt ausrichten? Weiss nicht was besser ist. Grüße Alex Alexander Heidenreich -- IT Security Consultant Tel: 03741-2518042 Email: a.heidenreich(a)adminteam6.de Am Pietzschebach 10 D-08525 Plauen Please use PGP/GnuPGP and no HTML for your emails!

6 11

Freifunk Sightseeing-Tours?
by Linus Lüssing 01 Dec '19

01 Dec '19

N'Abend alle zusammen! Wollte mal fragen, bin ja noch nicht so lange hier, gäbe es interessante Freifunk-Installationen mit guter Aussicht hier in Plauen, die es sich lohnen würden, mal anzuschauen? Bin immer neugierig, wie die hübschen, langen Linien tatsächlich in der Praxis aussehen und realisiert wurden. Falls es die Möglichkeit gäbe, eine kleine "Sightseeing-Tour" zu machen, hätten auch andere Interesse, sich so etwas einmal anzuschauen? Ansonsten wollte ich schon einmal vorankündigen, dass ich demnächst in der Bärenstraße hier noch erstmal zwei Ubiquiti Unifi AC Mesh installieren würde mit Blick Richtung Süden. Das Haus in der Bärenstraße 1 verursacht ein bisschen "Funkschatten", aber westlich und östlich von der 1 habe ich eigentlich eine gute, weite Aussicht. Mit einer TP-Link CPE210 v3 habe ich schon ein bisschen rumprobiert und aus dem Fenster gehalten, aber soweit nichts empfangen können. Auf der Knoten-Status-Seite wurden keine Nachbarknoten gefunden. Gruß, Linus

1 0

FFV Treffen - PhoSaigon am 19.11.2019 (Plauen)
by Sven Eckelmann 19 Nov '19

19 Nov '19

Hi, am Dienstag gegen 18 Uhr ist wieder Treffen im PhoSaigon [1,2]. Gruesse, Sven [1] https://www.vereinonline.org/freifunk.vogtland/?veranstaltung=24193 [2] https://pad.freifunk.net/p/vogtland_freifunk_-_Treffen

1 1

Re: [Ticket ID: FBK-4125-399] MTU-Probleme bei Routing ueber VPN05 (linevast)
by Sven Eckelmann 18 Nov '19

18 Nov '19

On Sunday, 17 November 2019 23:46:03 CET Droptop GmbH Allgemeine Anfrage wrote: [...] > Zum Testen wurden die BGP-Routen ueber alle anderen Server in unserem AS > gestoppt, nur BGP-Session zu einem der FFRL-BB-Server ueber GRE eroffnet > (am meisten mit bb_a_ak_ber und bb_a_ix_dus wiederholt) und dann wurde auf > einem Client Traffic erzeugt (einmal 1270 Byte und einmal 1271 Byte Ethernet- > Pakete): > > ping -4 -M do -s 1228 193.99.144.85 > ping -4 -M do -s 1229 193.99.144.85 > > Dabei viel auf, dass die minimal groesseren Pakete nicht durchkamen. Bei > genauerer Betrachung kam heraus, dass bei den Tests: [...] Nachdem ich die Last auf dem GRE gestern runtergenommen habe, ist das Problem heute frueh nicht mehr so extrem auf dem Server direkt zu sehen. Aber wenn ich einfach mal einen Flood-Ping ueber einen der GRE-Tunnel starte, sehe ich ploetzlich einen Paketloss und Paketfehler. Das laesst sich auf keinem der anderen Server reproduzieren. $ ping -f -M do -s 1229 100.64.9.190 PING 100.64.9.190 (100.64.9.190) 1229(1257) bytes of data. ............................................................................................................................................Warning: time of day goes back (-4773820003067610888us), taking countermeasures. Warning: time of day goes back (-4773820003067610801us), taking countermeasures. C....................^C --- 100.64.9.190 ping statistics --- 1640 packets transmitted, 1480 received, +1 corrupted, 9.7561% packet loss, time 82ms rtt min/avg/max/mdev = 14.462/14.756/29.327/1.000 ms, pipe 3, ipg/ewma 14.068/14.683 ms Ohne GRE-Tunnel sieht es aehnlich aus $ ping -f -M do -s 1229 185.66.195.0 PING 185.66.195.0 (185.66.195.0) 1229(1257) bytes of data. ............................................................C.......................................................................................................................................................................................................................................Warning: time of day goes back (-4774352475924711221us), taking countermeasures. Warning: time of day goes back (-4774352475924711123us), taking countermeasures. C.....C......^C --- 185.66.195.0 ping statistics --- 3110 packets transmitted, 2804 received, +4 corrupted, 9.83923% packet loss, time 832ms rtt min/avg/max/mdev = 14.452/14.681/33.697/0.756 ms, pipe 3, ipg/ewma 14.084/14.877 ms Leider sehe ich Aehnliches auch ueber VXLAN (bis auf Paketfehler): $ ping -f -M do -s 1229 169.254.0.4 PING 169.254.0.4 (169.254.0.4) 1229(1257) bytes of data. ......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................^C --- 169.254.0.4 ping statistics --- 6960 packets transmitted, 6136 received, 11.8391% packet loss, time 174ms rtt min/avg/max/mdev = 2.650/2.870/14.618/0.365 ms, ipg/ewma 4.331/2.884 ms Dieses Problem tritt auch nur bei Linevast auf und bei keinem anderen Server von uns. Gruesse, Sven

1 0

MTU-Probleme bei Routing ueber VPN05 (linevast)
by Sven Eckelmann 17 Nov '19

17 Nov '19

Hi, ich habe soeben festgestellt, dass es mit den Gegenstellen der Freifunk- Rheinland-Backbone ein paar Probleme gibt wenn wir ueber VPN05 (linevast) routen. Wir haben hierfuer 6 (per GRE verbundene) Server mit denen wir Routen austauschen: * bb_a_ak_ber: 185.66.195.0 * bb_a_fra2_fra: 185.66.194.0 (nicht relevant fuer Test, da er momentan keine Route zum Internet anbietet) * bb_a_ix_dus: 185.66.193.0 * bb_b_ak_ber: 185.66.195.1 * bb_b_fra2_fra: 185.66.194.1 * bb_b_ix_dus: 185.66.193.1 Zum Testen wurden die BGP-Routen ueber alle anderen Server in unserem AS gestoppt, nur BGP-Session zu einem der FFRL-BB-Server ueber GRE eroffnet (am meisten mit bb_a_ak_ber und bb_a_ix_dus wiederholt) und dann wurde auf einem Client Traffic erzeugt (einmal 1270 Byte und einmal 1271 Byte Ethernet- Pakete): ping -4 -M do -s 1228 193.99.144.85 ping -4 -M do -s 1229 193.99.144.85 Dabei viel auf, dass die minimal groesseren Pakete nicht durchkamen. Bei genauerer Betrachung kam heraus, dass bei den Tests: * grosse Pakete koennen geschickt werden, aber Antworten kommen nicht zurueck * Rueckroute sieht von aussen erstmal ziemlich gleich aus (unabhaengig von der BGP-Konfiguration) $ traceroute 185.66.195.42 traceroute to 185.66.195.42 (185.66.195.42), 30 hops max, 60 byte packets 1 static.233.248.46.78.clients.your-server.de (78.46.248.233) 0.299 ms 0.279 ms 0.263 ms 2 static.137.135.4.46.clients.your-server.de (46.4.135.137) 0.434 ms 0.423 ms 0.408 ms 3 core21.fsn1.hetzner.com (213.239.229.113) 0.506 ms 0.496 ms 0.482 ms 4 juniper5.nbg1.hetzner.com (213.239.252.241) 2.717 ms juniper5.nbg1.hetzner.com (213.239.252.237) 2.681 ms 2.685 ms 5 ae7-0.bbr02.anx84.nue.de.anexia-it.net (144.208.211.56) 2.994 ms 2.973 ms 2.951 ms 6 ae0-0.bbr01.anx84.nue.de.anexia-it.net (144.208.208.139) 6.383 ms 6.285 ms 6.460 ms 7 ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141) 6.218 ms 6.529 ms 6.438 ms 8 185.66.195.0 (185.66.195.0) 16.405 ms 16.392 ms 16.432 ms 9 185.66.195.42 (185.66.195.42) 16.342 ms 20.787 ms 20.767 ms * Rueckroute sieht ca (bis auf letzten Hop zu 185.66.195.42) gleich aus bei dem funktionierendem VPN01 Das Problem tritt nicht auf bei VPN01 (GK)+VPN04 (Hetzner)+VPN06 (Hetzner) auf - aber auf VPN05 (Linevast). Konfiguration ist aber bei allen Servern gleich. Wenn ich die IP (fuer welche wir die Route announcen) auf VPN03 verschiebe, sehe ich das Problem auch nicht bei VPN03. Ich habe erstmal die IPv6-Announcements von VPN05 gestoppt und die public IP lasse ich erstmal auf VPN03. Damit umgehen wir das Problem erstmal und schicke den Traffic ueber VXLAN zu einem anderen Server. Schoen ist das aber nicht gerade. Gruesse, Sven

1 0

Aw: neues Büro = neuer Freifunk-Node
by Daniel Grosse 08 Nov '19

08 Nov '19

1 0