MIC Mismatch when trying to connect to TTN

[m_l]

I tried wifi in the past wwhich did nor work. alternative is zigbee whixch is better suited for this but sadly its industrial standart and closed source or everythign is behind a paywal, so Lora it is. My mistake was to assume LoRa and LoRaWAN are the same and people jsut dont like to sue the full name, but apparently LoraWAN is somethign ontop of Lora. simiular to how TCP is basicly ontop the IP protokoll.

[descartes (Nick McCloud)]

@m_l

RTC is nto that hard, as I can edit the code I can jsut add RTC_DATA_ATTR to the varibales of the libraries.

Easy to add RTC, not at all easy to get session details from LMIC to save in RTC ram & then restore them after sleep.

With the deadline you face and the consequent pressures, you would be better served to move to a well supported device as has been suggested above.

[kersing (Jac Kersing)]

@m_l

if the devices shout at each other noise should not be an issue so that is good.

Let’s hope none of your tutors read along or else you will have a hard time while defending your choices.

Overloading receiver circuits results in malformed signals which means data corruption resulting in retransmissions because CRC or MIC fails.

[terrillmoore (Terry Moore)]

You don’t mention what gateway is used. I have seen problems with the packet forwarder on the gateway discarding packets where the first 4 bytes (after the header byte) are all zero. Normally not a problem, but a join request with an AppEUI of all zero will have the first 4 bytes all zero. There is nothing special about the AppEUI; you can set it to any value you like. If you chose 01-01-01-01-01-01-01-01, you will guarantee that the AppEUI won’t trigger the discard.

The mentioned delays are because of duty-cycle limitations. The LMIC is not fully compliant in the backoff calculations from the LoRaWAN spec, but it does comply with regulatory limitations (less strict than join backoff instructions in 1.0.3).

There is a good Python script for decoding things: GitHub - tanupoo/lorawan-parser: a parser of LoRaWAN PHY payload for Python3 – if you use that to try to decode the uplink traffic, you may be able to play around with byte orders etc., and figure out what’s going on.

Good luck!
–Terry

[Jeff-UK]

@terrillmoore

I have seen problems with the packet forwarder on the gateway discarding packets where the first 4 bytes (after the header byte) are all zero

@kersing Jac is that a condition your MPPF is prone to?

[descartes (Nick McCloud)]

@terrillmoore

You don’t mention what gateway is used.

OP is using someone else’s gateway so unlikely to know.

@terrillmoore

I have seen problems with the packet forwarder on the gateway discarding packets where the first 4 bytes (after the header byte) are all zero.

Any ideas who’s software or what gateways are affected?

[terrillmoore (Terry Moore)]

@descartes

Any ideas who’s software or what gateways are affected?

It is one of the forwarders for the MultiTech. We observed the problem and narrowed it down to the packet forwarder, and then went looking. Jeff Honig of TTN Ithaca has the code on his machine; I looked at it with him a week or two ago; today I’m traveling and can’t check as there are several repos that are pulled together.

If memory serves, we found code that looks for packets with 4 bytes of zero; comments say it’s to reject spurious packets from USB-based LoRa cards. We concluded the code meant to check for a devaddr of zero, but it doesn’t use the packet type from the MHDR; IMO it should not do this unless the packet type is unconfirmed uplink or confirmed uplink. (If you want to find the code yourself, look for four byte-by-byte compares of packet[] to zero, for each of the bytes after the MHDR.) I’ve sent a query to Jeff, will repost after I get word back.

[kersing (Jac Kersing)]

Yes, cause has been found but I need some more testing before I release the fixed sources.

@terrillmoore

If memory serves, we found code that looks for packets with 4 bytes of zero

If you take a moment of two to check GitHub you will find I’ve found the same some
September 14th, the code was added to drop rogue packets created by USB connected concentrators on (yes you guessed it) MultiTech hardware. It didn’t cause issues on V2 because back then everyone was using a real AppEUI. These days it seems there is no need for them so all zeros is recommended triggering the issue in joins.

If you wait a couple of days I intend to push a fix.

[Jeff-UK]

