ipcop-devel Mailing List for IPCop Firewall

----- Original Message ----- 
From: "Gilles Espinasse" <g....@fr...>
To: "Ivan Kabaivanov" <ch...@ya...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Thursday, March 22, 2007 2:14 AM
Subject: Re: [IPCop-devel] diff for ppc changes


> > what's the glibc version you have on gentoo?  Can you email the contents
> > of /usr/lib/libc.so -- there should be 5 lines.  Is line 5 like this:
> >
> > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED
> > ( /lib/ld-linux.so.2 ) )
> >
> > this is on one line.
> >
> > Try changing it to:
> >
> > GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
> >
> > but then after you compile ipcop-toolchain stage, change it back.
> >
> > Looks like the problem is that old binutils' ld doesn't understand
> AS_NEEDED.
> > That means we have to upgrade binutils, but I wanted to stay with the
> > original 1.4.x binutils to avoid trouble (even though I don't think
> > there'll be any even if we do upgrade).
> >  I just don't like messing with the toolchain
> > (binutils,gcc,glibc).
> >
> > IvanK.
> >
> the workaround allow to pass Building gcc LFS_PASS=1
> glibc version is 2.4
>
> Gilles
>
I make some more tests, just building on i386.
With the modified /usr/lib/libc.so on gentoo gcc-4.1.1, glibc-2.4,
kernel-2.6.20,
I am able to build the toolchain and ipcop

Without changes on stable debian gcc-3.3.5, glibc-2.3.2, linux-2.6.8,
I am able to build the toolchain and ipcop.

But I am not able to build on debian sarge using the toolchain build on
gentoo.
Mar 31 13:03:05: Stage2 linux base build
Mar 31 13:03:05: Building stage2
Mar 31 13:03:15: Building makedev
Mar 31 13:03:16: Building linux
FATAL: kernel too old
FATAL: kernel too old
FATAL: kernel too old
ERROR: Build process interrupted

I try to set  --enable-kernel=2.4.18 in lfs/glibc for the tool pass.
The message 'FATAL: kernel too old' appear more time in lfs/linux build but
did not stop on error.

It stop in lfs/glibc just after with
...
# Force the use of /bin/bash, because in Ubuntu /bin/sh is a link to
/bin/dash and glibc wants bash
cd /usr/src/glibc-build && CONFIG_SHELL=/bin/bash
../glibc-2.3.3-lfs-5.1/configure --prefix=/usr --disable-profile --enable-ad
d- --libexecdir=/usr/lib --with-headers=/usr/include --witho
ut-cvs --disable-nls
checking build system type... ../glibc-2.3.3-lfs-5.1/scripts/config.guess:
line 1: 13112 Segmentation fault      ( $c -c -o $dummy.o $dummy.c )
>/dev/null 2>&1
../glibc-2.3.3-lfs-5.1/scripts/config.guess: line 1: 13113 Segmentation
fault      ( $c -c -o $dummy.o $dummy.c ) >/dev/null 2>&1
i386-pc-linux-gnu
checking host system type... i386-pc-linux-gnu
checking sysdep dirs... sysdeps/i386/elf
linuxthreads/sysdeps/unix/sysv/linux/i386
linuxthreads/sysdeps/unix/sysv/linux linuxthreads/sysdeps/pthread
sysdeps/pthread linuxthreads/sysdeps/unix/sysv linuxthreads/sysdeps/unix
linuxthreads/sysdeps/i386 sysdeps/unix/sysv/linux/i386
sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman
sysdeps/unix/inet sysdeps/unix/sysv/i386 sysdeps/unix/sysv sysdeps/unix/i386
sysdeps/unix sysdeps/posix sysdeps/i386/fpu sysdeps/i386 sysdeps/wordsize-32
sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32
sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic
checking for a BSD-compatible install... /tools/bin/install -c
checking whether ln -s works... yes
checking for gcc... gcc
checking for suffix of object files... configure: error: cannot compute
suffix of object files: cannot compile
See `config.log' for more details.
make: *** [/usr/src/log/glibc-2.3.3-lfs-5.1] Error 1

The contrary work, I am able to build on gentoo using the toolchain build on
debian sarge.

And the problem remain with AS_NEEDED.

Gilles

Feature Requests item #1691780, was opened at 2007-03-31 05:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1691780&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: Next release
Status: Open
Priority: 5
Private: No
Submitted By: Curtis Sutter (curtis8)
Assigned to: Nobody/Anonymous (nobody)
Summary: Extra Module loaded in Kernel

Initial Comment:
I am trying to get my UTStarcom 6700 to work with IP Cop. It works with Fedora Core 7 using the ipaq.o module. I have tried to copy this file to my IP Cop, but am unable to get it to load. If you could include the ipaq module in the next release, I would be very happy. This driver also allows other PPC devices to connect, so I believe others would like this feature as well.
Thank you very much for your time.

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

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

----- Original Message ----- 
From: "Marco Sondermann" <mar...@my...>
To: "IPCop devel" <ipc...@li...>
Sent: Thursday, March 29, 2007 5:39 PM
Subject: Re: [IPCop-devel] Integrate more add-ons on 1.4.x?


> Hello,
>
> first, I feel very honored that you think about integrating (some of) my
> addons into the official IPCop release. Thank you for the confidence shown
> to me.
>
> Olaf contacted me a few days ago and I promised him I will let you all
take
> part of my thoughts.
>
>
> Whether I could imagine that my addons might become part of IPCop?
>
> Yes, I can. But not for release 1.4 yet...
>
Fine

> Why ... or why not?
>
> As I understand and implement software versioning (and you can read about
it
> at Wikipedia http://en.wikipedia.org/wiki/Software_versioning ) the third
> digit (described as maintenance / revision) is meant for small fixes and
> minor feature changes.
>
> >From this point of view, I dont't think that the integration of any of my
> (or other's) addons might be a _minor_ feature change. This is the reason
I
> would see the integration of addons rather in the next *minor* release of
> IPCop than in the next *maintenance* release.
>
I am fine with that

> Though development didn't stop for 1.4 in the past, the feature set didn't
> change significantly. And this is exactly, what everybody would expect
from
> a professional 1.4 release maintainance.
>
> A few years ago, the IPCop project has constricted itself with its
long-term
> roadmap, advertising the release 1.5 as the next release including huge
> changes, improvements and other milestones - instead of a 2.0 release.
>
> In my opinion, the current IPCop versioning strategy needs to be
redesigned.
> It took less than three years from the initial release 0.0 to 0.1, 1.2,
1.3,
> finally to 1.4. Now the release 1.4 has matured for almost three years,
> becoming a solid and reliable firewall distribution.
>
> But meanwhile, the requirements have changed. Many users are talking now
> about "must-have-addons" and even the IPCop development team is just
> discussing about short-term feature improvements. The only reasonable way
> out of this will be changing the versioning roadmap from 1.5 to 2.0 and
from
> 1.6 to 3.0. Take a look at the right-minded and long-sighted Squid
> versioning structure. This is not by accident, this is based on years of
> experience.
>
I agree to have started only short term subject in the public list.
That does not mean that I loose any long term interest.
I am actually a bit too busy, particullary this week so I would have reopen
a bit later the discussion on some objectives that we have to agree for the
new version.
This should be better for me after two/three weeks.

> A new versioning will give the IPCop project back what was the major
> advantage in the past when it forked from the SmoothWall project:
> flexibility, innovation, progress and efficiency.
>
>
> What counts against moving the current long-term 1.5 development branch to
a
> long-term 2.0 branch and inserting a new intermediate 1.5 release based on
> the current 1.4 instead?
>
> Please, take a minute (or two) and reflect on this question...
>
I am open to proposal.
The idea of a intermediate version between v1.4 and what is in main tree
make sense.
- openswann-1.2 is obsolete
- linux-2.4 branch is becoming older every day.
That mean that it will cost us many time just to support existing hardware
and not only the oldest.
So having a intermediate version with linux-2.6 and some limited changes
only could accelerate the release of this new version.
>
> Anyway, integrating different 3rd-party addons into an existing 1.4 branch
> is not what I would commonly rate as "best practice".
>
> * The integration of new features takes time and needs to be very well and
> carefully tested. IPCop is not a word processor, IPCop is a firewall.
>
> * Most users might be confused. They will try to install their favourite
1.4
> addons on their 1.4.x IPCops with these features already built-in and will
> break their installations. Or it even might work - with unforseeable
> results. And the worst case will take place when users will try to
uninstall
> these addons...
>
> * Integrating some addons into the official code will break other addons
on
> IPCop. There are known incompabilities between different addons. Making
some
> of them a standard will lock out some other addons. This will annoy users
> and displease addon developers.
>
I fully agree.
That's one of the reasons why when I evaluate the possibility to integrate
parts of your changes one year before, I did not do that.
This is a bit different for openvpn as there is no conflict with other
add-on.
>
> To cut a long story short:
>
> As long as IPCop 1.4 will exist, I will continue maintaining my addons the
> same way as I did in the past few years. If somebody else wants to
integrate
> the code into the official 1.4 release, so have a go at it. I will neither
> complain nor disagree with this.
>
> Whenever the IPCop development team decides to change the versioning for a
> 'new' minor release, I will offer all my knowledge and my time to
integrate
> and actively maintain the code in this new minor IPCop release. In
addition
> to this, I would offer my support for any other IPCop related code, if
> necessary.
>
I welcome your proposal.

Gilles

Hello,

first, I feel very honored that you think about integrating (some of) my
addons into the official IPCop release. Thank you for the confidence shown
to me.

Olaf contacted me a few days ago and I promised him I will let you all take
part of my thoughts.


Whether I could imagine that my addons might become part of IPCop?

Yes, I can. But not for release 1.4 yet...

Why ... or why not?

As I understand and implement software versioning (and you can read about it
at Wikipedia http://en.wikipedia.org/wiki/Software_versioning ) the third
digit (described as maintenance / revision) is meant for small fixes and
minor feature changes.

>From this point of view, I dont't think that the integration of any of my
(or other's) addons might be a _minor_ feature change. This is the reason I
would see the integration of addons rather in the next *minor* release of
IPCop than in the next *maintenance* release.

Though development didn't stop for 1.4 in the past, the feature set didn't
change significantly. And this is exactly, what everybody would expect from
a professional 1.4 release maintainance.

A few years ago, the IPCop project has constricted itself with its long-term
roadmap, advertising the release 1.5 as the next release including huge
changes, improvements and other milestones - instead of a 2.0 release.

In my opinion, the current IPCop versioning strategy needs to be redesigned.
It took less than three years from the initial release 0.0 to 0.1, 1.2, 1.3,
finally to 1.4. Now the release 1.4 has matured for almost three years,
becoming a solid and reliable firewall distribution.

But meanwhile, the requirements have changed. Many users are talking now
about "must-have-addons" and even the IPCop development team is just
discussing about short-term feature improvements. The only reasonable way
out of this will be changing the versioning roadmap from 1.5 to 2.0 and from
1.6 to 3.0. Take a look at the right-minded and long-sighted Squid
versioning structure. This is not by accident, this is based on years of
experience.

A new versioning will give the IPCop project back what was the major
advantage in the past when it forked from the SmoothWall project:
flexibility, innovation, progress and efficiency.


What counts against moving the current long-term 1.5 development branch to a
long-term 2.0 branch and inserting a new intermediate 1.5 release based on
the current 1.4 instead?

Please, take a minute (or two) and reflect on this question...


Anyway, integrating different 3rd-party addons into an existing 1.4 branch
is not what I would commonly rate as "best practice".

* The integration of new features takes time and needs to be very well and
carefully tested. IPCop is not a word processor, IPCop is a firewall.

* Most users might be confused. They will try to install their favourite 1.4
addons on their 1.4.x IPCops with these features already built-in and will
break their installations. Or it even might work - with unforseeable
results. And the worst case will take place when users will try to uninstall
these addons...

* Integrating some addons into the official code will break other addons on
IPCop. There are known incompabilities between different addons. Making some
of them a standard will lock out some other addons. This will annoy users
and displease addon developers.


To cut a long story short:

As long as IPCop 1.4 will exist, I will continue maintaining my addons the
same way as I did in the past few years. If somebody else wants to integrate
the code into the official 1.4 release, so have a go at it. I will neither
complain nor disagree with this.

Whenever the IPCop development team decides to change the versioning for a
'new' minor release, I will offer all my knowledge and my time to integrate
and actively maintain the code in this new minor IPCop release. In addition
to this, I would offer my support for any other IPCop related code, if
necessary.


Thank you for your attention.

Marco 

Is there any plans to include a web/cl interface to kill off active TCP connections (eg tcpkill)?

  Sally

Hi IvanK,
  This is a reply for the feature request I filed on SF.net

I manage to build IPCop with e100 v3.5.17 .
However, when I install IPCop on Dell Dimension 5150, at the stage of
probing network adaptor,
the process of probing end with screen showing all the register +
their value(EAX,EBX etc) .

In fact I have built IPCop 1.4.13 + e100 v3.5.17 before , end up with
the similar problem .

1.4.13 + e100 v3.4.14    Work fine for me (currently using)
1.4.15 + e100 v3.4.14    Tested , works.

I'm not sure what is the problem but I guess maybe e100 v3.5.x is for
2.6.x kernel and not back-ported to 2.4.x kernel


Glad to hear that it may be included in the next release , looking
forward to the next release soon .




> Date: 2007-03-28 13:01
> Sender: chepati <http://sourceforge.net/users/chepati/>
> I have already done this in my local tree.  It will probably be included
> in one of the next releases if Gilles approves it.

> What was the problem with 3.5.17?  Please reply on the devel list.

> IvanK.

----- Original Message ----- 
From: "Mohamed Hegazy" <mh...@em...>
To: "William Warren" <hes...@em...>
Cc: <ipc...@li...>
Sent: Wednesday, March 28, 2007 9:29 PM
Subject: Re: [IPCop-devel] [IPCop-user] problem with LSI SAS on ipcop 1.4.15


>
> sorry I did not really get what you mean; so what should i do to get it
> to work?
>
> Quoting William Warren <hes...@em...>:
>
> > bypass the controller as the reduced featureset of the ipcop kernel
> > isn't going to find it.
> >
> > Mohamed Hegazy wrote:
> >> we have got a new gateway server with LSI serial attached SCSI (SAS)
> >> host bus
> >> adapter (HBA). ipcop installation fails to detect the harddisk. so I
got the
> >> driver from LSI and compiled it with ipcop; but still, I still get the
same
> >> problem "no hard disk found".
> >>
> >> anybody knows why the compilation did not work or what should I od
> >> other than
> >> that.
> >>
> >> thanks;
> >> Mohamed
> >>
Unless you say exactly what you have done, we can't understand what could
have been wrong.

Gilles

sorry I did not really get what you mean; so what should i do to get it 
to work?

Quoting William Warren <hes...@em...>:

> bypass the controller as the reduced featureset of the ipcop kernel
> isn't going to find it.
>
> Mohamed Hegazy wrote:
>> we have got a new gateway server with LSI serial attached SCSI (SAS) 
>> host bus
>> adapter (HBA). ipcop installation fails to detect the harddisk. so I got the
>> driver from LSI and compiled it with ipcop; but still, I still get the same
>> problem "no hard disk found".
>>
>> anybody knows why the compilation did not work or what should I od 
>> other than
>> that.
>>
>> thanks;
>> Mohamed
>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> IPCop-user mailing list
>> IPC...@li...
>> https://lists.sourceforge.net/lists/listinfo/ipcop-user
>>
>>
>
> --
> My "Foundation" verse:
> Isa 54:17  No weapon that is formed against thee shall prosper; and
> every tongue that shall rise against thee in judgment thou shalt
> condemn. This is the heritage of the servants of the LORD, and their
> righteousness is of me, saith the LORD.
>
> -- carpe ductum -- "Grab the tape"
> CDTT (Certified Duct Tape Technician)
>
> Linux user #322099
> Machines:
> 206822
> 256638
> 276825
> http://counter.li.org/

Feature Requests item #1690111, was opened at 2007-03-29 03:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1690111&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: Next release
Status: Open
Priority: 5
Private: No
Submitted By: Koa CG (cyberkoa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include updated e100 driver

Initial Comment:
Although I have mentioned in the developer mailing list, here I file a official feature request for developers tracking purpose.

Dimension 5150 come with a network adaptor with new chipset , which do not supported by the IPCop 1.4.x kernel.

I have built my own customize IPCops CD to include the updated e100 driver and the latest attempt is with IPCops 1.4.15 source code + e100 v3.4.14.

Although it works fine for me , I still hope that it will be the official release because I cannot do an incremental update every a new version is released. 

FYI, I have tested to build IPCops with two version of  e100 driver, I found the latest version , ie, v3.5.17 will cause problem . The version that works is v3.4.14.

Attached the e100 file to put under <base>/lfs for building.

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

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

Feature Requests item #1690035, was opened at 2007-03-28 16:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1690035&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: Next Release (example)
Status: Open
Priority: 5
Private: No
Submitted By: tandilboy (tandilboy)
Assigned to: Nobody/Anonymous (nobody)
Summary: AX.25 support and routing

Initial Comment:
all the kernels (since 2.2) haves AX.25 Packet Radio Support. a good new improvement is AX.25 protocol to access Amateur Radio Networks

http://www.linux-ax25.org/wiki/AX.25

the better how-to for ax-25 over tcp/ip, please consider this idea...

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

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

Feature Requests item #1690028, was opened at 2007-03-28 16:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1690028&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: Next Release (example)
Status: Open
Priority: 5
Private: No
Submitted By: tandilboy (tandilboy)
Assigned to: Nobody/Anonymous (nobody)
Summary: AX.25 support and routing

Initial Comment:
all the kernels (since 2.2) haves AX.25 Packet Radio Support. a good new improvement is AX.25 protocol to access Amateur Radio Networks

http://www.linux-ax25.org/wiki/AX.25

the better how-to for ax-25 over tcp/ip, please consider this idea...

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

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

Bugs item #1689409, was opened at 2007-03-27 15:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1689409&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: Translations
Group: 1.4.15
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Patrick Scott (patrickscott)
Assigned to: Nobody/Anonymous (nobody)
Summary: Spanish translation for SSH Access is incorrect

Initial Comment:
For the SSH Access option in the System menu, the Spanish translation is incorrect.

Currently: Accesso SSH
Should be: Acceso SSH

This is also a problem in the SSH Access screen.

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

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

On Monday 26 March 2007, Jim Webster wrote:
> I have IPCop successfully running on a computer in my home network -
> great idea!
>
> I now have a little newbie question - I have four other old computers
> lying around here and rather than install & learn some other Linux ISO
> on them I was wondering if it was feasible to strip out the firewall
> programs from IPCop and use the remainder to run BOINC?
>
> Or is this impractical?

Ipcop is based on LFS (Linux From Scratch, http://www.linuxfromscratch.org).  
It's not a ready to download/install/use distribution, but rather 
do-it-yourself-and-learn-in-the-process kind of distribution.  You can choose 
just what you want to install, thus avoiding all the cruft that's installed 
by regular distributions.

The advantage of LFS is that you'll learn the underpinnings of ipcop, learn 
how linux works, and create a very lean os, that will be usable on an old 
machine.

But this should be on the -users list.

IvanK.

Bugs item #1688806, was opened at 2007-03-26 17:51
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1688806&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: Bill K (drotta)
Assigned to: Nobody/Anonymous (nobody)
Summary: Proxy Crash after Sudden Power Down

Initial Comment:
On 1.4.15, after a sudden power failure with Proxy service enabled and configured as the following.

Enabled On Green, Transparent On Green, and Log Enabled.

I had the Cache File set to 800meg, and the remaining options set as  default.

The computers were no longer able to browse the web, The proxy Setting had defaulted to the Original Settings for IPCOP. 

Copfiler is running on this machine.

Copfilter was turned off, and internet access still was not working.

I unchecked the options to deactive the proxy and then browsing would work,  Reactivating the proxy from services  with default settings and browsing was not functional.

Using Repair Cache funtion did not work. This function appeared to work in earlier versions .12 and 13. If my recollection serves me right Franck worked on adding the repair function around 1.4.11 to deal with something very similar to this.

Not until I recreated the cache file to the size it had been was I able to browse with the proxy enabled.

On other odd thing was as the proxy file was being recreated to its larger size, there was a very large amount of disk activity which was very different than previous experiences doing so. 

THanks for the super project.


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

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

Jason wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jim Webster wrote:
>> I have IPCop successfully running on a computer in my home network - 
>> great idea!
>>
>> I now have a little newbie question - I have four other old computers 
>> lying around here and rather than install & learn some other Linux ISO 
>> on them I was wondering if it was feasible to strip out the firewall 
>> programs from IPCop and use the remainder to run BOINC?
>>
>> Or is this impractical?
> 
> I'm sure it's possible, but it may be harder than you think.  Since
> you're new to Linux I would suggest trying another distro for the
> experience.  You could do something full-blown like Ubuntu or go with a
> smaller installation like DSL (damned small linux) or puppy linux.  Old
> hardware is a great opportunity to learn.

oops the newbie bit referred to my use of IPCop... I've been running a 
SUSE-Linux machine here for about 2 years buts its way too large for a 
distro for an old computer in more ways than one....

I still wouldn't mind giving at go with some guidance as to exactly what 
it entails.


-- 
TTFN
Jim


'Interdum feror cupidine partium magnarum Europae vicendarum!'

Bugs item #1688785, was opened at 2007-03-26 17:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=1688785&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: Bill K (drotta)
Assigned to: Nobody/Anonymous (nobody)
Summary: Proxy Randomy Missing from menu Tabs

Initial Comment:
Upgraded from 1.4.13 to 1.4.15.  After the upgrade, I noticed that On the Services tab and on the Log Tab that the Proxy and Proxy logs respective Missing.

I then exited IE, cleared the Cache. I was still not able to see the Proxy and Proxy Logs as being options.

However after several times of mousing over the respective Tabs, I was able to get them to appear. 

I use the Proxy and Proxy Logs all the time and this was the first time that it was not even an option on the Services Menu to Check. 

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

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

I have IPCop successfully running on a computer in my home network - 
great idea!

I now have a little newbie question - I have four other old computers 
lying around here and rather than install & learn some other Linux ISO 
on them I was wondering if it was feasible to strip out the firewall 
programs from IPCop and use the remainder to run BOINC?

Or is this impractical?

-- 
TTFN
Jim


'Interdum feror cupidine partium magnarum Europae vicendarum!'

Feature Requests item #1688761, was opened at 2007-03-27 05:10
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1688761&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: Koa CG (cyberkoa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ajax for frequently change  status page

Initial Comment:
There is a request for Ajax interface previously but is on the page showing rules.

My request is a bit different, where my request is only focus on some frequently changed status page. 

For example, the connection status page. 

I found this is helpful when I was troubleshooting a connection problem where I need to click Refresh button many times in order to get the page show the latest connection.

Although manually refresh can work well ，I think this is where Ajax is really applicable and worth the effort.

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

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

On Thursday 15 March 2007, Ivan Kabaivanov wrote:
> On Monday 05 March 2007 04:09, Franck Bourdonnec wrote:
> > Update of /cvsroot/ipcop/ipcop/lfs
> > In directory sc8-pr-cvs2.sourceforge.net:/tmp/cvs-serv22846
> >
> > Modified Files:
> > 	lzma
> > Log Message:
> > I stored the patch in unix text but the source file is in cr/lf format.
> > Add a sed before feeding patch.
>
> Franck,
>
> since we keep the patch in our own repository (as opposed to downloading
> it), it's better if we fix the lf/cr rather than add more commands, even if
> they are simple.
>
> IvanK.


Franck,

ignore my previous email -- I was confused.

IvanK.


>
> > Index: lzma
> > ===================================================================
> > RCS file: /cvsroot/ipcop/ipcop/lfs/lzma,v
> > retrieving revision 1.3
> > retrieving revision 1.4
> > diff -C2 -d -r1.3 -r1.4
> > *** lzma	4 Mar 2007 12:48:51 -0000	1.3
> > --- lzma	5 Mar 2007 09:09:51 -0000	1.4
> > ***************
> > *** 82,86 ****
> >   	@rm -rf $(DIR_APP) && cd $(DIR_SRC) && mkdir $(THISAPP) && cd
> > $(THISAPP) && tar jxf $(DIR_DL)/$(DL_FILE)
> >
> > ! 	cd $(DIR_APP) && patch -Np1 < $(DIR_PATCHES)/lzma433_lib.patch
> >   	cd $(DIR_APP)/C/7zip/Compress/LZMA_Alone && make -f makefile.gcc
> > CXX="g++ $(CFLAGS)" cd $(DIR_APP)/C/7zip/Compress/LZMA_Alone && install
> > -m 0755 lzma /usr/bin --- 82,86 ----
> >   	@rm -rf $(DIR_APP) && cd $(DIR_SRC) && mkdir $(THISAPP) && cd
> > $(THISAPP) && tar jxf $(DIR_DL)/$(DL_FILE)
> >
> > ! 	cd $(DIR_APP) && sed 's/$$/\x0D/' $(DIR_PATCHES)/lzma433_lib.patch |
> > patch -Np1 cd $(DIR_APP)/C/7zip/Compress/LZMA_Alone && make -f
> > makefile.gcc CXX="g++ $(CFLAGS)" cd $(DIR_APP)/C/7zip/Compress/LZMA_Alone
> > && install -m 0755 lzma /usr/bin
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> IPCop-cvs mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-cvs

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "Gilles Espinasse" <g....@fr...>
Cc: "IPCop devel" <ipc...@li...>;
<mar...@my...>
Sent: Friday, March 23, 2007 10:58 AM
Subject: Re: [IPCop-devel] Integrate more add-ons on 1.4.x?


> Gilles,
>
> > I was inclined to choose advanced proxy add-on and related other add-on
URL
> > filter, update accelerator and calamaris.
>
> I am not so sure if this is a good idea.
> We are now already 3 versions behind with Squid (1.4.15 has 2.6STABLE9,
> current Squid is 2.6STABLE12)
>
> In my opinion Marco does a splendid job with his addons, they integrate
> very well, work and are uptodate.
>
>
> I guess this (integration of Advanced Proxy) only makes sense if we:
>
> 1) have a mechanism to quickly update parts of IPCop (hotfixes), so that
> we can better follow Squid (for those that have proxy activated).
>
> 2) persuade Marco to be the maintainer of the IPCop-Proxy parts.
>
> 3) integrate Advanced Proxy such that the admin can choose: no proxy,
> standard proxy, advanced proxy. Depending on choice we should provide
> different GUI. The adv. Proxy view can really swamp someone and we have
> more than enough complicated GUI pages at the moment.
>
>
> cheers Olaf
>
I agree for the three points.
for 1) we have to make some progress on v1.5 so that v1.5 really come again
the development version, so we would only commit on v1.4 stable, tested and
ready to release changes.
This is the first key point.

for 2) that's Marco decision

for 3) nothing to add to your proposal

I do not forget that if Marco changes were integrated, we will broke the
other squid solutions (not definitely, but a small packaging effort), so we
may create temporary breakage. That's not so good and could be minimised if
we could plan the integration time.

Gilles
Gilles

----- Original Message ----- 
From: "Robert Staaf" <rs...@be...>
To: "IPCop devel" <ipc...@li...>
Sent: Saturday, March 24, 2007 12:38 AM
Subject: Re: [IPCop-devel] Integrate more add-ons on 1.4.x?


> I have to say that I much prefer the add-on concept.  Where do you draw
the
> line on incorporating the add-on of the day?  It doesn't take a lot of
time
> or effort to get these add-ons installed and running, why the need to
> incorporate them into the distribution?  My fear is that IPCop will become
> overly complex and bloated....
>
> Just my 2 cents, probably all it is worth :)
>
> Bob
>
I want to make v1.5 more modular but with v1.4 we have to live and maintain
an the installed base and change as less code as we are able to.
v1.4 will stay with the same required space on root partition, that's the
main limit.

Gilles

On Sunday 25 March 2007 03:46:34 am Olaf Westrik wrote:
> Hello,
>
>
> now that the dust has settled, I think we should do some reflecting and
> consider some rules for the future.
>
>
> In future we always make (at least) one release candidate for every
> upgrade. And wait a minimal of 10 days for feedback. So that those that
> can test have time to do so and can report back.
> There will be no exceptions to this rule. For quickly fixing something
> (critical bug / security bug) we need a different mechanism.
>
>
> If the project leader (Gilles) announces that he wants to
> prepare a release, there is effectively a feature freeze. That means
> *every* developer stops making changes unless these are bugfixes and
> even these must be coordinated with the project leader (Gilles).
> The coordination will take place in here, ipcop-devel mailinglist, so
> that everybody knows what is going on.
> Preparing a release is enough work as it is (I have never done this
> using CVS, but I can imagine) and modifications (large or small) only
> makes things worse.
>
>
> As always following applies: the next version will come shortly after it
> is finished. And it is finished as soon as it is uploaded by the project
> leader. In other words: if Gilles needs more time (for whatever reason)
> than he simply needs (and will be given) more time.
>
>
> cheers Olaf

This normally was the case anyway, we went for nearly a year between updates a 
while back but recently there was an urgent need and the option was there to 
just apply the time/date patch. I don't think for a second that anyone was 
releasing updates just for the fun of it.

Dave

----- Original Message ----- 
From: "Jochen Rupp" <joc...@we...>
To: <ipc...@li...>
Sent: Sunday, March 25, 2007 11:43 AM
Subject: [IPCop-devel] Implementation of Inode-usage in System-Status


> Hi Gilles,
>
> I ran into problems with my cop ad it took quite a while to find out that
there just were no inodes left on the disk. It would be great to have the
output of 'df -i' at the 'System-Status-Page' in order to have a advance
warning in the future . Normally you check all the ressource usage there and
everything seems to be ok but since there is no Inode-Usage-Info it could be
hard to find the reason for a problem.
>
> Thanks in advance!
>
> Cheers,
> Jochen (cibo mato)
>
>
Hello

That's done in 1.4.14 in the System Status page.
Olaf do it.

This would mean that you are late in updates ;-)

Gilles

Feature Requests item #1687959, was opened at 2007-03-25 21:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1687959&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: cunning_plan (cunning_plan)
Assigned to: Nobody/Anonymous (nobody)
Summary: make ISP's modem status page visible

Initial Comment:
Most Alcatel und Thomson modems provide a status page on 10.0.0.138 with interesting ISP's link data like up- and downstream speeds even during an active PPPoE connection. It would ease the debugging of connection problems or just be interesting to occasionally check the uplink to the ISP if this status page would be visible from within IPCop's GUI.
I think it should be possible to assign the RED interface the static IP 10.0.0.1 in /etc/rc.d/rc.red and embed the modem's status page fetched from 10.0.0.138 in a page displayed in the web interface of IPCop - maybe as simple as a frame.
For security reasons, this embedded frame might be stripped off of all links as it might otherwise provide direct access to the ISP's modem configuration pages.



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

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

Feature Requests item #1687950, was opened at 2007-03-25 20:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428519&aid=1687950&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: cunning_plan (cunning_plan)
Assigned to: Nobody/Anonymous (nobody)
Summary: make ISP's modem status page visible

Initial Comment:
Most Alcatel und Thomson modems provide a status page on 10.0.0.138 with interesting ISP's link data like up- and downstream speeds even during an active PPPoE connection. It would ease the debugging of connection problems or just be interesting to occasionally check the uplink to the ISP if this status page would be visible from within IPCop's GUI.
I think it should be possible to assign the RED interface the static IP 10.0.0.1 in /etc/rc.d/rc.red and embed the modem's status page fetched from 10.0.0.138 in a page displayed in the web interface of IPCop - maybe as simple as a frame.
For security reasons, this embedded frame might be stripped off of all links as it might otherwise provide direct access to the ISP's modem configuration pages.



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

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