WinGate Forums

by **Rroff** » Dec 22 03 10:31 am

just updated to 5.2.2 and I'm getting out of buffer errors (and resultant problems with clients internet acess) witin 24 hours of uptime and having to continually reboot the server atleast once a day sometimes more often. This happens on all 3 machines that I can test the server on that can directly connect to the net, these machines are a range of spec and OS.

by **genie** » Dec 22 03 10:51 am

Hi, can you check the the driver installed after upgrade is the new one? It is a possibility the the driver was not updated during upgrade.
Also, what kind of networking hardware is installed on the machine?

by **Rroff** » Dec 22 03 11:48 am

The main machine is a Celeron 400 running windows 98SE, internet access is via a USB ADSL modem and has a generic 10/100Mbit NIC connection to the network.

From the advanced options on that machine:

1.01 WINGATE CONFIGURATION REPORT
1.02 Sunday, December 21, 2003, 22:37
1.03
1.04 ---------------------------------------------
1.05 WinGate Engine
1.06 ---------------------------------------------
1.07 WinGate 5.2.2 (Build 892)
1.08 Operating System: Windows 98 (4.10)
1.09 Language: eng

The 2nd machine I tried is a P3 1gig with win2k (same internet connection), this is the first time I've installed wingate on it since the last OS reinstall andit was straight from the 5.2.2 installation package. Same thing happens on both, after 15-20 hours web pages start to load up with images missing, soon after every other time someone opens a web page it will throw up a bunch of can't find site errors but usually eventually loads, after 20 hours internet explorer goes straight to a couldn't find page error and trying to open gatekeeper on the server results in an out of buffers error.

What I do find strange... on the main machine I was getting this error along with massive memory leaks when trying the 5.1 version and eventually went back to 5.0.7 which had run stable before for upto 2 weeks at a time, however it was now giving the out of buffers error after 3-4 days up time, prompting me to upgrade to 5.2.2.

by **adrien** » Dec 22 03 4:38 pm

This might sound like a dumb idea, but when was the last time you did a virus scan on your network? We have seen things like the Blaster virus doing things like this.

Adrien

by **Rroff** » Dec 23 03 5:35 am

could be a possibility, all my machines are locked down tight, regular virus sweeps, etc., but theres several machines that don't belong to me, connected too. Though I'd have thought such activity would show in the activity pane in gatekeeper, which I keep a fairly good eye on for suspicous activity.

by **Rroff** » Dec 23 03 7:32 am

well, I've run norton and housecall over all the machines without finding anything.

I've gone back to 5.0.7 for now... gonna see what happens, I can't be rebooting the server every 15-20 hours.

by **Rroff** » Dec 25 03 10:25 am

52 hours on 5.0.7 and out of buffers error came up... I did a netstat -an on the server:

