Hello,
since this is the only contact available at bluez.com I'm sending these
questions to this list. If this is not the contact to be used please
direct me to the one which is.
I'm trying to make a sort of content server using bluetooth. As such I
coded a non blocking rfcomm server which accepts remote connections and
according to the received connections sends data back. The machine doing
this uses two bluetooth adapters and one is binded to the accepting
socket, however the same machine, in this case the same application is
supposed to scan visible remote bluetooth adapters for rssi values and so
my first question arises.
Is it possible to accept connections at the same time a inquiry is running
or is the inquiry a blocking operation at the stack level? With two
adapters my server accepts remote connections and receives and sends data
but when an inquiry is running it stops accepting connections. The inquiry
is done in a separate thread.
Another question is related to a rfcomm client getting into D state and
thus not killable. Due to my setup (two adapters in the same computer) I
can use the computer as both the server and the client. For test purposes
only I made a simple rfcomm client and I put it in a shell cycle thus
stressing the system regarding bluetooth connections. In this situation
the rfcomm client application becomes unresponsive after some time due to
a non exiting disk sleep. I then end up with multiple instances of the
same application and I can't kill them. By launching the application after
this I can see that the code blocks at a socket connection command
entering in a disk sleep state from which it doesn't exit. When this
happens I have to unplug the bluetooth adapter to get it working again
since it starts to give timeouts with hciconfig commands like "hciconfig
reset".
Any ideas about this? The problem itself is not serious since it shouldn't
arise in normal conditions but it does require a reboot because of the
state D processes and makes the adapter unusable unless it is unplugged.
Best regards,
--
S?rgio Pedro dos Santos Capela - Tziranda
Polo Tecnol?gico de Lisboa
Edif?cio Empresarial 3
1600-546 Lisboa
Telf: 21 314 09 83
Telml: 96 491 94 37
Email: [email protected]
SGkgU8OpcmdpbywNCg0KT24gU3VuLCAyMDExLTA3LTI0IGF0IDE4OjA4IC0wNDAwLCBTw6lyZ2lv
IENhcGVsYSB3cm90ZToNCj4gSGkgUGV0ZXIsDQo+IA0KLi4uLg0KPiA+IElmIHlvdSBoYXZlIHRv
IGhhdmUgc2VydmVyLXNpZGUgZGlzY292ZXJ5LCB5b3UgY291bGQgb25seSBwZXJmb3JtDQo+ID4g
aW5xdWlyeSB3aXRoIG9uZSBjb250cm9sbGVyIGF0IGEgdGltZS4gVGhhdCB3YXksIHRoZSBvdGhl
ciBjb250cm9sbGVyJ3MNCj4gPiBhdmFpbGFibGUgZm9yIG5ldyByZmNvbW0gY29ubmVjdGlvbnMg
KGFzc3VtaW5nIHlvdXIgY2xpZW50IGxvYWQtYmFsYW5jZXMNCj4gPiBsaWtlIHRoYXQuLi4pLg0K
PiA+DQo+IA0KPiBZZXAsIHRoYXQgaXMgd2hhdCBJJ20gZG9pbmcuIEkgYmluZCBvbmUgYWRhcHRl
ciB0byB0aGUgcmZjb21tIHNlcnZlciBhbmQgIA0KPiB1c2UgdGhlIG90aGVyIG9uZSBmb3IgZGlz
Y292ZXJ5IGFuZCBjb250ZW50IGRlbGl2ZXJ5LiBUaGUgbWFpbiBwcm9jZXNzICANCj4gdGhyZWFk
IGlzIHRoZSBhY2NlcHQgc2VydmVyIGFuZCBib3RoIHRoZSBpbnF1aXJ5IGFuZCB0aGUgY29udGVu
dCBkZWxpdmVyeSAgDQo+IGFyZSBkb25lIGluIHRocmVhZHMgbGF1bmNoZWQgZm9yIHRoZSBwdXJw
b3NlLiBJIGFsc28gbWFkZSBtb3JlIHRlc3RzICANCj4gcmVjZW50bHkgYW5kIHdoYXQgaXMgaGFw
cGVuaW5nIGlzIHRoYXQgYXMgc29vbiBhcyB0aGUgaW5xdWlyeSBzdGFydHMgdGhlICANCj4gc2Vy
dmVyIHN0b3BzIGFjY2VwdGluZyBjb25uZWN0aW9ucyBhbmQgc3RhcnRzIHByb2Nlc3NpbmcgaW5x
dWlyeSByZXN1bHQgIA0KPiBldmVudHMsIGhvd2V2ZXIsIGFmdGVyIGEgY291cGxlIG9mIG1pbnV0
ZXMgSSBjYW4gc2VlIHRoZSBzZXJ2ZXIgYm90aCAgDQo+IGFjY2VwdGluZyBhbmQgcHJvY2Vzc2lu
ZyBuZXcgY29ubmVjdGlvbnMgYW5kIG5ldyBpbnF1aXJ5IHJlc3VsdCBldmVudHMuICANCj4gVGhl
IGVuZCByZXN1bHQgaXMgdGhhdCBsYXVuY2hpbmcgYW4gaW5xdWlyeSBsZWFkcyBtZSB0byBsb29z
ZSBwb3NzaWJsZSAgDQo+IGNvbm5lY3Rpb25zIGR1cmluZyBhIGZldyBtaW51dGVzIHdoaWNoIGlz
IGV4Y2Vzc2l2ZSBmb3IgdGhpcyBjYXNlIHdoZXJlICANCj4gaW5xdWlyaWVzIHdvdWxkIGJlIGxh
dW5jaGVkIHJlZ3VsYXJseS4NCg0KSW5xdWlyeSBpbiB0aGUgaG9zdCBzdGFjayBkb2VzIHNlcmlh
bGl6ZSB3cnQuIHNldmVyYWwgb3RoZXIgaW9jdGwNCmZ1bmN0aW9uczsgaG93ZXZlciwgdGhpcyBp
cyBwZXIgZGV2aWNlLiBSdW5uaW5nIGEgc2ltcGxlIHRlc3QgaGVyZQ0KcHJvZHVjZXMgZXhwZWN0
ZWQgcmVzdWx0cywgaWUuIGNvbmN1cnJlbnQgZGlzY292ZXJ5IGFuZCBjb25uZWN0aW9uczoNCiAg
MS4gU3RhcnQgaW5xdWlyeSBvbiBkZXZpY2UgaGNpMS4gZWcuLCANCiAgICAgICAgIGhjaXRvb2wg
LWkgaGNpMSBpbnEgLS1sZW5ndGg9MzANCiAgMi4gSW5pdGlhdGUgY29ubmVjdGlvbiBvbiBkZXZp
Y2UgaGNpMC4gSW4gbXkgY2FzZSwgdHVybmluZyBvbiBhDQogICAgIGJsdWV0b290aCBoZWFkc2V0
IGluaXRpYXRlcyBhIGNvbm5lY3Rpb24uIE9mIGNvdXJzZSwgdGhlIGhlYWRzZXQNCiAgICAgd2Fz
IHByZXZpb3VzbHkgcGFpcmVkLg0KDQpZb3UgbWF5IG5lZWQgdG8gY29uZmlybSB3aGVyZS93aGF0
IHlvdXIgdGhyZWFkcyBhcmUgYmxvY2tlZCBvbiAod2VsbCwgYXQNCmxlYXN0IHlvdXIgbWFpbiBw
cm9jZXNzIHRocmVhZCB0aGF0IHNob3VsZCBiZSBibG9ja2VkIG9uIHRoZSBhY2NlcHQNCnN5c2Nh
bGwpLiBTdGFjayBiYWNrdHJhY2UgaW4gZ2RiIHdvdWxkIGNsZWFyIHRoYXQgdXAuDQoNCj4gPj4g
QW5vdGhlciBxdWVzdGlvbiBpcyByZWxhdGVkIHRvIGEgcmZjb21tIGNsaWVudCBnZXR0aW5nIGlu
dG8gRCBzdGF0ZSBhbmQNCj4gPj4gdGh1cyBub3Qga2lsbGFibGUuDQouLi4NCj4gPg0KPiA+IEFs
dGhvdWdoIEknbSBub3QgY2VydGFpbiB0aGF0IHRoZXkgd291bGQgZml4IHRoZSBwcm9ibGVtIHlv
dSdyZSBoYXZpbmcsDQo+ID4gSSBqdXN0IHBvc3RlZCBhIHBhdGNoIHNlcmllcyB0aGF0IHJlc29s
dmVzIHNvbWUgaXNzdWVzIHdpdGggbG9zdCB3YWtldXBzDQo+ID4gaW4gcmZjb21tIGFuZCBsMmNh
cC4gVGhleSBuZWVkIHRlc3RpbmcuIFlvdSdkIG5lZWQgcGF0Y2hlcyAxfjQgb2YgNy4NCj4gPg0K
PiA+IFBsZWFzZSBmZWVsIGZyZWUgdG8gcmVwbHkgZGlyZWN0IHJlZ2FyZGluZyB3aGV0aGVyIHlv
dSBjYW4gdGVzdCB0aGVzZQ0KPiA+IGFuZCB3aGF0IHRoYXQgb3V0Y29tZSB3YXMuDQo+IA0KPiBJ
IHN1cHBvc2UgdGhvc2UgcGF0Y2hlcyB3b3VsZCBiZSBhdmFpbGFibGUgaW4gdGhlIGdpdCBzb3Vy
Y2VzIHJpZ2h0PyBBdCAgDQo+IHRoZSBtb21lbnQgSSBjYW4ndCB0ZXN0IGl0IGJ1dCBpbiBhIHdl
ZWsgb3IgdHdvIEkgd2lsbCB0cnkgdG8gY29tcGlsZSB0aGUgIA0KPiBzb3VyY2VzIGFuZCB1bmxl
c3MgSSBlbmNvdW50ZXIgc29tZSBwcm9ibGVtIEkgd2lsbCByZXBseSBpbiB0aGlzIHRvcGljLg0K
DQpXZWxsLCByaWdodCBub3csIHRob3NlIHBhdGNoZXMgYXJlIG9uIHRoZSBtYWlsaW5nIGxpc3Qu
IEkgd2FzIHJlYWxseQ0KbG9va2luZyB0byBnZXQgc29tZSBtb3JlIHRlc3Rpbmcgb24gdGhlbSBf
cHJpb3JfIHRvIHRoZW0gbWFraW5nIHRoZWlyDQp3YXkgaW50byB0aGUga2VybmVsLiBUaGV5J3Jl
IG1vc3RseSBhc3NvY2lhdGVkIHdpdGggbWlzc2luZyB3YWtldXBzIC0tDQphbHRob3VnaCBpdCdz
IHBvc3NpYmxlIHRoZXkgY291bGQgZml4IHRoZSBEIHN0YXRlIGNsaWVudCwgSSBjb3VsZG4ndA0K
aHlwb3RoZXNpemUgaG93IHRoZSByZmNvbW0gc29ja2V0IGNvdWxkIGJlY29tZSB1bmludGVycnVw
dGlibGUgZnJvbSB3aGF0DQpJIGZpeGVkLiBUaGV5IG1heSBiZSB1bnJlbGF0ZWQuDQoNClJlZ2Fy
ZHMsDQpQZXRlcg0KDQo=
Hi Peter,
On Sun, 24 Jul 2011 17:26:24 +0100, Peter Hurley
<[email protected]> wrote:
> Hi S?rgio,
>
> On Wed, 2011-07-13 at 06:51 -0400, S?rgio Capela wrote:
>> Hello,
>>
> ...
>> Is it possible to accept connections at the same time a inquiry is
>> running
>> or is the inquiry a blocking operation at the stack level? With two
>> adapters my server accepts remote connections and receives and sends
>> data
>> but when an inquiry is running it stops accepting connections. The
>> inquiry
>> is done in a separate thread.
>
> That's handled in the controller at the baseband level. I don't know of
> any controllers that will accept connections while in the Inquiry
> substate - I'm not even sure if it's possible.
>
> Why are you initiating discovery from the server-side?
>
Well, this is a test where I'm trying to see if content delivery is viable
through bluetooth and in this case the content depends on context. Imagine
a number of rooms which should serve differentiated content accordingly.
The server side discovery would try to automatically infer which content
should be delivered to a given possible client. For this purpose I perform
inquiries with rssi and thus the servers would act like tracking devices
which would transmit inquiry data to a central database. These are only
trials for now and I know that inquiries with rssi values are not that
good for this type of decision so in the future this operation can be
dropped in favor of other solution even if it end up as a choice at the
user side.
> If you have to have server-side discovery, you could only perform
> inquiry with one controller at a time. That way, the other controller's
> available for new rfcomm connections (assuming your client load-balances
> like that...).
>
Yep, that is what I'm doing. I bind one adapter to the rfcomm server and
use the other one for discovery and content delivery. The main process
thread is the accept server and both the inquiry and the content delivery
are done in threads launched for the purpose. I also made more tests
recently and what is happening is that as soon as the inquiry starts the
server stops accepting connections and starts processing inquiry result
events, however, after a couple of minutes I can see the server both
accepting and processing new connections and new inquiry result events.
The end result is that launching an inquiry leads me to loose possible
connections during a few minutes which is excessive for this case where
inquiries would be launched regularly.
>> Another question is related to a rfcomm client getting into D state and
>> thus not killable. Due to my setup (two adapters in the same computer) I
>> can use the computer as both the server and the client. For test
>> purposes
>> only I made a simple rfcomm client and I put it in a shell cycle thus
>> stressing the system regarding bluetooth connections. In this situation
>> the rfcomm client application becomes unresponsive after some time due
>> to
>> a non exiting disk sleep. I then end up with multiple instances of the
>> same application and I can't kill them. By launching the application
>> after
>> this I can see that the code blocks at a socket connection command
>> entering in a disk sleep state from which it doesn't exit. When this
>> happens I have to unplug the bluetooth adapter to get it working again
>> since it starts to give timeouts with hciconfig commands like "hciconfig
>> reset".
>>
>> Any ideas about this? The problem itself is not serious since it
>> shouldn't
>> arise in normal conditions but it does require a reboot because of the
>> state D processes and makes the adapter unusable unless it is unplugged.
>
> Although I'm not certain that they would fix the problem you're having,
> I just posted a patch series that resolves some issues with lost wakeups
> in rfcomm and l2cap. They need testing. You'd need patches 1~4 of 7.
>
> Please feel free to reply direct regarding whether you can test these
> and what that outcome was.
I suppose those patches would be available in the git sources right? At
the moment I can't test it but in a week or two I will try to compile the
sources and unless I encounter some problem I will reply in this topic.
Regards,
S?rgio
>
> Regards,
> Peter
--
S?rgio Capela
SGkgU8OpcmdpbywNCg0KT24gV2VkLCAyMDExLTA3LTEzIGF0IDA2OjUxIC0wNDAwLCBTw6lyZ2lv
IENhcGVsYSB3cm90ZTogDQo+IEhlbGxvLA0KPiANCi4uLiANCj4gSXMgaXQgcG9zc2libGUgdG8g
YWNjZXB0IGNvbm5lY3Rpb25zIGF0IHRoZSBzYW1lIHRpbWUgYSBpbnF1aXJ5IGlzIHJ1bm5pbmcg
IA0KPiBvciBpcyB0aGUgaW5xdWlyeSBhIGJsb2NraW5nIG9wZXJhdGlvbiBhdCB0aGUgc3RhY2sg
bGV2ZWw/IFdpdGggdHdvICANCj4gYWRhcHRlcnMgbXkgc2VydmVyIGFjY2VwdHMgcmVtb3RlIGNv
bm5lY3Rpb25zIGFuZCByZWNlaXZlcyBhbmQgc2VuZHMgZGF0YSAgDQo+IGJ1dCB3aGVuIGFuIGlu
cXVpcnkgaXMgcnVubmluZyBpdCBzdG9wcyBhY2NlcHRpbmcgY29ubmVjdGlvbnMuIFRoZSBpbnF1
aXJ5ICANCj4gaXMgZG9uZSBpbiBhIHNlcGFyYXRlIHRocmVhZC4NCg0KVGhhdCdzIGhhbmRsZWQg
aW4gdGhlIGNvbnRyb2xsZXIgYXQgdGhlIGJhc2ViYW5kIGxldmVsLiBJIGRvbid0IGtub3cgb2YN
CmFueSBjb250cm9sbGVycyB0aGF0IHdpbGwgYWNjZXB0IGNvbm5lY3Rpb25zIHdoaWxlIGluIHRo
ZSBJbnF1aXJ5DQpzdWJzdGF0ZSAtIEknbSBub3QgZXZlbiBzdXJlIGlmIGl0J3MgcG9zc2libGUu
DQoNCldoeSBhcmUgeW91IGluaXRpYXRpbmcgZGlzY292ZXJ5IGZyb20gdGhlIHNlcnZlci1zaWRl
Pw0KDQpJZiB5b3UgaGF2ZSB0byBoYXZlIHNlcnZlci1zaWRlIGRpc2NvdmVyeSwgeW91IGNvdWxk
IG9ubHkgcGVyZm9ybQ0KaW5xdWlyeSB3aXRoIG9uZSBjb250cm9sbGVyIGF0IGEgdGltZS4gVGhh
dCB3YXksIHRoZSBvdGhlciBjb250cm9sbGVyJ3MNCmF2YWlsYWJsZSBmb3IgbmV3IHJmY29tbSBj
b25uZWN0aW9ucyAoYXNzdW1pbmcgeW91ciBjbGllbnQgbG9hZC1iYWxhbmNlcw0KbGlrZSB0aGF0
Li4uKS4NCg0KPiBBbm90aGVyIHF1ZXN0aW9uIGlzIHJlbGF0ZWQgdG8gYSByZmNvbW0gY2xpZW50
IGdldHRpbmcgaW50byBEIHN0YXRlIGFuZCAgDQo+IHRodXMgbm90IGtpbGxhYmxlLiBEdWUgdG8g
bXkgc2V0dXAgKHR3byBhZGFwdGVycyBpbiB0aGUgc2FtZSBjb21wdXRlcikgSSAgDQo+IGNhbiB1
c2UgdGhlIGNvbXB1dGVyIGFzIGJvdGggdGhlIHNlcnZlciBhbmQgdGhlIGNsaWVudC4gRm9yIHRl
c3QgcHVycG9zZXMgIA0KPiBvbmx5IEkgbWFkZSBhIHNpbXBsZSByZmNvbW0gY2xpZW50IGFuZCBJ
IHB1dCBpdCBpbiBhIHNoZWxsIGN5Y2xlIHRodXMgIA0KPiBzdHJlc3NpbmcgdGhlIHN5c3RlbSBy
ZWdhcmRpbmcgYmx1ZXRvb3RoIGNvbm5lY3Rpb25zLiBJbiB0aGlzIHNpdHVhdGlvbiAgDQo+IHRo
ZSByZmNvbW0gY2xpZW50IGFwcGxpY2F0aW9uIGJlY29tZXMgdW5yZXNwb25zaXZlIGFmdGVyIHNv
bWUgdGltZSBkdWUgdG8gIA0KPiBhIG5vbiBleGl0aW5nIGRpc2sgc2xlZXAuIEkgdGhlbiBlbmQg
dXAgd2l0aCBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlICANCj4gc2FtZSBhcHBsaWNhdGlvbiBh
bmQgSSBjYW4ndCBraWxsIHRoZW0uIEJ5IGxhdW5jaGluZyB0aGUgYXBwbGljYXRpb24gYWZ0ZXIg
IA0KPiB0aGlzIEkgY2FuIHNlZSB0aGF0IHRoZSBjb2RlIGJsb2NrcyBhdCBhIHNvY2tldCBjb25u
ZWN0aW9uIGNvbW1hbmQgIA0KPiBlbnRlcmluZyBpbiBhIGRpc2sgc2xlZXAgc3RhdGUgZnJvbSB3
aGljaCBpdCBkb2Vzbid0IGV4aXQuIFdoZW4gdGhpcyAgDQo+IGhhcHBlbnMgSSBoYXZlIHRvIHVu
cGx1ZyB0aGUgYmx1ZXRvb3RoIGFkYXB0ZXIgdG8gZ2V0IGl0IHdvcmtpbmcgYWdhaW4gIA0KPiBz
aW5jZSBpdCBzdGFydHMgdG8gZ2l2ZSB0aW1lb3V0cyB3aXRoIGhjaWNvbmZpZyBjb21tYW5kcyBs
aWtlICJoY2ljb25maWcgIA0KPiByZXNldCIuDQo+IA0KPiBBbnkgaWRlYXMgYWJvdXQgdGhpcz8g
VGhlIHByb2JsZW0gaXRzZWxmIGlzIG5vdCBzZXJpb3VzIHNpbmNlIGl0IHNob3VsZG4ndCAgDQo+
IGFyaXNlIGluIG5vcm1hbCBjb25kaXRpb25zIGJ1dCBpdCBkb2VzIHJlcXVpcmUgYSByZWJvb3Qg
YmVjYXVzZSBvZiB0aGUgIA0KPiBzdGF0ZSBEIHByb2Nlc3NlcyBhbmQgbWFrZXMgdGhlIGFkYXB0
ZXIgdW51c2FibGUgdW5sZXNzIGl0IGlzIHVucGx1Z2dlZC4NCg0KQWx0aG91Z2ggSSdtIG5vdCBj
ZXJ0YWluIHRoYXQgdGhleSB3b3VsZCBmaXggdGhlIHByb2JsZW0geW91J3JlIGhhdmluZywNCkkg
anVzdCBwb3N0ZWQgYSBwYXRjaCBzZXJpZXMgdGhhdCByZXNvbHZlcyBzb21lIGlzc3VlcyB3aXRo
IGxvc3Qgd2FrZXVwcw0KaW4gcmZjb21tIGFuZCBsMmNhcC4gVGhleSBuZWVkIHRlc3RpbmcuIFlv
dSdkIG5lZWQgcGF0Y2hlcyAxfjQgb2YgNy4NCg0KUGxlYXNlIGZlZWwgZnJlZSB0byByZXBseSBk
aXJlY3QgcmVnYXJkaW5nIHdoZXRoZXIgeW91IGNhbiB0ZXN0IHRoZXNlDQphbmQgd2hhdCB0aGF0
IG91dGNvbWUgd2FzLg0KDQpSZWdhcmRzLA0KUGV0ZXINCg==
Hi Peter,
Em Mon, 25 Jul 2011 23:05:17 +0100, Peter Hurley
<[email protected]> escreveu:
> Hi S?rgio,
>
> On Sun, 2011-07-24 at 18:08 -0400, S?rgio Capela wrote:
>> Hi Peter,
>>
> ....
>> > If you have to have server-side discovery, you could only perform
>> > inquiry with one controller at a time. That way, the other
>> controller's
>> > available for new rfcomm connections (assuming your client
>> load-balances
>> > like that...).
>> >
>>
>> Yep, that is what I'm doing. I bind one adapter to the rfcomm server and
>> use the other one for discovery and content delivery. The main process
>> thread is the accept server and both the inquiry and the content
>> delivery
>> are done in threads launched for the purpose. I also made more tests
>> recently and what is happening is that as soon as the inquiry starts the
>> server stops accepting connections and starts processing inquiry result
>> events, however, after a couple of minutes I can see the server both
>> accepting and processing new connections and new inquiry result events.
>> The end result is that launching an inquiry leads me to loose possible
>> connections during a few minutes which is excessive for this case where
>> inquiries would be launched regularly.
>
> Inquiry in the host stack does serialize wrt. several other ioctl
> functions; however, this is per device. Running a simple test here
> produces expected results, ie. concurrent discovery and connections:
> 1. Start inquiry on device hci1. eg.,
> hcitool -i hci1 inq --length=30
> 2. Initiate connection on device hci0. In my case, turning on a
> bluetooth headset initiates a connection. Of course, the headset
> was previously paired.
>
> You may need to confirm where/what your threads are blocked on (well, at
> least your main process thread that should be blocked on the accept
> syscall). Stack backtrace in gdb would clear that up.
>
I was able to test this today to make sure that a block was not the cause
of the problem. The thread isn't blocked since it remains printing to
stdout on the accept thread.
I'm calling the client from a separate machine using the following shell
command:
while [ 1 ]; do ./rfcomm-client; sleep 5; done
where rfcomm-client is the simple example found in the web from the
bluetooth introduction book.
The response from my server is:
waiting for connection
waiting for connection
waiting for connection
accepted connection from 00:15:83:15:A3:10
received [{"sala":"Sala
tziranda","conteudos":[{"i":"qualquercoisa","t":"qualquercoisa2","d":"a"}]}]
thread created and detached
waiting for connection
thread end
waiting for connection
waiting for connection
waiting for connection
accepted connection from 00:15:83:15:A3:10
received [{"sala":"Sala
tziranda","conteudos":[{"i":"qualquercoisa","t":"qualquercoisa2","d":"a"}]}]
thread created and detached
waiting for connection
thread end
waiting for connection
waiting for connection
waiting for connection
accepted connection from 00:15:83:15:A3:10
received [{"sala":"Sala
tziranda","conteudos":[{"i":"qualquercoisa","t":"qualquercoisa2","d":"a"}]}]
thread created and detached
waiting for connection
thread end
waiting for connection
waiting for connection
waiting for connection
accepted connection from 00:15:83:15:A3:10
received [{"sala":"Sala
tziranda","conteudos":[{"i":"qualquercoisa","t":"qualquercoisa2","d":"a"}]}]
thread created and detached
thread end
waiting for connection
waiting for connection
waiting for connection
where "waiting for connection" is written to stdout before the accept
call. The timeout for the accept is of 1.5 seconds.
In attachment I send two logs with my results when I turn on the rssi
inquiry. For testing purposes I initiate the inquiry when receiving a
client connection if one isn't already running.
- ssh-output.txt is the log for the client where the error message I get
is presented in one line followed by the time in seconds in another;
- shell-output.txt is the log for the server where both the accept server
messages and the inquiry messages are present. The content of the file is
similar to the one already presented except for the following:
-- inquiry start logged with two lines: "Inquiry" and "Starting inquiry
with RSSI..." which appears whenever I start a inquiry;
-- inquiry results: "<TZ_OK> RSSI 188 Time 1312194878" which shows the
result of a curl call from within the program followed by a "RSSI" value
and time in seconds.
From the server log it can be seen that I initiate a inquiry in response
to a connection and start receiving inquiry responses at time 1312194729
and at the same time I stop receiving connections despite the "waiting for
connection" logged output. Inspecting the client log I see six failed
connection attempts from Time 1312194740 to time 1312194791. Going to the
sever log again I can see that I then receive 3 connection from the client
with the inquiry still running as seen below.
<TZ_OK> RSSI 200 Time 1312194794
waiting for connection
accepted connection from 00:15:83:15:A3:10
received [{"sala":"Sala
tziranda","conteudos":[{"i":"qualquercoisa","t":"qualquercoisa2","d":"a"}]}]
thread created and detached
waiting for connection
thread end
waiting for connection
waiting for connection
<TZ_OK> RSSI 190 Time 1312194799
<TZ_OK> RSSI 182 Time 1312194801
accepted connection from 00:15:83:15:A3:10
received [{"sala":"Sala
tziranda","conteudos":[{"i":"qualquercoisa","t":"qualquercoisa2","d":"a"}]}]
thread created and detached
waiting for connection
thread end
<TZ_OK> RSSI 181 Time 1312194801
<TZ_OK> RSSI 186 Time 1312194804
waiting for connection
accepted connection from 00:15:83:15:A3:10
received [{"sala":"Sala
tziranda","conteudos":[{"i":"qualquercoisa","t":"qualquercoisa2","d":"a"}]}]
thread created and detached
waiting for connection
thread end
waiting for connection
<TZ_OK> RSSI 189 Time 1312194809
I then start another inquiry:
<TZ_OK> RSSI 190 Time 1312194811
<TZ_OK>accepted connection from 00:15:83:15:A3:10
received [{"sala":"Sala
tziranda","conteudos":[{"i":"qualquercoisa","t":"qualquercoisa2","d":"a"}]}]
thread created and detached
Inquiry
waiting for connection
Starting inquiry with RSSI...
thread end
RSSI 189 Time 1312194812
And start loosing connections again:
uh oh: Invalid argument
Time 1312194823
>> >> Another question is related to a rfcomm client getting into D state
>> and
>> >> thus not killable.
> ...
>> >
>> > Although I'm not certain that they would fix the problem you're
>> having,
>> > I just posted a patch series that resolves some issues with lost
>> wakeups
>> > in rfcomm and l2cap. They need testing. You'd need patches 1~4 of 7.
>> >
>> > Please feel free to reply direct regarding whether you can test these
>> > and what that outcome was.
>>
>> I suppose those patches would be available in the git sources right? At
>> the moment I can't test it but in a week or two I will try to compile
>> the
>> sources and unless I encounter some problem I will reply in this topic.
>
> Well, right now, those patches are on the mailing list. I was really
> looking to get some more testing on them _prior_ to them making their
> way into the kernel. They're mostly associated with missing wakeups --
> although it's possible they could fix the D state client, I couldn't
> hypothesize how the rfcomm socket could become uninterruptible from what
> I fixed. They may be unrelated.
>
I thought the patches were on the user side of things and not on the
kernel side. I can't really test this since I can't even afford the disk
space needed for the kernel compilation because I'm making these tests in
a resource limited machine. Also I can't make the machine unstable.
Regards,
S?rgio Capela
> Regards,
> Peter
>
--
S?rgio Pedro dos Santos Capela - Tziranda
Polo Tecnol?gico de Lisboa
Edif?cio Empresarial 3
1600-546 Lisboa
Telf: 21 314 09 83
Telml: 96 491 94 37
Email: [email protected]