I am using Anki Vector SDK with Python to access Anki Vector robot.
However, the SDK is limited to Python and I want to write Android apps for the Vector.
So I am trying to figure out API endpoints and their parameters together with how to use them. Unfortunately Anki has used GRPC on their SDK to access API endpoints. They also supplied some proto files to use with other languages. However, I could not understand how I can use them.
Instead, I tried GRPC tracing with the following environment variables:
export GRPC_VERBOSITY=DEBUG
//export GRPC_TRACE=list_tracers
//export GRPC_TRACE=all
export GRPC_TRACE=http
I can get the headers for the HTTP call with this method. (example trace log below)
But I can't see the body of the HTTP call (or the streaming content)
How can I get it?
I0105 16:40:33.658871867 2405 chttp2_transport.cc:1702] perform_stream_op[s=0x6c90b2d4]: SEND_INITIAL_METADATA{key=3a 73 63 68 65 6d 65 ':scheme' value=68 74 74 70 73 'https', key=3a 6d 65 74 68 6f 64 ':method' value=50 4f 53 54 'POST', key=3a 61 75 74 68 6f 72 69 74 79 ':authority' value=56 65 63 74 6f 72 2d 4b 38 50 35 'Vector-K8P5', key=3a 70 61 74 68 ':path' value=2f 41 6e 6b 69 2e 56 65 63 74 6f 72 2e 65 78 74 65 72 6e 61 6c 5f 69 6e 74 65 72 66 61 63 65 2e 45 78 74 65 72 6e 61 6c 49 6e 74 65 72 66 61 63 65 2f 50 72 6f 74 6f 63 6f 6c 56 65 72 73 69 6f 6e '/Anki.Vector.external_interface.ExternalInterface/ProtocolVersion', key=61 75 74 68 6f 72 69 7a 61 74 69 6f 6e 'authorization' value=42 65 61 72 65 72 20 6e 49 6f 6f 59 43 49 68 54 51 32 30 47 7a 78 78 4c 63 2b 70 53 67 3d 3d 'Bearer nIooYCIhTQ20GzxxLc+pSg==', key=74 65 'te' value=74 72 61 69 6c 65 72 73 'trailers', key=63 6f 6e 74 65 6e 74 2d 74 79 70 65 'content-type' value=61 70 70 6c 69 63 61 74 69 6f 6e 2f 67 72 70 63 'application/grpc', key=75 73 65 72 2d 61 67 65 6e 74 'user-agent' value=67 72 70 63 2d 70 79 74 68 6f 6e 2f 31 2e 31 37 2e 31 20 67 72 70 63 2d 63 2f 37 2e 30 2e 30 20 28 6c 69 6e 75 78 3b 20 63 68 74 74 70 32 3b 20 67 69 7a 6d 6f 29 'grpc-python/1.17.1 grpc-c/7.0.0 (linux; chttp2; gizmo)', key=67 72 70 63 2d 61 63 63 65 70 74 2d 65 6e 63 6f 64 69 6e 67 'grpc-accept-encoding' value=69 64 65 6e 74 69 74 79 2c 64 65 66 6c 61 74 65 2c 67 7a 69 70 'identity,deflate,gzip', key=61 63 63 65 70 74 2d 65 6e 63 6f 64 69 6e 67 'accept-encoding' value=69 64 65 6e 74 69 74 79 2c 67 7a 69 70 'identity,gzip'} SEND_MESSAGE:flags=0x00000000:len=2 SEND_TRAILING_METADATA{} RECV_INITIAL_METADATA RECV_MESSAGE RECV_TRAILING_METADATA
I0105 16:40:33.659113265 2405 chttp2_transport.cc:1398] perform_stream_op_locked: SEND_INITIAL_METADATA{key=3a 73 63 68 65 6d 65 ':scheme' value=68 74 74 70 73 'https', key=3a 6d 65 74 68 6f 64 ':method' value=50 4f 53 54 'POST', key=3a 61 75 74 68 6f 72 69 74 79 ':authority' value=56 65 63 74 6f 72 2d 4b 38 50 35 'Vector-K8P5', key=3a 70 61 74 68 ':path' value=2f 41 6e 6b 69 2e 56 65 63 74 6f 72 2e 65 78 74 65 72 6e 61 6c 5f 69 6e 74 65 72 66 61 63 65 2e 45 78 74 65 72 6e 61 6c 49 6e 74 65 72 66 61 63 65 2f 50 72 6f 74 6f 63 6f 6c 56 65 72 73 69 6f 6e '/Anki.Vector.external_interface.ExternalInterface/ProtocolVersion', key=61 75 74 68 6f 72 69 7a 61 74 69 6f 6e 'authorization' value=42 65 61 72 65 72 20 6e 49 6f 6f 59 43 49 68 54 51 32 30 47 7a 78 78 4c 63 2b 70 53 67 3d 3d 'Bearer nIooYCIhTQ20GzxxLc+pSg==', key=74 65 'te' value=74 72 61 69 6c 65 72 73 'trailers', key=63 6f 6e 74 65 6e 74 2d 74 79 70 65 'content-type' value=61 70 70 6c 69 63 61 74 69 6f 6e 2f 67 72 70 63 'application/grpc', key=75 73 65 72 2d 61 67 65 6e 74 'user-agent' value=67 72 70 63 2d 70 79 74 68 6f 6e 2f 31 2e 31 37 2e 31 20 67 72 70 63 2d 63 2f 37 2e 30 2e 30 20 28 6c 69 6e 75 78 3b 20 63 68 74 74 70 32 3b 20 67 69 7a 6d 6f 29 'grpc-python/1.17.1 grpc-c/7.0.0 (linux; chttp2; gizmo)', key=67 72 70 63 2d 61 63 63 65 70 74 2d 65 6e 63 6f 64 69 6e 67 'grpc-accept-encoding' value=69 64 65 6e 74 69 74 79 2c 64 65 66 6c 61 74 65 2c 67 7a 69 70 'identity,deflate,gzip', key=61 63 63 65 70 74 2d 65 6e 63 6f 64 69 6e 67 'accept-encoding' value=69 64 65 6e 74 69 74 79 2c 67 7a 69 70 'identity,gzip'} SEND_MESSAGE:flags=0x00000000:len=2 SEND_TRAILING_METADATA{} RECV_INITIAL_METADATA RECV_MESSAGE RECV_TRAILING_METADATA; on_complete = 0x6c90b1b4
I0105 16:40:33.659194720 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: :scheme: https
I0105 16:40:33.659223208 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: :method: POST
I0105 16:40:33.659249145 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: :authority: Vector-K8P5
I0105 16:40:33.659274769 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: :path: /Anki.Vector.external_interface.ExternalInterface/ProtocolVersion
I0105 16:40:33.659301851 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: authorization: Bearer nIooYCIhTQ20GzxxLc+pSg==
I0105 16:40:33.659328569 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: te: trailers
I0105 16:40:33.659354193 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: content-type: application/grpc
I0105 16:40:33.659379036 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: user-agent: grpc-python/1.17.1 grpc-c/7.0.0 (linux; chttp2; gizmo)
I0105 16:40:33.659405129 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: grpc-accept-encoding: identity,deflate,gzip
I0105 16:40:33.659431273 2405 chttp2_transport.cc:1376] HTTP:0:HDR:CLI: accept-encoding: identity,gzip
I0105 16:40:33.659462991 2405 chttp2_transport.cc:1187] HTTP:CLI: Allocating new grpc_chttp2_stream 0x6c90b2d4 to id 1
I0105 16:40:33.659492209 2405 chttp2_transport.cc:852] W:0x6ae19ad8 CLIENT state IDLE -> WRITING [START_NEW_STREAM]
I0105 16:40:33.659522468 2405 chttp2_transport.cc:852] W:0x6ae19ad8 CLIENT state WRITING -> WRITING+MORE [SEND_MESSAGE]
I0105 16:40:33.659557571 2405 chttp2_transport.cc:1249] complete_closure_step: t=0x6ae19ad8 0x6c90b1b4 refs=3 flags=0x0001 desc=op->on_complete err="No Error" write_state=WRITING+MORE
I0105 16:40:33.659641005 2397 writing.cc:413] W:0x6ae19ad8 CLIENT[1] im-(sent,send)=(0,1) announce=5
I0105 16:40:33.659708711 2397 hpack_encoder.cc:473] Encode: ':authority: Vector-K8P5', elem_interned=1 [1], k_interned=1, v_interned=1
I0105 16:40:33.659791937 2397 hpack_encoder.cc:473] Encode: ':path: /Anki.Vector.external_interface.ExternalInterface/ProtocolVersion', elem_interned=0 [2], k_interned=1, v_interned=0
I0105 16:40:33.659828134 2397 hpack_encoder.cc:473] Encode: 'authorization: Bearer nIooYCIhTQ20GzxxLc+pSg==', elem_interned=0 [2], k_interned=0, v_interned=0
I0105 16:40:33.659860684 2397 hpack_encoder.cc:473] Encode: 'te: trailers', elem_interned=1 [3], k_interned=1, v_interned=1
I0105 16:40:33.659891308 2397 hpack_encoder.cc:473] Encode: 'content-type: application/grpc', elem_interned=1 [3], k_interned=1, v_interned=1
I0105 16:40:33.659961983 2397 hpack_encoder.cc:473] Encode: 'user-agent: grpc-python/1.17.1 grpc-c/7.0.0 (linux; chttp2; gizmo)', elem_interned=1 [1], k_interned=1, v_interned=1
I0105 16:40:33.659995888 2397 hpack_encoder.cc:473] Encode: 'grpc-accept-encoding: identity,deflate,gzip', elem_interned=1 [3], k_interned=1, v_interned=1
I0105 16:40:33.660025887 2397 hpack_encoder.cc:473] Encode: 'accept-encoding: identity,gzip', elem_interned=1 [3], k_interned=1, v_interned=1
I0105 16:40:33.660059531 2397 chttp2_transport.cc:1249] complete_closure_step: t=0x6ae19ad8 0x6c90b1b4 refs=2 flags=0x0001 desc=send_initial_metadata_finished err="No Error" write_state=WRITING+MORE
I0105 16:40:33.660103644 2397 chttp2_transport.cc:1249] complete_closure_step: t=0x6ae19ad8 0x6c90b1b4 refs=1 flags=0x0001 desc=send_trailing_metadata_finished err="No Error" write_state=WRITING+MORE
I0105 16:40:33.660134112 2397 chttp2_transport.cc:1249] complete_closure_step: t=0x6ae19ad8 0x6c90b1b4 refs=0 flags=0x0001 desc=on_write_finished_cb err="No Error" write_state=WRITING+MORE
I0105 16:40:33.660166923 2397 chttp2_transport.cc:852] W:0x6ae19ad8 CLIENT state WRITING+MORE -> WRITING [begin write in current thread]
I0105 16:40:33.660500817 2397 chttp2_transport.cc:852] W:0x6ae19ad8 CLIENT state WRITING -> IDLE [finish writing]
I0105 16:40:33.660902208 2400 chttp2_transport.cc:2609] ipv4:192.168.254.44:443: Complete BDP ping err="No Error"
I0105 16:40:33.671334525 2400 parsing.cc:656] parsing initial_metadata
I0105 16:40:33.671392960 2400 hpack_parser.cc:636] Decode: ':status: 200', elem_interned=1 [3], k_interned=1, v_interned=1
I0105 16:40:33.671427021 2400 parsing.cc:407] HTTP:1:HDR:CLI: :status: 32 30 30 '200'
I0105 16:40:33.671476551 2400 hpack_parser.cc:636] Decode: 'content-type: application/grpc', elem_interned=1 [3], k_interned=1, v_interned=1
I0105 16:40:33.671506810 2400 parsing.cc:407] HTTP:1:HDR:CLI: content-type: 61 70 70 6c 69 63 61 74 69 6f 6e 2f 67 72 70 63 'application/grpc'
I0105 16:40:33.671552277 2400 hpack_parser.cc:636] Decode: 'trailer: Grpc-Status', elem_interned=1 [1], k_interned=1, v_interned=1
I0105 16:40:33.671581651 2400 parsing.cc:407] HTTP:1:HDR:CLI: trailer: 47 72 70 63 2d 53 74 61 74 75 73 'Grpc-Status'
I0105 16:40:33.671617014 2400 hpack_parser.cc:636] Decode: 'trailer: Grpc-Message', elem_interned=1 [1], k_interned=1, v_interned=1
I0105 16:40:33.671645555 2400 parsing.cc:407] HTTP:1:HDR:CLI: trailer: 47 72 70 63 2d 4d 65 73 73 61 67 65 'Grpc-Message'
I0105 16:40:33.671682689 2400 hpack_parser.cc:636] Decode: 'trailer: Grpc-Status-Details-Bin', elem_interned=1 [1], k_interned=1, v_interned=1
I0105 16:40:33.671714771 2400 parsing.cc:407] HTTP:1:HDR:CLI: trailer: 47 72 70 63 2d 53 74 61 74 75 73 2d 44 65 74 61 69 6c 73 2d 42 69 6e 'Grpc-Status-Details-Bin'
I0105 16:40:33.674612891 2400 parsing.cc:661] parsing trailing_metadata
I0105 16:40:33.674655858 2400 hpack_parser.cc:636] Decode: 'grpc-status: 0', elem_interned=1 [3], k_interned=1, v_interned=1
I0105 16:40:33.674685597 2400 parsing.cc:503] HTTP:1:TRL:CLI: grpc-status: 30 '0'
E0105 16:40:33.677045300 2396 fork_posix.cc:63] Fork support is only compatible with the epoll1 and poll polling strategies
I0105 16:40:33.677160556 2396 fork_posix.cc:68] Other threads are currently calling into gRPC, skipping fork() handlers
Related
I get a AWS S3 bucket URL when I call an API
On the s3 URL I am trying to upload a file via retrofit
But I am getting the following error
<Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>AKIA6F7T6E47MWT7QUOT</AWSAccessKeyId><StringToSign>PUT
multipart/form-data; boundary=754bc465-aad0-41d4-8ac2-2f333ec2c011
1642929217
/plnms-devappmedia/payment-receipt/252ec59e-0947-42e9-9d11-dd8f7eca0902.jpg</StringToSign><SignatureProvided>mcUVkLkJCtrlG5E0X+9uG3Yh5QA=</SignatureProvided><StringToSignBytes>50 55 54 0a 0a 6d 75 6c 74 69 70 61 72 74 2f 66 6f 72 6d 2d 64 61 74 61 3b 20 62 6f 75 6e 64 61 72 79 3d 37 35 34 62 63 34 36 35 2d 61 61 64 30 2d 34 31 64 34 2d 38 61 63 32 2d 32 66 33 33 33 65 63 32 63 30 31 31 0a 31 36 34 32 39 32 39 32 31 37 0a 2f 70 6c 6e 6d 73 2d 64 65 76 61 70 70 6d 65 64 69 61 2f 70 61 79 6d 65 6e 74 2d 72 65 63 65 69 70 74 2f 32 35 32 65 63 35 39 65 2d 30 39 34 37 2d 34 32 65 39 2d 39 64 31 31 2d 64 64 38 66 37 65 63 61 30 39 30 32 2e 6a 70 67</StringToSignBytes><RequestId>356AM1RVYQJRDBHM</RequestId><HostId>cMj3x6+X2Er0lSFHqDSaWCbKOXNw8qlNVqst7RIMllSyUr9bvkKn305dJRTqd31shmTmbLa972A=</HostId></Error>
I am doing a multipart upload via PUT method. On postman it is working but not from Android
val requestFile: RequestBody = file.name.toRequestBody("image/jpeg".toMediaTypeOrNull())
val body: MultipartBody.Part = MultipartBody.Part.createFormData("image", file.name, requestFile)
val res= executeApiCall { octaveUserApi.uploadFile(uploadUrl,body)}
The releveant retrofit
#Multipart
#PUT
suspend fun uploadFile(
#Url url:String,
#Part filepart: MultipartBody.Part
): Response<String>
It was a binary upload and I was doing it by multipart which was failing
Retrofit call
#PUT
suspend fun uploadFile(
#Url url:String,
#Body filebody: RequestBody
): Response<RequestBody>
Request body would be
Api.uploadFile(uploadUrl,file.asRequestBody("image/jpeg".toMediaTypeOrNull()))
I am using OrmLite over SQLite with SQLCipher to encrypt a database on Android. Is there a way to cipher a Room database?
Room by default store data in the app's internal storage which any root user can access.
if you need some security you need to use encryption lib like this cwac-saferoom.
SQLCipher for Android now directly supports Room. You can find the documentation here
Consequently, #CommonsWare will not be actively developing cwac-saferoom any longer and recommends using SQLCipher's support
Android Room DB explicitly doesn't support encryption. A typical
SQLite database in unencrypted. You can use SQLCipher for Android with
Room or other consumers of the androidx.sqlite API to Secure Your Data
stored in sqlite DB. QLCipher has a SupportFactory class in
the net.sqlcipher.database package that can be used to configure Room
to use SQLCipher for Android. See the hexdumps of a standard SQLite db
and one implementing SQLCipher.
~ sjlombardo$ hexdump -C sqlite.db
00000000 53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00 |SQLite format 3.|
…
000003c0 65 74 32 74 32 03 43 52 45 41 54 45 20 54 41 42 |et2t2.CREATE TAB|
000003d0 4c 45 20 74 32 28 61 2c 62 29 24 01 06 17 11 11 |LE t2(a,b)$…..|
…
000007e0 20 74 68 65 20 73 68 6f 77 15 01 03 01 2f 01 6f | the show…./.o|
000007f0 6e 65 20 66 6f 72 20 74 68 65 20 6d 6f 6e 65 79 |ne for the money|
~ $ sqlite3 sqlcipher.db
sqlite> PRAGMA KEY=’test123′;
sqlite> CREATE TABLE t1(a,b);
sqlite> INSERT INTO t1(a,b) VALUES (‘one for the money’, ‘two for the show’);
sqlite> .quit
~ $ hexdump -C sqlcipher.db
00000000 84 d1 36 18 eb b5 82 90 c4 70 0d ee 43 cb 61 87 |.?6.?..?p.?C?a.|
00000010 91 42 3c cd 55 24 ab c6 c4 1d c6 67 b4 e3 96 bb |.B?..?|
00000bf0 8e 99 ee 28 23 43 ab a4 97 cd 63 42 8a 8e 7c c6 |..?(#C??.?cB..|?|
~ $ sqlite3 sqlcipher.db
sqlite> SELECT * FROM t1;
Error: file is encrypted or is not a database
https://github.com/sqlcipher/android-database-sqlcipher
I'm trying to send BLE Notification from android (GAP:central, GATT:server) to peer device (GAP: peripheral, GATT: client).
The problem is that on android 5.0 there is command: BluetoothGatt.requestMtu(int mtu).
But I do not know the way how to find out if peer device support requested MTU and what is actually negotiated MTU.
The required function:
BluetoothGattCallback.onMtuChanged(BluetoothGatt gatt, int mtu, int status)
was added only in API level 22 (Android L 5.1).
My problem is that I do not know how many bytes in packet I can send.
I write a test code to send bigger packet than 20B and it seems android sends just first 20B of data and never tell me that it discarded rest of the data!!! That is terrible behavior. Either I'm missing something, or Android 5.0 is useless for bigger packets than 20 bytes :(
I wrote test code and logs prove that all is sent and returns true:
BluetoothGattCharacteristic mCharacVal;
BluetoothGattServer mGattServer;
...
//log: I/vbeOryNotify: bleNotify snd:msg body; id:27; len:60 :I should have known those alien maggots booby-trapped this s
ret = mCharacVal.setValue(toSnd);
Log.i("vbeOry","bleNotify: setValue "+AppCommon.ByteArrayToHexStr(toSnd)+" ret:"+ret);
//log: I/vbeOry: bleNotify: setValue 03 1B 00 00 00 3C 49 20 73 68 6F 75 6C 64 20 68 61 76 65 20 6B 6E 6F 77 6E 20 74 68 6F 73 65 20 61 6C 69 65 6E 20 6D 61 67 67 6F 74 73 20 62 6F 6F 62 79 2D 74 72 61 70 70 65 64 20 74 68 69 73 20 73
//log: ret:true
byte[] dataRdBck = mCharacVal.getValue();
Log.i("vbeOry","bleNotify: getValue "+AppCommon.ByteArrayToHexStr(dataRdBck));
//log: I/vbeOry: bleNotify: getValue 03 1B 00 00 00 3C 49 20 73 68 6F 75 6C 64 20 68 61 76 65 20 6B 6E 6F 77 6E 20 74 68 6F 73 65 20 61 6C 69 65 6E 20 6D 61 67 67 6F 74 73 20 62 6F 6F 62 79 2D 74 72 61 70 70 65 64 20 74 68 69 73 20 73
ret = mGattServer.notifyCharacteristicChanged(device, mCharacVal, false);
Log.i("vbeOry","bleNotify: notifyCharacteristicChanged "+AppCommon.ByteArrayToHexStr(toSnd)+" ret:"+ret);
//log: I/vbeOry: bleNotify: notifyCharacteristicChanged 03 1B 00 00 00 3C 49 20 73 68 6F 75 6C 64 20 68 61 76 65 20 6B 6E 6F 77 6E 20 74 68 6F 73 65 20 61 6C 69 65 6E 20 6D 61 67 67 6F 74 73 20 62 6F 6F 62 79 2D 74 72 61 70 70 65 64 20 74 68 69 73 20 73
//log: ret:true
Even from call back I do not get any error:
private BluetoothGattServerCallback mGattServerCallback = new BluetoothGattServerCallback() {
public void onNotificationSent(BluetoothDevice device, int status){
Log.i("vbeGattServ", "onNotificationSent status: "+status);
//log: I/vbeGattServ: onNotificationSent status: 0
but then I look with my BLE analyzer and I see that only first 20 B of notification data is send:
So my question is either how to find out negotiated MTU or at least how to find out that not all data was sent? (Constrain is Android 5.0).
Perhaps it has no solution for Android 5.0 :( And I have to stick with 20B even when both device could support higher. Only work around would be to implement mechanism for returning MTU from peer device as was suggested here on stack overflow.
Your issue is not Android but Bluetooth / the app running on your central.
Increasing the useful data size from 20B is only possible with BLE v4.2 and newer. I suppose your radio is running with BLE v4.0 or v4.1 or there is an issue setting up your MTU.
Either way this should not affect reading data. The central device can read a characteristic with an offset. Assuming you have 60B, you would have 3 requests from the central:
Read, offset=0
Read, offset=20
Read, offset=40
TL;DR: Your GATT central simply handles reads wrong.
I am working on an client - server application project with an Android client and Apache server and mutual authentication (i.e., client certificate). I am poor in SSL/TLS.
Server authentication get done all okay but when it comes to client authentication this error: ssl23_get_server_hello:tlsv1 alert handshake failure happens. I have also checked packets using WireShark many times and i also have created self signed certificates using my self created CA many times.
I should mention I've set Apache SSLVerifyClient property on "require" and SSLVerifyDepth on 1 and SSLCACertificateFile is set also. on "optional" everything is okay but i dont want it to be like that.
It seems everything is okay and without problem on my localhost when I test it using openssl s_client and I address client cert and key and CA file .
c:\OpenSSL-Win64\bin>openssl s_client -connect 192.168.1.55:443 -key c:\xampp\apache\conf\ssl.key\client.key
-cert c:\xampp\apache\conf\ssl.crt\client.crt -CAfile c:\xampp\apache\conf\ssl.crt\ca.crt
Enter pass phrase for c:\xampp\apache\conf\ssl.key\client.key:
CONNECTED(0000011C)
depth=1 C = ir, ST = khuzestan, L = dezful, O = nama, OU = nama, CN = Nama System
verify return:1
depth=0 C = ir, ST = khuzestan, L = dezful, O = nama, OU = nama, CN = 192.168.1.55
verify return:1
---
Certificate chain
0 s:/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=192.168.1.55
i:/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
1 s:/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
i:/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDQTCCAikCAQEwDQYJKoZIhvcNAQELBQAwZjELMAkGA1UEBhMCaXIxEjAQBgNV
BAgMCWtodXplc3RhbjEPMA0GA1UEBwwGZGV6ZnVsMQ0wCwYDVQQKDARuYW1hMQ0w
CwYDVQQLDARuYW1hMRQwEgYDVQQDDAtOYW1hIFN5c3RlbTAeFw0xNjEwMDcxODE0
MjdaFw0xNzEwMDcxODE0MjdaMGcxCzAJBgNVBAYTAmlyMRIwEAYDVQQIDAlraHV6
ZXN0YW4xDzANBgNVBAcMBmRlemZ1bDENMAsGA1UECgwEbmFtYTENMAsGA1UECwwE
bmFtYTEVMBMGA1UEAwwMMTkyLjE2OC4xLjU1MIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAo3U+hTqP6911dUELWS9V4h1W172KKNXq/eJqnWO32+nraVHI
jPiFDcU9qRDFNSUdbFAokOrtXVZXePebNKpgbzVW2EDp3EtU4OXzYd/32YEaW0NB
SXS8eQDoJZ4+d1wl/vIM5jRovGmnNEv94XQbeGrUKdYSzaZL0Zilcg7Qop2mG3cq
EKGLCZm2tTzgkRTwkng0L7ODq1SZE4yoy5T+WNqnEOjOlQ2hVfio8HGAgGqJXUY+
YHgj0Shk6nFfg5pRpH15poNRgVGlizqLolN/EUf2CzV12MCyjdri8d5ZMfrTbszN
lwpUzp/3K3CGYjSqzEWL+9j85dE11Lrdix+rcwIDAQABMA0GCSqGSIb3DQEBCwUA
A4IBAQA1XaLfV36GBpOBw32fMvoK7K9XkwP52lvMYgcAPWZFjFvdZnysndDKntFe
cQXZdKnEzm3GNUv4APAEyj97VWnFKKM3lDLaMy99jWavdMNvyU4WpjT4DWj5kP0w
9Esc2fNDv6/A1ME4Ty1XUwNbfDjbG/pz0WZn00bgvbKwmA0GjHYFZTYC0W4wdion
dP9NPTJNENmOIeIE2N4tIPuieMTeCYqwRNplVldmzgeDYKW+n15glvRF1+18kuAC
xNj6bMTOwS2aY5DXthFeLNXWerspcgyUdTss/TdIJxO+pzA1s8ZN8E6RwqfIeKWv
gIwkTiitf8InLsQVRzxEzcmR5V15
-----END CERTIFICATE-----
subject=/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=192.168.1.55
issuer=/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
---
Acceptable client certificate CA names
/C=ir/ST=khuzestan/L=dezful/O=nama/OU=nama/CN=Nama System
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3440 bytes and written 2352 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 155B16EEDAF469AB0E4604A02CAEF4C3FFF20834DE2E25CAD801480CB1E40B2C
Session-ID-ctx:
Master-Key: C83DD8E4633A8DECF0410FA1ED4591F49A10AC24E3B59DC1F6CFC2E5B05878EEB7589EE5F51237E51A01E7017A1F594E
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 6e c4 ab eb 6f d2 04 b3-81 73 9d cf fc a6 20 08 n...o....s.... .
0010 - 08 1d 1e bc 9e 01 e5 0e-c6 c7 a3 81 02 a9 3d 04 ..............=.
0020 - 5c 86 aa e6 b8 f0 ad 97-a8 e4 bd 44 5b a9 97 17 \..........D[...
0030 - 39 81 71 bf 0c 67 4a b2-fd d9 fe d8 aa c9 5e af 9.q..gJ.......^.
0040 - 21 78 c5 e0 30 c7 5c 0c-4a 62 84 15 4b 45 48 68 !x..0.\.Jb..KEHh
0050 - a6 f8 3b 02 61 1a f2 43-11 54 c1 dc 73 3a 2a 27 ..;.a..C.T..s:*'
0060 - 61 f1 32 df a8 0b 21 c5-fd 02 ff 86 d6 da 7a 79 a.2...!.......zy
0070 - ae af 92 9e 2b a5 e8 eb-dc f8 c8 9b ec 5c a0 58 ....+........\.X
0080 - 75 f5 c7 92 e4 01 49 66-be a2 96 fd 5a 36 34 08 u.....If....Z64.
0090 - c2 eb 14 30 f8 54 45 43-e0 4f 83 45 a1 3d 33 37 ...0.TEC.O.E.=37
00a0 - 0c fc 8f 46 8e f8 28 f3-0f df b7 db 71 2a 81 0e ...F..(.....q*..
00b0 - 39 2d 85 08 52 29 cf d1-8a 56 d6 b9 ca 24 10 a0 9-..R)...V...$..
00c0 - 86 44 68 56 13 dc c7 7b-8d 45 c1 8c c4 b4 be 5d .DhV...{.E.....]
00d0 - 91 75 4c e9 a9 61 a1 d5-af 37 70 d9 7b 7d 9a bd .uL..a...7p.{}..
00e0 - 92 85 cc d9 a8 64 9c bf-7b 8f 89 67 9a 15 d7 47 .....d..{..g...G
00f0 - 56 e9 45 39 35 b6 d5 e2-8d a6 75 0e 71 4d 9b b0 V.E95.....u.qM..
0100 - 0e 97 ae 60 37 49 bd ed-97 93 35 98 10 45 a2 0b ...`7I....5..E..
0110 - dc a2 c9 af 3b 38 98 f9-af ab 65 83 80 fc b2 19 ....;8....e.....
0120 - 10 b7 f6 4f 72 3d fd 2b-9c 18 90 9e be 32 0e 68 ...Or=.+.....2.h
0130 - 60 ac 0f 13 94 b0 9e 80-d4 14 44 41 70 7d 40 86 `.........DAp}#.
0140 - dd 04 66 da 5b 05 69 d3-57 db c9 e0 e5 76 4e 5e ..f.[.i.W....vN^
0150 - b5 07 d1 2b 47 ba 8e f1-92 38 68 b0 23 9e 98 4e ...+G....8h.#..N
0160 - dc aa fd 51 52 e0 7c 7b-f9 0e 30 58 d2 ae 80 5f ...QR.|{..0X..._
0170 - f2 85 0a 48 ab d6 6e 1c-ee 1b 1b 3d c6 b6 13 f6 ...H..n....=....
0180 - ab cc 57 8d d8 90 cc 46-7c 6f af ff 83 46 b4 3d ..W....F|o...F.=
0190 - 1b c7 ed b4 f1 bd 91 c1-6e 22 7f 47 8c b1 39 ef ........n".G..9.
01a0 - 98 7b bc a2 09 0a 2e 76-13 e3 98 6f a1 b7 a3 bd .{.....v...o....
01b0 - 3f 8b 0e cd ca f3 65 83-a4 6f 8c 48 4a fa 82 db ?.....e..o.HJ...
01c0 - 96 f6 c5 e3 57 cf da 26-14 7f 91 65 cc a3 37 b3 ....W..&...e..7.
01d0 - 4d 96 c9 4c 8a e4 cb c4-db 77 10 69 82 d5 7b e2 M..L.....w.i..{.
01e0 - 0d 9e 62 8a 20 95 3a 8a-27 76 60 fa a8 4b 29 88 ..b. .:.'v`..K).
01f0 - e5 90 e7 49 e9 a8 9e 14-8a f5 8f 06 da eb 1f 4c ...I...........L
0200 - b5 e7 9a d9 9b ed db 12-11 e2 f4 2b df cb 6f 73 ...........+..os
0210 - 4e aa 53 a2 e7 04 ff 9c-de bc 5e 21 42 0c b7 2a N.S.......^!B..*
0220 - 1f d3 b9 1a b7 9b 25 92-ef 81 70 d5 1b 4d d5 9b ......%...p..M..
0230 - 65 40 52 c8 b4 cd b4 6b-ab d8 42 31 e0 2a 9f d4 e#R....k..B1.*..
0240 - 35 78 34 b3 34 b5 9d 53-c2 56 82 ff e7 99 8b a6 5x4.4..S.V......
0250 - bd 7b a5 a1 86 25 ce 45-ee 44 d4 14 19 0c 97 41 .{...%.E.D.....A
0260 - b1 a2 c9 eb 5a c8 13 39-09 7a fa 58 15 83 fe e3 ....Z..9.z.X....
0270 - e4 a7 5b f4 b7 74 65 bb-f7 5d d1 88 47 e2 a4 c3 ..[..te..]..G...
0280 - 45 af 6e 31 86 73 19 1e-20 7c 3a a2 69 88 67 30 E.n1.s.. |:.i.g0
0290 - de 3c 75 e0 d5 d4 1e 10-d8 80 ea ca 99 0a e7 c6 .<u.............
02a0 - f5 8d ca 83 2c 23 3e 32-ec e6 72 6c 1d f1 6e 37 ....,#>2..rl..n7
02b0 - 45 de ce 5b df a0 54 69-c5 a9 9d 9b 8f a5 7c 8c E..[..Ti......|.
02c0 - 0b 7d c4 b5 16 64 69 20-4e ca 0f 68 01 e9 bd db .}...di N..h....
02d0 - e5 17 a9 b7 40 d3 dc fd-c1 2a d7 3f a4 f8 2d e2 ....#....*.?..-.
02e0 - f8 1f 83 25 44 d7 54 bb-e2 e6 5b 34 73 99 89 89 ...%D.T...[4s...
02f0 - cd c8 49 53 cf f3 52 a4-c4 e6 9b b1 c6 16 85 1e ..IS..R.........
0300 - e8 0a af d0 8c 7e ab 6e-65 d6 2f 01 ff 59 b5 49 .....~.ne./..Y.I
0310 - 41 56 cd 4a 3f de 75 3a-21 30 9b bc 14 66 71 87 AV.J?.u:!0...fq.
0320 - 59 4e a2 e3 03 a1 95 7a-7a 28 7d 5a 09 05 d3 0a YN.....zz(}Z....
0330 - ea 4f 77 61 74 48 e4 6c-44 5b 7a 5c ed 6c f9 07 .OwatH.lD[z\.l..
0340 - 96 ee a6 69 16 22 3b 8f-8c 53 a2 d2 b7 eb f5 3a ...i.";..S.....:
0350 - 8f 36 8e 2d 6e 59 58 7c-06 02 81 fb e2 c0 56 c2 .6.-nYX|......V.
0360 - 4e 43 89 29 fd 68 0c 36-fc db 0a aa 77 70 c5 e9 NC.).h.6....wp..
0370 - ea c2 78 9e 65 c0 10 12-73 90 54 22 80 4b 24 c9 ..x.e...s.T".K$.
0380 - 74 39 41 d0 0c 59 61 1b-f2 eb 16 2b 35 19 88 13 t9A..Ya....+5...
0390 - 58 79 22 83 03 2c 2c 49-52 10 7c a4 a5 ea 3a b2 Xy"..,,IR.|...:.
03a0 - e9 94 51 70 44 71 ee 6a-1c 34 b4 aa 76 dd d3 08 ..QpDq.j.4..v...
03b0 - 92 7d b8 db 04 47 3e ca-ea 6c 24 ac ae 9e 4f 15 .}...G>..l$...O.
03c0 - 32 f2 34 30 9d 7d 67 29-51 17 89 26 d1 bb ec 1b 2.40.}g)Q..&....
03d0 - 7d b2 b0 18 1f ed 84 bc-23 bb 21 04 1a 1e f5 88 }.......#.!.....
03e0 - 10 c0 9e 97 ed f7 ee 9e-37 8f 57 27 38 59 e9 62 ........7.W'8Y.b
03f0 - 69 58 ac 09 80 c4 42 05-93 2c 39 2e f1 3e ba f4 iX....B..,9..>..
Start Time: 1476823635
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
It seems problem is android client authentication. My Android device version which i test the app on is Android 4.4 (Kitkat) and my Apache cipher suite is like this:
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GC$
i have searched a lot and i guess the problem can be client and server Ciphers mismatch , but i am not sure if its right and i dont know how to fix it.
Thank you very much for the help.
UPDATE:
I am using NoSSLv3SocketFactory.java class to avoid sslv3.
it turned to this error: SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure, and here is my packet capture my packet capture
and here is also my ssl access log :
[19/Oct/2016:00:47:46 +0330] 192.168.1.55 TLSv1 ECDHE-RSA-AES256-SHA "-" -
[19/Oct/2016:01:08:41 +0330] 192.168.1.55 TLSv1 ECDHE-RSA-AES256-SHA "-" -
Based on the information so far, especially the image of the packet capture, it looks like:
Client and server successfully agree on a cipher (otherwise server would not sent its ServerHello)
Client accepts the servers certificate (otherwise client would complain instead of continuing with the handshake)
Client sends its own certificate
Server sends back an alert: handshake_failure
The most likely thing is that the server does not like the clients certificate. Since the test with openssl s_client and a client certificate shows a successful handshake it might be that the Android client is sending a different certificate than used with the other test. Digging deeper into the packet capture should show, which certificate is sent by the client. Apart from that information about the problem should be visible on the server side, i.e. in server logs or similar.
I am trying to communicate between PN532 and HCE on Android with ISO 7816-4 command, I am successfully select the AID (a DF), but when I select the EF under that DF (that EF does not exist, so I assume that Select command will create that EF), and then write the records to that EF but it display like this:
inList passive target
write: 4A 1 0
read: 4B 1 1 0 4 60 4 8 23 5A 4D 5 75 80 70 2
write: 40 1 0 A4 4 0 7 F0 1 2 3 4 5 6 0
read: 41 0 48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21
Successfully hehe
48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21 Hello Desktop!
write: 40 1 0 A4 2 C 1 1 0
read: 41 0 48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21
Not enough space
write: 40 1 0 D2 0 0 7 42 41 4F 47 49 41 40 0
read: 41 0 4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 30
Not enough space
write: 40 1 0 D2 0 2 4 44 4F 41 4E 0
read: 41 0 4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 31
Not enough space
write: 40 1 0 B2 0 0 7 42 41 4F 47 49
read: 41 0 4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 32
Not enough space
write: 40 1 0 B2 0 2 4 44 4F 41 4E 0
read: 41 0 4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 33
Not enough space
I don't know what I am doing wrong here?
On Android, the log is :
04-15 09:36:54.024: D/HostEmulationManager(929): notifyHostEmulationData
04-15 09:36:54.024: W/System.err(17710): [B#41ed5970
04-15 09:36:54.024: I/HCEDEMO(17710): Received: ???????BAOGI
04-15 09:36:54.024: D/HostEmulationManager(929): Sending data
04-15 09:36:54.164: D/BrcmNfcJni(929): RoutingManager::stackCallback: event=0x17
04-15 09:36:54.164: D/BrcmNfcJni(929): RoutingManager::stackCallback: NFA_CE_DATA_EVT; h=0x302; data len=10
04-15 09:36:54.164: D/HostEmulationManager(929): notifyHostEmulationData
04-15 09:36:54.164: W/System.err(17710): [B#41ed5e20
04-15 09:36:54.164: I/HCEDEMO(17710): Received: ?????DOAN??
04-15 09:36:54.174: D/HostEmulationManager(929): Sending data
04-15 09:36:54.885: D/BrcmNfcJni(929): RoutingManager::stackCallback: event=0x19
04-15 09:36:54.885: D/HostEmulationManager(929): notifyHostEmulationDeactivated
04-15 09:36:54.885: I/HCEDEMO(17710): Deactivated: 0
04-15 09:36:54.885: D/HostEmulationManager(929): Unbinding from service ComponentInfo{de.grundid.hcedemo/de.grundid.hcedemo.MyHostApduService}
04-15 09:36:54.895: E/BrcmNfcNfa(929): UICC[0x0] is not activated
It displays that it can receive some data, but it misses some elements I want to transmit, but, from PN532, when I use read records, it does not display these data?
The commands that your Android HCE emulated smartcard application understands and processes are completely up to you (as long as they are formatted as valid ISO 7816-4 APDUs).
In your case, your Android HCE service obviously processes the SELECT (by DF name) APDU,
00 A4 04 00 07 F0010203040506 00
and gives this as a response:
48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21 ("Hello Desktop!" when interpreted as ASCII)
(Note that this response is not a valid response APDU according to ISO 7816-4 as it lacks a status word.)
The next command you send is an invalid SELECT (by EF) command:
00 A4 02 0C 01 01 00
For that command, Lc should be 2 and the EF identifier should consist of two bytes if following ISO 7816-4. In response to that, your Android HCE service again sends
48 65 6C 6C 6F 20 44 65 73 6B 74 6F 70 21 ("Hello Desktop!" when interpreted as ASCII)
(Note that this response is not a valid response APDU according to ISO 7816-4 as it lacks a status word.)
So I would guess, that your Android HCE service performs a check like this:
public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
if (apdu[1] == (byte)0xA4) {
return "Hello Desktop!".getBytes("US-ASCII");
}
}
The next command that you send is a malformed WRITE RECORD command that tries to write "BAOGIA#" in the first record of the cuirrently selected file (malformed, because a WRITE RECORD command normally does not have an Le field):
00 D2 00 00 07 42 41 4F 47 49 41 40 00
As a response your Android HCE service sends:
4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 30 ("Message from android: 0" when interpreted as ASCII)
(Note that this response is again not a valid response APDU according to ISO 7816-4 as it lacks a status word.)
You then repeat the WRITE RECORD command with a different record payload and after that you send two malformed READ RECORD commands:
00 D2 00 02 04 44 4F 41 4E 00
00 B2 00 00 07 42 41 4F 47 49
00 B2 00 02 04 44 4F 41 4E 00
As a response your Android HCE service sends:
4D 65 73 73 61 67 65 20 66 72 6F 6D 20 61 6E 64 72 6F 69 64 3A 20 xx ("Message from android: X" when interpreted as ASCII)
Where xx seems to be an ASCII digit X that is incremented for each received command.
So I would guess, that your Android HCE service looks like this:
private int mCommandCounter = 0;
public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
String response;
if (apdu[1] == (byte)0xA4) {
response = "Hello Desktop!";
} else {
response = "Message from android: " + Integer.toString(mCommandCounter);
++mCommandCounter;
}
return response.getBytes("US-ASCII");
}
So, to summarize this, your Android HCE service will understand and process only those commands that you (or whoever develops it) implement. So it is up to you what commands you can send to the HCE device. There is no file system behind it. ISO 7816-4 only suggests a file system layout for smartcard applications.