Greetings all!
I have two deployments of Kamailio: one running version 5.3 and one 5.5
with practically identical configurations, same (MySQL and REDIS) data
sources.
We have customers that we assign an ACL "group" to, where the ID of this
group resolves to records in the "address" table in our MySQL database -
using the "grp" field.
On the box running Kamailio 5.5, we have noticed that if a group has
ip_addr=0.0.0.0, mask=0, port=0 - and we try to run
the allow_source_address() - it will return false, thus failing this phase
of the authentication process.
However, on Kamailio 5.3 we are not seeing this issue, i.e. if a customer
is assigned a group where the ACL is 0.0.0.0/0 - it will let him through.
Has something changed that I'm not aware of?
Any suggestions on how to resolve this?
My best, Tom
Show replies by date
Hello Tom,
I’ve done a quick comparison of the main function and the called function. On a first view
it looked identically, but I looked only a few levels deep.
Do you have maybe some means to reproduce this on a test system? Then it would be probably
interesting to look to the DEBUG logging of this cases. Maybe you can compare if you spot
some obvious differences from the logic.
Cheers,
Henning
From: sr-users <sr-users-bounces(a)lists.kamailio.org> On Behalf Of Tom Dworakowski
Sent: Tuesday, September 14, 2021 4:10 AM
To: sr-users(a)lists.kamailio.org
Subject: [SR-Users] Empty Subnets in Permissions Module
Greetings all!
I have two deployments of Kamailio: one running version 5.3 and one 5.5 with practically
identical configurations, same (MySQL and REDIS) data sources.
We have customers that we assign an ACL "group" to, where the ID of this group
resolves to records in the "address" table in our MySQL database - using the
"grp" field.
On the box running Kamailio 5.5, we have noticed that if a group has ip_addr=0.0.0.0,
mask=0, port=0 - and we try to run the allow_source_address() - it will return false, thus
failing this phase of the authentication process.
However, on Kamailio 5.3 we are not seeing this issue, i.e. if a customer is assigned a
group where the ACL is 0.0.0.0/0<http://0.0.0.0/0> - it will let him through.
Has something changed that I'm not aware of?
Any suggestions on how to resolve this?
My best, Tom