Hello, I have installed version 4 of Chirpstack, before I had used version 3 and I managed to do everything I needed, but now I have not been able to connect the end device to the application. First, to ensure that my gateway (Dragino LPS8) was in the “On Line” state, I uncommented the variable "#topic_prefix=“au915_0” from the “region_au915_0.toml” file, that is in this same forum… Now, the end devices, when sending the join request, the error “Error=rx_info_set is empty” occurs. I have tried everything and I have no more suggestions.
Now the error is…
It is a shame that this project is abandoned and the new version has errors that are not explained… 
The error says it all.
Doublecheck the Dev EUI and AppKey in both node and ChirpStack.
Note there is MSB and LSB format.
Hello “Datnuts”, first of all, thank you for your response and interest in solving the problem I have, which is probably due to my lack of knowledge and experience in this platform and protocol (LoraWAN), So I ask you for a little patience 
… As I said before, the end devices that I am trying to join to Chirpstack V4, I used them in Chirpstack V3, in version 3 I only had to create the profile with their respective configurations and create the end device in the Applications section with its respective DevUI and the Application key was negotiated by the end device and the platform, everything worked fine, but now we wanted to install the new version of Chirpstack and we have the error that I described before (“MIC of join-request is invalid, make sure keys are correct”), As you say “the error says it all”, but the problem is that on the final device I bought (with support for the LoraWAN V 1.0.2 protocol) I cannot change or read the application key on the end device so that they are the same than in the application.
May be you need to upload full images of packes here, so we can have more information?
Which Chirpstack version are you using? E.g: v4.6 or 4.7?
From the gatewayId in your photo, the id doesn’t look like from Dragino LPS8 or you manually change it.
Have you compared this MSB/LSB mode of your v3 and v4?
The Chirpstack Version is 4.7.0
#From Chirpstack Version 3.17.7
OTAA-Keys
Activation
DEVICE DATA
LoraWAN Frames
#FROM Chirpstack Version 4.7.0
OTAA-Keys
Events
LoraWAN Frames
Could you check CS v3 if it uses au915_0?
I saw it uses 925.1 and 925.7Mhz which should not be in au915_0.
While your CSv4 seems using au915_0.
This is the frequency plan for au915_0
[[regions.gateway.channels]]
frequency=915800000
bandwidth=125000
modulation="LORA"
spreading_factors=[7, 8, 9, 10, 11, 12]
[[regions.gateway.channels]]
frequency=916000000
bandwidth=125000
modulation="LORA"
spreading_factors=[7, 8, 9, 10, 11, 12]
[[regions.gateway.channels]]
frequency=916200000
bandwidth=125000
modulation="LORA"
spreading_factors=[7, 8, 9, 10, 11, 12]
[[regions.gateway.channels]]
frequency=916400000
bandwidth=125000
modulation="LORA"
spreading_factors=[7, 8, 9, 10, 11, 12]
[[regions.gateway.channels]]
frequency=916600000
bandwidth=125000
modulation="LORA"
spreading_factors=[7, 8, 9, 10, 11, 12]
[[regions.gateway.channels]]
frequency=915900000
bandwidth=500000
modulation="LORA"
spreading_factors=[8]
In CS V3,
file “/etc/chirpstack-network-server/chirpstack-network-server.toml”
[network_server]
net_id=“000000”
[network_server.band]
name=“AU915”
[network_server.network_settings]
enabled_uplink_channels=[0,1,2,3,4,5,6,7]
In CS V4,
file “chirpstack.toml”
[network]
net_id=“000000”
secondary_net_ids=[ ]
dev_addr_prefixes=[ ]
enabled_regions=[
“au915_1”,
]
file “region_au915_1.toml”
[[regions]]
id=“au915_1”
description=“AU915 (channels 8-15 + 65)”
common_name=“AU915”
[regions.gateway]
force_gws_private=false
[regions.gateway.backend]
enabled=“”
[regions.gateway.backend.mqtt]
#topic_prefix=“au915_1”
Note that the “topic_prefix” variable is commented because before the error I have now, was the gateway was not registered and I read this solution in a forum. If I uncomment that variable, the gateway remains in the “Offline” state, the “gateway-bridge” receives data from the gateway but no error indicating what is happening…
In the case of CS V4 I have tried with all the channels in the region (from au915_0 to au915_7) and in those that are different from au915_1 the error in the Chirpstak Log is:
“debian12-shirpstack chirpstack[1616]: 2024-04-08T03:56:16.527780Z ERROR up{deduplication_id=89f07f0e-0ce3-4cc6-85c5-8f506f9ca13a}: chirpstack::uplink::join: Handle join-request error error=rx_info_set is empty”
-
Commenting topic_prefix doesn’t seem correct to me.
The gateway should be “online” even if there is no node at all. -
I guess AU915 in old Chirpstack v3 is this one.
In Dragino LPS8, the plan will be this one. Dragino should start the band count as 0 instead.
And in ChirpStack v4, it will be equivalent to this region_au915_1.toml
- One issue I may think of is your node is old and using outdated frequency plans.
The frequency plans in CS v4 are updated.
Good luck.
1.- I uncommented the parameter "topic_prefix=“au915_1"” and the gateway was in Off Line state. The Gateway Bridge service receives Union requests, but the Chirpstack service does not show any errors to tell me what is happening. Additionally, the gateway shows the status connected to LoRaWAN
CS V4 Gateways
CS Gateway Bridge LOG
Dragino LPS8 Systema Overview
2.- Dragino LPS8 LoRa Config
3.- The firmware that the gateway has is LBT-5.4.1658454438, before using the latest available lgw–build-v5.4.1704801796-20240109-2005 and gw-openvpn–build-v5.4.1699323660-20231107-1022 and in all problems are the same.
Have you set back the prefix for chipstack-gateway-bridge? This is to match with region-au915_1.toml.
From your log, I can see there are some packets from udp packets to chirpstack-gateway-bridge.
in the file “region_au915_1.toml”, uncomment the variable “topic_prefix”
and in the file “chirpstack-gateway-bridge.toml” add the prefix “au91_1” to the variables “event_topic_template” and “command_topic_template”
I restarted the “chirpstack” and “chirpstack-gateway-bridge” services and now the Gateway is online, but now when executing the join request from the node (end device), the CS services (Chirpstak and Gateway Bridge) do not show up the log of the union request and eny other ERROR.
Gateway Log
Chirpstack Log
I bought a “Dragino PS-LB-NA LoRaWAN Analog Sensor” and the product comes with the following information… devEUI (obviously), EUI app, and Key app, add the device (Node) with its respective “Device Profile”, “Applications” etc… first I tried, adding the “Application Key” value different from the one that came with the device and I got the same error as before (“MIC of join-request is invalid, make sure keys are correct”) and then I entered the value that came with the device… and everything started working… The Join Reques, DataUP and DataDown…
So the question is… in CS V4 is it mandatory to add Nodes to which the Application Key value can be obtained?
I ask this because the Nodes that I was testing and which I still cannot join to the server (In CS V4), only have the devEUI value visible and in CS V3 it was not necessary to add that value to the network server, that value, I suppose, is created internally.
Yes, DevEUI and appkey are required.
They must be matched as I said in early reply.
Chirpstack v3 and v4 both require deveui and appkey.
Dear @datnus, Excuse me but that is not correct… I have CS V3 installed, and the same Node in that version correctly passes the union process and can send data without problem. please see the devEUI in the images
Device Data in CS V3
Events in CS V3
As I said before, the Node that has devEUI “8cf9572000074af4” does not have any way to obtain or see the value of the Application Key and in CS V3 it works correctly and in CS V4 it does not… Something changed significantly… Also, the same Node I added it to “The Things Network” before and it also worked correctly
Everything is the same in CSv3, CSv4 and even TTN.
Correct DevEUI and AppKey are a MUST.
So for a long way, you didnot put in the correct appkey.
Nevermind, enjoy Chirpstack v4.