Code: Select all: Active Connections Proto Local Address Foreign Address State TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING TCP 0.0.0.0:1026 0.0.0.0:0 LISTENING TCP 0.0.0.0:1028 0.0.0.0:0 LISTENING TCP 0.0.0.0:1028 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:1032 0.0.0.0:0 LISTENING TCP 0.0.0.0:1034 0.0.0.0:0 LISTENING TCP 0.0.0.0:1035 0.0.0.0:0 LISTENING TCP 0.0.0.0:6667 0.0.0.0:0 LISTENING TCP 0.0.0.0:21 0.0.0.0:0 LISTENING TCP 0.0.0.0:1045 0.0.0.0:0 LISTENING TCP 0.0.0.0:2837 0.0.0.0:0 LISTENING TCP 0.0.0.0:1046 0.0.0.0:0 LISTENING TCP 0.0.0.0:1048 0.0.0.0:0 LISTENING TCP 0.0.0.0:1049 0.0.0.0:0 LISTENING TCP 0.0.0.0:3101 0.0.0.0:0 LISTENING TCP 0.0.0.0:5924 0.0.0.0:0 LISTENING TCP 0.0.0.0:3376 0.0.0.0:0 LISTENING TCP 0.0.0.0:4400 0.0.0.0:0 LISTENING TCP 0.0.0.0:4401 0.0.0.0:0 LISTENING TCP 0.0.0.0:2870 0.0.0.0:0 LISTENING TCP 0.0.0.0:59 0.0.0.0:0 LISTENING TCP 0.0.0.0:80 0.0.0.0:0 LISTENING TCP 0.0.0.0:81 0.0.0.0:0 LISTENING TCP 0.0.0.0:3667 0.0.0.0:0 LISTENING TCP 0.0.0.0:3418 0.0.0.0:0 LISTENING TCP 0.0.0.0:2910 0.0.0.0:0 LISTENING TCP 0.0.0.0:3939 0.0.0.0:0 LISTENING TCP 0.0.0.0:3941 0.0.0.0:0 LISTENING TCP 0.0.0.0:2918 0.0.0.0:0 LISTENING TCP 0.0.0.0:2919 0.0.0.0:0 LISTENING TCP 0.0.0.0:3943 0.0.0.0:0 LISTENING TCP 0.0.0.0:2925 0.0.0.0:0 LISTENING TCP 0.0.0.0:2931 0.0.0.0:0 LISTENING TCP 0.0.0.0:2933 0.0.0.0:0 LISTENING TCP 0.0.0.0:1145 0.0.0.0:0 LISTENING TCP 0.0.0.0:1913 0.0.0.0:0 LISTENING TCP 0.0.0.0:1146 0.0.0.0:0 LISTENING TCP 0.0.0.0:2939 0.0.0.0:0 LISTENING TCP 0.0.0.0:2941 0.0.0.0:0 LISTENING TCP 0.0.0.0:2943 0.0.0.0:0 LISTENING TCP 0.0.0.0:2945 0.0.0.0:0 LISTENING TCP 0.0.0.0:2949 0.0.0.0:0 LISTENING TCP 0.0.0.0:2953 0.0.0.0:0 LISTENING TCP 0.0.0.0:2442 0.0.0.0:0 LISTENING TCP 0.0.0.0:2447 0.0.0.0:0 LISTENING TCP 0.0.0.0:2965 0.0.0.0:0 LISTENING TCP 0.0.0.0:2967 0.0.0.0:0 LISTENING TCP 0.0.0.0:2969 0.0.0.0:0 LISTENING TCP 0.0.0.0:2971 0.0.0.0:0 LISTENING TCP 0.0.0.0:1948 0.0.0.0:0 LISTENING TCP 0.0.0.0:2464 0.0.0.0:0 LISTENING TCP 0.0.0.0:2977 0.0.0.0:0 LISTENING TCP 0.0.0.0:2469 0.0.0.0:0 LISTENING TCP 0.0.0.0:2982 0.0.0.0:0 LISTENING TCP 0.0.0.0:2983 0.0.0.0:0 LISTENING TCP 0.0.0.0:4007 0.0.0.0:0 LISTENING TCP 0.0.0.0:2985 0.0.0.0:0 LISTENING TCP 0.0.0.0:4014 0.0.0.0:0 LISTENING TCP 0.0.0.0:4016 0.0.0.0:0 LISTENING TCP 0.0.0.0:4017 0.0.0.0:0 LISTENING TCP 0.0.0.0:4019 0.0.0.0:0 LISTENING TCP 0.0.0.0:28085 0.0.0.0:0 LISTENING TCP 0.0.0.0:5824 0.0.0.0:0 LISTENING TCP 0.0.0.0:3523 0.0.0.0:0 LISTENING TCP 0.0.0.0:4055 0.0.0.0:0 LISTENING TCP 0.0.0.0:6624 0.0.0.0:0 LISTENING TCP 0.0.0.0:3048 0.0.0.0:0 LISTENING TCP 0.0.0.0:3572 0.0.0.0:0 LISTENING TCP 0.0.0.0:3573 0.0.0.0:0 LISTENING TCP 0.0.0.0:3323 0.0.0.0:0 LISTENING TCP 0.0.0.0:3069 0.0.0.0:0 LISTENING TCP xxx.xxx.xxx.xxx:6667 24.247.104.137:60771 ESTABLISHED TCP xxx.xxx.xxx.xxx:6667 xxx.xxx.xxx.xxx:2464 ESTABLISHED TCP xxx.xxx.xxx.xxx:1045 216.248.61.76:6667 ESTABLISHED TCP xxx.xxx.xxx.xxx:2837 213.221.165.248:6668 ESTABLISHED TCP xxx.xxx.xxx.xxx:1049 207.53.232.254:20 ESTABLISHED TCP xxx.xxx.xxx.xxx:3101 213.221.189.3:6667 ESTABLISHED TCP xxx.xxx.xxx.xxx:1913 207.53.232.254:21 ESTABLISHED TCP xxx.xxx.xxx.xxx:137 0.0.0.0:0 LISTENING TCP xxx.xxx.xxx.xxx:138 0.0.0.0:0 LISTENING TCP xxx.xxx.xxx.xxx:139 0.0.0.0:0 LISTENING TCP xxx.xxx.xxx.xxx:2447 207.46.107.77:1863 ESTABLISHED TCP xxx.xxx.xxx.xxx:2464 xxx.xxx.xxx.xxx:6667 ESTABLISHED TCP xxx.xxx.xxx.xxx:2469 64.71.177.228:6667 ESTABLISHED TCP xxx.xxx.xxx.xxx:1723 202.180.113.232:80 TIME_WAIT TCP xxx.xxx.xxx.xxx:1727 202.180.113.232:80 TIME_WAIT TCP xxx.xxx.xxx.xxx:1729 202.180.113.232:80 TIME_WAIT TCP xxx.xxx.xxx.xxx:3523 207.46.106.139:1863 ESTABLISHED TCP 127.0.0.1:1031 0.0.0.0:0 LISTENING TCP 127.0.0.1:1032 127.0.0.1:4400 ESTABLISHED TCP 127.0.0.1:21 0.0.0.0:0 LISTENING TCP 127.0.0.1:23 0.0.0.0:0 LISTENING TCP 127.0.0.1:2080 0.0.0.0:0 LISTENING TCP 127.0.0.1:808 0.0.0.0:0 LISTENING TCP 127.0.0.1:554 0.0.0.0:0 LISTENING TCP 127.0.0.1:4400 127.0.0.1:1032 ESTABLISHED TCP 127.0.0.1:1080 0.0.0.0:0 LISTENING TCP 127.0.0.1:8000 0.0.0.0:0 LISTENING TCP 127.0.0.1:80 0.0.0.0:0 LISTENING TCP 127.0.0.1:7000 0.0.0.0:0 LISTENING TCP 127.0.0.1:110 0.0.0.0:0 LISTENING TCP 127.0.0.1:368 0.0.0.0:0 LISTENING TCP 127.0.0.1:46789 0.0.0.0:0 LISTENING TCP 127.0.0.1:1755 127.0.0.1:808 TIME_WAIT TCP 192.168.0.1:1031 0.0.0.0:0 LISTENING TCP 192.168.0.1:1034 192.168.0.1:6667 ESTABLISHED TCP 192.168.0.1:6667 192.168.0.1:1034 ESTABLISHED TCP 192.168.0.1:21 0.0.0.0:0 LISTENING TCP 192.168.0.1:2838 0.0.0.0:0 LISTENING TCP 192.168.0.1:2838 192.168.0.8:1060 ESTABLISHED TCP 192.168.0.1:23 0.0.0.0:0 LISTENING TCP 192.168.0.1:2080 0.0.0.0:0 LISTENING TCP 192.168.0.1:2080 192.168.0.2:1030 ESTABLISHED TCP 192.168.0.1:2080 192.168.0.2:1041 ESTABLISHED TCP 192.168.0.1:2080 192.168.0.3:1026 ESTABLISHED TCP 192.168.0.1:2080 192.168.0.3:1218 ESTABLISHED TCP 192.168.0.1:2080 192.168.0.7:1027 ESTABLISHED TCP 192.168.0.1:2080 192.168.0.8:1035 ESTABLISHED TCP 192.168.0.1:2080 192.168.0.8:1038 ESTABLISHED TCP 192.168.0.1:2080 192.168.0.8:1059 ESTABLISHED TCP 192.168.0.1:5924 192.168.0.3:1340 ESTABLISHED TCP 192.168.0.1:554 0.0.0.0:0 LISTENING TCP 192.168.0.1:53 0.0.0.0:0 LISTENING TCP 192.168.0.1:2871 0.0.0.0:0 LISTENING TCP 192.168.0.1:1080 0.0.0.0:0 LISTENING TCP 192.168.0.1:8000 0.0.0.0:0 LISTENING TCP 192.168.0.1:67 0.0.0.0:0 LISTENING TCP 192.168.0.1:1609 0.0.0.0:0 LISTENING TCP 192.168.0.1:1609 192.168.0.2:1059 ESTABLISHED TCP 192.168.0.1:80 0.0.0.0:0 LISTENING TCP 192.168.0.1:1618 0.0.0.0:0 LISTENING TCP 192.168.0.1:1618 192.168.0.2:1066 ESTABLISHED TCP 192.168.0.1:7000 0.0.0.0:0 LISTENING TCP 192.168.0.1:110 0.0.0.0:0 LISTENING TCP 192.168.0.1:368 0.0.0.0:0 LISTENING TCP 192.168.0.1:1914 0.0.0.0:0 LISTENING TCP 192.168.0.1:1914 192.168.0.3:1219 ESTABLISHED TCP 192.168.0.1:137 0.0.0.0:0 LISTENING TCP 192.168.0.1:138 0.0.0.0:0 LISTENING TCP 192.168.0.1:139 0.0.0.0:0 LISTENING TCP 192.168.0.1:2444 0.0.0.0:0 LISTENING TCP 192.168.0.1:2446 0.0.0.0:0 LISTENING TCP 192.168.0.1:2446 192.168.0.8:1041 ESTABLISHED TCP 192.168.0.1:1948 192.168.0.3:1049 ESTABLISHED TCP 192.168.0.1:2465 0.0.0.0:0 LISTENING TCP 192.168.0.1:2465 192.168.0.3:1028 ESTABLISHED TCP 192.168.0.1:2465 192.168.0.3:1032 ESTABLISHED TCP 192.168.0.1:3046 0.0.0.0:0 LISTENING UDP 0.0.0.0:1026 *:* UDP 0.0.0.0:1028 *:* UDP 0.0.0.0:1029 *:* UDP 0.0.0.0:1030 *:* UDP 0.0.0.0:1048 *:* UDP 0.0.0.0:2870 *:* UDP xxx.xxx.xxx.xxx:137 *:* UDP xxx.xxx.xxx.xxx:138 *:* UDP 127.0.0.1:1031 *:* UDP 127.0.0.1:8000 *:* UDP 127.0.0.1:368 *:* UDP 127.0.0.1:46789 *:* UDP 192.168.0.1:1031 *:* UDP 192.168.0.1:53 *:* UDP 192.168.0.1:2871 *:* UDP 192.168.0.1:8000 *:* UDP 192.168.0.1:67 *:* UDP 192.168.0.1:368 *:* UDP 192.168.0.1:137 *:* UDP 192.168.0.1:138 *:* UDP 192.168.0.1:3046 *:*

