[OpenSIPS-Users] Weird behaviour when replying to an OPTIONS with a Cseq of 0

[Karolis Pabijanskas]

Thanks. I will see if I can post the actual packet tomorrow.

The only reason the contact header has 127.0.0.1 is because this test
example is generated with sipp and ir is picking that off from [local_ip]
there. Even with an identical packet, if you change the cseq to 1 it will
work as expected. Hence cseq 0 is the suspect as that can reliably be
replicated with it being the only difference.

While these particular packets were generated, we are actually hitting this
in real world where we have someone constantly pinging us starting with
cseq 0. The packet with cseq 0 never gets a reply. All others (1-100, then
they start from 0 again) get a reply. I'll post a copy of that packet
tomorrow too.

Thanks.
On 6 Jul 2016 5:55 p.m., "Eric Tamme" <eric at uphreak.com> wrote:

> obscuring the ip/hostnames in this makes it difficult to troubleshoot -
> please dont do that in the future.
>
> I am not certain the CSeq is the issue.  I believe that the contact is
> broken, aka it contains localhost, so when opensips tries to route it, it
> fails on udp_send: sendto.
>
> Again, this is my guess, but since you have manipulated and obscured the
> complete sip trace it makes it difficult to confirm.
>
> -Eric
>
> On 07/06/2016 10:44 AM, Karolis Pabijanskas wrote:
>
> Hi List,
>
> We seem to be hitting a strange behaviour when we get an OPTIONS ping with
> a Cseq of 0. (latest 1.11 branch).
>
> Our routing script contains this at the very beginning to decline OPTIONS
> messages:
> route {
>     if (is_method("OPTIONS")) {
>         sl_send_reply("501", "Method not allowed");
>         exit;
>     };
>    ## blah...
> }
>
> If we send this OPTIONS request:
>
> 2016-07-06 17:12:05 +0100 : CLIENT_IP:5061 -> OPENSIPS_IP:5060
> OPTIONS sip:200 at HOSTNAME:5060 SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1:5061
> ;branch=z9hG4bK-895-1-0 From: sipp <sip:100 at 127.0.0.1>;tag=1 To: <sip:200@
> HOSTNAME:5060> Call-ID: 1-895 at 127.0.0.1 CSeq: 0 OPTIONS Contact: sip:100 at 1
> 27.0.0.1:5061 Max-Forwards: 100 Content-Length: 0
>
> There is no reply from OpenSIPS. Interestingly, siptrace module is also
> running and saving captures in Homer. Homer, actually, is getting a copy of
> the generated reply:
> 2016-07-06 17:12:05 +0100 : OPENSIPS_IP:5060 -> CLIENT_IP:5061
> SIP/2.0 501 Method not allowed Via: SIP/2.0/UDP 127.0.0.1:5061;received=
> *CLIENT_IP*;branch=z9hG4bK-895-1-0 From: sipp <sip:100 at 127.0.0.1>;tag=1
> To: <sip:200 at HOSTNAME:5060>;tag=06a366df8881a48001f15f72f7138d9f.7522
> Call-ID: 1-895 at 127.0.0.1 CSeq: 0 OPTIONS Server: User Agent String
> Content-Length: 0
> But running a tcpdump on the OpenSIPS host reveals that no actual packet
> is ever sent to the client. Debug shows:
> Jul  6 17:40:25 HOSTNAME /sbin/opensips[48357]: ERROR:core:udp_send:
> sendto(sock,0x7f7867aee470,324,0,0x7fff77d00090,16): Operation not
> permitted(1)
> Jul  6 17:40:25 HOSTNAME /sbin/opensips[48357]: ERROR:sl:msg_send:
> udp_send failed
>
> OpenSIPS is running as root.
>
> Switching Cseq to 1 in that original OPTIONS message works. But in this
> particular case we have no control over the Cseq of the host we are being
> pinged from, and need to reply. According to the RFC, Cseq should be a
> 32bit unsigned integer, so 0 should not be an issue.
>
> Any ideas?
>
> Thanks!
> Karolis
>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160706/ef0b3641/attachment.htm>