Handle join-request with different host

Hello,

I’m having trouble with join-request since I have LoRa Server and LoRa App Server on different host.
On the LoRa Server machine, I changed the network_server.api (lora_server_ip:8000) and on the LoRa App Server machine, I changed application_server.api.bind (lora_app_server_ip:8001) and application_server.public_host (lora_app_server:8001). Still, I can’t join my devices (in OTAA) :

LoRa Server config file :

[general]
# Log level
#
# debug=5, info=4, warning=3, error=2, fatal=1, panic=0
log_level=4

# PostgreSQL settings.
#
# Please note that PostgreSQL 9.5+ is required.
[postgresql]
# PostgreSQL dsn (e.g.: postgres://user:password@hostname/database?sslmode=disable).
#
# Besides using an URL (e.g. 'postgres://user:password@hostname/database?sslmode=disable')
# it is also possible to use the following format:
# 'user=loraserver dbname=loraserver sslmode=disable'.
#
# The following connection parameters are supported:
#
# * dbname - The name of the database to connect to
# * user - The user to sign in as
# * password - The user's password
# * host - The host to connect to. Values that start with / are for unix domain sockets. (default is localhost)
# * port - The port to bind to. (default is 5432)
# * sslmode - Whether or not to use SSL (default is require, this is not the default for libpq)
# * fallback_application_name - An application_name to fall back to if one isn't provided.
# * connect_timeout - Maximum wait for connection, in seconds. Zero or not specified means wait indefinitely.
# * sslcert - Cert file location. The file must contain PEM encoded data.
# * sslkey - Key file location. The file must contain PEM encoded data.
# * sslrootcert - The location of the root certificate file. The file must contain PEM encoded data.
#
# Valid values for sslmode are:
#
# * disable - No SSL
# * require - Always SSL (skip verification)
# * verify-ca - Always SSL (verify that the certificate presented by the server was signed by a trusted CA)
# * verify-full - Always SSL (verify that the certification presented by the server was signed by a trusted CA and the server host name matches the one in the certificate)
dsn="postgres://loraserver_ns:dbpassword@localhost/loraserver_ns?sslmode=disable"

# Automatically apply database migrations.
#
# It is possible to apply the database-migrations by hand
# (see https://github.com/brocaar/loraserver/tree/master/migrations)
# or let LoRa App Server migrate to the latest state automatically, by using
# this setting. Make sure that you always make a backup when upgrading Lora
# App Server and / or applying migrations.
automigrate=true

# Redis settings
#
# Please note that Redis 2.6.0+ is required.
[redis]
# Redis url (e.g. redis://user:password@hostname/0)
#
# For more information about the Redis URL format, see:
# https://www.iana.org/assignments/uri-schemes/prov/redis
url="redis://localhost:6379"

# Network-server settings.
[network_server]
# Network identifier (NetID, 3 bytes) encoded as HEX (e.g. 010203)
net_id="000000"

# Time to wait for uplink de-duplication.
#
# This is the time that LoRa Server will wait for other gateways to receive
# the same uplink frame. Valid units are 'ms' or 's'.
# Please note that this value has influence on the uplink / downlink
# roundtrip time. Setting this value too high means LoRa Server will be
# unable to respond to the device within its receive-window.
deduplication_delay="200ms"

# Device session expiration.
#
# The TTL value defines the time after which a device-session expires
# after no activity. Valid units are 'ms', 's', 'm', 'h'. Note that these
# values can be combined, e.g. '24h30m15s'.
device_session_ttl="744h0m0s"

# Get downlink data delay.
#
# This is the time that LoRa Server waits between forwarding data to the
# application-server and reading data from the queue. A higher value
# means that the application-server has more time to schedule a downlink
# queue item which can be processed within the same uplink / downlink
# transaction.
# Please note that this value has influence on the uplink / downlink
# roundtrip time. Setting this value too high means LoRa Server will be
# unable to respond to the device within its receive-window.
get_downlink_data_delay="100ms"

