Problem V 1.14 #125

harry-refrath · 2022-12-29T17:32:34Z

Hallo Jens,
zur Info.
nach Installation gestern der V1.14 lief Anfangs alles wie es soll. das Logg File zeigte alles korrekt an .
Nach verlassen des hauses wurde mir aber heute morgen keine Abwesenheit der Geräte angezeigt. Das Loogfile zeigt auch die Geräte nicht als abwesend auf, die werden im logg File nicht aufgelistet. Nach Downgrade auf 1.1 geht es wieder

Sie beiliegende Datei

schöne Grüße Harald
Fehler.pdf

mbhomie007 · 2022-12-29T21:29:23Z

Wie sieht die Addon-Konfiguration aus?
Bitte Screenshots einfügen und keine PDFs.
Welche Hardware nutzt du?

harry-refrath · 2022-12-30T07:11:18Z

Hallo

die zwei Screenshot Ausschnitte sind nur als PDF zusammengefasst und gespeichert (?) , der obere Teil ist das Logfile und der untere die Konfiguration, oder was fehlt noch ?
Zu erkennen ist das in der Konfiguration 3 Geräte eingerichtet sind die aber im Log File nicht mehr aufgeführt sind. Nach Installation wurden die "ursprünglich" angezeigt
Am nächsten Tag waren die weg...
CCU 3, original Hardware mit neuster Firmware, FB 7590 mit OS 7.50

jens-maus · 2022-12-30T07:20:04Z

Screenshots sind Bilder und Bilder gehören nicht in ein pdf verpackt, egal wo. Und hier schon gar nicht. Die gehören hier direkt hochgeladen damit man da nix runterladen muss und unnötig sein system mit sowas zumüllt… man verpackt die ja auch nicht in ein word dokument oder ähnliches…

harry-refrath · 2022-12-30T07:28:03Z

verstanden...

Piri22 · 2023-01-01T18:23:06Z

Auch bei mir massive Probleme (raspberrymatic der neusten Version auf Proxmox 7.3 auf Intel NUC).

Das Log sagt:

== So 1. Jan 19:08:50 CET 2023 ===================================
Querying FRITZ! devices: 192.168.168.1
== So 1. Jan 19:08:40 CET 2023 ===================================
Querying FRITZ! devices: 192.168.168.1
== So 1. Jan 19:08:30 CET 2023 ===================================

Rückschritt auf Version 1.13: das Problem bleibt bestehen (auch nach Neustart der CCU).
Rückschritt auf Version 1.11: alles läuft normal (nach Neustart der CCU).

Das selbe Problem übrigens, wenn ich hm_pdetect direkt unter Linux laufen lassen.
Wie kann ich unter Linux eine frühere Version per wget bekommen?

Die Einstellungen:

# IP address/hostname or https:// URI and login credentials of
# FRITZ! devices (e.g. FRITZ!Box or FRITZ!repeater)
HM_FRITZ_IP="192.168.168.1 192.168.168.10 192.168.168.11"
HM_FRITZ_USER="CCU"
HM_FRITZ_SECRET=XXXXXXXXXXX"

# IP address/hostname of CCU device (CCU1, CCU2, RaspberryMatic)
HM_CCU_IP="192.168.168.40"

# used names within variables
HM_CCU_PRESENCE_USER="Nutzer"
HM_CCU_PRESENCE_GUEST="Gast"
HM_CCU_PRESENCE_NOBODY="Niemand"
HM_CCU_PRESENCE_PRESENT="anwesend"
HM_CCU_PRESENCE_AWAY="abwesend"
HM_CCU_PRESENCE_LIST="list"
HM_CCU_PRESENCE_STR="string"

# Name of the CCU variable prefix used
HM_CCU_PRESENCE_VAR="HOME_PRESENCE_Anwesenheit"

# number of seconds to wait between iterations
# (will run hm_pdetect in an endless loop)
HM_INTERVAL_TIME="15"

# maximum number of iterations if running in interval mode
# (default: 0=unlimited)
HM_INTERVAL_MAX="0"

# where to save the process ID in case hm_pdetect runs as
# a daemon
HM_DAEMON_PIDFILE="/tmp/hm_pdetect.pid"

# Processing logfile output name
# (default: no output)
#HM_PROCESSLOG_FILE="/var/log/hm_pdetect.log"
HM_PROCESSLOG_FILE="/opt/hm_pdetect/hm_pdetect.log"

