Knoten in 1130 Nähe Küniglberg

Ja, und ja :slight_smile:

Also jedenfalls katapultiert dich der Setup0xFf-Wizard von 0 auf 99 ohne nennenswerten Aufwand. Online über deine Lightbeam wirst du dann vermutlich schnell sein. Danach kannst du dich mit denn setup weiterhin spielen und umbauen wie es dir taugt.

OK, hat teilweise funktioniert. musste es ein 2.Mal machen, weil eth1 “verloren” gegangen ist.
Jetzt sähe es gut aus, aber LB ist noch immer nicht erreichbar
ubnt@kue48-router:~$ /usr/sbin/arp -a
? (192.168.10.1) at b0:4e:26:5e:55:3b [ether] on eth1
? (10.30.73.1) at on br1
? (192.168.1.10) at a8:1e:84:33:08:9a [ether] on eth0

Komme jetzt natürlich nicht mehr auf die LB ohne zu resetten? {habe dort als Management bridge1 mit LAN0.1100 und WLAN0.1100 eingetragen mit IP 10.30.73.1]
OLSR scheint theoretisch auch zu funktionieren:
23:22:13.648454 IP router.hof28.wien.funkfeuer.at.698 > 255.255.255.255.698: OLSRv4, seq 0x8f61, length 56
23:22:16.052453 IP router.hof28.wien.funkfeuer.at.698 > 255.255.255.255.698: OLSRv4, seq 0x8f62, length 56
23:22:16.160038 IP L1-kue48-hof28.kue48.wien.funkfeuer.at.698 > 255.255.255.255.698: OLSRv4, seq 0x38d7, length 32
23:22:16.160082 IP L1-kue48-hof28.kue48.wien.funkfeuer.at.698 > 255.255.255.255.698: OLSRv4, seq 0x38d7, length 32
komisch, dass OLSR keine default route über br0 einträgt:
default via 192.168.10.1 dev eth1 proto zebra
10.30.73.0/24 dev br1 proto kernel scope link src 10.30.73.100
78.41.113.204 dev br0 proto kernel scope link
192.168.1.0/24 dev eth0 proto kernel scope link
192.168.10.0/24 dev eth1 proto kernel scope link src 192.168.10.111

Lite beam aktualisiert auf letzte version. Nochmals versucht den edge router zu resetten und setup-wizard neu auszuführen, leider endet immer mit Fehlermeldung und schreibt keine config …
Nur dass ich keinen Denkfehler mache:
eth0 mit 192.168.1.1 als “Konfigurationsport”
eth5 mit 192.168.10.x als Uplink zum G4-Modem
eth 1, 2, 3 und 4 frei für POE und Antennen (Antenne hängt an eth4)

Nachtrag: Lessons learned:

  1. Fehler bei der Eingabe der IP-Adresse für Antenne - jetzt geht die Config problemlos
  2. RJ45-Modul für SFP-Port funktioniert nicht mit allen Ethernetports, z.B. Link bei Zyxel Switch o.k., nicht aber bei TP-Link 4G Modem
  3. dmesg kann man abrufen wenn man direkt auf den ER-switch einloggt.

Abhängig von den Einstellungen und dem genutzten eth-Port kann es “normal” sein, dass dein Browser beim Anwenden der Einstellungen die Verbindung zum Router verliert. Das Speichern könnte also sehr wohl gut gegangen sein, doch meldet das Webinterface einen Fehler aufgrund der verlorenen Verbindung.

Ich schlage vor, du trägst den zum konfigurieren genutzten eth-Port als “LAN-Interface-Port” ein - idealerweise ist das eth0. Dann bleibt die Verbindung beim Speichern bestehen und du siehst nach dem apply (plus 2min) die Logfile anstelle des Setupwizards (Full-Browser-refresh vermutlich nötig).

Heute Antennenhalterung Richtung Roter Berg montiert und mal Wandurchbrüche für Verkabelung vorbereitet, bin beim Konfigurieren des power beams M5 400. Kabel kann ich erst in den nächsten Tagen verlegen. Melde mich, wenn Antenne online.
UPDATE 17.5.: Verkabelung funktionell verlegt (ein Stück Kabelkanal muss noch komplettiert werden). Daten: Power Beam M5 400, SSID: 280deg.kue48.funkfeuer.at, Accesspoint, bridging on. Theoretisch sollte der Link funktionieren.

