I successfully configured passive roaming for devices from netid 13 (ttn). It was a bit difficult because the changes from Chirpstack v3 to v4. E.g. the documentation on packetbroker.org (How to configure chirpstack) seem to be based on Chirpstack v3, they do not mention it but i deducted it from the names and structure of the configuration in comparison with the source-code.
The chirpstack v4 doc has no topic about the roaming configuration, only the example config with some comments. This was a start, but I stumbled in a problem, because I configured “resolve_net_id_domain_suffix” to “.netids.lora-alliance.org” (as states in packetbroker config).
This did not work, I tried to find my error and studied the v4 source (and learn rust ^^). I found out, that when “resolve_netid_domain_suffix” is set, the URL for the fNS is constructed from netid + resolve_netid_domain_suffix, and the configured “server” config is ignored. I checked the resolving of 00000d.netids.lora-alliance.org and it did not work. I read the lorawan backend specification 1.0 and was confused that there is a backend spec 1.1.0 called “TS002-1.1.0” from 2020, which uses “.netids.lorawan.net” which isn’t even registered from the lora alliance. I tried to resolve the examples from the backend spec 1.0 - the netids there did not resolve, but the join-server do… strange.
After removing the “resolve_net_id_domain_suffix” config, the roaming to the packet-broker is working, but maybe someone can enlighten me about the state of the lorawan specs and why the resolving of netids is not working.
did you get this to work, i’ve been following their skinny instructions verbatim as far as i can tell on setting this up and go and it doesn’t even download and compile the binaries required in their examples from to go install .... (i’m not a go programmer i so perhaps i’m doing something wrong)
i have latest version of go at /usr/local/bin/go and in my path.
According to the documentation of “go install” (go help install) the binaries are installed in $GOPATH/bin or $HOME/go/bin if the GOPATH environment variable is not set.
After that, I got a pbadmin-binary in $HOME/go/bin
You have to check that either your GOPATH is set so /usr/local/go/bin or you add $HOME/go/bin to you PATH.
it doesnt seem to generate the ca.srl and i get an error
cory@dred:~/pb-certs$ openssl x509 -sha256 -req -in pb_client.csr -out pb_client.crt -CA ca.crt -CAkey ca.key -days 1825 -CAserial ca.srl
Signature ok
subject=C = NL, ST = Noord-Holland, L = Amsterdam, O = The Things Industries B.V., OU = Packet Broker, CN = 000013
Getting CA Private Key
ca.srl: No such file or directory
140659870709056:error:02001002:system library:fopen:No such file or directory:../crypto/bio/bss_file.c:69:fopen('ca.srl','r')
140659870709056:error:2006D080:BIO routines:BIO_new_file:no such file:../crypto/bio/bss_file.c:76:
which is correct as the file doesnt exist. i just assumed that command would generate it.
The documentation “man openssl-x509” states:
-CAserial filename
Sets the CA serial number file to use.
When creating a certificate with this option and with the -CA option, the certificate serial number is
stored in the given file. This file consists of one line containing an even number of hex digits with
the serial number used last time. After reading this number, it is incremented and used, and the file
is updated
So when you use this parameter, the file has to exist. But you can safely leave this parameter away, because then:
f the -CA option is specified and neither <-CAserial> or <-CAcreateserial> is given and the default
serial number file does not exist, a random number is generated; this is the recommended practice.
thanks, going off my version this was the only option that worked for me openssl x509 -sha256 -req -in pb_client.csr -out pb_client.crt -CA ca.crt -CAkey ca.key -days 1825 -CAcreateserial
i might need to check and update openssl it seems quite old on this system OpenSSL 1.1.1f 31 Mar 2020.
Not exactly… I’ve just moved onto the next snag but I have been unable to debug further as increasing log verbosity doesnt really work for the passive roaming output
my instance kept crashing if i generated the certs how packet broker says… i had to generate them as rsa 4096 signed and sent to them.
everything seems to be ok according to ttn, but idk how to proceed after receiving the following in reply a few days ago.
The certs look good now, but curl still fails and Packet Broker shows:
roaming: request failed: Post \"https://example.com:5138\": remote error: tls: handshake failure
"remote error" indicates that the server (ChirpStack) gave an error during the TLS handshake.
Nothing we can diagnose further from our side, unfortunately.
