针对BACnet MSTP的帧失步攻击

如前面的文章 “BACnet MSTP 帧失步” 所指, BACnet MSTP 有一个帧失步的设计缺陷,但是是否可以利用这个缺陷,在完全遵守协议的前提下,对MSTP总线进行破坏呢?

设计这个攻击,我们先做以下几个假设:

  1. 总线上至少有3个设备,MAC地址分别为1, 8, 10。其中设备1是精心设计用来发动攻击的,设备8与10是无辜的。
  2. 设备1支持扩展帧,设备8与10不支持。
  3. 这3个设备的定时器都足够精确。

设备1的工作流程如下:

  1. 得到令牌,发送A帧
  2. 传递令牌到其它设备
  3. 再次得到令牌时,发送B帧
  4. 传递令牌到其它设备
  5. 重复步骤1.

A帧是一个合法的私有数据帧,十六进制数据如下:

55 ff 80 ff 01 00 1d a3 02 2b 72 fe 55 ff 03 08 01 00 11 a0 ff 55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf

B帧也是一个合法的私有数据帧,十六进制数据如下:

55 ff 80 ff 01 00 1d a3 02 2b fe dc 55 ff 03 0a 01 00 11 b1 ff 55 ff 21 01 0a 00 09 fd 8a 51 55 ff 00 01 0a 00 00 8c

如果没有帧失步,一切都将正常运行。但是可能几小时,也可能几天后,设备8对设备1发出的A帧失步了,错过了A帧的帧头(设备10如对B帧失步,也是同样的效果),则设备8继续扫描A帧的数据部分,发现另一个有效帧:

55 ff 03 08 01 00 11 a0 ff 55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf

这是发给设备8的Test-Request帧,设备8等待Tturnaround后发送Test-Response帧进行应答:

55 ff 04 01 08 00 11 ae ff 55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf

但是此时,设备1正在传出令牌:

55 ff 00 02 01 00 00 73

令牌帧与Test_Response的前8个字节冲突了,对于设备10来说,收到了几个错误字节后,继续扫描,在Test_Response的数据部分又发现了一个帧:

55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf

对设备10来说,这不是发给它的帧,所以他进入SKIP-DATA状态,抛弃数据,等这个帧结束,但是直到设备8发完数据,设备10还差一个字节来结束帧,他将继续等待。

对设备1来说,它发出令牌帧后,收到如下数据:

55 ff 21 01 08 00 09 ce d4 f3 55 ff 00 01 08 00 00 bf

这是一个扩展数据帧,因为它支持扩展帧,所以他按 Addendum 135-2012an规定的流程校验帧头,发现数据长度过短,中断前帧后又开始扫描,发现新帧:

55 ff 00 01 08 00 00 bf

这是一个发给设备1的令牌帧,设备1又得到令牌,经过Tturnaround后,重新发送B帧:

55 ff 80 ff 01 00 1d a3 02 2b fe dc 55 ff 03 0a 01 00 11 b1 ff 55 ff 21 01 0a 00 09 fd 8a 51 55 ff 00 01 0a 00 00 8c

在前面提到,设备10还差1个字节来结束前面一帧,因Tframe_abort>Ttrurnaround,所以解析没有中断,B帧的第一个55字节被设备10抛弃,然后开始扫描新帧,发现了:

55 ff 03 0a 01 00 11 b1 ff 55 ff 21 01 0a 00 09 fd 8a 51 55 ff 00 01 0a 00 00 8c

这是一个发给设备10的Test-Request帧,事情又开始重复。

从上面可以看出,每个设备都严格地遵守标准,但是一旦帧失步发生,整条总线就永远地瘫痪了。

更多信息见:MSTP帧失步解决方案

MSTP帧失步解决方案

因为固件版本3.x,于2020.3.25更新

我们曾在下面的文章中讨论过BACnet MSTP协议中有帧失步的弱点:

BACnet MSTP 帧失步

针对 BACnet MSTP 的帧失步攻击

对于BACRouter 来说,怎么来防范这个漏洞呢?让我们从标准的 9.5.3章节找线索:

