From owner-freebsd-bluetooth@FreeBSD.ORG Mon Jan 10 20:06:25 2005 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 386F816A4CE for ; Mon, 10 Jan 2005 20:06:25 +0000 (GMT) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFBD943D45 for ; Mon, 10 Jan 2005 20:06:24 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45])j0AK68GF002203; Mon, 10 Jan 2005 14:06:08 -0600 Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 14:06:02 -0600 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 10 Jan 2005 14:05:53 -0600 Message-ID: <41E2E01C.2090003@savvis.net> Date: Mon, 10 Jan 2005 12:05:48 -0800 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jes References: <20050107163705.616cbe5f@zurich.homeunix.com> <41DECEA3.5080500@savvis.net> <20050107195406.0c76f42e@zurich.homeunix.com> <41DEE958.70403@savvis.net> <20050107223725.15a4554d@zurich.homeunix.com> <20050110163125.060d1e26@zurich.homeunix.com> <41E2C546.10801@savvis.net> In-Reply-To: <41E2C546.10801@savvis.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jan 2005 20:05:53.0808 (UTC) FILETIME=[CA153100:01C4F74F] X-ECS-MailScanner: No virus is found cc: freebsd-bluetooth@freebsd.org Subject: Re: Motorola E1000 and obexapp 1.4.4 in server mode X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 20:06:25 -0000 Jes, can i ask you to try something else? basically its the same change as before, but you need to adjust a couple more variables. 1) edit /sys/netgraph/bluetooth/include/ng_btsocket_rfcomm.h file and change #define RFCOMM_DEFAULT_MTU 127 to #define RFCOMM_DEFAULT_MTU 667 2) edit /sys/netgraph/bluetooth/include/ng_btsocket_rfcomm.h file and change #define NG_BTSOCKET_RFCOMM_SENDSPACE \ (RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 10) #define NG_BTSOCKET_RFCOMM_RECVSPACE \ (RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 10) to #define NG_BTSOCKET_RFCOMM_SENDSPACE \ (RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 2) #define NG_BTSOCKET_RFCOMM_RECVSPACE \ (RFCOMM_MAX_CREDITS * RFCOMM_DEFAULT_MTU * 2) 3) re-compile ng_btsocket module, i.e. # cd /sys/modules/netgraph/bluetooth/socket/ # make depend # make # make install 4) reboot and try again >>>> at this point i'm not sure who is at fault here. after reading the >>>> spec i was not sure if *entire* rfcomm frame must fit into l2cap >>>> mtu, or segmentation is allowed. i need to re-read the spec >>>> and look at more dumps from different bluetooth devices. it seems >>>> to me that if l2cap channel was configured to use 132 bytes >>>> mtu then device should not send larger packets, so my first >>>> impression is that the phone has a bug. >>>> >>>> as workaround you might want to try this: >>>> >>>> 1) edit /sys/netgraph/bluetooth/include/ng_btsocket_rfcomm.h file >>>> and change RFCOMM_DEFAULT_MTU from 127 to 667. >>>> >>>> 2) re-compile ng_btsocket module, i.e. >>>> >>>> # cd /sys/modules/netgraph/bluetooth/socket/ # make depend # make >>>> # make install >>>> >>>> 3) reboot and try again >>> >>> >>> No, it doesn't work nor obexapp in client mode with that change. It >>> really doesn't matter because of I can retrieve files from pc in >>> client mode... > > > hcidump please? > >> The transfer initated from phone to Windows 2000 works fine, the same >> with a sony ericsson T610. The problem is "only" with obexapp. Maybe >> is a phone bug but could be possible to do a workaround to solve it >> ? > > > that is what i said - i'm not sure who at fault here. the problem really > is in l2cap/rfcomm layer *not* in the opexapp. the phone sends packets > that exceeds configured mtu, so the stack drops them. these packets > never reach obexapp. > > btw, did you try to push files from t610 to freebsd? does it work? i > have se t68i and it works just fine. thanks, max