barry-devel — Development discussion mailing list

Re: [Barry-devel] upldif hangs

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

On Tue, Feb 19, 2013 at 07:09:59PM +0100, YuGiOhJCJ Mailing-List wrote:
> > This is what happened when I try to dump my contacts with upldif:
> > "$ sudo upldif -v
> > 
> > "
> > The program hangs.
> > My objective is to dump my contact list from the SIM card.

Some clarification.  The upldif program is a tool meant to *write* to
your BlackBerry.  Since it has the potential of deleting all your
contacts and then writing what you give it, it does not actually
upload by default.  You have to explicitly give it the -u option.

If you want to *read* data from your blackberry, you want other tools,
such as btool, or bio.




> I found a way to dump my contact list from the SIM card using the btool program instead of the upldif program:
> $ btool -c dn > file.txt
> (in fact, it can't be done directly, I need before this to go in my BlackBerry menu to copy my contact list from the SIM to the phone)
> Then I can upload it using the upldif program:
> $ upldif -u < file.txt

I'm not aware of any direct access to the SIM card, but I haven't looked
too closely either.  If it doesn't show up by default in Address Book,
then it would either be in some other database (btool -t) or it may always
require the "copy from SIM" operation first.


> But if I read the help of the upldif program I can see that it should be able to dump my contact list:
> "$ upldif -h
>  -u        Do the upload.  If not specified, only dumps parsed
>              LDIF data to stdout.
> "
> So, I think the behaviour of the upldif program is not the expected behaviour.

Since upldif reads LDIF data on stdin, for safety's sake, it writes what
it thinks it just read to stdout for verification, and it writes it in
BlackBerry record style.  This way you can feed in your ldif data, and make
sure that upldif is parsing your data correctly (by viewing stdout) before
using the -u to blow away your existing contacts and upload.



> Is there a way to copy the contact list from/to the SIM directly ?

Not that I know of.


> Can you correct the behaviour of the upldif program to be the expected behaviour ?

Perhaps I can clarify the man page.  upldif is not for reading, but for writing.

Thanks!
- Chris

Re: [Barry-devel] upldif hangs

[YuGiOhJCJ Mailing-L. <yug...@la...>]

On Tue, 19 Feb 2013 17:54:03 +0100
YuGiOhJCJ Mailing-List <yug...@la...> wrote:

> Hello,
> 
> This is what happened when I try to dump my contacts with upldif:
> "$ sudo upldif -v
> 
> "
> The program hangs.
> My objective is to dump my contact list from the SIM card.
> 
> I have a BlackBerry 8900 Curve.
> And other Barry Project programs work correctly with it:
> $ bjavaloader 
> missing command
> bjavaloader - Command line USB Blackberry Java Loader
>         Copyright 2008-2009, Nicolas VIVIEN.
>         Copyright 2005-2012, Net Direct Inc. (http://www.netdirect.ca/)
>         Using: Barry library version 0.18.3 (little endian)
> $ sudo bjavaloader deviceinfo
> Hardware Id:     0x84001503
> PIN:             0x2625c92e
> OS Version:      0.0.0.0
> VM Version:      4.6.1.133
> Radio ID:        0x0
> Vendor ID:       302
> [...]
> 
> Is it me who use incorrectly the upldif program or a bug ?
> 

I found a way to dump my contact list from the SIM card using the btool program instead of the upldif program:
$ btool -c dn > file.txt
(in fact, it can't be done directly, I need before this to go in my BlackBerry menu to copy my contact list from the SIM to the phone)
Then I can upload it using the upldif program:
$ upldif -u < file.txt

But if I read the help of the upldif program I can see that it should be able to dump my contact list:
"$ upldif -h
 -u        Do the upload.  If not specified, only dumps parsed
             LDIF data to stdout.
"
So, I think the behaviour of the upldif program is not the expected behaviour.

Is there a way to copy the contact list from/to the SIM directly ?
Can you correct the behaviour of the upldif program to be the expected behaviour ?

Thank you.
Regards.

[Barry-devel] upldif hangs

[YuGiOhJCJ Mailing-L. <yug...@la...>]

Hello,

This is what happened when I try to dump my contacts with upldif:
"$ sudo upldif -v

"
The program hangs.
My objective is to dump my contact list from the SIM card.

I have a BlackBerry 8900 Curve.
And other Barry Project programs work correctly with it:
$ bjavaloader 
missing command
bjavaloader - Command line USB Blackberry Java Loader
        Copyright 2008-2009, Nicolas VIVIEN.
        Copyright 2005-2012, Net Direct Inc. (http://www.netdirect.ca/)
        Using: Barry library version 0.18.3 (little endian)
$ sudo bjavaloader deviceinfo
Hardware Id:     0x84001503
PIN:             0x2625c92e
OS Version:      0.0.0.0
VM Version:      4.6.1.133
Radio ID:        0x0
Vendor ID:       302
[...]

Is it me who use incorrectly the upldif program or a bug ?

Thank you.
Regards.

Re: [Barry-devel] Barry Install Ubuntu 12.04

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

On Tue, Feb 05, 2013 at 12:03:00AM -0600, David P. Jessup wrote:
> Greetings everyone,
> 
> I have attempted to install Barry on Ubuntu 12.04 and this is the error 
> I am getting:
> 
>    Failed to fetch
>    http://download.barry.netdirect.ca/barry-0.18.3//dists/ubuntu1204/main/binary-amd64/libtar0_1.2.16-1_amd64.deb
>    Got a single header line over 360 chars
> 
> If you can see anything that I am missing that could help with 
> installing I would appreciate it.

Hi David,

This is a known problem with the sourceforge.net site.  They have a
particular header which causes certain versions of apt-get to choke
due to the length.

I've opened a ticket on sourceforge to address this, but so far it has
not gotten a lot of attention.

You can work around it by pre-downloading all the files from the ubuntu1204
barry sourceforge page into your /var/cache/apt/archives directory.
Then apt won't have to download them from sourceforge, and you can still
benefit from the automatic dependency resolution.

Looks like sourceforge is experiencing HTTP 500 errors right now, so I
can't point you to the right URLs. :-(

In the long term, apt-get has been fixed to handle longer header lines,
so hopefully in future versions of Ubuntu this will not be a problem

Let me know if you still have trouble downloading (after sourceforge
comes back from their issues) :-)

- Chris

[Barry-devel] Barry Install Ubuntu 12.04

[David P. J. <dpj...@gm...>]

Greetings everyone,

I have attempted to install Barry on Ubuntu 12.04 and this is the error 
I am getting:

    Failed to fetch
    http://download.barry.netdirect.ca/barry-0.18.3//dists/ubuntu1204/main/binary-amd64/libtar0_1.2.16-1_amd64.deb
    Got a single header line over 360 chars

If you can see anything that I am missing that could help with 
installing I would appreciate it.

BB-Soldier

Re: [Barry-devel] postalAddress corrupt on read from BB9700

[John S. <jo...@st...>]

>>>>> "Matthew" == Matthew Ernisse <mer...@ub...> writes:

Matthew> On Wed, Jan 30, 2013 at 10:52:57PM -0500, John Stoffel said unto me:
>> Anyway, So I got the newest version from git, which reports itself as
>> 0.18.4 and tried again using btool and I get the output corrupted as
>> well.  I've appended the output of one record when using the -v
>> option.  I generated it like this:

Matthew> [ snip ]

>> 00000240: 33 31 32 30 20 48 69 67 68 77 6f 6f 64 73 20 42  3120 Highwoods B
>> 00000250: 6c 76 64 00 0a 00 24 53 75 69 74 65 20 31 30 38  lvd...$Suite 108
>> 00000260: 00 08 00 26 52 61 6c 65 69 67 68 00 03 00 27 4e  ...&Raleigh...'N
>> 00000270: 43 00 06 00 28 32 37 36 30 34 00                 C...(27604.

Matthew> [ snip ]

>> postalAddress:: MzEyMCBIaWdod29vZHMgQmx2ZApTdWl0ZSAxMDgKUmFsZWlnaCBOQyAKMjc2MDQ=
>> postalCode: 27604
>> sn: Adman
>> st: NC
>> street: 3120 Highwoods Blvd

Matthew> In LDIF the :: at the end of the object name means the value is base64 
Matthew> encoded (often you'll see this for things like multi-line fields).  If 
Matthew> I decode the postalAddress value, I get:

Matthew> ---
Matthew> 09:47:43@apollo (3566) ~ >echo "MzEyMCBIaWdod29vZHMgQmx2ZApTdWl0ZSAxMDgKUmFsZWlnaCBOQyAKMjc2MDQ=" | base64 -d
Matthew> 3120 Highwoods Blvd
Matthew> Suite 108
Matthew> Raleigh NC 
Matthew> ---

Matthew> Which looks right from the raw output.

Ah ok, that makes sense then.  So when I tried to use '2vcard' to
parse this LDIF output to get vCard formated data, it bombed on this
info.  Sigh... time to start hacking the perl script.

Or can I just import the LDIF data into outlook?  Time to try....

John

Re: [Barry-devel] postalAddress corrupt on read from BB9700

[Matthew E. <mer...@ub...>]

On Wed, Jan 30, 2013 at 10:52:57PM -0500, John Stoffel said unto me:
> Anyway, So I got the newest version from git, which reports itself as
> 0.18.4 and tried again using btool and I get the output corrupted as
> well.  I've appended the output of one record when using the -v
> option.  I generated it like this:

[ snip ]

>     00000240: 33 31 32 30 20 48 69 67 68 77 6f 6f 64 73 20 42  3120 Highwoods B
>     00000250: 6c 76 64 00 0a 00 24 53 75 69 74 65 20 31 30 38  lvd...$Suite 108
>     00000260: 00 08 00 26 52 61 6c 65 69 67 68 00 03 00 27 4e  ...&Raleigh...'N
>     00000270: 43 00 06 00 28 32 37 36 30 34 00                 C...(27604.

[ snip ]

> postalAddress:: MzEyMCBIaWdod29vZHMgQmx2ZApTdWl0ZSAxMDgKUmFsZWlnaCBOQyAKMjc2MDQ=
> postalCode: 27604
> sn: Adman
> st: NC
> street: 3120 Highwoods Blvd

In LDIF the :: at the end of the object name means the value is base64 
encoded (often you'll see this for things like multi-line fields).  If 
I decode the postalAddress value, I get:

---
09:47:43@apollo (3566) ~ >echo "MzEyMCBIaWdod29vZHMgQmx2ZApTdWl0ZSAxMDgKUmFsZWlnaCBOQyAKMjc2MDQ=" | base64 -d
3120 Highwoods Blvd
Suite 108
Raleigh NC 
---

Which looks right from the raw output.

--Matt

-- 
Matthew Ernisse
E-Mail: mer...@ub...
Web: http://www.ub3rgeek.net/                   PGP Key ID: 0x4AE6BF32

[Barry-devel] postalAddress corrupt on read from BB9700

[John S. <jo...@st...>]

Hi all,

I'm trying to extract my Contacts from a BB Bold 9700 running 6.0
Bundle 2342 (v6.0.0.526, Platform 6.6.0.195).  I'm running on Ubuntu
12.04 using barry 0.15 from the repositories.  This is a test BB I'm
using, since my main BB has a strange contacts corruption, with two
seperate categories of "Unknown".  Completely annoying.

Anyway, So I got the newest version from git, which reports itself as
0.18.4 and tried again using btool and I get the output corrupted as
well.  I've appended the output of one record when using the -v
option.  I generated it like this:

  > barry/tools/btool -v -c 'Address Book - All' > contacts-2013-01-30.ldif.0.18.4

All I want is to get this into vCard format so I can import them into
Exchange and push them back out to my BB in a clean way.  Any suggestions?

Thanks,
John


BulkWrite to endpoint 0x2:
    00000000: 06 00 07 00 41 00 00                             ....A..

Socket::Receive: Endpoint 2
Received:
    00000000: 00 00 0c 00 13 06 01 00 21 00 00 00              ........!...

Socket::Receive: Endpoint 2
Received:
    00000000: 06 00 04 04 60 01 44 00 1c 00 19 4c 4a 26 01 08  ....`.D....LJ&..
    00000010: 00 20 4d 69 63 68 65 6c 65 00 06 00 20 41 64 6d  . Michele... Adm
    00000020: 61 6e 00 05 00 21 54 41 45 43 00 b4 05 4d ff d8  an...!TAEC...M..
    00000030: ff db 00 84 00 08 06 06 07 06 05 08 07 07 07 09  ................
    00000040: 09 08 0a 0c 14 0d 0c 0b 0b 0c 19 12 13 0f 14 1d  ................
    00000050: 1a 1f 1e 1d 1a 1c 1c 20 24 2e 27 20 22 2c 23 1c  ....... $.' ",#.
    00000060: 1c 28 37 29 2c 30 31 34 34 34 1f 27 39 3d 38 32  .(7),01444.'9=82
    00000070: 3c 2e 33 34 32 01 09 09 09 0c 0b 0c 18 0d 0d 18  <.342...........
    00000080: 32 21 1c 21 32 32 32 32 32 32 32 32 32 32 32 32  2!.!222222222222
    00000090: 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32  2222222222222222
    000000a0: 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32 32  2222222222222222
    000000b0: 32 32 32 32 32 32 ff c4 01 a2 00 00 01 05 01 01  222222..........
    000000c0: 01 01 01 01 00 00 00 00 00 00 00 00 01 02 03 04  ................
    000000d0: 05 06 07 08 09 0a 0b 01 00 03 01 01 01 01 01 01  ................
    000000e0: 01 01 01 00 00 00 00 00 00 01 02 03 04 05 06 07  ................
    000000f0: 08 09 0a 0b 10 00 02 01 03 03 02 04 03 05 05 04  ................
    00000100: 04 00 00 01 7d 01 02 03 00 04 11 05 12 21 31 41  ....}........!1A
    00000110: 06 13 51 61 07 22 71 14 32 81 91 a1 08 23 42 b1  ..Qa."q.2....#B.
    00000120: c1 15 52 d1 f0 24 33 62 72 82 09 0a 16 17 18 19  ..R..$3br.......
    00000130: 1a 25 26 27 28 29 2a 34 35 36 37 38 39 3a 43 44  .%&'()*456789:CD
    00000140: 45 46 47 48 49 4a 53 54 55 56 57 58 59 5a 63 64  EFGHIJSTUVWXYZcd
    00000150: 65 66 67 68 69 6a 73 74 75 76 77 78 79 7a 83 84  efghijstuvwxyz..
    00000160: 85 86 87 88 89 8a 92 93 94 95 96 97 98 99 9a a2  ................
    00000170: a3 a4 a5 a6 a7 a8 a9 aa b2 b3 b4 b5 b6 b7 b8 b9  ................
    00000180: ba c2 c3 c4 c5 c6 c7 c8 c9 ca d2 d3 d4 d5 d6 d7  ................
    00000190: d8 d9 da e1 e2 e3 e4 e5 e6 e7 e8 e9 ea f1 f2 f3  ................
    000001a0: f4 f5 f6 f7 f8 f9 fa 11 00 02 01 02 04 04 03 04  ................
    000001b0: 07 05 04 04 00 01 02 77 00 01 02 03 11 04 05 21  .......w.......!
    000001c0: 31 06 12 41 51 07 61 71 13 22 32 81 08 14 42 91  1..AQ.aq."2...B.
    000001d0: a1 b1 c1 09 23 33 52 f0 15 62 72 d1 0a 16 24 34  ....#3R..br...$4
    000001e0: e1 25 f1 17 18 19 1a 26 27 28 29 2a 35 36 37 38  .%.....&'()*5678
    000001f0: 39 3a 43 44 45 46 47 48 49 4a 53 54 55 56 57 58  9:CDEFGHIJSTUVWX
    00000200: 59 5a 63 64 65 66 67 68 69 6a 73 74 75 76 77 78  YZcdefghijstuvwx
    00000210: 79 7a 82 83 84 85 86 87 88 89 8a 92 93 94 95 96  yz..............
    00000220: 97 98 99 9a a2 a3 a4 a5 a6 a7 a8 a9 aa b2 b3 b4  ................
    00000230: b5 b6 b7 b8 b9 ba c2 c3 c4 c5 c6 c7 c8 c9 ca d2  ................
    00000240: d3 d4 d5 d6 d7 d8 d9 da e2 e3 e4 e5 e6 e7 e8 e9  ................
    00000250: ea f2 f3 f4 f5 f6 f7 f8 f9 fa ff c0 00 11 08 00  ................
    00000260: 60 00 48 03 01 11 00 02 11 01 03 11 01 ff da 00  `.H.............
    00000270: 0c 03 01 00 02 11 03 11 00 3f 00 e2 9d 86 2b 05  .........?....+.
    00000280: 6e 84 5a e4 2c 46 7a d5 34 ac 1c b6 dc 6b 6d 22  n.Z.,Fz.4....km"
    00000290: a5 30 69 5c 44 23 b1 a0 34 7b 12 67 8a 95 a3 b1  .0i\D#..4{.g....
    000002a0: 49 db 46 2e 79 a7 e4 1c af b8 c9 0e 05 17 be 83  I.F.y...........
    000002b0: d3 a9 4d 9b 93 5a ec 44 86 82 31 83 4b 42 53 ee  ..M..Z.D..1.KBS.
    000002c0: 5d de 4d 4b 49 31 de c8 61 34 f7 43 bf 41 ac 71  ].MKI1..a4.C.A.q
    000002d0: 49 6e 1a bd 1e c0 99 15 4e d7 12 d0 97 38 e6 b3  In......N....8..
    000002e0: 72 5d 06 da 4c 50 7b 8e b4 b6 2d 34 b6 23 91 b2  r]..LP{...-4.#..
    000002f0: 39 a4 97 52 6e a4 ca 65 b0 4d 6f 17 74 1b 68 86  9..Rn..e.Mo.t.h.
    00000300: 16 c9 eb 4d ab 19 fa 9b 22 d2 43 d1 6b 0e 65 d4  ...M....".C.k.e.
    00000310: d5 6b a3 10 d9 49 d7 6d 38 b4 f4 42 94 34 03 62  .k...I.m8..B.4.b
    00000320: e4 7a 51 cf 1b d8 ab 68 02 cd 87 5a 39 af b0 f9  .zQ....h...Z9...
    00000330: 7b 8a d6 ec 07 35 09 ab 89 6a 42 51 81 3e 95 a5  {....5...jBQ.>..
    00000340: d0 b6 d0 85 fa 13 9a 6a c2 4a 25 27 3c f5 ad 21  .......j.J%'<..!
    00000350: 15 6d 05 28 c6 da 0c fe 1e b4 f6 61 a5 8e c9 a7  .m.(.......a....
    00000360: 8d 7a 62 b8 74 b1 aa 49 6a 44 d7 71 8e 01 19 a9  .zb.t..IjD.q....
    00000370: b3 7b 0f a1 13 de 2f b5 54 60 d6 c0 92 b5 c8 5a  .{..../.T`.....Z
    00000380: f5 7d 7b 53 b3 17 4b 10 35 e8 61 d6 a9 c2 cd 58  .}{S..K.5.a....X
    00000390: 7c ca d6 20 7b b1 4f 95 b6 66 ac 57 79 c3 03 d2  |.. {.O..f.Wy...
    000003a0: b4 50 40 e1 67 72 a3 9f 9a ae 1e 44 35 ad c6 1e  .P@.gr.....D5...
    000003b0: 95 77 57 05 6b 1a 8d 33 9e fc d6 4a 29 ab a2 ae  .wW.k..3...J)...
    000003c0: 46 64 6f 5a 9e 5e e0 9b ea 35 9d aa b9 6d a8 e4  FdoZ.^...5...m..
    000003d0: ec b4 18 77 67 ad 1c 89 a0 d9 6a 30 e7 3c f4 a7  ...wg.....j0.<..
    000003e0: b1 09 5b 71 a4 1f ce a9 15 e8 34 d0 a2 2b da e3  ..[q......4..+..
    000003f0: 0f 4e 68 4b 51 34 c6 f5 38 cf e1 57 15 62 75 46  .NhKQ4..8..W.buF
    00000400: 91 1c f3 d6                                      ....

Socket::Receive: Endpoint 2
Received:
    00000000: 06 00 7b 02 40 01 b3 e9 a1 49 5f 71 b8 39 3d 73  ..{.@....I_q.9=s
    00000010: 52 da 63 4a e2 32 1c e7 14 d4 fa 03 4d 88 c8 4f  R.cJ.2......M..O
    00000020: 6a 4a 45 59 8d d8 79 e2 9f 3a 46 62 79 66 97 3b  jJEY..y..:Fbyf.;
    00000030: 1e bb 0d f2 8e 39 a4 e4 34 ad b8 d6 8b 8f e9 49  .....9..4......I
    00000040: 49 b6 1a ee 84 11 60 03 57 19 eb a8 d7 99 b5 e4  I.....`.W.......
    00000050: 8c f4 15 87 3a b5 8b b0 d3 17 38 c5 2b 83 43 4a  ....:.....8.+.CJ
    00000060: 0e 9d 69 a9 05 86 95 00 f4 a3 de 77 01 85 46 0d  ..i........w..F.
    00000070: 09 30 69 6c 34 af e5 4d 4c 12 63 4e 07 18 a7 76  .0il4..ML.cN...v
    00000080: d6 80 ef d0 66 28 8b 61 ae c3 48 e2 9e a8 2e cd  ....f(.a..H.....
    00000090: 62 47 38 ae 7b 15 d6 e3 09 cd 52 56 07 ab 18 c4  bG8.{.....RV....
    000000a0: 55 0a c9 0c 27 e9 49 37 d0 1e bb 11 f6 26 ab 99  U...'.I7.....&..
    000000b0: ec 84 90 cd dd 69 b8 df 71 25 71 86 a9 34 82 56  .....i..q%q..4.V
    000000c0: 10 9c 66 a2 ee fa 8e fd c6 55 4a 42 d9 1a 45 b9  ..f......UJB..E.
    000000d0: 35 96 c8 6a db 0d 2c 3d 45 38 d9 96 9a 5a 31 8c  5..j..,=E8...Z1.
    000000e0: e3 d6 92 ba 25 34 88 cb 82 38 aa 7a 07 9a 18 5d  ....%4...8.z...]
    000000f0: 71 d6 84 db 0d 08 cb 81 54 bc c5 a0 9e 62 f4 e9  q.......T....b..
    00000100: 4b cc 13 d4 61 90 0e 3d 69 c5 73 0a 4d 21 ad 20  K...a..=i.s.M!. 
    00000110: c5 2b a1 4b ba 2d 19 88 15 2a cf 72 ec 47 e7 72  .+.K.-...*.r.G.r
    00000120: 79 ab e5 d0 6f b8 c6 97 8e 2a 35 ea 26 b4 19 bc  y...o....*5.&...
    00000130: f3 5a a6 9a 13 8e 82 79 9c 52 6a db 05 f4 b0 dd  .Z.....y.Rj.....
    00000140: d9 e8 79 a7 f2 0b 5f 71 9b f3 d3 a7 ad 1c ab a8  ..y..._q........
    00000150: ec 96 83 49 ce 71 42 d3 66 29 24 34 92 29 f5 b1  ...I.qB.f)$4.)..
    00000160: 36 65 b2 6a 2d d8 d1 6f a8 d2 78 22 a7 a8 3b 34  6e.j-..o..x"..;4
    00000170: 30 9e 95 a2 d1 58 51 42 12 09 a9 49 a2 ad a5 c4  0....XQB...I....
    00000180: a1 cd dc 80 18 c9 ab bd f6 2a e3 40 18 38 35 37  .........*.@.857
    00000190: 04 86 e3 9a 6a db 8b 97 50 ea 7d a9 29 04 9a 44  ....j...P.}.)..D
    000001a0: fd ba 73 49 d9 31 b5 d4 69 38 a2 31 bb 10 8c 78  ..sI.1..i8.1...x
    000001b0: a6 fc 87 a2 42 12 2a 92 76 d4 94 b5 d4 69 6f 4a  ....B.*.v....ioJ
    000001c0: 5c a8 1e 9b 20 ce 07 43 51 cb 76 55 fb 08 0e 01  \... ..CQ.vU....
    000001d0: e2 87 1b 0b 9b a0 9b 8d 68 a1 6d 41 ec 26 69 59  ........h.mA.&iY
    000001e0: 09 58 ff d9 08 00 54 24 88 91 3e 63 17 8d bc 04  .X....T$..>c....
    000001f0: 00 55 19 4c 4a 26 20 00 01 6d 69 63 68 65 6c 6c  .U.LJ& ..michell
    00000200: 65 2e 61 64 6d 61 6e 40 74 61 65 63 2e 74 6f 73  e....@ta...s
    00000210: 68 69 62 61 2e 63 6f 6d 00 0f 00 06 31 2d 39 31  hiba.com....1-91
    00000220: 39 2d 38 35 34 2d 32 39 38 32 00 0f 00 08 31 2d  9-854-2982....1-
    00000230: 39 31 39 2d 32 37 34 2d 39 38 32 32 00 14 00 23  919-274-9822...#
    00000240: 33 31 32 30 20 48 69 67 68 77 6f 6f 64 73 20 42  3120 Highwoods B
    00000250: 6c 76 64 00 0a 00 24 53 75 69 74 65 20 31 30 38  lvd...$Suite 108
    00000260: 00 08 00 26 52 61 6c 65 69 67 68 00 03 00 27 4e  ...&Raleigh...'N
    00000270: 43 00 06 00 28 32 37 36 30 34 00                 C...(27604.

# Contact 0x264a4c19, Michele Adman
dn: cn=Michele Adman,Address Book - All
cn: Michele Adman
displayName: Michele Adman
givenName: Michele
l: Raleigh
mail: mic...@ta...
mobile: 1-919-274-9822
o: TAEC
postalAddress:: MzEyMCBIaWdod29vZHMgQmx2ZApTdWl0ZSAxMDgKUmFsZWlnaCBOQyAKMjc2MDQ=
postalCode: 27604
sn: Adman
st: NC
street: 3120 Highwoods Blvd
telephoneNumber: 1-919-854-2982
objectClass: inetOrgPerson

Re: [Barry-devel] Getting usb serial number string descriptor

[Eddy C. <edd...@gm...>]

Thanks Chris,

I've seen my mistake, it is working now. Thank you very much!


BR


2012/11/22 Chris Frey <cd...@fo...>

> On Thu, Nov 22, 2012 at 01:09:23PM -0600, Eddy Castillo wrote:
> > Hi all,
> >
> > Currently I'm working on a program to get a file with a lot of
> information
> > on BB devices using Barry. When I try to get the usb serial number (usb
> > device serial number not imei) I can get the iSerialNumber index (on
> > DeviceDescriptor) but when I try to get the string descriptor using
> > the usb_get_string_simple function I get a segmentation fault every time.
> >
> > Do you know what is the correct way to get this information?
>
> Something like this:
>
> +       char buf[1024];
> +       int ret = usb_get_string_simple(handle,
> +               desc.iSerialNumber, buf, sizeof(buf));
>
>
> I've added Device::GetSimpleSerialNumber() to the latest git, and I've
> added
> an -s option to the bidentify command line tool, to display the USB
> serial number.  Note that this is the same serial number retrieved via
> the lsusb tool, so you don't really need Barry, but might as well have
> this available through Barry as well.
>
> It works here.  Please let me know if you have trouble.
>
> - Chris
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel
>



-- 
Eddy Castillo
Statistics, Process Reengineering and Sofware Development Consultant
Mobile:             +52 (899) 214 5631

Re: [Barry-devel] Regarding email's date and time conversion.

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

On Fri, Nov 23, 2012 at 06:20:15AM +0000, tge...@gm... wrote:
> Hi,
> 
> How do barry convert email received date and time value to actual datetime.
> 
> For eg:
> Date value = 7718 and Time value = 36967.

Take a look at src/time.cc and src/r_message* and friends.

- Chris

Re: [Barry-devel] Getting usb serial number string descriptor

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

On Thu, Nov 22, 2012 at 01:09:23PM -0600, Eddy Castillo wrote:
> Hi all,
> 
> Currently I'm working on a program to get a file with a lot of information
> on BB devices using Barry. When I try to get the usb serial number (usb
> device serial number not imei) I can get the iSerialNumber index (on
> DeviceDescriptor) but when I try to get the string descriptor using
> the usb_get_string_simple function I get a segmentation fault every time.
> 
> Do you know what is the correct way to get this information?

Something like this:

+       char buf[1024];
+       int ret = usb_get_string_simple(handle,
+               desc.iSerialNumber, buf, sizeof(buf));


I've added Device::GetSimpleSerialNumber() to the latest git, and I've added
an -s option to the bidentify command line tool, to display the USB
serial number.  Note that this is the same serial number retrieved via
the lsusb tool, so you don't really need Barry, but might as well have
this available through Barry as well.

It works here.  Please let me know if you have trouble.

- Chris

[Barry-devel] Getting usb serial number string descriptor

[Eddy C. <edd...@gm...>]

Hi all,

Currently I'm working on a program to get a file with a lot of information
on BB devices using Barry. When I try to get the usb serial number (usb
device serial number not imei) I can get the iSerialNumber index (on
DeviceDescriptor) but when I try to get the string descriptor using
the usb_get_string_simple function I get a segmentation fault every time.

Do you know what is the correct way to get this information?


Best Regards,


-- 
Eddy Castillo
Statistics, Process Reengineering and Sofware Development Consultant
Mobile:             +52 (899) 214 5631

Re: [Barry-devel] WinCE port of Barry

[Toby G. <tob...@re...>]

On 12/11/12 15:30, Chris Frey wrote:
> Sorry for the delay.  I've merged your wince branch, all 3 changes that
> I found there.
>

That's great thanks. I forgot to mention the other fixes that I made in 
the branch.

Regards,

Toby

Re: [Barry-devel] [PATCH] lib: minor: remove undue "mode" in Browser Identity string

[Nicolas C. <car...@gm...>]

Le 12/11/2012 16:36, Chris Frey a écrit :
> On Fri, Oct 05, 2012 at 07:52:42AM +0200, Nicolas CARRIER wrote:
>> If I'm not wrong the string :
>>   "Browser Identity mode"
>> should be replaced by :
>>   "Browser Identity"
>> in /src/r_bookmark.cc
>>
>> If I'm right, then I'll update the translation accordingly.
> Hi Nicolas,
>
> Thank you for your quick response on the translation work!
> Sorry for my delay.
No problem at all !
>
> I have applied all 5 of your patches to the master branch.
>
> Thanks again!
> - Chris
Don't hesitate to warn me again like you did, the next time a release is 
near, so I can update it quick. Sadly I have no time to watch for the 
project...
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel
>

Re: [Barry-devel] [PATCH] lib: minor: remove undue "mode" in Browser Identity string

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

On Fri, Oct 05, 2012 at 07:52:42AM +0200, Nicolas CARRIER wrote:
> If I'm not wrong the string :
>  "Browser Identity mode"
> should be replaced by :
>  "Browser Identity"
> in /src/r_bookmark.cc
> 
> If I'm right, then I'll update the translation accordingly.

Hi Nicolas,

Thank you for your quick response on the translation work!
Sorry for my delay.

I have applied all 5 of your patches to the master branch.

Thanks again!
- Chris

Re: [Barry-devel] WinCE port of Barry

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

On Wed, Oct 10, 2012 at 05:32:36PM +0100, Toby Gray wrote:
> Good point. I've put a fix for this in my wince branch.

Hi Toby,

Sorry for the delay.  I've merged your wince branch, all 3 changes that
I found there.

Thanks!
- Chris

Re: [Barry-devel] Regarding barry's password hashing.

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

On Tue, Oct 23, 2012 at 01:42:00PM +0000, tge...@gm... wrote:
> Thanks for instant reply.
> 
> The length of SHA1 is 160, so how does this convert into password of 20 bytes.

See also SocketZero::SendPasswordHash()

- Chris

Re: [Barry-devel] Regarding barry's password hashing.

[<tge...@gm...>]

Thanks for instant reply.

The length of SHA1 is 160, so how does this convert into password of 20 bytes.
Sent on my BlackBerry® from Vodafone

-----Original Message-----
From: Nicolas CARRIER <nic...@pa...>
Date: Tue, 23 Oct 2012 13:39:18 
To: Barry project development discussion<bar...@li...>
Reply-To: Barry project development discussion
	<bar...@li...>
Subject: Re: [Barry-devel] Regarding barry's password hashing.

Hello,
you can take a look at m_ipmodem.cc:IpModem::SendPassword (l. 65 in current master's HEAD)

Basically :
  1. compute the SHA1 of the password
  2. prefix the result with the seed sent by the device
  3. compute the SHA1 of the result of step 2.
  4. send the result of step 3. to the device in a suitably built packet


On 23/10/2012 12:39, Tech Geek wrote:
> Hi,
>
> I am curious to know about barry's password hashing. How does hashing is done and which algo is used ?
>
> Thanks


-- 
Nicolas CARRIER - 6081 - 2ème centre

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Barry-devel mailing list
Bar...@li...
https://lists.sourceforge.net/lists/listinfo/barry-devel

Re: [Barry-devel] Regarding barry's password hashing.

[Nicolas C. <nic...@pa...>]

Hello,
you can take a look at m_ipmodem.cc:IpModem::SendPassword (l. 65 in current master's HEAD)

Basically :
  1. compute the SHA1 of the password
  2. prefix the result with the seed sent by the device
  3. compute the SHA1 of the result of step 2.
  4. send the result of step 3. to the device in a suitably built packet


On 23/10/2012 12:39, Tech Geek wrote:
> Hi,
>
> I am curious to know about barry's password hashing. How does hashing is done and which algo is used ?
>
> Thanks


-- 
Nicolas CARRIER - 6081 - 2ème centre

[Barry-devel] Regarding barry's password hashing.

[Tech G. <tge...@gm...>]

Hi,

I am curious to know about barry's password hashing. How does hashing is
done and which algo is used ?

Thanks

Re: [Barry-devel] WinCE port of Barry

[Toby G. <tob...@re...>]

On 05/10/12 02:35, Chris Frey wrote:
> On Thu, Sep 27, 2012 at 04:55:19PM +0100, Toby Gray wrote:
>> Hi,
>>
>> I've finally managed to get enough spare timeto make the changes that
>> Chris suggested in his review comments. I've updated my wince branch in
>> github:
>> https://github.com/tobygray/barry/tree/wince
> Thanks Toby!  My time for Barry has been limited lately, but I took a
> brief look tonight.

That's understandable. I know how easy it is for other work to get in 
the way.

>
>
>> The good news is that I managed to get a solution to the tr1 problem
>> without needing to change the barry headers:
>> https://github.com/tobygray/barry/commit/af3d23b39279930f755bfb8a0aac5d91e5f7aec3
> Nice.
>
>
> Regarding the new TCP stream support:
>
> I notice that in the unix implementation for brawchannel, you use both
> ::read() and fwrite() in the Stdin/Stdout stream classes.  Is there a
> reason for this?  The ::read() is straight, unix, unbuffered I/O, while
> the fwrite() is buffered.  For buffered streams, we normally use cout.
>
> It is safe to use fwrite() here, since we have cout.sync_with_stdio(true);
> in most of the tools as I recall, but it would be nice if Barry code
> didn't have this dependency.
>
> I think ::write() is satisfactory, unless you know something I don't. :-)

Good point. I've put a fix for this in my wince branch.

>
> I've merged this, since this is strictly tools/ code, but I can see
> stream classes like this being useful elsewhere, and could in the future
> be moved to a library, so it would be good to change this.  Also...
>
>
> +TcpStream::TcpStream(const char * addr, long port)
> +{
> +       mImpl.reset(new TcpStreamImpl);
> +       mImpl->mListenAddress = addr;
> +       mImpl->mPort = port;
> +       mImpl->mSocket = INVALID_SOCKET;
> +       mImpl->mListenSocket = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
> +       if( mImpl->mListenSocket == INVALID_SOCKET ) {
> +               cerr << "Failed to create listening socket: " <<
> +                       errno << endl;
> +       }
> +       if( mImpl->mListenAddress == NULL ) {
> +               mImpl->mHostAddress.s_addr = INADDR_ANY;
> +       } else {
> +               mImpl->mHostAddress.s_addr = inet_addr(mImpl->mListenAddress);
> +       }
> +}
>
> This takes an external const char* and saves it internally, for later use.
> This is also dangerous in code that could be used in the library.  I'd use
> a std::string in the TcpStreamImpl struct here for safety.

Another good point. Again I've put a fix for this in my wince branch.

>> I also fixed the registering for data packet handling without needing
>> the messy transfer interest function that my previous patches had
>> implemented.
> This is better than TransferInterest().  Clever too.  I didn't like exposing
> RegisterInterest() with a type argument as the default option, so I
> modified things a bit and added comments, trying to make it clear that
> most users shouldn't use the new API.  Socket::SyncSend() really needs
> both data and sequence packets in order to function, so this entire API
> is really only for the socket opening race condition.  It still seems
> a bit heavy to me, but I don't have a better way in mind, and this is
> pretty clean as is! :-)  Thanks!

It's a shame it is a bit complex, but at least it avoids the 
TransferInterest and redelivering packets. I imagine that this hasn't 
been seen before as none of the other socket mode protocols start with 
data coming from the device.

>> I based all these changes off the v0.19.0 branch rather than master as I
>> that seemed to make more sense.
> I've rebased the v0.19.0 branch onto master, and have included all your
> work.
>
> Thanks again!

Thank you for reviewing and pulling my changes.

Regards,

Toby

[Barry-devel] [PATCH]po: desktop: minor translation fixes

[Nicolas C. <car...@gm...>]

Minor translation fixes in desktop translation.

The previous patch I sent, was marked as 1/5, this is an error due to a
wrong use of format-patch.
Do I need to correct and re-submit it or can you make the correction ?

[Barry-devel] translation work

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

Hi,

Version 0.18.4 might get released this month.  We'll see :-)  But before
that happens, it would be nice if the translations were all up to speed.

I think the French one is looking pretty good.

The Spanish one needs work.

And if there are others out there who want to dive in, let me know.

- Chris

Re: [Barry-devel] WinCE port of Barry

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

On Thu, Sep 27, 2012 at 04:55:19PM +0100, Toby Gray wrote:
> Hi,
> 
> I've finally managed to get enough spare timeto make the changes that 
> Chris suggested in his review comments. I've updated my wince branch in 
> github:
> https://github.com/tobygray/barry/tree/wince

Thanks Toby!  My time for Barry has been limited lately, but I took a
brief look tonight.


> The good news is that I managed to get a solution to the tr1 problem 
> without needing to change the barry headers: 
> https://github.com/tobygray/barry/commit/af3d23b39279930f755bfb8a0aac5d91e5f7aec3

Nice.


Regarding the new TCP stream support:

I notice that in the unix implementation for brawchannel, you use both
::read() and fwrite() in the Stdin/Stdout stream classes.  Is there a
reason for this?  The ::read() is straight, unix, unbuffered I/O, while
the fwrite() is buffered.  For buffered streams, we normally use cout.

It is safe to use fwrite() here, since we have cout.sync_with_stdio(true);
in most of the tools as I recall, but it would be nice if Barry code
didn't have this dependency.

I think ::write() is satisfactory, unless you know something I don't. :-)

I've merged this, since this is strictly tools/ code, but I can see
stream classes like this being useful elsewhere, and could in the future
be moved to a library, so it would be good to change this.  Also...


+TcpStream::TcpStream(const char * addr, long port)
+{
+       mImpl.reset(new TcpStreamImpl);
+       mImpl->mListenAddress = addr;
+       mImpl->mPort = port;
+       mImpl->mSocket = INVALID_SOCKET;
+       mImpl->mListenSocket = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
+       if( mImpl->mListenSocket == INVALID_SOCKET ) {
+               cerr << "Failed to create listening socket: " << 
+                       errno << endl;
+       }
+       if( mImpl->mListenAddress == NULL ) {
+               mImpl->mHostAddress.s_addr = INADDR_ANY;
+       } else {
+               mImpl->mHostAddress.s_addr = inet_addr(mImpl->mListenAddress);
+       }
+}

This takes an external const char* and saves it internally, for later use.
This is also dangerous in code that could be used in the library.  I'd use
a std::string in the TcpStreamImpl struct here for safety.



> I also fixed the registering for data packet handling without needing 
> the messy transfer interest function that my previous patches had 
> implemented.

This is better than TransferInterest().  Clever too.  I didn't like exposing
RegisterInterest() with a type argument as the default option, so I
modified things a bit and added comments, trying to make it clear that
most users shouldn't use the new API.  Socket::SyncSend() really needs
both data and sequence packets in order to function, so this entire API
is really only for the socket opening race condition.  It still seems
a bit heavy to me, but I don't have a better way in mind, and this is
pretty clean as is! :-)  Thanks!


> I based all these changes off the v0.19.0 branch rather than master as I 
> that seemed to make more sense.

I've rebased the v0.19.0 branch onto master, and have included all your
work.

Thanks again!

- Chris

Re: [Barry-devel] WinCE port of Barry

[Toby G. <tob...@re...>]

Hi,

I've finally managed to get enough spare timeto make the changes that 
Chris suggested in his review comments. I've updated my wince branch in 
github:
https://github.com/tobygray/barry/tree/wince

The good news is that I managed to get a solution to the tr1 problem 
without needing to change the barry headers: 
https://github.com/tobygray/barry/commit/af3d23b39279930f755bfb8a0aac5d91e5f7aec3

I also fixed the registering for data packet handling without needing 
the messy transfer interest function that my previous patches had 
implemented.

I based all these changes off the v0.19.0 branch rather than master as I 
that seemed to make more sense.

Regards,

Toby

On 16/07/12 12:10, Toby Gray wrote:
> Hi,
>
> I've been working on a port of Barry to WinCE. It's currently sitting 
> in the "wince" branch on my github:
> https://github.com/tobygray/barry/tree/wince
>
> I don't think it's currently in a state to merge back into barry as 
> I've made a few changes which I'm not entirely sure about if they are 
> the best thing to do.
>
> The main commit which adds WinCE support is 
> https://github.com/tobygray/barry/commit/d660a40f21b823510e5b81113f20fe4af3c3974a. 
> This adds a wince directory in the root to contain the build files and 
> implementations of some functions not present on WinCE, such as getopt 
> and sleep. I have a feeling that these headers and source code should 
> probably be moved into /src, to go near pre-existing support code such 
> as getpwuidandroid.cc. Would that make sense?
>
> I have already done similarily for configfile.cc, splitting it up into 
> common code, code for unix systems and code for win32 systems in 
> https://github.com/tobygray/barry/commit/36131b090c3d6c1c34af441b40868b3b094fa66b
>
> As WinCE doesn't have tr1 support I had to change how the shared_ptr 
> support in Barry was referenced. Instead of directly referencing 
> tr1::shared_ptr, I changes this so that there is 
> Barry::tr1::shared_ptr which is provided by boost::shared_ptr on WinCE 
> and by tr1::shared_ptr on all pre-existing platforms.
>
> This was done in 
> https://github.com/tobygray/barry/commit/b4a70d9f7feedaa52bebe46d78e7dce880e73b74. 
> I'm not entirely happy with this, especially as it changes the 
> external API for libbarry, but I couldn't think of an alternative 
> solution.
>
> I added support for brawchannel to read and write the channel data 
> over TCP, instead of STDIN and STDOUT as WinCE doesn't have great 
> terminal support. This has made tools/brawchannel.cc a bit of a mess 
> of #ifdef WIN32. I think the best thing to do is to split it into 
> tools/brawchannel.cc, tools/brawchannel_unix.cc and 
> tools/brawchannel_win32.cc. Does that make sense?
>
> I noticed a couple of issues with routing of data and sequence packets 
> early on in channel setup if the device sends data to the PC quickly. 
> I fixed these in 
> https://github.com/tobygray/barry/commit/ebbdf4c9d5868a69d636119da354547918c70e1a 
> and 
> https://github.com/tobygray/barry/commit/6dff36f6c2cd1ef2c0006af2baebbf5ee0c0c291
>
> The rest of the commits are a combination of changes to the code to 
> fix warnings or errors from the Microsoft compiler. If the commit 
> messages aren't detailed enough for any of these then let me know and 
> I'll fill in the gaps (and update the commit messages).
>
> Regards,
>
> Toby
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Barry-devel mailing list
> Bar...@li...
> https://lists.sourceforge.net/lists/listinfo/barry-devel