[jira] [Commented] (PLC4X-210) [KNX] When running a KNX Tunneling Subscription for a longer time there are packets that kill the connection

["Christofer Dutz (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PLC4X-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17155550#comment-17155550 ] 

Christofer Dutz commented on PLC4X-210:
---------------------------------------

It turns out I was creating a KNX Tunnel-Busmonitor connection as I was using the ETS5 Busmonitor to create the first version of the KNX driver. In this mode all data on the bus seems to be transported (Possibly also corrupt packages). I changed the driver to be more robust against such failures, but switched it to use a Tunnnel Link-Layer connection instead. This has the benefit of making the client a full member of the KNX bus and it seems to eliminate the problems due to corrupt packages on the bus.

> [KNX] When running a KNX Tunneling Subscription for a longer time there are packets that kill the connection
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: PLC4X-210
>                 URL: https://issues.apache.org/jira/browse/PLC4X-210
>             Project: Apache PLC4X
>          Issue Type: Bug
>          Components: Driver-KNX
>    Affects Versions: 0.7.0, 0.8.0
>            Reporter: Christofer Dutz
>            Assignee: Christofer Dutz
>            Priority: Major
>             Fix For: 0.8.0
>
>
> Every now and then comes a packet, the driver seems to be unable to process. In this case the driver just dies. It seems the gateway is expecting some sort of response and after not getting it, it cancels the connection.
>  
> Luckily the driver outputs the package he was not able to decode:
> {code:java}
> 0610042000180404ce00 2b0703010404025002 bab8b838bb
> 061004200018047ddf00 2b0703010404020702 9f9c9c9cdc
> 0610042000180401c200 2b0703010304025601 bab8b838bb
> {code}
> It looks as if these messages are too short (they actually end after the expected targetAddress however the decoded source and destination address seem garbled, so I would assume something's not quite correct here.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)