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
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
