Richtfunkstrecke Nano M5

Hallo Zusammen,

ich habe hier ein Netzwerk mit ein paar Unifi Komponenten - daher bin ich hier im Forum gelandet

Ich hab es im Anhang aufgezeichnet. Mein Problem ist, das ich bei J ab und zu Aussetzer habe. Das ist nicht nur der PC sondern eigentlich alles was im Gebäude B hängt (Smart TV, Tablet usw. usf.). Oft äußert es sich das Youtube lagt, VPNs zusammenbrechen oder Lagen und Telefone sich beschweren damit es über LTE schneller geht

Somit hab ich die Richtfunkstrecke F zu E im Verdacht. Dazu hab ich an G einen Linuxrechner angeschlossen und iperf3 Richtung Router (A) gemacht. Da hab ich recht zuverlässig 90MBit - aber ab und zu, wenn ich mit IPerf 10min penetriere, kommen 0,1 bis 1% Retrys zu Tage.

Mit iperf3 -c 192.168.0.1 -p5201 -t 600 von einem LinuxPC an G Richtung Router (quasi einmal Netzwerk mit alles ) :

[ ID] Interval Transfer Bitrate Retr

[ 5] 0.00-600.00 sec 5.90 GBytes 84.5 Mbits/sec 3089 sender

[ 5] 0.00-600.00 sec 5.90 GBytes 84.5 Mbits/sec receiver

Inerhalb der Gebäude bekomme ich recht zuverlässig 700MBit++ - was ja dicke ausreicht.

Hab ich evtl. die Nanostations falsch eingestellt? Die sind seit 10 Jahren im default Setting (Nur Verschlüsselung/IPs angepasst)

Wissenswert ist evtl. noch das ich im USG viele Ports blocke die nicht gebraucht werden und es ein PIHole gibt.

Gruß Raphael

Hallo Hommes,

ich kann leider alles nicht so genau beziffern da wir auch Probleme mit dem ISP haben. Das mit der Failover Leitung kommt daher.

Ich hab nun einen Ping Tracer laufen und dort gesehen damit es mal eine Stunde kein Thema gibt (alles <10ms) und dann wie ein "Burst" 20...500 Timeouts hageln - durchsetzt mit einigen Pings unter 10ms. Die Bilder sind alle auf meinem Firmennotebook - müsste ich nachher mal hier her holen. An den M5 hab ich nun mal auf der AP Seite Airmax deaktiviert - am Client war es schon auf None.
Zusätzlich stand eine M5 auf 1.6km und die andere auf 0.4km. Da wir 150m überbrücken (grade per GPS nachgemessen) habe ich ACK Timeouts beidseits auf 28 gestellt.
Jetzt läuft ein neuer Test - mal sehen.
An den M5 war ich ewig nicht dran - also wird alles outdated sein. Das ist dann die nächste Variable an der ich schraube wenn es weiterhin Lagt.

Wäre das dann die:

airOS6 for XM board firmware v6.3.16?

Vielen Dank dir und Grüße

Also es wurde nicht besser.... Mitlerweile sind beide Stations Up to Date und der nächste iperf 10min Test läuft.
Ich sehe aber schon während der eine PC Iperf3 laufen lässt geht am anderen die Pingrate über 10ms - mit ein paar timeouts.
Ebenso sehe ich in der M5 damit die TX Rate hoch und runter springt.
Dieser Test wird also wieder Paketverluste zeigen - das warte ich ab und teste dann nochmal mit herabgesetzter TX/RX Rate in der M5 und ohne Automatik.

Edit: Oh Wunder... keine Retrys beim IPerf - dafür aber einzelne Ping Verluste. Ich hab nun erstmal ein test laufen mit 20dBm auf beiden Seiten - vorher waren es 15.
Signalstärke ist aktuell bei -61dBm bei -85dBm Rauschteppich.

Neuer Tag, Neues Glück oder so.

Ich hatte gestern und vorgestern abend kein Lag beim TV schauen. Dabei sind sichere Lags "leider" auch nicht die Regel. Gestern war ich nicht im Büro, dafür hatte ich vorgestern Abend noch 2 Voip Telefonate - da gab es öfters ruckeln. Ob das nun an meiner Verbindung liegt kann ich ja schwer sagen.

Also gestern Abend und heute Morgen neue Tests. Da sieht noch alles so aus wie am Anfang. Wenn ich IPerf zum Router (über die komplette Strecke) laufen lasse, sehe ich das an meinem Ping zum anderen Ende der Richtfunkstrecke.
Im Anhang mal ein PingTrace - die roten sind meine Fails die ich weg haben möchte. Die passieren sehr selten im Idlemode - da ist auch alles recht oft bei 1ms aber so gut wie immer unter 20ms. Damit bei Vollast die Pingzeit zwischen 30 und 50 liegen kann ist ja okay, aber Verluste sollen keine passieren. Parallel dazu ein Ping hier lokal im Haus bleibt sicher bei 1...3ms. Somit ist der Switch hier nahezu ausgeschlossen.

