WinGate Forums

by **avok** » Mar 02 04 10:00 am

Hello,

First problem:
It happens frequently that my connection with WGIC server terminates unexpectedly. Sometimes because of DHCP lease expire or because of my ISP technical faults. In this case, some active sessions on WGIC server does not clear and stay stuck until I manually terminate them. When this happens with the port my application listens to, the port become blocked and the application will not work properly anymore.

Second problem:
Sometimes when client application initiates connections too fast one after another the internet client causes the application to crash. I have observed this on several java-based clients and on some native too.

I use the latest version of wingate 5.2.3 (build 901)

by **Pascal** » Mar 02 04 5:34 pm

Is the connection between the WinGate server and the Client terminated ?

If you close the application on the client, does that remove the session ?

A last thought - do those connections time out gracefully after the timeout period ? (Default 60 seconds, I believe)

by **avok** » Mar 03 04 9:38 am

Pascal wrote:Is the connection between the WinGate server and the Client terminated?

Yes, it's completely terminated. As I said, my ISP changes my IP address often.

If you close the application on the client, does that remove the session?

No

A last thought - do those connections time out gracefully after the timeout period? (Default 60 seconds, I believe)

No, they never ever terminate at all. Not one of them. I tried many values for timeout, even switched it off. No difference.

If I terminate the client gracefully, newer connections disappear. But those that are stuck from before don't. Restarting WRS don't help either. The only way to terminate this TCPLinks is to click with right mouse button on every one of them and choose terminate.

It's possible that they disappear after a time. Because when I change the listening port for my client to some different value it works (until the next connection drop and the new TCPLinks stuck). And after a time I can change the port back and it works again. But it's a very long time before that can happen.

by **avok** » Mar 05 04 7:29 am

I answered your questions, now, please, answer mine.

by **Pascal** » Mar 05 04 9:40 am

Apologies for the delay, things are quite hectic on this side.

The application is listening on a client machine, behind WinGate ? If you go to the WinGate Server when it become stuck like that, I suspect you will see that the port is still in use. (netstat -an from a command line should show that) It should be in a TIME_WAIT or similar state, so it's possible that after a while it might become available again.

by **avok** » Mar 05 04 11:24 am

Ok, I used netstat -na on the wingate server.

