I have been messing around with monitoring probe requests to track wi-fi enabled devices. I have a scanner in a set location that I know rarely has people near it 24-7. When I look at the resulting probe requests, it appears that some wifi enabled devices are around almost 24-7, which makes me think this is not really a person with a smartphone.
If there are APs in the area, is it possible I am picking up something from them? I am only collecting probe requests: type 0 (management) subtype 4 (probe request). As far as I can tell, only clients should send probe requests.
Usually the client (also called station node) keep sending probe requests to scan available APs in it's range. AP will respond with probe response and also it keep sending beacons. But an AP can also send probe requests, if it happens to scan for other APs. You can check the probe requests captured and see the RSSI field(signal strength). RSSI being low indicates the sender is a bit far from your monitor.
Related
Description - How I can get the number of BLE connection in iOS.
I want to restrict a user to add more BLE sensor after a particular number of BLE connection. I want to get the number of a BLE connection a device can handle.
A connection represents state, not traffic. The count of connections will be bound by either memory or the data structures used by the Bluetooth stack to manage them, both unknown. My answer is, "As many as it can and no more."
Packets represent traffic and each is handled one at a time. From this perspective, my answer is, "One."
However, if a packet cannot be processed out of the critical paths in the chip and protocol stack fast enough to begin processing the next packet, packets can be dropped. Experience has shown these critical paths in iOS are dependent on the traffic's packet size and rate. Additionally, other devices in the area not connected to your BLE stack may be flooding the radio spectrum and causing packet collisions outside the stack. I have seen BLE traffic go to hell with an excess of 20 connections and as few as one. From this perspective my answer is, "It depends."
If probe response packets announces the capabilities of a network,
then what is the purpose of Beacon frames in wireless 802.11 ?
Among other things, beacons allow a device to passively scan all channels for available Access Points so that a list may be presented to a user showing signal strength. They also allow a device to detect if there is another Access Point on the same network and presumably on a different channel with a better signal.
I've been reading about MQTT and I understand it uses TCP for network transport. So if I have a mobile app that will send subscribe request, I presume this will be an full-duplex connection so the client can be notified for incoming pushed data.
How then is this more battery and network efficient? I mean you still established an open TCP connection. Also how does it handle disconnection, does it auto-reconnect to the broker?
Taking into account my comment on the question, assuming you want to compare to HTTP Long polling these 2 links may help to answer your question:
https://www.ibm.com/developerworks/community/blogs/sowhatfordevs/entry/using_mqtt_protocol_advantages_over_http_in_mobile_application_development5?lang=en
http://stephendnicholas.com/archives/1217
TL;DR version:
The message sizes tend to be significantly smaller with MQTT vs HTTP (especially when you take into account all the http headers that get sent), this saves on network usage and in turn battery usage.
As for the reconnect side of things, the client libraries do not automatically reconnect but they do trigger a call back when the connection drops so you can handle reconnecting as required.
Is it possible to send only 1 iBeacon packet? I have tried using CBPeripheralManager,but since there are only 2 method to start and stop advertising, so I can't control how many packet is being broadcast.
What I want to try to do is use an iBeacon packet as a command, instead of just a broadcasting some ID. So I could send 1 iBeacon packet, and if the receiver got the message, it can send back Acknowledgement with another iBeacon packet. The intention is to avoid the pairing of bluetooth to send very simple data. The information will be linked to UUID, major, and minor of the packet.
Or are there better ways to do this than using iBeacon.
Yes, you can use iBeacon technology to send information back and forth between two iOS devices without pairing. If you have two devices, Device A and Device B, you set both of them up to range for beacons with a common ProximityUUID, say, E2C56DB5-DFFB-48D2-B060-D0F5A71096E0. And then you can exchange information in the two byte major and minor fields.
What you can't do is control the transmitter enough to send only a single iBeacon advertisement. The transmitter in iOS sends out 10 advertisement packets per second, so the best you could do is start the transmitter then stop it on a timer about 100ms later. (You probably shouldn't do this, because there is no guarantee that a single iBeacon advertising packet will be received successfully by the other device -- it may be lost due to a CRC error in the radio noise. You are probably better off letting the packet continue to transmit until you can confirm from a response from the other device that it was received.)
You can see an example of starting and stopping a transmitter on a timer in my answer here.
Of course, there may be easier and more robust ways of accomplishing what you want with built-in Bluetooth data exchange mechanisms. But that doesn't change the fact that what you propose is certainly possible.
No you can't since iBeacon is uni-direction device
I'm building a portion of an app that will require the user to download files of varying size. Currently, I'm using Apple's Reachability code to let me know if I have a connection.
(http://developer.apple.com/library/ios/#samplecode/Reachability/Introduction/Intro.html)
While the reachability code can keep track of 'having a connection', it doesn't have an ability to let me know of a worsening connection. It would seem that I need to expand on the functionality of the Apple code to meet my requirement. Is it possible for me to measure the number or percentage of dropped packets during the data transfer? This would be helpful so I could message the user and be able to pause or stop the download.
There is no iOS API available that hooks deep into the networking stack that tells you when and why packets are dropped. It could be dropped at a router or it could be dropped locally because of a checksum error.
What kind of data is it? I assume TCP.
You might be able to infer the quality of the connection by examining the throughput rate. You can count how many bytes you receive per second.
TCP has something called congestion control and the end hosts (iOS devices) will throttle back their throughput as packets are dropped and go unacknowledged. So throughput may correlate with network quality. However, your throughput rate may vary for many reasons such as network congestion, packet shaping, QoS, etc.
iOS does not have a public API to monitor the wifi signal strength. There is a private API but your app would not be approved in the app store if you use the private API.