EINVAL when using libipt_limit on sparc64, revisited

[Jed Davis]

Jed Davis <jldavis+netfilterlist@cs.oberlin.edu> writes:
> 
> I also noticed that the size and layout of struct ipt_rateinfo,
> defined in /usr/include/linux/netfilter_ipv4/ipt_limit.h, change
> depending on whether the compiler is 32/64-bit (one member is unsigned
> long, another is a pointer where the alignment changes its offset).
> So I fiddled the struct definition to make it word-size-independent,
> but still got the unhelpful error message.
> 
This was actually the right thing to do.  Unfortunately, I did it in
the wrong header file.  Had I just made those changes in
/usr/src/linux/include/..., I wouldn't have had to spend hours and
hours with gdb and emacs and grep tracking function calls back and
forth across the kernel/user boundary...  well, such is life.  Anyway,
the problem is specifically that the struct ipt_rateinfo, even when
8-byte-aligned, changes size depending on the word size; the user code
sends what it thinks the size is into the kernel, which flags the
difference and sends an error back through the mists of time to be
cryptically printed out by the iptables process.

The best solution I can think of now is either to condition on
KERNEL_64_USERSPACE_32 to modify the struct so that it would have the
proper layout, or use the IPT_ALIGN and/or IPT_MIN_ALIGN macros, if
defined, to generate appropriate padding.  The former would be
simpler; the latter would be more general.  I'll probably do the
latter, if I (or anyone else) can't think up anything better by
tomorrow.  In either case a line in the iptables user-code Makefile
needs to be moved to have the appropriate compiler flags take effect
for the modules. 

--Jed

-- 
"But life wasn't yes-no, on-off.  Life was shades of gray, and rainbows
not in the order of the spectrum."   -- L. E. Modesitt, Jr., _Adiamante_

sub f{(($n,$d,@_)=@_)?(substr(" ExhortJavelinBus",$n&&$d/$n,1),$n?f($d%$n,$
n,@_):&f):("\n")}print f 1461,10324,55001,444162,1208,1341,5660480,79715997