One main reason, for which Smart Home Appliances are cloud-based.

Like many other consumers, I have some ‘smart appliances’ in my home, and a harmless example which I will use, is my Dyson Air Purifier. It gives me features (beyond) what I would have requested, but a feature which I do appreciate, is the ability to access its settings etc., from an app on my smart-phone, regardless of whether I’m connected to my own Wi-Fi, the way the appliance is, or whether I’m outside somewhere. And this is a feature which most smart appliances offer.

Screenshot_20191223-122814_Dyson Link_c

But a question which I could easily picture a consumer asking would be, ‘Why is it necessary for this device to log in to a cloud server, just so that I can access it? Why can this arrangement not work autonomously?’

And I can visualize all sorts of answers, which some consumers could come up with, that might include, ‘Because Big Brother Is Watching Us.’ I tend to be sensitive to certain privacy issues, but also know that in this case, this would not be the main answer. Is Big Brother really so curious about what the air quality is in our homes?

A big reason why these devices need to be logged in to a cloud server, has to do with that last part of what they offer: To give us access to the appliance and its controls, even when we are not on our own LAN (Local Area Network).

Continue reading One main reason, for which Smart Home Appliances are cloud-based.

Surprising Revelation about the Apache Listening IPs

One of the details in my Apache configuration which I had placed emphasis on, was that this Web-server is supposed to listen on all IPv4 as well as all IPv6 interfaces, on the host-machine I name ‘Phoenix’. And so in the configuration file ‘/etc/apache2/ports.conf‘, I have set up so:


# If you just change the port or add more ports here, you will likely also
# have to change the VirtualHost statement in
# /etc/apache2/sites-enabled/000-default.conf

Listen 80

<IfModule ssl_module>
        Listen 443

<IfModule mod_gnutls.c>
        Listen 443

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet


And, in the file ‘sites-enabled/000-default.conf‘ I have stated:


<VirtualHost *:80>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.



But, when I run the command ‘netstat‘, what that command seems to reveal is:


dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 80
tcp6       0      0 :::80                   :::*                    LISTEN
dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 443
tcp6       0      0 :::443                  :::*                    LISTEN


What I expect to see, is instead:


dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 80
tcp        0      0    *               LISTEN
tcp6       0      0 :::80                   :::*                    LISTEN
dirk@Phoenix:~$ netstat -l --tcp --numeric | grep 443
tcp        0      0   *               LISTEN
tcp6       0      0 :::443                  :::*                    LISTEN


Yet, contrarily to what catastrophic expectations might suggest, I find that my site is accessible to IPv4 addresses to begin with. Not only that, but I routinely use the internal, IPv4 loopback-address, and the URL:


To access my own blog. The surprising fact about this setup, is that it still works, and I could come up with some creative ideas, about why this has been working all along.

  • The router could be forwarding all the IPv4 traffic from the WAN, to a LAN-specific IPv6 address belonging to my host-machine,
  • The way the kernel works could be such, that if any server is listening on ‘:::80‘, it is also automatically listening on ‘‘.

My actual router settings only show my host as having an IPv4, LAN address.

I don’t understand it, but as long as this has not been creating any malfunctions, I’m not going to dig deeper into the subject for now. If indeed, my server was no longer listening on any IPv4 WAN addresses, I would have obtained notifications to that effect by now.


(Edit : )

This has just been confirmed as the standard behavior of Apache (to use just one socket), as described in this external BB posting.


I am working to establish IPv6 access to my site.

This little project kept me up late last night, and also accounted for a brief interruption in my server availability between 21h00 and 22h00.

I have set up a Teredo gateway, which gives limited IPv6 availability by way of an IPv4 tunnel, and which presents the local computer with a virtual IPv6 NIC. The ultimate goal of this exercise was, that people in the WWW who have native IPv6 access, should be able to access my site using this IPv6 address.

Right now the global address in question is ‘2001:0:53aa:64c:302a:2849:b9e5:30c7′, but it may change at any time.

While it seems superficially that I may have succeeded at achieving this goal, I am unable to give it a thorough test, because the Teredo gateway also does not allow loop-back access. For me to try loop-back access, I need to use the IPv6 address of the loop-back interface provided by my kernel, which is ‘::1′. The problem with this is, that it does not provide a thorough test, or even an adequate test. Certain single Web-pages display fine.

But in order for my blog, for example, to display correctly, it is not only the main, home page of the blog which must get served up, but also the many individual URLs embedded within that main page-view. And then what seems to happen with my own PC, is that even if I specified the IPv6 address literally as a URL to fetch (which requires embedding it in square brackets), all the embedded URLs are still resolved to the IPv4 DNS addresses by my browser, resulting in an inconsistency, which I believe will prevent any complex page from displaying.

The only way this blog will display correctly using its IPv6 address, is from a client, on which every reference to my host URL has an IPv6 resolution.



Loss of Internet Connection, Downtime

I take the unusual approach, of hosting my blog on my own private Web-server at home. One nasty side-effect of this is, that if my domicile loses its Internet connection, which for most homes would only be a minor inconvenience, my Web-site and blog actually go offline. This also differs from what other bloggers might experience, who host their blogs on professional servers, where professional admins do their best to avoid downtime.

This morning, starting at about 4h30, my home Internet started to experience instabilities. One of the details which I do not really know yet, is what might have been causing this. But my Internet was effectively out, from 4h30 until 14h30, at which time I took the step of power-cycling my router, which means, to unplug the router from its AC wall outlet, to wait for 60 seconds, and to plug it in again. Then, already having lost my connectivity, I also thought it best just to reboot my host-machine ‘Phoenix’.

So it could be, that my blog was visible to the Internet again by 14h45 this afternoon.

I still do not really know whether my connection is fully stable again, but it seems that way, except for my IPv6 connectivity, which is managed through a Teredo gateway. That Teredo gateway is still experiencing intermittent issues. One aspect of this problem which worries me, is that between 4h00 and 8h00, I had 3 changes to my IP address, assigned by my ISP. I have a system in place, called ‘DynDNS’, which updates this IP address to allow readers to resolve my URL. But when there are several changes within a few short hours, this automated system will also fail to keep updating the IPv4 address. And, the fact that this was happening also seems to suggest, that there was not one failure of my Internet connection, but perhaps rather, some malfunction of the router itself.

I apologize for the problems, to anybody who might have been wanting to read my blog, on a rainy Saturday afternoon.