[Home]

Summary:ASTERISK-12846: insecure doesn't work
Reporter:pj (pj)Labels:
Date Opened:2008-10-07 16:54:26Date Closed:2009-02-12 14:40:09.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 13644_trunk.patch
( 1) 13644_trunkv2.patch
( 2) sip-debug.txt
Description:I have sip peer (callmanager4), that doesn't support authetication, so I have insecure=port,invite in sip.conf
When I call to asterisk from callmanager peer, from phone, that has linenumber same, that exist as sip peer entry on asterisk, asterisk then try to authenticate callmanager peer and call then fail.
Asterisk 1.6.0 branch (and 1.4 branch) is working fine,
Asterisk 1.6.1 branch and above (trunk) fail.


****** ADDITIONAL INFORMATION ******

callmanager sip.conf entry
[ccm-gw]
type=peer
host=192.168.200.3
port=5061
insecure=port,invite
nat=never
disallow=all
allow=alaw
canreinvite=no
qualify=yes
context=from-ccm

normal peer entry:
[688]
secret=*****
callerid="test" <688>
type=peer
host=dynamic
qualify=6000
qualifyfreq=20
nat=yes
canreinvite=no
disallow=all
allow=g729,gsm,ilbc
callcounter=yes
busylevel=1
allowsubscribe=yes
subscribecontext=linestates
context=zamestnanci

in sip.conf [general] I have also:
match_auth_username=yes
Comments:By: Mark Michelson (mmichelson) 2008-10-09 19:38:46

I set up a similar peer on an Asterisk trunk installation, and Asterisk did not send a 401 in response to the INVITE the phone sent. The only difference between the peer I used and the one that you have defined is that I do not have the "port=5061" line.

I don't see any significant difference between 1.6.0 and 1.6.1 with regards to this section of code. I'm not sure what could be causing this problem for you.
By: pj (pj) 2008-10-10 02:29:06

during off-hours, I will try to reconfigure callmanager to use udp port 5060 instead of 5061 and then give feedback, what happened.
but, keep in mind, that main reason, why call setup fail, is, that I try to call from callmanager phone, that has _same_ linenumber that exist in sip.conf.
from above example: I have peer 688 defined in sip.conf, when I try to call arbitrary destination from callmanager phone [ccm-gw] that have line 688 it fail, because asterisk ignores 'insecure' and require authentication. If I remove [688] entry from sip.conf, call will be successfull. Or if I leave [688] in sip.conf and try to call arbitrary number from callmanager phone, that have _different_ linenumber from 688, call is also successfull, because asterisk doesn't require to authenticate my callmanager peer, that's correct because of 'insecure' set.


By: Mark Michelson (mmichelson) 2008-10-10 09:19:25

If you still have the issue, I think it would be helpful to see a console trace with verbosity and debug set high and sip debug turned on. That may help to pinpoint where the issue is.
By: pj (pj) 2008-10-10 13:53:14

sip debug is attached to this tiket,
difference between (working) asterisk 1.6.0 or 1.4 is, that asterisk doesn't found calling peer number (688) in users list
[Oct 10 20:43:57] No user '688' in SIP users list
[Oct 10 20:43:57] Found peer 'ccm-gw' for '688' from 192.168.200.3:5061

in 1.6.1 and trunk, asterisk _found_ 688 and trying to authenticate, this is incorrect because I have insecure=port,invite on callmanager peer
[Oct 10 20:40:04] Found peer '688' for '688' from 192.168.200.3:5061

setting port udp/5060 instead of udp/5061 for callmanager peer doesn't have any effect


By: Mark Michelson (mmichelson) 2008-10-10 14:07:36

Okay, then I suspect this has to do with the removal of the sip_user structure from chan_sip.c

I'll research this a bit more and get back to you. Thanks for the information!
By: pj (pj) 2008-10-10 14:14:28

I found, that this issue is caused by commit "KILL THE USER!"
asterisk-1.6.1-r128241 OK
asterisk-1.6.1-r128254 FAIL
By: Mark Michelson (mmichelson) 2008-10-10 14:29:21

Your message about how the peer was found gave me a good idea about what may be going wrong. There  was a subtle logic change introduced with the "KILL THE USER" commit. I have reversed this change in the attached patch, 13644_trunk.patch. The patch was created against current Asterisk trunk, but when I tried applying it to 1.6.1, it applied cleanly there as well.

Please give this a try. Thanks!
By: pj (pj) 2008-10-10 15:01:17

applied cleanly to latest trunk, but fails to compile

  [CC] chan_sip.c -> chan_sip.o
chan_sip.c: In function ‘check_peer_ok’:
chan_sip.c:12000: error: too few arguments to function ‘find_peer’
chan_sip.c:12000: error: too few arguments to function ‘find_peer’
make[1]: *** [chan_sip.o] Error 1
make: *** [channels] Error 2
By: Mark Michelson (mmichelson) 2008-10-10 15:19:30

Sorry about that. I copied and pasted from 1.6.0 and didn't realize that the find_peer function had an extra argument. I have uploaded a new patch.
By: pj (pj) 2008-10-10 15:45:52

It's now working! if you think, that your patch can't broke other things, it can be commited, thanks! :-)
patch tested with Asterisk SVN-trunk-r148329


