iPad fails networking 101; how to earn it a passing grade

The iPad is not playing nice with the DHCP protocol: if the screen is turned off, it doesn't release its IP address when it's supposed to. This leads to address conflicts when the DHCP server gives the address to another system, but there are ways around the problem.

<a href='http://meincmagazine.com/apple/news/2010/04/ipad-fails-networking-101-how-to-earn-it-a-passing-grade.ars'>Read the whole story</a>

 

[operagost]

I know the problem is a bug in the iPad, but setting a DHCP lease to expire more often than once every few days is rarely necessary and asking for trouble.

 

[smellykaka]

Does anyone else not think that this is done to ensure a speedy wake from sleep? Press the button and surf! Having to poll the DHCP server for another IP will add the "un-snappy"

Under normal circumstances, a DHCP request and reply should take a fraction of a second.

 

[lilo777]

...it just works?

Yeah, lately turning into: "It just does not work".

 

[lilo777]

The iPad WiFi problems is a bit old. I remember reading a few articles about it right after the launch.

A little Google foo:

http://www.pcmag.com/article2/0,2817,2362319,00.asp

http://www.usatoday.com/communities/tec ... internet/1


Surprised it's just getting some coverage here at Ars.

The articles that you refer to describe a different WiFi problems that iPads have. Apple and networking are two very incompatible things.

 

[mmtroute]

41 iPads have been seen and 22 have exhibited the problem, eight to the degree of having been blocked from further access to the network.

I found this a bit confusing. I'm assuming that only 22 of the 41 seen on the network exhibited the problem due to different usage patterns but why were 8 blocked? I can't imagine it's due to deliberate manipulation of this flaw in the iPad on the part of the student, if that was the case they'd have to ban his entire account because he could do the same thing with a custom linux build on a laptop. Not only that but he could just spoof his MAC address and then the device would no longer be "banned."

So were the select 8 banned due to usage patterns, was it due to apps that were installed, was it due to those few being used in certain extremely congested parts of campus or what? Just curious if anybody knows.

Because it's Apple and Net Admins have all the power minus the logic...

"...appletalk is "chatty" so we don't allow it on our network. But feel free to use Netware IPX..."

 

[aix]

The iPad WiFi problems is a bit old. I remember reading a few articles about it right after the launch.

<snip A little unrelated Google foo>

Surprised it's just getting some coverage here at Ars.

Because it is a completely different problem.

And folks nobody has class anything address space any more. Classful address space has been gone for 10 years.

No, actually it is the same problem. The iPad's Wifi.

 

[RojBlake]

The iPad WiFi problems is a bit old. I remember reading a few articles about it right after the launch.

<snip A little unrelated Google foo>

Surprised it's just getting some coverage here at Ars.

Because it is a completely different problem.

And folks nobody has class anything address space any more. Classful address space has been gone for 10 years.

No, actually it is the same problem. The iPad's Wifi.

No, it isn't. The links you posted talk about low signal strength and connections being dropped, a problem that Apple says is caused by configuring the iPad's networking settings in a particular way and then trying to use it with certain dual-band, third party routers. This problem is not at all like the one described in this article.

 

[JimHk]

Have you actually verified that this problem exists as described?

I have attempted to confirm the DHCP leasing problem but have not been able to reproduce it (the iPad requests a new DHCP lease when awaking it from sleep after the lease has expired). I suspect that the problem may be more complex and related in some way to the Princeton network.

Assigning fixed IP addresses may be problematic.

I doubt that so simple a DHCP problem would have escaped Apple system test so I suspect something more complex is involved.

 

[AndreaFaulds]

Like virtually all Internet-capable devices, iPads obtain an IP address using the Dynamic Host Configuration Protocol (DHCP) when they connect to a WiFi network.

Virtually all? Really? Do we have any statistics on this? Because in my house the majority of devices have fixed IP addresses, even on WiFi.

I might believe that statement if it were qualified with "consumer-grade devices" instead of the blanket "virtually all."

