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