ipcop-devel Mailing List for IPCop Firewall

On Thu, 30 Jun 2005 14:27:11 +0200, Achim wrote in message 
<42C...@gm...>:

> > Hi IPCops,
> > the following line makes the ipcop machine reboot,
> > when ctrl-alt-del is pressed (/etc/inittab).
> > 
> > ca::ctrlaltdel:/sbin/shutdown -r now
> > 
> > This can be done by everybody, who has access to the
> > ipcop's keyboard. But in my opinion only root (and admin)
> > should be allowed to reboot or shutdown the machine?!
> > 
> > See:
> > 
> > http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap5sec49.html
> 
> When i have physical access to the IPCop box i can poweroff the
> machine...
> 
> Too when i have physical access i can boot ipcop with single parameter
> and  change the root password ;-)

..ah yeah, good old 'init=/bin/sh'.  ;o)
 
> Achim
> 
> PS: I do change the command to "shutdown -h now" on every of my
> ipcop's. So i don't have to boot my workstation when i forgot to
> shutdown the cop.

..this halt on C-M-Del should be the default only for dial-up users, as
they will wanna go off-line and shut down their ipcop.  And, this
option should set-able from at least the system or dial-up web page.

..most people who stay online 24/7/365 and with servers etc, will want
always-on, and always online, and 15 second reboots rather than 1500
calls per minute of downtime until someone puts a finger on the power
button.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;o)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Le Jeudi 30 Juin 2005 14:34, vous avez =E9crit :
> On Thu, 2005-06-30 at 08:39 +0000, Franck Bourdonnec wrote:
> > A strange line is also noted:
> > 1) only executed when ORANGE_DEVICE exists,
> > 2) what usefull thing can an iptables -A FORWARD -i eth0 -o eth0 -j
> > ACCEPT can do ????  (yes ( -i -o are same device).
>
> It lets traffic from orange to orange work... at first you might think
> it strange that orange to orange traffic would ever go through IPCop,
> but consider this:
>
>  * you have a port forward for your mailserver, from red to orange
>  * you have another server on orange that tries to email one of your
>    users
>
> What happens then is the server looks up your MX, and goes to connect to
> your red IP, which IPCop then forwards back to your mailserver. So in
> effect you get orange to orange traffic, but it's being routed through
> IPCop.
>
> The rule was added to CVS recently to fix a bug someone reported in
> 1.4.6.

This is exactly the kind of line which needs a least a minimum comment and=
=20
explication near it....
Someone reading this code is absolutly unable to guess that 'bug' !

It is a strange explanation, I can't imagine tcp/ip stack machine A speaking
to machine B through machine C, all on same subnet. It simply 'defeats?'
ip mask and gateway functionning !

I think placing a host entry for dnsmasq for the mail server is unsifficien=
t=20
because of MX being querried ?


=46ranck

Le Jeudi 30 Juin 2005 14:18, Robert Kerr a =C3=A9crit :

> Shouldn't be too difficult... what do you want to do that uses SSL?

HTTPS is used with some DYNDNS providers while updating records.
(selfhost.de I think). And others will follow I think. It is not secure to
send any password/keycode as cleartext .... !

=46ranck

> Hi IPCops,
> the following line makes the ipcop machine reboot,
> when ctrl-alt-del is pressed (/etc/inittab).
> 
> ca::ctrlaltdel:/sbin/shutdown -r now
> 
> This can be done by everybody, who has access to the
> ipcop's keyboard. But in my opinion only root (and admin)
> should be allowed to reboot or shutdown the machine?!
> 
> See:
> 
> http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap5sec49.html

When i have physical access to the IPCop box i can poweroff the machine...

Too when i have physical access i can boot ipcop with single parameter and 
change the root password ;-)

Achim

PS: I do change the command to "shutdown -h now" on every of my ipcop's. So i
don't have to boot my workstation when i forgot to shutdown the cop.

