On 30.05.2016 18:24, Stuart Henderson wrote: > So people are running into the pppoe vlan priority problem again, some > ISP equipment doesn't like the default of IFQ_DEFPRIO (prio 3). > > http://permalink.gmane.org/gmane.os.openbsd.misc/231358 > > As things stand, priority of normal IP packets can be set using PF > rules, but there's no way to set the priority of pppoe control frames, > and whichever way you look at it, the value we're currently using is not > optimal. > > The diff below adds a #define and applies it in the appropriate places > to set priority on the control frames. I sent out similar diffs a couple > of times before but had zero feedback, the only difference with this one > is that it has been updated to apply following the removal of pppoe(4) > server. > > I had a thought of using interface priority from the pppoe interface, > but after implementing that I realised it's bogus because that is for > setting *route* priorities. > > So as in the previous diffs it's still hard coded to 7 at present - > highest priority, "Network Control" - which is most appropriate for > these frames in normal conditions. > > People having the problem where they require 0 in the vlan header will > need to change the #define to SPPP_CTL_PRIO 1, and use a PF rule like > "match on pppoe set prio 1". (Yes, 1, not 0; IEEE 802.1Q-2014 table I-2). > For those people the advantage of this diff over the other one is that > in other cases vlan priorities will still work as expected. > > Any comments? >
Just tested your patch on my 5.9-stable amd64 gateway. Setting SPPP_CTL_PRIO to 1 and adding "match out on pppoe0 set prio 1" to /etc/pf.conf solves my issues. The only drawback is having to change the source and compiling a new kernel. Would be nice if this could be configured in hostname.pppoe0 :) Thx for the patch. Daniel -- Unix _IS_ user friendly - it's just selective about who its friends are!
