Knoten mit 4040 stört(e) WLAN .... evtl

'nabend,

ich weiß natürlich dass es viel zu spät ist um jetzt noch was rauszufinden, aber ich war leider das ganze Wochenende unterwegs und konnte nur die Holzhammermethode anwenden:

Ich habe ja seit einigen Tagen einen Knoten mit einer 4040 hier stehen. Letzten Donnerstag Abend hatte ich das Problem, dass mein lokales WLAN (Fritz 7590) total träge war. Nachdem das am Freitag morgen immer noch der Fall war, habe ich die 4040 ihres Stroms und Netzwerk beraubt (das war die letzte Änderung die ich am ganzen System gemacht hatte). Danach war es schlagartig besser.

Jetzt habe ich den Knoten vorhin wieder ans Netz gehängt und aktuell ist alles völlig OK. Sollte dieses Verhalten noch mal auftreten, was sollte ich dann als erstes nachgucken? Ich komme per SSH auf den Knoten.

Zieh doch im Fall der Fälle mal das Netzwerkkabel und lasse den am Strom und schau unmittelbar danach ob es besser ist. Wenn nicht wäre meine „Vermutung“ ein WLAN Problem.
Ansonsten müsste man netzwerktechnisch weiterschauen…

Du kannst dir ja optional auch vor dem „Cut“ die Logs per SSH anschauen auf dem Router und danach obigen Weg versuchen.

Ich setze auf den Klassiker…
Hast du im Konfigmode Mesh on WAN aktiviert?

Gruß Marius

1 „Gefällt mir“

@corny456 nicht das ich wüsste.

root@ff-Buldern-J01:~# uci show | grep mesh_wan.disabled
network.mesh_wan.disabled='1'
root@ff-Buldern-J01:~#

Ist es das hier?

Jup. Das ist aber aus so wie es sollte.

Läuft alles :-). Habe mir das gerade alles noch mal ein wenig angeschaut. Logread schreibt allerdings irgendeinen Fehler bez MTU heute tagsüber, ich habe mal das drumherum auch mit kopiert. Soll/muss ich da irgendwas tun?

Wed Aug 28 15:10:01 2019 user.notice tunneldigger-watchdog: Process-Pid does not match with pid-File.
Wed Aug 28 15:10:01 2019 user.notice tunneldigger-watchdog: Restarting Tunneldigger.
Wed Aug 28 15:10:01 2019 daemon.warn td-client: Got termination signal, shutting down tunnel...
Wed Aug 28 15:10:01 2019 daemon.notice netifd: Network device 'mesh-vpn' link is down
Wed Aug 28 15:10:01 2019 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity loss
Wed Aug 28 15:10:01 2019 kern.info kernel: [147970.359367] batman_adv: bat0: Interface deactivated: mesh-vpn
Wed Aug 28 15:10:01 2019 kern.info kernel: [147970.401035] batman_adv: bat0: Removing interface: mesh-vpn
Wed Aug 28 15:10:01 2019 daemon.notice netifd: Interface 'mesh_vpn' is disabled
Wed Aug 28 15:10:02 2019 daemon.info td-client: Performing broker selection...
Wed Aug 28 15:10:03 2019 daemon.debug td-client: Broker usage of domaene12-a.servers.freifunk-muensterland.net:20012: 6207
Wed Aug 28 15:10:04 2019 daemon.debug td-client: Broker usage of domaene12-a.servers.freifunk-muensterland.de:20012: 6207
Wed Aug 28 15:10:12 2019 daemon.info td-client: Selected domaene12-a.servers.freifunk-muensterland.de:20012 as the best broker.
Wed Aug 28 15:10:14 2019 daemon.info td-client: Tunnel successfully established.
Wed Aug 28 15:10:14 2019 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Wed Aug 28 15:10:14 2019 daemon.notice netifd: Network device 'mesh-vpn' link is up
Wed Aug 28 15:10:14 2019 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Wed Aug 28 15:10:14 2019 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Wed Aug 28 15:10:14 2019 daemon.notice netifd: Interface 'mesh_vpn' is now up
Wed Aug 28 15:10:14 2019 kern.info kernel: [147983.517309] batman_adv: bat0: Adding interface: mesh-vpn
Wed Aug 28 15:10:14 2019 kern.info kernel: [147983.517387] 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.
Wed Aug 28 15:10:14 2019 kern.info kernel: [147983.523624] batman_adv: bat0: Interface activated: mesh-vpn
Wed Aug 28 15:10:14 2019 user.notice firewall: Reloading firewall due to ifup of mesh_vpn (mesh-vpn)
Wed Aug 28 15:11:01 2019 user.notice gluon-offline-ssid: TQ is 29, SSID is Freifunk, change to FF_OFFLINE_ff-Buldern-J01
Wed Aug 28 15:11:01 2019 user.notice gluon-offline-ssid: TQ is 29, SSID is Freifunk, change to FF_OFFLINE_ff-Buldern-J01
Wed Aug 28 15:11:01 2019 daemon.notice hostapd: client0: AP-STA-DISCONNECTED 2c:f0:a2:61:a9:6f
Wed Aug 28 15:12:00 2019 user.notice gluon-offline-ssid: TQ is 75, SSID is FF_OFFLINE_ff-Buldern-J01, change to Freifunk
Wed Aug 28 15:12:00 2019 user.notice gluon-offline-ssid: TQ is 75, SSID is FF_OFFLINE_ff-Buldern-J01, change to Freifunk
1 „Gefällt mir“

Was war denn nun die Ursache?

Ich habe keine Ahnung :frowning: Läuft ja bis jetzt alles. Wenn es noch mal wieder auftritt versuche ich auf die Kiste zu kommen und eine logread-Ausgabe zu bekommen.