Return-Path: Message-ID: <20051205083440.79581.qmail@web32414.mail.mud.yahoo.com> From: Arch Sayo To: bluez-users@lists.sourceforge.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-578106633-1133771680=:79534" Subject: [Bluez-users] Did not proceed with 2nd OBEX Connect request Sender: bluez-users-admin@lists.sourceforge.net Errors-To: bluez-users-admin@lists.sourceforge.net Reply-To: bluez-users@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ users List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 5 Dec 2005 00:34:40 -0800 (PST) --0-578106633-1133771680=:79534 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi Marcel, Yes, you're right. There was no OBEX Connect request following the SDP service request. What I was trying to ask is that supposed to be, there is another OBEX Connect request following the SDP service request. However as you have seen in the hcidump trace, this did not happen. The normal flow of the Bluetooth transaction on the client side is that after the SDP service request, there will be a 2nd OBEX Connect request (without a prior OBEX Disconnect request for the 1st OBEX Connect request). In this regard, is there something in BlueZ that prevents this from happening? Thank you so much, Arch > Supposedly, after the L2CAP disconnection, the Bluetooth device > (mobile phone) will issue another OBEX Connect Request. However, as > you may see in this trace, the 2nd OBEX Connect Request was not > issued. I hope to know more about what happened to the connection and > why doesn't the transaction proceed. the first L2CAP is to PSM 3 to establish the RFCOMM connection and then it establishes the OBEX connection on channel 5. The second L2CAP is to PSM 1 for an SDP service request. There are no multiple OBEX connection requests. Regards Marcel --------------------------------- Yahoo! Personals Skip the bars and set-ups and start using Yahoo! Personals for free --0-578106633-1133771680=:79534 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi Marcel,

Yes, you're right. There was no OBEX Connect request following the SDP service request. What I was trying to ask is that supposed to be, there is another OBEX Connect request following the SDP service request. However as you have seen in the hcidump trace, this did not happen. The normal flow of the Bluetooth transaction on the client side is that after the SDP service request, there will be a 2nd OBEX Connect request (without a prior OBEX Disconnect request for the 1st OBEX Connect request). In this regard, is there something in BlueZ that prevents this from happening?

Thank you so much,

Arch

> Supposedly, after the L2CAP disconnection, the
Bluetooth device
> (mobile phone) will issue another OBEX Connect
Request. However, as
> you may see in this trace, the 2nd OBEX Connect
Request was not
> issu ed. I hope to know more about what happened to
the connection and
> why doesn't the transaction proceed.

the first L2CAP is to PSM 3 to establish the RFCOMM
connection and then
it establishes the OBEX connection on channel 5. The
second L2CAP is to
PSM 1 for an SDP service request. There are no
multiple OBEX connection
requests.

Regards

Marcel

Yahoo! Personals
Skip the bars and set-ups and start using Yahoo! Personals for free --0-578106633-1133771680=:79534-- ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users