On Thu, 2005-06-30 at 14:01 +0200, Daniel Berlin wrote:
> Hi IPCops,
> the following line makes the ipcop machine reboot,
> when ctrl-alt-del is pressed (/etc/inittab).

> ca::ctrlaltdel:/sbin/shutdown -r now

> This can be done by everybody, who has access to the
> ipcop's keyboard. But in my opinion only root (and admin)
> should be allowed to reboot or shutdown the machine?!

You can't stop someone with physical access being able to reboot or
shutdown the machine, they can just use the power button on the case or
pull the power cord. Indeed anyone with physical access can get root
access by removing the harddrive and reading/changing it on another
machine. If you don't trust people with physical access then you need to
move the system to a more secure location.

Allowing someone with keyboard access to cleanly reboot the machine can
be quite useful. If there's a problem at a remote office you can tell
someone there to hit ctrl-alt-delete instead of having to drive up
there, log in, and reboot manually.

-- 
 Robert Kerr

On Wed, 2005-06-29 at 22:19 +0200, Franck Bourdonnec wrote:
> Le Mercredi 29 Juin 2005 21:28, Robert Kerr a =C3=A9crit :
> > Use libwww-perl for HTTP downloads from CGIs, this should resolve the
> > issues some users are having with IDS rule updates. Also should fix the
> > inability to download update lists when an upstream proxy requires
> > user/pass (bug 1205470)

> If you are working on this part of ipcop [perl], maybe you can also
> add "https" (cpan module NET-SSLeay) to complete your job.
> Also set a UserAgent Name to "ipcop" ?

Shouldn't be too difficult... what do you want to do that uses SSL?

I did wonder about setting the user agent to ipcop, but I wasn't sure if
it's a good idea. People often tend to be paranoid about being tracked,
particularly if it also sent the version of IPCop as well as the name.
What does anyone else think?

> The "download code" is also in used setddns.pl.
> Can you do the the swap code  also ? Or give me a zip
> a Perl::modification to add to 1.4.6 so that I can do it.

Should be able to do this at the weekend.

> I have seen a serious bug with my setddns.pl. During this
> month, I had to kill 'setddns.pl' to unlock my ipcop box.
> An infinite loop somewhere. Twice!!

I've seen this too, not sure if someone else reported it or one of my
test systems did it.

--=20
 Robert Kerr

Hi IPCops,
the following line makes the ipcop machine reboot,
when ctrl-alt-del is pressed (/etc/inittab).

ca::ctrlaltdel:/sbin/shutdown -r now

This can be done by everybody, who has access to the
ipcop's keyboard. But in my opinion only root (and admin)
should be allowed to reboot or shutdown the machine?!

See:

http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap5sec49.html

Greez,
daniel berlin

Le Mercredi 29 Juin 2005 21:28, Robert Kerr a =E9crit :
> Use libwww-perl for HTTP downloads from CGIs, this should resolve the
> issues some users are having with IDS rule updates. Also should fix the
> inability to download update lists when an upstream proxy requires
> user/pass (bug 1205470)
>
If you are working on this part of ipcop [perl], maybe you can also
add "https" (cpan module NET-SSLeay) to complete your job.
Also set a UserAgent Name to "ipcop" ?



The "download code" is also in used setddns.pl.
Can you do the the swap code  also ? Or give me a zip
a Perl::modification to add to 1.4.6 so that I can do it.

I have seen a serious bug with my setddns.pl. During this
month, I had to kill 'setddns.pl' to unlock my ipcop box.
An infinite loop somewhere. Twice!!

The first thing I suppose is 'gethostbyname' do not time out
if network is down (it is the last addition).!?


=46ranck



NET_SSLeay

1)download one more file : "Net_SSLeay.pm"
http://search.cpan.org/CPAN/authors/id/S/SA/SAMPO/Net_SSLeay.pm-1.25.tar.gz
md5=3D 87de8a06802fbb63c7c85e89eedbe139
2)compile and install.

