Still no internet?

[#1]

I managed to get pppoesk working last night but it requires you to be connected to the modem (as far as I can tell) so it can't find any "ghost" session as I can't connect to the modem (error 651 in windows).
I've also left the router off all night and still nothing. Can these sessions be remotely terminated from the Plusnet end?
Just to reiterate I am not getting ANY session. I have no IP, no subnet mask and no gateway. My problem is that all the equipment times-out attempting to get a connection so I don't see how rebooting can help with this. If it thinks I am connected then it's not going to clear the session after leaving a router, that can't connect due to the previous session, off since from the point of view of the connection, nothing has changed.
It seems that the "access concentrator" (whatever that is) is occupied with something (presumably a previous session) and nothing I do from my end is convincing it to let go. My suggestions for things that Plusnet could try:
+ Can you ask BT (or do it yourself) to clear the session
+ Can we go on the IPV6 trial? This would presumably clear that session...?
+ Can you move me to a static IP (from dynamic). Again I assume this would cause a reset and clear the old session
+ Can one of your engineers tell me how to use pppoesk properly to clear a session (rather than me fumbling in the dark)
+ Can you change my login information / password. Presumably this would then reject the active, unauthenticated session.
Is any of that possible?

[#2]

Re your last suggestion: changing your password doesn't terminate the current session

[#3]

...But the other three do?

[#4]

I'm not sure but I don't think changing to static will help as I think it applies the next time you successfully connect.
I'm passing on the others.

[#5]

Off the wall suggestion: would spoofing the router's WAN MAC bypass the stale session?
http://npr.me.uk/telnet.html#spoof

[#6]

@ schaff - It actually doesnt look like you have a stale session as the BT test logins don't work. This would mean that you have an authentication fault which I will try get picked up today for you.
@ tytm - If you haven't already, can you try logging into the router using 'bt_test@startup_domain' and password 'testing', let me know if that connects or fails.
Jelv is right in regards to the static IP.
Unfortunately, the other suggestions wouldn't work either

[#7]

OK well I have now been offered a BT appt. and got this update:
"fault in AA so will require visit. Connection still down."
If this is saying "so, actually it turns out you couldn't fix it at your end!" I'm going to be a little pissed off after six days of telling Plusnet that rebooting the router is a fools errand.

[#8]

Have you tried spoofing the MAC? Having read the description of pppoesk there's a chance this might work.

[#9]

Tytm,
This IS darned frustrating, however in the midst of the dregs of the MSO possibly understandable?  There is always likely to be some fringe conditions which are difficult to understand and need a sledge hammer to fix.
HOWEVER Plusnet need to be smarter at profiling and understanding the edge conditions so that resolutions for these oddballs can be delivered more promptly than has been done here.
@CTR,
Has this oft reputed stale session issue been fully profiled?
Does it apply to both ADSL and FTTC?
Does having a static IP have any bearing?
Is it different to the no available IP issue we discussed yesterday?
What is the session - what does it exist between?
Why does it stick?
What is the correct resolution (rather than the hit and miss - keep sucking it until it gives approach)?
Is there a clearer set of symptoms which identify this as the oddball issue rather than the simple after MSO reconnection congestion condition(s)?
I suggest that there needs to be a full profile for post MSO reconnection issues based on objective criteria, rather than empirical "suck it and see" retry methods at varying back off intervals.  If you can fully understand what is going wrong, you have a better chance of fixing it and getting users back on line quicker - a full week is just not acceptable to be told to just do the same old suck it and see reboot, power down and retry routine.
I was advised yesterday that networks claimed all users were back online - clearly their assessment / counting method has a flaw, as there are users who have yet to reconnect.  Is it viable to run a database query to identify those users who have not reconnected since the time of the MSO and do not have a current session?  (Or something like.)
Would the protracted inability of these users to reconnect be considered a supply fault?
Kevin

[#10]

@Plusnet: The test logins just give the same "concentrator not reachable" error.
@jelv: I've had to learn everything I've done so far so I'm not super keen to spend another evening fiddling with something I don't fully understand in an effort to correct a problem that may or may not be solved by my actions! I appreciate your suggestion though.
@Townman: I understand, but my income is reliant on having access to the internet so having stated over and over again that the reboot does nothing, I had hoped that Plusnet support would actually listen and not assume I was incompetent whilst sending engineers to other customers with mere speed issues. I've been calm and polite for 6 days whilst getting absolutely no suggestions for resolution other than "Reboot your router" & "Why not leave your router off?" and I am beginning to feel that all of the lists of debugging information above was wasted time when what I should have done was just b1tch loudly on the phone.

[#11]

Thanks for confirming the test logins fail.
This means you have an authentication fault, as you are on fibre we would need to get an engineer out to you. I'll update the faults ticket shorty.

[#12]

@tytm,
I completely agree with you.
@DanH,
How do we collectively do a better job of reaching the conclusion that a particular user has the oddball profile issue and get an engineer on the job quicker than this please?  Both PlusNET and the bright sparks have been offering this user the same (with hindsight) futile advice - whilst others have had engineer visits already. How might we have better helped this user quicker?  What diagnostic methods are available in this condition?
Kevin

[#13]

A BT engineer turned up today and did manage to get us back online.
He said (I'm just repeating this to help anyone else diagnose a fault);
+What "outage"? (he seemed oblivious to any general issues)
+It was a stale session, though he only started to say that after I said, that's what you guys called it.
+Identified problem by BT was an "Authentication Error"
+Fixed by doing a "DLM reset" (It may have been DLN, the first part was "Dynamic Line...")
+All fault resolution seemed to happen remotely. i.e. the guy in my house didn't do much but relay the effects of a remote operators actions.
+He strongly suggested that this was a Plusnet problem and that Plusnet should be doing the resetting (but not DLM some other kind of authentication reset). However when I said "So the ISP can do that can they?" he said, "Well, you would have thought, wouldn't you!" So pinch of salt territory.
+Took about 30 mins to do all the resetting
+No one knows what an Access Concentrator is. It is the Loch Ness Monster of broadband errors.
Thanks to everyone who helped me resolve this. 

[#14]

Glad to hear that you are finally sorted.
Would be happier if CRT can find out EXACTLY...
- What was wrong
- What fixed it
- Who can apply the fix
- How the condition can be more clearly identified
Then next time a user encounters the condition they can be got back on air quicker than a week. I hope there will be some recognition of the inconvenience.
Kevin