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… 
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… 
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?
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)
- You can’t pick one claimed on TTN as the console wouldn’t allow you to register it.
- 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.
I’ll try to summarise the discussion here a little bit for future users.
-
Gateways silently dropping packets.
Gateways and TTN (the Network Server) are not designed to drop traffic silently. Any error would at least be logged either in the gateway or on the network. If this is actually happening, then that needs some investigation.The issue could be related to the gateway IP address changes, network interface change, ACK messages not received by the gateway/network etc etc. An issue such as this needs debugging and if there are packet forwarder logs, we can help you with that.
Btw, the author of the original thread (Gateway EUIs blocked and their traffic dropped silently? ) never provided any logs to debug what the issue is.
I would’ve preferred that thread be called “My Gateway does not forward traffic” with relevant logs to debug the issue instead of directly assuming there is a bug and the network blocks EUIs and silently drops traffic. -
As explained by others, changing the EUI is not a valid solution. It might temporarily circumvent the problem since the network assumes that it’s a completely different gateway and starts a new connection, with new connection state.
- It does not solve the original problem. If the issue is with the gateway’s network interfaces, it will appear again on the new EUI.
- Unless the EUI chosen is truly randomly, you are most likely registering your gateway with someone else’s valid gateway EUI, which they will purchase in the future and would not be happy that it’s already registered.
- Many gateways cannot change their EUIs.
We can usually identify the issue by looking at the PULL_DATA: PULL_ACK and PUSH_DATA: PUSH_ACK messages in the packet forwarder logs.
So let’s not jump to conclusions before we have data. @rharte can you provide PF logs of the gateway? You can strip sensitive information and post that here.
2 Likes