[SR-Users] Kamailio not processing SIP TCP

[Daniel-Constantin Mierla]

The receive queue is empty, so either the kernel is no putting the
traffic there or kamailio consume it.

Is this box in the same subnet as initial target? Is it having the same
IP as the initial target of the packets? If I anot wrong, tcp mirroring
is a bit more tricky and restrictive in what has to be configured.

Cheers,
Daniel


On 19/01/2017 22:05, JR Richardson wrote:
> 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
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com