So a round of field upgrades in order?! Perhaps rather than all zeroes as recomendation we change to 010101… as above if not using a ‘real’ ID (or the other trick of duplicate Dev EUI?)

[terrillmoore (Terry Moore)]

@kersing

If you take a moment of two to check GitHub you will find I’ve found the same some
September 14th, the code was added to drop rogue packets created by USB connected concentrators on (yes you guessed it) MultiTech hardware.

I guess crossing messages. We have about 100 MultiTechs deployed, and first noticed this issue as soon as we upgraded to V3, but we didn’t get a chance to check the code until more recently. In any case, we have remote management software so we can push updates.

I have no objection to checking mote address for zero; but those four bytes are only the mote address if MHDR says that the packet is an unconfirmed or confirmed uplink.

For those who can’t push updates, an AppEUI of 0x1 is sufficient as long as the user doesn’t hit endian issues (and that’s what we normally use at TTN NY). Using 0x01010101010101 avoids endian issues.

[m_l]

THe gatway used is a RAK7258: Indoor LoRaWAN Gateway - Compact, Quick, Easy Installation - IoT Made Easy, and its managed from my university. other devices do work.

@kersing

Let’s hope none of your tutors read along or else you will have a hard time while defending your choices.

Overloading receiver circuits results in malformed signals which means data corruption resulting in retransmissions because CRC or MIC fails

those effects honestly sound super interesting, I wish I had courses about these topics and more advanced electronics

@descartes

Easy to add RTC, not at all easy to get session details from LMIC to save in RTC ram & then restore them after sleep.

even if I edit the library itself?

@descartes

With the deadline you face and the consequent pressures, you would be better served to move to a well supported device as has been suggested above.

chances are low it will arrive on time alias if I order now it will take 3 weeks at best until it arrives.

@terrillmoore

If you chose 01-01-01-01-01-01-01-01, you will guarantee that the AppEUI won’t trigger the discard.

that is a good idea I will try that. if it still triggers a MIC Mismatch, even when I am far away so I dont overload the circuit, what else can I try ? (besides from trying to switch btween big and little endien for the AppKey) ?

[descartes (Nick McCloud)]

@m_l

@descartes

Easy to add RTC, not at all easy to get session details from LMIC to save in RTC ram & then restore them after sleep.

even if I edit the library itself?

You can try, but when you start searching the forum, you’ll find out what reality means.

@m_l

besides from trying to switch btween big and little endien for the AppKey

You can try, but when you start reading the instructions, you’ll see that it’s not endian sensitive.

[m_l]

Thanks everone! I changed JoinEUI to 2222… DevEUI to 44444… AppKey to 666… and it worked. Which means software and hardware can work! (this was ma greatest fear) now I need to find actual save value which are somehwat secure and find out what was the issue. ( I als changed the transmission window back to 60 seconds )

Edit just notived the line:

os_setTimedCallback(&sendjob, os_getTime()+sec2osticks(TX_INTERVAL), do_send);

so the 5 seconds would have only been used for the messages after the device joined, thats why it never used that number befor.

[kersing (Jac Kersing)]

@terrillmoore

have no objection to checking mote address for zero; but those four bytes are only the mote address if MHDR says that the packet is an unconfirmed or confirmed uplink.

It has been a while since I worked on that issue, however what I recall is that the data I was getting was mostly random with just a few bytes consistently providing the same values indicating it wasn’t a valid uplink. I need to check again with MultiTech hardware to find the other ‘stable’ bytes to see if I can refine the valid uplink check.
This will take some time as I’m rebuilding my Linux development system after the previous system died and I don’t have the toolchains available yet.
The fix for other platforms will be available soon. (Basically just removing the check as it isn’t needed)

[descartes (Nick McCloud)]

@m_l

I changed JoinEUI to 2222… DevEUI to 44444… AppKey to 666

So, to clarify, you changed the JoinEUI as suggested 3 days ago in post 9 and here we are on post 40 and now you have it working. What does this suggest to you?

Your DevEUI is not a legal one to use. Please use one generated by the console or a locally administered address. As it happens all 2’s is OK for a JoinEUI