=46rom the readme:

Installing
=2D---------
Unix:
        # build OpenSSL as per instructions in that package
        gunzip <Net_SSLeay.pm-1.25.tar.gz | tar xvf -
        cd Net_SSLeay.pm-1.25
        ./Makefile.PL -t     # builds and tests it
        make install         # You probably have to su to root to do this
     #   perldoc Net::SSLeay  # optional, but highly recommended
      #  perldoc Net::SSLeay::Handle

----- Original Message -----=20
From: "Franck Bourdonnec" <fbo...@ch...>
To: <ipc...@li...>
Sent: Wednesday, June 29, 2005 2:20 AM
Subject: Re: [IPCop-devel] patch for general-functions.pl sub validedmail
longer than 3 chars


> Le Mercredi 29 Juin 2005 00:17, John Edwards a =E9crit :
>
> > While I was looking at this, I was thinking either a single file or
> > prepending 'cpan-' to the lfs file would be tidier.
> >
> > Including the modules required for my patch we are currently at 8 CPA=
N
> > modules:
> > Digest
> > Digest-HMAC
> > Digest-SHA1
> > Email-Valid
> > GD
> > MailTools
> > Net-DNS
> > Net-IPv4Addr
> >
> >
> > I'm not deeply familiar with Linux from Scratch but from what I can
> > see having seperate files means:
> >
> > 1) Each module is run as it's own build process launched from make.sh
> > and creates it's own log file. Would this make things easier to debug=
?
>
>
> > 2) Each module contains it's own variables in line with what appears
> > to be the LFS standard - eg "VER", "DL_FROM", "md5", etc. I suspect
> > that placing multiple download files in a single lfs file would
> > complicate matters.
>
> I prefer (imho) to limit number a files making a project.
> Theses can be seen as pacth to apply to Perl, One file.
> We can also group two or more cpan modules in one
> 'patch' file =3D> MailTool&ValidEmail
> 'patch' file =3D> Net-DNS&NetIPv4
> 'patch' file =3D> Digest&Digest-HMAC/SHA1 & SSL
>
> This limits number of files...   Good not good ?

