Hi - I am trying to verify a private network in the absence of an actual gateway.
I am not convinced that ttnctl is verifying enough, I get the impression that it is just accessing the mqtt message broker not the ttn broker component and certainly not the router.
But trying to build the Golang above but I think it is out of date and is based on old ttn go lang libaries (?)
Also I am new to Golang so any hints help would be appreciated
Here is the output of the go build
[pfry@pfry all-in-one]$ go build routerTest.go
command-line-arguments
./routerTest.go:24:20: cannot use *gateway.RxMetadata literal (type *gateway.RxMetadata) as type gateway.RxMetadata in field value
./routerTest.go:25:11: unknown field ‘Rssi’ in struct literal of type gateway.RxMetadata
./routerTest.go:26:10: unknown field ‘Snr’ in struct literal of type gateway.RxMetadata
./routerTest.go:29:21: cannot use *protocol.RxMetadata literal (type *protocol.RxMetadata) as type protocol.RxMetadata in field value
./routerTest.go:30:18: undefined: protocol.RxMetadata_Lorawan
./routerTest.go:51:27: undefined: discovery.NewClient
./routerTest.go:51:90: unknown field ‘Id’ in struct literal of type discovery.Announcement
./routerTest.go:63:19: undefined: router.NewRouterClientForGateway
./routerTest.go:63:75: undefined: c
./routerTest.go:64:19: undefined: router.NewMonitoredUplinkStream
./routerTest.go:64:19: too many errors
[pfry@pfry all-in-one]$ go version
go version go1.9.2 linux/amd64
I have tried to fix the issues that are obvious (upper case field names etc) but am left with
./routerTest.go:24:20: cannot use gateway.RxMetadata literal (type *gateway.RxMetadata) as type gateway.RxMetadata in field value
./routerTest.go:29:21: cannot use protocol.RxMetadata literal (type *protocol.RxMetadata) as type protocol.RxMetadata in field value
./routerTest.go:51:27: undefined: discovery.NewClient
./routerTest.go:63:19: undefined: router.NewRouterClientForGateway
./routerTest.go:63:75: undefined: c
./routerTest.go:64:19: undefined: router.NewMonitoredUplinkStream
When I start the local discovery server I get the following:
./ttn-linux-amd64 discovery --config ./discovery/ttn.yml
Using config file: ./discovery/ttn.yml
INFO Initializing The Things Network Auth Servers=map[ttn-account-v2:https://account.thethingsnetwork.org local:file://discovery/server.pub] ComponentID=mynetwork-discovery Description= Discovery Server Address:1900=discover.thethingsnetwork.org Monitors=map
INFO Initializing Discovery Database=localhost:6379/0 HTTP Proxy=0.0.0.0:8080 Server=0.0.0.0:1900
INFO Starting
INFO ttn: Got public keys for token validation
I am suspecting there is an issue with the discovery server address setting there.
As much as anything ‘fair use’ is about utilisation & saturation of the available RF spectrum…every GW in range receives all packets irrespective of network used and it is only when data gets to back end that policy is enforced and packets dropped. Having a private environment doesnt resolve the spectrum problem so short answer is no - (also) you still need to follow ETSI/FCC or who ever rules (in your part of the world) wrt duty cycle/dwell times etc. and fair use, whilst tighter than regs, ensures fair use for all…
‘Bypassing’ is somewhat antisocial…(IMHO) - though occasional ‘excess’ for testing & commissioning will usually see a blind eye turned…
TTN’s fair access policy only applies to the public community network, and is there to ensure that everyone can enjoy the public resources that are provided for free by the community. If you have your own private network with your own gateways, you can use them as much as you want, as long as you comply with the local duty cycle, transmit power or dwell time regulations. Having a private network does not except you from those. TTN’s backend will not help you break the law. If you use our backend in your private network, it will not be possible to circumvent those regulations.
One last thing: If you run into these limitations with your use case, then LoRaWAN is probably not a suitable technology for your use case, and you may want to consider alternatives such as Bluetooth/Wifi or 3G/4G/LTE/…
Hello,
we have set up a local backend on a Raspberry Pi3 which seems to be running fine on localhost (no Docker). Now we also have a TTN Gateway here which we would like to connect to this private backend. With the ttnctl-CLI one can set the address of the router for the gateway (something like: ttnctl gateways edit MYGATEWAY_ID --router 192.168.2.22).
Now the question is: Is it sufficient to set the router-address in the gateway to the IP of the Raspberry-backend (e.g. 192.168.2.22.) or is there more that has to be done?
I have tried to setup the whole backend using the IP of the Raspberry instead of localhost and set this address in the TTN gateway. The gateway seems to get the new address after a restart, but it will fail to connect to anything except the official routers (e.g. ttn-eu-router). The necessary ports (1900 - 1904 I think) were open, as I could verify with another Raspberry in the Ethernet.
Are we thinking to simple there, did we miss something, or is the TTN gateway not intended to work with private backends at all?
I highly appreciate your help!
First of all: If you want to use a private, local backend, it’s probably much easier to use a gateway different to TheThings Gateway. You can use the TTN Gateway plug-n-play to connect with the worldwide TTN (for noobies) or go the full on nerdy way, but nothing in between. Nerds can go on reading …
The problem is the TheThings Gateway and/or TheThings Console-WebGUI. In the firmware code on GitHub and in particular in app_configuration.c there is code that will force the gateway to load it’s configuration from the account server (default: account.thethingsnetwork.org). Now you can either (somehow) program your own account server and set it in the gateway or you can use the (closed-source) TTN account server. The problem now is, that the account server or the TTN Console-WebGUI refuses to accept routers other than the official TTN routers, so the Gateway will not get your local router’s adress, if you set it on the WebGUI.
The solution (or at least my solution) was to reprogram the gateways firmware (which is open-source and available on Github) and hard-code my local router’s IP-address.
In app_configuration.c search for: int r = EXIT_FAILURE; _ f(strstr(response_code, "200") != NULL) { // Success SYS_DEBUG(SYS_ERROR_DEBUG, "CONF: Response: too much to print\r\n"); SYS_DEBUG(SYS_ERROR_DEBUG, "CONF: Stack size 1: %d\r\n", uxTaskGetStackHighWaterMark(NULL)); r = _parseSettings(request.data_buffer); SYS_DEBUG(SYS_ERROR_DEBUG, "CONF: Stack size 2: %d\r\n", uxTaskGetStackHighWaterMark(NULL)); if(r == EXIT_SUCCESS) appConfigurationData.state = APP_CONFIGURATION_VALIDATING; else appConfigurationData.state = APP_CONFIGURATION_INCOMPLETE; }
The decoding of the HTTP request to the activation server happens in _parseSettings(request.data_buffer). So afterwards you can just force the gateway to reject the configuration from the activation server and set:
const char nhost = "YOUR_BACKENDS_IP-ADDRESS"
const char npath = "";
bool tls = false; //true
uint16_t nport = 1883; //8883 if you need TLS encryption of MQTT_
sprintf(appGWActivationData.configuration_gateway.ttn_servers[0].server_address, "%s%s", nhost,
npath);
appGWActivationData.configuration_gateway.ttn_servers[0].serv_port_up = nport;
appGWActivationData.configuration_gateway.ttn_servers[0].serv_port_down = nport;
appGWActivationData.configuration_gateway.ttn_servers[0].serv_tls = tls;
To setup your development environment see the instructions at: https://github.com/TheThingsProducts/gateway/tree/develop/firmware https://www.thethingsnetwork.org/forum/t/building-the-ttn-gateway-firmware-from-the-github-code/12739
To update the firmware via SD-card, compile your new firmware with MPLABX and run generate_hex_with_checksum.sh in the TTN firmware folder.
For programming the gateway with a PickIt or ICD3 debugger see https://www.thethingsnetwork.org/docs/gateways/gateway/programhexfile.html.
For debugging, be sure to modify the reset vector in the linker file (still does not work flawlessly, resets at start of RTOS scheduler, don’t know why):
RESET_ADDR = 0xBFC00000 //NOT 0xBD000000, works only with bootloader in non-debugging state
Btw: It is sufficient to setup your local backend according to Hylke Visser’s guide. The gateway will finally connect to mosquitto and the gateway-bridge. The bridge will then forward the gateways data to the router and there you go. Be sure to only use ttnctl-CLI-tool for your local backend and not the WebGUI.
I’m trying to setup the routing environment on an Azure virtual machine. I have followed the instructions and setup my backend on Ubuntu 16.04.
Everything seems to run without error, except when I run the “gateway-connector-bridge” command, It stays up for few minutes and then it shows following error (FATAL Not all backends started in time) and closes. My gateway connects with my backend and after few minutes lost the connection because the error.
The error has short description and I don’t know what is it related to. Any help would be appreciated.
I’m really new to this community and sorry if my question is a basic question.
I have installed private TTN network and gone through articles in blog.
I have run 'docker-compose up -d ’ and all the services are started successfully.
Now, i have changed the server_address in gateway( which has ttn software) to hostname i.e.“192.168.0.163” and left port as it is 1700
when i try to analyze packets are transmitted from gateway on 1700 port but no respose from the server.
Found that ‘destination unreachable’ from the wireshark even though the port is opened.
I have registered the gateway using ‘ttnctl’ and configured as Router - mynetwork-router.
I would like to know where can i see the server status ?
my configurations looks like below,
ttnctl.yml:
config file: /home/xx/.ttnctl.yml
data dir: /home/xx/.ttnctl
sorry first of all for revive this topic! I have a brief question regarding the Gateway registration when using the Private Backend guide. Can I register my LoRa Gateway, App and Devices locally on the same lab using the ttnctl console specifying private IPs? If so, I guess that using local IPs when asked for the router and handler would be enough to orchestrate all together. Otherwhise, should I use a public domain and enable port forwarding?
One final remark for all those trying to get their private backend running:
Get yourself some different gateway (e.g. on Raspberry Pi basis) and use Brocaar as LoRa server. Just my humble opinion …
TTN stuff is pretty nice and easy when using the whole TTN environment as is, but it is probably not intended (or at least not favorable) to be used as a private network.
Hi,
i deployed the private routing environment. How to connect my sensors that already connected/migrate from the TTN cloud to TTN local host? I had tried follow the all parameter setup e.g. Dev EUI, App EUI and App key same as in TTN cloud. But the result the device still can not connect .
I found system log as follow:
stack_1 | INFO Finished unary call duration=800µs error=error:pkg/networkserver:device_not_found (device not found) error_cause=error:pkg/networkserver/redis:no_uplink_match (no device matches uplink) error_correlation_id=f9e49cd0fc544fd0a88f1dd42c88ee5c error_name=device_not_found error_namespace=pkg/networkserver grpc.method=HandleUplink grpc.service=ttn.lorawan.v3.GsNs grpc_code=NotFound namespace=grpc peer.address=pipe request_id=01FGE67J1VWT79YSXF3V13QF0K
stack_1 | INFO Finished unary call duration=800µs error=error:pkg/networkserver:device_not_found (device not found) error_cause=error:pkg/networkserver/redis:no_uplink_match (no device matches uplink) error_correlation_id=186540b9604a4eeea1f5c5498d5e71e2 error_name=device_not_found error_namespace=pkg/networkserver grpc.method=HandleUplink grpc.service=ttn.lorawan.v3.GsNs grpc_code=NotFound namespace=grpc peer.address=pipe request_id=01FGE67M1X3N39WHE1PJ68JY3G
stack_1 | INFO Finished unary call duration=800µs error=error:pkg/networkserver:device_not_found (device not found) error_cause=error:pkg/networkserver/redis:no_uplink_match (no device matches uplink) error_correlation_id=310aa7a7c06047b18671235be5655c3a error_name=device_not_found error_namespace=pkg/networkserver grpc.method=HandleUplink grpc.service=ttn.lorawan.v3.GsNs grpc_code=NotFound namespace=grpc peer.address=pipe request_id=01FGE67SWTFHW27QCKX9Q5A35B
stack_1 | INFO Finished unary call duration=800µs error=error:pkg/networkserver:device_not_found (device not found) error_cause=error:pkg/networkserver/redis:no_uplink_match (no device matches uplink) error_correlation_id=393d9d90714144f696d4c4f05bde8a46 error_name=device_not_found error_namespace=pkg/networkserver grpc.method=HandleUplink grpc.service=ttn.lorawan.v3.GsNs grpc_code=NotFound namespace=grpc peer.address=pipe request_id=01FGE67V353T5RZK7HP35220E6
stack_1 | INFO Request handled duration=0s http.method=GET http.path=/healthz/live http.status=200 namespace=web peer.address=127.0.0.1:57376 request_id=01FGE67VBGN7VZRKN7FQX1BY7T
stack_1 | INFO Finished unary call duration=800µs error=error:pkg/networkserver:device_not_found (device not found) error_cause=error:pkg/networkserver/redis:no_uplink_match (no device matches uplink) error_correlation_id=7b2b782f1bb54a2aa875426851d95bc0 error_name=device_not_found error_namespace=pkg/networkserver grpc.method=HandleUplink grpc.service=ttn.lorawan.v3.GsNs grpc_code=NotFound namespace=grpc peer.address=pipe request_id=01FGE67X38SQZVKDVMMDCWVZDC
stack_1 | INFO Finished unary call duration=800µs error=error:pkg/networkserver:device_not_found (device not found) error_cause=error:pkg/networkserver/redis:no_uplink_match (no device matches uplink) error_correlation_id=f062f2f519494ce6b9a38a9cca613953 error_name=device_not_found error_namespace=pkg/networkserver grpc.method=HandleUplink grpc.service=ttn.lorawan.v3.GsNs grpc_code=NotFound namespace=grpc peer.address=pipe request_id=01FGE6864GK9WRKV9XFQB280W7
stack_1 | INFO Finished unary call duration=800µs error=error:pkg/networkserver:device_not_found (device not found) error_cause=error:pkg/networkserver/redis:no_uplink_match (no device matches uplink) error_correlation_id=ff8f1bf5011c45939cbbe284b40f3ab4 error_name=device_not_found error_namespace=pkg/networkserver grpc.method=HandleUplink grpc.service=ttn.lorawan.v3.GsNs grpc_code=NotFound namespace=grpc peer.address=pipe request_id=01FGE6898G8QF2ZGGVQ0WQ551X
I deployed V3.13 stack for local host.
I used my own gateway 7249 series from RAK. I pointed gateway to local host .
I successfull connect the gateway to local host, but not for the end device.
Whats wrong and what should we do?
If you deployed the v3.13 (v3.15 has many bug fixes in it) on a computer there is no way the RAK gateway can point at it if you’ve put localhost in for the gateway server address as localhost on the RAAK gateway will be itself.
Actually i deployed V3.13 stack in Raspi 4. I point at my gateway to Raspi 4 IP address.
In the Raspi4 with ttn stack V3.13 i registered the gateway and connected successfully. Unfotunattely, the end device can not connect to V3.13 in raspi. Please advice how to connect end device in V3.13 ttn local host (raspi4).
Note: the current end devices succesfull connect to V3.15 stack in ttn cloud server.
as being you pointing the gateway to localhost - which has a specific meaning.
I’m now interpreting it as being a local computer on your network, a RPi4.
As I said above, the v3.15 has a lot of fixes from v3.13 so my advice would be to run the upgrade script on your local server, the RPi, to bring it up to 3.15. I’d also suggest looking up what localhost means vs a phrase like local server or local network. I realise English may not be your first language, but this confusion took a lot of head scratching to figure out the all important space in your usage!
