Jump to content
The simFlight Network Forums

WideFS: ServerName OK, but ServerIPAddr not ?


Recommended Posts

Hello,

first off, please note: My problem is already solved :grin:

This message is based on mere curiosity (also with a view to possible future related issues).

I have been running (for years) a setup with FS9 on box A (locally 192.168.255.55) and all sorts of add-ons on Box B (192.168.255.66); both "connected" via WideFS. Has always worked like a charm.

Today I found out it had ceased to do so: both WideFS server and client kept waiting for a connection, but none was ever made.

The only change in the setup had been that due to an ISP change I had taken into use a new ADSL modem/router; same model as before, with almost same settings, except for the subnet 192.168.255.* addresses which now are 192.168.1.*

(I realize that the router should be irrelevant for the WideFS connection anyway, as long as the boxes can see each other at all; but read on.)

The WideClient.ini had so far contained only an entry for ServerIPaddr, and I had of course changed that from 192.168.255.55 to 192.168.1.55, i.e. to the new IP address of box A. Still no connection.

More or less by lucky guess I then disabled the ServerIPaddr entry and added a ServerName=ABC one.

And lo and behold! instant success -- everything works again.

No changes in hardware/software firewall or NAT settings were required.

This quite surprises me (hence the curiosity) -- I have always thought, explicit numerical IP addresses are the "safer bet" (because they don't require name resolving which can be an added source of problems.)

How can that be?

Why can my WideFS client not handle the server IP address any more, but will still run fine when given the server name instead?

(BTW I did check with ping, and it worked OK for both IP address and machine name, so it's not a matter of me mis-associating numbers and names.)

Inquiring minds want to know.

Thanks in advance for any enlightenment!

Cheers,

Martin

Link to comment
Share on other sites

The only change in the setup had been that due to an ISP change I had taken into use a new ADSL modem/router; same model as before, with almost same settings, except for the subnet 192.168.255.* addresses which now are 192.168.1.*

(I realize that the router should be irrelevant for the WideFS connection anyway, as long as the boxes can see each other at all; but read on.)

If you haven't set fixed IP addresses for your PCs and let them get them automatically instead, then the router is very important for the IP addresses as it is probably that which is assigning them.

The WideClient.ini had so far contained only an entry for ServerIPaddr, and I had of course changed that from 192.168.255.55 to 192.168.1.55, i.e. to the new IP address of box A. Still no connection.

More or less by lucky guess I then disabled the ServerIPaddr entry and added a ServerName=ABC one.

it is almost always better to set the Server's name rather than its IP Address as then WideClient obtains the IP address from Windows, which should of course keep track of changes and of dynamic assignments if you leave the system to those.

This quite surprises me (hence the curiosity) -- I have always thought, explicit numerical IP addresses are the "safer bet" (because they don't require name resolving which can be an added source of problems.)

No, it's normally the other way around -- Server Names are more reliable. The facility to provide the address is there to override Windows in certain strange cases (which no one has ever explained) where Windows sometimes seems to provide Internet IP addresses instead, generally one the ISP might assign. This peculiarity seems to be related to ceretain router types and settings.

Why can my WideFS client not handle the server IP address any more, but will still run fine when given the server name instead?

The IP address is what is actually used, so if you give the exact same one as Windows gives for the Server Name, then there is absolutely no difference. Evidently that is not 192.168.1.55. In fact it seems most unlikely that when you changed the router it changed the subgroup address from 192.168.255 to 192.168.1 but coincidentally assigned 55 like the previous router. That's actually very difficult to understand. Why 55? Where did it get that from?

Just check the WideClient log file. It will show the IP address it uses, even if you set a Name.

Regards

Pete

Link to comment
Share on other sites

Wow, that was fast, thanks for the informative reply!

If you haven't set fixed IP addresses for your PCs and let them get them automatically instead, then the router is very important for the IP addresses as it is probably that which is assigning them.

What I had (stupidly) forgotten to mention was that I have indeed set up static DHCP, i.e. the boxes always get the same 192.168.1.55 (and *.66, resp.) address.

...it is almost always better to set the Server's name rather than its IP Address as then WideClient obtains the IP address from Windows, which should of course keep track of changes and of dynamic assignments if you leave the system to those. [...]

No, it's normally the other way around -- Server Names are more reliable.

OK, thanks, I knew I would learn something useful!

In fact it seems most unlikely that when you changed the router it changed the subgroup address from 192.168.255 to 192.168.1 but coincidentally assigned 55 like the previous router. That's actually very difficult to understand. Why 55? Where did it get that from?

Again, I was not precise enough. As said above, the 55 was set up by me in static DHCP also for the new router, hence the same as before.

The different subgroup (192.168.1.* instead of the previous 192.168.255.*) came from the router presets the new ISP had done already, and which I did not dare to change back to the previous 192.168.255.*

Just check the WideClient log file. It will show the IP address it uses, even if you set a Name.

With a WideClient.ini entry of

ServerName=AB1234

the client log now (with connection OK) shows

735 ... Okay, IP Address = 192.168.1.55

5547 Connection made okay!

which is what I would expect.

But if I use exactly the same IP number (instead of ServerName)

ServerIPAddr=192.168.1.55

it does not work; the log gives me only

********* WideClient Log [version 6.615] Class=FS98MAIN *********

Date (dmy): 05/10/11, Time 16:00:43.437: Client name is AB1234

203 Opening GPSout port COM3, speed=9600 -- OK!

250 Attempting to connect now

672 Trying to locate server: Protocol not yet decided

672 Failed to connect: waiting to try again

2719 Attempting to connect now

But no problem, I shall just stick to the ServerName parameter in the future.

Cheers,

Martin

Link to comment
Share on other sites

What I had (stupidly) forgotten to mention was that I have indeed set up static DHCP, i.e. the boxes always get the same 192.168.1.55 (and *.66, resp.) address.

So you also had to manually change the 255 to 1?

With a WideClient.ini entry of

ServerName=AB1234

the client log now (with connection OK) shows

735 ... Okay, IP Address = 192.168.1.55

5547 Connection made okay!

which is what I would expect.

But if I use exactly the same IP number (instead of ServerName)

ServerIPAddr=192.168.1.55

it does not work; the log gives me only

Well that is completely weird, because all using the Server Name does is ask Windows for the IP address instead of reading it from the INI file. After that the code is common. It uses whatever IP address that was supplied either which way.

All I can imagine happening is that there is some glitch in Windows + Ethernet driver which only "wakes up" to the correct existence of that IP address when Windiows has already prompted. How that could be I'm afraid I haven't the foggiest. I've never seen such a thing reported before!

********* WideClient Log [version 6.615] Class=FS98MAIN *********

Version 6.615 of Wideclient is pretty old now and unsupported for a long time. Version 6.86 is current.

But no problem, I shall just stick to the ServerName parameter in the future.

Have you thought of letting it all connect automatically, as it is really designed to do? You just have to make sure that all your PC's are in the same WorkGroup, as stated in the Dox. Then you don't need ServerIPAddr, ServerName, or Protocol lines in the WideClient INI file at all. It is all controlled from the Server.

Regards

Pete

Link to comment
Share on other sites

Thanks again!

So you also had to manually change the 255 to 1?

Correct.

Well that is completely weird

I agree. :grin:

(My problem is that I do not really understand the role of those IP subnets (the third number in the address); that's why I did not dare to change them back from 1 to 255 in the router. And I have no clue if, how, and why a change in the subgroup would make a difference.)

Version 6.615 of Wideclient is pretty old now and unsupported for a long time. Version 6.86 is current.

I am always behind the times, because if I can help it, I don't want to take onboard too much FSX-related stuff which from my point of view is just ballast. :grin:

But I'll check out the newer versions, thanks for the tip.

Then you don't need ServerIPAddr, ServerName, or Protocol lines in the WideClient INI file at all. It is all controlled from the Server.

Well, I had never tried that because my "legacy" setup has so far always worked. But I tested it now, and indeed, I can leave both ServerName and ServerIPAddress out, and still get a functioning connection.

Excellent!

Thanks again for the quick response; nothing beats support straight from the author. :)

Cheers,

Martin

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.