@m_l

I als changed the transmission window back to 60 seconds

You were told about this 3 days ago on post 9. This is still in breach of FUP - if you don’t start responding to this matter, you may well find that further interest in helping you becomes more & more sporadic.

@m_l

now I need to find actual save value which are somehwat secure and find out what was the issue

Please don’t waste your time trying to work out ‘the issue’ - it’s a long way inside the LoRaWAN system - you can get an official DevEUI from the console, you can use all 2’s for the JoinEUI or, from a forum search, use this tool to create a valid EUI that won’t clash with anyone else: Random EUI or Key generator and you can get the console to generate an AppKey.

[descartes (Nick McCloud)]

@terrillmoore

For those who can’t push updates, an AppEUI of 0x1 is sufficient as long as the user doesn’t hit endian issues (and that’s what we normally use at TTN NY). Using 0x01010101010101 avoids endian issues.

This is NOT a locally administered address and should not be used or suggested (and it’s not actually 8 bytes either). I know this because I read this post:

DevEUI for non-hardware assigned values

You’ll have to judge whether you want to use a random ID. However, the definition of EUI-64 allows for this. The definition is given in chapter 8 of the IEEE-802 spec (freely available at http://standards.ieee.org/getieee802/download/802-2014.pdf). In section 8.2, they describe the u/l bit (bit 1) of byte 0 of EUI-64. If you set that bit, you have a “locally administered address”. Bit 0 always has to be zero for addresses. So a legitimate way of generating a random address, with very low proba…

Please enjoy the irony! I find this tool useful: Random EUI or Key generator

The OP managed to stumble upon all 2’s which is OK.

[m_l]

@descartes

So, to clarify, you changed the JoinEUI as suggested 3 days ago in post 9 and here we are on post 40 and now you have it working. What does this suggest to you?

I also wrote back then that I could not change the JoinEUI via TTN I needed to make a new device to enter all numbers form scratch. Also as stated only when I am away from home I can actually test changes thats why it takes so long to test stuff.

@descartes

Your DevEUI is not a legal one to use. Please use one generated by the console or a locally administered address. As it happens all 2’s is OK for a JoinEUI

as states

now I need to find actual save value which are somehwat secure

@descartes

You were told about this 3 days ago on post 9. This is still in breach of FUP - if you don’t start responding to this matter, you may well find that further interest in helping you becomes more & more sporadic.

this value was never used in the first place as stated above.

@descartes

Please don’t waste your time trying to work out ‘the issue’ - it’s a long way inside the LoRaWAN system - you can get an official DevEUI from the console, you can use all 2’s for the JoinEUI or, from a forum search, use this tool to create a valid EUI that won’t clash with anyone else: Random EUI or Key generator and you can get the console to generate an AppKey.

I used the console to generate random value the first time and it did not work, finding the issue for me is finding out what value actually causes the issue - alias what value can be a actuall good random value and which one cant.

Another question. if I just send LoRa messages constantly is this also against the spec or is that ok? (asking because a random tutorial did that to test out how good some antenna design where and what distance they provided)

[Jeff-UK]

@m_l

because a random tutorial did that to test

If one guy posts a video of crashing himself into a brick wall would you follow that? There is a lot of bad advice and poor info on the net…that is fine in an RF anechoic chamber for characterising an antenna as a test set up but should not be used in the open depending on where in the world…remember the spectrum is a shared resource for all and in most bands and locations where LoRa would be used there are regulatory limits wrt duty cycle, dwell time or what ever with penal/judicial backing - be warned. Also where a short range RF system may only impact a few LORa (its in the name!) will impact many more and further afield if you abuse the airwaves… just saying…

[descartes (Nick McCloud)]

@m_l

I used the console to generate random value the first time and it did not work, finding the issue for me is finding out what value actually causes the issue - alias what value can be a actuall good random value and which one cant.

The console provides official EUI’s that cost TTI money. They are not random.

You do not have the working knowledge to debug this - accept that an all 0’s JoinEUI does not work and move on and read the learning materials: https://www.thethingsnetwork.org/docs/lorawan/