Date: 2007-10-09 15:04
Sender: Ludovic Rousseau
This "bug" should be closes in revision 2635
If you have problems please open a new bug.
Thomas Harning, I can't reproduce your problem. |
Date: 2007-07-31 17:23
Sender: Thomas Harning
Correction to my previous post about it working w/ 32-64 interop:
Using the 1.4.0 patch, PCSC-Lite mostly works, however it does not work well w/ TokenStatus called from a 32-bit app:
It does not return failure-state when the token is removed.
It does not fill in the ATR.
This was a nasty bug to discover... since I was thinking that it was in my app, rather than PCSC-Lite... |
Date: 2007-07-23 03:41
Sender: Eric Andry
Mr. Hutzelman,
Your right, I should have said what kind of card reader I am using. My Dell D820 laptop's internal card reader DOES work when I was running FC6 x86_64.
I've upgraded to F7, and the card reader works when using all 32-bit drivers and OS. I knew the support for 64-bit to 32-bit server communication would take a while, so when F7 came out, I opted for 32-bit. |
Date: 2007-07-20 21:46
Sender: Jeffrey Hutzelman
Eric:
You haven't said exactly what Dell laptop you have, but chances are the internal reader didn't work because it's simply not supported. Sufficiently recent machines have an O2Micro reader (USB ID 0b97:7772) which is not supported by the CCID driver today, but will be shortly -- Chaskiel and I worked out what was needed a couple of days ago, and I'll be sending patches as soon as I have a spare moment.
As for other status, I'm not sure. I was going to work up a patch to allow a new server to handle both old and new clients, but simply haven't had a chance -- I've been very busy the last couple of months getting our F7 support ready here, and PC/SC simply hasn't been on the radar (except for getting my new laptop to work :-)). I expect to have some time to spend on this starting the week after next.
I don't know if there are any other issues preventing integration of Jacob's patches. If not, then maybe it's better to do so now than to wait for the backwards-compatibility stuff. That's up to Ludovic.
-- Jeff |
Date: 2007-07-20 21:26
Sender: Thomas Harning
I've tried both patches and they work on AMD64 w/ 32-64 interop...
Has there been any more progress on this bug? |
Date: 2007-05-28 17:08
Sender: Eric Andry
You might want to try a distro that's setup to work with mixed 64-bit/32-bit like FC6.
I run FC6 x86_64 kernel on a Dell laptop that has the Core 2 Duo.
It separates 32-bit from 64-bit libs with the structure:
/lib64
/usr/lib64
vise
/lib
/usr/lib
When I wanted to test the 64-bit patched daemon I compiled, targeted, and installed to
/usr/local/lib64
/usr/local/bin
and kept the /etc/init.d/pcscd
and /usr/sbin/bin/pcscd
script and binary.
Then I modified the startup script to point to the patched binary rather than the one from the distribution.
Since my last post, I also tried removing all 64-bit pcsc packages and drivers and installed 32-bit daemon, associated tools, ccid, and libcoolkey. The combination x86_64 kernel and 32-bit ccid driver worked with an external keyboard with built-in smart card reader. However the laptop internal reader did not work. I'm not a kernel/C/C++ hacker to understand why the 32-bit ccid driver worked with the keyboard and not the internal reader.
So I'm back to square one with 64-bit pcsc*, ccid, and libcoolkey.
Just let me know when you have a patch you'd like me to test out. |
Date: 2007-05-28 13:07
Sender: Ludovic Rousseau
I can't "mount --bind /var/run /chroot/var/run" since /chroot/var/run contains files for other daemons (ssh for example)
But I can configure pscsc-lite with --enable-ipcdir=/whatever_shared_dir and share this directory in both worlds. Thanks for the idea. |
Date: 2007-05-28 12:51
Sender: jacob berkman
can you mount --bind /var/run /chroot/var/run ?
(when using chroots, i also usually do /dev and /proc as well) |
Date: 2007-05-28 09:41
Sender: Ludovic Rousseau
I now have access to a 32/64-bits machine (iMac with Core2Duo) but I don't know how to setup the configuration so that I can have 32-bits applications inside my 64-bits distribution (Debian etch).
I have a 32-bits chroot to make tests but the /var/run/ directory is not shared between 32 and 64-bits worlds.
Do you have any documentation on how to setup a system like yours? |
Date: 2007-05-16 06:11
Sender: Ludovic Rousseau
Jeffrey Hutzelman, please do not wait after Jabob's patch to be integrated. It is best to have a global solution from the beginning.
So, if you can, post here a global patch with every thing working. |
Date: 2007-05-16 01:41
Sender: Eric Andry
Wow that's great that I could start the wheels churning again with this issue!
Seriously, I volunteer to continue to test new patches as you release them. I'm already setup to easily swap out vendor provided 64-bit pcscd daemon with one built from source.
Also in addition to testing with pcsc_scan, I will also be testing with libcoolkey (both 64-bit and 32-bit) and pam_pkcs11 module.
Thank you for your continued awesome work! If I can help let me know. |
Date: 2007-05-16 00:17
Sender: Jeffrey Hutzelman
OK. Given that the protocol major version changes, I think I can see how to make a pcscd that can talk to old 32-bit, old 64-bit and new clients. Once Jabob's patch is stabilized and integrated, I'll work up a patch to add backward-compatibility. Also, XXX has convinced me that it's probably not a big deal if you can't run PPC PC/SC applications within Rosetta.
That just leaves testing. The offer of a 64-bit VM still stands, though I'll have to dig around a bit to find a reader I can use for that. The easiest thing to come up with is probably a cryptoflex e-gate card. |
Date: 2007-05-15 22:23
Sender: Jeffrey Hutzelman
Sure, but won't the PPC application also be linked against a PPC version of libpcsclite, which will also be emulated? I can't imagine this working any other way; allowing calls from PPC code to x86 libraries is infeasible except when the emulator completely understands the ABI and thus knows things like which parts of a structure are words that require byte-swapping.
Similarly, the emulator can't know that aboud data structures written to disk or sent over the network or to another process, so it can't convert those, either. So if you want PPC and x86 programs to communicate with each other, the message formats they use need to not depend on the host byte order.
Now, we don't currently support MacOS in our computing environment, so I don't much care if the byte-order issue is addressed or not. But I do think it's a real issue, and if a backward-incompatible protocol change is needed anyway to deal with the word size problem, then it seems like a perfect opportunity to kill two birds with one stone.
|
Date: 2007-05-15 19:59
Sender: Ludovic Rousseau
> On machines like intel-based Mac's, you can have software using both byte orders on the same machine. So, a PPC application would not be able to talk to an x86 pcscd, because of the byte order problem.
No. The PPC application is _emulated_ using Rosetta. And I hope Rosetta will switch the bytes when needed. The PPC application will not talk directly to pcscd or to libpcsclite.
But I am not sure a PowerPC PC/SC application is supposed to run within Rosetta. |
Date: 2007-05-15 17:53
Sender: Jeffrey Hutzelman
Hm; I don't think I ever answered this:
> What would be the benefit of using the network byte order?
On machines like intel-based Mac's, you can have software using both byte orders on the same machine. So, a PPC application would not be able to talk to an x86 pcscd, because of the byte order problem.
Incidentally, I was originally OK with making a backward-incompatible change to the wire protocol and requiring people to upgrade pcscd and clients at the same time. However, now that there are Linux distributions which include pcsc-lite and ship both 32- and 64-bit libraries, we're going to start seeing problems like Eric Andry's, where people try to build pcsc-lite from source and it doesn't interop with the vendor's pcscd (or, they install the new one and it doesn't interop with the vendor's apps). It would be nice if we could figure out how to prevent this, at least in the common cases. |
Date: 2007-05-15 17:30
Sender: Jeffrey Hutzelman
I can set up a VM for this purpose; contact me directly and we'll work out the details. |
Date: 2007-05-15 16:35
Sender: Ludovic Rousseau
I first need to setup a 32/64-bits machine. I do not own one so I have wait until I can access one and test the proposed patch. |
Date: 2007-05-15 04:21
Sender: Eric Andry
Hello.
I'm trying to use the x86_64 patch that was posted for theon pcsc-lite-1.4.0 source.
I'm running FC6 x86_64 with kernel 2.6.20-1.2948.fc6
My options for configure:
./configure --libdir=/usr/local/lib64 --enable-usbdropdir=/usr/lib64/pcsc/drivers --enable-daemon --enable-libusb
I've installed and am testing pcscd running as follows:
./pcscd -f -d
All seems to startup and run okay. But when I attempt to use existing
pcsc_scan tool from FC6 package pcsc-tools-1.4.8-1.fc6.x86_64 I get the message:
$ pcsc_scan
PC/SC device scanner
V 1.4.8 (c) 2001-2006, Ludovic Rousseau <ludovic.rousseau@free.fr>
Compiled with PC/SC lite version: 1.3.1
winscard_clnt.c:416:SCardEstablishContextTH() Your pcscd is too old and does not support CMD_VERSION
SCardEstablishContext: Cannot Connect to Resource Manager 80100013
I also attempted compile pcsc-tools-1.4.8 from source and it also gave the same error message.
I really would like to have the ability to use pcscd with 32-bit clients because
many of the plugins I use (including Citrix) still do not support 64-bit browsers.
|
Date: 2007-04-12 18:03
Sender: jacob berkman
Hello Ludovic,
I've done a new patch, changing only the internal wire protocols as you suggest. It was indeed a little bit trickier, but not too difficult.
I've included a "wirecheck" program which will check for changes to the structs that are not word-size compatible. Even thought it is a generated file, pcsc-wirecheck-dist.c should *not* normally be rebuilt; only when you know you are breaking compatibility. We used a similar tool when I worked on Lustre.
I've uploaded the new patch to:
http://off.net/~jacob/pcsc-lite-1.4.0-64bit-compat2.patch
Note that while this patch retains both binary and source compatibility with previous versions, it does break the wire protocol and so pkcs11 modules with forked versions of pcsc-lite (i've run into a couple) will break. I am ok with that.
|
Date: 2007-04-10 07:04
Sender: Ludovic Rousseau
Thanks for the patch.
It is nice but this is an user API change since user code has to be changed to replace some %ld by %d. I don't think I want this.
I was thinking of only changing the communication between libpcsclite and pcscd. I think it should work just by changing the types used in winscard_msg.h |
Date: 2007-04-09 16:01
Sender: jacob berkman
I've written a patch to address this problem; it is available at:
http://off.net/~jacob/pcsc-lite-1.3.2-64bit-compat.patch
After some soul-searching, I decided take a route that should have less pain in the long run, at the possible cost of some short-term pain. I decided to change the offending typedefs in wintypes.h to match what their sizes would be on Windows (DWORD in win64 is still 32 bits, as is LONG i believe).
Because this changes the signature of functions and structs, I've bumped the sonumber on the libraries. I thought about only doing this for 64-bit, since this really doesn't change anything for 32-bit, but that seems like more long-term pain that it is worth.
After making this change, I am able to use certificates in a 32-bit mozilla talking to a 64-bit pcscd.
|
Date: 2006-08-27 10:34
Sender: Ludovic Rousseau
connecté user_id=2410You are rigth. I know see why Apple uses explicit sizes in ths pcsc-lite headers files.
What would be the benefit of using the network byte order? The protocol is supposed to be local to a same machine. |
