[RP-PPPoE] Multilink PPPoE

[Gordon Henderson]

On Wed, 2 Nov 2011, Insane Laughing Clown wrote:

> On 11/02/2011 02:42 AM, Gordon Henderson wrote:
>
>> 
>> I've tried it on a 2nd (Linux) router just in-case it was an issue with
>> running a bonded session with a non-bonded session on the same router,
>> but it didn't have any effect.
>> 
>> Does this help? Let me know if you want anything more.
>> 
>
> What kernel do you have (Show me 'uname -a') and am I right in assuming this 
> is from connections that are originated from the router (like from the 
> command line) as opposed to connections being nat'd from stations behind it? 
> If it does happen with nat, what does your iptables look like?

   uname -a
   Linux waveguide 3.0.4-drouter #1 Thu Oct 20 19:39:40 BST 2011 i686 GNU/Linux

I've tried kernels 2.6.27, 2.6.35 and 3.0.4. I'll need to put that 2nd 
router back in-place to try others though. I can do that later today if 
needed. They're all statically compiled from sources tailored to the 
underlying hardware (no modules) I guess I ought to try a bog-standard 
Debian kernel just in-case though - I can do that later when I get a 2nd 
router back on-site.

The corruption happens both ways - if I try to connect out, the very first 
SYN packet gets corrupted in the same way. The NAT table shouldn't be 
getting in the way for incoming connections - it's just:

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
SNAT       all  --  172.16.0.0/12       !172.16.0.0/12       to:87.127.18.122
SNAT       all  --  10.0.0.0/8           anywhere            to:87.127.18.122

the router currently has 4 internal LANs and that IP address is the IP of 
the first ADSL PPPoE connection.

the mangle table (entries added by the Debian scripts):

Chain FORWARD (policy ACCEPT 658K packets, 296M bytes)
  pkts bytes target     prot opt in     out     source               destination
  7504  394K TCPMSS     tcp  --  any    ppp0    anywhere             anywhere            tcp flags:SYN,RST/SYN tcpmss match 1400:65495 TCPMSS clamp to PMTU
     0     0 TCPMSS     tcp  --  any    ppp1    anywhere             anywhere            tcp flags:SYN,RST/SYN tcpmss match 1400:65495 TCPMSS clamp to PMTU

I don't think there's anything untoward there, but I've tried it with and 
without - no change. (Although connections into or outof the router aren't 
going via the forward table anyway)

There is a generic firewall applied to the INPUT side of both interfaces - 
but I doubt it's the issue - it's fairly generic just dropping most 
connections and allowing a few from nominated sites, etc. I use it on all 
sites I setup without any issues here and it's applied to both PPP 
interfaces here - and does seem fine when just one line of the multilink 
is going too.

Thanks,

Gordon