## 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.

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).

## Just performed a wanton reboot of my Modem/Router.

The modem/router which I use for my LAN is a Bell Hub 3000, which I still hold to be a good modem. But lately, I discovered a slight glitch in the way it works. I have given it numerous specialized settings, such as, for example, a “Reserved IP Address” for my new Chromebook.

The problem I ran in to was, that the modem was executing all my settings without the slightest flaw, but was failing to commit changes to certain settings to non-volatile memory. Apparently, the way the modem is organized internally is, that it has volatile as well as non-volatile memory, which mimic the RAM and the Storage of other, modern devices.

In certain cases, even a full-blown PC could be running some version of an operating system, in which a user-initiated change is accepted and enacted, but only saved to non-volatile storage, when the user logs out successfully.

Well, earlier this evening I had a power failure, after which the modem restarted, but restarted with settings, that predated the most recent settings which I had given it. This was its only offence.

Now, I could go through the ritual of changing all my special settings again, after every power failure, but in reality, that would not do. And so, what I did was to soft-boot the modem, which, just like that poorly programmed desktop manager would, saved all my settings to non-volatile memory. After the reboot, those settings have stuck.

But what it also means is twofold:

1. This blog went down again, from 20h15 until 20h25, in other words, for an extra 10 minutes.
2. And, if there are any readers who examine the IP address log in the side-bar of my blog, they will notice an additional IP address change, simply due to the modem reboot. This will be, between 20h10 and 21h10. This one was not due to any malfunction, but was deliberately triggered by my action.

The process was short but painful, and had to be done.

Dirk

## Discovering avahi

One of the facts about modern computing which many people take for granted, is a LAN which can be browsed. Without such an ability, a Local Area Network only consists of IP addresses, and unless we have made special preparations otherwise, those IP addresses can also be reassigned by our router. Yet, this view of the LAN has prevailed under Linux for some time, where specific services need to be configured with text-files, and where users have made entries in the file ‘‘, such that specific host-names are associated with specific IP addresses, that are defined manually.

There exists a Linux solution to this problem, which can be installed with the package ‘‘. In short, this daemon provides in a Linux-friendly way, what the old ‘‘ used to provide under Windows. It associated packages, ‘‘, ‘‘, and ‘‘ , provide a GUI that allows the local computer to browse graphically. Additionally, the package ‘‘ allows for the host-names on the LAN to receive the suffix ‘‘, so that regular Linux programs can refer to those host-names and connect to their IP addresses transparently, without requiring manual configuration.


dirk@Phoenix:~$ping Mithral.local PING Mithral.local (192.168.2.10): 56 data bytes 64 bytes from 192.168.2.10: icmp_seq=0 ttl=128 time=0.183 ms 64 bytes from 192.168.2.10: icmp_seq=1 ttl=128 time=0.266 ms 64 bytes from 192.168.2.10: icmp_seq=2 ttl=128 time=0.275 ms 64 bytes from 192.168.2.10: icmp_seq=3 ttl=128 time=0.374 ms 64 bytes from 192.168.2.10: icmp_seq=4 ttl=128 time=0.281 ms 64 bytes from 192.168.2.10: icmp_seq=5 ttl=128 time=0.302 ms 64 bytes from 192.168.2.10: icmp_seq=6 ttl=128 time=0.465 ms 64 bytes from 192.168.2.10: icmp_seq=7 ttl=128 time=0.280 ms ^C--- Mithral.local ping statistics --- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.183/0.303/0.465/0.078 ms dirk@Phoenix:~$




Some people have noted problems getting this latter feature to work, but on my LAN, it just seems to work out-of-the-box.

It should be noted though, that if we install this to a computer which is not used to it, there can be some stability issues, and ‘‘ may not be compatible with arrangements some users have already made, to resolve their host-names. There was a specific problem I ran in to myself, after installing this on a laptop, according to which a list of available printers had become unstable, as viewed from one application.

## Two Hypothetical Ways, in which Push Notifications Could Work Over WiFi

The reality is that, being 52 years old and only having studied briefly in my distant past, my formal knowledge in Computing is actually lacking these days, and one subject which I know too little about, is how Push Notifications work. Back in my day, if a laptop was ‘asleep’ – i.e. In Standby – it was generally unable to be woken externally via WiFi, but did have hardware clocks that could wake it at scheduled times. Yet we know that mobile devices today, including Android and iOS devices, are able to receive push notifications from various servers, which do precisely that, and that this feature even works from behind a firewall. And so I can muse over how this might work.

I can think of two ways in which this can hypothetically work:

1. The application framework can centralize the receipt of push notifications for the client device, to one UDP port number. If that port number receives a packet, the WiFi chip-set wakes up the main CPU.
2. Each application that wants to receive them, can establish a client connection to a server in advance, which is to send them.

The problem with approach (1) is that, behind a firewall, by default, a device cannot be listening on a fixed port number, known to it. I.e., the same WAN IP Address could be associated with two devices, and a magic packet sent to one fixed port number, even if we know that IP Address, cannot be mapped to wake up the correct device. But this problem can be solved via UPnP, so that each device could open a listening port number for itself on the WAN, and know what its number is.

We do not always know that UPnP is available for every NAT implementation.

Approach (2) requires more from the device, in that a base-band CPU needs to keep a list, of which specific UDP ports on the client device will be allowed to wake up the main CPU, if that port receives a packet.

Presumably, this base-band CPU would also first verify, that the packet was received from the IP address, which the port in question is supposed to be connected to, on the other side, before waking the main CPU.

(Edit 12/19/2016 : Google can simply decide that after a certain Android API Number – i.e., Android version – the device needs to have specific features, that earlier Android APIs did not require.

Hence, starting from , or , Google could have decided that it was no longer a special app permission, for the user to acknowledge, to wake the device. Likewise, starting from some Android version, possessing a base-band CPU might have become mandatory for the hardware, so that the API can offer a certain type of push notification.)

Also, approach (1) would have as drawback, a lack of authentication. Any networked device could just send this magic packet to any other networked device, provided that both the IP address and the port number it is sensitive to are known.

Approach (2) would bring as an advantage, that only specific apps on the client device could be enabled to receive push notifications, and the O/S would be aware of which UDP ports those are sensitive on, so that the base-band CPU would only be waking up the main CPU, if push notifications were received and associated with an app authorized to wake the device.

Also, with approach (2), the mapping of WAN port numbers back to LAN port numbers would still take place passively, through port triggering, so that the WAN-based server does not need to know, what LAN-based port number the connected port is associated with on the client device.

But, approach (2) has as a real drawback, that a server would need to keep a socket open, for every client it might want to send a push notification to. This might sound unimportant but is really not, since many, many clients could be subscribed to one service, such as Facebook. Are we to assume then, that the Facebook server also keeps one connection open to every client device? And if that connection is ever dropped, should we assume that a sea of client devices reconnect continuously, as soon as their clocks periodically wake them?

Dirk