[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using raw to post data
Hard to say..."We are listening on the raw socket for an inbound tcp
request with http headers"
Doesn't tell us much...
You said you had a PC tool that successfully talked to the device.� I
assume it's a tool provide by the vendor?
And you mentioned a doing a wireshark trace.
That might be your best bet assuming the vendor isn't forthcoming with
the technical details.
Charles
On Fri, Feb 27, 2015 at 3:05 PM, Michael Ryan <[1]michaelrtr@xxxxxxxxx>
wrote:
� �Well...this may be an issue...
� �From me to vendor:
� �Usually when I communicate using an HTTP POST, itâs something
like
� �this:
� �� � �[1][2]http://www.twcs.cc/tfcapps/tfc_process_sts.tsk
� �Where http is the protocol, [2][3]www.twcs.cc is the host URL,
and
� �tfcapps/tfc_process_sts.tsk is the thing that gets executed.
� �Iâm just sending this to the device:
� �[3][4]http://192.168.1.99:986
� �With no task or program to be executed. I think I need
something there.
� �� � �Vendor response:
� �No, that isnât quite how we have it built. We are listening on
the raw
� �socket for an inbound tcp request with http headers. Not really
a
� �standard web service.
� �What can I do?
� �On Fri, Feb 27, 2015 at 1:42 PM, Scott Klement
<[4][5]sk@xxxxxxxxxxxxxxxx>
� �wrote:
� � �The difference in content length is that "<?xml
version="1.0" ?>"
� � �was omitted from his 2nd attempt.
� �On 2/27/2015 12:39 PM, Mike Krebs wrote:
� � �I was little surprised to see the content-length change when
you
� � �changed that. Scott might know if that is the way it works
but I
� � �thought additional headers were headers and not content.
� � �Reading up on Connection:close real quick looks like it
should have
� � �been okay. I think the protocol calls for closing the
connection
� � �after the response, so that should have been okay.
Basically, you
� � �would be telling the server that it is okay to close the
connection
� � �when they are finished. It appears that was the default
behavior on
� � �HTTP 1.0 but can be assigned using HTTP 1.1
� � �Which brings us to this:
� � �POST / HTTP/1.1
� � �Where are you posting this to? It appears you might have
missed the
� � �actual location of the service.
� � �-----Original Message-----
� � �From: [5][6]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
� � �[mailto:[6][7]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On
Behalf Of
� � �Michael Ryan
� � �Sent: Friday, February 27, 2015 12:19 PM
� � �To: HTTPAPI and FTPAPI Projects
� � �Subject: Re: Using raw to post data
� � �Well, it made sense to take it out the CONNCLOSE additional
� � �header...I need to wait until the user does
something...still
� � �getting the same error though. Here's the latest debug log.
� � �On Fri, Feb 27, 2015 at 1:15 PM, Michael Ryan
� � �<[7][8]michaelrtr@xxxxxxxxx> wrote:
� � �Hmmm...I'll take that out and see what happend. Thanks Mike.
� � �On Fri, Feb 27, 2015 at 1:11 PM, Mike Krebs
� � �<[8][9]mkrebs@xxxxxxxxxxxxxxxxxx>
� � �wrote:
� � �Some of the things you see in the debug are in fact the
headers that
� � �are being sent and Content-Length is one of them. I didn't
count the
� � �bytes but
� � �140 seems about right.
� � �The recvresp(): end with err is new one for me. I am used to
seeing
� � �something more descriptive there. I wonder if that is
related to
� � �Connection: close being sent.� That doesn't seem right to
me.
� � �-----Original Message-----
� � �From: [9][10]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:
� � �[10][11]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of
Michael Ryan
� � �Sent: Friday, February 27, 2015 11:41 AM
� � �To: HTTPAPI and FTPAPI Projects
� � �Subject: Using raw to post data
� � �I've modified an existing program to talk to a device. I
know I'm
� � �hitting it - I can see the device light up. But I don't get
a valid
� � �response - seems like it's an error. I've attached the debug
� � �log...can anyone shed any light? The vendor suggested that
� � �content-length wasn't being passed. I can't see the actual
headers
� � �in
� � �the debug log, but the log certainly indicated
content-length was
� � �passed. Thanks!
� � �------------------------------------------------------------------
--
� � �-
� � �-- This is the FTPAPI mailing list.� To unsubscribe,
please go to:
� � �[11][12]http://www.scottklement.com/mailman/listinfo/ftpapi
� � �------------------------------------------------------------------
--
� � �-
� � �--
� � �------------------------------------------------------------------
--
� � �---
� � �This is the FTPAPI mailing list.� To unsubscribe, please
go to:
� � �[12][13]http://www.scottklement.com/mailman/listinfo/ftpapi
� � �------------------------------------------------------------------
--
� � �---
� �------------------------------------------------------------------
-----
� �This is the FTPAPI mailing list.� To unsubscribe, please go
to:
� �[13][14]http://www.scottklement.com/mailman/listinfo/ftpapi
� �------------------------------------------------------------------
-----
References
� �1. [15]http://www.twcs.cc/tfcapps/tfc_process_sts.tsk
� �2. [16]http://www.twcs.cc/
� �3. [17]http://192.168.1.99:986/
� �4. mailto:[18]sk@xxxxxxxxxxxxxxxx
� �5. mailto:[19]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
� �6. mailto:[20]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
� �7. mailto:[21]michaelrtr@xxxxxxxxx
� �8. mailto:[22]mkrebs@xxxxxxxxxxxxxxxxxx
� �9. mailto:[23]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
� 10. mailto:[24]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
� 11. [25]http://www.scottklement.com/mailman/listinfo/ftpapi
� 12. [26]http://www.scottklement.com/mailman/listinfo/ftpapi
� 13. [27]http://www.scottklement.com/mailman/listinfo/ftpapi
--------------------------------------------------------------------
---
This is the FTPAPI mailing list.� To unsubscribe, please go to:
[28]http://www.scottklement.com/mailman/listinfo/ftpapi
--------------------------------------------------------------------
---
References
1. mailto:michaelrtr@xxxxxxxxx
2. http://www.twcs.cc/tfcapps/tfc_process_sts.tsk
3. http://www.twcs.cc/
4. http://192.168.1.99:986/
5. mailto:sk@xxxxxxxxxxxxxxxx
6. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
7. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
8. mailto:michaelrtr@xxxxxxxxx
9. mailto:mkrebs@xxxxxxxxxxxxxxxxxx
10. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
11. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
12. http://www.scottklement.com/mailman/listinfo/ftpapi
13. http://www.scottklement.com/mailman/listinfo/ftpapi
14. http://www.scottklement.com/mailman/listinfo/ftpapi
15. http://www.twcs.cc/tfcapps/tfc_process_sts.tsk
16. http://www.twcs.cc/
17. http://192.168.1.99:986/
18. mailto:sk@xxxxxxxxxxxxxxxx
19. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
20. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
21. mailto:michaelrtr@xxxxxxxxx
22. mailto:mkrebs@xxxxxxxxxxxxxxxxxx
23. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
24. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
25. http://www.scottklement.com/mailman/listinfo/ftpapi
26. http://www.scottklement.com/mailman/listinfo/ftpapi
27. http://www.scottklement.com/mailman/listinfo/ftpapi
28. http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------