# LoRaWAN regional band configuration.
#
# Note that you might want to consult the LoRaWAN Regional Parameters
# specification for valid values that apply to your region.
# See: https://www.lora-alliance.org/lorawan-for-developers
[network_server.band]
# LoRaWAN band to use.
#
# Valid values are:
# * AS_923
# * AU_915_928
# * CN_470_510
# * CN_779_787
# * EU_433
# * EU_863_870
# * IN_865_867
# * KR_920_923
# * RU_864_870
# * US_902_928
name="EU_863_870"

# Enforce 400ms dwell time
#
# Some band configurations define the max payload size for both dwell-time
# limitation enabled as disabled (e.g. AS 923). In this case the
# dwell time setting must be set to enforce the max payload size
# given the dwell-time limitation. For band configuration where the dwell-time is
# always enforced, setting this flag is not required.
dwell_time_400ms=false

# Enforce repeater compatibility
#
# Most band configurations define the max payload size for both an optional
# repeater encapsulation layer as for setups where a repeater will never
# be used. The latter case increases the max payload size for some data-rates.
# In case a repeater might used, set this flag to true.
repeater_compatible=false

# LoRaWAN network related settings.
[network_server.network_settings]
# Installation margin (dB) used by the ADR engine.
#
# A higher number means that the network-server will keep more margin,
# resulting in a lower data-rate but decreasing the chance that the
# device gets disconnected because it is unable to reach one of the
# surrounded gateways.
installation_margin=10

# Class A RX1 delay
#
# 0=1sec, 1=1sec, ... 15=15sec. A higher value means LoRa Server has more
# time to respond to the device as the delay between the uplink and the
# first receive-window will be increased.
rx1_delay=1

# RX1 data-rate offset
#
# Please consult the LoRaWAN Regional Parameters specification for valid
# options of the configured network_server.band.name.
rx1_dr_offset=0

# RX2 data-rate
#
# When set to -1, the default RX2 data-rate will be used for the configured
# LoRaWAN band.
#
# Please consult the LoRaWAN Regional Parameters specification for valid
# options of the configured network_server.band.name.
rx2_dr=-1

# RX2 frequency
#
# When set to -1, the default RX2 frequency will be used.
#
# Please consult the LoRaWAN Regional Parameters specification for valid
# options of the configured network_server.band.name.
rx2_frequency=-1

# Disable mac-commands
#
# When set, uplink mac-commands are ignored and the network-server will not
# send mac-commands to the devices. This is intended for testing only.
disable_mac_commands=false

# Enable only a given sub-set of channels
#
# Use this when ony a sub-set of the by default enabled channels are being
# used. For example when only using the first 8 channels of the US band.
#
# Example:
# enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7]
enabled_uplink_channels=[]

# Extra channel configuration.
#
# Use this for LoRaWAN regions where it is possible to extend the by default
# available channels with additional channels (e.g. the EU band).
# The first 5 channels will be configured as part of the OTAA join-response
# (using the CFList field).
# The other channels (or channel / data-rate changes) will be (re)configured
# using the NewChannelReq mac-command.
#
# Example:
# [[network_server.network_settings.extra_channels]]
# frequency=867100000
# min_dr=0
# max_dr=5

# [[network_server.network_settings.extra_channels]]
# frequency=867300000
# min_dr=0
# max_dr=5

# [[network_server.network_settings.extra_channels]]
# frequency=867500000
# min_dr=0
# max_dr=5

# [[network_server.network_settings.extra_channels]]
# frequency=867700000
# min_dr=0
# max_dr=5

# [[network_server.network_settings.extra_channels]]
# frequency=867900000
# min_dr=0
# max_dr=5

# Class B settings
[network_server.network_settings.class_b]
# Ping-slot data-rate.
ping_slot_dr=0

# Ping-slot frequency (Hz)
#
# Set this to 0 to use the default frequency plan for the configured region
# (which could be frequency hopping).
ping_slot_frequency=0

# Network-server API
#
# This is the network-server API that is used by LoRa App Server or other
# custom components interacting with LoRa Server.
[network_server.api]
# ip:port to bind the api server
bind="lora_server_ip:8000"

