Mesh-links gehen komplett verloren


#1

Eine Rocket M2 hat vor ein paar Tagen alle WiFi-Meshlinks verloren. Ursprünglich war ich davon ausgegangen, dass die Ursache in der Umstellung auf eine experimentelle Firmware mit Gluon 2018.1 lag. Das Problem zeigt sich aber völlig unabhängig von Reboots und besteht auch nach einem Downgrade auf 2017.1.8 mittels sysupgrade -n

Symptome:

  • Es sind alle Meshlinks verloren gegangen
  • Clients können sich zum Teil noch verbinden, die Anzahl ist aber stark gefallen
  • Benachbarte Nodes ‘hören’ den Knoten mit unverändertem Signalpegel (siehe Bild: Statussseite eines benachbarten Knotens: ‘e2:b8:f7:63:36:31’ ist die Rocket M2.
  • iw mesh0 scan funktioniert – EDIT: liefert ein nicht erwartetes Ergebnis, siehe übernächsten Beitrag

image

batctl td mesh0 liefert

18:43:33.561106 BAT 7e:be:64:3c:5c:63: OGM IV via neigh e2:b8:f7:63:36:31, seq 419674681, tq 186, ttl 47, v 15, flags [...], length 112, tvlv_len 28
	TVLV TTv1: OGM DIFF [.] ttvn=83 vlan_num=2 entry_num=0
		VLAN ID 0, crc 0x951d0073
		VLAN ID -1, crc 0xca12823e
	TVLV DATv1: enabled
18:43:33.661131 BAT 0e:0b:19:4b:67:7b: OGM IV via neigh e2:b8:f7:63:36:31, seq 3897019016, tq 211, ttl 48, v 15, flags [...], length 52, tvlv_len 28
	TVLV TTv1: OGM DIFF [.] ttvn=39 vlan_num=2 entry_num=0
		VLAN ID 0, crc 0xdbcba2a5
		VLAN ID -1, crc 0x7da3a74e
	TVLV DATv1: enabled
18:43:33.901016 BAT c2:b0:8a:71:44:1b: OGM IV via neigh e2:b8:f7:63:36:31, seq 2202760409, tq 182, ttl 47, v 15, flags [...], length 360, tvlv_len 36
	TVLV TTv1: OGM DIFF [.] ttvn=163 vlan_num=2 entry_num=0
		VLAN ID 0, crc 0xcdf0e274
		VLAN ID -1, crc 0x0f31a99e
	TVLV DATv1: enabled

Karte:
https://karte.freifunk-muensterland.de/map36/#!v:m;n:6872512a2dbb

Erweiterte Statistik
https://grafana.freifunk-muensterland.de/d/000000021/advanced-node-stats?refresh=30s&orgId=1&var-node=6872512a2dbb&from=now-7d&to=now


#2

ich gehe davon aus, dass ein simples “wifi” das Problem nicht (zumindest) kurzzeitig fixed?


#3

Das ist korrekt.

Eben gesehen, dass iw dev mesh0 scan keine Geräte auf Kanal 1 findet.

root@ffwaf-eloh-alleestr-2:~# iw dev mesh0 scan | grep primary
		 * primary channel: 8
		 * primary channel: 11
		 * primary channel: 10
		 * primary channel: 11
		 * primary channel: 11
		 * primary channel: 11
		 * primary channel: 13
		 * primary channel: 6
		 * primary channel: 6
		 * primary channel: 6
		 * primary channel: 6
		 * primary channel: 11
		 * primary channel: 11
		 * primary channel: 6
		 * primary channel: 6
		 * primary channel: 11
		 * primary channel: 13

EDIT: Hier noch ein weiterer Auszug aus iw dev mesh0 scan von einem möglichen Mesh-Partner

BSS 70:4c:a5:40:ee:73(on mesh0)
	TSF: 251681027 usec (0d, 00:04:11)
	freq: 2472
	beacon interval: 100 TUs
	capability: ESS (0x0421)
	signal: -83.00 dBm
	last seen: 10 ms ago
	Information elements from Probe Response frame:
	SSID: Freifunk
	HT capabilities:
		Capabilities: 0x18d
			RX LDPC
			HT20
			SM Power Save disabled
			TX STBC
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
			No DSSS/CCK HT40
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: No restriction (0x00)
		HT TX/RX MCS rate indexes supported: 0-15
	HT operation:
		 * primary channel: 13
		 * secondary channel offset: no secondary
		 * STA channel width: 20 MHz

#4

Ich vermute, der RX-Amp ist schlicht hardwäremäßig defekt.
Und da das Gerät auch keine zweite Antenne hat, um das “stillschweigend” zu kaschieren: fällt halt sofort auf.


#5

Das verstehe ich noch nicht, die Rocket hat doch zwei Antennenanschlüsse?

Vielen Dank für die Einschätzung, ich werde das Geräte auswechseln.


#6

sorry, ich war gedanklich bei der Bullet…

aber wenn beide Antennen betroffen sind: Dann evtl. ein onboard VR, der die nötige Spannung nimmer liefert.
Oder einer der LNAs hat einen Kurzschluss und “zieht” so viel Strom, dass der andere auch nix mehr bekommt.


#7

Passt das dazu, dass iw dev mesh0 scan | grep signal noch die üblichen Werte liefert?


#8

Fahre doch doch mal ein Recovery auf Stock-FW. Vielleicht repariert das ja die ART, falls da etwas angeschlagen sen sollte. Danach dann wieder ein Gluon drauf.


#9

Ich habe das Gerät gerade durch einen UniFi AC Mesh getauscht - exakt das gleiche Phänomen. Es muss sich m. E. um eine Störquelle handeln.

Könnte es das PoE-Netzteil sein? Der Knoten hängt via PoE-pass trough an einer CPE210 mit Stock-FW. Die CPE selber kann ich ausschließen aber ein zweites Netzteil hatte ich nicht dabei


#10

@jotzt, das Problem haben wir mit den Rockets am Hawerkamp auch ständig. Bei uns hilft aber ein Neustart.

Die Rockets haben irgendwie massive Probleme. Die Ausfallraten sind extrem hoch und dann noch das Problem mit den abreißenden Links. Das hochgelobte Gerät und unser Standard für Außenmesch ist in seinem Ansehen so schnell abgestürzt wie vorher nur die CPE210 ;).

