Android 5.0 BluetoothGattServer.notifyCharacteristicChanged how to find MTU? - android

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.

Related

Error uploading file on AWS android retrofit

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()))

grpc call see body/stream of grpc call

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

Android: Room: no encryption and security?

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

Android Beam and SNEP to pn532

we are trying to send a big file from an android phone to a mikroprocessor via nfc-p2p, android-beam and snep.
This is what we have so far. I can connect the pn532(target) with the phone(initiator). My android app uses setNdefPushMessage to send a NdefMessage via nfc.
As soon as i tap the phone(Beam-UI) it starts to connect with SAP 4 on my pn532 and after a readcommand(tgGetData) i receive the following:
00 FF 86 7A D5 87 00 13 20 00 10 02 00 00 03 BD C1 01 00 00 03 B6 54 30 68 61 6C 6C 6F 20 64 61 73 20 69 73 74 20 65 69 6E 20 74 65 73 74 31 68 61 6C 6C 6F 20 64 61 73 20 69 73 74 20 65 69 6E 20 74 65 73 74 32 68 61 6C 6C 6F 20 64 61 73 20 69 73 74 20 65 69 6E 20 74 65 73 74 33 68 61 6C 6C 6F 20 64 61 73 20 69 73 74 20 65 69 6E 20 74 65 73 74 34 68 61 6C 6C 6F 20 64 61 73 20 69 73 74 20 65 69 6E 20 74 65 73 74
To clean it up:
PN532 header: 00 FF 86 7A D5 87 00 no MI Bit set!
LLCP header: 13 20 00 I-Package from SAP 32 to 4
SNEP header: 10 02 00 00 03 BD version 10 request PUT len 0x3bd
NDEF header: C1 01 00 00 03 B6 54 c1: start+EndMessage
Message ... the rest
I made the connect complete with MUI 128.
my problem:
it says the SNEP packae is 0x3BD Bytes long but i only received this short part.
Nowhere in this message is any indication whether it is a split message.
where is the rest of my Data?
i tried to read more packages from pn532 but there were none.
** edit:
After a night of trying i finally got somewhere. What worked at least sometimes:(all from the PN532's point of view)
receive: Connect
send: Connect complete[MUI=128]
receive: SYMM
send: SYMM
receive: I first Fragmented Data(as shown above)
send: RR
receive: SYMM
send: I SNEP:response CONTINUE
receive: RR
send: I SNEP:request CONTINUE
receive: I second Fragmented Data
send: RR
receive: RR
send: I SNEP:request CONTINUE
receive: I third Data Fragment
Like I said this only works some times. most of the Time my PN532 just responds with an error Code 0x29 -> Initiator droped the Connection. So te Question is can it be a timing problem or what else causes the Connection to be dropped before sending the Rest of the Data.

SNEP is designed as a simple request/response protocol run on top of an LLCP data link connection (a pair of source and destination SAP established with CONNECT). The client requests an operation to be executed by the server and the server returns the response. With a PUT operation the client attaches data to the request. If the request then exceeds the maximum information unit size of an LLCP Information PDU, the client transmits the request in appropriate fragments. The first fragment informs the server of the number of octets it should be prepared to receive from the client. If the server is able to receive the data it answers the first fragment with a Continue response, if the data size exceeds the server's capabilities it can stop the exchange with a Reject response. After the client has received a Continue response it will send all remaining fragments without expecting intermediate responses. The server finally sends a Success response after having received all request data, as was indicated by the length value. The same principle applies to large SNEP responses, only that Continue or Reject are then request messages (because they are sent by the client).

ISO 7816-4 APDU command Select File and Write Record

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.

Categories

Resources