Test Connectivity to Apple Push Notification Services

You can do some pretty simple testing to Apple’s APNS of ports and network communications using strategies I’ve outlined in the past with tcpdump, trace route, telnet, curl, stroke and of course ping. These are classic ways to test connectivity to servers. However, netcat has a few interesting things you can do with it; namely actually run a port super-quickly to test traffic between subnets, forcing scans of ipv6 traffic, debugging sockets, keeping connections alive, parodying through SOCKS 4 and 5 and just checking for daemons that are listening rather than actually sending data to them.

In this first example, we’re going to just check that Apple’s web server is accessible (adding -v for verbose output):

/usr/bin/nc -v www.apple.com 80

The result would be pretty verbose

found 0 associations
found 1 connections:
1: flags=82
outif en0
src 10.10.20.176 port 50575
dst 23.78.138.214 port 80
rank info not available
TCP aux info available

Connection to www.apple.com port 80 [tcp/http] succeeded!
HTTP/1.0 408 Request Time-out
Server: AkamaiGHost
Mime-Version: 1.0
Date: Tue, 29 Jul 2014 15:41:34 GMT
Content-Type: text/html
Content-Length: 218
Expires: Tue, 29 Jul 2014 15:41:34 GMT

Request Timeout

The server timed out while waiting for the browser’s request.

Reference #2.48cf4d17.1406648494.0

If we added a -w to timeout we’ll cut out all the cruft (but wouldn’t know that the server’s at Akamai). Next, we’ll get a little more specific and fire up a test to check Apple’s push gateway at, using port 2195:

/usr/bin/nc -v -w 15 gateway.push.apple.com 2195

But, I want the cruft for the purposes of this article. Next, we can add a -4 to force connections over IPv4 and check the Apple feedback server and port 2196, also required for APNs functionality:

/usr/bin/nc -v -4 feedback.push.apple.com 2196

Right about now, something is probably happening at Apple where they’re getting sick of me sending all this data their direction, so let’s add a -z option, to just scan for daemons, without actually sending any data their way:

/usr/bin/nc -vz -4 feedback.push.apple.com 2196

Because of how NAT works, you might notice that the src port keeps changing (incrementing actually). Here’s the thing, we’re gonna’ go ahead and force our source port to stay the same as our destination port using the -p option:

/usr/bin/nc -vz -4 -p 2196 feedback.push.apple.com 2196

Now, what if this is failing? Well, let’s spin up a listener. I like to start on my own subnet, then move to another subnet on the same network and ultimately to another network so I’m checking zone-by-zone so-to-speak, for such a failure. So, we can spin up a listener with netcat in a few seconds using the -l option on another host:

/usr/bin/nc -l 2196

Then I can scan myself:

/usr/bin/nc 127.0.0.1 2196

I could also do this as a range if I forgot which port I used per host:

/usr/bin/nc 127.0.0.1 2195-2196

Now, as is often the case, if our connection problem is because data isn’t parodying, we can also use nc to check that using the -x operator followed by an IP and then : and a port. For example:

/usr/bin/nc -vz -4 -w 10 -p 2196 -x 10.0.0.2:8080 feedback.push.apple.com 2195-2196

Fun times with push notifications. Enjoy.