I've replaced my IP with xxxs

by **Rroff** » Dec 25 03 1:30 pm

restarted after the last post and was only up 3 hours before it happened this time, and ALL that was running was an FTP download and 2 idle IRC connections.

as I see it, something must have screwed up when I installed 5.2 (where I first encountered this error) and I'll need to remove wingate, do a complete removal of every file and registry entry and reinstall.

by **ngrayson** » Dec 26 03 7:17 am

Until I read this I had not checked the ports under netstat but I get the same issue, web pages on clients being served up with missging images etc.

I thought I was alone. I've seem it before and it disappeared, 5.2 was OK for me but it has now reappeared.

I have not checked and this is a guess but is it possible that an intrussion attempt is logged but the session/hence port is not removed?

by **ngrayson** » Dec 26 03 7:44 am

Just looked at this some more and I'm either barking up the wrong tree or barking mad, more likely the latter.

I did a whois on some of the addresses shown under foriegn on the netstat display. Interestingly, I can see no reason for my clients to have gone there. There are only three, I'm one and the other two are my kids and I know where they have been.

The addresses are not shown in the blocked firewall logs, and if you look at some of the port counts, they are increasing by one each time.

Is is possible that they are intrussion atempts or the result of port scans not blocked by the firewall which allow a session setup which decays into listening or timed_wait?

