Experimental 1.2.0
Neue Firmware auf Basis von Gluon 2018.2
Releasenotes wie immer unter https://gluon.readthedocs.io/en/v2018.2/releases/v2018.2.html
Wenn es bis 25.02.2019 keine groben Probleme gibt und niemand hier ein berechtigtes Veto einlegt wird die Firmware in Beta & Stable wandern.
Habe gerade verzweifelt versucht, die 1.2.0 zu installieren, bis ich gemerkt habe, dass die schon seit 5 Tagen auf meinem Knoten drauf ist… Kann das sein?
Ja das ist möglich, habe die Firmware bereits am 14.02. veröffentlicht aber den Forenthread vergessen.
Auch die Beta ist seit gestern Abend verfügbar
Hi,
ich frage meine Nodes ja via SNMP ab und mache nach jedem Update der FW eigentlich ein:
opkg update
opkg install snmpd
Hat bis jetzt soweit immer funktioniert und anschließend lief snmpd wieder.
Bei der aktuellen FW ist dem nicht so, auf einem offloader lauscht snmpd wieder, auf den “normalen” Nodes, also irgendwelche TP-Link Router z.B. meinem ffrn-msu TP-Link TL-WR1043N/ND v2 geht kein snmp mehr.
Hat jemand das selbe Problem bzw. noch besser: Zeit sich das mal anzuschauen und könnte mir helfen?
Vielen Dank im Voraus!
Was passiert denn, wenn Du das hier machst:
opkg install snmp-utils
snmpwalk -v1 -c public localhost@tobox ich frage via IPv6 ab, muss irgendwie wohl an der Firewall liegen, denn:
root@ffrn-msu:~# snmpwalk -v2c -c XXXXXXX udp6:[::1]
liefert mir den gewünschten Output, nur von meinem Server aus geht es (nicht) mehr.
Ich prüfe via PING und SNMP die Adresse, welche auf dem: br-client liegt.
FW-Regel sieht folgendermaßen aus:
config rule 'snmp_wan
option target ‘ACCEPT’
option src ‘wan’
option family ‘ipv6’
option proto ‘udp’
option dest_port ‘161’
option name ‘SNMP’
Vielen Dank im Voraus!
Ich würde mal mit TCPdump schauen, wo die Pakete verloren gehen (bzw. abgelehnt werden). Bist Du sicher, dass
option src ‘wan’
korrekt ist? Willst Du Dich über Freifunk mit dem Knoten verbinden oder über seinen WAN-Anschluss? Dann brauchst Du ggf. noch Freigaben im Internet-Router.
Naja, ich bin mir nicht „sicher“ ob das so richtig ist - aber es hat funktioniert bis zum FW-Update. 
Die Daten hole ich über die „offizielle“ IP vom Freifunk-Node ab. Ist da eventuell neuerdings noch eine FW davor gekommen oder Ähnliches?
Also bei meinem Node ffrn-msu wäre das die IP hier:
http://[2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32]
über die erreiche ich (via map) auch die Status-Seite des nodes.
EDIT:
Die Schnittstelle wird verwendet:
br-client Link encap:Ethernet HWaddr E8:94:F6:68:BC:32 inet6 addr: fe80::ea94:f6ff:fe68:bc32/64 Scope:Link inet6 addr: 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9589742 errors:0 dropped:2 overruns:0 frame:0 TX packets:289424 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:310433184 (296.0 MiB) TX bytes:47178142 (44.9 MiB)
Pakete kommen am Router an:
root@ffrn-msu:~# tcpdump -i any -n host 2001:16b8:2229:8400:d250:99ff:fec1:2d63 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 21:06:10.522106 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:10.522139 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:10.522318 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:10.522354 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:11.520644 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:11.520676 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:11.520855 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:11.520890 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:12.522129 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:12.522161 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:12.522338 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:12.522370 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:13.522382 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:13.522415 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:13.522590 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:13.522624 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:14.523516 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:14.523548 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:14.523727 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:14.523762 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:15.524559 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:15.524591 IP6 2001:16b8:2229:8400:d250:99ff:fec1:2d63.46354 > 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32.161: C="XXXXXXXX" GetNextRequest(25) .1.3.6.1.2.1 21:06:15.524771 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 21:06:15.524805 IP6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 > 2001:16b8:2229:8400:d250:99ff:fec1:2d63: ICMP6, destination unreachable, unreachable port, 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 udp port 161, length 100 24 packets captured 36 packets received by filter 0 packets dropped by kernel
komischerweise auch:
root@ffrn-msu:~# ping6 -I br-client 2001:16b8:2229:8400:d250:99ff:fec1:2d63
PING 2001:16b8:2229:8400:d250:99ff:fec1:2d63 (2001:16b8:2229:8400:d250:99ff:fec1:2d63): 56 data bytes
^C
— 2001:16b8:2229:8400:d250:99ff:fec1:2d63 ping statistics —
9 packets transmitted, 0 packets received, 100% packet loss
von extern aus funktioniert der Ping jedoch:
server@server:/tmp$ ping6 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32
PING 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32(2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32) 56 data bytes
64 bytes from 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32: icmp_seq=1 ttl=54 time=35.0 ms
64 bytes from 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32: icmp_seq=2 ttl=54 time=33.5 ms
64 bytes from 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32: icmp_seq=3 ttl=54 time=33.2 ms
64 bytes from 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32: icmp_seq=4 ttl=54 time=36.0 ms
^C
— 2a01:4f8:171:fcff:ea94:f6ff:fe68:bc32 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 33.277/34.482/36.037/1.130 ms
EDITEDIT:
root@ffrn-msu:~# ip -6 route 2001:16b8:2229:8401::/64 dev br-wan metric 256 2001:16b8:2229:8400::/56 via fe80::e228:6dff:fe75:f182 dev br-wan metric 512 fd00:ca:ff:ef::/64 dev br-wan metric 256 fd00:ca:ff:ef::/64 via fe80::e228:6dff:fe75:f182 dev br-wan metric 512 default via fe80::e228:6dff:fe75:f182 dev br-wan metric 512 unreachable default dev lo metric 65535 error -148 unreachable default dev lo metric -1 error -128 2a01:4f8:171:fcff::ffff dev local-node metric 256 2a01:4f8:171:fcff::/64 dev br-client metric 256 2a01:4f8:171:fcff::/64 dev br-client metric 1024 unreachable fdc7:9965:28c5::/48 dev lo metric 2147483647 error -148 fe80::/64 dev local-node metric 256 fe80::/64 dev br-client metric 256 fe80::/64 dev br-wan metric 256 fe80::/64 dev bat0 metric 256 fe80::/64 dev primary0 metric 256 fe80::/64 dev mesh-vpn metric 256 default via fe80::5054:ff:fe3c:b702 dev br-client metric 512 unreachable default dev lo metric -1 error -128 ff00::/8 dev local-node metric 256 ff00::/8 dev br-client metric 256 ff00::/8 dev br-wan metric 256 ff00::/8 dev bat0 metric 256 ff00::/8 dev primary0 metric 256 ff00::/8 dev mesh-vpn metric 256 unreachable default dev lo metric -1 error -128
sieht mir irgendwie auch merkwürdig aus - unreachable default, verschiedene errors?
Ich hab das mal kurz so formatiert das man es entspannt lesen kann.
@leah vielen Dank dir! Ich hatte eigentlich die
Code Einrückung verwendet
Aber die funktioniert irgendwie nicht immer - wie hast du das nun geschafft? Würde es nächstes Mal auch gerne können…
Also die Routingtabelle sieht schon etwas komisch aus, bei mir ist sie aber prinzipiell genauso.
Das Problem sieht eher nach einem Firewallproblem aus (wobei ich keine Erklärung habe, warum es auf einem Gerät geht und auf dem anderen nicht).
Dein TCPdump zeigt, dass die Pakete ankommen und die Firewall oder der Kernel sagen, dass auf dem SNMP-Port nichts läuft.
Da der Dienst aber lokal funktioniert, muss der SNMP-Port ja offen sein. Mit
netstat -una | grep 161
udp 0 0 0.0.0.0:161 0.0.0.0:*
udp 0 0 :::161 :::*
sehe ich bei mir, dass der Dienst nicht nur auf dem lo Interface läuft, sondern auf allen (0.0.0.0:* bedeutet alle IPv4 Interfaces, :::* bedeutet alle IPv6 Interfaces).
Wenn dann also Destination Unreachable kommt, müsste es eigentlich an der Firewall liegen. Kannst ja mal versuchen, dest = br-client freizugeben.
Beim iptables debugging mache ich manchmal folgendes:
Counter löschen
iptables -Z
Ausgabe sichern
iptables -v -L > vorher.txt
Dann mal versuchen, per SNMP zu kommunizieren, und anschließend wieder:
iptables -v -L > nachher.txt
Dann die beiden Dateien irgendwie vergleichen, z.B.
opkg install diffutils
diff vorher.txt nachher.txt
Manchmal sieht man dann, welche Firewallregeln in der Zwischenzeit zugeschlagen haben. Ggf. mit iptables -t TABELLENNAME für spezielle Tabellen wiederholen.
Via dem Zitate Symbol.
@tobox erst mal ein dickes Lob für die tolle Unterstützung!
Also weshalb es an einem Router funktioniert und an den anderen Nodes nicht mehr ist mir nun klar: den funktionalen frage ich via „LAN“ also das „WAN“ des Nodes direkt ab. Alle anderen frage ich via öffentlicher IPv6 Adresse ab.
Hier der Output von heute:
root@ffrn-msu:~# netstat -una | grep 161
udp 0 0 :::161 :::*
sieht also mal so aus, als würde der snmpd lauschen auf IPv6, so soll das ja auch sein…
iptables gibt mir jedoch zu denken:
Chain zone_wan_input (1 references)
pkts bytes target prot opt in out source destination
174 42108 input_wan_rule all – any any anywhere anywhere /* !fw3: Custom wan input rule chain /
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:bootpc / !fw3: Allow-DHCP-Renew /
0 0 ACCEPT icmp – any any anywhere anywhere icmp echo-request / !fw3: Allow-Ping /
0 0 ACCEPT igmp – any any anywhere anywhere / !fw3: Allow-IGMP /
0 0 ACCEPT igmp – any any anywhere anywhere / !fw3: Allow-IGMP /
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:ssh / !fw3: wan_ssh /
0 0 ACCEPT tcp – any any anywhere anywhere tcp dpt:www / !fw3: wan_http /
0 0 ACCEPT udp – any any anywhere anywhere udp dpt:snmp / !fw3: wan_snmp /*
0 0 ACCEPT all – any any anywhere anywhere ctstate DNAT /* !fw3: Accept port redirections /
174 42108 zone_wan_src_REJECT all – any any anywhere anywhere / !fw3 */
Hier der Node bei dem es tut als Vergleich:
root@ffrn-aufaucon-offloader:~# netstat -una | grep 161
udp 0 0 0.0.0.0:161 0.0.0.0:*
und iptables:
root@ffrn-aufaucon-offloader:~# iptables -v -L | grep snmp
616K 47M ACCEPT udp – any any anywhere anywhere udp dpt:snmp /* !fw3: SNMP */
Weshalb matcht meine alte Regel nicht mehr? Any ideas?
EDIT:
Das Rätsel ist gelöst, das br-client Interface hängt nicht mehr im wan, sondern nun im mesh.
mit der FW-Regel:
config rule ‚mesh_snmp‘
option target ‚ACCEPT‘
option src ‚mesh‘
option proto ‚udp‘
option dest_port ‚161‘
option name ‚mesh-SNMP‘
funktioniert es nun wieder wie gewünscht! ;)
Schön dass Du es hinbekommen hast!
Aber “iptables” ist nur für IPv4, Du musst ip6tables nehmen wenn Du die Firewalleinstellungen für IPv6 sehen willst.
br-client hing noch nie im wan. Es lag also genau daran, was ich in Neue Firmware 1.2.0 - #8 von tobox vermutet hatte.
Naja, jedoch hat es jetzt schon ewig mit:
option src ‘wan’
funktioniert und nun erst seit dem FW-Update tat es auf einmal nicht mehr.
Wie bekomme ich das denn genau heraus, in welcher src das jeweilige interface hängt?
Ich weiß nicht, ob das zur neuen Firmware passt oder ob das ein eigener Thread Wert ist:
Ich habe mir diesen Node ( HD-Neuenheim-Auszeit-01) nach Hause geholt, da mir im Café aufgefallen ist, dass er auf der Karte als online angezeigt wird, aber mehrfach die Minute die WLAN-Verbindung zu meinem Client (Android Smartphone) verloren hat. Aufgefallen ist mir ein unregelmäßiges Blinken der Aktivitätsanzeige und eine hohe Load von über 2,5.
Ich habe ihn nun bei mir zu Hause angeschlossen. Nach anfänglich hoher Load funktionierte er einwandfrei. Um 03:45 Uhr heute Nacht ist eine kleine Delle bei der Uptime zu sehen. Von da an steigt die Load von 0,49 auf 2 und mehr an. Schön im Grafana zu sehen: http://stats.ffrn.de/d/000000002/nodes?refresh=1m&orgId=1&var-Node=HD-Neuenheim-Auszeit-01&from=now-6h&to=now-1m
Mal davon abgesehen, das das Gerät wie ein wr841 zu schwach auf der Brust ist:
Kann es sein, dass sich am 10.03. irgendetwas verändert hat? Ich habe mir die Grafana Statistiken von mehreren TL-WA850 angeschaut und die sehen bei der Load und der RAM-Auslastung ähnlich aus: Vor dem 10.03. liegt die Load bei unter 0.5, danach Spitzen bis zu 3.5:
http://stats.ffrn.de/d/000000002/nodes?refresh=1m&orgId=1&var-Node=HD-Neuenheim-Auszeit-01&from=now-30d&to=now-1m
http://stats.ffrn.de/d/000000002/nodes?var-Node=HD-Mobil-001-temp&theme=dark&refresh=1m&orgId=1&from=now-30d&to=now-1m
Ich habe eine Richtfunkstrecke mit zwei CPE 210 in der Gausstraße. Auch hier kann ich beobachten, dass seit der 1.2 der load oft sehr hoch ist, obwohl die Ramauslastung z.B noch okay ist. Mir ist klar, dass die CPE 210 wie die 841 eben auch wenig Ram haben, aber die alte Firmware hat das eben besser hingekriegt.Bildschirmfoto.pdf (331,2 KB)
Habt ihr eine Idee, woran es liegt. Ich krieg da jetzt schon langsam Streß mit den Jungs aus der Gausstraße, die verstehen da wenig Spaß…
Ich habe den Router vor 20 min neu gestartet, und der geht gleich wieder in die Überlastung. Roam okay, Auslastung bei 2,5. Tendenz steigend. Internet dadurch unbenutzbar.
Vielleicht kann @leah ein firmware downgrade auf dem LA-RW-GSS001 und 2 machen? Sie hat einen SSH Key auf den Routern liegen. Ich kann das leider nicht remote, weiß nicht , wie es geht…