Recently added extension/user fails to login

I’ve had a bunch of extensions and multiple different phones and SIP clients able to login fine but recently I added extension 55 with username 55 and this user cannot login (REGISTER fails with 401 Unauthorized). I’ve tried two different SIP softphones and the password is correct. These same softphones can register with another extension/user.

It’s as if there is something else blocking this new extension/user to login.

This is FreePBX 17.0.21

401 Unauthorised is not a failure; it is a normal part of the registration process (and also the call initiation process). Also note that registration isn’t a log in; a phone can initiate calls without being registered. Registration tells the registrar where to send calls.

If the phone abandons the registration when it receives 401, it means it either doesn’t support the authentication method requested (unlikely), or there is no authentication information configured in the phone.

Your reply isn’t helpful. No need to argue about what 401 means.

I can clearly see from the logs:

  • Phone sends REGISTER
  • Freepbx responds with 401 Unauthorized (challenge)
  • Phone sends another REGISTER with Authorization response
  • Freepx response with another 401 Unauthorized
    • And logs “Failed to authenticate”

It now seems whenever I either add a new extension/user or change password, authentication with that password no longer works.

If you get 401 for the second one, that could be that the phone was not recognized as one known to the PABX (to try and hide the fact that it wasn’t known); that the nonce had expired between the challenge and the response, or that some of the information in the response didn’t match the challenge. I would have expected 403, not 401, but I think I’ve seen suggestions that chan_pjsip sends 401.

Your question was not helpful in that it didn’t provide logs or even say that the phone tried to authenticate. In this case the full contents of the INVITEs and 401s are needed, and you should also look for any reason given for re-challenging.

1 Like

What do you mean “reason for re-challenging”? The challenge-response communication I explained in my previous message is the standard Digest authentication method. The first 401 is normal, the second 401 can be caused by incorrect password, for example. But my password is correct. I’ve even calculated the messages hashes myself to be sure.

What other reasons can there be for the authentication to fail if the challenge response is valid (password is correct)?

chan_sip would certainly explain why it was re-challenging. I’m not so sure what chan_pjsip does, but I would hope, at some debug, level, it would explain why it didn’t like the response.

Do you have any pjsip trunks between pbx systems. I have had this happen when my trunks between systems just messed up, I was trying to get device states working and I screwed them up because I was figuring out the custom.conf files. I had to delete them and then recreate them. Then the phones registered, but would not dial any extensions or any call of any type, even voicemail. I would just say “call failed”. I did a fwconsole reload to rebuild the from-internal context that my pjsip trunks between systems used and then it started working correctly and making calls.

I have made a detailed test.

I started with a working extension/user that I’ve created about one year earlier: the extension is 641 and password is 64112345. I can connect to FreePBX with this account using MicroSIP on Windows.

I can also confirm from Asterisk database that the bcrypt hash is

$2a$08$XK3PuUCEDsPJCGojONivFuD.ct2snM6q7sWgbuXu577W83BJI.e.K

This can be tested here and it matches the password “64112345”: https://bcrypt-generator.com/

Now I change the password to 66612345 (Admin → User management → Set password). I can see that the password hash changes to which is correct:

$2a$08$7GbFuPqw0HDiKTFSDZKSv.DX3mFq2Yr1eNwRjHsgMeaAdKH6vpRse

Now with the updated password, MicroSIP fails to connect and reports “Incorrect password”.

Next I change the password back to 64112345. The hash is:

$2a$08$4L/imW5.ki3SGXgxt2ZdXOIZclnNSz1CJp9XuGnoJ2jh0b9q6V6ui

…and now it works again in MicroSIP.

It’s as if the password change is not reflected to what PJSIP expects. Does it have the password saves in multiple places? What is going on?

Ok I figured it out. I was confused about the difference between user password and SIP extension secret (password).

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.