BACNET_BDT_ADDR_1 - dotted IPv4 address of the BBMD table entry 1..128
BACNET_BDT_PORT_1 - UDP port of the BBMD table entry 1..128 (optional)
BACNET_BDT_MASK_1 - dotted IPv4 mask of the BBMD table
entry 1..128 (optional)
Added environment variable to allow setting of the public NAT address.
BACNET_IP_NAT_ADDR - dotted IPv4 address of the public facing router
When a packet is received which expects a reply a copy is stored in the PDU ring buffer so it can be matched with the reply. Unfortunately when the reply is received it is only checked against the first entry in the ring buffer. This can cause a failure if a second packet expecting a reply has been received while waiting for the first reply to arrive.
This is a known issue in the bacnet-stack open source stack, and there is a outstanding FIXME in the latest version of the source code:
/* The ANSWER_DATA_REQUEST state is entered when a */
/* BACnet Data Expecting Reply, a Test_Request, or */
/* a proprietary frame that expects a reply is received. */
/* FIXME: MSTP_Get_Reply waits for a matching reply, but
if the next queued message doesn't match, then we
sit here for Treply_delay doing nothing */
The fix for this is to check all the messages in the PDU queue to see if any of them match, and if one does then handle it in the normal way. Thank you to Ian Smith of Abelon Systems Ltd. for the patch!
Added BACnet/IPv6 datalink layer and example BACnet/IPv4 to BACnet/IPv6 router.
BVLC6 layer is working on Linux port without BBMD features yet. Win32 is implemented, untested.
Tested during BACnet North American Plugfest 2016.
........
Added checks for OPTIONAL context tagged decoding to be sure it is not a closing tag.
Added makefile for unit test in bacdevobjpropref.c module, and improved unit test.
https://sourceforge.net/p/bacnet/bugs/49/
........
Implemented the majority of functionalities presented in the standard, but there are several features that this patch currently lacks:
- Set-Master-Key message has a specific order of key adding and decoding which is not covered
- There is no general secure-apdu-handler function
- Checks for the type of keys used for signing/encryption of specific messages is not implemented
- The status of encrypted flag during the calculation of the signature is ambiguous
There is a Linux implementation using the OpenSSL library, with function prototypes broad enough to allow for different implementations.
Thank you, Nikola Jelić!
skarg