Jump to content
The simFlight Network Forums

Recommended Posts

Posted

I have always used "ServerNode=0.0.39010.53038.58815" in my Wideclient.

I got the node from the Wideserver log (a long long time ago) but have not changed anything in the network for a long time so have had no cause to change it.

However I have just noticed that the Wideserver log is now reporting a different node - 64828 ServerNode=13330.61389.0.0.512

(? this happened when changed to 6.4.1 - but don't know this for sure because I've just noticed it).

The problem is that if I use the new node as reported, it doesn't work and Wideclient can not find the network. If I continue to use the old node as I always have done, then everything is fine. ?????

Here are the initial sections from the logs for a session which works - you will see that the nodes which connected successfully are different from that reported by Wideserver.

NB I have just put in the first part of the logs to save space here:

********* WideServer.DLL Log [version 6.41] *********

Blocksize guide = 4096 (double allowed)

Date (dmy): 14/11/04, Time 10:28:09.015: Server name is MAINCOMPUTER

64828 Initialising TCP/IP server

64828 Initialising IPX/SPX server

64828 ServerNode=13330.61389.0.0.512

76813 Restarting service due to total lack of use

131297 Incoming connection Accepted ok (skt=4212)

131735 Connected to computer "LAPTOP" (skt=4212)

266406 Incoming connection Accepted ok (skt=1852)

266485 Connected to computer "PFD" (skt=1852)

********* WideClient.DLL Log [version 6.41] Class=FS98MAIN *********

Date (dmy): 14/11/04, Time 10:29:20.010: Client name is LAPTOP

748 Attempting to connect now

1306 Trying IPX/SPX on Port 8002, Node 0.0.39010.53038.58815 ...

6646 Connection made okay!

30965 New Client Application: "CDU" (Id=-261871)

********* WideClient.DLL Log [version 6.41] Class=FS98MAIN *********

Date (dmy): 14/11/04, Time 10:31:44.843: Client name is PFD

500 Attempting to connect now

500 Trying IPX/SPX on Port 8002, Node 0.0.39010.53038.58815 ...

532 Connection made okay!

6516 New Client Application: "pfd" (Id=1248)

Not sure if this is a problem / bug / or something wrong with my network?

Regards,

Stuart

Posted
However I have just noticed that the Wideserver log is now reporting a different node - 64828 ServerNode=13330.61389.0.0.512

(? this happened when changed to 6.4.1 - but don't know this for sure because I've just noticed it).

Ouch!

I've tried going back even to 6.22. That does the same! In fact the same wrong ServerNode (the same one you get now) is provided on all my systems for all versions of WideServer I can find.

I thought this might have been something trivial, but it isn't. I've compared the code which gets this data with some old archive code I have going back two years, and it is the identical! The only change on my systems is that my Windows XP systems are now SP1 whereas when I first did tests of IPX/SPX on WinXP (and found it was problematic) this was with the very first WinXP releases.

This is going to need some research. I only knew one way of getting this information, and now, for reasons presumably best known to Microsoft, that doesn't work. Ugh ...

[LATER]

Yes, this is definitely a change in Windows XP -- I've just tried version 5.40 of WideServer in FS2002, and that gives the same identically bad node number. On the other hand, the very latest WideServer, running on Windows 98SE, is fine!

I don't know if this is a bug in XP SP1 which is fixed in SP2 -- what operating system version are you using?

Regards,

Pete

Posted
I don't know if this is a bug in XP SP1 which is fixed in SP2 -- what operating system version are you using?

Sorry Pete - I'm using XP with SP2 !

