-
Notifications
You must be signed in to change notification settings - Fork 9
Description
The firewall inspects the ethertype and rejects anything that doesn't match IPv4, IPv6, or ARP.
In the IEEE 802.1Q VLAN tagging case, an IEEE 802.1Q header is placed between the source MAC and the ethertype containing a tag protocol identifier and tagging information. The firewall thus reads the tag protocol identifier (typically 0x8100), sees that it doesn't match IPv4, IPv6, or ARP, and rejects the packet.
Potential fix:
To fix this, I suggest that we:
- Define a
struct TaggedEthernetHeaderthat matches the Ethernet header in the IEEE 802.1Q VLAN tagging case; - Before we parse the ethertype field, check if its value corresponds to IEEE 802.1Q VLAN tagging;
- If so, re-cast into a
TaggedEthernetHeaderbefore entering the Ethertype switch.
We should do that on ingress and egress.
A similar solution could be applied to support other forms of tagging such as IEEE 802.1ad double tagging, though I doubt we need support for that now.
Notes:
This should not be considered a priority, as the FreeRTOS+TCP stack does not currently support VLAN tagging. Adding support for VLAN tagging to the firewall without support in the network stack is not useful.
We will have the same problem with the incoming DNS resolver: #50