Exception thrown kills Node

[gfcittolin]

This issue refers to the thread at st-one-io/node-red-contrib-s7#30 (comment)

There's an odd issue when communicating with LOGO! devices, where the last byte is missing in the response telegram, and this last byte arrives later at another telegram. The big issue happens when we try to check if the second packet is valid by checking its header fields, but this second telegram is only one byte length, and a range index error is thrown.

From the previous mentioned issue:

nodered_1 | [106045,280937200 192.168.0.1 S2] ReadResponse called
nodered_1 | [106045,281001000 192.168.0.1 S2] Time is 0 seconds and 261.5 ms.
nodered_1 | [106045,281056100 192.168.0.1 S2] Address DB61,INT42 has value 1 and quality OK
nodered_1 | [106045,281076100 192.168.0.1 S2] Address DB61,INT44 has value 9 and quality OK
nodered_1 | [106045,281085900 192.168.0.1 S2] Address DB61,INT46 has value 36 and quality OK
nodered_1 | [106045,281101600 192.168.0.1 S2] Address DB61,CHAR48.72 has value LS 44.2 1.WT nicht vorhanden(3x schlecht) and quality OK
nodered_1 | [106045,281111400 192.168.0.1 S2] Address DB61,DINT134 has value 0 and quality OK
nodered_1 | [106045,281134700 192.168.0.1 S2] We are calling back our readDoneCallback.
nodered_1 | [106045,338518300 192.168.0.3 S2] Reading All Items (readAllItems was called)
nodered_1 | [106045,338623500 192.168.0.3 S2] Calling SRP from RAI
nodered_1 | [106045,338637500 192.168.0.3 S2] SendReadPacket called
nodered_1 | [106045,338720500 192.168.0.3 S2] Sending Read Packet
nodered_1 | [106045,338735700 192.168.0.1 S2] Reading All Items (readAllItems was called)
nodered_1 | [106045,338758000 192.168.0.1 S2] Calling SRP from RAI
nodered_1 | [106045,338765000 192.168.0.1 S2] SendReadPacket called
nodered_1 | [106045,338811900 192.168.0.1 S2] Sending Read Packet
nodered_1 | [106045,596579600] INVALID READ RESPONSE - DISCONNECTING
nodered_1 | [106045,596628000] TPKT Length From Header is 39 and RCV buffer length is 38 and COTP length is 2 and data[6] is 128
nodered_1 | [106045,596656600] <Buffer 03 00 00 27 02 f0 80 32 03 00 00 00 02 00 02 00 12 00 00 04 02 ff 04 00 30 00 01 00 09 00 24 ff 04 00 20 00 00 00>
nodered_1 | [106045,596692800] ConnectionReset is happening
nodered_1 | 16 May 15:57:58 - [red] Uncaught Exception:
nodered_1 | 16 May 15:57:58 - RangeError: Index out of range
nodered_1 | at checkOffset (buffer.js:977:11)
nodered_1 | at Uint8Array.Buffer.readInt16BE (buffer.js:1121:5)
nodered_1 | at checkRFCData (/usr/src/node-red/node_modules/nodes7/nodeS7.js:1474:27)
nodered_1 | at NodeS7.onResponse (/usr/src/node-red/node_modules/nodes7/nodeS7.js:1120:11)
nodered_1 | at Socket. (/usr/src/node-red/node_modules/nodes7/nodeS7.js:390:20)
nodered_1 | at emitOne (events.js:116:13)
nodered_1 | at Socket.emit (events.js:211:7)
nodered_1 | at addChunk (_stream_readable.js:263:12)
nodered_1 | at readableAddChunk (_stream_readable.js:250:11)
nodered_1 | at Socket.Readable.push (_stream_readable.js:208:10)
nodered_1 | at TCP.onread (net.js:601:20)
nodered_1 | npm ERR! code ELIFECYCLE
nodered_1 | npm ERR! errno 1
nodered_1 | npm ERR! node-red-docker@1.0.0 start: node $DEBUG_OPTIONS $NODE_OPTIONS node_modules/node-red/red.js -v $FLOWS "--userDir" "/data" "--settings" "/usr/src/node-red/settings.js"
nodered_1 | npm ERR! Exit status 1
nodered_1 | npm ERR!
nodered_1 | npm ERR! Failed at the node-red-docker@1.0.0 start script.
nodered_1 | npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
nodered_1 | at readableAddChunk (_stream_readable.js:250:11)
nodered_1 | at Socket.Readable.push (_stream_readable.js:208:10)
nodered_1 | at TCP.onread (net.js:601:20)

I propose a fix in two steps:

• As a hotfix, put a length check at onResponse, just preventing that we crash the whole process
• Properly fix the issue. Some discussion need to be done, mainly because I'm not sure if it's worthy to be done to the actual codebase, since the next branch is close do be done, and would handle such a behavior without any problem.

[plcpeople]

OK I will do a release on npm with the hotfix, I agree it would be nice to fix it properly and join the packets and process the reply as a valid one, but that may not be practical right now.

[gfcittolin]

Thanks once again for merging and publishing it!

Just a side node: if you check the published node, there are some other files there... nothing harmful, only something to cleanup on your checkout there before publishing it ;)