4.1.30 and 4.1.31 build failure on S10x86 5/08

[J.D. Bronson]

(Using Sun Studio 12 with all patches and OS fully patched)

4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c

[4.1.29 compiles just fine....]


I didnt see anything in the list archives about anyone reporting
a problem....


/opt/SUNWspro/prod/bin/cc -Xa -xildoff -I. -I../.. -DIPFILTER_LKM
-I../../../pfil -D_KERNEL -DSUNDDI -DSOLARIS2=10 -DIPFILTER_LOG
-DIPFILTER_LOOKUP -DIPFILTER_SCAN -c ../../radix.c -o radix.o
/opt/SUNWspro/prod/bin/cc -Xa -xildoff -I. -I../.. -DIPFILTER_LKM
-I../../../pfil -D_KERNEL -DSUNDDI -DSOLARIS2=10 -DIPFILTER_LOG
-DIPFILTER_LOOKUP -DIPFILTER_SCAN -c ../../md5.c -o md5.o
/opt/SUNWspro/prod/bin/cc -Xa -xildoff -I. -I../.. -DIPFILTER_LKM
-I../../../pfil -D_KERNEL -DSUNDDI -DSOLARIS2=10 -DIPFILTER_LOG
-DIPFILTER_LOOKUP -DIPFILTER_SCAN -DNEED_LOCAL_RAND=1 -c
../../arc4random.c -o arc4random.o
"../../arc4random.c", line 46: warning: no explicit type given
"../../arc4random.c", line 46: syntax error before or at: void
"../../arc4random.c", line 242: warning: pointer to void or function
used in arithmetic
"../../arc4random.c", line 242: warning: pointer to void or function
used in arithmetic
cc: acomp failed for ../../arc4random.c
*** Error code 2
make: Fatal error: Command failed for target `arc4random.o'
Current working directory /export/home/junk/ip_fil4.1.31/SunOS5/i386-5.10
*** Error code 1
make: Fatal error: Command failed for target `sunos5'
Current working directory /export/home/junk/ip_fil4.1.31
*** Error code 1
make: Fatal error: Command failed for target `solaris'


..this is with all patches and after a full fresh install.

[Charles Seeger]

+------ "J.D. Bronson" wrote (Fri, 17-Oct-2008, 19:07 -0500):
|
| (Using Sun Studio 12 with all patches and OS fully patched)
|
| 4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
|
| [4.1.29 compiles just fine....]

Similar problems on Solaris 8 SPARC. See:

http://sourceforge.net/tracker/index.php?func=detail&aid=2063742&group_id=169098&atid=849053

As said there, the patch gets the compile to complete, but I haven't
tested the result (I have 4.1.29 installed, and it is likely to be
a while before I get back to this). The same patch submitted there
is included below. Let us know if it actually works. 8-)

HTH,
Chuck
--
Charles Seeger
***@cise.ufl.edu

--- arc4random.c.orig 2008-07-26 16:08:18.000000000 -0400
+++ arc4random.c 2008-09-07 22:10:35.738378000 -0400
@@ -18,6 +18,9 @@
#ifdef __FreeBSD__
# include <sys/libkern.h>
#endif
+#ifdef SUNDDI
+# include <sys/conf.h> /* uniqtime() decl from <sys/systm.h> */
+#endif
#include <sys/lock.h>
#include <sys/mutex.h>
#include <sys/time.h>
@@ -25,6 +28,9 @@
#include <sys/socket.h>
#include <net/if.h>
#include <netinet/in.h>
+#ifdef SOLARIS2
+# include <netinet/in_systm.h> /* n_long typedef */
+#endif
#include <netinet/ip.h>
#include "netinet/ip_compat.h"
#include "md5.h"
@@ -43,7 +49,11 @@
static u_int8_t arc4_randbyte(void);
static int ipf_read_random(void *dest, int length);

+#ifdef __SUNPRO_C
+static inline void
+#else
static __inline void
+#endif
arc4_swap(u_int8_t *a, u_int8_t *b)
{
u_int8_t c;

[J.D. Bronson]

Post by Charles Seeger
| 4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
|
| [4.1.29 compiles just fine....]
http://sourceforge.net/tracker/index.php?func=detail&aid=2063742&group_id=169098&atid=849053
As said there, the patch gets the compile to complete, but I haven't
tested the result (I have 4.1.29 installed, and it is likely to be
a while before I get back to this). The same patch submitted there
is included below. Let us know if it actually works. 8-)

as expected, the patch permits the compile to complete.
I am leery of testing this in the real world though.

Why? - This was posted to sourceforge OVER A MONTH AGO and there has been
no feedback or comments from Darren or anyone else.

Is IPFilter still supported and maintained?

If so, why has there been no 'official' word about this compile issue and
if this provided patch you submitted is appropriate ???

Unless I am missing something here?

-JD

[Charles Seeger]

+------ "J.D. Bronson" wrote (Sat, 18-Oct-2008, 05:30 -0500):
|
| At 09:07 PM 10/17/2008 -0400, you wrote:
| >| 4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
| >|
| >| [4.1.29 compiles just fine....]
| >
| >Similar problems on Solaris 8 SPARC. See:
| >
| >
| >http://sourceforge.net/tracker/index.php?func=detail&aid=2063742&group_id=169098&atid=849053
| >
| >As said there, the patch gets the compile to complete, but I haven't
| >tested the result (I have 4.1.29 installed, and it is likely to be
| >a while before I get back to this). The same patch submitted there
| >is included below. Let us know if it actually works. 8-)
|
|
| as expected, the patch permits the compile to complete.

Good to hear that it compiles on Solaris 10 as well as 8.

| I am leery of testing this in the real world though.
|
| Why? - This was posted to sourceforge OVER A MONTH AGO and there has been
| no feedback or comments from Darren or anyone else.

Do consider that likely I was delinquent in only putting it up on
the Sourceforge bug tracker without announcing it either here or
to Darren privately. Also consider that Solaris 10 comes with
IPFilter already compiled, so relatively few will be attempting
to compile the latest versions on that platform. The new features
in 4.1.31 over 4.1.29, of which the arc4random.c is a major part,
are not of much immediate use in my environment.

OTOH, it seems as though Darren has or had some employment or
crontracting connection with Sun, presummably with integrating
IPFilter into Solaris (and perhaps more). So, I'm a bit suprised
that he allowed something to creep into IPFilter with compilation
problems on Solaris. Although arc4random.c appears to have been
a contribution from the FreeBSD community, and it may have been
rushed into IPFilter, I too am a bit disappointed not to see a
fix since the release back in late July. I'm guessing that
Darren has been busy with other tasks. Improving the IPFilter
build system hopefully is on his task list somewhere. 8-)

Best Regards,
Chuck

And thanks to Darren for all his contributions, past and future.

[Darren Reed]

J.D. Bronson wrote:
| At 09:07 PM 10/17/2008 -0400, you wrote:
|> | 4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
|> |
|> | [4.1.29 compiles just fine....]
|>
|> Similar problems on Solaris 8 SPARC. See:
|>
|>
|>
http://sourceforge.net/tracker/index.php?func=detail&aid=2063742&group_id=169098&atid=849053
|>
|> As said there, the patch gets the compile to complete, but I haven't
|> tested the result (I have 4.1.29 installed, and it is likely to be
|> a while before I get back to this). The same patch submitted there
|> is included below. Let us know if it actually works. 8-)
|
|
| as expected, the patch permits the compile to complete.
| I am leery of testing this in the real world though.
|
| Why? - This was posted to sourceforge OVER A MONTH AGO and there has been
| no feedback or comments from Darren or anyone else.
|
| Is IPFilter still supported and maintained?

So, this problem is with Solaris 8.

My priority is with Solaris 9 & 10 because I can easily run them the
x86 versions in a virtual machine rather than needing to power a whole
other system.

Darren

[Darren Reed]

J.D. Bronson wrote:
| At 09:07 PM 10/17/2008 -0400, you wrote:
|> | 4.1.30, 4.1.31, 5.0.4 all fail on arc4random.c
|> |
|> | [4.1.29 compiles just fine....]
|>
|> Similar problems on Solaris 8 SPARC. See:
|>
|>
|>
http://sourceforge.net/tracker/index.php?func=detail&aid=2063742&group_id=169098&atid=849053
|>
|> As said there, the patch gets the compile to complete, but I haven't
|> tested the result (I have 4.1.29 installed, and it is likely to be
|> a while before I get back to this). The same patch submitted there
|> is included below. Let us know if it actually works. 8-)
|
|
| as expected, the patch permits the compile to complete.
| I am leery of testing this in the real world though.
|
| Why? - This was posted to sourceforge OVER A MONTH AGO and there has been
| no feedback or comments from Darren or anyone else.
|
| Is IPFilter still supported and maintained?

So, this problem is with Solaris 8.

My priority is with Solaris 9 & 10 because I can easily run them the
x86 versions in a virtual machine rather than needing to power a whole
other system.

Darren

[J.D. Bronson]

Post by Darren Reed
So, this problem is with Solaris 8.
My priority is with Solaris 9 & 10 because I can easily run them the
x86 versions in a virtual machine rather than needing to power a whole
other system.
Darren

Thank you for replying Darren...however, this is indeed
a Solaris 10 issue...

I am running Solaris 10 05/08......

% cat /etc/release
Solaris 10 5/08 s10x_u5wos_10 X86
Copyright 2008 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 24 March 2008

-JD

[Darren Reed]

J.D. Bronson wrote:
| At 04:40 PM 10/18/2008 -0700, Darren Reed wrote:
|> So, this problem is with Solaris 8.
|>
|> My priority is with Solaris 9 & 10 because I can easily run them the
|> x86 versions in a virtual machine rather than needing to power a whole
|> other system.
|>
|> Darren
|
| Thank you for replying Darren...however, this is indeed
| a Solaris 10 issue...

Right... it appears that your problem is Sun's C compiler.

If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?

Darren

[J.D. Bronson]

Post by Darren Reed
Right... it appears that your problem is Sun's C compiler.
If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?
Darren

I do not run gcc nor do I have it on these machines for testing.
(It was not installed)
All programs are compiled with Studio 12.

So I cant answer that. However, if we could have you review the patch
that Charles submitted and give some feedback, that would be great.

His patch does allow a clean compile under Studio 12.

Thanks again Darren.

In the meantime, I have compiled 4.1.29 and it compiles/runs fine.

-JD

[Charles Seeger]

+------ Darren Reed wrote (Sat, 18-Oct-2008, 18:36 -0700):
|
| Right... it appears that your problem is Sun's C compiler.
|
| If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?

Darren, if you examine the patch, only one of the three changes is
compiler related. The other two involve including headers to get
all the definitions required by the code. The entire arc4random.c
udiff is only 34 lines, containing 10 new lines.

Best,
Chuck

[Darren Reed]

Charles Seeger wrote:
| +------ Darren Reed wrote (Sat, 18-Oct-2008, 18:36 -0700):
| |
| | Right... it appears that your problem is Sun's C compiler.
| |
| | If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?
|
| Darren, if you examine the patch, only one of the three changes is
| compiler related. The other two involve including headers to get
| all the definitions required by the code. The entire arc4random.c
| udiff is only 34 lines, containing 10 new lines.

I'll have to install solaris 8 to check this out...

S10 doesn't require the other includes, only the workaround for __inline.

Cheers,
Darren

[J.D. Bronson]

Post by Darren Reed
I'll have to install solaris 8 to check this out...
S10 doesn't require the other includes, only the workaround for __inline.
Cheers,
Darren

Could someone possibly provide a S10 'only' patch from this so I can test?

I will try and install GCC today and see if I can get IPFilter to compile
as well - for a 2nd thought.

-JD

[J.D. Bronson]

10/19/2008

GCC 3.4.6 permits a complete build of 4.1.31 on Solaris 10.

In fact, there are much less error comments than with Studio12.

-JD

[Charles Seeger]

Date: Sun, 19 Oct 2008 06:49:12 -0500
+------ "J.D. Bronson" wrote (Sun, 20-Dec-71, 20:02 -0500):
|
| At 09:23 PM 10/18/2008 -0700, Darren Reed wrote:
| >I'll have to install solaris 8 to check this out...
| >
| >S10 doesn't require the other includes, only the workaround for __inline.
| >
| >Cheers,
| >Darren
|
| Could someone possibly provide a S10 'only' patch from this so I can test?

That would be just this part of the original diff:

@@ -43,7 +49,11 @@
static u_int8_t arc4_randbyte(void);
static int ipf_read_random(void *dest, int length);

+#ifdef __SUNPRO_C
+static inline void
+#else
static __inline void
+#endif
arc4_swap(u_int8_t *a, u_int8_t *b)
{
u_int8_t c;

Though those line numbers would change to "@@ -43,7 +43,11 @@"
without the previous six extra lines for the includes.

If one wants to guard the gcc "__inline" (or any other gcc-isms),
the "__GNUC__" cpp macro might be best choice, short of using any
autoconf-like generated macros. Something like:

#if defined __GNUC__
static __inline void
#elif defined __SUNPRO_C
static inline void
#else
static void
#endif

Alas, I haven't used any other compilers recently enough to recall
what might be appropriate for them. A quick look at GNU autoconf
suggests that some compilers use "__inline__". Since autoconf
actually tests for all three, it doesn't enumerate which compiler
uses which inline flavor.

Best,
Chuck

[Darren Reed]

J.D. Bronson wrote:
| At 06:36 PM 10/18/2008 -0700, Darren Reed wrote:
|> Right... it appears that your problem is Sun's C compiler.
|>
|> If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?
|>
|> Darren
|
| I do not run gcc nor do I have it on these machines for testing.
| (It was not installed)
| All programs are compiled with Studio 12.

Technically, you're not supposed to be using Studio 12 on Solaris 8
as the download only states (Solaris 9/10.) But if it works for you,
it's not for me to comment :)

Darren

[J.D. Bronson]

Post by Darren Reed
|> If you do "setenv CC gcc" (or "export CC=gcc), does the build succeed?
|>
|> Darren
|
| I do not run gcc nor do I have it on these machines for testing.
| (It was not installed)
| All programs are compiled with Studio 12.
Technically, you're not supposed to be using Studio 12 on Solaris 8
as the download only states (Solaris 9/10.) But if it works for you,
it's not for me to comment :)
Darren

I am not sure what the major confusion is here.
I am running Solaris 10. (as my post subject states) and using
Studio 12.
Certainly thats an appropriate choice :-)

The OP uses an older Solaris.

With the OPs provided patch on Sorceforge, the program compiles and
runs via Solaris 10 and Studio 12.

This patch needs to be reviewed and ideally incorporated.

BTW, the link on the ipfilter main page shows 4.1.30 for download
but yet when you click it, your given 4.1.31 but yet when that builds
it still shows as 4.1.30.

-JD

[Cy Schubert]

In message <***@reed.wat
tle

After what seems like an eternity, I've finally uploaded version
IPFilter 5.1.1.
There are no patch files for against 5.1.0 or 4.1.35 as they'd be
too large to
have any meaning.
Building and testing has been primarily done on Solaris 10 and
NetBSD 5.99, with no panics or crashes from regular activity.
It should also compile and load up fine on FreeBSD as well.
Someone asked about Illumos earlier in the week - when I last
tried building there, I ran into some problems that seem related
to bugs in their header files.
Why should you replace version 4 with 5?
At the user interface level, obscure error messages should now be
a thing of the past when dealing with the kernel module. There are
still likely to be obscure messages when parsing configuration
files or in other areas, but that will be taken care of in time too.
If you build IPFilter with "COMPAT_IPFILTER" defined in the top
level Makefile, it will be possible to use ipf/ipnat from earlier
versions of IPFilter to load a configuration but use of ipfstat
and ipnat to display rules and statistics will run into trouble.
In terms of basic features, ipnat now supports IPv6 and with new
"rewrite" rules, both the source and destination address can be
replaced using a single NAT rule. In addition, "divert" and
"encap" rules have been added for experimentation.
See the new man page ipnat(5) for more details.
For ipf, it is now possible to use a filter rule group for filtering
of ICMP packets associated with existing state entries using the
"icmp-head" option with "keep state". Additionally, it is now
possible to restrict the number of individual networks or hosts
that have associated state entries, preventing a single source from
dominating the state table. Version 5 also introduces a compeltely
new type of rule to ipf.conf - "decapsulate". These rules make it
possible to tell IPFilter to "remove" the headers at the front of a
packet and process the contents as a new packet. In the short term,
the primary application of this is to allow firewalls that are not
a tunnel end point to filter on the traffic inside the tunnel where
the traffic is not encrypted. See ipf.conf(5) for more details.
The logging application, ipmon, can now be given a configuration
file that allows for log entries to be stored in different files,
delivered via syslog or via SNMP traps. See ipmon(5) for more
details.
http://coombs.anu.edu.au/~avalon/ip_fil5.1.1.tar.gz
MD5 (ip_fil5.1.1.tar.gz) = e9d51c6e58f549c4ab499254c81c90d2

Thanks Darren.

As it's too new, it's probably too soon to import this into the FreeBSD src
tree. However I've started work on an IP Filter port (to be put in
security/ipfilter). It will put the kernel modules into /boot/modules
(where ports put their modules) while the userland binaries will go into
$PREFIX (usually /usr/local). Had to patch a couple of Makefiles to get the
PREFIX stuff set up (just not installing correctly yet). I spent an hour on
it last night and hope to put in a couple more hours tonight. I may have to
rename the kernel modules so as not to confuse kldload (or the user will
have to specify the fully qualified pathname or change the module loading
order via sysctl -- haven't had a chance to think about this yet).

The port will has an overwrite base option like the bind ports do however
I'm not entirely convinced this is something we need so it may be removed
before it's committed.

Of course if folks want to compile it into the base kernel, they're on
their own. The port will not support that.

I suppose once people have had a chance to use the port for a while we can
import it into base.

[Darren Reed]

Post by Cy Schubert
Thanks Darren.
As it's too new, it's probably too soon to import this into the FreeBSD src
tree. However I've started work on an IP Filter port (to be put in
security/ipfilter). It will put the kernel modules into /boot/modules
(where ports put their modules) while the userland binaries will go into
$PREFIX (usually /usr/local). Had to patch a couple of Makefiles to get the
PREFIX stuff set up (just not installing correctly yet). I spent an hour on
it last night and hope to put in a couple more hours tonight. I may have to
rename the kernel modules so as not to confuse kldload (or the user will
have to specify the fully qualified pathname or change the module loading
order via sysctl -- haven't had a chance to think about this yet).
The port will has an overwrite base option like the bind ports do however
I'm not entirely convinced this is something we need so it may be removed
before it's committed.
Of course if folks want to compile it into the base kernel, they're on
their own. The port will not support that.
I suppose once people have had a chance to use the port for a while we can
import it into base.

That's great!

Thanks,
Darren