Re: [libmicrohttpd] Unable to connect to libmicrohttpd in embedded system.

[Evgeny Grin]

Hi Marcel,

Why do you think that you have some race condition? You are using single thread, unlikely it could produce any internal race condition.

With recent versions of MHD, I suggest to use MHD_USE_AUTO.

In your case it could be MHD_USE_AUTO | MHD_USE_INTERNAL_POLLING_THREAD | MHD_USE_DEBUG combination.

'daemon->connections_tail' should be NULL while MHD do not serve any connection (only listening).

I suggest you to try to debug 'MHD_accept_connection ()' - this function should accept new connection.

Alternatively, you could try to run any of provided examples to ensure that MHD function properly.

--

Best Wishes,
Evgeny Grin

22.01.2018 1:09, Marcel Rutten пишет:

Thanks, Silvio, it would be great if you could send me that working code. Probably saves a lot of time :-). My environment is an openembedded tree, as published by the manufacturer of the thermostat, back in 2012. Parts of it are really old, so sometimes I have to do quite some patching to backport newer code to that tree and toolchain. Nevertheless, your working code is probably fairly easy to build. libmicrohttpd wasn't so hard in terms of passing it through this toolchain. Getting it to work is a different story :-).

In the meantime, I ploughed through a lot of routines, working my way up from the routines that have daemon->default_handler (which is called from ozwcp) as argument.

I have tested the following options for the server:

MHD_USE_EPOLL | MHD_USE_INTERNAL_POLLING_THREAD | MHD_USE_DEBUG

This ends up in a race condition in MHD_epoll(), as called in MHD_polling_thread().

MHD_USE_POLL | MHD_USE_INTERNAL_POLLING_THREAD | MHD_USE_DEBUG

gives a race condition in MHD_poll()

and finally:

MHD_USE_INTERNAL_POLLING_THREAD | MHD_USE_DEBUG

This gives a race condition in MHD_select(). 
The race conditions at least explain why the client keeps trying, while nothing gets actually loaded. Only after killing the daemon, the connection is reset. 
I did some follow-up on the race condition in MHD_select(), and found that the connections in the daemon struct are not filled:
(excerpt from internal_run_from_select() ):
...
       (FD_ISSET (ds,
                  read_fd_set)) )
    (void) MHD_accept_connection (daemon);
 
  if (0 == (daemon->options & MHD_USE_THREAD_PER_CONNECTION))
    {
      /* do not have a thread per connection, process all connections now */
      prev = daemon->connections_tail;                                 <---- prev = 0x00
      while (NULL != (pos = prev))                                     <---- pos is also 0x00, so the loop never starts, resulting in a new call to MHD_select(), and so on and on ..                  
        {
	  prev = pos->prev;
          ds = pos->socket_fd;
...

Both current and previous connections are NULL pointers, which is not good :-(, but it already narrows the issue down to a much smaller part of the daemon. So the next question is: where are these connections filled, and how do I check if it's done properly? 

On 21 January 2018 at 22:28, silvioprog <address@hidden> wrote:

Hello Marcel, welcome to the list!

I used MHD on ARM in a small HTTP server testing for Android: https://lists.gnu.org/archive/html/libmicrohttpd/2017-02/msg00014.html . This link contains an attached picture showing the results. I think I have the sources in my old machine.

I don't know if my environment can be useful for you, but I built MHD for ARM via integrated Android Studio's CMake, and used MHD in Java project with JNI. I can search and send sources if they could be useful for you ...

On Sun, Jan 21, 2018 at 7:48 AM, Marcel Rutten <address@hidden> wrote:

Hi, I'm new to this list, and I have been trying to get libmicrohttpd to work on a linux-based smart thermostat.

To no avail, so far. I should say that I'm not an expert on web connections, but fairly fluent in C.

The thermostat has a Freescale imx 27 processor, (ARM-926 EJS) and has an openembedded image, developed around 2011, with linux kernel 2.6.26. The reason I want to get libmicrohttpd working on it, is because it features a zwave controller, which may be used to control TRVs (Thermostatic Radiator Valves), a feature which is not available in the standard firmware of the thermostat.  The zwave interface can be operated through openzwave, and its web interface ozwcp (open zwave control panel). ozwcp is linked against libmicrohttpd to provide the web interface.

I have tested the combination libopenzwave-1.4.164, libmicrohttpd-0.9.58 and ozwcp (latest version from github) on a CentOS7 machine, x86_64, with a USB zwave controller and it works flawlessly. External access to the webinterface is OK.

I built the same libraries and code for the thermostat, and everything works, apart from the web interface. When testing with wireshark, I can send a request, and get a 0-byte ACKnowledgement. For the rest, the server remains quiet. No 404 not found, forbidden, unable to connect, nothing.  There appears to be no timeout for external connections, in fact, my PC has been trying to connect for the last 30 minutes or so, without interruption.  The thermostat has no firewall (I switched it off), and nmap shows the default port (8090) to be open.

I have built libmicrohttpd with the following options :

"--prefix=/usr/local/ --disable-dependency-tracking --enable-examples --enable-messages --enable-https --enable-largefile --enable-curl --with-pic", copied from archlinux for ARM.

The main program was linked against this library, and the webserver is started normally, at least does not report any errors. The options were set as follows:
MHD_USE_THREAD_PER_CONNECTION | MHD_USE_INTERNAL_POLLING_THREAD | MHD_USE_DEBUG | MHD_USE_ERROR_LOG

I browsed through previous threads of this mailing list, and the only thing I came across regarding ARM-specific issues was the definition of a long vs. a long long integer. There are differences between a long on x86_64 (8 bytes) and ARM (4 bytes length). I'm not sure if this plays a role,  Other than that' there's nothing much to find.

My questions: Is this something new, or have other people encountered this problem, and if so, how was it solved.

If it's really a new issue, where do I start looking? The code is well documented, but it's a lot to plough through.

TIA,

marcelr

--

Silvio Clécio

signature.asc
Description: OpenPGP digital signature