public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* [Bluez-devel] Rfcomm use count
@ 2004-08-31 22:09 Daryl Van Vorst
  2004-09-08 22:48 ` Daryl Van Vorst
  2004-09-12 14:15 ` Marcel Holtmann
  0 siblings, 2 replies; 41+ messages in thread
From: Daryl Van Vorst @ 2004-08-31 22:09 UTC (permalink / raw)
  To: 'BlueZ Mailing List'

Hi Marcel,

Any suggestions you have regarding the following would be greatly
appreciated.

I have a server program which does the following:

1. Intializes and attaches two modules via serial port (CSR 18.1)
2. Has SPP and OPP servers
3. Does some HCI-level stuff to monitor connections and close =
connections to
misbehaving devices.

The program will initiate rfcomm connections to devices which do not =
allow
role switches.

If I kill the program while several devices are connected (or are in the
process of connecting/disconnecting), sometimes the rfcomm use count is =
left
above 0 (I've seen it as high as 4). Killing the program detaches the
modules (this is verified by hcid's log output). Killing sdpd and hcid
doesn't reduce the use count. No other bluetooth programs are running,
except a kernel thread krfcommd.

Re-starting the program produces the error "Address already in us(98)" =
when
trying to bind the SPP server socket. The only remedy I've found is to
reboot the device.

Could sending an hci_disconnect directly, rather than using close(), be
confusing the stack? I realize this isn't the ideal way of closing
connections... It only gets used if the normal process is taking longer =
than
is desired when a device is forcing the server to be a slave.

The kernel version is 2.4.21-mh10, with various ARM patches (which, as =
far
as I can tell, do not touch any bluetooth related code). I have a very
similar program running on 2.4.18-mh8 and have never noticed this =
problem.

This doesn't seem to be related, but just in case it is: I'm also seeing
"hci_cmd_task: hci0 command tx timeout" errors. I am able to get the =
above
situation to happen without a timeout error.

Thanks,

-Daryl.



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 41+ messages in thread
* RE: [Bluez-devel] Rfcomm use count
@ 2004-09-13 19:06 Daryl Van Vorst
  2004-09-13 20:48 ` Daryl Van Vorst
  0 siblings, 1 reply; 41+ messages in thread
From: Daryl Van Vorst @ 2004-09-13 19:06 UTC (permalink / raw)
  To: 'Marcel Holtmann'; +Cc: 'BlueZ Mailing List'

[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]

Hi Marcel,

I have attached a log for you to look at if you have some time. If not,
maybe just answer my question below. :)

Here's what I see:

One stray socket. I added the socket pointer to the proc output.
Proc/bluetooth/rfcomm:
sk  2C:02:5F:16:05:00 3A:A4:58:16:05:00 9 1 c3b69340

I have a setup where I kill my app after a random time interval while
several devices are connecting, disconnecting, and transfering data, etc.

Here's a brief version of the log:

1. Program gets kill signal (time 15:09:30)
2. HCI devices get shut down
3. Some data remaining for transmission is sent.
4. One listen socket is closed (I think this is the one which is not being
used)
5. Some sockets/dlcs get closed
6. An incomming connection is received (rfcomm_connect_ind is called, and a
socket is created which matches the one in proc)
7. Some more sockets/dlcs get closed
8. The listen (probably the one which is being used) gets closed

I don't see any lines from rfcomm_sock_accept after the rfcomm_connect_ind
line. And rfcomm_sock_release is never called for the new connection.

My knowledge here is limited, and I may be mis-interpreting the log. But it
appears that a socket is allocated for the new connection as long as there
is room in the wait queue. And if that connection is never accepted, is it
the job of rfcomm_sock_cleanup_listen() to deal with it? That is, it is not
the kernel's duty (outside of the rfcomm module) to deal with the allocated
socket?

So, I think, it appears that rfcomm_sock_cleanup_listen isn't working right.

Not sure if rfcomm_sock_accept is still looping or not while this is going
on.

More digging needed...

Thanks,

-Daryl.

> -----Original Message-----
> From: Daryl Van Vorst [mailto:daryl@wideray.com] 
> Sent: September 13, 2004 9:37 AM
> To: 'Marcel Holtmann'
> Subject: RE: [Bluez-devel] Rfcomm use count
> 
> 
> Hi Marcel,
> 
> > I haven't had time to look at your problem in the last two weeks and
> > dealing with ARM related stuff still not fits into my left 
> > free time for
> > the next weeks. Is this behaviour reproduceable on x86 
> machines and do
> > you have a small text program to trigger this effect? And 
> > what I really
> > care about, is this problem also available with a 2.6 kernel?
> 
> Thanks for the response.
> 
> I have not yet tried to reproduce it on an x86. And 
> unfortunately I don't have a good way to trigger the effect. 
> I have spent quite a lot of time trying to come up with a 
> simple way (or any way) to reliably reproduce the problem. 
> Depending on how the next while plays out, I may try to 
> reproduce it on an x86.
> 
> I would like to be working with a 2.6 kernel, but time 
> constraints have prevented moving to it (would require 
> porting drivers). Maybe on an x86 if time permits.
> 
> I'm currently sifting through RFCOMM debug output. When I get 
> something interesting I'll send it along. I should have 
> something shortly.
> 
> -Daryl.
> 
> 

[-- Attachment #2: messages.gz --]
[-- Type: application/x-gzip, Size: 3161 bytes --]

^ permalink raw reply	[flat|nested] 41+ messages in thread
* [Bluez-devel] Rfcomm Use Count
@ 2004-09-17  0:10 Daryl Van Vorst
  2004-09-17  8:58 ` Marcel Holtmann
  0 siblings, 1 reply; 41+ messages in thread
From: Daryl Van Vorst @ 2004-09-17  0:10 UTC (permalink / raw)
  To: 'BlueZ Mailing List'

Marcel,

I have a simple way to reproduce at least part of this bug. I don't have =
an
up-to-date x86 machine to try this on, but I suspect you'll see the same
behaviour:

1. Compile and run the attached code on one machine
2. Connect to it from another machine using: rctest -n -P1 <bd_addr>
3. Hit ctrl-c on rctest
4. Hit ctrl-c on bzt (or whatever you called the compiled code)
5. lsmod and look at the rfcomm use count.

I think the problem stems from rfcomm_cleanup_listen() and
bluez_accept_dequeue(). Bluez_accept_dequeue() won't return the socket =
if it
is in the closed state, and so rfcomm_cleanup_listen() can't fully =
cleanup.

And if accept is called before rfcomm_cleanup_listen(), then (I think) =
the
socket will be unlinked from the accept queue (by accept) but not =
killed,
and so also will not get cleaned up.

Things appear to work if you reverse the order of steps 3 and 4.

I'd send you a patch if I had a simple one, but I don't know what the =
best
approach is. On solution may be to make bluez_accept_dequeue() always =
return
the socket regardless of state and then fix anything that calls
bluez_accept_dequeue() to handle the possibility of a closed socket =
being
returned.

-Daryl.

--- test code below ---
// bzt.c

#include <stdio.h>
#include <errno.h>
#include <sys/socket.h>

#include <bluetooth/bluetooth.h>
#include <bluetooth/rfcomm.h>

int main(int argc, char *argv[])
{
	struct sockaddr_rc loc_addr;
	int s;
=09
	if((s =3D socket(PF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM)) < 0) {
		printf("Can't create server socket:
%s(%d)\n",strerror(errno), errno);
		return -1;
	}
=09
	loc_addr.rc_family =3D AF_BLUETOOTH;
	bacpy(&loc_addr.rc_bdaddr, BDADDR_ANY);
	loc_addr.rc_channel =3D 1;
	if(bind(s,(struct sockaddr *) &loc_addr, sizeof(loc_addr)) < 0) {
		printf("Can't bind %s(%d)\n",strerror(errno), errno);
		return -1;
	}
=09
	if(listen(s,10)) {
		printf("Can't listen %s(%d)\n",strerror(errno),errno);
		return -1;
	}
=09
	printf("Listening...\n");
	while(1) sleep(999);
=09
	return 0;
}



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 41+ messages in thread
end of thread, other threads:[~2004-10-02  9:26 UTC | newest]

Thread overview: 41+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-31 22:09 [Bluez-devel] Rfcomm use count Daryl Van Vorst
2004-09-08 22:48 ` Daryl Van Vorst
2004-09-08 23:10   ` Daryl Van Vorst
2004-09-12 14:15 ` Marcel Holtmann
  -- strict thread matches above, loose matches on Subject: below --
2004-09-13 19:06 Daryl Van Vorst
2004-09-13 20:48 ` Daryl Van Vorst
2004-09-13 23:54   ` Daryl Van Vorst
2004-09-14  9:18     ` Marcel Holtmann
2004-09-14 21:58       ` Daryl Van Vorst
2004-09-17  0:10 [Bluez-devel] Rfcomm Use Count Daryl Van Vorst
2004-09-17  8:58 ` Marcel Holtmann
2004-09-20 17:58   ` Daryl Van Vorst
2004-09-20 18:32     ` Marcel Holtmann
2004-09-20 18:52       ` Daryl Van Vorst
2004-09-20 19:48         ` Marcel Holtmann
2004-09-20 20:52           ` Daryl Van Vorst
2004-09-20 18:37     ` Daryl Van Vorst
2004-09-20 19:50       ` Marcel Holtmann
2004-09-20 20:11         ` Daryl Van Vorst
2004-09-20 20:34           ` Marcel Holtmann
2004-09-20 21:03             ` Daryl Van Vorst
2004-09-20 21:28               ` Marcel Holtmann
2004-09-20 22:38                 ` Daryl Van Vorst
2004-09-20 23:33                   ` Marcel Holtmann
2004-09-21 20:14                     ` Daryl Van Vorst
2004-09-21 20:32                       ` Marcel Holtmann
2004-09-21 20:39                         ` Daryl Van Vorst
2004-09-21 21:26                           ` Daryl Van Vorst
2004-09-21 22:07                             ` Marcel Holtmann
2004-09-21 22:26                               ` Marcel Holtmann
2004-09-21 22:44                                 ` Daryl Van Vorst
2004-09-22 11:08                                   ` Marcel Holtmann
2004-09-22 13:53                                     ` Marcel Holtmann
2004-09-22 17:57                                       ` Daryl Van Vorst
2004-09-22 18:12                                         ` Marcel Holtmann
2004-09-22 19:05                                           ` Daryl Van Vorst
2004-09-22 19:33                                             ` Marcel Holtmann
2004-09-22 19:52                                               ` Daryl Van Vorst
2004-09-22 19:57                                                 ` Marcel Holtmann
2004-09-22 20:05                                                   ` Daryl Van Vorst
     [not found]                                       ` <1096471423.20392.444.camel@igno>
2004-10-02  9:26                                         ` Marcel Holtmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox