MIC Mismatch when trying to connect to TTN

[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/