I am absolutely positive that I got the initial (correct) node when using XP (though if it was before or after I got SP1 I don't know).

Regards,

Stuart

Posted

Sorry Pete - I'm using XP with SP2 !

Ah, thanks. That saves me installing it just to see.

I am absolutely positive that I got the initial (correct) node when using XP (though if it was before or after I got SP1 I don't know).

I too am absolutely positive that it was all okay in WinXP, at one time. It was a load of testing in XP that made me add TCP/IP!

Something has gone wrong in XP since it's initial release. :-(

I don't know how to work around this at present, other than manually finding the MAC address as described in the WideFS DOC (troubleshooting tip 7).

BTW, if your Server is running Win98SE, no matter what the Clients are running, IPX/SPX works fine with no ServerNode needed whatsoever. Win98SE also gives the correct Node details, even though they aren't really needed!

Daft.

Regards,

Pete

Posted

I found out what is going on, but not why nor how to get around it by program. However, you can get around it by changing your IPX/SPX configuration slightly, in Windows. In fact it may work better if you do. Let me explain.

If found a program, available in all WinXP installations, which gives you a list of IPC/SPX "addresses". It is IPXROUTE. If you open an MSDOS window (run, and enter COMMAND will get you one), then enter

IPXROUTE config

and press return, you will get something like this:

NWLink IPX Routing and Source Routing Control Program v2.00


Num  Name                      Network    Node           Frame
===============================================1.   IpxLoopbackAdapter        1234cdef   000000000002   [802.2]
2.   Local Area Connection 5   00000000   0040f453e76c   [EthII]
3.   NDISWANIPX                00000000   f03520524153   [EthII] -

Legend
======
- down wan line

What seems to be happening, on WinXP only I think, is that this "IpxLoopbackAdapter", whatever that is, is getting in the way. The numbers you saw reported for the ServerNode are those: 1234CDEF etc. The ones we need are those for the Local Area Connection, in this case the 2nd address.

I think this "IpxLoopbackAdapter" has been added to WinXP since the original release. I also think it may be slowing things down a tad, which may explain why I measure only a little speed difference with IPX/SPX over TCP/IP. That's only theory -- I'l see if I can find time to do some tests in the week.

Anyway, the problem only seems to arise with WideServer if you have the same frame type running on the Local connection as on this mysterious Loopback thingy. If you let the Frame type set "auto", it will choose 802.2 and that creates the problem.

The solution appears to be to assign a different frame type. I've used Ethernet II and that seems to work very well.

You'll need to do this on the Server PC and on all Clients. This is how:

On WinXP:

-- Network properties

-- -- select NWLink IPX/SPX

-- -- -- properties

-- -- -- -- Frame Type: select "Ethernet II".

On Win98SE:

-- Control Panel -- network

-- -- Select IPX/SPX

-- -- -- properties

-- -- -- -- Advanced

-- -- -- -- -- Frame Type, select "EtherNet II".

I'll post this as a Sticky, above, too. If I can find a programmatic solution to it I will implement one, else I will just put all this in the WideFS documentation too.

Regards,

Pete

Posted

Further news on this:

With Katy Pluta's help, I found another, possibly easier, way to fix the wrong reporting of the ServerNode -- disable network authentication on the Server.

I've documented it now in the revised Sticky thread near the top of the Forum.

Regards,

Pete

Posted

Pete,

This works great but I am not sure about disabling the network authentication - I already had this disabled and it did not seem to make any difference to reporting the server node.

The thing that did it for me was changing to Ethernet II instead of AUTO as you describe. Again this had to be done on ALL PC's (not just the server) and regardless of Win98 or XP for it to work.

I also found out that if you have a network bridge on WinXP (if you use WinXP's network setup wizard it will probably configure this even though it may not be needed), then you need to remove your LAN connection from the bridge for this all to work.

After removing from the bridge and reconfiguring as EthernetII, I am now using IPX on 3 clients with Wideserver and things have never been smoother!!!!!!!!!!!!

Now just quickly looking for the piece of wood to touch!

Regards,

Stuart

Posted

This works great but I am not sure about disabling the network authentication - I already had this disabled and it did not seem to make any difference to reporting the server node.

Hmmm. It did here -- but I admit I tried changing the Frame type first. When Katy suggested the Authentication, I put the frame type back to Auto and disabled Authentication, and it was okay. But maybe changing frame type altered something else more permanently. Hmmm.

The thing that did it for me was changing to Ethernet II instead of AUTO as you describe. Again this had to be done on ALL PC's (not just the server) and regardless of Win98 or XP for it to work.

Yes, even though they say "auto detect", it doesn't appear to successfully do so. I have mentioned that. But I'll do some more tests with Authentication. Maybe I'll change the wording to "try this, but if not, then ...".

I also found out that if you have a network bridge on WinXP (if you use WinXP's network setup wizard it will probably configure this even though it may not be needed), then you need to remove your LAN connection from the bridge for this all to work.

You've lost me there. How do i see if I have one and then remove it? Isn't a bridge something that joins two Networks?

After removing from the bridge and reconfiguring as EthernetII, I am now using IPX on 3 clients with Wideserver and things have never been smoother!!!!!!!!!!!!

Is the original slow/reconnecting start-up fixed too now?

Regards,

Pete

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.