Beantwoord

MIC Verifieren RX2

  • 25 November 2020
  • 4 reacties
  • 277 keer bekeken
O

Ik heb een vraag met betrekking tot het ontvangen van data op het RX2 slot. 

Het lukt me niet om de MIC te verifieren op het RX2 slot. Het bericht is compleet verkeerd.(Frequenties in CFList zijn niet in de goede range)
Op het RX1 Slot heb ik geen problemen.

Kan het zijn dat de berekening/decryptie anders is op RX2? ik kan hier geen aanwijzingen voor vinden.

Is het ook mogelijk om een receive op RX2 te forceren. Op kantoor krijg ik alles op RX2, omdat het in de stad is en in een kantoorgebouw. Thuis kan ik RX2 niet testen, ik krijg daar alles op RX1 binnen. 

Alvast bedank.

 

Of topic vraag:  Hoe log ik in op de KPN Forums via GRIP? Het lukt me alleen door elke keer m’n wachtwoord te resetten. 

 

icon

Beste antwoord door oetzevandenbroek 1 December 2020, 15:41

Bekijk origineel

4 reacties

O

Als extra toevoeging op dit bericht.

Het lukt ook niet om een unconfirmed data down bericht te verifieren met het normale RX1 slot. 

Het verifieren van de join-accept data lukt wel. En ik kan met die gegevens een  bericht sturen.

Na veel uitzoekwerk en veel uistluitingen kan ik het volgende zeggen:
Ervanuitgaande dat deze website klopt: https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/?data=60FFEAB31520000000665FEE04510000000000571654D358E7E9A8CC53DC4B0999C144269F&nwkskey=055BD52EB1AAF547C737CF9C43F2552C&appskey=7D2B6AD7D77F737F18C293B9C1D65160

Klopt mijn payload decryption.
Klopt mijn MIC verificatie.
Komt het MAC commando wat door KPN word gestuurd met de eerste 5 bytes altijd overeen.
En lijkt het alsof het bericht wat door de Portal wordt gestuurd niet het bericht is wat ik ontvang. 
Het Device  address komt wel overeen met het Device address wat ik in de JOIN Accept ontving, dus ik ga ervanuit dat het bericht wel voor mij bestemd is. 
 

Rick S.
Rank
Reputatie 7
Badge +6

Goedemiddag @oetzevandenbroek,

Daar ben ik dan! 
Zoals u wellicht ook al vermoedde ben ik gelijk aan de slag gegaan toen ik uw topic zag. Ik heb dit weer met wat collega's besproken . Het issue waar u tegenaan loopt is best wel een uitdaging. Wij zien namelijk dat niet veel gebruikers zelf de MIC verificatie doen. Doordat het een diep technisch verhaal is kan het eigenlijk aan veel zaken liggen, maar uiteraard doen we onze uiterste best om u verder te helpen. 

Er is geen verschil in MIC-berekening tussen RX1 en RX2. Maar als de decryptie van de join accept wel lukt en die van een bericht niet, dan lijkt het erop dat u misschien de verkeerde key gebruikt voor de decryptie?

De join accept is namelijk encrypted met de AppKey. Vervolgens zit in de join accept informatie waarmee een NwkSKey en een AppSKey af te leiden zijn. Vervolgens wordt de NwkSKey gebruikt om de MIC te verifiëren en de AppSKey om de data te decrypten.

Dan over de MAC command. Multiple byte waardes in een Mac command worden litte endian verstuurd. In het device moeten de bytes omgedraaid worden om de juiste waarde te krijgen. Hieronder een voorbeeld aan de hand van een new channel request command: 
 

Example command: 0708f8008450

Opsplitsing:

07                      command identifier, 0x07 = NewChannelReq

08                      ChIndex, 0x08 = Channel 8

f80084              Freq, actual channel frequency in Hz is 100 x Freq

                            little endian f8 00 84 à 84 00 f8, 0x8400f8 = 8651000.

                           8651000 x 100 = 865.100.000 Hz = 865,1 MHz.

50                       DRRange, 0x50 -> MaxDr = 5 (SF7), MinDR = 0 (SF12)

 

De keuze tussen RX1 en RX2 is afhankelijk van het bereik van de uplink waarop geantwoord wordt. Bij goed bereik is de kans groter dat RX1 gekozen wordt, bij slecht bereik wordt er eerder voor RX2 gekozen. Maar als het gateway die de downlink stuurt druk is (= veel andere devices te bedienen heeft) dan zal er ook weer eerder voor RX2 gekozen worden. Het is niet mogelijk om de keuze voor RX1 of RX2 van tevoren vast te zetten. Maar door het bereik van het device te verslechteren kan je de kans op RX2 dus wel vergroten.

Hopelijk kunt u hiermee verder! 

Met vriendelijke groet, Rick | - Is uw vraag beantwoord? Markeer de reactie met de oplossing als 'Beste antwoord' -
O

Bedankt voor het uitgebreide antwoordt,

ik heb ook niet stil gezeten, en kan nu zeggen dat het me wel gelukt is.

Het probleem zat hem in de chip die ik gebruikte SX127, die een bug bevat. Ik moest speciale registers zetten die niet in datasheet vernoemd waren maar in de Errata. Waarom mijn bericht dan altijd klopte voor de eerste 5 bytes kan ik nog niet zeggen. 

Het klopt dat het idd niet veel voorkomt dat een MIC verfieren zelf wordt gedaan, en ik weet dat dat een extra uitdaging bezorgd. 

De keys die ik gebruikte klopte wel, anders kan ik geen berichten sturen naar KPN. 

Ik heb het signaal kunnen verslechteren nu, een metalen vergiet doet wonderen

Rick S.
Rank
Reputatie 7
Badge +6

Goedemorgen, 

Geen probleem hoor! We denken graag met u mee. 
Het duurt soms alleen even omdat wij ook moeten puzzelen. Gelukkig is het nu opgelost.
En waar een metalen vergiet wel niet goed voor kan zijn he. 

Met vriendelijke groet, Rick | - Is uw vraag beantwoord? Markeer de reactie met de oplossing als 'Beste antwoord' -

Reageer


Forumvoorwaarden