# ca certificate used by the api server (optional)
ca_cert=""

# tls certificate used by the api server (optional)
tls_cert=""

# tls key used by the api server (optional)
tls_key=""

# Gateway statistics settings.
[network_server.gateway.stats]
# Create non-existing gateways on receiving of stats
#
# When set to true, LoRa Server will create the gateway when it receives
# statistics for a gateway that does not yet exist.
create_gateway_on_stats=true

# Aggregation timezone
#
# This timezone is used for correctly aggregating the statistics (for example
# 'Europe/Amsterdam').
# To get the list of supported timezones by your PostgreSQL database,
# execute the following SQL query:
# select * from pg_timezone_names;
# When left blank, the default timezone of your database will be used.
timezone=""

# Aggregation intervals to use for aggregating the gateway stats
#
# Valid options: second, minute, hour, day, week, month, quarter, year.
# When left empty, no statistics will be stored in the database.
# Note, LoRa App Server expects at least "minute", "day", "hour" !

aggregation_intervals=[";minute", "hour", "day"]

# MQTT gateway backend settings.
#
# This is the backend communicating with the LoRa gateways over a MQTT broker.
[network_server.gateway.backend.mqtt]
# MQTT topic templates for the different MQTT topics.
#
# The meaning of these topics are documented at:
# https://docs.loraserver.io/lora-gateway-bridge/use/data/
#
# The default values match the default expected configuration of the
# LoRa Gateway Bridge MQTT backend. Therefore only change these values when
# absolutely needed.
# Use "{{ .MAC }}" as an substitution for the LoRa gateway MAC.
uplink_topic_template="gateway/+/rx"
downlink_topic_template="gateway/{{ .MAC }}/tx"
stats_topic_template="gateway/+/stats"
ack_topic_template="gateway/+/ack"
config_topic_template="gateway/{{ .MAC }}/config"

# MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
server="tcp://localhost:1883"

# Connect with the given username (optional)
username=""

# Connect with the given password (optional)
password=""

# Quality of service level
#
# 0: at most once
# 1: at least once
# 2: exactly once
#
# Note: an increase of this value will decrease the performance.
# For more information: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels
qos=0

# Clean session
#
# Set the "clean session" flag in the connect message when this client
# connects to an MQTT broker. By setting this flag you are indicating
# that no messages saved by the broker for this client should be delivered.
clean_session=true

# Client ID
#
# Set the client id to be used by this client when connecting to the MQTT
# broker. A client id must be no longer than 23 characters. When left blank,
# a random id will be generated. This requires clean_session=true.
client_id=""

# CA certificate file (optional)
#
# Use this when setting up a secure connection (when server uses ssl://...)
# but the certificate used by the server is not trusted by any CA certificate
# on the server (e.g. when self generated).
ca_cert=""

# TLS certificate file (optional)
tls_cert=""

# TLS key file (optional)
tls_key=""

# Default join-server settings.
[join_server.default]
# hostname:port of the default join-server
#
# This API is provided by LoRa App Server.
server="http:lora_app_server_ip:8003"

# ca certificate used by the default join-server client (optional)
ca_cert=""

# tls certificate used by the default join-server client (optional)
tls_cert=""

# tls key used by the default join-server client (optional)
tls_key=""

# Network-controller configuration.
[network_controller]
# hostname:port of the network-controller api server (optional)
server=""

# ca certificate used by the network-controller client (optional)
ca_cert=""

# tls certificate used by the network-controller client (optional)
tls_cert=""

# tls key used by the network-controller client (optional)
tls_key=""

Here is the logs :

 oct. 17 15:41:21 debian systemd[1]: Starting LoRa Server...
