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

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:

...

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@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