Bugs item #1537245, was opened at 2006-08-09 09:26 Message generated for change (Comment added) made by henningw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1537245&group_id=139143
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.1.x >Status: Closed Resolution: None Priority: 2 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Daniel-Constantin Mierla (miconda) Summary: mod_mangle crash Initial Comment: mailto:[EMAIL PROTECTED] I am expiriencing crash that seems to happen when mod_mediaproxy's fix_contact() rewrites contact and I subsequently call encode_contact(). When fix_contact() is called but contact is not changed, all works OK. This bug has been there since 0.9.x. Log: 0(14215) SIP Request: 0(14215) method: <INVITE> 0(14215) uri: <sip:[EMAIL PROTECTED]> 0(14215) version: <SIP/2.0> 0(14215) parse_headers: flags=2 0(14215) Found param type 232, <branch> = <z9hG4bK- d87543-767618259b786972-1--d87543->; state=6 0(14215) Found param type 235, <rport> = <n/a>; state=17 0(14215) end of header reached, state=5 0(14215) parse_headers: Via found, flags=2 0(14215) parse_headers: this is the first via 0(14215) After parse_msg... 0(14215) preparing to run routing scripts... 0(14215) parse_headers: flags=100 0(14215) DEBUG:maxfwd:is_maxfwd_present: value = 70 0(14215) LOG: uri=sip:[EMAIL PROTECTED] 0(14215) parse_headers: flags=80 0(14215) LOG: Someone trying to register from private IP, rewriting 0(14215) parse_headers: flags=80 0(14215) parse_headers: flags=8000000 0(14215) DEBUG:parse_to:end of header reached, state=10 0(14215) DBUG:parse_to: display={}, ruri= {sip:[EMAIL PROTECTED] 0(14215) DEBUG: get_hdr_field: <To> [29]; uri= [sip:[EMAIL PROTECTED] 0(14215) DEBUG: to body [<sip:[EMAIL PROTECTED]> ] 0(14215) get_hdr_field: cseq <CSeq>: <1> <INVITE> 0(14215) BUG: del_lump: offset exceeds message size (239840 > 938) aborting... Here's backtrace: (gdb) bt #0 0x4005a7c1 in kill () from /lib/libc.so.6 #1 0x4005a545 in raise () from /lib/libc.so.6 #2 0x4005ba88 in abort () from /lib/libc.so.6 #3 0x08053d8c in del_lump (msg=0x81279d0, offset=239840, len=30, type=HDR_OTHER_T) at data_lump.c:288 #4 0x40221e97 in patch (msg=0x6, oldstr=0x0, oldlen=0, newstr=0x81246a8 "sip:encoded*michal**10.245.64.193*621 [EMAIL PROTECTED]", newlen=0) at utils.c:53 #5 0x4021e5a1 in encode_contact (msg=0x81279d0, encoding_prefix=0x8125770 "encoded", public_ip=0x81257f8 "62.141.0.225") at contact_ops.c:114 #6 0x0805071b in do_action (a=0x8125880, msg=0x81279d0) at action.c:701 #7 0x08050631 in do_action (a=0x81258b0, msg=0x81279d0) at action.c:89 #8 0x08050631 in do_action (a=0x8125940, msg=0x81279d0) at action.c:89 #9 0x08050631 in do_action (a=0x8125970, msg=0x81279d0) at action.c:89 #10 0x080522c2 in run_actions (a=0x81247e0, msg=0x81279d0) at action.c:89 #11 0x08051f2e in run_top_route (a=0x0, msg=0x0) at action.c:151 #12 0x08071ec1 in receive_msg ( buf=0x80ea340 "INVITE sip:[EMAIL PROTECTED] SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.0.2:8286;branch=z9hG4bK-d87543- 2d69a52d124c2029-1--d87543-;rport\r\nMax- Forwards: 69\r\nContact: <sip:[EMAIL PROTECTED]:8286>\r\nTo: <sip:"..., len=938, rcv_info=0xbffffbb0) at receive.c:155 #13 0x08089654 in udp_rcv_loop () at udp_server.c:465 ---Type <return> to continue, or q <return> to quit--- #14 0x08063b64 in main_loop () at main.c:925 #15 0x08064fae in main (argc=7, argv=0xbffffd34) at main.c:1477 Configuration file snippet: ... # main routing logic route{ ... if ((src_ip != 10.245.155.174) && (client_nat_test ("3"))) { if (method == "REGISTER" || ! search("^Record- Route:")) { fix_contact(); # Rewrite contact with source IP of signalling if (method == "INVITE") { encode_contact("encoded","62.141.0.225"); }; ... } ... ---------------------------------------------------------------------- >Comment By: Henning Westerholt (henningw) Date: 2008-03-07 16:35 Message: Logged In: YES user_id=337916 Originator: NO Closes this bug, as it probably not apply anymore to a present openser release. Please reopen if this issue appears again. Ovidiu still uses this module, but there was no real maintaince for the code since it was imported into SER, aside some API ports and warning fixes. Perhaps it could be removed for 1.5, after some parts has been integrated into another module. Cheers, Henning ---------------------------------------------------------------------- Comment By: Ovidiu Sas (osas) Date: 2007-03-16 15:15 Message: Logged In: YES user_id=1395524 Originator: NO > On the other hand, mangler is a bit deprecated This module is quite handy for emulating rfc3327 [Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts] when a registrar does not have support for it. ---------------------------------------------------------------------- Comment By: Henning Westerholt (henningw) Date: 2007-03-16 13:58 Message: Logged In: YES user_id=337916 Originator: NO Communication with bug reporter: > Problem solved with internal patch. > If it is a feature of the lump system that it is impossible to rewrite > a url more than once, than this could be closed. Perhaps then we should then document this? ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2006-08-14 09:37 Message: Logged In: YES user_id=1246013 It is possible to rewrite same field twice or more, the new values will be concatenated. See on the mailing list issues related to calling twise force_rtp_proxy(). To have the proxy in the path of dialog request you must use Record Route mechanism (see rr module). Many of us do NAT traversal in their paltforms and usage of mangler module is not necessary. However, OpenSER should not crash - this module has to be fixed or removed (if no longer necessary). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-08-10 12:07 Message: Logged In: NO The bug is 100% reproducible. To explain what I am doing: I have a client (eyeBeam) behind NAT that is using my proxy. I use openser in conjunction with MediaProxy, so I have mediaproxy module loaded. When client makes a call, there's his private address in the Contact: field. I rewrite this contact with the fix_contact() function of the mediaproxy module. That puts there IP and port his packets are really comming from. But that's not enough. A packet will go back to the client through the NAT _only_ when it is sent from the proxy. So, for example, sending BYE to this contact by remote endpoint does not work. What I have to do is encode the original contact information and put proxy IP in it. This way, the BYE command will reach the proxy, which will decode back the uri and use it to forward the request. So I have to first fix the contact and then encode it. The problem is, that fix_contact() allocates new memory for fixed contact and this memory is placed (of course) after msg->buf + msg->len. Then when the mangle module wants to rewrite the contact again, it cannot delete lump created by the fix_contact() function, since offset of the data is too high. >From the impression I got now the bug is not directly related to neither mediaproxy not mangle module, but it is rather a (design?) bug in the lump system, because it seems it is not possible to rewrite single field twice during the same processing. ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2006-08-10 09:32 Message: Logged In: YES user_id=1246013 It seem to be some data corrupted. The offset to del_lump is for sure greater than the whole message. Also, the parameters to patch() function are null and there is a test for such values. It might be that the core file was overwritten. Could this crash be reproduced in an easy way, or is it a rare event. On the other hand, mangler is a bit deprecated, you can use nathelper to change the contact addresses and perform NAT traversal. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2006-08-09 11:37 Message: Logged In: NO I have investigated this problem futher. As far as I understand the "lump" system, it seems to be more design problem - it is not possible to delete lump that was added, just one that was originally present. Am I right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1537245&group_id=139143 _______________________________________________ Devel mailing list Devel@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/devel