oct. 17 15:41:21 debian systemd[1]: Started LoRa Server.
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="starting LoRa Server" band=EU_863_870 docs="https://docs.loraserver.io/" net_id=000000 version=1.0.1
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="setup redis connection pool"; url="redis://localhost:6379"
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="connecting to postgresql"
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="backend/gateway: TLS config is empty"
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="backend/gateway: connecting to mqtt broker" server="tcp://localhost:1883"
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="configuring join-server client" ca_cert= server="http:lora_app_server_ip:8003" tls_cert= tls_key=
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="no network-controller configured"
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00"  level=info msg="applying database migrations"
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="backend/gateway: connected to mqtt server"
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="backend/gateway: subscribing to rx topic" qos=0 topic=gateway/+/rx
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="backend/gateway: subscribing to stats topic"qos=0 topic=gateway/+/stats
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="migrations applied" count=0
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="starting api server"bind="lora_server_ip:8000" ca-cert= tls-cert= tls-key=
oct. 17 15:41:21 debian loraserver[6504]: time="2018-10-17T15:41:21+02:00" level=info msg="starting downlink device-queue scheduler"
oct. 17 15:41:22 debian loraserver[6504]: time="2018-10-17T15:41:22+02:00" level=info msg="backend/gateway: rx packet received"
oct. 17 15:41:22 debian loraserver[6504]: time="2018-10-17T15:41:22+02:00" level=info msg="packet(s) collected" dev_eui=70b3d59ba00005bb gw_count=1 gw_macs=b827ebfffef65df2 mtype=JoinRequest
oct. 17 15:41:22 debian loraserver[6504]: time="2018-10-17T15:41:22+02:00" level=error msg="processing rx packet error: get device error: object does not exist" data_base64="AAQAAKCb1bNwuwUAoJvVs3Ak+CjcSso="
oct. 17 15:41:27 debian loraserver[6504]: time="2018-10-17T15:41:27+02:00" level=info msg="backend/gateway: rx packet received"
oct. 17 15:41:27 debian loraserver[6504]: time="2018-10-17T15:41:27+02:00" level=error msg="processing rx packet error: get device-session error: device-session does not exist or invalid fcnt or mic" data_base64="QOKq8Q+A4gACJRa1BQ34BrzD85rg4z9vkw=="

The configuration file in LoRa App Server :

[general]
# Log level
#
# debug=5, info=4, warning=3, error=2, fatal=1, panic=0
log_level=4

# The number of times passwords must be hashed. A higher number is safer as
# an attack takes more time to perform.
password_hash_iterations=100000

# PostgreSQL settings.
#
# Please note that PostgreSQL 9.5+ is required.
[postgresql]
# PostgreSQL dsn (e.g.: postgres://user:password@hostname/database?sslmode=disable).
#
# Besides using an URL (e.g. 'postgres://user:password@hostname/database?sslmode=disable')
# it is also possible to use the following format:
# 'user=loraserver dbname=loraserver sslmode=disable'.
#
# The following connection parameters are supported:
#
# * dbname - The name of the database to connect to
# * user - The user to sign in as
# * password - The user's password
# * host - The host to connect to. Values that start with / are for unix domain sockets. (default is localhost)
# * port - The port to bind to. (default is 5432)
# * sslmode - Whether or not to use SSL (default is require, this is not the default for libpq)
# * fallback_application_name - An application_name to fall back to if one isn't provided.
# * connect_timeout - Maximum wait for connection, in seconds. Zero or not specified means wait indefinitely.
# * sslcert - Cert file location. The file must contain PEM encoded data.
# * sslkey - Key file location. The file must contain PEM encoded data.
# * sslrootcert - The location of the root certificate file. The file must contain PEM encoded data.
#
# Valid values for sslmode are:
#
# * disable - No SSL
# * require - Always SSL (skip verification)
# * verify-ca - Always SSL (verify that the certificate presented by the server was signed by a trusted CA)
# * verify-full - Always SSL (verify that the certification presented by the server was signed by a trusted CA and the server host name matches the one in the certificate)
dsn="postgres://loraserver_as:dbpassword@localhost/loraserver_as?sslmode=disable"

# Automatically apply database migrations.
#
# It is possible to apply the database-migrations by hand
# (see https://github.com/brocaar/lora-app-server/tree/master/migrations)
# or let LoRa App Server migrate to the latest state automatically, by using
# this setting. Make sure that you always make a backup when upgrading Lora
# App Server and / or applying migrations.
automigrate=true

