Darren Reed writes: > On BSD, the same rule works (applying to both broadcast and multicast) > but because of the flags that are specific to broadcast/multicast are > present in their equivalent of the mblk_t, it is also possible to write > rules that are specific to one, e.g: > > block in quick all with broadcast
So ... should that same thing work on Solaris one day or not? You previously said that IP Filter doesn't need to know the difference between broadcast and multicast. But this makes it look as though knowing that difference would in fact benefit IP Filter. > >I don't think that's the point. The point is what sort of > >functionality makes sense for users of this interface. What gyrations > >IP may need to go through to provide the needed information are a > >separate design and implementation matter (and I don't think I share > >the concern about "scope" -- our IP _implementation_ is already hip > >deep in MAC layer trivia, and doing a compare between dl_dest_addr_* > >and dl_brdcst_addr_*, to both of which IP has ready access, shouldn't > >be hard). > > > > > > I'll look into this but it makes no difference to the architecture, > only the implementation that would enable setting just one of > the flags rather than both. I disagree. Setting both flags as an attempted emulation of the BSD interface _is_ architectural, because it means that consumers of the interface can't actually rely on it to implement user interface artifacts such as the "with broadcast" filter. I could go along with this _if_ there's a commitment to repair the interface before changing the stability. "Repair" would mean that either the flags operate as intended, or that the interface itself is removed. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
