I am using PeerFinder.FindAllPeersAsync() in my WP8 application to discover devices running the same application by the Bluetooth interface.
The function has to return the list of peers which are in range. However, it also returns the devices which have recently become peered with the application but are not in range anymore. Even by uninstalling and installing the application, those old devices are returned by FindAllPeersAsync() function.
Is there any way to prevent this thing to happen?
It seems that FindAllPeersAsync() method always returns the devices which were paired before. I solved this by removing paired devices in Bluetooth settings.
But as good solution, your app should do something like "online" request to determine if peer is really present in your range.
Related
I am currently having some issues with connecting to my peripheral. The bluetooth module in our peripheral does not seem to be advertising a name initially. I've have found that once I connect to the peripheral for the first time it will update the name and my scanner is then able to see the correct name.
I have no understanding why this is the case. I have also tried it using the Swift app we are developing, as well as a range of Bluetooth scanners on iOS and Android so I do not believe that this is an OS or programming error on the scanner side.
Is there a specific parameter that should be set on the peripheral. As I am just the app developer I do not have very much understanding about how the module is handing the process.
Any help would be much appreciated.
Just to confirm the scanner does not see a name for the peripheral until it has connected once. After this it will start displaying the name. Once the peripherals name is changed the old name is still being displayed until I have connected to it once again.
To display the name of device you need to see in advertisementData Dictionary which contains several keys depending on your device, in callback of didDiscoverPeripheral from CentralManager.
- (void)centralManager:(CBCentralManager *)central didDiscoverPeripheral:(CBPeripheral *)peripheral advertisementData:(NSDictionary<NSString *, id> *)advertisementData RSSI:(NSNumber *)RSSI
You can look for key CBAdvertisementDataLocalNameKey.
If you do not see the name, you can make changes in your firmware to include a name in GATT characteristic .
You can use LightBlue app to verify once. This is a good app on app-store to test your BLE device.
Chromecast v2 devices announce their presence using mDNS, and they are discoverable when performing mDNS queries for _googlecast._tcp.
DNS-SD / Bonjour also support the concept of "wide-area discovery", which makes use of standard unicast DNS queries to find devices. This can be useful for more complex networking scenarios - i.e your Chromecast devices may be in one VLAN but your sender devices are in another.
However, when trawling Chromium source I found this code in mdns_api.cc which seems to indicate that the Chrome extension will only search for _googlecast._tcp.local - completely preventing wide-area DNS discovery of other Chromecast devices. Based on anecdotal testing, it seems the Chromecast iOS app and SDK also have this behaviour.
Why does the official discovery mechanism for the Chromecast Chrome extension explicitly only discover link-local Chromecast devices?
They probably didn't do "wide-area discovery" because there are a lot of gotchas in implementing it and there isn't much gain to be had.
Let's suppose that they did implement it (from looking at the spec, it doesn't seem to be technically difficult; seems like it is mostly an edge-case problem).
You'd need:
A domain under your control. Could be a local-only domain.
Not many people do this.
Multiple VLANs that you want to use.
Most homes only have a single VLAN.
A DNS-SD server that supports Wide-Area Discovery.
This is probably the easiest thing to have. Even then, most people wouldn't do it.
A UX flow to input the various WAD servers that you want to ping for devices.
This is the hard part for Google since it needs to be consistent across all SDKs and using a WAD-discovered Chromecast would cause all local-media-server Apps to not work (e.g. Plex).
(1) - (3) are why Google wouldn't make this a priority. Chromecast is, after all, a consumer device and consumers tend to have simple networking situations. (4) is why it isn't low-hanging fruit.
You'd also need to solve a few problems:
What happens when you are connected to a Chromecast on a separate VLAN and then remove it's WAD server?
What if the WAD server goes offline?
What happens when you have multiple Chromecasts with the same name?
What if they also have the same IP address (possible since VLANs can have overlapping IP spaces)?
What happens when a Chromecast is discoverable using WAD but not reachable?
Should they attempt a connection to every single Chromecast you discover to test that it is reachable?
How would you scale this out to work with 100s of Chromecasts in VLANs that could be "far" away?
It is these problems that I think would prevent Google from implementing WAD even if they wanted to.
I am using a SPP Bluetooth module to send data between my Android phone app and the module. I stumbled upon an interesting thing today.
I pair to my module by entering a passkey
I can normally send data back and forth between my app and the module
From within my app I disconnect from the module and close my app.
On the module I change its passkey to a new value.
I reopen my app and can still exchange data. I do not need to go through pairing again. All security information exchanged by my phone and module when I first paired them (using the old passkey) seem to still be valid even after changing the PIN on the module.
I then close my app and unpair the device from Bluetooth settings.
After that I pair the two devices to make sure Passkey change was in fact accepted and surely enough it was. I can now only pair with the new PIN.
My surprise is that in point 5 above everything still worked even without updating the PIN also on my mobile phone. I plan on getting around this by calling removeBond() using reflection after I send the module a command to change PIN since this is enough for my particular use case. But if the PIN change could be triggered by something else then my phone this would not work.
My question is if this is normal. Bluetooth specs are quite long so I was hoping someone else knows this. I would imagine that after changing the passkey for a Bluetooth device all devices already paired with it will have to go through the pairing process again, this time with the new passkey. But steps above indicate this is not the case. Is this a bug on my Bluetooth module (Bluegiga WT12) or is this expected behaviour? Has Anyone encountered this before?
Thank you.
Cheers!
So, Bluetooth specs are more friendly than I thought. I found my answer in this paragraph:
The Bluetooth PIN is used to authenticate two Bluetooth devices (that have not
previously exchanged link keys) to each other and create a trusted relationship
between them. The PIN is used in the pairing procedure (see Section 11.2 on
page 241) to generate the initial link key that is used for further authentication.
So passkey is not like a password in a router. It is just a sequence which both devices need to know when connecting so that one authenticates the other. Once they are sure they can trust each other they exchange link keys and those are used for future communication. Passkeys/PINs are then irrelevant.
I hope I understand this right.
Terribly sorry for posting too soon.
Cheers!
I'm currently looking for a way to list the services exposed by a remote bluetooth device and to enable them.
Normally I would be using the WindowsAPI-functions (or more likely one of the known wrappers) to list the services and to enable them by GUID (SetServiceEnable).
The problem is, that the device is exposing two Services with the same GUID!
Thus using the windowsAPI-functions only enables one of these services. The other service can't be enabled.
I thought perhaps WMI could do the trick, but I'm still new to WMI and couldn't find any
Windows itself is able to enable both, none or a specific service over the servicemenu.
UPDATE
The problem I want to solve is to be able to enable either the first or the second service. By now only the first service (which is usually the service I need), but I couldn't find a solution to enable the second service (except by using the Windows UI).
If both services are enabled I have two Commports in devicemanager (SPP).
Since I can't add comment/questions (don't have the privilege on stackoverflow yet). Here's my best take.
If I understand correctly, it's invalid to have the service available more than once in the service record, right? Can you right click on the device in Bluetooth Pairing UI and see if you see two services and that you can enable them through the Windows UI? And once you enable them do you see two PNP devnodes under that device in device manager (view by connection) with the corresponding opposite role of the two service you enabled? (I can't try this because I don't know of a device I have with two identical UUIDs.)
As you might already know, when you enable service on a remote device, you are not actually enabling the service on the remote device through the Windows Bluetooth API. What you are doing is telling the core bluetooth component in Windows to generate the corresponding opposite role of the service. (This is what BluetoothSetLocalServiceInfo does.) For example, if the remote device supports A2DP sink, by enabling that service the Bluetooth service on desktop would then register a A2DP source service for that device, which generates a PNP devnode for matching A2DP source drivers to install on that devnode. By disabling that service, the Bluetooth service would then unregister the A2DP source devnode and the PNP devnode would be removed (sort of like unplugging a USB device).
Depending on what profile you are seeing being duplicated, it might not make sense to have two instances of device objects and driver objects that matches on the same mac address of the remote device.
My answer (which is actually not answering your question) is to check if it's even valid for the two services to be enabled in that case on the desktop with the drivers on the desktop that you will be working with. For example, a bundle of A2DP plus HFP would require A2DP and HFP to synchronize certain behavior, such as AVDTP suspend. Depending on the implementation and the drivers, they might not be expecting there are two instances of A2DP driver installed, hence causing the unexpected state of the local drivers.
I am Developing a Java ME Application. Here I am using WiFi Connection. Now My Question is how to get a particular WiFi Connections name using Java ME Code ?
My Requirement is for Nokia E5 Device only.
After doing much research work I found that this is not possible in Java ME Technology to fetch the WiFi Connection's Name.
However Similar Library would be com.nokia.multisim.networkid which returns Network ID and Network Short Name.
I Dont Think so it is 100% possible in J2ME and even though if it has worked and there is no guarantee that it will work on all J2ME devices which has Wifi connectivity.
most appropriate answer i have found , please go through it once.
" Much as I hate to put you through all that grief and then not have a simple answer, I don't have a simple answer.
The reason for that is because Java's networking model is based on TCP/IP, and the TCP/IP architecture is based on the idea that applications will neither know nor care about the hardware details of networking. A typical mobile device may contain several different network interfaces (WiFi, Bluetooth, Infrared, USB cable, and so forth), but when an app wants to contact another network node, the app doesn't know which of these interfaces is actually being used. And in fact, if the OS wants to do so, it can use more than one (in parallel) and/or switch interfaces in and out, based on routing criteria such as best measured data rates. Rather like how cell phones route phone calls.
So basic Java/JME won't know anything about WiFi.
However, there is an extension, specified as JSR 309 (http://jsp.org) that looks like it may help. It supports learning about and controlling the network interfaces themselves. The problem is that not all devices will implement this extension, so it will depend on what device(s) you are supporting. "