NFD » NFD-android

Do you have a hex dump of the packet? That would really help.

I would like to add more to explain why I think this is a jNDN bug but not NDN-Android bug. The following code is what happens behind the previous code (specifically, what happens when gm.getGroupKey is called, except that it doesn't get keys from a database, if I didn't miss something), and it works well on Android. I don't know why this works but the previous code doesn't work, maybe the bug relates to AndroidSqlite3 database?

        RsaKeyParams params = new RsaKeyParams(2048);
        DecryptKey memberDecryptKey = RsaAlgorithm.generateKey(params);
        Blob decryptKeyBlob = memberDecryptKey.getKeyBits();
        EncryptKey memberEncryptKey = RsaAlgorithm.deriveEncryptKey(decryptKeyBlob);
        Blob encryptKeyBlob = memberEncryptKey.getKeyBits();
        Name name = new Name("/prefix/READ/type/D-KEY/20170709T000000/20170710T000000/FOR")
          .append(keyChain.getCertificate(keyChain.getDefaultCertificateName()).getPublicKeyName());
        System.out.println(name);
        final Data data = new Data(name);
        data.getMetaInfo().setFreshnessPeriod(24 * 265 * 3600 * 1000);
        EncryptParams encryptParams = new EncryptParams(EncryptAlgorithmType.RsaOaep);
        Encryptor.encryptData
          (data, decryptKeyBlob, name, keyChain.getCertificate(keyChain.getDefaultCertificateName()).getPublicKeyInfo().getKeyDer(), encryptParams);
        m_face.registerPrefix(name, new OnInterestCallback() {
          @Override
          public void onInterest(Name name, Interest intrst, Face face, long l, InterestFilter i) {
            System.out.println("receive interest: " + intrst.getName());
            try {
              face.putData(data);
            } catch (IOException ex) {
              ex.printStackTrace();
            }
          }

        }, new OnRegisterFailed() {
          @Override
          public void onRegisterFailed(Name name) {
            throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
          }

        });

Jeff Thompson wrote:

Do you have a hex dump of the packet? That would really help.

Is there a tool to dump NDN packets easily (without rooting the phone)?

Can you just dump the bad data packet before jNDN sends it?

System.out.println("Data packet: " + data.wireEncode().toHex());

Jeff Thompson wrote:

Can you just dump the bad data packet before jNDN sends it?

System.out.println("Data packet: " + data.wireEncode().toHex());

Here is the hex code of the packet:

06fd07fa076308067072656669780804524541440804747970650805442d4b4559080f323031373037313054303030303030080f3230313730373131543030303030300803464f52080c746d702d6964656e7469747908116b736b2d31343939373636353330373234140a19080000000757b12c0015fd064982fd012c1c230721080c746d702d6964656e7469747908116b736b2d3134393937363635333037323483010384fd010010a94206f160d94f2c724d198ff3871327d29f31c16791fa1f12c68718dc93835c7e8ff485f9b1c26c48f816b59bf60ba3cdcc197174630cf556515eee1d2517455c832d0db41445d07c256b8c0d02154e38cc06c458326ae26db96947ea5ea782756b4bc2d09434ebacd1b93c2d86ddf42f29b2259ff763a1ec9f3e08bc89868dfe6e3723afa70b8048389b365ca1f44c4bf36eeba75f419cda8ec32e8bc8deecddfcc8f194b374c8bb4ae26d172ad6966daf769b92bc85498c2c41498902ca7acbddc3c8ce42233738413c2d894261680c10da6abeff29bd09565d5e3f672f3e3de52dfae25fdb15c5631cf3fca3deffbb276cfdc323d1fa33b7483646103d82fd05151c2a0728080c746d702d6964656e7469747908116b736b2d3134393937363635333037323408056e6f6e63658301018510de62bec95b129e39b21f8b7758ee18ef84fd04d05bb97dfbd2a89c8263fb5bfff7530ff08a0e8fd80b9e87ea8b16b144997a5475a9ec760984257826ac4890704c97dd295a4d01ed439689b56485cd72d9f03c778643b2aa2c81b757ed69fff5f7544163268c41276e13896038c11a86747a2b6cdda53c3aacfd6395a89aafeb491e40edb90c83a0b22d5fdfd8b41a85b3b5d3242f9811b6aea9e2fc23bf5e695a208032291f541840b6803549e3e7882451eab70ed5e495e083876717eec457e6826181429bfad587fb7943b37c976e4036ab21fa9b3c422e7d578c6d46743c78fe98a200fb7003881410377f50da18a4e07e27682a83262f72601c7f228dd81d456a87b53e9445fc9fdd45095a8640611eb5469d5fe07861297723650837541b9a8edd59db12a11190d13daef872af4877c84f3e634241211052fe66fa5f688f3a7bf1a235dbaf929544a81c3ee063f4ae4f33dda7c6ddd90ada4b51cec6bb697fa314c709b98eb7782c1390e819b132b644b0313df1d2b91a0090c6b9c369059fad9f126431a15093dfb85f77a3eef134b6554c0b436c985bea673c30a81b83aa7b0c4ec3ca6708fbaff57e306be78f65dafd0a0afa91ca2039cb90967f5ee8717200ef798828de14429fc35e434c24cc55d755f9f554b530f5e282655d766b06593bee19fe964187dcd0a8b997ff5b92759a661efce6f2b26ab9156c30d7f2b0fe05b4bb06ef8d2be9f75c36dc7c76b48a4ecb3e6e0f5c4e310a1128ead4d30328c605aad5410bfbfa8bc54bbe00afdecacb9c2d047ea19b40118b516715273407a99850cc0c3aea549ba6a196c007199271971138c7643e2f9e2d19ce95036c64874c194751f8ef30cb92b6dafad44ddfd4bbd0d8d6a12811b6826c368440995312234f15c40a3cfcb193ad7b467d48c7a03d5819fd7f10c696940bda14eff021731f9924282c5e9e6f28bf6a4e22d44997ed47a4d2238e9b8d504eabcfcf2f7ac6122097c06d6179ab1c9faf3a01afecbe5b1b818adcee74a29cd1dd2a01a30351b8a5e8c6938bb219fb858a44c672d778986377bcc69f5832fc8b26744678b1f0c2f1026473db8b22d2d89edf6f5b27a21c00fd521ba0988d16f100b76ff9b61b1b8fec4c4ec302a6c9861f6ee0e221a89a0f0749a7d876537526035a42b3c369ab2d6b7cf528dbbd42dc021cb4a4b6ba5cfec298847effdf817b02684b235ab34dd5f278eb4a7b6a4aedac9c117100da48c6d4193afc2022209bbe071d4cb39038383538da1fcbee3d71541f8ac19847f12ffc5fe575749a4ecb52001f5c9b0a6ecb070a1f7c93479d9ef5122b2e9ee7618f2083900688b72ec638f3bd4c8c97e189e5e692a36c8ce202b59f3345c2451e69ce37e99d2d1496292ceead3a22633cc4d77c690f432c0a7bfed96678c751f0d587b069feac129f252daf469d6daac1f860bf6816091c1f889d17e600dd1f33782fd573f7321c83a65f2e67fcaa7a49b3ba49b012825c6aeaa185dfb99aa6b75bd7d0cf29c17766a2483e2bf3b77cd6abcd58df017f0c7e21ac94e095c5c0c18baa0a446dbe719be8aa6bda3f07e1df49a845080d31102eb3a291ce296e9538f8cf81bfc7474e3a490ea7d7f2778a87ef687e0b1812434fc3945f0eb594c77a289b972bdb6356c52443400abc8d91f1d514f99837a5f425dd7a5baa96d077a7d40592028aed226601e851c5c941c74e172c07f6df946a8ee28d990426396844006bbb87d4464277d5cc89e147960316361b01011c31072f080c746d702d6964656e7469747908034b455908116b736b2d31343939373636353330373234080749442d4345525417fd0100a42f4100364f58058b6a85156ce3c0290227309035b62d23c66811614e5e49ca2d1739dfea164d88ed8fd6b477a1a2bcd0383f290ea680df5446408a96b7dfa8d40ad07adec2a901e1668ba069bf477591d9604bb796fd693df1c2abf0f9c7f71b4bd64ff5eb97fc32738c6ff12071972b00a52cf82ad3b1c3c36e51102ac7ac31e4c656f9f0d0e7b18be2f3530aad3283820ab3f83385dfad78bddcd374e252f2bf557c496e0c8183603dc05f2b93eb4f0acae6ec9e1adc60554b242beed2dc2ee7e52e0c9a74d3cb7727a47ce0f7f751a21e7d7cc233b2fc8d84f4b855205635cef58f64df9ba82beff5