# maximum number of lines the logfile should contain
# (default: 500 lines)
HM_PROCESSLOG_MAXLINES="500"

# MAC/IP addresses of user devices
HM_USER_LIST=([Andreas]='xxxxxxxxxxxx' [Katja]='xxxxxxxxxxxx' 

# Specify mode of HM_KNOWN_LIST variable setting
#
# guest - apply known ignore list to devices in a dedicated
#         guest WiFi/LAN only (requireѕ enabled guest WiFi/LAN in
#         FRITZ! device)
# all   - apply known ignore list to all devices
# off   - disabled guest recognition
HM_KNOWN_LIST_MODE="off"

# MAC/IP addresses of known devices that should be ignored from
# guest device recognition
HM_KNOWN_LIST=""

jens-maus · 2023-01-11T09:22:41Z

Auch bei mir massive Probleme (raspberrymatic der neusten Version auf Proxmox 7.3 auf Intel NUC).

Was hast du denn als Abfrageinterval eingestellt in der Konfigurationsseite von hm_pdetect?

Das Log sagt:

== So 1. Jan 19:08:50 CET 2023 ===================================
Querying FRITZ! devices: 192.168.168.1
== So 1. Jan 19:08:40 CET 2023 ===================================
Querying FRITZ! devices: 192.168.168.1
== So 1. Jan 19:08:30 CET 2023 ===================================

Weil das sieht nach 10 Sekunden aus. Vielleicht dauert das Login auf deine Fritz-Geräte einfach zu lange und deshalb bricht da was ab.

Das selbe Problem übrigens, wenn ich hm_pdetect direkt unter Linux laufen lassen. Wie kann ich unter Linux eine frühere Version per wget bekommen?
# MAC/IP addresses of user devices
HM_USER_LIST=([Andreas]='xxxxxxxxxxxx' [Katja]='xxxxxxxxxxxx' 

Hier fehlt die schließende Klammer ")" am Schluss der Zeile.

Und wenn das nicht hilft dann einfach mal in das .sh ein paar debug statements (echo XXXX) einbauen um zu schauen an welcher Stelle er denn hängen bleibt bzw. nicht weiter macht. Für mich sieht das danach aus das er bei dir irgendwo im Login-Prozess zu den FRITZ Geräten hängen bleibt.

Piri22 · 2023-01-11T10:10:12Z

Dass am Ende von HM_USER_LIST=([Andreas]='xxxxxxxxxxxx' [Katja]='xxxxxxxxxxxx' eine Klammer (zu) fehlte, war nur ein Übermittlungsfehler.
Aber die 10 Sekunden waren wohl tatsächlich zu kurz. Ich habe nun die standardmäßigen 15 eingestellt und es scheint wieder alles zu laufen.
Ich behalte das im Auge

Piri22 · 2023-01-25T06:10:15Z

Soeben musste ich feststellen, dass hm_pdetect, sowohl als CCU Addon, als auch als Standalone Version unter Linux, wieder den Betrieb eingestellt hat. Es kommt mal wieder nichts mehr außer:
"= Mi 25. Jan 07:07:00 CET 2023 ===================================
Querying FRITZ! devices: 192.168.168.1
== Mi 25. Jan 07:06:30 CET 2023 ===================================
Querying FRITZ! devices: 192.168.168.1
== Mi 25. Jan 07:06:00 CET 2023 ===================================
Querying FRITZ! devices: 192.168.168.1
== Mi 25. Jan 07:05:29 CET 2023 ==================================="

Ich habe daraufhin das Abfrageintervall auf 30 Sekunden hochgesetzt, ohne Erfolg.
Einziger Unterschied zu "vorher": ich habe vor einigen Tagen meine Fritz!Box (6690cable) auf FritzOS 7.50 gebracht. Das kann primär aber nicht die Ursache sein, da hm_pdetect erst seit gestern Nacht oder heute Morgen nicht mehr funktioniert

rolbx · 2023-02-14T22:55:23Z

Bei mir tritt das gleiche Problem unter Fritz!OS 7.51 auf. Aber NUR wenn ein Smartphone per Wireguard mit der Fritzbox verbunden ist erhalte ich im Log "Querying FRITZ! devices"

Edit: Habe die Wireguard-Verbindung nochmal manuell eingerichtet und einen anderen IP Bereich zugewiesen. Jetzt funktioniert die Abfrage.

VG
Robby

Piri22 · 2023-02-15T11:39:28Z

Ja, die Wireguardverbindung scheint es nicht (alleine?) zu sein.
Mein iPhone ist derzeit über Wireguard verbunden und hm_pdetect 1.14 läuft klaglos.

harry-refrath · 2023-02-15T17:56:50Z

unter 1.14 funktioniert bei mir mit dem aktuellen IOS der FB auch alles ohne Probleme. Ich nutze auch WireGuard beim IPhone.
Was ich hatte ist das bei den eingerichteten Geräten teilweise bei den IP Adressen,die den IPhone zugeordnet wurden, trotz Anwesenheit auf abwesend im Logfile angezeigt wurde. Statt IP habe ich dann die Mac Adresse eingetragen und seitdem funktioniert alles bei der Version 1.14

Browserlauser · 2023-02-16T18:50:51Z

Hallo,

ich kann das Problem hier auch bestätigen und nachstellen.
Habe eine FritzBox 6591 Cable mit FRITZ!OS: 7.39-103100 BETA (gibt noch keine V7.5) und eine CCU 3 mit Version hm_pdetect 1.14.

Sobald ein VPN mit Wireguard aufgebaut wird, fällt hm_pdetect aus. Baut man die Verbindung wieder ab, geht es wieder. Scheint allerdings hier erst seit der letzten Beta so zu sein. Vorher lief es auch schon Wochen stabil. Auch mit Wireguard.
Sieht so aus, als ob da was von AVM geändert wurde und hm_pdetect damit nicht zurecht kommt.
VG

spiu16 · 2023-02-16T19:33:19Z

@Browserlauser für deine Fritzbox steht Fritz OS 7.5 bereit ;-)
https://avm.de/produkte/fritzos/fritzos-750/

Browserlauser · 2023-02-16T20:25:42Z

Wow aber dann erst seit gerade eben... Da probier ich das morgen gleich mal aus. Danke für den Hinweis ;)

Browserlauser · 2023-02-17T14:25:03Z

Habe heute die 7.50 installiert aber das Problem besteht hier weiterhin.
Habe auch die Wireguard VPN-Verbindung, wie oben beschrieben, nochmal neu eingerichtet. Aber sobald man die Verbindung mit einem Tablet/Handy aufbaut, geht die Abfrage von hm_pdetect nicht mehr. Wird die Verbindung getrennt, läuft sofort auch hm_pdetect wieder los.

Wäre schön, wenn Jens sich das mal anschauen könnte. Dankeschön :)

