From owner-freebsd-bluetooth@FreeBSD.ORG Tue Oct 19 09:28:54 2010 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5F78106567A for ; Tue, 19 Oct 2010 09:28:54 +0000 (UTC) (envelope-from plunky@rya-online.net) Received: from smtp6.freeserve.com (smtp5.freeserve.com [193.252.22.151]) by mx1.freebsd.org (Postfix) with ESMTP id 41E188FC0C for ; Tue, 19 Oct 2010 09:28:54 +0000 (UTC) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3528.me.freeserve.com (SMTP Server) with ESMTP id 0DD921C00087 for ; Tue, 19 Oct 2010 11:12:32 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf3528.me.freeserve.com (SMTP Server) with ESMTP id F35BB1C00089 for ; Tue, 19 Oct 2010 11:12:31 +0200 (CEST) Received: from rya-online.net (unknown [89.194.195.33]) by mwinf3528.me.freeserve.com (SMTP Server) with SMTP id 239AC1C00087 for ; Tue, 19 Oct 2010 11:12:30 +0200 (CEST) X-ME-UUID: 20101019091231146.239AC1C00087@mwinf3528.me.freeserve.com Received: (nullmailer pid 19547 invoked by uid 1000); Tue, 19 Oct 2010 09:12:45 -0000 Date: Tue, 19 Oct 2010 10:12:45 +0100 (BST) To: freebsd-bluetooth@freebsd.org User-Agent: Alpine 2.00 (NEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-792984880-1287479565=:7443" Message-Id: <1287479565.566030.22663.nullmailer@galant.ukfsn.org> From: Iain Hibbert Subject: obexapp handling clean disconnect X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 09:28:54 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-792984880-1287479565=:7443 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 --0-792984880-1287479565=:7443 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=obexapp.patch Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=obexapp.patch JE5ldEJTRCQNCg0KLS0tIHRyYW5zcG9ydC5jLm9yaWcJMjAxMC0xMC0xOSAw ODo1MDoxMS4wMDAwMDAwMDAgKzAwMDANCisrKyB0cmFuc3BvcnQuYw0KQEAg LTM1OCw2ICszNTgsMTAgQEAgYWdhaW46DQogDQogCQlyZXR1cm4gKG4pOw0K IAl9DQorCWlmIChuID09IDApIHsNCisJCWxvZ19pbmZvKCIlcygpOiBDb25u ZWN0aW9uIGNsb3NlZC4iLCBfX2Z1bmNfXyk7DQorCQlyZXR1cm4gKC0xKTsN CisJfQ0KIA0KIAlsb2dfZGVidWcoIiVzKCk6IEdvdCAlZCBieXRlcyIsIF9f ZnVuY19fLCBuKTsNCiANCg== --0-792984880-1287479565=:7443--