Hi,
(Any Synapse experts around :-) ? )

With the great help from Thomas (who taught me to understand how the Linker works and that it's error messages are not what I supposed them to be) I have been able to compile and partly run my Snapse-based project - that already runs fine on Windows and PC-Linux - on my QBAP NAS device.

It can receive and send E-Mails via POP3 and SMTP just fine and does access a HTTP server (the controller of a Central Heating attached to the local Ethernet) via HTTP.

The problem is, that the HTTP access to the "embedded Web Server" in the Heating Controller rather often results in a timeout. (Supposedly the small CPU in the controller is too busy with other stuff and just drops the Socket open request instead of answering.)

For the Windows and PC Linux versions of my project this is no problem at all. When I get any error message from Synapse, I simply do a retry. I found I never need more than just another try to make it work decently. (Supposedly any Browser does this under the hood without the user noticing it.)

But when using the same Pascal code for my project and Synapse (the RTL and FCL libraries are from the svn for the PC, but from the "TAR-distribution" for ARM) on the ARM Box, the project infinitely hangs when this situation is hit. Usually several HTTP requests do work and it hangs with the next one.

Synapse (or whatever is called by same) It hangs in state "5" ("HR_Connect") and obviously never returns to my user code.

When it hangs, even CTRL-C does not have any effect and I need to use "kill" from another console session.

I tried to reproduce this with a more simple project, just accessing a non-existing IP address, but I found that while on Windows here Synapse issues a time out (after some seconds, exactly like when the Heating Controller fails to answer), when compiling for Linux (PC and ARM) the error message is "HR_Error: 113,No route to host" and is issued immediately and thus not involves a timeout (and no hanging on ARM).

So I'm out of luck, as I would need to install debugging tools (Lazarus locally, Remote debugging with Lazarus) or learn to work with gdb on fpc projects) and try to find problems in code that is not created by myself. This does not sound like easy to do.

Any suggestions on how to proceed ?

Thanks
-Michael

Al 28/01/13 11:47, En/na Michael Schnell ha escrit:

(Supposedly any Browser does this under the hood without the user noticing it.)

I don't think so.
Anyway, it can be that your problem is too long a connection timeout (which is system dependent). There was a patch a while ago to synapse to add a ConnectionTimeout, but I don't know if it's included in the current version.

Bye

Luca Olivetti wrote

Anyway, it can be that your problem is too long a connection timeout (which is system dependent).

This would be hours, then. But maybe it is that way on that system.

There was a patch a while ago to synapse to add a ConnectionTimeout, but I don't know if it's included in the current version. Bye

I'll take a look.

In the svn - version in blksock.pas there is a property
ConnectionTimeout: Integer read FConnectionTimeout write FConnectionTimeout;

Is this what you suggest ?

I'll try to set it, as soon as I have access to the box again.

Thanks,
-Michael

On Mon, January 28, 2013 11:47, Michael Schnell wrote: .
.

.
.

While I don't know how to fix your problem, this "no route to host" should be possible to solve (whether it helps you in reproducing and fixing your issue is another question). What is the IP address and netmask of your device and what is the (non-existing) IP address which you try to access?

Tomas

I used the same source code for all compiles (Windows, PC Linux and ARM-Linux), and I tried to use an IP-Address within the local network (192.168.71.XXX) .

I'll take another look ASAP.
Thanks,
-Michael

Al 28/01/13 12:26, En/na Michael Schnell ha escrit:

On 01/28/2013 12:18 PM, Luca Olivetti wrote: > Anyway, it can be that your problem is too long a connection timeout (which is system dependent). This would be hours, then. But maybe it is that way on that system.

Well, then it's not it. The default connection timeout should be 20 seconds.

Yes, that's it.

Bye

Luca Olivetti wrote

Well, then it's not it. The default connection timeout should be 20 seconds.

This is a slightly propriety Linux distribution by QNAP. So we can't be sure...

-Michael

Al 28/01/13 12:49, En/na Luca Olivetti ha escrit:

or around 3 minutes, I'm not really sure, but certainly not hours.

Bye

In fact I feel that "no Route" is the more appropriate Error message.

When trying to access a not known local IP, the system should issue an ARP request that will time out much faster than the Connect Timeout. After this a "no Route" Error should be generated by the system.

-Michael

i'm trying to make sure i'm following along here because i'm also using synapse for a project...

using a "slightly modified" testhttp (that came with synapse, attached) and attempting to connect via http to a non-existant IP in my network, i get a 0 result code, empty result string and "Connection reset by peer" string on my winwhatever box but that may be due to a firewall proxy that is injected into all http streams on that winwhatever system... on my os/2 eCS2 box, i get 500 result code, empty result string and "Connection refused" string... however, if i try using a non-existent hostname, both return 500 result code, empty result string and "Host not found" string...

i would suggest that trying to use a non-existent IP or host is not the way you want to go to test this... the results are not going to be what you should be getting from the heating controller connection when it fails...

your "No route to host" actually sounds plausible if there is, in fact, no route to the IP you have chosen... that also sounds like there's no default routing gateway defined for networking traffic headed out of the local network... when i test trying to access a non-existent IP outside my local network, my winwhatever box reports "Connection reset by peer" (as above) and my OS/2 eCS2 box reports "Connection timed out"...

suffice it to say that synapse's error codes are not always they seem to be, unfortunately... run testhttp and you'll see what i mean... i'm pretty sure there are other result codes and strings that i've not been told about or discovered yet... oh, and yes, this testhttp will use ssl libraries if they exist so you can test against https as well as http ;)

EG:
testhttp http://google.com/

301 Moved Permanently
"ssl_openssl" "OpenSSL 0.9.8o 01 Jun 2010"
""
""
""

HTTP/1.0 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Mon, 28 Jan 2013 19:00:49 GMT
Expires: Wed, 27 Feb 2013 19:00:49 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Connection: Keep-Alive

testhttp https://google.com/

301 Moved Permanently
"ssl_openssl" "OpenSSL 0.9.8o 01 Jun 2010"
""
""
""

HTTP/1.0 301 Moved Permanently
Location: https://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Mon, 28 Jan 2013 19:01:35 GMT
Expires: Wed, 27 Feb 2013 19:01:35 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 220
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Connection: Keep-Alive

I'll do another test and report...

-Michael

Follow-up:

I d/l'ed the most recent Synapse snapshot and when compiling I get:

Compiling ./synapse/synautil.pas
jedi.inc(512,4) Error: Illegal assembler style specified "INTEL"

This is easily fixed by commenting out the appropriate line in jedi.inc, but it shows that this Synapse version is not yet tested on ARM.

Now I set the ConnectTimeout to 10000 (10 seconds) and retested.

I found that in fact Synapse does return to the user program which requests a retry but in one test of the same project it finished after about 30 Minutes and in another it was after more than 60 (I killed the test after that time.) .

Either some other Timeout definition is used, or the timeout in that case does not work decently

I found that with Synapse on Windows and PC Linux, the Target (Heating Controller device) mostly seems to force a timeout (or some other error resulting in a retry) but sometimes not. With 20 or more seconds connect timeout I usually get one retry, with 10 Seconds connect Timeout I usually get two retries. But on ARM the project always hangs on the third HTTP request (after two successful ones.)

I did do some logging using HTTPSend.Sock.OnStatus. (complete Logs below)

Here in Windows I see a:
"13:10060,Connection timed out"
after 30 Seconds (I think I did set the ConnectTimeout to 30000 at this time)
resulting in a retry requested by my software.

Note that the timeout comes after
"2:IPv4"
("2" being HR_SocketCreate if I am not failed, and "7" = HR_CanWrite / "5" = HR_Connect are not reached on the first try.)

