Stefan Berger <stefanb(a)linux.vnet.ibm.com> wrote on 10/25/2011 05:50:09
AM:
The below algorithm also seems to assume that the VM does not send
802.1Q (VLAN) headers. I remember having had problems when trying to
receive 802.1Q headers when the VM's interface is on a bridge and the
remote traffic comes through the network. I wonder whether it generally
doesn't work. I think at least in the code you should look at the
header, check for ETHERTYPE_IPv4 and then use eh_data[0], otherwise
either discard it or if ETHERTYPE_VLAN (0x8100) is used read the
encapsulated protocol ID and make sure ETHERTYPE_IPv4 is found there and
then use eh_data[4] for further processing.
Stefan,
I added code similar to what you had, but when trying to test it,
I realized that this cannot work with the existing filters. It appears
to me that if a VLAN header is present, that packet won't match any of
the protocols supported and will be dropped (ETHERTYPE_VLAN won't match
IPv4, ARP, RARP, etc). If so, then decoding a VLAN DHCP ACK does no good
because the VM will never see it, and the rules will never even check a
source IP address for a packet that ebtables won't match as an IP packet.
Right?
I saw later your post for VLAN filtering. I haven't played with
vlans much, and especially not with ebtables filtering of vlans. If
we cannot apply the higher-layer protocol rules without making a
complete copy of all of them for VLANs, then I'm not sure I see the
point in having address learning decode VLAN headers.
For the "no spoofing" case, allowing all VLAN packets is clearly
not right, so it appears to me that the current nwfilters simply do
not support the presence of VLANs.
I can leave the current (untested) address matching checks in. It
doesn't hurt the non-VLAN case, if you see some way of adding full VLAN
no-spoofing support in the future. But unless I'm missing something, it
doesn't look to me like the VLAN case works at all now and not supporting
that in DHCP snooping is not a new problem.
+-DLS