Hier noch die Ausgabe von IPerf während dem Stressen:

[ ID] Interval Transfer Bitrate

[ 5] 0.00-60.01 sec 591 MBytes 82.6 Mbits/sec sender

[ 5] 0.00-60.01 sec 591 MBytes 82.6 Mbits/sec receiver

Wo muss ich an der Richtfunke was stellen damit die Verluste weg gehen? Bei TCP ist das ja kein Thema aber bei UDP nervt es sehr. Im Anhang dazu mal die Übersicht des M5 Client Systems.

Anbei mal die in meinen Augen wichtigen Settings gegenüber gestellt. Lan Speed setze ich mal von 10/100 auf fix 100 und beobachte weiter.

Wenn ich die LAN Ports Beider M5 auf 100Mbit Half Duplex schalte sind die Ausfälle weniger.... ist das Symptom oder Ursache? Wird dadurch alles etwas langsamer oder bin ich da was auf der Spur?

Edit: Ich bin weiter: Im großen Switch im Haus B hängt die M5 direkt an einem Port. Dort ist mir aufgefallen das ich Paketkollisionen ohne Ende habe. 304329 in 30 min - wo Pack ich da an?

Ich hab grade das Kabel vom Switch ins Patchpannel gewechselt. Da war ein sehr kurzes drin was ja auch Laufzeiten problematisch sein kann. Wobei Ethernet da ja recht robust ist. Das war es nicht.

Als nächstes tausche ich den Port am Switch, dann den POE Connector, dann die Kabel aufm Dachboden und wenn alles nicht hilft den LAN Port am M5.

Edit: Switchport und Patchkabel ist es nicht... Der POE Injektor des Unifi AP Pro geht nicht da aktiv GBit und die M5 will wohl Passive...

Wie warscheinlich ist es der Injektor? Dann bestelle ich mir einen neuen. An den M5 komme ich nur mit 10m Leiter - was ich grade witterungsbedingt vermeiden möchte

Die Kollisionen sind viel zu viel - die zählen sehr schnell hoch. Edit: Wir reden von 10% der Pakete die Kollisionen verursachen - das ist zu viel. Alle anderen Ports haben 0 über 5 Tage.

2FE über GBE hab ich zwar im Einsatz aber nur in den Schaltschrank für die Modbus/KNX Koppler. Damals hab ich 2x GBE gelegt und es ist zu wenig

So, es wird langsam eng... Der POE Adapter ist es auch nicht. Morgen noch das Kabel tauschen und dann muss ich an die Richtfunkstrecke ran.
Welche würde man nun verbauen?

Die Strecke ist ja kurz - da ist die Frage ob ich überhaupt so eng bündeln muss. Die Gen2 hat ja angeblich 450Mbit - das wäre geil
Dann würde ich hier schonmal auf Gen2 aufrüsten und im Sommer die andere Seite nachziehen.
https://www.omg.de/ubiquiti-ne…-nanobeam-ac-gen2/a-14332 wäre sowas tauglich?

oder reicht auch schon sowas?

Ubiquiti LiteBeam 5AC GEN2 | Online-Shop für perfomante IT Lösungen | OMG.de GmbH

www.omg.de

Darf bei 2 Stück natürlich gerne günstig sein - muss es aber nicht zwingend. Wenn etwas mehr Geld deutlich mehr bringt sagt mir das bitte.

Servus zusammen,

also hier geht es weiter. Das Kabel wurde Samstag gelegt und brachte nichts (wie zu erwarten). Nun habe ich 2 LiteBeam bestellt und bringe zumindest mal unsere Seite nachher aufs Dach (wenn die Witterung und Post mitspielt).

Ich war nicht ganz Inaktiv und habe mir SmokePing auf einem Server Installiert. Hier im Gebäude B gibt es einen Homeserver mit Proxmox und darin rennt dann auch SmokePing. Wieso rede ich so viel darüber? Ich denke das könnte dem einen oder anderen helfen.

Zuerst mal eine Messung zum Router hin. Hier sieht man deutlch das in der Zeit um 12:00 und 16:00 eine hohe RTT (Round Trip Time) sowie viele Losses waren. In der Zeit waren auch alle Probleme weshalb ich das ganze analysiere maximal. Sprich die IP Radios sind ausgetickt, Telko ging nicht usw.

Man sieht aber auch damit die "Linie" der Losses nie konstant grün ist... Also müssen wir in der Kette weiter zurück.

Dazu nun die Gegenprobe... mein PiHole im gleichen Rack wie der Proxmox Server:

Erkentniss: Lokal läufts... 0% Losses und eine RTT von max 0,9ms mit 0,1ms SD (Standard Deviation).

Dagegen stehen ja die Messungen des Routers mit bis zu 43% Losses, max 10,5ms RTT und 1.5ms SD.

Also schauen wir uns den Switch im besagten Rack an:

