Kitz Forum
Broadband Related => Router Monitoring Software => Topic started by: tiffy on February 08, 2019, 08:10:14 PM
-
Having trouble with one of my remotely connected RPi's which is running DSLStats, connecting remotely with VNC viewer.
The associated router is a Billion 8800NL r2 and the issue appeared to start a few months ago after updating the router FW to cure random re-booting issues, establishing a remote connection via VNC became very hit & miss usually timing out a few times and taking quite a few attempts to connect to the RPi which is a RPi ZW running DSLStats under "Raspbian Stretch" which is fully up to date.
Router connections to both remote RPi ZW's is by Wi-Fi.
Solutions tried to date:
Replaced the RPi 16 Gb. SD memory card.
Replaced the complete RPi ZW.
Today, substituted the router with a spare ZyXEL VMG1312-B10D I had available.
The Rpi ZW is being accessed by my desktop PC, via VNC viewer, this is running Win 8.1, I have also tried access from my laptop PC which is running Win 10, same results.
I have 2 further identical VNC setup's, one remote to another RPi ZW and one local to a RPi 3B (normally connect to the local RPi via LAN but can treat the connection as remote for test purposes), all of the VNC configurable server settings on all 3 RPi's are identical, have never had any connection issues with the other RPi's.
Having now substituted all the associated hardware and software have run out of ideas, suggestions welcomed.
Edit: Additional information added.
-
When you say connection via vnc is hit or missed and times out are you running that raspi zero w with a static IP?
What is the CPU usage like?
-
I think my RPi ZW is somewhat 'on the edge' running DSLStats.
When it is sampling, CPU usage goes up to 100% for a time. Saving Snapshots & Datastore to a local NAS adds to the load, and when the device is maxed out I think listening for a cloud connection from VNC takes a very low priority. Connecting directly over the local LAN is less difficult, but even then I sometimes have to try a couple of times. Once the connection is established there's no real problem, although Whilst the Pi is sampling response to user input is very sluggish.
On the other hand, I've experienced no lag at all when running the same on a RPi 3B+, but that has a different processor.
-
Ya the Raspi 3B+ is a beast and is quad core that's what I am using along with xvnc/RDP wrapping for remote connections.
Now you the only way WiFi issue might be there is because the WiFi is CPU dependant and if CPU is getting hammered WiFi will be effected. Does this issue occur when dslstats is not running?
If it doesn't whilst dslstats is not running then it's pointing to the issue being cause when the CPU is being hit hard which is causing your time outs. It was the main reason I replaced my Raspi model B original with a 3B+, more cores less issues unless you open up chrome then it goes into a slippery slope.
Do try it without dslstats running if it works lovely on that a suggestion would be to increase the time between samples if how your monitoring your line allows it.
Sent from my LLD-L31 using Tapatalk
-
Bit OT but can I ask what "cloud" services people are using to VNC into their pis without opening ports etc? Are they free?
-
Thanks to all for the interest and suggestions.
Yes, I have always assigned static IP addresses to all my RPi's for both Wi-Fi and ethernet, it's sometimes necessary to use a USB/Ethernet adaptor with the RPI ZW's after changes or re-configuration in order to get back into Wi-Fi.
Appreciate that the RPi ZW can struggle with CPU usage, does "top out" for a few seconds when DSLStats is sampling, I have already changed both RPI ZW's DSLStats sample frequency from the default 60 secs to 120 secs..
Have verified that the connection issue still exists with DSLStats sampling halted and even with DSLStats shut down, under these circumstances the CPU is practically idle showing a few percent usage.
@johnson:
Sorry, don't fully understand your questions.
I'am using VNC free which permits up to 5 cloud connections.
The system currently exibiting the connection issues has been in use for at least 18 months, originally set up for MDWS service, the issue having started late last year, from memory, after upgrading the Billion 8800NL r2 router firmware.
As already reported, all of the system hardware including the router has now been replaced but the issue remains.
My other remote RPi ZW has exactly the same setup with a Billion 8800NL r1 router and does not exibit any connection issues.
-
Since a while I noticed the ram on my raspberry gets full over time caused by a system process. I think this could also cause the issues you described. Have you already checked the memory usage?
-
Since a while I noticed the ram on my raspberry gets full over time caused by a system process. I think this could also cause the issues you described. Have you already checked the memory usage?
Not much can be done about RAM resources on a RPi other than allocating the min. possible to the GPU which I have always done, RPi ZW's having a total RAM of 512 Mb. I have allocated 64 Mb. to GPU on all my RPi's which run DSLStats..
My RPi ZW's sample every 120 secs. and are configured to upload snapshots only to a web server every 2 days, did try to run FTP data uploads to the web server but the RPi ZW's could not handle this, CPU max'ed out.
FTP data uploading to web site via DSLStats works fine on my local RPi 3B as would be expected.
I don't think RAM resources are the root cause of my current issue because:
1/. The same setup worked perfectly for over a year without any remote logon issues.
2/. The exact same setup is still working on my other remote RPi ZW without any logon issues.
Just remembered, one difference does exist between the two remote RPi ZW installations, a Sam Knows White Box is in service at the installation where the remote connection problem exists, always has been the case, it branches off a router LAN port then feeds a desktop PC and smart TV via wired ethernet connections, can't honestly see how this could effect the cloud connection to the RPi which has a direct Wi-Fi connection to the router ?
-
Maybe SamKnows have recently changed how they transfer data to/from the Whitebox, and are hogging the bandwidth? I know the Whitebox listens to internet traffic originating from the LAN, but doesn't the cloud connection to a RPi come from outside the LAN, so perhaps the Whitebox doesn't know about or make allowance for it.
I know almost nothing about DSL compared with many on here, so the above may be complete codswallop!
-
Yes, in lieu of any other possibilities it's certainly worth taking the Sam Knows White Box out of the equasion, I had intended to visit the location and try this today but the opportunity never arose.
The only marker to the start of the issue I can identify from memory was the updating of the associated Billion 8800NL r2 firmware due to a random re-booting issue at the time, with the substitution of the router to a ZyXEL VMG1312-B10D a few days ago and the issue remaining that would seem to eliminate that train of thought.
Will disable the SK White Box tomorrow and report results, another part of the process of elimination I suppose, something has changed !
-
Well, tried a few hours of operation today with the Sam Knows White Box out of circuit and switched off, absolutely no difference with respect to the "hit & miss" remote connection issue to the RPi ZW/DSLStats via VNC..
Also thought that I would try an ethernet connection from router to RPi using a micro USB to RJ-45 adaptor just to eliminate the Wi-Fi connection which I disabled on the RPi, again, made absolutely no difference to the issue.
Can anyone think of any router settings that could possibly cause this issue as i'am sure it started after the Billion 8800NL r2 had a FW update to address random re-booting at the end of last year.
Having said that, I have recently substituted the Billion for a ZyXEL VMG1312-B10D I had on hand and the issue has remained, suppose it's not impossible that comparable setting on both routers could be the cause of the issue, I'am certainly out of ideas now ?
-
Nope. In bridge mode the modem has nothing to do with anything PPP related.
If it occurred around the same time it's likely a coincidence.
You mentioned you already substituted the Billion for a Zyxel and the issue persisted. That further points to the Billion not being the problem.
My advice would be run a tracert when it works, and another when it doesn't. See what changes.
-
Sorry, don't fully understand your questions.
I'am using VNC free which permits up to 5 cloud connections.
Yes so in order to connect remotely without knowing the public IP or opening any ports you are using a service, from googling it appears to be RealVNC:
https://www.realvnc.com/en/raspberrypi/
Who offer free accounts to raspberry pi users. So your pi is either keeping a constant connection open to RealVNCs servers or is polling them frequently to allow you to connect remotely buy going through them (at least initially).
I wonder if there is any choice of server in the VNC config of the pi or if its all done by magic. To start troubleshooting I'd be testing connectivity to these servers from your end and the remote one.
-
Thanks to both for further interest and suggestions.
@j0hn:
In bridge mode the modem has nothing to do with anything PPP related.
Both the Billion & ZyXEL are used in modem/router (one box) configuration, no separate modem involved, any confusion likely my fault for using "router" terminology when I meant "modem/router".
You mentioned you already substituted the Billion for a Zyxel and the issue persisted. That further points to the Billion not being the problem
Yes, that certainly seems logical to me also but as the start of the issue occured after Billion FW update and I happened to have a spare ZyXEL on hand decided to eliminate all doubt.
My advice would be run a tracert when it works, and another when it doesn't. See what changes.
Wouldn't know where to start with that, I do know the local IP addresses of the modem/router and the RPi (both fixed) and the current public IP address of the modem/router but no idea how the routing would transit via VNC systems.
@johnson:
https://www.realvnc.com/en/raspberrypi/
Yes, that's the setup, free cloud access for up to 5 devices.
I wonder if there is any choice of server in the VNC config of the pi or if its all done by magic. To start troubleshooting I'd be testing connectivity to these servers from your end and the remote one.
Yes, well expressed, as far as I'am concerned it's certainly all done by magic !
I have tried deleting the device from my on line account and re-adding from the RPi server as per VNC's procedure, did not make any difference.
-
Hi tiffy
I am sorry if you have already posted the answer but to be sure where the initial is
When the pi cannot be vnc too, can you ping the device from the router (so it’s an internal ping)
If so, have you setup SSH rules to allow you to connect, and if so, if you SSH into pi, if you run top, can you see vnc service running, or it maybe from command vncserver status or vncserver
It’s just a thought and sorry if you have already posted the answer
Many thanks
John
-
@d2d4j:
Hi John, thanks for your interest and suggestions.
Apologies, most of your dialogue is over my head, I can however answer regarding local RPi/DSLStats access.
I can reliably and virtually instantly access the RPi/DSLStats using VNC Viewer configured to either Wi-Fi or LAN IP addresses (using a USB to ethernet adaptor on the RPi for LAN) from either the local LAN connected desktop PC or a laptop which is connected either direct LAN or Wi-Fi to the modem/router.
Remote cloud connection to the RPi/DSLStats will always work eventually, just very hit & miss which as already stated was not the case previously.
So yes, I have no reason to doubt that "internal" pings to the RPi will work as the IP address connected requests from VNC Viewer work perfectly.
I have no real idea on the protocol or workings of VNC cloud connections, as "johnson" has commented previously it's just magic, to me anyway !
-
What device are you attempting to use Real VNC Viewer (or whatever they call it now) from?
Is it a desktop PC?
If you have an Android phone (might work from iPhone) you could try using the Real VNC app to connect.
If/when it fails to connect you could switch off WiFi and use mobile data to try the connection again.
Though as you can successfully connect to other VNC devices hosted on other connections it sounds like it could be a routing issue on the Pi's connection.
You would need to obtain the IP that the Pi connects to over Real VNC and run a tracert when it works and when it doesn't, then compare the 2.
-
What device are you attempting to use Real VNC Viewer (or whatever they call it now) from?
Is it a desktop PC?
Either my desktop PC running Win 8.1 or laptop running Win 10 both using wired LAN connections.
As stated in last post, can connect when at the remote location using desktop PC running Win 7 or laptop running Win 10 using VNC "local" configuration (stipulating IP address) or strangely enough also using cloud configuration, ie., should be the same as connecting remotely from anywhere.
Considering the above, logic would appear to indicate that the issue is at my home connection point except that I can still connect perfectly to my other remote RPi which uses an identical setup !
Used the system extensively all last summer to the 3 devices (my own line included) while touring, worked faultlessly from all locations and proved to be very effective after the demise of MDWS last March.
Something I have not yet tried and as further process of elimination, I'll try a VNC cloud connection to the RPi with the issue from the other remote location.
You would need to obtain the IP that the Pi connects to over Real VNC and run a tracert when it works and when it doesn't, then compare the 2.
Absolutely no idea how I would get this.
-
Well, have now tried cloud connection to the remote, troublesome RPi location from the other remote RPi location rather than my home location, results still the same, hit & miss connection via VNC viewer.
Will just have to accept the situation, always get a connection eventually and the "2 daily" snapshots upload to web server is still working normally.
Again, thanks to all who expressed interest and offered suggestions.
-
If you are using RealVNC as your client it has one gotcha. In the advanced settings the Quality defaults to Automatic. That can give an unusable connection if it resolves as low. I set my Quality explicitly to High or Medium.
Can you ssh to the remote box? If you are on Windows then that would be using ssh under Cygwin, MSYS2 or WSL; or PuTTY.
If so you can then run your VNC session over an SSH tunnel. That has two advantages. One is security. The other is that a plain text connection is easier to diagnose.
An example command to start a tunnel is
ssh -fNL 8901:localhost:5901 remote.example.com
That is to connect to display :1 on remote.example.com. The 8901 is an arbitrary port number, you connect your VNC viewer to ::8901
If you are using PuTTY instead of ssh then add the tunnel in there.
Connection/SSH/Tunnels: L8901 localhost:5901
-
@ petef:
Many thanks for your interest and suggestions.
If you are using RealVNC as your client it has one gotcha. In the advanced settings the Quality defaults to Automatic. That can give an unusable connection if it resolves as low. I set my Quality explicitly to High or Medium.
Yes, I had realised that as soon as I started using RealVNC Client, on my old RPi 1B and the RPi ZW's especially, the desktop display was inclined to show "negative" if I left the "Picture Quality" at default "Auto" setting always set to "Medium" on all my connections.
However, was not aware that this could effect the connection quality or ability.
To be honest, your further questions & suggestions are way above my knowledge level and diagnostic ability on the subject, would not know where to start !