Hi all
I've been playing with the pipelimit module, and found several problems
with the pl_set_pipe command. See the details below:
VERSION 3.3.4
1.- If the command is sent with a wrong number of arguments kamailio
crashes. For instance:
kamctl fifo pl_set_pipe global RED (note the absence of the last argument)
Core was generated by `./kamailio -f
/usr/local/kamailio/etc/kamailio/kamailio.cfg -E -dddd -w /var/ru'.
Program terminated with signal 11, Segmentation fault.
#0 mi_set_pipe (cmd_tree=<value optimized out>, param=<value optimized
out>) at pl_ht.c:554
554 if ( !node->value.s || !node->value.len ||
strno2int(&node->value,&limit)<0)
(gdb) bt
#0 mi_set_pipe (cmd_tree=<value optimized out>, param=<value optimized
out>) at pl_ht.c:554
#1 0x00007f8b7cd00c72 in run_mi_cmd (fifo_stream=0x2843870) at
../../lib/kmi/mi.h:77
#2 mi_fifo_server (fifo_stream=0x2843870) at fifo_fnc.c:509
#3 0x00007f8b7cd02b10 in fifo_process (rank=<value optimized out>) at
mi_fifo.c:247
#4 0x00007f8b7cd02eaf in mi_child_init (rank=0) at mi_fifo.c:211
#5 0x00000000004e23c9 in init_mod_child (m=0x7f8b7cf18d78, rank=0) at
sr_module.c:893
#6 0x00000000004e233c in init_mod_child (m=0x7f8b7cf18f50, rank=0) at
sr_module.c:890
#7 0x00000000004e233c in init_mod_child (m=0x7f8b7cf19100, rank=0) at
sr_module.c:890
#8 0x00000000004e233c in init_mod_child (m=0x7f8b7cf19750, rank=0) at
sr_module.c:890
#9 0x00000000004e233c in init_mod_child (m=0x7f8b7cf1ac08, rank=0) at
sr_module.c:890
#10 0x00000000004e233c in init_mod_child (m=0x7f8b7cf1b230, rank=0) at
sr_module.c:890
#11 0x00000000004e233c in init_mod_child (m=0x7f8b7cf1b5a0, rank=0) at
sr_module.c:890
#12 0x00000000004e233c in init_mod_child (m=0x7f8b7cf1bb48, rank=0) at
sr_module.c:890
#13 0x00000000004e233c in init_mod_child (m=0x7f8b7cf1ecf0, rank=0) at
sr_module.c:890
#14 0x00000000004e233c in init_mod_child (m=0x7f8b7cf1f140, rank=0) at
sr_module.c:890
#15 0x00000000004e233c in init_mod_child (m=0x7f8b7cf1f3e8, rank=0) at
sr_module.c:890
#16 0x00000000004e233c in init_mod_child (m=0x7f8b7cf1fe68, rank=0) at
sr_module.c:890
#17 0x00000000004e233c in init_mod_child (m=0x7f8b7cf20130, rank=0) at
sr_module.c:890
#18 0x00000000004e233c in init_mod_child (m=0x7f8b7cf20430, rank=0) at
sr_module.c:890
#19 0x00000000004e233c in init_mod_child (m=0x7f8b7cf20b68, rank=0) at
sr_module.c:890
#20 0x00000000004e233c in init_mod_child (m=0x7f8b7cf20fa0, rank=0) at
sr_module.c:890
#21 0x00000000004e233c in init_mod_child (m=0x7f8b7cf211f8, rank=0) at
sr_module.c:890
#22 0x00000000004e233c in init_mod_child (m=0x7f8b7cf215d8, rank=0) at
sr_module.c:890
#23 0x00000000004e233c in init_mod_child (m=0x7f8b7cf21940, rank=0) at
sr_module.c:890
#24 0x00000000004e233c in init_mod_child (m=0x7f8b7cf21fb8, rank=0) at
sr_module.c:890
#25 0x00000000004e233c in init_mod_child (m=0x7f8b7cf222b8, rank=0) at
sr_module.c:890
#26 0x00000000004e233c in init_mod_child (m=0x7f8b7cf22500, rank=0) at
sr_module.c:890
#27 0x00000000004e233c in init_mod_child (m=0x7f8b7cf226e8, rank=0) at
sr_module.c:890
#28 0x00000000004e233c in init_mod_child (m=0x7f8b7cf22bf8, rank=0) at
sr_module.c:890
#29 0x00000000004e233c in init_mod_child (m=0x7f8b7cf230e8, rank=0) at
sr_module.c:890
#30 0x00000000004e233c in init_mod_child (m=0x7f8b7cf236e0, rank=0) at
sr_module.c:890
#31 0x00000000004e233c in init_mod_child (m=0x7f8b7cf23bd8, rank=0) at
sr_module.c:890
#32 0x0000000000465db5 in main_loop () at main.c:1710
#33 0x0000000000467de6 in main (argc=0, argv=0xe) at main.c:2546
2.- If the number of arguments is correct kamailio gets blocked, from
that point on, no other request is processed:
1(23742) DEBUG: mi_fifo [mi_parser.c:84]: end of fifo input tree
DEBUG: mi_fifo [fifo_fnc.c:507]: done parsing the mi tree
DEBUG: pipelimit [pl_ht.c:557]: set_pipe: global:1:30
Nothing happens after this message, kamailio blocks and no further
request is processed.
VERSION 4.0
1.- Same as in 3.3.4
2.- Same as in 3.3.4
3.- Using RPC commands. Kamalio correctly complains about the incorrect
number of arguments, but still blocks when setting up new params in a pipe.
3.1 /kamcmd pl.set_pipe s:106433 RED
error: 400 - error at parameter 2: expected integer type but end of
packet encountered
3.2 kamcmd pl.set_pipe s:106433 RED 50 => kamailio blocks
Regards
Javi
[Apologies if this made it to the list last week; I got trapped in the return-email-address-doesnt-match moderation penalty box, and can't tell whether or not this was posted.]
There's a mismatch in the logic between the way that authentication headers are parsed (and stuffed in ->authorized) and the logic in consume_credentials.
In pre_auth (api.c), any ACK, CANCEL or PRACK bypasses the header parsing and setting of the ->authorized struct member:
if (msg->REQ_METHOD & (METHOD_ACK|METHOD_CANCEL|METHOD_PRACK))
return AUTHENTICATED;
but then in consume_credentials (auth_mod.c), an error is emitted if it's a PRACK:
[auth_mod.c:370]: auth:consume_credentials: No authorized credentials found (error in scripts)
which is because the error is explicitly suppressed for ACK or CANCEL, but not PRACK:
if (msg->REQ_METHOD != METHOD_ACK
&& msg->REQ_METHOD != METHOD_CANCEL) {
LOG(...)
auth_mod should be amended.
Also, since ACK, CANCEL and PRACK can never have these headers, the function should be probably skip calling get_authorized_cred multiple times for those types of messages:
int consume_credentials(struct sip_msg* msg)
{
struct hdr_field* h;
int len;
// Credentials aren't parsed for ACK/CANCEL/PRACK, so ignore those types
// and return that no processing has occurred.
if (msg->REQ_METHOD & (METHOD_ACK|METHOD_CANCEL|METHOD_PRACK))
return -1;
get_authorized_cred(msg->authorization, &h);
if (!h) {
get_authorized_cred(msg->proxy_auth, &h);
if (!h) {
LOG(L_ERR, "auth:consume_credentials: No authorized "
"credentials found (error in scripts)\n");
}
return -1;
}
}
len = h->len;
if (del_lump(msg, h->name.s - msg->buf, len, 0) == 0) {
LOG(L_ERR, "auth:consume_credentials: Can't remove credentials\n");
return -1;
}
return 1;
}
Hope that's useful to someone. It would remove tens of thousands of error messages in our daily logs and avoid the hack we're staging in our proxy configuration, specifically for PRACKs, just to get rid of those messages. :)
-- Jorj