I want to develop an app that does basic packet sniffing. So, I would like to know if packet sniffing is feasible from a BlackBerry.
I don't think this is possible. The most you can do is keep track of the number of packets sent and received over the radio, but not see the actual contents. See RadioInfo.getNumberOfPacketsReceived() and RadioInfo.getNumberOfPacketsSent().
This is tagged "blackberry simulator" are you looking for an app in to observe what the simulator is doing or for an app in real world mode?
Intercepting things going in and out of the sim is not to hard, especially if you acted as some kind of intermediary pipe between the bbsim and the mds-cs sim.
Packet sniffing on device though i do not believe is possible at all, except over wifi from a promiscuous node laptop sniffing next to it.
Related
I know I can send 802.11 custom packets with wifi_send_pkt_freedom, and I'am using it without any problem.
But what about receiving?. Yes, I can enable promiscuos mode, and filter by MAC address. Doing that is perfect for sniffing, but not for communication, because the ESP8266 won't ACK the packets and if I'am not sniffing and my ESP is the only receiver, it will make the transmitter to repeat many times the packet. Yes, I can send it like broadcast or multicast to avoid waiting for the ACK, but I'll missing the ACK/re-send functionality. In short I would like to put the ESP Wifi interface in monitor mode (which is not promiscuos mode)
And yes, I can use ESPNOW, but for my application it wont suit very well my needs.
Thanks!
Román
developers!
I would like to know whether is it possible for AltBeacon Transmitter Android App to detect if a Scanner Android App is listening to the Transmitter? If it is possible, how do I start?
I have attached an image for a clearer picture of my question. Overview
A beacon transmitter is a transmit-only device that emits packets with no knowledge of whether any receiver is listening. It is not possible to know directly if a receiver is present.
This is equivalent to an over-the-air television broadcast. The transmitter sends the signal with no knowledge of there is anybody with a television turned on and tuned to the proper frequency.
in both cases in order to find out if anybody is listening you must build another feedback mechanism. With Bluetooth beacons, it is typical to build a mobile app to call a server to tell it the advertisement has been received.
Apologizing in advance, I am no 802.11 expert and this is a long winded question...
I am working on an iOS voip client, we use the Cocoaasyncsocket library for our TCP/UDP connections. The app/iDevice is allowed to roam in/out of wifi coverage (for the purposes of this discussion we will assume the app is using wifi only... no cellular connection). We have the appropriate plist settings for backgroundmode (voip, audio) as well as requiring persistent wifi.
We are having a problem that seems particular to Cisco AP's. With the client app in the foreground and roaming out and in of wifi range, we noticed that eventually the iOS device will eventually not automatically rejoin the network. After a great deal of debug the failure to rejoin was noted to have nothing to do with the app. The failure to re-join can ultimately be reproduced by forcing the AP (via config) to deauthenticate the iDevice three times. After the 1st and 2nd deauthentications, the iDevice readily automatically re-joins. But after the 3rd time, iOS does not automatically rejoin the network.
The network will be rejoined if, for example, the iOS email app is put in the foreground.
We were curious if any other VOIP type apps suffered this problem, and ran an experiment with running FaceTime and Skype on the iOS device.
Skype behaved much like our voip app, after the 3rd deauth the connection was lost. Trying to initiate another call resulted in a message to the effect of "must have an internet connection to make a call".
FaceTime did disconnect on the 3rd deauth and failed to automatically rejoin... however, we were able to re-initiate another FaceTime call which caused iOS to rejoin the network and make the call.
We would like to emulate the FaceTime behavior, but so far do not understand what we should be doing differently. To the best of our knowledge, we are properly closing the open sockets when we get disconnected. Is anyone familiar with this issue and have some insight to offer?
I have a multiplayer iOS game, and I am sending data using GKMatchSendDataReliable. However, occasionally, the data packet is lost. I've checked on the sending end and I am not getting an error. I'm just not receiving it on the receiving in. It is intermittent, and I have NSLogs right at the beginning of my receive method, so I always know when I get a message.
Is GKMatchSendDataReliable 100% reliable? It seems like a waste to have to set up my own reliable data sending routines.
It seems that this only happens when one device is on Verizon's LTE network. I havn't tried any other cellular network. When using Wi-Fi only, not necessarily the same wi-fi, it works fine.
This happens to me too. It appears that while GKMatchSendDataReliable is oodles more reliable than GKMatchSendDataUnreliable (which loses about 2% of packets in my tests), GKMatchSendDataReliable seems to occassionally lose the first packet I send (immediately after connecting).
My users also complain that some data may be accidentally lost during the game. I wrote a test app and figured out that GKMatchSendDataReliable is not really reliable. On weak internet connection (e.g. EDGE) some packets are regularly lost without any error from the Game Center API.
So the only option is to add an extra transport layer for truly reliable delivery.
I wrote a simple lib for this purpose: RoUTP. It saves all sent messages until acknowledgement for each received, resends lost and buffers received messages in case of broken sequence.
In my tests combination "RoUTP + GKMatchSendDataUnreliable" works even beter than "RoUTP + GKMatchSendDataReliable" (and of course better than pure GKMatchSendDataReliable which is not really reliable).
Apple stated that this was a bug and fixed in iOS7
I am developing an app to get information on network devices.
I have seen two different ipads get into a state where they are not sending out bonjour/mDNS traffic.
I used wireshark and did not see any broadcast traffic from the ipads at all.
I have a bonjour broadcast that other devices were responding to but the two iPads in question did not respond.
After I shut down the ipad and restarted it I was seeing normal bonjour traffic and they responded to my bonjour query just fine.
The iPads had been running for a long time without being shut down.
So, the question is: do iPads get into a funky state after they have been running for a long time where the mDNS service stops working?
Are there other causes for this to happen?
Is there any way to kick it other than shutting down to get it to respond again?
A suggeston, mostly maybe the problem of your progame. Once I met this case. My soultion is like this:
restart(re alloc) bonjour browse once the program exchanged "backgournd from foreground", of course,stop bonjour browse from "foreground" to "background" firstly. Thus sloved.