If I am barking mad the tell me to shut up although Pascal knows I have generally give good feedback.

by **ngrayson** » Dec 26 03 10:08 am

I know this is bitty but I'm reporting as I find.

I searched the logs and found that one of the Ip addresses I found under foriegn, had previously been blocked by the fire wall on numerous occassions on clear intrussion attemps. Interestingly, no such log for this session.

I'm personally convinced that these are dangling sessions left as a result of the firewall not blocking them properly and allowing a session to be set up.

Do you have any similar way of verifying this?

BTW befoe its suggested, defintly no viruses.

by **genie** » Dec 26 03 12:55 pm

Included in NetPatrol installer there is a tool called PortList which shows what application use4s this or that port - it might help. Also, try to figure out who uses this port 6667 - it might be an IRC or something malign.

by **adrien** » Dec 26 03 1:13 pm

Hi

One thing we found causes out of buffers errors was kernel memory leaks. I thought we patched the last of these with the release of 5.2 but it is possible something on your network is causing something like this.

The way to tell is by looking in Task Manager, in the performance tab, and seeing if over time (i.e. 10 hours or so) whether the nonpaged kernel memory keeps increasing

Adrien

by **Rroff** » Dec 26 03 2:48 pm

adrien, I had that problem with 5.2, but I ran 5.2.2 the first time for quite a while before the first instance of out of buffers crept up and memory useage was stable, prolly the best I've seen so far with wingate...