Thanks for the hex code of the packet. Can you paste a code sample which includes the line where you print the hex code? (I ask because it may matter where it's getting the data packet.)

Now I modified the sample code to be the following (remove the for loop, and register a prefix on NFD), and the bug still happens. The line for printing out hex code of the data packet is also included.

        GroupManager gm = new GroupManager(new Name("/prefix"), new Name("type"),
          new AndroidSqlite3GroupManagerDb(getApplicationContext().getFilesDir().getAbsolutePath()
            + "/tmp.db"),
          2048, 24 * 365, keyChain);
        RepetitiveInterval interval = new RepetitiveInterval(
          Schedule.fromIsoString("20170701T000000"),
          Schedule.fromIsoString("20170730T000000"),
          0, 24, 1,
          RepetitiveInterval.RepeatUnit.DAY);
        Schedule schedule = new Schedule();
        schedule.addWhiteInterval(interval);
        String scheduleName = "schedule1";
        gm.addSchedule(scheduleName, schedule);
        gm.addMember(scheduleName, keyChain.getCertificate(keyChain.getDefaultCertificateName()));
        List groupKeys = gm.getGroupKey(Schedule.fromIsoString("20170710T000000"), false);

        final Data oneKey = (Data) (groupKeys.get(1));
        System.out.println(oneKey.getName());
        m_face.registerPrefix(new Name("/prefix"), new OnInterestCallback() {
          @Override
          public void onInterest(Name name, Interest intrst, Face face, long l, InterestFilter i) {
            try {
              System.out.println("Data packet: " + oneKey.wireEncode().toHex());
              face.putData(oneKey);
            } catch (IOException ex) {
              ex.printStackTrace();
            }
          }

        }, new OnRegisterFailed() {
          @Override
          public void onRegisterFailed(Name name) {
            throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
          }

        });

The hex code I got this time is:
06fd07fa076308067072656669780804524541440804747970650805442d4b4559080f323031373037313054303030303030080f3230313730373131543030303030300803464f52080c746d702d6964656e7469747908116b736b2d31343939373936393436393136140a19080000000757b12c0015fd064982fd012c1c230721080c746d702d6964656e7469747908116b736b2d3134393937393639343639313683010384fd01007f1152f70361a90fac4a401f56ca97a2799701c90dbe914f97ef7d92fa63f989542afcb74d614b5334b14fd0c90e5c18b0829e18b8e43b8228a8b4e15ae6470e01fe1848fd19021396ecd07dcd6f3c70356b14119df9b3cc7ebfaa47b6a0658af07d3fe71f2c6e1ab61d2eab90f03cb69980b5271c9c9143bd2bb33954bd1261e9fd3f0fdf9eed70eb94d70fc0bc441e3ebd83fc4d4591cd7ce69d09800f22af3546da50532ef64729c206d368af4808c5bc0a38af2bbe901beba3ec5d019307397b5f33205e4d6be7b12b4416a5b9a6acd01ca780ceca05c812e1ecc0ce93eb32ca88180fcceabe95715c83d43f03af7b06325570dc376023432a97b0228dcf82fd05151c2a0728080c746d702d6964656e7469747908116b736b2d3134393937393639343639313608056e6f6e63658301018510326d154bd29a8c2bd46dd9534b29bea284fd04d061bcbd6a3ab0c59f1fa932f644f0aba6af9b365d56afd2e10eb110ad863abb06b4608b0f305ff141944a8fe03df32397709a8d960d3f5a4f5e950f709bbe1e388442edcc963a0725835c22d762a2cd8c6d351876e45081f1e5f40ac737ccbb840b4e21a1f164690baaea397bdbbc6c39fcd8d752b343fec34fa3c0f21aa3fc401ca53d0290bf63416cd2d70d02ed7d2b311aee92d4133c15915e0924a18d982becd44a2ed84d889b0beed615a1520283fbc04863a4a406fae4f75f3c02cc940d6ca582ef90996e2e1f824ba0a32d609c235605e0905934838d922f6a261646cf85ed82c10ec3c940d2989d00c239a17712989805ef26673bfdeed6a90e45d5abfcd9c26c452303906fcdb4b64a8c37cf8a07cd2881662ba4397caa3effc6de562895fd4a5bef3fad601251bb5201e02d25cbf5d9a60b1a9fe15ee0ed978290e7095f69230c9279e1fb7e2d3b3b1ebfe88c714983cf0cd8ea39381b231c82cd2a432ef10636b41b1bfd8d85b478453d76ac456776771e15f1fc34f91b49e57bddd48bd831fa91dd0054e1cc25ff11b37a100b870159e0a9858969959e7d5c64290d72d57d5c6417b9e06e73368188a74dc6330016172ab496a96e5a1c9ee15e35333f198333ed1b0d74b9d20516053dd199d23a6965116270f95bcc1a596e46bc8d44dbe8b0e6d3411c4e03821650a260ff9c07999a2873f9a6921f664353f2a6e97b887867c7b2d21ae49a7b6223e2bdc604b6f8186d626e30cedf80a718c00445d03221984bf84fa4b13e530c7e9669c4f8a540a0598034b2bc52e3e4e03678e65a7e2ceafecfe73e6f35fd517f959b088b53fc0c749967e0361beb4967a15358f49ea0ee0b4999255074187e6dc41c4a1096c6fa77070cace51086d1141561804be071a8427b2c5b2388247a5d9d43e0512889d97fcc2ec8c8c85776de6ce7a5f72bc8cbc85d8e43fbd74b2cb0e1954a4e09323aa33e4cd46eea9060916cd880e70c81cf185b17ec1b13c91ff4f4cf32e0c1572f34e896ff6925830f3c9b74bf89b7c73811748e30d60f88037873ec30fc579496641b84a31c20b2b92ecdb406d3d6bf8cf383ad4d3ec7dab43808e6bdf389c00080f433668182d69a42f096560ec183f2efa0cb3dff8753c92cfe6513fce346a15f147487fbe7e3fc0db9d2a36c5a1b1d653e8e3eaf1da4e9b8082a012c4918ffd3e15ea12e3b85058614cd43c01b5fcef1ff1b615a475091216235e01ed8c45231b260aa4a5d2c3755ce3de6a6269b12a1ac9b7865c6bba959ef21c9b229724a4da5e8d1c39a2fe4b96763d145f49429367fb253fa282d7c0ebcaf93819c0a41be635d4d1c2edd821014c72265126205ad92b6225e96295b25d19bbfacc59936212557adb1910561ddcc0aee3a5f314fa432689ef410aea9e4ce364875ab630bd1b888c07a913f7874b51c32510a97dfd7c69619edd0417eb13f50ddff7e25515c065f137e1d12b18447a81ec85cc743d8e7920b395b4c7cc73c22cd814c86aeffc5ea16221bc12f1167187e87f26201ac951b44407837c1082daeb224cfa82043c2f6612969ccd0b625ecf0ce571ed96a6a7a06ad7b641d0305a6411d9464d1c6d2c8f85571175c85e36a08fafc97a76a1efd80a2281b2203da86fa59669f4f6ba31faa73a1f4db88b6ab173b285d555864fef81ed8af0c84a2cf0ba13d8ab2a08375a5cbb60a880ca37bac9119ccdd60339ef786906cc152768816361b01011c31072f080c746d702d6964656e7469747908034b455908116b736b2d31343939373936393436393136080749442d4345525417fd0100441ccdee310e71531bafa112b1dacc566e8796011048ecc3ca0cec87d93bef059b05bfd1b7d92bfb76467e1d6abc37aa93cc352852638cc7ed7c808dc88ae6cbcadc592bc8815c1a6cb0ea1189d6518b04620f49fbfb800f1e11a8635d8bc93fd2347fcb4e7410e74d825c711d064b5d19bdd320a711b9d6569ff320570e2738a07f29aaa748039880af8f892365c184c62564841c1b232dc8ff33994141337f5bce7548dd6f38035f4260b98594a2f7a7543556857eedaf72ca5efdd38db5ae7c1fdaeed547f14f61f003bc542c49e08ca4b6b84a0986c7093e1480d9b334449c3d498ec8df9848a64809

Thanks. Please do me a favor and also print oneKey.wireEncode().toHex() immediately after the line final Data oneKey = (Data) (groupKeys.get(1)); , and post the result. I ask because the hex code looks odd, and I wonder if it looks the same before the callback.

Jeff Thompson wrote:

Thanks. Please do me a favor and also print oneKey.wireEncode().toHex() immediately after the line final Data oneKey = (Data) (groupKeys.get(1)); , and post the result. I ask because the hex code looks odd, and I wonder if it looks the same before the callback.

I also printed oneKey.wireEncode().toHex() immediately after the line final Data oneKey = (Data) (groupKeys.get(1)). Two outputs are the same (I copied the outputs and pasted them into two files, and used diff to compare those two files. And I triple checked the result).

This time, the hex code is:
06fd07fa076308067072656669780804524541440804747970650805442d4b4559080f323031373037313054303030303030080f3230313730373131543030303030300803464f52080c746d702d6964656e7469747908116b736b2d31343939383334303238333937140a19080000000757b12c0015fd064982fd012c1c230721080c746d702d6964656e7469747908116b736b2d3134393938333430323833393783010384fd0100117042057962e9c2d0ec36df467211a6d8871cf15b24d0e1fd1fbc69ac23617d281967bf0525ac79cc518704d135b01db473229d8d7a4ff11e0cd6e6ced59c58fe0e6ae90c78bc919c59c1ac35e1fa035101bfe5036ce1a95e457b1a9408e6b438f863f8eb060ce2c08841971d44ecf0366a050977eac55efa3383fc858e598ad4d10f8bf80fcf690ba9d60c3ed85c0e51a2d8781e7c1b12d617fc5a5299e42af175810fea99cc4998b5d17eebfcad071b7debd2ce0873df0129fa0f9ae98f7ad6d42f15b69c341c87bcdb6a0a4c0e00a07efe6996741765c66cab9ae54d9f1177abeea65de6fad79d40909335f7febd31232acec8cc5fa9864863e21b29d81b82fd05151c2a0728080c746d702d6964656e7469747908116b736b2d3134393938333430323833393708056e6f6e636583010185108d95d35bcf23e344dc5582838f3b93a884fd04d02b2a6a3ecddb639161b875f61bfc1db9e277e698597c94d0f21019a0d0bff34f374a24b8fc72054e644fe15c3fe075c027a992806cae77bfe32efa165289ad8875cb9c203a03a5657b397fb9bfdaa41200849ed0b73f377cea33180fc0b50a721cb06cd63201a20360c5765bdb0e8baea28dfc4862a60710dbf96f0449a9ca28c887abb8658858a13dd3270260320c1e48ed80aabcee80179da3a619d2b0e1d93867bf446f695873527e130eed1113b9287c5ecda9aff74f9e3dcbbbf5c4aed8115f5be4b1daf5a20a739b730ac6722092af4a5565b1529dc7570896bfd6bba7e05823d729cdceaad071e8fb71eeec60cde28635127f05b00c6a45eaadbb6e974a8331bcbcfbcc7d450e0253896cb741bf51ff56139425e3d57eb0643931963f16bce9b3ac6bffee97e799f32c86a9471593f9798f0cc7f4790a45ae36e51c605df33b5227cc8af815a95b33b419af0d7fd6519616eb6af288cb6a62e62ac1b1328cf25151b93eaf1f80f93b2b1bbb3427375bbe9deea8af327f875c010655d76b1ae8d5eb2c395eb1b0c650cfbd53f35a6ec5bef5c39cc1067681c0896ba74887c1ec2398116604ebf1b797c1a198b5286d38139f08f333afef70952f5931cba9cdd5193b2405d4ac30e0a076fbd5e715b8b59f15fa0e9d91969f1f1812e9fe2552bc9ee7dbe82a075fa69cf32381862990f6b547526f2a0a11330175248bed289d08244affa68092414eb712681dc6a643eaf1fe3466e71615cd25d90c0be9c05d049b82d312820f09b7eab7fa065af83457e8f6c7797b0b5b7f6d097cb6e1536fab4569920e8fbf70e674d81e467e68cecf78a88c7e0ef560464ecf04d99682bb06d9805047ea522cfddecb97505653bb4165a3c93be630a681dbd8227577fa59fc1f6e40c779427ce8a26f747d5d6affe62c8b053b78fc11b5b0ec1c923fc81a12d69b4f26940199e5e2e2f88329061952533f38480812874004eb7d57d8e5faf7762a229dae6a50e8f91cd627a3b241ad1d993df18a16947ad692d762037dc9265d1c30643e50f1f0d440770fde5fa7e43aa801cdb0f38666fe02769fd1acad32f028ad45954010f71c12ac7fae439678ac7041203ff92f43d4aa5b864654d2e3f03c37edf5c2f7cf478003dba2305df5dd6e8a574bd2747be14b0d6cda6262bacd314dbd1be2eca3275d38697f640f880e576b79c778791a64a1e2919fe37898aae6f6746edf75bb6f99edeb765b84b3bc440ee88596245a539b551320cfb4a966a59b8fddef1c72321679f58ec0ffa1c92ad607c3c9653870dbdd3bd3e73d8e2b6676da7a6b3876d52dd2d137294451a098de5b1e2981add74cc2b3a8bc2fb41be23ede0612ee048cffd12c0fb7f134c4ff3c2a458a34d31edd7f78b7b8bf810d3afc399cc6d56d809e7dbff3038e42f9e1310bc4b8a9f4531152e7b1330c7f4dcf7d72ada561d110f6f0359a23d554c31cb69bdef5f7453a66ef864e77ed3381903fbf4f0e6d2da86103b754c9cdaeeb204b631e6e028da517a5b294ad3acb35c95b0203b0653c28818ce5530efadf8a4702991d0d57c0b3951f83d52a7a7eee4d6ffe3e0dda9c773713a558de81a2a4398c2492b25e8a32beb965d9b2e1e84dc8d507300710791801523be95b1d73f55f58d170527707dafdab414165fe02ed35e11c31b9c8d8724cbcb1b3e69c5615af323d82c33595ce74f5f23d4a91b8cb3cb05b2f0523fda499a21f0816361b01011c31072f080c746d702d6964656e7469747908034b455908116b736b2d31343939383334303238333937080749442d4345525417fd010095d6a6ba17341edade3ddee7754621f7ce05ddb289e112a8b5bca739c8ebc71744a4929a72b773d130ab184c263fa4c9cbcb985fba5155e1bf24552b364627286d2f04b97d83ee65dff39e75c93311a826faf2e87242056776c2d2a35e6bfcaeeafa0accb9e0d6f7656db74f5e2b89801374c51037c424b23ee3548518cd7bf8a1c805803789a8fdfe90b0b24abb26d8dc15a3e778e442cd2b18423b349e7e400a57fabe79c0e63d586760f21a704f33fad8a6bf96717e342d7c92551e5f09a999bcf2fce55e34baa11c37a355c1980ce2a5e8c731830df200be879c482b9481dab6c865bcbb8f9a28931e

I looked at the encoding. There seem bytes missing from the end of the hex dump. The first few bytes are 06fd07fa which are "type" and "length" for the Data packet type and length 0x07fa (decimal 2042). So the total encoded data packet should be 2046 bytes. But the hex dump only has 2025 bytes. So 21 bytes are missing.

I wonder if this is due to a limitation on the printed output, or if the bytes are really missing in the encoding. Therefore, please add the following print statements:

System.out.println("Encoding size " + oneKey.wireEncode().size());
System.out.println("Encoding hex length " + oneKey.wireEncode().toHex().length());

These should print:

Encoding size 2046
Encoding hex length 4092

Finally, in case there is a limitation on the size of the printed output, please split the output for oneKey.wireEncode().toHex() in two:

System.out.println("Data packet 1: " + oneKey.wireEncode().toHex().substring(0, 2000));
System.out.println("Data packet 2: " + oneKey.wireEncode().toHex().substring(2000));

If the actual encoding is being truncated, then we will need to do a web conference to try to find the problem. (I tried encoding this packet on my Android phone and it works OK.)

Yes, there is a limitation on the size of the printed output.
(1) Encoding size is 2046, and Encoding hex length is 4092

(2) When I split the output in two, the outputs are:

06fd07fa076308067072656669780804524541440804747970650805442d4b4559080f323031373037313054303030303030080f3230313730373131543030303030300803464f52080c746d702d6964656e7469747908116b736b2d31343939393233333636393033140a19080000000757b12c0015fd064982fd012c1c230721080c746d702d6964656e7469747908116b736b2d3134393939323333363639303383010384fd0100ae04affe039148f1dfaa6595c6e0e9fed43db3bd8cc13211b8dee4ee967c7efd45c6f8ccf465a0b2e28f1b9722deef9a5eeca83d42d7516451a643653e498303b28634261b3b99ac8080cea5c7b9766c9097cd1812f8d1305ae2e2da61ea3f701f64254660622fc61f3980272dfca818a6be6888585194606ed03b92e0626a6ad3e0ff5e56573f0544bd8ad3b24cefd04210556b0a7b9abe843521f41bb7ea2196daeda3ee0bd300c7f19e66d0cef7d526c8e7bec8d2449d9a32d69ac6f28035fcd22706029c8acd8dc503c8e1753858b3eb7d7b2552dc3251e96fc1212b2a0e4e0fb70e799f978609f0a07796142db1559a88097da8ff6dfa4ea78cdc5d3a5282fd05151c2a0728080c746d702d6964656e7469747908116b736b2d3134393939323333363639303308056e6f6e636583010185109b2b9f91a412cf1166185a24ea2241e384fd04d0039f49643ea3ee965913f4cbfb730d82c23dfcf420194b51c2533a7063ca2e821a7c62351ef2d32a89e41c955016c0e4ef12e21ed23670ec2c74153796d881c7ce029e8b97f6d914a38db936d7ff9711f0d9006b16b0635386b60c74252dda0ffa71b30bfc1b7d8c58ed467fe06f876a6853513284118b5d6ce8f15f598fc19950637e0ce7399dd92fe684148eaa1e374dd088432f626088a4c1caf1bb31d478a709a9ab2ac7435beb0b742cef9255b6c95da80eadeb5bebea500935bf6dead506f9841666eb5adecaa26673728ca8cd6fef7aa6e34bb60e652fa50c7e6883836f4ae70bd85efa474591d008cafa385c2a1005b44e61f90d0d992a77e6e978f19a43b3d01ec13abca25e9790b4879f396e637943cbdf8976e8b3c4a3333c2b494415ce4cd423b4003639a4c7e8727f1c4d02751dac2f46ccb4b51a8e9204932c1affc570f0ee28d838bd507cca03fbf82c0515897be25bf2427b4b9d692f95f2a914c11690bec4056a61e4d0fa65e23a26b52043d6ac628abb6280052e47e780609ff692485ee0901a7428cdbec6f3d314cd2f62195f2bc940e1264d8dcda7cf5c4ac046c77d00a6484e6457285d7b2b5c2b2a68e2fe663a6d8205f4ef1d7fd3393d1b738574c36942fe250bf180f49aaff5de8a406e63a2dd04c61d477b7b218733e0c43da6f2e6b21f915ff671e8a0ebbb0200e9b9

and

e48c67980c96e7fa29b754bdd0534ea3bb8d472eccdf6c2bffcd8c535a74c865fb133eedaf9ae2f6231af92a6ffc0163d38a92dfab45bd148168b6831183fce17fd7c627c8b5c820d765e70eaa70a510ca0fb4516f55cca540dae962d633e07c51be9c45031de07eb7b9722008dc2c1c7cc1aad4cded813e8ebe7f18a62799f809de9a6d7b8faa6b6c613703d3792c5709438eb3b44206c7b40e5a7e3d672df46c036c668c748fba3458bdda2c198ecbc9d4c3d9ec1f438f2e8598d81c9d23bcfa4c38e9461c0944a397c3d49a59c329574564f7737cca75e0e4b3448173b0f2c0cd85b49e597b6e57f11d384ec45e778eca05c43341494b3270a99cbf3455ca3417e47f743e620cdb86eb9a6df78d6af47bb786a7ca7cde0721acb0563b2eca9f773b7c4c45283b9f153772170629ca01f5bbd77771bb5e3924ae43625f9344ef31987d752fbe139430304af686cac943f326f4a4141525e199c5bf97f095f64b0af11b065a36c1d20cdfec34ab5ae0a6cc7b18d3d9d14d10af61e582c36c5a39dac9933cb07af12a2e5c55e76bf900b2ec81d63360ca966579949decbdfa68de62da680f8f3f82e97319de88727b533fd58bf2aa6462ac1cb6d6b17750851186e984a28dea17ec4cae8ea8a9121aacd908da1fc425c7704bb02a2e870859ef609c9ae0bb631f66bc9c17cc6a2aea7e9bc3f38e6a8dbc116e4ac018463fce12c22086407da269ae0d98da6f8a9fc0cc55430a5828e8091367dc7d5461fc37b8d2d385661b05b939b0387cae11d3c3b0ccef6867e615bc52d529a2d4d360d7a42e1b9c4d470714cbd3d3d0975c9b2f7fea9dbe512e7878620bdd54eba34d54b2861da102fa5e8a50f701d5107827ca92acf1b60a943bca462f5ad9654686d34df393e4f059bf922d4756a0c94a46c7f3ae66230a1e71d26b054c1d0cd74535d9a7847e6e6684b862f05e30cbf389d23a3e34bba3af848e6626fc6fd1f917e055d38adce9bcde5bf1775e7647c5307ac011b859b42838510c929516361b01011c31072f080c746d702d6964656e7469747908034b455908116b736b2d31343939393233333636393033080749442d4345525417fd0100246592dc4d0ff7c63e436a81f3476f0fab34c0475bcc907bb27e8e5e5537ef986823c5700cd948fd20faf03d900d6ad97adc092253ec4ad9be8be033fc9206f5dff9e60faef3adbd110e6cde87daf21c1dbe7957f77c81e671c5a6633249931ef2cf0a6d9ddbc0c2a886632d2b266f25a19f90bd568cbeeb30fd41012c24cba0cda339e5b1070e1ba2266cd379210becab82688c16b5e2ad485eed416c7a58a5c387b3c3f554d262f153e88254d44a3ab72c748a1aed44f3e7814e9e2d45fdd56d58f3840ce5022d0cdc3ac9177529ca07386dad5096a81817cc65cb8ad7801efd316ad305dcca5cda577bc8f17de9a29027875195ede602fa535019424c88c9

(3) If the whole packet is not split, the last few bytes "c8f17de9a29027875195ede602fa535019424c88c9" are missing.

Thanks for providing the non-truncated hex code I wrote a test program and my Android phone is able to decode the Data packet from the hex code. The the wire encoding buffer is correct.

What is your code to create the Face object? Does it use TcpTransport? I ask because the next question is whether the network stack is truncating a packet of size 2046 bytes.

I simply use

    Face face = new Face("localhost"); 

to create the face, so it's TcpTransport.

To provide more info, I also print out the hex code of a data packet generated using the code I posted on #7 (in case I modified something, I post the code here again). This data packet doesn't crash NDN-Android.

        RsaKeyParams params = new RsaKeyParams(2048);
        DecryptKey memberDecryptKey = RsaAlgorithm.generateKey(params);
        Blob decryptKeyBlob = memberDecryptKey.getKeyBits();
        EncryptKey memberEncryptKey = RsaAlgorithm.deriveEncryptKey(decryptKeyBlob);
        Blob encryptKeyBlob = memberEncryptKey.getKeyBits();
        Name name = new Name("/prefix/READ/type/D-KEY/20170709T000000/20170710T000000/FOR")
          .append(keyChain.getCertificate(keyChain.getDefaultCertificateName()).getPublicKeyName());
        System.out.println(name);
        final Data data = new Data(name);
        data.getMetaInfo().setFreshnessPeriod(24 * 265 * 3600 * 1000);
        EncryptParams encryptParams = new EncryptParams(EncryptAlgorithmType.RsaOaep);
        Encryptor.encryptData
          (data, decryptKeyBlob, name, keyChain.getCertificate(keyChain.getDefaultCertificateName()).getPublicKeyInfo().getKeyDer(), encryptParams);
        System.out.println("Data packet: " + data.wireEncode().toHex());
        System.out.println("Encoding size " + data.wireEncode().size());
        System.out.println("Encoding hex length " + data.wireEncode().toHex().length());
        System.out.println("Data packet 1: " + data.wireEncode().toHex().substring(0, 2000));
        System.out.println("Data packet 2: " + data.wireEncode().toHex().substring(2000));
        m_face.registerPrefix(new Name("/prefix"), new OnInterestCallback() {
          @Override
          public void onInterest(Name name, Interest intrst, Face face, long l, InterestFilter i) {
            System.out.println("receive interest: " + intrst.getName());
            try {
              face.putData(data);
            } catch (IOException ex) {
              ex.printStackTrace();
            }
          }

        }, new OnRegisterFailed() {
          @Override
          public void onRegisterFailed(Name name) {
            throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
          }

        });

Data packet: 06fd07af07cb08067072656669780804524541440804747970650805442d4b4559080f323031373037303954303030303030080f3230313730373130543030303030300803464f52080c746d702d6964656e7469747908116b736b2d313439393936373237313936390803464f5208067072656669780804524541440804747970650805442d4b4559080f323031373037303954303030303030080f3230313730373130543030303030300803464f52080c746d702d6964656e7469747908116b736b2d313439393936373237313936391406190454b53c0015fd06cd82fd016e1c65076308067072656669780804524541440804747970650805442d4b4559080f323031373037303954303030303030080f3230313730373130543030303030300803464f52080c746d702d6964656e7469747908116b736b2d3134393939363732373139363983010384fd010034c23c52e498b3a09378047ba66fcfdb6e1750e16f8a6b881c7f3fd0d58eb437e49f3b6ff397d318c9ef530f243462ffdaab61e3396c15fafc6c8d44c6b0a0b761660890db372ca45683b0aa0b49b6767dab1eb736e8c996b946d66a87be45308ed854f0ed3ec77a34d5f432c12786d6b9e6a834ade88635a2e357bfd7a978b0f2d30d2d86114070b514f68d820f548c9caea162365de8baddc255604c0228fa12faa51fe7ddcdcf6df70af85ab567778aa4b8bdb8d901f3e05ecc3d288fcf51cfa0f4c6d7d6605f271a72e760d71954ab5a23a5cf487ef2b63193ff46b3ab1b13b59e94eccdb6af52f0e9ab01d09ecfa995b4490ab62cb71d44581af15cdde482fd05571c6c076a08067072656669780804524541440804747970650805442d4b4559080f323031373037303954303030303030080f3230313730373130543030303030300803464f52080c746d702d6964656e7469747908116b736b2d3134393939363732373139363908056e6f6e63658301018510ff0ba6936cfd9abd71497603f08d592284fd04d0b18595b7af8a6f0fd9ece187206ba493afdd37012ac02fee8bf7fa8fe16f5091474d7d5945c3438493205048f455a4c262c51dbd735b17f7e25cd810667faa17bc1cf9d9519c3458c4746a7c66274b19d3e986f74bff3c232f3357b6d2d23730a43bad9fc4a12e12947e141e87fcd8f3c7c94f1f4836b89765045198af65a56d05a38a22ab63b528677c6bb78a1e941ef88cca6f0fc7f48714f8a3f6aeb168fd81b1c8fda18c79f0abba73f330e44cbee558a0e5ef8e1b0dbf617215ca82dfdaaae7da08ab7b1ad284003029c8e0d1ec875454d8ea7881cc52cde98c4ecc7b7d46e6af4093687d38b9e73a9c6ec0fa441df03dbce21d0f3a7581f6156188ad8c55623da30d94b7c35cc395a21fb9dcacbc48511649ae555f066f1adb25d98bf32c65ecf61949c247c33afe960128227eb80f704a444c7d2d78a27fc3f55a6e662eb5cd019c2f7c7f66043ac093cea8df9ff967c7cca8b6b9a301f8a652903e2789e0afe304a7d029f5e239d4a7cc5d807c37be7bf683e791f84c567542d32d10480edc1bebac515ec6512c1bb6403fd57d249752f890b3121c39118c3fa879eb8d7a99738f6780229b99a20cd9567f84ef4f2188df5ce2fd3fd12a940996a3128d27ab0c9ac9698ac97ca5b2fe69413787ed227122fd024a4e730b73aa07a3372fe5baedfce4b5f794028b469e588514491aa688acd30e882cf7b876a157f5d0385b6661cfce8aa3149b6670b7aa791d2ecb00d5b98c68eddf7688081c2e8cd515f4db60539b9c026de2c497882226b449ee3f732b5bfdf2725535079c5bfffff598478cb3be370220c8c7f582b24e089723c5838b14f1ffcc45f76cc7850b8f7e1097be99a81df1bffdc4a2a459e3dee4915f5af915e2541607362986a78bcb92001acce8e6819222deb13be4b61f911e6988ea5aaff84c15a98e1ce9a93e5eda51c5031bd51f6c099c455147adab6a772194a69663c4ff9f3b8f4199aeae10feb599f7037799d4ee63857b3536d15a904839831b18cede8ddaec83593468392eb475a9c6c36735c05db3cb45ebbfc155b3e6448f3f8c4dbfcc06a9f14a3b73b80fb3f59530a230107ffcc8b209062ff45e5f0f524c09bf310066f2c43e720ab5107a266de0649295f6ddbf2bdde2822a8d5343d49dffd78405b0d9cd3aa32d6072a71c10dfa40cda9a6c5810eac54fff4f445d8e1ddf1f52ea28e93fd5ff5e52ec2a4c49c6fef1d16ec73445f64fdbe7469d817b25f4686444c7258039376ccc7d7f4ce4b6db056e26169e4402119bffdec75d021ea68183c3542eae4d4eb2f70532e27037871f17bdcf15811c98a40124d8982fd3347c75cd9e763f015a94696256d37b62378033a67fa551b11142e0572dea430a8f4479ad4860b9274b72de6069a1841de2c3e8e6aaf466ef2dd8af93312c430afce1d504758561c874d799a63269c5af4f8c50717cfe42dcaa30c2d656e87bcd9a658d6e626bfd0750609b70ed25b81dbb0ed4b123c73fb446da3d2e62cfb0ae4f8dac066ee616cd7f28928291bd8700524692cf94454bacfd1298429e6893b295b7c1f179610b1158b5f70e614997e6a93818fff43eb7aec987145257850f664db33b6bc204e9dead9533d17028bffa99ceee778f03bd5340c35ccb8bf68165b73962173159feb502570e9b168dc436e4f85a2a4926e616edfc2e45fe3020b40c30f0036c4a0618e30f7d7090fe05552e99bc44d85487b647c116051b01011c001700

Encoding size 1971
Encoding hex length 3942
(They are different from the the length info when I create data packet using NAC. Maybe something is wrong here?)

Data packet 1: 06fd07af07cb08067072656669780804524541440804747970650805442d4b4559080f323031373037303954303030303030080f3230313730373130543030303030300803464f52080c746d702d6964656e7469747908116b736b2d313439393936373237313936390803464f5208067072656669780804524541440804747970650805442d4b4559080f323031373037303954303030303030080f3230313730373130543030303030300803464f52080c746d702d6964656e7469747908116b736b2d313439393936373237313936391406190454b53c0015fd06cd82fd016e1c65076308067072656669780804524541440804747970650805442d4b4559080f323031373037303954303030303030080f3230313730373130543030303030300803464f52080c746d702d6964656e7469747908116b736b2d3134393939363732373139363983010384fd010034c23c52e498b3a09378047ba66fcfdb6e1750e16f8a6b881c7f3fd0d58eb437e49f3b6ff397d318c9ef530f243462ffdaab61e3396c15fafc6c8d44c6b0a0b761660890db372ca45683b0aa0b49b6767dab1eb736e8c996b946d66a87be45308ed854f0ed3ec77a34d5f432c12786d6b9e6a834ade88635a2e357bfd7a978b0f2d30d2d86114070b514f68d820f548c9caea162365de8baddc255604c0228fa12faa51fe7ddcdcf6df70af85ab567778aa4b8bdb8d901f3e05ecc3d288fcf51cfa0f4c6d7d6605f271a72e760d71954ab5a23a5cf487ef2b63193ff46b3ab1b13b59e94eccdb6af52f0e9ab01d09ecfa995b4490ab62cb71d44581af15cdde482fd05571c6c076a08067072656669780804524541440804747970650805442d4b4559080f323031373037303954303030303030080f3230313730373130543030303030300803464f52080c746d702d6964656e7469747908116b736b2d3134393939363732373139363908056e6f6e63658301018510ff0ba6936cfd9abd71497603f08d592284fd04d0b18595b7af8a6f0fd9ece187206ba493afdd37012ac02fee8bf7fa8fe16f5091474d7d5945c3438493205048f455a4c262c51dbd735b17f7e25cd810667faa17bc1cf9d9519c3458c4746a7c66274b19d3e986f74bff3c232f3357b6d2d23730a43bad9fc4a12e12947e141e87fcd8f3c7c94f1f4836b89765045198af65a56d05a38a22ab63b528677c6bb78a1e941ef88cca6f0fc7f48714f8a3f6aeb168fd81b1c8fda18c79f0abba73f330e44cbee558a0e5ef8e1b0dbf617215ca82dfdaaae7da08ab7b1ad284003029c8e0d1ec875454d8ea7881cc52cde98c4ecc7b7d46e6af4093687d38b9e73a9c6ec0fa441df03dbce21d0f3a7581f6156188ad8c55623da30d94b7c35cc395a21fb9
Data packet 2: dcacbc48511649ae555f066f1adb25d98bf32c65ecf61949c247c33afe960128227eb80f704a444c7d2d78a27fc3f55a6e662eb5cd019c2f7c7f66043ac093cea8df9ff967c7cca8b6b9a301f8a652903e2789e0afe304a7d029f5e239d4a7cc5d807c37be7bf683e791f84c567542d32d10480edc1bebac515ec6512c1bb6403fd57d249752f890b3121c39118c3fa879eb8d7a99738f6780229b99a20cd9567f84ef4f2188df5ce2fd3fd12a940996a3128d27ab0c9ac9698ac97ca5b2fe69413787ed227122fd024a4e730b73aa07a3372fe5baedfce4b5f794028b469e588514491aa688acd30e882cf7b876a157f5d0385b6661cfce8aa3149b6670b7aa791d2ecb00d5b98c68eddf7688081c2e8cd515f4db60539b9c026de2c497882226b449ee3f732b5bfdf2725535079c5bfffff598478cb3be370220c8c7f582b24e089723c5838b14f1ffcc45f76cc7850b8f7e1097be99a81df1bffdc4a2a459e3dee4915f5af915e2541607362986a78bcb92001acce8e6819222deb13be4b61f911e6988ea5aaff84c15a98e1ce9a93e5eda51c5031bd51f6c099c455147adab6a772194a69663c4ff9f3b8f4199aeae10feb599f7037799d4ee63857b3536d15a904839831b18cede8ddaec83593468392eb475a9c6c36735c05db3cb45ebbfc155b3e6448f3f8c4dbfcc06a9f14a3b73b80fb3f59530a230107ffcc8b209062ff45e5f0f524c09bf310066f2c43e720ab5107a266de0649295f6ddbf2bdde2822a8d5343d49dffd78405b0d9cd3aa32d6072a71c10dfa40cda9a6c5810eac54fff4f445d8e1ddf1f52ea28e93fd5ff5e52ec2a4c49c6fef1d16ec73445f64fdbe7469d817b25f4686444c7258039376ccc7d7f4ce4b6db056e26169e4402119bffdec75d021ea68183c3542eae4d4eb2f70532e27037871f17bdcf15811c98a40124d8982fd3347c75cd9e763f015a94696256d37b62378033a67fa551b11142e0572dea430a8f4479ad4860b9274b72de6069a1841de2c3e8e6aaf466ef2dd8af93312c430afce1d504758561c874d799a63269c5af4f8c50717cfe42dcaa30c2d656e87bcd9a658d6e626bfd0750609b70ed25b81dbb0ed4b123c73fb446da3d2e62cfb0ae4f8dac066ee616cd7f28928291bd8700524692cf94454bacfd1298429e6893b295b7c1f179610b1158b5f70e614997e6a93818fff43eb7aec987145257850f664db33b6bc204e9dead9533d17028bffa99ceee778f03bd5340c35ccb8bf68165b73962173159feb502570e9b168dc436e4f85a2a4926e616edfc2e45fe3020b40c30f0036c4a0618e30f7d7090fe05552e99bc44d85487b647c116051b01011c001700

You said that when you use a 1024-bit RSA key, the D-KEY data packet is under 1500 bytes. Can you please post the hex dump of this data packet? (We can use it to make a simple application that just sends this data packet to NFD to see if it crashes.)

I have finished two experiments:
(1) Check MTU of the my Android phone.
format of the following data is: [interface name] [interface index] [ip addresses] mtu

[lo][1][/::1%1%1][/127.0.0.1]16436
[ifb0][2]1500
[ifb1][3]1500
[sit0][4]1480
[ip6tnl0][5]1452
[rmnet0][6]1500
[rmnet1][7]1500
[rmnet2][8]1500
[p2p0][9][/fe80::a00b:baff:fee0:e160%p2p0%9]1500
[wlan0][10][/2601:647:4601:c5c4:ec45:780c:dfe8:eb31%10%10][/2601:647:4601:c5c4:a20b:baff:fee0:e160%10%10][/fe80::a20b:baff:fee0:e160%wlan0%10][/10.0.0.138]1500

lo has a MTU 16436 >> 1500, and wlan0 has a MTU 1500. As a face connected to lo is used, MTU should not be the cause of the bug.

(2) I used a 1024-bit RSA key to generate D-KEY data, and got the hex dump the data packet.
06fd048a076308067072656669780804524541440804747970650805442d4b4559080f323031373037313054303030303030080f3230313730373131543030303030300803464f52080c746d702d6964656e7469747908116b736b2d31353030303137353437333931140a19080000000757b12c0015fd02d982fd012c1c230721080c746d702d6964656e7469747908116b736b2d3135303030313735343733393183010384fd0100c89d0994eb74cead9fea4d8013df63f7d6b83d430999acf3446882af88abc365486e6687a1f63fd9457be0c3fad8c3c978f43b017c539c225c64ef96cf95d4d17697472975ed75233005d4f03521d2a546a7701f083e052f331bc5c53c326e243087abfa856b82472303dda48c616a46421ed9042875abf1b6eac3236423d91093d24119286e0a9bcd9d316ccebd86084e5ca2f9e2542902d754576b7088aef1d05147e538d4db3741f4d2c15b5b3e5ef9206a6d0c7ef72cf63cf1296536675c9e81fff8d30d847c9e56205f1f542a488de516254db9ff21815f3e07affd525604a92ac203a450fe067a2f581358c4b8049de4eae09ddea82fad60909b19b18a82fd01a51c2a0728080c746d702d6964656e7469747908116b736b2d3135303030313735343733393108056e6f6e63658301018510dbf1a600552cc2d77129756c40a7d2fa84fd01605d3b88a11b81a1f33bd35e1898dd445fcd1980f1965ef64304285ebbbaafbb80959930458551bc37b67a8e0f34e06cc9f3ee084abdbdc97ab294bfcd9336f6267989c9744fa580d6d41caefc7db8cb2d8424d17f40b1f86f3ba3e8edbcdeee9afd147ac4c30ae2bb2a20796faa3a09ad2f37406714968fe707eeac9267d9a470eaf7b3a2076bd65e9c92731212525741bb8faefe504790fac2ae74f8f1581cdb1c7b0b12d3af66c13d409e8ed0c8cc7f8e95393c574b708bea5d613be20194f06d416992b459ebb33f75b9821db76f58c9df74f10c49aa29668e0c26e400a987b3130c158fe54c324dda41ccb3146c6c64f203382b855f10d7aabf7ece55fafb00f51388272b06116a7f2509a25ad56c7fe30f89e99175189e71f7d97cfe3c80b4c74c91ef808a3987d65ed241a6c9f63a988126991301af5b2a2f363114be173ed0d005923c2e7fee341961a7f957c9c03fc9e6d8b51fb5f54d17ffe87c5ba116361b01011c31072f080c746d702d6964656e7469747908034b455908116b736b2d31353030303137353437333931080749442d4345525417fd0100a6f0a731b8b2da6bacf4a953e17cb1a5371d3a07ab311c8eddb00f97ffe6566f9f17e91cad272133e5b19429c8c8d8cfc5f822bb6305ab93813dee28dbc37c5dd269591158419010712cdfd14f51437db476e8c87dbfb655b941c527517242a4313e681628dc39f0391602b0fa036fc11119c1c17a599f5e88a24e83420869e8de63f11d59f082d2f70e3ce763b3ad26fe57b99d40c18d204864062090f37545bca98222ee2efb3b6b9bbd1295aa65df0c8f92bee5082cdfef581984785604b658563b20102b0b2464f12b346174aea3507813489217df957fbf4b4ffc2bc182b05c2e4661424740439f9aed5ff7e5baf8c8e0405a532b3e06857f3e796edf34

Later, I used this hex dump to generate a new Data packet, and send it to NDN-Android when interest comes, NDN-Android still crashes.

I will conduct 3 other experiments later:
(1) check the difference between the two pieces of code (the previous code which generates D-KEY with and without using NAC), to find why the sizes of generated data packets are different, and why this difference affects whether NDN-Android crashes or not.
(2) send the packet generated by the first piece of code directly to NFD (version 0.5.0, which is the same as the version used by NDN-Android) running on Linux/Mac, to see if NFD crashes or not, in order to check whether this is a bug of NFD c++ code or not.
(3) do the same tests on one or more other Android phones, to check if this bug only occurs on the current phone.

I have confirmed that this is not a jNDN bug. It may relate to crystal ndk. Following are reasons

(1) NDN-cxx and NFD code don't have this bug. When the D-KEY generated by the first piece of code (the one employs NAC lib) is sent directly to NFD (version 0.5.0, which is the same as the version used by NDN-Android) running on Linux/Mac, NFD works well. To make the app be able to send the D-KEY to such an NFD, face is created by "Face face = new Face("IP of the Linux/Mac machine")"

(2) The packet forwarding logic doesn't invoke Java code, but only NDN-cxx and NFD native code, which are complied by crystal ndk.

(3) This bug only occurs when freshnessPeriod is set larger than Integer.MAX_VALUE. The first piece of code (the one employs NAC lib) set the D-KEY's freshnessPeriod to be a long int 24 * 365 * 3600000, the bug occurs; the second piece of code set the data packet's freshnessPeriod to be an int (there is a numeric overflow problem, as I didn't put L at the end of the number. although 24 * 365 * 360000 is larger than Integer.MAX_VALUE, due to numeric overflow, the result is still an int number), the bug doesn't occur. I did some other tests to verify this finding.

(4) This bug occurs on many Android phones. I tested (3) on 5 different Android phones (different brands or different Android versions), the same thing happened.

Further tests are still needed to find the specific reason and fix the bug.

I confirmed crash on ARM build for the phone. We actually recently discovered and fixed unaligned memory access during decoding, which could be the reason (or has relation) to the problem. I have back-ported the patch in https://gerrit.named-data.net/#/c/4042/ and for me seem to fix the issue.

@Haitao Zhang, can you confirm that the fix addressed the problem or not? I cannot merge the code / push to google play until you confirm.

Alex Afanasyev wrote:

@Haitao Zhang, can you confirm that the fix addressed the problem or not? I cannot merge the code / push to google play until you confirm.

@Alex, the fix addressed the problem. Thanks!