New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DevConfig "Link List" defekt #441

Closed
Hypnos3 opened this Issue Oct 9, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@Hypnos3
Contributor

Hypnos3 commented Oct 9, 2018

Describe the bug
DevConfig "Link List" defekt:
Auch nach 2 Minuten Ladezeit bleibt die Seite weiß und komplett leer.
siehe Homematic Forum

tested with: 3.37.8.20180929 - But problem exists inf RaspberryMatic also in early versions.

To Reproduce
Steps to reproduce the behavior:

  1. Go to 'Startseite > Einstellungen > Systemsteuerung'
  2. Click on 'DevConfig'
  3. Click on 'Link List' - [ccu IP]/tools/devconfig.cgi?cmd=list_links&sid=[sid]
  4. nothing happens

@jens-maus jens-maus added this to the next release milestone Oct 9, 2018

@jens-maus

This comment has been minimized.

Owner

jens-maus commented Oct 10, 2018

After some investigation of this issue, I found that the XMLRPC server implementation in HMIPServer as well as the used libXmlRpc library has to be partly blamed here. DevConfig is actually using the tclrpc interface to send a getLinks method call via the following tclsh command:

# echo "load tclrpc.so; puts [xmlrpc 'http://127.0.0.1:2010' getLinks]" | tclsh

If this is executed on a CCU/RaspberryMatic this call never actually returns and results in a stalled tclsh process. That's actually why the DevConfig "Link List" page will never be successfully loaded at all.

After some more deeper analysis it occurred to me that it is not the tclrpc.so library that has to be blamed here, but the XMLRPC Server in HMIPServer not answering in a nice way like the one in rfd or other standard XMLRPC Server implementations. That's why the used XML-RPC client library (libXmlRpc.so) which tclrpc.so (and other processes, like ReGaHss) is using is confused, ending up in a situation where libXmlRpc.so causes a stall.

The same situation can be triggered, for example, by simply sending out an XML-RPC request with some unknown method:

# echo "load tclrpc.so; puts [xmlrpc 'http://127.0.0.1:2010' unkown]" | tclsh

This call also causes the tclsh to stall forever. By using the following curl call, one can actually see what is happening inside the XMLRPC server in HMIPServer:

# curl -v --silent http://127.0.0.1:2010/ -H "Content-Type: text/xml" -d "<?xml version='1.0' encoding='UTF-8'?><methodCall><methodName>unkown</methodName><params></params></methodCall>"
> POST / HTTP/1.1
> Host: 127.0.0.1:2010
> User-Agent: curl/7.61.1
> Accept: */*
> Content-Type: text/xml
> Content-Length: 111
> 
< HTTP/1.1 200 OK
< Content-Length: 0
< 

As you can see, the XML-RPC server returns with an totally empty response with content-length 0 which IMHO violates the XML-RPC protocol and thus libXmlRpc.so being not prepared for such a lazy answer. The same query to the XML-RPC server to rfd returns the following valid response:

# curl -v --silent http://127.0.0.1:2001/ -H "Content-Type: text/xml" -d "<?xml version='1.0' encoding='UTF-8'?><methodCall><methodName>unkown</methodName><params></params></methodCall>"
> POST / HTTP/1.1
> Host: 127.0.0.1:2001
> User-Agent: curl/7.61.1
> Accept: */*
> Content-Type: text/xml
> Content-Length: 111
> 
< HTTP/1.1 200 OK
< Server: XMLRPC++ 0.7
< Content-Type: text/xml; charset=iso-8859-1
< Content-Length: 280
< 
<?xml version="1.0" encoding="iso-8859-1"?>
<methodResponse><fault>
	<value><struct><member><name>faultCode</name><value><i4>-1</i4></value></member><member><name>faultString</name><value>unkown: unknown method name</value></member></struct></value>
</fault></methodResponse>

Here the XML-RPC server in rfd always returns with a "" response including content-type and content-length larger 0.

Thus, to conclude: This is a bug/issue in the XML-RPC Server implementation in the HMIPServer component as well as in the libXmlRpc library (since it should never actually happen that it causes a stall!) in the CCU infrastructure. This issue has already been reported to eQ3 and a fix is already being worked on.

@Hypnos3

This comment has been minimized.

Contributor

Hypnos3 commented Oct 10, 2018

Thank you for the investigation!

eq-3-occu pushed a commit to eq-3/occu that referenced this issue Oct 21, 2018

Wolfgang Willinghöfer
- update to 3.41.1 ( 3.41.x Release Candidate 1)
- added minor workarounds to libXmlRpc to play nicer with the lazy XMLRPC server implementation in HMIPServer which doesn't send any methodResponses at all for unknown or unexpected xmlrpc requests. This refs jens-maus/RaspberryMatic#441

jens-maus added a commit to jens-maus/occu that referenced this issue Oct 21, 2018

- added minor workarounds to libXmlRpc to play nicer with the lazy XM…
…LRPC server implementation in HMIPServer which doesn't send any methodResponses at all for unknown or unexpected xmlrpc requests. This refs jens-maus/RaspberryMatic#441
@jens-maus

This comment has been minimized.

Owner

jens-maus commented Oct 22, 2018

Within the next version this issue should be resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment