Try to run tcpdump/ethereal to see WHY the connection is not accepted (is TCP SYN packet sent at all?). Maybe the problem is due to an incorrect network interface being selected.
----- Original Message ----- From: "ivan mitev" <ivan.mitev@xxxxxxxxx>
Sent: Tuesday, April 19, 2005 4:06 PM
sorry if that's not the right place to ask ; this post could belong to both pwlib and kernel mailing-lists :(
after an upgrade from kernel 2.6.10 to 2.6.11, gnugk doesn't work anymore in proxy mode : calls from an internal host to an external gateway are terminated at the time when the rtp traffic usually begins to be sent (at least i think so, based on the logs)
all other network things on the machine - daemons,routing,netfilter,... - work well
the strange thing is that compiling the kernel with CONFIG_DEBUG_INFO makes thing work again, so this could be a timing/thread issue, the kernel with debug info being slower.
another thing that is puzzling me is that sometimes - but very rarely - gnugk opens the socket successfuly, so that also makes me wondering if something hasn't changed between 2.6.10 and 2.6.11 regarding random port selection
tested kernels that work without debug: 2.6.10, 2.6.10-ac9 tested kernels that work only with debug : 2.6.11, 2.6.11.6, 2.6.12-rc2-mm1
all the stable and cvs versions of pwlib/openh323/gnugk show the same behavior.
log excerpt:
admissionConfirm {} [...]ProxyChannel.cxx(722) Q931s Received: Setup CRV=19932 from 192.168.20.10:1037
gkacct.cxx(958) GKACCT Successfully logged event 1 for call no. 5
ProxyChannel.cxx(1690) GK Call 5 is NAT type 0
ProxyChannel.cxx(609) GK Call 5 proxy enabled
ProxyChannel.cxx(2173) Q931 Connect to [pub_gk_ip]:1720 successful
ProxyChannel.cxx(722) Q931d Received: CallProceeding CRV=19932 from
[pub_gk_ip]:1720
yasocket.cxx(528) H245d Delete socket [pub_gk_ip]:1077
yasocket.cxx(528) H245s Delete socket 192.168.20.10:1036
ProxyChannel.cxx(722) Q931d Received: Alerting CRV=19932 from [pub_gk_ip]:1720
ProxyChannel.cxx(722) Q931d Received: Connect CRV=19932 from [pub_gk_ip]:1720
gkacct.cxx(958) GKACCT Successfully logged event 32 for call no. 5
ProxyChannel.cxx(2436) H245 Set h245Address to 192.168.20.1:1030
ProxyChannel.cxx(2387) H245 Connected from 192.168.20.10:1039
ProxyChannel.cxx(2409) H245 [pub_gk_ip]:1079 DIDN'T ACCEPT THE CALL RasTbl.cxx(2136) CDR|5|02 13 67 96 33 32 03 76 56 34 34 34 34 ef 00
00|1|Sun, 17 Apr 2005 11:06:05 +0300|Sun, 17 Apr 2005 11:06:06
+0300|192.168.20.10:1037|9679_endp$
gkacct.cxx(918) GKACCT FileAcct logged event 2 for call no. 5
gkacct.cxx(958) GKACCT Successfully logged event 2 for call no. 5
RasSrv.cxx(219) RAS Send to [pub_gk_ip]:1719
disengageRequest{} [...]ProxyChannel.cxx(722) Q931d Received: ReleaseComplete CRV=19932 from
[pub_gk_ip]:1720
RasSrv.cxx(168) RAS Read from [pub_gk_ip]:1719 RasSrv.cxx(207) RAS
disengageConfirm{} [...]
RasSrv.cxx(1240) RAS Trapped DCF yasocket.cxx(500) ProxyH Select error: 10 yasocket.cxx(600) Q931s 192.168.20.10:1037 Error(0): Bad file descriptor (8:9) yasocket.cxx(758) ProxyH(0) waiting... yasocket.cxx(600) H245s 192.168.20.10:1039 Error(0): Input/output
error (12:104)
yasocket.cxx(758) ProxyH(0) waiting... RasSrv.cxx(168) RAS Read from 192.168.20.10:1024 RasSrv.cxx(207) RAS
i gues the "bad file desc." and "i/o error" are side errors because of the previous 'DIDN'T ACCEPT THE CALL' error (missing check before opening/closing the socket ?)
for a successfull call, there is the following line instead of the 'didn't accept the call' error:
ProxyChannel.cxx(2407) H245 Connect to [pub_gk_ip]:1077 successful
and then eveything as usual;
gnugk's relevant config is:
[RoutedMode] GKRouted=1 H245Routed=0 CallSignalPort=1720 CallSignalHandlerNumber=1 RtpHandlerNumber=1 RemoveH245AddressOnTunneling=1 DropCallsByReleaseComplete=1 SupportNATedEndpoints=1 H245PortRange=1024:1030 # tested without that one without sucess AcceptUnregisteredCalls=0 AcceptNeighborsCalls=1
[Proxy] Enable=1 InternalNetwork=192.168.20.0/24 T120PortRange=30000-31000 RTPPortRange=30000-31000
[Endpoint] Gatekeeper=[pub_gk_ip] Type=Gateway H323ID=mitevbg_gk1 Prefix=72 TimeToLive=60 RRQRetryInterval=10 Discovery=0
the system is a fedora core 3 updated, athlon XP / msi kt400 ; the same thing happens with an old epia m800 (via c3) with the same fc3 and kernel 2.6.11 (i didn't test if gnugk was working properly on 2.6.10 with this hardware though).
anybody with a clue if it's a gnugk thread problem, a pwlib socket one, or even a kernel one ? if not, how can i manage to debug that in order to provide something useful ? - the debug trc 5 logs don't seem to show something useful...
thanks ivan
------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 _______________________________________________________
Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
