From firmware version 4.x, BACRouter has builtin Modbus gateway functionality. This article will try to explain the underlying mechanism.
BACRouter will periodically read point’s value and cache it. “Update interval” defines how often BACRouter update the value.
To improve performance, BACRouter will read as more as possible data in one transcation. In Modbus standard, at most 2000 bits (coil or discrete) or 125 registers (input or holding register) could be read in one request, but specific Modbus slave device may only support a lower value. In BACRouter’s WebUI, there is a Modbus parameter edit dialog in “Slave Settings”, “Multiply read bits” and “Multiply read registers” parameters define the ability of the slave device.
BACRouter will not segment reading of single point even the “Multiply read registers” is less than registers used by the point.
Usually the data we care for has discontinuous Modbus address, for example, We only care for coils on address 1 and 2000, though we could read coil data from address 1 to 2000 in one request and skip returned data from address 2 to 1999, sending two requests independently for coil on address 1 and coil on address 2000 maybe more efficient. “Bits skipped” and “Registers skipped” parameter define how many unused data units between 2 cared data units are allowed to be skipped. As previous example, if “Bits skipped” is set to 1998, the BACRouter will try to read coil 1 and 2000 in single request. If “Bits skipped” is set to 1997, then BACRouter will read Coil 1 first, then Coil 2000, because bits skipped is 1998 and is greater than the setting of 1997.
On the WebUI page for slave, the “Read Group” button will show how the BACRouter will group the reading and test it. User should pay special attention on server exception of “Illegal data address”.
BACRouter will not combine multiple writing demand into one writing request. It always queue write request immediately after receiving command.
For writing single data unit, there are two Modbus function codes available. For example, function code 5 is writing single coil, function code 15 is writing multiple coils but the quantity of coil to write could be assigned to 1. Some devices only support one of them. “Coil write singly” parameter will specify which function code is used.
In the same way, “Register write singly” is applied to register writing. If any BACnet output object maps to multiple holding registers, it implies the slave device support function code 16 for write multiple registers, “Register write singly” will be automatically disabled, function code 16 will be used for writing any register.
If any read/write request failed, BACRouter will retry it, when the continuous fail count reachs 3, BACRouter will regard the slave device as offline. In offline state, BACRouter will retry the request every “Offline update interval”.
The BACnet side reaction for offline event will be described later.
Modbus Serial Bus
BACRouter supports serial slave devices with different baudrate, parity, RTU/ASCII mode on same RS485 bus. Before sending request, BACRouter will change it serial port parameter based on slave device’s settings.
It should be safe to have 2 devices with same slave address but different baudrate or RTU/ASCII mode, but preventing collision based on different parity might not be enough, because some devices do not examine parity error.
Single Device Mapping Mode
If VBUS network port is not enabled, BACRouter will work in single device mapping mode, every Modbus slave device will be mapped into exclusive object instance space of 1000 in the only BACnet device defined in “Application Settings”.
The actual BACnet object name will be organized as “master_name|slave_name|object_name”, The “|” is name delimiter which could be selected from dozen of characters by user.
As recommended by standard, BACRouter will create one StructuredView object for each slave device.
When the slave device turn to offline in this mode, all points’ reliability will be set to “COMMUNICATION_FAILURE”, if slave device is back to online, upon updating of point value, the point’s reliability will be set back to “NO_FAULT_DETECTED”.
Virtual Device Mapping Mode
If VBUS network port is enabled. Each slave device will be mapped to a virtual BACnet device on VBUS network. The MAC address will start from 1.
In this mode, each slave shall has a unique “Device instance”. The BACnet device name of the slave will be “master_name|slave_name”, The delimiter “|” is select-able.
When the slave device turn to offline in this mode, as recommended by standard, the virtual BACnet device will stop sending/receiving any packet to simulate offline state. if slave device is back to online, after updating all point’s value, the virtual BACnet device will quite offline state.
Slave Device’s Status
For every slave device, BACRouter will create 3 objects in gateway device, one object is Binary_Input with name of “online”, which represents online/offline status of slave device. another object is Analog_Input with name of “update_delay”, which is recently average update time delayed over “”Update interval”, the last one is Analog_Input with name of “fail_rate”, which count a relative long time fail rate on Modbus side.
Those objects’ name have prefix of “master_name|slave_name|comm|”, where “|” is select-able delimiter.
Object Instance Assignment
Object Instance is defined for every object. When the editor dialog for a object is submitted and the object is enabled, the object instance claimed by the object will be assigned, if that assigning fail, a automatically selected instance will be used.
AV/BV/MV is behaving same as AI/BI/MI, except that when AV/BV/MV is mapped to writable Modbus address (0X or 4X), the present value of the object is writable, the writing will be forwarded to Modbus side (See below 2 exceptions).
Exception 1: If AV is mapped to holding register, its data type is customized, but the binding script doesn’t support output, that AV will be read only.
Exception 2: If AV is mapped to multiple holding registers, but the”Register write singly” option is enabled, that implies output will not be supported, so the AV will be read only.
The value of output object is still being polled from Modbus side and set to object’s Relinguish_Default property. If the value read back does not match last value written, BACRouter will set the reliability of that object to “UNRELIABLE_OTHER”, and BACRouter will queue another write after a certain time. When “Tolerate unmatch” option is enabled, If the value read back does not match last value written, the reliability of that object keeps unchanged, and BACRouter will re-write the value on “Offline update interval”. (Update for v4.34)
Because of above verifying mechanism, the BACRouter will prevent defining two output objects with overlaping Modbus writable address.
NaN For Float And Double
NaN is a special value defined by IEEE-754, BACRouter does not accept NaN (Infinite is still valid for BACRouter).
When a point is defined as Float and Double, but NaN is read from slave, BACRouter will set the reliability to “UNRELIABLE_OTHER”.
Unsupported value for script
When a analog object is customized, but the Modbus to BACnet conversion reports unsupported value from the script, that object’s reliability will be set to “UNRELIABLE_OTHER”.
For a Analog Output object, when the BACnet to Modbus conversion reports unsupported value from the script, the object’s reliability will be set to “PROCESS_ERROR”
For a Analog Value object, when the BACnet to Modbus conversion reports unsupported value from the script, that output attempt will be dropped, the object’s reliability will be unchanged.
Original BACnet MS/TP data link specification only supports NPDU length up to 501 bytes, which is much shorter than 1497 bytes of Ethernet and IP data link. It limits transmission performance, increases complexity on application layer, especial when two IP/Ethernet networks are conjoined by a MS/TP network.
Frame type 32 is extended from frame type 5 (BACnet Data Expecting Reply), the special of it is that it is encoded by COBS and the NPDU length it carried is in range of 502 to 1497 bytes.
In the same way, frame type 33 is extended from frame type 6 (BACnet Data Not Expecting Reply)
Extended frame support was added into BACnet standard since revision 16. There are still lot of devices installed or on the market that do not support it. The interoperability between extended frame capable devices and legacy device is discussed below.
Non-router legacy device and extended frame capable device: Because all messages sent to legacy device are application layer message, the “Max APDU Length Accepted” from Device object property or confirmed service request primitive should be respected, the NPDU length will not exceed 501 bytes. So there are no problem with this configuration.
Legacy router and extended frame capable device: NPDU that should be relayed to other network through legacy router with length over 501 bytes will be discarded, no reject-message-to network with reason “Message Too Long” will be responded. Even more, the “Max APDU Length Accepted” of legacy router may be determined by other port that has a NPDU length larger than 501 bytes (It is allowed by standard), so NPDU for local application layer sent to legacy router will still possibly be carried by extended frame and discarded. So this configuration may cause problem in field.
BACRouter supports extended frame from very early version. From firmware version 3.18, we introduced “Extended frame” option on BACRouter’s MS/TP configuration, if there are legacy router that does not support extended frame on the bus, this option should be disabled to avoid Interoperability issues.
It’s worth noting that even “Extended frame” option is disabled, unlike legacy router, BACRouter will still be interoperable with extended frame capable devices.
（Screenshot has been updated on Aug 5, 2021. Because extended frame is mandatory from standard revision 16, from firmware 4.13, we move this option to extended configure mode.)
Update on 2020-11-20 (Appended info. about JCI module)
MSTP baudrate is always painful for field technician. If the baudrate is wrong, device can’t join a MSTP bus.
Most devices have fixed baudrate. To modify the baudrate setting, technician have to physically access the device and change dip switches. Some devices support changing baudrate by BACnet service. but before that they should already have correctly baudrate setting for BACnet service to access it.
Some vendors implement auto baudrate, but introduce more problem than it solves. There are two types of auto baudrate mechanism:
Starting detection: The device detects and adopts baudrate on the bus when it starts. then never changes baudrate.
Dynamic detection: The device does same as starting detection type when it starts, but if it find there are error on bus for a predefined time, it considers that the baudrate is changed, it detects baudrate again.
For both types, it is difficult to change baudrate when devices is working. Simply changing baudrate on all fixed baudrate devices can not work, because auto baudrate devices are still working on old baudrate. The solution is to power off all auto baudrate devices, then power on all auto baudrate devices（Don’t power off/on auto baudrate devices one by one)
Our new firmware(>=2.0) introduces new baudrate management mechanism(Patent pending). There are 3 types of baudrate mode for BACRouter : Fixed/Auto/Force:
Fixed baudrate mode works as most traditional devices.
Auto baudrate mode is same as above-mentioned dynamic detection. The predefined time to re-initiate detection is 10 error frames, it usually take several seconds.
Forced baudrate mode is same as auto mode except that when the device get token, it changes baudrate to predefined value.
When there is a device with forced baudrate mode, the baudrate on the bus will be forced to predefined value. Devices with auto baudrate mode will automatically synchronize to predefined baudrate. Devices with fixed baudrate mode but baudrate setting different with predefined value will not be seen on bus (It’s easy to check out in “Recent active devices” field from BACRouter’s runtime info). Devices with starting detection type may run on wrong baudrate, they will not be seen on bus too, but powering off/on them one by one will synchronize them to forced value.
More than one device with forced baudrate mode could coexist on a bus, but the baudrate values on them should be same.
JCI FEC/IOM modules implements baudrate dynamic detection mechanism, the re-detect interval is about 150 sec on the test.
On a test bus , BACRouter cooperate perfectly with FEC2611, IOM3731, the baudrate is dynamically controlled by BACRouter from 9.6k ~ 76.8k, FEC2611 and IOM3731 will catch up after 2.5 minutes.
From firmware ver2.0, BACRouter introduced new “Max_info_frames by token occupy time” feature.
In BACnet standard of MSTP, a master device could hold token until it has sent frames up to Max_info_frames. The default value of Max_info_frames is 1. But for router, this value may be increased to improve bandwidth between networks. Mostly the suggested value for router is between 5 to 20.
MSTP works as a field bus for controllers; sensors and actuators. The data exchanging latency between devices usually should be guaranteed. We recommend devices get token at least every 1 second.
The APDUs passing router usually have size between 10~50 bytes, but could be up to 480 or 1476 (Extended frame). Larger APDU need more time to send or receive.
For APDU which need a reply from targeted device, router has to wait for reply. Usually the targeted device need more time to handle or generate larger APDU, router has to wait longer.
So the time router holding token could be varied much, which impacts latency guaranty of MSTP bus. To avoid this problem, “Max_info_frames by token occupy time” feature limits router’s token holding time.
The limitation is calculated by:
byte_time * 32 * Max_info_frames
For example, Max_info_frames is set to 10. The baud rate is 76800bps, so the byte_time is 0.13 milliseconds:
0.13 * 32 * 10 = 41.6 milliseconds.
When router founds it have held token for 41.6 milliseconds, it passes token to next station, though the frames it sent may be less than 10.
This feature could be enabled/disabled by user from WebUI.
Because the same time online for all devices could not be guaranteed, there is no auto addressing solution could avoid MAC conflict. We remove this feature on firmware 3.x. To help determine max_master and unused MAC on bus, “Sniffer mode” could be enabled, then “Current max master” could be obtained from run time info. Unused MAC also could be chosen referred to “Recently active devices”.
Every device on a MSTP bus should have a unique MAC address. For master device, the available address range is 0~127, and 128~254 for slave device.
Usually MAC address is set by DIP switch, jumper, LCD screen, firmware downloaded by configuration tools. Some devices support MAC address modification through BACnet object/property, but before doing that, it should have a valid MAC address to join BACnet network.
If the unique MAC address could be automatic obtained like we get IP address just by plugging notebook into home/office network, it would save a lot of time in commission.
“Zero-Config” only works on fixed configuration that Max-master is 127 and automatic assigned address range is 64~127. If not, it may cause mess.
To avoid above limitation, BACRouter implements proprietary auto addressing solution and keep compatible with “Zero-Config”. It has some attractive features:
Learning Max-master from bus traffic.
Assigning MAC address from highest unused one.
So users have more freedom on MAC address schema, For example, leave address 0~30 for fixed address devices, set Max-master as 40, so automatic addressing devices would use 31~40.
Both Zero-Config and BACRouter’s solution have trouble when a automatic addressing device is pulled out bus then plugged in again without reboot, because a new attached automatic addressing device would occupy the same address.(BACRouter is more weak in such situation because of it’s predictable address assigning), So
ALWAYS power on automatic addressing device after attaching to bus.
But what is BACRouter’s solution to this problem, let’s look for the clues from the standard.
SilenceTimer: A timer with nominal 5 millisecond resolution used to measure and generate silence on the medium between octets. It is incremented by a timer process and is cleared by the Receive State Machine when activity is detected and by the SendFrame procedure as each octet is transmitted.
Tframe_gap: The maximum idle time a sending node may allow to elapse between octets of a frame the node is transmitting: 20 bits times.
Tturnaround: The minimum time after the end of the stop bit of the final octet of a received frame before a node may enable its EIA-485 driver: 40 bits time.
Tpostdrive: The maximum time after the end of the stop bit of the final octet of a transmitted frame before a node must disable its EIA-485 driver: 15 bit times.
9.5.5 The SendFrame Procedure
If SilenceTimer is less than Tturnaround, wait (Tturnaround – SilenceTimer).
Transmitter disable: The node shall disable its EIA-485 driver within Tpostdrive after the beginning of the stop bit of the final octet of a frame in order that it not interfere with any subsequent frame transmitted by another node. This specification allows, but does not encourage, the use of a “padding” octet after the final octet of a frame in order to facilitate the use of common UART transmit interrupts for driver disable control. If a “padding” octet is used, its value shall be X’FF’. The “padding” octet is not considered part of the frame, that is, it shall be included within Tpostdrive.
(It’s unclear that whether the Tturnaround include “padding” octet, but in 135.1 testing standard, chapter 184.108.40.206 “Verify T turnaround”: If the reference master employs a “padding” octet of X’FF’ as the last octet of every frame, then the time shall be measured starting from the trailing edge of the stop bit of the octet that precedes the X’FF’ “pad” octet in the frame transmitted by the reference master)
So in a valid frame, the maximum bus idle is Tframe_gap plus tailing bit “1” in the previous octet. it’s 29 bits time (assuming previous octet is X’FF’)
Considering “padding” octet, the minimum bus idle between 2 frames is Tturnaround – Tpostdrive + 9 (tailing bit “1” in the “padding” octet), it’s 34 bits time.
BACRouter use a revised RSM to implement previous logic:
When the time between receiving 2 sequential bytes is longer than 20 bits time, the receiving frame is aborted.
Idle time on the bus greater than or equal to 33 bits time means there is a new frame.
To be compatible with devices not respecting to Tturnaround, any data following valid frame will be regarded as new frame.
In 115200bps, one bit time is only 8.7us. To precisely measure duration of idle line, the timer granularity of BACRouter is set to only 5us. It help to resist to frame desynchronization, and reach 98.8% bandwidth utilization on 115.2kbps because BACRouter no more waste time when 40 bits Tturnaround is over.
As pointed out by previous article “BACnet MSTP frame lost synchronization” , BACnet MSTP has a design flaw on frame synchronization, but how to utilize it to perform attack and strictly obey the standard at the same time?
We make some assumptions here:
There are at least 3 devices on the bus with MAC address 1, 8,10. The device 1 is carefully designed to perform attack. Device 8 and 10 are innocent.
Device 1 supports extended frame, device 8 and 10 are not.
The timers of 3 devices is precise enough.
The work flow of device 1 is:
When get token, send out frame A
Pass token to MAC address 2
When get token again, send out frame B
Pass token to MAC address 2
goto step 1 again.
Frame A is a valid proprietary frame (hexadecimal);
Every thing will go well if there is no frame desynchronization, but after hours running, if device 8 losses synchronization with frame A header (It has same effect if device 10 losses synchronization when device 1 sends frame B) , device 8 find another frame when scan Frame A’s data portion:
For device 10, it get a valid Not-For-Us frame header, so it enter SKIP-DATA state, there is not enough data to skip, so device 10 will wait until Tframe_abort.
For device 1, it’s a BACnet-Extended-Not-Expecting-Reply frame header, because it support extended frame, so it validate header by procedure described in Addendum 135-2012an. Because the data length is too short, so it abort the frame enter IDLE state again, then find another frame:
55 ff 00 01 08 00 00 bf
It’s a token frame passing token to device 1, so device 1 get token then sending Frame B just after Tturnaround:
BACnet MSTP datalink layer frame, it has at least 8 octet bytes, including: 2 preamble bytes of 0x55 and 0xff, frame_type, destination_mac, source_mac, 2 data_len bytes, crc, and omissible data portion. We call this type of frame as “MSTP frame”.
EIA-485 frame, it is consisted of bits, including start bit, data bit, parity bit, stop bit. BACnet MSTP using non-return to zero (NRZ) encoding with one start bit, eight data bits, no parity, and one stop bit. The start bit shall have a value of zero, while the stop bit shall have a value of one. The data bits shall be transmitted with the
least significant bit first. We call this type of frame as “byte frame”.
BACnet MSTP Receive Frame Finite State Machine (hereafter refer to RSM) distinguish starting of frame by preamble bytes. If there is no DataAvailable or ReceiveError within a frame for Tframe_abort (60 bits time, but Implementations may use larger values for this timeout, not to exceed 100 milliseconds) , the frame is aborted, RSM search for next frame again.
Because preamble bytes is allowed on other portions of MSTP frame (Extended frame introduced by Addendum 135-2012an is an exception, it use COBS encoding to avoid 0x55 existing in data portion), so RSM may parse MSTP frame beginning from data portion of previous MSTP frame.
The minimum time gap between MSTP frames is Tturnaround (40 bits time), it is less than Tframe_abort, so if RSM lost sychronization of MSTP frame, it may parse the wrong MSTP frame across actual MSTP frames.
There are several cause of losing synchronization:
Program defect on sending or receiving device. It could be eleminated by code review and test.
Timer precision. BACnet MSTP standard only requires a 1% precise timer with a resolution of 5 ms or less. So it is hard to check out Tframe_abort. Because there is only 5 ms of error space between delay and timeout (Tusage_delay to Tusage_timeout, Treply_delay to Treply_timeout), it is very likely causing collisions for slow responding devices.
Noise on bus line. Noise causes byte frame error and crc error, RSM will abort previous MSTP frame in both situations.
Some may argue that MSTP frame integrity is protected by header crc8 and data crc16. Even without considering malicious devices(Here is a attack example) and random data collision, there are still applications may send valid frame in data portion.
(Updated 25 June 2021) For example, There are some products that have implemented a packet capture function on MSTP bus, then the captured data may be transferred by BACnet service (PrivateTransfer or AtomicReadFile?). What would happen if there is electronic noise on the bus when the data is passing through a MSTP network?
It is not only possible to cause MSTP bus being blocked, but also device
malfunction if the wrong frame is a APDU or break whole BACnet
inter-network if the wrong frame is a I-Am-Router-To-Network.
Byte Frame Desynchronization
For the byte frame, losing synchronization usually is caused by noise, no termination or absence of biasing. The symptoms include regarding data bit of 1 as idle line, regarding data bit of 0 as start bit of new byte. In addition to data error, the losing synchronization of last byte in a MSTP frame will introduce measure error of idle time between MSTP frames.
135-2016br-2: Accept writes of NULL to non-commendable properties.
MSTP driver reports new packets to upper layer immediately instead of a 20ms period.
Modbus script: context add point name and point description.
Modbus supports multistate objects on 2 registers.
Modbus support analog objects on part of register.
Modbus support customized analog objects on up to 24 registers.
Modus add “Tolerate unmatch” option when mapping output object. When the read back value does not match last output value, “Reliability” property keeps unchanged, Output value will be re-written on “Offline update interval”.
Modbus driver remove some over-skill optimizations: merge multiple write requests on same register to single write; cache analog conversion from Modbus to BACnet.
TCP slave report server exception may cause segment fault.
WebUI: On the Modbus slave setting page, users often incorrectly click “Edit” or “Copy” button. “Edit” button is removed, Point editing popup now could be fired by click object name or property.
A long time BACnet bug is found: Default writing priority is not set when priority is ignored in the APDU.
Modbus: BV/BO mapping to bit in holding register should refer to “Write register singly” instead of “Write coil singly” when choosing write function code.
Modbus: Extends TCP slave address(id) range from 1~247 to 0~255
Modbus bug introduced by v4.23: Offline device may increase fail-rate to online device.
WebUI: More detailed Modbus fail messages will be reported on “Read Test” and “Write Test”
WebUI: UI optimized for Modbus parameter editing.
WebUI bug introduced by v4.25: Modbus “Write Test” should not be enabled when mapping to read-only Modbus address, or BACnet object type is input.
WebUI: promote user to notice conflict of “Register write singly” setting when “Write Test” writing to multiple registers.
WebUI: enable drag&drop to move point in slave settings
WebUI: enable drag&drop to move state when editing multi-state object.
WebUI: When exporting something to a file, popup a dialog to modify file name.
WebUI bugfix: Modbus slave “Reset” button will not rollback modification of “Batch Data Address”.
WebUI: Modbus slave adds new “Reorder Instance” function to reorder object instance of points.
Total limitation for capture buffer size is changed from 16M to 12M.
WebUI bugfix: Modbus slave’s “Batch Conversion” should skip customized data type.
WebUI: Exported Modbus master/slave configuration should carry referenced script. When importing configuration, script in it will be imported too.
BIP udp port’s low limitation is lowered down to 1024.
Many bugfixs and improvements for script:
When there is a OOM, all scripts will be temporally unloaded one by one, memory reclaimed for each script will be logged. The maximum reclaimed one will be regards as leaking memory and be forcedly completely unloaded (even the byte code will be dropped), other scripts will be reloaded to run again.
WebUI adds “Runtime Info” for script to help finding memory leaking.
Script importing will go to edit mode.
New and imported script can replace old script with same name after confirmation.
We always get reports from clients about weird Modbus devices which can not be linearly converted from Modbus value to float used by BACnet analog object. so we introduce Lua script to extend BACRouter’s ability to mapping such devices.
User could import/create/edit Lua script by the WebUI. Thanking to the WASM support in modern Web browsers, User could run and debug Lua script by the WebUI, even though the Modbus device is offline. The error will be caught and promoted to user, the Lua print function will output to web browser’s console.
As a result, BACRouter drops support for IE, but Edge will still work.
From v4.23, we abstract Modbus rs485 driver to support common rs485 devices in the future, but that may introduced bugs in Modbus Gateway function for serial devices (MSTP was not affected, because it’s different driver). This release fix some of them:
Offline devices may cause segment fault.
Device responding time for the WebUI raw test result is inaccurate.
Bugfix: Buffer overflow when Modbus module maps Ananlog_Output to multiple registers.
Bugfix: Modbus TCP bug would be triggered when there are more than one slaves defined under a TCP master and the “Keepalive” is 0.
WebUI removes support for IE10.
Historical data of runtime info could be reset.
MS/TP runtime info introduces colored mac table.
Support for BACRouter-S (single ms/tp port router) is integrated.
Modbus Gateway CSV file importing:
1. There is a bug ignoring Modbus data unit type from 2th point.
2. Mulltistate point without states defined need not to be forcedly disabled.
From v3.00, we added a integrity check: A relayed NPDU with 255 hop count is regards as malformed and will be dropped. The log will show: [WARN]npdu_decode_pci: hop count should not be 255 for relayed npdu
Dropping such NPDU may causes interoperability problem with other routers. Though the hop count is incorrect here, BTL test does not completely cover it, So there are still BTL passed routers have such bug.
Modbus: MultiState objects could be mapped from bit range in a register.
There is a bug on rescue upgrade that old configuration is not deleted which may prevent WebUI from loading. If old version WebUI could not be loaded because of invalid configuration, please rescue upgrade to this version twice, first time it will upgrade firmware, the second time it will delete old configuration.
A bug on Modbus virtual device mode is fixed which cause malfunction when virtual devices are more than 5.
A WebUI bug when Modbus slave number overflowing limitation is fixed.
The limiations of Modbus master and slave are changed from 100 to 128.
A WebUI bug when disabling “Packet capture mapping” is fixed.
More name delimiter characters are added. Internal object names are modified to avoid collision with new name delimiter characters.
Reject-Message-To-Network should be unicasted to compliant to BTL.
TTL of registered foreign device should plus 30 seconds to compliant to BTL.
Confirmed service sent to broadcast address should be dropped on application layer to compliant to BTL
BBMD should drop unicasted forwarded npdu from local subnet with same udp port.
Bug on multiple BBMD detection when checking existence of entry in BDT with different udp port is fixed.
WebUI adds network settings page, which will show routing table.
A bug on slave proxy is fixed: when there is a unicasted who-is send to slave device, the device instance range carried by the service should be respected, same as broadcasted one.
MS/TP duplicate detection algorithm which is learned from duplicating of JCI FEC2611 and IOM3731 is added.
MS/TP duplicated MAC detection is implemented. Duplicated MAC will be shown by Red color in “Recently active other devices”. Because of complexity of behavior on duplicating situation, the detection is inaccurate and for reference only.
A potential bug introduced from 3.0 in the low level MS/TP state machine is fixed.
Based testing and clients’ feedback, many(maybe most) devices does not obey the MS/TP receive frame finite state machine described in BACnet standard when they encounter error. Our proprietary “Timeout Interrupt” feature will cause trouble or degrade performance in this situation. So “Timeout Interrupt” feature is removed.
More statistics is added to MS/TP runtime information page.
WebUI bug on BIP’s Foreign Device Mode introduced from 3.08 is fixed.
Fix mstp calculation bug on time used for invalid packet.
Fix bug on mstp slave proxy introduced by 3.08
Some minor WebUI improvements.
The config file format is changed much between 2.x and 3.x, so from 3.00 to 3.09, when upgrade firmware, the upgrading script will install new config file. This version add a “Keep config” option when upgrade firmware. If config file have something wrong, the WebUI will popup a warning when it is opened.
Fixs bug introduced in 3.08 when fetch mstp runtime info.
Some minor WebUi improvements.
Bugfix: 1 hop broadcast distribution is optional for BBMD, From version 3.00, BACRouter force other BBMDs to use 1 hop distribution if cross-network broadcast support is enabled. It’s incorrect behavior and fixed in this version.
BDT editing UI is improved. When submitting, BDT entries will be checked to detect possible misconfigure. The checking is also taken when receiving Write_BDT BVLL message.
If multiple BBMD support is not enabled, when receiving forwarded npdu from BBMD not present in local BDT, the npdu will be dropped and logged. It will help distinguishing configure problem of BBMD on most situation. “Report multiple BBMD” function in last verion is covered by this function, so it’s removed.
The filename of downloaded config is set as IP_Version.json, for example: 192.168.100.1_3.08.json
Config uploaded from file will be edited in WebUI before saving to eliminate any potential incompatibility.
Ethernet is disabled by default. If BIP and Ethernet are enabled at the same time, a warning of possible circular route will be promoted.
The default capture size increases to 4M.
Capture control function is mapped to BACnet. Each datalink port has its “Capture buf_size” and “Capture command” Multi_State_Value. “Capture buf_size” could be set between “64K” to “16M”. “Capture command” could be set between “Stop&Clean”, “Start”, “Stop”.
Password for root could be modified from WebUI now.
BACRouter verifies other router’s live by query its routing table with Initialize-Routing-Table message. But addendum 135-2012AL removed the enforced supporting of Initialize-Routing-Table from router. So in this version BACRouter also monitors Reject-Message-To-Network message that could only be sent by router.
BIP BVLL header of forwarded npdu is 6 bytes larger than other npdu, so there was potential bug on packet length verification that is fixed on this release.
Minor bugfixs for UI
“Download config” and “Upload config” are added to “System setting”
Add Packet capture feature：
Supported on all ports(Ethernet, BIP, MSTP).
Because Wireshark could not decode MSTP extended frames, MSTP extended frames are converted to traditional data frames. Fortunately, Wireshark doesn’t complain about overflowed data length.
MSTP packet could be downloaded as “Interval format”. it could be used to show exact idle time before packet by selecting “Seconds Since Previous Captured Pakcet” as “Time Display Format” in Wireshark. It is very helpful to analyze timing and performance problem.
MSTP support real time analysis for max master and show it on run time info, if the value is not matched to the setting, “unmatched” is showed after it.
MSTP support sniffer mode. it could analyze and record data without interfering the bus.
The WebUI of MSTP port add options for basic mode and extend mode.
The timeout settings for MSTP are changed from Integer to Float.
MSTP port’s slave proxy is only support broadcasted Who-Is in previous version. Now it support unicast too.
MSTP port’s slave proxy send unicasted I-AM instead of broadcasted one in previous version.
There is a bug in previous version that Who-Is packet readed by MSTP slave proxy module bypass source address routing verify. it’s fixed this time.
BBMD module add option to log error when multiple BBMDs are found in local lan.
Modify feature introduced by version 2.17. “Accept unmatched destination IP” option is provided, if it is selected, only warning message will be logged, else error message will be be logged and the packet will be dropped.
Process 0 in unconfirmed COV notification service is reserved for unsubscribed notificationCOV. Not longer reports error when can not find matched process for 0.
In previous version, when BACRouter receive Original-broadcast BVLL from unicast address or Original-unicast BVLL from broadcast address, it would print error message then drop it. A customer reported that Johnson Controls’ CCT sends Original-broadcast BVLL to unicast address, so now we only print warning message.
From version 2.0.8, only proprietary network layer messages would be relayed. Now all unknown network layer messages will be relayed.
Redirect URL from “/” to “/?” to support Edge web browser (avoid keep asking authorization)
MSTP: Fix bug in standard state machine which would cause passing token to self when duplicated token is found.
MSTP: With standard state machine device in sole master mode would send max_info_frames * Npoll frames after polling one master. A more reasonable behavior is implemented that device send max_info_frames * Npoll frames after finish polling all masters.
Fixed bug introduced from 2.0, it should not wait reply when it send expecting reply request to mac address 255 on MSTP.
Potential bug (barely) may be triggered if MSTP auto mac and baudrate forcing are enabled together.
Optimizing route entry protection: Deletion from route hop will bypass protection.
Support devices utilizing 6.5.3 methods 1 and 4 for establishing the address of a BACnet router for a particular DNET.
This update help building up routing table quickly in large BACnet inter-network.
When BACRouter startups, it broadcasts out Who_Is_Router_To_Network without network number specified to learn routing info from other routers.
When Who_Is_Router_To_Network/Router_Busy_To_Network/Router_Available_To_Network without network number specified is received, BACRouter reports network number up to 1120 instead of 112 in previous version.
Bugfix: ReadRange on property_list should not return object_identifier; object_name; object_type.
Delay 1 second for sending Network_Number_Is when router startup, because if router is a BIP foreign device, the foreign device registering have not completed yet.
Protect route entry 60 seconds from last activity. Avoid broadcast storm in circular routing path.
Bugfix: Vendor proprietary network message should be correctly relayed.
When relay Reject-Message-To-Network with reason 4(Too long), use unicast address instead of broadcast address.
Relax daemon’s max_apdu_retries to 10, in accord with WebUI.
Compliant to BACnet Router and BBMD device profile.
Try to purge invalid route entry if no reply is received for Who_Is_Router_To_Network or Initializing_Routing_Table. This feature helps to rescue from mess network configuration.
Avoid sending too many I_Am_Router_To_Network with circular routing path.
Reduce memory consumption in complicated inter-network.
Avoid BBMD broadcast storm. If Forwarded-NPDU is received from broadcast address, do not re-broadcast it.
When relay Reject-Message-To-Network with reason 1/2/4, use broadcast address.
Discard Reject-Message-To-Network with incorrect route info.
Check source net of incoming NPDU.(Trickily handle Initializing-Routing-Table)
Bug: global broadcasted initializing-routing-table should be executed.
Bug: WebUI BIP mode select should not be applied without submiting.
Limit number of route entry in runtime info page to avoid request failure in very large internetwork.
Fix WebUI Bug for verifying BDT.
Save configuration and restart when receive reinitialize-device service request.
BIP BBMD NAT mode support udp port modifying.
BIP BBMD NAT mode do not listen to local net broadcast address and not send broadcast to local net.
BIP foreign device mode do not listen to local net broadcast address.
Regards device sent Who-Is-Router-To-Network has no route to that network.(Delete that route entry from route table)
When Initializing-Routing-Table request modify network number of route port, I-Am-Route-To-Network is sent to report new network number.
Fix bug introduced by ver2.0 for saving new BDT modified by BVLL Write-Broadcast-Distribution-Table message.
Add upgrade entry “http://ip/app/upgrade for rescue.