IPFilter 4.1.33 with backward compatibility

[Darren Reed]

With every update ipfilter in current, there's always
a request to have the changes back ported that gets
shelved because of compatibility issues. The support
to deal with that has always been there, I've just
never done anything to make it happen.

So I'd appreciate it if a couple of volunteers could
download the code at the link below and either update
their LKM with one built from it or update their kernel
source and give it a go. If you're going to build a
static kernel, you'll need to ensure that all of the
ipfilter kernel bits all get built with "-DIPFILTER_COMPAT=1".
Eventually, this will need to go into opt_ipfilter.h.

http://coombs.anu.edu.au/~avalon/ipf41c.tgz

What you should see is something like this:
excalibur# dmesg | tail -3
IP Filter: loaded into slot 44
IP Filter: v4.1.33 initialized. Default = pass all, Logging = enabled
LKM 'IP Filter: v4.1.33': forced load, skipping compatibility checks
excalibur# modstat
Type Id Offset Loadaddr Size Info Rev Module Name
DEV 0 -1/44 cbba0000 0094 cbbc0e40 2 IP Filter: v4.1.33
excalibur# ipf -V
ipf: IP Filter: v4.1.24 (396)
Kernel: IP Filter: v4.1.24
Running: yes
Log Flags: 0 = none set
Default: pass all, Logging: available
Active list: 0
Feature mask: 0x87

.. yes, "ipf -V" is displaying correct information,
it is just the kernel that is lieing for compat. reasons.

One word of caution: compatibility with IPFilter versions
prior to 4.1.14 may be limited because programs such as
ipfstat were still using /dev/kmem to get live information
rather than ioctls.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[matthew green]

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...


.mrg.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by matthew green
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.

Darren

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

On Dec 17, 12:53am, ***@netbsd.org (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...

christos

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Christos Zoulas
-- Subject: Re: IPFilter 4.1.33 with backward compatibility
| > 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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Christos Zoulas]

Post by Darren Reed

Post by Christos Zoulas
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.

structures passed between kernel and userland should ideally not contain
pointers...

christos


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[matthew green]

Post by matthew green
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.)

that probably seems easiest. i didn't see anything else that
needs this help -- no other time_t, timeval or dev_t's.

let me know when you have another patch to try out. :-) you
can easily see it on any netbsd 5 userland netbsd-current kernel
with a 32 bit system.

Afterall, the goal isn't to remain backward compat with 5.99.X,
only actual releases, such as 5.0.

yes, that is our (netbsd) goal as well. (we try to do it for
-current versions, too, but there's much less care here.)

thanks.


.mrg.

ps: if you're switching stuff around, it may be nice to make
everything used fixed-size types to help 32bit compat. we've
tended to put things into 64 bit items including for pointers.
i think this one is a harder problem, we should solve after
the basics work, but if you're already changing something it
is a good time to make this sort of change as well. we can
handle dealing with 32 bit pointers and 32 bit data items
being converted in netbsd32, but there are nicer ways to avoid
it...

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Just to tie up this loose end, this work was completed.

At some point in the near future, I will update NetBSD's
in-tree source code for IPFilter.

http://coombs.anu.edu.au/~avalon/ip_fil4.1.34.tar.gz

Darren

Post by Darren Reed

Post by matthew green
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.)
that probably seems easiest. i didn't see anything else that
needs this help -- no other time_t, timeval or dev_t's.
let me know when you have another patch to try out. :-) you
can easily see it on any netbsd 5 userland netbsd-current kernel
with a 32 bit system.
Afterall, the goal isn't to remain backward compat with 5.99.X,
only actual releases, such as 5.0.
yes, that is our (netbsd) goal as well. (we try to do it for
-current versions, too, but there's much less care here.)
thanks.
.mrg.
ps: if you're switching stuff around, it may be nice to make
everything used fixed-size types to help 32bit compat. we've
tended to put things into 64 bit items including for pointers.
i think this one is a harder problem, we should solve after
the basics work, but if you're already changing something it
is a good time to make this sort of change as well. we can
handle dealing with 32 bit pointers and 32 bit data items
being converted in netbsd32, but there are nicer ways to avoid
it...

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de