Auch da ist alles gut, die RTT geht etwas hoch auf 2,1ms was aber auch daran liegt dass ich auf die Management Konsole des Switches Pinge und die im Zweifel nicht für eine schnelle Response ausgelegt ist. Diesen Verdacht begründe ich mit der guten Erreichbarkeit des PiHole (RasPi 3B).

Also nun eine Stufe weiter zur Client Seite der Richtfunkstrecke. Hier sehen wir massiv erhöhte RTT in besagten Zeiträumen und immer mal wieder Losses. Die Losses sind nicht so viel wie beim Router, aber es sind schon einige. Da ich ja an die Richtfunkstrecke selbst Pinge und nicht darüber ist die Funkstrecke noch außen vor. Somit hat die Hardware hier irgend einen Wurm - daher tausche ich die erstmal.

Meine Theorie: Nach 10Jahren exponiert werde ich wohl den einen oder anderen Überspannungsschlag bekommen haben. Im Zweifel alles nur statische Aufladung und somit ESD Schäden. Aus meinem Beruf weis ich dass das nicht zwangsweise einen Ausfall bedeutet sondern nur undefinierte Probleme erzeugen kann.

Das kenne ich auch von Sat und Radio Recivern die im Alter immer "tauber" werden.

Ich habe mir von Unifi nun auch die Überspannungseinrichtungen gekauft und baue die direkt auf die Innenseite der Hauswand meiner Streckenseite.

So, gleiches gilt für den kleinen Switch im anderne Haus, dort entstehen die Losses. Die andere Seite der Richtfunkstrecke schaut genauso aus wie die erste - sprich der "Luftweg" wird da kein Thema bereiten. Schau ich nun aber auf den kleinen Netgear trifft hier sicher das gleiche auf die Management Konsole zu - sie ist nicht performant. Aber ich sehe auch eine Häufung der Pingprobleme über die der Richtfunkstrecke hinaus.

Ich bin "gespannt wie ein Flitzebogen" ob und was die neue Rifu Strecke bringt. Wenn ich keinem Geist nachgelaufen bin sollte es sich ja sofort in den Messungen zeigen. Das ganze werde ich euch dann hoffentlich Morgen um die Zeit zeigen

Vielen Dank für eure Unterstütung - eine Tolle Comunitiy.

Ich hoffe ich konnte mit dem Beitrag dem einen oder anderen eine Idee geben.

So... ich war in der Mittagspause mal an der Antenne.

Alles blöde... Die LiteBeam will nicht mit der Nanostation M5. Ich sehe die Funkstrecke als incompatible Device. Aktuell habe ich die M5 nun im Haus hängen und mit knapp -79dB in Betrieb. Also Internet geht - wenn auch nur semi geil.

Können die 2 einfach nicht miteinander oder muss ich die LiteBeam auf abwärtskompatiblität konfigurieren?

Nein, der AP steht "gegenüber" - hier sind beides Clients

Die Site Survey vom LiteBeam findet auch den Nanostation AP, listet Ihn aber als Inkompatibel auf.

So, die 2te LiteBeam ist oben
bisher läuft alles sehr performant. Ich bin auf Dienstag gespannt, mein erster Homeoffice Tag mit der neuen Technik.

Danach berichte ich.

Irgendwie geht die Strecke in eine art Idlemode - da muss ich mal sehen wie störend das ist und ob ich das abschalten kann/muss.

Speedtest macht mir 200mbit mit der weiten Welt.

Wenn alles läuft stresse ich die Strecke auch mal bissle mit Iperf.

Bad News...

Heute aufm Ipad bei media.ccc was geschaut: 2x geruckelt. Dann Tatort in der Mediathek: ebenso.
Aber das gute: zeitgleich gab es errors im Logfile.

Jan 19 22:11:01 hostapd: ath0: STA 28:xx:xx:xx:xx:xx IEEE 802.11: disassociated

Jan 19 22:11:01 wireless: ath0 Expired node:28:xx:xx:xx:xx:xx

Jan 19 22:11:01 wireless: ath0 Deauthenticated Station 28:xx:xx:xx:xx:xx (Airmax carrier lost)

Jan 19 22:11:52 wireless: ath0 Received auth from 28:xx:xx:xx:xx:xx. Status: Successful (0).

Jan 19 22:11:52 wireless: ath0 Authenticated Station 28:xx:xx:xx:xx:xx (Successful)

Jan 19 22:11:52 wireless: ath0 Sending auth to 28:xx:xx:xx:xx:xx. Status: Successful (0).

SNR geht so mit um die -60dB zu ca. -85dB. Habt Ihr ideen?

Achso: ping ist oft bei 3...4ms über die RiFu Strecke, ab und zu gehts auf 500ms hoch.

Morgen bin ich erstmal im Außendienst - da habt ihr Zeit zu antworten (kein Zwang, nur Spaß)

Danke und Grüße

Ich habe bei Unifi etwas gefunden:

https://help.ui.com/hc/en-us/a…o-Channel-Width-Selection

Nun habe ich mal die Channelwidth von 80MHz auf 40MHz zurück gestellt und teste es.