Right, I think it should work because in order to have a non-zero TCP
port the flow setup code will require that we have an exact match on
the IP protocol.
I added a log message and applied this patch.
On Tue, Jul 16, 2013 at 3:09 PM, Andy Zhou wrote:
> Never mind. It is also covered.
>
>
> On T
Never mind. It is also covered.
On Tue, Jul 16, 2013 at 3:07 PM, Andy Zhou wrote:
> What if the IP protocol field is partially masked?
>
>
> On Tue, Jul 16, 2013 at 1:54 PM, Jesse Gross wrote:
>
>> I think it actually is safe even in the presence of partial masks
>> because of the way that we
What if the IP protocol field is partially masked?
On Tue, Jul 16, 2013 at 1:54 PM, Jesse Gross wrote:
> I think it actually is safe even in the presence of partial masks
> because of the way that we are enforcing the checks. For example, if
> we have a set TCP action then it isn't safe to just
I think it actually is safe even in the presence of partial masks
because of the way that we are enforcing the checks. For example, if
we have a set TCP action then it isn't safe to just look at the IP
protocol because that could correspond to a packet that is truncated
after the IP header. Instead
Using masked key for validate_and_copy_actions() won't be safe against
partially masked fields.
It may not be a problem in practice, but it is technically possible with
the netlink messages.
Would you please add a error log before returning EINVAL.
I like the API clean ups. It makes the code easi
It is important to validate flow actions to ensure that they do
not try to write off the end of a packet. The mechanism to do this
is to ensure that a flow is precise enough to describe valid vs.
invalid packets and only allowing actions on valid flows.
The introduction of megaflows broke this by