By: Mark Michelson (mmichelson) 2008-10-10 16:09:35

Great, I'll commit this then! Thank you for testing.
By: Digium Subversion (svnbot) 2008-10-10 16:11:17

Repository: asterisk
Revision: 148376

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r148376 | mmichelson | 2008-10-10 16:11:17 -0500 (Fri, 10 Oct 2008) | 13 lines

The logic used when checking a peer got changed subtly
in the "kill the user" commit and caused calls relying
on the insecure setting to not work properly. I changed
for finding a peer back to how it was prior to that
commit.

(closes issue ASTERISK-12846)
Reported by: pj
Patches:
     13644_trunkv2.patch uploaded by putnopvut (license 60)
Tested by: pj


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=148376
By: pj (pj) 2008-10-15 15:59:02

I must reopen this issue, I haven't tested change thoroughly and now, I found that change in commit 148376 causes, that successfully registered peer isn't matched correctly in asterisk.
It's weird, that issue doesn't appears after peer first registering with asterisk, but if peer unregisters and then registers again from _different_ udp source port, it causes wrong peer matching in asterisk.
Only way, how to restore correct matching for this peer is restarting asterisk, it will work again until peer is reregistered from different port.
Maybe asterisk doesn't free memory structures correctly and trying to match peer according to firstly used source port?
asterisk databaze is updated correctly (according to 'database show')

sip debug when peer is matched correctly (look at source port 10864):

[Oct 15 22:44:13] Sending to 193.85.164.154 : 10864 (NAT)
[Oct 15 22:44:13] Using INVITE request as basis request - FO8t2cYYoIdpHRCdB7HbpW6kWQisXp
[Oct 15 22:44:13] Found peer '324' for '324' from 193.85.164.154:10864


when peer is registered from different source port asterisk doesn't match this peer:

[Oct 15 22:36:05] Sending to 193.85.164.154 : 10846 (NAT)
[Oct 15 22:36:05] Using INVITE request as basis request - zCVgmV3noIegfOJzUgjAngqhh0r9Wc
[Oct 15 22:36:05] No matching peer for '324' from '193.85.164.154:10846'


 Status       : OK (481 ms)
 Useragent    : Nokia RM-49 3.0633.09.04
 Reg. Contact : sip:324@193.85.164.154:10846;transport=UDP


By: Mark Michelson (mmichelson) 2008-10-15 16:07:12

Did Asterisk behave properly prior to the "kill the user" commit that caused the first issue you reported?
By: pj (pj) 2008-10-15 16:17:38

peer matching issue, about what I wrote in this bugreport in msg 0093766, was caused by commit r148376, because Asterisk SVN-trunk-r148373 matches peers fine.
but "insecure" doesn't work from time when "KILL THE USER!" was commited, look at my msg (0093498) in this bugreport.
By: pj (pj) 2008-10-29 16:26:07

please revert commit 148376 from trunk, it seems, that this patch caused more serious issues than it fixed.
I checked current svn trunk r152643 and have issues, that asterisk doesn't require authentication for invite at all! Call is then always placed from context specified in sip.conf [general] section and not from peer specific context.
If you think, that my issue isn't caused by this commit, please tell me, if I should open separate bugreport, but it's needed to be solved, because chan_sip from current svn trunk is now seriously broken.
By: Mark Michelson (mmichelson) 2008-10-29 16:48:57

It should be easy to test if that commit is what is causing the issue for you. From your trunk source directory, issue the following command.

#svn diff -c -148376 | patch -p0

That will revert the commit you are talking about and you can see if the same issue still exists. I have done a quick check, and there are no conflicts when attempting to execute the above command.
By: pj (pj) 2008-10-30 06:35:28

it failed to revert commit 148376 from current trunk, it starts failing after commit 152020, maybe right this commit (152020) is source of peer matching issues...

[root@ipbx asterisk152777]# svn diff -c -148376 | patch -p0
patching file channels/chan_sip.c
Hunk #1 FAILED at 11997.
1 out of 1 hunk FAILED -- saving rejects to file channels/chan_sip.c.rej
By: Mark Michelson (mmichelson) 2008-12-18 13:15:25.000-0600

There have been several changes to trunk to help in fixing the matching issues that occurred because of the "kill the user" merge. Could you try upgrading and see if your problem has been fixed? Thanks.
By: Leif Madsen (lmadsen) 2009-01-13 16:13:35.000-0600

Pinging the reporter again to see if he can confirm or deny resolution in trunk.
By: pj (pj) 2009-01-14 10:07:00.000-0600

I don't forgot to this, let me some time, I will reply asap. thx
By: pj (pj) 2009-01-28 13:14:16.000-0600

currently, I can't test last asterisk revision until bug ASTERISK-1418336 will be resolved, so please be patient. thanks
By: pj (pj) 2009-02-12 14:37:40.000-0600

I could finally test 1.6.1 branch, because bug ASTERISK-1418336 is resolved now.
Tested Asterisk SVN-branch-1.6.1-r175257 and it seems, that issues from this bugreport are resolved. thanks!
By: Joshua C. Colp (jcolp) 2009-02-12 14:40:08.000-0600

Closed per reporter, it has already been fixed.