On 25 November 2014 at 16:55, Trent W. Buck <trentbuck(a)gmail.com> wrote:
Toby Corkindale <toby(a)dryft.net> writes:
I hit a problem when attempting to upgrade to
kernel 3.17.2 on a
Some time between 3.13 and 3.17, the bonding driver has stopped
accepting ppp devices, instead throwing an error that the MAC address
cannot be changed.
(And does not allow this to be forced)
I suspect it's unlikely.. but has anyone here encountered this issue
and found a solution?
I have two upstream PPPoEs to different ISPs.
I don't bond them, but I have policy routing magick to send replies out
the correct link (without bothering with BGP and an AS):
No idea if that's a usable plan B for your setup.
I don't think it'll work in my case, as incoming data streams are
split up between the links (so I get an aggregated amount of
bandwidth, even on single TCP streams on the downlink)
Alternatively.. do you know where the right place to file bug report
about this would be? It's been a while since I've filed anything
against the linux kernel itself.
If it's a stock kernel, complain to your distro.
If you're compiling it yourself, have you double-checked that you
haven't accidentally =n'd something you need for bonds to accept pppN?
It's a mainline kernel I was trying.. Doesn't look like there's
anything new or changed in the config around either the network
bonding driver, or the ppp network driver.
What is particularly strange, is that between 3.13 and 3.17, this
commit was added:
bonding: permit enslaving interfaces without set_mac support
ie. That seems to suggest what I was doing *wouldn't* work previously,
but would in 3.17, yet my experience is the opposite... o.O
However it looks like the way they handle/reach the error is
different, and the commit gives me some hints that it *should* work..
perhaps by ensuring that the bonding driver is set to balancing before
adding any slaves. (Maybe the Ubuntu/Debian network start-up is adding
slaves before setting mode?)