I've installed an applet I've written onto a smartcard - but when sending commands to it, keep getting the 61 xx response. This doesn't happen when I run it in JCIDE, only when on an actual card.
I understand that a response of 61 xx means 'response bytes remaining' and that the xx is how many bytes of data are left - but I'm not sure why this happens. Does the Le of the command APDU need to specify the number of bytes in response? Do I need do get the response somehow (and how do I do this)? or is there another reason I am getting this error?
I have written other applets using the same code (see below) and not had this issue
apdu.SetOutgoing();
apdu.setOutGoingLength(length);
apdu.sendByteslOng(buff, offset, length);
61xx is not an error, but a warning, see ISO 7816, part 4, section 5.6. Warnings are less severe and still keep their response data (which are discarded for errors).
There 61xx is one of the easiest status codes (beyond 90 00), because the reaction is simple and clear: send a Get Response command with P3/LE set to the number indicated in SW2 (the xx part of 61xx). The main reason for the status is, that T=0 protocol is unable to send arbitrary many bytes (so it just sends 61xx) or more than 256 bytes in a response (in which case it sends the first chunk and an indication of how many bytes follow-up; if more than 255, only 255 can be shown and repeated Get Response commands are required getting the remaining chunks).
Related
We are trying to read enOcean data from TCP.
The protocol description for enOcean ESP3-Messages says:
As soon as a Sync.-Byte (value 0x55) is identified, the subsequent 4 byte-Header is compared with the corresponding CRC8H value.
If the result is a match the Sync.-Byte is correct. Consequently, the ESP3 packet is detected properly and the subsequent data will be passed.
If the Header does not match the CRC8H, the value 0x55 does not correspond to a Sync.-Byte. The next 0x55 within the data stream is picked and the verification is repeated.
Until now we used a device (client) that automatically closes the connection to our server after the end of a number of messages coming within a very small timeframe (some milliseconds). Therefore we were able to use a simple ByteArrayRawSerializer. Whenever the connection was closed we got the byte array, read the data, found all the sync-Bytes and were able to interpret the messages.
Now there is a new device that is holding the connection for a very long time (several minutes), so we somehow need another way to read the data from the stream. Because there is no End-of-Message-Byte and the SyncByte 0x55 is part of the message and a ByteArrayLengthHeaderSerializer doesn't suit us either we wonder what we could use:
Is there any Deserializer usable for our scenario? Is it possible to writer our own Deserializer (in this specific scenario)? Or is there another (simpler) way we should follow? Maybe use an Interceptor?
You would need to write a custom deserializer.
I am using 3.2.6 (I know its way too old but current project constraints does not allow me to upgrade till next two months) for one of server solution. I do not have control over client.
We have a framedecoder in pipeline to handle the custom message which has a header and body. One of the header fields contains the length of the body. For a specific message, I get a size of 1076 bytes. But while getting the message, I always get 1024 bytes (readableBytes()) and hence decoder fails.
I checked with wireshark (with suitable dissector for the protcol). The client always sends 1076 bytes and puts the same value on the header. So, client does not seem to misbehave.
My receive buffer size is already set to higher value as following on server bootstrap with no apparent effect.
bootstrap.setOption("child.receiveBufferSize", 1*1024*1024);
This is seen consistently only for this specific message and all other messages (whose sizes range from 100 to 1000 bytes) are handled correctly without any issues.
Please let me know what else could cause this issue and how to fix the same?
I have a java program set up that takes MIDI input from a controller and ideally does different things (not necessarily related to playing synthesizer output) depending on which midi note is sent.
My code is heavily based on the code in this SO question: Java getting input from MIDI keyboard, specifically I'm using the entire MidiInputReceiver class. I've modified it to do System.out.println(msg) as well as printing "MIDI received, and it appears to work in as far as every time I press a key from my controller it detects the MIDI and prints the midi msg, but I don't know how to decode the output into something I can decipher, if that's even possible.
The output i'm getting is:
midi received
com.sun.media.sound.FastShortMessage#75b0e2c3
midi received
com.sun.media.sound.FastShortMessage#2ff7ac92
midi received
com.sun.media.sound.FastShortMessage#2d62bdd8
midi received
com.sun.media.sound.FastShortMessage#2d9dc72f
I've been trying to use this Java class http://www.jsresources.org/examples/DumpReceiver.java.html to decode the message, but it only decodes ShortMessages, not FastShortMessages, and I can't find any documentation online about what a FastShortMessage is, much less how to convert from an FSM to an SM. Does anybody have any ideas? Is there an easier way than what I'm doing?
Edit: This might not be the best way, but I just came up with a way that works, I can't answer my own post for 8 hours but I'll post it here in case anybody else needs it.
I just managed to solve my own problem, with the code below.
public void send(MidiMessage msg, long timeStamp) {
// Print to confirm signal arrival
System.out.println("midi received");
byte[] aMsg = msg.getMessage();
// take the MidiMessage msg and store it in a byte array
// msg.getLength() returns the length of the message in bytes
for(int i=0;i<msg.getLength();i++){
System.out.println(aMsg[i]);
// aMsg[0] is something, velocity maybe? Not 100% sure.
// aMsg[1] is the note value as an int. This is the important one.
// aMsg[2] is pressed or not (0/100), it sends 100 when they key goes down,
// and 0 when the key is back up again. With a better keyboard it could maybe
// send continuous values between then for how quickly it's pressed?
// I'm only using VMPK for testing on the go, so it's either
// clicked or not.
}
System.out.println();
}
Sample output for two keys pressed:
midi received
-103
71
100
midi received
-119
71
0
midi received
-103
52
100
midi received
-119
52
0
So aMsg[1] holds the Midi number for each note, which can be referenced anywhere online, I can't post a link due to rep.
The getMessage() and getLength() methods come from http://docs.oracle.com/javase/7/docs/api/javax/sound/midi/MidiMessage.html, I still haven't figured out what a FastShortMessage is, but it might just be leftover legacy code or something? It's com.sun stuff so it's got to be pretty old.
From here I can do a switch() statement on the aMsg[1] with a different case depending on which key is pressed, which is exactly what I was aiming to do, which will be backwards compatible to 1.6 since it's an integer.
FastShortMessage is (indirectly) derived from MidiMessage; just handle it like one.
When you have a ShortMessage, you should use the getCommand/getChannel/getData1/2 functions, which are easier to use than a temporary byte array.
How to download first 125 bytes and 125 last byte file via HTTP protocol ?
I believe you want to send an appropriate Range header. See the HTTP/1.1 spec for more information. Be aware that not all servers will support this, mind you. You may need to transfer the whole file, just to get to the last 125 bytes. Of course, you can get just the first 125 bytes by requesing the whole thing, and then only reading the first 125 bytes before killing the connection.
In theory I believe you should be able to use:
Range: 0-124,-125
Note that this will give interesting results if the full response would be less than 250 bytes...
Accept-Ranges: bytes
Range: bytes=-255
send content-range in request headers for specific range of content as response. but for which the webserver has to support range requests
I am writting a .Net/C# client to a Java Server on Solaris.
The Java server is writting Raw byte data in a Gziped format which I need to extract, but I am having trouble to read the data in the right buffer sizes. I read the message not-deterministicly incomplete or complete and can not read the second message in any case.
I am reading the bytes using the NetworkStream class with the DataAvailable property.
My guess is that it could be related to a little/big endian problem.
Do I need to use a special conversion to change the data from big into little Endian? Do I need to read the necessary bytes using the gzip header?
I used to use the same server with an uncompressed protocol before and had no problem using a StreamReader with the ReadLine function before, but that protocol was purely text based.
Edit: Unfortunately I have no choice as the remote server and protocol is given. Is the endiness part of the GZip format or do I only need to convert the header accordingly? The uncompressed data are pure UTF8-encoded strings with line breaks as delimiters.
The GZIP format is not complex. It is available in all its glory in a simple, accessible specification document, IETF RFC 1952.
The GZIP format specifies the bit-order for bytes. It is not tunable with a flag for endianness. The producer of a GZIP stream is responsible for conforming to the spec in that regard, and a consumer of a GZIP stream, likewise.
If I were debugging this, I would look at the bytes on either end of the wire and verify that the bytes going in are the same as the bytes coming out. That's enough to put aside the endian issues.
If you don't have success transmitting a GZIP bytestream, try transmitting test data - 16 bytes of 0xFF, followed by 16 bytes of 0xAA, etc etc. And then, verify that this is the data coming out the other end.
I'm sorry, I don't know what you mean by I read the message not-deterministicly incomplete or complete and can not read the second message in any case. Second message? What second message? The endianness shouldn't affect the amount of data you receive.
It feels to me that you don't have confidence that you are successfully transmitting data. I would suggest that you verify that before working on endian issues and GZIP format issues.