Hello,
I have a RAK7244 gateway and am getting lora data from an LHT65 temp/hum sensor using the RAK builtin chirpstack server. I’m very new at this and it took a while to actually get things working.
I seem to have a “phantom device” sending join requests every 15 seconds, and I have no knowledge of what it is. This is a private setup so I’m certain there are no neighbors with devices trying to join. I’m certain it’s something I have misconfigured but don’t know how to find it. I have shutdown a couple of linux machines on my LAN to eliminate something from them.
Can anyone suggest how I might be able to find the phantom device that is causing the problem? I am attaching one of the join requests.
do you have a device with this devEUI? if not the device could be potentially calling from anywhere if your gateway location is good. you will see other peoples traffic noise on the same frequency if they are nearby as well as the misconfigured nodes etc. if it is not yours it might also be a tracker someone has put on something which is outside of its own network coverage perhaps.
The information provided is very limited to support you, where as if you have access to Phantom device and if you could play with it, please change the Join request interval or Re-Join interval from 15 seconds to your desired time interval.
If you need further help, please post more details about your LoRaWAN setup.
Thanks for the replies. I have no idea where the phantom device is coming from. It has the devEUI as listed above but I don’t have any other devices powered on. The RAK7244 is on my local LAN with antenna located indoors. I don’t know of anyone in the area who is using LoRa devices.
Being very new to this, I’m not sure how to set the join/re-join interval to a longer period. Is it located in the config file: chirpstack-network-server.toml ?
I disabled the LHT65 sensor to be certain it wasn’t doing anything it shouldn’t be doing but the phantom device continued to send the join requests.
Here is a section from syslog which may be meaningful to someone:
Aug 17 09:15:42 rak-gateway chirpstack-gateway-bridge[607]: time=“2021-08-17T09:15:42.106533577-04:00” level=info msg=“integration/mqtt: publishing event” event=up qos=0 topic=gateway/dca632fffe36b226/event/up uplink_id=8c9e22d7-97e0-4a5a-ae97-d2006d699ce2
Aug 17 09:15:42 rak-gateway chirpstack-network-server[608]: time=“2021-08-17T09:15:42.107879866-04:00” level=info msg=“gateway/mqtt: uplink frame received” gateway_id=dca632fffe36b226 uplink_id=8c9e22d7-97e0-4a5a-ae97-d2006d699ce2
Aug 17 09:15:42 rak-gateway chirpstack-network-server[608]: time=“2021-08-17T09:15:42.313158156-04:00” level=info msg=“uplink: frame(s) collected” ctx_id=372e868e-4bc3-4819-957d-f5923227fc71 mtype=JoinRequest uplink_ids=“[8c9e22d7-97e0-4a5a-ae97-d2006d699ce2]”
Aug 17 09:15:42 rak-gateway chirpstack-network-server[608]: time=“2021-08-17T09:15:42.315862641-04:00” level=error msg=“uplink: processing uplink frame error” ctx_id=372e868e-4bc3-4819-957d-f5923227fc71 error=“get device error: object does not exist”
Please let me know what additional information I can post to help solve the mystery.
Thanks again for the helpful comments
Bob
LoRa range is quote good, I have devices trying to join on my network that were multiple city-blocks away, even with the small indoor antenna setup (diff gateway but still). How do you know nothing else is in your area?
Does your system use the chirpstack-gw-bridge? If so, you can set up the JoinEUI/NetID filter to only allow the JoinEUI for your devices. That way it will not even send these other device join packets up to your LNS. Same with NetID filter for already joined devices on a different network
Setting a filter sounds like a good way to get rid of this thing. On the RAK7244 I seem to have:
chirpstack-application-server
chirpstack-gateway-bridge
chirpstack-network-server
Could you tell me where/how to set this filter?
Thanks.
In the chirpstack-gateway-bridge.toml file on the gateway, is where the filters are set. See Configuration - ChirpStack open-source LoRaWAN<sup>®</sup> Network Server for the reference. You would have had to set that config file up to point to your network server, so I am assuming you know how to get at it.
Then, you will need to assign a Network ID (done in the network server config file on your server) just pick something unique/random other than the default “000000”. Note the NetID is assigned to the device during the OTAA join procedure, so no need to configure that on the device. However, the JoinEUI depends on your end-device. If you can program it, then set the JoinEUI for all your devices.
You then use these JoinEUI and NetID in the [filters] section of chirpstack-gateway-bridge.toml. JoinEUI will filter out any join requests that don’t belong to yours, and NetID will filter out any uplink messages from devices that don’t belong to your NetID
[filters]
# NetIDs filters.
#
# The configured NetIDs will be used to filter uplink data frames.
# When left blank, no filtering will be performed on NetIDs.
#
# Example:
# net_ids=[
# "000000",
# "000001",
# ]
net_ids=[
]
# JoinEUI filters.
#
# The configured JoinEUI ranges will be used to filter join-requests.
# When left blank, no filtering will be performed on JoinEUIs.
#
# Example:
# join_euis=[
# ["0000000000000000", "00000000000000ff"],
# ["000000000000ff00", "000000000000ffff"],
# ]
join_euis=[
]
Ok, stupidity has taken control here. I found the culprit device sending join requests, removed it, and all seems well. In frustration the other day, I had thrown aside an Adafruit M0 which I was trying to setup on the LoRa network. It was still powered up…
My appologies and appreciation to everyone who tried to help. Other than being 81 this week, I have no excuses for your time I have wasted. The only value here is that I have learned more about Chirpstack although I still have a long way to go.
Cheers,
Bob
Bahh… never any stupid questions… if anything its a post people can search and see the answers later on.
Despite finding the rogue device its still a good idea to set those filters. You should be able to sniff the join request in the app server webpage “live frames”, and expand the packet to see the joineui your devices use. The syntax for setting that filter should be documented in the comments of the config file mentioned above.
If not, its not a big deal, just an extra dropped packet every so often. Hey Happy Bday!