Piri22 · 2023-02-20T12:01:18Z

Ich habe hier bei mir (FB6690 cable, 7.50) versucht, das Problem nachzustellen. Also Smartphone per WireGuard mit der FB verbunden.
Leider (oder glücklicherweise?) klappt es nicht, hm_pdetect läuft klaglos weiter. Es muss also wohl noch irgend ein anderer Parameter existieren, um zu erreichen, dass hm_pdetect tatsächlich keinen Kontakt mehr zu FB bekommt.
Der DHCP Server meiner FB vergibt Adressen von 192.168.178.101 bis 192.168.178.199, die ganzen VPN Verbindungen bekommen die Adressen ab 192.168.178.200 aufwärts. Hilft das bei jenen, bei denen die VPN Verbindung hm_pdetect killt?

Browserlauser · 2023-02-20T13:58:46Z

Der DHCP vergibt bei mir von 192.168.1.130 - 199. Alles darunter sind Geräte mit fester IP (auch die CCU). Die Wireguard-Verbindungen bekommen alle ebenfalls Adressen oberhalb von 192.168.1.200-
Scheint also alles ziemlich ähnlich. Bin ratlos... Habe sogar nochmal alle WG-Verbindungen neu angelegt. Aber sobald ein VPN besteht, klingt sich hm_pdetect aus. Trennt man VPN geht es wieder los.

== Mon Feb 20 14:57:09 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
Normal-WiFi/LAN devices active: 24
Guest-WiFi/LAN devices active: 1
Checking user presence:
M: away
N: present
L: away
T: present
Checking guest presence:
Gast: disabled
== Mon Feb 20 14:57:09 CET 2023 ===================================
== Mon Feb 20 14:56:39 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
== Mon Feb 20 14:56:08 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
== Mon Feb 20 14:55:38 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
== Mon Feb 20 14:55:08 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
== Mon Feb 20 14:54:36 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
== Mon Feb 20 14:54:06 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
== Mon Feb 20 14:53:35 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
Normal-WiFi/LAN devices active: 24
Guest-WiFi/LAN devices active: 1
Checking user presence:
M: away
N: present
L: away
T: present
Checking guest presence:
Gast: disabled

