> > Huh, there's a fair amount of subtlety there. What about logic similar to > the following (untested) code? > > -=-=-=-=-=-=-=-=- > ovs_be32 mask = be32_prefix_mask(ps.ipv4_addrs[i].plen); > /* When the netmask is applied, if the host portion is > * non-zero, the host can only use the specified > * address. If zero, the host is allowed to use any > * address in the subnet. */ > if (ps.ipv4_addrs[i].addr & ~mask) { > ds_put_format(&match, IP_FMT, > IP_ARGS(ps.ipv4_addrs[i].addr)); > } else { > ip_format_masked(ps.ipv4_addrs[i].addr & mask, mask, > &match); > } > -=-=-=-=-=-=-=-=- > > > Below is the port security description > > > > <p> > > Each element in the set may additionally contain one or more > IPv4 or > > IPv6 addresses (or both), with optional masks. If a mask is > given, it > > must be a CIDR mask. In addition to the restrictions > described for > > Ethernet addresses above, such an element restricts the IPv4 > or IPv6 > > addresses from which the host may send and to which it may > receive > > packets to the specified addresses. A masked address, if the > host part > > is zero, indicates that the host is allowed to use any address > in the > > subnet; if the host part is nonzero, the mask simply indicates > the size > > of the subnet. In addition: > > </p> > > The next paragraph is interesting because it describes what should happen > with the subnet: > > · If any IPv4 address is given, the host is also > allowed to > receive packets to the IPv4 local broadcast > address > 255.255.255.255 and to IPv4 multicast > addresses > (224.0.0.0/4). If an IPv4 address with a mask is > given, > the host is also allowed to receive packets to the > broad‐ > cast address in that specified subnet. > > Would you mind expanding the tests to make sure that we're testing these > different combinations both on the send and receive enforcement? We > clearly had some gaps before. > > Sure. I will do that. Thanks for the suggestions and comments.
> Thanks for noticing these issues. > > --Justin > > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev