> On 15 Jun 2018, at 21:57, David Woodhouse <dw...@infradead.org> wrote: > > > > On Fri, 2018-06-15 at 20:49 +0000, Kevin Darbyshire-Bryant wrote: >> >>> 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 <l...@darbyshire-bryant.me.uk> > > 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
signature.asc
Description: Message signed with OpenPGP
