On Tue, Jan 23, 2007 at 06:01:01PM +0100, Michal Soltys wrote: > I've noticed that many programs love to "abuse" TOS byte, lowdelay bit in > particular. The effect is, that a lot of packets that one would never > expect, land in the 2nd queue (even scp & sftp set it),
NB: He means the second queue mentioned in the filter rule. My scp and sftp clients (openssh) certainly don't set it. When I scp, it's ToS 0x8. When I do interactive ssh, it's 0x10. However, be aware that interpretation of the ToS byte, now called the DSCP byte, is totally arbitrary: http://www.isi.edu/in-notes/rfc2474.txt http://www.isi.edu/in-notes/rfc3168.txt (ECN bit) http://www.isi.edu/in-notes/rfc3260.txt (general ISP/NSP info on DSCP) According to RFC, hosts have to provide a way to configure how they handle the values of the DSCP byte (called codepoints for some unfathomable reason). Since you can hack kernel code, perhaps you'd like to take a shot at generalizing the current stuff? Other parties welcome to debate this. Ostensibly, one would want pf to be able to remark traffic as well; the general premise is that DSCP is network-specific, and that ISPs and whatnot would remark at the boundaries. This seems like a natural fit for pf, once some syntax and mechanisms are added. -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -><- <URL:http://www.subspacefield.org/~travis/>
pgpoIuhE6zsj7.pgp
Description: PGP signature