mdk2412 · 2023-02-20T16:06:37Z

Hier ebenso: Fritzbox 7490 auf 7.51-103186 BETA. Sobald per Wireguard verbunden wird, werden keine Geräte mehr von hmpmdetect gefunden. Ich kann nicht genau sagen, seit wann das auftritt, bemerkt habe ich die Auswirkungen erst heute. Wireguard nutzt auch hier IP-Adressen x.x.x.201 und darüber, darunter DHCP von der Fritzbox.

jens-maus · 2023-02-20T16:36:01Z

Dann muss da eben mal jemand hm_pdetect näher debuggen. Vmtl hat AVM mal wieder was verändert auf das hm_pdetect nicht vorbereitet ist... Selber kann ich das nicht weil keine fritzbox mit wireguard support fw hier

Browserlauser · 2023-02-20T17:32:02Z

Wenn Du mir sagst, was ich tun soll, bin ich dabei.

mdk2412 · 2023-02-21T06:42:48Z

Dito, was würdest Du brauchen und wie kriege ich die Infos aus der Box raus?

jens-maus · 2023-02-21T06:48:44Z

Ihr müsst das hm_pdetect.sh binary auf der Zentrale selbst in einer SSH Sitzung von Hand ausführen und dort ggf. Debuginfos noch hinzufügen, usw. Ganz ohne Linux/Shell-Kenntnisse geht das natürlich nicht.

mdk2412 · 2023-02-21T13:26:39Z

Die Linux-Kenntnisse sollten kein Problem sein. Ich komme per ssh in die pivccu und in das Verzeichnis, wo hm_pmdetect liegt. Aber nun komme ich nicht weiter:

./hm_pdetect.sh
env: can't execute 'bash': No such file or directory

/usr/local/addons/hm_pdetect/bin/bash ./hm_pdetect.sh
ERROR: 'iconv' tool missing. Please install.

Bevor ich jetzt hier weiter wild rumrate: wie muss ich das denn aufrufen?

jens-maus · 2023-02-21T13:36:47Z

Ruf das /usr/local/addons/hm_pdetect/run.sh skript einfach direkt auf. Das sollte alles so vor dem aufruf einstellen das es hm_pdetect.sh korrekt aufrufen kann. Und dann musst du eben das hm_pdetect.sh skript so ändern das es die entsprechenden Debuginfos ausgibt und die landen dann im logfile.

Browserlauser · 2023-02-21T14:27:11Z

Hallo Jens,

hab mir das auch mal über SSH angesehen. Du hast in dem hm_pdetect.sh ja mehrere Stellen wo sich Debuginfos ausgeben lassen. Soll ich einfach mal alle aktivieren oder nur eine bestimmte Stelle?

Browserlauser · 2023-02-21T15:02:53Z

Sorry, das zuletzt geschriebene mit der MAC-Adresse stimmt so nicht. Die Geräte haben eine MAC. (Es gab nur noch alte Einträge in der Deviceliste) Deshalb ist der letzte Beitrag hier gelöscht!

jens-maus · 2023-02-21T17:37:12Z

Du musst halt mal selber schauen an welcher Stelle hm_pdetect.sh nicht weitermacht, denn ganz offensichtlich kommt es ja nicht bis zur Ausgabe von Normal-WiFi/LAN devices active: ... wenn Wireguard VPN Verbindungen aktiv sind.

Browserlauser · 2023-02-22T10:44:01Z

Hallo Jens,

es scheint hier vor dem Aufruf von "retrieveFritzBoxDeviceList" zu "hängen" da ja immer wieder in Folge diese Ausgabe erolgt:

== Wed Feb 22 11:20:35 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
== Wed Feb 22 11:19:49 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
== Wed Feb 22 11:19:04 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1

In diesem Teil:

 # output time/date of execution
  echo "== $(date) ==================================="

  # lets retrieve all mac<>ip addresses of currently
  # active devices in our network
  echo -n "Querying FRITZ! devices:"
  i=0
  for ip in ${HM_FRITZ_IP}; do
    if [[ ${i} -gt 0 ]]; then
      echo -n ","
    fi
    echo -n " ${ip}"
    if retrieveFritzBoxDeviceList "${ip}" "${HM_FRITZ_USER}" "${HM_FRITZ_SECRET}"; then
      ((i = i + 1))
    fi
  done

