19 Jan
2017
19 Jan
'17
2:43 a.m.
Yes, this is a sipcapture node. I'm listening on a switch port that is
set to mirror my VoIP traffic. I see all SIP UDP/TCP packets on the
mirror port and the Ethernet port of the host node. Just don't see any
TCP packets process in kamailio, debug 3. UDP packets are processed as
expected.
My config is using port mirror for the capture parameters:
modparam("sipcapture", "capture_on", 1)
modparam("sipcapture", "hep_capture_on", 0)
modparam("sipcapture", "raw_ipip_capture_on", 0)
modparam("sipcapture", "raw_moni_capture_on", 1)
modparam("sipcapture", "raw_sock_children", 4)
modparam("sipcapture", "raw_interface", "eth1")
modparam("sipcapture", "raw_socket_listen",
"10.99.99.99:5060-5070")
modparam("sipcapture", "promiscious_on", 1)
modparam("sipcapture", "raw_moni_bpf_on", 1)
Is there a method I could diagnose if the SIP TCP Packets are getting
from the kernel network process and the kamailio process?
# ngrep -d eth1 -W byline host x.x.x.x | /var/run/kamailio/kamailio.pid
Or pipe to kamailio local unix socket?
I don't know, I'm just guessing.
Thanks.
JR
Somehow is not clear for me how you have the
configuration there ...
before commenting further, this needs to be clarified.
The node you presented the config is a sipcapture instance, right? What
is sending traffic to it? Is another kamailio with siptrace module? Or
the sipcature agent? Or you have a port mirroring in the router?
Cheers,
Daniel
On 17/01/2017 16:37, JR Richardson wrote:
--
JR Richardson
Engineering for the Masses
Chasing the Azeotrope
On Mon,
Jan 16, 2017 at 10:29:39AM -0600, JR Richardson wrote:
Interesting. Are you referring to handshaking on the network stack or
SIP TCP TLS handshaking? I guess I can see it two ways.
1) if your talking about TCP/IP handshake, even though the SIP packet
comes into the mirror port on the host node, the kernel processing the
TCP packet is not establishing a valid connection due to no TCP
handshake because its only a monitor port, no transmit back, then the
kernel network stack does not pass the SIP TCP packet to the kamailio
process for capture because it drops the packet due to no valid
handshake?
2) the kernel network stack is passing the SIP TCP packet to the
kamailio process, but since kamailio cannot handshake back it drops
the packet and does not process through the sipcapture module. This
kinda breaks the whole capture ability for homer with SIP TCP. Using
ngrep, I see all SIP TCP packets, invite -->, trying <--, session
progress <--, request timeout <--, ack -->, etc...
So how would I diagnose if the network stack is the culprit? Debugging
kamailio is pretty straight forward, setup and listening for SIP TCP,
but never see any processing of any TCP packets.
Thanks.
JR Yes, I'm familiar with the methods sipcapture
uses, I don't use HEP,
using raw socket capture, I think this may be a sipcapture issue,
debuging kamailio shows normal startup and processing of UDP SIP
packets, but does not show any activity with TCP packets.
I never used HOMER sofar
but when I saw your first message my thoughts
was that this can't work in a simple way since for TCP you need to
complete a 4 way handshake before you can start to send data.