Virtually all Internet-capable devices. In this case, internet-capable means interactive internet-capable devices (smartphones etc.)
Wireless security cameras, print servers, printers, media streamers and the like usually have a fixed IP address, but only as to make port forwarding easier, and make programmers do less work

 

[AndreaFaulds]

Have you actually verified that this problem exists as described?

I have attempted to confirm the DHCP leasing problem but have not been able to reproduce it (the iPad requests a new DHCP lease when awaking it from sleep after the lease has expired). I suspect that the problem may be more complex and related in some way to the Princeton network.

Assigning fixed IP addresses may be problematic.

I doubt that so simple a DHCP problem would have escaped Apple system test so I suspect something more complex is involved.

Read more carefully.
"the iPad requests a new DHCP lease when awaking it from sleep after the lease has expired". No.
The problem is it isn't requesting a new one DURING sleep.
This is an issue I can confirm exists from experience with my iPod touch, which has the same issues.

 

[stmiller]

Read more carefully.
"the iPad requests a new DHCP lease when awaking it from sleep after the lease has expired". No.
The problem is it isn't requesting a new one DURING sleep.
This is an issue I can confirm exists from experience with my iPod touch, which has the same issues.

Interesting. So how are you browsing the web with your iPod in sleep mode?

I can't reproduce Princeton's steps. Every time the iPad wakes, it simply requests a new lease. If previous ip is available - great. If not, it gets a new one.

 

[bjartur]

Can't someone just write a script to restart DHCP or tell it to ask for a new IP when the iPad comes out of sleep mode or if the Wake/Sleep button is pressed?

Yah and try and get that passed through Apple's approval system, the patch will be out before its approved. No really.

Sorry, it has to be written in C, C++ or Obj-C (rather than sh); and as such would be getting close to the complexity of the patch to this. You might have to use some "proprietary APIs" which would cause the "app" to be rejected when it'll finaly be judged (probably after an official patch has been released).

 

[JimHk]

Have you actually verified that this problem exists as described?

I have attempted to confirm the DHCP leasing problem but have not been able to reproduce it (the iPad requests a new DHCP lease when awaking it from sleep after the lease has expired). I suspect that the problem may be more complex and related in some way to the Princeton network.

Assigning fixed IP addresses may be problematic.

I doubt that so simple a DHCP problem would have escaped Apple system test so I suspect something more complex is involved.

Read more carefully.
"the iPad requests a new DHCP lease when awaking it from sleep after the lease has expired". No.
The problem is it isn't requesting a new one DURING sleep.
This is an issue I can confirm exists from experience with my iPod touch, which has the same issues.

The basic premise in the article, "But unlike the iPhone, if the iPad screen turns off—either automatically or because the user pushes the wake/sleep button—it keeps its WiFi connection alive. The lower-level IP stack also remains active, as the iPad responds to ping packets", is NOT true. Shortly after the iPad is put to sleep (~15 seconds) the WiFi and, of course, lower level protocol stacks are shut down. After that, the iPad does NOT respond to pings. See the ping trace below

iMac:~ alpha1$ ping 192.168.1.2 <------------------ Ping request to iPad and iPad put to sleep
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=140.078 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=55.928 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=79.592 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=103.892 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=25.471 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=50.806 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=75.449 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=97.389 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=18.493 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=45.393 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=66.918 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=64 time=90.629 ms
64 bytes from 192.168.1.2: icmp_seq=12 ttl=64 time=12.392 ms
64 bytes from 192.168.1.2: icmp_seq=13 ttl=64 time=36.519 ms
64 bytes from 192.168.1.2: icmp_seq=14 ttl=64 time=60.174 ms
64 bytes from 192.168.1.2: icmp_seq=15 ttl=64 time=87.312 ms
Request timeout for icmp_seq 16 <- iPad no longer responds to pings
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26

Hence, there is no need to request a new DHCP release during sleep. As I said previously, Princeton may have detected a a DHCP leasing problem of some sort but it is not so simple as has been suggested.