IFB_LLLBINARY: Problem unpacking field 55 (java.lang.ArrayIndexOutOfBoundsException: arraycopy: last source index 391 out of bounds for byte[321])

[juan esteban sepulveda]

Good day fellow programmers

I hope you are doing well

 I am trying to send several transactions to a switch, an echo test already sends me correctly and I successfully get a response, but as soon as I try to send a simulated purchase with field 55, it throws me the following error:

 org.jpos.iso.IFB_LLLBINARY: Problem unpacking field 55 (java.lang.ArrayIndexOutOfBoundsException: arraycopy: last source index 391 out of bounds for byte[321]) unpacking field=55, consumed=115

I have changed the class of my <isofieldpackager/> for all the Class summary found in org.jpos.iso
<isofieldpackager
         id="55"
         length="999"
         name="DATA EMV"
         emitBitmap="false"
         packager="org.jpos.iso.packager.GenericSubFieldPackager"
         class="org.jpos.iso.IFB_LLLBINARY">

But none works properly for me, the one that comes closest to my task, which is to be able to process field 55, is org.jpos.iso.IFB_LLLBINARY, since in the specification of the switch it receives it is a Binary field with variable length without Bitmap

Does anyone know what could be causing this problem and how to fix it? 

[Alejandro Revilla]

What's inside your <isofieldpackager> element?

I'd try with an opaque field first, like this:

  <isofield
      id="55"
      length="999"
      name="EMV Data"
      class="org.jpos.iso.IFB_LLLBINARY" />

--

@apr

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/1eb7d35a-3bec-42ba-9984-d6e57579ec3dn%40googlegroups.com.

[juan esteban sepulveda]

This is my information that contains the DE 55 

<isofieldpackager
        id="55"
        length="999"
        name="DATA EMV"
        emitBitmap="false"
        packager="org.jpos.iso.packager.GenericSubFieldPackager"
        class="org.jpos.iso.IFB_LLLBINARY">

<isofield
            id="40742"
            length="8"
            name="APPLICATION CRYPTOGRAM"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40743"
            length="1"
            name="CRYPTOGRAM INFORMATION DATA"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40720"
            length="32"
            name="ISSUER APPLICATION DATA"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40759"
            length="4"
            name="UNPREDICTABLE NUMBER"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40758"
            length="2"
            name="APPLICATION TRANSACTION COUNTER"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="149"
            length="5"
            name="TERMINAL VERIFICATION RESULT"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="154"
            length="3"
            name="TRANSACTION DATE"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="156"
            length="1"
            name="TRANSACTION TYPE"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40706"
            length="6"
            name="AMOUNT AUTHORIZED"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="24362"
            length="2"
            name="TRANSACTION CURRENCY CODE"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="130"
            length="2"
            name="APLICATION INTERCHANGE PROFILE"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40730"
            length="2"
            name="TERMINAL COUNTRY CODE"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40756"
            length="3"
            name="CARDHOLDER VERIFICICATION METHOD RESULTS"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40755"
            length="3"
            name="TERMINAL CAPABILITY PROFILE"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40707"
            length="6"
            name="AMOUNTH OTHER"
            class="org.jpos.iso.IFA_BINARY"/>

         <isofield
            id="40734"
            length="8"
            name="IFD SERIAL NUMBER"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="132"
            length="16"
            name="DEDICATED FILE NAME"
            class="org.jpos.iso.IFA_BINARY"/>

       <isofield
            id="40737"
            length="3"
            name="TRANSACTION TIME"
            class="org.jpos.iso.IFA_BINARY"/>
        <isofield
            id="40757"
            length="1"
            name="TERMINAL TYPE"
            class="org.jpos.iso.IFA_BINARY"/>

</isofieldpackager>

[juan esteban sepulveda]

My field 55 data in the iso message has the following structure: field 55 length + tag in hexadecimal + tag value in hexadecimal bytes (these last two are repeated until the end of the field 55 tags that are being sent)

[juan esteban sepulveda]

Getting the same problem when running the packager like this:

org.jpos.iso.IFB_LLLBINARY: Problem unpacking field 55 (java.lang.ArrayIndexOutOfBoundsException: arraycopy: last source index 391 out of bounds for byte[321])

El jueves, 11 de agosto de 2022 a las 19:35:37 UTC-5, a...@jpos.org escribió:

[Andrés Alcarraz]

Hi Juan,

The problem may be before, in an earlier field. If you configure the packager for debugging, you can see if previous fields were unpacked correctly, add something like this to your channel configuration file if you didn’t already:

<property name="packager-logger" value="Q2"/>
<property name="packager-realm" value="packager-debug"/>

Hope this helps.

Andrés Alcarraz

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/b26c80f6-7e33-4c1f-b0cd-dba4fd471645n%40googlegroups.com.

