Missing some parts of SIP header and the entire SDP in HEP ​​message

[matuskaacc]

I'm noticing that when the SIP message collected for the captagent is a little larger, is missing out part of the header and the entire SDP body in the HEP message sent to the heplify-server. Does anyone know if there is any configuration in the captagent that could cause this behavior?

I have enabled the reasm parameter in socket_pcap.xml file but didn't work. The captagent stops to send the Invite message to heplify-server

            <param name="dev" value="enp129s0f0"/>
            <param name="promisc" value="true"/>
            <param name="reasm" value="true"/>
            <param name="websocket-detection" value="false"/>
            <param name="tcpdefrag" value="false"/>
            <param name="erspan" value="false"/>
            <!-- <param name="capture-filter" value="ip_to_ip"/> -->
            <param name="capture-plan" value="sip_capture_plan.cfg"/>
            <param name="filter">
                <value>portrange 5060-5091</value>
            </param>
        </settings>
    </profile>

[lmangani]

The issue is indeed packet fragmentation. The reasm parameter only affects UDP packets, while for TCP you need to also enable tcpdefrag. If none works, I would suggest attempting the same with heplify to determine if this is a bug or some other issue.

[matuskaacc]

Thank you for your quick response. I noticed in source SIP signaling that isn’t receiving some of fragmented packets. In Wireshark it’s just cames one packet of this Invite message with fragment-offset = 1480. I am not seeing the packet with fragment-offset=0. I will open a ticket with the switch supplier to understand this behavior in the mirror process.

[kYroL01]

Most likely you're not receiving the last fragment, the one with fragment-offset = 0, but only the first one (fragment-offset = 1480).

Thank you

[matuskaacc]

After checking more carefully, wireshark did not show off-set because it had the default reasemble configuration. When I disabled this option I was able to check the part of the fragment with off-set=0. So what could be causing this Invite message to not be sent to these fragmented UDP packets received even with the reasm parameter enabled?

[kYroL01]

It's very hard to say. reasm = true should do the trick.
I will retest my lab and see if I discover something.

[kYroL01]

@matuskaacc I just tested and for me it works fine. I import a fragmented INVITE and I see it reassembled.
Just to test, can you please try to remove the value inside filter and try it again ?
Thank you

[matuskaacc]

Thank you. Could you show here how your socket_pcap file that you tested was configured?

[kYroL01]

<profile name="socketspcap_sip" description="HEP Socket" enable="true" serial="2014010402">
	    <settings>
		<param name="dev" value="eth0"/>
		<param name="promisc" value="true"/>
		<param name="reasm" value="true"/>
		<param name="websocket-detection" value="false"/>
		<param name="tcpdefrag" value="false"/>
		<param name="erspan" value="false"/>
	        <!-- <param name="capture-filter" value="ip_to_ip"/> -->
		<param name="capture-plan" value="sip_capture_plan.cfg"/>
		<param name="filter">
		    <value>port 5060</value>
		</param>
	    </settings>
	</profile>

Have you already tried to remove the BPF filter and retest ?
Remove the filter part and give it another shot.

[matuskaacc]

How could i remove all BPF?
I have tried edit with this config:

but its ocurring this error:

[kYroL01]

Just remove these lines

                <param name="filter">
		    <value>port 5060</value>
		</param>

[matuskaacc]

Its ocurring this error removing BBF filter

[kYroL01]

Yes because we're ingesting all the traffic with no filter, so some bad packets also arrive and create issues.
Anyway, if you have the correct IPV4 SIP fragments it should work, is still unclear why it does not.
Does this traffic have anything particular that you can spot ? I'm also happy to take a look.

[matuskaacc]

sip_invite_fragments_not_reassembling.zip
This is the pcap with the two packets parts of UDP SIP Invite fragmented that isn't working the reassembling. thank you.

[kYroL01]

I see this traffic has VLAN layer. Have you tried to use this filter in socket_pcap.xml ?

<param name="filter">
         <value>vlan and port 5060</value>
</param>

[matuskaacc]

I tried this sugestion with vlan and port in filter configuration but didn't work. Heplify is working nice
./heplify -i enp129s0f0 -pr 5060-5500 -hs 127.0.0.1:9060 -sipassembly true -dim OPTIONS,NOTIFY

[kYroL01]

Ah, wait wait, now it makes sense: you're using -sipssembly which reassemble the out of order SIP at application level, not transport level, which is not implemented in Captagent.

BTW this does not reflects the pcap you shared, that it must be reassembled with no issue on Captagent.

Just to try, could you please remove the -sipassembly from the heplify command and see if it's still working fine or not ?

Thank you

[matuskaacc]

When i remove the -sipassembly works nice also.Then the parameter -sipassembly doesn't make diference to heplify processing complete Invite. Have you tested with my pcap file if captagent is processing all Invite with SDP?

[matuskaacc]

The fragmentation problem was resolved with this configuration/filter in the socket_pcap.xml file:
root@SPOCEN-HOMER-AGENT1:/usr/local/captagent/etc/captagent# cat socket_pcap.xml

< param name="capture-plan" value="sip_capture_plan.cfg"/> portrange 5060-5500 or ip

[kYroL01]

Thanks @matuskaacc this means you have VLAN and non-VLAN traffic to be processed in the same time.
Thank you for sharing this.