Re: socket problem and kernel >= 2.6.11

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hi michal, 

sorry for the late answer ...

yes, i had tcpdump'ed the connection, and everything seemed to be ok,
but a comparison of the 2 traces shows that the tcp port range
allocation is different:
with the 2.6.11 kernel, which doesn't work, the source tcp port
allocated when opening the socket to the public gatekeeper is in a
range just after 1024
with 2.6.10, which works, the tcp ports allocated are greater than
32000 (not sure if that's exactly this limit though)

on the working setup, if i force Q931PortRange to something like
1024-2000, calls won't be established with exactly the same problem as
with 2.6.11

the next logical step was to try to force Q931PortRange to something
like 32000-64000 on 2.6.11; oddly enough, it works randomly, eg. after
a gnugk reload, but not after a gnugk restart or a machine reboot;
i'll try to get more time to provide something reproducible...
however it's still unclear why the socket can't be opened with "low"
ports ; i've tried to remove selinux from the kernel, preventing any
netfilter/iptables modules from loading, etc., but with no luck

ivan

On 4/20/05, Zygmuntowicz Michal <m.zygmuntowicz@xxxxxxx> wrote:
> 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/
>


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&opÌk
_______________________________________________________

Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx
Archive: http://sourceforge.net/mailarchive/forum.php?forum_id?49
Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users
Homepage: http://www.gnugk.org/


[Index of Archives]     [SIP]     [Open H.323]     [Gnu Gatekeeper]     [Asterisk PBX]     [ISDN Cause Codes]     [Yosemite News]

  Powered by Linux