Showing posts with label Apple. Show all posts
Showing posts with label Apple. Show all posts

Monday, 4 February 2013

Which iPads Are On The Network?

Sometimes you can walk on to a customer site and the customer may have iPad devices using the WiFi network.

They may also have a range of different models, so that it is difficult to perhaps know the WiFi support capabilities available among their devices.

In summary, to-date all iPads support 802.11 a/b/g and 802.11n on both the 2.4GHz and 5GHz bands.

The 802.11n support is exclusively single stream, but the channel width that can be used has changed with recent models. Both the 4th Gen. iPad and iPad Mini support 40MHz channel widths on the 5GHz band.

It is quite difficult to determine which version of iPad you have just by a cursory glance at the device. A very good way of determining the device type you are working with is to check the model number on the back of the iPad. It's a little tricky to read due to the small size of the etched-in font, but with a bit of a squint, you can just about see it. Here is a picture taken from the rear of my own iPad 2:

By using the reference table below, you can verify very quickly which iPad models you are dealing with:

iPad Version
Model #
WiFi Support
40MHz on 5GHz?
iPad Original) 16, 32, 64 GB
iPad Wi-Fi/3G/GPS (Original) 16, 32, 64 GB

iPad 2 (Wi-Fi Only) 16, 32, 64 GB
iPad 2 (Wi-Fi/GSM/GPS AT&T) 16, 32, 64 GB
iPad 2 (Wi-Fi/CDMA/GPS Verizon 16, 32, 64 GB

iPad 3rd Gen (Wi-Fi Only) 16, 32, 64 GB
iPad 3rd Gen (Wi-Fi/4G LTE AT&T/GPS) 16, 32, 64 GB
iPad 3rd Gen (Wi-Fi/4G LTE Verizon/GPS) 16, 32, 64 GB

iPad 4th Gen (Wi-Fi Only) 16, 32, 64 GB
iPad 4th Gen (Wi-Fi/AT&T/GPS) 16, 32, 64 GB
iPad 4th Gen (Wi-Fi/Verizon & Sprint/GPS) 16, 32, 64 GB

iPad Mini (Wi-Fi Only) 16, 32, 64 GB
iPad Mini (Wi-Fi & Cellular) 16, 32, 64 GB
iPad Mini (Wi-Fi & Cellular (MM)) 16, 32, 64 GB


Tuesday, 8 January 2013

Apple TV Services

I've been taking a look at the Bonjour protocol in general recently due to some requirements I have been looking at for customers.

The availability of Bonjour gateways from the likes of Cisco and Aerohive certainly make things a lot easier to provide access to Bonour services without having to jump through lots of multicast-over-wireless hoops.

One area of particular focus has been Apple TV. It seems to be quite a popular device with execs who want to be able to mirror their iPad on to a meeting room projector.

There are some great tools that allow you to browse the services that are available on a network. I have been using Bonjour Browser for Windows, though other Mac equivalents are also available.

When looking at the services available from an Apple TV, I see the following services advertised:
  • _airplay._tcp.
  • _raop._tcp.
  • _sleep-proxy._udp.
  • _touch-able._tcp.
  • _appletv-v2._tcp

I was interested to know what each of these services does. So, here it what I've been able to turn up with a bit of Googling (it's also worth looking in this document to find out even more information about each service):


This service is Airplay which is used for streaming photo and video content.


This service is RAOP which is the 'remote audio output protocol' that is used for audio streaming.


This service is a difficult one to nail-down in terms of function. It is a service that responds on behalf of devices which have gone in to sleep mode  (for power-save purposes). I assume that it is acting on behalf of the other Apple TV services, as all of the services mentioned in this document remain visible, even when the Apple TV unit has gone to sleep. I set my Apple TV to go in to sleep mode after 15 minutes (after which time the lamp indicator goes out on the front of the Apple TV unit) - all services were still visible across the network.

For more info, see


This service is used to allow iPads/iPods etc. to be used as a remote controller for the Apple TV unit (see the Remote app on the iTunes Store)


