Date: Sat, 13 Jul 2002 01:35:09 -0700 From: Luigi Rizzo <luigi@FreeBSD.org> To: Mike Barcroft <mike@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: New ipfw isn't 64-bit clean Message-ID: <20020713013509.B59424@iguana.icir.org> In-Reply-To: <20020713003829.A64412@espresso.q9media.com>; from mike@FreeBSD.org on Sat, Jul 13, 2002 at 12:38:29AM -0400 References: <20020713003829.A64412@espresso.q9media.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Seems to me that the problem is not in ipfw2.c but rather in different structure padding when compiling the kernel and userland. ipfw2.c uses sizeof() to determine the size of the structure so it does not make any assumptions on operand sizes etc. Re. the printf problems could you submit a patch ? I basically copied the code in the old ipfw for all printf() so the problems must have been there as well. cheers luigi On Sat, Jul 13, 2002 at 12:38:29AM -0400, Mike Barcroft wrote: > In struct ip_fw, the member timespace becomes padded with 32-bits > because a pointer follows it. This causes the RULESIZE() macro to > miscalculate the size of the rule by 4 bytes. Resulting in EINVAL > and kernel warnings: > > %%% > bowie# ipfw add allow all from me to 192.168.3.1 > 00000 allow ip from me to 192.168.3.1 > ipfw: size mismatch (have 64 want 68) > ipfw: getsockopt(IP_FW_ADD): Invalid argument > %%% > > (Shouldn't 00000 be 00100?) > > I worked around the breakage by moving next_rule to the second > position in the struct. I imagine the real solution involves not > jamming kernel pointers into public interfaces. > > Also, ipfw(8) has lots of warnings as a result of printf()s with > deprecated quad_t's. This should be easily fixed by using intmax_t's. > > Best regards, > Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020713013509.B59424>