Nilay Das

Hi, I see that in BACnet IP "Max APDU Length Accepted" is 1476. However, if we calculate backwards from what is standard Ethernet frame size it mismatches. 1518 = Max MTU i.e. Ethernet frame size. 42 = Ethernet Header + IP header + UDP header 4 = BVLC 2 = NPDU unicast Note: I didnt add the preamble (7 bytes) and delimiter (1 byte) of ethernet frame in the above calculation. If we calculate 1518 - 42 - 4 - 2 = 1470. Which is lesser than APDU size 1476. In such case if we pack a full frame APDU, wont...

Hi, I am seeing a functionality in the stack where, I specified the CoV increment = 2 and subscribe an object. I am changing the value making sure the "delta" / change remain below CoV increment. However, I see that after certain time Yabe suddenly received latest present value. When I look at the MSTP captured log I found that there is an unconfirmedCoVnotification sent from the device to Yabe with current present value. I repeated the test many times and result is consistent. for e.g. a temperature...

Hi, I am seeing a functionality in the stack where, I specified the CoV increment = 2 and subscribe an object. I am changing the value making sure the "delta" / change remain below CoV increment. However, I see that after certain time Yabe suddenly received latest present value. When I look at the MSTP captured log I found that there is an unconfirmedCoVnotification sent from the device to Yabe with current present value. I repeated the test many times and result is consistent. for e.g. a temperature...

Hi, I am seeing a functionality in the stack where, I specified the CoV increment = 2 and subscribe an object. I am changing the value making sure the "delta" / change remain below CoV increment. However, I see that after certain time Yabe suddenly received latest present value. When I look at the MSTP captured log I found that there is an unconfirmedCoVnotification sent from the device to Yabe with current present value. I repeated the test many times and result is consistent. for e.g. a temperature...

Hi, I am seeing a functionality in the stack where, I specified the CoV increment = 2 and subscribe an object. I am changing the value making sure the "delta" / change remain below CoV increment. However, I see that after certain time Yabe suddenly received latest present value. When I look at the MSTP captured log I found that there is an unconfirmedCoVnotification sent from the device to Yabe with current present value. I repeated the test many times and result is consistent. for e.g. a temperature...

Thank you Steve, We can close this discussion with conclusion that the the bug is with Wireshark version w are using. Just now tested with Wireshark Version 2.6.20. There is no malformed packet now for UnconfirmedCOVNotification. It is now confirmed that the issue is with Wireshark version we are using. Wireshark Version 3.4.3 (v3.4.3-0-g6ae6cd335aa9) Wireshark Version 3.0.6 (v3.0.6-0-g908c8e357d0f) Note - bug in v2.6.20: With Wireshark Version 2.6.20, Simple-ACK to subscribeCOV will show Ethernet...

Thank you Steve, We can close this discussion with conclusion that the the bug is with Wireshark version w are using. Just now tested with Wireshark Version 2.6.20. There is no malformed packet now for UnconfirmedCOVNotification. It is now confirmed that the issue is with Wireshark version we are using. Wireshark Version 3.4.3 (v3.4.3-0-g6ae6cd335aa9) Wireshark Version 3.0.6 (v3.0.6-0-g908c8e357d0f) Note - bug in v2.6.20: With Wireshark Version 2.6.20, Simple-ACK to subscribeCOV will show Ethernet...

Thank you Steve, We can close this discussion with conclusion that the the bug is with Wireshark version w are using. Just now tested with Wireshark Version 2.6.20. There is no malformed packet now for UnconfirmedCOVNotification. It is now confirmed that the issue is with Wireshark version we are using. Wireshark Version 3.4.3 (v3.4.3-0-g6ae6cd335aa9) Wireshark Version 3.0.6 (v3.0.6-0-g908c8e357d0f) Note - bug in v2.6.20: With Wireshark Version 2.6.20, Simple-ACK to subscribeCOV will show Ethernet...