diff options
author | Simon Horman <horms@verge.net.au> | 2009-05-06 19:02:29 +0400 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2009-05-09 01:54:47 +0400 |
commit | be8be9eccbf2d908a7e56b3f7a71105cd88da06b (patch) | |
tree | 0046061772516257c3bc6b63fdacee12dcd34e5d /drivers | |
parent | e81963b180ac502fda0326edf059b1e29cdef1a2 (diff) | |
download | linux-be8be9eccbf2d908a7e56b3f7a71105cd88da06b.tar.xz |
ipvs: Fix IPv4 FWMARK virtual services
This fixes the use of fwmarks to denote IPv4 virtual services
which was unfortunately broken as a result of the integration
of IPv6 support into IPVS, which was included in 2.6.28.
The problem arises because fwmarks are stored in the 4th octet
of a union nf_inet_addr .all, however in the case of IPv4 only
the first octet, corresponding to .ip, is assigned and compared.
In other words, using .all = { 0, 0, 0, htonl(svc->fwmark) always
results in a value of 0 (32bits) being stored for IPv4. This means
that one fwmark can be used, as it ends up being mapped to 0, but things
break down when multiple fwmarks are used, as they all end up being mapped
to 0.
As fwmarks are 32bits a reasonable fix seems to be to just store the fwmark
in .ip, and comparing and storing .ip when fwmarks are used.
This patch makes the assumption that in calls to ip_vs_ct_in_get()
and ip_vs_sched_persist() if the proto parameter is IPPROTO_IP then
we are dealing with an fwmark. I believe this is valid as ip_vs_in()
does fairly strict filtering on the protocol and IPPROTO_IP should
not be used in these calls unless explicitly passed when making
these calls for fwmarks in ip_vs_sched_persist().
Tested-by: Fabien DuchĂȘne <fabien.duchene@student.uclouvain.be>
Cc: Joseph Mack NA3T <jmack@wm7d.net>
Cc: Julius Volz <julius.volz@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers')
0 files changed, 0 insertions, 0 deletions