Probleme mit KNXnet/IP-Tunnel und Routeranbindung

[gaert]

coliflower
So weit so "gut" - Dein Router hat ja offenbar so seine Probleme. Entscheidend ist nun: Was passiert nach dem "Fehler" (der übrigens mehr als Hinweis zu verstehen ist): Geht's normal weiter oder hagelt es Fehler (wie mit dem anderen Stack)?

[coliflower]

OK, die erste Fehlermeldung ..

FehlerLog:
2016-01-26 20:48:56 858099 KNX 15063 ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (ACK): Ist-Wert=13, Soll-Wert=14 / Raw: 06100420001704020d002900bce0111503050300800770 ERROR

TraceLog:
2016-01-26 20:48:55 945362 KNX 15063 ROUTER @ DE | TUNNELING_REQUEST:L_Data.ind / Typ: Write / SeqCounter: 13 (13) / PA: 1.1.21 / GA: 0/3/5 = 19.04 / Raw: 06100420001704020d002900bce0111503050300800770 Ok

2016-01-26 20:48:55 945472 KNX 15063 EDOMI @ DE | TUNNELING_ACK / Raw: 06100421000a04020d00 Ok

2016-01-26 20:48:56 857985 KNX 15063 ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (ACK): Ist-Wert=13, Soll-Wert=14 / Raw: 06100420001704020d002900bce0111503050300800770 ERROR

2016-01-26 20:48:56 858266 KNX 15063 EDOMI @ DE | TUNNELING_ACK / Raw: 06100421000a04020d00 Ok

[stefan.gey]

gaert

So läuft es bei mir mit einem Siemens N148/2x seit Jahren ohne Probleme:

...
CEMIConnectionRequest request = new CEMIConnectionRequest(packet.ServiceType, packet.Body);
if(request.ChannelId == this.channelId)
{
    byte received = request.SequenceCounter;
    byte expected = this.receiveSequenceCounter;

    if(received == expected || received == expected - 1)
    {
        byte[] ack = new CEMIConnectionAck(this.connectionTypeInfo.Ack, this.channelId, received, ErrorCode.NoError).ToArray();
        Send(ack);

        if(received == expected)
        {
            this.receiveSequenceCounter++;
            if(this.OnFrameReceived != null)
                this.OnFrameReceived(this, request.Data);
        }
    }
}
...

D.h. mein eigener Counter wird nur erhöht, wenn der empfangene und erwartete gleich sind.

[coliflower]

Bis jetzt scheint es zu laufen … https://knx-user-forum.de/forum/proj...319#post905319

[basaltnischl]

Ich komme leider erst Donnerstag zum testen, da gerade Beruflich unterwegs.

[gaert]

Ok, ich lade die Datei mal auf GoogleDrive hoch (proc_knx.php.zip) im Ordner "test".

WICHTIG:
Die Datei natürlich zunächst entpacken. Dann die Datei proc_knx.php in folgenden Ordner kopieren: /usr/local/edomi/main/proc (die alte Datei kannst Du ja umbenennen, sonst wird die Datei überschrieben).

WIRKLICH WICHTIG:
Die Übertragung der Datei per FTP muss UNBEDINGT im Binary-Modus erfolgen!! Viele FTP-Clients denken "Ah, eine php-Datei! Also ASCII!" - die Datei ist aber KEINE gewöhnliche PHP-Datei, sondern eine binäre Datei (kompiliert). Eine Übertragung im ASCII-Mode zerstört die Datei und EDOMI startet nicht mehr!

[gaert]

Ich erkläre es mal etwas detailierter:

Dein Router empfängt vom Bus ein Telegramm und teilt EDOMI dies über IP mit:

ROUTER @ DE | TUNNELING_REQUEST:L_Data.ind / Typ: Write / SeqCounter: 186 (186) / PA: 1.1.1 / GA: 0/0/1 = 2016-01-26

Und dann noch ein weiteres Telegramm:

ROUTER @ DE | TUNNELING_REQUEST:L_Data.ind / Typ: Write / SeqCounter: 187 (187) / PA: 1.1.26 / GA: 0/3/3 = 20.46

Das nächste Telegramm ist plötzlich fehlerhaft, weil der SeqCounter nicht korrekt ist (hat den selben Wert wie das Telegramm zuvor, nämlich 187):

ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (ACK): Ist-Wert=187, Soll-Wert=188

Laut Spezifikation muss EDOMI dieses "Telegramm" bestätigen (ACK) und anschließend verwerfen (sprich: nicht auswerten). Das macht EDOMI natürlich auch. Die Frage ist jetzt allerdings: Wie geht's weiter - soll EDOMI nun den SeqCounter trotzdem erhöhen oder nicht?
Dazu hüllt sich die Spec in Schweigen. Ich werde mal folgendes versuchen: Wenn so ein Fall eintritt, wird der interne SeqCounter NICHT erhöht, sondern bleibt wie er ist.
In diesem Beispiel bedeutet das also: Router sagt 187, EDOMI erwartet aber 188 (was ja auch korrekt wäre). EDOMI ACKed das Telegramm, erwartet aber als nächstes nicht(!) die 189, sondern die 188. Dein Router sendet nämlich anschließend den Wert 188, statt sich dem EDOMI-Counter anzupassen:

