AndrewFaulds":e3k14nqx said:
JimHk":e3k14nqx said:
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.
