Ok, wäre aber schon sinnvoll, wenn ihr euch da nochmal Gedanken zu machen würdet. Warum ?
Viele der Knoten, die über längere Zeit offline sind, sind es vermutlich auch deshalb, weil die/der
Knotenbetreiberin/betreiber gar nicht wissen, dass die Knoten nicht laufen oder vermutlich sogar
denken, dass ihr euch darum kümmern würdet, wenn bei ihnen was nicht läuft.
Was meinen Knoten betrifft: Nach erneuten manuellen Einspielen der 1.x Firmware läuft der Knoten,
komisch nur, dass der Router nicht wieder versucht die 2.x Firmware einzuspielen, obwohl ich an der
Konfig sonst nichts geändert habe und viele andere Knoten der Domäne 05 jetzt mit Firmware 2.x laufen.
In der Firmware sind jetzt nur noch die DNS Adressen der Gateways eingetragen und keine IP’s mehr. Daher gehe ich davon aus das der Knoten die DNS nicht auflösen kann und deswegen nicht hoch kommt.
Wie gesagt hab ich nach dem Unfall in Domäne 07 die Updates gestoppt. Dadurch zieht dein Knoten sich die 2.1.0 nicht mehr…
In D39 Ostbevern (Großraum Telgte, daher werfe ich das mal in diesen Thread) sind mit zeitlicher Nähe zum FW-Update ebenfalls einzelne Knoten ausgefallen. Anscheinend vornehmlich Mesh-only Knoten ohne VPN-Verbindung. Z.B. http://[2a03:2260:115:3900:822a:a8ff:fe68:4ea6]/
Da es recht aufwendig ist, da dran zu kommen würde ich gerne vorher abklären, was ich tun kann.
Neustart
aktuelle FW manuell aufspielen
???
Möglicherweise habe ich einen Key für SSH auf den Kisten. Denke ich richtig, dass ich damit die neue FW über WLAN aufspielen könnte, indem ich in die Nähe des Knotens gehe, wenn ich die IPv6 Adresse kenne? Dann wäre es einfacher, weil ich nicht so gut physikalisch an die Geräte komme…
Das Gerät ist via WDS angebunden, bis gestern lief es noch. Jetzt meldet es sich mit offline-SSID. Zum WDS-Gerät (CPE210) kann ich mich verbinden. Der UAP ist jedoch im lokalen Netz nicht mehr zu erreichen.
Ich hole den Eintrag doch wieder raus. Nach einem sysupgrade -n ist die Verbindung zur Supernode jetzt einwandfrei, Clients bekommen aber keine Verbindung. Login via SSH geht, DNS funktioniert auch.
batctl gwl
Gateway (#/255) Nexthop [outgoingIF]: advertised uplink bandwidth ... [B.A.T.M.A.N. adv 2016.2, MainIF/MAC: primary0/a6:e8:de:d9:d9:5b (bat0)]
62:ec:98:0e:20:31 (221) 2a:f8:ad:90:c0:aa [ mesh-vpn]: 1024.0/1024.0 MBit
=> 2a:f8:ad:90:c0:aa (250) 2a:f8:ad:90:c0:aa [ mesh-vpn]: 1024.0/1024.0 MBit
traceroute 8.8.8.8 [OK]
logread:
Sat Dec 10 16:18:30 2016 kern.info kernel: [ 8193.900000] br-client: Multicast hash table chain limit reached: bat0
Sat Dec 10 16:53:09 2016 kern.info kernel: [10273.480000] br-client: Multicast hash table chain limit reached: bat0
Sat Dec 10 16:53:09 2016 kern.warn kernel: [10273.490000] br-client: Cannot rehash multicast hash table, disabling snooping: bat0, 208, -22
Sat Dec 10 17:18:21 2016 user.notice firewall: Reloading firewall due to ifupdate of wan6 (br-wan)
Sat Dec 10 17:18:22 2016 user.notice firewall: Reloading firewall due to ifupdate of wan6 (br-wan)
Sat Dec 10 17:18:38 2016 daemon.warn td-client: Tunnel has timed out, closing down interface.
Sat Dec 10 17:18:38 2016 daemon.notice netifd: Network device 'mesh-vpn' link is down
Sat Dec 10 17:18:38 2016 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity loss
Sat Dec 10 17:18:38 2016 kern.info kernel: [11802.420000] batman_adv: bat0: Interface deactivated: mesh-vpn
Sat Dec 10 17:18:38 2016 kern.info kernel: [11802.460000] batman_adv: bat0: Removing interface: mesh-vpn
Sat Dec 10 17:18:38 2016 daemon.err td-client: Connection to domaene36-b.servers.freifunk-muensterland.de lost.
Sat Dec 10 17:18:38 2016 daemon.notice netifd: Interface 'mesh_vpn' is disabled
Sat Dec 10 17:18:38 2016 daemon.info td-client: Performing broker selection...
Sat Dec 10 17:18:38 2016 daemon.err td-client: Failed to resolve hostname 'domaene36-a.servers.freifunk-muensterland.net'.
Sat Dec 10 17:18:38 2016 daemon.err td-client: Failed to resolve hostname 'domaene36-b.servers.freifunk-muensterland.net'.
Sat Dec 10 17:18:39 2016 daemon.debug td-client: Broker usage: 0xacad20 domaene36-b.servers.freifunk-muensterland.de 8767
Sat Dec 10 17:18:39 2016 daemon.debug td-client: Broker usage: 0xac65d0 domaene36-a.servers.freifunk-muensterland.de 9279
Sat Dec 10 17:18:55 2016 daemon.info td-client: Reinitializing tunnel context.
Sat Dec 10 17:18:55 2016 daemon.info td-client: Reinitializing tunnel context.
Sat Dec 10 17:18:55 2016 daemon.err td-client: Failed to resolve hostname 'domaene36-a.servers.freifunk-muensterland.net'.
Sat Dec 10 17:18:55 2016 daemon.err td-client: Failed to resolve hostname 'domaene36-b.servers.freifunk-muensterland.net'.
Sat Dec 10 17:19:00 2016 daemon.info td-client: Selected domaene36-b.servers.freifunk-muensterland.de:20036 as the best broker.
Sat Dec 10 17:19:00 2016 user.notice gluon-offline-ssid: TQ is 0, SSID is Freifunk, change to FF_OFFLINE_ffwaf-el...henweg-1
Sat Dec 10 17:19:01 2016 daemon.info td-client: Tunnel successfully established.
Sat Dec 10 17:19:01 2016 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Sat Dec 10 17:19:01 2016 daemon.notice netifd: Network device 'mesh-vpn' link is up
Sat Dec 10 17:19:01 2016 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Sat Dec 10 17:19:01 2016 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Sat Dec 10 17:19:01 2016 kern.info kernel: [11825.420000] batman_adv: bat0: Adding interface: mesh-vpn
Sat Dec 10 17:19:01 2016 kern.info kernel: [11825.420000] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1364) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Sat Dec 10 17:19:01 2016 kern.info kernel: [11825.450000] batman_adv: bat0: Interface activated: mesh-vpn
Sat Dec 10 17:19:01 2016 kern.info kernel: [11825.450000] batman_adv: bat0: no_rebroadcast: Changing from: disabled to: enabled
Sat Dec 10 17:19:01 2016 daemon.notice netifd: Interface 'mesh_vpn' is now up
Sat Dec 10 17:19:06 2016 daemon.info dnsmasq[1661]: reading /tmp/resolv.conf.auto
Sat Dec 10 17:19:06 2016 daemon.info dnsmasq[1661]: using local addresses only for domain lan
Sat Dec 10 17:19:06 2016 daemon.info dnsmasq[1661]: using nameserver 2a03:2260:115:3600::3#53
Sat Dec 10 17:19:06 2016 daemon.info dnsmasq[1661]: using nameserver 2a03:2260:115:3600::2#53
Sat Dec 10 17:21:00 2016 user.notice gluon-offline-ssid: TQ is 75, SSID is FF_OFFLINE_ffwaf-el...henweg-1, change to Freifunk
Also…
Es scheint so, als gibt es ein Problem mit 2016.2.1, zumindest was meinen UAP outdoor+ betrifft. Nach dem Downgrade auf 2016.1.5 läuft wieder alles tip top.
Fazit: 2016.1.5+1.1.5 ist die letzte Version, mit der der UAP einwandfrei läuft. Ggf. liegt es auch nicht am UAP sondern an der Funkbrücke.
Mit der alten FW bei 100 %. Bei der neuen gab es wohl Schwankungen, allgemein aber auch > 90 %. Genaueres müsste ich noch in Erfahrung bringen. Die UAPs in der DOM 38 laufen ohne Probleme, daher vermute ich, dass es tendenziell an der Funkbrücke liegt.
Überhaupt keine WLAN-Verbindung, mein S3 meldete „Authentifizierungsfehler“ (sic!). Die SSID verschwindet regelmäßig.
Da die UAPs in der DOM 38 laufen, werde ich mich jetzt als erstes auf den Tunndeldigger konzentrieren. Wie kann ich das am besten debuggen? Via logread?
UPDATE: Es scheint ein DNS-Problem zu geben. Nur warum?
Sat Dec 10 17:18:55 2016 daemon.err td-client: Failed to resolve hostname 'domaene36-a.servers.freifunk-muensterland.net'.
Sat Dec 10 17:18:55 2016 daemon.err td-client: Failed to resolve hostname 'domaene36-b.servers.freifunk-muensterland.net'.
ist, das ist normal da die .net Domäne bei uns noch nicht eingerichtet ist.
bezieht der Knoten via DHCP eine IP oder hast du dem eine Feste gegeben?
Falls feste IP: DNS Server mit angegeben? Es gab mal einen Gug in einer Gluon Version das auch wenn der DNS eingetragen wurde, dieser nicht übernommen / gespeichert wurde…
Sat Nov 12 06:35:36 2016 daemon.info dnsmasq[1315]: reading /var/gluon/wan-dnsmasq/resolv.conf
Sat Nov 12 06:35:36 2016 daemon.info dnsmasq[1315]: using nameserver fd00::9ec7:a6ff:fe67:2e23#53
Sat Nov 12 06:35:36 2016 daemon.info dnsmasq[1315]: using nameserver 192.168.178.1#53
[Edit] wirklich schlau bin ich jetzt nicht daraus geworden. Womöglich lag es auch am Gateway. Der aktuelle GW performt jedenfalls prächtig. Die
Laufzeiten für Pings nach Roubaix liegen nur 5 ms über denen aus dem privaten Netz, manchmal sogar darunter…
Wie weiter oben berichtet gibt es in Ostbevern zwei UAP Outdoor+, die seit dem Firmwareupdate offline sind. Beide haben keinen VPN-Uplink, sondern erweitern nur das Netz via Mesh.
Jetzt habe ich mir einen näher angeschaut: https://service.freifunk-muensterland.de/maps/map39/#!v:m;n:802aa8684ea6
Mit dem ist aber alles in Ordnung. Ist auf neuestem FW-Stand und meshed korrekt, wenn ich ihn in die Nähe eines anderen FF-Routers bringe. Aber mit seinem eigentlichen Partner will er nicht meshen: https://service.freifunk-muensterland.de/maps/map39/#!v:m;n:a42bb0d89b44
Der hat ebenfalls neueste FW gezogen und wurde mehrmals neu gestartet.
Die beiden wollen sich nicht finden. Auf der Statusseite des letzteren wird bei “mesh0” eine MAC-Adresse angezeigt, aber die wird nicht wie gewohnt zu einem Namen aufgelöst:
http://[2a03:2260:115:3900:a62b:b0ff:fed8:9b44]
