Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 Oct 2010 10:12:45 +0100 (BST)
From:      Iain Hibbert <plunky@rya-online.net>
To:        freebsd-bluetooth@freebsd.org
Subject:   obexapp handling clean disconnect
Message-ID:  <1287479565.566030.22663.nullmailer@galant.ukfsn.org>

next in thread | raw e-mail | index | archive | help

[-- Attachment #1 --]
Hi

I was just cleaning up a minor annoyance (on NetBSD), that sdpd would
complain of an error rather than notice a disconnect when a remote device
closed the L2CAP socket. eg I would see

 "Could not receive SDP request on L2CAP socket. Connection reset by peer (54)"

rather than

 "Client on L2CAP socket has disconnected"

in my log. Interestingly, sdpd always reported this properly for the
control socket and I traced this to my L2CAP code which unnecessarily set
the socket error to ECONNRESET when a disconnect request was received.

So, all is well..  then I looked to the RFCOMM code because I did the same
thing there, but when I changed it I found that obexapp dives into a loop
in obexapp_transport_handle_input() when the remote side ends the
connection normally as read() now returns 0 for EOF.

The OBEX_HandleInput() function normally returns -1 for this case, and
updating the obexapp_transport_handle_input() function to do the same
fixes it for me, patch attached.

regards,
iain
[-- Attachment #2 --]
$NetBSD$

--- transport.c.orig	2010-10-19 08:50:11.000000000 +0000
+++ transport.c
@@ -358,6 +358,10 @@ again:
 
 		return (n);
 	}
+	if (n == 0) {
+		log_info("%s(): Connection closed.", __func__);
+		return (-1);
+	}
 
 	log_debug("%s(): Got %d bytes", __func__, n);
 

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1287479565.566030.22663.nullmailer>