[OpenSIPS-Users] HEPv3 siptrace to Homer v7 - "Trailing stray characters"

[solarmon]

Hi,

I had opened a GitHub for this issue:

https://github.com/OpenSIPS/opensips/issues/2146

(Sorry, I seem to have forgotten to put a title on it)

The opensips version is 2.4:

version: opensips 2.4.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 3a566f1
main.c compiled on 09:53:43 Mar 15 2019



Thank you.

On Mon, 22 Jun 2020, 18:19 Bogdan-Andrei Iancu, <bogdan at opensips.org> wrote:

> Hi,
>
> What is the exact OpenSIPS version you have (opensips -V) ?
>
> Regards,
>
> Bogdan-Andrei Iancu
>
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>
> On 6/18/20 12:13 PM, solarmon wrote:
>
> Hi,
>
> I'm trying to set up siptrace to send HEPv3 packets to a Homer 7 setup.
>
> Currently this is not working and it seems the HEPv3 packets coming from
> opensips is not being ingested for some reason. Using hepgen (
> https://github.com/sipcapture/hepgen.js) to generate test HEPv3 traffic
> on the same opensips nodes is successful.
>
> When comparing both he captured opensips and hepgen generated HEPv3
> packets I notice the following difference which might explain why the
> opensips HEPv3 packets are not being ingested.
>
> I'm using the HEP dissector plugin for Wireshark from:
>
> https://github.com/sipcapture/hep-wireshark
>
> The opensips HEPv3 packet is decoded as HEPv3 by the dissector plugin, but
> it gives a working about "Trailing stray characters" for the packet.
> Inspecting the packet further I see that there is indeed extra data at the
> end. For example, the for the HEPv3 packet for INVITE there is the
> following data:
>
> .....70110F001-0000FA9B-5EEA5D1C-0000000E at ip.address
>
> (IP address sanitised)
>
> This seems to be the same value as for the Call-ID header:
>
> Call-ID: 0110F001-0000FA9B-5EEA5D1C-0000000E at ip.address
>
> I have the following config, which I pulled together from various sources
> - so I'm not sure whether this is correct or causing this issue:
>
> ### HEP Capture
>
> #TCP Hep listener
> listen=hep_tcp:w.x.y.z:6060
> #UDP Hep listener
> listen=hep_udp:w.x.y.z:6060
>
> loadmodule "proto_hep.so"
> modparam("proto_hep", "hep_id",
> "[homer]a.b.c.d:9060;transport=tcp;version=3;")
>
> #loadmodule "tls_mgm.so"
> #loadmodule "proto_tls.so"
> #modparam("proto_tls", "trace_destination", "homer")
> #modparam("proto_tls", "trace_filter_route", "trans_tracer")
>
> loadmodule "siptrace.so"
> modparam("siptrace", "trace_on", 1)
> modparam("siptrace", "trace_id", "[traceid]uri=hep:homer")
>
> ###
>
> and I'm call sip_trace() withing the main route{} function (just for
> testing at the moment):
>
> sip_trace("traceid","M","sip");
>
> Why is opensips adding this extra data at the end of the HEPv3 packets and
> is this expected/normal?
>
> If not expected/normal how should I change the opensips config to resolve
> it.
>
> Thank you.
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200622/43babd7e/attachment.html>