Re: Raw Post/Connect Issue

[Michael Ryan <michaelrtr@xxxxxxxxx>]

   Thanks to all who chimed in on this. The vendor and I went around, and
   they actually shipped a laptop and test device to me so they could
   remote in an check out what was happening. The developer I was working
   with was making changes to their C (not ++, not #) as we were speaking.
   It turns out that they weren't receiving the entire transmission, and
   were moving on and causing an error. They basically put retries in to
   read the entire message I was sending.�   I'm using a sockets program (thanks Scott) instead of an HTTP POST
   (thanks Scott) and it's working pretty well.�   Again, thanks for all that had ideas and shared them!

   On Mon, Mar 16, 2015 at 9:03 PM, Charles Wilt
   <[1]charles.wilt@xxxxxxxxx> wrote:

     � �Yep going back to the raw comm traces, comparing the trace from
     IBM i
     � �<-->Device to PC <-->Device will give you the answer.
     � �You might have to dig into the raw bytes sent instead of just
     looking
     � �at the pretty wireshark summary...
     � �You also might see if there's anyway to trace from the device
     side.
     � �I once got involved in trying to figure out why we were having
     comm
     � �errors on Win Mobile 5.0 cellular handhelds talking to a
     backend app
     � �running on a windows server.�  And just for fun, there was a
     "relay"
     � �server in the DMZ that the connections got relayed through.
     � �Traces at the device, the relay server and the backend server
     told the
     � �story...
     � �Turned out that while the software used a protocol identified
     as HTTP,
     � �it wasn't really.�  When the packets would hit certain parts
     of the
     � �Verizon network, they would get broke up/reformated/optimized.�     � �Perfectly legitimate for HTTP but the app could not deal with
     it.�  Had
     � �to move to a different port so version would leave them alone.
     � �Good luck!
     � �Charles
     � �On Mon, Mar 16, 2015 at 6:22 PM, Mike Krebs
     � �<[1][2]mkrebs@xxxxxxxxxxxxxxxxxx> wrote:
     � � �I am sure you understand that if the device is in error at
     connect,
     � � �something is really wrong. But could the TCP connect code be
     bad on
     � � �your IBMi? I doubt it.
     � � �Back to comparing the wireshark SYN/ACK-SYN/ACK bytes and
     see if you
     � � �can determine what the IBMi SYN/ACK-SYN/ACK is sending or
     not
     � � �sending that the device doesn't like.
     � � �I can't imagine the device people wrote their own sockets
     but if so,
     � � �they missed something. If not, could it possibly be wrong?
     � � �Unlikely....but you know one or the other is wrong.
     � � �Hmmm? Fun debug - and I'm sure pretty frustrating at this
     point.
     � � �Good luck.
     � � �-----Original Message-----
     � � �From: [2][3]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
     � � �[mailto:[3][4]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On
     Behalf Of
     � � �Michael Ryan
     � � �Sent: Monday, March 16, 2015 2:59 PM
     � � �To: HTTPAPI and FTPAPI Projects
     � � �Subject: Raw Post/Connect Issue
     � � �I had the post about using http_raw to post to a device. The
     vendor
     � � �has been pretty accommodating, but doesn't see the problem.
     They
     � � �asked me to write a socket program as a proof of concept
     type thing.
     � � �I took one of my existing programs (in solid production for
     years),
     � � �stripped it down, and gave it a try.
     � � �When I do a tconnect (I've also tried a connect), the device
     flashes
     � � �communication error and puts a zero on the screen. I think
     this is
     � � �probably the same issue when I was using HTTPAPI. I receive
     a return
     � � �code of zero for the tconnect which I think is good. The
     vendor is
     � � �baffled since their Intel customers (everyone except me)
     doesn't
     � � �have a problem.
     � � �Any stabs in the dark? Thanks...
     � �     �------------------------------------------------------------------
     --
     � � �---
     � � �This is the FTPAPI mailing list.�  To unsubscribe, please
     go to:
     � � �[4][5]http://www.scottklement.com/mailman/listinfo/ftpapi
     � �     �------------------------------------------------------------------
     --
     � � �---
     References
     � �1. mailto:[6]mkrebs@xxxxxxxxxxxxxxxxxx
     � �2. mailto:[7]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
     � �3. mailto:[8]ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
     � �4. [9]http://www.scottklement.com/mailman/listinfo/ftpapi
     --------------------------------------------------------------------
     ---
     This is the FTPAPI mailing list.� To unsubscribe, please go to:
     [10]http://www.scottklement.com/mailman/listinfo/ftpapi
     --------------------------------------------------------------------
     ---

References

   1. mailto:charles.wilt@xxxxxxxxx
   2. mailto:mkrebs@xxxxxxxxxxxxxxxxxx
   3. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   4. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   5. http://www.scottklement.com/mailman/listinfo/ftpapi
   6. mailto:mkrebs@xxxxxxxxxxxxxxxxxx
   7. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   8. mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
   9. http://www.scottklement.com/mailman/listinfo/ftpapi
  10. 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
-----------------------------------------------------------------------