Re: IPFilter 4.1.33 with backward compatibility

[Darren Reed <darrenr%netbsd.org@localhost>]

Christos Zoulas wrote:
> On Dec 17, 12:53am, darrenr%netbsd.org@localhost (Darren Reed) wrote:
> -- Subject: Re: IPFilter 4.1.33 with backward compatibility
> 
> | matthew green wrote:
> | > hi darren.
> | > 
> | > 
> | > thank you so much for working on this.  it's been 12 years or
> | > more coming (since i first asked anyway :-)
> | > 
> | > i patched my netbsd-current kernel with your changes.  it seems
> | > to mostly work.  i'm having trouble loading ipf rules on 32 bit
> | > platforms.
> | > 
> | > it seems to be 64-bit time-t related.  struct frentry has a
> | > struct timeval, which has changed (on 32 bit only...) struct
> | > frentry{} in 5.0 on i386 is 396 bytes, but 400 in -current.
> | > 
> | > 
> | > fixing this looks really ugly, i'm afraid to say...
> | 
> | Hmmm, maybe the thing to do is to put that timeval (and any
> | others) in a union that's 12 bytes in size and bump the version
> | of ipfilter (that will happen anyway before these changes are
> | committed.)
> | 
> | There is one program that will break - ipmon. The way to fix
> | this might be to define "struct iplog" to use long for what it
> | puts seconds in and store the time in a local variable that
> | then is copied in. At some later date, an ioctl could be added
> | that tells ipfilter what size timestamp ipmon can deal with.
> | 
> | Afterall, the goal isn't to remain backward compat with 5.99.X,
> | only actual releases, such as 5.0.
> 
> Please use only fixed length types in structures that are passed
> between userland and kernel. Remember compat_32...

A 32bit /sbin/ipf will not work with a 64bit sparc64
kernel because the structure in question already
contains a whole swag of pointers.

Darren