Why I can't receive APDU buffer contents?

Question

I wrote the following program to return all the APDU buffer contents on reception of each APDU command:

package testPack;

import javacard.framework.APDU;
import javacard.framework.Applet;
import javacard.framework.ISOException;

public class BufferReturner extends Applet {

    private BufferReturner() {
    }

    public static void install(byte bArray[], short bOffset, byte bLength) throws ISOException {
        new BufferReturner().register();
    }

    public void process(APDU arg0) throws ISOException {
        if(selectingApplet()){
            return;
        }
        arg0.setOutgoingAndSend((short)0, (short)255);

    }

}

When I send commands though the contact interface using T=0 protocol, I receive the following result:

Connect successful.
Send: 00 A4 04 00 06 01 02 03 04 05 00 00
Recv: 90 00
Time used: 8.000 ms
Send: 00 00 00 00 10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 00
Send Apdu error: A device attached to the system is not functioning.
Send: 00 00 00 00 10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 00
Recv: 6C FF
Time used: 5.000 ms
Send: 00 00 00 00 10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 FF
Recv: 6C FF
Time used: 5.000 ms
Send: 00 00 00 00 10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 FF
Recv: 6C FF
Time used: 5.000 ms
Send: 00 00 00 00 10 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 FF
Recv: 6C FF
Time used: 6.000 ms
Send: 00 C0 00 00 FF
Send Apdu error: A device attached to the system is not functioning.
Send: 00 C0 00 00 FF
Send Apdu error: A device attached to the system is not functioning.

As you see I can't receive the APDU buffer contents. What's wrong?

Answer 1

Just like with Transmission error for T=0 JavaCards there is nothing wrong with your card and this is kind of "expected" behavior.

For the setOutgoing() method (setOutgoingAndSend() is just a convenience method wrapping setOutgoing()), the Java Card API specification clearly states:

On a case 4 command, the setIncomingAndReceive() must be invoked prior to calling this method. Otherwise, erroneous behavior may result in T=0 protocol.

Hence, what you see is exactly that "erroneous behavior" indicated in the API specification.