We have overridden the PacketRx method in our custom firmware class as shown below for our FOTA implementation.

void CustomLora::PacketRx(uint8_t port, uint8_t *payload, uint16_t size, int16_t rssi, int16_t snr, lora::DownlinkControl ctrl, uint8_t slot, uint8_t retries, uint32_t address, uint32_t fcnt, bool dupRx) {
	mDotEvent::PacketRx(port, payload, size, rssi, snr, ctrl, slot, retries, address, fcnt, dupRx);
	
	if(port == 200 || port == 201 || port == 202) {
	    Fota::getInstance()->processCmd(payload, port, size);
	}
}

1) I was hoping to intercept the FOTA Frag Session Setup request on port 201 with payload 0200xxxxxxxxxxdddddddd where dddddddd
is the descriptor. However I am not sure how do I distinguish this payloads that arrive on port 201 from the other payload that arrive on this port? We want to be able to make some decisions based on the descriptor passed in this Fragment Session setup packet. Based on the Multitech documentation on FOTA fragmentation the command type “02” is that unique for this payload?

2) I have a similar question on how to intercept the Checksum response packet, which has a payload 800x where x indicates correct (1) or incorrect(0). Is the command type “80” unique to identify the checksum response?

3) Finally if the checksum response is incorrect, does the underlying fota implementation delete the file that was downloaded so far from the external flash and/or does the conduit attempt to send the entire firmware again?

Thanks,
Ajay