​

[juan esteban sepulveda]

Thank you very much I didn't have this

I was analyzing the information before field 55, but everything is correct and it is processed as expected

I get this error after adding the code you mentioned above:

org.jpos.iso.IFB_LLLBINARY: Problem unpacking field 55

      <nested-exception>

      java.lang.ArrayIndexOutOfBoundsException: arraycopy: last source index 391 out of bounds for byte[321]

    at java.base/java.lang.System.arraycopy(Native Method)
    at org.jpos.iso.LiteralBinaryInterpreter.uninterpret(LiteralBinaryInterpreter.java:53)
    at org.jpos.iso.ISOBinaryFieldPackager.unpack(ISOBinaryFieldPackager.java:129)
    at org.jpos.iso.ISOMsgFieldPackager.unpack(ISOMsgFieldPackager.java:87)
    at org.jpos.iso.ISOBasePackager.unpack(ISOBasePackager.java:306)
    at org.jpos.iso.ISOMsg.unpack(ISOMsg.java:479)
    at org.jpos.iso.BaseChannel.unpack(BaseChannel.java:976)
    at org.jpos.iso.BaseChannel.receive(BaseChannel.java:746)
    at org.jpos.iso.ISOServer$Session.run(ISOServer.java:344)
    at org.jpos.util.ThreadPool$PooledThread.run(ThreadPool.java:76)
      </nested-exception>

I can't show the information inside field 55, since it is real card information, but if it helps, I'm trying to send the Length in BCD encoding with a maximum of 3 digits (ie LLLVAR), and the value is = 0274 ← this is the total of digits that are in field 55, if I send the message directly to the Host to which I try to forward this information, it responds correctly without any problem

