Daniel Hartmeier schrieb: > Watch the output of pfctl -vvsq while you send out traffic. Are counters > for the individual queues increasing?
No, there are increasing: queue std_ext priq( red ecn default ) [ pkts: 6119 bytes: 5709747 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue high_prio_ext priority 7 [ pkts: 141708 bytes: 10703383 dropped pkts: 20 bytes: 1247 ] [ qlength: 0/ 50 ] queue low_prio_ext priority 2 priq( red ecn ) [ pkts: 31457 bytes: 4061784 dropped pkts: 38 bytes: 19942 ] [ qlength: 0/ 50 ] queue std_int priq( red ecn default ) [ pkts: 22 bytes: 1224 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue high_prio_int priority 7 [ pkts: 72204 bytes: 17511076 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue low_prio_int priority 2 priq( red ecn ) [ pkts: 42760 bytes: 13563899 dropped pkts: 10 bytes: 14940 ] [ qlength: 0/ 50 ] But I don't understand why std_ext is increasing. According to one of the last rules I've put posted here, anything besides DNS, ICMP, and UDP to that port range should be assigned to low_prio_out. > Create a connection, run pfctl -vvss, you should see a state entry for > your connection. Yes. > Find the rule that created the state entry (through the > rule number printed by pfctl -vvss, corresponding to the @number part of > pfctl -vvsr output). rule 29, which is correct: @29 pass out quick on tun0 proto udp from (tun0:1) to any port 27000:28000 keep state queue high_prio_ext So everything seems to be fine, mmh. I tried the same thing with high prio to tcp smtp connections and the rest with low_prio and vice versa. Worked excellent. However it seems, as if IS using the right queue, but has problems with udp connections. Jochen
