Activity for TCNOpen
-
Thorsten posted a comment on ticket #448
I would consider the sc-32 handling in the spy as broken, or to the least not finished. Firstly, I just spent a day to find a reliable source how to calculate the sc-32 correctly. The standard has an example value for "123456789", which is wrong, as it relates to the AUTOSAR crc, which from what I understand, uses different data reflections ... I think. The testcase in tcnopen isn't any help either, as it is not checking against an expectation. Couldn't find any examples for Profisafe neither, and...
-
@John I cannot remember whether this was a bug that I fixed. Alternatively, did you accidentally set the dissector preference? You can choose between LE and BE interpretation, see screenshot 2. If this does not work as in the screen shots, you'll have to wait for the spy to respawn with the latest fixes in upstream-wireshark. It may be 4.7 or 4.8 ... And thanks for providing the attachments.
-
MD messages look better in the latest updates (once they go public). I think it might had an issue with packet reassembly.
-
I believe this is fixed once the latest updates go upstream in wireshark
-
Aditya Kumar created ticket #476
pdCallback() only propagates TRDP_NO_ERR and TRDP_TIMEOUT_ERR; other TRDP error codes missing
-
Xavier created ticket #475
Failure to update sequence counter if sequence counter is small but not zero
-
Hi, I agree with Bryce Jensen. The current TCNOpen stack (3.0.0.0) doesn't work well with multiple ip addresses per interface.
-
davidwang posted a comment on ticket #464
Thank you @ahweiss BTW, Do you know whether IEEE 802.1Qbv is still applicable to intra-consist networks?
-
Armin-Hagen Weiss modified ticket #464
Remove compiler switch TSN_SUPPORT and related dead code
-
Hi @ahweiss Could you please clarify whether this means that all TSN-related components in the TRDP code are no longer in use, such as TSN PD and TRDP version 2? If this is the case, it would represent a major change. Will the TSN-related content in IEC 61375-2-3 Edition 2 also be entirely removed?
-
We don't agree with the change proposed in #463, and think that the current behaviour is correct! The author of the ticket hasn't taken the resultCode included as part of the PD callback into the consideration. If there a timeout for any PD subscriber, the callback with TRDP_TIMEOUT_ERR result code has the 'last received' sequence counter and 'last received' data. If I take different examples, considering that the successive rows happen chronologically after 1 second and timeout is 3 seconds for...
-
We don't agree with the change proposed in #463, and think that the current behaviour is correct! The author of the ticket hasn't taken the resultCode included as part of the PD callback into the consideration. If there a timeout for any PD subscriber, the callback with TRDP_TIMEOUT_ERR result code has the 'last received' sequence counter and 'last received' data. If I take different examples, considering that the successive rows happen chronologically after 1 second and timeout is 3 seconds for...
-
We don't agree with the change proposed in #463, and think that the current behaviour is correct! The author of the ticket hasn't taken the resultCode included as part of the PD callback into the consideration. If there a timeout for any PD subscriber, the callback with TRDP_TIMEOUT_ERR result code has the 'last received' sequence counter and 'last received' data. If I take different examples, considering that the successive rows happen chronologically after 1 second and timeout is 3 seconds for...
-
We don't agree with the change proposed in #463, and think that the current behaviour is correct! The author of the ticket hasn't taken the resultCode included as part of the PD callback into the consideration. If there a timeout for any PD subscriber, the callback with TRDP_TIMEOUT_ERR result code has the 'last received' sequence counter and 'last received' data. If I take different examples, considering that the successive rows happen chronologically after 1 second and timeout is 3 seconds for...
-
We don't agree with the change proposed in #463, and think that the current behaviour is correct! The author of the ticket hasn't taken the resultCode included as part of the PD callback into the consideration. If there a timeout for any PD subscriber, the callback with TRDP_TIMEOUT_ERR result code has the 'last received' sequence counter and 'last received' data. If I take different examples, considering that the successive rows happen chronologically after 1 second and timeout is 3 seconds for...
-
We don't agree with the change proposed in #463, and think that the current behaviour is correct! The author of the ticket hasn't taken the resultCode included as part of the PD callback into the consideration. If there a timeout for any PD subscriber, the callback with TRDP_TIMEOUT_ERR result code has the 'last received' sequence counter and 'last received' data. If I take different examples, considering that the successive rows happen chronologically after 1 second and timeout is 3 seconds for...
-
We don't agree with the change proposed in #463, and think that the current behaviour is correct! The author of the ticket hasn't taken the resultCode included as part of the PD callback into the consideration. If there a timeout for any PD subscriber, the callback with TRDP_TIMEOUT_ERR result code has the 'last received' sequence counter and 'last received' data. If I take different examples, considering that the successive rows happen chronologically after 1 second and timeout is 3 seconds for...
-
Inconsistency for returned sequence counters after a timeout
-
I don't agree with the change proposed in #463, and think that the current behaviour is correct! I think the author of the ticket hasn't considered the resultCode included as part of the PD callback into the consideration. If there a timeout for any PD subscriber, the callback with TRDP_TIMEOUT_ERR result code has the 'last received' sequence counter and 'last received' data. If I take different examples, considering that the successive rows happen chronologically after 1 second and timeout is 3...
-
TCNOpen released /TRDP/3.0.0.0/3.0.0.0.zip
-
-
-
-
-
-
-
-
-
Not all session parameters for PDs and MDs updated by tlc_configSession()
-
Session parameters for PDs and MDs not updated
-
Receiving ECSP Status PD over multicast instead of unicast
-
Regarding KEEP behaviour after PD Timeout
-
Incomplete check in vos_netIfUp for DSA switch attached interfaces
-
Implemented like proposed, Test pending.
-
#462 Incomplete check in vos_netIfUp for DSA switch attached interfaces
-
Session parameters for PDs and MDs not updated
-
#466 Potential null pointere dereference
-
Potential null pointere dereference
-
No problem, thanks for Your contribution ! INow NULL pointer check of pNumJoinis done before valid session check.
-
tlc_configSession() should be removed from the API. Session configuration should be done only once with tlc_open Session(),
-
#464 Remove compiler switch TSN_SUPPORT and related dead code
-
Remove compiler switch TSN_SUPPORT and related dead code
-
#474 Error in the implementation of 'LABEL' data type
-
At network protocol level the type 16 char long TRDP_NET_LABEL_T was used due to the fact that in a earlier protocol version rhe lpavel at network level was not necessarily \0 terminated. Therefore at TRDP stack api level TRDP_LABEL_T was used which was 17 char long and included always \0 termination, Today the \0 termination of a label is also required at network level. Thus the code was changed now to use at api and network level only TRDP_LABEL_T containig 16 char including \0 termination.
-
Error in the implementation of 'LABEL' data type
-
At network protocol level the type TRDP_NET_LABEL_T is used which is 16 char long and might not be 0 terminated. In TRDP stack TRDP_LABEL_T is used which is 17 char long and always 0 terminated, I'll check if that can be changed in 61375-2-3 2nd edition.
-
Error in the implementation of 'LABEL' Data Type causing issues with TRDP_DNS_REQUEST_T and TRDP_DNS_REPLY_T
-
At network protocol level the type TRDP_NET_LABEL_T is used which is 16 char long and might not be 0 terminated. In TRDP stack TRDP_LABEL_T is used which is 17 char long and always 0 terminated, I'll check if that can be changed in 61375-2-3 2nd edition.
-
Error in the implementation of 'LABEL' Data Type causing issues with TRDP_DNS_REQUEST_T and TRDP_DNS_REPLY_T
-
Size mismatch of VOS_IF_REC_T between source and header on Linux
-
Implemented like proposed.
-
#470 Size mismatch of VOS_IF_REC_T between source and header on Linux
-
#470 Size mismatch of VOS_IF_REC_T between source and header on Linux
-
DNR not working if DNS Server is different than TTDB Manager
-
Solved with #472
-
Add option for a preconfigured ECSP address
-
#472 Add option for a preconfigured ECSP address
-
Muntasir Hossain created ticket #474
Error in the implementation of 'LABEL' Data Type causing issues with TRDP_DNS_REQUEST_T and TRDP_DNS_REPLY_T
-
Stefan P created ticket #473
DNR not working if DNS Server is different than TTDB Manager
-
Add option for a static ECSP address
-
Add TRDP option to forbid reusing ports/sockets for MD only
-
TRDP_OPTION_T changed to UINT16 and new option TRDP_OPTION_NO_REUSE_MD_ADDR added
-
Version updated
-
#471 Add TRDP option to forbid reusing ports/sockets for only MD
-
Add TRDP option to forbid reusing ports/sockets for only MD
-
Manuel Borelli created ticket #470
Size mismatch of VOS_IF_REC_T between source and header on linux
-
SDTv2 original release 2.4.0.1
-
SDTv2 code to be replaced by original one from SDTv2 release 2.4.0.1
-
SDTv2 source code replaced by the original one from SDTv2 release 2.4.0.1
-
-
SDTv2 Release 2.4.0.1
-
-
Chirag Khangani posted a comment on ticket #468
Committed code change in r2463
-
Committed code change in r2462
-
#468 Regarding KEEP behaviour after PD Timeout
-
#469 Receiving ECSP Status PD over multicast instead of unicast
-
SDTv2 Wrong Latency Monitoring in case of SDT_ERR_LOSS (and others)
-
Wrong self acknowledgment of LTM after Trxsafe
-
Multiple validator with same SMIs
-
SDTv2: Format of User Data Version parameter
-
SDTv2: Format of User Data Version parameter
-
Regarding KEEP behaviour after PD Timeout
-
Receiving ECSP Status PD over multicast instead of unicast
-
Receiving ECSP Status PD over multicast instead of unicast
-
Regarding KEEP behaviour after PD Timeout
-
Kari Keinanen posted a comment on ticket #438
Hi. We also faced this issue, here is a patch proposal. Best regards, -Kari-
-
Lorenzo Buzzi created ticket #467
Session parameters for PDs and MDs not updated
-
Maybe I assigned this ticket to the wrong milestone. In such case I apologize and please change the assignment to the right value.
-
Understood Thank you for the explanation.
-
Potential null pointere dereference
-
MD telegram added for testing
-
remove unused items in trdp_config. xsd
1 >