Tframe_gap 翻译为字节间隔,指的是 “节点在发送一个帧时,在两个字节之间允许的最长的空闲时间”,它的值是20位时间。市面大部分MSTP设备的字节间隔为0。

所以BACRouter采用一个改进的接收有限状态机:

  1. 在一个MSTP帧中,字节间隔如大于Tframe_gap,认为MSTP帧中断。
  2. 字节间隔如大于帧间隔Tturnaround,认为新的MSTP帧出现。考虑到字节帧失步引起的测量误差,我们实际采用的值是30.5位时间。
  3. 为了尽量兼容部分不遵守Tturnaround的设备,所有在有效MSTP帧后的数据认为是新的一帧。

在115200波特率下,一个数据位的时间仅8.7微秒,为了精确地测量空闲时间,BACRouter采用了5微秒精度的定时器,它有效地防止帧失步出现,并且 在115.2kbps下达到98.8%的带宽利用率 因为BACRouter发包时精确地遵守40位的Tturnaround,没有浪费多余的等待时间。

BACnet MSTP 帧失步

在MSTP领域有2个帧的概念:

  1. BACnet MSTP数据链路层的帧,它由最少8个字节组成,包括:2个前导字节为0x55, 0xff,帧类型,目标MAC地址,源MAC地址,2个字节的数据长度,crc8校验,如果数据长度不为零,还包括数据与数据较验。这里把这种帧称为MSTP帧。
  2. EIA-485帧,它由位组成,包括一个起始位,数据位,较验位,停止位。MSTP采用NRZ不归零编码,8个数据位,无较验位,一个停止位。起始位为0低电平,停止位为1高电平,数据位低位优先传输。这里把这种帧称为“字节帧”。

BACnet MSTP的接收有限状态机采用前导字节分辨MSTP帧的起始。如果在中途超过Tframe_abourt(最小60位时间,最大可达100毫秒)没有收到数据或错误,则放弃帧,重新开始搜寻帧前导字节。

因为前导字节可以出现在MSTP帧的数据部分(Addendum 135-2012an 引入的扩展帧的数据及数据较验部分采用COBS编码避免出现前导字节)所以如果出现帧失步,接收状态机有可能会把前一个MSTP帧的数据部分认为是新的MSTP帧。

MSTP帧之间最小时间间隔是Tturnaround(40位时间)小于Tframe_abort,如果接收状态机对MSTP帧的解析失步,有可能会跨过帧间隔继续解析。

MSTP帧失频有几个可能原因:

  1. 发送设备与接收设备的程序漏洞,这可以通过代码审查与除错解决。
  2. 时间精度. BACnet MSTP标准仅要求1%精度的定时器,分辨率最小5毫秒。而应答方的最大延迟时间与等待方的最小超时之间的时间冗余只有5毫秒(如Tusage_delay与Tusage_timeout, Treply_delay与Treply_timeout),因此非常容易触发冲突引起失步。
  3. 总线上噪声。噪声导致的接收错误或数据校验错引起失步。

有人可以争辨说MSTP帧有crc校验保护。即使不考虑恶意设备(这里是一个例子), 现实中仍然有可能在帧数据中包含完整的MSTP帧。

例如,市场上很多串口转IP的设备,它们通常有一个或多个RS232/RS485串口及一个有线或无线网口,可以通过TCP/UDP远程在串口上接收、发送裸包。串口的协议可能是Modbus或其它非特定协议。这种设备对简单的协议集成非常有用。

那么是否可以把这类设备的网络端协议封装为BACnetPrivateTransfer服务,然后通过BACnet网络传输呢。如果用户把这个设备串口端RS485接到一个MSTP总线上,并且网络端传输又经过一个MSTP网络时,结果就是出现在这个MSTP网络的传输帧的数据部分包括了完整的MSTP帧。

帧失步的后果不仅仅是可能导致总线拥堵,甚至设备的误动作(如果数据部分的帧是个APDU),更有甚者如果错误的帧是路由配置包的话,可能导致整个BACnet互联网络瘫痪。


关于字节帧的失步,可能原因一般是:数据噪声,不当的终端电阻,总线未偏置引起。失步的表现有两个,一是将数据位的1解析为总线的空闲,二是将数据位的0解析为新字节的起始位。失步除了导致接收到错误的数据,如果发生在MSTP帧的最后一个字节,将可能引起对总线空闲时间的测量误差(可能过长或过短)。

更多信息见:MSTP帧失步解决方案

一次最大发包数与根据令牌占用时间

从固件版本2.0开始,BACRouter引入一个新的特性:根据令牌占用时间的一次最大发包数。

在BACnet MSTP标准中,一个主站得到令牌后,可以发送“一次最大发包数”的包后,再传递出令牌。“一次最大发包数”的默认值是1。路由器作为流量汇聚点,提高这个值可以改进网络交换带宽,但是会增加令牌占用时间。大多数路由的建议值为5到20。

MSTP作为常见的现场总线,通常由控制器、传感器、执行器互联,这些设备构成直接的控制回路,数据交换延迟通常要得到保证。我们建议设备得到令牌的时间间隔要小于1秒 。

路由器发送的NPDU的长度通常在10~50字节之间。但是最大可达到501字节(或扩展帧的1497字节)。越大的帧需要越长的时间来收发。

对于需要回应的NPDU来说,路由器需要等待目标设备应答。通常目标设备需要更长的时间来处理长帧,即路由器需要等待更长的时间。

所以同样的“一次最大发包数”,每次路由持用令牌的时间变化很大,对MSTP总线的延迟保证非常不利。

为避免这个问题,我们引进“根据令牌占用时间”特性来限制路由器持有令牌的时间。这个特性启用后。路由器不计算发包数,而是计量持有令牌的时间,当时间达到:

每字节发送时长 * 32 * “一次最大发包数”

就不再发送新帧,并传出令牌。例如“一次最大发包数”为10, 波特率为76.8kbps,每字节发送时长为0.13毫秒,则最大令牌持有时间为:

0.13 * 32 * 10 = 41.6 毫秒.

这个特性可以通过WebUI方便地启用与关闭。

MSTP包延时保证

BACnet有两种类型的服务,分为无确认与有确认。有确认服务的发送者(客户端)会等待应答直至超时。

通常情况下,无确认服务的包延时不会带来副作用。但对于有确认服务的请求包与应答包,过长的包延时将导致应答包因为超时而被抛弃,浪费了通讯带宽。

更有甚者,过迟到达的应答包可能导致应用层的逻辑错误!原因如下:

有确认服务的请求包头带有一个InvokeID,值范围0~255。应答包有同样的InvokeID。客户端通过这个InvokeID匹配请求与应答。在一个繁忙的客户端,InvokeID会快速耗尽, 此时只能回收重用已完成的服务的InvokeID。

如果一个有确认服务的应答包被过分延迟,客户端可能因为超时而结束服务,其InvokeID被回收,并被重新分配使用。此时被延迟的应答包被收到后,其InvokeID将被匹配到错误的服务。例如:

  • 客户端发出一个WriteProperty请求A,写设备X对象Y属性Z,分配的InvokeID为0。写入成功,但此请求包或者应答包延迟了。
  • 客户端等待超时而结束服务,InvokeID 0被回收。
  • 客户端发出一个WriteProperty请求B,写设备X对象U属性V,InvokeID又分配到0。写入失败。
  • 请求A的应答包先到达,由其InvokeID匹配到请求B。客户端认为请求B写入成功,造成应用层逻辑错误。

对高速的链路层如以太网或IP, 包延时通常是可忽略的,但是对于MSTP,有很多原因将造成过长的包延时:

  1. 信号噪声造成的令牌丢失或冲突。
  2. 不适当的设备配置(波特率,最大扫描站号,最大发包数)。
  3. 过高的流量。
  4. 过慢的设备。

为了避免InvokeID冲突及提高网络性能,版本2.0及以上的BACRouter实现了10秒钟的包延时保证,在收到后不能在10秒钟内完全转发的包将被抛弃。

虽然此策略可能造成服务无应答,但是比起错误应答,无应答是可以通过应用层的重试机制处理。

 

MSTP 固定/自动/强制 波特率

MSTP的波特率设置一直是个现场工程师头痛的问题,如果设备的波特率设置有误,就无法加入MSTP网络中。

