Socket Error For Users

[MattP]

Hi,

We should have a beta release ready by midweek next week which should address the DNS problems.

Regards,

Matt

[tpateman]

Hi,

Can I ask for an update? Has this beta version gone ahead? Is there a full release due out? Thanks in advance. Timothy.

Hi,

We should have a beta release ready by midweek next week which should address the DNS problems.

Regards,

Matt

[MattP]

Hi,

We hope to have the beta out soon, but at this stage we haven't got a firm time for release.

Thanks,

Matt

[tpateman]

Hi,

Any news Please? A month since your last post, have you made any progress?

Thanks, Timothy.

Hi,

We hope to have the beta out soon, but at this stage we haven't got a firm time for release.

Thanks,

Matt

[Pascal]

The first beta was release some time ago. A second beta is due shortly, probably within the next week or so. (But that's not a firm time)

[tpateman]

Should I install this beta or wait for the next beta to be released? Where can I get the beta's from?

Or should I wait till a full release is out and not install a beta version as I will be putting it live to my users. Thanks.

The first beta was release some time ago. A second beta is due shortly, probably within the next week or so. (But that's not a firm time)

[Pascal]

I'd recommend waiting for the next BETA. It has significant improvements over the previous BETA and it is due shortly.

Do you have a 'psuedo' live machine you can test the setup with first, though ?

[tpateman]

I'd recommend waiting for the next BETA. It has significant improvements over the previous BETA and it is due shortly.

Do you have a 'psuedo' live machine you can test the setup with first, though ?

We do not have any test machine, only a live one which the users use. We can not test the beta before it is in the live which is maybe why I should wait for the next main release?

Thanks, Timothy.

[MattP]

Hi Timothy,

That's probably a good idea, we've released Release Candidate 1 which should be pretty good, but if you need to be sure then you can wait.

Matt

[tpateman]

Hello,

I see that V6 has now been released, our license key is only for version 4 can we upgrade? Is it just an install over the top like the others times we have upgraded.

I looked through the list of updates for V6 but I could not see anything relating to my problem even though I was advised this was getting looked at in the next version release.

This problem with 'Socket Error' has been going on for some time since October 2003 well over 6 months ago! Please can someone advise me if my problem has been looked into and fixed?

Any advice would be great,
Thanks, Timothy.

[kgoodknecht]

Hello,

I see that V6 has now been released, our license key is only for version 4 can we upgrade? Is it just an install over the top like the others times we have upgraded.

I looked through the list of updates for V6 but I could not see anything relating to my problem even though I was advised this was getting looked at in the next version release.

This problem with 'Socket Error' has been going on for some time since October 2003 well over 6 months ago! Please can someone advise me if my problem has been looked into and fixed?

Any advice would be great,
Thanks, Timothy.

If you don't mind if I jump in here, what port is the Wingate Proxy listening on?
What OS is the Wingate server on and does it have a webserver running on it?

[Pascal]

Yes, you can use it with a version 4 license key. Some of the new features (Bandwidth Control, WRP Central Configuration, Email Server might not be available) You do get all the stability and performance improvements, bug fixes, etc.

We've made significant improvements in the web-browsing side of things - adding HTTP 1.1 support with a whole slew of related improvements. This coupled with the driver improvements and general stability improvements as well as an improved DNS means your problem might very well be resolved (Even if not listed in the readme / forums)

[tpateman]

If you don't mind if I jump in here, what port is the Wingate Proxy listening on?
What OS is the Wingate server on and does it have a webserver running on it?

Hello,

No I don't mind any help is great as this problem has been going on far too long! The Wingate Proxy is listening on the normal port 80, the Wingate server is on Windows 2000 server in a W2K network.

[kgoodknecht]

If you don't mind if I jump in here, what port is the Wingate Proxy listening on?
What OS is the Wingate server on and does it have a webserver running on it?

Hello,

No I don't mind any help is great as this problem has been going on far too long! The Wingate Proxy is listening on the normal port 80, the Wingate server is on Windows 2000 server in a W2K network.

Is IIS installed?

Try moving the Wingate proxy to another port, or for that fact leave the proxy intact and create a new WWW proxy service on port 81 or port 8080, then use that as your proxy port in IE. If it works and you have a Win2k Active Directory domain, you can push the setting to all clients using group policy.

Also, if this is Active Directory, you have to disable the Wingate DNS service and use the Win2k DNS service, because it is the one that will have your Domain Controller records in it.

[__Ranger]

I have the same problem. Wingate log:

Error: Caught socket exception in CWWWSession::HTTPProcessRequest() Connection to Remote Host timed out - terminating

Win2000 Server, LAN, no IIS. This happens not only with http proxy, but with mapped links too. I got this error in version 5.x, then install 6.0 RC2, but nothing changed.

[Firefly]

Hi, readers of this painful topic.

We used to have the very problem. Socket Error (Connection to Remote Host timed out). At least 100 times a day, on

every PC using the WWW Proxy Server, and when browsing just about any web site.

But the problem has completely and permanently gone away.

WinGate 6 solved the problem for us. But it did not solve the problem automatically. We had to choose a setting or two which to my knowledge had not been available in WinGate 5.

Here's our scenario:

We have 2 broadband routers which I will call "DSL-A" and "DSLB". "DSL-A" has IP number "IP-A" and uses gateway "GW-A".

"DSL-B" has IP number "IP-B" and uses gateway "GW-B". The two are on different subnets, to keep routing simple.

We have our WWW Proxy server set so that the outgoing connections to the internet are rotated between the two devices.

Now in WinGate 5 one could only select which devices to rotate by choosing the IP. So we were rotating between IP-A and IP-B.

The same place in the WinGate 6 Gatekeeper lets one choose the device by name rather than by IP, so now we rotate between

"DSL-A" and "DSL-B". Unlike WinGate 5, WinGate 6 lets one *EDIT* some parameters for each of these. The default setting (which kept on causing these socket errors) is to use "Any gateway" and "Any IP address" for each device.

As soon as I specified that DSL-A *must* use gateway GW-A and address IP-A, and that DSL-B *must* use gateway GW-B and address IP-B, our problem was gone for good!

(Of course these same IP and gateway settings are also set like that in the network properties of the operating system, but that was not enough. WinGate had to be forced in Gatekeeper as well, for the problem to go away.)

My conclusion is that our problem had nothing to do with DNS or traffic load. It must have been about routing.

Perhaps the developers can use this information now, to say how one can effectively choose the same settings in WinGate 5. There may be some undocumented registry settings. Or perhaps one can define some static routes to force the routing to work the right way.

Or perhaps everybody can upgrade to WinGate 6 and then choose settings as above?

*giggle*

[adrien]

OK, this is the difference between the Interfaces tab in WinGate 5.x and the Gateways tab in WinGate 6.0

In WinGate 5.0 and earlier versions, the Interfaces tab, if used, would cause sockets used for connections made by a service to be bound to a specified local address first. What this would do, is make the source IP address specified prior to making a connection (rather than unspecified). Normally, the OS chooses which source address to use on a connection based on the route table.

The problem with this method, was that we would set the source address, and connect out. However the OS ignores the source address when routing, so say we had 2 interfaces, interface A with IP A and GW A, and interface B with IP B and GW B, then even if we set the source address of a connection to IP A, if GW B had priority in the route table, then the packets would go out interface B to GW B, not A.

The physical symptoms of this would be that say you had 2 modem connections, all outbound packets would go out one interface regardless.

Looking in the route table, there would be 2 default routes (network destination 0.0.0.0). Since a default route matches all destinations, the OS would not know where to send a packet, and so sends the packets out the route with the lowest metric. When other default gateways are added by dialup etc, the existing default routes have their metrics increased (deprecated), so if other dialups come and go, this could break existing connections.

This also meant that this method could not be used to go through an upstream NAT, since the source address would be wrong for that interface, the NAT wouldn't be able to return packets.

The final problem was that the previous version couldn't cope with 2 gateways on a single interface.

So, in WinGate 6.0, we decided to solve all these problems by pre-creating a hash entry in our NAT driver for outbound connections, specifying which interface to use, and which next hop gateway to use. Then no matter how badly the OS messed up the routing (and believe me it does), we could fix it.

This means that when a connection is made with a specified gateway, we pre-create a hash entry, then bind the socket to the specified interface address (which sets the source IP on the packets), then make the connection. When we see the packet coming down the stack in our driver, if it is not coming down on the interface we specified, we re-direct it, and re-write the MAC addresses on the packet so that it goes to the right gateway.

This works like a charm in all the scenarios we have tested it in. The one restriction we applied was that you can only specify a gateway to use if there is such a gateway (corresponding to a default route in the route table) in the OS.

We could even allow users to manually add gateway IP addresses also if there was any sort of demand for it, that would allow you the benefits of multiple gateways, without creating headaches for your OS routing system by having multiple default routes to go with it.

Adrien

[tpateman]

Hello,

Thank You for the update and I can see everyone has been busy with the new look and new feature's of WinGate how ever even these new feature's have not fixed my problem of the 'SOCKET ERROR'. This problem is still happening to users and still far to often as I am sure you would agree that this error message should never happen. Please can someone advise what we could do to fix this problem?
Thanks, Timothy.

[adrien]

OK, if it is a routing problem, can you please go to the command prompt, and type "route print" and cut and paste what output you get back in here?

Then we can see if there is a problem with your route table.

Adrien

[tpateman]

OK, if it is a routing problem, can you please go to the command prompt, and type "route print" and cut and paste what output you get back in here?

Then we can see if there is a problem with your route table.

Adrien

Thanks, I have done this Please can I have your email address to send this to you. Thanks, Timothy.

[Pascal]

At the bottom of each post are buttons - one of them is "Email". Adrien's email is adrien at qbik dot com

[adrien]

Hi

I note you have 2 default routes.

One obviously going to the Internet, and another to some gateway on your internal network?

This will cause confusion for your system router on that machine, as it has no information about whether it should send a packet that needs to go to the internet, to your internet gateway, or to your internal one.

Does the machine 10.0.X.X have an internet connection as well? Or is it a gateway to other subnets on your LAN? If the latter, you are better off adding specific routes to these other subnets and removing the default gateway setting from your internal adapter.

Adrien