The Development Log


 
Updated snapshot again this morning
  • Fix Pi B / Zero / Zero W being stuck in "Performance" CPU mode. Now frequency scales on demand.
  • Disable DHCPv6 server on wifi interface when set to client mode. Stupid IPv6. This has been a problem in the snapshots for a long time and I never correlated the fact that my Android devices (tablets and phone) would suddenly stop seeing all my local devices by name (printers, power monitors) when certain HeaterMeters were on. It was infuriating and network traces were showing it wasn't even trying to look them up by name (IPv4). Turns out OpenWrt / LEDE doesn't disable the IPv6 server services when you set dhcp.ignore on the interface, you need to also explicitly set DHCPv6 and SLAAC servers off as well.
 
Bryan Mayland said:
Pushed out new snapshots for both Pi and Pi2/3 which finally enables HTTPS for the web server as well as some other minor fixes.
Custom firmware download
Raw images

Only thing I have left of my list is to include the RT5370 wifi driver. The rtl8192cu driver does not support AP mode any more so this new firmware will be a step backward for those who use Edimax adapters in AP mode. Client mode works just fine, as well as the Pi3 wifi in either mode. The RT5370 should also work in both modes but I haven't tested yet.
Click to expand...

FYI - I've been playing around with https://github.com/Neilpang/acme.sh on the HM, and it looks like we should be able to use it for generating valid HTTPS certs, issued via Let's Encrypt.

Since the certs are only valid for 90 days at a time, a process via cron / startup script would be needed to ensure that the cert remains updated and valid.

There also also some other caveats to this, such as requiring both port 80 and 443 be forwarded to the HM.

With so much push towards https these days, and the fact that the US government has given ISPs the ability to collect and sell data of its customers, it's probably worth the effort to make this a more permanent feature in LinkMeter. At least I think so anyways!
 
Last edited:
I can't get ACME to work. Everything goes fine but when it launches netcat to listen for the challenge, it doesn't pass a port number or anything so netcat returns immediately and then the challenge fails. My ncaddr is blank here, and the _NC command should be `nc -c -l -p 80` and it is just `nc -c -l `. This is with the latest acme.sh you've linked there. Any ideas?
Code: 
ok, let's start to verify
Verifying:home.capnbry.net
d='home.capnbry.net'
keyauthorization='qvMTH0Z0bcNxsjMl0RnMLmoyPcrsD2W0C4-9oMZaDDE.qLYOXPtWGfIQ8lJeyx3Jb9TfnOkq-hL3m4w7TS32cXc'
uri='https://acme-v01.api.letsencrypt.org/acme/challenge/AvfcSmdiYCPXhgURyBctvtsKxMLZWxRDpZMbAMSxKZc/967785988'
_currentRoot='no'
Standalone mode server
ncaddr
startserver: 8119
Le_HTTPPort='80'
Le_Listen_V4
Le_Listen_V6
_NC='nc -c -l '
serverproc='9736'
url='https://acme-v01.api.letsencrypt.org/acme/challenge/AvfcSmdiYCPXhgURyBctvtsKxMLZWxRDpZMbAMSxKZc/967785988'
payload='{"resource": "challenge", "keyAuthorization": "qvMTH0Z0bcNxsjMl0RnMLmoyPcrsD2W0C4-9oMZaDDE.qLYOXPtWGfIQ8lJeyx3Jb9TfnOkq-hL3m4w7TS32cXc"}'
POST
url='https://acme-v01.api.letsencrypt.org/acme/challenge/AvfcSmdiYCPXhgURyBctvtsKxMLZWxRDpZMbAMSxKZc/967785988'
_CURL='curl -L --silent --dump-header /etc/acme/http.header '
_ret='0'
code='202'
sleep 2 secs to verify
checking
GET
url='https://acme-v01.api.letsencrypt.org/acme/challenge/AvfcSmdiYCPXhgURyBctvtsKxMLZWxRDpZMbAMSxKZc/967785988'
timeout
_CURL='curl -L --silent --dump-header /etc/acme/http.header '
ret='0'
Pending
sleep 2 secs to verify
checking
GET
url='https://acme-v01.api.letsencrypt.org/acme/challenge/AvfcSmdiYCPXhgURyBctvtsKxMLZWxRDpZMbAMSxKZc/967785988'
timeout
_CURL='curl -L --silent --dump-header /etc/acme/http.header '
ret='0'
home.capnbry.net:Verify error:Could not connect to home.capnbry.net
Debug: get token url.
GET
url='http://home.capnbry.net/.well-known/acme-challenge/qvMTH0Z0bcNxsjMl0RnMLmoyPcrsD2W0C4-9oMZaDDE'
timeout='1'
_CURL='curl -L --silent --dump-header /etc/acme/http.header  --connect-timeout 1'
Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 7
ret='7'
Skip for removelevel:
pid='9736'
No need to restore nginx, skip.
_clearupdns
Dns not added, skip.
_on_issue_err
Please add '--debug' or '--log' to check more details.
See: https://github.com/Neilpang/acme.sh/wiki/How-to-debug-acme.sh
url='https://acme-v01.api.letsencrypt.org/acme/challenge/AvfcSmdiYCPXhgURyBctvtsKxMLZWxRDpZMbAMSxKZc/967785988'
payload='{"resource": "challenge", "keyAuthorization": "qvMTH0Z0bcNxsjMl0RnMLmoyPcrsD2W0C4-9oMZaDDE.qLYOXPtWGfIQ8lJeyx3Jb9TfnOkq-hL3m4w7TS32cXc"}'
POST
url='https://acme-v01.api.letsencrypt.org/acme/challenge/AvfcSmdiYCPXhgURyBctvtsKxMLZWxRDpZMbAMSxKZc/967785988'
_CURL='curl -L --silent --dump-header /etc/acme/http.header '
_ret='0'
code='400'
 