大部分设备采用固定的波特率,如需修改波特率,工程师必须接触到设备并调整DIP开关。有的设备支持通过BACnet服务修改波特率,但是在这之前,设备必须要能接入到BACnet网络中。

有的厂商实现了自动波特率配置,但是也带来了更多的问题,目前市场上的自动波特率有两种类型:

  • 启动时探测:设备在启动时监听总线并探测波特率,随后一直以该波特率运行。
  • 动态探测:设备不但在启动时探测波特率,在运行中如果在一段时间内持续发生通讯错误,即认为波特率改变,重新探测波特率。

不管是哪种类型,在总线运行时改变波特率都是非常困难的。仅仅改变所有固定波特率设备的设置是无法影响总线波特率的,因为其它自动波特率设备仍然以旧的波特率运中。唯一可靠的方法是在改变所有固定波特率设备的设置后,关掉所有自动波特率设备,再启动所有自动波特率设备(不能一个接一个的重新启动自动波特率设备!因为仍在运行中的自动波特率设备将维持总线波特率)

BACRouter的新版本固件(版本>=2.0)引入了新的波特率管理机制(专利申请中)。BACRouter有三种波特率模式:固定/自动/强制。

  • 固定波特率模式与传统的固定波特率一样
  • 自动波特率模式类似于前述的动态探测。重新探测的条件是10个连续的错误帧。
  • 强制波特率模式类似于自动波特率模式,区别在于其在得到令牌后,将波特率改为预设的波特率。

当总线中有一个强制模式设备时,总线的波特率将会强制运行于预设值,而其它自动模式设备将自动同步波特率。固定模式但波特率设置值不同于预设值的设备将无法出现在总线中(通过检查BACRouter的运行信息中的“最近活动设备”项将很快地把这些设备找出)。对于上述的启动时探测设备,如果其探测到的波特率不同于预设值,也无法出现在总线中(同样可以通过检查BACRouter的运行信息中的“最近活动设备”项找出),但只需将其一个接一个的重新启动即可(不需全部断电,再全部上电)。

多个强制模式的设备可以共存在总线中,但这些设备中的波特率预设值必须相同。

BACnet路由版本升级记录

3.06  2020.5.22  下载

因为Ethernet端口现在已很少用到,缺省将其关闭,同时如果BIP与Ethernet同时被启用,将弹出警告,提醒用户注意可能的路由回环。

将默认的捕捉缓冲区大小增加为4M。

3.05  2020.5.15  下载

包捕捉功能映射到BACnet。 每个链路层端口都有独立的”Capture buf_size”与”Capture command” 多状态值. “Capture buf_size”可以在”64K”到”16M”之间设置。 “Capture command”可以在”Stop&Clean”, “Start”, “Stop”之间设置。

此功能应国外用户需求开发,使用场景如下:路由默认开启包捕捉。当上位机发现某设备的通讯异常时,可以停止路由对应端口的包捕捉(使用“Stop”保留捕捉数据,而不是”Stop&Clean”),然后通过邮件提醒管理员,从WebUI读取当时的包捕捉数据进行分析。

3.04  2020.4.28  下载

增强安全性,由WebUI可修改root密码。

3.03  2020.4.23  下载

BACRouter以Initialize-Routing-Table包查询路由表的方式, 确认其它的路由器仍然存活。但是附录135-2012AL移除了路由器对Initialize-Routing-Table的强制支持。本版本增加通过Reject-Message-To-Network包确认路由存活的方式。

BIP BVLL对转发 (Forwarded) 的NPDU的包头要比其它的包头长6个字节,老版本在较验转发的NPDU包长时有个隐蒧的Bug,本版本已得以修正。

3.02  2020.3.26  下载

UI的小修正

3.01  2020.3.17

系统设定增加下载配置与上传配置功能

3.00  2020.3.10

增加包捕捉功能:

所有端口均支持包捕捉。

因为Wireshark不支持MSTP扩展帧解析,扩展帧在下载时转为常规数据帧(幸运的是,Wireshark并不抱怨长度溢出)。

