zen and ADSL2+ PROBLEMS

"We previously sent you an email and a letter to advise you that we will be moving your broadband service listed below to new equipment within the local BT exchange.Moves may occur at any time on the date of the planned move, although typically take place during the early hours of the morning. During the move process there will be an interruption of approximately 15 minutes to your telephone service, after which it will continue to operate exactly as before."

Well, that was the theory from my ISP [zen] but in practice my 2003 vintage Netgear DG814 which had given A1 service could not connect to internet after the "improvements" even after the intervention of ISP Tech Support.
That was a nuisance as I needed connection for eBay that evening,
On advice from ISP Tech Support I bought in a hurry a new Netgear DG834UK which appeared to work for a while, though the connection is now much less reliable than the old router.

I am using the older pre-ADSL2+ service, so in theory there should have been no change noticed.
In practice I have spent £55 and now have an unreliable service.
The ISP has not yet been able to explain why, nor been able to put it right.

Anyone else had similar troubles?

What's the full model version of your Netgear DG834UK?

"What's the full model version of your Netgear DG834UK? "

NETGEAR ADSL+2 Modem Router DG834 v4

SERIAL 1PL60CBF00511

MAC E091F541520A

Leo, putting aside the individual user issue here, shouldn't the real discussion be why the email suggested everything should work as normal after the migration, yet the original router could not connect? I appreciate the technical reasons for it, but surely clear notifications of the potential implications of an upgrade should be standard in your notifications?

Morning,

Can you PM me your username please.

In the meantime, can you please change the modem modulation to PPPoE instead of oA please.

Kindest Regards,
Leo

Edited by deleted (Fri 22-Apr-11 09:57:53)

Yes I agree Stu,

The modem *should* work straight out of the box, however it is the case that they don't all work out of the box. Different chipset Manufacturers write code differently before sending them to the modem Manufacturers.

Over the past years we have seen many reasons for modems not working out of the Box and as you asked Stu, the question is why do we not explain this to all customers? Unfortunately this is impossible to do for everyone. We don't know why some modems will and won�t work until we start looking at the line and the modem. Then we will investigate the exchange, including the line card and the MSAN to see if there is any common issues.

This is why I wanted the modem model. I will look at the line as the point of migration, I will check to see if there is any commonality between this line and any others in the same exchange. At that point we will see if anything presents itself.

Kindest Regards,

We've had a horrendous time with Zen the last 4 or so months. They have since closed the fault and blamed it on an internal network issue, because we have a 'complex' internal network. We have two Macs that regularly connect to the network a couple of smart phones and a PS3. I personally have a bunch of other machines but they have literally only been turned on to prove that the fault was nothing to do with the Mac OS.

They stopped a BT engineer from fixing our fault and I've dealt directly with Leo who actually made up things about our fault and it seems very few of their engineers actually know anything about TCP/IP and have lied on several occasions, they block port 993, they don't block port 993, they don't support port 993.

Please don't believe this issue is a modem issue, it doesn't sound like a modem issue.

Hi Sackboy, I don't feel its fair to directly compare your case with the one of the original poster's as the issues are not exactly the same and have different circumstances.

You certainly did have serious intermittency which did take a considerably longer amount of time to deal with than it should have, thankfully the intermittency was eventually resolved. That left the issue that you have been having connecting to a 3rd party service on port 993 which was totally different problem. Zen most certainly do not block port 993, if someone had advised you that we do they were certainly mistaken. Leo is not in for me to ask him what was meant by not supporting 993, I would guess he was trying to explain that he could not comprehensively support a service provided by a 3rd party.

Both Zen and BT were unable to reproduce the SSL problem. Due to the large number of BT engineers booked and stating they could find nothing wrong or not getting access (even though we both know you were in at the time),the case went to the BT complex faults team and they could not find anything or reproduce the problem either. We would not deliberately block the booking of an engineer however in this case we did have to ask what would engineer number 9 find that the ones that had attended didn't find.

With BT's engineer charge policy there is the risk of BT charging you nearly £200 per engineer visit if they felt the issue was nothing to do with BT. If they apply a charge these would need to be disputed on a visit by visit basis. From the way I read the case notes it was as much about protecting you from needless charges as it was about trying to get to the bottom of the issue.

Certain basic diagnostics had not been performed or at least not clearly noted if you had done them. Such things for example as testing alternate MTU values from your computers and router to ensure that you�re not suffering packet fragmentation (which would cause such problems with SSL). The kind of diagnostics that we could present proving that the issue was not at your end would be invaluable in ensuring you did not get charged for all of those visits.

I fully understand your frustration with the issue its one of the strangest cases that I've read through, and while I was not directly involved in any part of your case I offer my apologies for the frustration this must have caused you.

As much as we wish it was not so the fact remains that some hardware does not work as well on 21CN as it does on 20CN and vice versa. Day in day out we see example of this and if we did not mention or investigate such possibility as hardware being part of a problem we could be ignoring a possible cause of a fault and expose our customers to the risk of engineer charges.

This would then lead to the point of why don�t Zen just stick to 20CN. Eventually the plan for 20CN is to be decommissioned anyone still on it would have no service. BT require the 21CN network to keep developing Internet access, without the 21CN network there would be no FTTC and FTTP (at least not in its current forms). With ISP backhaul on 20CN bandwidth costs are higher, moving to 21CN allows for higher usage limits. It would just not be commercially viable to not adopt 21CN and deal with the small percentage of issue that come along with it.

Edited by drefsab (Thu 28-Apr-11 16:46:57)

Some good news at last.
After suffering poor reliability of internet link, with frequent drop outs and difficult restarts from end March to mid-June, I finally got hold of the right person in zen Tech Support [ Thanks ANDY!] who produced the magic pill.
So simple I don't expect to be believed, but since taking the medicine the service has been back to near normal, with just one drop out a few days ago, which was easily dealt with just by RESTART the iMac.

Here are the steps taken:
In browser address: 192.168.0.1
Setup
Basic Settings
Idle Timeout (In Minutes) - Change old setting from 1 minute to 0 minutes

Job done!

The change makes the router permanently ON by effectively cancelling the Idle Timeout setting and leaving the router always ON.

I would not attempt to explain why this works - I am just glad that it does.

In reply to a post by DIOGENES:

The change makes the router permanently ON by effectively cancelling the Idle Timeout setting and leaving the router always ON.

I would not attempt to explain why this works - I am just glad that it does.

Quite simply it works because the router was configured to disconnect your session (i.e. disconnect you from the internet) when it detected your connection was idle for 1 minute... So (in simple terms) if you stop browsing the web for more than 1 minute it would switch off.