Do HTTP requests from your Miniserver cause IP devices in your installation to crash?

[Rob_in]

Hi all,

As per the title I just raised a ticket with Loxone regarding their HTTP implementation... thought this info could be useful to others.

Executive summary: Miniserver HTTP requests made for virtual inputs do not include 'Connection: close' header which I believe causes some devices with limited connection tracking to crash.

For those that want details, full ticket text submitted below.

Cheers,

Robin

Loxone Ticket #338747:

 

I have a Legrand Ecocompteur power measurement device for which I have created a virtual HTTP input in my Miniserver. Ie. Miniserver reads the instantaneous power from this unit via fetch/parse of a JSON file over HTTP.
The Legrand Ecocompteur functions perfectly, but I have noticed that since creating this virtual input it will sometimes stop responding to HTTP requests. It appears that something in the Miniserver requests is causing it's IP stack to crash!
To test the Legrand Ecocompteur device I wrote some code to perform the same HTTP requests to this device from a Linux server. Interestingly, these requests are handled perfectly by the Legrand Ecocompteur.
So I took a network packet capture and looked into what might be causing the Miniserver requests to make the Legrand Ecocompteur malfunction by comparing it's communications with those from the Linux server. I discovered that the Miniserver HTTP requests for this virtual input do not include the 'Connection: close' header.
It seems this is non-compliant with the RFC which states, "HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message."
See https://tools.ietf.org/html/rfc2616#section-14.10
I imagine that this Legrand Ecocompteur will have a basic TCP implementation (as does the Miniserver) and will have limited connection tracking. I am guessing that after a certain period of time with many connections from the Miniserver without the 'Connection: close' header it may be trying to keep track of all these supposedly persistent connections and that causes a crash.
To be honest though, it doesn't really matter what the Legrand Ecocompteur is doing, the fact is that the Miniserver does not seem to be compliant with RFC 2616. It needs the 'Connection: close' header adding to each HTTP request that is made.
On this topic, I notice there is a 'User-Agent: [en]' header in the Miniserver HTTP request. This is clearly of little use think it would be better either remove this agent header or use something more useful that can identify the request as coming from a Loxone Miniserver.
I haven't checked requests that are emitted from the Miniserver as HTTP virtual outputs (and other HTTP traffic coming from the Minserver?), but if the same issue exists with them please correct there too.
I consider this a high priority bug as it can cause malfunction in other devices in my installation. Surely it is also a very easy fix and can be made quickly.

[James Mitchelmore]

Interesting.  Look forward to hearing their response...

[Rob_in]

Hi,

Yeah, me too. Their IP implementation leaves much to be desired. I had to raise another ticket regarding their non-RFC compliant ping requests a while back (this manifested itself as our Miniserver thinking it was constantly offline as our ISP threw away their bad ICMP packets!), although they did fix that so there is hope.

FWIW, the router the Miniserver & other device I talk about in the ticket (the Legrand Ecocompteur) are plugged into runs OpenWRT. So it already has an instance of Nginx running and I created a reverse proxy to shield the Legrand Ecocompteur from the Miniserver. The IP stack in OpenWRT is clearly much more robust than the one in the Legrand Ecocompteur so this seems a good temporary fix (couple lines of config and no extra hardware to fail). Hope that helps someone else if they stumble across this.

Robin

[AaronP]

Hi Rob,

Have you heard back on this at all? 

On Friday, 10 July 2020 09:44:18 UTC+1, Rob_in wrote:

[Rob_in]

On Friday, 17 July 2020 23:16:33 UTC+2, AaronP wrote:

Have you heard back on this at all? 

Sadly not.

Although I can confirm there have been zero outages from our Legrand Ecocompteur since configuring the Miniserver to make it's requests via an Nginx proxy, so think I can pretty safely say that the issue reported to Loxone is what was causing it problems and needs to be addressed.

Robin

[Arnaud]

Hi Robin,

I just installed Loxone everywhere (a wonder :)) as well as the ecocompteur legrand (so useful and interesting).

I am quite interested in having those data accessible in my miniserver, but the issue you pointed out kind of damper my optimism.

Any news on this topic ?

@+

[Rob_in]

On Friday, 22 January 2021 at 11:47:04 UTC+1 Arnaud wrote:

Any news on this topic ?

Indeed... basically if you put the Legrand Ecocompteur behind an Nginx micro-caching reverse proxy (can run on an OpenWRT box if you have one on your LAN) it will function flawlessly. Ie. the ecocompteur won't crash any more, at least not here in our LAN.

I wrote an ioBroker Adapter for this device just... well, because ;) ... and this has been running here for ages now without killing the ecocompteur. Even when polling every second. Anyhow, I mention the Nginx proxy in the readme of that adapter:

https://github.com/raintonr/ioBroker.legrand-ecocompteur#note-the-ecocompteurs-fragile-ip-stack 

Polling at 1s you could easily stuff the results into Loxone over UDP or a GUI Virtual Input but I actually left Loxone just doing it's own polling every 10s (via the Nginx proxy of course).

FWIW, there are marginal differences in the energy kWh values that are calculated by my ioBroker adapter sampling every second and Loxone sampling every 10 seconds but these are small so guess should be considered within the margin of error for the device. And I should also mention that either method is more accurate (at least matches more closely with EDF's billing meter read via TIC) than the energy figures the ecocompteur calculates itself. I have mentioned this to Legrand support but guess they don't care, probably as there is a new model of this device out (which looks inferior to me as it only has 4 circuit inputs plus one for 'total' for some reason).

Cheers,

Robin

[Bartel Eerdekens]

Technical Changelog Config 11.3 Beta 4 (2021.01.15):

• BG-I7976 Miniserver does not include ‚Connection: close‘ header in http requests (Virtual HTTP inputs,…) when no keep alive is used

https://www.loxone.com/enen/info/public-beta/

[Techdoctor]

Have been following this thread and started another on another forum (to do with the Pixel blaze LED controller) about a similar issue.

So what I have found is that on my RPi when running Firestorm  (centralised control console for Pixel Blaze), I can then use Loxone to control the PB. But when I run the Loxone App or via the Chromium web browser on the RPi to do anything, the PB crashes. Can't communicate with it at all, no ping nothing. And the PB needs to be restarted. So something strange going on there.

Someone else on  the PB forums has found out that when using Firefox to control the PB, the Network Stack of the PB3 seems to die.  May be related maybe not.

Now I know a lot of IOT and various other devices use some form of ESP chip thing, my washing machine has one and so does the PB. 

This could be a similar issue to  yours Rob_in. 

So do you access the data either via the app or a web broser and if so which one.

I also now have a question  is the Loxone App just a modified browser and if it is, which one is it.

[Rob_in]

On Tuesday, 30 March 2021 at 18:26:28 UTC+2 Techdoctor wrote:

So do you access the data either via the app or a web broser and if so which one.

I think you are barking up the wrong tree here. Miniserver communicates with a device. You use an app or browser (or API) to communicate with the Miniserver. That second means of communication (you <-> Miniserver) really should have no bearing on the first (device <-> Miniserver).

 

I also now have a question  is the Loxone App just a modified browser and if it is, which one is it.

You mean the Loxone Android app? Looks like a standalone app to me, but that's just based on how it looks and runs.

Robin 

[Jonathan Dixon]

On Wed, 31 Mar 2021 at 08:08, Rob_in <rain...@gmail.com> wrote:

On Tuesday, 30 March 2021 at 18:26:28 UTC+2 Techdoctor wrote:

So do you access the data either via the app or a web broser and if so which one.

I think you are barking up the wrong tree here. Miniserver communicates with a device. You use an app or browser (or API) to communicate with the Miniserver. That second means of communication (you <-> Miniserver) really should have no bearing on the first (device <-> Miniserver).

 

That was my thought too... while it's not impossible that opening the Loxone App causes some change in behaviour in the Loxone IP stack that in turn causes it to change the way it's connecting out to the RPi, this seems a stretch. I'd definitely start by trying to isolate Loxone out from the crash altogether. The fact other people see Firefox crashing it sounds a good lead to pull on first.

 

 

I also now have a question  is the Loxone App just a modified browser and if it is, which one is it.

You mean the Loxone Android app? Looks like a standalone app to me, but that's just based on how it looks and runs.

One way to tell for sure is to use the Hierarchy viewer / layout inspector, and drill down through the UI widgets to see if they're WebView, native controls, or from some other toolkit.

https://developer.android.com/studio/debug/layout-inspector

(I haven't had to do this for >5 years, so no idea if newer Android versions put extra blocks in place to debugging random 3p apps.)

Bonus: If it is a WebView, you maybe able to inspect & debug the html/JS inside it via chrome remote debugger https://developer.chrome.com/docs/devtools/remote-debugging/ (I know that does have some controls to stop connections to random apps so YMMV)

 

Robin 

--
You received this message because you are subscribed to the Google Groups "Loxone English" group.
To unsubscribe from this group and stop receiving emails from it, send an email to loxone-englis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/loxone-english/e2dfc97b-c3b1-4dd3-bd89-73478d9be1adn%40googlegroups.com.

[Techdoctor]

@Rob_in I actually mean the Linux app or Windows app rather than the Android version.

[Bartel Eerdekens]

The MacOS app is an Electron-based app (Electron can be used for Windows + Linux as well, so I assume it is the same), thus, being a Chrome instance.