I have problem with understanding why all the BER-TLV parsers I found:
https://paymentcardtools.com/emv-tlv-parser
https://emvlab.org/tlvutils/
https://chrome.google.com/webstore/detail/tlv-parser/iemijfhdlipdpcjfnphcdalpccnkfedb
Recognize this tag: DF9A03001736 as "invalid", while: DF5603001736 and DF0903001736 work just fine.
What's the difference?
just follow the description provided in EMV Book 3, Annex B1
"invalid" case: DF9A03001736
DF - 1101 1111
9A - 1001 1010 - here, in the second byte of the Tag, the b8 is set (1), which means that 'Another byte follows', so the following byte (value 03) is also part of the Tag
03 - 0000 0011 - the last byte of the Tag, i.e. the actual Tag is DF9A03
so, in our sequence we have:
DF9A03 - Tag
00 - Length (no value)
17 - is already a new Tag
36 - length of the Tag 17 ...
So the parser (https://paymentcardtools.com/emv-tlv-parser) fails because no data is available (Error during parsing Tag 17: Not enough data)
correct example: DF5603001736
DF - 1101 1111
56 - 0101 0110 - there are no more bytes that constitute Tag, so we just have Tag DF56
the sequence is:
DF56 - Tag
03 - Length
001736 - Value
Related
"Request Message 1" is using static table index 31 to send content-type information. Then the entry is added to dynamic table with index value 63. How to derive the dynamic table index value from "Request Message 1"?
Request message 1:
Header: content-type: multipart/related; boundary=++Boundary
Name Length: 12
Name: content-type
Value Length: 38
Value: multipart/related; boundary=++Boundary
content-type: multipart/related; boundary=++Boundary
[Unescaped: multipart/related; boundary=++Boundary]
Representation: Literal Header Field with Incremental Indexing - Indexed Name
Index: 31
Hex dump
5f 9d a6 da 12 6a c7 62 58 b0 b4 0d 25 93 ed 48
cf 6d 52 0e cf 50 7f bf f7 74 f6 d5 20 ec f5
Request message 2:
Header: content-type: multipart/related; boundary=++Boundary
Name Length: 12
Name: content-type
Value Length: 38
Value: multipart/related; boundary=++Boundary
content-type: multipart/related; boundary=++Boundary
[Unescaped: multipart/related; boundary=++Boundary]
Representation: Indexed Header Field
Index: 63
Hex dump : 0xbf (dynamic table index value)
If I understand you right: Your first request marked as "Field with Incremental Indexing". That's mean that this header also had this index in static or dynamic table and it must be added to dynamic table(because it has other value). Dynamic table's first index is 62. It's because static table ends on 61. When header added to dynamic table he get to the top - 62 index (RFC7541-2.3). I will assume that you did not show us the whole request, most likely it had another incremental header, which took a position above this.
MadBard is right. The hex dump of the header shows the first octet is 5f = 01011111.
According to RFC 7541 "6.2.1. Literal Header Field with Incremental Indexing," the first two bits - 01 - indicate the header field is a new one that should be appended to the dynamic table. Since the next 6 bits (011111) are not all 0, they are referencing a header name in the static table. 011111 is the index of the header name to be used in the new header field. 011111 is 31, so it takes the header name at index 31 of the static table, which is "content-type" (see "Appendix A. Static Table Definition" of RFC 7541). The value for the header field is thus composed of the static table name (content-type), and the value which is carried over-the-wire in Request 1. (The value is also Huffman encoded to save a few bytes, which is why we can't read the ASCII directly from the hex dump). This new header is then appended to index 62 of the lookup table. The indices of all previous entries in the dynamic portion of the lookup table are incremented by one (e.g. the previous 62 becomes 63, since it is a FIFO queue).
Another header was added to the dynamic portion of the lookup table after the one of interest, since we can see that the lookup index in Request 2 is 63, not 62, and thus it was bumped up 1 since it was added. If you were to keep monitoring as more headers were added, you would see the index of this particular header would keep incrementing. Eventually it would get evicted from the lookup table when the dynamic table size gets exhausted.
I am trying to read data from sony felica card using pc/sc transparent session and transceive data object.
The response I am getting is for a read without encryption command is
c0 03 00 90 00 92 01 00 96 02 00 00 97 82 00 + Data
But according to the protocol, the response should be
c0 03 00 90 00 92 01 00 96 02 00 00 97 + Data
I am unable to figure out the last 82 00 appended in the response from the card.
Now when I try to authenticate with the card I get
c0 03 01 6F 01 90 00
which is a error in pc/sc. I want to resolve these extra bytes 82 00 which I believe will solve the issue with all the commands which require authentication and encryption.
The response data is BER-TLV encoded (see PC/SC 2.02, Part 3).
In BER-TLV encoding there are several possibilities to encode tag 0x97 with two octets of data 0xD0D1, e.g.:
97|02|D0D1 -- short form (see parsed)
97|8102|D0D1 -- long form with one octet with length (see parsed)
97|820002|D0D1 -- long form with two octets with length (see parsed)
97|83000002|D0D1 -- long form with three octets with length (see parsed)
...
Your reader is using two octets for sending the length of ICC Response data object (which is perfectly valid).
You should parse the response properly...Good luck!
PS: The above means, that the Data part of your truncated responses still contains one extra byte with the response length (i.e. Len|Data)
I'm currently using software called LineView. It generates downtime reason codes for our factory lines. An operator scans the barcodes with an RS232 scanner and it goes into our XL board system.
The software itself generates the barcodes within an internet browser, but I am trying to make it so our own labeling machine can also print out the barcodes. However, the barcodes that are produced by the labeler (and the many online barcode generators I've tried) look longer and do not work.
The data for the example 128 barcode that I am trying to replicate is [SOH]1[STX]65;1067[ETX].
According to the manual:
- The Start of Header character (ASCII 0x01) starts the XL Command packet.
1 - The Serial Address of the XL device (the default is 1).
- The Start of Transmission character (ASCII 0x02) marks the start of the actual command.
65; - The ID of the Production State > Set Reason Code command.
The Reason Code ID (which can range from 1 to 999 for system reasons or 1000 to 1999 for user defined reasons). In my case it is 1067
- The End of Transmission character (ASCII 0x03) ends the XL Command packet.
I have attatched the pictures of what LineView produces (which is what I want it to look like) and what it is currently printing like on our labeller.
When I scan them they both come up with the [SOH]1[STX]65;1067[ETX] code despite them looking different.
Any help with this would be very much appreciated.
Your intended barcode is constructed internally using the following series of Code 128 codewords which correctly represent the ASCII control characters:
103 Start-in-Mode-A (Upper-case and control characters)
65 [SOH] (ASCII 1)
17 1
66 [STX] (ASCII 2)
22 6
21 5
27 ;
99 Switch-to-Mode-C (Double-density numeric)
10 10
67 67
101 Switch-to-Mode-A
67 [ETX] (ASCII 3)
67 Check-digit
106 Stop
Your label printer is printing a barcode representing the literal string [SOH]1[STX]65;1067[ETX] with no ASCII control characters (i.e. left-bracket, S, O, H, right-bracket, ...) using the following internal codewords:
104 Start-in-Mode-B (Mixed-case)
59 [
51 S
47 O
40 H
61 ]
17 1
59 [
51 S
52 T
56 X
61 ]
22 6
21 5
27 ;
99 Switch-to-Mode-C (Double-density numeric)
10 10
67 67
100 Switch-to-Mode-B
59 [
37 E
52 T
56 X
61 ]
57 Check-digit
106 Stop
So you need to work out how to correctly specify ASCII control characters in the input to your labelling machine.
Beginner in Pig, Need help
For all NON - AlphaNumeric, Cast the STRING TO INT
- To be handled without passing each field name separately.
Sample data -
00013425731998101620140402300032736901 00000000AAA001200X111685V00000000
00283335542006120920131010300030003105 00000000AAA001200X117407 00000000
00000000331998101620140402300033128107 00000000AAA001200X111685 00000000
00003902331999090620140402300032545208 00000000AAA001200X111685 00000000
Its a fixedwidth file, mapping details as follow -
orderNumber 1 9
origin 10 10
Startdate 11 18
ModDate 19 26
Identifier 27 36
Code 37 38
CodeType 39 40
Number 41 48
Num 49 114
Either use substr to extract the parts and then cast them or use a regexp. For example for the first two fields:
input = load ... as (line:chararray);
a = foreach input generate SUBSTRING(line, 0, 9) as orderNumber:long, SUBSTRING(line, 9, 10) as origin:chararray;
This way you should be able to convert each part of the input line into the desired components.
Alternatively you could write a UDF that takes a string as input and does the splitting and returns a bag or tuple.
I am using snmpV3 adapter and passing V2 traps to it by using commands as below. It looks like the range for type u (i.e. unsigned) is upto (2^31) - 1 (i.e. 2147483647). I was expecting it to be (2^32) - 1 (i.e. 4294967295).
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483647
Above command generates following log:
trace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 04 7F FF FF FF
dumpv_recv: UInteger: 2147483647 (0x7FFFFFFF)
Where as for:
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483648
Above command generates following log:
enter code heretrace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 05 00 80 00 00 00
dumpv_recv: UInteger: -2147483648 (0x80000000)
Refer to:
http://www.net-snmp.org/docs/man/snmptrap.html
I am using net-snmp v5.5.
Is this the correct behavior or am I missing something?
I have discovered various problems with net-snmp over the years. This is apparently one more. The standards are quite clear. RFC 2578 defines Unsigned32 as follows:
-- an unsigned 32-bit quantity
-- indistinguishable from Gauge32 Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
As noted, this is identical to Gauge32, which is identical to Gauge in SNMPv1 (RFC 1155):
Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
The encoding is correct; all integers within SNMP are encoded as signed, meaning a value above 2^31-1 must be encoded in 5 bytes. Thus the proper translation of the encoding is:
42 Type: Gauge32 or Unsigned32
05 Length: 5 bytes
00 80 00 00 00 Value: 2^31
net-snmp is incorrectly decoding the value.