[Firehol-support] FireQOS srcmac and dstmac matching and IPv6

[Phineas Gage]

> On Nov 15, 2014, at 7:16 PM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
> 
> 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.

I just pulled down the latest automatic build (e190008) and it works well for me. You’re probably right to leave the check in, as the documentation for the “interface” keyword makes it clear that shaping applies to IP traffic. I’d be surprised to find out someone was using it to shape a protocol besides IP.

> 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
> only.
> 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.

That makes sense. IPv6 adoption worldwide is still shy of 5%. Maybe one day it will matter more. I don’t prioritize SYNs or ACKs in my setup so am not affected by that.

Thanks!

> 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
>> http://lists.firehol.org/mailman/listinfo/firehol-support