It was not pretty. First some additional info. My client can listen on these four ports 15200, 15201, 15202, 15203. Generally, it uses only one, the others are also pinholed in the firewall and used for backup in case the primary become stuck. I switch them manually in the client if that happens. So considering that and the fact that I haven't used ports other than 15201 for almost 20 hours already, take a look at this:

Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:809 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1029 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1030 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2428 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2500 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2825 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3105 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3113 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3127 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4607 0.0.0.0:0 LISTENING
TCP 0.0.0.0:4887 0.0.0.0:0 LISTENING
TCP 0.0.0.0:6881 0.0.0.0:0 LISTENING
TCP 0.0.0.0:9948 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15200 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15201 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15202 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15202 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15202 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15202 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15202 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15203 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15203 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15203 0.0.0.0:0 LISTENING
TCP 0.0.0.0:15203 0.0.0.0:0 LISTENING
TCP 127.0.0.1:808 0.0.0.0:0 LISTENING
TCP 127.0.0.1:808 127.0.0.1:4607 ESTABLISHED
TCP 127.0.0.1:1029 127.0.0.1:7161 ESTABLISHED
TCP 127.0.0.1:4607 127.0.0.1:808 ESTABLISHED
TCP 127.0.0.1:7161 0.0.0.0:0 LISTENING
TCP 127.0.0.1:7161 127.0.0.1:1029 ESTABLISHED
TCP 172.16.134.52:21 0.0.0.0:0 LISTENING
TCP 172.16.134.52:25 0.0.0.0:0 LISTENING
TCP 172.16.134.52:809 83.97.24.39:46462 ESTABLISHED
TCP 172.16.134.52:1080 0.0.0.0:0 LISTENING
TCP 172.16.134.52:2028 0.0.0.0:0 LISTENING
TCP 172.16.134.52:2428 68.2.187.111:6881 ESTABLISHED
TCP 172.16.134.52:2500 192.168.10.2:15201 ESTABLISHED
TCP 172.16.134.52:2825 68.59.88.163:6881 ESTABLISHED
TCP 172.16.134.52:2857 0.0.0.0:0 LISTENING
TCP 172.16.134.52:2857 192.168.10.2:1214 ESTABLISHED
TCP 172.16.134.52:2857 192.168.10.2:3016 ESTABLISHED
TCP 172.16.134.52:2857 192.168.10.2:3019 ESTABLISHED
TCP 172.16.134.52:2857 192.168.10.2:3027 ESTABLISHED
TCP 172.16.134.52:2857 192.168.10.2:3703 ESTABLISHED
TCP 172.16.134.52:2857 192.168.10.2:3862 ESTABLISHED
TCP 172.16.134.52:3105 80.196.34.219:6881 ESTABLISHED
TCP 172.16.134.52:3113 141.153.171.142:6881 ESTABLISHED
TCP 172.16.134.52:3127 81.132.42.74:6881 ESTABLISHED
TCP 172.16.134.52:3128 0.0.0.0:0 LISTENING
TCP 172.16.134.52:4887 80.61.9.225:6884 ESTABLISHED
TCP 172.16.134.52:6881 24.1.52.181:1670 CLOSE_WAIT
TCP 172.16.134.52:6881 24.93.185.68:2793 CLOSE_WAIT
TCP 172.16.134.52:6881 80.180.30.93:4739 CLOSE_WAIT
TCP 172.16.134.52:6881 82.48.234.137:3384 CLOSE_WAIT
TCP 172.16.134.52:6881 82.84.175.151:2010 CLOSE_WAIT
TCP 172.16.134.52:6881 213.84.36.27:35132 CLOSE_WAIT
TCP 172.16.134.52:9948 192.168.10.2:1701 ESTABLISHED
TCP 172.16.134.52:15200 24.59.144.191:2245 ESTABLISHED
TCP 172.16.134.52:15200 24.59.144.191:3333 ESTABLISHED
TCP 172.16.134.52:15200 24.160.217.183:2714 CLOSE_WAIT
TCP 172.16.134.52:15200 24.160.217.183:2930 CLOSE_WAIT
TCP 172.16.134.52:15200 62.3.229.135:18785 ESTABLISHED
TCP 172.16.134.52:15200 62.155.177.233:1304 CLOSE_WAIT
TCP 172.16.134.52:15200 64.230.136.25:3039 CLOSE_WAIT
TCP 172.16.134.52:15200 64.231.93.169:15936 CLOSE_WAIT
TCP 172.16.134.52:15200 66.66.89.193:2715 CLOSE_WAIT
TCP 172.16.134.52:15200 66.227.139.238:2367 CLOSE_WAIT
TCP 172.16.134.52:15200 67.170.0.87:3010 CLOSE_WAIT
TCP 172.16.134.52:15200 68.72.10.59:1056 CLOSE_WAIT
TCP 172.16.134.52:15200 68.72.10.59:2210 CLOSE_WAIT
TCP 172.16.134.52:15200 68.230.173.121:1820 CLOSE_WAIT
TCP 172.16.134.52:15200 69.156.103.104:4862 CLOSE_WAIT
TCP 172.16.134.52:15200 80.6.163.18:3245 CLOSE_WAIT
TCP 172.16.134.52:15200 80.7.209.243:1671 ESTABLISHED
TCP 172.16.134.52:15200 80.172.34.20:2702 ESTABLISHED
TCP 172.16.134.52:15200 80.190.246.78:35780 CLOSE_WAIT
TCP 172.16.134.52:15200 80.190.246.78:38561 CLOSE_WAIT
TCP 172.16.134.52:15200 80.190.246.78:48625 CLOSE_WAIT
TCP 172.16.134.52:15200 80.190.246.78:48662 CLOSE_WAIT
TCP 172.16.134.52:15200 80.190.246.78:48675 CLOSE_WAIT
TCP 172.16.134.52:15200 80.190.246.78:57546 CLOSE_WAIT
TCP 172.16.134.52:15200 81.36.212.124:2293 CLOSE_WAIT
TCP 172.16.134.52:15200 81.96.244.163:4279 CLOSE_WAIT
TCP 172.16.134.52:15200 81.110.253.131:3430 ESTABLISHED
TCP 172.16.134.52:15200 81.133.43.87:3437 CLOSE_WAIT
TCP 172.16.134.52:15200 81.185.36.240:3837 CLOSE_WAIT
TCP 172.16.134.52:15200 81.249.169.151:34601 ESTABLISHED
TCP 172.16.134.52:15200 82.36.67.202:20438 ESTABLISHED
TCP 172.16.134.52:15200 82.36.127.182:64313 CLOSE_WAIT
TCP 172.16.134.52:15200 82.36.127.182:65459 ESTABLISHED
TCP 172.16.134.52:15200 82.168.49.32:19805 CLOSE_WAIT
TCP 172.16.134.52:15200 129.15.209.8:61898 ESTABLISHED
TCP 172.16.134.52:15200 129.15.209.8:62453 ESTABLISHED
TCP 172.16.134.52:15200 129.142.199.76:3451 ESTABLISHED
TCP 172.16.134.52:15200 134.84.207.5:2624 CLOSE_WAIT
TCP 172.16.134.52:15200 158.94.82.82:1992 CLOSE_WAIT
TCP 172.16.134.52:15200 203.217.38.8:63410 CLOSE_WAIT
TCP 172.16.134.52:15200 203.217.78.191:3274 CLOSE_WAIT
TCP 172.16.134.52:15200 203.218.152.49:2773 CLOSE_WAIT
TCP 172.16.134.52:15200 210.0.204.168:2535 CLOSE_WAIT
TCP 172.16.134.52:15200 210.6.29.27:3320 CLOSE_WAIT
TCP 172.16.134.52:15200 210.6.29.27:3623 CLOSE_WAIT
TCP 172.16.134.52:15200 210.6.29.27:4537 CLOSE_WAIT
TCP 172.16.134.52:15200 213.10.52.31:57666 ESTABLISHED
TCP 172.16.134.52:15200 213.168.168.239:17395 CLOSE_WAIT
TCP 172.16.134.52:15200 213.208.113.63:1817 CLOSE_WAIT
TCP 172.16.134.52:15200 213.208.113.63:3981 ESTABLISHED
TCP 172.16.134.52:15200 213.231.240.28:3028 CLOSE_WAIT
TCP 172.16.134.52:15200 217.23.231.66:24666 CLOSE_WAIT
TCP 172.16.134.52:15200 217.84.241.208:2447 ESTABLISHED
TCP 172.16.134.52:15200 217.84.241.208:2879 CLOSE_WAIT
TCP 172.16.134.52:15200 218.102.80.96:4746 CLOSE_WAIT
TCP 172.16.134.52:15200 218.102.83.112:3364 CLOSE_WAIT
TCP 172.16.134.52:15200 218.102.182.157:2329 CLOSE_WAIT
TCP 172.16.134.52:15200 218.218.180.62:49838 CLOSE_WAIT
TCP 172.16.134.52:15200 218.253.248.115:35068 CLOSE_WAIT
TCP 172.16.134.52:15200 218.254.34.57:55200 CLOSE_WAIT
TCP 172.16.134.52:15200 218.254.178.65:2440 CLOSE_WAIT
TCP 172.16.134.52:15200 220.240.69.36:23194 ESTABLISHED
TCP 172.16.134.52:15201 24.12.118.233:2162 ESTABLISHED
TCP 172.16.134.52:15201 24.202.46.235:4460 ESTABLISHED
TCP 172.16.134.52:15201 24.223.178.37:60064 ESTABLISHED
TCP 172.16.134.52:15201 61.29.106.66:2409 ESTABLISHED
TCP 172.16.134.52:15201 61.29.106.66:4616 ESTABLISHED
TCP 172.16.134.52:15201 62.147.134.46:3933 CLOSE_WAIT
TCP 172.16.134.52:15201 62.147.189.242:4259 ESTABLISHED
TCP 172.16.134.52:15201 64.228.70.193:3120 ESTABLISHED
TCP 172.16.134.52:15201 65.95.161.109:61965 CLOSE_WAIT
TCP 172.16.134.52:15201 66.24.28.114:62863 CLOSE_WAIT
TCP 172.16.134.52:15201 66.151.22.14:37665 CLOSE_WAIT
TCP 172.16.134.52:15201 66.227.139.238:3449 CLOSE_WAIT
TCP 172.16.134.52:15201 68.61.58.193:27778 CLOSE_WAIT
TCP 172.16.134.52:15201 68.93.20.13:2635 CLOSE_WAIT
TCP 172.16.134.52:15201 68.153.68.93:3226 CLOSE_WAIT
TCP 172.16.134.52:15201 80.6.163.18:3097 CLOSE_WAIT
TCP 172.16.134.52:15201 80.6.163.18:3238 CLOSE_WAIT
TCP 172.16.134.52:15201 80.6.163.18:3500 CLOSE_WAIT
TCP 172.16.134.52:15201 80.11.113.138:4905 CLOSE_WAIT
TCP 172.16.134.52:15201 80.170.131.1:11382 ESTABLISHED
TCP 172.16.134.52:15201 80.172.34.76:3304 CLOSE_WAIT
TCP 172.16.134.52:15201 80.221.254.137:3864 CLOSE_WAIT
TCP 172.16.134.52:15201 81.49.79.75:2650 CLOSE_WAIT
TCP 172.16.134.52:15201 81.49.215.110:2687 ESTABLISHED
TCP 172.16.134.52:15201 81.49.235.191:4306 ESTABLISHED
TCP 172.16.134.52:15201 81.53.123.138:4134 CLOSE_WAIT
TCP 172.16.134.52:15201 81.57.125.93:4092 CLOSE_WAIT
TCP 172.16.134.52:15201 81.57.178.178:4633 CLOSE_WAIT
TCP 172.16.134.52:15201 81.63.52.52:61487 ESTABLISHED
TCP 172.16.134.52:15201 81.79.56.140:4961 CLOSE_WAIT
TCP 172.16.134.52:15201 81.86.117.16:4643 CLOSE_WAIT
TCP 172.16.134.52:15201 81.99.21.112:1495 CLOSE_WAIT
TCP 172.16.134.52:15201 81.137.229.20:63692 CLOSE_WAIT
TCP 172.16.134.52:15201 81.168.68.137:10179 ESTABLISHED
TCP 172.16.134.52:15201 81.178.216.18:4535 CLOSE_WAIT
TCP 172.16.134.52:15201 81.178.230.161:1823 ESTABLISHED
TCP 172.16.134.52:15201 81.185.36.240:4303 CLOSE_WAIT
TCP 172.16.134.52:15201 81.185.36.240:4523 CLOSE_WAIT
TCP 172.16.134.52:15201 81.185.113.40:2842 CLOSE_WAIT
TCP 172.16.134.52:15201 81.249.69.78:4114 ESTABLISHED
TCP 172.16.134.52:15201 81.249.168.130:3998 CLOSE_WAIT
TCP 172.16.134.52:15201 82.2.138.129:3537 ESTABLISHED
TCP 172.16.134.52:15201 82.36.67.202:20374 ESTABLISHED
TCP 172.16.134.52:15201 82.42.155.48:3545 CLOSE_WAIT
TCP 172.16.134.52:15201 82.64.170.228:3400 ESTABLISHED
TCP 172.16.134.52:15201 82.65.67.174:1600 ESTABLISHED
TCP 172.16.134.52:15201 82.65.130.11:1950 CLOSE_WAIT
TCP 172.16.134.52:15201 82.224.196.34:22839 CLOSE_WAIT
TCP 172.16.134.52:15201 83.76.80.115:51332 ESTABLISHED
TCP 172.16.134.52:15201 83.154.88.100:3290 CLOSE_WAIT
TCP 172.16.134.52:15201 128.243.123.252:4149 CLOSE_WAIT
TCP 172.16.134.52:15201 144.136.55.159:4881 ESTABLISHED
TCP 172.16.134.52:15201 161.116.95.20:3096 CLOSE_WAIT
TCP 172.16.134.52:15201 172.180.197.121:2593 CLOSE_WAIT
TCP 172.16.134.52:15201 193.2.4.129:3784 CLOSE_WAIT
TCP 172.16.134.52:15201 194.204.4.161:1652 ESTABLISHED
TCP 172.16.134.52:15201 199.126.239.40:3743 CLOSE_WAIT
TCP 172.16.134.52:15201 203.217.66.10:4665 CLOSE_WAIT
TCP 172.16.134.52:15201 203.217.200.172:29226 ESTABLISHED
TCP 172.16.134.52:15201 203.217.214.108:3111 CLOSE_WAIT
TCP 172.16.134.52:15201 208.234.160.253:32739 CLOSE_WAIT
TCP 172.16.134.52:15201 210.0.204.168:4887 CLOSE_WAIT
TCP 172.16.134.52:15201 212.4.61.164:3731 CLOSE_WAIT
TCP 172.16.134.52:15201 212.194.104.126:4101 ESTABLISHED
TCP 172.16.134.52:15201 213.10.52.31:55448 ESTABLISHED
TCP 172.16.134.52:15201 213.44.155.37:22218 ESTABLISHED
TCP 172.16.134.52:15201 213.44.237.246:4182 ESTABLISHED
TCP 172.16.134.52:15201 213.46.108.250:4820 CLOSE_WAIT
TCP 172.16.134.52:15201 213.103.194.150:2467 ESTABLISHED
TCP 172.16.134.52:15201 213.103.240.208:3830 CLOSE_WAIT
TCP 172.16.134.52:15201 213.208.113.63:4151 ESTABLISHED
TCP 172.16.134.52:15201 213.208.113.63:4854 ESTABLISHED
TCP 172.16.134.52:15201 217.109.163.158:41422 CLOSE_WAIT
TCP 172.16.134.52:15201 218.102.195.10:32911 CLOSE_WAIT
TCP 172.16.134.52:15201 218.102.195.10:63960 CLOSE_WAIT
TCP 172.16.134.52:15201 218.191.36.252:4233 CLOSE_WAIT
TCP 172.16.134.52:15201 219.78.25.62:51683 CLOSE_WAIT
TCP 172.16.134.52:15202 61.29.106.66:2661 ESTABLISHED
TCP 172.16.134.52:15202 62.234.64.127:1805 ESTABLISHED
TCP 172.16.134.52:15202 65.82.79.35:4502 CLOSE_WAIT
TCP 172.16.134.52:15202 81.109.146.155:3796 CLOSE_WAIT
TCP 172.16.134.52:15202 81.168.106.33:63423 CLOSE_WAIT
TCP 172.16.134.52:15202 81.227.133.161:64547 CLOSE_WAIT
TCP 172.16.134.52:15202 194.204.4.161:33342 ESTABLISHED
TCP 172.16.134.52:15202 210.6.29.27:4313 CLOSE_WAIT
TCP 172.16.134.52:15202 210.6.29.27:4602 CLOSE_WAIT
TCP 172.16.134.52:15202 212.158.237.147:62862 CLOSE_WAIT
TCP 172.16.134.52:15202 218.102.195.10:38729 CLOSE_WAIT
TCP 172.16.134.52:15202 219.78.25.62:50338 CLOSE_WAIT
TCP 172.16.134.52:15203 62.3.229.135:12281 CLOSE_WAIT
TCP 172.16.134.52:15203 62.34.15.227:2166 CLOSE_WAIT
TCP 172.16.134.52:15203 67.61.18.65:4404 CLOSE_WAIT
TCP 172.16.134.52:15203 129.15.209.8:60042 CLOSE_WAIT
TCP 172.16.134.52:15203 199.126.16.66:65159 ESTABLISHED
TCP 172.16.134.52:15203 203.218.152.49:1122 CLOSE_WAIT
TCP 172.16.134.52:15203 210.0.204.168:1552 CLOSE_WAIT
TCP 172.16.134.52:15203 213.10.52.31:58775 ESTABLISHED
TCP 172.16.134.52:15203 218.102.195.10:32821 CLOSE_WAIT
TCP 172.16.134.52:15203 218.102.195.10:33021 CLOSE_WAIT
TCP 172.16.134.52:15203 219.215.231.58:4121 ESTABLISHED
UDP 0.0.0.0:161 *:*
UDP 0.0.0.0:162 *:*
UDP 0.0.0.0:445 *:*
UDP 0.0.0.0:520 *:*
UDP 0.0.0.0:1026 *:*
UDP 0.0.0.0:1027 *:*
UDP 0.0.0.0:1031 *:*
UDP 0.0.0.0:1032 *:*
UDP 0.0.0.0:1033 *:*
UDP 0.0.0.0:50161 *:*
UDP 127.0.0.1:1034 *:*
UDP 172.16.134.52:500 *:*
UDP 172.16.134.52:4500 *:*

