GatewayID as only numbers

[ToniStonde]

I noticed a little problem if using only numbers gateway_ID. Packet_forwarder seems to parse it as an int. Example from /etc/global_conf.json after parsing configs:

"gateway_ID":"333833304b005200"

"gateway_ID":3.3383330410052e+15

First is parsed correctly because there is atleast one letter, second has only numbers.

This causes that some LoRaWAN implementations interpret this as '0000000000000000'

[reissjason]

The "gateway_ID" field is a hexadecimal string of 8 bytes with no delimiters allowed.
The value is only parsed if it is a string, otherwise NULL is returned and the default value '0000000000000000' is used.

str = json_object_get_string(conf_obj, "gateway_ID");

[ToniStonde]

yeah, but my point is this. I'll explain (this happens when the global_conf.json is created from lora-global):

option gateway_ID '333833304b005200' => "gateway_ID":"333833304b005200"

option gateway_ID '3338333041005200' => "gateway_ID":3.3383330410052e+15

So if I insert gateway_ID like the upper one -> parsed OK

But if the gateway_ID is like the bottom one (for example) so it has only numbers -> it parses it like that.

Should it also accept only hex strings which do not have A, B, C, D, E, or F in the ID ?

[reissjason]

Only hex strings are accepted. If a tool is creating the global_conf.json or local_conf.json it must output the gateway_ID as a string. Numeric values are not going to be parsed.

[rbaldwin13]

In an effort to improve our customer support experience and in recognition that our support backlog on GitHub has historically exceeded the capacity of our engineering team, we have taken the difficult decision to focus on the most contemporary issues reported and to close all others without confirmation of resolution.

Our belief is that issues which have remained unresolved and unaltered for extended periods of time are less likely to continue to pose a significant problem to the user than when they were originally filed. More contemporary issues however may still be relevant and hence are more appropriate to prioritize.

For those users who remain interested in resolution of a reported issue that was closed, we are encouraging usage of our developer portal forums [https://forum.lora-developers.semtech.com/] and commercial support portal [https://semtech.force.com/ldp/ldp_support?__hstc=212684107.579a13689e43099691e328c9248e6ecc.1623103335314.1624470656297.1624635514661.6&__hssc=212684107.6.1624635514661&__hsfp=4176385453] as the preferred avenues to receive support. We will continue to monitor the GitHub issue trackers as well, but want to encourage all users to take advantage of the increased community presence on the developer portal. For commercial customers, we highly recommend using the commercial support portal which is uniquely tailored to service such support requests.