ipcop-devel Mailing List for IPCop Firewall

----- Original Message ----- 
From: "Olaf" <mai...@ba...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Sunday, May 30, 2010 9:11 PM
Subject: Re: [IPCop-devel] install-exec and localisation


> On 2010-05-30 09:22, Gilles Espinasse wrote:
> > We start using install-exec when available as it produce a much smaller
list
> > of installed files.
> > We compile each package with nls support but do not include the .mo
files in
> > iso (except ipcop translations).
>
> I intend to do that only when upgrading a package because of a new
> version or making some other modifications.
>
>
> Olaf

I agree for that.
I have a bunch of change related to cross-compilation, build order (solve
libtool error 37 and 74 by just following LFS order and compiling libtool
after bash or libtool try to use locale from /tools where none is
installed). As file package move from base to toolchain, that change require
to be commit with the cross-toolchain changes.

I have understood the issue with gcc test on debian machine.
If inside the chroot on a lenny or recent ubuntu machine, you run as explain
in LFS FAQ
expect -c "spawn ls"
you will have the message "The system has no more ptys. ..."
That's because we forget to mount /dev/pts for the chroot.

The reason why it does not happen for me on another machine or ubuntu-8.04
where gcc tests were working depend on the kernel configuration.
If /dev/ptyp0 exist, it is used in replacement of /dev/pts/0.
I had to use strace to see that.
I should be able to commit that after a full rebuild

Gilles

----- Original Message ----- 
From: "Olaf" <mai...@ba...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Wednesday, May 19, 2010 9:28 AM
Subject: Re: [IPCop-devel] pending work on my side


> On 2010-05-19 08:23, Gilles Espinasse wrote:
>
> > Should we not have i486-xxx gcc target for x86?
> > That should allow us not to need some locale hack on glibc, gmp to force
> > i486 build (and maybe fix procps actually miscompiled for i486)
>
> That looks like a good idea.
>
Not easy unless on PASS=1
I fail to achieve that goal actually.
If I add a target, I am cross-compiling gcc like in pass 1 and I have to
disable some options like in pass 1 or gcc fail to compile.

Maybe some hacking is needed on uname (maybe arch too) to answer i486 at
uname -m and not require to add a --target option.

I fixed the general gcc test failure.
I will then look at binutils tests. We should remove CFLAGS hardening there
as nothing is include
For glibc tests, we should use TIMEOUTFACTOR=16 make -j 1 -k check (borrowed
from Fedora)

Gilles

On 2010-05-30 09:22, Gilles Espinasse wrote:
> We start using install-exec when available as it produce a much smaller list
> of installed files.
> We compile each package with nls support but do not include the .mo files in
> iso (except ipcop translations).

I intend to do that only when upgrading a package because of a new
version or making some other modifications.


Olaf

We start using install-exec when available as it produce a much smaller list
of installed files.
We compile each package with nls support but do not include the .mo files in
iso (except ipcop translations).

LANG remain set on "en_GB.utf8"

Should we consider that we don't want  to do much for 2.0?
There is still enough work to do.

Gilles

On 2010-05-29 12:02, Eric Oberlander wrote:

> Perhaps setreservedports.pl could be altered so that $oldport is read
> from httpd.conf, or the $oldport regex is replaced by something more
> general, such as [0-9]+, or \d{2,5}, or similar/better?

We need a parameter to setreservedports.pl, something like --restore.
In that case setreservedports.pl can ignore any configured ports and do
a straightforward overwrite.

I'll fix things up in the coming days.


Olaf

Eric,
Am 29.05.2010 12:17, schrieb Eric Oberlander:
> On 29 May 2010 11:02, Eric Oberlander<eri...@gm...>  wrote:
>> Presumably, we don't want to restrict ourselves by including
>> httpd.conf in a backup file. It may need to be overwritten in a future
>> update?
>>
>> setreservedports.pl currently reads the existing gui port number from
>> /var/ipcop/main/settings, and uses that to change the apache port.
>> That is why the script is failing for you, as the oldport/existing
>> port in httpd.conf is different, and the sed command is failing.
>>
>> Perhaps setreservedports.pl could be altered so that $oldport is read
>> from httpd.conf, or the $oldport regex is replaced by something more
>> general, such as [0-9]+, or \d{2,5}, or similar/better?
>
> Or, regex the line in httpd.conf with Listen, that is _not_ 'Listen
> 81' might be better.
I believe the problem is here not that the setreservedports script fails 
but that a previously created backup set doesnt work right after 
restore, leaving the installation in a state where GUI access is not 
possible.
I think the restore process needs to take care of any settings, and push 
them into the proper places after restore - that means that after 
restore a script needs to be fired which reads /var/ipcop/main/settings 
and puts the Listen ports into httpd.conf.

Gün.

On 29 May 2010 11:02, Eric Oberlander <eri...@gm...> wrote:
> On 28 May 2010 21:06, Udo <li...@ur...> wrote:
>> Hi all,
>>
>> have a problem with command setreservedports for the GUI in combination
>> with the restore process during installation. I will explane.
>>
>> Before I backup my Cop 1.9.15-r4603, i modified the secureport for the
>> GUI to port
>> 33445 and it worked. Then I created the backup set and exported the
>> backup key.
>>
>> During installation of my new build 1.9.15r4608 I restored this backup
>> set and tried to use
>> the GUI with port 33445 but nothing happend. 8443 the same.
>>
>> I thought that I could fix this by using the setreservedports --gui
>> 33445 command
>> but the port is still occupied, so setreservedports failed.
>>
>> Ok, I found this!
>>
>> In the /var/ipcop/main/settings file wthe port was set to 33445 but in
>> httpd.conf the Listen Port
>> and the Vhost Port are still set to 8443.
>>
>> Created a new backup set but this time on floppy medium to see the
>> backup files list.but the
>> httpd.conf was not listed.
>>
>> I don´t know if the httpd.conf should be stored in the backup file and
>> failed
>> in this case, or if a script finally reads the /var/ipcop/main/settings
>> and push
>> it into httpd.conf
>>
>> I had the same problem with the latest builds before.
>>
>> Udo
>
> Presumably, we don't want to restrict ourselves by including
> httpd.conf in a backup file. It may need to be overwritten in a future
> update?
>
> setreservedports.pl currently reads the existing gui port number from
> /var/ipcop/main/settings, and uses that to change the apache port.
> That is why the script is failing for you, as the oldport/existing
> port in httpd.conf is different, and the sed command is failing.
>
> Perhaps setreservedports.pl could be altered so that $oldport is read
> from httpd.conf, or the $oldport regex is replaced by something more
> general, such as [0-9]+, or \d{2,5}, or similar/better?

Or, regex the line in httpd.conf with Listen, that is _not_ 'Listen
81' might be better.

On 28 May 2010 21:06, Udo <li...@ur...> wrote:
> Hi all,
>
> have a problem with command setreservedports for the GUI in combination
> with the restore process during installation. I will explane.
>
> Before I backup my Cop 1.9.15-r4603, i modified the secureport for the
> GUI to port
> 33445 and it worked. Then I created the backup set and exported the
> backup key.
>
> During installation of my new build 1.9.15r4608 I restored this backup
> set and tried to use
> the GUI with port 33445 but nothing happend. 8443 the same.
>
> I thought that I could fix this by using the setreservedports --gui
> 33445 command
> but the port is still occupied, so setreservedports failed.
>
> Ok, I found this!
>
> In the /var/ipcop/main/settings file wthe port was set to 33445 but in
> httpd.conf the Listen Port
> and the Vhost Port are still set to 8443.
>
> Created a new backup set but this time on floppy medium to see the
> backup files list.but the
> httpd.conf was not listed.
>
> I don´t know if the httpd.conf should be stored in the backup file and
> failed
> in this case, or if a script finally reads the /var/ipcop/main/settings
> and push
> it into httpd.conf
>
> I had the same problem with the latest builds before.
>
> Udo

Presumably, we don't want to restrict ourselves by including
httpd.conf in a backup file. It may need to be overwritten in a future
update?

setreservedports.pl currently reads the existing gui port number from
/var/ipcop/main/settings, and uses that to change the apache port.
That is why the script is failing for you, as the oldport/existing
port in httpd.conf is different, and the sed command is failing.

Perhaps setreservedports.pl could be altered so that $oldport is read
from httpd.conf, or the $oldport regex is replaced by something more
general, such as [0-9]+, or \d{2,5}, or similar/better?

Eric

Hi all,

have a problem with command setreservedports for the GUI in combination
with the restore process during installation. I will explane.

Before I backup my Cop 1.9.15-r4603, i modified the secureport for the 
GUI to port
33445 and it worked. Then I created the backup set and exported the 
backup key.

During installation of my new build 1.9.15r4608 I restored this backup 
set and tried to use
the GUI with port 33445 but nothing happend. 8443 the same.

I thought that I could fix this by using the setreservedports --gui 
33445 command
but the port is still occupied, so setreservedports failed.

Ok, I found this!

In the /var/ipcop/main/settings file wthe port was set to 33445 but in 
httpd.conf the Listen Port
and the Vhost Port are still set to 8443.

Created a new backup set but this time on floppy medium to see the 
backup files list.but the
httpd.conf was not listed.

I don´t know if the httpd.conf should be stored in the backup file and 
failed
in this case, or if a script finally reads the /var/ipcop/main/settings 
and push
it into httpd.conf

I had the same problem with the latest builds before.

Udo

Am 27.05.2010 07:05, schrieb Eric S. Johansson:
> finally am getting a chance to play with 1.9. are there any notes on connecting
> 1.9 IP sec VPN to an older 1.4 system?

Yes.

IPCop v1.9.14: IPsec (KLIPS, Net2Net) to IPCop v1.4.21 works (with 
certificates only).
IPCop v1.9.15: IPsec (NETKEY, Net2Net) to IPCop v1.4.21 works (with 
certificates and with PSKs).

Cheers Tom

finally am getting a chance to play with 1.9. are there any notes on connecting 
1.9 IP sec VPN to an older 1.4 system?

Am 26.05.2010 15:23, schrieb Guenter:
> with 1.4.x the console screen was blanked after few minutes to save
> power, and to save the monitor from burn-ins ...
> 1.9.x doesnt do this by default, and when I tried to use setterm to
well, just found that a 1.9.12 does blank the console screen; so this 
issue is introduced recently ...

Gün.

Hi,
if you decide to remove a previously installed NIC then setup seems not 
to fix the count nor remove the settings. I've just seen that where I 
did restore a backup on another machine which had less NICs installed; 
setup did fix the driver and MACs, but the now non-existant DMZ settings 
were not removed, thus causing an error message during startup.

Gün.

Hi,
with 1.4.x the console screen was blanked after few minutes to save 
power, and to save the monitor from burn-ins ...
1.9.x doesnt do this by default, and when I tried to use setterm to 
enable powersave mode I found setterm missing in the installation 
(r4603) although it can be found in build_i486/ipcop/usr/bin; I copie it 
over, and could then enable screen blanking with 'setterm -powersave on' ...
can we put back this useful feature please?

Gün.

Am 23.04.2010 11:36, schrieb Guenter:
> Guenter schrieb:
>> cant we modify the serial console install process in this way that we
>> log all errors to a file, and before we shutdown the system in case of
>> errors try to write this log to the harddisk / flash so that we have a
>> chance to further track down this annoying issue?
> no ideas how we can nail down this issue?
I just took some time, and did a couple of installations on an Alix 2C3 
board ....
this time I tested also with 2.5" HDs - one very old lame 2GB, and one 
newer 30GB ...
first I tested with 1.9.7; and both HDs as well as CF worked fine, no 
matter if I select HD install or flash install.
Then with 1.9.15 r4603 there come the differences:
- the lame 2GB breaks already with 'cant create file systems'.
- the 30GB and the CF work both when I select HD install, and fail both 
with flash install -> 'Bootloader installation error'.

So seems this now nails down the issue to the flash installation.
Beside this it seems that we now also have another issue with lame HDs 
where the filesystem creation process runs into a timeout or something 
like that. Interesting also that after the 'cant create file systems' 
error reboot still worked, and booted the old system, but then entered 
maintainance mode because varlog was not found ...

Gün.

Bugs item #3006438, was opened at 2010-05-24 13:42
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3006438&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot add .com in dynamic DNS

Initial Comment:
I have transferred a .com domain to Dyndns.com.  I cannot add it to the dynamic dns updater as com is rejected in 1.9.11
entering it as .com in the domain field ensures that domain..com is passed to the service and not domain.com causing the update to repeeatedly fail.

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

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

Hi,
I would like to have the msr kernel module added; this is a very small 
module only (less than 2kb), and enables the use of flashrom which is 
useful for bios updates.

Please add this for both 1.9.x and 1.4.x.

Thanks, Gün.

Hi,
I would like to have a label for localboot added to the 
ipcop-pxe-*.model files:

--- ipcop-pxe-1.9.15.model.orig 2010-05-17 02:40:19.000000000 +0200
+++ ipcop-pxe-1.9.15.model      2010-05-19 18:47:30.000000000 +0200
@@ -27,3 +27,5 @@
  LABEL memtest
    KERNEL memtest
    APPEND -
+LABEL localboot
+  localboot 0

this enables to boot locally in case you end up un-wanted in the PXE 
boot menu because you forgot to switch bios boot order.
Please add this for both 1.9.x and 1.4.x.

Thanks, Gün.

On 2010-05-19 08:23, Gilles Espinasse wrote:

> Should we not have i486-xxx gcc target for x86?
> That should allow us not to need some locale hack on glibc, gmp to force
> i486 build (and maybe fix procps actually miscompiled for i486)

That looks like a good idea.


> Then I would work on installer.
> I take the occasion of a disk failure to look at the files include by debian
> installer in initramfs and it look to work with mostly less system files
> than us (no archive-locale for example and that's a big file).

without archive-locale the installer cannot correctly display when using
languages with 'special' characters. For example French (ê) and German
(ä, ö, ü). The calculations for text length is messed up in that case.
Maybe it is possible to fix that someway, but I did not find any other
method then to include archive-locale :-/



My pending work:
 - some modifications to our iptables chains, so we can correctly
regulate IPsec traffic


As soon as that is finished and the toolchain modifications are done, I
will put together 1.9.15.
1.9.15 is very likely to be the latest test release before 2.0.0-rc1.


Olaf

> toolchain cross-compilation
> I will rework on that next week.
toolchain cross-compilation is now working for me on x86 and ppc.
I have just mostly LFS-6.6 commands for binutils, gcc, glibc,
adjust-toolchain.
This has solved for me compiling the toolchain from my old gentoo based
machine.

This still fail on sparc64 (lenny).
We probably have a bad mix of sparc,sparc64, sparc9v.
I think our binutils/gcc cross-compile logic is wrong.
Debian/Ubuntu build binutils with
CC="gcc" CXX="g++" CFLAGS="-g -O2 -Wno-format-security" \


../configure --enable-shared --enable-plugins --prefix=/usr --build=sparc-li
nux-gnu --host=sparc-linux-gnu --with-pkgversion="GNU Binutils for
Ubuntu" --enable-targets=sparc64-linux-gnu --enable-gold=both


and gcc with
--enable-multiarch
--build=sparc-linux-gnu
--host=sparc-linux-gnu
--target=sparc-linux-gnu
That should be enought to build both for 32 and 64bits, no need to build a
special gcc version.

Should we not have i486-xxx gcc target for x86?
That should allow us not to need some locale hack on glibc, gmp to force
i486 build (and maybe fix procps actually miscompiled for i486)

I am not totally ready to commit the 'split log' changes. That should be
ready next week.
It was easier to work on toolchain compilation as each log is smaller.
But I still have minor changes to do.

Then I would work on installer.
I take the occasion of a disk failure to look at the files include by debian
installer in initramfs and it look to work with mostly less system files
than us (no archive-locale for example and that's a big file).

I have not yet started a full week working on ipcop, delayed by real work.

Gilles

> Is this change going to enable one to ping remote machines from a
> Gateway IPCop across an IPSec VPN?
>
> Thanks
> Darren

This has nothing to do with KLIPS/NETKEY. You can ping remote machines
across an IPsec tunnel from IPCop this way:

IPCop 1.4.21:
# /usr/bin/ping -I <Green IP/NIC> <IP of remote machine>

IPCop 1.9.14/15:
# ping -I lan-1 <IP of remote machine>

Cheers, Tom

Bugs item #3003176, was opened at 2010-05-18 11:04
Message generated for change (Tracker Item Submitted) made by molly42
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3003176&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: Kernel
Group: V2 beta
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Molly (molly42)
Assigned to: Nobody/Anonymous (nobody)
Summary: sysctl vs. kernel .config

Initial Comment:
/etc/sysctl.conf states mmap_min_addr = 4096 (the correct variable would be vm.mmap_min_addr), but the shipped kernel .config has CONFIG_DEFAULT_MMAP_MIN_ADDDR = 65536. I suggest usint the same value in sysctl.conf

When booting the kernel complains about

nf_conntrack version 0.5.0 (1980 buckets, 7920 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.

so it might be a good idea, to move this to /etc/sysctl.conf as well

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

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

Feature Requests item #3001978, was opened at 2010-05-15 03:44
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=3001978&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: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Intel 82574L+Gigabit+Ethernet driver

Initial Comment:
http://downloadcenter.intel.com/SearchResult.aspx?lang=eng&ProductFamily=Ethernet+Components&ProductLine=Ethernet+Controllers&ProductProduct=Intel%c2%ae+82574+Gigabit+Ethernet+Controller

Could anyone help to build the intel 82574 driver? IPCop installation can't be finished on my PC without it.

Thanks in advance.

Jun

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

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

On 12 May 2010 21:45, SourceForge.net <no...@so...> wrote:
> Bugs item #3000712, was opened at 2010-05-12 20:45
> Message generated for change (Tracker Item Submitted) made by
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3000712&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: General
> Group: V2 beta
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: https://www.google.com/accounts ()
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Spike in graph data at boot up
>
> Initial Comment:
> Running IPCop v1.9.14  every time I reboot the box I get this spike in the green graph usage of 60 to 100 megs which of course
> means unit that spike disappears from the web page you can't see valid data for a couple of days,

I've notice that too in the past, but I thought it was my dodgy hardware.

I don't see it in my v1.9.15 traffic graphs.

Eric

Bugs item #3000712, was opened at 2010-05-12 20:45
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3000712&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: General
Group: V2 beta
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Spike in graph data at boot up

Initial Comment:
Running IPCop v1.9.14  every time I reboot the box I get this spike in the green graph usage of 60 to 100 megs which of course means unit that spike disappears from the web page you can't see valid data for a couple of days,

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

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