I am wondering how my client even works at all in these conditions. What do you think? Any suggestions?

by **Pascal** » Mar 05 04 12:04 pm

Is this a custom application, or an off-the-shelf product ? If it's off the shelf, would you be able to provide a link to where I can download it. It would be interesting to test, and see if we can reproduce the scenario here.

by **Pascal** » Mar 05 04 12:11 pm

Would you run a debug kit for us, please ? It will require replacing the WinGate executable on the server until you see the problem again, then you can revert back to the original version.

by **avok** » Mar 05 04 12:28 pm

It is a peer-to-peer client. One of the most popular for the torrent network. Name Azureus. You can get it from here http://azureus.sourceforge.net/

But it's Java based, so it uses the Java Virtual Machine for network operation. As a Java developer myself, I can tell you that there is not much you can do to tweak the default implementation of TCP sockets in Java. So most probably, this issue exists for all Java based applications. Or at least for that version of JVM. I use the latest one from sun "Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)" http://www.java.com/en/download/manual.jsp
Another important thing. I use Azureus with the option "Slowly connect new peer connections" switched on. Without it, the Wingate Internet Client will eventually crash Azureus. You can try to reproduce that as well.

Finally, an excerpt of what I found on the topic of CLOSE_WAIT connection status. It is from here http://www.itisit.nl/uk/solutions/tuning/
-----------
Sometime sockets are in CLOSE_WAIT state, this state conducts when a client doesn’t answer back anymore with the last ack N+1. A client crashing while they had a connection is occurring may times as a result the socket isn’t closed properly, but much more occurring bad programming is the issue why sockets are closed inappropriate. Most socket developers forget to give an explicit call for shutdown() before the close()/ socketclose(). The shutdown(RDWR) flushes the socket send and receive buffers and tells the other side to stop sending data and that it don’t have to expect data anymore. As a close()/ socketclose() is called upon the chance on a CLOSE_WAIT state is out of the question at the side of the software. According to the TCP specifications, the server has to stay in CLOSE_WAIT state to be sure that all data (TCP guarantees data transmission) is transmitted. Lot of OS developers saw this problem in the TCP specifications and added a (friendly) timeout to the CLOSE_WAIT that in most cases is adjustable. Windows NT and 2000 doesn’t foresee in a CLOSE_WAIT timeout parameter, the only way to free those resources is restarting. When there are structural CLOSE _WAIT(s) on a certain service, the best way is to contact the reseller of the service or client(s) to solve this problem because this is a clear software problem with the service, client(s) or both.
-----------