MSTP支持包间隔格式,可以在Wireshark中以5us精度显示包前的空闲时间,是时序与性能分析的利器。

支持持续化包捕捉,提供API接口,方便自动化流量记录。

MSTP移除自动地址探测功能。因为设备无法保证同一时间上线,无法完全避免地址冲突。如现场调试时,需要知道可用MAC地址及最大扫描地址,可以采用下述方式:开启侦听模式,从运行信息得到“当前最大扫描地址”及“最近活动站点”。

MSTP增加最大扫描地址实时分析功能,在运行信息中显示,如与配置值不符,将提示“不匹配”

MSTP增加侦听模式,可以在不干涉总线运行的前提下,检测总线运行情况。

MSTP的Web配置界面,提供简单模式与扩展模式选择。

MSTP的所有超时改为浮点数,方便精确定义。

MSTP从设备代理前版只支持广播的Who-Is查询,现版本增加支持单播的Who-Is查询

MSTP从设备代理前版应答I-Am采用网内广播,现版本采用单播

MSTP从设备代理功能修正前版中分析Who-Is查询的路由来源的漏洞。

BBMD增加选项在发现内网有多个BBMD时错误报警。

对2.17版提供功能的修正,增加“接受不匹配的目标地址”选项,如果启用,仅打印报警信息,如果未启用,打印错误信息并丢弃。

很多的WebUI小改进。

2.18  2019.4.16  下载

提高了IP与以太网口的性能

在Unconfirmed COV通知中的进程0保留给未订阅的COV通知,当没找到进程0时不再报告错误。

2.17  2019.4.2  下载

在前版中,当从单播地址接收到Original-broadcast BVLL包或从广播地址接收到Original-unicast BVLL包,认为是个错误而丢包。有客户报告江森的CCT用单播地址发送Original-broadcast BVLL包,所以此版中仅打印报警信息。

2.16  2019.2.25  下载

从版本2.0.8起,  仅支持转发私有的网络层包,其它不认识的网络层包将被拒绝。此行为不利于支持标准的升级。本版本中所有不认识的网络层包均支持转发。

2.15  2017.10.19  下载

重定向 URL “/” 到 “/?” 以支持Edge 浏览器 (否则将不停地要求认证)

修正MSTP标准状态机中的Bug: 令牌重复可能导致转发令牌给自身.

MSTP标准状态机中,当设备处于单主机模式下,其开始查询一个主站后,发送max_info_frames * Npoll 个帧。修改为更合理的行为:当结束查询所有主站后发送max_info_frames * Npoll 个帧.

2.14  2017.10.13  下载

修复从2.0引入的Bug,当MSTP发送Expecting reply请求到255地址时,不必等待回应。

2.13  2017.9.19  下载

当MSTP自动地址分配与波特率强制功能同时启用时,隐藏的bug可能(极其罕见的条件下)引发。

2.12  2017.7.10  下载

优化路由表项保护功能: 来自下一跳的删除将跳过保护.

支持采用6.5.3中查找网络路由地址的方法1与4的设备。

2.11  2017.6.16  下载

此次更新有助于在大型BACnet互联网络中快速建立路由表。

当BACRouter启动时, 广播一个无目标网络号的Who_Is_Router_To_Network以学习其它路由的信息.

当收到无目标网络号的Who_Is_Router_To_Network/Router_Busy_To_Network/Router_Available_To_Network, BACRouter回复的网络号最多可达1120个(对比前版本的112个).

2.10  2017.6.13  下载

错误修下: ReadRange在读取property_list不应返回以下三个属性: object_identifier; object_name; object_type.

启动时延时1秒发送Network_Number_Is,因为如果路由器做为BIP的外部设备,此时注册流程尚未完成。

2.09  2017.6.10  下载

保护路由表项从最后活动计起60秒,避免路由回环时的广播风暴。

2.08  2017.6.7

错误修正: 正确转发私有的网络层包.

转发Reject-Message-To-Network(原因4,包太长)时,使用单播地址.

修改后台的最大apdu重试为10,与WebUI一致。

2.07  2017.6.5

遵从BACnet Router与BBMD的设备描述.

