Gateway 2.0 web server issues

[champson]

I've started to put together an alarm system using the Gateway 2.0 along with the default 1.2 version software.  It's a fantastic system and exactly what I've been looking for.
I have found a couple of issues, which I'll list below.

1. Web server stops responding.  After doing some fault-finding I found this seems to be related to a PIR sesnsor I have triggering the alarm.  This particular PIR has 4 wires going to it,  a 12v supply and then two NC alarm dry contacts.   At the Gateway end, I have connected one dry contact to the GND, and the other dry contact to the Zone 1 input.   Sometimes this correctly triggers the alarm, but most of the time it kills the web service.  I have configured this zone as an 'unbalanced input'.
Do I need to wire this some other way?

2.  The RTC seems to lose time (5 minutes over around 4 hours).  Maybe this is related to the issue above?

[vysocan]

Hello Charles,

thanks again for your appreciation.

It might be that you wired the PIR sensor wrongly, and making short on 12V rail. To check that, just disconnect the sensor completely and connect just a piece of wire from zone 1 input to GND(-). Then see the web interface.

If you are making short one or two of the resetable fuses will be hot/warm. Zone fuse is bottom right, main is top left orange disc. This basically drain power from whole system. Do not run the system shorted for long time the fuses will definitely degrade if shorted for long time.

Other hints, see STATUS LED, blinks periodically if system is running. Also, you can plug in micro USB cable to gateway and open terminal and play with the commands while you see problem with web interface.

Also I have updated version, I would suggest to upload latest one. Latest compiled firmware is present here: https://github.com/vysocan/OHS_2-gateway/releases

Guide how to upload it: https://openhomesecurity.blogspot.com/2020/08/dfu-device-firmware-upgrade.html It might be you need to power off gateway after all is updated, as I have fixed the reset sequence for DFU just recently.

PIR sensors should be connected as balanced, with 2 resistors that should be included, see: https://openhomesecurity.blogspot.com/p/blog-page_16.html

But go with first step first, to test if you are not making short.

Adam

[champson]

Hi Adam,
I checked all the wiring and it looks good.  The fuses were not getting warm either.
I did some more debugging, and found that the device only stops responding when I have an email alert configured.  I hadn't been getting email alerts, and suspected it was something to do with the SMTP authentication, but it seems now that it causes the Gateway an issue.
I will try updating to the newer firmware and see what happens.

[vysocan]

Hello,

OK, this seems like a software issue. Maybe problem when SMTP is not setup, then it makes the network to freeze. I'll check it too.

[vysocan]

I have tested resetting to defaults. That is, without proper login credentials to mail.smtp2go.com.
I get in debug console:
Mail (0) sent with results: 0x06, 0x0217, 0x00000000
But gateway works without issue.

Debug console can enabled over USB when you type "debug on".

[champson]

I'm able to reproduce it now by setting the following values:

server: mail.smtp2go.com
smtp port: 465
User name:  [e-mail]
Password:  test

The critical value here seems to be the port set to 465,  which was the SSL port my ISP used for SMTP.  It seems to cause an issue with the Gateway.  When I change this to 22587 with my ISP details (or indeed the default of 2525) the problem goes away.  
I can't imagine non-encrypted SMTP being around for too many more years, so we should probably look at supporting TLS on port 597.

[vysocan]

You are right, lwip smtp client does stuck the lwip (network) thread until remote server close the connection. I run lwip debug and got:
smtp_tcp_recv: connection closed by remote host
Mail (0) sent with results: 0x04, 0x0000, 0x00000000
smtp_dns_found: hostname resolved, connecting
smtp_connected: Waiting for 220

As I think about it, I feel it has wrong order?

Moving to TLS is definitely on my task list. But it is quite a complex task. First there is surprisingly no easy way to do it for embedded. In ChibiOS there is example how to build simple HTTPS static server by using WOLFSSL, and on the other hand lwip does support only MbedTLS. MbedTLS then what I see requires loads of memory.

I've managed with great effort to port the existing WolfSSL demo HTTPS to OHS, but the implementation of TLS is not great (both WolfSSL and MbedTLS), as it uses malloc/free a lot. Something you do not like to see on embedded platform.

[champson]

It's no big issue for me currently.  I just disabled the email alerting in the meantine.
Here is the output from the debug consle:

ch> info
Kernel:       6.1.1
Compiler:     GCC 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
Architecture: ARMv7E-M
Core Variant: Cortex-M4F
Port Info:    Advanced kernel mode
Platform:     STM32F437 High Performance with DSP and FPU
Board:        Open Home Security STM32F4x7-2.0.4
Build time:   Sep 28 2020 - 16:08:31
ch>
ch>
....
<********** I've deleted entries here as not sure if it is a security risk *********>
....
SMS end: -11
Mail (0) sent with results: 0x06, 0x0217, 0x00000000
Mail (0) sent with results: 0x06, 0x0217, 0x00000000
Mail (0) sent with results: 0x06, 0x0217, 0x00000000
ch>

[vysocan]

Hello Charlie,

the smtp client that OHS uses is part of lwip(netowrking) library. I've tried to dig deeper just to find that the 5 mins stuck issue is done in lwip core. It is simply when you enter secure port of mail.smtp2go.com and gateway does non secure connection, whole lwip thread gets stuck for 5 mins. I'll look more, but it is not critical issue I think.

But generally the mail.smtp2go.com works, just use the 2525 port and create your own credentials there to get user and password.

The error that you pasted in last reply is reply: Mail (0) sent with results: 0x06, 0x0217, 0x00000000
It is from server, 0x0217 = 535 (535 Incorrect authentication data).

I'll create a function to better describe it. Something like this:
Mail (0) sent with results: ERR_SVR_RESP, Server response: 535, 0x00000000

Adam

[vysocan]

Hello again,

added the promised extra debug info to debug result message, also packed in new commit.