Here you go:

I'm not using standalone mode, I'm using the uhttpd webroot of /www, and the acme script will auto create and cleanup the .well-known/acme-challenge entries inside of /www/

Code: 
root@HM42:/opt/acme# ./acme.sh --debug --issue -d heatermeter.zerofox.ca -w /www/ --key-file /etc/uhttpd.key --fullchain-file /etc/uhttpd.crt --reloadcmd "/etc/init.d/uhttpd restart"
[Wed Apr  5 14:32:05 EDT 2017] Lets find script dir.
[Wed Apr  5 14:32:05 EDT 2017] _SCRIPT_='./acme.sh'
[Wed Apr  5 14:32:05 EDT 2017] _script='/opt/acme/acme.sh'
[Wed Apr  5 14:32:05 EDT 2017] _script_home='/opt/acme'
[Wed Apr  5 14:32:05 EDT 2017] Using default home:/root/.acme.sh
[Wed Apr  5 14:32:05 EDT 2017] Using config home:/root/.acme.sh
https://github.com/Neilpang/acme.sh
v2.6.8
[Wed Apr  5 14:32:05 EDT 2017] Using api:
[Wed Apr  5 14:32:05 EDT 2017] Using config home:/root/.acme.sh
[Wed Apr  5 14:32:05 EDT 2017] DOMAIN_PATH='/root/.acme.sh/heatermeter.zerofox.ca'
[Wed Apr  5 14:32:05 EDT 2017] _on_before_issue
[Wed Apr  5 14:32:05 EDT 2017] Le_LocalAddress
[Wed Apr  5 14:32:05 EDT 2017] Check for domain='heatermeter.zerofox.ca'
[Wed Apr  5 14:32:05 EDT 2017] _currentRoot='/www/'
[Wed Apr  5 14:32:05 EDT 2017] config file is empty, can not read CA_KEY_HASH
[Wed Apr  5 14:32:05 EDT 2017] Using config home:/root/.acme.sh
[Wed Apr  5 14:32:05 EDT 2017] Use default length 2048
[Wed Apr  5 14:32:05 EDT 2017] length='2048'
[Wed Apr  5 14:32:05 EDT 2017] Using config home:/root/.acme.sh
[Wed Apr  5 14:32:05 EDT 2017] Use length 2048
[Wed Apr  5 14:32:05 EDT 2017] Using RSA: 2048
[Wed Apr  5 14:32:09 EDT 2017] RSA key
[Wed Apr  5 14:32:16 EDT 2017] AGREEMENT
[Wed Apr  5 14:32:16 EDT 2017] Registering account
[Wed Apr  5 14:32:16 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/new-reg'
[Wed Apr  5 14:32:16 EDT 2017] payload='{"resource": "new-reg", "agreement": ""}'
[Wed Apr  5 14:32:16 EDT 2017] GET
[Wed Apr  5 14:32:16 EDT 2017] url='https://acme-v01.api.letsencrypt.org/directory'
[Wed Apr  5 14:32:16 EDT 2017] timeout
[Wed Apr  5 14:32:16 EDT 2017] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Wed Apr  5 14:32:17 EDT 2017] ret='0'
[Wed Apr  5 14:32:17 EDT 2017] POST
[Wed Apr  5 14:32:17 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/new-reg'
[Wed Apr  5 14:32:17 EDT 2017] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Wed Apr  5 14:32:18 EDT 2017] _ret='0'
[Wed Apr  5 14:32:18 EDT 2017] code='201'
[Wed Apr  5 14:32:18 EDT 2017] Registered
[Wed Apr  5 14:32:18 EDT 2017] _accUri='https://acme-v01.api.letsencrypt.org/acme/reg/11969113'
[Wed Apr  5 14:32:18 EDT 2017] _tos='https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf'
[Wed Apr  5 14:32:18 EDT 2017] AGREEMENT='https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf'
[Wed Apr  5 14:32:18 EDT 2017] Update tos: https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf
[Wed Apr  5 14:32:18 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/reg/11969113'
[Wed Apr  5 14:32:18 EDT 2017] payload='{"resource": "reg", "agreement": "https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf"}'
[Wed Apr  5 14:32:18 EDT 2017] POST
[Wed Apr  5 14:32:18 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/reg/11969113'
[Wed Apr  5 14:32:19 EDT 2017] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Wed Apr  5 14:32:20 EDT 2017] _ret='0'
[Wed Apr  5 14:32:20 EDT 2017] code='202'
[Wed Apr  5 14:32:20 EDT 2017] Update success.
[Wed Apr  5 14:32:20 EDT 2017] Calc CA_KEY_HASH='36eQrIZ8QNHUtvsqb3RRFzH9g3N+8FebRBb9k5yNCFw='
[Wed Apr  5 14:32:20 EDT 2017] ACCOUNT_THUMBPRINT='X-Mk5PB4riXnxOzK2ZUwjVVvdLXdJ8w2wPqFiU3j49k'
[Wed Apr  5 14:32:20 EDT 2017] Read key length:
[Wed Apr  5 14:32:20 EDT 2017] Creating domain key
[Wed Apr  5 14:32:20 EDT 2017] Use DEFAULT_DOMAIN_KEY_LENGTH=2048
[Wed Apr  5 14:32:20 EDT 2017] Using config home:/root/.acme.sh
[Wed Apr  5 14:32:20 EDT 2017] Use length 2048
[Wed Apr  5 14:32:20 EDT 2017] Using RSA: 2048
/BEGIN
[Wed Apr  5 14:32:20 EDT 2017] Use DEFAULT_DOMAIN_KEY_LENGTH=2048
[Wed Apr  5 14:32:20 EDT 2017] Using config home:/root/.acme.sh
[Wed Apr  5 14:32:20 EDT 2017] Use length 2048
[Wed Apr  5 14:32:20 EDT 2017] Using RSA: 2048
[Wed Apr  5 14:32:29 EDT 2017] _createcsr
[Wed Apr  5 14:32:29 EDT 2017] Single domain='heatermeter.zerofox.ca'
[Wed Apr  5 14:32:30 EDT 2017] Getting domain auth token for each domain
[Wed Apr  5 14:32:30 EDT 2017] Getting webroot for domain='heatermeter.zerofox.ca'
[Wed Apr  5 14:32:30 EDT 2017] _w='/www/'
[Wed Apr  5 14:32:30 EDT 2017] _currentRoot='/www/'
[Wed Apr  5 14:32:30 EDT 2017] Getting new-authz for domain='heatermeter.zerofox.ca'
[Wed Apr  5 14:32:30 EDT 2017] Try new-authz for the 0 time.
[Wed Apr  5 14:32:30 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/new-authz'
[Wed Apr  5 14:32:30 EDT 2017] payload='{"resource": "new-authz", "identifier": {"type": "dns", "value": "heatermeter.zerofox.ca"}}'
[Wed Apr  5 14:32:30 EDT 2017] POST
[Wed Apr  5 14:32:30 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/new-authz'
[Wed Apr  5 14:32:30 EDT 2017] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Wed Apr  5 14:32:31 EDT 2017] _ret='0'
[Wed Apr  5 14:32:31 EDT 2017] code='201'
[Wed Apr  5 14:32:31 EDT 2017] The new-authz request is ok.
[Wed Apr  5 14:32:32 EDT 2017] entry='"type":"http-01","status":"pending","uri":"https://acme-v01.api.letsencrypt.org/acme/challenge/","token":""'
[Wed Apr  5 14:32:32 EDT 2017] token=''
[Wed Apr  5 14:32:32 EDT 2017] uri='https://acme-v01.api.letsencrypt.org/acme/challenge//968200465'
[Wed Apr  5 14:32:32 EDT 2017] keyauthorization=''
[Wed Apr  5 14:32:32 EDT 2017] dvlist='heatermeter.zerofox.ca##https://acme-v01.api.letsencrypt.org/acme/challenge//#http-01#/www/'
[Wed Apr  5 14:32:32 EDT 2017] vlist='heatermeter.zerofox.ca##https://acme-v01.api.letsencrypt.org/acme/challenge//#http-01#/www/,'
[Wed Apr  5 14:32:32 EDT 2017] ok, let's start to verify
[Wed Apr  5 14:32:32 EDT 2017] Verifying:heatermeter.zerofox.ca
[Wed Apr  5 14:32:32 EDT 2017] d='heatermeter.zerofox.ca'
[Wed Apr  5 14:32:32 EDT 2017] keyauthorization=''
[Wed Apr  5 14:32:32 EDT 2017] uri='https://acme-v01.api.letsencrypt.org/acme/challenge//'
[Wed Apr  5 14:32:32 EDT 2017] _currentRoot='/www/'
[Wed Apr  5 14:32:32 EDT 2017] wellknown_path='/www//.well-known/acme-challenge'
[Wed Apr  5 14:32:32 EDT 2017] writing token: to /www//.well-known/acme-challenge/
[Wed Apr  5 14:32:32 EDT 2017] not changing owner/group of webroot
[Wed Apr  5 14:32:32 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/challenge/'
[Wed Apr  5 14:32:32 EDT 2017] payload='{"resource": "challenge", "keyAuthorization": ""}'
[Wed Apr  5 14:32:32 EDT 2017] POST
[Wed Apr  5 14:32:32 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/challenge/'
[Wed Apr  5 14:32:32 EDT 2017] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Wed Apr  5 14:32:33 EDT 2017] _ret='0'
[Wed Apr  5 14:32:33 EDT 2017] code='202'
[Wed Apr  5 14:32:33 EDT 2017] sleep 2 secs to verify
[Wed Apr  5 14:32:35 EDT 2017] checking
[Wed Apr  5 14:32:35 EDT 2017] GET
[Wed Apr  5 14:32:35 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/challenge/2LnQZYVYOJwrGNuy9qZapN7KBYqpiDnzUnxpxTjOCvA/968200465'
[Wed Apr  5 14:32:35 EDT 2017] timeout
[Wed Apr  5 14:32:36 EDT 2017] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Wed Apr  5 14:32:36 EDT 2017] ret='0'
[Wed Apr  5 14:32:36 EDT 2017] Success
[Wed Apr  5 14:32:36 EDT 2017] pid
[Wed Apr  5 14:32:36 EDT 2017] Debugging, skip removing: /www//.well-known/acme-challenge/w_YOGzCDkZBEuv2YTK8ZYowJYIN-PB8APaQ3qDtJuMA
[Wed Apr  5 14:32:36 EDT 2017] pid
[Wed Apr  5 14:32:36 EDT 2017] No need to restore nginx, skip.
[Wed Apr  5 14:32:36 EDT 2017] _clearupdns
[Wed Apr  5 14:32:36 EDT 2017] Dns not added, skip.
[Wed Apr  5 14:32:36 EDT 2017] Verify finished, start to sign.
[Wed Apr  5 14:32:36 EDT 2017] i='2'
[Wed Apr  5 14:32:36 EDT 2017] j='15'
[Wed Apr  5 14:32:36 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/new-cert'
[Wed Apr  5 14:32:36 EDT 2017] payload='{"resource": "new-cert", "csr": "..."}'
[Wed Apr  5 14:32:37 EDT 2017] POST
[Wed Apr  5 14:32:37 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/new-cert'
[Wed Apr  5 14:32:37 EDT 2017] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Wed Apr  5 14:32:38 EDT 2017] _ret='0'
[Wed Apr  5 14:32:38 EDT 2017] code='201'
[Wed Apr  5 14:32:38 EDT 2017] Le_LinkCert='https://acme-v01.api.letsencrypt.org/acme/cert/030f5cbcc9a4c4b9b63448713f8c958054a9'
[Wed Apr  5 14:32:38 EDT 2017] Cert success.
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
[Wed Apr  5 14:32:38 EDT 2017] Your cert is in  /root/.acme.sh/heatermeter.zerofox.ca/heatermeter.zerofox.ca.cer
[Wed Apr  5 14:32:38 EDT 2017] Your cert key is in  /root/.acme.sh/heatermeter.zerofox.ca/heatermeter.zerofox.ca.key
[Wed Apr  5 14:32:38 EDT 2017] Le_LinkIssuer='https://acme-v01.api.letsencrypt.org/acme/issuer-cert'
[Wed Apr  5 14:32:38 EDT 2017] _link_issuer_retry='0'
[Wed Apr  5 14:32:38 EDT 2017] GET
[Wed Apr  5 14:32:38 EDT 2017] url='https://acme-v01.api.letsencrypt.org/acme/issuer-cert'
[Wed Apr  5 14:32:38 EDT 2017] timeout
[Wed Apr  5 14:32:38 EDT 2017] _CURL='curl -L --silent --dump-header /root/.acme.sh/http.header '
[Wed Apr  5 14:32:39 EDT 2017] ret='0'
[Wed Apr  5 14:32:39 EDT 2017] The intermediate CA cert is in  /root/.acme.sh/heatermeter.zerofox.ca/ca.cer
[Wed Apr  5 14:32:39 EDT 2017] And the full chain certs is there:  /root/.acme.sh/heatermeter.zerofox.ca/fullchain.cer
[Wed Apr  5 14:32:39 EDT 2017] _on_issue_success
[Wed Apr  5 14:32:39 EDT 2017] Installing key to:/etc/uhttpd.key
[Wed Apr  5 14:32:39 EDT 2017] Installing full chain to:/etc/uhttpd.crt
[Wed Apr  5 14:32:39 EDT 2017] Run reload cmd: /etc/init.d/uhttpd restart
[Wed Apr  5 14:32:40 EDT 2017] Reload success
 
Last edited:
And the verification afterwards:

Code: 
root@HM42:/opt/acme# openssl s_client -showcerts -connect localhost:443 </dev/null | grep CN
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = heatermeter.zerofox.ca
verify return:1
 0 s:/CN=heatermeter.zerofox.ca
   i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
DONE
 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
subject=/CN=heatermeter.zerofox.ca
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
 
Last edited:
It seems that the busybox version of netcat needs a "NC_SERVER" option set to compile in the server functionality, which would allow -l (listen) to work. This will be required for it to run in standalone mode.

Probably need to add "BUSYBOX_CONFIG_NC_SERVER=y" to diffconfig.BCM2708
 
Last edited:
Steve_M said:
It seems that the busybox version of netcat needs a "NC_SERVER" option set to compile in the server functionality, which would allow -l (listen) to work. This will be required for it to run in standalone mode.

Probably need to add "BUSYBOX_CONFIG_NC_SERVER=y" to diffconfig.BCM2708
Click to expand...
Actually I have full-on netcat installed. There is a package for luci that has a nice config page for it and does all the dirty work of setting up cron to keep the certificate up to date, and it uses full GNU nc. Taking a longer look at the acme.sh, it does include the -p when it calls netcat and if I put a delay in acme.sh, I can connect to it and I get data back. However, the data is not in the right format to be an HTTP response. What that tells me is that the busybox printf doesn't work in the way that acme.sh expects. If I edit the LEDE wrapper script and change it from standalone to -w /www it worked perfectly the first time. Very strange that they set it to --standalone, require full GNU netcat, and modify the uhttpd configuration to stop it from listening on port 80. Seems like a lot of hoops to jump through for no reason.

I'm not entirely sure I see the benefit of having this integrated though. Sure it is better than a self-signed certificate but to get this to work you have to poke a hole in your firewall to direct port 80 to HeaterMeter and leave it open all the time so it can recreate the certificate when needed. I feel like this is a bigger security risk than running with a self-signed certificate. It does add another package to maintain which I am less than thrilled about. It does not do anything about ISPs collecting your data because we have SSL already which should be sufficient for those purposes. So the question is if it is worth it.
 
I think there's value to it, but there may not be enough value to have it fully baked into LinkMeter. Personally, I'd much rather have a valid cert than a self signed cert, simply because I hate being nagged by the browser about the security risks, even if they're somewhat of a false alert. Modern browsers are also making it increasingly more difficult to visit sites with invalid and expired certs, for good reason.

The ACME protocol has a tls-sni-01 method, which allows you to complete the process over port 443. I'm going to see if this is something that can be done without much effort.

In the meantime, maybe a page on the HM wiki will suffice for providing folks with the steps needed to make this work if they're interested.
 
Looks to work just fine using the tls method.

It requires stopping and starting uhttpd before and after, but that can be done with acme.sh

Code: 
root@HM42:/opt/acme# ./acme.sh --tls --issue -d heatermeter.zerofox.ca --key-file /etc/uhttpd.key --fullchain-file /etc/uhttpd.crt --test --pre-hook "/etc/init.d/uhttpd stop" --reloadcmd "/etc/init.d/uhttpd start"
[Thu Apr  6 09:01:48 EDT 2017] Using stage api:https://acme-staging.api.letsencrypt.org
[Thu Apr  6 09:01:48 EDT 2017] Run pre hook:'/etc/init.d/uhttpd stop'
[Thu Apr  6 09:01:48 EDT 2017] Standalone tls mode.
[Thu Apr  6 09:02:04 EDT 2017] Registering account
[Thu Apr  6 09:02:05 EDT 2017] Registered
[Thu Apr  6 09:02:07 EDT 2017] Update success.
[Thu Apr  6 09:02:07 EDT 2017] ACCOUNT_THUMBPRINT='cB2bnPz1FeF4cQibluICjy_ofGGVhgeMYKr5aNnprS0'
[Thu Apr  6 09:02:07 EDT 2017] Creating domain key
[Thu Apr  6 09:02:11 EDT 2017] Single domain='heatermeter.zerofox.ca'
[Thu Apr  6 09:02:12 EDT 2017] Getting domain auth token for each domain
[Thu Apr  6 09:02:12 EDT 2017] Getting webroot for domain='heatermeter.zerofox.ca'
[Thu Apr  6 09:02:12 EDT 2017] Getting new-authz for domain='heatermeter.zerofox.ca'
[Thu Apr  6 09:02:13 EDT 2017] The new-authz request is ok.
[Thu Apr  6 09:02:13 EDT 2017] Verifying:heatermeter.zerofox.ca
[Thu Apr  6 09:02:13 EDT 2017] Starting tls server.
[Thu Apr  6 09:02:29 EDT 2017] Multi domain='DNS:21a17d44bd04705b05e8163a8a3dbb21.825cb7c8f742be44948acdbb08d5937a.acme.invalid'
[Thu Apr  6 09:02:34 EDT 2017] Success
[Thu Apr  6 09:02:34 EDT 2017] Verify finished, start to sign.
[Thu Apr  6 09:02:36 EDT 2017] Cert success.
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
[Thu Apr  6 09:02:36 EDT 2017] Your cert is in  /root/.acme.sh/heatermeter.zerofox.ca/heatermeter.zerofox.ca.cer 
[Thu Apr  6 09:02:36 EDT 2017] Your cert key is in  /root/.acme.sh/heatermeter.zerofox.ca/heatermeter.zerofox.ca.key 
[Thu Apr  6 09:02:37 EDT 2017] The intermediate CA cert is in  /root/.acme.sh/heatermeter.zerofox.ca/ca.cer 
[Thu Apr  6 09:02:37 EDT 2017] And the full chain certs is there:  /root/.acme.sh/heatermeter.zerofox.ca/fullchain.cer 
[Thu Apr  6 09:02:37 EDT 2017] Installing key to:/etc/uhttpd.key
[Thu Apr  6 09:02:37 EDT 2017] Installing full chain to:/etc/uhttpd.crt
[Thu Apr  6 09:02:37 EDT 2017] Run reload cmd: /etc/init.d/uhttpd start
[Thu Apr  6 09:02:37 EDT 2017] Reload success
 
Last edited:
Bryan Mayland said:
I'm not entirely sure I see the benefit of having this integrated though. Sure it is better than a self-signed certificate but to get this to work you have to poke a hole in your firewall to direct port 80 to HeaterMeter and leave it open all the time so it can recreate the certificate when needed. I feel like this is a bigger security risk than running with a self-signed certificate. It does add another package to maintain which I am less than thrilled about. It does not do anything about ISPs collecting your data because we have SSL already which should be sufficient for those purposes. So the question is if it is worth it.
Click to expand...

I have to agree, being a security conscience IT guy, I'd rather not have ports left open on my network just for the connivence of not having my browser bug me about self signed certs. Plus some users might already be using port 80/443 for other things.

just my 2 cents
 
JohnW said:
I have to agree, being a security conscience IT guy, I'd rather not have ports left open on my network just for the connivence of not having my browser bug me about self signed certs. Plus some users might already be using port 80/443 for other things.

just my 2 cents
Click to expand...

If you'd have seen my last post, we don't need port 80 anymore. It can all be done over 443.
 
Steve_M: Does --tls work even if the uhttpd has a self-signed certificate? Just curious.

EDIT: Oops forgot to say New Snapshot
  • Loading scripts now sanitize and correctly maintain escaping through loading from config.txt to setting up wifi
  • Fix for corrupted network address display on LCD on startup. This one is a bit hokey and I'm still not 100% sure why it works.
 
Last edited:
Bryan Mayland said:
Steve_M: Does --tls work even if the uhttpd has a self-signed certificate? Just curious.
Click to expand...

Yes. It shuts down uhttpd and uses openssl to create an HTTPS server that serves up the hashed response data. Once the new cert is installed it starts uhttpd again.

It only needs to shutdown uhttpd to do this when generating a cert for the first time, or renewing the cert if it's going to expire in less than 30 days. If the cert is not close to expiring and you run the script, it doesn't stop and start uhttpd each time.
 
Ah crap looks like the Network Address display isn't working properly, it is still getting lost in the serial buffer. I'll probably have to do they 8-byte chunk / delay thing to make it work reliably. The serial layer is so generic in the kernel that it is hard to find where to look in the bcm27xx-specific code for where to figure out what is going wrong.
 
Pushed another new version, which breaks down serial writes into 8 byte blocks and waits for each to transmit. This should fix corrupted / missing "Network Address" messages on the LCD on the Pi 3 and Zero W

I can't find anything in the 8250 serial driver that would cause this overflow to happen. I went through the kernel commit log and nothing really jumped out at me between 4.4 and 4.9 but there have been quite a bit of changes so it might be difficult for me to recognize it just looking at the commit message. I also tried writing and doing a poll() on the write fd, but that never returned that the buffer was empty, it just timed out every time.

So if anyone wants to see if they can figure it out, go for it! The workaround should be ok, but I hate "just adding a delay makes it work!" fixes.
 
Bryan,

Any chance you can add checksum files along with the uploads to https://heatermeter.com/devel/snapshots/bcm2708/ ?

This would allow comparing the checksums when upgrading before clicking the proceed button.

28A9dPll.png


Thanks!
 
Last edited:
Yeah sure! How do you think the best way to do this is? like another file openwrt-rpi3.gz.md5.txt / sha256.txt? Do you know of any way to have that automatically appear as the description in the file list (Apache/2.4.18)
 
Minor update today. Fixes: HeaterMeter would not appear in device list if atmega isn't present or didn't flash properly (for example, if there's a hardware problem). Yesterday's update also upgrades the HeaterMeter Device Registration to use HTTPS, forgot to mention that.

I also fixed up the website this morning so things are properly centered and all the pages are themed the same. The devices page also fails more gracefully when using the Microsoft Edge browser. Edge won't let a webpage loaded from the "Internet Zone" create web requests to devices on your local network so we can't check the device IPs to find which are accessible. This actually makes sense from a security standpoint. You could hit a malicious Internet page that makes requests to your router using manufacturer default passwords and attempt to disable your firewall.

I also did a little design work on a new RESTful access API for instead of the username/password option for apps. I almost fully decided on using a shared key hashing system, the Amazon Web Services V4 signing system (AWS4-HMAC-SHA256) which would be easy enough to implement because there are iOS and Android libraries for it directly from Amazon and it isn't very complicated but very secure. I think I might fall back to just an apikey variable that has to be present in the POST though. It is just easier for everyone to implement and still has the same user requirement, entering a key. Anyone have any thoughts?
 
You must log in or register to reply here.

 

Back
Top