L2CAP services unregister doesn't work on client disconnect

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Register an L2CAP service from a daemon client
2. Close the client
3. Restart the client

What is the expected output? What do you see instead?
New client should be able to register services with the same ID. Instead, they 
are refused because the old connections persist.

What version of the product are you using? On what operating system?
SVN trunk, Linux 3.x.

Patch attached -- adds a function to l2cap.c to unregister all services from a 
particular connection, which is then called from daemon.c as the client is 
disconnected.

Original issue reported on code.google.com by soul.cak...@gmail.com on 15 Oct 2014 at 12:08

Attachments:

• l2cap_unreg.patch

[GoogleCodeExporter]

I totally missed the documentation in linked_list.h that points out you do the 
bookkeeping to make it safe to remove while iterating. Here is a much neater 
patch.

Original comment by soul.cak...@gmail.com on 15 Oct 2014 at 7:51

Attachments:

• l2cap_unreg_v2.patch

[GoogleCodeExporter]

Hi

Until recently, l2cap & rfcomm had to do the bookkeeping about which client 
would do what. As this violates the layer structure and is not needed in 
embedded systems, we moved the book-keeping into daemon.c.
Check daemon_disconnect_client() the functions it calls.

Original comment by matthias.ringwald@gmail.com on 15 Oct 2014 at 9:08

• Changed state: Started

[GoogleCodeExporter]

Hi Mathias,
thanks for pointing that out. I see the code now, but unfortunately it doesn't 
seem to work for me.

When daemon_packet_handler receives L2CAP_EVENT_SERVICE_REGISTERED, the 
connection is NULL, presumably because it's coming from the stack - so it 
doesn't get tallied against the connection. Does this mean one has to keep 
track of pending connections somewhere else?

A smaller issue is that the status check is also backwards; it checks for 
!packet[2], but should be packet[2]. (Are the status codes for 
RFCOMM_EVENT_OPEN_CHANNEL_COMPLETE the same? If so, the same applies.)

Thanks - James

Original comment by soul.cak...@gmail.com on 15 Oct 2014 at 10:37

[GoogleCodeExporter]

Thanks for pointing that out. So, we need to add the connection value to the 
l2cap_event_service_registered event. Will check tomorrow.

No, it's up to the daemon to close all channels and unregister all services.

Which status check is suspicious? (file & line number?)

Original comment by matthias.ringwald@gmail.com on 15 Oct 2014 at 12:01

• Changed title: L2CAP services unregister doesn't work on client disconnect

[GoogleCodeExporter]

We fixed this. Thanks for helping out.

Original comment by mila@ringwald.ch on 16 Oct 2014 at 11:35

• Changed state: Fixed

[GoogleCodeExporter]

Found the missing connection parameter. Patch is attached - including the 
status checks.

Original comment by soul.cak...@gmail.com on 16 Oct 2014 at 11:37

Attachments:

• l2cap_unreg_v3.patch

[GoogleCodeExporter]

thanks, but we won by 2 minutes :)

Original comment by matthias.ringwald@gmail.com on 16 Oct 2014 at 11:39

[GoogleCodeExporter]

then no, thank you ;)

Original comment by soul.cak...@gmail.com on 16 Oct 2014 at 12:26