Neue Firmware 1.2.0

#1

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.

2 Like
Aktuelle Hardware
#2

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?

#3

Ja das ist möglich, habe die Firmware bereits am 14.02. veröffentlicht aber den Forenthread vergessen.

1 Like
#4

Auch die Beta ist seit gestern Abend verfügbar

2 Like
#5

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!

#6

Was passiert denn, wenn Du das hier machst:

opkg install snmp-utils
snmpwalk -v1 -c public localhost
#7

@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!

#8

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.

#9

Naja, ich bin mir nicht “sicher” ob das so richtig ist - aber es hat funktioniert bis zum FW-Update. :slight_smile:
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?

#10

Ich hab das mal kurz so formatiert das man es entspannt lesen kann.

1 Like
#11

@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…

#12

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.

#13

Via dem Zitate Symbol.

#14

@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! ;)

1 Like
#15

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.

#16

br-client hing noch nie im wan. Es lag also genau daran, was ich in Neue Firmware 1.2.0 vermutet hatte.

#17

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?

#18

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:

  • Hat sich etwas verändert mit der neuen Firmware, das dafür verantwortlich sein kann?
  • Was kann das sein, das die hohe Load mitten in der Nacht verursacht?
  • Kann das noch jemand bei seinen Clients beobachten?
  • Gibt es ein ähnlich kompaktes Nachfolgegerät zum WA850RE, das zu empfehlen ist?
#19

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

#20

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…