by **avok** » Mar 05 04 12:31 pm

I would. I will send you a message with my e-mail.

by **avok** » Mar 06 04 9:46 am

Ok, I made the test. Here are some major steps.

1. I made VPN tunnel, started WIC and started my client. The client was able to work normally.
2. I disconnected the VPN. They I closed the client. I connected the tunnel again and started the client again. The client was able to work normally.
3. I repeated the previous step setup, but this time I disconnected my LAN card physically and then reconnected it. Same results.
4. I repeated step 2 with one important difference. This time I didn't close the client after disconnecting VPN. And when I connected the VPN again, the client was not able to use its listening port (15202).

So the problem is maybe when the WIC session with the client application is not reset. That case (step 4) produced one permanently stuck connection (in the gatekeeper activity tab) and problems for the client. I think that was also the time when the multiple persistent close_wait connections appeared, but I am not sure for all of them. However in each one step, one more "TCP 0.0.0.0:15202 0.0.0.0:0 LISTENING" entry was added to the netstat output. All the persistent problematic connections and listen bindings disappeared when I restarted wingate engine (restating WGIC makes no difference)

So now it’s your turn :)

by **avok** » Mar 09 04 9:17 pm

Hello?

Any news on my problem?

by **Pascal** » Mar 10 04 9:42 am