Could the error be due to another cause? :(

[murtuza chhil]

Please see the testcases for https://github.com/jpos/jPOS/blob/master/jpos/src/test/java/org/jpos/iso/IFB_LLLBINARYTest.java

See if the length indicator as shown in the test data aligns with how your data is setup.

You can set up the tests with your data to pack (this will give you what the length indicator needs to be as compared to what you have). 

-chhil

[juan esteban sepulveda]

Thank you all very much for your help, thanks to you I was able to correctly identify the problem, the solution to the problem was to change the Class of field 55 from IFB_LLLBINARY to IFB_LLLNUM, since it is the one that accepts a length in BCD

[juan esteban sepulveda]

Hi Again 

It is not completely solved, you know how I can get to use a BCD length (For example: 0274) but with the values in Binary, the IFB_LLLNUM worked for me because it handles the Length in BCD, but in the end I change the value when I receive it :(

[juan esteban sepulveda]

I don't fully understand what I should do with this, if it's not too much trouble, could you give me some documentation of what I should do with these test classes or any suggestions? I am relatively new to Jpos. I have already read the General Jpos Documentation, but I consider that I am still a newbie about this.

El martes, 16 de agosto de 2022 a las 3:02:25 UTC-5, chi...@gmail.com escribió:

[Alejandro Revilla]

Hi Juan Esteban,

You probably want to use IFB_LLLHBINARY

And BTW, sorry for the cryptic naming convention, it comes from old '#defines' in my very old POS C library, back from the late 80s. 'IF' stands for ISO Field, then B for binary, A for ASCII, but I soon ended up with quite a mess, because you have EBCDIC fields, then mixed stuff where the length is encoded in one way, and the actual field content in another one.

Let us know if IB_LLLHBINARY works for you. I think it will as we use it a lot on some major networks.

--

@apr

[murtuza chhil]

You could provide the DE55 (with the length) after manually parsing it by hand and replacing value with X's (since you have mentioned is prod data) for the TLVs (tag length value) so we can assist determining the packager. 

-chhil

[Vladimir Kotovich]

Try using the following config (just DE55 part):

<isofieldpackager id="55"

  length="999"
  name="EMV Smart Card Specific Data"
  class="org.jpos.iso.IFB_LLLBINARY"
  pad="true"
  emitBitmap="false"
  packager="org.jpos.tlv.packager.bertlv.BERTLVBinaryPackager">
  <isofield
    id="0"
    length="999"
    pad="true"
    name="RESERVED ISO"
    class="org.jpos.iso.IFA_TTLLBINARY"/>
</isofieldpackager>

it disassmbles DE55 on the fields by using BERTLV algorithm without every single field definition. it looks something like

четверг, 18 августа 2022 г. в 01:39:56 UTC+3, jjjuan...@gmail.com:

[juan esteban sepulveda]

Hi good day

Thanks for your quick response

I tried what you suggest, but I still get the same error, but now with a higher difference in last read source:

org.jpos.iso.IFB_LLLHBINARY: Problem unpacking field 55 (java.lang.ArrayIndexOutOfBoundsException: arraycopy: last source index 745 out of bounds for byte[321]) unpacking field=55, consumed=115

Thank you very much for the explanation of cryptic naming convention :D, now I understand much better what each class means with this cryptic naming convention

[juan esteban sepulveda]

Of course, this is how I send my field 55:

This is ordered, for a better visualization:

Legth: 0274
9f26 08 XXXXXXXXXXXXXXXX
9f27 01 XX
9f10 12 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
9f37 04 XXXXXXXX
9f36 02 XXXX
95 05 XXXXXXXXXX
9a 03 XXXXXX
9c 01 XX
9f02 06 XXXXXXXXXXXX
5f2a 02 XXXX
82 02 XXXX
9f1a 02 XXXX
9f03 06 XXXXXXXXXXXX
9f33 03 XXXXXX
9f34 03 XXXXXX
9f35 01 XX
9f21 03 XXXXXX
84 07 XXXXXXXXXXXXXX
9f1e 08 XXXXXXXXXXXXXXXX

And this is how it is sent in the purchase I am working with:

02749f2608XXXXXXXXXXXXXXXX9f2701XX9f1012XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9f3704XXXXXXXX9f3602XXXX9505XXXXXXXXXX9a03XXXXXX9c01XX9f0206XXXXXXXXXXXX5f2a02XXXX8202XXXX9f1a02XXXX9f0306XXXXXXXXXXXX9f3303XXXXXX9f3403XXXXXX9f3501XX9f2103XXXXXX8407XXXXXXXXXXXXXX9f1e08XXXXXXXXXXXXXXXX

[juan esteban sepulveda]

Thank you very much for the answer, but I keep getting the same error :( 

 

[Alejandro Revilla]

Please try IFB_LLHBINARY instead of IFB_LLLHBINARY.

--

@apr

[juan esteban sepulveda]

This class does not work for me, because the length must be 3(LLLVAR) :( , If it helps, this would be the structure of the DE 55 that I have, but without compromising my production information:

Legth: 0274
9f26 08 XXXXXXXXXXXXXXXX
9f27 01 XX
9f10 12 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
9f37 04 XXXXXXXX
9f36 02 XXXX
95 05 XXXXXXXXXX
9a 03 XXXXXX
9c 01 XX
9f02 06 XXXXXXXXXXXX
5f2a 02 XXXX
82 02 XXXX
9f1a 02 XXXX
9f03 06 XXXXXXXXXXXX
9f33 03 XXXXXX
9f34 03 XXXXXX
9f35 01 XX
9f21 03 XXXXXX
84 07 XXXXXXXXXXXXXX
9f1e 08 XXXXXXXXXXXXXXXX

And this is how it is sent in the purchase I am working with:

02749f2608XXXXXXXXXXXXXXXX9f2701XX9f1012XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX9f3704XXXXXXXX9f3602XXXX9505XXXXXXXXXX9a03XXXXXX9c01XX9f0206XXXXXXXXXXXX5f2a02XXXX8202XXXX9f1a02XXXX9f0306XXXXXXXXXXXX9f3303XXXXXX9f3403XXXXXX9f3501XX9f2103XXXXXX8407XXXXXXXXXXXXXX9f1e08XXXXXXXXXXXXXXXX

[Alejandro Revilla]

IFB_LLLHBINARY is probably the right one then.

--

@apr

[juan esteban sepulveda]

I think the same, but with IFB_LLLBINARY I think that it continues to interpret the Length of DE 55 in Binary, not in BCD

[juan esteban sepulveda]

I just understood, that with IFB_LLLBINARY I take the length in BCD, but the value of DE 55 takes 274 Hexadecimal Bytes, but what I need is that it takes 274 Characters of DE 55, is there any way to do this?

[Alejandro Revilla]

IFB_LLLBINARY will interpret the two bytes 02 74 as 274 bytes.

IFB_LLLHBINARY will interpret the two bytes 02 74 as 628 bytes.

I think what you might need is a packager that interprets the '02 74' bytes as 274 nibbles (half-bytes).

We have IFB_LLHEX for that, but it's just for LL kind of fields. You'd need an IFB_LLLHEX that we don't have.

I just added it to jPOS 2.1.8-SNAPSHOT and jPOS 3.0.0-SNAPSHOT.

Can you give it a try?

--

@apr

[juan esteban sepulveda]

Good day

I already tried and processed the DE55 correctly, as I expected, thank you very much for the help :D

--

--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3D%3Dm8707bzPn%3DvkPnCxsmf7TCkjWSSgz-H95z2eLauz7qg%40mail.gmail.com.

[Alejandro Revilla]

Great! Thank you for letting us know.

--

@apr