On 2021-02-02, [email protected] <[email protected]> wrote:
> --syjteu3hgkkj7xpe
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit
>
> Hi, I'm trying to setup queues on my LTE interface. This machine is firewall
> machine with two interfaces: wan and lan. Egress traffic is queueing without
> a problem. Rules like
>
> match out on $i_wan proto {tcp udp} to any port $p_dns set queue
> q_lte_out_dns set prio 6
>
> work as intended and I can see that rules are being matched in systat queue
> and rules.
>
> Problem is with ingress packets. Yes, I know people say it makes no sense to
> do it, but I belive it can work for TCP traffic. The slower program is
> receiving data, the slower it will ACK, the slower server will be sending
> data, and there should be more space for other packets.
>
> Anyway, it does not seem to work for me. I try the most basic rules:
>
> queue q_lte_in_root on $i_lan bandwidth 20M max 20M qlimit 50
>
> This works as intended, speedtests do indeed show my speed is more or less
> 20Mbit. Now I add 2 more queues, default and for http
>
> queue q_lte_in_std parent q_lte_in_root bandwidth 512K default qlimit 50
> queue q_lte_in_http parent q_lte_in_root bandwidth 512K qlimit 50
>
> And I create match rule:
>
> match out on $i_lan all set queue q_lte_in_http set prio 0
There is a knack to this that pretty much everybody doing queue config
takes a while to figure out - the queue name with "in" is a giveaway
that you didn't find it yet.
Whichever rule creates state for the packets that you want to send
to a queue should have the queue assignment. The queue name is attached
to the PF state; when the packet is transmitted outbound it will use
the queue of that name on that interface.
You don't want queue names dealing with in/out/interface. Just the type
of traffic / queue policy / whatever. For example "user1", "user2", ..
or "http", "dns", .. or "high/med/low" or something.
Simplest match rules are like
match from 192.0.2.1 queue user1
match to 192.0.2.1 queue user1
or
match proto tcp to port 80 queue http
(plus the pass rule to allow it)
I find it easier to make the match rule setting the queue quite wide,
then do anything more complex (IP/port restrictions etc) in pass/block
rules.
> And this rule is matched only by a handful of packets. systat queue
> shows that majority of packets go through q_lte_in_std, and only some
> of the packets go through q_lte_in_http. systat rules also shows only
> some of the packets are being matched by that rule.
>
>
> I don't know, it looks like only packets without state match "match"
> rule and are being queued properly? I know filtering will be skipped
You should use some variant of "block" covering all traffic as your
first rule ("block" / "block log" etc) so that packets are not allowed
to pass unless they create state. This makes it easier to figure out
the queues, and prevents state tracking getting messed up with TCP (the
TCP state must be created from a SYN packet not an intermediate packet
otherwise it doesn't know what the window-scaling value is, which will
cause longer lasting or fast connections to get dropped incorrectly).
> for packets that have state but queueing is not skipped. So why can't
> I queue packets ingressing on LTE that are being egressed on LAN
> interface?
>
> Is there any way to limit ingress on some ips/ports? I'd like to limit
> greedy apps like youtube or netflix from taking all the bandwidth.
Good luck finding the relevant IPs for these ;) You might like to play
with "burst" and see if you can do something that way. (e.g. standard
bandwidth is slower, but allow a fast initial burst). But you'll probably
need to do that with separate queues per IP and it gets to be a pain.
> I read pf.conf man and searched the whole net but I couldn't find
> answer to my question. I think I could make it work if I made pf
> stateless by default? Performance is not an issue here, machine
> can take it, but I couldn't find a way to do stateless by default.
stateful is the way to go, it just needs the queue assigned in the right
place.
> Any ideas? Maybe I didn't read something carefully enough?
>
>
