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

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

## My IP address was reassigned last evening.

I am hosting this blog on a personal Web-server, which connects to the Internet via a personal DSL. This may also be why downloading some of my content could have been slow for the readers.

I don’t own my IP-address. So my ISP can just cut that off, and reassign me a new one whenever they feel like it. When they do this, my LAN is still up – thankfully – but my link to the WAN – the Extranet – is gone for a  few minutes.

I have software which updates my IPv4 address automatically in this situation, so that this URL finds me again afterward. And I need to update my IPv6 address manually. But with any luck, these things can even take place without my being present, and most of my software just reconnects as it should.

And yet for the 5 minutes this can take, the readers might not have been able to retrieve my blog last night.

Dirk