This service pops up when you enable the home sharing option on Apple TV. 


Apple iTunes Services

This is just a quick note about some Apple services you may see advertised using mDNS when you are implementing a Bonjour gateway on your wireless network. I've been investigating which services might be visible when the iTunes application is being run on computers that are connected to the wireless network.

From my testing, I have only been able to find 2 services you may come across when using iTunes (this just considers the iTunes application and does not include any other services from Apple TV, printers etc.):
  • _daap._tcp.local.
  • _apple-mobdev._tcp.local.


This service becomes available when you choose the option to share your library on the local network Share library on local network:

The service advertisements are generated by the iTunes software on the computer (and hence originate from the computer itself) to be detected by other devices/computers across the network


This service becomes visible when the 'Sync over Wifi' option is selected for a device that is connected to the computer running via the sync cable. Once this option has been enabled, the device can sync with iTunes using the WiFi network rather than having to be tethered by the sync cable.

Interestingly, the _apple-mobdev._tcp.local. service advertisements come from the device itself (e.g. the iPad which has WiFi sync enabled), NOT the iTunes software on the computer.


In summary, you may see the following services from when iTunes is being used on your network:
  • _daap._tcp.local. (from the iTunes computer)
  • _apple-mobdev._tcp.local. (from the mobille device - e.g. iPad)
If you come across any other services that may be associated with iTunes, let me know - these were the only 2 I could find (see screenshot below).

Friday, 15 June 2012

Issue: Having to log back in on Apple devices on a Cisco wireless guest network

I'm documenting this for my own reference as much as anything, to avoid having to look this information up (yet again).

(This description assumes that the use-case is for a guest network, but will apply to any layer-3 authenticated wireless network)

It is a common occurrence on Cisco wireless networks (using a WLC of some type) to have complaints from guest users that they have to keep logging back in to the guest network after their device has gone in to sleep mode. They are often put in to sleep when they are enveloped in some type of holder or covering system that has a built-in magnet to make them sleep when they are not in use (this is very typical on iPad holders/covers).

The reason for the annoying issue of having to log back in to the guest network is that the WLC has a user idle timeout setting which expires (by default) after 5 minutes. So, when a device is put in to sleep mode, the WLC will not hear from it for a while and then after  5 minutes will terminate its session.

If you know a little about WLCs, you would expect this behaviour to be dictated by the 'session timeout' setting which is available on the WLC GUI via the Advanced tab of the WLAN definition. But, that timer is the time-out for the entire (continuous) session. If you wish guest sessions to automatically end after a pre-defined period of use (e.g. force guest users to re-authenticate every couple of hours of use), you would use that setting.

To configure the idle time-out setting, you can only configure this via the CLI (in version 7.0 code anyhow) using the command below. Remember, this is the setting that will determine how long a client is idle (e.g. in sleep mode)  before its session is terminated. The command to use is:

config network usertimeout  seconds

The 'seconds' value is obviously the amount of time a device can be idle before its session is terminated. By default, it is 5 minutes (300 seconds), and can be a minimum value of 90 seconds.

The value you choose depends on how long your users may put their device to sleep for. Obviously you need to wind it up above the default of 300 seconds if users are complaining. I'd suggest trying 15 minutes (900 secs) and maybe wind it up  if users still complain (...try 30 minutes(1800 secs) next?).

The only downside to winding this value up is that clients will sit in your client list on the WLC for longer. Normally, they would time-out within 5 minutes. But, if you wind this value up, they won't age-out as quickly.

Right...the next time I need this info, I know exactly where to find it.

(Note: I had a note via Twitter from @revolutionwifi advising that another consideration with this approach is the possible impact this may have on WLC memory, which is a fair point. I guess it depends very much on your environment. This setting is going to affect all clients that attach to the WLC, so if you have large numbers of users, you may need to keep an eye on your memory usage. I suspect this would only be an issue if you had an environment where you have many unique users who come and go during the day, who would effectively hang around in the WLC memory for longer periods than you would like.)