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:
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
--
Daniel-Constantin Mierla -
http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda