After removing the ha1b column, I am now getting the following errors and
authentication does not work:
Aug 12 20:51:59 live01 /usr/sbin/opensips[10064]:
ERROR:db_mysql:db_mysql_store_result: driver error: Commands out of sync; you
can't run this command now
Aug 12 20:51:59 live01 /usr/sbin/opensips[10064]: ERROR:auth_db:get_ha1: failed
to query database
Aug 12 20:52:00 live01 /usr/sbin/opensips[10057]:
ERROR:db_mysql:db_mysql_store_result: driver error: Commands out of sync; you
can't run this command now
Aug 12 20:52:00 live01 /usr/sbin/opensips[10057]: ERROR:auth_db:get_ha1: failed
to query database
auth_db module configuration:
modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "password_column", "ha1")
modparam("auth_db", "user_column", "username")
modparam("auth_db", "domain_column", "domain”)
What can be the reason for this?
Regards,
Adrian
> On 12 Aug 2021, at 13:04, Liviu Chircu <[email protected]> wrote:
>
> On 12.08.2021 18:36, Adrian Georgescu wrote:
>> The auth_db module has some dramatic changes which are either undocumented
>> or not backwards compatible and is unclear how to handle this.
>>
>> https://opensips.org/docs/modules/3.1.x/auth_db.html#param_password_column_2
>> <https://opensips.org/docs/modules/3.1.x/auth_db.html#param_password_column_2>Hi
>> Adrian,
>
> Indeed, with the addition of RFC 8760 support (support for SHA-256 and
> SHA-512-256 auth algorithms), me and Maksym Sobolyev decided to try and
> remove the "ha1b" feature, originally designed to accommodate some broken SIP
> UAs who cannot follow the basic SIP authentication spec. The feature had
> been in there since the very beginnings, and we were not sure if anyone is
> really benefiting from it anymore nowadays.
>
> A strong reason for removing "ha1b" was the sheer number of hashes to be
> stored per subscriber. Since we now have 3 algorithms (MD5, SHA-256,
> SHA-512-256), there are 3 hash-columns to store. With the "ha1b" feature,
> there would be 2 x 3 = 6 hashes in total to store, per user. So you can see
> where this is going: "Can we get away with dropping ha1b and storing half the
> data per user?" ... was the big question.
>
> Still, we agreed that if there is still enough traction for the "ha1b"
> feature from the community, we can easily re-add the ha1b logic and 3 more
> columns to the table and backport everything to 3.2. It's a trivial task,
> frankly.
>
> The big question is: on your platform(s), can you control the software in all
> SIP UAs that incorrectly include "realm" information in the "username" field
> (which should really be just the user's name!) and fix the problem on the
> phone side?
>
> PS: I noticed the 3.2 migration page is missing any info on ha1b. Will get
> it fixed soon, depending on the outcome of the discussion.
>
> Best Regards,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu <http://www.twitter.com/liviuchircu> |
> www.opensips-solutions.com <http://www.opensips-solutions.com/>
> OpenSIPS Summit 2021 Distributed | www.opensips.org/events
> <http://www.opensips.org/events>_______________________________________________
> Users mailing list
> [email protected]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
