Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: Anthony2007 on August 19, 2007, 04:51:32 PM
-
I'm having a strange problem with my router or internet connection (not sure which). I have an ADSL Max connection with Pipex (Pipex Midi) which is normally fast and stable. I get speeds varying from 4.0 to 4.8Mb and the connection stays up for days between losing sync - it only disconnects once every 4 or 5 days.
The problem is that whenever the router does lose sync it doesn't reconnect automatically. It just sits there disconnected from the internet until I go into the connection manager and click the connect button, whereapon it connects straight away. It never used to do this, it always used to reconnect automatically within a few seconds, but it stopped doing so a few weeks ago.
I'm using a BT Voyager 2110 router with the latest firmware (3.03c). I've tried resetting it to factory defaults, but it made no difference. I've also tried a second BT Voyager 2110 with older firmware and a BT Voyager 220V with unlocked version 3.03c firmware - they all behave the same way. Strangely, though, they all reconnect automatically when logged into the BT test account or the Pipex test user account.
On the other hand, if I use my old USB modem (Speedtouch 330) and set it to redial automatically on disconnect it does so without a problem.
Does anyone know what could be causing this problem? I've had no luck with the Pipex or BT Voyager support departments - they blame each other.
Thanks for any advice you can give, and apologies if I've posted to the wrong forum (it's my first post here!)
-
Hi and welcome :)
Just check that the voyager 2110 settings are set to "always on" under the Quick Setup settings.
Is it definitely loosing sync with the exchange do you know? (The green DSL light will be off).
If the green light is on but youre going nowhere then its likely that you havent go a PPP session.
When you loose connection - theres 3 "places" where you can loose it
1. Your ISP can disconnect you - (you loose the PPP session).
2. It can occur between the exchange and the RAS (ATM session) (authentication part 1).
3. You can also loose sync (between your home and the exchange).
If you loose sync or the ATM session then most routers if set correctly will keep trying to reconnect.
Most routers will also attempt to reconnect when the PPP session is lost - However this is not always the case and sometimes for some reason it doesnt seem to happen. Why I dont know - I've not seen anyone be able to explain a valid reason.
---
I dont think this will make any difference but just check that your router is set to PPPoA (not PPPoE).
The next bit is just a theory and I have no proof of this.. but when my own ISP started "playing" with ellacoyas a couple of customers reported some strangeness. Netgears were dropping at midnight, and some routers when they lost PPP session would not reconnect again automatically.
My own router (a voyager 2100) did this for a very short period of time when previously it had been fine. Its fine again now.. but pipex have ellacoyas and iirc they are still "tweaking" theirs.
-
Many thanks for your quick response! :)
I can confirm the router is set to "always on" and PPPoA.
I think it's losing sync with the exchange but could be wrong about that (not sure if I'm using the correct terminology), I just know it disconnects from the internet. On the rare occasions I've seen it happen, the DSL and Internet lights go out, then the DSL light comes back on after a few seconds but the internet light stays off. The configuration manager then shows the "ready to connect" screen with the username and password fields (both filled in correctly) and the big connect button. In the past, the internet light would come back on shortly after the DSL light and it would be connected again (this is what still happens when logged into the test accounts).
Normally I just notice that the router is showing two lights (power and DSL) instead of three (power, DSL and internet). It's usually overnight that it disconnects.
I can also simulate it by simply unplugging the filter from the socket. On the test accounts, the router reconnects on it's own when I plug it back in, but on my normal internet account it doesn't. By "test accounts" I mean BT_TEST@STARTUP_DOMAIN and BT_TEST_USER@XTREME3.PIPEX.NET.
BT Voyager support suggested that the Pipex servers think I'm still connected and so don't reconnect me. I'm leaning towards it being a Pipex problem, since it only occurs when I'm logged into my Pipex account and happens with three different routers. However, Pipex think it's a router problem since all three routers I tried were BT Voyagers and I don't have a problem when using a USB ADSL modem. I'm confused!
-
From the tests youve done it would appear to be a pipex related problem. Routers (using ethernet) and adsl modems work slightly differently which may be why you dont see it happen with the ST
I'm out of ideas on this one Im afraid - like I said above I had a short period of time when it happened here.. Ive also seen the odd instance occur from people on other ISPs. I dont know why it suddenly occured on my connection - then righted itself again.
Its also kind of like the enta problem why some users have to reboot after ALT to get a new profile but some people dont.. I dont think they got to the bottom of that one either.
It all seems to be a combo of which router you use, and the ISP.
Saying that I just this min recalled a case where just prior to the period I saw this happen.. a PN customer complained that his router wouldnt auto re-connect after a loss of PPP. Since he was abroad and often VPN'd in, this was a major inconvenience to him as he would have to get someone to visit his premises to physically reboot the router.
He moved ISP to zen because of this - thinking it may be ISP related.. but the problem followed him to Zen too... so it could even be something BT/exchange/router related.
iirc in the end he changed router. But why he had to when previously it worked ok and the same router worked ok for many other users on either the same or different ISPs I really dont know.
Have you got access to a router that you could "borrow" for a couple of hours from a friend just to try out?
-
It's been my experience that Belkin routers with the Broadcom chipset are rather poor at reconnecting automatically, but Netgear and Speedtouch are fine. This may depend on which type of DSLAM you're connected to of course.
-
Thanks for all your advice - this site and forum has been far more helpful than my other routes of investigation! I've learned a lot from browsing the site too.
I'm now pretty convinced that this is a Pipex problem and I'm beginning to think I'll have to live with it. It's been going on for weeks, showing no signs of stopping and Pipex seem very reluctant to even consider investigating beyond suggesting problems with my equipment. They certainly won't do anything before reporting the problem to BT and having an engineer visit to test my line, but have warned me that if no problem is found with the BT line itself (which presumably there won't be as it's only the Pipex login at fault) I will have to pay £60! Not sure I want to agree to that.
Strangely, the problem began at the beginning of June, shortly after I received an email from Pipex telling me my local exchange was about to be "upgraded" to LLU. According to Pipex, though, this never actually happened in the end so it's just coincidence - but I can't help wondering if something was changed at the time.
I'm going to see if I can get hold of a different make of router to test, although I don't know anyone who has a non-BT router I can borrow. If I ever get this thing fixed I'll report back.
Thanks again for your help!
-
Hmm.. a bit naughty, but Argos (http://www.argos.co.uk/ProductDisplayTRK019?partNumber=6753887) do have a good returns policy if all else fails ;)
(can't work out what that router on Argos is, it's probably a DG834G, which seem very good at reconnecting if I lose connection somehow - well mine does anyway!)
-
>> Strangely, the problem began at the beginning of June, shortly after I received an email from Pipex telling me my local exchange was about to be "upgraded" to LLU. According to Pipex, though, this never actually happened in the end so it's just coincidence - but I can't help wondering if something was changed at the time.
Sorry only just seen this as Ive been so busy the past few days.
Would you like to be a guinea-pig and perhaps test my latest "on-going project". Its a bit rough right now until I get the time to finish it but most of the back-end stuff should be working despite it not looking "pretty".
The exchange checker should tell you if pipex has LLU'd your exchange.
http://www.kitz.co.uk/adsl/adslchecker.php
.. and also an interesting "quirk" with the adsl line checker Im coding that possibly shows up LLU'd lines (or at least during the testing done so far).. it will depend on how long ago your line was LLU'd and whether BT still has something called RAG test results on it.
Anyway it will be designed to input both the phone no and the postcode - but if you try entering just your phone no and see if it throws up anything strange on the RAG tests.
http://www.kitz.co.uk/adsl/adslchecker.php
(ignore any messages at the top of the page this is to be expected whilst its still in beta phase and is there deliberately until Ive finished it)
[ edited to update urls]
-
Would you like to be a guinea-pig and perhaps test my latest "on-going project". Its a bit rough right now until I get the time to finish it but most of the back-end stuff should be working despite it not looking "pretty".
Happy to!
The exchange checker should tell you if pipex has LLU'd your exchange.
http://www.kitz.co.uk/test/exchangechecker2.php5
That gives the following result:
Exchange was enabled on March 31, 2000
Exchange was MAX enabled on March 31, 2006
Output test
Q2 2010By road0 metres Crow flies0 metres
LLU Providers
1AOL Not available
2Be* Available December 31, 2006
1C&W / Bulldog Not available
1Homechoice Not available
1NewNet Not available
1Node4 Not available
1Orange Not available
2Pipex Available May 27, 2007
2Sky / Easynet Available May 14, 2004
2TalkTalk Available
2Tiscali Available March 15, 2006
1Zen Not available
2Virgin Media Available
...which seems to show that Pipex LLU was due to be installed on May 27th. The email I received was on June 7th and the problem started a few days after that. Pipex say the upgrade never happened, but then they say a lot of conflicting things.
.. and also an interesting "quirk" with the adsl line checker Im coding that possibly shows up LLU'd lines (or at least during the testing done so far).. it will depend on how long ago your line was LLU'd and whether BT still has something called RAG test results on it.
Anyway it will be designed to input both the phone no and the postcode - but if you try entering just your phone no and see if it throws up anything strange on the RAG tests.
http://www.kitz.co.uk/test/linechecker_test2.php5
Here's the results I got from that:
Line Speed Estimation
adsl (fixed) : 2048 kbps (2 Mb)
dsl max : 5000 kbps (5 Mb)
Important: The above figures are an estimate based on information obtained from the BTw database.
DSLmax speeds are best guess based on the surrounding area and cannot take into effect individual line conditions which may effect the result such as the type of equipment you use or other issues which may affect the Signal to Noise Ratio.
RAG Test Results
adsl 1 linecode : GGEC
dslmax linecode: GEGEGEC
1Mbps and 2Mbps available (fixed adsl)
512Kbps and 256Kbps available (radsl)
ADSL Max is available (maxdsl)
The check identified another service on your line which may prevent you from ordering a new ADSL connection. Examples are : Existing adsl connection, DACs, LLU, TPON
Full explanation of RAG codes here
I'm afraid I don't know anything about RAG tests so I don't know what the linecodes mean!
-
Thanks for doing that.
>> 2Pipex Available May 27, 2007
According to that pipex LLU'd your exchange on the 27th May. If theyve gone to the expense of LLU'ing an exchange then they normally move all of their users on that exchange over to LLU within the next few weeks.
Try doing a BTw test login (http://www.kitz.co.uk/adsl/bttest.htm). If you cant log in then it looks like for sure that youve been LLU'd.
>> RAG tests so I don't know what the linecodes mean
RAG = Red Amber Green. Most of the results (well the important ones) are interpreted underneath.
G = Green E = enabled final C= Compatability issue for new order.. which doesnt really tell us that much other than you already have an adsl connection with someone.
If you put in your postcode it checks locale rather than just the line, but its possible that if you just put the phone no in that if its not a BTw adsl connection then theres no info in the database.
RAG status could have been picked up anyhow from having a previous max connection fairly recently and therefore info still being in the database and certainly not a sure fire way of telling if you have been LLU'd... but worth a shot.
It is beginning to look like you have been LLU'd and therefore the different way in which LLU works (different dslam) could be the cause of this. :/
-
According to that pipex LLU'd your exchange on the 27th May. If theyve gone to the expense of LLU'ing an exchange then they normally move all of their users on that exchange over to LLU within the next few weeks.
Try doing a BTw test login (http://www.kitz.co.uk/adsl/bttest.htm). If you cant log in then it looks like for sure that youve been LLU'd.
I can still log in to bt_test@startup_domain and don't get the reconnect problem when I do so (by which I mean it still disconnects occasionally, but always reconnects automatically). Same goes for bt_test_user@xtreme3.pipex.net.
It is beginning to look like you have been LLU'd and therefore the different way in which LLU works (different dslam) could be the cause of this. :/
In that case is there anything that Pipex could do to fix the problem, or am I stuck with it unless I can find a different router that works with the new dslam?
-
>> I can still log in to bt_test@startup_domain
oops sorry :-[
If you can do that then youre not LLU'd.
The info on the checker comes from info supplied by pipex (for the pipex llu) so it does seem strange that pipex should LLU an exchange and not transfer all their users across ??
-
From what I've been told by Pipex it seems they intended to, but then didn't "for some reason" (they either don't know or they're not telling!).
Since the problem began at around that time, I have to wonder if an engineer did some sort of preparation for the switch to LLU, causing my problem, before deciding to abort. But then, I don't have a clue how these things are done!
-
I'm not sure TBH.
From what I can gather the normal process is that the ISP will install their own kit in the exchange, once thats done, then they normally pass a list of customers on that particular exchange over to BTw so that the adsl lines are moved over. This can take several weeks before work is fully completed.
The LLU dslam will have several racks of line cards - each of these being able to hold a number of lines. It is always possible that they ran out of ports (it even happens to BTw) and therefore they stopped transferring any more users over until they purchase some more line cards. I honestly dont know but to me that would seem the only logical explanation as to why yours wasnt moved across.
>> I have to wonder if an engineer did some sort of preparation for the switch to LLU,
Doubtful - more likely IMHO that youve been moved to a different DSLAM on the BTw side of things. BT do seem to do this periodically.. Ive been shifted several times.
BTw also went through a period of time earlier this year when they seemed to be upgrading many exchanges to MSANs (similar to DSLAMs but bigger and more up to date), this work appears to be ongoing and they do seem to be running some dslams down and moving users over to MSANs.
BTw arent always the most forthcoming when it comes to saying whats going on at the exchanges :/
-
Hi
Might be a bit late but that reconnection problem is sorted by upgrading the firmware.
In Ireland we have had loads of problems with Voyagers, not only with reconnection issues, anyhow the problem lays on the boot up sequence and it was sorted some months ago. If you can get a new version from BT UK try the BT ROI, version 3.62 for 2110 and 3.63a for 210.
good luck
-
Thanks! I did see someone on usenet suggest that the ROI firmware was "better", but when I looked at the BT site I was put off by the following:
Warning
This firmware is only for BT Voyager 2110 users who reside in the Republic of Ireland (ROI). This firmware is the same as version 3.01q but is proconfigured to work with the ADSL broadband service supplied in the ROI. Installation of thsi firmare on any 2110 outside of this area will result in a router that will not connect to your broadband service.
http://www.voyager.bt.com/wireless_devices/voyager_2110/firmware_update_roi.htm
The latest version they have for everyone else is 3.03c (released 23/05/07) which is already installed on my router.
Is it safe to try the ROI 3.62 firmware here in England?
-
Don't take this as an authoritative answer, but I would have thought that the ROI firmware could be set up manually with little difficulty to work in the UK. It should be just a matter of using the web interface to configure a small number of items to their UK specs.
-
yeah, exactly eric ...... and if there are any incompatibility probs .... flash it back to the old firmware !
-
Have just noticed this thread, and I know it's quite old, but I had this exact problem occurring with my voyager 210 (not reconnecting after losing sync).
But when I changed my PC about a month ago, the problem disappeared, until I downloaded and re-installed the DMT Tool from the Kitz site. The problem then re-appeared.
So is the problem somehow tied up with the DMT Tool.
Has anyone else who is experiencing this problem installed the DMT Tool?
-
>> I changed my PC about a month ago, the problem disappeared,
TBH I dont see how changing your PC could affect whether the router will auto-connect or not after loosing sync, since resync is negotiated entirely between the router and dslam at the exchange.
Just checking though are you using the ethernet or usb connection?
I'm wondering if perhaps some traffic requests could have perhaps been "kick starting" the router into action.
Off the top of my head I dont see how DMT could have affected this either.. anyone else got any ideas?
-
The only way DMT could have affected it (as far as I can see) would be if the target noise margin was tweaked too low, but then manual reconnection would also be a problem. So I think it's probably a red herring.
-
Sorry, my problem was not quite the same as the thread title suggests, but judging by the original poster's follow up entries I think he did have the same problem as me.
The voyager did resync after a loss of connection, but would not reconnect to the ISP; that had to be done manually.
Then when I changed my PC, everything reconnected automatically until I downloaded and installed the DMT Tool.
Then it wouldn't reconnect to my ISP after resyncing again.
-
>> Then it wouldn't reconnect to my ISP after resyncing again.
That bit is part of the establishing a PPP session. Sync is attained between you and the exchange, whilst the PPP session is the ISP part.* Your ISP can make you loose the PPP session but they cant make you drop sync.
I have actually seen numerous reports where users have problems automatically regaining PPP session after an ISP has carried out load balancing, or if the PPP session is lost for some other reason. As mentioned I know someone who moved to zen because he thought it was an isp specific problem but it followed him there too. Ive seen reports of Enta customers and also many other ISPs saying the same thing.
I even went through a period of it myself with my Voyager 2100 router which righted itself again out of the blue. I didnt have DMT installed at the time, nor did the guy who moved to Zen.
This problem seems to crop up with various different routers, it covers various ISPs and it seems to come and go, one thing I have seen mentioned elsewhere is that it doesnt seem to affect the ST frog modems, possibly because a USB modem will automatically sync when the PC is booted up, but relies on the "dial command" (PPP session) being initiated on the PC.
A router is a separate entity with its own processor, CPU and even operating system and doesnt need anything PC related to be able to attain sync or establish a PPP session and carries out this process without any interaction from the PC or anything on the PC.
All the DMT tool does is sets a command in the router so that it will establish a sync at a lower target SNR Margin during the sync negotiation process with the dslam and DLM. It doesnt actually amend anything at all to do with the PPP session.
Because a router doesnt rely on a PC related for sync or PPP then thats why I dont see how the problem could have "gone away" when a new PC was attached.
When I did have the problem the time frame did co-incide with a time when BT was "mucking about" stuff at my exchange,
and although I cant prove it, it is possible that it is far more likely to be something to do with a combination of the router hardware, the dslam and further up the chain at RADIUS servers which does have responsiblity for establishing a login.
Although it shouldnt in theory happen, there are many many cases when if the router chipset and the dslam chipset is "matched" then users seem to report better stability. Theres also the AR7 chipset "issue" which hasnt yet been fully explained, but its possible that that involves a specific combination of the router chipset and the dslam chipset and some other as yet undiscovered BT variant(s) on their config. If you match all those variants whatever they are then something weird seems to happen.
It cant however be anything PC related... hence why the change of PC etc is likely to be a co-incidence.
However just thought do you connect via USB or ethernet?
----
Edited to clarify
* Although the PPP session is generally on the whole ISP related, there is an earlier part of authentication which is carried out still on the BT system.
Authentication is a many stage process, but can be split down into 2 main parts... at the BTw RAS and at the ISP's RADIUS.
-
Thanks for the reply.
I'm not really trying to blame DMT for the problem, but just trying to find out if anyone else has similar experience.
To answer your question, I connect via ethernet.
There's another little quirk that crops up when I access the router via IE7 (ie http//192.168.1.1/)
I get the "quck start" screen but it is frozen, in fact IE7 freezes, and the only way out is by ending the process in task manager.
If I use Firefox everything works fine.
-
Thought I'd report in with the latest - finally my problem has gone away!
I had given up on this problem ever getting resolved months ago and learned to live with it, but just recently (within about the last week) my router has started reconnecting automatically again out of the blue. It still disconnects occasionally, but I no longer have to intervene to get it back online. I've also noticed that the router stats have changed slightly. The downstream noise margin is now always around 10 to 12dB (it used to be around 6dB) and the upstream line rate has dropped from 448Kbps to 288Kbps.
I noticed on a Pipex newsgroup that some Pipex users are complaining of having recently been migrated to Tiscali LLU without warning. I wonder if that's what has happened to me? Still, if things stay as they are, I'm happy!
-
quick rule of thumb, if your on a fixed rate dsl service ie 0.5, 1, & 2 mb the upstream speed would be 288 kbps
the SNR should be in double figures, in the teens is average, 20's good, 30 very good, 40's buy a lottery ticket
upstream 440's then your on rate adaptive "yes this isp can give you up to 8mb (subject to azamaphulp)"
The SNR "MARGIN" is best as low as possible ie 3/6db where's that lottery ticket, 9/12db ok, 15db sort of ok, 18db ahh!. the db should be stable within 3db's within say a half hour.
The analogy I always use for snr, your talking to someone at the end of the street/garden & someone starts a lawn mower nearby "Your tea's ready" "what" "i said... can you turn that off" "what....There iv'e turned that off now what were you saying ?"
-
quick rule of thumb, if your on a fixed rate dsl service ie 0.5, 1, & 2 mb the upstream speed would be 288 kbps
the SNR should be in double figures, in the teens is average, 20's good, 30 very good, 40's buy a lottery ticket
upstream 440's then your on rate adaptive "yes this isp can give you up to 8mb (subject to azamaphulp)"
I'm on the Pipex Midi "up to 8Mb" service (downstream currently 5280Kbps) which is why I was surprised to see my upstream showing 288Kbps now - it used to be 448Kbps. I think I am one of the "lucky"(?) Pipex users who have been moved to Tiscali LLU without being told - speedtest.net now shows my ISP as being "TISCALI UK LIMITED". If it gives me a connection that I don't have to keep restarting manually then all the better!
-
Glad its sorted for you... it does seem to go back to my post earlier when I said
My own router (a voyager 2100) did this for a very short period of time when previously it had been fine...[snip]... thinking it may be ISP related.. but the problem followed him to Zen too... so it could even be something BT/exchange/router related.
If you have been moved to tiscali LLU (which seems likely since you have a tiscali IP).. then you will have been moved to a different dslam (one of theirs) at the exchange.
Does seem to make you wonder if it is something to do with the DSLAM configuration you were connected to. Mine righted itself without going on LLU.. but I do suspect that I was moved to one of the new MSANs.
You could see if tiscali have equip at your exchange from the adsl checker (http://www.kitz.co.uk/adsl/adslchecker.php).
I would ask your ISP though why youre getting the lesser upstream speed.