Why can't I get a reply on my TCP node? (Wireshark Info included)

Hi All,

I'll start by saying, I don't think this is specifically a NR issue, but I don't know where else to ask and I'm hoping the knowledge of the forum will be able to give me some pointers.

The scenario: Alarm panel with an IP connection. Software on PC can connect without issue.

The desire: To reverse engineer the protocol, and use node red to poll the alarm to receive system info.

The Method: I used wireshark to record the TCP traffic between the alarm and the software during a connection. Everything is unencrypted and the commands are exactly the same no matter when or how I connect (simple protocol, not time based)

I took the HEX data sent by the software from Wireshark, and made several 'change' nodes in a flow, which send the data via TCP to the alarm. I was expecting a response.
image

Looking at the NR TCP traffic in Wireshark, it appears that I'm sending exactly the same data as the official alarm software is, but the alarm never responds. I get an 'ack' but no data sent.

I'm at a loss as to why this could be. I'm fairly familiar with NR, but relatively new to working with TCP. Any help would be greatly appreciated.

Here is the first data sent from the software, with response from the alarm:

And here is the traffic when attempting to connect from Node Red - The same data is sent, but nothing received.

Thanks in advance for any and all help

maybe there is some preamble or handshake when the pc application first starts up, kinda like a login that then permits communication?

What is the make and model of this alarm panel?

Thanks for your reply.

There is a handshake with the software, which is what I'm trying to recreate in NR. The 'handshake' is always the same when the software connects. The software always sends the same data, and the alarm always sends the same reply. There's around 5 exchanges before the software is 'online' - I've tried sending all 5 as well as only the first, only the second, etc.

As a test, I also made a flow which emulates the alarm side, and the software can connect to that and thinks it's connected to the alarm, so I know the Wireshark data seems to be good.

I'm just completely stumped with this one!

The alarm is a texecom premier elite 168 on v4.x

In your example, the software in position 6 sends a frame ending in 0489.
But in your NR simulation at position 6 you send the wrong frame, which ends with 38e8.
Isn't this frame missing?

No that is the reply from the other device.. which is what he is not seeing for some reason. Only thing I can think is that in the working case the initial packet at 4 is not sent for 2seconds after start. Maybe the NodeRED version is starting before the other end is ready ?

1 Like

You're right regarding it being the reply not the sent data.

I hadn't thought about the delay between connection and data sent, but this is a very good lead to look into!
It would explain why I get some kind of response around 1 in 20 attempts.

I'll try to introduce delays and report back.

Thanks again.

We have a winner!

I had attempted delays previously, but the method had been sending the initial data, waiting for a few seconds, and sending again.

This time, I tried by sending empty data to open the connection, waiting 2s, and then sending the following data and... Bingo!

I'm on a road trip with patchy signal right now so can't test further for a while, but this seems to be the missing part of the puzzle.

Thank you!

2 Likes