All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-users@lists.sourceforge.net
Subject: Re: [Bluez-users] error on connect
Date: Tue, 19 Apr 2005 17:47:00 +0200	[thread overview]
Message-ID: <1113925620.2469.26.camel@pegasus> (raw)
In-Reply-To: <426522C6.10700@gmx.ch>

Hi Marco,

> >>If a broadcom dongle is listening, sometimes the ACL packet marked with #2# 
> >>is received where the #1# lines are. Actually, looking at the hcidump of 
> >>the sending dongle, that's the time the packet is sent (alway, dongle 
> >>independant).
> > 
> > do you have a dump where this actually happens?
> 
> the dump of the listeining or the sending dongle?
> for the listening one, I sent a hcidump from a successfull and failed 
> connection. with a diff, you see exactly what I described.

I checked the thread and I found the listening one. The handles are
matching and now I fully understand whats happening.

> >>It looks like this too early packet now causes the (sensefull) 
> >>"hci_acldata_packet: hci1 ACL packet for unknown connection handle 6" 
> >>kernel error message. The dongle then waits for this acl package and thinks 
> >>this connection is in etablishing phase, so it is blocked.
> > 
> >>From a quick look at the kernel code, it seems that an ACL packet for an
> > unknown connection handle may corrupt the HCI flow control.
> 
> I think exactly this happens...

However even if I fix the HCI flow control problem, the packet is still
lost, because we don't know the connection handle at that time.

> >>The question now is, who is responsible for holding this packed back? The 
> >>kernel? The dongle itself?
> > 
> > The dongle is responsible for that and actually it is only allowed to
> > send data packets after the "Connect Complete" event. Otherwise we don't
> > know its handle and thus can't correctly assign it to a connection.
> 
> but then it's strainge that these ACL packets are always sent before the 
> "connection" successfull packet. or do I right now miss something?

This must be a bug in the Broadcom link manager firmware. Seems like
BlueZ is "too fast" for these chips.

If you wanna workaround this problem you must put potential ACL data
packets into a queue and then check this queue after you received the
connection handle.

Does this happen with both Broadcom dongles you have? You only saw that
on the listing side, right?

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

  reply	other threads:[~2005-04-19 15:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-15 17:52 [Bluez-users] error on connect Marco Trudel
2005-04-15 23:20 ` Marcel Holtmann
2005-04-16 19:07   ` Marco Trudel
2005-04-16 20:09     ` Marcel Holtmann
2005-04-17  1:33       ` Marco Trudel
2005-04-17  1:46         ` Marcel Holtmann
2005-04-17 10:17           ` Marco Trudel
2005-04-18 18:13             ` Marco Trudel
2005-04-18 18:41               ` Marcel Holtmann
2005-04-19 14:48                 ` Marco Trudel
2005-04-19 15:13                   ` Marcel Holtmann
2005-04-19 15:24                     ` Marco Trudel
2005-04-19 15:47                       ` Marcel Holtmann [this message]
2005-04-19 16:00                         ` Marco Trudel
2005-04-19 16:13                           ` Marcel Holtmann
2005-04-19 16:32                             ` Marco Trudel
2005-04-19 16:51                               ` Marcel Holtmann
2005-04-19 22:11                                 ` Marco Trudel
2005-04-19 22:32                                   ` Marcel Holtmann
2005-04-20 12:17                                     ` Marco Trudel
2005-04-20 12:32                                       ` Marcel Holtmann
2005-04-20 12:44                                         ` Marco Trudel
2005-04-24 12:53                                         ` Marco Trudel
2005-04-24 14:48                                           ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1113925620.2469.26.camel@pegasus \
    --to=marcel@holtmann.org \
    --cc=bluez-users@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.