Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[emalf]

I have adsl with talktalk, and on wednesday they completed llu at the local exchange. Since then, my router can connect to *something*, in that the netgear router shows as connected, with upload/download connection speeds, but:

*the router can not get dns info
*no ip address is being given
*authentication is not happening

...therefore I get no connection to the internet. Talktalk can see my connection, and reset it, and change my profile, but after about 12 hours on the phone they insist my router is broken. Everything worked fine until they unbundled.

So, what is happening here? How can the isp see my connection, yet... not go any further? At which point is the connection failing? Why is dns info no longer broadcast by the isp?

I had to travel 3 miles into uni just now to try to find this info on the net, but I haven't spotted the answer. I'll be in again tomorrow to see if anyone knows... :p

[Astral]

Hi emalf

Welcome to the forum. I'm sorry I can't give you an answer to your question, but I am sure somebody who can will be along soon.

[kitz]

Hi

First thing to try is check the settings in your router very carefully:-

Protocol :- PPPoA (PPP over ATM)
Multiplexing method: VC-BASED or VC-Mux
(On some routers the above 2 settings may be combined as "PPPoA VC-Mux".)
VPI = 0
VCI = 38
DSL Standard: G.dmt
Security Protocol: CHAP

BT IPStream is not quite so fussy on some of those settings as what LLU is - and many users who have recently been swapped over to LLU find they cant connect because they dont have VC Mux set in their router.

[emalf]

I have checked all the settings carefully (for the 117th time), and they are correct. My router is a DG834GT, and there appears to be nowhere to set DSL Standard=G.dmt or Security Protocol=CHAP. I think that this may be set automaticaly by the router, perhaps by setting Multiplexing method=VC-BASED.

This appears to be a LCP (Line Control Protocol) issue. When testing, I get:

 LCP down... LCP allowed to come up...

Authentication stage never occurs. Should the username/password be a problem, then this would come back as an access denied error, and before that the router would begin timing the authentication process. Neither of these events occur, which would suggest that it is soley an LCP issue. It seems that my router is sending out LCP packets, but that these packets are not being returned. I really wish I could monitor this exchange more closely, and see if any packets are being returned. Before establishing communications over a point-to-point link, each end of the PPP link must send out LCP packets. The LCP packet either accepts or rejects the identity of its linked peer, then agrees upon packet size limits, and looks for common misconfiguration errors. I wonder at what stage this process is failing? Does anyone know if it is possible to get the dg834gt to log exactly what is happening here, so that I can read the logs and find out exactly what is happening?

What I would really like to know is: what does the isp need to change in its servers, after an llu, so that my router can talk to them?

If I know this then I can tell the isp what they need to do, so that I can get my internet connection working again.

Sigh....

[kitz]

TBH Im not entirely sure exactly how the TT LLU system works, since the routing past exchange belongs to TT,  rather than BTw then the ISP.

There wont be a RAS, -  once you are connected to the exchange you go straight over to the ISP (or their carriers) network.  They will still have RADIUS servers (which are what authenticate your connection).

Most of the TT problems I have heard of when going over to LLU have involved not being able to sync at all.  Other common LLU problems have been the result of not using VCMux.

Since it would appear that you can sync and are showing the connected speeds then you are obviously connecting to the dslam, which would perhaps suggest something is wrong between the dslam and the radius servers.
Would be interesting to know if there are any other TT users in your town also having the same problem, because if failure is at this point then it would affect a whole batch of users.

[emalf]

Thanks for your comments.

I tried to connect with a old sagem800 I had to dig out of the attic - both the lights were on, and the connection speed showed as around 6.5mb/s, but when trying to dial it came back with a 721 error (which I think indicates an LCP issue also).

Having done some more reading on the internet, it seems that many people have problems with tt after llu.

From what I understand (having read your comments and the info on your site), when my router/modem negotiates  a service, it connects to a dslam, from which the connection speed is established. The radius server deals with lcp. Which server is responsible for broadcasting dns info? Is this the radius server also?

Unfortunately I have no way of knowing if other people are experiencing the same trouble, as I don't know anyone else in the area with talktalk

[emalf]

yesterday night the problem automagically fixed itself. I still wish I knew exactly what the problem was, and what the solution to the problem was... but I guess I will never know...

Thanks again for your comments

[kitz]

Sorry I couldnt answer your question much further because little info is out there on how the LLU providers are provisioning their networks.

On IPStream authentication is a 2 stage process.. diagram http://www.kitz.co.uk/adsl/images/l2tpauthentication.gif
But basically first you authenticate with the BT RADIUS which is at the RAS, then you authenticate with your ISP who will have their own bank of RADIUS servers at their own data center(s).

LLU has no RAS because the network belongs to the ISP (or their carrier).. and theres no RAS, because you fo straight from the exchange onto their network.  LLU providers will obviously have an equivalent and there will be RADIUS servers somewhere.
I should imagine LLU carriers such as easynet would also have a similar 2 stage process for when they resell LLU on to some ISPs.

If you can establish sync but cant get CHAP authentication then all you can really say is something is wrong between the exchange and either the carrier or ISP RADIUS servers.
The VC MUX problem was iirc one of the problems that materialised in this way, since some routers were incorrectly set to the wrong encapsulation mode or connection protocol type.

If it isnt that - then a problem with the RADIUS severs? I honestly dont know Im afraid.

However I glad they finally sorted it