barry-devel — Development discussion mailing list

[Barry-devel] more ServiceBook parsing

[Chris F. <cd...@fo...>]

Hi,

I've committed some more code to CVS to parse the service book fields.  I've
tested this against a 72xx device and an 8700r, and the type codes for
similar fields are different.

I just noticed that the large "type 0x9" field has more variable length
fields inside it.  I'll have to parse that out as well.

- Chris

Re: [Barry-devel] Service Book parser

[Chris F. <cd...@fo...>]

On Fri, Jun 09, 2006 at 10:29:57PM -0400, Ron Gage wrote:
> I have partially decoded the Desktop[CICAL] Service Book:

It is interesting to compare the service book information that is available
from the blackberry itself, to what is seen on the protocol side.

For example, there are IP addresses and ports listed in the blackberry GUI
but this is nowhere to be seen in the hex dump data from btool.

I wonder if there is some cross referenced data from other databases.

- Chris

Re: [Barry-devel] Service Book parser

[Chris F. <cd...@fo...>]

On Fri, Jun 09, 2006 at 10:29:57PM -0400, Ron Gage wrote:
> Haven't had much chance to correlate this to all the Service Books yet - 
> it IS getting late here...
> 
> I have partially decoded the Desktop[CICAL] Service Book:

Thanks!

Btw, What is a DSID?


>         Type: 0xa3 Data:
>     00000000: 4e 00 00 00                                      N...
> Corresponds to User ID

Is this a string that you entered?  My test blackberry doesn't show this type.


>         Type: 0x6 Data:
>     00000000: 53 30 30 30 30 30 30 30                          S0000000
> Corresponds to UID - aka the SRP of the BES server

On my test device, this shows as "ff ff ff ff" in all records.


- Chris

Re: [Barry-devel] Service Book parser

[Ron G. <ro...@ro...>]

Chris Frey wrote:
> Hi,
>
> I've added a record class for Service Book to CVS.  Pleasantly, the service
> book records used the same CommonField structure as the Calendar.
>
> The basic structure is:
>
> 	packet header
> 	record header
> 	... then an array of CommonFields, each field having the following
> 	structure:
>
> 		Size of data (2 bytes)
> 		Type (1 byte)
> 		Data (variable length)
>
> The new CVS version of barry parses out all these fields and displays them
> individually.  The challenge now is to find out what each field is,
> and give names to the type codes.
>
> If you're following along in the code, see the protostructs.h header,
> where you'll find the CommonField struct, and the OldServiceBookRecord
> struct that definds the record header.
>
> Also, near the end of record.cc you'll see the new ServiceBook class
> functions.  There is an array where we can add type codes and names
> once they are each reverse engineered.  (Again, compare the new ServiceBook
> code to the Calendar class code above it to see how it will work.)
>
> Enjoy,
> - Chris
>
>
>
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel
>
>   
Haven't had much chance to correlate this to all the Service Books yet - 
it IS getting late here...

I have partially decoded the Desktop[CICAL] Service Book:

ServiceBook entry: 0xef32
    Unknowns:
        Type: 0xfa Data:
    00000000: 00 00 00 00                                      ....
Possibly corresponds to Record Type (Active/Inactive)

        Type: 0x1 Data:
    00000000: 44 65 73 6b 74 6f 70 00                          Desktop.
Corresponds to Name

        Type: 0xa1 Data:
    00000000: 34 66 39 63 34 39 00                             4f9c49.
Corresponds to DSID

        Type: 0xa3 Data:
    00000000: 4e 00 00 00                                      N...
Corresponds to User ID

        Type: 0x6 Data:
    00000000: 53 30 30 30 30 30 30 30                          S0000000
Corresponds to UID - aka the SRP of the BES server

        Type: 0x8 Data:
    00000000: 43 49 43 41 4c                                   CICAL