The log file looks okay. I think best is for us to try and reproduce this. We are busy with WGIC at the moment.[/b]

by **neil** » Mar 10 04 10:38 am

I think we're going to need some more details before we can start to reproduce this. Firstly, is it a WinGate VPN that you are connecting? Secondly on which side of the VPN (Hoster or Joiner) is this Azureus on? Thirdly is a peer to peer connection being made with this software to another machine on the other side of the VPN? Fourthly, how is the Azureus app set in the WGIC? Globally or mixed? Does this issue occur if you don't connect the VPN and just connect the app to the WRP service normally?

Regards

Neil

by **avok** » Mar 10 04 11:34 am

neil wrote:I think we're going to need some more details before we can start to reproduce this. Firstly, is it a WinGate VPN that you are connecting? I use Wingate VPN to connect to Wingate(full) Secondly on which side of the VPN (Hoster or Joiner) is this Azureus on? On the joiner side Thirdly is a peer to peer connection being made with this software to another machine on the other side of the VPN? Not to just another mashine, but to many machines most of them on internet Fourthly, how is the Azureus app set in the WGIC? Globally or mixed?It is not set at all. It is by default Globally I assume Does this issue occur if you don't connect the VPN and just connect the app to the WRP service normally? I don't know, I cannot connect normally because both the PC where the client is (Wingate VPN) and the full Wingate server are behind NAT. I tried this but it seems WGIC uses multiple bidirectional connections and NAT is standing in the way

Regards

Neil

BTW Azureus 2.0.8.0 is out. It has the same problem too. Other very popular peer to peer client eMule (http://www.emule-project.net) does not work also. When eMule client connects to some (any) compatible server, the server then checks if it can reach the port where the client is declared it listens to. And then the server reports that this port is unreachable. If I make some test with some regular server side app like telnet for example I am sure it won't work too. So the problem is most likely not in the client.

by **avok** » Mar 14 04 7:11 am

Any success yet?

by **avok** » Apr 02 04 11:21 am

You don't even bother to answer anymore is that right? Well, I will not forget about the topic and I will keep posting until you come up with some solution or you state that you cannot fix your product. You didn't really solve any of my problems until now! And I have had plenty of them already. So I will continue to bump this topic, for others to see what they can expect.

by **avok** » Apr 14 04 12:17 am

by **avok** » Apr 19 04 7:52 pm

WinGate Forums

WGIC sessions stuck and client crashes

WGIC sessions stuck and client crashes

Who is online