[SR-Users] Kamailio not processing SIP TCP

[JR Richardson]

root at homer02:~# netstat -altp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address
State       PID/Program name
tcp        0      0 homer02.xxxxx.xxx:sip    *:*
LISTEN      16018/kamailio
tcp        0      0 homer02.xxxxx.xxx:5066   *:*
LISTEN      16018/kamailio

Thanks.

JR

> If you use netstat, what is in the recv queue for tcp packets on sip ports?
>
> netstat -altp
>
> Cheers,
> Daniel
>
>
> On 18/01/2017 16:43, JR Richardson wrote:
>> 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:
>>>>> On Mon, Jan 16, 2017 at 10:29:39AM -0600, JR Richardson wrote:
>>>>>> 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.
>>>>>
>>>> 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
>