[Home]

Summary:ASTERISK-04840: chan_h323 crashes when gatekeeper used and calls addressed with IP address
Reporter:goestelecom (goestelecom)Labels:
Date Opened:2005-08-15 09:36:13Date Closed:2011-06-07 14:00:54
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Channels/chan_h323
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) gdb.txt
( 1) gdb2.txt
Description:Asterisk crashes on a call via gnugk.  The problem can be reproduced and also happens on earlier releases of pwlib, openh323 and gnugk. Calls from gnugk can be completed by Asterisk (however, the all calls use context=default problem is also happening). It may be that there is a gnugk configuration issue, but that should not cause Asterisk to crash.

I will be happy to provide more detailed diagnostic information if needed.

pwlib-v1_9_1
openh323-v1_17_2
gnugk-2.2.2

The following gnugk log message is generated:

Routing.cxx(75)    ROUTING Invalid destination address: ipAddress {
       ip =  4 octets {
         00 00 00 00                                        ....
       }
       port = 0
     }


****** ADDITIONAL INFORMATION ******

   -- Executing Dial("SIP/xxxxx", "H323/111@ip.address.of.gnugk) in new stack
   -- Called 111@ip.address.of.gnugk

ERROR[10060]: ast_h323.cxx:164 void PAssertFunc(const char*): Assertion fail: Null pointer reference, file h225_1.cxx, line 431

ERROR[10060]: ast_h323.cxx:164 void PAssertFunc(const char*): Assertion fail: Invalid cast to non-descendant class, file h225_1.cxx, line 431

output: fwrite: Broken pipe
output: fwrite: Broken pipe
Segmentation fault (core dumped)
Comments:By: Tilghman Lesher (tilghman) 2005-08-15 10:13:25

You must provide a backtrace in order for us to be able to track down the issue.
By: goestelecom (goestelecom) 2005-08-15 12:03:34

This info came from asterisk.core after recompiling (gmake clean;gmake valgrind;gmake install).

(gdb) info thread
* 27 LWP 100227  0x282dd713 in pthread_testcancel () from /usr/lib/libpthread.so.1
 26 Thread 27 (runnable)  0x2833ae47 in lstat () from /lib/libc.so.5
 25 Thread 26 (LWP 100137)  0x282dd6f3 in pthread_testcancel () from /usr/lib/libpthread.so.1
 24 Thread 25 (runnable)  0x28399ce4 in _ctx_start () from /lib/libc.so.5
 23 Thread 24 (sleeping)  0x282d6237 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1
 22 Thread 23 (runnable)  0x2833bb67 in read () from /lib/libc.so.5
 21 Thread 22 (runnable)  0x2833bb67 in read () from /lib/libc.so.5
 20 Thread 21 (sleeping)  0x282d6237 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1
 19 Thread 20 (runnable)  0x28399ce4 in _ctx_start () from /lib/libc.so.5
 18 Thread 19 (sleeping)  0x282d6237 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1
 17 Thread 18 (runnable)  0x2833b3e7 in select () from /lib/libc.so.5
 16 Thread 17 (runnable)  0x2833aca7 in poll () from /lib/libc.so.5
 15 Thread 16 (runnable)  0x28399ce4 in _ctx_start () from /lib/libc.so.5
 14 Thread 15 (runnable)  0x2833bb67 in read () from /lib/libc.so.5
 13 Thread 14 (runnable)  0x2833aca7 in poll () from /lib/libc.so.5
 12 Thread 13 (runnable)  0x2833aca7 in poll () from /lib/libc.so.5
 11 Thread 12 (runnable)  0x28399ce4 in _ctx_start () from /lib/libc.so.5
 10 Thread 11 (runnable)  0x2833aca7 in poll () from /lib/libc.so.5
 9 Thread 10 (runnable)  0x2833aca7 in poll () from /lib/libc.so.5
 8 Thread 9 (runnable)  0x2833aca7 in poll () from /lib/libc.so.5
 7 Thread 8 (runnable)  0x2833aca7 in poll () from /lib/libc.so.5
 6 Thread 7 (sleeping)  0x282d6237 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1
 5 Thread 6 (runnable)  0x2833aca7 in poll () from /lib/libc.so.5
 4 Thread 5 (sleeping)  0x282d6237 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1
 3 Thread 4 (runnable)  0x2833bb67 in read () from /lib/libc.so.5
 2 Thread 2 (runnable)  0x28d0989c in H323TransportAddress::H323TransportAddress () from /usr/local/src/openh323/lib/libh323_FreeBSD_x86_r.so.1.17.2
 1 Thread 1 (runnable)  0x2833b3e7 in select () from /lib/libc.so.5
(gdb) thread 2
[Switching to thread 2 (Thread 2 (runnable))]#0  0x28d0989c in H323TransportAddress::H323TransportAddress ()
  from /usr/local/src/openh323/lib/libh323_FreeBSD_x86_r.so.1.17.2
(gdb) bt full
#0  0x28d0989c in H323TransportAddress::H323TransportAddress () from /usr/local/src/openh323/lib/libh323_FreeBSD_x86_r.so.1.17.2
No symbol table info available.
#1  0x28ce6d12 in H323SignalPDU::GetDestinationAlias () from /usr/local/src/openh323/lib/libh323_FreeBSD_x86_r.so.1.17.2
No symbol table info available.
#2  0x2840499b in MyH323Connection::OnSendSignalSetup () from /usr/local/lib/asterisk/modules/chan_h323.so
No symbol table info available.
#3  0x28cc70f9 in H323Connection::SendSignalSetup () from /usr/local/src/openh323/lib/libh323_FreeBSD_x86_r.so.1.17.2
No symbol table info available.
#4  0x28ccc631 in H225CallThread::Main () from /usr/local/src/openh323/lib/libh323_FreeBSD_x86_r.so.1.17.2
No symbol table info available.
ASTERISK-1  0x28667c3d in PThread::PX_ThreadStart () from /usr/local/src/pwlib/lib/libpt_FreeBSD_x86_r.so.1.9.1
No symbol table info available.
ASTERISK-2  0x282c7ac9 in pthread_create () from /usr/lib/libpthread.so.1
No symbol table info available.
ASTERISK-3  0x28399ce7 in _ctx_start () from /lib/libc.so.5
No symbol table info available.

The following DEBUG messages were produced:

Aug 15 12:47:58 DEBUG[37426] chan_h323.c: type=H323, format=4, data=611@209.102.227.19.
Aug 15 12:47:58 DEBUG[37426] chan_h323.c: Extension: 111 Host: ip.address.of.gnugk
Aug 15 12:47:58 DEBUG[37426] chan_h323.c: Setting NAT on RTP to 0
Aug 15 12:47:58 DEBUG[37426] chan_h323.c: Placing outgoing call to 111@111@ip.address.of.gnugk, 101

I'm no expert in H.323, but the last line of the DEBUG output looks suspect.  In fact, I tried removing ${EXTEN} and replacing it with 111 in extensions.conf with the same results.
By: goestelecom (goestelecom) 2005-08-15 12:09:11

**** Note:

Aug 15 12:47:58 DEBUG[37426] chan_h323.c: type=H323, format=4, data=611@209.102.227.19.

Should have been cleaned to:

Aug 15 12:47:58 DEBUG[37426] chan_h323.c: type=H323, format=4, data=111@ip.address.of.gnugk.

Sorry for any confusion.
By: Michael Jerris (mikej) 2005-08-15 13:48:36

can you recompile openh323 with debug symbols so that we can get a good backtrace there.
By: goestelecom (goestelecom) 2005-08-15 14:59:45

#0  0x28d577c2 in PASN_Integer::operator unsigned int () from /usr/local/src/pwlib/lib/libpt_FreeBSD_x86_r.so.1.9.1
#1  0x2897a05b in H323TransportAddress (this=0xbf554338, transport=@0x873db2c) at transports.cxx:663
#2  0x289563d6 in H323SignalPDU::GetDestinationAlias (this=0xbf5545b8, firstAliasOnly=0) at h323pdu.cxx:1416
#3  0x2873d771 in MyH323Connection::OnSendSignalSetup (this=0x8738000, setupPDU=@0xbf5545b8) at ast_h323.cxx:787
#4  0x2892bb29 in H323Connection::SendSignalSetup (this=0x8738000, alias=@0x8739048, address=@0x873905c) at h323.cxx:3192
ASTERISK-1  0x2893605c in H225CallThread::Main (this=0x8739000) at h323ep.cxx:864
ASTERISK-2  0x28de6c3d in PThread::PX_ThreadStart () from /usr/local/src/pwlib/lib/libpt_FreeBSD_x86_r.so.1.9.1
ASTERISK-3  0x282c7ac9 in pthread_create () from /usr/lib/libpthread.so.1
ASTERISK-4  0x28399ce7 in _ctx_start () from /lib/libc.so.5

I'll post another bt after recompiling pwlib with debug symbols as well.
By: Michael Jerris (mikej) 2005-08-15 15:04:06

when you do, please attatch as a file a bt full, and a thread apply all bt.
By: goestelecom (goestelecom) 2005-08-15 16:23:11

gdb.txt = bt full, and a thread apply all bt.
gdb2.txt = thread 2, bt full
By: goestelecom (goestelecom) 2005-08-16 18:50:51

When gatekeeper=disable is specified in h323.conf and the H.323 endpoint IP address is used (in place of the gatekeeper IP address) in the Dial command, the call completes normally and no crash happens.
By: Sebastian Nocetti (snocetti) 2005-08-18 15:57:28

When Gatekeeper is present in h323.conf and call is sent using IP ADDRESS in form: @xx.xx.xx.xx, asterisk crashes. If call is sent to GnuGK, it completes ok.

h323.conf
gatekeeper = xx.zz.yy.dd

dial(h323/1111@xx.xx.xx.xx) --> Crash.
dial(h323/1111) --> OK.

h323.conf
gatekeeper = DISABLED

dial(h323/1111@xx.xx.xx.xx) --> OK.


By: goestelecom (goestelecom) 2005-08-21 21:20:43

snocetti,

What is the Operating System that you are experiencing the crash on ?  I think there is a question as to whether this is problem is specific to BSD.
By: Sebastian Nocetti (snocetti) 2005-08-22 14:45:58

Well, I am using FEDORA RC4, and GENTOO LINUX, both same problem, as I described before.... I compiled chan_h323 with pwlib and openh323 versions as in README.
By: Michael Jerris (mikej) 2005-08-24 01:14:13

what has me confused is:

0 0x28d577c2 in PASN_Integer::operator unsigned int () from /usr/local/src/pwlib/lib/libpt_FreeBSD_x86_r.so.1.9.1

Why is that saying FreeBSD if you are on linux?
By: goestelecom (goestelecom) 2005-08-24 06:37:43

We are experiencing the crash on FreeBSD (goestelecom)

snocetti is experiencing the crash on Fedora RC4 and Gentoo

The traces in this report are from the FreeBSD crash.

Regards,
Norm
By: goestelecom (goestelecom) 2005-08-25 18:24:39

Based on the information in the notes, the Category of this problem should be re-evaluated.
By: goestelecom (goestelecom) 2005-09-05 20:02:43

Does anyone have any status or request for more diagnostic information ?
By: Tilghman Lesher (tilghman) 2005-09-05 20:14:00

Given the extensiveness of the openh323 libraries, there are a limited number of people familiar enough with the codebase to contemplate writing a patch.  If you are one of those people, I would strongly urge you to file a disclaimer and submit a patch.  If you are not, well, we need someone familiar with the OpenH323 project code who is willing to both file a disclaimer and submit a patch.
By: Mark Spencer (markster) 2005-09-12 22:39:08

have you tried the new chan_ooh323 driver to see if it works properly in your environment?
By: goestelecom (goestelecom) 2005-09-13 21:40:58

It appears that there is no crash when using the ooh323 channel driver (and yes, calls do complete).

The configure/gmake is very rough around the edges.

There were a few hard-coded search paths that needed to be modified (this probably isn't specific to FreeBSD).

Of particular note is having to hard-code -DHAVE_PTHREAD_H during the compile process.  This might be FreeBSD specific.  I didn't test on Linux.

During my testing, the only visible notice in the logs is listed below:

Sep 13 22:28:39 WARNING[73270]: src/chan_h323.c:923 h323_indicate: Don't know how to indicate condition -1 on ooh323c_5

Disclaimer: By no means was my testing exhaustive.  I can say this appears to be a step in the right direction.

Regards,
Norm
By: Matt O'Gorman (mogorman) 2005-10-04 10:50:39

goestelecom is tis issue resolved for you as of now?  Can this issue be resolved.

Matt
By: Olle Johansson (oej) 2005-10-25 09:46:44

No answer from reporter.

Propably fixed by switching to the new H.323 channel. If not, please re-open this report.

/Housekeeping
By: goestelecom (goestelecom) 2005-10-25 10:23:20

If there is a resolution type of "workaround" rather than "fixed" this would more accurately describe the situation.

The distributed H323 driver (channels/h323) still causes Asterisk to crash.

The asterisk-addons ooh323 driver does not cause a crash (in my configuration).

Regards,
Norm
By: Matt O'Gorman (mogorman) 2006-01-08 09:59:09.000-0600

goestelecom if this is still aproblem can you find jerjer and work with him on this. Jerher would you mind doing the same?
By: jerjer (jerjer) 2006-01-08 10:52:25.000-0600

No problem - however I will require access to someones gatekeeper as we no longer have anything other than H.323 capable phones here.
By: goestelecom (goestelecom) 2006-01-09 06:13:59.000-0600

It has been a couple of months since the developers have expressed any interest in resolving this problem.  I will be happy to assist but it will take a little while to rebuild the development environment.

Will update this ticket when the development environment has been rebuilt.

Regards,
Norm
By: Clod Patry (junky) 2006-02-13 23:07:18.000-0600

/Housekeeping
Any update here, since that bug is like 6 months old.
By: goestelecom (goestelecom) 2006-02-16 08:06:42.000-0600

Based on todays 02/16/2006 SVN chan_h323 won't compile (FreeBSD).  If I get a chance, I'll look into this a little more unless someone else already has fixed this.  Note that I'm using the CVS versions of both pwlib and openh323 (and yes, it has all compiled properly in the past).

Regards,
Norm

gcc  -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O6 -I/usr/local/include -L/usr/local/lib -march=i386  -DZAPTEL_OPTIMIZATIONS         -fomit-frame-pointer  -DT38_SUPPORT -DWITH_SMDI -Wno-missing-prototypes -Wno-missing-declarations -DIAX_TRUNKING -DCRYPTO -fPIC    -c -o chan_h323.o chan_h323.c
chan_h323.c: In function `oh323_hangup':
chan_h323.c:499: warning: initialization discards qualifiers from pointer target type
chan_h323.c: In function `__oh323_new':
chan_h323.c:738: warning: passing arg 1 of `snprintf' discards qualifiers from pointer target type
chan_h323.c:745: error: structure has no member named `type'
chan_h323.c:768: warning: passing arg 1 of `strncpy' discards qualifiers from pointer target type
chan_h323.c: In function `connection_made':
chan_h323.c:1237: warning: unused variable `c'
chan_h323.c: In function `chan_ringing':
chan_h323.c:1439: warning: unused variable `c'
chan_h323.c: At top level:
chan_h323.c:2314: warning: initialization from incompatible pointer type
gmake[1]: *** [chan_h323.o] Error 1
gmake[1]: Leaving directory `/usr/local/src/ast/asterisk/channels'
gmake: *** [subdirs] Error 1
By: goestelecom (goestelecom) 2006-02-17 06:27:19.000-0600

Looks like the last compiling note is the same as: 0006521

Regards,
Norm
By: Andrey S Pankov (casper) 2006-02-19 12:25:51.000-0600

Please see the patch in the bug ASTERISK-634621, it fixes all the issues with compilation.
By: Andrey S Pankov (casper) 2006-02-19 14:30:01.000-0600

This is a configuration issue. Current chan_h323 does not allow (read: does not support and does not check to prevent) exten@host dialing if GK is configured. And that makes sense in GK-enabled environment since in that case the GK configured has information about all registered aliases and decides where to send the call with that particular alias/exten.

A feature request should be posted I.M.O. to support mixed (GK/non-GK) environment in chan_h323.

The source of the problem is that we pass '111@111@ip.addr' as remoteParty to MakeCallLocked. According to OpenH323 documentation:
 The general form for this parameter is
 [alias@][transport$]host[:port] where the default alias is the same as
 the host, the default transport is "ip" and the default port is 1720.
By: jerjer (jerjer) 2006-02-19 14:53:46.000-0600

Granted it is been quite a while since I have read the H.323 Recommendation, but I remember wording saying that if a Gatekeeper is used, all communication SHALL be sent via the Gatekeeper.
By: Serge Vecher (serge-v) 2006-05-06 14:09:35

goestelecom: do you still have the crash happening? Presumably, h.323 now compiles again -- could you please revisit this issue?

Thanks.
By: Andrey S Pankov (casper) 2006-05-06 15:11:58

Yes, it crashes! Nothing changed...
By: Serge Vecher (serge-v) 2006-05-06 15:14:14

casper: are you able to fix this issue?
By: Andrey S Pankov (casper) 2006-05-06 15:16:27

vechers: that's in no way related to 6521, thanks!

And how did you find it compiles again? It compiles in Solid PBX r79,
but not in Asterisk afaik. You need to apply ASTERISK-6822 first.
By: Andrey S Pankov (casper) 2006-05-06 15:18:15

vechers: not earlier than devconn in Pisa is over... and then we'll see...
By: goestelecom (goestelecom) 2006-05-08 07:41:50

We haven't been able to get a clean compile of Asterisk SVN on FreeBSD for a few weeks.  

For example, it appears that a default ODBC installation isn't detected at all.

A checkout from about 5 minutes ago produced the following error (last week, the compile failed in logger.c so I suppose progress is being made):

gcc   -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3    -O6 -I/usr/local/include -L/usr/local/lib -march=i386           -fomit-frame-pointer  -include include/autoconfig.h -Iinclude   -c -o sched.o sched.c
sched.c: In function `sched_context_create':
sched.c:83: warning: implicit declaration of function `ast_calloc'
sched.c:83: warning: assignment makes pointer from integer without a cast
sched.c: In function `sched_alloc':
sched.c:127: warning: assignment makes pointer from integer without a cast
sched.c: In function `schedule':
sched.c:184: warning: implicit declaration of function `AST_LIST_INSERT_BEFORE_CURRENT'
sched.c:184: error: `list' undeclared (first use in this function)
sched.c:184: error: (Each undeclared identifier is reported only once
sched.c:184: error: for each function it appears in.)
gmake: *** [sched.o] Error 1



Once we can get Asterisk to compile, we will try once again to see if the problem associated with this ticket is still there.

Regards,
Norm
By: Serge Vecher (serge-v) 2006-05-08 09:05:23

Norm: I haven't seen the problem you describe in any open bug report. Can you please file it a new bug. Thanks!
By: goestelecom (goestelecom) 2006-05-09 15:19:17

First, I would like to "THANK" the magicians that fixed up the Makefiles so that a default ODBC FreeBSD installation works.

We pulled fresh copies of pwlib and openh323.  They compiled correctly.  

We then entered channels/h323 and received the errors below.  It was not a big deal to remove the offending Makefile lines and have the compile complete.

The next step was to head back to the top level Asterisk directory and perform a compile.  Unfortunately, chan_h323 refused to even attempt a compile.  Perhaps the recent Makefile changes that Asterisk has undergone has caused this problem.  We will continue to investigate this but someone else may quickly know what's up.

.....all in an attempt to get a working h323 implementation that can be used to verify if the issue associated with this ticket is still out there.....

Regards,
Norm




-bash-2.05b# gmake opt
g++ -DNDEBUG   DEBUG_THREADS +=  -I../../include -include autoconfig.h -Wmissing-prototypes -fPIC  -DP_USE_PRAGMA -D_REENTRANT -I/usr/local/include -Wall  -I/usr/local/src/pwlib/include -DPTRACING -I/usr/local/src/openh323/include -Os  -pipe -felide-constructors -c ast_h323.cxx -o ast_h323.o
g++: DEBUG_THREADS: No such file or directory
g++: +=: No such file or directory
cc1plus: warning: command line option "-Wmissing-prototypes" is valid for C/ObjC but not for C++
gmake: *** [ast_h323.o] Error 1
gmake: *** Deleting file `ast_h323.o'
By: Serge Vecher (serge-v) 2006-05-09 15:30:10

norm: glad to see some progress here. Again, please file the compilation problems separately, so that they can be addressed in the most efficient matter.

hint: there is a fix waiting to be committed in http://bugs.digium.com/view.php?id=7006. If it does indeed work, please make a note in that bug stating so -- that will help to get it in.

Thanks.
By: Andrey S Pankov (casper) 2006-05-17 16:03:41

ASTERISK-6822 was intended to fix:

    g++: DEBUG_THREADS: No such file or directory

But this is not needed now...
By: Serge Vecher (serge-v) 2006-05-26 10:00:31

goestelecom: where are we with diagnosing the original issue. AFAIK, chan_h323 compiles ok now.

Thanks
By: Andrey S Pankov (casper) 2006-05-26 15:29:34

vechers: nearly everyting here is not related to the original bug.
Deeper explanation of the bug is in my note 0041472 here.
Any H.323 related knowledge is not needed to fix it.
The bug still exists in both 1.2 and trunk.
By: Serge Vecher (serge-v) 2006-05-26 16:00:18

ok, casper, thanks for clarification. Can you please write a small note for h323.conf.sample so we can amend it and close the bug?
By: Anthony LaMantia (alamantia) 2006-05-26 20:52:42

Can you provide a core dump or any relevent log information from asterisk and what you were trying to perform with gatekeeper?

-Anthony
By: Andrey S Pankov (casper) 2006-05-28 13:06:26

vechers: i doubt it's enough to add a note there. Anyway that's already in
channels/h323/README:

------------------------------- CUT -------------------------------
Dialing an H.323 channel
------------------------
Without a gatekeeper:
exten => _1NXXNXXXXXX,1,Dial,H323/${EXTEN}@peer
or
exten => _1NXXNXXXXXX,1,Dial,H323/${EXTEN}@ip.or.hostname

'peer' is defined in h323.conf as:

[peer]
type=peer
host=1.2.3.4
disallow=all
allow=ulaw

Using a gatekeeper:
exten => _1NXXNXXXXXX,1,Dial,H323/${EXTEN}

When using a gatekeeper you cannot utilize the type=peer features,
since the H.323 spec states that when a Gatekeeper is part of an H.323 network,
the Gatekeeper shall be used for all communication.
------------------------------- CUT -------------------------------

We need the code to prevent exten@ip|peer dialing when gatekeeper is used.
And a volunteer to commit it... ;)

alamantia: it's already enough info here and the bug is clearly described imo...
By: Serge Vecher (serge-v) 2006-05-30 08:40:35

ok, at this point I will suspend the issue, since the opportunity to submit such code has existed for a while and nobody submitted the code yet. If anybody comes up with a patch to be considered for inclusion into trunk or would like to add anything else, please feel free to contact a bug marshall to reopen this bug. Thank you.