Segmentation fault when specify a specific filter with Captagent 6.4.1

[tuan-pham-hoiio]

Segmentation fault when specify a specific filter with Captagent 6.4.1

[tuan-pham-hoiio]

Here is a 30-second-traffic pcap file:
test_traffic.tar.gz

Thank you so much for your support ^^.

[kYroL01]

I dont think the problem is the portrange to be honest, as the filter is only a simple BPF filter that works with BPF rules.
Let me quickly check and see what it could be.

Anyway if it's generate a corecump you can run coredumpctl debug and see where the captagent blobks.

[kYroL01]

Hi @tuan-pham-hoiio
I just tested version 6.4.1 with your specific BPF filter and I don't have any issues on running captagent.
It starts with no issue

[DEBUG] socket_pcap.c:1142 BPF Filter => Index: [0], Expression: [(portrange 5000-6000 and not host 192.168.1.123)], Reasm: [0]
[DEBUG] conf_function.c:456 find_export_record: found <msg_check> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <parse_sip> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <send_hep> in module transport_hep [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <clog> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <sip_has_sdp> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <check_rtcp_ipport> in module database_hash [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <clog> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] socket_pcap.c:1055 Setting device: any

[DEBUG] socket_pcap.c:1207 Index in proto_collect(): index: [0]
[DEBUG] socket_pcap.c:1263 Link offset interface type [113] [16]
[DEBUG] socket_pcap.c:1089 Activated device [any] at index [1]

[DEBUG] socket_pcap.c:1136 Filter for index [1]: [(portrange 8000-30000 and len >=64 ) and (ip and ip[6] & 0x2 = 0 and ip[6:2] & 0x1fff = 0 and udp and udp[8] & 0xc0 = 0x80 and udp[9] >= 0xc8 && udp[9] <= 0xcc)]
[DEBUG] socket_pcap.c:1142 BPF Filter => Index: [1], Expression: [(portrange 8000-30000 and len >=64 ) and (ip and ip[6] & 0x2 = 0 and ip[6:2] & 0x1fff = 0 and udp and udp[8] & 0xc0 = 0x80 and udp[9] >= 0xc8 && udp[9] <= 0xcc)], Reasm: [0]
[DEBUG] conf_function.c:456 find_export_record: found <msg_check> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <is_rtcp> in module protocol_rtcp [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <is_rtcp_exist> in module database_hash [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <parse_rtcp_to_json> in module protocol_rtcp [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <send_hep> in module transport_hep [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <clog> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <clog> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <clog> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] conf_function.c:456 find_export_record: found <clog> in module protocol_sip [/usr/local/captagent/lib/captagent/modules]
[DEBUG] captagent.c:359 The Captagent is ready
[DEBUG] socket_pcap.c:1207 Index in proto_collect(): index: [1]
[DEBUG] socket_pcap.c:1263 Link offset interface type [113] [16]

Unfortunately I cannot reproduce it.
In case of further information, please provide it, but this is not a global issue for captagent.

Thank you

[tuan-pham-hoiio]

Thanks for the investigation. Sorry for taking so long to generate the core dump file.
It threw out this in the file. Can you look through it? @kYroL01

#0  0x00007f1e72215ffc in callback_proto (arg=0x7f1e71327ee4 "", pkthdr=0x7f1e71327dc0, packet=0x7f1e7132a044 <error: Cannot access memory at address 0x7f1e7132a044>) at socket_pcap.c:555
555         ip_ver = ip4_pkt->ip_v;```

[btriller]

That occurs if listening on device any. Ethertype offset is different in SLL header than from ethernet header, so if last two bytes in SLL's link-layer address field [1] matches ethertype VLAN ipv4_pkt is not set, because type_ip is not set, hence this segfault.

captagent/src/modules/socket/pcap/socket_pcap.c

Lines 468 to 479 in 47f67cc

	memcpy(&ethaddr, (packet + 12), 2);
	memcpy(&mplsaddr, (packet + 16), 2);
	if (ntohs((uint16_t)*(&ethaddr)) == ETHERTYPE_VLAN) {
	if (ntohs((uint16_t)*(&mplsaddr)) == MPLS_UNI) {
	hdr_offset = 8;
	vlan = 1;
	} else {
	hdr_offset = 4;
	vlan = 2;
	}
	}

captagent/src/modules/socket/pcap/socket_pcap.c

Lines 504 to 507 in 47f67cc

	if(vlan == 0) {
	// IP TYPE = 0x86dd (IPv6) or 0x0800 (IPv4)
	type_ip = ntohs(sll->sll_protocol);
	}

captagent/src/modules/socket/pcap/socket_pcap.c

Lines 522 to 528 in 47f67cc

	else if(type_ip == ETHERTYPE_IP || type_ip == ETHERTYPE_VLAN) {
	ip4_pkt = (struct ip *)(packet + link_offset + hdr_offset + ipip_offset);
	} else {
	#if USE_IPv6
	ip6_pkt = (struct ip6_hdr*)(packet + link_offset + hdr_offset + ipip_offset);
	#endif
	}

[1] https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html

[tuan-pham-hoiio]

Thank you for your info @btriller. So basically, i can overcome this by setting the device part to specific interface?

[kYroL01]

Yes, that's always better than left any, that sometimes creates issues. When you can specify the networking interface, do it.

[tuan-pham-hoiio]

hi @kYroL01, I have already change dev to a specific interface, but the error is still being raised. Can you recommend where I could look next?

And seem like another user experiencing my bug #272.

[kYroL01]

Hi @tuan-pham-hoiio I cannot reproduce the issue, to be honest, so it could be something with this particular traffic..
Do u have a sample of this traffic so I will try to see it once I have time ?

IMHO the thing is that when you put port 5060 the traffic has no issue, but when you extend the port range, some bad non-SIP, or VLAN tag pkt create the problem.