Menu
▾
▴
bitpim-devel
|
From: Stephen M. <mar...@ch...> - 2004-03-14 13:33:35
|
Hello,
I found a slight BREW protocol difference with this phone...
Normally, you expect a file list response as below:
PACKET listfileresponse:
* responseheader header
4 UINT entrynumber
4 UNKNOWN unknown1
4 UINT date
4 UINT size
5 UNKNOWN unknown2
* STRING {'terminator': None, 'pascal': True} filename # no terminator
for some reason
But this phone has 5 "UNKNOWN" bytes before the remaining fields
(date,size,etc...)
Would it be possible to add this option in to support this phone?
Thanks!
-- Steve
-------------------------------------------------------------------------
22:09:25.594 SCP-5300: Now in brew mode
22:09:25.594 SCP-5300: brew request Data - 9 bytes
<#! p_brew.listfilerequest !#>
00000000 59 0b 00 00 00 00 02 2f 00 Y....../.
22:09:25.664 SCP-5300: brew response Data - 37 bytes
<#! p_brew.listfileresponse !#>
00000000 59 0b 00 00 00 00 00 01 1f 00 00 00 c1 83 1d 2c Y..............,
00000010 06 00 00 00 00 00 00 00 00 0b 75 69 62 75 69 6c ..........uibuil
00000020 64 2e 64 69 72 d.dir
-------------------------------------------------------------------------
|
|
From: Roger B. <ro...@ro...> - 2004-03-14 23:06:15
|
Stephen Marchant wrote: > But this phone has 5 "UNKNOWN" bytes before the remaining fields > (date,size,etc...) > Would it be possible to add this option in to support this phone? I would prefer something that works correctly against all models (ie find the root cause of the problem). (BTW the VX4400 is also based on the MSM5100). I was hoping that the first or second of unknowns would give some clue as to why the latter field is larger, but couldn't find anything. However I would appreciate it if you could put some more work into trying to figure out what these fields actually are. For unknown1, these are the values on the 3 phones I have: VX6000 FF 00 01 00 CDM8900 FF 00 01 03 (last 03 is sometimes zero) VX4400 FF 00 01 00 Unknown2 is almost always 00 followed by a four byte integer that is usally the same as the entry number. It is always a small value, usually less than 10. So far it looks like we can use the first byte of unknown1 to detect what is happening. Can everyone who doesn't have one of the phones listed please turn on the protocol logging, list a directory, and then press Ctrl-Alt-P in the protocol log pane. Find a p_brew.listfileresponse, and expand it in the second pane and write down what the value of the unknown1 field is. Feel free to also try and figure out what unknown2 is. Roger |
|
From: Tom P. <mlp...@ea...> - 2004-03-15 00:02:48
|
On Mar 14, 2004, at 6:07 PM, Roger Binns wrote: > For unknown1, these are the values on the 3 phones I have: > > VX6000 FF 00 01 00 > CDM8900 FF 00 01 03 (last 03 is sometimes zero) > VX4400 FF 00 01 00 > > Unknown2 is almost always 00 followed by a four byte integer > that is usally the same as the entry number. It is always > a small value, usually less than 10. > > So far it looks like we can use the first byte of unknown1 to > detect what is happening. Can everyone who doesn't have > one of the phones listed please turn on the protocol logging, > list a directory, and then press Ctrl-Alt-P in the protocol > log pane. Find a p_brew.listfileresponse, and expand it in > the second pane and write down what the value of the unknown1 > field is. Feel free to also try and figure out what unknown2 > is. It looks like unknown1 isn't simply a phone-dependent constant. After listing the root directory on my VX4500, I found at least three different values for unknown1 in different listfileresponse packets: unknown1 unknown2 FF 00 00 00 00 02 00 00 00 FF 00 01 00 00 02 00 00 00 FF 00 01 03 00 02 00 00 00 Listing the ART directory, I get a few more variations: FF 00 01 01 00 08 00 00 04 FF 00 01 01 00 06 00 00 04 FF 00 01 01 00 04 00 00 04 FF 00 01 01 00 30 00 00 04 Listing the OWS directory, I found: FF 00 01 00 00 16 00 00 04 FF 00 01 00 00 02 00 00 04 FF 00 01 00 00 04 00 00 04 etc. There were additional variations for unknown2 in other directories, but these are the only three values of unknown1 I've seen. In all cases, the directory listing itself was successful. Tom |
|
From: Stephen W. <sa...@ge...> - 2004-03-15 01:06:40
|
On Sun, 2004-03-14 at 18:07, Roger Binns wrote:
> ... Can everyone who doesn't have
> one of the phones listed please turn on the protocol logging,
> list a directory, ...
I get a bit more variety in unknown1 and unknown2 with Sanyo phones.
With the SCP-5500 in the top directory, with 6 files I get
FF 00 01 03 00 02 00 00 00 $USER_DIRS
37 00 01 03 00 02 00 00 00 $SYS.FACTORY
FF 00 01 00 00 02 00 00 00 uivrState.dat
FF 00 01 00 00 02 00 00 00 CLK_DB
FF 00 00 00 00 02 00 00 00 RDM_PORT_MAP
FF 00 01 00 00 02 00 00 00 $SYS_RMT
On the SCP-4900 which has all these files except CLK_DB. The same
unknown codes match up with the same file names as the 5500.
Now if I go into a directory, say nvm on the 5500, it gets a little more
interesting.
37 00 01 03 00 02 00 00 04 nvm/$SYS.ESN
37 00 01 03 00 02 00 00 04 nvm/$SYS.INVAR1
37 00 01 03 00 02 00 00 04 nvm/$SYS.INVAR2
FF 00 01 03 00 02 00 00 04 nvm/$SYS.INVAR3
Now drilling down to down to nvm/nvm
file size
FF 00 01 03 00 04 00 00 08 nvm/nvm/nvm_0000 829
FF 00 01 03 00 82 00 00 08 nvm/nvm/nvm_0001 31976
FF 00 01 03 00 04 00 00 08 nvm/nvm/nvm_0002 716
FF 00 01 03 00 08 00 00 08 nvm/nvm/nvm_0003 1524
FF 00 01 03 00 02 00 00 08 nvm/nvm/nvm_0004 5
FF 00 01 03 00 10 00 00 08 nvm/nvm/nvm_0005 3809
FF 00 01 03 00 c4 00 00 08 nvm/nvm/nvm_0008 48200
FF 00 01 03 00 c4 00 00 08 nvm/nvm/nvm_0009 48200
FF 00 01 03 00 c4 00 00 08 nvm/nvm/nvm_0010 48200
So unknown 2 seems to be related to file size, but not by a nice power
of 2.
Then again, if I go into other directories, the second byte doesn't seem
connected to file size anymore??
I am sure this just adds more confusion.
Stephen
|
|
From: Roger B. <ro...@ro...> - 2004-03-15 03:21:31
|
> VX6000 FF 00 01 00 > CDM8900 FF 00 01 03 (last 03 is sometimes zero) > VX4400 FF 00 01 00 > VX4500 FF 00 00 00 > VX4500 FF 00 01 01 > VX4500 FF 00 01 03 > SCP5500 FF 00 01 03 > SCP5500 37 00 01 03 I also had the CDM8900 have 37 as first byte of unknown1 after looking in several other directories. So it doesn't look like unknown1 can be used as a useful predictor of the extra byte for the Kyocera 7135 (incidentally Kyocera typically just rebadge Qualcomm phones and hence are closest to the "real thing"). The second byte of unknown2 seems to be somewhat related to file size. (The protocol uses a block size of 256 bytes). Hopefully Stephgen Marchant can figure out some form of indicator since I really don't want to have variations on the brew protocol. (I will do so if there is no choice). Roger |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X