My Gateway does not forward traffic

My Lorank8 (V2) gateway eui-1dee0b85451eb89e suddenly stopped carrying traffic this afternoon. If I check the gateway console, all seems healthy, like for instance it shows:

7 radio packets received
7 radio packets crc good
7 radio packets forwarded
7 datagrams send to server 1
7 datagrams acknowledged by server 1 (server 1 being router.eu.thethings.network)

Furthermore the gateway reports 100% on heartbeats received from router.eu.thethings.network.

but the traffic tab in the TTN console remains empty, the Received Messages counter stays the same and after about an hour into this situation, the gateway status went to ā€˜unknownā€™.

Rebooting and power cycling the gateway did not solve it. No configuration changes were made on my end, everything has been running stable for quite a long time already.

Anyone has any clues what can cause this?

Aha, my problem could be related to Gateway EUIs blocked and their traffic dropped silently?
because changing the gateway to a fresh EUI and re-registering solved the problem. Nasty bugā€¦ :wink:

Hmmā€¦ really? So now itā€™s someone elseā€™s problem? Well done, I guess.

@bertrik Iā€™m not sure what you mean by this remark. Apparently this is a known TTN-bug and currently the only known remedy/workaround is to change the gateway EUI and re-register it. What else would you expect from me?

Maybe the remark was a bit harsh.

The EUI you claimed has possibly been assigned to someone else. So perhaps next week, weā€™ll see someone else who suddenly canā€™t register their gateway anymore (because you grabbed its EUI).

You seem so sure this is a bug on someone elseā€™s end, perhaps you can help clarify the bug?

@bertrik That is not possible. If you try to register an EUI that is already in use, the console gives an error message.
For more information on the bug, please refer to the topic I linked in my original post. From the conversation it seems the developers are already aware of it.

Itā€™s not a bug, not even a little bit, there is no way for TTN to know the user isnā€™t typing in the correct EUI.

@descartes Iā€™'m not sure I understand what you mean and I am not even sure you understood what I meantā€¦ :grin:

This looks a bit like you saying there is a bug in TTN regarding it insisting on unique EUIā€™s for gateways.

If someone registers a gateway with the wrong EUI that is an unfortunate situation that we can all work to to unravel by some means, but itā€™s not a bug in the stack. Itā€™s how it has to work.

@descartes Iā€™m reacting to two remarks placed by @bertrik in the previous post. His first remark being that I may have wrongfully claimed someone elses gateway EUI, to which I replied that this is not possible, and his second remark asking for clarification on the bug which causes gateway traffic to be silently dropped, to which I am referring him to the original thread on that issue. These two replies are not related, but you seem to have cross-connected them, leading to the confusion.

You canā€™t claim an already claimed gateway. However if you register an EUI based on the original one you can use an EUI that will be assigned to a gateway in the future which result in the owner of that gateway not being able to claim it.
The only way to avoid that is to use a unique EUI that you own and canā€™t be assigned to another gateway by another party.

Then start another thread or post in that.

if @bertrik asks me two questions regarding the issue of my original post, why should I reply to them in a different thread?

Because it confuses people?

Who ā€˜ownsā€™ the EUI anyway? My gateway came with an EUI. Do I own it now? Or does the gateway vendor own it? And if there is a bug silently dropping my traffic, and the only workaround advised on this very same forum is to change the EUI and reregister, how or from where do I get a new EUI being sure that itā€™s not already claimed somewhere on the planet?
Furthermore, given the 8 bytes there are 1.8E19 combinations, so chances are less than 1 in a trillion that I would pick an already claimed one, right? :wink:

It confuses people if you respond to questions they pose to you? Bertrik asked me two questions, I gave two answers, you think he is confused now?

It appeared to me you were declaring a bug in TTN regarding the entry of gateway EUIā€™s which, unless substantiated, leaves a potential red-herring for people trying to figure out any gateway registration issues.

Iā€™m not worried if @bertrik is confused, itā€™s others finding this thread Iā€™m concerned for.

My concern is that anyone finding this thread ends up with the misunderstanding that having a gateway EUI rejected due to there being a duplicate is a bug.

Some gateways, particularly the Pi & some OpenWRT based gateways, allow you to override the EUI which does indeed open up a can of worms about generating a unique one, for which there is a reasonably definitive thread on EUI generation here. And some gateways donā€™t. This is a particular problem with the TTIG and only this week weā€™ve had someone find their vendor ā€œtestedā€ a gateway by registering it. This isnā€™t a new topic, one thread from Aug 2017 is still active as of April 2021, see here.

But fundamentally, declaring it a bug is not appropriate and the community members will work with anyone experiencing problems to resolve it (as we did this week).

@kersing (author of a gateway packet forwarder in use by many TTN gateways) and @Jeff-uk (gateway expert) - your views on this would be appreciated.

There are several ways. You could use the MAC address of a non LoRaWAN device (laptop) to base the new EUI on. Or buy an address block from IEEE (yes, overkill but stil an option)

  1. You canā€™t pick one claimed on TTN as the console wouldnā€™t allow you to register it.
  2. What the actual chances are you used an assigned one depends on how you created it. If you just changed one of the last two or three bytes of the existing one chances are high you picked one that was assigned to another LoRaWAN device are actually quite high as usually vendors assign these numbers sequentially to their products rolling of the manufacturing line.

The person that bought the address block from IEEE is the owner of the range. They might have transferred ownership to you on sale of the device that assigned it to but I wouldnā€™t count on it.

Genius!

See this thread for how to turn a MAC address in to an EUI. Obviously you need several pieces of hardware with network cards in if you need more than one, but most laptops have two (Ethernet & WiFi) and desktops have Ethernet.

Or buy a pile of Microchip 24AA025E64 - last batch end of April cost me 19.8p each for 100 - some end up on boards, most get the EUI read by the office gnome (pick me or the wife) to go on file for use as AppEUIā€™s (one used for an application) or for our hand built LMiC devices for DevEUIā€™s. I have a number of gateways that pick up the EUI from the global_config.json so I have carved off some EUIā€™s for them. Iā€™ve also got the code compiled from this thread for use on private instances of TTSv3 and Chirpstack for test purposes.

If you can change your gateway EUI and really really need an official EUI, ask and ye shall receive. If you canā€™t change it on the gateway, the community can look at the details & help track down the owner of the errant gateway.

1 Like

Something came to mind, is the external IP of the gateway (as seen by TTN) fixed or does it change? If it changes there might be an anti spoofing safeguard that youā€™ve encountered. (Sometimes internet providers rotate IPs quickly when there is maintenance so an IP might change a couple of times in a day, depending on the provider)

It would be interesting to see if the original EUI does work again after not having been used for some time.