It is easier for maintenance if each module is separate. Consider the cas=
e
of module upgrade or simple patch.
Until we use md5 to track each FILES version release list, it is not alwa=
ys
simple to know wich file has been changed by a patch, so wich files need =
to
be include in an update after a patch.
Very long log/* file is a nightmare to verify if you have set the proper
rootfile inclusion.

The drawback is that it take a bit more time to build as creating pre and
post-build log is a time costly operation.

I would prefer as minimal as possible changes in v1.4, so change only wha=
t
is necessary to change.

Gilles

On Wed, Jun 29, 2005 at 02:20:26AM +0200, Franck Bourdonnec wrote:
> Le Mercredi 29 Juin 2005 00:17, John Edwards a =E9crit :
>=20
>> While I was looking at this, I was thinking either a single file or
>> prepending 'cpan-' to the lfs file would be tidier.
>>
>> Including the modules required for my patch we are currently at 8 CPAN
>> modules:
>> Digest
>> Digest-HMAC
>> Digest-SHA1
>> Email-Valid
>> GD
>> MailTools
>> Net-DNS
>> Net-IPv4Addr
>>
>>
>> I'm not deeply familiar with Linux from Scratch but from what I can
>> see having seperate files means:
>>
>> 1) Each module is run as it's own build process launched from make.sh
>> and creates it's own log file. Would this make things easier to debug?

>> 2) Each module contains it's own variables in line with what appears
>> to be the LFS standard - eg "VER", "DL_FROM", "md5", etc. I suspect
>> that placing multiple download files in a single lfs file would
>> complicate matters.

> I prefer (imho) to limit number a files making a project.
> Theses can be seen as pacth to apply to Perl, One file.
> We can also group two or more cpan modules in one
> 'patch' file =3D> MailTool&ValidEmail
> 'patch' file =3D> Net-DNS&NetIPv4
> 'patch' file =3D> Digest&Digest-HMAC/SHA1 & SSL
>=20
> This limits number of files...   Good not good ?

That would still have the problem with needing to put multiple=20
variables into each file, one set for each module.

Some of the answers to these questions are probably in the LFSmake and
GNU make docs:
	http://www.sunsetsystems.com/lfsdoc.php3
	http://www.gnu.org/software/make/


IIRC 'make' has lists, but not any more complex arrays. So I think=20
it can be done if we roll the module name, version and CPAN download=20
directory together and just have a list of those, some like:

DL_FILES =3D Email/Email-Valid-0.15.tar.gz Mail/MailTools-1.67.tar.gz
DL_FROM =3D $(subst %,%$(URL_CPAN)/,$(DL_FILES))

(above is completely untested and probably wrong)

The drawback is that we lose seperate variables for the module name=20
("THISAPP" and "DL_FILE"), version number ("VER") and CPAN directory=20
("DL_FROM"). Of these I think the only one that is likely to cause a=20
problem is the version number, and I can't see that it's used anywhere=20
for the CPAN modules (though it is for Perl itself).

I'll see if I can have a little play with make scripts tomorrow.


--=20
#---------------------------------------------------------#
|    John Edwards   Email: jo...@co...    |
|                                                         |
| A. Because it breaks the logical sequence of discussion |
| Q. Why is top posting bad ?                             |
#---------------------------------------------------------#

Le Mercredi 29 Juin 2005 00:17, John Edwards a =E9crit :

> While I was looking at this, I was thinking either a single file or
> prepending 'cpan-' to the lfs file would be tidier.
>
> Including the modules required for my patch we are currently at 8 CPAN
> modules:
> Digest
> Digest-HMAC
> Digest-SHA1
> Email-Valid
> GD
> MailTools
> Net-DNS
> Net-IPv4Addr
>
>
> I'm not deeply familiar with Linux from Scratch but from what I can
> see having seperate files means:
>
> 1) Each module is run as it's own build process launched from make.sh
> and creates it's own log file. Would this make things easier to debug?


> 2) Each module contains it's own variables in line with what appears
> to be the LFS standard - eg "VER", "DL_FROM", "md5", etc. I suspect
> that placing multiple download files in a single lfs file would
> complicate matters.

I prefer (imho) to limit number a files making a project.
Theses can be seen as pacth to apply to Perl, One file.
We can also group two or more cpan modules in one
'patch' file =3D> MailTool&ValidEmail
'patch' file =3D> Net-DNS&NetIPv4
'patch' file =3D> Digest&Digest-HMAC/SHA1 & SSL

This limits number of files...   Good not good ?


=46ranck

On Tue, Jun 28, 2005 at 11:48:33PM +0200, Franck Bourdonnec wrote:
> Le Mardi 28 Juin 2005 23:12, John Edwards a =E9crit :
>> Hi Robert
>> I've finished testing the patch, which also includes lfs scripts to
>> build the required Perl modules:
>> 	http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1229322&=
group_id=3D40604&atid=3D428519
>>=20
>> Currently it's written against the 1.4 branch of CVS, but should work
>> for HEAD as well.

> Hello John, Hello Robert,
>=20
> I plan to add "https" support also from CPAN.=20
>=20
> HTTPS:need LWP and Crypt-SSLeay addition to perl
>=20
> John, you already made two "lfs/files" to add two modules into Perl.

I was following the pattern of previous CPAN modules.

> My question is :
>=20
> Isn't a single file "lfs/cpan" more efficient to maintain all
> module extension to Perl ???
>=20
> The patch content
>=20
> Mail::tools
> Mail::valid
> I need SSLeay
> and I'm not sure, another (LWP ?)

While I was looking at this, I was thinking either a single file or=20
prepending 'cpan-' to the lfs file would be tidier. =20

Including the modules required for my patch we are currently at 8 CPAN
modules:=20
Digest
Digest-HMAC
Digest-SHA1
Email-Valid
GD
MailTools
Net-DNS
Net-IPv4Addr


I'm not deeply familiar with Linux from Scratch but from what I can=20
see having seperate files means:=20

1) Each module is run as it's own build process launched from make.sh
and creates it's own log file. Would this make things easier to debug?

2) Each module contains it's own variables in line with what appears=20
to be the LFS standard - eg "VER", "DL_FROM", "md5", etc. I suspect=20
that placing multiple download files in a single lfs file would=20
complicate matters.


--=20
#---------------------------------------------------------#
|    John Edwards   Email: jo...@co...    |
|                                                         |
| A. Because it breaks the logical sequence of discussion |
| Q. Why is top posting bad ?                             |
#---------------------------------------------------------#

Le Mardi 28 Juin 2005 23:12, John Edwards a =E9crit :

> Hi Robert
> I've finished testing the patch, which also includes lfs scripts to
> build the required Perl modules:
> 	http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1229322&gro=
up_id=3D
>40604&atid=3D428519
>
> Currently it's written against the 1.4 branch of CVS, but should work
> for HEAD as well.
>

Hello John, Hello Robert,

I plan to add "https" support also from CPAN.=20

HTTPS:need LWP and Crypt-SSLeay addition to perl

John, you already made two "lfs/files" to add two modules into Perl.

My question is :

Isn't a single file "lfs/cpan" more efficient to maintain all
module extension to Perl ???

The patch content

Mail::tools
Mail::valid
I need SSLeay
and I'm not sure, another (LWP ?)



=46ranck


ps: (https will be use with some dyndns provider to update records).

On Fri, Jun 17, 2005 at 03:50:11PM +0100, Robert Kerr wrote:
> John Edwards <jo...@co...> wrote:
>> On Fri, Jun 17, 2005 at 01:48:43PM +0100, Robert Kerr wrote:
>>> One possible alternative would be to use Email::Valid, which uses Tom's
>>> regex and wraps it in an easy to use package. Maybe it would be easier to
>>> stick with what we have now though and just hope nobody finds another
>>> valid email address it filters.

>> The current method is ugly and wrong. I think there are two options
>> are to either use a full validator like Email::Valid, or do a basic
>> sanity check to stop either obviously wrong or potentially malicious
>> address being given.

>> I could have a go a trying to write a patch for the Email::Valid module.
>> In what circumstances is the email address currently used ?
> 
> As far as I know it's only for validating addresses used in VPN certificates,
> it's probably pretty irrelevant whether these are truly valid or not. The
> only issue is whether any of the underlying software (openssl or openswan)
> places any requirements on the validity of the address.

Hi Robert
I've finished testing the patch, which also includes lfs scripts to 
build the required Perl modules:
	http://sourceforge.net/tracker/index.php?func=detail&aid=1229322&group_id=40604&atid=428519

Currently it's written against the 1.4 branch of CVS, but should work 
for HEAD as well.


ps. Note that it only checks that the email address is syntactically 
correct. It doesn't check that the domain exists, or has MX or A 
records, or that mail can be sent to it. But we don't want any of 
that.


-- 
#---------------------------------------------------------#
|    John Edwards   Email: jo...@co...    |
|                                                         |
| A. Because it breaks the logical sequence of discussion |
| Q. Why is top posting bad ?                             |
#---------------------------------------------------------#

Feature Requests item #1229322, was opened at 2005-06-28 22:06
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=1229322&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
Submitted By: John Edwards (johnedwards)
Assigned to: Nobody/Anonymous (nobody)
Summary: Patch to use Email::Valid perl module

Initial Comment:
A patch to fix the validemail function in
general-functions.pl by replacing the current kludge of
regular expressions wi\th the CPAN module Email::Valid.
It also builds the Email::Valid and Mailtools perl
modules from CPAN.

The patch is against the 1.4 branch of CVS from 24th
July 2005, and has been tested with a clean install on
VMWare.



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

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

Gilles Espinasse skrev den 28-06-2005 19:38:

>>The file ipaddr-1.4.tar.gz is unavaible in this main site. Are you an
>>alternative url please?
>>
>It is available. It should be more a question of firewalling on your
>building machine or the way the wget request is made in lfs/Config.
>On  some ftp sites, you need to accept ftp connection on your building
>machine.
>A other solution could be to add the passive option for ftp site (but only
>for ftp). I am unsure that it will not shift the problem for ftp site not
>supporting passive mode.
>  
>

This is a really classic problem. As it is just a small file, it ought 
to be possible to find another server to host it.

A small improvement could be a remark in the lfs-file about trying to 
get it manually from the same adress with a ordinary ftp-program.


-- 
Morten Christensen

----- Original Message ----- 
From: "leso" <le...@le...>
To: <ipc...@li...>
Sent: Tuesday, June 28, 2005 8:52 AM
Subject: [IPCop-devel] File unavaible


> The file ipaddr-1.4.tar.gz is unavaible in this main site. Are you an
> alternative url please?
>
It is available. It should be more a question of firewalling on your
building machine or the way the wget request is made in lfs/Config.
On  some ftp sites, you need to accept ftp connection on your building
machine.
A other solution could be to add the passive option for ftp site (but only
for ftp). I am unsure that it will not shift the problem for ftp site not
supporting passive mode.

on 28/6/05 7:52 am, leso at le...@le... wrote:

> The file ipaddr-1.4.tar.gz is unavaible in this main site. Are you an
> alternative url please?

Morten attached a copy to his recent post:
http://marc.theaimsgroup.com/?l=ipcop-devel&m=111977322501651&w=2

Eric

The file ipaddr-1.4.tar.gz is unavaible in this main site. Are you an 
alternative url please?

Bugs item #1228283, was opened at 2005-06-27 14: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=1228283&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: User Interface
Group: 1.4.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Oberlander (eoberlander)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in logwatch 5.2.2 http section

Initial Comment:
On my Log Summary page (summary.dat) the HTTP Server 
section always shows 0.0 MBytes transferred. 
 
IPCop v1.4.6 uses logwatch version 5.2.2, whereas the current 
stable version of logwatch is 6.1.2 
 
Replacing the file /etc/log.d/scripts/services/http with the latest 
stable version (http v1.28) appears to fix it. Can anyone else 
confirm? 
 
Eric 
 

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

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

Bugs item #1228204, was opened at 2005-06-27 12:43
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=1228204&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: User Interface
Group: 1.4.6
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Oberlander (eoberlander)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in logwatch 5.2.2 http section

Initial Comment:
On my Log Summary page (summary.dat) the HTTP Server 
section always shows 0.0 MBytes transferred. 
 
IPCop v1.4.6 uses logwatch version 5.2.2, whereas the current 
stable version of logwatch is 6.1.2 
 
Replacing the file /etc/log.d/scripts/services/http with the latest 
stable version (http v1.28) appears to fix it. Can anyone else 
confirm? 
 
Eric 
 

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

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

Hi all,

I got a system that filters users based on their tunnel name and when
they're active or not. 1 problem I've come into is where 2 users on
different networks are connected and both appear on ipsec0 and both are
on a LAN with a 192.168.0.XX address

IF they have the same IP on the LAN (different network), they will have
the same/merged rules..

any ideas on this?

Thanks,
____________________________________________
George Vieira

Robert Kerr schrieb:

>On Thu, 2005-06-23 at 11:09 +0200, Matthias Mosimann wrote:
>
>  
>
>>I installed ipcop three times .. and had always the same problems. Then I
>>checked the hardware (I've got a very old machine) ... but I can't find any
>>problems.
>>    
>>
>
>How did you check your hardware? have you ran memtest86 on it?
>  
>
yep.

>  
>
>>In /var/log/messages I can't find any strange entries. The I decided to have
>>a look at the bug database and I found a problem similar to mine:
>>http://sourceforge.net/tracker/index.php?func=detail&aid=1077113&group_id=40604&atid=428516
>>    
>>
>
>  
>
>>Now my questions: Is that realy a bug or do I have another problem? When it
>>is one: Are you working on this bug? .. or should I open a new one? I
>>haven't read the whole thread in the bug database. But I entered some of
>>commands listed there but couldn't find any strange things.
>>    
>>
>
>Your problem is not the same; that bug describes the port forwarding
>stopping working, it makes no mention of anything else stopping working.
>These differences may not seem much to you but they're very significant
>in terms of how IPCop works.
>
>You can open a new bug describing your particular problem, but bear in
>mind this is going to be difficult to debug. It's not something that
>affects anyone else, so it seems likely it's somehow related to your
>hardware or setup. Be sure to include as much detail about your setup as
>possible, especially the type of red interface you have. The more we
>know about your setup the more likely it is we'll be able to replicate
>the problem.
>  
>
ok ... I have three RTL8139 cards in my box ... maybe there is a problem 
with this cards.
I set up a total new box up, but still have the same problem. Maybe I 
should by some
new hardware and some intel eepro100 card's.


regards
Matthias

raj...@as... skrev:

>Hi all,
>
>I am trying to compile iocop from scratch. But when I try the prefetch
>stage I get ~ 10 urls which are wrong. 
>ftp://ftp.ingate.com/pub/ipaddr/ipaddr-1.4.tar.gz
>

ipaddr is a well-known problem. Their server does not allow the lfs-way, 
but you can download it manualle from the address wit a ftp-program, or 
use this attached file.

-- 
Morten Christensen

On Sat, Jun 25, 2005 at 07:02:33PM +0200, Gilles Espinasse wrote:
> 
> ----- Original Message ----- 
> From: <raj...@as...>
> To: <ipc...@li...>; <ipc...@li...>
> Sent: Saturday, June 25, 2005 3:54 PM
> Subject: [IPCop-devel] make.sh prefetch failures
> 
> 
> > Hi all,
> >
> > I am trying to compile iocop from scratch. But when I try the prefetch
> > stage I get ~ 10 urls which are wrong. I fixed some of them with the
> > help of google, and manually downloaded some others (some with later
> > versions). But that leaves still leaves a couple of files. They are:
> >
> >
> http://www.linuxfromscratch.org/patches/downloads/man/man-1.5p-80cols-1.patch
> >
> http://www.linuxfromscratch.org/patches/downloads/shadow/shadow-4.0.7-uClibc-1.patch
> > ftp://ftp.ingate.com/pub/ipaddr/ipaddr-1.4.tar.gz
> >
> > I have changed the version of the following packages:
> >
> > capi4k-utils
> > #VER        = 2005-03-22
> > VER        = 2005-05-09
> >
> > dhcp
> > #VER        = 3.0.3b1
> > VER        = 3.0.3b3
> >
> > I am yet to compile, so cannot comment if the new versions will work.
> > But before I starts compilation I need to hunt down the 3 files I am
> > missing. Any help in locating a working url for these 3 files will be
> > much appreciated.
> >
> > regards,
> >
> > raj
> >
> you are building the developement version, what will be v1.5. There is
> actually an issue building perl-5.8.7 for me.

This is a known issue with perl 5.8.7.

The -fno-stack-protector needs to be used to build perl 5.8.7. I'm not
going to add that to CVS, and I've logged the bug with the perl developers
to fix it.

Alan.