Hi, I hit a problem when attempting to upgrade to kernel 3.17.2 on a particular server. 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? 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. Cheers, Toby
Toby Corkindale <toby@dryft.net> writes:
I hit a problem when attempting to upgrade to kernel 3.17.2 on a particular server. 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): http://cyber.com.au/~twb/doc/dual-uplink.txt No idea if that's a usable plan B for your setup.
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?
On 25 November 2014 at 16:55, Trent W. Buck <trentbuck@gmail.com> wrote:
Toby Corkindale <toby@dryft.net> writes:
I hit a problem when attempting to upgrade to kernel 3.17.2 on a particular server. 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): http://cyber.com.au/~twb/doc/dual-uplink.txt
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 https://github.com/torvalds/linux/commit/f54424412b6b2f64cae4d7c39d981ca14ce... 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?) Toby
On Tue, 25 Nov 2014 12:07:37 PM Toby Corkindale wrote:
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.
https://bugzilla.kernel.org/ In regard to the commit you mentioned later in the thread, git shows the author as: Author: Veaceslav Falico <vfalico@gmail.com> So perhaps contacting him might be useful if you can demonstrate that reverting that commit fixes the regression. Linus takes a dim view of people breaking compatability so it may also be worth asking on LKML. Good luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
I never did manage to get things running on 3.17.4 (latest stable) and couldn't see anything promising committed to latest release candidate, so have submitted a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=89161 Have not as yet tried reverting just that commit as there's always too much other stuff to be doing in the day :( On 26 November 2014 at 22:50, Chris Samuel <chris@csamuel.org> wrote:
On Tue, 25 Nov 2014 12:07:37 PM Toby Corkindale wrote:
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.
In regard to the commit you mentioned later in the thread, git shows the author as:
Author: Veaceslav Falico <vfalico@gmail.com>
So perhaps contacting him might be useful if you can demonstrate that reverting that commit fixes the regression.
Linus takes a dim view of people breaking compatability so it may also be worth asking on LKML.
Good luck! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
_______________________________________________ luv-main mailing list luv-main@luv.asn.au http://lists.luv.asn.au/listinfo/luv-main
-- Turning and turning in the widening gyre The falcon cannot hear the falconer Things fall apart; the center cannot hold Mere anarchy is loosed upon the world
On Tue, 2 Dec 2014, Toby Corkindale wrote:
I never did manage to get things running on 3.17.4 (latest stable) and couldn't see anything promising committed to latest release candidate, so have submitted a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=89161
Have not as yet tried reverting just that commit as there's always too much other stuff to be doing in the day :(
I know who works in a corporate environment :) (caught myself topposting the other day, just in the nick of time). Have you tried the teaming driver? They seem to be phasing out the bonding driver in favour of team. But I've never seen team in action, so don't know how it compares. -- Tim Connors
Just rebooting a thread a year later.. Thought I'd mention that a) the teaming driver doesn't support bonding ppp devices b) the linux kernel bonding driver still hasn't corrected the regression I reported a year ago. c) I patched the kernel myself, and thus have a working modern kernel again. Patch is attached to the bug report below. d) Linux netdev mailing list pretty much ignored my attempts to get this sorted out, so I gave up, and will just quietly keep patching my own kernels. Figured I'd mention this in case anyone else comes across this thread while searching for a solution. Toby On Thu, 4 Dec 2014 at 16:57 Tim Connors <tim.w.connors@gmail.com> wrote:
On Tue, 2 Dec 2014, Toby Corkindale wrote:
I never did manage to get things running on 3.17.4 (latest stable) and couldn't see anything promising committed to latest release candidate, so have submitted a bug report: https://bugzilla.kernel.org/show_bug.cgi?id=89161
Have not as yet tried reverting just that commit as there's always too much other stuff to be doing in the day :(
I know who works in a corporate environment :) (caught myself topposting the other day, just in the nick of time).
Have you tried the teaming driver? They seem to be phasing out the bonding driver in favour of team. But I've never seen team in action, so don't know how it compares.
On Mon, 16 Nov 2015 12:47:35 AM Toby Corkindale via luv-main wrote:
d) Linux netdev mailing list pretty much ignored my attempts to get this sorted out, so I gave up, and will just quietly keep patching my own kernels.
Disappointed to hear that.. :-( -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
participants (5)
-
Andrew Pam -
Chris Samuel -
Tim Connors -
Toby Corkindale -
trentbuck＠gmail.com