如果没有收到Who_Is_Router_To_Network或Initializing_Routing_Table包的回应, 删除无效的路由. 此特性有助于从错误的网络配置中恢复.

在网络回环时(当配置错误时), 避免发送过多的I_Am_Router_To_Network.

减少复杂网络下的内存消耗.

2.06  2017.6.1

避免BBMD广播风暴.

广播发送转发的Reject-Message-To-Network包(只针对拒绝理由1,2,4).

抛弃含有错误路由信息的Reject-Message-To-Network包.

检查NPDU包头的源网络.(对Initializing-Routing-Table包特别处理)

2.05  2017.5.23

修正全局广播的initializing-routing-table请求未执行的错误.

修正WebUI BIP的模式选择未提交即生效的错误.

限制运行信息页面的路表项个数,以避免在大型互联网络中的请求失败。

2.04  2017.5.11 下载

修正WebUI较验BDT时的错误.

当收到reinitialize-device服务请求时保存配置重启。

2.03  2017.5.7

BIP BBMD NAT模式支持端口号修改。

BIP BBMD NAT模式不监听本地广播地址及发送本地广播

BIP BBMD 外部设备模式不监听本地广播地址

2.02  2017.5.5

当收到Who-Is-Router-To查询时,假定源设备没有该路由(从路由表中删除)

当Initializing-Routing-Table修改了网络号,重新发送I-Am-Routr-To-Network以报告新网络号

修正v2.0引入的错误:保存BVLL Write-Broadcast-Distribution-Table修改的BDT表时出错

2.01  2017.5.3

增加后备的升级入口 http://ip/app/upgrade

更直觉的日志信息

改进网络层拒绝行为

修正发送I-Am-Routr-To-Network时的溢出(当报告的网络数量超过1476/2时)

以动态时间间隔发送I-Am-Routr-To-Network.

2.0  2017.4.19

提供选项启用路由内的设备对象。.

允许从BACnet端修改配置

支持What_is_Network_Number and Network_Number_Is 网络包

提供MSTP max_info_frames的by occupy time选项

实现新的MSTP自动/强制波特率机制.

MSTP包最大延迟保证(10 seconds).

WebUI界面更智能.

1.22  2016.10.26  下载

将路由表项的数目由1024增加到65534(即没有限制).

1.21  2016.10.18

从设备代理: 如果对方是快速设备加快ReadProperty(Multiple)的发送速率.

BVLL回应NAK当收到BBMD相关的请求,但BBMD未使能. (附录135-2012ax-5)

BVLL回应NAK当收到Distribute-Broadcast-To-Network请求,但源设备未注册为外部设备. (附录135-2010ad-10)

1.20  2016.10.8

BIP提供选项接受发往255.255.255.255的广播报文

BIP外设设备模式的注册时间间隔的最小值从30秒减少到15秒。

1.19  2016.9.23

webui如果IP/掩码/网关/DHCP没有改动,采用快速重启

MSTP加入快速设备超时中止功能

MSTP快速设备最小超时改为0ms(实际是收发切换后1.5bits加上50us)

MSTP快速设备令牌传递超时最小值设为20ms

MSTP运行信息显示最近10秒活动的设备

1.18  2016.9.13

BIP BBMD 支持NAT,增加两个参数”接受BDT表写入“与”接受外部设备注册”

在“配置”页面显示以太网地址

1.17  2016.9.8

应某些OEM用户需求,登录认证的域名可以由用户定制。

1.16  2016.9.7

修正从站代理应答Who-is但查询到的设备并没有在该入口代理。

修正写远程BBMD的BDT表错误

许多的界面改进

1.15  2016.9.1

加入了从设备代理功能.

MSTP加入了无切换延时桢计数及带填充字节桢计数

一些界面改进。

修正无切换延时桢紧跟带填充字节桢时的解码错误

1.14  2016.8.24

这是一次大升级,比较多的修订:

MSTP增加令牌超时、回应超时配置项。

MSTP增加快速设备功能,允许指定设备使用小至1毫秒的令牌超时与回应超时。

MSTP增加运行诊断信息含地址冲突,发送冲突、令牌冲突、令牌丢失,令牌转发失败、无应答、包错误。

