CRC Check on Extension Blocks Failure

[martinoo31]

I am currently using ION 4.1.2, and I am carrying out interoperability tests with other BP implementations. I modified the file "/bpv7/library/ext/bpextenstions.c" to add CRC16 to extension blocks.

// line 239 Original code
static ExtensionSpec extensionSpecs[] = {
    { PreviousNodeBlk, 0, NoCRC },
    { QualityOfServiceBlk, 0, NoCRC },
    { BundleAgeBlk, 0, NoCRC },
    { SnwPermitsBlk, 0, NoCRC },
    { ImcDestinationsBlk, 0, NoCRC },

    #if RGREB
        { RGRBlk, 0, NoCRC },
    #endif

    #if CGRREB
        { CGRRBlk, 0, NoCRC },
    #endif
    { UnknownBlk, 0, NoCRC }
};

// line 239 Modified code
static ExtensionSpec extensionSpecs[] = {
    { PreviousNodeBlk, 0, X25_CRC_16 },
    { QualityOfServiceBlk, 0, X25_CRC_16 },
    { BundleAgeBlk, 0, X25_CRC_16 },
    { SnwPermitsBlk, 0, X25_CRC_16 },
    { ImcDestinationsBlk, 0, X25_CRC_16 },

    #if RGREB
        { RGRBlk, 0, X25_CRC_16 },
    #endif

    #if CGRREB
        { CGRRBlk, 0, X25_CRC_16 },
    #endif

    { UnknownBlk, 0, X25_CRC_16 }
};

and "/bpv7/library/libbpP.c" to add CRC16 to the payload block.

// Line 62 Original Code
#ifndef PAYLOAD_BLOCK_CRC_TYPE
#define PAYLOAD_BLOCK_CRC_TYPE  0
#endif

// Line 62 Modified Code
#ifndef PAYLOAD_BLOCK_CRC_TYPE
#define PAYLOAD_BLOCK_CRC_TYPE  1
#endif

But then the generated bundle does not get accepted by ION, neither by itself or a completely different ION instance. If I remove the CRC from extensions block the bundle then gets correctly delivered. In ion.log it is stated "CRC check failed on extension block". However, the bundle gets correctly dissected by Wireshark and it is accepted by other BP implementations such as Unibo-BP and ESA BP. Bundle by ESA BP with CRCs on every block are correctly delivered to ION. I have attached the .dmp files I examined with Wireshark. Ion-Ion-CRC16.dmp Ion-Esa-CRC16.dmp Ion-Esa-CRC32.dmp

[iondev33]

Thank you, Martin, for reporting this. We will investigate it.

We are in the final stage of releasing 4.1.3, so the fix may not be available in time. However, 4.1.4 is planned for the end of summer/early fall. We will try to resolve this as soon as possible.

[iondev33]

For clarification, if we understand correctly, you indicated that:

• ESA BP can receive bundles generated by ION with CRCs on every block without error.
• ION can receive bundles generated by ESA BP with CRCs on every block without error.
• You observed an error when ION is built to generate CRC16 for every block and sends bundles to either itself or another instance (which may or may not be built with the CRC16 activated for every canonical block.)

Additional questions for you:

1. Which extension blocks are generated by ESA BP to send to ION?
2. Which extension blocks are generated by ION (modified) to send to ESA BP?

If you could confirm and answer these questions, it would be most helpful. Thank you!

[martinoo31]

Yes, you have understood correctly. I have also done another test, with CRC16 only on the primary block from ESA BP to ION and the bundle was correctly delivered.

While on the matter of extension blocks, all the analysis I am carrying out are based on the packet captures linked above:

• Bundle generated by ION have the following extension blocks: Previous Node (type 6), type 193 (it should be ECOS, although IANA has not standardized it yet), Bundle Age (type 7)
• Bundle generated by ESA BP have the following extension blocks: Previous Node (type 6), Hop Count (type 10), Bundle Age (type 7)

The bundle from ION were sent using bptrace like in the example below

bptrace ipn:1.1 ipn:2.1 ipn:1.0 60 0.0 "Hello ESA"

Node 1 is ION, Node 2 is ESA BP.

[iondev33]

Also just a quick check in your code snippet, you do mean X25CRC16 instead of X25_CRC_16, correct?

[martinoo31]

Yes, it is X25CRC16

[iondev33]

@martinoo31 We believe the problem is with a bad block processing control flag mask. Our testing now passes here. Please try this:

In file: bpv7/library/bpP.h

Change:

#define BLK_PROC_FLAGS_MASK     (475239)

To:

#define BLK_PROC_FLAGS_MASK     23

Let us know if this resolves the issue you observed. Because we are integrating 4.1.3 right now, this fix won't be incorporated until the 4.1.4 release, due out later in the summer.

[martinoo31]

I done some tests and the fix is working correctly. Though, I have only tried with CRC16.

[type6six]

Thanks for confirming CRC16. If you encounter the same issue with CRC32 later, please feel free to submit another ticket. Closing this issue for now.