brocaar / lorawan

Package lorawan provides structures and tools to read and write LoraWAN messages from and to a slice of bytes.

LoRaWAN (Go)

Package lorawan provides structures and tools to read and write LoRaWAN 1.0 and 1.1 frames from and to a slice of bytes.

The following structures are implemented (+ fields):

PHYPayload    (MHDR | MACPayload | MIC)
MACPayload    (FHDR | FPort | FRMPayload)
FHDR          (DevAddr | FCtrl | FCnt | FOpts)

The Following message types (MType) are implemented:

• JoinRequest
• RejoinRequest
• JoinAccept
• UnconfirmedDataUp
• UnconfirmedDataDown
• ConfirmedDataUp
• ConfirmedDataDown
• Proprietary

The following MAC commands (and their optional payloads) are implemented:

• ResetInd
• ResetConf
• LinkCheckReq
• LinkCheckAns
• LinkADRReq
• LinkADRAns
• DutyCycleReq
• DutyCycleAns
• RXParamSetupReq
• RXParamSetupAns
• DevStatusReq
• DevStatusAns
• NewChannelReq
• NewChannelAns
• RXTimingSetupReq
• RXTimingSetupAns
• TXParamSetupReq
• TXParamSetupAns
• DLChannelReq
• DLChannelAns
• RekeyInd
• RekeyConf
• ADRParamSetupReq
• ADRParamSetupAns
• DeviceTimeReq
• DeviceTimeAns
• ForceRejoinReq
• RejoinParamSetupReq
• RejoinParamSetupAns
• PingSlotInfoReq
• PingSlotInfoAns
• PingSlotChannelReq
• PingSlotChannelAns
• BeaconFreqReq
• BeaconFreqAns
• DeviceModeInd
• DeviceModeConf
• Proprietary commands (0x80 - 0xFF) can be registered with RegisterProprietaryMACCommand

Sub-packages

• airtime functions for calculating TX time-on-air
• band ISM band configuration from the LoRaWAN Regional Parameters specification
• backend Structs matching the LoRaWAN Backend Interface specification object
• backend/joinserver LoRaWAN Backend Interface join-server interface implementation (http.Handler)
• applayer/clocksync Application Layer Clock Synchronization over LoRaWAN
• applayer/multicastsetup Application Layer Remote Multicast Setup over LoRaWAN
• applayer/fragmentation Fragmented Data Block Transport over LoRaWAN
• applayer/firmwaremanagement Firmware Management Protocol over LoRaWAN
• gps functions to handle Time <> GPS Epoch time conversion

Documentation

See https://godoc.org/github.com/brocaar/lorawan. There is also an examples section with usage examples. When using this package, knowledge about the LoRaWAN specification is needed. You can download the LoRaWAN specification here: https://lora-alliance.org/lorawan-for-developers

Support

For questions, feedback or support, please refer to the ChirpStack Community Forum: https://forum.chirpstack.io.

License

This package is distributed under the MIT license which can be found in LICENSE. LoRaWAN is a trademark of the LoRa Alliance Inc. (https://www.lora-alliance.org/).

lorawan's Issues

rxInfoSet --> phyPayload --> frmPayload Decrypted

Hi @brocaar ,

I am trying to get some information about decoding the framepayload at "frames_logs", at LoRa Server.

I can get easily decode the payload at mqtt broker using a python script and then doing decode 64 to hex. So my payload sent over the node is the same hex value!

But at postgresql database, the frame payload is some kind different. :/

When I receive from broker on my python application it appears "AQDwBQHy/1H/Wg==" (base64) --> x0100F00501F2FF51FF5A. Thats correct! It is the same frame I've sent over the node.

However when i check on postgres' database, the frame header value also in base 64 would be the same, but there appears "+OU1NBf6d+EHcg==" --> xf8e5353417fa77e10772,

Converting to hex I can take the data correctly size of information, but the frame payload doesnt.

Please give me a light how to proceed :) I will keep studynd and searching how to. In case i got it I will put here the answer.

Best Regards,
Rogério Cassares Pires.

Range problem

Hi i have ported complete semtech Lorawan Stack to my MCU and using sx1276 via spi. I am able to send packet but my rssi value is -65 when i placed my end node close to gateway. whereas when i used Risinghf Modem with gateway at same distance his rssi value is -20 to -25. I am unable to debug error.

stm32wl55

Dear Sir

I work to a representative of Wisol in South America.

I am starting blogs about TINYGO and our module is the LSM110A (STM32WL55)