MSTP增强对不遵守40bit发送切换要求的设备的兼容性

MSTP修正发送扩展桢的编码错误

MSTP修正特定条件下应答测试桢的CRC错误

1.13  2016.8.16

底层api改动,对本软件无影响

1.12  2016.8.12

加入系列号

1.11  2016.8.10

固件文件名带版本号及校验字串。

左边树型菜单处显示版本号。

重启及升级固件后,自动刷新。

修复一些界面bug

CCN网关版本升级记录

2.9 2017.5.30

兼容一台不规范的30RQ固件。

移除2.2引入的特性,以与CCN控制网络并存。

2.8 2016.10.26

修正转换unicode字符串到utf8编码时的缓冲溢出缺陷。

2.7 2016.10.3

WebUI采用basic认证方式

修正WebUI的表格索引溢出错误(感谢Nitin的报告)

2.6 2016.9.13

WebUI 显示Ethernet地址

2.5 2016.9.13

处理字符串时忽略0-9/a-z/A-Z以外的字符

2.4 2016.8.26

可选择0.001,0.01,0.1,10,100,1000倍的映射倍数

BACnet部分合并了BACnet路由器的修订。

2.3 2016.8.16

底层API变动,为后续产品作准备

修复2.1版引入的Bug,通讯失败后持续错误

2.2 2016/8/12

某些原厂技术人员为竞争项目故意用CCN服务工具软件将一些重要的数据点强制锁定,无法写入。在初始化时检测并解锁。

2.1 2016/8/10

固件文件名带版本号及校验字串。

左边树型菜单处显示版本号。

重启及升级固件后,自动刷新。

修复一些界面bug

发表在 CCN

开利中国特色的冷机固件

前两个月我们的工程师在现场调试CCN Gateway,冷机型号是30RB,控制系统是touch pilot,发现Web Gui里看到的机组状态是中文乱码,其它点的中文显示正确,工程师当场就凌乱了,查了开利美国版本的手册,及国内最常用的法国版本的手册,都对应不上。

工程师只能操作冷机的面板,看看什么状况,结果,居然冷机面板看到的一样是乱码。客户当场就要发飚,这根本就是汉化不完全的半成品。

联系到前两年有一款30XA的中文界面,在英文原版的界面中,机组状态有”Stopping”与”Off”,英文很好理解,“Stopping”就是正在停机中,”Off“就是停机状态。

但是中文的面板,将两者都翻译成”停止“,这样客户无法分辨机组到底停了没有,水泵能不能安全关闭。其实只要将”Stopping“翻译成”停止中“,就不会有这个混淆产生了。

今天,在一款30XA_NGA的热回收机组上,看到热回收进出水温度的英文是”Hear Reclaim Entering”, “Hear Reclaim Leaving”, 明显这里的单词”Hear”是错误的,本应为“Heat”。而且在”RECLAIM”表中的热回收进出水温度的数据一直为0,不更新。这意味着如果客户不幸高价采购了开利原装的网关,只能读到无效的热回收工作数据。

幸运的是在维持表“WCHRSTAT”中,有对应的数据点,而且数值持续更新中。我们新版的网关固件支持维持表映射(开利原装网关不支持),终于为客户解决了这个麻烦。

以我们的理解,这些问题的根源在于开利国内的开发部,在原版固件的基础上做二次开发时不严谨。而且CCN部门在面对用户时一贯强势,使得对于产品的缺陷,客户也只能逆来顺受,无法将需求传导到开发部门,从而修正缺陷。

而对我们来说,仅有最大程度满足客户需求,才有市场立足之地。因些对客户的所有问题,我们都尽力解答,甚至要为客户解释机组的运行逻辑、故障维修,半夜三更远程替客户配置网关。

开利某国分公司成为我司客户

去年下半年,开利某国分公司与我方进行接触,经过详细的技术探讨、对方认可了我们的CCN Gateway,准备订购一块用于项目中,但该采购违反了总公司的政策,被截止。对方只能让经销商向我们直接采购。经过半年的运行,对方非常满意,经由经销商与我们达成长期合作协议,本月再次订购了两块。

发表在 CCN