Adding 255.255.255.255/32 to an ipfw table results in "Invalid argument". This is a freshly-installed 11.1-RELEASE system: FreeBSD kiki0 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 04:10:47 UTC 2017 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 Repeat by: ********************************************************************** root@kiki0:/usr/local/etc # ipfw /dev/stdin table 30 create type addr algo addr:radix table 30 add 255.255.255.254/32 added: 255.255.255.254/32 0 table 30 add 255.255.255.255/32 error: 255.255.255.255/32 0 Line 3: Adding record failed: Invalid argument root@kiki0:/usr/local/etc # ipfw /dev/stdin table 30 list --- table(30), set(0) --- 255.255.255.254/32 0 table 30 detail --- table(30), set(0) --- kindex: 3, type: addr references: 0, valtype: legacy algorithm: addr:radix items: 1, size: 416 IPv4 algorithm radix info items: 1 itemsize: 72 IPv6 algorithm radix info items: 0 itemsize: 76 table 30 destroy ^D root@kiki0:/usr/local/etc # ********************************************************************** See also bug #180731 -- it's hard not to suspect that there is a tendency toward confusion between -1 as an error code and 255.255.255.255, which has the same bit pattern (at least on 32-bit machines).
Is 255.255.255.255 a valid IP address -- in every netmask it is a broadcast destination, right?
(In reply to Conrad Meyer from comment #1) The reason why I want to add 255.255.255.255/32 to a table even though it's not a valid IP address is because the table lists things that are invalid. See BAD_ADDR_TBL in /etc/rc.firewall, which arguably should contain this entry.
(In reply to Dave Eckhardt from comment #2) Dave, thanks. That makes a lot of sense.
255.255.255.255 is a special broadcast IP addresses used to broadcast on "this network". That is not applicable in this case though. BUT 255.255.255.255 should be a perfectly valid table entry for the reasons the submitter stated. If for some odd reason someone got this IP on the wire you would want ipfw to filter it out. As a workaround you could use 255.255.255.254/31, this is pretty safe as: 240.0.0.0/4 is "reserved". Which you could also use to block this, and if your trying to block bad addresses you should block 240/4 anyway. I am not sure how much effort it is worth trying to fix this. And now that I see: ${fwcmd} table ${BAD_ADDR_TBL} add 240.0.0.0/4 is already in /etc/rc.firewall which would include 255.255.255.255 this bug could be closed as "to hard to fix"
(In reply to Rodney W. Grimes from comment #4) I agree that workarounds are possible. For example, if some values won't fit into a table, it is possible to handle those values via a separate rule check. But firewall rule systems are hard enough to understand if they work the way they are documented as working. Random misbehaviors, even if survivable, make the system much harder to understand. Again please see bug #180731 which is a different problem with the same "odd" value (it seems as if on amd64 machines you can get the value into the table but you can't see it once it's there). I guess I would argue against closing either bug, on the grounds that it/they might make a nice starter project for somebody looking to do serious work on ipfw. Thanks for looking at my report so quickly!
Interestingly, there seem to be an issue with the ipfw <> radix interaction. ipfw record add process for radix-backed table: input -> ta_prepare_add_radix() -> tei_to_sockaddr_ent() ta_add_radix -> rnh->rnh_addaddr() == rn_addroute() dtrace: ## good one: 1 65028 tei_to_sockaddr_ent:return addr=255.255.255.251 mask=255.255.255.255 1 26742 rn_addroute:entry addr=fffff8006fc26560 mask=0 rh=fffff80005046d00 elem=fffff8006fc26500 key: addr=255.255.255.251 len=8 family=2 1 26743 rn_addroute:return ret=fffff8006fc26500 1 64859 ta_add_radix:return return=0 ## bad one: 1 65028 tei_to_sockaddr_ent:return addr=255.255.255.255 mask=255.255.255.255 1 26742 rn_addroute:entry addr=fffff8006fc26be0 mask=0 rh=fffff80005046d00 elem=fffff8006fc26b80 key: addr=255.255.255.255 len=8 family=2 1 26743 rn_addroute:return ret=0 1 64859 ta_add_radix:return return=22 ## in general, radix seem to work with 255.255.255.255: ## route add -host 255.255.255.255 10.0.0.2 1 26742 rn_addroute:entry addr=fffff80003b63ce0 mask=0 rh=fffff80003b02800 elem=fffff800320cdc30 key: addr=255.255.255.255 len=16 family=2 1 26743 rn_addroute:return ret=fffff800320cdc30
This issue is still present in 12.3-STABLE (rev d891ee6ac7e6af693959c6d11c5af7c440919ea9). Inclusion of the limited broadcast address in a table has legitimate uses. Selectively allowing DHCP requests in is an example, there are surely several more. I think this should be fixed.