On 15 Jun 2018, at 21:57, David Woodhouse [off-list ref] wrote:



On Fri, 2018-06-15 at 20:49 +0000, Kevin Darbyshire-Bryant wrote:

quoted

quoted

That does end up being quite hairy. I don't think it's worth doing.

This should probably suffice to fix it...

Kevin this is going to conflict with the ifx_atm_alloc_skb() hack in
the tree you're working on, but that needs to be killed with fire
anyway. It's utterly pointless as discussed.

I had already done so as part of the last pastebin debug info round :-)

As regards your patch… MAGIC!  Works an absolute treat.  Will get
that submitted along with the ‘nuke ifx_atm_alloc_skb’ patch to
OpenWrt tomorrow.  For now, maybe my brain will let me sleep :-)

Thank you soooooo much for your help & patience.

Tested-by: Kevin Darbyshire-Bryant <redacted>

Thanks. In the morning please could I trouble you to test the other
variants that you can manage — PPPoA with llc-encap, as well as br2684
and PPPoE over that?

I can confirm that PPPoA with both vc & llc encapsulations work.  BR2684 with PPPoE and both vc & llc encapsulations also work.  No nasty messages noted in dmesg.  I’m actually gobsmacked at how tolerant TalkTalk/BT are of what I’ve thrown at them, they clearly just look for PPP frames :-)

Kevin