Menu
▾
▴
bitpim-devel — For bitpim developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(53) |
Apr
(48) |
May
(14) |
Jun
(3) |
Jul
(21) |
Aug
(11) |
Sep
(77) |
Oct
(67) |
Nov
(28) |
Dec
(163) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(112) |
Feb
(143) |
Mar
(114) |
Apr
(138) |
May
(173) |
Jun
(119) |
Jul
(119) |
Aug
(117) |
Sep
(187) |
Oct
(170) |
Nov
(254) |
Dec
(193) |
| 2005 |
Jan
(336) |
Feb
(284) |
Mar
(189) |
Apr
(100) |
May
(89) |
Jun
(52) |
Jul
(85) |
Aug
(138) |
Sep
(181) |
Oct
(137) |
Nov
(104) |
Dec
(98) |
| 2006 |
Jan
(76) |
Feb
(106) |
Mar
(224) |
Apr
(270) |
May
(103) |
Jun
(144) |
Jul
(77) |
Aug
(38) |
Sep
(37) |
Oct
(20) |
Nov
(14) |
Dec
(73) |
| 2007 |
Jan
(130) |
Feb
(68) |
Mar
(78) |
Apr
(60) |
May
(45) |
Jun
(63) |
Jul
(84) |
Aug
(45) |
Sep
(40) |
Oct
(12) |
Nov
(71) |
Dec
(56) |
| 2008 |
Jan
(44) |
Feb
(20) |
Mar
(25) |
Apr
(17) |
May
(33) |
Jun
(60) |
Jul
(97) |
Aug
(38) |
Sep
(10) |
Oct
(20) |
Nov
(13) |
Dec
(19) |
| 2009 |
Jan
(7) |
Feb
(5) |
Mar
(23) |
Apr
(10) |
May
(6) |
Jun
(5) |
Jul
(17) |
Aug
(7) |
Sep
(14) |
Oct
(27) |
Nov
(13) |
Dec
(12) |
| 2010 |
Jan
(37) |
Feb
(9) |
Mar
(13) |
Apr
(12) |
May
(8) |
Jun
(3) |
Jul
(1) |
Aug
(9) |
Sep
(3) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
| 2011 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
(2) |
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
(3) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Roger B. <ro...@ro...> - 2004-03-31 02:40:13
|
After a humunguous amount of effort, I have given up trying to use XML-RPC over HTTP over SSL using the Python standard library and M2Crypto. Although I mostly had them playing together, it was horrid. The good news is that I have figured out how to do it using XML-RPC over SSH, and will be using the paramiko library (pure Python implementation of SSH). My prototype code has worked well. It also has the connection oriented semantics I wanted, and was trying to get with HTTP/1.1 keepalives. I will be using a private copy of Paramiko initially. This is because the standard version doesn't support Python 2.2 as needed on Redhat. Paramiko also depends on pycrypto (which is a binary package). The code I commit over the next few days may or may not cause issues if you don't have stuff installed. Here is what you should do: - Double-check that Paramiko is okay to use (it is LGPL) (ie would you be happy exposing it to the open Internet?) - Install pycrypto package from http://www.amk.ca/python/code/crypto.html On Linux and Mac: $ python setup.py install On Windows (hard way): - Install VC++6 or MinGW > python setup.py build --compiler=mingw32 bdist_wininst - The package is in the dist directory (--compiler not needed for VC++6) On Windows (easy way): - There is one I prepared earlier at http://sf.net/project/showfiles.php?group_id=75211&package_id=113804 - If using Python earlier than 2.3 (eg on Redhat), install the logging package. You can copy it from a Python 2.3 install or grab it from the above link. I suggest extracting the zip into the site-packages directory in Python eg /usr/lib/python2.2/site-packages You don't need to do anything yet until stuff starts falling over due to lack of these. If any Windows guru is looking for a small project, I would like a standalone binary of ssh-keygen from OpenSSH (I can use one from Cygwin, but would prefer something smaller and needing less DLLs). If there is any crypto guru out there, I would be ever happier with code that generates SSH2 DSA keys (that is all I need ssh-keygen for). I would recommend contributing it to paramiko. Roger |
|
From: John C. <ra...@ho...> - 2004-03-30 06:01:01
|
>Calendar writing was broken for the 5500 in 0.7test6. Looks like it >will probably work for the 5400 in the next test7 release. Cool, I'll check it out and let you know for both phones... >Is the list of ringers on the 5400 identical to the 7300? If not could >you make a list of the built in ringers on the 5400. The list is the same, but tones 1-8 sound different. Media (annimations), are all different too for what its worth. >Do you see any differences in the 7300 and 5400, other than shape of the >phone? Minor updates in the software with the 7300, but for the most part no. Manuals look more or less the same, same stats on phonebook numbers 300/500. According to the web, the 7300 has more storage space for downloads (832k vs 640k, but I havent verified it). They really look like the exact same phone except that the 7300 is touting the 'impact resistant' outer covering... yet to be tested. >Do you actually use the Readylink on your phones? I am curious if any >of the readylink phonebook is kept on the phone, and thus readable by >BitPim. > > Thanks, Stephen > I'm not currently using it, it costs $20 a month for the two phones. I'll keep my eye out for specials where I can demo it for a bit, though. According to the web it looks like: Company: 200 Entries (200 Max Groups with 5 per Group) Personal: 200 Entries (33 Max Groups with 5 per Group) If you want to send me a backup of your 5500's tree I'll compare it to mine and see if anything's obvious, or I could send you a copy of mine. _________________________________________________________________ Get reliable access on MSN 9 Dial-up. 3 months for the price of 1! (Limited-time offer) http://join.msn.com/?page=dept/dialup&pgmarket=en-us&ST=1/go/onm00200361ave/direct/01/ |
|
From: Stephen W. <sa...@ge...> - 2004-03-29 13:32:30
|
On Mon, 2004-03-29 at 01:48, John Camin wrote:
> >2. I have no information on the SCP-5400 protocol. If you could try
> >reading the phone book using both the SCP-8100 and SCP-5500 settings in
> >BitPim, and report reults, that would help.
>
> The phone book worked just peachy using the SCP-5500 settings. Read/Edited
> and Wrote back to the phone all fine. Calendar choked with the following
> error. If this is unexpected, I'll post the entire error. It's repeatable,
> anytime anything is attempted to be uploaded.
>
> Frame _complainaboutunusedargs in prototypes.pyo at line 119
> self = <p_sanyo5500.sanyoheader object at 0x018E48B0>
> dict = {'readwrite': 14}
> klass = <class 'p_sanyo5500.sanyoheader'>
>
Calendar writing was broken for the 5500 in 0.7test6. Looks like it
will probably work for the 5400 in the next test7 release.
Is the list of ringers on the 5400 identical to the 7300? If not could
you make a list of the built in ringers on the 5400.
Do you see any differences in the 7300 and 5400, other than shape of the
phone?
Do you actually use the Readylink on your phones? I am curious if any
of the readylink phonebook is kept on the phone, and thus readable by
BitPim.
Thanks, Stephen
|
|
From: John C. <ra...@ho...> - 2004-03-29 06:48:37
|
>There are a few areas where help would be much appreciated.
>
>1. RL7300 support has just been added to BitPim and will appear in the
>next text release (0.7test7) which should be released very soon. The
>7300 support was done based on newsgroup reports that the SCP-5500
>BitPim code works on the 7300. Since I don't have a 7300 myself, I
>would appreciate it if someone could thoroughly test it. Some things to
>check for are, a) do ringer assignments come out with the correct names
>when the phonebook is read, and b) do calendar read/writes work.
Great, will do as soon as its posted.
>2. I have no information on the SCP-5400 protocol. If you could try
>reading the phone book using both the SCP-8100 and SCP-5500 settings in
>BitPim, and report reults, that would help.
The phone book worked just peachy using the SCP-5500 settings. Read/Edited
and Wrote back to the phone all fine. Calendar choked with the following
error. If this is unexpected, I'll post the entire error. It's repeatable,
anytime anything is attempted to be uploaded.
Frame _complainaboutunusedargs in prototypes.pyo at line 119
self = <p_sanyo5500.sanyoheader object at 0x018E48B0>
dict = {'readwrite': 14}
klass = <class 'p_sanyo5500.sanyoheader'>
>3. I will be starting media transfer support for Sanyo phones soon. I
>have a 5500, so code developed for that should be close to what is
>needed for the 7300. However, there will be differences, as the 7300
>does not have a camera. If you can get the CVS version of BitPim
>working, then you could help by running test code learn the differences
>between the protocols of the two phones.
>
> Stephen
>
Great again, will be happy to test the media stuff as soon as its ready...
or even if its not ready. :)
I'll try to get the CVS going, but I've got a few other programs to write
first... :( A newb question, though, and I appologize if I missed this
somewhere, but can you download the entire project as one file from CVS? I
can get the individual parts, but thats it via the web. (prolly a dumb
question, I havent used CVS before)
just fyi, 5400 is sans camera as well. 5400, 7200 and 7300 all have the new
readylink stuff... which as far as i can tell is about useless with free
sprint-sprint calls, but oh well.
_________________________________________________________________
Check out MSN PC Safety & Security to help ensure your PC is protected and
safe. http://specials.msn.com/msn/security.asp
|
|
From: Steven P. <n9...@n9...> - 2004-03-29 03:53:12
|
On Mar 28, 2004, at 9:23 AM, Steven Palm wrote: > On Mar 28, 2004, at 12:25 AM, Roger Binns wrote: >> Everything is ready from my end for doing the build. > > OK, I'll build them this afternoon. Or, when all else fails and the world cocks a snook at you, you fall back to the next best thing.... ;-) I'll do them in the morning, shouldn't be a problem then. ;-) |
|
From: Stephen W. <sa...@ge...> - 2004-03-28 22:59:30
|
I would like add media support for Sanyo Phones. I have just started to work on this. Stephen |
|
From: Roger B. <ro...@ro...> - 2004-03-28 20:47:25
|
Here is my current list of what needs to be done for a 0.7 final release, followed by what needs to happen after that. Mandatory means I will implement it if noone else does. Mandatory: - Complete BitFling (this allows the phone and BitPim to be on different machines, even across the Internet and will make development a lot easier). I am actively working on this. - Complete the media code currently used for wallpaper display (do something on activitation of items, buttons for dealing with conversions, setting origin for items [mms, drm, etc]) - Move the ringtones over to the media code - Deal with ringtone formats correctly, and not auto-force to mid. Deal with format conversion (pvconv, ffmpeg) - Complete the phonebook import/merge code. Categories need to be selectable in the import dialog, and the merge display (ie where an imported entry and an existing entry need to joined together) Optional: - Outlook import via the import dialog - Phonebook export After 0.7 final is out, the following needs to be done for the next release: - Get a better version numbering system :-) [Probably the odd/even scheme used by Linux and other projects] - Sort out the calendar - I also want to do SMS, voice and text memos and other things, but they are optional Roger |
|
From: Stephen W. <sa...@us...> - 2004-03-28 19:48:19
|
On Sun, 2004-03-28 at 02:12, John Camin wrote: > ... > > I picked up two new phones this week that I'd like to help add to > your program. I've got both the RL2500 (SCP-5400) and the RL7300 > (SCP-7300). > There are a few areas where help would be much appreciated. 1. RL7300 support has just been added to BitPim and will appear in the next text release (0.7test7) which should be released very soon. The 7300 support was done based on newsgroup reports that the SCP-5500 BitPim code works on the 7300. Since I don't have a 7300 myself, I would appreciate it if someone could thoroughly test it. Some things to check for are, a) do ringer assignments come out with the correct names when the phonebook is read, and b) do calendar read/writes work. 2. I have no information on the SCP-5400 protocol. If you could try reading the phone book using both the SCP-8100 and SCP-5500 settings in BitPim, and report reults, that would help. 3. I will be starting media transfer support for Sanyo phones soon. I have a 5500, so code developed for that should be close to what is needed for the 7300. However, there will be differences, as the 7300 does not have a camera. If you can get the CVS version of BitPim working, then you could help by running test code learn the differences between the protocols of the two phones. Stephen |
|
From: Steven P. <n9...@n9...> - 2004-03-28 15:23:34
|
On Mar 28, 2004, at 12:25 AM, Roger Binns wrote: > Everything is ready from my end for doing the build. OK, I'll build them this afternoon. |
|
From: Paul T. <bit...@st...> - 2004-03-28 07:37:26
|
whoops, ignore me. the timeouts have gone away after a kernel reboot. I probably screwed the pooch with some earlier debugging. Thanks for all the help! |
|
From: John C. <ra...@ho...> - 2004-03-28 07:13:34
|
Hi all, I'm new to the list as of today and just wanted to say hi to everyone. I picked up two new phones this week that I'd like to help add to your program. I've got both the RL2500 (SCP-5400) and the RL7300 (SCP-7300). I managed to get the hexdump's from the filesystem on both phones, but not surprisingly nothing else works. What can I do to help? Unfortunately, I'm probably not going to have time to learn python for a few weeks (months?), but I can certainly get any info you need from these two phones. Just let me know. I'm pretty impressed with what you guys have accomplished... looks great. :) -John _________________________________________________________________ MSN Toolbar provides one-click access to Hotmail from any Web page FREE download! http://toolbar.msn.com/go/onm00200413ave/direct/01/ |
|
From: Paul T. <bit...@st...> - 2004-03-28 07:09:07
|
Thanks! Now I understand your communications interface. I didn't wrap
my head around the fact that you couldn't use the native acm module.
Yes, I am building from source because I am running debian linux, and
even after converting your rpm to a deb and installing it, the precompiled
stuff was barfing due to libstdc++ shared library incompatabilities.
I'm sorry I missed that comment about building libusb in the other docs.
I installed swig and built your private _libusb.
So, usbscan is now working properly for me:
getting configvalue
value is 1 now about to set config
config set
claiming 1
getting configvalue
value is 1 now about to set config
config set
claiming 2
UsbScan $Revision: 1.5 $
usb::005::006::1:
active: True available: False
description: USB Device - Vendor LG Electroncs Product VX4400/4500/4600/6000 Phone (Interface Modem Interface)
libusb: True protocol: Data / Generic usb-interface: Modem Interface
usb-interface#: 1 usb-product: VX4400/4500/4600/6000 Phone
usb-product#: 24576 usb-productstring: Qualcomm CDMA Technologies MSM
usb-vendor: LG Electroncs usb-vendor#: 4100
usb::005::006::2:
active: True available: False
description: USB Device - Vendor LG Electroncs Product VX4400/4500/4600/6000 Phone (Interface Diagnostics Interface)
libusb: True protocol: Vendor Specific Class / Vendor Specific Subclass
usb-interface: Diagnostics Interface usb-interface#: 2
usb-product: VX4400/4500/4600/6000 Phone usb-product#: 24576
usb-productstring: Qualcomm CDMA Technologies MSM
usb-vendor: LG Electroncs usb-vendor#: 4100
but when I go to grab some data out of the phone I get a USB timeout:
An unexpected exception has occurred.
Please see the help for details on what to do.
Traceback (most recent call last):
File "/home/pst/bitpim/gui.py", line 150, in run
res=call()
File "/home/pst/bitpim/gui.py", line 91, in __call__
return apply(self.method, self.args+args, d)
File "/home/pst/bitpim/gui.py", line 1053, in getdata
results=self.getfundamentals()
File "/home/pst/bitpim/gui.py", line 1047, in getfundamentals
self.commphone.getfundamentals(results)
File "/home/pst/bitpim/com_lgvx4400.py", line 89, in getfundamentals
results['uniqueserial']=sha.new(self.getfilecontents("nvm/$SYS.ESN")).hexdigest()
File "/home/pst/bitpim/com_brew.py", line 201, in getfilecontents
res=self.sendbrewcommand(req, p_brew.readfileresponse)
File "/home/pst/bitpim/com_brew.py", line 283, in sendbrewcommand
self.setmode(self.MODEBREW)
File "/home/pst/bitpim/com_phone.py", line 102, in setmode
res=getattr(self, func)()
File "/home/pst/bitpim/com_brew.py", line 239, in _setmodebrew
self.sendbrewcommand(req, respc, callsetmode=False)
File "/home/pst/bitpim/com_brew.py", line 291, in sendbrewcommand
self.comm.write(data, log=False) # we logged above
File "/home/pst/bitpim/commport.py", line 187, in write
self.ser.write(data)
File "/home/pst/bitpim/commport.py", line 294, in write
self.dev.write(data, self.timeout)
File "/home/pst/bitpim/native/usb/usb.py", line 262, in write
raise USBException()
USBException: error writing to bulk endpoint 6: Connection timed out
Variables by last 8 frames, innermost last
Frame getfilecontents in /home/pst/bitpim/com_brew.py at line 201
self = <com_lgvx6000.Phone instance at 0x42ac7f2c>
req = <p_brew.readfilerequest object at 0x42ac7fec>
start = 1080457151.340672
file = 'nvm/$SYS.ESN'
data = <cStringIO.StringO object at 0x42ac7fa0>
desc = 'Reading nvm/$SYS.ESN'
Frame sendbrewcommand in /home/pst/bitpim/com_brew.py at line 283
callsetmode = True
request = <p_brew.readfilerequest object at 0x42ac7fec>
self = <com_lgvx6000.Phone instance at 0x42ac7f2c>
responseclass = <class 'p_brew.readfileresponse'>
Frame setmode in /home/pst/bitpim/com_phone.py at line 104
desiredmode = 'modebrew'
self = <com_lgvx6000.Phone instance at 0x42ac7f2c>
strmode = 'none'
strdesiredmode = 'brew'
func = '_setmodebrew'
v = 'writefile'
Frame _setmodebrew in /home/pst/bitpim/com_brew.py at line 242
self = <com_lgvx6000.Phone instance at 0x42ac7f2c>
req = <p_brew.memoryconfigrequest object at 0x42ac7f4c>
respc = <class 'p_brew.memoryconfigresponse'>
Frame sendbrewcommand in /home/pst/bitpim/com_brew.py at line 295
responseclass = <class 'p_brew.memoryconfigresponse'>
buffer = <prototypes.buffer instance at 0x42acc26c>
request = <p_brew.memoryconfigrequest object at 0x42ac7f4c>
callsetmode = False
firsttwo = 'Y\x0c'
data = 'Y\x0c\xc4\xc1~'
self = <com_lgvx6000.Phone instance at 0x42ac7f2c>
Frame write in /home/pst/bitpim/commport.py at line 187
self = <commport.CommConnection instance at 0x420b258c>
data = 'Y\x0c\xc4\xc1~'
log = False
Frame write in /home/pst/bitpim/commport.py at line 294
self = <commport._usbdevicewrapper instance at 0x42ac7f8c>
data = 'Y\x0c\xc4\xc1~'
Frame write in /home/pst/bitpim/native/usb/usb.py at line 262
res = -110
self = <native.usb.usb.USBFile instance at 0x42acc12c>
data = 'Y\x0c\xc4\xc1~'
timeout = 3000
first = False
Unfortunately, I'm running kernel 2.6.4 (can't go down to 2.4). I'm
also using python 2.3.
Has anyone else successfully built bitpim out of CVS HEAD under a 2.6
kernel or verified that your libusb works under 2.6?
|
|
From: Roger B. <ro...@ro...> - 2004-03-28 06:36:08
|
> also, "no modules for USB product 1004/6000/0" was output by hotplug on That doesn't matter. Interface 0 is an interrupt interface and is paired with interface 1 (bulk/modem). Roger |
|
From: Roger B. <ro...@ro...> - 2004-03-28 06:35:11
|
> I then tried /dev/usb/acm/0 as a hope of accessing the diagnostic port, http://bitpim.sourceforge.net/testhelp/hoto-usbintro.htm The VX6000 has 3 interfaces. 0 and 1 are the modem interface and are used by the acm driver. Interface 2 is the diagnositcs interface and is what BitPim needs to talk to. It can only be accessed via libusb on Linux as there is no driver. usbscan should list every USB device connected to your machine (not just phones). If you aren't getting that then something is wrong. Note that if you are working from the source code, you need to build the USB module in native/usb which also requires SWIG amongst other things. The prebuilt rpm has all the right stuff built and links dynamically to libusb: $ ldd _libusb.so libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0x400e6000) libc.so.6 => /lib/i686/libc.so.6 (0x400ed000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) > but the bit about not reading > the vendor string seems like it might be an issue? None of the LG phones will give up a vendor string except when they very first get plugged in, and then they tell the OS as it interrogates them. > However I know that we should just be looking for the IDs? Yes, that is what happens. The strings from the device itself are shown in the port browser if present. We also have our own USB ids to string database to augment the standard one. > This could simply be that I don't know where to get access to the damn > thing in my /dev (devfs) tree. libusb accesses the usbfs tree. > Any suggestions as to what the right > major (and minor) numbers for the diag port device should be? Then I > could just run a find command to figure out what debian called it? It doesn't work like that (except for the modem interface). The devices and interfaces appear as nodes in the usb filesystem. Roger |
|
From: Roger B. <ro...@ro...> - 2004-03-28 06:25:58
|
Steven, Everything is ready from my end for doing the build. Roger |
|
From: Paul T. <bit...@st...> - 2004-03-28 02:21:00
|
Dang, sorry, I forgot to add this... output from my kernel yellow flag? usb 5-1: new full speed USB device using address 2 usb 5-1: device not accepting address 2, error -110 usb 5-1: new full speed USB device using address 3 usb 5-1: device not accepting address 3, error -110 usb 5-1: new full speed USB device using address 4 usb 5-1: device not accepting address 4, error -110 usb 5-1: new full speed USB device using address 5 cdc_acm 5-1:1.0: ttyACM0: USB ACM device<6>drivers/usb/core/usb.c: registered new driver cdc_acm drivers/usb/class/cdc-acm.c: v0.23:USB Abstract Control Model driver for USB modems and ISDN adapters usb 5-1: USB disconnect, address 5 also, "no modules for USB product 1004/6000/0" was output by hotplug on stderr |
|
From: Paul T. <bit...@st...> - 2004-03-28 02:14:32
|
Roger (et al), I'm trying to get 0.7test6 running on a Linux box. I'm sorry, I have little if any previous USB under Linux experience. The environment: Linux quemadura.shockwave.org 2.6.4-1-686-smp #1 SMP Sat Mar 13 21:05:54 EST 2004 i686 GNU/Linux Debian testing/unstable I've brought up bitpim. I first tried to let it auto-find my LG VX6000 phone with no luck. I figured libusb/usbscan was just confused? The output of usbscan if run separately is nothing (nothing found). I then tried /dev/usb/acm/0 as a hope of accessing the diagnostic port, that failed with a BREW CRC error, so I assume that the particular port I tried to access represents either the data port or some strange composite port for the modem. Traceback (most recent call last): File "/home/pst/bitpim/gui.py", line 150, in run res=call() File "/home/pst/bitpim/gui.py", line 91, in __call__ return apply(self.method, self.args+args, d) File "/home/pst/bitpim/gui.py", line 1053, in getdata results=self.getfundamentals() File "/home/pst/bitpim/gui.py", line 1047, in getfundamentals self.commphone.getfundamentals(results) File "/home/pst/bitpim/com_lgvx4400.py", line 89, in getfundamentals results['uniqueserial']=sha.new(self.getfilecontents("nvm/$SYS.ESN")).hexdigest() File "/home/pst/bitpim/com_brew.py", line 201, in getfilecontents res=self.sendbrewcommand(req, p_brew.readfileresponse) File "/home/pst/bitpim/com_brew.py", line 325, in sendbrewcommand raise common.CommsDataCorruption(self.desc, "Brew packet failed CRC check") CommsDataCorruption: LG-VX6000: Brew packet failed CRC check Variables by last 8 frames, innermost last Frame __bootstrap in /usr/lib/python2.3/threading.py at line 436 self = <WorkerThread(BitPim helper, started daemon)> Frame run in /home/pst/bitpim/gui.py at line 143 e = <common.CommsDataCorruption instance at 0x42065dac> res = None self = <WorkerThread(BitPim helper, started daemon)> item = (<gui.Request instance at 0x41fb76ac>, <gui.Callback instanc call = <gui.Request instance at 0x41fb76ac> ex = <common.CommsDataCorruption instance at 0x42065dac> resultcb = <gui.Callback instance at 0x4204b04c> first = 0 Frame __call__ in /home/pst/bitpim/gui.py at line 91 self = <gui.Request instance at 0x41fb76ac> args = () d = {} kwargs = {} Frame getdata in /home/pst/bitpim/gui.py at line 1053 self = <WorkerThread(BitPim helper, started daemon)> req = <guiwidgets.GetPhoneDialog instance; proxy of C++ wxDialog i Frame getfundamentals in /home/pst/bitpim/gui.py at line 1047 self = <WorkerThread(BitPim helper, started daemon)> results = {} Frame getfundamentals in /home/pst/bitpim/com_lgvx4400.py at line 89 self = <com_lgvx6000.Phone instance at 0x4204b78c> results = {} Frame getfilecontents in /home/pst/bitpim/com_brew.py at line 201 self = <com_lgvx6000.Phone instance at 0x4204b78c> req = <p_brew.readfilerequest object at 0x42065d6c> start = 1080438070.1254621 file = 'nvm/$SYS.ESN' data = <cStringIO.StringO object at 0x42065d00> desc = 'Reading nvm/$SYS.ESN' Frame sendbrewcommand in /home/pst/bitpim/com_brew.py at line 325 origdata = 'Y\x04\rnvm/$SYS.ESN1\xe2~' d = 0 responseclass = <class 'p_brew.readfileresponse'> buffer = <prototypes.buffer instance at 0x42065ecc> request = <p_brew.readfilerequest object at 0x42065d6c> callsetmode = True firsttwo = 'Y\x04' crc = '1\xe2' data = 'Y\x04\rnvm/$SYS.ESN' self = <com_lgvx6000.Phone instance at 0x4204b78c> I saw your note about checking libusb against the kernel (since I am running 2.6 and downgrading is not an option for me). I ran the testusb utility (as well as lsusb). It appears to clearly be finding the ACM device and a couple of bulk endpoints (?), but the bit about not reading the vendor string seems like it might be an issue? However I know that we should just be looking for the IDs? This could simply be that I don't know where to get access to the damn thing in my /dev (devfs) tree. Any suggestions as to what the right major (and minor) numbers for the diag port device should be? Then I could just run a find command to figure out what debian called it? Thanks, Paul lsusb Bus 005 Device 005: ID 1004:6000 LG Electronics, Inc. Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 002: ID 046d:c501 Logitech, Inc. Cordless Mouse Receiver Bus 003 Device 001: ID 0000:0000 Bus 002 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 lsusb -v (just bus 5) Bus 005 Device 005: ID 1004:6000 LG Electronics, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.01 bDeviceClass 2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 16 idVendor 0x1004 LG Electronics, Inc. idProduct 0x6000 bcdDevice 0.00 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 90 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 bytes 16 once bInterval 32 CDC Header: bcdCDC 1.09 CDC Call Management: bmCapabilities 0x03 call management use DataInterface bDataInterface 1 CDC ACM: bmCapabilities 0f connection notifications sends break line coding and serial state get/set/clear comm features CDC Union: bMasterInterface 0 bSlaveInterface 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 10 Data bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8a EP 10 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 bytes 64 once bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0b EP 11 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 bytes 64 once bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 bytes 64 once bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x06 EP 6 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 bytes 64 once bInterval 0 Bus 005 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 iProduct 2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x40 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 bytes 2 twice bInterval 255 output from testlibusb: bus/device idVendor/idProduct 005/005 1004/6000 - Unable to fetch manufacturer string - Unable to fetch product string wTotalLength: 90 bNumInterfaces: 3 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: e0h MaxPower: 50 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 1 bInterfaceClass: 2 bInterfaceSubClass: 2 bInterfaceProtocol: 1 iInterface: 0 bEndpointAddress: 81h bmAttributes: 03h wMaxPacketSize: 16 bInterval: 32 bRefresh: 0 bSynchAddress: 0 bInterfaceNumber: 1 bAlternateSetting: 0 bNumEndpoints: 2 bInterfaceClass: 10 bInterfaceSubClass: 0 bInterfaceProtocol: 0 iInterface: 4 bEndpointAddress: 8ah bmAttributes: 02h wMaxPacketSize: 64 bInterval: 0 bRefresh: 0 bSynchAddress: 0 bEndpointAddress: 0bh bmAttributes: 02h wMaxPacketSize: 64 bInterval: 0 bRefresh: 0 bSynchAddress: 0 bInterfaceNumber: 2 bAlternateSetting: 0 bNumEndpoints: 2 bInterfaceClass: 255 bInterfaceSubClass: 255 bInterfaceProtocol: 0 iInterface: 0 bEndpointAddress: 83h bmAttributes: 02h wMaxPacketSize: 64 bInterval: 0 bRefresh: 0 bSynchAddress: 0 bEndpointAddress: 06h bmAttributes: 02h wMaxPacketSize: 64 bInterval: 0 bRefresh: 0 bSynchAddress: 0 005/001 0000/0000 - Unable to fetch manufacturer string - Unable to fetch product string - Unable to fetch serial number string wTotalLength: 25 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: 40h MaxPower: 0 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 1 bInterfaceClass: 9 bInterfaceSubClass: 0 bInterfaceProtocol: 0 iInterface: 0 bEndpointAddress: 81h bmAttributes: 03h wMaxPacketSize: 2 bInterval: 255 bRefresh: 0 bSynchAddress: 0 004/001 0000/0000 - Unable to fetch manufacturer string - Unable to fetch product string - Unable to fetch serial number string wTotalLength: 25 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: 40h MaxPower: 0 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 1 bInterfaceClass: 9 bInterfaceSubClass: 0 bInterfaceProtocol: 0 iInterface: 0 bEndpointAddress: 81h bmAttributes: 03h wMaxPacketSize: 2 bInterval: 255 bRefresh: 0 bSynchAddress: 0 003/002 046D/C501 - Unable to fetch manufacturer string - Unable to fetch product string wTotalLength: 34 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: a0h MaxPower: 25 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 1 bInterfaceClass: 3 bInterfaceSubClass: 1 bInterfaceProtocol: 2 iInterface: 0 bEndpointAddress: 81h bmAttributes: 03h wMaxPacketSize: 8 bInterval: 10 bRefresh: 0 bSynchAddress: 0 003/001 0000/0000 - Unable to fetch manufacturer string - Unable to fetch product string - Unable to fetch serial number string wTotalLength: 25 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: 40h MaxPower: 0 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 1 bInterfaceClass: 9 bInterfaceSubClass: 0 bInterfaceProtocol: 0 iInterface: 0 bEndpointAddress: 81h bmAttributes: 03h wMaxPacketSize: 2 bInterval: 255 bRefresh: 0 bSynchAddress: 0 002/001 0000/0000 - Unable to fetch manufacturer string - Unable to fetch product string - Unable to fetch serial number string wTotalLength: 25 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: 40h MaxPower: 0 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 1 bInterfaceClass: 9 bInterfaceSubClass: 0 bInterfaceProtocol: 0 iInterface: 0 bEndpointAddress: 81h bmAttributes: 03h wMaxPacketSize: 2 bInterval: 255 bRefresh: 0 bSynchAddress: 0 001/001 0000/0000 - Unable to fetch manufacturer string - Unable to fetch product string - Unable to fetch serial number string wTotalLength: 25 bNumInterfaces: 1 bConfigurationValue: 1 iConfiguration: 0 bmAttributes: 40h MaxPower: 0 bInterfaceNumber: 0 bAlternateSetting: 0 bNumEndpoints: 1 bInterfaceClass: 9 bInterfaceSubClass: 0 bInterfaceProtocol: 0 iInterface: 0 bEndpointAddress: 81h bmAttributes: 03h wMaxPacketSize: 2 bInterval: 12 bRefresh: 0 bSynchAddress: 0 |
|
From: Roger B. <ro...@ro...> - 2004-03-25 18:17:01
|
> Ok. FWIW, it looks like iCal supports vCalendar, iCalendar, and > Entourage formats for import, and exports vCalendar files. vCalendar is also in the VFile format. I have never looked into the spec or implementations to see how bad it is. Hopefully it is way better than vCard simply because there are fewer implementations :-) Roger |
|
From: Tom P. <mlp...@ea...> - 2004-03-25 14:25:24
|
On Mar 25, 2004, at 9:05 AM, Steven Palm wrote: >> Sane - or not - it's the only export format for the MacOS X Address >> Book. I hope I'll be forgiven if ambiguities in the spec are >> resolved arbitrarily in favor of Address Book usage. > > Export format, perhaps, but not the only way to get that data out. > You can extract bits through the AddressBook API provided by Apple, so > perhaps a small C library wrapped by SWIG would allow Python to > interact with AddressBook in a much more useful fashion. That's a good idea. I'll probably still go for vCard export/import first. > I started looking at this, but didn't get very far as my spare time is > non-existant these days. iCal has no API yet, so you are stuck with > using AppleEvents or just dealing with the raw data files. Ok. FWIW, it looks like iCal supports vCalendar, iCalendar, and Entourage formats for import, and exports vCalendar files. Thanks, Tom |
|
From: Steven P. <n9...@n9...> - 2004-03-25 14:05:53
|
On Mar 25, 2004, at 12:19 AM, Tom Pollard wrote: > On Mar 25, 2004, at 1:06 AM, Roger Binns wrote: > Sane - or not - it's the only export format for the MacOS X Address > Book. I hope I'll be forgiven if ambiguities in the spec are resolved > arbitrarily in favor of Address Book usage. Export format, perhaps, but not the only way to get that data out. You can extract bits through the AddressBook API provided by Apple, so perhaps a small C library wrapped by SWIG would allow Python to interact with AddressBook in a much more useful fashion. I started looking at this, but didn't get very far as my spare time is non-existant these days. iCal has no API yet, so you are stuck with using AppleEvents or just dealing with the raw data files. |
|
From: Roger B. <ro...@ro...> - 2004-03-25 06:57:10
|
> I hope I'll be forgiven if ambiguities in the spec are resolved > arbitrarily in favor of Address Book usage. Whoever actually writes the code gets first pick as to how it is done. Anyone else concerned can supply patches :-) Roger |
|
From: Tom P. <mlp...@ea...> - 2004-03-25 06:17:32
|
On Mar 25, 2004, at 1:06 AM, Roger Binns wrote: >> What's the current status of the code supporting vcard import and >> export of phonebook entries? I see the vcard.py file, but it doesn't >> appear to be used anywhere. (I probably just didn't look hard >> enough...) > > You did look hard enough :-) I was afraid of that. > The VFile class needs a little more to be completed, as is noted > in the comments. > > The VCard class then needs to translate elements into a table > (think like a CSV file). None of this code has been written > yet. Ok. > You may also be under the impression that Vcard is somehow > a sane and sensible format. It isn't. Bummer. > A human will have > a hard enough time understanding one correctly, let alone > a machine. There is a lot of ambiguity in the format, and > in different versions of the format, and I didn't actually > find any program that 100% conforms to the spec anyway. Sane - or not - it's the only export format for the MacOS X Address Book. I hope I'll be forgiven if ambiguities in the spec are resolved arbitrarily in favor of Address Book usage. > I did gather up examples of every format I saw out there. > You can find it in examples/vcards.vcf This will make a nice > project for someone :-) :-), indeed. Thanks, Tom |
|
From: Roger B. <ro...@ro...> - 2004-03-25 06:06:44
|
> What's the current status of the code supporting vcard import and > export of phonebook entries? I see the vcard.py file, but it doesn't > appear to be used anywhere. (I probably just didn't look hard > enough...) You did look hard enough :-) The VFile class needs a little more to be completed, as is noted in the comments. The VCard class then needs to translate elements into a table (think like a CSV file). None of this code has been written yet. You may also be under the impression that Vcard is somehow a sane and sensible format. It isn't. A human will have a hard enough time understanding one correctly, let alone a machine. There is a lot of ambiguity in the format, and in different versions of the format, and I didn't actually find any program that 100% conforms to the spec anyway. I did gather up examples of every format I saw out there. You can find it in examples/vcards.vcf This will make a nice project for someone :-) Roger |
|
From: Tom P. <mlp...@ea...> - 2004-03-25 04:36:51
|
Hi, What's the current status of the code supporting vcard import and export of phonebook entries? I see the vcard.py file, but it doesn't appear to be used anywhere. (I probably just didn't look hard enough...) Thanks, TomP |
|
From: Roger B. <ro...@ro...> - 2004-03-22 21:59:44
|
> The Curitel application that was used to communicate with the CDM8900 > was the one for the TX95C found at the following link: Thanks. > Warning: Do not write to your phone using > this application - apparently it corrupts your phone if you do (a slight > difference in the phone book format). I will eventualy write, but be very careful. The phone is a loaner from RPI Wireless and I don't actually have it activated, but am still careful nonetheless. After looking at some traces, the news is that the phone has an explicit sync protocol for phonebook and calendar, and that it just does filesystem access for SMS. Roger |
107 messages has been excluded from this view by a project administrator.
