TCP Write seems to no longer work since about June 1st

[Dave@Ventec]

I have a personal weather station uploading to Weather Underground using LabVIEW for a couple of years.  It quit working about June 1st and I am just now finding time to troubleshoot the issue.  Having tried everything I can think of, I am beginning to wonder if something changed within LabVIEW itself causing my issue??

Attached is a snippet from my trouble shooting VI - the line at the top works correctly if copied and pasted into a browser - in this case Chrome.

Also attached is a copy of the traffic captured at port 80 from the Chrome test - note that it has a "success" reply from Weather Underground as it should - and I can see that it has been accepted and posted on the website.

Also attached is a copy of the traffic captured at port 80 using my trouble shooting VI tying to duplicate Chrome EXACTLY and I believe I have - but I do not get a "success" reply and it is NOT posted on the website.

Perhaps I am now just blurry eyed but they seem identical to me.  Can anyone suggest what might be wrong here?  

[nathand]

Of course you don't get a "success" reply - you close the TCP connection immediately after sending the data.  I know very little about HTTP, but I wonder if the "keep-alive" instruction is causing some conflict with the fact that you close the TCP connection.

If I'm not mistaken, both the DataSocket functions and some VIs included in the Internet Toolkit (if you have it) can open a URL and read the response.  Have you considered trying one of those, instead of sending the raw HTTP data yourself?

[Dave@Ventec]

I have put a delay of varing lenghts between the write and the close to wait for a response - makes no difference.  Besides monitoring the port seperately ouside of LabVIEW would see the reply - I think...

I do not have the Internet Toolkit...  The real question is why did this work as presented but does not now - ecept through a browser -  has something changed in LabVIEW?

Appreciate your help.

David

[nathand]

You should still be able to use the DataSocket functions without the internet toolkit.

I think it's more likely that something changed on the weather underground site, or possibly some Windows update, than in LabVIEW.  Have you tried adding a TCP read after the write to see if you get a response, instead of adding a wait?  Is it possible you're missing a termination character that wouldn't be easily visible but would affect whether the data is accepted?

How are you doing the port monitoring?  You would not necessarily see the response in the monitor if the connection is already closed, since if I'm mistaken, closing the connection tells the remote side that the connection is closed, in which case it should not send any response.

Have you tried changing the timeout for the TCP Write?

[altenbach]

What is the OS?

What else happened on June 1?

Did you check your firewall settings? Is the application allowed to access the internet?

Can you compare the raw packets? Maybe the line termination characters need to be different.

[Dave@Ventec]

The OS is Windows 7 running virtually with Parallels on a MAC with OS X 10.8.2  - This is my standard configuration that I have used for years - inclduing this application.  I have tried other machines as well - same issue.  

NO firewalls enabled on any of the devices....

The line termination characters were suspect, but I have tried all resonable combinations - and as you see in the snippet is how they were working before.

I also set up the LabView WebServer VI and looked at both Chrome and my VI going to LocalHost - attached - again I see no differences.

I've looked at the hex dump and haven't found anything yet - but am still looking.

As to June 1 - have not been able to put my finger on anything - but looking at the data reccord on Weather Underground that is when it changed....

[altenbach]

It is difficult to see any difference if the array elements are scrolled differently. 😮

can you enable \-codes display on the string indicator?

[Dave@Ventec]

Actually I didn't scroll them differently....the element associated with GET/weatherstation/ does fill differently depending on the capture....  I believe that is timing associate with advancing a breakpoint so I can get a screen shot before it reloads.....

Attached are both my VI and Chrome with \-code on.  I did notice an extra line feed carriage return at the very end of the Chrome string so I added an extra on mine as well and am posting that version.  Still didn't get posted at Weather Underground.

[nathand]

Have you tried adding a TCP Read after your Write to see if the LabVIEW code receives any response from the Weather Underground server?

[Dave@Ventec]

I have - using all variations of the read - no response received - same as the port sniffer shows.

Also I have now run the example VI Patterns For Communicaing with Remote VI's - just to be sure on ports and communications - runs just fine.