lupa2 Posted October 13, 2017 Report Share Posted October 13, 2017 (edited) Hello everyone The issue I've run into is fairly simple. I'm running WideFS server registered on my sim PC and wideFS client on my Surface. When I run the wideFS client normally it connects to the server just fine but it won't produce GPS output (which I need for Jepp FliteDeck), and when I run it as admin it does generate GPS data (can be monitored in VSPE, the client is writing data to the connector), but the client won't connect to the server anymore. I'm pulling my hair out over this one, maaybe you can help Cheers Luca Edit: Just for additional info, seems like WideFS Client is running version 6.999z4, WideFS Server is on 7.971 and FSUIPC is on version 5.121b, same behaviour with version 4.971 though Edited October 13, 2017 by lupa2 Link to comment Share on other sites More sharing options...
Thomas Richter Posted October 13, 2017 Report Share Posted October 13, 2017 Hi, user privilegs are locally on that PC and don't effect PC's over the network. If the Client doesn't connect when running with administrator privilegs it will be most likely a firewall serttingthat isolates WideClient. Thomas Link to comment Share on other sites More sharing options...
lupa2 Posted October 13, 2017 Author Report Share Posted October 13, 2017 I have both ports 8002 and 9002 excluded from the firewall on both TCP and UDP both in and out, shouldn't be an issue I don't think, I also don't kow how that would be affected by user privileges Link to comment Share on other sites More sharing options...
Pete Dowson Posted October 13, 2017 Report Share Posted October 13, 2017 2 hours ago, lupa2 said: Edit: Just for additional info, seems like WideFS Client is running version 6.999z4, WideFS Server is on 7.971 and FSUIPC is on version 5.121b, same behaviour with version 4.971 though There's no separate "WideFS server", it is part of FSUIPC. The number 7.971 just indicates it is running in FSUIPC5 but is at the same level and FSUIPC 4's 4.971 version. When you have a communication problem betwen Server and Client you should provide the loags -- wideserver.log and wideclient.log. 1 hour ago, lupa2 said: I have both ports 8002 and 9002 excluded from the firewall on both TCP and UDP both in and out, shouldn't be an issue I don't think, I also don't kow how that would be affected by user privileges Nothing to do with network exchanges should be affected by process privilage levels. 2 hours ago, lupa2 said: when I run it as admin it does generate GPS data (can be monitored in VSPE, the client is writing data to the connector), but the client won't connect to the server anymore. How is it producing data if it isn't receiving any? It only pases on what it receives. I have never needed to run WideClient in elevated privilage mode for any application, so something is odd in that Client system somewhere. VSPE presents a virtual port, which is at system level, nothing user or admin level at all, so those are really irrelevant. Pete Link to comment Share on other sites More sharing options...
lupa2 Posted October 14, 2017 Author Report Share Posted October 14, 2017 Hi Pete Thanks for the swift response, let's hope we can get this resolved before CTP :P Anyways, logs attached below, also my diagnosis flow in images here: https://imgur.com/a/6BP2W Hope this helps you figure out this mess Thanks! Luca Elevated user privileges WideClient.log WideServer.log Regular user privileges WideClient.log Link to comment Share on other sites More sharing options...
Pete Dowson Posted October 14, 2017 Report Share Posted October 14, 2017 1 hour ago, lupa2 said: Anyways, logs attached below, Ah, now it is clearer. The elevated session appears not to receive broadcasts, so it doesn't know the name of IP addressof the Server. See, the successful connection in the "regular" log: 156 Attempting to connect now 156 Trying to locate server: Need details from Server Broadcast 156 Failed to connect: waiting to try again 1172 Attempting to connect now 2188 Server = LUCAPC 2203 Trying TCP/IP host "LUCAPC" port 8002 ... 2203 ... Okay, IP Address = 192.168.1.10 2203 Connection made okay! compared with this for the elevated log: 156 Attempting to connect now 188 Trying to locate server: Protocol not yet decided 188 Failed to connect: waiting to try again 1219 Attempting to connect now 22531 Trying to locate server: Protocol not yet decided Try putting the ServerIPAddr parameter into the WideClient.INI file, and Protocol=TCP or UDP, as you wish. This is the first thing to try when connections aren't being made -- it is documented in the WideFS User Guide, in the part imploring readers to read at least part of it! Pete Link to comment Share on other sites More sharing options...
lupa2 Posted October 14, 2017 Author Report Share Posted October 14, 2017 I should have attached my WideFS.ini, sorry for that. Adding the serverIPAddr parameter was the first thing I did when this issue came up, read the docs back and forth trying to figure it out. I might try the protocol =TCP setting, didn't think it'd have an impact as it works on regular user privileges ; PLEASE SEE WideFS documentation for parameter details ; ===================================================== [Config] ServerIPAddr=192.168.1.10 Port=8002 Window=924,452,886,589 Visible=Yes ButtonScanInterval=20 ClassInstance=0 NetworkTiming=5,1 MailslotTiming=1000,1000 PollInterval=2000 Port2=9002 ReconnectMinutes=0 ResponseTime=18 ApplicationDelay=0 TCPcoalesce=No WaitForNewData=500 MaxSendQ=100 OnMaxSendQ=Log NewSendScanTime=50 Priority=3,1,2 ; ----------------------------------------------- [User] Log=Errors+ [GPSout] Port=COM1 Speed=19200 ; =============================================== [Sounds] Path=C:\Program Files (x86)\WideFS\Sound\ Device1=Primary Sound Driver Device2=Speakers (Realtek High Definition Audio(SST)) Link to comment Share on other sites More sharing options...
Pete Dowson Posted October 14, 2017 Report Share Posted October 14, 2017 4 minutes ago, lupa2 said: I should have attached my WideFS.ini, sorry for that. Adding the serverIPAddr parameter was the first thing I did when this issue came up, read the docs back and forth trying to figure it out. I might try the protocol =TCP setting, You need the Protocol parameter as well -- with broadcasting it gets told the protocol by the Server (which can be overridden by the local parameter). But without broadcasts it definitely needs both IP Address (or Name) AND Protocol. It won't work with just one of those. (This too is as per documentation). 7 minutes ago, lupa2 said: didn't think it'd have an impact as it works on regular user privileges I don't know why elevating it stops it receiving broadcasts. That seems a bit strange. Pete Link to comment Share on other sites More sharing options...
lupa2 Posted October 14, 2017 Author Report Share Posted October 14, 2017 Specifying the protocol seems to have worked, the client now connects to the server. Why it worked with regular privileges and not with elevated ones I'm still wondering. Anyways, that far it works, now to make FliteDeck see my GPS position, because currently it does not :D Thanks for the help Luca Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now