https://ninab3-python.blogspot.com/2022/12/u-blox-nina-b302-rodando-tinygo.html
https://ninab3-python.blogspot.com/2022/12/wisol-lsm110a-rodando-tinygo-blynk-led.html
Both are running...

Can you help me where to include the LoRaWAN package to compile it on TINYGO FOLDER structure ?

├───bin
├───lib
│ ├───clang
│ │ └───include
│ ├───CMSIS
│ │ └───CMSIS
│ │ └───Include
│ ├───compiler-rt-builtins
│ │ ├───aarch64
│ │ ├───arm
│ │ ├───Darwin-excludes
│ │ ├───hexagon
│ │ ├───i386
│ │ ├───macho_embedded
│ │ ├───ppc
│ │ ├───riscv
│ │ ├───ve
│ │ └───x86_64
│ ├───macos-minimal-sdk
│ │ ├───download
│ │ ├───src
│ │ │ ├───arm64
│ │ │ ├───usr
│ │ │ │ └───include
│ │ │ │ ├───arm
│ │ │ │ ├───arpa
│ │ │ │ ├───i386
│ │ │ │ ├───libkern
│ │ │ │ │ ├───arm
│ │ │ │ │ └───i386
│ │ │ │ ├───mach
│ │ │ │ │ ├───arm
│ │ │ │ │ ├───i386
│ │ │ │ │ └───machine
│ │ │ │ ├───machine
│ │ │ │ ├───malloc
│ │ │ │ ├───protocols
│ │ │ │ ├───secure
│ │ │ │ ├───sys
│ │ │ │ │ ├───_pthread
│ │ │ │ │ └───_types
│ │ │ │ ├───xlocale
│ │ │ │ └───_types
│ │ │ └───x86_64
│ │ └───test
│ ├───mingw-w64
│ │ ├───mingw-w64-crt
│ │ │ ├───def-include
│ │ │ └───lib-common
│ │ └───mingw-w64-headers
│ │ ├───crt
│ │ │ ├───sdks
│ │ │ ├───sec_api
│ │ │ │ └───sys
│ │ │ └───sys
│ │ └───defaults
│ │ └───include
│ │ └───sdks
│ ├───musl
│ │ ├───arch
│ │ │ ├───aarch64
│ │ │ │ └───bits
│ │ │ ├───arm
│ │ │ │ └───bits
│ │ │ ├───generic
│ │ │ │ └───bits
│ │ │ ├───i386
│ │ │ │ └───bits
│ │ │ └───x86_64
│ │ │ └───bits
│ │ ├───crt
│ │ ├───include
│ │ │ ├───arpa
│ │ │ ├───net
│ │ │ ├───netinet
│ │ │ ├───netpacket
│ │ │ ├───scsi
│ │ │ └───sys
│ │ └───src
│ │ ├───env
│ │ ├───errno
│ │ ├───exit
│ │ │ └───arm
│ │ ├───include
│ │ │ ├───arpa
│ │ │ └───sys
│ │ ├───internal
│ │ │ ├───i386
│ │ │ └───sh
│ │ ├───malloc
│ │ ├───math
│ │ │ ├───aarch64
│ │ │ ├───arm
│ │ │ ├───i386
│ │ │ ├───mips
│ │ │ ├───powerpc
│ │ │ ├───powerpc64
│ │ │ ├───riscv64
│ │ │ ├───s390x
│ │ │ ├───x32
│ │ │ └───x86_64
│ │ ├───mman
│ │ ├───signal
│ │ │ ├───aarch64
│ │ │ ├───arm
│ │ │ ├───i386
│ │ │ ├───m68k
│ │ │ ├───microblaze
│ │ │ ├───mips
│ │ │ ├───mips64
│ │ │ ├───mipsn32
│ │ │ ├───or1k
│ │ │ ├───powerpc
│ │ │ ├───powerpc64
│ │ │ ├───riscv64
│ │ │ ├───s390x
│ │ │ ├───sh
│ │ │ ├───x32
│ │ │ └───x86_64
│ │ ├───stdio
│ │ ├───string
│ │ │ ├───arm
│ │ │ ├───i386
│ │ │ └───x86_64
│ │ ├───thread
│ │ │ ├───aarch64
│ │ │ ├───arm
│ │ │ ├───i386
│ │ │ ├───m68k
│ │ │ ├───microblaze
│ │ │ ├───mips
│ │ │ ├───mips64
│ │ │ ├───mipsn32
│ │ │ ├───or1k
│ │ │ ├───powerpc
│ │ │ ├───powerpc64
│ │ │ ├───riscv64
│ │ │ ├───s390x
│ │ │ ├───sh
│ │ │ ├───x32
│ │ │ └───x86_64
│ │ ├───time
│ │ └───unistd
│ │ ├───mips
│ │ ├───mips64
│ │ ├───mipsn32
│ │ ├───sh
│ │ └───x32
│ ├───nrfx
│ │ ├───doc
│ │ │ ├───buildfiles
│ │ │ └───config_dox
│ │ ├───drivers
│ │ │ ├───include
│ │ │ └───src
│ │ │ └───prs
│ │ ├───hal
│ │ ├───helpers
│ │ ├───mdk
│ │ ├───soc
│ │ └───templates
│ ├───picolibc
│ │ └───newlib
│ │ ├───libc
│ │ │ ├───ctype
│ │ │ ├───include
│ │ │ │ ├───machine
│ │ │ │ ├───rpc
│ │ │ │ ├───ssp
│ │ │ │ └───sys
│ │ │ ├───locale
│ │ │ ├───string
│ │ │ └───tinystdio
│ │ │ └───ryu
│ │ └───libm
│ │ ├───common
│ │ └───math
│ └───wasi-libc
│ └───sysroot
│ ├───include
│ │ ├───arpa
│ │ ├───bits
│ │ ├───net
│ │ ├───netinet
│ │ ├───netpacket
│ │ ├───scsi
│ │ ├───sys
│ │ └───wasi
│ └───lib
│ └───wasm32-wasi
├───pkg
│ ├───thumbv6m-unknown-unknown-eabi-cortex-m0
│ │ ├───compiler-rt
│ │ └───picolibc
│ │ └───include
│ ├───thumbv6m-unknown-unknown-eabi-cortex-m0plus
│ │ ├───compiler-rt
│ │ └───picolibc
│ │ └───include
│ └───thumbv7em-unknown-unknown-eabi-cortex-m4
│ ├───compiler-rt
│ └───picolibc
│ └───include
├───src
│ ├───crypto
│ │ ├───internal
│ │ │ └───boring
│ │ │ └───sig
│ │ └───rand
│ ├───device
│ │ ├───arm
│ │ ├───arm64
│ │ ├───avr
│ │ ├───esp
│ │ ├───kendryte
│ │ ├───nrf
│ │ ├───nxp
│ │ ├───riscv
│ │ ├───rp
│ │ ├───sam
│ │ ├───sifive
│ │ └───stm32
│ ├───examples
│ │ ├───adc
│ │ ├───blinkm
│ │ ├───blinky1
│ │ ├───blinky2
│ │ ├───button
│ │ ├───button2
│ │ ├───can
│ │ ├───caninterrupt
│ │ ├───dac
│ │ ├───echo
│ │ ├───echo2
│ │ ├───gba-display
│ │ ├───hid-keyboard
│ │ ├───hid-mouse
│ │ ├───i2s
│ │ ├───mcp3008
│ │ ├───memstats
│ │ ├───microbit-blink
│ │ ├───pininterrupt
│ │ ├───pwm
│ │ ├───rand
│ │ ├───serial
│ │ ├───systick
│ │ ├───temp
│ │ ├───test
│ │ ├───uart
│ │ ├───usb-midi
│ │ └───wasm
│ │ ├───callback
│ │ ├───export
│ │ ├───invoke
│ │ ├───main
│ │ └───slices
│ ├───internal
│ │ ├───bytealg
│ │ ├───fuzz
│ │ ├───reflectlite
│ │ └───task
│ ├───machine
│ │ └───usb
│ │ ├───cdc
│ │ ├───hid
│ │ │ ├───keyboard
│ │ │ └───mouse
│ │ └───midi
│ ├───net
│ ├───os
│ │ └───exec
│ ├───reflect
│ ├───runtime
│ │ ├───cgo
│ │ ├───debug
│ │ ├───internal
│ │ │ └───sys
│ │ ├───interrupt
│ │ ├───pprof
│ │ ├───trace
│ │ └───volatile
│ ├───sync
│ ├───syscall
│ └───testing
└───targets

