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.
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:
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.
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 ?
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.