# Redis settings
#
# Please note that Redis 2.6.0+ is required.
[redis]
# Redis url (e.g. redis://user:password@hostname/0)
#
# For more information about the Redis URL format, see:
# https://www.iana.org/assignments/uri-schemes/prov/redis
url="redis://localhost:6379"

# Application-server settings.
[application_server]
# Application-server identifier.
#
# Random UUID defining the id of the application-server installation (used by
# LoRa Server as routing-profile id).
# For now it is recommended to not change this id.
id="6d5db27e-4ce2-4b2b-b5d7-91f069397978"

# MQTT integration configuration used for publishing (data) events
# and scheduling downlink application payloads.
# Next to this integration which is always available, the user is able to
# configure additional per-application integrations.
[application_server.integration.mqtt]
# MQTT topic templates for the different MQTT topics.
#
# The meaning of these topics are documented at:
# https://docs.loraserver.io/lora-app-server/integrate/data/
#
# The following substitutions can be used:
# * "{{ .ApplicationID }}" for the application id.
# * "{{ .DevEUI }}" for the DevEUI of the device.
#
# Note: the downlink_topic_template must contain both the application id and
# DevEUI substitution!
uplink_topic_template="application/{{ .ApplicationID }}/device/{{ .DevEUI }}/rx"
downlink_topic_template="application/{{ .ApplicationID }}/device/{{ .DevEUI }}/tx"
join_topic_template="application/{{ .ApplicationID }}/device/{{ .DevEUI }}/join"
ack_topic_template="application/{{ .ApplicationID }}/device/{{ .DevEUI }}/ack"
error_topic_template="application/{{ .ApplicationID }}/device/{{ .DevEUI }}/error"

# MQTT server (e.g. scheme://host:port where scheme is tcp, ssl or ws)
server="tcp://localhost:1883"

# Connect with the given username (optional)
username=""

# Connect with the given password (optional)
password=""

# Quality of service level
#
# 0: at most once
# 1: at least once
# 2: exactly once
#
# Note: an increase of this value will decrease the performance.
# For more information: https://www.hivemq.com/blog/mqtt-essentials-part-6-mqtt-quality-of-service-levels
qos=0

# Clean session
#
# Set the "clean session" flag in the connect message when this client
# connects to an MQTT broker. By setting this flag you are indicating
# that no messages saved by the broker for this client should be delivered.
clean_session=true

# Client ID
#
# Set the client id to be used by this client when connecting to the MQTT
# broker. A client id must be no longer than 23 characters. When left blank,
# a random id will be generated. This requires clean_session=true.
client_id=""

# CA certificate file (optional)
#
# Use this when setting up a secure connection (when server uses ssl://...)
# but the certificate used by the server is not trusted by any CA certificate
# on the server (e.g. when self generated).
ca_cert=""

# TLS certificate file (optional)
tls_cert=""

# TLS key file (optional)
tls_key=""

# Settings for the "internal api"
#
# This is the API used by LoRa Server to communicate with LoRa App Server
# and should not be exposed to the end-user.
[application_server.api]
# ip:port to bind the api server
bind="lora_app_server_ip:8001"

# ca certificate used by the api server (optional)
ca_cert=""

# tls certificate used by the api server (optional)
tls_cert=""

# tls key used by the api server (optional)
tls_key=""

# Public ip:port of the application-server API.
#
# This is used by LoRa Server to connect to LoRa App Server. When running
# LoRa App Server on a different host than LoRa Server, make sure to set
# this to the host:ip on which LoRa Server can reach LoRa App Server.
# The port must be equal to the port configured by the 'bind' flag
# above.
public_host="lora_app_server_ip:8001"

# Settings for the "external api"
#
# This is the API and web-interface exposed to the end-user.
[application_server.external_api]
# ip:port to bind the (user facing) http server to (web-interface and REST / gRPC api)
bind="0.0.0.0:8080"

