Optima Releases T:LAN NetPro OS Update – September 2018

RECOGNIZED ONEWIRE TEMPERATURE ALARMS NOT LOGGING

BACKGROUND:

Rev.3x T:LANs (running OS versions up to and including BN7618) fail to log OneWire Temperature Sensor alarms while Rev.4x T:LANs work correctly.

T:LAN OS BEHAVIOUR:

Rev.3x T:LANs without an AXM+ (Enhanced Alarm Expansion Module, a factory installed option) would correctly identify OneWire Sensors in NORMAL or ALARM state in the RIO EDIT MENU. However, the units fail to log these recognized alarm events in the RIO EVENT LOG (and thereby also omit sending out the corresponding SNMP traps). This was missed by in-house QA as all Rev.3x (Status: Legacy/EOL) testing was performed using AXM+ equipped units.

AFFECTED UNITS:

All Rev.3x T:LANs WITH external RIO’s, WITH OneWire Temperature Sensors, and WITHOUT the AXM+ module (see GENERAL SYSTEM CHARACTERISTICS).

REMEDY:

Impacted units require a T:LAN OS update to BN7622 to guarantee proper OneWire Sensor operation.

TELNET ISSUE WITH LARGE MDR-8000 RSL DATA SETS

BACKGROUND:

The TELNET protocol defines a number of command/control sequences to establish a link or negotiate certain options. To distinguish between these TELNET protocol commands (which are sent in-band) and regular data bytes, a special ‘escape character’ is used (0xFF).

This escape character is commonly referred to as IAC (Interpret As Command). Any endpoint receiving the TELNET data stream looks for this particular byte as it signals the beginning of a command/control sequence. Any bytes following the IAC will be decoded and interpreted as command/control bytes and not as data bytes.

This creates a problem when an transmitter actually needs to send 0xFF as a data byte. According to the encoding rules, each occurrence of an actual 0xFF data byte needs to be ‘escaped’, meaning, the 0xFF byte will be sent as a sequence of 0xFF 0xFF (IAC IAC) bytes.

According to the TELNET protocol the receiver converts this 0xFF 0xFF sequence back to the original 0xFF data byte, thus ensuring proper reception. See also http://www.tcpipguide.com/free/t_TelnetProtocolCommands-2.htm

T:LAN OS BEHAVIOUR:

BN6404 did not support this escaping mechanism for BINARY MODE connections. BN7618 does, as per TELNET standard. However, this seems to have created an issue, as evidenced by failed attempts when downloading very long sequences of MDR-8000 RSL data points.

AFFECTED UNITS:

All T:LAN units running OS versions HIGHER than BN6404 and LESS than BN7622 and connected to MDR-8000 radios.

REMEDY:

BN7622 removes the 0xFF to 0xFF 0xFF TELNET conversion operation from BINARY MODE connections. Reverting back to the earlier (incomplete TELNET implementation found for instance in BN6404) will thereby ensure backwards compatibility. Update all impacted units to BN7622.