Multicast Telegramme vom gleichen Host werden nicht an TPUART weitergeleitet

[NilsS]

Woran kann es liegen das Multicast Telegramme vom knxd ignoriert werden wenn sie vom gleichen Host kommen?

Die Telegramme sind aber auf jeden Fall per Multicast raus. Sichtbar in der ETS auf anderem Rechner.
Sie werden aber nicht auf die Linie am TPUART geschrieben.
Woran kann es liegen?
Falsche physikalische Adressen?

Derzeit hat sowohl der knxd als auch das andere Programm welches per Multicast sendet keine physikalische Adresse aus der TP Linie.

[Smurf]

Vielleicht sagst du uns mal deine Optionen und deine Adressen und so.

Ansonsten: Debugging einschalten. Der knxd sagt dir dann ob er ein Paket wegwirft.

[NilsS]

ooops sorry, jo denke das hilft evtl.

[groupcache]
#max-size = 65535
[main]
background = false
cache = groupcache
pidfile = /var/run/knxd/knxd.pid
connections = tcpserver,knxserver,knxdevice
name = pi
addr = 1.0.1
client-addrs = 1.0.10:20
[tcpserver]
port = 6720
server = knxd_tcp
systemd-ignore = false
[knxdevice]
device = /dev/serial0
driver = tpuart
[knxserver]
discover = true
server = ets_router
tunnel = tunnel
router = router

Von externen Geräten funktioniert alles prima.

TP Linie ist 1.1

ich hab mal trace-mask auf 1053 gesetzt.

pi: Layer 0 [ 9:knxserver/server    14.827] Send(017): 06 10 05 30 00 11 29 00 BC D0 11 D5 2A 79 01 00 80
pi: Layer 0 [ 9:knxserver/server    14.828] Dropped(017): 06 10 05 30 00 11 29 00 BC D0 11 D5 2A 79 01 00 80
pi: Layer 2 [20:router.pace_/router 14.844] delay done
pi: Layer 2 [20:router.pace_/router 15.100] out 1/2: delay for 0.017 sec
pi: Layer 0 [ 9:knxserver/server    15.100] Send(017): 06 10 05 30 00 11 29 00 BC D0 11 99 2C 29 01 00 80
pi: Layer 0 [ 9:knxserver/server    15.101] Dropped(017): 06 10 05 30 00 11 29 00 BC D0 11 99 2C 29 01 00 80
pi: Layer 2 [20:router.pace_/router 15.117] delay done
pi: Layer 0 [ 9:knxserver/server    15.455] Dropped(017): 06 10 05 30 00 11 29 00 B4 E0 00 F1 08 0C 01 00 81
pi: Layer 2 [20:router.pace_/router 15.715] out 1/4: delay for 0.019 sec
pi: Layer 0 [ 9:knxserver/server    15.715] Send(019): 06 10 05 30 00 13 29 00 BC D0 11 65 22 0A 03 00 80 18 E1
pi: Layer 0 [ 9:knxserver/server    15.716] Dropped(019): 06 10 05 30 00 13 29 00 BC D0 11 65 22 0A 03 00 80 18 E1
pi: Layer 2 [20:router.pace_/router 15.734] delay done
pi: Layer 2 [20:router.pace_/router 15.930] out 1/4: delay for 0.019 sec
pi: Layer 0 [ 9:knxserver/server    15.930] Send(019): 06 10 05 30 00 13 29 00 BC D0 11 7B 21 8C 03 00 80 19 3B
pi: Layer 0 [ 9:knxserver/server    15.931] Dropped(019): 06 10 05 30 00 13 29 00 BC D0 11 7B 21 8C 03 00 80 19 3B
pi: Layer 2 [20:router.pace_/router 15.949] delay done
pi: Layer 2 [20:router.pace_/router 15.986] out 1/4: delay for 0.019 sec
pi: Layer 0 [ 9:knxserver/server    15.987] Send(019): 06 10 05 30 00 13 29 00 BC D0 11 7B 22 8C 03 00 80 18 7D
pi: Layer 0 [ 9:knxserver/server    15.987] Dropped(019): 06 10 05 30 00 13 29 00 BC D0 11 7B 22 8C 03 00 80 18 7D
pi: Layer 2 [20:router.pace_/router 16.006] delay done
pi: Layer 0 [ 9:knxserver/server    16.032] Dropped(017): 06 10 05 30 00 11 29 00 B4 E0 00 F1 08 0C 01 00 81
pi: Layer 0 [ 9:knxserver/server    16.579] Dropped(017): 06 10 05 30 00 11 29 00 B4 E0 00 F1 08 0C 01 00 81

das Dropped(017) könnte es sein 1/0/12 auf 1

Woran kann das liegen?

[makki]

Woran kann es liegen das Multicast Telegramme vom knxd ignoriert werden wenn sie vom gleichen Host kommen?

An Multicast ansich, denn derselbe, sendende Host muss die ja nicht wirklich nochmal selbst sehen (ich hab jetzt nicht in die RFC und KNX-spec geschaut)

Aber wahrscheinlicher ist, das Multicast-Handling einfach "kaputt" ist - wie auf den meisten (End-)Geräten, MC ist ein defekt ansich by design (zumindest dafür, einen 9,6kbit Bus über GigE), meine Meinung..

Makki

[Smurf]

Es gibt am Multicast-Socket eine Option IPPROTO_IP/IP_MULTICAST_LOOP, die man setzen muss, wenn man will, dass die gesendeten Pakete auch am eigenen Hos ankommen.

Der knxd tut das, aber das betrifft natürlich nur die Pakete die er selber sendet.

[NilsS]

Ja die hatte ich gefunden. Hab sie auch in dem Python Programm nach bestem Wissen dort als SOL_IP gesetzt. Hat es ohne Probleme genommen. Aber keine Änderung

[NilsS]

Besten Dank Matthias

IPPROTO_IP und nicht SOL_IP oO .. man sollte nicht einfach nur die darüberliegende Zeile kopieren

EDIT: Ist vom Wert her das gleiche beides entspricht 0

[NilsS]

hmm nein, war es doch nicht. Hatte mich versehen das Licht ging aufgrund einer Logik vom HS dann an.

Also die Multicast Message geht ja aus dem Programm auch raus, sowohl übers Netz zu anderen Multicast Listenern als auch zum knxd der die Nachricht ja dropped.

Im knxd in io_recv_cb ist der recvall was auch immer der besagt 2.

(recvall == 2 && memcmp (&r, &localaddr, sizeof (r))) ||

Daher müsste dann der hintere Teil wahr sein damit wir nicht gedropped werden, oder?

Hmm das Verhalten ist in etwa das gleiche als wenn ich von einem anderen Host.
knxtool groupwrite 1/0/12 1 schicke, welches NICHT geht aber trotzdem über Multicast per ETS sichtbar ist.
und
knxtool groupswrite 1/0/12 1 . welches funktioniert wie es soll, das Paket in der ETS aber genauso aussieht wie das groupwrite welches nicht ging.

Die Verbindung vom knxtool ist aber per tcp, oder? oder sendet das direkt per multicast

[NilsS]

Smurf
kannst du mir sagen an welcher Stelle recvall = 2 wird?
Irgendwie bin ich in cpp nicht firm genug.

Das GetSourceAddress hatte ich noch gefunden, aber wird die Adresse nicht natürlich die gleiche sein wenn ich vom gleichen Host etwas abschicke.

Ich habe auch kein Programm gefunden welches lokal vom gleichen Host KNX Multicast verwendet um Pakete abzuschicken.

Hast du irgend etwas womit ich nach einer Lösung suchen kann?

[Ilalei]

Hi Nils, hast du hier ne Lösung gefunden?

[NilsS]

Hi,
nein leider nicht. Ich denke aber das die Funktion dahinter einfach falsch ist.
Das Prinzip ist klar, ich will nicht meine eigenen Pakete wieder auf den Bus schicken. Das sollte aber nicht anhand der IP des Multicast Paketes passieren sondern anhand der physikalischen Adresse.

Welches Programm macht bei dir dieses Problem?

Ich könnte mir auch vorstellen, dass zwei knxd Instanzen das Problem hätten. Das wurde zwar schon mal irgendwo geschrieben das das gehen soll.
Hab aber noch von niemandem gehört der das auch tatsächlich gemacht hat.

Ich hab versucht mich ein wenig durch den source zu hangeln, aber "recvall" .... keine Ahnung was der Sinn dieser Variable ist, die irgendwo (ich habs nicht gefunden) auf 2 gesetzt wird.

Aber wie gesagt, aus meiner Sicht sollte der knxd die physikalische Adresse des TP Netzes haben und nur Pakete an TP forwarden die nicht im gleichen Phy Netz sind.

[Ilalei]

Bei mir ist Openhab das Problemkind. Im Tunnel funktioniert es, aber als Router das gleiche Fehlerbild wie bei dir. Signale empfangen kann Openhab, aber sobald ich senden will kommen die beim knxd nicht an.
Habe auch noch keine Config/Person gefunden bei der das Funktioniert

Und wie man die Opts IPPROTO_IP/IP_MULTICAST_LOOP ändert, weiß ich grad auch noch nicht

[NilsS]

Das kannst du dir sparen. Die hab ich gesetzt und es ändert nix. Dann würdest du auch im Log nicht die Drops haben.