The Log for the ARM version shows something very different (unfortunately this version of my software did not yet timestamp the log. I'll retest with the updated version ASAP.)
"2:IPv4"
"7:"
"5:192.168.71.252:80"
"11:5382"
"13:110,Connection timed out"

Seemingly the connect ( "7" = HR_CanWrite / "5" = HR_Connect) is performed without a timeout being hit.

Now it does "11" = HR_WriteCount is shown, supposedly indicating my write request.
and "13" = HR_Error seems shows that a timeout error on that Write occurred.

Seemingly the target does not understand or like the write request issued by synapse.

Seemingly this is deterministic and happens all the time.

Is the number given with the "11" = HR_WriteCount log message indeed the count of bytes that are written in this request or is it an accumulated count ?

In fact I think I issue not more than 100 bytes per request.

Any additional suggestions ?

Thanks,
-Michael

------------------------------------------------------------------------ HTTPSend.Sock.OnStatus Log on Windows (on PC Linux it's similar):

621 OK

(1)
Logout OK
Boost OK
==== 0 -> Brenner ist bereits eingeschaltet
Send Mail OK
Login OK
MailCount: 0
Logout ...
OK
CheckMail OK
-- No Mail --
Login OK
MailCount: 0
Logout ...
OK
CheckMail OK
-- No Mail --
Login OK
MailCount: 0
Logout ...
OK
CheckMail OK
-- No Mail --
Login OK
MailCount: 0
Logout ...
OK
CheckMail OK
-- No Mail --
Login OK
MailCount: 0
Logout ...
OK
CheckMail OK
-- No Mail --
Stopped 29.01.2013 00:19:40

>>29.01.2013 00:19:40>>>3:

I:\Lazarus_Projekte\heizung>

------------------------------------------------------------------------ HTTPSend.Sock.OnStatus Log on ARM:

Login OK
MailCount: 1
Mail No. 1:
From: Michael Schnell
To:

Subject: test1
Date: 28-1-13 22:56:41
Body Lines: 9
Deleting Mail No. 1...
OK
Logout ...
OK
CheckMail OK
Sender = Michael Schnell : OK
<html>
<head>

     <meta http-equiv="content-type" content="text/html;
       charset=ISO-8859-15">
   </head>
   <body bgcolor="#FFFFFF" text="#000000">
     boost
   </body>

</html>
Command = 1

(0)
Login OK

(0)
621 OK

Boost Error
Boost Error
==== -9 -> Fehler bei Zugriff auf die Steuerung
Send Mail OK
Stopped 29-1-13 00:02:36

>>3:

[/share/Public/heizarm] #

waldo kitty wrote

i'm trying to make sure i'm following along here because i'm also using synapse for a project...

Do you know where to find the Synapse "Powers" ? I do hope (and feel) they are interested in helping to make this work and fix potential problems in the Synapse code.

This is why I upgraded to the most recent svn sources of Synapse (and found that it obviously is not yet tested on ARM: it does not compiled without a (simple) modification).

Here are my latest finding:

- I set the ConnectTimeout property and I set the other timeouts by calling "SetTimeout".
- As described my project does perform two complete HTTP communications with the target successfully.
- With the third access, the "connect" does work even without a timeout and a retry performed by my software (Synapse Status log: "7" = HR_CanWrite / "5" = HR_Connect).
- then it does "11" = HR_WriteCount is shown, supposedly indicating my write request. and "13" = HR_Error seems shows that a timeout error on that Write occurred.
- my latest log shows that the timeout occurs after more than 15 Minutes (see below).
- my software does a retry and the same happens again.

Now the "extended" Timeout is one problem, but the primary problem is why this write HTTP access does not work, while the previous two accesses do work fine.

How do we proceed ?

Thanks,
-Michael

------------------------------------------------------------------------

.
.

The dedicated support list for Synapse might be a better place for potential issues related to Synapse return codes on certain platforms - see the link "Support" on Synapse pages.

Tomas

Tomas Hajny wrote

The dedicated support list for Synapse might be a better place for potential issues related to Synapse

Did so,

Hoping to see both of you over there...
-Michael

no, sorry, i do not... i haven't seen them in the synapse list, either...

I do hope (and feel) they are interested in helping to make this work and fix potential problems in the Synapse code.

as do i and others ;)