10 Apr
2014
10 Apr
'14
10:08 a.m.
i have these two lines in config:
$var(common_name) = @tls.peer.subject.cn;
$var(common_name) = $sel(tls.peer.subject.cn);
the latter gives error at startup:
0(24214) ERROR: <core> [select.c:316]: resolve_select(): Unable to resolve select
'tls' at level 0
0(24214) ERROR: <core> [select.c:177]: w_parse_select(): parse_select: error while
resolve_select 'tls.peer.subject.cn'
0(24214) ERROR: pv [pv_select.c:45]: pv_parse_select_name(): invalid select name
[tls.peer.subject.cn]
0(24214) ERROR: <core> [pvapi.c:839]: pv_parse_spec2(): pvar "sel" has an
invalid name param [tls.peer.subject.cn]
0(24214) ERROR: <core> [pvapi.c:994]: pv_parse_spec2(): wrong char [)/41] in
[$sel(tls.peer.subject.cn)] at [24 (5)]
0(24214) : <core> [cfg.y:3408]: yyerror_at(): parse error in config file
/etc/sip-proxy/sip-proxy.cfg, line 874, column 29-53: Can't get from cache:
$sel(tls.peer.subject.cn)
ERROR: bad config file (1 errors)
based on pseudo variable wiki page, the syntax should be correct. what
is wrong with $sel(tls.peer.subject.cn)?
-- juha
10 Apr
10 Apr
10:17 a.m.
Hello,
the $sel(...) should work, I wonder if selects can add themselves
dynamically at runtime, so 'peer' is only when a tls connection is
established. Can you try with other selects pointing to own certificate,
iirc should be like: $sel(tls.my.subject.cn)?
Cheers,
Daniel
On 10/04/14 09:08, Juha Heinanen wrote:
i have these two lines in config:
$var(common_name) = @tls.peer.subject.cn;
$var(common_name) = $sel(tls.peer.subject.cn);
the latter gives error at startup:
0(24214) ERROR: <core> [select.c:316]: resolve_select(): Unable to resolve select
'tls' at level 0
0(24214) ERROR: <core> [select.c:177]: w_parse_select(): parse_select: error
while resolve_select 'tls.peer.subject.cn'
0(24214) ERROR: pv [pv_select.c:45]: pv_parse_select_name(): invalid select name
[tls.peer.subject.cn]
0(24214) ERROR: <core> [pvapi.c:839]: pv_parse_spec2(): pvar "sel" has
an invalid name param [tls.peer.subject.cn]
0(24214) ERROR: <core> [pvapi.c:994]: pv_parse_spec2(): wrong char [)/41] in
[$sel(tls.peer.subject.cn)] at [24 (5)]
0(24214) : <core> [cfg.y:3408]: yyerror_at(): parse error in config file
/etc/sip-proxy/sip-proxy.cfg, line 874, column 29-53: Can't get from cache:
$sel(tls.peer.subject.cn)
ERROR: bad config file (1 errors)
based on pseudo variable wiki page, the syntax should be correct. what
is wrong with $sel(tls.peer.subject.cn)?
-- juha
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
10:52 a.m.
Daniel-Constantin Mierla writes:
the $sel(...) should work, I wonder if selects can add
themselves
dynamically at runtime, so 'peer' is only when a tls connection is
established. Can you try with other selects pointing to own certificate,
iirc should be like: $sel(tls.my.subject.cn)?
i tried with these two in the config:
$var(cn) = @tls.me.subj.cn;
$var(cn) = $sel(tls.me.subj.cn);
the latter gave the same error:
0(25236) ERROR: <core> [select.c:316]: resolve_select(): Unable to resolve select
'tls' at level 0
0(25236) ERROR: <core> [select.c:177]: w_parse_select(): parse_select: error while
resolve_select 'tls.me.subj.cn'
0(25236) ERROR: pv [pv_select.c:45]: pv_parse_select_name(): invalid select name
[tls.me.subj.cn]
0(25236) ERROR: <core> [pvapi.c:839]: pv_parse_spec2(): pvar "sel" has an
invalid name param [tls.me.subj.cn]
0(25236) ERROR: <core> [pvapi.c:994]: pv_parse_spec2(): wrong char [)/41] in
[$sel(tls.me.subj.cn)] at [19 (5)]
0(25236) : <core> [cfg.y:3408]: yyerror_at(): parse error in config file
/etc/sip-proxy/sip-proxy.cfg, line 692, column 16-35: Can't get from cache:
$sel(tls.me.subj.cn)
ERROR: bad config file (1 errors)
so looks like there is some problem with $sel implementation.
-- juha
11:06 a.m.
It might be the way tls module exports the selects -- I see it does it
in modinit, which is executed after the config is parsed.
Can you move the line:
register_select_table(tls_sel);
from mod_init() to mod_register() in tls_mod.c and try again?
If all works ok with your tests, then you can commit.
Note that there should be direct pv alternative, as I could see in the
module, such as $tls_peer_subject_cn -- see tls_pv structure inside
tls_select.c file of the tls module. Not sure if they were documented
somewhere.
Cheers,
Daniel
On 10/04/14 09:52, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
the $sel(...) should work, I wonder if selects
can add themselves
dynamically at runtime, so 'peer' is only when a tls connection is
established. Can you try with other selects pointing to own certificate,
iirc should be like: $sel(tls.my.subject.cn)?
i tried with these two in the
config:
$var(cn) = @tls.me.subj.cn;
$var(cn) = $sel(tls.me.subj.cn);
the latter gave the same error:
0(25236) ERROR: <core> [select.c:316]: resolve_select(): Unable to resolve select
'tls' at level 0
0(25236) ERROR: <core> [select.c:177]: w_parse_select(): parse_select: error
while resolve_select 'tls.me.subj.cn'
0(25236) ERROR: pv [pv_select.c:45]: pv_parse_select_name(): invalid select name
[tls.me.subj.cn]
0(25236) ERROR: <core> [pvapi.c:839]: pv_parse_spec2(): pvar "sel" has
an invalid name param [tls.me.subj.cn]
0(25236) ERROR: <core> [pvapi.c:994]: pv_parse_spec2(): wrong char [)/41] in
[$sel(tls.me.subj.cn)] at [19 (5)]
0(25236) : <core> [cfg.y:3408]: yyerror_at(): parse error in config file
/etc/sip-proxy/sip-proxy.cfg, line 692, column 16-35: Can't get from cache:
$sel(tls.me.subj.cn)
ERROR: bad config file (1 errors)
so looks like there is some problem with $sel implementation.
-- juha
11:58 a.m.
Daniel-Constantin Mierla writes:
Note that there should be direct pv alternative, as I
could see in the
module, such as $tls_peer_subject_cn -- see tls_pv structure inside
tls_select.c file of the tls module. Not sure if they were documented
somewhere.
those seem to work without modifying tls module source. i tested like
this:
if (proto == TLS) {
xlog("L_INFO", "tls_my_subject_cn =
<$tls_my_subject_cn>\n");
xlog("L_INFO", "tls_peer_subject_cn =
<$tls_peer_subject_cn>\n");
};
and got:
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: INFO: REGISTER
<sip:test@test.tutpro.com> by <test(a)test.tutpro.com> from
<192.98.102.30> is authorized
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: INFO: tls_my_subject_cn =
<test.tutpro.com>
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: ERROR: tls [tls_select.c:152]:
get_cert(): Unable to retrieve TLS certificate from SSL structure
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: INFO: tls_peer_subject_cn =
<<null>>
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: ERROR: tls [tls_select.c:152]:
get_cert(): Unable to retrieve TLS certificate from SSL structure
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: ERROR: <core> [lvalue.c:416]:
lval_assign(): assignment failed at pos: (878,49-878,49)
i'm not sure yet, if this peer gave its certificate during the
handshake. if there is no peer certificate, ERROR level message seems
like an overkill. in my opinion it would suffice to return empty
value.
-- juha
1:18 p.m.
The parameters for functions are resolved at fixup time, which is done
after mod_init -- the config parser will see any function parameter as
just string, then later will run fixup for function parameters.
Probably the error message from tls_select.c:152 can be made dbg, the pv
value is ok, being null in this case.
Cheers,
Daniel
On 10/04/14 10:58, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Note that there should be direct pv alternative,
as I could see in the
module, such as $tls_peer_subject_cn -- see tls_pv structure inside
tls_select.c file of the tls module. Not sure if they were documented
somewhere.
those seem to work without modifying tls module source. i tested like
this:
if (proto == TLS) {
xlog("L_INFO", "tls_my_subject_cn =
<$tls_my_subject_cn>\n");
xlog("L_INFO", "tls_peer_subject_cn =
<$tls_peer_subject_cn>\n");
};
and got:
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: INFO: REGISTER
<sip:test@test.tutpro.com> by <test(a)test.tutpro.com> from
<192.98.102.30> is authorized
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: INFO: tls_my_subject_cn =
<test.tutpro.com>
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: ERROR: tls [tls_select.c:152]:
get_cert(): Unable to retrieve TLS certificate from SSL structure
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: INFO: tls_peer_subject_cn =
<<null>>
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: ERROR: tls [tls_select.c:152]:
get_cert(): Unable to retrieve TLS certificate from SSL structure
Apr 10 11:53:16 siika /usr/sbin/sip-proxy[11597]: ERROR: <core> [lvalue.c:416]:
lval_assign(): assignment failed at pos: (878,49-878,49)
i'm not sure yet, if this peer gave its certificate during the
handshake. if there is no peer certificate, ERROR level message seems
like an overkill. in my opinion it would suffice to return empty
value.
-- juha
3886
days inactive
3886
days old
5 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Juha Heinanen