Closed JoxBlizz closed 9 years ago
sorry Jaime, but can you please provide a little bit more information how you capture traffic ?
capture node, capture server, HEP version etc...
Hi Alexandr,
we're capturing traffic with captagent in it's last version (commit 9f4b04fe9ad1b6a0b158c55fbc2bdda39161d301)
Find attached the config file of captagent.
<?xml version="1.0"?>
<document type="captagent/xml">
<configuration name="core.conf" description="CORE Settings">
<settings>
<param name="debug" value="3"/>
<param name="daemon" value="true"/>
<param name="syslog" value="true"/>
<param name="pid_file" value="/var/run/captagent.pid"/>
<param name="path" value="/usr/local/lib/captagent/modules"/>
</settings>
</configuration>
<configuration name="modules.conf" description="Modules">
<modules>
<load module="core_hep"/>
<load module="proto_uni"/>
<load module="capt_cli"/>
</modules>
</configuration>
<!-- CORE MODULES -->
<configuration name="core_hep.conf" description="HEP Socket">
<settings>
<param name="version" value="2"/>
<param name="capture-host" value="XXXX"/>
<param name="capture-port" value="9060"/>
<param name="capture-proto" value="udp"/>
<param name="capture-id" value="4004"/>
<param name="capture-password" value="myHep"/>
<param name="payload-compression" value="false" />
</settings>
</configuration>
<!-- PROTOCOLS -->
<configuration name="proto_uni.conf" description="UNI Proto Basic capture">
<settings>
<param name="port" value="5060"/>
<param name="dev" value="any"/>
<param name="promisc" value="true"/>
<param name="sip-parse" value="true"/>
<param name="rtcp-tracking" value="true"/>
<param name="ip-proto" value="udp"/>
<param name="proto-type" value="sip"/>
<param name="filter" value="and not host XXXX"/>
</settings>
</configuration>
<!-- CLI -->
<configuration name="capt_cli.conf" description="CLI socket">
<settings>
<param name="cli-host" value="localhost"/>
<param name="cli-port" value="8909"/>
<param name="cli-password" value="12345"/>
</settings>
</configuration>
</document>
We're sniffinf the traffic sent by captagent directly, as we're developing a Python parser. We need to decode HEPv2, and we're using as reference [https://github.com/sipcapture/hep-erlang]
This is one of the captures:
02 10 02 11 13 c4 13 c4 86 d5 95 08 9a 35 81 74 8c c8 59 55 f2 c8 09 00 a4 0f 88 54 53 49 ...
We think that this reference is not entirely correct, but you could solve our doubts about this.
Thanks for your answer
can you please switch to HEPv3 ? version 2 is obsolete
On 19 May 2015 at 13:42, Jox4 notifications@github.com wrote:
I'm usiong HEPv2. One of the captures was this:
02 10 02 11 13 c4 13 c4 86 d5 95 08 9a 35 81 74 8c c8 59 55 f2 c8 09 00 a4 0f 88 54 53 49 ...
Thanks for your answer
— Reply to this email directly or view it on GitHub https://github.com/sipcapture/HEP/issues/1#issuecomment-103455682.
Hi Alexandr,
I'm Carlos, a Jaime co-worker. We will switch if we can, but one of our clients it's using HEPv2 in it's infrastructure and it's not going to switch due to legacy software (I don't have the details, it's a Kamailio OpenSER related issue).
We were asking for a HEPv2 specification, if it exists. I think we can go on, ignoring timestamps and undefined fields, but if we have all the information we can contribute with a better Python parser for HEP (v2 and v3).
Thanks for your time
/* FIRST BLOCK _/ struct hep_hdr{ u_int8_t hpv; / version _/ u_int8_t hpl; / length _/ u_int8_t hpf; / family _/ u_int8_t hpp; / protocol _/ u_int16_t hpsport; / source port _/ u_int16_t hpdport; / destination port */ };
/* SECOND BLOCK _/ struct hep_iphdr{ struct in_addr hp_src; struct in_addr hpdst; / source and dest address / }; / OR IPV6 as SECOND BLOCK _/ struct hep_ip6hdr { struct in6_addr hp6src; / source address _/ struct in6_addr hp6dst; / destination address */ };
/* THIRD BLOCK HEPv2 ONLY _/
struct hep_timehdr{
u_int32_t tvsec; / seconds _/
u_int32_t tvusec; / useconds _/
u_int16t captid; / Capture ID node */
};
/* PAYLOAD */
i hope it will be ok for you.
Thanks a lot.
In our first inspection, the captured packets doesn't seem to follow this spec. Anyway, if you say that v2 is obsolete, maybe there's no need to check captagent v2 implementation.
Thanks for your time
Thanks for your time and support.
Looking some packages i can see the lenght metadata don't matches with the real header size (Version and lenght fields included and payload excluded as says the protocol), timestamps and Capture ID of node fields keeps outs of this margin, being watched as a HEP.v1 header adding new fields with a constaint size that are excluded of the header lenght.
Too I can see that the timestamp don't match with actually dates, they are from ¡2044!
Please, resolve my boubts as soon as possible.
Thanks in advance
Jaime Olmedo Zazo