Configuring OpenWRT for PPPoE via Openreach FTTC modem

[#1]

Ok, so a reboot of the OpenWRT box results in a 6 minute wait for the PPPoE connection to finally kick in.
I see the logs of the PPPoE PADI being sent (3 times), with no reply coming back, then it takes down the interface and brings it back up to try again.  Eventually it kicks in.
If I take down the PPPoE interface cleanly from the OpenWRT web UI, and then bring it back up from the webUI, the PPPoE connection is established within 10 seconds.  This seems solid and repeatable.

[#2]

I can see that OpenWRT issues "ifdown -a" when the network is shut down (due to issuing a controlled router shutdown / restart).  I imagine what might be happening is that "ifdown -a" goes through the list of network interfaces and shuts them all down one by one.  But it gets to the ethernet interface that the PPPoE session is on before it shuts down the pppoe-wan interface (or perhaps it would never bother to try), and so the net result is that the ethernet transport is pulled from under the feet of the PPPoE session, just like if the router had been hard powered-off.
I've just simulated this by doing "ifconfig eth2 down" - which takes down the interface that I've got the openreach modem - and then doing "ifconfig eth2 up".  The result of that is the long wait for it to eventually connect. 
I guess a sticking plaster might be to fix up the shutdown scripts so that the pppoe-wan connection is taken down cleanly first.  That would only fix scenarios where the router had been powered off / rebooted cleanly.  It does seem a bit weird that these broken sessions hang around for quite so long.

[#3]

Good work there jimbof. As njay said earlier you would have expected the ppp timeout to be quite short ( < time taken for the VDSL resync ) and so it would be well and truly timedout before the 3 PADI requests have been and gone. Interesting results from the ifdown/up though, I wonder if the shutdown of the network interface is somehow ( not sure how though! ) is affecting the BT modem. The ASUS routers that seem to have been giving problems also have GPL code so it's quite possible that they use a significant amount of the same code as OpenWrt, may explain why they exhibit similar  issues. We could really do with someone from PlusNet networks team to help with a controlled test and provide details of the ppp session timing so we can get to the bottom of this problem. There may not be much desire for that at the moment, since it works fine with the PlusNet TG582, but with self install for Fibre being on the horizon there's going to be more people out there using there own routers I would guess. 

[#4]

I'm not sure it does work fine with the Thomson router - if you hard power cycle the Thomson router I think you see the same long connect time?  But you can't get to any log files to see if there are connect errors, plus the Thomson is quite slow to boot anyhow.
I found with my OpenWRT box yesterday that if I disconnect the PPPoE connection and then reboot the OpenWRT box it connects instantly after the reboot.
Agree this really needs someone with access t the appropriate logs at Plusnet to help debug. 
I could see a few interesting avenues for investigation:
1) make sure that OpenWRT is as good as it can be - ie take down the connection cleanly wherever possible
2) (not sure if this is feasible) Before making a PPPoE connection, attempt to kill any open session by sending the same thing down the wire that gets sent on a clean disconnection
But really, it seems like the problem is at the Plusnet PPP end. 
Can anyone tell me - does the PPP session terminate at the cabinet, at the exchange, or at a Plusnet office somewhere?

[#5]

I would have thought the ppp session must terminate at one of the PlusNet gateways.

[#6]

That's what I guessed.  That would make it quite feasible for Plusnet to have an issue and not other ISP's.

[#7]

It looks like sending PADT before connecting might work, though you might have to cached the session identifier information (which might be tricky over a reboot, don't really want to write it to flash).
http://bellsouthpwp.net/j/d/jdloop/adsl/shastabbg/
"Control connection teardown
The PPPoE Active Discovery Terminate (PADT) packet may be sent any time after a session is established to indicate that a PPPoE session has been terminated. It may be sent by either the host or the Access Concentrator. The DESTINATION_ADDR field is a unicast Ethernet address, the CODE field is set to 0xa7 and the SESSION_ID must be set to indicate which session is to be terminated. No tags are required. When a PADT is received, no further PPP traffic is allowed to be sent using that session. Even normal PPP termination packets must not be sent after sending or receiving a PADT. A PPP peer should use the PPP protocol itself to bring down a PPPoE session, but the PADT may be used when PPP cannot be used."
pppoe command could be used:
http://linux.about.com/od/commands/l/blcmdl8_pppoe.htm
"-k
Causes pppoe to terminate an existing session by sending a PADT frame, and then exit. You must use the -e option in conjunction with this option to specify the session to kill. This may be useful for killing sessions when a buggy peer does not realize the session has ended."

[#8]

It looks like the modification proposed here to the network script on OpenWRT would shut down any pppoe connections cleanly on a controlled shutdown / reboot.
https://dev.openwrt.org/ticket/12472#comment:4
Doesn't help with the situation where the modem has dropped and reconnected, or an uncontrolled reboot/ power loss of the router.
Could anyone from Plusnet comment on why there is this behaviour of very long PPP timeouts? I'd like to make my connection more robust in the case of power being cycled to the router and all the options at my end are very longwinded to what is probably a server configuration issue.
As njay says, it does look like the current configuration is in contravention of SIN495
http://www.sinet.bt.com/495v1p0.pdf
I'm happy to help in any testing which might be useful.

[#9]

So, I've managed to kill off a stale PPPoE connection in seconds from my end with a little hacking of the following app:
https://github.com/lpefferkorn/pppoesk
Basically it sniffs the interface specified for PPP packets, grabs the session ID out of one, and then builds a PADT and sends it down the interface, causing the session to be killed at Plusnet's server, and allowing a new session to start.  The source code at the link above appears to have a couple of quirks which I'm looking into, but I wonder if the Technicolor router does something similar.
Now I need to modify the script that brings up the WAN interface to run this app before starting up the new PPPoE connection.

[#10]

Interesting!.
The readme in that link seems to imply that the concentrator still responds with a PADO packet even when there is a stale session. That's obviously not true since the router reports PADO timeout. The utility, as you say, seems to just listen and attempt to extract MAC and Session ID from any pppoe packets and then send a PADT to close the session.

[#11]

I guess it probably worked for the author and his ISP.  I've noticed a few weirdnesses (it gets the mac addresses the wrong way round depending on which way the packet it sniffs is flowing, so for the moment I've hacked it to send a packet to both the concentrator and the host)  and improvements that could be made, but the idea is sound and does work with plusnet connections.
I'm stuck a little at the moment trying to work out how to get this run before each connection attempt.  Have you played with openwrt much?
Still would be better for plusnet not to have the stale connections hanging around for so long.  Some input from plusnet on why the service is configured like this would be appreciated.

[#12]

It is possible to modify /lib/netifd/proto/ppp.sh to issue the pppoesk command before trying to start a PPPoE session, and job-done, stale PPPoE session sniffed and killed, connection back up in seconds instead of 6+ minutes. 

[#13]

See here for the latest.

[#14]

See here for the work happening tomorrow regarding this.

[#15]

Thanks for the update!  Look forward to taking my hack out of my router, will make firmware upgrades much simpler.