Nur aus Interesse - bekommst Du aus 100° jetzt irgendwelche SSIDs, die einem meiner Knoten gehören könnten? Theoretisch sollte ja nicht ankommen - Link obstructed… :slight_smile:

Leider, keine Funkfeuer SSID’s

Update: hatte leider vergessen AirMAx abzuschalten, daher war der Powerbeam nicht sichtbar. Seit gestern sollte er sichtbar sein unter der oben genannten SSID 280deg.kue48.funkfeuer.at. Hab meine mobile Lite beam (12V-7Ah Akku, 75W Inverter, Lite Beam, 6.1kg plus Laptop - naja sagen wir lieber netzunabhängiges Testequipment) getestet.


Leider vom Roten Berg aus keine direkte Sicht, daher nichts vermessen, warte bis mein Bekannter vom Urlaub zurück ist, vom Dach besteht noch eine Chance.
Veitingergasse sehe ich von meinen Standort praktisch der Länge nach; von einem erhöhten Standpunkt dort sollte es also gehen.

1 Like

Hi, habe heute versucht einen Backup-Link zu FFH (nachdem der OZW ja doch ein paar Tage weg war) zu etablieren. Antenne im 1. Stock montiert, Link grün, SNR -76/-96, halt nicht so ganz flott bei 7 km (13-39 Mbit, schwankend).
Komischerweise bewertet OLSR den Link als recht gut und schickt einen Teil der Routen über diesen Link:
IPv4 Default-Route
router.ffh.wien.funkfeuer.at (193.238.156.4) via br0
IPv4 OLSR-Links
Intf Local IP Remote IP Remote Hostname LQ NLQ Cost routes nodes
br0 78.41.113.204 193.238.156.39 router.hof28.wien.funkfeuer.at 1.000 1.000 1.000
br0 78.41.113.204 193.238.156.4 router.ffh.wien.funkfeuer.at 0.987 1.000 1.012

Allerdings werden einige funkfeuer interne IP’s nicht richtig geroutet, z.B. map.funkfeuer.at geht, aber forum.funkfeuer.at “stirbt” an folgendem Router:
6 7 ms 10 ms 35 ms ge2-rn01falke.falke-bb.wien.funkfeuer.at [193.238.156.86]
7 * * * Zeitüberschreitung der Anforderung.

Kann ich da irgend etwas konfigurationsmäßig beitragen? Wo kann ich die Priorität am edge router für den Backuplink etwas heruntersetzen? Kann gerne die gesamten traceroutes per PN schicken, wenn jemand eine Idee hat …

Nur, um das klarzustellen:

Du verwendest (hoffentlich) auf der br0 die Netzmaske 255.255.255.255?
Hab dem Backbone-Team die Bitte geschickt, kurz gegenzuchecken. Am 19.06. und 20.06. gab es Wartungsarbeiten an Krypta (HW-Tausch) und Falke. Ich könnte mir vorstellen, dass in der Eile vergessen wurde, ein VLAN zu schalten.

Ja, br0 hat 78.41.x.x./32
mit dem Uplink über hof28 geht ja alles, nur wenn ich Antenne ffh daran hänge
o wird die default route auf ffh gesetzt (obwohl für mich nicht logisch, ist langsamer und hat doch bessere metrik???):
IPv4 Default-Route
router.ffh.wien.funkfeuer.at (193.238.156.4) via br0
IPv4 OLSR-Links
Intf Local IP Remote IP Remote Hostname LQ NLQ Cost routes nodes
br0 78.41.113.204 193.238.156.39 router.hof28.wien.funkfeuer.at 1.000 1.000 1.000
br0 78.41.113.204 193.238.156.4 router.ffh.wien.funkfeuer.at 0.940 1.000 1.062

o internationale IP über ffh gehen
o funkfeuer IP’s über hof28 gehen weitererhin, über ffh gehen nicht
Beispiel: map.funkfeuer.at über hof28 geht, forum.funkfeuer.at wird über ffh geroutet und geht nicht