I wonder if this is a firewall issue however as mentioned above, because I do get very heavy numbers of connection attempts blocked by the firewall (atleast 20megs a day now in logging) and in the last 2 weeks or so it has been increasing dramatically, pretty much corresponding to these problems.

6667 is indeed IRC sessions, I have a private IRCd running here for testing scripts, etc. and have several users with persistant IRC connections, this has been so ever since I first started using wingate a few years back.

The only things I can possibly attribute this problem too are:

+Excessive number of firewall hits I'm currently experiencing (could explain why this problem occurred when internet access was otherwise almost idle)
+Something got screwed after installing 5.2
+Steam/Halflife, about the same time this started cropping up I had several users install the steam client to play HL/CS online.
+QuoteServ (small HTTP script I wrote to serve a random quote to my sig on other forums) - I've double checked and this is closing redundant connections correctly, however it does get a lot of connections throughout the day.

by **genie** » Dec 26 03 2:55 pm

Can you check the kernel non-paged memory as well (as Adrien suggested)? Wingate itself can be fine but the driver might have some problems - kernel non-paged memory can be a good indication of it.

by **Rroff** » Dec 26 03 2:57 pm

hmmm just realised a clean install prolly won't help, tho I'll try it, as the clean install on the win2k machine had similar problems... making me think even more that this is related to teh firewall.

by **Rroff** » Dec 26 03 3:05 pm

memory both paged and non-paged is holding steady at around the normal levels.

by **genie** » Dec 26 03 3:09 pm

I assume that just stopping and starting the engine does not help - but can the NAT clients connect or it is just a proxy-related problem?

by **Rroff** » Dec 26 03 3:14 pm

stopping and restarting the engine seems to help, but usually only as a temp measure, I usually have to reboot anyhow after 30mins or so (or I can keep restarting the engine every 30mins :D)

I don't know about NAT, since only visiting peeps use it (connect laptop to spare LAN port and let wingate NAT do the rest :D)

by **adrien** » Dec 27 03 7:57 pm

you can stop winGate from reporting firewall hits.. it is a bit convoluted, but to do so, you need to set up a port range which covers all ports, and set the action to deny (rather than relying on the default action), and uncheck the option "notify when this range is accessed". That should stop the ENS driver telling you about all the firewall hits, which if this is the problem, should alleviate things.

Problem is, that these hits are stored in memory in the engine until a GateKeeper logs in to see them.

Adrien

by **Rroff** » Dec 28 03 4:18 am

I'm gonna spend the weekend seeing if I can track down this problem, I'm not convinced its a firewall issue, but its the only thing I can see so far that would fit the problem.

WinGate Forums

5.2.2 out of buffers problem...

5.2.2 out of buffers problem...

Similar issue

Inrussion attemps or not?

some more

Who is online