Module: kamailio
Branch: master
Commit: 5fe9c7d5a82a12f0033785e3ee7fa2d35bc0f3df
URL: https://github.com/kamailio/kamailio/commit/5fe9c7d5a82a12f0033785e3ee7fa2d…
Author: Aleksandar Yosifov <alexyosifov(a)gmail.com>
Committer: Aleksandar Yosifov <alexyosifov(a)gmail.com>
Date: 2019-06-04T09:37:38+03:00
ims_ipsec_pcscf: IPv6 support
- Set authentication algorithm for SA depending of
parsed security-client info from REGISTER request msg.
For now, the supported algorithms are md5 and sha1,
the default algorithm is sha1.
- fill_contact() changes:
No significant changes, but added a debug message
and code is more readable.
- Added support for IPv6.
A new parameter IPSEC_LISTEN_ADDR6 is added in pcscf.cfg
file that describe IPv6 listen address.
A new module parameter ipsec_listen_addr6 is added in
kamailio.cfg to pass IPv6 listen address into the ipsec module.
- mode_init() changes:
Add ipv4 and/or ipv6 listen interfaces depending of configured
parameters in pcscf/kamailio config files.
- create_ipsec_tunnel() changes:
Update temp security parameters for contact.
Add 4 SAs and polisies (UE client->Proxy server, Proxy client->
UE server, Proxy server->UE client and UE server->Proxy client).
Server->client SAs are used for TCP connections.
- destroy_ipsec_tunnel() changes:
Remove all SAs and policies.
- ipsec_forward() changes:
Refactored to use both UDP and TCP protocols. Selects the protocol
type, sourse and destination ports based on message type.
- Removed unused method convert_ip_address(). Replaced by core methods
str2ipbuf() and str2ip6buf().
- changes in README
README regenerated via ims_ipsec_pscscf_admin.xml.
Added a new parameter for listen IPv6 address.
---
Modified: src/modules/ims_ipsec_pcscf/README
Modified: src/modules/ims_ipsec_pcscf/cmd.c
Modified: src/modules/ims_ipsec_pcscf/doc/ims_ipsec_pcscf_admin.xml
Modified: src/modules/ims_ipsec_pcscf/ims_ipsec_pcscf_mod.c
Modified: src/modules/ims_ipsec_pcscf/ipsec.c
Modified: src/modules/ims_ipsec_pcscf/ipsec.h
---
Diff: https://github.com/kamailio/kamailio/commit/5fe9c7d5a82a12f0033785e3ee7fa2d…
Patch: https://github.com/kamailio/kamailio/commit/5fe9c7d5a82a12f0033785e3ee7fa2d…
### Description
When using the Python3 extension for KEMI, `registrar.save` complains about an unknown location: `registrar [api.c:44]: regapi_save(): usrloc domain [location] not found`. Saving the user location works without problems in the core scripting language.
### Troubleshooting
#### Reproduction
Here is a fairly minimal Python3 script:
```python
import KSR as KSR
def mod_init():
KSR.info("===== from Python mod init\n")
return kamailio()
class kamailio:
def __init__(self):
KSR.info('===== kamailio.__init__\n')
def child_init(self, rank):
KSR.info('===== kamailio.child_init(%d)\n' % rank)
return 0
def ksr_request_route(self, msg):
KSR.hdr.remove('Route')
if KSR.is_method('INVITE'):
KSR.rr.record_route()
if not KSR.is_myself_ruri():
KSR.info(f'Relaying to foreign domain: to={msg.RURI} method={msg.Method}\n')
return self.relay(msg)
if KSR.is_method("REGISTER"):
return self.registration(msg)
KSR.registrar.lookup("location")
KSR.sl.send_reply(100, "Trying")
return self.relay(msg)
def ksr_reply_route(self, msg):
KSR.info(f'Received response: from={msg.src_address} status={msg.Status}\n')
return 1
def ksr_onsend_route(self, msg):
if msg.Type == 'SIP_REQUEST':
KSR.info(f'Sending request: to={msg.dst_address} method={msg.Method}\n')
return 1
def registration(self, msg):
if not KSR.registrar.save("location", 0x01):
KSR.sl.sl_reply_error()
return 1
def relay(self, msg):
if not KSR.tm.t_relay():
KSR.sl.sl_reply_error()
return 1
```
If this script is used for request routing, the user locations cannot be saved and the above mentioned error is logged.
#### Log Messages
`4(4360) ERROR: {1 15678 REGISTER 16c11b02-2458-4263-9350-c2f26fafee53} registrar [api.c:44]: regapi_save(): usrloc domain [location] not found`
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.2.3 (x86_64/linux) c36229
flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: c36229
compiled on 13:25:11 Jun 2 2019 with gcc 8.3.0
```
* **Operating System**:
```
Linux linux 5.1.5-gentoo #1 SMP PREEMPT Mon May 27 14:42:14 CEST 2019 x86_64 AMD A6-3670 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1972
### Description
We had Kamailio 5.1.4 with websocket module. Unfortunately, our clients don't support websocket keepalive mechanism at all, so I used TCP keepalive instead with the following parameters:
```
tcp_keepalive=yes
tcp_keepcnt=6
tcp_keepidle=60
tcp_keepintvl=10
```
and set up KEEPALIVE_MECHANISM_NONE:
`modparam("websocket", "keepalive_mechanism", 0)`
During load testing and debugging, when 8k clients sent registrations, it was found out that shared memory was not freed after closing connections (_ws_connection_list_t *wsconn_used_list_ variable in ws_conn.c ).
### Possible Solutions
I've decided to add new keepalive mechanism that periodically checks TCP connection related to websocket:
```
enum
{
KEEPALIVE_MECHANISM_NONE = 0,
KEEPALIVE_MECHANISM_PING = 1,
KEEPALIVE_MECHANISM_PONG = 2,
KEEPALIVE_MECHANISM_TCP_CONN_CHECK = 3
};
```
and added the line to config:
```
# Enable custom tcp-connection-health based keepalive mechanism (3)
# KEEPALIVE_MECHANISM_NONE = 0,
# KEEPALIVE_MECHANISM_PING = 1,
# KEEPALIVE_MECHANISM_PONG = 2
# KEEPALIVE_MECHANISM_TCP_CONN_CHECK = 3
modparam("websocket", "keepalive_mechanism", 3)
```
Also, I've implemented the mechanism in ws_keepalive function:
```
void ws_keepalive(unsigned int ticks, void *param)
{
int check_time =
(int)time(NULL) - cfg_get(websocket, ws_cfg, keepalive_timeout);
ws_connection_t **list = NULL, **list_head = NULL;
ws_connection_t *wsc = NULL;
/* get an array of pointer to all ws connection */
list_head = wsconn_get_list();
if(!list_head)
return;
list = list_head;
wsc = *list_head;
while(wsc && wsc->last_used < check_time) {
if (ws_keepalive_mechanism == KEEPALIVE_MECHANISM_TCP_CONN_CHECK) {
struct tcp_connection *con = tcpconn_get(wsc->id, 0, 0, 0, 0);
if(!con) {
LM_INFO("tcp connection has been lost\n");
wsc->state = WS_S_CLOSING;
}
}
if(wsc->state == WS_S_CLOSING || wsc->awaiting_pong) {
LM_INFO("forcibly closing connection\n");
wsconn_close_now(wsc);
} else {
int opcode = (ws_keepalive_mechanism == KEEPALIVE_MECHANISM_PING)
? OPCODE_PING
: OPCODE_PONG;
ping_pong(wsc, opcode);
}
wsc = *(++list);
}
wsconn_put_list(list_head);
}
```
and changed memory allocation method in wsconn_get_list and wsconn_put_list methods from pkg to shm, because, as it turned out during load testing, using pkg_malloc (the C malloc) in this functions may cousing fails under serious loads.
These modifications solved the problem. But about a week ago we've started switching to ver. 5.2.1 and found a lot of changes in the websocket module. So, I've added my changes in this commit https://github.com/korizza/kamailio/commit/b3e03d03574ff4ff076005bb8a01d746… . Please take a look.
### Additional Information
Adding ws_conn_put_id in this commit https://github.com/kamailio/kamailio/commit/a975bca1702ea2f3db47f834f7e4da2… did not solve problem with ref counter increasing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1892
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
A patch was pushed to master branch to enable use of trace_type in the ki_sip_trace_dst_cid_flag(), following the latest additions to the module. It seemed that the trace type was used only for kamailio.cfg functions, because inside ki_sip_trace_dst_cid_flag() the trace_type was parsed and stored in local variable, but it was not used further.
I open this issue for review, to be sure something was not overlooked, the commit is:
* e8d765610c6926cc6cb4dfa490595214a3680f97
@ionutionita92 - can you have a look and eventually do some tests to be sure it still works as expected for kamailio.cfg functions?
There is one more aspect to clarify. The trace info structure is alocated in shared memory, but some of its fields (duplicate uri and correlation id) were set to addresses of function parameters/local variables. The code was relocated and now is at the following lines:
* https://github.com/kamailio/kamailio/blob/master/src/modules/siptrace/siptr…
Is it safe to do it like this? Are the fields used in this case only in current process and the callbacks use the variant stored in AVP?
Speaking of serializing to a string stored in AVP, it might be better to just have a structure compacted with all content in shared memory and stored in an XAVP -- the xavp can store a pointer and also have in its structure the callback to free the pointer.
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
Git Master Branch
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
(paste your output here)
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1955
Hello,
several days ago I split the app_lua module, relocating the code related
to old Lua sr library to app_lua_sr module, keeping in this way app_lua
smaller and focused to the KEMI code. Over the time, app_lua_sr should
be deprecated and removed, as we are sure the functions in Lua sr have
an equivalent in Lua KSR.
Therefore, if you are using in Lua scripts functions from 'sr' library,
consider migrating to KSR as soon as possible. The intermediary solution
for a quick upgrade to master version (to be release as v5.3.x) is to
load app_lua_sr and update some modparams, like:
loadmodule "app_lua.so"
loadmodule "app_lua_sr.so"
modparam("app_lua_sr", "register", "sl")
If you find a function from Lua sr not available in Lua KSR, then report
it via mailing lists or bug tracker.
An article about this topic was published at:
* https://www.kamailio.org/w/2019/05/new-module-app_lua_sr/
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda