IPFW IPFW IPv6 dummynet invalid mask len

[tonyhain]

I am still struggling with the syntax of ipfw, so this may be operator error, but when I put in:

...
mask24="0xffffff00"
mask48="0xffffffffffff00000000000000000000"
...
$IPFWa 1123 pipe 123 ip from any to any out
$IPFWp 123 config bw 2kbit/s
$IPFWq 123 config pipe 123 mask dst-ip $mask24
$IPFWq 123 config pipe 123 mask dst-ip6 $mask48

----- variables substituted that last line is ----

ipfw -q queue 123 config pipe 123 mask dst-ip6 0xffffffffffff00000000000000000000

the output is --

...
Bump flowset buckets to 64 (was 0)
Bump WF2Q+ weight to 1 (was 0)
ipfw: in6addr invalid mask len
...

it would appear that the code block in dummynet.c is:

                           } else if (pa6 != NULL) {
                                    if (a > 128)
                                        errx(EX_DATAERR,
                                            "in6addr invalid mask len");
                                    else
                                        n2mask(pa6, a);

Replacing the variable with the 0xffffffffffff00000000000000000000 string doesn't work either, so it doesn't appear to be a substitution problem. I have counted multiple times, and even retyped the IPv6 mask, so I am fairly sure it is 128 bits, but clearly the comparison listed above in dummynet.c thinks otherwise. That is the only place I could find that had the specific error string in the return message.

Am I getting the syntax wrong, or is there something in a parser that is sending more than 128 bits to the test in dummynet.c ???

 

[tonyhain]

found what appears to be the work-around when I stumbled across:
http://www.ogris.de/oldnews.html

 ...
If you're limiting IPv6 traffic, you should use the latter variant only:
pipe 2 config mask dst-ip6 /64 bw 42KBit/s ...
Internally, the variable which holds the value of src-ip/src-ip6/dst-ip/dst-ip6 is an unsigned 32 bits integer, which overflows and yields an error if given anything larger than 0xffffffff.

That doesn't actually work at this point:

# ipfw -q queue 123 config pipe 123 mask dst-ip6 /48
ipfw: pathname: /48: No such file or directory


It would be useful if the dummynet maintainer would actually fix the apparent uint-32 problem at some point, because that work-around is from 4 years ago. If it actually worked back then, something else has changed because the current parser tries to open a file named 48 in /. Note the different error from above...

# touch /48
# ipfw -q queue 123 config pipe 123 mask dst-ip6 /48
ipfw: extraneous filename arguments /48


 

[tonyhain]

So it looks like I figured out the string that doesn't fail thinking it is a file name. I don't know if it actually works yet, but the string that doesn't generate an error response is:
ipfw queue 123 config pipe 123 mask dst-ip6 ffff:ffff:ffff::/48
In any case the man page needs to be updated to show a working ipv6 example. Clearly a straight translation of the existing IPv4 example will not work. The code should be fixed to allow that, but it probably makes more sense to deprecate the 0x... format in favor of the cidr syntax anyway, and drop the hex IPv4 example. It wouldn't hurt to put in a syntax check to deal with the problem of interpreting a leading / as a file name when it follows a mask command.