Port/portrange: syntax incompatibilities in edge cases with regards to libpcap

[kbara]

On the good side: pflua appears to have fairly good libpcap compatibility on this point. The only incompatible detail that has appeared is that pflua does not treat hexadecimal arguments to portrange as a 0.

libpcap version 1.5.3, pflua 5e2c56baa0cf1ec471719bac83e2a99c4e2d5495

portrange x-y requires both x and y to be decimal numbers; if they are not, it has rather unintuitive behaviour. Numbers starting with an 0x cause a parse error in pflua and are treated as 0 by libpcap, in expressions like "portrange 1-0x3. Numbers starting with a 0 are treated as decimal, rather than octal:

% ./pflua-compile  "portrange 1-0151661"
luajit: ../src/pf/parse.lua:425: port 151661 out of range

% tcpdump -d "portrange 1-0151661"
tcpdump: illegal port number 151661 > 65535

---

Note that port can take octal and hexadecimal values. For instance, port 0151661 is tested against #0xd3b1 in libpcap, and 45523 in pflua on x86 (0xb1d3 - it's not abstracting away network byte order vs x86 byte order, but it gives the correct result).

[mpeterv]

It seems that libpcap does not accept hexadecimal numbers as the first port in portrange ("portrange 0x-1" gives "unknown port in range '0x-1'". On the other hand, for the second port it simply ignores any garbage after the number, e.g. "portrange 1-20" and "portrange 1-20foobar" produce same code.

For octal numbers, I personally think it makes sense to ignore leading zero in contexts where only decimal numbers are expected.

If you are looking for other incompatibilities, I noticed that libpcap accepts single number as portrange argument, so that "portrange N" is equivalent to "port N". Another thing is that pflua doesn't seem to support hexadecimal literals starting with 0X.

[kbara]

Good observations, thank you!