[Devel] [ openser-Bugs-1537245 ] mod_mangle crash
SourceForge.net
noreply at sourceforge.net
Fri Mar 16 14:58:29 CET 2007
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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Daniel-Constantin Mierla (miconda)
Summary: mod_mangle crash
Initial Comment:
mailto:michal.kara at nextiraone.cz
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:zdenek at 10.245.155.174>
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:zdenek at 10.245.155.174
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:zdenek at 10.245.155.174}
0(14215) DEBUG: get_hdr_field: <To> [29]; uri=
[sip:zdenek at 10.245.155.174]
0(14215) DEBUG: to body [<sip:zdenek at 10.245.155.174>
]
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
11*@62.141.0.225",
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:zdenek at 10.245.155.174
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:michal at 192.168.0.2: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: 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
More information about the Devel
mailing list