All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bastien Nocera <hadess@hadess.net>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Broken SDP parsing?
Date: Mon, 09 Mar 2009 14:14:00 +0000	[thread overview]
Message-ID: <1236608040.16880.1580.camel@cookie.hadess.net> (raw)
In-Reply-To: <2d5a2c100903090608kd4ffea6sd9b1746e2362bf2@mail.gmail.com>

On Mon, 2009-03-09 at 10:08 -0300, Luiz Augusto von Dentz wrote:
> Hi Bastien,
> 
> On Sun, Mar 8, 2009 at 11:46 AM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Fri, 2009-03-06 at 01:00 +0000, Bastien Nocera wrote:
> >> Heya,
> >>
> > <snip>
> >> The first 2 chars in the IEEE1284 ID are supposed to be the length of
> >> the string. This should enable me to make the CUPS backend's discovery
> >> work again.
> >
> > This isn't quite enough it seems.
> >
> > >From DiscoverDevices on org.bluez.Device:
> >        <attribute id="0x0300">
> >                <text value="" />
> >        </attribute>
> >
> It may happen that bluetoothd and sdptool doesn't really share the sdp
> xml parsing code. So perhaps we need to replicated your fix on
> bluetoothd too or just make bluetoothd to use what you have done for
> sdptool.

Both use the code in common/sdp-xml.[ch] and convert_sdp_record_to_xml()
in particular, which is why it makes no sense to me...

I double-checked by adding some debug to convert_raw_data_to_xml() and
the string for the attribute I'm interested in is empty, so it must be a
problem parsing the raw data from the device, or there's something that
strips this value somewhere in bluetoothd...


  reply	other threads:[~2009-03-09 14:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-06  1:00 Broken SDP parsing? Bastien Nocera
2009-03-08 14:46 ` Bastien Nocera
2009-03-09 13:08   ` Luiz Augusto von Dentz
2009-03-09 14:14     ` Bastien Nocera [this message]
2009-03-09 14:32       ` Luiz Augusto von Dentz
2009-03-09 14:53         ` Luiz Augusto von Dentz
2009-03-09 15:25         ` Bastien Nocera
2009-03-09 16:40           ` Luiz Augusto von Dentz
2009-03-09 17:09             ` Bastien Nocera
2009-03-09 18:04               ` Johan Hedberg
2009-03-09 19:29                 ` Port CUPS discovery to BlueZ 4.x (Re: Broken SDP parsing?) Bastien Nocera
2009-03-13 15:37                 ` Broken SDP parsing? Bastien Nocera
2009-03-13 18:15                   ` Johan Hedberg
2009-03-14  0:39                     ` Bastien Nocera
2009-03-14 13:29                       ` Johan Hedberg

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=1236608040.16880.1580.camel@cookie.hadess.net \
    --to=hadess@hadess.net \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /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.