Re: [PF] bug in port range.
* Patrick Lamaiziere patf...@davenulle.org [2012-01-03 19:00]: Well because for me 80:82 is (80, 81, 82) and 82:80 the same items and so the same range. but it is NOT the same. I'd claim your expectations is strange ;) So what is the meaning for PF of the range 82:80? If this is a non sense, an error from pfctl would be cool. it isn't nonsense, it just can't match. that is not an error, strictly speaking. it comes down to basic unix philosophy. the system doesn't assume it is more clever than its operator. it does exactly what you tell it to do, no more, no less. port 82 80 defines a range that can't match, and it doesn't. as in, all is good. when you mean 80 82 you ought to write 80 82 and not 82 80. Sure, but when using service name it's easy to make a mistake. In fact I've found this strange behavior while translating a Cisco acl : permit tcp any any range ftp ftp-data Translated to port ftp:ftp-data, which if I understand well does not mean anything for PF. right. pilot error. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: [PF] bug in port range.
* Patrick Lamaiziere patf...@davenulle.org [2012-01-03 17:45]: I think there is a off-by-one error in Packet Filter port ranges, for example with an exclude boundary range : port1 port2 nope. Ports and ranges of ports are specified using these operators: : (range including boundaries) (range excluding boundaries) yes, that is from the manpage, of course. explicitely EXCLUDES the boundaries. now where is that off by one? PF or pfctl does not check that port1 = port2 and if port1 port2 the port range is not correct. pf does what you, the operator, tells it to do. For example 82 80 is not the same as 80 82 (but should IMO). should? why? port 82 80 defines a range that can't match, and it doesn't. as in, all is good. when you mean 80 82 you ought to write 80 82 and not 82 80. Then, port 81 is not filtered out. correct, that is exactly what you told pf to do and it does. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: [PF] bug in port range.
For those of us playing the CS home game. Is this an example of left-to right evaluation? My thought on this was that the value 81 isn't greater than 82 and isn't less than 80, so the rule doesn't match.
Re: [PF] bug in port range.
Le Tue, 3 Jan 2012 17:54:18 +0100, Henning Brauer lists-open...@bsws.de a icrit : Hello, * Patrick Lamaiziere patf...@davenulle.org [2012-01-03 17:45]: I think there is a off-by-one error in Packet Filter port ranges, for example with an exclude boundary range : port1 port2 nope. Ports and ranges of ports are specified using these operators: : (range including boundaries) (range excluding boundaries) yes, that is from the manpage, of course. explicitely EXCLUDES the boundaries. now where is that off by one? Please forget the off-by-one, I've found that 82:80 differs from 80:82 :) PF or pfctl does not check that port1 = port2 and if port1 port2 the port range is not correct. pf does what you, the operator, tells it to do. For example 82 80 is not the same as 80 82 (but should IMO). should? why? Well because for me 80:82 is (80, 81, 82) and 82:80 the same items and so the same range. But you are right, the man page is explicit. I should re-read it more often. So what is the meaning for PF of the range 82:80? If this is a non sense, an error from pfctl would be cool. port 82 80 defines a range that can't match, and it doesn't. as in, all is good. when you mean 80 82 you ought to write 80 82 and not 82 80. Sure, but when using service name it's easy to make a mistake. In fact I've found this strange behavior while translating a Cisco acl : permit tcp any any range ftp ftp-data Translated to port ftp:ftp-data, which if I understand well does not mean anything for PF. Thanks, regards.