It`s possible to establish two connections( or more) between Pc and other device? When I try to do that I have got exception: 10048 -> ex.Message = "A connect request was made on an already connected socket xxxxxxxxxxxx:0000110100001000800000805f9b34fb". If not, there is some workaround? I used 32feet libary to wrote application.
i just connected 4 devices (spp) simultanously and transfering data periodically.
so it is definitely possible.
if one device is disconnected the other connection can't get data anymore, but i guess this is just a bug in my code.
it would be very interesting if anyone else has tried this.
I guess its not possible. There can exist one connection between a master and slave. A master can be simultaneously connected to as much as 7 active slaves.
And most probably the other device that you are using might support only one connection.
In your case it is possible to connect up to 7 device to your pc.
This an RFCOMM limitation, not a limitation of the lower levels of the Bluetooth stack. See a workaround described in the 32feet.NET documentation https://32feet.codeplex.com/wikipage?title=General%20Bluetooth%20Data%20Connections
Notes
[1] The one RFCOMM connection is a protocol limitation. TCP/IP has port numbers on source and destination ends and thus can support multiple connections, RFCOMM has only the remote channel number so only can support one connection.
If you need multiple connection and are in control of the 'server' device then have the service listen on two (or more) RFCOMM channels so the client can connect to different channel numbers.
Related
I'm trying to connect to a BTLE device from Linux from C++ with BlueZ.
Connecting to most devices works fine, but there is a special device which times out with 90% probability. From a standard Android smartphone the connection to this particular device works as intended.
For #Emil's advice in my other question (thanks!) I've setup a Link Layer sniffer tool for further investigation.
During the sniff period I tried connecting to the device(Destination) from both device(Good) and device(Bad).
Device(Good) is working perfectly - it connected
Device(Bad) is not working - timed out
Now I have a Link Layer data of both device connection trials and there is one significant difference between their trials:
Device(Good)'s LL Data for its CONNECT_REQ uses 500 for Timeout value (which is 625ms) while Device(Bad)'s LL Data in CONNECT_REQ uses 42 (which is 52.5ms).
I think Device(Destination)'s response is normally (mostly) arriving between those two, ie after 52.5ms and below 625ms, but sometimes it arrives in less than 52.5ms, and then also BlueZ can connect to it finally.
Is there any possibility to change this Timeout property for CONNECT_REQ in BlueZ? Maybe with setsockopt by any chance?
Or this is something hardcoded into kernel, even for bluetooth adapters attached to USB?
The usual way to access L2CAP is to create an L2CAP socket and simply call connect() on it to connect to the bluetooth device you want to access. This usually works completely fine. However, I'm trying to do this on an ARM device with Linux kernel 3.0 and there appears to be a nasty bug where you can't have multiple L2CAP connections without all of the data coming down which ever channel was created last. (ie if I connect to 2 bluetooth sensors with 2 l2cap sockets, all the notifications for both devices come through the socket open last and nothing comes on the socket open first.) However, if I set the filters right on the HCI socket I can see that the ACL data is coming through with the proper connection handles so I could get the data properly over there.
So... I'd like to change my code to utilize just the HCI socket.
My problem is, I'm not sure how (or even if it's possible). There's a "create logical link command" in HCI that seems like it would create an L2CAP connection, but the arguments make no sense to me. After I make an HCI connection over LE I get back a "connection complete event" that gives me a 2 octet "Connection_Handle". The "create logical link command" takes a 1 octet "Physical_Link_Handle" though.
The "create logic link command" is for AMP controllers and has nothing to do with L2CAP. With LE you automatically have a "connection" through the fixed channels and can simply send ATT commands as ACL packets on CID 4. The ACL packets make use of the connection handle returned fro the HCI LE connection event.
(answer courtesy someone on the #bluez IRC channel; I don't recall who)
In BLE, whenever you establish a connection, the L2CAP is ready to be used.
You don't need to connect or anything else. Once you receive the LE Connection Complete Event, you are ready to go and you may start communicating through L2CAP.
The other commands and data you mention are not LE, they are only for BR/EDR.
I want to clear of my basics before I Jump into more complicated matter of bluetooth. I have following basic question.
If there is two bluetooth devices(A phone and a bluetooth display). Is it that bluetooth connection is initiated only by the phone.
Suppose there would be lot of bluetooth communication happening from a phone to bluetooth display.Both devices can send messages to any other devices at any time. What is usual design approach of communication. Is it that the phone creates a Socket Connection to the bluetooth display through RFCOMM first time by sending a connect request to the Bluetooth device and this connection is maintained all the time or for every message the Socket connection is made and then socket is closed, after that again reopened and closed for next message.
If the connection is opened till the devices are in nearby range what are the consequences.
What is normal way of communication in case of phone and headset.
Can I get any reference so that i can get some knowledge about that.
1) In general, bluetooth connections can be initiated by either device. For example, with a phone and computer, you could start a connection from either side. With a phone and a display or headset, there may be no input interface on one device, so you would initiate connections from the phone. Devices can also auto-negotiate role switches such that they swap master/slave roles.
2) If you have continuous data to exchange, or require low latency, the connection would typically be left up. If you only have rare messages to exchange, tearing down the connection would save power because the devices are maintaining the connection synchronization by exchanging null packets.
3) You can't maintain a connection with devices out of range. If they can't communicate for some timeout period (on the order of seconds) then they lose sync and kill the connection.
4) Note that phone/headset are not using RFCOMM connections, rather the HSP (headset profile). Connections for isochronous voice data are inherently different than a sporadic data connection like RFCOMM.
5) A good way to see how "real" devices are communicating is to use tools like hcidump, as part of the linux blueZ stack. This lets you fully sniff the protocol messages that happen as you connect devices.
windows7, we can see different adapters in "Control Panel\Network and Internet\Network Connections", ex: 3g modem, mobile data connection, ethernet, vpn etc...I think some of these are ras connections. Say if there is a connection made on "abc modem"(ras modem) using some program given by vendor, then you can right click on adapter and disconnect.
Is there a api available for this disconnect process?
You can administratively shutdown the adapter with the SetIfEntry function. You pass a MIB_IFROW structure that you get filled with GetIfEntry before but with a changed dwAdminStatus member value.
You will need the IOCTL_NDIS_REBIND_ADAPTER ioctl call to enable the addapter again.
RasHangUp Function solved my problem. Though, i'm not so sure about consequences.
http://msdn.microsoft.com/en-us/library/aa377567(v=vs.85).aspx
I have a black-box device with a modem attached (which I can send commands to), and would like to be able to connect to send data to a server from it. What connectivity options do I have, is PPP the protocol I need to use or is there a better option?
ppp is certainly the most common solution for getting an IP connection over a modem. There are other solutions, but there's no reason not to use PPP if what you need is an IP connection.
If you don't need an IP connection and you're writing both the client and the server, you could also do a straight serial connection from one modem to another, but that's kind of old-school.
PPP is probably your best option, if you also want an IP gateway and routing. If you only need terminal access to the device, and it runs some form of *nix, you probably have getty+serial communication as an option. You can use any number of modem terminal clients on the other side.