Thanks!

Downlink Problem in "C" type device

Hi,

I am sending Confirmed downlink to a C type device.
I have observed the following:
"The downlink is not sent immediately to the device. The downlink is sent after the next uplink message. And if the device does not send ACK back to the server then the server keeps on sending the downlink after each subsequent uplink. It never stops."

Please help.

MHDR

I have a question(not so a issue), by the documentation MHDR has one more field RFU. Why you skipped in your implementation, is there some reason?

Host Controller to sleep mode in RX windows

Hi,

Can we make host controller to sleep mode when LoRa module (SX1262) is in receive mode (RX1 and RX2 windows)??

Add code example for decoding a PHYPayload

2.4GHz MAC-Command pending error, Frequency mismatching

Hi, I’m trying to utilize 2.4GHz band for communication with a STM32 based sensor and although I’m getting the data consistently, I’m still seeing this error in the network server logs:

The frequency field is 24 bits, thus the max value is (2^24)-1) which is same for both Sub-GHz and 2.4GHz. Only difference is for 2.4GHz is that the frequency is multiplied by 200 instead of 100.

Handle unknown MAC commands according to LoRaWAN specification

Returning an error in https://github.com/brocaar/lorawan/blob/master/fhdr.go#L198 stops processing of the entire message, while the LoRaWAN specification only says that "the first unknown MAC command terminates the processing of the MAC command sequence" (v1.0.1, bottom of page 22).

