Anyone using HTTPCMD?

[Andrew S]

I'm having a heck of a time getting my BRX to talk to an in-house webserver using HTTPCMD. Even though the webserver appears to be functioning correctly from multiple pc-based clients (so there's no firewall issue here) the PLC won't connect to it. I'm connecting using an IP address and I've double-checked the port number. The dialog is simple - I send a GET with a specific URL to the server, and the server responds with a 5-digit code. There's no HTML involved and I"m not sending any special headers. I'm confident that the network config isn't the issue here.

DMLogger reports:
Connecting to HTTP server...
Error connecting to HTTP server
Couldn't open TCP connection with specified device in HTTPCMD

Response Status code is 0.


Any thoughts about how I could debug this further? I'm pulling my hair out (at least what little hair I have left....)

Thanks, Andrew.

[ADC Product Engineer]

Using Wireshark to look at the messaging back and forth to the server might give some clue.  It would need to be installed on the server or a switch that supports mirroring would need to be used to see the traffic.

[Andrew S]

Thanks. I did look at Wireshark but it shows only the TCP SYN received at the server. Nothing else appears to happen, not even an ACK. It's very strange.

[Andrew S]

I noticed that the Ethernet header has the destination set to the broadcast address (FF:FF:FF:FF:FF:FF). Am I missing something in the HTTPCMD that's causing this?

EDIT: Sorry, edited to say Ethernet header, not TCP header. Also, the IP dest IS set correctly.

[plcnut]

What type of server is it (IIS, Wamp, )?
When you send a test call to the server, are you testing using the IP and port, or using a name?

[Andrew S]

What type of server is it (IIS, Wamp, )?
When you send a test call to the server, are you testing using the IP and port, or using a name?

This is a NodeJS Express server. I'm using the IP and port. The server is on the same subnet as the PLC. The packet doesn't make it as far as the webserver - I think the issue with the destination being the broadcast address is the root cause of the problem. I'm just not sure how I can resolve it.

In case it matters I'm using DMD 2.6.1.

[plcnut]

Are you using an existing TCP connection?

[Andrew S]

Are you using an existing TCP connection?

No. I'm using the HTTPCMD statement to dynamically open and close the connection.

[plcnut]

Just for kicks, you may want to try opening a connection externally, and then see if the command will run.

BTW:
I have not used the new HTTPCMD instruction, but have extensive experience in raw TCP using DMD.

[Andrew S]

I'll give that a try. Thanks.

I looked in the System Information screen and noted a couple of messages that appear to be relevant:
In Warning Messages:
"Device driver error - $DriverError (ST143)"
In Last Error(s):
Unknown error (64)...in HTTPCMD at" ...

[Andrew S]

The OPENTCP command fails but doesn't provide any diagnostics about why.

[plcnut]

Interesting.
If I had time, I would run some tests on my own, but I'm kinda covered up...
You might post some screenshots of what you have so we can take a quick look.

[Andrew S]

I'll do that. Thanks for your assistance.

[BobO]

We refactored the errors returned from OPENTCP and any of the instructions that use a TCP connection (HTTPCMD, EMAIL), with the specific intention of distinguishing between connections that were dropped by the server vs those that never succeeded. Previously both of those used a generic "something broke" error. The 64 code means that the connection was never established to begin with, and somebody (read: Yours Truly) forgot to add an error description to the appropriate table. So basically the controller isn't getting the answer from the server.

FF:FF:FF:FF:FF:FF is the broadcast address, which means that a valid TCP address either wasn't provided, the ARP didn't work, or the DNS came back with something jacked up.

[plcnut]

Are you using a variable for the IP?
If so, try viewing it as an IP from a Dataview to make sure the format is correct.