Anyone using HTTPCMD?

[Andrew S]

I'm using a directly assigned IP address. It's not a variable.

I came to the same conclusion Bob, but of the scenarios you mentioned I don't know that any really fit my situation. I've validated and re-validated the IP address (I'm able to use the exact same IP address from another client on the same subnet), it's on the same subnet as the server (so unlikely to be an ARP failure) and we're not using DNS for this since it's an IP address.

Perhaps I just need a holiday...

[Andrew S]

I'm still beating my head against a wall with this.

I added a PING statement which works fine. This tells me that the network connectivity is good.

Wireshark shows TCP SYN packets being sent from the PLC to the Server, but no ACK responses come from the server. However, all other clients I've tried elicit a correct response from the server.

Here's the really strange thing - if I run the PING first, the HTTPCMD succeeds, and continues to succeed for a while. After a period of inactivity it starts failing again, until I PING the server once more.

Is it possible that ARP handling is failing for HTTPCMD but it's working for PING?

Another thing to note is that it works just fine (always) on a different NodeJS server. The server that's failing is an Ubuntu 19.04 box running in a Hyper-V VM on my Win10 box. Once again though, other clients always connect to it just fine - it's just the PLC/this-particular-server combo that's causing a problem.

[BobO]

Is it possible that ARP handling is failing for HTTPCMD but it's working for PING?

Doubtful. Stack doesn't know the difference.

[franji1]

Another thing to note is that it works just fine (always) on a different NodeJS server.

By "it", do you mean the BRX PLC doing HTTPCMD?

[plcnut]

I have only piddled with NodeJS, but have done a lot with IIS.
In IIS you can set up your server to only respond to a request based on the Name versus an IP request. I do not know if this "filtering" happens at the connect, or at the request level.
The only servers that I maintain are on private networks, so we always set them to work based on the IP.
Maybe the NodeJS server doesn't like the request from the BRX?

[Andrew S]

By "it", do you mean the BRX PLC doing HTTPCMD?

Yes. The solution works end-to-end if I run a PING first. At least for a while.

Another weirdness I've come across is that I can't get HTTPCMD to succeed (ever) if I use TCPOPEN. The TCPOPEN connects successfully (and the CLOSE works correctly too) but the HTTPCMD always fails without an error code (just the error bit being set). Since there's no diagnostics I can't tell why it fails but if I bypass the TCPOPEN and CLOSE statements and change the same HTTPCMD statement to specifically use either an IP address or hostname, it succeeds.

[Andrew S]

Maybe the NodeJS server doesn't like the request from the BRX?

It's not getting as far as the server (which doesn't by default care how you reach it - IP address or any hostname is ok by default). The problem occurs lower down at the TCP negotiation.

[BobO]

By "it", do you mean the BRX PLC doing HTTPCMD?

Yes. The solution works end-to-end if I run a PING first. At least for a while.

Another weirdness I've come across is that I can't get HTTPCMD to succeed (ever) if I use TCPOPEN. The TCPOPEN connects successfully (and the CLOSE works correctly too) but the HTTPCMD always fails without an error code (just the error bit being set). Since there's no diagnostics I can't tell why it fails but if I bypass the TCPOPEN and CLOSE statements and change the same HTTPCMD statement to specifically use either an IP address or hostname, it succeeds.

The option to TCPOPEN then HTTPCMD may not work. We had good thoughts, but reality got in the way. I thought that option got removed, but I guess not.

[Controls Guy]

What if you load the program on a SIM on one of the PC's that can access the server?

[Andrew S]

What if you load the program on a SIM on one of the PC's that can access the server?

Same behavior as the PLC.

[BobO]

Same behavior as the PLC.

Windows stack is *very* different than the hardware's stack. I'd be looking elsewhere.