#564 sip_trace module bug

1.8.x
closed-fixed
modules (454)
5
2013-01-29
2012-10-11
No

Hi

The siptrace module reports a wrong value in the `fromip` field of the sip_trace table.

For example , for this INVITE, coming from tls:80.187.x.x:62510 , I would expect the value "tls:80.187.x.x:62510" to be added in the `fromip` field,
but it's adding "tls:80.187.x.x:625" instead . It's missing two digits from the port value.
Also , sometimes it would put its local port (in my case 5061) instead of the remote port in the `fromip` or `toip` fields.

INVITE sips:+49170738xxxx@sip.domain.com SIP/2.0
Call-Id: c64e6615c79ab23501ad13f2e1a58918@10.77.26.75
CSeq: 1 INVITE
Via: SIP/2.0/TLS 10.77.26.75:59076;branch=z9hG4bK127109c14cd3b59c9ef9909b737982ab
Max-Forwards: 70
From: "+491713xxxxx" <sips:username@sip.domain.com>;tag=yRkyOWfbq
To: <sips:+4917073xxxxx@sip.domain.com>
Contact: <sips:00xxxx@80.187.x.x:62510;transport=tls>
Allow: ACK,BYE
User-Agent: SomeUserAgent
Content-Type: application/sdp
Content-Length: 138

v=0
o=- 1349965870484 1349965870484 IN IP4 10.77.26.75
s=-
c=IN IP4 10.77.26.75
t=0 0
m=audio 37566 RTP/AVP 0
a=rtpmap:0 PCMU/8000

The problem was observed with opensips 1.8.1-tls and opensips-1.7.2-tls .

Cheers,
Dragos

