IP-Router Schwierigkeiten mit Tunnelverbindungen

[re4p3r]

ja hab es gerade auch nochmal getestet mit einem Re-Konfiguration der Verbindung von HA. Der benutzt immer denselben Tunnel.
Gestern abend war es auf jeden Fall wieder so, dass sowohl HA keine Verbindung mehr aufbauen konnte. Gerätekonsole hatte aber keine Einträge.
Ich lass die heute so gut es geht mal noch weiter mitlaufen. Vielleicht tritt das Problem ja im Laufe des Tages nochmal auf unmd die Gerätekonsole logged irgendwas

[re4p3r]

hab die Gerätekonsole mal so gut es ging mitlaufen lassen. Leider ist das Problem bisher nicht mehr wirklich aufgetreten. Es hat sich aber ja sonst erst nach ein paar Tagen etc. bemerkbar gemacht.
Hab das neue Log trotzdem mal mit angehangen.

[re4p3r]

also das Problem trat heute wieder auf. Ich hab das ETS log mal angehängt.
Da ist zu sehen, dass die ETS zwischendurch mal versucht reconnects zu machen (die VM lief die ganze Zeit ansich durch). Teilweise klappt dass dann auch, teilweise eben nicht bzw. nicht mehr wenn eben keine Tunnelverbindungen mehr zur Verfügung stehen.

Kann das eben damit zusammenhängen, dass die ETS Tag für Tag durchläuft? Aber auch dann sollte ja immer wieder dieselbe Tunnelverbindung verwendet werden oder nicht?

Vielleicht erbarmt sich ja jemand in das Log zu schauen ?

[Ing-Dom]

das Log hilft leider nicht viel, da fehlen wichtige Protokolldetails.
Ich brauche den Console Log und/oder (und ist besser!) Wireshark auf dem auch die Tunnelverbindungen zu sehen sind.

Die ETS läuft durch - warum?

[re4p3r]

Die ETS läuft durch - warum?

weil der Mac an der Stelle meist immer an ist, die VM weiterläuft und ich meist die ETS einfach in der VM offen lasse.

Ich habe die Wireshark Dateien die ich hab mitlaufen lassen mal angehängt:
- beforereset -> sind die Dateien die vor einem Reset des Routers über das Netz geganggen sind. Ich hoffe die KNXNet und mdns Anfragen reichen hier aus
- afterreset -> sind die Dateien die nach einem Reset des Routers über das Netz geganggen sind. Ich hoffe die KNXNet und mdns Anfragen reichen hier aus

Sofern der Wireshark in gänze ausreicht und die Console für den IP-Router nicht mitlaufen muss, kann ich das ganze auch mal über einen längeren Zeitraum, da ich ja dann am Netz hängen kann, mitlaufen lassen

Ich hab aber fast die Vermutung dass wenn die ETS weiterläuft und bspw. das Diagnosewerkzeug bzw. der Gruppenmonitor ausversehen noch offen ist und weiterläuft es zu diesem Phänomen kommt und er einfach alle Tunnelverbindungen aufbraucht, bis keine mehr da sind. Kann das sein ?

[Ing-Dom]

was man hier sieht ist dass der Router alle Tunnel mit Verbindungen zur IP des ETS Rechner belegt hat.
Der Router sendet auf allen Tunnelverbindungen, aber die ETS bestätigt nicht.

Leider sieht man nicht, wie es dazu gekommen ist.

[Ing-Dom]

könntest du nochmal dein Setup genau beschreiben.
FWVersion, Hardware, welche ETS, was genau macht die ETS (Gruppenmonitor offen?)

[Ing-Dom]

Ich hatte noch einen Verdacht was es hätte sein können bei dir - aufgrund der Tatsache dass der Router die maximalzahl an Tunneln offen hatte und keine einzige bestätigt wurde (Tunnel.ack) hat das für mich darauf hingedeutet dass das automatische schließen von Tunneln nicht mehr funktioniert.
Das wäre eine Erklärung.. Hintergrund: nach 2min ohne dass die Gegenseite (Client) mit einem ConnectionStateRequest den Tunnel offen hält wird dieser beendet.

Das ist aber nicht der Fall.. das klappt.

Jetzt bleibt die Frage, warum bei dir alle Tunnel belegt sind. Aufschluss kann hier nur eine Aufzeichnung bringen, die den Übergang zeigt wie es vom normalzustand (ein offener Tunnel von der ETS) zu dem Fehlerzustand mit vollbelegung kommt. Und damit meine ich in erster linie wireshark.

[willisurf]

Hilft ggf. das Log der ETS?

[re4p3r]

Sorry ich kam jetzt erst zum lesen der Vorschläge. ich versuche das mal zu beschreiben

FWVersion, Hardware, welche ETS, was genau macht die ETS (Gruppenmonitor offen?)

FW-Version

9d 04:33:56: Firmware
9d 04:33:56: Name: IP-Router
9d 04:33:56: Version: 0.6.0
9d 04:33:56: Number: $A11F
9d 04:33:56: KNX-Type: Router (091A)
9d 04:33:56: CPU-Mode: Single-Core​

Hardware: REG1-LAN-TP-Base / OpenKNX REG1 Basismodul LAN+TP

ETS: 6.3.1 Build 8272, läuft wie gesagt in einer VM unter VMware Fusion im Bridge Netzwerk Modus

Was genau macht die ETS: also so ganz durchgängig war es noch nicht. Manchmal hat es nach einer Zeit nicht mehr funktioniert wenn ich bspw. neu programmieren wollte oder aber der Gruppenmonitor war offen (und ich hab nicht gemerkt dass der offen war )

Teststellung zum weiteren Debuggen:
- Ich würde die ETS VM mal laufen lassen
- Gruppenmonitor offen
- Netzwerktraffic mit Wireshark auf dem Interface mitschneiden
Ing-Dom reicht hier die Ziel und Quell IPs und gefilter auf KNX und Multicast aus ?

Was wären die Anforderungen an das ETS Log sollte ich das auch exportieren sollen ? Einfach alles was die Diagnose dann her gibt ?

[Ing-Dom]

reicht hier die Ziel und Quell IPs und gefilter auf KNX und Multicast aus ?

knxip reicht aus als protokollfilter, dazu (wenn viel anderweitiger kip traffic da ist) src oder dst ip = ip router oder ip ets oder 224.0.23.12

[re4p3r]

ich hab die Daten mal gesammelt, leider ist das capture File relativ groß geworden, sodass ich den Umweg über den Drive hier gehen muss: https://drive.google.com/file/d/1E5C...ew?usp=sharing

Die ETS hat aber schon nach ein paar Minuten, ein paar Events gezeigt, die evtl. auf die Problematik hinzeigt:
image.png
nach knapp 15min kam hier ein Stop (ohne manuelles zutun) und danach ein weiteres Connection event. An der Stelle ging das ganze noch "gut".

Ab 20:21 dasselbe dann wieder, nur ohne "Recovery":
image.pngDanach lässt sich dann auch definitiv keine Verbindung mehr über den IP-Router aufbauen.

Folgendes war generell der zeitliche Verlauf

restart IP-Router: 19:28

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 271414342, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd _drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:4660
load:0x40078000,len:15556
load:0x40080400,len:4
ho 8 tail 4 room 4
load:0x40080404,len:3152
entry 0x400805a0
E (553) esp_core_dump_flash: No coreVW
▒partition found!
E (553) esp_core_dump_flash: No core dump partition found!
0d 00:00:00: LED-Manager: Init 4 Leds
0d 00:00:00: SerialLedManager: init
$ E (24) gpio: gpio_pullup_en(78): GPIO number error (input-only pad has no internal PU)
E (28) gpio: gpio_pullup_en(78): GPIO number error (input-only pad has no internal PU)
E (36) gpio: gpio_pullup_en(78): GPIO number error (input-only pad has no internal PU)
E (43) gpio: gpio_pullup_en(78): GPIO number error (input-only pad has no internal PU)
E (51) gpio: gpio_pullup_en(78): GPIO number error (input-only pad has no internal PU)
0d 00:00:00: Common: Init firmware
0d 00:00:00: KNX: Set Callback
0d 00:00:00: Watchdog: Sta17 0C 00 01 20 00 1E 4F 70 65 6E 4B 4E 58 3A 20 49 50 2D 52 6F 75 74 65 72 00 00 00 00 00 00 00 00 00 00 00 00 3F 00 00 00 00 00 00 00 01 00 00 00 01 00 00 00 01 00 01 00 00 20 00 00 00 02 00 00 01 17 00 01 63 00 01 1F 00 01 0F 20 00 FF 00 01 FF FF
0d 00:00:00: KNX: restoring data from flash...
0d 00:00:00: KNX: saverestores 4
0d 00:00:00: KNX: -12
0d 00:00:00: KNX: .
0d 00:00:00: KNX: -28
0d 00:00:00: KNX: .
0d 00:00:00: KNX: -28
0d 00:00:01: KNX: Initializing KNX multicast
0d 00:00:01: Flash<Default>: Load data from flash
0d 00:00:01: Flash<Default>: Load module data (from slot 0)
0d 00:00:01: Flash<Default>: Loading completed (12ms)
0d 00:00:01: KNX: Try Initialize 19200
0d 00:00:01: KNX: BCU connected (Baudrate: 19200)
0d 00:00:01: KNX: Stop mode disabled
0d 00:00:01: KNX: Reset received
0d 00:00:01: Network: Link connected
0d 00:00:01: Network: Network established
0d 00:00:01: Network: Using static IP
0d 00:00:02: ================================================== ==============================
0d 00:00:02:
0d 00:00:02: Open # OpenKNX.de
0d 00:00:02: +----+
0d 00:00:02: # KNX wiki.openknx.de - forum.openknx.de
0d 00:00:02:
0d 00:00:02: ======================== Information ===========================================
0d 00:00:02: Device
0d 00:00:02: ID: REG1-LAN-TP-Base
0d 00:00:02: Name: OpenKNX REG1 Basismodul LAN+TP
0d 00:00:02: Serial number: 00FA:08EA130C
0d 00:00:02: Firmware
0d 00:00:02: Name: IP-Router
0d 00:00:02: Version: 0.6.0
on: Warning: The loop took longer than usual (160 >= 50); stack 0
0d 00:00:59: KNX: New Tunnel-Connection[0], Channel: 0x1 PA: 1.1.255 with 192.168.178.128:44109

Start Wireshark 19:31

Start Gruppenmonitor 19:32:44

Device Console nach start Gruppenmonitor

0d 00:03:50: KNX: New Tunnel-Connection[1], Channel: 0x2 PA: 1.1.254 with 192.168.178.116:52620
0d 00:03:50: KNX: New Tunnel-Connection[16], Channel: 0x3 PA: 0.0.0 with 192.168.178.116:52620 (Config-Channel)

Ich hoffe es hilft

Viele Grüße und vielen Dank für die Analyse

[Ing-Dom]

Ich hoffe es hilft

leider nicht. Das Wireshark beginnt, da ist die "Fehlersituation" schon eingetreten:
15 offene Tunnel, keiner Antwortet und die neue Verb. wird abgewiesen.

Screenshot 2026-03-05 112556.png