Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: Chunkers on March 04, 2016, 10:01:09 PM
-
I am happy to say I think I have my data up and running on MyDSLstats (https://www.mydslwebstats.co.uk/) which I think is pretty awesome :)
I have had a lot of problems with my line and would value any insights into the data and whether I have a case to try and get BT to 'fix' it? I am pretty sure there is nothing wrong with my house wiring - I just had it all entirely replaced.
When I do a quiet line test on my phone there are infrequent, but quite noticeable, pops and a constant but fairly loud background hiss.
The honest truth is that I don't really understand the data, is it trying to tell me anything? Graphs like this one intrigue me as I really don't understand the error related info at all, presumably a certain amount of errors is fine .............. ?
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi43.photobucket.com%2Falbums%2Fe352%2FJolltax%2Fdownload_zpsxeeik84x.png&hash=0c7384e1f63f25e5c1db04745854995004ef6f9d)
o7
Chunks
-
When I do a quiet line test on my phone there are infrequent, but quite noticeable, pops and a constant but fairly loud background hiss.
If you get this - especially from your master/test socket [ideally using a corded phone] - then report it to whoever you pay your line rental to as a voice fault (noise on the line)
-
Hi - This isnt a detailed report, just a 'quick' half hour analysis.
SNRm is usually what we look at first as it gives a good indication how your line performs over the course of the day.
Looking at your data over the past few days, there appears to be some sort of pattern emerging. -
Your line is perfectly fine between the hours of circa 7am and 5.30 pm. Things start to go downhill a bit afer 6pm and are at their worst at around 9:30.
Next I looked at your cumulative Err/Secs. Those seem to show a fairly steady growth throughout the day, perhaps a bit steeper after 6pm especially on the 4th, but nothing too dramatic.
Your attenuation shows that you are apprx 2.7km from the exchange and if all was perfect then you should be looking at a max sync of around 10.6 Mbps
From your bit loading - Indicates this is an adsl/2+ line - I see some nasty spots - more on this later.
Your hlog looks good - No bridge taps in the wiring. Actually looks good for a longish line and a lovely smooth decline over distance, suggesting no obvious problems in the physical wiring.
QLN - hmmm, some nice spiking :/ More on this later because I could practically overlay this with your bit loading.
QLN indicates crosstalk - or in somecases EMI. From the bit loading, your line is noisy in places I wouldnt expect to see unless there is some sort of interference. My gut reaction is saying EMI - coupled with your SNRm its something that is only switched on after 5:30 at night and turned off at 7am in the morning. QLN is a snapshot in time and can only be taken during sync, your last sync would be just entering the noisy period. It would be interesting to see a QLN taken during 9-5 on a working day but no matter, I think I have sufficient to go off to show the problematic areas. Noise at those particular tones are what is causing low bit loading at certain frequencies, which is why you arent quite capable of attaining your max speed. The round bumps at 700 -1200 kHz onwards also to me suggest EMI.
EMI/REIN is very hard to track down, but IMHO there is something there causing this which notably gets worse outside of working hours. I have no idea what is causing it, but 'something' is definitely there. Because of the timing then getting BT to do something about it is going to be exceedingly difficult, because it looks line your line is ok during 9-5 and any tests they run during these hours will likely show good. :(
If it was me Id be racking my brains to find out if anything gets switched on during the mentioned hours. Street lighting, central heating, PIR lighting, faulty monitors, the list is practically endless. I'd also check the frequencies against here (http://www.kitz.co.uk/adsl/rein.htm#MWradio) to make sure its not a local transmitter or radio HAM. Sorry its got late and Im too tired atm to zoom in on any actual tones to check against any possible local radio stations (aside from the fact I dont know your location).
-
When I do a quiet line test on my phone there are infrequent, but quite noticeable, pops and a constant but fairly loud background hiss.
If you get this - especially from your master/test socket [ideally using a corded phone] - then report it to whoever you pay your line rental to as a voice fault (noise on the line)
I agree, however just having looked at chunkers hlog and QLN... and taking into consideration the intermediateness of SNRm... whilst there could be a budding HR fault, atm Im more erring towards EMI of some sort.
It would be useful if chunkers could perform a couple of other tests just for the sake of elimination:-
Ring the landline whilst monitoring the SNRM and see if it suddenly takes a hit when 1) the phone is rings 2) the phone is in use.
-
You guys are super cool, thanks for the insights. My line is 1.37Km from the telegraph pole (DP234) to the Cabinet (PCP1) - shorter as the crow flies :) I know it has the dreaded aluminium overhead lines so am expecting it to be rubbish but was wondering whether I have additional issues.
I still see weird drop-outs which are losses in service but not logged as modem dropouts on my VMG8324 (maybe I have the logging screwed up). Here is one today :
Mar 5 11:52:19 pppd[510]: Connection terminated.
Mar 5 11:52:19 pppd[510]: Modem hangup
Mar 5 11:52:29 pppd[510]: Connected to 00:30:88:00:00:02 via interface eth0
Mar 5 11:52:29 pppd[510]: Connect: ppp0 <--> eth0
Mar 5 11:53:06 pppd[510]: Connection terminated.
Mar 5 11:53:06 pppd[510]: Modem hangup
Mar 5 11:53:16 pppd[510]: Connected to 00:30:88:00:00:02 via interface eth0
Mar 5 11:53:16 pppd[510]: Connect: ppp0 <--> eth0
Mar 5 11:53:53 pppd[510]: Connection terminated.
Mar 5 11:53:53 pppd[510]: Modem hangup
Mar 5 11:54:03 pppd[510]: Connected to 00:30:88:00:00:02 via interface eth0
Mar 5 11:54:03 pppd[510]: Connect: ppp0 <--> eth0
Mar 5 11:54:40 pppd[510]: Connection terminated.
Mar 5 11:54:40 pppd[510]: Modem hangup
Mar 5 11:54:50 pppd[510]: Connected to 00:30:88:00:00:02 via interface eth0
Mar 5 11:54:50 pppd[510]: Connect: ppp0 <--> eth0
Mar 5 11:54:52 pppd[510]: CHAP authentication succeeded
Mar 5 11:54:52 pppd[510]: peer from calling number 00:30:88:00:00:02 authorized
Mar 5 11:54:52 miniupnpd[26144]: Failed to get IP for interface ppp0
Mar 5 11:54:52 miniupnpd[26144]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 5 11:54:52 miniupnpd[26144]: Failed to get IP for interface ppp0
Mar 5 11:54:52 miniupnpd[26144]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 5 11:54:52 miniupnpd[26144]: Failed to get IP for interface ppp0
Mar 5 11:54:52 miniupnpd[26144]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 5 11:54:52 pppd[510]: local IP address 217.155.196.87
Mar 5 11:54:52 pppd[510]: remote IP address 62.3.84.19
Mar 5 11:54:52 rc_service: ip-up 31865:notify_rc start_firewall
Mar 5 11:54:52 dnsmasq-dhcp[442]: not giving name localhost to the DHCP lease of 192.168.1.25 because the name exists in /etc/hosts with address 127.0.0.1
Mar 5 11:54:52 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Mar 5 11:54:53 wan: finish adding multi routes
Mar 5 11:54:53 WAN Connection: WAN was restored.
Anyway really appreciate your feedback and stuff, I will be pondering.
Chunks
-
My line is 1.37Km from the telegraph pole (DP234) to the Cabinet (PCP1) - shorter as the crow flies
Just checking. Your line is adsl2+?
I was going off the bitloading ending at 31 upstream and before 512 downstream.
Re location, its b*cat who is the genius when it comes to working out location based on interference from certain radio transmitters. I'm afraid I dont quite have his patience to do it working backwards :/
but not logged as modem dropouts on my VMG8324 (maybe I have the logging screwed up).
To turn on logging go to:-
Maintenance > Log Setting.
Enable Syslog Logging and set Mode to Local File (iirc its set to remote by default which is why it may not be showing)
You then need to tick the relevant options what you want to show.
Below are the settings I currently have, but feel free to suit to your own prefs.
-
When this thread was initially begun, I reconfigured the "circuit to be monitored" (using MDWS) to be that of Chunkers.
My usual configuration is to view the plots of SNRM, CRCs, FECs, QLN and Hlog.
It was immediately obvious that the circuit is subject to a 2 dB swing of the SNRM over a 24 hour period.
The CRC/minute never exceeded 290 for the DS and 23 US for the last 24 hour period (as of 1825 hours on 06 March 2016). Those figures are not excessive, so I was puzzled by the "colour of the traffic lights". Amber, red & red for the DS error second. Green, green & amber for the US error seconds. Green, green, & green for the retrain indicator.
When the FEC plot was seen to be a straight line, centred on zero, it became clear that the circuit is operating in fast-path mode. Surely interleaving would be far more appropriate? Perhaps this should be raised with Zen, the ISP. Changing from the FEC plot to that of the interleaving depth showed another straight line, centred on one. That confirms my suspicion. The circuit has been locked into fast-path mode and until it has been reconfigured to operate in interleaved mode, things will not improve. I then took a quick look at the error seconds plot and then the severely errored seconds plot. The latter two plots explained the "colour of the traffic lights".
The QLN plot showed a number of peaks, all related to RF ingress and probably due to licensed broadcast transmitters, both home and possibly abroad.
The Hlog plot was reasonable for an ADSL2+ circuit. All was reasonable up to about tone 400 and then decay gradually became obvious. The plot gives an impression that up to tone 400 there will be adequate data carried on each sub-carrier. Tones 401 - 512 should really be disregarded as serious data sub-carriers.
Considering the RF peaks, as shown in the QLN plot --
Sub-carrier Frequency (kHz)
46 198
161 694
198 854
211 910
244 1052
282 1216
338 1458
367 1583
475 2048
495 2135
Cross-referencing the above with data available from UK Long Wave and Medium Wave Transmitters (http://www.mediumwaveradio.com/uk.php) allows us to identify the majority of the RF sources --
Frequency (kHz) Broadcast
198 Radio 4
693 Radio 5
855 Radio Norfolk or Devon or Lancashire
909 Radio 5
1053 Talk Sport
1215 Virgin AM
1458 Sunrise Radio or BBC Asian Network or Big 1458 AM
or Radio Devon or Radio Newcastle or Radio Cumbria
1584 Radio Nottingham or BBC Hereford & Worcester
or Tay AM or London Turkish Radio
Taking a copy of the map (from the aforementioned website (http://www.mediumwaveradio.com/uk.php)), with all the relevant transmitting sites plotted thereupon (attached below), will allow Chunkers location to be tentatively deduced. This last step of the process is left for other interested Kitizens to perform. ;)
-
Wow,thanks for the analysis. If I am picking this up right then it seems that the issues are possibly related to local transmitters. I live in Tenbury Wells, as it happens I am quite close to a number of transmitters including this one huge thing (https://en.wikipedia.org/wiki/Woofferton_transmitting_station) a few miles away also I live near a RADAR station and a number of other transmitter positioned around us.
I really appreciate the info, it is sounding like there is not much I will be able to do about the situation (without upsetting a lot of people!)
Chunks
-
The CRC/minute never exceeded 290 for the DS and 23 US for the last 24 hour period (as of 1825 hours on 06 March 2016). Those figures are not excessive, so I was puzzled by the "colour of the traffic lights". Amber, red & red for the DS error second. Green, green & amber for the US error seconds. Green, green, & green for the retrain indicator.
The circuit has been locked into fast-path mode and until it has been reconfigured to operate in interleaved mode, things will not improve.
The WBC DLM is a lot more forgiving than FTTC DLM, especially if you are on Standard profile, which is what Zen uses.
Chunkers line hasn't received enough Err/Secs for DLM to consider action is necessary. Until that top traffic light goes red, the line will stay on Fast Path.
The QLN plot showed a number of peaks, all related to RF ingress
Thanks b*cat, :thumbs: I didnt look at the individual tone numbers against as it got rather late, but as you can see from the shape I was pondering if it could be local transmitters causing problems.
Now that Chunkers has disclosed his approx location then if I recall a conversation with another kitz member several years ago correctly, then around that area there are loads of transmitters, radars and god knows what else around there- like a whole farm of them. This certainly does confirm for the lack of bit loading at certain tones and why chunkers isn't able to attain the maximum expected speed. There isnt much that can be done about that. :(
However, this doesn't quite seem to explain to me the SNRM variance outside of the 8am - 5pm hours. That timing doesn't quite tie up with normal broadcasting hours of those stations and why I think there may be something else there as well as the local transmitters. :hmm:
-
Had a good chat with Zen support today after a serious of annoying disconnects last night at around 2120 hrs, I generally find them very helpful and a few things came out of it which align with your advice:
- On the basis that 99% of the time our line is fine he did a line test but didn't find any issues, the testing he did suggests that the problem is within our house and is SHINE. He then went through the MW radio tuned to 612 Mhz stuff and linked me to the Kitz webpage on REIN (http://www.kitz.co.uk/adsl/rein.htm) - high praise!
- He offered to add interleaving to our service but advised against it when I revealed we have online gamers in the house-hold, he said it would adversely affect latency
- He offered to increase our SNR target to 9db to improve stability, i decided to decline this for the moment
- He also sent me this cool connection graph (I added it at the end of my post)
Frustrating, but I feel like I am making some tiny progress. I am slightly suspicious that the issue is not internal to my house because everytime I report a fault it feels like all parties are defaulting to the "its not us, its you" so I now have a new house phone line wiring, new socket, new modem and I am still having the same issue!
One question now on my mind is ... I decided not to "upgrade" to FTTC as the line speeds suggested for me were the same as I currently get on ADSL - is FTTC more or less susceptible to this kind of interference?
Anyways, all the advice on here is really helping me get to grips with the technical side, so thanks all.
EDIT : All I need to do now is find out whether I actually still have a MW radio anywhere!
Chunks
Red = Disconnected for 15 min period
Yellow = At least 1 connection in 15 min period
Green = Solid connection for 15 min period
Note the red sections are almost all times when I have been doing stuff to my equipment.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fi43.photobucket.com%2Falbums%2Fe352%2FJolltax%2FDropsOverTime_000500_zpshyqkmb9k.png&hash=e41bc581dcbf57dc665e8d6b2e8743507c78a81a)
-
One thing that immediately strikes me is that the Zen graph doesn't quite seem to tie up with what we are seeing on MDWS.
Zen will be monitoring your PPP session from their RADIUS server.
MDWS monitors your sync which is connection to the exchange.
According to MDWS you resync'd at 10:05 this morning, and prior to that your last resync was 1st of March.
I started to think perhaps theres was some sort of reporting issue or something missing here, so I checked your sync speeds for any changes.
28/02/2016 08:58 - 9716/1139
01/03/2016 10:08 - 9867/1103
07/03/2016 10:06 - 9859/1091
Unless you are rate limited (which you arent), then it is highly unlikely that you will ever sync at exactly the same speeds. The fact that your sync speed remained exactly the same from 1st of March to 7th of March confirms the MDWS record of last sync was correct.
Soooooo now we know that sync isnt the issue, but PPP sessions that are dropping out.
I'd hang fire with that radio for now - Yes you do have a small EMI (REIN) issue that causes the loss of SNRm, but this doesnt look like its what is taking your internet down.
What's your current set up?
Do you use a combined modem/router or have separate units controlling sync (modem) and PPP (router).
I also have the nagging thought at the back of my mind, that quite a few people on Zen randomly see PPP drops that have never quite been resolved. They usually happen overnight though and certainly not at the frequency displayed on that graph.
-
On the basis that 99% of the time our line is fine he did a line test but didn't find any issues, the testing he did suggests that the problem is within our house and is SHINE.
I believe that you have some sort of EMI that causes REIN. You also have RFI ingress which affects your max sync - but unless its HAM I dont think this is your main issue. I think youve got 3 separate issues here... and after seeing that Zen graph I dont think that its REIN which is causing your biggest problem of drop outs.
He offered to add interleaving to our service but advised against it when I revealed we have online gamers in the house-hold, he said it would adversely affect latency
Im of the same opinion. DLM will add it if need be.
He offered to increase our SNR target to 9db to improve stability, i decided to decline this for the moment
Definitely hang fire on that one. It will decrease your sync speed and judging from your SNRm graphs you dont appear to have gone below 3dB. You could try doing a router reboot at say 10 oclock at night when things are usually at their worst. This will have the effect of reversing that curve. ie most of the time you will be above 6dB. Again it will cost some sync speed but not as much as setting target SNRm to 9dB which is more final and not as easy to reverse.
He also sent me this cool connection graph (I added it at the end of my post)
That is brilliant - I think seeing that combined with all the other info we have about your line - it's pointing to a problem with PPP connectivity and not sync.
-
What's your current set up?
Do you use a combined modem/router or have separate units controlling sync (modem) and PPP (router).
I also have the nagging thought at the back of my mind, that quite a few people on Zen randomly see PPP drops that have never quite been resolved. They usually happen overnight though and certainly not at the frequency displayed on that graph.
My setup is now an Asus RT-AC68U router (Merlin 380.57 firmware) bridged to a Zyxel VMG8324 (firmware 1.00(AAKL.12)C0), I have a number of different modems which I have tried over the last month. If there IS a problem with my hardware then I guess it is more likely to be my router as this is the common factor in my recent issues, is there a way I can tell whether my router is dropping the connection?
I guess I could switch to using the VMG8324 as a full modem+router and just use the AC68U as WAP and see if it improves things.
Chunks
-
Two quick comments . . .
- The Wooferton transmitting station (https://en.wikipedia.org/wiki/Woofferton_transmitting_station) will not be responsible for any RF ingress, as it transmits on the HF (short wave) band. (It has a very interesting history and there are a sequence of YouTube videos which give a "guided tour".) However if the external segment of your circuit is less than perfect, poor AC balance, "iffy" joint(s), etc, then there could be adverse effects caused by the relatively high signal strength from the Wooferton transmitters. Sub-harmonics, cross-modulation, etc. Also, Tenbury Wells is "right in the firing line" for Wooferton's eastern broadcasts.
- Your hardware configuration is of a Zyxel VMG8324 in bridging mode connected to an Asus RT-AC68U router. (I realise that it might appear somewhat pedantic but your Asus RT-AC68U is not "bridged to" anything. It is the Zyxel that is acting as a full bridge.)
-
Quick question, I happening to be up late last night binge re-watching Battlestar Galactica and I suffered another outage. AS the house was pretty dead and everyone (else) was in bed I doubt there was any other initiating event.
I now have my logging sorted out and I notice that the outage appears to have originated in my router i.e. the AC68U log shows
this :
Mar 7 10:07:44 WAN Connection: WAN was restored. - note this is my ISP line test completing
…... EDIT
Mar 8 02:00:38 miniupnpd[15030]: Failed to get IP for interface ppp0
Mar 8 02:00:38 miniupnpd[15030]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 8 02:00:41 WAN Connection: Fail to connect with some issues.
Mar 8 02:00:41 stop_nat_rules: apply the redirect_rules!
Mar 8 02:00:41 pppd[510]: Connection terminated.
Mar 8 02:00:41 pppd[510]: Modem hangup
…...... EDIT
Mar 8 02:00:56 WAN Connection: WAN was restored.
…...... EDIT
Mar 8 02:59:51 miniupnpd[18065]: Failed to get IP for interface ppp0
Mar 8 02:59:51 miniupnpd[18065]: SendNATPMPPublicAddressChangeNotification: cannot get public IP address, stopping
Mar 8 02:59:54 WAN Connection: Fail to connect with some issues.
Mar 8 02:59:54 stop_nat_rules: apply the redirect_rules!
Mar 8 02:59:54 pppd[510]: Connection terminated.
Mar 8 02:59:55 pppd[510]: Modem hangup
Mar 8 03:00:05 pppd[510]: Connected to 00:30:88:00:00:02 via interface eth0
Mar 8 03:00:05 pppd[510]: Connect: ppp0 <--> eth0
Mar 8 03:00:05 pppd[510]: CHAP authentication succeeded
Mar 8 03:00:05 pppd[510]: peer from calling number 00:30:88:00:00:02 authorized
Mar 8 03:00:05 miniupnpd[18065]: Failed to get IP for interface ppp0
…......... 10 or so connection attempts
Mar 8 03:07:04 WAN Connection: WAN was restored.
Mar 8 03:07:04 rc_service: ip-up 18481:notify_rc stop_upnp
Mar 8 03:07:04 rc_service: ip-up 18481:notify_rc start_upnp
Mar 8 03:07:04 rc_service: waitting "stop_upnp" via ip-up ...
Mar 8 03:07:04 miniupnpd[18418]: shutting down MiniUPnPd
Mar 8 03:07:06 miniupnpd[18515]: HTTP listening on port 38549
Mar 8 03:07:06 miniupnpd[18515]: Listening for NAT-PMP/PCP traffic on port 5351
Mar 8 10:05:18 rc_service: zcip 19904:notify_rc start_firewall
Mar 8 10:05:18 zcip client: configured 169.254.86.173
Mar 8 10:05:19 start_nat_rules: apply the nat_rules(/tmp/nat_rules_ppp0_eth0)!
Mar 8 10:30:47 miniupnpd[18515]: HTTP Connection from 192.168.1.101 closed unexpectedly
But my modem (the VMG8324) only show the last reconnection which was during the line test by my ISP yesterday i.e. planned :
1 2016 Mar 7 10:09:05 Internet notice Internet Up. connection type=atm0.1 IP=0.0.0.0 VCMUX PVC: 0/38
2 2016 Mar 7 10:09:05 XDSL notice ADSL link up. Speed:RX:9859/TX:1091 (Kbps)
3 2016 Mar 7 10:06:20 Internet notice Internet Down.
4 2016 Mar 7 10:06:20 XDSL notice xDSL ATM link down.
Here is the full log for info (http://pastebin.com/fwcmaLcC) So am I right in assuming that my Asus RT-AC68U is causing the disconnects? I am now suspicious of the Merlin firmware, maybe I should downgrade the firmware .....
Chunks
-
Not sure if you can edit pppoe.conf on merlin to change LCP echo interval and fail limit.
if not try tomato firmware, (not sure if avail on ac68U) there are options to tweak PPPoe connections; I managed to change modem without dropping pppoe connection the other day.
Ian
-
So am I right in assuming that my Asus RT-AC68U is causing the disconnects? I am now suspicious of the Merlin firmware, maybe I should downgrade the firmware .....
No way of knowing for sure. It certainly looks like its the router (Asus) or something at Zen's end.
The dropping of PPP sessions does seem to crop up on Zen every so often. What is causing it though weve never been able to get to the bottom of. I dont know if its something perhaps to do with some sort of config keep alive feature, but it doesnt affect the vast majority of users, but it has also been seen on some Billion modems where suspicion was perhaps going down that track.
I guess I could switch to using the VMG8324 as a full modem+router and just use the AC68U as WAP and see if it improves things.
If it were my line, I would certainly give it a go... just for the sake of elimination if nothing else.
-
OK, after experiencing further random disconnects I have now removed my Asus AC68U router from routing and WAN duties and my Zyxel VMG8324, which was only bought for modem duties is now shouldering the full burden.
I'll keep things like this for a few weeks and this will hopefully tell me whether the disconnects were related to to the AC68U i.e. if they magically disappear. I am now using the AC68U as a WAP, which is rather a shame.
I'll keep you guys posted!
Chunks
-
Good luck. At least if nothing else, it will eliminate one possible cause for troubleshooting.
-
I thought I would tidy up this thread by closing it out with some findings.
Since I changed my network around and removed my Asus RT-AC68U router from bridge duties my connection has been uninterrupted and I haven't seen a single disconnection. Whilst its interface is a bit slow the Zyxel VMG8324 has been doing a good job so far, the AC68U has been relegated to a WAP.
Previously I was averaging around 3 drops / day, since making the changes my connection has been solid since 2016 Mar 10 14:43:15, at the time of writing this is almost 3 days.
I think this is conclusive proof that the AC68U was the cause of my disconnections and further research suggests I am not the only one who has had this issue, although it does appear to be a small proportion of users.
This is disappointing as I really like the AC68U, especially the interface, and I had made up my mind that separate modem and router was the way forward and was convinced the AC68U was the best choice.
My plan will now be to find an alternative router to bridge to my VMG8324, I won't need wireless as the AC68U will stay in that role as WAP - a role it does seem to be able to carry out reliably. I'll probably start a separate thread with a request for suggestions on which one to get once I have done some research....
Thanks for the help guys!
Chunks
-
I'm pleased to know that you have resolved the situation. I would call that result conclusive proof! :)
-
Thanks for the update. I was wondering earlier how you were getting on.
Im glad that you have found the cause and that things now seem stable.
I had made up my mind that separate modem and router was the way forward and was convinced the AC68U was the best choice.
Can I ask, why dont you leave the VMG8324 as modem/router and leave the AC68U for WAP. Whilst I appreciate that the web GUI can sometimes be slow.. do you really need a separate router?
-
PS moving this thread to router hardware section as its not really an issue related to router monitoring software.
I was in 2 minds last week whether its should be considered an adsl or hardware issue, so hadnt quite made up my mind which section it needed moving to :)
-
PS moving this thread to router hardware section as its not really an issue related to router monitoring software.
I was in 2 minds last week whether its should be considered an adsl or hardware issue, so hadnt quite made up my mind which section it needed moving to :)
Very sensible, obviously at the beginning of the thread I had no idea that my router was the issue. It would probably also be a good idea to change the thread title to something more relevant (WAN disconnects caused by Asus RT-AC68U router?) but I don't want to break and any forum rules about this.
Can I ask, why dont you leave the VMG8324 as modem/router and leave the AC68U for WAP. Whilst I appreciate that the web GUI can sometimes be slow.. do you really need a separate router?
In reality this may well end up being what I do, it all seems to be working really well at the moment - a preliminary look at the market suggests that there are very few consumer level non-wireless routers which would end up offering any significant advantage over my current setup.
Chunks
-
. . . obviously at the beginning of the thread I had no idea that my router was the issue. It would probably also be a good idea to change the thread title to something more relevant (WAN disconnects caused by Asus RT-AC68U router?)
Having seen your suggestion I've performed the re-titling, on your behalf. :)
-
Cool, I think that's much more helpful for anyone searching!
Thanks
Chunks
-
So am I right in assuming that my Asus RT-AC68U is causing the disconnects? I am now suspicious of the Merlin firmware, maybe I should downgrade the firmware .....
No way of knowing for sure. It certainly looks like its the router (Asus) or something at Zen's end.
The dropping of PPP sessions does seem to crop up on Zen every so often. What is causing it though weve never been able to get to the bottom of. I dont know if its something perhaps to do with some sort of config keep alive feature, but it doesnt affect the vast majority of users, but it has also been seen on some Billion modems where suspicion was perhaps going down that track.
I guess I could switch to using the VMG8324 as a full modem+router and just use the AC68U as WAP and see if it improves things.
If it were my line, I would certainly give it a go... just for the sake of elimination if nothing else.
My experience on Zen is very similar, you get PPP disconnects every so often, but the sync with the FTTC cabinet is maintained.
I've replicated this on the following hardware
HG612 + AC68U
Billion 8800nl
Billion 8800AXL
Zyxel 8324
Zyxel 8924
In each case, you can go several weeks without PPP dropping then it can happen twice in a couple of days all the while the sync is maintained with the FTTC cabinet.
For me, this is certainly an ISP 'quirk' and isn't hardware or line related. I've found the AC68U+HG612 to be the best solution as this re-establishes the PPP connection more quickly than the other devices.
** edit ** this thread is also worth a read as Zen is having some issues at the moment and quite a few people are getting PPP disconnects on their service at the moment - http://forums.thinkbroadband.com/zen/t/4458979-slow-downloads.html
-
My experience on Zen is very similar, you get PPP disconnects every so often, but the sync with the FTTC cabinet is maintained.
I started getting this (but on ADSL2) in January before that my connection was always very reliable.
Thanks for the link, the Zen forum on TB makes interesting reading and makes me wonder whether their halo is slipping a bit - I have always been very pleased with their service but am left wondering whether my recent problems are actually my problems.
In reality the evidence suggested they were at my end, it does seem too much of a coincidence to ignore that the moment I removed my AC68U from connection and routing duties my connection instantly became solid again.
Cheers
Chunks
-
Google brought me to this thread as I am looking for solutions to my PPP disconnect problem although I am using a Tp-Link router at the moment I seem to be getting this problem on VDSL2. Did Zen ever identify the problem?
-
Google brought me to this thread as I am looking for solutions to my PPP disconnect problem although I am using a Tp-Link router at the moment I seem to be getting this problem on VDSL2. Did Zen ever identify the problem?
@banger - this was a long time ago!
My recollection is that the problems I was encountering were related to the RT-AC68U and not Zen, when I switched to another device the connection drops stopped immediately and I have had excellent service from Zen (I now have 2 Zen lines currently last connection drop was 22 days ago, when I rebooted my modem)
I stopped using the RT-AC68U shortly afterwards in 2016 as I found that even as a WAP it wasn't particularly reliable and would freeze every week or so ..
I know some people rate the RT-AC68U highly, mine was an early model and I quite prepared to believe it was a lemon / dud, but my experience put me off getting another.
Coincidentally, I have also owned a couple of TP-Link routers, I had firmware issues with the TP-Link TL-ER5120v2 Load Balancing Router which led to crashes and dropped connnections - TP-Link support confessed this to me and even sent a beta firmware to me (which did not fix it). Given this and other firmware issues I have had with TP-Link devices (homeplugs, smart home devices, wifi adapters) I also put them on my junk pile although my personal view is that the hardware is OK so if the device has third party firmware might make a good choice.
Good luck!
C
-
Did you come to a conclusion as to which router is best currently?
-
Did you come to a conclusion as to which router is best currently?
I'm not really the best person to answer this question, shortly after this thread was concluded in 2016 I assembled my own DIY pfSense router and have never looked back, I use Zyxel 8924 routers as modems (I have two lines load-balanced). Since then I have fooled around with home-builds running pfSense and OPNsense but I appreciate they are not for everyone ...
Regarding off-the-shelf one box routers : I recently tested and really liked the Fritz!Box 7530 and have had good experiences with Draytek in the past.
Why not create a separate post with a bit more details on your requirements / situation and I am sure you will get a lot of helpful advice for other more knowledge-able Kitz peeps?
C
-
Well I'm having the same problems as you with the same router.
How easy was your pfsense solution? I have all the hw spare here to run 2 pc's assuming I can find a nice slim case with a psu inside. 3770k and 2500k I'm assuming either would be enough for a router, right? I've been thinking about it for a while as it happens as consumer networking hardware just seems so pathetic compared to consumer computer hardware.
What I didn't mention is in the last 4 years I have gone through 3 AC68U's they tend to last about 12-15 months then start conking out...I'm sick of replacing them at £150 a pop.
-
If you have an old PC or some old bits and pieces then it pretty easy, the configuration takes a little homework if you have something unconventional like me. If you are modestly capable at say, installing windows, you can probably manage it!
Before I invested in dedicated hardware for my router I stuck a cheap 4 port PCI card in an old PC and installed pfSense (https://www.pfsense.org) and OPNsense (https://opnsense.org) to try - it took a little time but worked great and pfSense is a excellent and very powerful !
I won't go through all the advantages of an opensource homebuilt router (there are many) but one thing to be wary about is power consumption - if you use a PC as your router permanently it will use a lot of electricity compared to a low power device, thats why I ended up with a PCEngines (https://www.pcengines.ch) APU2C4, I suspect there are better choices and there is lots of knowledge from others on this forum.
[youtube]https://www.youtube.com/watch?v=-xSvAIq9-tM&t=1s[/youtube]
You can, of course, buy preconfigured devices with pfSense installed but its not as much fun :)
I think it would be a really good idea for you to share your query in a separate thread and catch the attention of really smart Kitzers :cool:
Chunks
-
I won't go through all the advantages of an opensource homebuilt router (there are many) but one thing to be wary about is power consumption - if you use a PC as your router permanently it will use a lot of electricity compared to a low power device, thats why I ended up with a PCEngines (https://www.pcengines.ch) APU2C4, I suspect there are better choices and there is lots of knowledge from others on this forum.
I was going to mention power consumption but there's a flip side to that argument, how long it would take the difference in power consumption vs a lower power dedicated pfSense appliance, to equal the cost of buying that box. Considering were talking say 10-20W vs 40-60W, it could take a decade.
There's also the fact we live in a relatively cold country, any power consumption is turned to heat and offsets your heating bill. So buying a dedicated box is not necessarily as important as first appears.
-
I was going to mention power consumption but there's a flip side to that argument, how long it would take the difference in power consumption vs a lower power dedicated pfSense appliance, to equal the cost of buying that box. Considering were talking say 10-20W vs 40-60W, it could take a decade.
There's also the fact we live in a relatively cold country, any power consumption is turned to heat and offsets your heating bill. So buying a dedicated box is not necessarily as important as first appears.
I agree power is not a deal breaker for most people, especially if you already have the bits. I looked into running costs a little recently as I considering a self-build NAS to replace an old PC acting as a NAS:
My current homebuild NAS (normal) power consumption : 70-80W (its an old Q8200 PC running headless and I have a power monitor device attached to it)
I only have a single drive in it so 60-70W would seem reasonable for the PC alone. At 14p/KWh and running 24/7 this is about £80/year
A low power device like mine uses about 8W, or about £10/year
So I think you are looking at about 3 years payback on your investment, which is marginal.
-
As I have a UPS on the network shelf I have a pretty good idea how much I'm using which is around 135W.
That's including my NAS:
4xNAS drives (3x7200RPM),
1x2.5" HDD,
1x2.5" SSD,
1xM.2 SSD,
i5 8600k with 32GB RAM
10" LCD screen displaying stats.Of course under CPU load, the NAS can pretty much double the power load by itself but even though I have remote desktop on it running torrents and firefox running 24/7 for the stats display (https://csdprojects.co.uk/forums/LCARS.png), it doesn't need to clock that high often.
Other devices on the UPS:
i5-7200U (pfSense Router)
10" LCD for CCTV display on stairs.
Multi-gig POE switch which also powers:
TP-Link WDR3600 (acting merely as a switch for my printer and Ubiquiti LiteBeam 5AC 23).
Hikvision CCTV with two 4K cameras.
8" LCD for CCTV display in hallway.
Ubiquiti NanoHD.
Modern PCs are pretty crazy, my desktop is an i9 9900k with 2xNVME M.2 drives and an RTX 2080 and FIVE fans, but it idles down to 36W in Linux although probably hanging more around 54W. It doesn't idle nearly as low in Windows 10 and you don't want to know what it can hit under load. ::)
I apologise that I've gone a bit off-topic here.
-
As I have a UPS on the network shelf I have a pretty good idea how much I'm using which is around 135W.
That's including my NAS:
4xNAS drives (3x7200RPM),
1x2.5" HDD,
1x2.5" SSD,
1xM.2 SSD,
i5 8600k with 32GB RAM
10" LCD screen displaying stats.Of course under CPU load, the NAS can pretty much double the power load by itself but even though I have remote desktop on it running torrents and firefox running 24/7 for the stats display (https://csdprojects.co.uk/forums/LCARS.png), it doesn't need to clock that high often.
Other devices on the UPS:
i5-7200U (pfSense Router)
10" LCD for CCTV display on stairs.
Multi-gig POE switch which also powers:
TP-Link WDR3600 (acting merely as a switch for my printer and Ubiquiti LiteBeam 5AC 23).
Hikvision CCTV with two 4K cameras.
8" LCD for CCTV display in hallway.
Ubiquiti NanoHD.
Modern PCs are pretty crazy, my desktop is an i9 9900k with 2xNVME M.2 drives and an RTX 2080 and FIVE fans, but it idles down to 36W in Linux although probably hanging more around 54W. It doesn't idle nearly as low in Windows 10 and you don't want to know what it can hit under load. ::)
I apologise that I've gone a bit off-topic here.
You are right way off-topic ;D, but I think the economics of device power consumption and how it may or may not justify expenditure on low power devices is a good subject area for a different post - I am been surprised at the (potentially high) cost of running PC's 24/7
C
-
You are right way off-topic ;D, but I think the economics of device power consumption and how it may or may not justify expenditure on low power devices is a good subject area for a different post - I am been surprised at the (potentially high) cost of running PC's 24/7
C
I'm actually really impressed all that comes in at 135W average, I use more than that on LED lighting in my room and during my childhood every room had 100W bulbs. So really, its not that they use a lot of power, its that electricity companies are ripping us off left and right.
As we've hit the limit of Moores Law and mobile computing has skyrocketed, the focus has been on efficiency. But the price of electricity has gone up quicker than the gains in efficiency.
I think a mod should split this topic off now so can continue (assuming there is much else to say about this).
-
One thing that you can do; move to the Highlands or further north, somewhere where it is not too hot, install a thermostat on your central heating and then your router’s energy consumption will be effectively exactly zero as the heat it produces will warm your house thus requiring less energy input into your central heating system. I have four modems, a MUX/DEMUX small VLAN switch, plus a router and other LAN- and WLAN-related boxen, so that lot all warms Janet’s office nicely and we really need the heat.
-
I deliberately have the radiators in my room down lower than everywhere else in the house as the TV, PC, games consoles can make up the difference. ::)
Would work even better if our crappy council house wasn't so draughty. (the councils "improvements" made it much worse)
-
I went crazy with draft excluder strip stuff at my parents’ house, which had a ridiculous north wind blowing straight in under the garage door then through a leaky crappy inner door into the interior of the house. Blocked all the draft at that inner door, stopped it dead. There were PVC patio doors from the sitting room cum kitchen looking out into the garden which had ridiculous drafts coming up around and especially below the frame so some gap filler goop/sealant did the job 100% there too. Warmed the whole place up enormously and slashed their heating bills.
-
You can feel the cold coming in through both outer doors and around every window frame, around the SEAL that holds the glass in. Plus as they took up the carpet to redo the central heating, it also gets in from under the skirting boards. But, umm, we've gone even further off-topic now. :-[