Ich würde Originalfirmware draufmachen und wenn es damit nicht geht, ist das ein Garantiefall. Wäre dann glaube ich schon der dritte oder vierte in einem Jahr alleine hier im Münsterland.


#11

Das Problem bestand nicht dauerhaft, es ist plötzlich aufgetreten (am 23.07 gegen 17/18 Uhr) und es ist unabhängig vom Gerät. Wie oben beschrieben habe ich die Rocket gegen einen UniFi AC Mesh getauscht und die Situation ist die gleiche.
https://grafana.freifunk-muensterland.de/d/000000021/advanced-node-stats?orgId=1&var-node=6872512a2dbb&from=1532197800912&to=1532457000912


#12

Hallo.
Falls du noch ein Gerät mit orig. Firmware zur Hand hast: Ubiquiti-Geräte mit AirOs haben doch das nette Feature “AirView”, bei dem man wie mit einem Spektrumanalyzer das Frequenzband abscannen kann. Falls sich ein neuer Störer in der Nachbarschaft eingenistet hat sollte man diesen damit evtl. sehen können.


#13

Was auch verdächtig ist: Von ca. 50 WLANs, die mir wavemon anzeigt, werden genau null auf Kanal 1 gefunden.


#14

Gerade die Rocket noch einmal getestet, der geht es prächtig.


#15

Es könnte auch eine “Nicht-Wlan-Störung” sein, z.B. ein HDMI-Link.
Oder aber ein Spielkind prügelt sich den Kanal frei mit einem Deauth-Script auf allen “feindlichen” SSIDs.


#16

Die Störquelle scheint sich verabschiedet zu haben, seit heute Nacht ist alles wieder normal.