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>

<IfModule mod_gnutls.c>
        Listen 443
</IfModule>

# 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.
        #ServerName www.example.com

        ServerAdmin admin@dirkmittler.homeip.net


 

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
dirk@Phoenix:~$


 

What I expect to see, is instead:

 


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


 

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:

 



http://127.0.1.1/blog/


 

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 ‘0.0.0.0:80‘.

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.

Dirk

(Edit : )

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

 

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

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

About Tor and Multi-Protocol Port Numbers.

On a past occasion I had tried to write on Facebook – of all places – that each computer, and therefore each IP Number, has seemingly arbitrary Port Numbers that it receives packets to, primarily to prevent most connection attempts from being futile. I.e., I was stating that there is an official, assigned port number, for most types of protocol that devices communicate with over the Internet. Yes, There Are Many More types of protocols, than just those for HTTP (80), HTTPS (443), POP, SMTP, IMAP, etc..

But this proclamation of mine just serves to remind, that no matter how hard we try to convey the truth, we only end up with approximations.

It’s possible for one server-program to listen on one port number, and to accept requests for a number of protocols – all on the same port number.

One example where this happens, is with proxy-servers. Typically, they might be listening for HTTP connections, let’s say on port 8118. But then the next question people might ask when setting up their browsers could be: ‘I like sending my regular HTML text through a proxy, let’s say to filter it, but I must also forward my HTTPS requests through a proxy – or not – And one might not want to send all the browser’s data through a single SOCKS5 port, just so that the proxy-server can do some differentiation. Therefore, where should I tell my browser to forward my HTTPS traffic?’

And in most cases, the answer would be through port 8118 again .  And that’s because a typical HTTP proxy, reacts to an HTTPS request, via a CONNECT instruction, which means that it treats the encrypted data as gibberish, and then either lets it through or not so. It’s not strictly necessary for a proxy server to analyze traffic, in order to be able to forward it. Yet, there can exist some HTTP proxies, whose feature just to accept a CONNECT command has been disabled. But you can in some cases just try them out.

Another example of this would be the “Tor” anonymizing network. Its standard port number has been 9050 for some time, but a Tor node simply listens on this one port number, regardless of whether that’s to accept connections from Tor nodes someplace else on the Internet, or whether that’s to accept an outbound connection from a local proxy-server – i.e. from another program on the same computer. With Tor specifically, If in doubt, you’d simply try to fire a connection at it and see what happens, via its only listening port. But for the most part, Tor likes a SOCKS5 connection going out.

Now there has been the issue, that certain firewalls will specifically block requests to connect to port 9050 on outside machines. And so some Tor nodes have been instructed to listen on some other port number, for incoming connections. But in order to get that to work, a kind of quiet agreement has been reached between Tor users, as to which port number they’re hijacking – that port number now being one officially assigned to an existing, other protocol.

So was I half-right, or half-wrong? I was trying to state basic knowledge, which might still be taken as a first-order approximation of the real world.

Dirk