Corresponds to CID

        Type: 0x9 Data:
    00000000: 04 00 00 00 07 0e 01 00 60 02 00 01 00           ........`....
Unknown

        Type: 0xa Data:
    00000000: 02 00 00 00                                      ....
Unknown

        Type: 0xb Data:
    00000000: 02 00 00 00                                      ....
Unknown

        Type: 0xc Data:
    00000000: 30 46 46 44 33 39 39 39 45                       0FFD3999E
Unknown - possibly a crypt key index

        Type: 0x32 Data:
    00000000: 57 69 72 65 6c 65 73 73 20 43 61 6c 65 6e 64 61  Wireless 
Calenda
    00000010: 72 00                                            r.
Corresponds to Description

        Type: 0x2b Data:
    00000000: 01                                               .
Unknown - possible corresponds to Record Type

        Type: 0xa2 Data:
    00000000: 13 00 15 61 61 61 61 61 61 61 61 61 61 61 61 61  
...aaaaaaaaaaaaa
    00000010: 61 61 2e 63 6f 6d 04 00 14 05 10 00 00 00 00 00  
aa.com..........
Unknown - contains the FQDN of the BES server


-- 
Ron Gage - Westland, MI
(MCP, LPIC1, A+, Net+)
Custom Linux Software

Re: [Barry-devel] Segfault in latest cvs

[Ron G. <ro...@ro...>]

Chris Frey wrote:
> On Fri, Jun 09, 2006 at 09:33:16PM -0400, Ron Gage wrote:
>   
>> Hmm - multi-threaded huh.. fun...
>>
>> Here is the backtrace:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread -1210820928 (LWP 29840)]
>> 0xb7f0012b in std::operator<< <char, std::char_traits<char>, 
>> std::allocator<char> > () from /usr/lib/libstdc++.so.5
>>     
>
> It is only multi-threaded in libusb.  Barry itself uses no threads.
>
> If it is crashing in libstdc++, I'd suspect a library version issue.
> If you've upgraded any of the libraries Barry depends on, or the
> C++ compiler, please try rebuilding everything just to make sure.
>
> I've had cases where the compiler changed, and I had to rebuild Boost
> to get things to link properly.
>
> - Chris
>
>   
OK - I am a moron.  I had an include problem during the previous build 
and fixed it half way through the build (after it died).  The include 
pointed to a wrong dir.  My bad.  I apoligize!


>
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel
>
>   


-- 
Ron Gage - Westland, MI
(MCP, LPIC1, A+, Net+)
Custom Linux Software

[Barry-devel] Service Book parser

[Chris F. <cd...@fo...>]

Hi,

I've added a record class for Service Book to CVS.  Pleasantly, the service
book records used the same CommonField structure as the Calendar.

The basic structure is:

	packet header
	record header
	... then an array of CommonFields, each field having the following
	structure:

		Size of data (2 bytes)
		Type (1 byte)
		Data (variable length)

The new CVS version of barry parses out all these fields and displays them
individually.  The challenge now is to find out what each field is,
and give names to the type codes.

If you're following along in the code, see the protostructs.h header,
where you'll find the CommonField struct, and the OldServiceBookRecord
struct that definds the record header.

Also, near the end of record.cc you'll see the new ServiceBook class
functions.  There is an array where we can add type codes and names
once they are each reverse engineered.  (Again, compare the new ServiceBook
code to the Calendar class code above it to see how it will work.)

Enjoy,
- Chris

Re: [Barry-devel] Segfault in latest cvs

[Chris F. <cd...@fo...>]

On Fri, Jun 09, 2006 at 09:33:16PM -0400, Ron Gage wrote:
> Hmm - multi-threaded huh.. fun...
> 
> Here is the backtrace:
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1210820928 (LWP 29840)]
> 0xb7f0012b in std::operator<< <char, std::char_traits<char>, 
> std::allocator<char> > () from /usr/lib/libstdc++.so.5

It is only multi-threaded in libusb.  Barry itself uses no threads.

If it is crashing in libstdc++, I'd suspect a library version issue.
If you've upgraded any of the libraries Barry depends on, or the
C++ compiler, please try rebuilding everything just to make sure.

I've had cases where the compiler changed, and I had to rebuild Boost
to get things to link properly.

- Chris

[Barry-devel] Segfault in latest cvs

[Ron G. <ro...@ro...>]

Latest CVS build runnning on 2.6.15 - blackberry is a 7290...


root@port4:~/bb/barry/src# ./btool -t
libusb: setting debugging level to 9 (on)
libusb: [usb_os_init:879] found USB VFS at /proc/bus/usb
libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/001
libusb: [usbi_os_find_busses:450] skipping non bus dir devices
libusb: [create_new_device:558] found device 001 on /proc/bus/usb/001
libusb: [create_new_device:558] found device 006 on /proc/bus/usb/001
libusb: [create_new_device:558] found device 007 on /proc/bus/usb/001
libusb: [usbi_parse_interface:165] skipped 1 class/vendor specific 
interface descriptors
libusb: [create_new_device:558] found device 013 on /proc/bus/usb/001
libusb: [usbi_os_find_busses:469] found bus dir /proc/bus/usb/001
libusb: [usbi_os_find_busses:450] skipping non bus dir devices
libusb: [create_new_device:558] found device 001 on /proc/bus/usb/001
libusb: [create_new_device:558] found device 006 on /proc/bus/usb/001
libusb: [create_new_device:558] found device 007 on /proc/bus/usb/001
libusb: [usbi_parse_interface:165] skipped 1 class/vendor specific 
interface descriptors
libusb: [create_new_device:558] found device 013 on /proc/bus/usb/001
Blackberry devices found:
Device ID: 4. PIN: 2027477f
Database database:
Segmentation fault

Hmm - multi-threaded huh.. fun...

Here is the backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210820928 (LWP 29840)]
0xb7f0012b in std::operator<< <char, std::char_traits<char>, 
std::allocator<char> > () from /usr/lib/libstdc++.so.5


-- 
Ron Gage - Westland, MI
(MCP, LPIC1, A+, Net+)
Custom Linux Software

Re: [Barry-devel] patch for probe.cc - working with 2.6.14 and later.

[Chris F. <cd...@fo...>]

On Fri, Jun 09, 2006 at 09:07:29PM -0400, Ron Gage wrote:
> Chris Frey wrote:
> > Can you try checking out the CVS tree, and then applying this patch and
> > let me know if this fixes it for 2.6.14?
> >
> >   
> g++ -ansi -Wall -fno-strict-aliasing -I/usr/local/libusb/include  -g -M 
> *.cc > dep.mak
> In file included from btool.cc:22:
> barry.h:45:28: controllertmpl.h: No such file or directory
> make[2]: *** [dep] Error 1

Doh!   I've attached it, and it will be in CVS tonight.

Thanks!
- Chris

Re: [Barry-devel] patch for probe.cc - working with 2.6.14 and later.

[Ron G. <ro...@ro...>]

Chris Frey wrote:
> Can you try checking out the CVS tree, and then applying this patch and
> let me know if this fixes it for 2.6.14?
>
>   
g++ -ansi -Wall -fno-strict-aliasing -I/usr/local/libusb/include  -g -M 
*.cc > dep.mak
In file included from btool.cc:22:
barry.h:45:28: controllertmpl.h: No such file or directory
make[2]: *** [dep] Error 1


-- 
Ron Gage - Westland, MI
(MCP, LPIC1, A+, Net+)
Custom Linux Software

Re: [Barry-devel] patch for probe.cc - working with 2.6.14 and later.

[Chris F. <cd...@fo...>]

That controller patch works for 0.0.1 too, although you may have to
apply it by hand.  It's fairly simple.

- Chris

Re: [Barry-devel] patch for probe.cc - working with 2.6.14 and later.

[Chris F. <cd...@fo...>]

On Fri, Jun 09, 2006 at 08:19:05PM -0400, Ron Gage wrote:
> Chris had asked me to send him this - and to start posting to the 
> mailing list so others can laugh at me too!  :)

Thanks for the patch, and for joining the list!


> Anyhow, here is what I did to probe.cc to get it to work with kernels 
> 2.6.14 and higher (and probably some earlier ones too)...
> 
> diff -u probe.cc probe.cc~
> --- probe.cc    2006-06-08 19:29:05.000000000 -0400
> +++ probe.cc~   2006-06-08 19:29:05.000000000 -0400
> @@ -110,10 +110,11 @@
>                 dev.Reset();
>                 sleep(5);
> 
> +               Interface iface(dev, BLACKBERRY_INTERFACE);
> +
>                 if( !dev.SetConfiguration(BLACKBERRY_CONFIGURATION) )
>                         throw BError(dev.GetLastError(),
>                                 "Probe: SetConfiguration failed");
> -               Interface iface(dev, BLACKBERRY_INTERFACE);
> 
>                 Data data;
>                 Intro(0, dev, data);
> 

(If this was agaisnt version 0.0.1, the patch is backwards.  Just for
reference, diff usage is "diff -u oldfile newfile"   It's a very common
error.)

Fortunately, this is in CVS, but unfortunately I haven't released it yet,
so those still working with 0.0.1, this patch is for you.

I see the problem is also in controller.cc, as you mentioned earlier Ron.

Can you try checking out the CVS tree, and then applying this patch and
let me know if this fixes it for 2.6.14?

Thanks Ron,
- Chris


Index: controller.h
===================================================================
RCS file: /home/cvs/NetDirect/barry/src/controller.h,v
retrieving revision 1.7
diff -u -r1.7 controller.h
--- controller.h        1 Apr 2006 01:19:29 -0000       1.7
+++ controller.h        10 Jun 2006 00:47:36 -0000
@@ -70,7 +70,7 @@
 
 private:
        Usb::Device m_dev;
-       Usb::Interface m_iface;
+       Usb::Interface *m_iface;
        uint32_t m_pin;
 
        Socket m_socket;

Index: controller.cc
===================================================================
RCS file: /home/cvs/NetDirect/barry/src/controller.cc,v
retrieving revision 1.13
diff -u -r1.13 controller.cc
--- controller.cc       1 Apr 2006 01:22:51 -0000       1.13
+++ controller.cc       10 Jun 2006 00:47:38 -0000
@@ -48,7 +48,6 @@
 ///
 Controller::Controller(const ProbeResult &device)
        : m_dev(device.m_dev),
-       m_iface(m_dev, BLACKBERRY_INTERFACE),
        m_pin(device.m_pin),
        m_socket(m_dev, device.m_ep.write, device.m_ep.read),
        m_mode(Unspecified)
@@ -56,10 +55,13 @@
        if( !m_dev.SetConfiguration(BLACKBERRY_CONFIGURATION) )
                throw BError(m_dev.GetLastError(),
                        "Controller: SetConfiguration failed");
+
+       m_iface = new Usb::Interface(m_dev, BLACKBERRY_INTERFACE);
 }
 
 Controller::~Controller()
 {
+       delete m_iface;
 }

[Barry-devel] patch for probe.cc - working with 2.6.14 and later.

[Ron G. <ro...@ro...>]

Chris had asked me to send him this - and to start posting to the 
mailing list so others can laugh at me too!  :)

Anyhow, here is what I did to probe.cc to get it to work with kernels 
2.6.14 and higher (and probably some earlier ones too)...

diff -u probe.cc probe.cc~
--- probe.cc    2006-06-08 19:29:05.000000000 -0400
+++ probe.cc~   2006-06-08 19:29:05.000000000 -0400
@@ -110,10 +110,11 @@
                dev.Reset();
                sleep(5);

+               Interface iface(dev, BLACKBERRY_INTERFACE);
+
                if( !dev.SetConfiguration(BLACKBERRY_CONFIGURATION) )
                        throw BError(dev.GetLastError(),
                                "Probe: SetConfiguration failed");
-               Interface iface(dev, BLACKBERRY_INTERFACE);

                Data data;
                Intro(0, dev, data);


-- 
Ron Gage - Westland, MI
(MCP, LPIC1, A+, Net+)
Custom Linux Software

[Barry-devel] Re: autoconfiscating barry (take three)

[Chris F. <cd...@fo...>]

On Fri, May 19, 2006 at 12:43:43AM -0400, Peter McAlpine wrote:
> Linked to this email are my proposed changes which autoconfiscate the barry

Thanks for putting the time into this.  I do have some comments however:

In future, it's better to send a patch created with "diff -ruN" against
the current CVS, which contains all your changes.

Also, like the libusb project does, we don't need to include all the auto-
generated files in the final result.  Especially not in CVS.  I'll be
putting the ./configure script in the release tarballs of course, but
as programmers, we only want to work with the source.

Ideally, the configure script should support syntax like --with-libusb=...
so that libusb can be installed anywhere, and installed separately from
Barry.

I'll do the ChangeLog and TODO renaming in CVS.

The time.h rename is interesting.  Seems like a bug in automake to me.

What is the IOKit library?  Is this something you needed to make it work?

- Chris

[Barry-devel] Re: autoconfiscating barry (take three)

[Chris F. <cd...@fo...>]

On Fri, May 19, 2006 at 12:43:43AM -0400, Peter McAlpine wrote:
> Linked to this email are my proposed changes which autoconfiscate the barry
> project. There are three files:
> 1) A tarball of the barry source tree with my changes applied:
> http://www.aoeu.ca/barry/barry.autoconfiscated.tar.gz
> 2) A small patch (already applied in the tarball) which changes the
> files already within the barry source:
> http://www.aoeu.ca/barry/barry.autoconf.diff
> 3) Notes on how to go about turning a CVS checkout of barry into the
> autoconficated version (like the tarball):
> http://www.aoeu.ca/barry/barry.autoconf.notes
> 
> My changes include renaming a couple files:
> -The time.h rename was to account for automake wanting to build
> everything with the -I. flag.
> -Todo was renamed to TODO (convention).
> -Changelog becomes ChangeLog (convention, and automake requires it).

Thanks very much.  I'll try to take a look at this soon.


> The design choice I wrestled with most was the inclusion of libusb
> within the barry source. I (and others, as the mailing list archives
> attest) had trouble getting barry built against a more recent version
> of libusb. Eventually this should change, but given barry's alpha
> state I figured it was ok for now.

I'd like to keep Barry and libusb separate.

I only discovered today that libusb had switched over to SVN instead
of CVS, so I was a little out of touch there for a while.  Plus I
got kinda busy with other projects that took priority.

Libusb's latest SVN tree compiled successfully by itself, which is better
luck than I had with the older CVS just a few months ago.  My plan is to
update Barry to use the new libusb API and do some testing.

It would be great if Barry didn't need a special libusb version.


> (This is my third post of this email... the first one got canned
> because I sent it from a non-member address, the second was because my
> attached files were larger than the threshold allowed by sf.net. Sorry
> about any confusion.)

No worries.

Thanks,
- Chris

[Barry-devel] autoconfiscating barry (take three)

[Peter M. <pet...@gm...>]

Linked to this email are my proposed changes which autoconfiscate the barry
project. There are three files:
1) A tarball of the barry source tree with my changes applied:
http://www.aoeu.ca/barry/barry.autoconfiscated.tar.gz
2) A small patch (already applied in the tarball) which changes the
files already within the barry source:
http://www.aoeu.ca/barry/barry.autoconf.diff
3) Notes on how to go about turning a CVS checkout of barry into the
autoconficated version (like the tarball):
http://www.aoeu.ca/barry/barry.autoconf.notes

My changes include renaming a couple files:
-The time.h rename was to account for automake wanting to build
everything with the -I. flag.
-Todo was renamed to TODO (convention).
-Changelog becomes ChangeLog (convention, and automake requires it).

The design choice I wrestled with most was the inclusion of libusb
within the barry source. I (and others, as the mailing list archives
attest) had trouble getting barry built against a more recent version
of libusb. Eventually this should change, but given barry's alpha
state I figured it was ok for now.

Please let me know what you think. I'm very interested in seeing this
project succeed.

-Peter

(This is my third post of this email... the first one got canned
because I sent it from a non-member address, the second was because my
attached files were larger than the threshold allowed by sf.net. Sorry
about any confusion.)

Re: [Barry-devel] Re: Endpoint discovery

[Steve Paras-C. <st...@fa...>]

Ok, will do.  Thanks!
Steve

Quoting Chris Frey <cd...@fo...>:

> On Sat, Dec 31, 2005 at 06:11:42PM -0500, Chris Frey wrote:
> > On Sat, Dec 31, 2005 at 02:30:40PM -0800, Steve Paras-Charlton wrote:
> > > Seems I'm wrong again :)
> > >
> > > The match() function isn't returning a match.  I updated libusb from
> DEVEL head
> > > yesterday, but perhaps something changed between your update and mine,
> Chris.
> > > Can you give me a tag/date to update from to get this working again?
> >
> > That's interesting, the match code didn't change in Barry.
> >
> > You can edit src/debug.h, and uncomment the dout() macro (and comment out
> the
> > dummy macro) for more verbose output.  That level got a little verbose when
> > things were working, so I left it off.
> >
> > I'll take a closer look at the match() calls...
>
> Stick with the 2005/11/26 libusb tree (you can grab the tarball on the
> Barry download site if you need).
>
> The latest V1_0_DEVEL libusb tree is still a little buggy. :-(
>
> - Chris
>
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Barry-devel] Re: Endpoint discovery

[Chris F. <cd...@fo...>]

On Sat, Dec 31, 2005 at 06:11:42PM -0500, Chris Frey wrote:
> On Sat, Dec 31, 2005 at 02:30:40PM -0800, Steve Paras-Charlton wrote:
> > Seems I'm wrong again :)
> > 
> > The match() function isn't returning a match.  I updated libusb from DEVEL head
> > yesterday, but perhaps something changed between your update and mine, Chris. 
> > Can you give me a tag/date to update from to get this working again?
> 
> That's interesting, the match code didn't change in Barry.
> 
> You can edit src/debug.h, and uncomment the dout() macro (and comment out the
> dummy macro) for more verbose output.  That level got a little verbose when
> things were working, so I left it off.
> 
> I'll take a closer look at the match() calls...

Stick with the 2005/11/26 libusb tree (you can grab the tarball on the
Barry download site if you need).

The latest V1_0_DEVEL libusb tree is still a little buggy. :-(

- Chris

[Barry-devel] Re: Endpoint discovery

[Chris F. <cd...@fo...>]

On Sun, Jan 01, 2006 at 01:07:31PM -0800, Steve Paras-Charlton wrote:
> I didn't get any further debug by addidng that macro, I think it's because I'm
> mostly in the libusb code at this point.  I tried assigning the VENDOR and
> PRODUCT as -1 to allow matching any device (if I'm reading the libusb code
> properly) and it still didn't seem to match my device.  I don't know if this is
> an issue in libusb or barry at this point.  I suppose I could skip the
> usbwrapper stuff and try accessing the libusb match funciont directly to see if
> that makes a difference...

I don't have access to a Blackberry to test with at the moment.  It could be
the new libusb.  If you want to go back to the old libusb from 2005/11/26
that we know worked, apply the following patch.

This just reverts the changes needed to use the latest DEVEL libusb.

- Chris



diff -u barry/src/usbwrap.h:1.10 barry/src/usbwrap.h:1.9
--- barry/src/usbwrap.h:1.10	Fri Dec 30 17:39:35 2005
+++ barry/src/usbwrap.h	Fri Dec 30 15:58:27 2005
@@ -51,7 +51,7 @@
 
 class Match
 {
-	libusb_match_handle_t m_match;
+	libusb_match_handle_t *m_match;
 	int m_lasterror;
 public:
 	Match(int vendor, int product)
@@ -164,7 +164,7 @@
 
 private:
 	libusb_device_id_t m_id;
-	libusb_dev_handle_t m_handle;
+	libusb_dev_handle_t *m_handle;
 
 	io_list_type m_ios;
 
@@ -189,7 +189,7 @@
 	// Data access
 
 	libusb_device_id_t GetID() const { return m_id; }
-	libusb_dev_handle_t GetHandle() const { return m_handle; }
+	libusb_dev_handle_t * GetHandle() const { return m_handle; }
 	int GetLastError() const { return m_lasterror; }
 
 

Re: [Barry-devel] Re: Endpoint discovery

[Steve Paras-C. <st...@fa...>]

I didn't get any further debug by addidng that macro, I think it's because I'm
mostly in the libusb code at this point.  I tried assigning the VENDOR and
PRODUCT as -1 to allow matching any device (if I'm reading the libusb code
properly) and it still didn't seem to match my device.  I don't know if this is
an issue in libusb or barry at this point.  I suppose I could skip the
usbwrapper stuff and try accessing the libusb match funciont directly to see if
that makes a difference...

Steve

Quoting Chris Frey <cd...@fo...>:

> On Sat, Dec 31, 2005 at 02:30:40PM -0800, Steve Paras-Charlton wrote:
> > Seems I'm wrong again :)
> >
> > The match() function isn't returning a match.  I updated libusb from DEVEL
> head
> > yesterday, but perhaps something changed between your update and mine,
> Chris.
> > Can you give me a tag/date to update from to get this working again?
>
> That's interesting, the match code didn't change in Barry.
>
> You can edit src/debug.h, and uncomment the dout() macro (and comment out the
> dummy macro) for more verbose output.  That level got a little verbose when
> things were working, so I left it off.
>
> I'll take a closer look at the match() calls...
>
> - Chris
>
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Barry-devel] Re: Endpoint discovery

[Chris F. <cd...@fo...>]

On Sat, Dec 31, 2005 at 02:30:40PM -0800, Steve Paras-Charlton wrote:
> Seems I'm wrong again :)
> 
> The match() function isn't returning a match.  I updated libusb from DEVEL head
> yesterday, but perhaps something changed between your update and mine, Chris. 
> Can you give me a tag/date to update from to get this working again?

That's interesting, the match code didn't change in Barry.

You can edit src/debug.h, and uncomment the dout() macro (and comment out the
dummy macro) for more verbose output.  That level got a little verbose when
things were working, so I left it off.

I'll take a closer look at the match() calls...

- Chris

Re: [Barry-devel] Endpoint discovery

[Steve Paras-C. <st...@fa...>]

Seems I'm wrong again :)

The match() function isn't returning a match.  I updated libusb from DEVEL head
yesterday, but perhaps something changed between your update and mine, Chris. 
Can you give me a tag/date to update from to get this working again?

Steve

Quoting Steve Paras-Charlton <st...@fa...>:

>
> Endpoint discovery on my device is not working well.  There doesn't seem to
> be
> verbose output in the endpoint discovery code, so I'll try to insert some and
> see what wrong.  Here's some output to chew on for now...
>
> Steve
>
>
> root@yu:/usr/src/barry/src # ./btool -v -l
> libusb: setting debugging level to 9 (on)
> libusb: [usb_os_init:895] found USB VFS at /proc/bus/usb
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/007
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/006
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/005
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/004
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/003
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/002
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/001
> libusb: [usbi_os_find_busses:466] skipping non bus dir devices
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/007
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/006
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/005
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/004
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/003
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/002
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/001
> libusb: [usbi_os_find_busses:466] skipping non bus dir devices
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/007
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/006
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/005
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/004
> libusb: [create_new_device:574] found device 006 on /proc/bus/usb/004
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/003
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/002
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/001
> Blackberry devices found:
> root@yu:/usr/src/barry/src #
>
> root@yu:/usr/src/barry/src # ./btool -d 'Address Book' -f adb.out
> libusb: setting debugging level to 9 (on)
> libusb: [usb_os_init:895] found USB VFS at /proc/bus/usb
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/007
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/006
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/005
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/004
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/003
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/002
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/001
> libusb: [usbi_os_find_busses:466] skipping non bus dir devices
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/007
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/006
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/005
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/004
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/003
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/002
> libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/001
> libusb: [usbi_os_find_busses:466] skipping non bus dir devices
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/007
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/006
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/005
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/004
> libusb: [create_new_device:574] found device 006 on /proc/bus/usb/004
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/003
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/002
> libusb: [create_new_device:574] found device 001 on /proc/bus/usb/001
> Blackberry devices found:
> No device selected
> root@yu:/usr/src/barry/src #
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Barry-devel] Endpoint discovery

[Steve Paras-C. <st...@fa...>]

Endpoint discovery on my device is not working well.  There doesn't seem to be
verbose output in the endpoint discovery code, so I'll try to insert some and
see what wrong.  Here's some output to chew on for now...

Steve


root@yu:/usr/src/barry/src # ./btool -v -l
libusb: setting debugging level to 9 (on)
libusb: [usb_os_init:895] found USB VFS at /proc/bus/usb
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/007
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/006
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/005
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/004
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/003
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/002
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/001
libusb: [usbi_os_find_busses:466] skipping non bus dir devices
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/007
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/006
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/005
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/004
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/003
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/002
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/001
libusb: [usbi_os_find_busses:466] skipping non bus dir devices
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/007
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/006
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/005
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/004
libusb: [create_new_device:574] found device 006 on /proc/bus/usb/004
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/003
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/002
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/001
Blackberry devices found:
root@yu:/usr/src/barry/src #

root@yu:/usr/src/barry/src # ./btool -d 'Address Book' -f adb.out
libusb: setting debugging level to 9 (on)
libusb: [usb_os_init:895] found USB VFS at /proc/bus/usb
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/007
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/006
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/005
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/004
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/003
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/002
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/001
libusb: [usbi_os_find_busses:466] skipping non bus dir devices
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/007
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/006
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/005
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/004
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/003
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/002
libusb: [usbi_os_find_busses:485] found bus dir /proc/bus/usb/001
libusb: [usbi_os_find_busses:466] skipping non bus dir devices
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/007
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/006
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/005
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/004
libusb: [create_new_device:574] found device 006 on /proc/bus/usb/004
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/003
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/002
libusb: [create_new_device:574] found device 001 on /proc/bus/usb/001
Blackberry devices found:
No device selected
root@yu:/usr/src/barry/src #


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

[Barry-devel] Re: CVS - 2005/12/30

[Chris F. <cd...@fo...>]

On Fri, Dec 30, 2005 at 09:49:59PM -0800, Steve Paras-Charlton wrote:
> Sounds great!  I'm having some difficulties with CVS, though...
> 
> root@yu:/usr/src #  cvs -d:pserver:ano...@cv...:/cvsroot/barry
> login
> Logging in to :pserver:ano...@cv...:2401/cvsroot/barry
> CVS password:
> cvs [login aborted]: end of file from server (consult above messages if any)
> 
> I'll try again in the morning in case it's a transient problem...

Yeah, I get those errors a lot when using SourceForge's anonymous access,
unfortunately.  It is nearly always a transient problem, but sometimes I
have to retry up to 20 times or so.

I find the Web CVS access much more reliable, but that isn't very handy for
downloading code to compile.  It works great though for reading code. :-)

- Chris

Re: [Barry-devel] CVS - 2005/12/30

[Steve Paras-C. <st...@fa...>]

Might be my cvs, as it worked when I turned on tracing (-t).

Building latest tree with glee!

Steve

Quoting Steve Paras-Charlton <st...@fa...>:

> Sounds great!  I'm having some difficulties with CVS, though...
>
> root@yu:/usr/src #  cvs
> -d:pserver:ano...@cv...:/cvsroot/barry
> login
> Logging in to :pserver:ano...@cv...:2401/cvsroot/barry
> CVS password:
> cvs [login aborted]: end of file from server (consult above messages if any)
>
> I'll try again in the morning in case it's a transient problem...
>
> Steve
>
> Quoting Chris Frey <cd...@fo...>:
>
> > Hi,
> >
> > Here's a brief update for the folks following the CVS tree.
> >
> > The latest Barry CVS tree contains:
> >
> > 	- Important!  Updated to latest libusb V1_0_DEVEL CVS tree
> > 		(as of 2005/12/30)
> >
> > 	- basic support for uploading contacts and calendar records
> > 		(incomplete)
> >
> > 	- compiler fixes for g++ 4.0.x
> >
> > 	- fix in probe.cc for Ron Gage's "device or resource busy" error...
> > 		Ron will have to test this, since I haven't see the same error
> >
> > 	- probe.cc now does dynamic discovery of endpoints
> >
> > 	- optional dependency on Boost, using the serialization library
> > 		Be sure to update your Makefile.conf files, even if just to
> > 		turn off Boost support.  If you don't include Boost, you
> > 		won't be able to experiment with upload very easily.
> >
> > Enjoy, and Happy New Year,
> > - Chris
> >
> >
> >
> > -------------------------------------------------------
> > 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
> > _______________________________________________
> > Barry-devel mailing list
> > Bar...@li...
> > https://lists.sourceforge.net/lists/listinfo/barry-devel
> >
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel
>




----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.