# http server TLS certificate
tls_cert="/etc/lora-app-server/certs/http.pem"

# http server TLS key
tls_key="/etc/lora-app-server/certs/http-key.pem"

# JWT secret used for api authentication / authorization
# You could generate this by executing 'openssl rand -base64 32' for example
jwt_secret="hnn++eQNoVOL86mniD3Mpc2kH+yy9mNqwgdVQYKZ/Vxk="

# when set, existing users can't be re-assigned (to avoid exposure of all users to an organization admin)"
disable_assign_existing_users=false

# Join-server configuration.
#
# LoRa App Server implements a (subset) of the join-api specified by the
# LoRaWAN Backend Interfaces specification. This API is used by LoRa Server
# to handle join-requests.
[join_server]
# ip:port to bind the join-server api interface to
bind="0.0.0.0:8003"

# ca certificate used by the join-server api server
ca_cert=""

# tls certificate used by the join-server api server (optional)
tls_cert=""

# tls key used by the join-server api server (optional)
tls_key=""

And, the logs from Lora App Server :

oct. 17 13:55:17 new-host systemd[1]: Starting LoRa App Server...
oct. 17 13:55:17 new-host systemd[1]: Started LoRa App Server.
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="starting LoRa App Server" docs="https://www.loraserver.io/" version=1.0.2
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="connecting to postgresql"
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="setup redis connection pool"
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="handler/mqtt: TLS config is empty"
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="handler/mqtt: connecting to mqtt broker" server="tcp://localhost:1883/"
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="applying database migrations"
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:10" level=info msg="handler/mqtt: connected to mqtt broker"
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="handler/mqtt: subscribing to tx topic" qos=0 topic=application/+/device/+/tx
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00"; level=info msg="migrations applied" count=0
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="starting application-server api" bind="lora_app_server_ip:8001" ca-cert= tls-cert= tls-key=
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="starting join-server api" bind="0.0.0.0:8003" ca_cert= tls_cert= tls_key=
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="starting client api server" bind="0.0.0.0:8080" tls-cert=/etc/lora-app-server/certs/http.pem tls-key=/etc/lora-app-server/certs/http-key.pem
oct. 17 13:55:17 new-host lora-app-server[9156]: time="2018-10-17T13:55:17+02:00" level=info msg="registering rest api handler and documentation endpoint" path=/api
oct. 17 13:55:21 new-host lora-app-server[9156]: time="2018-10-17T13:55:21+02:00" level=warning msg="creating insecure network-server client" server="lora_server_ip:8000"
oct. 17 13:55:21 new-host lora-app-server[9156]: time=";2018-10-17T13:55:21+02:00" level=info msg="finished client streaming call" grpc.code=OK grpc.method=StreamFrameLogsForDevice grpc.service=ns.NetworkServer grpc.time_ms=0.089 span.kind=client system=grpc

I guess this is related to the join_server.bind but I have no idea which ip to inform.
Thanks in advance.

I don’t think it is related to your configuration:

oct. 17 15:41:22 debian loraserver[6504]: time="2018-10-17T15:41:22+02:00" level=error msg="processing rx packet error: get device error: object does not exist" data_base64="AAQAAKCb1bNwuwUAoJvVs3Ak+CjcSso=" oct. 17 15:41:27 debian loraserver[6504]: time="2018-10-17T15:41:27+02:00" level=info msg="backend/gateway: rx packet received"
oct. 17 15:41:27 debian loraserver[6504]: time="2018-10-17T15:41:27+02:00" level=error msg="processing rx packet error: get device-session error: device-session does not exist or invalid fcnt or mic" data_base64="QOKq8Q+A4gACJRa1BQ34BrzD85rg4z9vkw=="

It seems the devices is not provisioned (correctly).

I’m pretty sure my device is provisionned correctly because I declared it exactly the same as before (when LoRa App and LoRa Server were on the same machine).

Therefore, I don’t understand why I can’t even see my gateway on the Live LoRaWAN Frames on the LoRa App Server whereas I can see it on the logs of my LoRa Server.

Thanks.