Not sure how this relates to you registering it on TTS CE.
If you ever want it on TTS CE, you’ll have to give the EUI to someone at some point so that a staff member can take out time to look it up on the database to see who’s got that registration. By sharing it here now, someone can sanity check the setup before it gets escalated.
As I said, the EUI becomes available to someone outside your organisation the first time their device uplinks via your gateway, so it’s not something that can be kept secret.
If there is a specific question you are struggling to understand, please highlight it so I can try to clarify. However, under the heading of a volunteer trying to help you, I’m not sure there is anything about LoRaWAN that you need to know to tell us the EUI.
That gateway was registered by @wdallas. They apparently never logged in to the forum, but you can try contacting them on the community platform: https://www.thethingsnetwork.org/u/wdallas.
To make it easier to find collaborators of gateways, I’ve submitted a change for The Things Stack v3.14 (release planned for this week, deployment planned for next week) that will allow you to find the collaborator(s) of any registered gateway using the CLI:
$ ttn-lw-cli gateways collaborators list [gateway-id]
(until the deployment this command only works for your own gateways)
There is the link that Hyke gave you that will allow you to send a message via TTN.
If there’s no response within a couple of days, you could come back here and ask someone at TTI to email him/her directly.
As I’d wonder how someone would end up with an official RAK EUI that they entered in to the console but not own the kit, I’d expect the gateway to be inactive and therefore possibly eligible for deletion, subject to some controls / proof. This isn’t the first time in the last few weeks we’ve had this on the forum.
Alternatively, you could ask on the RAK forum if there is a way to change the EUI on the gateway.
I think that being able to configure an EUI in gateways is a better solution for gateways which do not support a claiming mechanism. If we release the EUI claim after inactivity of the gateway, we will start seeing false positives on registration (the actual owner had an internet outage, lost their EUI and has to climb in their tower to configure a new EUI) and false negatives (someone else squatted the EUI and keeps the gateway active to keep the claim).
Today we have four classes of gateways:
Gateways with a fixed EUI that have a proof of ownership mechanism and claiming (like TTIG)
Gateways have an EUI but that allow changing the EUI. No proof of ownership
Gateways with a fixed EUI. No proof of ownership
Gateways without an EUI
The problem is really caused by (3) and (4). We should get rid of these. To get rid of (3), we should require gateway vendors to either support claiming (and become (1)) or allow changing the EUI (and become (2)). To support (2) and (4), we can start issuing gateway EUIs from a MAC block owned by The Things Network, just like we do with DevEUIs.
Trying not to add complexity to the discussion (Huh!!!), it looks to me there is an assumption that the EUI is derived from the MAC address of the Wifi or Ethernet port.
Don’t forget the SX1302/3 gateway chip have their own unique EUI which can also be used.
You may want to consider if a long term solution is to have the packet forwarder use this by default. While EUI could be set by the config file, only if the correct parameters are added, the standard config file would exclude this and by default the SX1302/3 chips EUI is used.
Most gateways already have an EUI indeed, that’s not the problem. The problem is that there is no way to prove that one owns the gateway with that EUI when registering it. The gateway could have had a previous life with another user, or the same EUI could have been registered accidentally or on purpose already. So, if one is able to change the EUI the gateway uses, then this problem gets solved. Or, better yet, be able to prove ownership, like we have with TTIG.
It is better to ask RAK how you can set the EUI that is being send to TTN. Once you know that you can simply use a different EUI to register your gateway.
EUIs are supposed to be unique but there have been multiple issues with that not being the case of the past 5 years so being able to determine the EUI to use is the best way forward for these units.