Warum, kann ich allerdings noch nicht sagen.

Grüße Thomas

jens-maus · 2023-02-22T10:46:57Z

es scheint hier vor dem Aufruf von "retrieveFritzBoxDeviceList" zu "hängen" da ja immer wieder in Folge diese Ausgabe erolgt:
[...]
Warum, kann ich allerdings noch nicht sagen.

Na dann musst du dir halt debug ausgaben in der retrieveFritzBoxDeviceList Funktion hinzufügen und schauen was da so passiert. Zwischenberichte braucht es nicht. Wenn du den Fehler findest, PullRequest her oder eben die Fehlerausgabe, etc.

Browserlauser · 2023-02-22T15:56:14Z

Hallo Jens,

also ich bin ja jetzt auch nicht der größte Codemeister, und daher kann ich jetzt auch nicht mit dem wirklichen Fehler dienen. Aber ich habe in deinen Script mal ein paar zusätzliche Debug-Infos eingebaut und ich vermute mal, dass es hier ein Problem mit der Session-ID gibt. Mit set -x hab ich das irgendwie nicht hinbekommen.
Jedenfalls bricht der Script genau an dieser Ausgabe ab. Unten im Codeschnipsel ist das so markiert <<<<<<<<
Viel mehr kann ich da jetzt auch nich beitragen. Da durchblicke ich den gesamten Code nicht.

== Wed Feb 22 16:45:02 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1 Retrieving network device list from http://192.168.1.1
Trying to use existing session ID for 192.168.1.1
Using existing session ID 1408fe5635f93394
Session ID 1408fe5635f93394 http://192.168.1.1

