[Firehol-support] FireQOS srcmac and dstmac matching and IPv6
costa at tsaousis.gr
Sat Nov 15 18:16:52 GMT 2014
I just pushed a version of FireQOS that checks the protocol and
generates proper matches for ipv4 and ipv6 for srcmac/dstmac (it
checks the ether_type for ipv4 and ipv6, it does not check ether_type
for anything else).
I am not sure either if the ether_type check should be omitted
completely. Probably it should, but I can't get this decision without
understanding its implications. I suggest to leave it like this for
the moment until someone reports something related to it.
You are right that ipv6 support should be enabled by default. However,
there are a few problems with it:
1. The generated rules will be twice as many by default. This is
minor, but it is a negative point for most people that still use ipv4
2. I don't know yet how to match certain things for ipv6, like SYN and
ACK packets or match the length of the packets. Generally, there is
very little info for TC and IPv6 out there.
So, yes it should be enabled by default, but I think it will be more
of a problem for the moment.
On Fri, Nov 14, 2014 at 3:10 PM, Phineas Gage <phineas919 at gmail.com> wrote:
> When you specify srcmac and dstmac to FireQOS, IPv6 packets are not matched. It has to do with the $smac_arg and $dmac_arg arguments, which specify the ethertype value of 0x0800 with "match u16 0x0800 0xFFFF at -2”. If you remove this part of the match altogether and just check the MAC address, it works, but I don’t know the consequences of that. Maybe it should match the protocol of its parent class? In that case, the ethertype of IPv6 is 0x86DD. Really not sure what’s the right behavior, whether it should check the ethertype value or not.
> Also not sure if the MAC address offsets would work for a VLAN with an 802.1Q tag, but that’s not my case. However, it might actually work fine because the 802.1Q tag might be stripped out at the hardware layer by VLAN acceleration anyway (the same reason why tcpdump -xx doesn’t show the 802.1Q value <https://bugzilla.redhat.com/show_bug.cgi?id=498981#c4>). Just a thought.
> One last thing is that I was confused for a little while, then finally realized that “interface” does not mean “interface46” but “interface4”, so that caused some surprises. :) Is it possible that “interface” could default to “interface46”, or would that have some unintended consequences?
> Matching is looking better now, but I still have some testing to do. I probably didn’t notice these IPv6 things before because my IPv6 setup wasn’t very good, so my browser was probably not using it much, and in that case srcmac and dstmac was working fine. Working with ping and ping6 explicitly helped to figure things out.
> Firehol-support mailing list
> Firehol-support at lists.firehol.org
More information about the Firehol-support