sipcapture / HEP

HEP-EEP: Extensible Encapsulation Protocol (Specs & Technical Docs)
http://sipcapture.org
46 stars 8 forks source link

Problems with Header's lenght and timesptamp in HEPv.2 #1

Closed JoxBlizz closed 9 years ago

JoxBlizz commented 9 years ago

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

adubovikov commented 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...

JoxBlizz commented 9 years ago

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

adubovikov commented 9 years ago

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.

cgarciaarano commented 9 years ago

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

adubovikov commented 9 years ago

hepv2

/* 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 */

adubovikov commented 9 years ago

i hope it will be ok for you.

cgarciaarano commented 9 years ago

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

JoxBlizz commented 9 years ago

Thanks for your time and support.