ipcop-devel Mailing List for IPCop Firewall

Feature Requests item #3308608, was opened at 2011-05-27 23:51
Message generated for change (Tracker Item Submitted) made by ipcopmann
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3308608&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interface Improvements (example)
Group: Next major version
Status: Open
Priority: 5
Private: No
Submitted By: IPcopMann (ipcopmann)
Assigned to: Nobody/Anonymous (nobody)
Summary: Firewall Rules - Default services (v2.0)

Initial Comment:
There are a couple of common ports missing from the Default services in the Firewall Rules (v1.9.19) that would be handy.
RDP 3389
VNC 5900

Thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3308608&group_id=40604

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Thursday, May 19, 2011 6:30 AM
Subject: Re: [IPCop-devel] Testing gcc-4.4.6 upgrade


> On 2011-05-14 19:39, Gilles Espinasse wrote:
>
> > For that reason, I have tried to upgrade make to 3.82. That compile and
is
> > unlikely to produce different binaries than 3.81 (I haven't yet checked
> > that). I will see with usage if our build bug is still there. For 3.82,
I
> > have one patch borrowed from fedora that fix 3 bugs, fedora has more
> > patches, maybe 2 or 3 other may fix real issues for us. Gentoo has 2
patches
> > that do mostly the same as the one from fedora I have compiled, as all
of
> > that is fixes from upstream cvs.
>
> I've been running test builds with make 3.82 for a long time now. No
> problems other then cdrtools.
> Since that is gone now (finally :-)), I see no obstacle for us to use
> make 3.82.
>
there is still 2 minor isssues.
- when looking at make-3.81 vs 3.82 build on one machine, the only file that
check_files find different is /lib/libproc-3.2.8.so. On that machine, I run
ps and had the 'Unknown HZ value' that LFS fix with one patch, this resolve
that issue. I will add that patch. You are more likely to see this message
not so long after the machine has started/rebooted because soem jiffies
added in linux-2.6 are missing,

- the other issue is in log
diff -urw log_i486-3.81/03_ipcop/wanpipe-3.5.18
log_i486-3.82/03_ipcop/wanpipe-3.5.18
--- log_i486-3.81/03_ipcop/wanpipe-3.5.18 2011-05-15 00:54:36.000000000
+0200
+++ log_i486-3.82/03_ipcop/wanpipe-3.5.18 2011-05-15 11:49:15.000000000
+0200
@@ -182,10 +182,15 @@
 Compiling WANPIPE LibSangoma API library ...Done.


-Compiling WANPIPE LibStelephony API library ...Done.
+Compiling WANPIPE LibStelephony API library ...Failed. -- Note this library
is not mandatory its safe to continue install


-Compiling WANPIPE API Development Utilities ...Done.
+Compiling WANPIPE API Development Utilities ...Failed!
+
+ ERROR: Failed to compile WANPIPE API Tools !!!
+ Please contact support at Sangoma Technologies
+ email: tec...@sa...
+ Please include the file setup_drv_compile.log

I have not yet reported the issue, I will do when I find time

>
> So let's do the updates for both gcc and make.
> We'd probably need to do a split update (.20 and .21) but that's not a
> real problem.
>
>
> Olaf

Ok I will do that, I will commit make-3.82 once the procps patch is added.
For gcc, that may be a bit later, more probably next week.

Gilles

On 2011-05-14 19:39, Gilles Espinasse wrote:

> For that reason, I have tried to upgrade make to 3.82. That compile and is
> unlikely to produce different binaries than 3.81 (I haven't yet checked
> that). I will see with usage if our build bug is still there. For 3.82,  I
> have one patch borrowed from fedora that fix 3 bugs, fedora has more
> patches, maybe 2 or 3 other may fix real issues for us. Gentoo has 2 patches
> that do mostly the same as the one from fedora I have compiled, as all of
> that is fixes from upstream cvs.

I've been running test builds with make 3.82 for a long time now. No 
problems other then cdrtools.
Since that is gone now (finally :-)), I see no obstacle for us to use 
make 3.82.


So let's do the updates for both gcc and make.
We'd probably need to do a split update (.20 and .21) but that's not a 
real problem.


Olaf

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Saturday, May 14, 2011 6:12 PM
Subject: Re: [IPCop-devel] Testing gcc-4.4.6 upgrade


> On 2011-05-11 19:55, Gilles Espinasse wrote:
>
> > Is it the time to update gcc?
>
> Not sure, other than less errors when testing, what would be the benefit
> for us?
>
>
> Olaf

We could prefer gcc-4.4.6 than gcc-4.4.5 as more bugs should have been fixed
than include in the last release.
In true life, when you are hit by a bug, it may require some hard time
before to know that the reason is in the compiler.

I agree there is no urgency to upgrade. I will keep that change on one
machine and see if the other machines behave differently.
I had other changes coupled with 4.4.6 in mind. If you disable static lib on
gcc, our installer and gdb build will fail because of TEXTREL issue.
Adding -fPIC on both solve those issues (the produced code is a bit bigger).
I haven't yet checked if every executable is PIE compiled and should do
that.

Actually, we know of our build bug and we have absolutly no idea where it
does come from.
That's the know issue where our build sometime and very unfrequently fail
for unidentified reason.
Once during ./make.sh clean && ./make.sh build, e2fsprogs fail to build
because pkg-config was not found. And that was true, pkg-config have not be
build _that time_ for the reason know from our bug only. That's a bit scary
but as we can't reliabily reproduce, we can't debug.

For that reason, I have tried to upgrade make to 3.82. That compile and is
unlikely to produce different binaries than 3.81 (I haven't yet checked
that). I will see with usage if our build bug is still there. For 3.82,  I
have one patch borrowed from fedora that fix 3 bugs, fedora has more
patches, maybe 2 or 3 other may fix real issues for us. Gentoo has 2 patches
that do mostly the same as the one from fedora I have compiled, as all of
that is fixes from upstream cvs.

There is one oddity in 3.82 vs 3.81 in the log produced
diff -ur log_i486-3.81/02_base/rsyslog-5.6.5 log_i486/02_base/rsyslog-5.6.5
--- log_i486-3.81/02_base/rsyslog-5.6.5 2011-05-13 17:51:22.000000000 +0200
+++ log_i486-3.82/02_base/rsyslog-5.6.5 2011-05-13 23:40:50.000000000 +0200
@@ -7,9 +7,9 @@
 Hunk #2 succeeded at 221 (offset -2 lines).
 patching file runtime/wtp.c
 cd /usr/src/rsyslog-5.6.5 && ./configure --prefix=/usr \
-     --exec-prefix=/usr \
-     --sysconfdir=/etc \
-     --localstatedir=/var
+    --exec-prefix=/usr \
+    --sysconfdir=/etc \
+    --localstatedir=/var
You may see nothing different here if your mailer does not render tab as 8
char (I suspect mine will replace tab with space).
With 3.82, there is one tab less for the characters after the first
continuation character : the \
After first configure line, for the next options, there is 5 tab with 3.81
and 4 with 3.82
So the log diff between 3.81 and 3.82 is big (1.3 MB) and hard to read.
I am unsure this is a bug. In makefile, the tab mean this is a command. On
the first line, that tab did not appear on log, so it may be normal make
suppress one tab on the lines that follow the first.

I now know too why the cairo test failure count is so big, but I don't know
yet the fix : the fonts are not found by cairo during the tests.
That look like https://bugs.freedesktop.org/show_bug.cgi?id=18077
Despite reading cairo test/README, I have no idea where to change something.
fc-list know the installed fonts.

Gilles

On 2011-05-10 00:35, Sebastian Henrich wrote:

> I try to figure out how to disable NAT, configure
> some routing rules between two networks and block some access from
> one network to the other with firewall rules. Is this possible using
> the current state of development or is it planned for the future?

Not possible and also not planned.


Olaf

On 2011-05-11 19:55, Gilles Espinasse wrote:

> Is it the time to update gcc?

Not sure, other than less errors when testing, what would be the benefit 
for us?


Olaf

Looking in the test suite result, the difference was one test
- busybox-1.17.4 FAIL 'date-R-works'
That fail on gcc-4.4.6 the first time but work the second time I tried.
This test should be racy, it mostly work but sometime fail, so that should
be only noise.

- gdb-7.2 there is less failures, the diff show
 Running ./gdb.base/miscexprs.exp ...
-FAIL: gdb.base/miscexprs.exp: print value of ibig.i[100] | 1
-FAIL: gdb.base/miscexprs.exp: print value of sbig.s[90] & 127
-FAIL: gdb.base/miscexprs.exp: print value of !ibig.i[100]
-FAIL: gdb.base/miscexprs.exp: print value of !sbig.s[90]
-FAIL: gdb.base/miscexprs.exp: print value of !ibig.i[100]
-FAIL: gdb.base/miscexprs.exp: print value of !ibig.i[100]
-FAIL: gdb.base/miscexprs.exp: print value of !sbig.s[90] * 10
-FAIL: gdb.base/miscexprs.exp: print value of ibig.i[100] * sbig.s[90]
-FAIL: gdb.base/miscexprs.exp: print value of fbig.f[100] * dbig.d[202]
-FAIL: gdb.base/miscexprs.exp: print value of !(sbig.s[90] * 2)
-FAIL: gdb.base/miscexprs.exp: print value of ibig.i[100] << 2
-FAIL: gdb.base/miscexprs.exp: print value of sbig.s[90] >> 4
-FAIL: gdb.base/miscexprs.exp: print value of lbig.l[333] >> 6
 Running ./gdb.base/float.exp ...
 Running ./gdb.base/longjmp.exp ...
 FAIL: gdb.base/longjmp.exp: next over longjmp(1)
@@ -221,8 +207,8 @@

   === gdb Summary ===

-# of expected passes  5178
-# of unexpected failures 20
+# of expected passes  5191
+# of unexpected failures 7

So that's not bad.
The full gdb test had some other FAIL, the total FAIL number is reduced from
38 to 25.

Looking at the log diff, using some sed -i -e 's|4\.4\.5|4.4.6|g' to reduce
the noise, I find nothing alarming, just the usual noise log.

So gcc-4.4.6 should just be something good.
The drawback is that there is 497 files that are different and not yet
include in update.
I haven't checked which include gcc version and which are differently
compiled.

Is it the time to update gcc?

Gilles

Hello,

I'm using IPCop for a couple of years and I'm really happy with
it!!! Thank you very much for your very good work!!!

At the moment I'm playing around with a test installation of IPCop
version 1.9.19. I try to figure out how to disable NAT, configure
some routing rules between two networks and block some access from
one network to the other with firewall rules. Is this possible using
the current state of development or is it planned for the future?

Regards

  Sebastian