root@kb1130:~# traceroute map.funkfeuer.at
traceroute to map.funkfeuer.at (78.41.112.104), 30 hops max, 38 byte packets
1 192.168.11.1 (192.168.11.1) 0.520 ms 0.400 ms 0.380 ms
2 router.hof28.wien.funkfeuer.at (193.238.156.39) 2.060 ms 1.900 ms 2.020 ms
3 220deg.OZW.wien.funkfeuer.at (78.41.113.227) 3.180 ms 3.060 ms 3.000 ms
4 tunnelLAN.OZW.wien.funkfeuer.at (193.238.159.229) 3.520 ms 3.480 ms 3.240 ms
5 br-641.tunnel.wien.funkfeuer.at (78.41.118.141) 4.960 ms 4.840 ms 4.740 ms
6 ge2-33-rn02krypta.krypta-bb.wien.funkfeuer.at (78.41.113.203) 5.220 ms 8.780 ms 5.000 ms
7 * * *
8 * * *
9^C
root@kb1130:~# traceroute forum.funkfeuer.at
traceroute to forum.funkfeuer.at (78.41.115.238), 30 hops max, 38 byte packets
1 192.168.11.1 (192.168.11.1) 0.420 ms 0.380 ms 0.200 ms
2 router.ffh.wien.funkfeuer.at (193.238.156.4) 1.780 ms 1.820 ms 1.760 ms
3 router.2380hochmayer28.wien.funkfeuer.at (78.41.113.115) 3.420 ms 3.920 ms 8.340 ms
4 router.2345falke.wien.funkfeuer.at (78.41.112.141) 4.680 ms 6.180 ms 6.720 ms
5 ge2-rn01falke.falke-bb.wien.funkfeuer.at (193.238.156.86) 5.620 ms 6.240 ms 4.620 ms
6 * * *
7 * * *
8^C
root@kb1130:~#

Ja, irgend wo zwischen falke und krypta dürfte was verloren gehen …

Ping geht?
traceroute -T geht?

Willkommen in der Welt von OLSR. OLSRv1 hat keinen Mechanismus, die Bandbreite eines Links zu bestimmen. Es orientiert sich lediglich an der Anzahl der über einen Link verlustfrei übertragenen Pakete. Es nimmt dafür im Algorithmus etx_ff auch die Traffic Control Pakete (TC) her.

OLSRv2 hat so einen Mechanismus, ist aber meines Erachtens noch immer eine frühe Alpha. @Pocki ist da der Experte.

Backbone-Team soll bitte sw2krypta durchchecken, wie ich schon per E-Mail an die Liste geschrieben habe - der wurde vor zwei Tagen aufgestellt…

-T hab ich am openwrt nicht :frowning:
aber es geht ja das https auch nicht, deshalb ist es ja erst aufgefallen
Ergänzung:
wenn ich am edge link über ffh deaktiviere geht alles über hof28 - OK
wenn ich am edge link über hof28 deaktiviere geht alles über ffh (!) - soweit OK
wenn ich beide links aktiviere wird ffh zur defaultroute (obwohl etwas instabiler) und dann gehen über ffh geroutete internationale IP’s schon, FF IP’s gehen nicht, und FF IPs welche zufällig über hof28 geroutet werden gehen schon.
Da gabs doch mal sowas mit split routes, wo die pakete den Rückweg nicht mehr finden?

Es gibt zwei dedizierte VLANs zwischen den Roofnodes, damit sich diese den Traffic gegenseitig schicken, der im Mesh bleiben soll… Eine Praxis, die ich für den Tunnelserver zugusten des früheren gemeinsamen VLANs abgelehnt habe und auch noch nicht umgestellt habe. Warum: Der Wartungsaufwand steigt mit jedem Roofnode. Und ich glaube, dass das hier die Ursache ist. Wie gesagt, vorgestern wurde ein neuer Switch auf Krypta aufgestellt und Ports dahin umgestöpselt.

@erich
d.h. die ermittelte LQ von 0.940 für FFH schlägt die 1.0 für hof28 (dachte das wäre umgekehrt, zum ffh gibt es nur 60% trans mit ccq)? Lieber wäre es mir wenn ich eine Vorgabe machen könnte.

Ich habe aktuell keine Probleme.
Was genau geht denn nun nicht? Traceroutes sind nur bedingt aussagekräftig.

s.o. Funkfeuer-Ips (also z.B. 78.41.x.x) über FFH wenn beide Antenen aktiv sind
“wenn ich beide links aktiviere wird ffh zur defaultroute … und dann gehen über ffh geroutete internationale IP’s schon, FF IP’s gehen nicht, und FF IPs welche zufällig über hof28 geroutet werden gehen schon.”