Hi, the problem is that TCP has very long timeouts (sometimes hours). In your example, the kernel tells GnuGk the connection is still open, so GnuGk tries to deliver the remaining bytes (the "access denied" message). I have checked in a fix for 2.3.1 that GnuGk is less persistent to deliver the output when access is denied. But the best solution is to firewall off all but the allowed clients from the status port and to set lower TCP defaults for retries. Regards, Jan Denis Kochmashev "Enforta" wrote: > Hello! > > I have a problem with status port. > > PWLib: 1.10.0 > OpenH323: 1.18.0 > GNUGK: 2.2.8 (release) > > The machine on which gnugk is running has two virtual interfaces: > > eth0.100 Link encap:Ethernet HWaddr 00:15:60:0F:78:09 > inet addr:10.56.0.5 Bcast:10.56.0.255 Mask:255.255.255.0 > inet6 addr: fe80::215:60ff:fe0f:7809/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:269399367 errors:0 dropped:0 overruns:0 frame:0 > TX packets:192601280 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:2077654537 (1.9 GiB) TX bytes:1200089463 (1.1 GiB) > > eth0.103 Link encap:Ethernet HWaddr 00:15:60:0F:78:09 > inet addr:172.24.56.15 Bcast:172.24.56.255 Mask:255.255.255.0 > inet6 addr: fe80::215:60ff:fe0f:7809/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:54819939 errors:0 dropped:0 overruns:0 frame:0 > TX packets:20498320 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:4217371101 (3.9 GiB) TX bytes:1933619506 (1.8 GiB) > > mmsvc@coll1:~> /sbin/route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > 10.56.0.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth0.100 > 172.24.56.0 0.0.0.0 255.255.255.0 U 0 0 0 > eth0.103 > 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 > eth0.103 > 172.24.0.0 172.24.56.1 255.252.0.0 UG 0 0 0 > eth0.103 > 0.0.0.0 10.56.0.2 0.0.0.0 UG 0 0 0 > eth0.100 > > Gnugk listens only on 172.24.56.15 (full config attached): > > mmsvc@coll1:~> netstat -atnp | grep gnugk > (Not all processes could be identified, non-owned process info > will not be shown, you would have to be root to see it all.) > tcp 0 0 172.24.56.15:7000 0.0.0.0:* > LISTEN 23419/gnugk > tcp 0 0 172.24.56.15:1720 0.0.0.0:* > LISTEN 23419/gnugk > > Some machine (192.168.66.38) in our network does something which looks like > a port-scan and when it finds gnugk's status port the following conversation > takes place (.pcap files attached): > > Iface Time Source Destination > Protocol Info > eth0.103 2009-09-03 23:43:08.448261 192.168.66.38 172.24.56.15 > TCP 50699 > 7000 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=437566779 > TSER=0 WS=7 > eth0.100 2009-09-03 23:43:08.448283 172.24.56.15 192.168.66.38 > TCP 7000 > 50699 [SYN, ACK] Seq=0 Ack=0 Win=5792 Len=0 MSS=1460 > TSV=3256461383 TSER=437566779 WS=2 > eth0.103 2009-09-03 23:43:08.505997 192.168.66.38 172.24.56.15 > TCP 50699 > 7000 [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=437566837 > TSER=3256461383 > eth0.103 2009-09-03 23:43:08.506036 192.168.66.38 172.24.56.15 > TCP 50699 > 7000 [RST, ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=437566837 > TSER=3256461383 > > ...and that's all. FIN is never sent. I don't know what exactly it does but > as I understand tcp-connections are left half-open. > > Debug level 5 shows the following: > > 2009/09/03 23:43:08.506 5 yasocket.cxx(786) TCPSrv 1 sockets > selected from 2, total 2/0 > 2009/09/03 23:43:08.506 4 yasocket.cxx(908) TCPSrv Accept > request on 172.24.56.15:7000 > 2009/09/03 23:43:08.525 5 job.cxx(364) JOB Worker > threads: 44 total - 38 busy, 6 idle > 2009/09/03 23:43:08.525 5 job.cxx(190) JOB Starting Job > Acceptor at Worker thread 3058879408 > 2009/09/03 23:43:08.526 5 GkStatus.cxx(1047) STATUS Client IP > 192.168.66.38 not found for explicit rule, using default (0) > 2009/09/03 23:43:08.526 4 GkStatus.cxx(1069) STATUS > Authentication rule 'explicit' rejected the client 192.168.66.38:50699 > 2009/09/03 23:43:08.526 4 GkStatus.cxx(932) STATUS New > connection from 192.168.66.38:50699 rejected > 2009/09/03 23:43:08.526 3 GkStatus.cxx(516) STATUS New client > rejected: 3 192.168.66.38:50699 , login: > 2009/09/03 23:43:08.535 4 yasocket.cxx(659) Status > 192.168.66.38:50699 Error(1): Timeout > 2009/09/03 23:43:08.535 4 yasocket.cxx(691) Status > 192.168.66.38:50699 blocked, 0 bytes written, 21 bytes queued > 2009/09/03 23:43:08.535 3 yasocket.cxx(645) Status > 192.168.66.38:50699 is busy, 21 bytes queued > 2009/09/03 23:43:08.545 4 yasocket.cxx(659) Status > 192.168.66.38:50699 Error(1): Timeout > 2009/09/03 23:43:08.545 4 yasocket.cxx(691) Status > 192.168.66.38:50699 blocked, 0 bytes written, 21 bytes queued > 2009/09/03 23:43:08.555 4 yasocket.cxx(659) Status > 192.168.66.38:50699 Error(1): Timeout > > and so on... Every time the same (I have several examples recorded with > wireshark). Gnugk is working but the log file is flooded with these > messages. > > If I send SIGHUP to gnugk it hangs and prints the following in the log until > I kill it with SIGKILL (SIGTERM doesn't help). > > 2009/09/04 07:12:39.339 1 gk.cxx(276) GK Gatekeeper > Hangup (signal 1) > 2009/09/04 07:12:39.339 1 gk.cxx(992) GK Logging > closed (reopen log file) > 2009/09/04 07:12:39.339 1 gk.cxx(1023) GK Logging > restarted > 2009/09/04 07:12:39.341 4 yasocket.cxx(659) Status > 192.168.66.38:60812 Error(1): Timeout > 2009/09/04 07:12:39.341 4 yasocket.cxx(691) Status > 192.168.66.38:60812 blocked, 0 bytes written, 21 bytes queued > 2009/09/04 07:12:39.341 4 yasocket.cxx(659) Status > 192.168.66.38:50699 Error(1): Timeout > 2009/09/04 07:12:39.341 4 yasocket.cxx(691) Status > 192.168.66.38:50699 blocked, 0 bytes written, 21 bytes queued > 2009/09/04 07:12:39.341 4 yasocket.cxx(659) Status > 192.168.66.38:5410 Error(1): Timeout > 2009/09/04 07:12:39.341 4 yasocket.cxx(691) Status > 192.168.66.38:5410 blocked, 0 bytes written, 21 bytes queued > 2009/09/04 07:12:39.343 4 yasocket.cxx(659) Status > 192.168.66.38:24060 Error(1): Timeout > 2009/09/04 07:12:39.343 4 yasocket.cxx(691) Status > 192.168.66.38:24060 blocked, 0 bytes written, 21 bytes queued > > Now I have all traffic from 192.168.66.38 filtered via Linux netfilter rule > and the problem disappeared. > > Is this a bug or am I doing something wrong? > > Thanks in advance. -- Jan Willamowius, jan@xxxxxxxxxxxxxx, http://www.gnugk.org/ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=openh323gk-users Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