Discussion

  • Bogdan-Andrei Iancu

    Can you reproduce that? if so, I will provide a small patch to print some extra logs - the idea is to see if the truncation comes from the siptrace or the mysql module

    Regards,
    Bogdan

     
  • Bogdan-Andrei Iancu

    • assigned_to: nobody --> bogdan_iancu
     
  • Dragos Oancea

    Dragos Oancea - 2012-10-12

    Hi

    Yes, it happens very often,I don't know why . Sometime it puts the correct values into the fields (for messages within the same dialog I could see some entries -requests or replies - added with the correct port , but some are missing one or two digits ),

    If you provide the patch I'll apply it.

    Cheers,
    Dragos

     
  • Bogdan-Andrei Iancu

    Dragos, apply this patch -> it will print to logs (on critical level) the calculated FROMIP and TOIP values. When you find bogus entries in siptrace, you can try to correlate with the log to see if the values from logs are also truncated.

    Thanks and regards,
    Bogdan

     
  • Dragos Oancea

    Dragos Oancea - 2012-10-15

    Hi Bogdan,

    INVITE sips:+4917133xxxxx@sip.domain.com SIP/2.0
    Call-Id: 6484f90259156c8d702a1cae0eb49f27@10.208.83.156
    CSeq: 1 INVITE
    Via: SIP/2.0/TLS 10.208.83.156:53912;branch=z9hG4bK2929012bef3d8abb931df26bd8fa498c
    Max-Forwards: 70
    From: "+4917073xxxxx" <sips:xxxxx@sis.secusmart.com>;tag=IhJICbbyh
    To: <sips:+4917133xxxxx@sip.domain.com>
    Contact: <sips:xxxxxx@80.187.x.x:52316;transport=tls>
    Allow: ACK,BYE
    User-Agent: SomeUserAgent
    Content-Type: application/sdp
    Content-Length: 142

    v=0
    o=- 1350298945023 1350298945023 IN IP4 10.208.83.156
    s=-
    c=IN IP4 10.208.83.156
    t=0 0
    m=audio 58639 RTP/AVP 0
    a=rtpmap:0 PCMU/8000

    | INVITE | | tls:80.187.x.x:5231 | tls:212.162.x.x:5061 | IhJICbbyh | in | 2012-10-15 13:02:24 |

    CRITICAL:siptrace:sip_trace: xXx to ip is [tls:212.162.x.x:5061]
    CRITICAL:siptrace:sip_trace: xXx from ip is [tls:80.187.x.x:52316]

    The log entries (printed with the patch you provided) look correct, the `fromip` and `toip` fields are showing truncated values in the sip_trace table for most of the request and replies.

    Cheers,
    Dragos

     
  • Bogdan-Andrei Iancu

    Could you check the table format ? Do "desc siptrace" and see what are the sizes of the fromip and toip fields in the table - maybe the truncating is done by db.

     
  • Dragos Oancea

    Dragos Oancea - 2012-10-15

    mysql> desc sip_trace ;
    +-------------+------------------+------+-----+---------------------+----------------+
    | Field | Type | Null | Key | Default | Extra |
    +-------------+------------------+------+-----+---------------------+----------------+
    | id | int(10) unsigned | NO | PRI | NULL | auto_increment |
    | date | datetime | NO | MUL | 1900-01-01 00:00:01 | |
    | callid | varchar(255) | NO | MUL | | |
    | traced_user | varchar(128) | NO | MUL | | |
    | msg | text | NO | | NULL | |
    | method | varchar(50) | NO | | | |
    | status | varchar(128) | NO | | | |
    | fromip | varchar(50) | NO | MUL | | |
    | toip | varchar(50) | NO | | | |
    | fromtag | varchar(64) | NO | | | |
    | direction | varchar(4) | NO | | | |
    | time_stamp | timestamp | NO | | CURRENT_TIMESTAMP | |
    +-------------+------------------+------+-----+---------------------+----------------+
    12 rows in set (0.01 sec)

    They are varchar(50) , there should be enough space.
    Also , sometimes the same ip:port pair is inserted correctly - for example it could we wrong for the received INVITE, but it could be correct for the relayed BYE .

     
  • Dragos Oancea

    Dragos Oancea - 2012-10-17

    Hi Bogdan,

    No , I am not using that feature.

    Regards,
    Dragos

     
  • David Sanders

    David Sanders - 2012-10-19

    I've also encountered this issue as described, with opensips 1.8.0-tls.

    In addition to the described case, I've seen times where the field will look like "sip:80.187.x.x:625 1", with a space present in the port number. This seems to suggest it isn't truncation.

     
  • Bogdan-Andrei Iancu

    Ok, last question - have you noticed a pattern on what kind of records have bogus port values ? like request, in or out, ? or maybe for replies ? It will help me to dig into the right code.

    Regards,
    Bogdan

     
  • David Sanders

    David Sanders - 2012-10-19

    I only see it occurring on direction = 'in'.

    In addition, it only affects the fromip field. It seems to be truncated to 22 characters.

    If there is a space in the port number it is only if the fromip was less than 22 characters. For example "udp:xx.xxx.x.xx:5060 1" is a pattern I see a lot. 1 seems to be the most common extra character, but I also see 0, 4, 7, 9, etc.

     
  • Bogdan-Andrei Iancu

    What about the type of SIP requests - do you see the err for requests or for replies (or both ?) ?

    Regards,
    Bogdan

     
  • Dragos Oancea

    Dragos Oancea - 2012-10-22

    I see the error for `fromip` , direction `in` for both requests and replies. 22 characters.
    I never saw a space in that field, but maybe my IPs are longer.

    Cheers,
    Dragos

     
  • David Sanders

    David Sanders - 2012-10-22

    I believe it occurs for both requests and replies for me as well.

    - David

     
  • Razvan Crainea

    Razvan Crainea - 2012-10-31

    Hi!

    I've attached a patch that disables the Prepared Statements. Please apply it and check if you still find any bogus fields in your db.

    Regards,
    Răzvan

     
  • Dragos Oancea

    Dragos Oancea - 2012-11-06

    will do. but funny thing , I did not see the problem again in the last week... I'm running the absolutely same opensips binary and config as when it happened.

    Regards,
    Dragos

     
  • Bogdan-Andrei Iancu

    The debugging did not reveal anything...If this problem pops up again, please open a new ticket !

    Regards,
    Bogdan

     
  • Bogdan-Andrei Iancu

    • status: open --> closed-invalid
     
  • Bogdan-Andrei Iancu

    Finally I was able to reproduce the bug - it is fixed on trunk and 1.8 !

    Thanks and regards,
    Bogdan

     
  • Bogdan-Andrei Iancu

    • status: closed-invalid --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks