GetURL failed - General transport failure. - winsock error -6

Usage and Config Platform
1

(imported topic written by SystemAdmin)

We seem to be getting this error on some clients that are outside our network. Not sure when it started, we just noticed it. The full error message in the logs is “RegisterOnce: GetURL failed - General transport failure. - winsock error -6”. The clients should be reporting into the DMZ relay we have set up. Instead they are trying to report in to the internal network relay, as if they were connected via vpn. If we initiate a VPN connection the client works fine or if we put the client on the inside network.

We have a BigFix Policy Action in place that is supposed to turn on “_BESClient_Comm_CommandPollEnable” when the ip address on the client does not match our network. I believe due to the error above, that action does not seem to happen on some clients even when the ip does not match. The relays.dat file on the client has an entry for the external ip address of the relay in the dmz, so we know the client is aware of it. A manual test from the client show the DMZ relay is accessible.

The problem really seems to be on the clients. Is this the expected behavior and is there a better way of forcing the clients outside the network to select the DMZ relay quicker?

2

(imported comment written by SystemAdmin)

Anyone? I’ve read the KB article on winsock errors (http://support.bigfix.com/cgi-bin/kbdirect.pl?id=273) which seems to confirm we expected = “-6 err_BAD_SERVERNAME The DNS name of the BES Server/BES Relay could not be resolved”.

So if it can’t resolve the name, shouldn’t it try a different relay?

3

(imported comment written by wnolan91)

I would suspect the following:

_BESClient_RelaySelect_IntervalSeconds is defaulted at 6 hours you may want to lower this… This is how often the BigFix Client will take to re-evaluate the BigFix Relays. What you may find helpful beyond the below Section, is to download the BigFix Client Diagnostics, from http://support.bigfix.com/bes/install/downloadutility.html and run the command:

BESClientDiagnostics.exe --runrelayselector

If your machines are set to use Automatic Relay Selection, you will need to ensure that the ICMP-Ping is enabled on the firewall from the client to the Relay, if they are never moving over to this relay.

Also, by default the

Take a look at the “BigFix Client Settings for BES Relay Control” section in http://support.bigfix.com/bes/misc/besconfigsettings.html

4

(imported comment written by SystemAdmin)

wnolan - we do indeed use auto relay selection which is set at the default 6 hours. But since the client is failing to communicate to that relay, wouldn’t this setting be more applicable - _BESClient_RelaySelect_MinRetryIntervalSeconds or perhaps _BESClient_RelaySelect_ResistFailureIntervalSeconds?

Thanks for the suggestion to use the diag tool. I did not realize it could troubleshoot relay selection issues. Below is the output. I guess a support call is in order.

======= Relay Selection ===========

Wait time out for tracert is: 100. Maximum num of hops is: 20.

  • BES Client autoselection value - 1
  • Parsing Relays.dat.
  • Number of Relays Found:4
  • Retrieving hop count and version information for each relay. (this may take a

while…)

DNS name IP Address Num Hops RelayVer

sion

123.123.123.123 123.123.123.123 20 7.2.5.22

Get Request Failed (http://relay1.company.LOCAL:52311/cgi-bin/bfenterprise/cl

ientregister.exe?requesttype=version) : 500 Can’t connect to relay1.company.L

OCAL:52311 (Bad hostname ‘relay1.company.LOCAL’).

relay1.company.LOCAL Unresolved Host Not Reached

Not Reached

Get Request Failed (http://relay2.company.LOCAL:52311/cgi-bin/bfenterprise/c

lientregister.exe?requesttype=version) : 500 Can’t connect to relay2.company

.LOCAL:52311 (Bad hostname ‘relay2.company.LOCAL’).

relay2.company.LOCAL Unresolved Host Not Reached

Not Reached

Get Request Failed (http://bigifx.company.LOCAL:52311/cgi-bin/bfenterpri

se/clientregister.exe?requesttype=version) : 500 Can’t connect to bigifx.

company.LOCAL:52311 (Bad hostname ‘bigifx.company.LOCAL’).

bigifx.company.LOCAL Unresolved Host Not Reached

Not Reached

Based on these results, BES Client should have chosen (hopcount 20):

123.123.123.123

BES Client last chose: bigifx.company.local

  • WARNING: BES Client has incorrectly chosen a BES Relay.
5

(imported comment written by BenKus)

Hey jspanitz,

If a client is using a relay in the network and then it moves outside the network, it will first report errors connecting to its relay (which will be in the log and you don’t need to worry about). It will retry a couple times based on the relay retry behavior and then it will give up and re-run relay autoselection to try to find a better relay (which in this case should be the DMZ relay).

Are you not seeing this behavior or were you just worried about the log error messages?

Ben

6

(imported comment written by SystemAdmin)

Ben,

We are not seeing the expected behavior. The test system I have never switches to the other relays. And I have had it on and off the corporate network / vpn / internet numerous times over a period of months. So far I am only seeing this on Win7 systems.

7

(imported comment written by wnolan91)

Jspanitz,

We’ve seen a similar issue, we had to make a choice of modifying the _BESClient_RelaySelect_MaximumTTLToPing, which we lowered to prevent exhaustive ICMP Ping Traffic of 255 HOPS, or put another DMZ Relay closer to the clients. In our case we opted to put another DMZ Relay in Asia, to keep the PINGs down.

I’m betting… as I’m a betting man… that you set this setting on your machines to also limit the number of PINGs each client will do. Now that you have hit the limit of “20” HOPs to this DMZ Relay, your machine does not connect. This gives you the intermittent issue, where some will connect as the number of HOPs is less than “20” and some will not connect, i.e. more than “20”.

Please let me know if I won my bet!

Bill

8

(imported comment written by SystemAdmin)

wnolan - you may have lost this one. we have not set that property. the farthest we have a client is 17 hops. the system in question is just 5 hops away. if it was the issue, wouldn’t we still see the client at least attempt to connect to the relay and then report back it was to far away - in the client log?

9

(imported comment written by wnolan91)

According to the posted

DNS name IP Address Num Hops RelayVer

sion

123.123.123.123 123.123.123.123 20 7.2.5.22

shows you are hitting 20 hops to this relay.

++++++++++++++++++++++++++++++++++++++++++

Ok, there is one other place where we have come into issues, although I’m not sure how big of an environment you have, but we have multiple Firewalls in our environment, and had to work with our networking folks to trace some packets coming in, to see that one of the Firewalls was not setup the correct way. i.e. missing ICMP-Ping, where some machines came into from one site would processes fine and then another client from a different connection going thru a different firewall would drop the ICMP-Ping packet giving the Winsock -6 error.

Good luck and would love to hear what the root cause is.

Bill

10

(imported comment written by SystemAdmin)

wnolan, you think I would have read my own post and realized it was 20 hops away. I pulled the hop count from web reports, thinking I’d see some high hop counts. Here is the REALLY strange thing - the problem client FINALLY switched relays late last night. I’m going to keep testing to see if it switches back, but I can honestly say this makes no sense.

11

(imported comment written by SystemAdmin)

So we kind of lost track of this and finally got back around to troubleshooting the problem.

Again, we are only seeing this with Win7 and version 7 or 8 client agents. When we manually stop and then start the client agent - 95% of the time the agent shuts down and logs and error. Wait a few hours or rebooting seems to resolve the issue, as does manually creating the directory.

At 16:38:46 -0400 - Starting client version 8.0.584.0 FIPS mode disabled by default. At 16:38:47 -0400 - Restricted mode At 16:39:03 -0400 - RegisterOnce: Attempting to register with 
'http://bigfixserver:52311/cgi-bin/bfenterprise/clientregister.exe?RequestType=RegisterMe60&ClientVersion=8.0.584.0&Body=6721367&SequenceNumber=7315&MinRelayVersion=6.0.0.0&CanHandleMVPings=1&Root=http://bigfixserver%3a52311&AdapterInfo=00-00-00-00-00-00_192.168.2.0%2f24_192.168.2.96_1&AdapterIpv6=00-00-00-00-00-00%5efe80%3a%3a5587%3ae6fe%3a1225%3a92a8%2f64_1' RegisterOnce: GetURL failed - General transport failure. - winsock error -6 Unrestricted mode Configuring listener failed to initialize as wake-on-lan forwarder(AdapterInfo=). At 16:39:06 -0400 - Unhandled error: File error 
"class FilePermissionError" on 
"C:\Program Files (x86)\BigFix Enterprise\BES Client\__BESData\__UICache": Windows Error: 5: Access is denied. Client shutdown (Unexpected error)

Originally we thought the winsock error was the issue, but now we know that it is actually due to the __UICache folder not being created successfully after we manually stop and restart the agent. If we manually create the folder and then manually start the agent the agent starts right up. Or if the folder does not exist and we reboot, the folder gets created and the agent starts up.

I know a support call is in order, but wanted to see if anyone else can duplicate or has experienced the problem.

12

(imported comment written by SystemAdmin)

FWIW - we still don’t have an answer, but we isolated this to clients that are behind a firewall (not the OS firewall, but an actual firewall). Even thought the firewall allows outgoing connections on 52311 and we can telnet to the dmz relay via its internet ip address on port 52311 and we can open a browser and paste the url that the client is trying into IE and connect successfully, the bes client itself can’t figure out to use that relay and make the connection.

13

(imported comment written by SystemAdmin)

Seems like every few months I start looking at this again, thinking I’ll find the answer.

Clients that are remote continue to randomly report / not report in. The errors range from winsock error -6 to winsock error -8. We’ve had the same 3 relays for 2 years. We have a single DMZ relay. The same client at the same remote locate one time will connect, the next time it will not. There is no rhyme or reason. We can take the url and paste it into a browser and connect right up to the relay. We can ping the relay. There are zero connection problems and the ONLY application having connection issues is the TEM Agent.

Take the system I am on right now. Last night, it failed to connect, tonight BINGO, it connects right to the relay. It’s almost laughable at this point. I’m betting most other companies are having the same problem but don’t even know it. Unless you regularly police your client log files.

Please fix this issue.

14

(imported comment written by MrFixit)

Something similar that I see is that if the client IP or some NIC changes are made causing the NIC to cycle after the BESclient has loaded I can get similar Winsock errors. Recycling the BESClient resolves every time.

15

(imported comment written by mmcgrew91)

I had a similar problem and had clients not reporting in. Setting the _BESClient_RelaySelect_FailoverRelay to the IP of the relay in the DMZ solved it for me.