Hello,
I’ve just setup my first simple LoRaWAN network with loraserver.io components and everything worked fine.
But when it comes to authorization at the mqtt broker I got stuck. I compiled mosquitto-auth-plug, added passwords and acls as given in the instructions and changed the toml files of loraserver, lora-app-server and gateway. Unfortunately I can’t get the system up anymore. All components show a lot of log entries like these taken from gateway:
INFO[0001] backend: connected to mqtt broker
INFO[0001] backend: subscribing to topic qos=0 topic=gateway/ID/tx
ERRO[0001] backend: mqtt connection error error=EOF
ERRO[0001] backend: subscribe multiple failed: Connection lost before Subscribe completed topic_count=1
ERRO[0001] backend: subscribe multiple failed: Connection lost before Subscribe completed topic_count=1
INFO[0001] backend: subscribing to topic qos=0 topic=gateway/ID/tx
followed by even more of these:
INFO[0002] backend: subscribing to topic qos=0 topic=gateway/ID/tx
The info in mosquitto log is:
1548763810: Socket error on client ef60439f-512b-4ec8-b8f7-15118ed15318, disconnecting.
I’ve already searched here, but didn’t found a thread which could get me further, maybe someone has an idea?
Thanks in advance
I can add another information; it looks like the login data from postgres is working, but the static data from files is not
@brocaar: Thanks for adding the correct tag
What mosquitto version are you using? How are you doing authentication/authorization? Could you show us your auth configuration, static acls and password files (without sensible parts)? Do static clients connect (i.e., authenticate correctly) but fail to subscribe only (i.e., authorization fails)?
1 Like
@iegomez Thanks for trying to help me
Trying to subscribe to a topic I got a
1548775762: |-- mosquitto_auth_acl_check(…, client id not available, loraserver_ns, #, MOSQ_ACL_WRITE)
1548775762: |-- SUPERUSER: loraserver_ns
1548775762: |-- user is 0
1548775762: |-- USERNAME: loraserver_ns, TOPIC: #, acc: 4
ERROR: column ou.u$ does not exist
LINE 1: … ‘/#’ from “user” u inner join organization_user ou on ou.u$
^
1548775762: |-- aclcheck(loraserver_ns, #, 4) HAS_ERROR=Y by postgres
1548775762: |-- aclcheck(loraserver_ns, #, 4) AUTHORIZED=0 by none
1548775762: |-- aclcheck(loraserver_ns, #, 4) AUTHORIZED=N HAS_ERROR=Y => ERR_UNKNOWN
1548775762: |-- Cached [9ECD761A974D8483A44359325A743A0FDEB3E361] for (client id not available,loraserver_ns,4)
1548775764: |-- mosquitto_auth_unpwd_check(loraserver_ns)
1548775764: |-- ** checking backend files
1548775764: |-- getuser(loraserver_ns) AUTHENTICATED=1 by files
log entry.
Copy and pasting the config from the webpage my editor messed up the long acl line resulting in an error at runtime. As a result, it looks like all acl rules did not work, including those from “files” 
As almost always the problem was in front of the keyboard! 
1 Like
Great to see you found the error. Let me know if you need help with anything else.
This was a little too optimistic.
I can connect and subscribe now, but I’m not able to receive anything from any topic with logins from password file. With the admin account via postgres I can receive data.
1548780951: |-- mosquitto_auth_acl_check(…, client id not available, loraserver_gw, gateway/aa555a0000004321/stats, MOSQ_ACL_WRITE)
I’m not quite sure if “client id not available” from the log is a problem?
My acl file:
user loraserver_gw
topic write gateway/+/stats
topic write gateway/+/rx
topic read gateway/+/tx
topic write gateway/+/ack
topic read gateway/+/config
user loraserver_ns
topic read gateway/+/stats
topic write gateway/+/tx
topic read gateway/+/rx
topic read gateway/+/ack
topic write gateway/+/config
user loraserver_as
topic write application/+/device/+/rx
topic write application/+/device/+/join
topic write application/+/device/+/ack
topic write application/+/device/+/error
topic read application/+/device/+/tx
topic write application/+/device/+/status
topic write application/+/device/+/location
Passwords:
loraserver_gw:PBKDF2$sha256$AAA
loraserver_as:PBKDF2$sha256$BBB
loraserver_ns:PBKDF2$sha256$CCC
Nothing special I would say 
Then could you please address my previous questions?
What mosquitto version are you using?
1.5.5
How are you doing authentication/authorization?
I’m not sure what you mean; static logins from files for lora software components, user logins via postgres
Could you show us your auth configuration, static acls and password files (without sensible parts)?
allow_anonymous false
auth_plugin /usr/lib/mosquitto-auth-plugin/auth-plugin.so
auth_opt_backends files,postgres
auth_opt_password_file /etc/mosquitto/mosquitto-auth-plug/passwords
auth_opt_acl_file /etc/mosquitto/mosquitto-auth-plug/acls
auth_opt_host localhost
auth_opt_port 5432
auth_opt_dbname loraserver_as
auth_opt_user loraserver_as
auth_opt_pass MyPassword
auth_opt_userquery select password_hash from "user" where username = $1 and is_active = true limit 1
auth_opt_superquery select count(*) from "user" where username = $1 and is_admin = true
auth_opt_aclquery select distinct 'application/' || a.id || '/#' from "user" u inner join organization_user ou on ou.user_id = u.id inner join organization o on o.id = ou.organization_id inner join application a on a.organization_id = o.id where u.username = $1 and $2 = $2
Do static clients connect (i.e., authenticate correctly) but fail to subscribe only (i.e., authorization fails)?
Again not quite sure; there seems to be no problem with connect and in any case I am able to subscribe (no error log entry like before), but received messages are missing for file based logins (could be a write not read problem too)
I meant which plugin, it seems it’s GitHub - jpmens/mosquitto-auth-plug: Authentication plugin for Mosquitto with multiple back-ends (MySQL, Redis, CDB, SQLite3).
You could do some testing by creating a user with read and write privileges to any application, i.e. something like this:
user test
topic read application/#
topic write application/#
If that user is able to get messages, then you’ve probably messed some permissions on your acls; if not, it’d seem that the plugin isn’t working well with the static files.
You could also try giving some explicit (and different) client ids at the conf files of the bridge, loraserver and lora-app-server to see if it has any effect. I don’t think it will change anything, random client ids should be assign when none is given, but who knows, maybe mosquitto 1.5.5 version introduced some bug.
i can confirm Mosquitto 1.5.5 version introduced a bug!
When the plugin requests the “ACL check” the access flag previously was set to either 1 (read), 2 (write) or (1 | 2) (read/write) but in the new version for some reason it’s passing 4 on subscribe.
i’ve modified my be-files.c to switch 4 to 3 for testing and confirms it works. however to fix this properly would need another permission flag adding to the core.
if you want to try: inside be_files.c - function do_aclcheck() add if (access == 4) access = 3;
This is the first time i’ve ever used the auth plugin and i’ve not looked at the Mosquito code so i wonder if bit 2 is now ‘subscribe’ so it could just clear the bit (access &= ~4)
FYI: the access flag after the initial sub is normal. e.g. bit 0 and 1 set for read/write.