A simple break would resolve this issue, but in some cases it might be good to log an error as well. (See https://github.com/TheThingsNetwork/lora-gateway-bridge/commit/d5662313741364a129709b9b522ef29eacce0438)

RTC settings

Is there any reliable way to change the RTC?
When I set the RTC date and time (HAL_RTC_SetTime / HAL_RTC_SetDate), the currently running timers (TimerEvent_t) may be broken!
We may need to stop all timers first, then change/set the date and time, and then restart the timers. But it's not quite easy ... How to do it easily?

EDITED: Sorry you are right I got the wrong repository!

FATA[0000] NetID parse error: lorawan: exactly 3 bytes are expected

Аt startup I get the following error:
FATA[0000] NetID parse error: lorawan: exactly 3 bytes are expected

/etc/systemd/system/loraserver.service.d/loraserver.conf content:

[Service]
Environment="NET_ID=010203"
Environment="BAND=EU_863_870"
Environment="HTTP_BIND=0.0.0.0:8000"
Environment="POSTGRES_DSN=postgres://loraserver:dbpassword@localhost/loraserver$

Environment="DB_AUTOMIGRATE=True"

Host platform: Raspberry PI3

LoRaWAN1.1 and LoRaWAN 1.0.4

Hi Brocaar,

We are currently using the LoRaMAC_node stack for LoRaWAN v1.0.3 in our project and are planning to upgrade it. Our target is to move to LoRaWAN 1.1, but we also consider using LoRaWAN v1.0.4. Is there a release of the LoRaBasicsModem from Semtech that supports LoRaWAN 1.1? Additionally, if we opt for LoRaBasicsModem with LoRaWAN v1.0.4, could you highlight the key differences or potential feature limitations compared to LoRaWAN 1.1? Understanding these differences is crucial for us to make a decision.

Thank you,
Sravs

Implement AS923 and SK920-923 Bands

On 15 November, the LoRa Alliance released the LoRaWAN 1.0.2 Specification and LoRaWAN Regional Parameters 1.0 that includes specifications for the Asian 923 MHz bands and the South Korean 920-923 MHz band.

Shouldn't be much work to implement these in the band package. Let me know if I can help with this.

Async request/response handling sometimes fails

The current solution run the whole subscription phase in a separate go-routine, unfortunately in some fast flows this results in the subscription not being setup completely before the response is published on the Redis channel.

Typically one can find these errors:

Dec 10 11:27:22 lns-roaming.demo.netmoregroup.com chirpstack-network-server[9990]: time="2021-12-10T11:27:22.663521545Z" level=info msg="roaming: api request received" async_client=true ctx_id=21933ed4-7124-467e-8399-a73c2de975c1 message_type=XmitDataAns receiver_id=000001 sender_id=c00012 transaction_id=3816299885
Dec 10 11:27:24 lns-roaming.demo.netmoregroup.com chirpstack-network-server[9990]: time="2021-12-10T11:27:24.67452184Z" level=error msg="downlink/data: XmitDataReq failed" ctx_id=1dba3435-a83d-48b3-90ba-54bf2cc0ffaa dev_eui=0018b20000020450 error="async timeout" net_id=c00012

I have made a pull request to solve this by

1. Move the subscription setup back to the sync flow.
2. Force a receive of the subscription successful message to make sure subscription is completed.
3. Wait for the response in a separate go-routine.

For further info/explanation, please review this issue redis/go-redis#575 (comment)

PHYPayload Unmarshalling -> uplink

Hey !
I just stumble across a small issue. How to unmarshal a payload if you don't know by advance if its uplink or downlink ?

payload = new(PHYPayload) // or PHYPayload{}, doesn't really matter here
payload.UnmarshalBinary(raw) 

PHYPayload.uplink is false by default, so, the above line is equivalent to:

payload = NewPHYPayload(false)
payload.UnmarshalBinary(raw)

But what if can't make the assumption whether the payload is relative to an uplink or a downlink ?
I feel a bit uncomfortable with having to handle externally to the PHYPayload itself the way it is going to be marshalled or unmarshalled regarding to an unexported attribute. Do you agree ?
Shall we find a way to make unmarshalBinary works in both cases in order to obtain the correct under-relying structure ?

Otherwise, each time one transmits a raw sequence of bytes representing a physical payload, one's also has to transmit whether or not its an uplink or downlink payload (this is obvious when you consider a context where the receiver / sender knows what they are doing, but considering libraries which manipulate payloads out of any context, this is not that straightforward).

As far as I see in the implementation, the uplink attribute is only used by MAC commands to check if the payload refers to a valid command depending on its nature (commands are split into two groups, uplink-related commands, and downlink-related commands). Nevertheless, isn't the nature of the payload defined by the command (and not the opposite way) ?

Let me know,
Thanks.

Use brocaar/lorawan on end-user Lora TinyGo device

Hi,

I’m working on a firmware for a GPS/Lora tracking device (Dragino LGT92 device)
This firmware is written in TinyGO and open-source (https://github.com/ofauchon/zaza-tracker)

This is the device I'm working on :

The firmware is still PoC/WIP, but I can already send GPS position through the Lora tranceiver (SX127x - RFM95).
(with a point to point Lora communication mode, not yet connected to Lorawan network)

I was wondering if I could use "brocaar/lorawan" code to add LoraWAN compatibility.

According to the README:

“Package lorawan provides structures and tools to read and write LoRaWAN 1.0 and 1.1 frames from and to a slice of bytes.”

… So I guess i could build and send all the required packets to join and communicate to Lorawan networks, with this code, right ?

Any comment welcome

Thanks

Olivier

Main package, and pointing IP lorawan

Hi Brocaar!
It's me, again :)

Just summing up:
-> lora server-setup is ok, up and running
-> lora gateway bridge is correctly giving the outputs
-> lora server and lora server-app is running ok !
-> I know the node is activated, transmiting and receiving by the LoRa server analysing the "sents frames" on Gateway guide. (we've signal with a LED flash when node receive confirmed data).

So, lastly I could run the lorawan in Go packets!

I've installed Go and go tools correctly and also I've run the "golang -getting started" an some "golang examples" from repository on github.

I've prepared, install and build your packages from this repository, by using "go get github.com/brocaar/lorawan" so the packets are correctly installed on repository on my computer.

Questions:

1. It's possible run this program in the same local network? The server is in a PC "10.193.101.11" and i'am tryng to run the go package in "10.193.101.12". they are connected by a just by-pass router.

2. In case of running ok from different PCs how can I point? there is in the codes?

3. There is a ready example implementation that I can run and see the data from the node, please? Or I have to make the 'main" package with the import "github.com/brocaar/lorawan" command line and respectives functions in func main () ?

I will looking forward your answer!
Best Regards,

Rogerio

Is there any plan to design a similar package for parsing frames on Python

It seems that only the go language can receive such support.

Incorrect datarate for AS923 in RP2-1.0.0 and later??

After I read RP2-1.0.3 LoRaWAN Regional Parameters. I found that the receive windows datarate value did not limit to DR5 as before. So I start to search for the beginning of this change. And found this value has changed in RP002-1.0.0.

So does this need to change?

lorawan/band/band_as923.go

Lines 73 to 75 in 63df695

	if dr > 5 {
	dr = 5
	}

OptNeg bit

Hello, Brocaar.
The OptNeg bit is described in the lorawan 1.1 specification. It is part of DLSetting JOIN ACCEPT. It characterizes the version of lorawan that is being used device. Now, your server not used it . Do you have plans to use it?

Passive roaming session error when sNS has no info about EDs

Hi,

I'm trying to understand why i'm getting some error messages in passive roaming.

I have the following architecture:

I've created two DNS resolvers one on deveui.iot-roam.net and netid.iot-roam.net

1st LNS: netid is 000001 and JoinEUI 0000000000000001
2nd LNS: netid is 000000 and JoinEUI 0000000000000002

The hNS (in this case netid is 000001), has no prior information about the ED, then I:

1. Send a Join Request with JoinEUI 00 00 00 00 00 00 00 02

Then I have the first DNS request:

2. DNS query for 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.joineui.iot-roam.net
3. DNS answer with the Join Server IP
4. TLS handshake
5. TLS App data with the NetID

Then, since the hNS has no information about this ED, i can see that there is a second DNS Query:
6. DNS query for 000000.netid.iot-roam.net
7. DNS answer with the hNS IP
8. TLS Handshake
9. TLS App data

Here I'm expecting to have this:
10. HomeNSReq / HomeNSAns
11. PRStartReq / JoinReq
9. JoinAns / PRStartAns
10. JoinAccept

But instead I have this from the logs:

On the sNS :

Nov 02 14:17:12 outils.plido.net chirpstack-network-server[1082]: time="2021-11-02T14:17:12.799863844+01:00" level=info msg="uplink/join: resolved joineui to netid" ctx_id=dbd9ff44-5758-441e-9b10-646e0a75ccd5 dev_eui=da03899bc920e487 join_eui=0000000000000002 net_id=000000
Nov 02 14:17:12 outils.plido.net chirpstack-network-server[1082]: time="2021-11-02T14:17:12.812686895+01:00" level=info msg="lorawan/backend: finished backend api call" message_type=PRStartReq protocol_version=1.0 receiver_id=000000 result_code= sender_id=000001 transaction_id=136598966
Nov 02 14:17:12 outils.plido.net chirpstack-network-server[1082]: time="2021-11-02T14:17:12.812846793+01:00" level=error msg="uplink: processing uplink frame error" ctx_id=dbd9ff44-5758-441e-9b10-646e0a75ccd5 error="PRStartReq error: response error, code: , description: "

On the hNS:

nov. 02 13:18:02 vps768800 chirpstack-application-server[4653]: time="2021-11-02T13:18:02.751940573Z" level=info msg="backend/joinserver: sending response" dev_eui=da03899bc920e487 message_type=HomeNSAns receiver_id=000001 result_code=Success sender_id=0000000000000002 transaction_id=1140153905
nov. 02 13:18:02 vps768800 chirpstack-application-server[4653]: time="2021-11-02T13:18:02.764110007Z" level=info msg="backend/joinserver: request received" message_type=PRStartReq receiver_id=000000 sender_id=000001 transaction_id=3904647844
nov. 02 13:18:02 vps768800 chirpstack-application-server[4653]: time="2021-11-02T13:18:02.764142392Z" level=error msg="backend/joinserver: error handling request" error="invalid MessageType: PRStartReq"

As application server I have in both sides the 3.17.3 version and for the NS I have 3.15.3

Am I doing something wrong?

Sorry if this is not the right place to ask

BR
Ivan
IMT Atlantique

Running example function of the package

Hi,

I'm trying to run the func ExamplePHYPayload_lorawan10Decode() from phypayload_test.go.
The result i had is :
=== RUN ExamplePHYPayload_lorawan10Decode --- PASS: ExamplePHYPayload_lorawan10Decode (0.01s) PASS Process finished with exit code 0

But the output should be more detailed like :
// Output: // {"mhdr":{"mType":"ConfirmedDataUp","major":"LoRaWANR1"},"macPayload":{"fhdr":{"devAddr":"01020304","fCtrl":{"adr":false,"adrAckReq":false,"ack":false,"fPending":false,"classB":false},"fCnt":0,"fOpts":[{"cid":"DevStatusReq","payload":{"battery":115,"margin":7}}]},"fPort":10,"frmPayload":[{"bytes":"4mTU9w=="}]},"mic":"e117d2c0"} // [1 2 3 4]

There is a specific option i should add in the go test, to show all the information ?

M.A

Mac Commands Encrypted with AppSKey instead NwkSEncKey in Lorawan 1.1 Packet

Reading test File phypayload_test.go, from row 374, it looks that Packet is encrypted with AppSKey instead of NwkSEncKey as stated in the Lorawan Specification 1.1 (Page 25 / 26).

When Port is 0 and there are Mac Commands in payload, shouldn't be use NwkSEncKey instead of AppSKey? or am I missing something ?

Kalik1

Question: Why []Payload ?

Hey !
Awesome job with the package.
Still, one thing raises a question, in the implementation of the MACPayload the FRMPayload has a []Payload type. Looking at LoRaWAN I don't see a clue about several payloads that could be sent within one MACPayload. I may be wrong but then I would appreciate to be enlightened on that point :)
So far, as I understand, the frame payload FRMPayload either comes from the application embedded on the end-device if it's data related or from a layer above if it's mac-related. In both cases nevertheless it is unique, isn't it ?

Thanks

packets LOrawan

I want to analyze the lorawan packages ... any way to do it?

New datarates for Australia

Hi @brocaar,
And thanks for your awesome projects!

I'm working on a LoRa deployment for Australia and just seen that the current config for au915_928 is not compatible with "LoRaWAN™ 1.0.2 Regional Parameters" specs.

When we try to connect a 1.0.2 device, we get the error "get join-accept txinfo error: lorawan/band: the given data-rate does not exist" during the join request.
That's because 1.0.2 introduces new datarates for Australia.

I'm not sure the backwards compatibility are maintained between 1.0.0 and 1.0.2 so I don't know how to create a pull request for your project.
To start, i'll work on my own fork, but it could be good to integrate new datarates here.

Do you have any idea?

Thanks!

Refactor TX Power table + default tx power (for gateway?)

The LoRaWAN Regional Parameters 1.0.2 are changing the TX power from absolute ERP to values relative to MaxEIRP. The purpose is that TX Power 0 means max tx-power for all devices, but that each device could implement its own MaxEIRP value.

The TXPower table should therefore contain the delta relative to the MaxEIRP value instead of the absolute TX Power value.

Important to note is that in the 1.0.2 revision the deltas have been updated. For example in the EU band the delta between TX Power 0 to TX Power 1 was -6dB, this has been changed to -2dB. As from the LoRaWAN protocol it is unknown which LoRaWAN Regional Parameters revision the node is implemented, this could potentially break ADR.

Other idea:

Refactor the DefaultTXPower into a method called GetDownlinkTXPower. By making this a method, we could also take the number of active channels into account.

CID.MarshalText() allways returns commands with Req suffixes (the first MAC-command name for CID)

Hello Brocaar.
When I marshal PHYPayload struct with MacCommands in it, I always have the same name for MACcommand in both directions.

( (on pictures the same behavior we can see via redis pubsub in chirpstack)

I see that there is a String() method generated for CID so it has no idea about the direction and there is no simple solution.
Any plans or ideas on how to improve this?

Does this package support cooking-hacks RN2483?

Hi, Brocaar,

I am wondering whether this package support RN2483 chip because the encryption algorithm at gateway seems not same as the one at node. Please follow my thought below.

For example, assuming that we have a string data "longtest" needs to be sent to a node. And we have network session key and app session key go like this:

char NWK_SESSION_KEY[] = "01020304050607080910111213141516";
char APP_SESSION_KEY[] = "000102030405060708090A0B0C0D0E0F";

The downlink packet sent by your lorawan system (lora-gateway-bridge/ lorawan-server/ lorawan-app-server) goes like this:

Assuming base64-encoded packet
YOLyEQYgAgAK68z9jEUZBpOUYg==

Message Type = Data
  PHYPayload = 60E2F211062002000AEBCCFD8C451906939462

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = 60
  MACPayload = E2F211062002000AEBCCFD8C4519
         MIC = 06939462

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = E2F21106200200
       FPort = 0A
  FRMPayload = EBCCFD8C4519

      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
     DevAddr = 0611F2E2 (Big Endian)
       FCtrl = 20
        FCnt = 0002 (Big Endian)
       FOpts = 

Message Type = Unconfirmed Data Down
   Direction = down
        FCnt = 2
   FCtrl.ACK = true
   FCtrl.ADR = false

When my RN2483 node receive this downlink, the decrypted buffer is not the ASCII for string "longtest".

9689e0b5eb2d

Later, I found another tool for encrypting/decrypting LoRa packets here: https://github.com/anthonykirby/lora-packet/

And I write a script (test.js) to illustrate the problem:

var lora_packet = require('lora-packet');

//-----------------
// packet decoding
// decode a packet
// Base64 Downlink Packet: YOLyEQYgbAEKW0lk2KCLHg==
//var packet = lora_packet.fromWire(new Buffer('60e2f2110620020001112a735eda5127e74afea1f7', 'hex'));  // right encrypted packet
var packet = lora_packet.fromWire(new Buffer('60E2F211062002000AEBCCFD8C451906939462', 'hex'));  // the gateway tx encrypted packet

// debug: prints out contents
// - contents depend on packet type
// - contents are named based on LoRa spec
console.log("packet.toString()=\n" + packet);

// e.g. retrieve payload elements
console.log("packet MIC=" + packet.getBuffers().MIC.toString('hex'));
console.log("FRMPayload=" + packet.getBuffers().FRMPayload.toString('hex'));

// check MIC
var NwkSKey = new Buffer('01020304050607080910111213141516', 'hex');
console.log("MIC check=" + (lora_packet.verifyMIC(packet, NwkSKey) ? "OK" : "fail"));

// calculate MIC based on contents
console.log("calculated MIC=" + lora_packet.calculateMIC(packet, NwkSKey).toString('hex'));

// decrypt payload
var AppSKey = new Buffer('000102030405060708090A0B0C0D0E0F', 'hex');
console.log("Decrypted='" + lora_packet.decrypt(packet, AppSKey, NwkSKey).toString('hex') + "'");
console.log("Decrypted='" + lora_packet.decrypt(packet, AppSKey, NwkSKey).toString('') + "'");



var constructedPacket = lora_packet.fromFields({
        MType: 'Unconfirmed Data Down',   // (default)
        DevAddr: new Buffer('0611F2E2', 'hex'), // big-endian
        FCtrl: {
            ADR: false,       // default = false
            ACK: true,        // default = false
            ADRACKReq: false, // default = false
            FPending: false   // default = false
        },
        FCnt: new Buffer('0002', 'hex'), // can supply a buffer or a number
        payload: 'longtest'
    }
    , new Buffer("000102030405060708090A0B0C0D0E0F", 'hex') // AppSKey
    , new Buffer("01020304050607080910111213141516", 'hex') // NwkSKey
);
console.log("constructedPacket.toString()=\n" + constructedPacket);
var wireFormatPacket = constructedPacket.getPHYPayload();
console.log("wireFormatPacket.toString()=\n" + wireFormatPacket.toString('hex'));

The output shows that the encryption algorithm of this package is not same as that running on cooking-hacks RN2483. (The encryption algorithm running in the RN2483 nodes is same as the one in JavaScript repo I mentioned before.) Would you please give me some help on this issue? Thank you.

Best Regards,
Xuanliang

32-bits frame counter

LoRaWAN allows 32-bits frame counters. When computing a MIC you can't just cast the 16-bits value from the header to 32 bits assuming the 16 MSB are 0. You would need to add a parameter to the functions to pass the 16 MSB's.

DecryptJoinAcceptPayload function appears to be encrypting not decrypting

Code here appears to invoke an encypt function when it is supposed to be decrypting. Is this a bug? Ditto for the encrypt function (which is decrypting).

https://github.com/brocaar/lorawan/blob/master/phypayload.go#L363

Issue with LoRaWAN 1.1.0 joining with Network server

Hi,

We are using SX1262 LoRa module with LoRaWAN 1.0.3 to connect with Network Server and this is working fine. When we try to connect using LoRaWAN 1.1.0, we are getting join request and join accept also at ChipStack but at end device side its showing LORAMAC_HANDLER_ERROR. Are we missing something. Please let me know. Thanks.

McKeyEncrypted byte order in McGroupSetupReq cmd

In LoRaWan spec 1.1 and LoRaWAN Remote Multicast spec 1.0.0, the "Conventions" sections all mentions that fields with multiple bytes are transferred in little endian:

The octet order over the air for all multi-octet fields is little endian

But in the implementation, the "McKeyEncrypted" field which is 16 bytes long is just copied in its original order. Why is it not encoded in little endian form?

Trouble with FOpts encryption

Hi Brocaar,

I've been having a bit of trouble getting FOpts encryption to work in my 1.1 stack, and came across this in PHYPayload.EncryptFOpts:

I believe the highlighted lines should be removed, to match the 1.1 spec below:

AS923 default frequency as refer to RP2-1.0.1 LoRaWAN®

Hi,
refer to RP2-1.0.1 LoRaWAN® Regional Parameters wich saying that AS923-1 represents the original AS923 plan; AS923-2 shifts the plan down 1.8MHz and AS923-3 shifts the plan down 6.6MHz, is there any update or how can i change the AS923 original default frequency to meet AS923-2 frequency plan??

How to use loranWan documents？

I didn't find an example of how to use it in the package

Which JS function derive AppKey ?

Hi,

I am in LORAWAN 1.0.2, and I am looking for the function that generates the NwkSKey and the AppSkey fromroot key (appKey).
I know it's two keys are generated in the generation of the join accept.
Are the two keys generated here?
*"lorawan / backend / join_request.go/" ====> func createJoinAnsPayload(ctx context) error