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

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

## My router may have been flashed.

One of the ironies of my LAN is, I am hosting a Web-site from it, but I do not even own my present router. Mine is a router owned by my ISP, and which provides me with proprietary TV as well.

This means that my ISP has the right to perform a firmware update on the router, which can also be called ‘flashing the router’.

I suspect that this may have happened, around Wednesday Morning, November 9.

My main reason for suspecting this, was a subtle change in the way my router manages my LAN.

According to This Earlier Posting, I previously needed to set my router as the WINS server as well.

To explain in lay-terms what this means, I need to mention that the local IP addresses which computers have on a LAN do exist, in addition to which Windows has introduced its own way of giving the local computers names. Linux can mimic how this works, using its ‘Samba’ software suite, but also tries to avoid ‘NetBIOS’ (naming) as much as possible, outside of Samba network browsing, or ‘copying-and-pasting of files, between computers on a LAN’.

Just like domain-names need to be resolved into IP addresses on the Internet, which is the WAN to this LAN – the Wide-Area Network – on the Local Area Network, computer-names also need to be resolved into IP addresses, before the computers can actually ‘talk to each other graphically’. Traditionally, Windows offered its whimsical mechanism for doing so, which was named NetBIOS, by which any and every computer could act as the WINS server – thus offering its repository of LAN locations to the WINS clients, but alternatively, there could also exist one dedicated WINS server.

What I had grown used to, was that on my LAN, the router would insist that it be my WINS server, thus ‘not trusting’ any of my Linux boxes to do so in some way. I therefore had to defer to this service, as provided by the router.

I had previously set my ‘/etc/samba/smb.conf‘ to

   wins support = no

dns proxy = yes

Well as of Wednesday, the LAN had suddenly ‘looked different’ according to client-browsers. Each computer had suddenly remained aware only of its own identity, with no Workgroup of other computers to network with.

This was all happening, while my connection to the WAN still seemed secure and operative.

Long story short, I think that my ISP may have performed the Firmware Update, and that according to the new firmware version, the router was suddenly not willing to provide this service anymore. And so what I felt I had to do next, was change these settings back to

   wins support = no

dns proxy = no

Now that I have done so, each computer can ‘see’ my whole Workgroup again – which was apparently not feasible according to earlier experiences.

Further, for laypeople I might want to emphasize, that it is not just a frivolous exercise of mine, to give each computer a name. If they did not have names, then according to the screen-shot below, I would also not be able to tell them apart, since they all have the same icon anyway:

Now I suppose that an inquiring mind might ask, “Since Linux can imitate Windows, why does Dirk not just set ‘wins support = yes‘ as well?” My answer to this hypothetical question would be, that

• According to common sense, this option will just make the current machine available, as a potential WINS Server, but
• In my practical experience, the LAN will interpret this as more of an imperative gesture, of a kind that will actually cause a feud to break out between the machines.

In my experience, if I even set one of my Linux machines to do this, all the other Linux machines will refer to its repository of (4) LAN names, the others becoming clients, but the Windows 7 machine named ‘Mithral’ will refuse to have it. In this case, Mithral will insist that it must be the WINS Server, and not some Linux box. And then, further logic-testing of which machines can see which, will reveal that in practice, I must leave this option switched off, if there is also to be any Windows machine to share the LAN with.

Dirk