While building an analysis tool for our community gateway traffic I observed the use of other Major versions than specified in LoRaWAN specificaton 1.1. I have seen usage of numbers 1 to 3 being used.
The specification states that 00 is for LoRaWAN R1 while 01 to 11 are RFU (Reserved for Futur Use.
Is anyone aware of and when so which application is using this Major version?
Are those packets with a valid crc, not something that got mangled somewhere?
And when the CRC is valid, can you somehow ensure it’s LoRaWAN?
(The only way to be sure is by validating the MIC. I don’t recall if the trace part in TTN Console’s gateway’s Traffic page gives you any clue if TTN has successfully matched a message to a registered device. If it does, then the MIC is valid, and the message is LoRaWAN. The gateway’s Traffic page in TTN Console does not reveal if the MIC was valid.)
I have considered that myself too: All gateways have been configured only to pass valid CRC packets.
I cannot confirm for all packets I received but the node I showed has produced more than 16 packets (until I took the snapshot) with increasing frame counter 
That allows me to presume that the node is emitting correct LoRaWAN packets.
I cannot verify MIC of received packets as I only observe received packets.
Also I have to investigate if data is mangled somewhere in the chain. I do know for sure that even when some data is mangled the phenomena seems valid.
Yes, I’d assume that too. Maybe a valid DevAddr prefix can give you a clue too. Also, once the radio transmission is received, I’d not expect the packet to be mangled somewhere in the chain. So, probably LoRaWAN indeed.
3A is unassigned 
could be anyone.
