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.

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.

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.

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

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?)

We fixed this. Thanks for helping out.

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

thanks, but we won by 2 minutes :)

then no, thank you ;)