ROUTER @ DE | TUNNELING_REQUEST / ErrMsg: SequenceCounter abweichend (ACK): Ist-Wert=188, Soll-Wert=189


Leider kann ich das nicht wirklich testen, da diese Phänomene bei mir nicht auftreten... Ich kann Dir aber den angepaßten KNX-Stack als Datei schicken - den müsstest Du dann händisch kopieren (als Test!).

[basaltnischl]

Bei mir sieht es genau so aus

der SeqCounter stimmt irgendwann nicht mehr und der Router wiederholt den Tunneling_Request dann immer wieder

Könnte aber was mit dem Gira Router zu tun haben, da ja coliflower auch den den Gira Router hat

[gaert]

Wie vermutet - der SeqCounter stimmt irgendwann nicht mehr und der Router wiederholt den Tunneling_Request dann immer wieder (bist Du die Sache offenbar beendest).

Ich werde nochmal in die Spec abtauchen um zu ermitteln, was man da machen kann. Denn anscheinend korrigiert der Router seinen Fehler nicht selbst, sondern hofft darauf, dass der Client (EDOMI) sich dem SeqCounter des Routers gefälligst anpasst.

Ich kann derartige Dinge halt immer nicht praktisch nachvollziehen, da es keinerlei Probleme bei mir gibt... Es gibt aber durchaus auch fehlerhaft implementierte Router-Firmware - siehe Starwarsfan...

[starwarsfan]

Das Trace .. ich musste das zip in pdf umbenennen um es hoch zu laden

Das ist aber seltsam, der Upload eines Zip hat bei mir gestern problemlos geklappt!? Anyway, ist ein anderes Thema...

[coliflower]

Das Trace .. ich musste das zip in pdf umbenennen um es hoch zu laden … bitte von pdf auf zip ändern
DANKESCHÖN

[coliflower]

DANKE, hier die Logik + Trace

Bildschirmfoto 2016-01-26 um 12.26.14.png

[gaert]

So pauschal kann ich dies nicht beantworten - das hängt von vielen Faktoren ab:
Für den SequenceCounter ist allein der Router verantwortlich - wenn dieser sich "verzählt", liegt irgendein Problem auf KNX/Router-Seite vor. Vielleicht ist Deine Logik selbst aber auch nicht korrekt. Oder beides

Ein TraceLog wäre u.U. nützlich, vielleicht liegt das Problem ja auch ganz woanders.

Wie gesagt: Die Spezifikation schreibt das Verhalten von EDOMI (s.o.) genau so vor - ohne Spielraum für Interpretationen:

If a KNXnet/IP Tunnelling Client receives a frame with a sequence number that equals the expected sequence number then it shall reply with a TUNNELLING_ACK (Status = E_NO_ERROR) frame and process the received frame.

If a KNXnet/IP Tunnelling Client receives a frame with a sequence number that is one less than the expected sequence number then it shall reply with a TUNNELLING_ACK (Status = E_NO_ERROR) message and discard the received frame.

If a KNXnet/IP Tunnelling Client receives a frame with a sequence number that is not equal to the expected sequence number and not equal to one less than the expected sequence number, the KNXnet/IP Tunnelling Client shall not reply and shall discard the received frame.

[coliflower]

Kann es seine dass aufgrund dieser Einträge „Sequence-Counter“ (was auch immer für diese Verantwortlich ist), meine Logik (Alle Lichter AN/AUS) nicht mehr funktioniert ?

Ich habe immer, wenn diese Einträge in der LOG aufschlagen, eine falsche Rückmeldung über den Status … z.B. mehrere oder alle Lichter sind an, trotzdem zeigt der Status „alles GRÜN“ ...

Bin ein wenig weil ich mich auf die LOGIK in Edomi derzeit nicht verlassen kann ..

[gaert]

Ganz einfach: Die Spezifikation schreibt vor, dass ein "Telegramm" erst geACKed und dann verworfen(!) werden soll, wenn der Sequence-Counter um 1 geringer ist, als der Sollwert. Nichts anderes macht EDOMI: Telegramm wird geACKed und nicht weiter berücksichtigt.

Das ist aber nicht unbedingt ein Grund zur Sorge: Dieser Sequence-Counter ist quasi ein sehr einfacher Kontrollmechanismus zur Überprüfung ob ein "Telegramm" korrekt ist oder nicht (so in etwa). Falls also hin und wieder mal ein solcher "Fehler" (es ist eigentlich kein Fehler, sondern mehr ein Hinweis) auftaucht ist dies nicht weiter schlimm. Der Router weiß ja bescheid und wiederholt das Telegramm entsprechend.

Es ist aber natürlich ein Indiz dafür, dass irgendwas in der Kommunikation instabil ist (Netzwerk, Buslast, Störeinflüsse auf die Busleitungen). Ich habe diesen "Fehler" seit ca. 1/2 Jahr nur 2 mal erleben dürfen.