One gateway near my location is till forwarding data to my account even if my device is shut down.
I disconnected my device (feather001) yesterday evening. But still receive data until now (12 hours later) every 2 Minute (approx)
The data seem to come from gateway iot-gw-sc-c01.
What can I do?
Make sure the device if fully powered down - remove batteries, if using a super cap make sure discharged (dont just short - use a 50-150 ohm resistor etc…)
Look at the metadata of the received message in your application/device console and check if its new each time or if you think it is a repeated fwd of a truely old message…
1 Like
Feather’s unlikely to have SuperCaps - more likely DIY.
As @Mat_Lynx hasn’t told us what he’s looking at when he still sees data, we would just be guessing, so here goes:
“Mat, you are looking at your gateway console and there is another device in the area that is sending”
PS, data doesn’t come from a gateway, they just relay what they hear.
Some actual info, JSON, meta-data etc would help solve the guessing bit!
Indeed - but I and I know many others - have added SC’s to various systems in the past to smooth out hit to lower capacity/higher internal resistance batteries to extend life and mitigate for slower chemical recovery after TX spike - so just asking 
As you say would be a DIY mod… agree with other asks which is why I pointed OP to look at the TX metadata so we know what he is actually saying vs guessing. Guess its a case of New Year New Crystal Balls! 
Thanks for your replies. (and sorry for not giving you all the needed informations, I’m a fairly unexperienced forum user)
I am using a Feather 32u4 and I indeed did disconnect it from USB and also from the battery (so I’m sure it is not sending data anymore)
I do not have any own gateway (I relay on the many other gateways in my region, what was working fine until yesterday…)
So after disconnecting my feather I was expecting no more traffic in the console of my application (Live data) but still i get data every 2 minutes or so. All coming from the same gateway. (Valid data came from other gateways too, but this data only come from gateway iot-gw-sc-c01) And the data come from the future! (2023-11-25T16:19:59.314845678Z see below)
Metadata:
“rx_metadata”: [
{
“gateway_ids”: {
“gateway_id”: “iot-gw-sc-c01”,
“eui”: “2CF7F1102440004F”
},
“time”: “2023-11-25T16:19:59.314845678Z”,
“timestamp”: 3189283163,
“rssi”: -114,
“channel_rssi”: -114,
“snr”: 1.8,
“location”: {
“latitude”: 47.1315,
“longitude”: 7.2213,
“altitude”: 480,
“source”: “SOURCE_REGISTRY”
},
“uplink_token”: “ChsKGQoNaW90LWd3LXNjLWMwMRIILPfxECRAAE8Q27Li8AsaCwiWg5qeBhCy6L5+IPiW3IDppLMR”,
“channel_index”: 2,
“received_at”: “2023-01-17T11:08:06.215816270Z”
}
],
Each packet gets (automatically) answered by: downlink transmission failed with result TOO_EARLY
Does this help for further trouble-shooting/suggestions?
One more information: This (in my eyes) strange behaviour showed up for the first time at 15. January 2023 at 23:50:03 CET (every approx. 2 Minutes since then, still ongoing)
Any idea?
Does that look like your payload? Or any of the information?
Can you start up your old device to see what happens?
The gateway id in-conjunction with the downlink too early looks suspicious - it may be a non-compliant gateway that can only work with a single channel. The future date may come from a bug in the gateway firmware.
But that’s mostly speculation - the easiest test is to turn on your old device to look at the console log.
I’m not sure there is any significance in the date.
Are the frame counters increasing?
Yes:
“f_cnt”: 1178
“f_cnt”: 1180
“f_cnt”: 1183
“f_cnt”: 1187
“f_cnt”: 1188
they do increase
That means there is an active node with the same credentials you use. A gateway can not invent traffic and create packets with the correct message integrity code because the gateway does not know the encryption keys.
Did you reuse an existing example with the same keys? Or published the code with keys somewhere?
The payload is 8 Bytes (what is correct) but the values are not precise. They are in an acceptable range but not accurate. (It’s a self made Weather-Station.)
You give us facts, but don’t seem to draw any conclusions of your own …
What thing could exist in the universe that could do the very same thing as your turned off device?
And is the Feather you have the one you think it is?
And did you try powering up this Feather that you do have?
Where did the code for the node come from, complety original by yourself ?
Thanks for the flowers. (@descartes: I’m disappointed that you have the impression I’m not working on the problem and am waiting for someone else to resolve my problem…)
I have no idea why someone could use my device addresses, my NWKSKEYs and my APPSKEYs to send fake data to my account… I use my own keys (that have been generated by TTN-webinterace) I am not publishing my code to any repo or so (GitHub or alike) etc.
But I’m also not a professional Developer. This is a hobby to me.
I changed the NWKSKEY and the APPSKEY on the device and the console today.
Thisway I was able to “resolve” the problem so far.
But the same thing started going on on my second feather since yesterday evening (approx. 12h before I started replacing anything in my code…)
And what is important in my eyes: the strange data only come from one gateway: “gateway_id”: “iot-gw-sc-c01” (all good an legitime data that my feathers send, are relayed from other gateways)
Any thoughts? Can a Gateway Owner be contacted?
The LoRa Part of the code is from an example (but I did use my own device ID, NWKSKEY and APPSKEY) the rest of the code is my own.
Is it possible that a gateway send old data (again)?
No I did not use existing keys (device ID, NWKSKEY and APPSKEY have been generated by TTN-Webinterface)
No, unless you modified the settings in the TTN console that facilitate that.
However, you are using ABP which is less secure because it encourages switching that security setting of for convenience during development, please switch to OTAA.
The offending gateway seems to be located near Biel. Is that anywhere near your location?
1 Like
Does this mean that your device web console is only showing you new traffic that you are expecting?
Have you recently sent a downlink to the device - if we suppose that the rogue gateway is a SCPF and it’s having issues (re, Downlink failed …) then it may just be repeating stuff it’s heard over and over again. Or someone has been playing with the codebase and it’s got some replay functionality. Or a massive delay between hearing an uplink & passing it on. None of which would require anyone to know your keys.
When did your Feather send the uplinks in the f_cnt range 1178 to 1188? Or data of that pattern - ie when the temp, humidity etc were like that recently.
In theory a gateway owner’s id can be looked up but then you have to send them a message via the forum with varying results. You could drive to the indicated location, again with varying results.
As for @kersing’s very correct suggestion about the improvements that come with OTAA, that can be looked at but the Feather32U is very very tight on space for LMIC on a good day, I suspect a recent version with OTAA may be beyond it, depends on what sensors are being used.
1 Like
Why would we suppose that?
Assume a gateway that sends uplinks delayed, now combine with the NS attempting to send a MAC command that is not acknowledged because the downlink can’t be send as the downlink window expired hours ago and we have exactly the behavior listed.
The only requirement for this to happen is using ABP with the "Resets frame counters option set and a gateway that buffers data.
The option to be set is common practice for ABP devices (although it should not be used to prevent these kind of issues to occur).
Buffering gateways are commercially available. Some vendors either can’t read the LoRaWAN specs or decide they know better.[RAK among them]) and implement non compliant features regardless of the consequences it might have for a LoRaWAN network.
1 Like
That’s right I’m using ABP (because the example I started with, is using ABP) And yes the Option “resets frame counters” is set, because the feather starts counting at zero each time it reboots (power outage for example) → This means I will try to use OTAA.
Yes I’m located near Biel (Switzerland) It looks like 2 GW at the same location: iot-gw-sc-c01 (which is sending me “wrong” data. And iot-gw-sc-c02 which looks like working fine. But no infos about the Owner.
