GadgetGuy
Super User
Joined: June 01 2008
Location: United States
Online Status: Offline
Posts: 942
|
| Posted: September 01 2013 at 11:28 | IP Logged
|
|
|
Over the last few months I have started a number of threads about finding an iPhone on your LAN to use for detecting Home/Away states to control home lighting, drapes, security, etc.
I succeeded in writing a Windows application that achieves that objective, a challenging task since the iPhone has many firewalls erected around it to prevent access from other than Apple Certified servers. It will normally not even respond to pings.
Since it has become confusing to update those various posts with links to software updates, I am creating this new post which will henceforth have the links, and will point the various prior posts back to this one.
Included in the software release are both a (Windows) executable as well as the native VB .Net 4.5 code, and a User Guide.
A ZIP folder containing these files can be found in the Forum download section here . . .
findMyPhone-v2.6.0.zip
Release History:
' [v2.3.3] Added 3rd attempt at finding reclusive phone by trying a socket connection
' [v2.2.4] New rtnStats format; 5 sec delay before writing report file to allow calling program to setup "Trigger on File Change" if used.
' [v2.2.5] Add arp phone entry delete to speed up the determination of state, otherwise delayed by 30-45 min arp cache auto refresh.
' [v2.2.6] Lengthened ping and wait times for better arp data
' [v2.2.7] Bug fix to recover from currupt findMyPhone.txt file
' [v2.2.8] Increase pings to 5; inc arp read delay to 30 sec
' [v2.3.3] As a last ditch effort, try a socket connection to see if phone is there.
' [v2.4.0] Added _newAlert flag to prevent overwhelming error message generation, and chgd -3 errRtn to a -4 for better handling.
' [v2.4.1] Fixed newAlert failure across separate executable runs with My.Settings
' [v2.4.2] Bug fix re lastKnows
' [v2.4.3] Reformat Returned info to elim extra line feeds.
' [v2.5.0] Bug fix on rtnStats, and elim name confusion by chg prior phone stat file read name into "lastKnownFile"
' [v2.5.1] Bug fix to correct missed phone from LAN.
' [v2.6.0] Added My.Settings.newAlert() for permanence across executions to prevent infinite error warning windows.
The findMyPhone application makes use of the Windows arp cache that attempts to keep track of device IP and MAC addresses of LAN connected devices. Unfortunately the arp cache is periodically cleared of idle devices after 30±15 minutes (random period) of device inactivity. Thus, if the phone has not been actively used recently there is a good chance it's arp entry will have been cleared.
An arp search is first tried in case the phone has been recently active. If no entry found, then the phone is pinged multiple times to wake it up and get it to respond to cache inquiries. While the phone does not respond to a ping directly, it will cause a sleeping phone to at least respond to system "whohas" inquiries on the LAN.
If these attempts do not find the phone, a 3rd try is made to see if the phone is present by trying to open a socket communications channel to the phone. Again the phone will not directly respond to a non "Apple approved" inquiry, however, at least it will not reject the socket effort, thus indicating it is present.
If these multiple efforts to find the phone fail, then it is declared to be absent from the LAN.
The executable (findMyPhone.exe) is called by Command Console, Script, or external application with capabilities to call other programs.
See User Guide for specific PH implementations. In general, this routine is called like this . . .
"findMyPhone.exe 192.168.1.92 C:/findMyPhone.txt"
"findMyPhone.exe 88-53-95-86-A0-1F C:/findMyPhone.txt"
Where:
1st argument is the IP/MAC address of the phone. (either address type may be used)
IP addresses should be given with periods or spaces between numbers . . . eg,
192.168.1.92 or 192 168 1 92 , or &nbs p; &nbs p; &nbs p; &nbs p;
MAC addresses with dash, colon, or spaces between numbers . . . eg,
88-53-96-86-A0-FF or 88:53:96:86:A0:FF or 88 53 96 86 A0 FF
2nd argument is the full path to a file where the Return Code information is placed.
Upon completion of the find attempt, the App will write a return code and stats to the file named in the 2nd argument of the App call (for the purposes of this document that file is “C:/findMyPhone.txt”).
The findMyPhone.txt file will look like this (which you can read to determine what is happening) . . .
[rtnCode]
1
[Reason]
The phone was found on the network.
[LastGood]
192.168.1.92
88-53-95-86-A0-1F
Where rtnCode shows:
• 1=Succesful find
***NOTE*** The first time a phone is found, the response may be a 1 with a Reason of . . .
"First detection of this phone with no accuracy check possible. Make sure it is correct!
• -1=No phone found in arp cache.
• -2=IP/MAC for dvc do not match arp cache
• -4=bad data in findMyPhone.txt file, or first time this phone is seen.
The Reason provides details of the attempt, and
The LastGood data indicates the IP/MAC address found that is known to be good.
Since the MAC address is hardware dependent and guaranteed to be unique it can be used to locate the phone on the LAN, but it is a slightly slower and more complex method to actually find the phone than the IP address approach.
If the network has DHCP enabled and the phone's address is dynamic, then the MAC address approach MUST be used as it is the only stable and unique method to identify the phone.
However, for highest performance, it is recommended that the network Router use a DHCP Reservation for the phone address allowing the IP address lookup method to be used for findMyPhone.
If the IP address method is used, findMyPhone will post a return usually within 10 seconds. NOTE: there is a first time run issue in finding a phone by its IP address, as there is no history yet to compare the MAC address in the arp cache with the device found at the given IP address. If the given IP address is incorrect, then the IP>MAC relationship will forever be inaccurate as the program will then be checking a wrong device (such as a printer, thinking it is the phone).
If the MAC method is used then this initial IP>MAC check is not a problem as the MAC is unique to a single device to search on, while an IP address can be dynamic and associated with different devices. With a MAC search it may take up to 40 seconds before a Return is posted to findMyPhone.txt.
Edited by GadgetGuy - September 01 2013 at 11:32
__________________
Ken B - Live every day like it's your last. Eventually, you'll get it right!
|
Active Topics 
Memberlist 
Search 
Help
Register 
Login
PowerHome Messageboard : PowerHome Programming
Topic: App to Detect iPhone on your LAN