function retrieveFritzBoxDeviceList()
{
  local ip=$1
  local user=$2
  local secret=$3
  local uri=${ip}

  # check if "ip" starts with a "http(s)://" URL scheme
  # identifier or if we have to add it ourself
  if [[ ! ${ip} =~ ^http(s)?:\/\/ ]]; then
    uri="http://${ip}"
  fi

  echo " Retrieving network device list from ${uri}"


  # retrieve the network device list from the fritzbox using a
  # specific call to query.lua so that we get our information without
  # having to parse HTML portions. we first try this with our
  local devices=
  local res=1
  local sid=""

  # get a previously existing session id and try that first
  echo "Trying to use existing session ID for ${ip}"

  sid=$(cat "/tmp/hm_pdetect-${ip}.sid" 2>/dev/null)
  if [[ -n ${sid} ]]; then
    echo "Using existing session ID ${sid}"

    devices=$(getDeviceList "${uri}" "${sid}")
	echo "Session ID ${sid} ${uri}"                    <<<<<<<<<<<<< ABBRUCH HIER <<<<<<<<<<<<<<
    res=$?
  fi
  if [[ ${res} -ne 0 || -z ${devices} ]]; then
    # the first iteration with the sid of the
    # last iteration didn't work out so lets
    # generate a new one
    echo "No or invalid session ID, trying to generate a new one for ${ip}"
    if ! sid=$(getSessionID "${uri}"); then
      echo "Could not get session ID for ${uri}"
      return ${RETURN_FAILURE}
    fi

    # try to retrieve the device list again

jens-maus · 2023-02-22T16:01:17Z

Du musst natürlich da etwas tiefer eintauchen un nun mehr debug infos in die getDeviceList Funktion hinzufügen, denn da drin wird irgendwo der Fehler bzw. das "hängen" liegen. Meine Vermutung ist der dort liegende wget call gegen die fritzbox. Und die Zeile die du da bei ABBRUCH HIER hinzugefügt hast, solltest du wieder rausnehmen, denn das res=$? muss unmittelbar nach dem getDeviceList kommen sonst ist die Logik kaputt.

Um diese Zeile sollte es gehen:

hm_pdetect/hm_pdetect.sh

Line 426 in e4bdc8a

    
           devices=$(wget --timeout=10 -q -O - --max-redirect=0 --no-check-certificate "${uri}/query.lua?sid=${sid}&network=landevice:settings/landevice/list(name,ip,mac,guest,wlan,speed,active)")

Ich vermute das der wget call gegen das query.lua vmtl. hängen bleibt oder mit komischer fehlermeldung abbricht. Müsste man also mal einfach mit valider sessionID testen was eine fritzxbox mit dieser neuen 7.50 FW dann so macht bzw. zurückgibt.

Browserlauser · 2023-02-22T18:43:01Z

Habe jetzt mit meine SID und URL:

wget --timeout=10 -q -O - --max-redirect=0 --no-check-certificate "http://192.168.1.1/query.lua?sid=1408fe5635f93394&network=landevice:settings/landevice/list(name,ip,mac,guest,wlan,speed,active)"

...die Abfrage per Hand ausgeführt aber in beiden Fällen (also WG an und aus) wird das Ergebnis aller Netzwerkgeräte sauber zurück geliefert. "wget" scheint also zu funktionieren.

jens-maus · 2023-02-22T19:45:52Z

Ok, dann gibt doch einfach mal direkt vor Zeile 462 mittels echo das ganze $devices aus bzw. auch vor Zeiel 473. Müsste doch recht leicht rauszubekommen sein wo genau die getDeviceList Funktion anfängt zu hängen.

Browserlauser · 2023-02-24T17:03:44Z

Hallo Jens,

ich glaube ich komme der Sache langsam näher. Ich denke das Problem besteht an der Stelle, wo die beiden Arrays aus den MAC-Adressen zusammengebaut werden. Zeile 580-589. Ich habe da mal ein paar Debuginfos eingebaut:

# modify the global associative array for the normal-WiFi/LAN
  for (( i = 0; i < ${#maclist_normal[@]} ; i++ )); do
    normalDeviceList[${maclist_normal[$i]}]=${iplist_normal[$i]}
	# DEBUG: uncomment for debugging purposes
	echo "--- modify array for the normal-WiFi/LAN"
	echo "${#maclist_normal[@]}"
	echo "${maclist_normal[$i]}"
	echo "${iplist_normal[$i]}"
  done

  # modify the global associative array for the guest-WiFi/LAN
  for (( i = 0; i < ${#maclist_guest[@]} ; i++ )); do
    guestDeviceList[${maclist_guest[$i]}]=${iplist_guest[$i]}
	# DEBUG: uncomment for debugging purposes
	echo "--- modify the array for the guest-WiFi/LAN"
	echo "${#maclist_guest[@]}"
	echo "${maclist_gues[$i]}"
	echo "${iplist_guest[$i]}"
  done

Hier zeigt sich jetzt, dass ohne WG beide Schleifen durchlaufen werden und auch das Logfile vollständig ist:

== Fri Feb 24 17:26:40 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1
--- modify array for the normal-WiFi/LAN
24
xx:CD:5A:xx:C2:99
192.168.1.210
--- modify array for the normal-WiFi/LAN
24
xx:11:32:xx:A3:B3
192.168.1.205
.
. (gekürzt...hier stehen dann die 22 weiteren Geräte)
.
.
--- modify the array for the guest-WiFi/LAN
1

192.168.179.22

 Normal-WiFi/LAN devices active: 24
 Guest-WiFi/LAN devices active: 1
Checking user presence: 
 M: away
 N: present
 L: away
 T: present
Checking guest presence: 
 Gast: disabled
== Fri Feb 24 17:26:41 CET 2023 ===================================

Wenn man nun eine WG-Verbindung aufbaut, dann bricht die Schleife 1 unvermittelt ab (Log ist hier ungekürzt).

== Fri Feb 24 17:49:05 CET 2023 ===================================
Querying FRITZ! devices: 192.168.1.1--- modify array for the normal-WiFi/LAN
25
xx:CD:5A:xx:C2:99
192.168.1.210
--- modify array for the normal-WiFi/LAN
25
xx:11:32:xx:A3:B3
192.168.1.205
--- modify array for the normal-WiFi/LAN
25
xx:D2:DD:xx:8A:B2
192.168.1.137

Hast du eine Idee warum das passieren könnte?

Grüße Thomas

Brandy-f1 · 2023-03-08T07:50:55Z

Hallo Zusammen,
Bei stellt sich die Sach so dar: VPN Verbindung wird aktiviert, Verhalten wie oben beschrieben. Nach Abbau der VPN Verbindung läuft hm_pdetect wieder. Ist die VPN Verbindung über längere Zeit aktiv (Zeitraum muss ich noch checken, sind aber sicher mehr als einige Minuten), läuft auch hm_pdect nicht wieder an. bei mir hat dann nur noch ein Neustart der Fritzbox etwas gebracht.

Das Problem beschränkt sich somit nicht nur auf WG VPNs sondern allgemein auf aufgebaute VPNs in der Fritzbox.

Ich denke auch, daß AVM hier in der FW etwass angepasst hat, auf das hm_pdetect "noch nicht" reagieren kann.

Verwendete Systeme:

Fritzbox 7590 AX Firmware: 7.39-103725 BETA
raspbarrymatic Firmware: 3.67.10.20230225
hm_pdetect: V1.14

jens-maus · 2023-03-08T08:29:01Z

ich glaube ich komme der Sache langsam näher. Ich denke das Problem besteht an der Stelle, wo die beiden Arrays aus den MAC-Adressen zusammengebaut werden. Zeile 580-589. Ich habe da mal ein paar Debuginfos eingebaut:
[...]
Wenn man nun eine WG-Verbindung aufbaut, dann bricht die Schleife 1 unvermittelt ab (Log ist hier ungekürzt).
[...]
Hast du eine Idee warum das passieren könnte?

Gib doch mal bitte einfach das ${devices} in Zeile 523 in eine Datei aus

hm_pdetect/hm_pdetect.sh

Lines 522 to 525 in e4bdc8a

    
           local active=0 
        
           # parse the query.lua output line by line 
        
           while read -r line; do

Einfach z.B. so:

echo "${devices}" >/tmp/output

Und dann lädst du hier mal die output Datei hoch oder schickst sie mir per mail und dann kann ich das näher debuggen

EmbCGuru · 2023-03-12T10:51:44Z

Hier wurden die Gastnetzwerkgeräte per MAC nicht erkannt.
Zum Test habe ich das Gastnetzwerk 192.168.179.* eingetragen, obwohl das der Standard ist, und siehe da es läuft.

Aber mit dem Wirebuard stimmt etwas nicht
Hier ein Logg Schnippsel zuerst mit WG aus und dann an.
Man sieht das deutlich weniger enthalten ist

== Sun Mar 12 11:50:00 CET 2023 ===================================
Querying FRITZ! devices: fritz.box
== Sun Mar 12 11:49:42 CET 2023 ===================================
Querying FRITZ! devices: fritz.box
== Sun Mar 12 11:48:41 CET 2023 ===================================
Querying FRITZ! devices: fritz.box
Normal-WiFi/LAN devices active: 22
Guest-WiFi/LAN devices active: 3
Checking user presence:
T: present
M: present
O: present
Checking guest presence:
Gast: present - 22 (....)
== Sun Mar 12 11:48:42 CET 2023 ===================================

mbhomie007 · 2023-03-12T11:13:27Z

ich glaube ich komme der Sache langsam näher. Ich denke das Problem besteht an der Stelle, wo die beiden Arrays aus den MAC-Adressen zusammengebaut werden. Zeile 580-589. Ich habe da mal ein paar Debuginfos eingebaut:
[...]
Wenn man nun eine WG-Verbindung aufbaut, dann bricht die Schleife 1 unvermittelt ab (Log ist hier ungekürzt).
[...]
Hast du eine Idee warum das passieren könnte?

Gib doch mal bitte einfach das ${devices} in Zeile 523 in eine Datei aus

hm_pdetect/hm_pdetect.sh

Lines 522 to 525 in e4bdc8a

local active=0

# parse the query.lua output line by line

while read -r line; do

Einfach z.B. so:
echo "${devices}" >/tmp/output
Und dann lädst du hier mal die output Datei hoch oder schickst sie mir per mail und dann kann ich das näher debuggen

@Browserlauser kannst du das mal bei Gelegenheit prüfen?

Browserlauser · 2023-03-12T15:43:26Z

Das hab ich schon gemacht und an Jens direkt per Mail geschickt.
Ohne Wireguard werden die Geräte dabei ganz normal in das Logfile geschrieben. Mit Wireguard kommt im Logfile aber nichts mehr an.

Bei mir bleibt der Script beim erstellen der Arrays in Zeile 580-589 hängen. Ohne WG werden beide Schleifen durchlaufen und auch das Logfile ist vollständig. Mit WG-Verbindung bricht die Schleife 1 unvermittelt ab.

mdk2412 · 2023-03-12T18:30:25Z

Nur als Ergänzung, vielleicht gibt das ja einen Hinweis: nach Downgrade auf 1.1 funktioniert es auch mit Wireguard wieder, trotz aktueller Labor-Firmware 7.51-103578 BETA auf der 7490.

jens-maus · 2023-03-12T18:38:20Z

Nur als Ergänzung, vielleicht gibt das ja einen Hinweis: nach Downgrade auf 1.1 funktioniert es auch mit Wireguard wieder

Du meinst doch sicher die 1.11 und nicht 1.1. die wäre schon ziemlich asbach uralt…

mdk2412 · 2023-03-13T10:11:58Z

Ja sorry, 1.11 ist richtig.

Piri22 · 2023-03-17T18:32:02Z

Jetzt gibt es Versuion 1.15, die das VPN Problem hätte lösen sollen. Merkwürdigerweise lief bei mir (FB6690cable, fritzOS 7.50) Version 1.14 problemlos auch bei bestehender WireGuard Verbindung.
Das hat sich nun mit Version 1.15 leider geändert. WG VPN Verbindung = hm_pdetect läuft nicht mehr richtig. Verbindung getrennt = alles wieder ok

mdk2412 · 2023-03-17T20:55:28Z

Also bei einer 7490 mit aktueller Labor-Firmware läuft es mit 1.15 jetzt wieder, mit 1.14 ging es reproduzierbar nicht.

Browserlauser · 2023-03-18T15:41:45Z

Mit einer 6591 Cable und FritzOS 7.50 funktioniert die Version 1.15 jetzt einwandfrei.

jens-maus closed this as completed in a67f9f6 Mar 15, 2023

Problem V 1.14 #125

Problem V 1.14 #125

Comments

harry-refrath commented Dec 29, 2022

mbhomie007 commented Dec 29, 2022

harry-refrath commented Dec 30, 2022

jens-maus commented Dec 30, 2022

harry-refrath commented Dec 30, 2022

Piri22 commented Jan 1, 2023 • edited by jens-maus Loading

jens-maus commented Jan 11, 2023 • edited Loading

Piri22 commented Jan 11, 2023

Piri22 commented Jan 25, 2023

rolbx commented Feb 14, 2023 • edited Loading

Piri22 commented Feb 15, 2023

harry-refrath commented Feb 15, 2023

Browserlauser commented Feb 16, 2023

spiu16 commented Feb 16, 2023

Browserlauser commented Feb 16, 2023

Browserlauser commented Feb 17, 2023

Piri22 commented Feb 20, 2023 • edited Loading

Browserlauser commented Feb 20, 2023 • edited Loading

mdk2412 commented Feb 20, 2023

jens-maus commented Feb 20, 2023

Browserlauser commented Feb 20, 2023

mdk2412 commented Feb 21, 2023

jens-maus commented Feb 21, 2023

mdk2412 commented Feb 21, 2023 • edited Loading

jens-maus commented Feb 21, 2023

Browserlauser commented Feb 21, 2023

Browserlauser commented Feb 21, 2023

jens-maus commented Feb 21, 2023

Browserlauser commented Feb 22, 2023 • edited Loading

jens-maus commented Feb 22, 2023

Browserlauser commented Feb 22, 2023

jens-maus commented Feb 22, 2023 • edited Loading

Browserlauser commented Feb 22, 2023 • edited Loading

jens-maus commented Feb 22, 2023

Browserlauser commented Feb 24, 2023 • edited by jens-maus Loading

Brandy-f1 commented Mar 8, 2023

jens-maus commented Mar 8, 2023

EmbCGuru commented Mar 12, 2023

mbhomie007 commented Mar 12, 2023

Browserlauser commented Mar 12, 2023

mdk2412 commented Mar 12, 2023

jens-maus commented Mar 12, 2023

mdk2412 commented Mar 13, 2023

Piri22 commented Mar 17, 2023

mdk2412 commented Mar 17, 2023

Browserlauser commented Mar 18, 2023

Piri22 commented Jan 1, 2023 •

edited by jens-maus

Loading

jens-maus commented Jan 11, 2023 •

edited

Loading

rolbx commented Feb 14, 2023 •

edited

Loading

Piri22 commented Feb 20, 2023 •

edited

Loading

Browserlauser commented Feb 20, 2023 •

edited

Loading

mdk2412 commented Feb 21, 2023 •

edited

Loading

Browserlauser commented Feb 22, 2023 •

edited

Loading

jens-maus commented Feb 22, 2023 •

edited

Loading

Browserlauser commented Feb 22, 2023 •

edited

Loading

Browserlauser commented Feb 24, 2023 •

edited by jens-maus

Loading