[Pcsclite-muscle] IFD polling
William Roberts
bill.c.roberts
Fri Feb 27 18:38:08 PST 2015
On Fri, Feb 27, 2015 at 2:58 PM, Frank Morgner <
morgner at informatik.hu-berlin.de> wrote:
> I doubt that there is a reasonable generic and non-complex way of doing
> this via jni. You said it before, you would have to start the JVM from
> pcscd's process space. I bet you will end up hard wiring any possible
> configuration in the process.
>
I can pass any information in the DEVICENAME needed, just like the
pipe/socket models.
>
> OR you could just delegate the calls to a different Java based process
> (which allows this flexibility) AND use some inter process communication
> between pcscd and your java backend. And then you end up with a socket
> interface a pipe or similar ;-)
>
Both are logically the same, your just replacing function calls to IPC
pipe/socket command interface.
So the quality of the abstraction has to do with the interface design
mostly, not IPC/func call.
In fact I almost have a working bridge. It's a bit more work, but reduces
the amount of memory
consumption on the system (1 less process), and removes one layer of IPC. I
am almost actually done.
One nice thing I can do, is detect based on the methods, and attributes of
the
implementing Java class, whether or not its supporting various things and
handle
some of the rawness of the IFD API. Which the current loader for the .so
can't
handle. The docs say to implement either
IFDHCreateChannelByName or IFDHCreateChannel. However, the loader
requires both symbols in the .so and fails if missing. It should check for
one or
the other, not both (both should be ok too).
Looking at IFDHTransmitToICC() the paramater PSCARD_IO_HEADER RecvPci
is not clear to me. Looking at:
bitbucket.org:mrts/pcsclite-softemu-ifdhandler.git
That code doesn't even use that argument, so I guess
I can ignore it, but whats its purpose?
> Greets, Frank.
>
> On Friday, February 27 at 10:04AM, William Roberts wrote:
> > I might be able to contribute a Generic Java binding for the ifd layer as
> > well.
> >
> > On Fri, Feb 27, 2015 at 8:31 AM, Frank Morgner <
> > morgner at informatik.hu-berlin.de> wrote:
> >
> > > Yes, the documentation needs some love, but I think for a bunch of
> spare
> > > time projects its quite OK. I'll move the example cases to the sub
> > > components where the generic use is outlined, too.
> > >
> > > Am 25. Februar 2015 21:24:19 MEZ, schrieb Martin Paljak <
> > > martin at martinpaljak.net>:
> > >>
> > >> Hello Frank,
> > >>
> > >> Maybe you should publicise your virtualsmartcard project better or
> > >> have the architecture or more precisely, various use cases, documented
> > >> even better or integrate the knowledge of these projects into
> > >> mainstream documentation. I did not look that much into it before
> > >> because I just did not understand what it was or if it related to
> > >> something I could use. Because most of the documentation was about
> > >> "virtual smart cards" and "nPA" and other German-specific terms, I
> > >> figured out that probably not relevant for me.
> > >>
> > >> BUT it turned out that your project contains a lot of useful universal
> > >> APDU/PC/SC layer plumbing stuff that could really be used more (like
> > >> contact->nfc relay, remote ifdhandler etc)
> > >>
> > >> Stuff for what support should be more integrated in open source
> > >> projects, really handy for debugging, testing and prototyping.
> > >>
> > >> Thanks & cheers
> > >> --
> > >> Ma!
> > >> rtin
> > >>
> > >> +372 515 6495
> > >>
> > >>
> > >> On Wed, Feb 25, 2015 at 6:34 PM, Frank Morgner
> > >> <morgner at informatik.hu-berlin.de> wrote:
> > >>
> > >>> You can delegate the calls e.g. by using jni.
> > >>>
> > >>> I am using a simple socket based interface for delegating the ifd
> requests,
> > >>> see
> http://frankmorgner.github.io/vsmartcard/virtualsmartcard/README.html
> > >>> VPCD delegates the calls to everything that listens on the other
> side of the
> > >>> socket. You can find a java implementation of "the other side" in
> this
> > >>> android app
> > >>> http://frankmorgner.github.io/vsmartcard/remote-reader/README.html
> > >>>
> > >>> Am 25. Februar 2015 17:01:19 MEZ, schrieb Jeffrey Hutzelman <
> jhutz at cmu.edu>:
> > >>>
> > >>> On Wed, 2015-02-25 at 07:42 -0800, William Roberts wrote:
> > >>>
> > >>>>
> > >>>> On Wed, Feb 25, 2015 at 7:28 AM, Ludovic Rousseau <
> > >>>> ludovic.rousseau at gmail.com> wrote:
> > >>>>
> > >>>>
> > >>>>> 2015-02-25 12:16 GMT+01:00 William Roberts <
> bill.c.roberts at gmail.com>:
> > >>>>>
> > >>>>>>
> > >>>>>> That's from the client application side. I was looking for a
> java
> > >>>>>>
> > >>>>>
> > >>>>> binding to
> > >>>>>
> > >>>>>>
> > >>>>>> the ifd
> > >>>>>> interface.
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> Why do you want to call the IFD handler directly from Java?
> > >>>>> Why not use the PC/SC
> > >>>>> interface?
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> I am not explaining this properly :-P
> > >>>>
> > >>>
> > >>>
> > >>> Perhaps not.
> > >>>
> > >>> I think what you're asking for is effectively the ability to write
> an
> > >>> IFD handler in Java. For pcsc-lite, I don't think that's realistic
> --
> > >>> it would mean pulling an entire Java interpreter into pcscd. What
> you
> > >>> could do is a bridge that talks to a Java program running in another
> > >>> process, but I think that's going to be more troublesome than it's
> > >>> worth.
> > >>>
> > >>> jPAM in fact does not do this; what it does is let Java applications
> > >>> call PAM, not the other way around. pam-python _does_ let you
> write PAM
> > >>> modules in Python; it does this by spinning up a Python interpreter
> in
> > >>> the PAM module. That works because Python is designed to be
> embedded in
> > >>> a!
> > >>> nother
> > >>> program in this way and because it will be shut down and
> > >>> unloaded when the module is removed, which happens no later than
> when
> > >>> the application calls
> > >>> pam_end().
> > >>>
> > >>> -- Jeff
> > >>>
> > >>>
> > >>> ------------------------------
> > >>>
> > >>>
> > >>> Pcsclite-muscle mailing list
> > >>> Pcsclite-muscle at lists.alioth.debian.org
> > >>>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
> > >>>
> > >>
> > >>
> > >> --
> > >> Frank Morgner
> > >>
> > >> ------------------------------
> > >>
> > >> Pcsclite-muscle mailing list
> > >> Pcsclite-muscle at lists.alioth.debian.org
> > >>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
> > >>
> > >>
> > > ------------------------------
> > >
> > > Pcsclite-muscle mailing list
> > > Pcsclite-muscle at lists.alioth.debian.org
> > >
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
> > >
> > > --
> > > Frank Morgner
> > >
> > > _______________________________________________
> > > Pcsclite-muscle mailing list
> > > Pcsclite-muscle at lists.alioth.debian.org
> > >
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
> > >
> >
> >
> >
> > --
> > Respectfully,
> >
> > William C Roberts
>
> > _______________________________________________
> > Pcsclite-muscle mailing list
> > Pcsclite-muscle at lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>
> --
> Frank Morgner
>
> Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
> OpenPACE http://openpace.sourceforge.net
> IFD Handler for libnfc Devices http://sourceforge.net/projects/ifdnfc
>
> _______________________________________________
> Pcsclite-muscle mailing list
> Pcsclite-muscle at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
>
--
Respectfully,
William C Roberts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pcsclite-muscle/attachments/20150227/7907e941/attachment.html>
More information about the pcsclite-muscle
mailing list