ipcop-devel Mailing List for IPCop Firewall

Feature Requests item #1113493, was opened at 2005-01-31 21:58
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=1113493&group_id=40604

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Bikerman (mobilix)
Assigned to: Nobody/Anonymous (nobody)
Summary: Xpeed X400 ADSL PCI

Initial Comment:
Hello

Is it possible to get this modem to work in Ipcop ??

I think I found a linux driver at this page:
http://sandra.firenze.net/linuxpppatm.html
But I can't read it.. :(

I would do it my self, but I have no idear how to :o)

If it can help, the chip on the modem is:

Xpeed chip: XP201-005
ITeX chip: 90135F

Would be nice if I could drop my router alltogether

/Dennis

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

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

Feature Requests item #1113440, was opened at 2005-01-31 14:46
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=1113440&group_id=40604

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Scott Duensing (sduensin)
Assigned to: Nobody/Anonymous (nobody)
Summary: No-IP+ Domains not supported

Initial Comment:
Users with No-IP+ domains are unable to update their
domain's IP address.  For example, my No-IP+ domain
"jaegertech.com" has no hostname, which is not a valid
entry for dynamic DNS in IPCop.  The hostname entry
should be optional for No-IP+ users.


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

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

Feature Requests item #1113435, was opened at 2005-01-31 14:44
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=1113435&group_id=40604

Category: Interface Improvements (example)
Group: None
Status: Open
Priority: 5
Submitted By: Scott Duensing (sduensin)
Assigned to: Nobody/Anonymous (nobody)
Summary: No-IP Groups not supported

Initial Comment:
When configuring a group of addresses for No-IP, there
is no way to specify a No-IP group name instead of a
hostname.  In /var/ipcop/ddns/noipsettings, HOSTNAME=
should be empty and GROUP= should specify the group of
hosts to update.

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

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

Hi,

Mailing list is great but I wanted it to be part of firewall=20
functionality or preferably a standalone script to run from cron.

Reason for  this is that I am writing an SMS gateway and i wanted it to=20
SMS me when new updates are out.

Serg

Franck Bourdonnec wrote:

>Le Lundi 31 Janvier 2005 10:29, Serg Belokamen a =E9crit :
> =20
>
>>Hi All,
>>
>>I was thinking of writing a Perl script that would check for updates (h=
ack
>>an existing copy of the code) and send an email to a nominated email
>>account.
>>   =20
>>
>
>The mailing list is doing this.
>
>Choose one here:
>https://sourceforge.net/mail/?group_id=3D40604
>
>Franck
>
>
>
> =20
>

Hi All, 

Weh IPCop has new updates available, users can see that from the web UI. 
However on a home network 
I dont generally check my firewall every day, but would like to know ASAP when
new updates are available for download.

I was thinking of writing a Perl script that would check for updates (hack an
existing copy of the code) and send an email to a nominated email account. 

Before I start working on this, I would like to know if somebody has made this
in the past, etc.  

   Cheers, 
       Serg

Hi,

It seems that running dhcp.cgi and hosts.cgi is strange under
"speedycgi".

I do not have it installed yet.

Eric is the first one seeing this problem.
Can somebody else confirms that Eric is not alone (in the dark ;-) ) ?

I have read carrefully the code and not seen any global variable
that could maintain a value between successive calls.

Maybe an enormous thing that I can't see. So , help needed until
I run an uptated ipcop to check 'speedy'.


Franck

Franck Bourdonnec wrote:
> Le Dimanche 30 Janvier 2005 18:22, Eric Oberlander a écrit :
> 
>>Hi Franck
>>
>>You're right. hosts.cgi works OK without the 'speedy -- -gcgi'
>>
>>I presume speedycgi is caching variables that break the current interface,
>>although that's just a guess.
>>
>>FYI, when I try replacing 'speedy -- -gcgi' with 'perl -w' in dhcp.cgi I
>>get errors of the 'Invalid MAC address' type when I try to add a fixed
>>lease.
>>
> 
> 
> 
> Enter them under his form:
> 11:11:11:11:11:01
Actually unless someone has broken the code, the routine that validated 
MAC addresses allowed you to enter it as 11:11:11:11:11:01 or 
11-11-11-11-11-01 and would store it as 11:11:11:11:11:01 in the 
settings file.
There was a replacement routine that swapped the -'s to :'s
This was included as a nicety for windows users who are not used to *nix 
style mac addresses.

One of the nice things about Ipcop is how easy it is for anyone to use 
it and little things like the - replacement in the MAC address goes a 
long way in a new user not being frustrated by *nixisms.

And no I am not a pro windows user, I am just realistic about the market 
  that we all work/live in - Windows has a lot of market share and a lot 
of sysadmins that are used to the "windows" way of doing things.

Darren

Le Dimanche 30 Janvier 2005 18:22, Eric Oberlander a =E9crit :
> Hi Franck
>
> You're right. hosts.cgi works OK without the 'speedy -- -gcgi'
>
> I presume speedycgi is caching variables that break the current interface,
> although that's just a guess.
>
> FYI, when I try replacing 'speedy -- -gcgi' with 'perl -w' in dhcp.cgi I
> get errors of the 'Invalid MAC address' type when I try to add a fixed
> lease.
>


Enter them under his form:
11:11:11:11:11:01

Does somebody else have seen problem with   'speedycgi' ??


=46ranck
=20

Sorry the fcdslsl-errors are caused by me/a corrupt
fcdslsl-suse8.2-03.11.02.tar.gz file.

My build proceed now.

Achim


> 1)
> Had an issue in make.sh will building.

> This was not working on my machine*:
>   KVER=`grep --max-count=1 VER lfs/linux | awk '{ print $3 }'`

> Option "--max-count" is not available.

> but this is working:
>   KVER=`grep --regexp=^VER lfs/linux | awk '{ print $3 }'`


> 2)
> In lfs/fcdslsl a false path:
> DIR_APP    = $(DIR_SRC)/fritz

> should be:
> DIR_APP    = $(DIR_SRC)/fritzsl

> there was only a folder fritzsl so i changed it and build moves on..to
> next error:

> 3)
> Error message from ipcop.log:
> ====================================== Installing fcdslsl-suse8.2-03.11.02 ...
> Install started; saving file list to /usr/src/lsalr ...
> cd /usr/src/fritzsl && patch -Np1 <
> /usr/src/src/patches/fcdslx-irqreturn.patch
> patching file src.drv/defs.h
> Hunk #1 FAILED at 81.
> 1 out of 1 hunk FAILED -- saving rejects to file src.drv/defs.h.rej
> make: *** [/usr/src/log/fcdslsl-suse8.2-03.11.02-smp] Error 1


> What to do next??

> Achim

> * my machine: Debian Woody with upgraded kernel 2.4.26

Ooops, gave the wrong code example should have been domainname, not domain.
Correct code:

if (domainname)
	sprintf(commandstring, "/bin/hostname %s.%s", hostname,domainname);
else
	sprintf(commandstring, "/bin/hostname %s", hostname);

Darren

I was looking at the code misc.c of the setup program and noticed 
something that may be amiss with the hostname setting.

Ipcop allows you to setup a hostname and a domain name, and in 
rc.sysinit, if a domain is specified, the command will set the hostname 
like this:
'hostname host.domain'
whereas, the code in misc.c in the function
int writehostsfiles(void) only writes the hostname and not the domain 
even if it is set.

The current code looks like this:
	sprintf(commandstring, "/bin/hostname %s", hostname);

but probably should look like this:
if (domain)
	sprintf(commandstring, "/bin/hostname %s.%s", hostname,domain);
else
	sprintf(commandstring, "/bin/hostname %s", hostname);

I am assuming that the code was not designed this way and it was an 
oversight by the person who added the domain code to the Ipcop code.
Can anyone confirm this or am I wrong about this?

Note: because of recent problems with CVS on my machine, I surfed the 
CVS tree through sourceforge, and it shows the current version of misc.c 
is 1.6 last updated June 9th, 2004, which only sets hostname and not 
domain name. Previously I have pointed out bugs that had been fixed due 
to a problem with CVS which probably dates back a year or so.

Darren

1)
Had an issue in make.sh will building.

This was not working on my machine*:
  KVER=`grep --max-count=1 VER lfs/linux | awk '{ print $3 }'`

Option "--max-count" is not available.

but this is working:
  KVER=`grep --regexp=^VER lfs/linux | awk '{ print $3 }'`


2)
In lfs/fcdslsl a false path:
DIR_APP    = $(DIR_SRC)/fritz

should be:
DIR_APP    = $(DIR_SRC)/fritzsl

there was only a folder fritzsl so i changed it and build moves on..to
next error:

3)
Error message from ipcop.log:
====================================== Installing fcdslsl-suse8.2-03.11.02 ...
Install started; saving file list to /usr/src/lsalr ...
cd /usr/src/fritzsl && patch -Np1 < /usr/src/src/patches/fcdslx-irqreturn.patch
patching file src.drv/defs.h
Hunk #1 FAILED at 81.
1 out of 1 hunk FAILED -- saving rejects to file src.drv/defs.h.rej
make: *** [/usr/src/log/fcdslsl-suse8.2-03.11.02-smp] Error 1


What to do next??

Achim

* my machine: Debian Woody with upgraded kernel 2.4.26

on 30/1/05 3:37 pm, Franck Bourdonnec at fbo...@ch... wrote:

> Hi,
> 
> I have emptied (size=0) /var/ipcop/main/hosts
> Then go to hosts.cgi page
> 
> Add 6 different line ok, etc/hosts updated
> 
> No problem seen.
> 
> Just replace 'speedy -- -gcgi'   with  'perl -w'
> a beginning of cgi.
> 
> Franck

Hi Franck

You're right. hosts.cgi works OK without the 'speedy -- -gcgi'

I presume speedycgi is caching variables that break the current interface,
although that's just a guess.

FYI, when I try replacing 'speedy -- -gcgi' with 'perl -w' in dhcp.cgi I get
errors of the 'Invalid MAC address' type when I try to add a fixed lease.

I tried this with file version:
# $Id: dhcp.cgi,v 1.14.2.46 2005/01/28 00:51:21 franck78 Exp $

Regards.

Eric

Hello,

I would like to know who update this file and what it is
for ?

Supposed: list of files modified between previous version.
Supposed: manually add file name to this list.

'setup': make adjustements

Who maintain this part of Ipcop ?


Bye
Franck

fr...@fr...(Franck Bourdonnec)  27.01.05 10:42

>Hello,
>this is only my opinion:

>Ipcop without add-on is like windows XP home / XP  pro diff.

>Introducing the ' use strict ' brakes every add-on. This should
>have been reported to 1.5.

>We should stay compatible with existing add-on. Many professional
>environment Ipcop use mail filtering/ antivirus / squidguard /
>blockout etc...

>Today, every add-on can go to trash !

I an add-on an i found that code:

        # Copy header.pl
        open(IN,"/var/ipcop/header.pl");
        open(OUT,">/tmp/header.pl.temp");
        while (<IN>) {
                print OUT $_;
        }
        close(OUT);
        close(IN);

[modify header.pl.temp]

        # Copy the changed files to the originals

        # Copy header.pl
        open(IN,"/tmp/header.pl.temp");
        open(OUT,">/var/ipcop/header.pl");
        while (<IN>) {
                print OUT $_;
        }
        close(OUT);
        close(IN);



No problem?

If "/tmp" happens to be come full header.pl will be lost...
or the space in /var/ipcop/ is not sufficient...


should read that at least (pseudoccode):

        # Copy header.pl
        open(IN,"/var/ipcop/header.pl") or die;
        open(OUT,">/tmp/header.pl.temp") or die;
        while (<IN>) {
                print (OUT $_) or die;
        }
        close(OUT);
        close(IN);

If sizeof(/var/ipcop/header.pl) equ 0 die;
If sizeof(/var/ipcop/header.pl) neq sizeof(/tmp/header.pl.temp" die;

[modify header.pl.temp]

        # Copy the changed files to the originals

        # Copy header.pl
        open(IN,"/tmp/header.pl.temp") or die;
        open(OUT,">/var/ipcop/header.pltmp") or die;
        while (<IN>) {
                print (OUT $_) or die;
        }
        close(OUT);
        close(IN);
If sizeof(/var/ipcop/header.pl) neq sizeof(/tmp/header.pl.temp" die
else move (/var/ipcop/header.pltmp /var/ipcop/header.pl)

Error logging would be more usefull, but so at least
ipcop's config is not left unusable(but maybe not consistent)


Rainer

phil wrote:
<SNIP>

> I HAVE to jump in on this one.
> 
> I too have notice upgrade==broken mods.
> 
> And all I do is iptables blocking.
> 
> ANY Firewall, Should be able to at least dump a current bogon list
> into iptables rules; to nuke bad/wrong cidr's. YES? We don't want
> traffic from them. I won't get into individual IP's that one may want
> to stop "annoying traffic."
> 
> I personally . . pretty much don't care personally about fine grained
> filtering on ads, or spyware.  But malicious cidr's.... that's another
> story. Good thing I have an OLD iso. Yep.
> 
> OTOH, I have to agree that security experts know theri safe coding
> practices or I wouldn't still be with ipcop. I can hack code to bend
> to my needs, but is it safe? I don't know. I ain't an expert. Mods are
> mods.  Creative names for mods are obscurity, wish I knew more about
> perl. But I don't and frankly won't EVER have time to learn to be perl
> master coder. So, I guess what MAY help, would be some ROUGH
> explanation of how new changes work.
> 
> e.g. how source of $xxx works. A rough road map, where it starts, what
> it effects, etc. Then I as a lame hack can find out roughly how it
> works and then work out how to make a mod work WITH it.
> 
> I prolly explained that poorly. Oh well.
> 
> Yes Code things securely. No don't do drastic changes without some
> kind of warning. In comments or SOMEWHERE.
> 
> How about a comment or explanation on operation of $tr ? for example.
> I sort of get it, but I sort of don't.
> 
> I am just brainstorming... not flaming.

Understood, but almost every upgrade of Ipcop has broken the addons. It 
is almost expected. The framework that the previous post spoke of has 
been approved for version 1.5 so that addons can survive upgrades, etc.
Although, there will still be addons that fail just because of updates 
to core libraries.

However, all that being said, it is still the responsibility of the 
addon creator/maintainer to test and correct for each new version of 
Ipcop. And you cannot realistically ask the Ipcop developers to take 
into account every addon when making a decision to make a change or 
improvement to Ipcop.

As for posting notice - it has been posted - it is called the Ipcop 
Developers List, and if you are an addon maintainer, you better be 
taking a look at that once in a while to see what is going on. Also, the 
change log is posted and shipped with each upgrade. What more do you 
want the developers to do?

Everytime the developers upgrade a component for security, there is a 
chance that it will break someones addon somewhere. In fact many times 
it breaks things right in Ipcop, and the developers have to struggle 
with fixing that as well.

Remember that the developers are volunteers, and their focus is Ipcop - 
plain vanilla Ipcop. While they do want to work with the community and 
often will help with recommendations on how to fix broken addons, their 
primary focus remains Ipcop with no addons.

This is not meant to be a harsh email or pick on the addon developers, 
this kind of thing happens in all software projects - hey Windows 
Service Pack 2 for XP was a prime example (not that I'm relating Ipcop 
in anyway to microsoft). At the IT company I work for, we maintain 
modifications to commercial products on Midrange systems, everytime the 
client buys an upgrade to their accounting package, we have to go 
through the source code and change our code so it still works. That 
means reading the changelog and seeing if their changes impact our 
changes. Nothing different going on here with Ipcop and the addon 
developers.

Darren

Le Samedi 29 Janvier 2005 18:45, Eric Oberlander a =E9crit :
> Hi
>
> Can anyone help track down a bug in hosts.cgi, in the latest version from
> CVS?
>
> Changes in the web page aren't being saved to the underlying config and
> settings files in a consistent fashion.
>
> I suspect that the problem lies within the file in the 'sortcurrent'
> subroutine, or the 'bymysort' subroutine that it calls... Tests indicate
> that some of the variables referenced in the 'bymysort' subroutine aren't
> available to it any more. I presume the code cleanup may be involved.
>
> However, I'm no perl expert, so I'm throwing this open to the floor...
>

Ok I take a look on it.


=46ranck

Hi

Can anyone help track down a bug in hosts.cgi, in the latest version from
CVS?

Changes in the web page aren't being saved to the underlying config and
settings files in a consistent fashion.

I suspect that the problem lies within the file in the 'sortcurrent'
subroutine, or the 'bymysort' subroutine that it calls... Tests indicate
that some of the variables referenced in the 'bymysort' subroutine aren't
available to it any more. I presume the code cleanup may be involved.

However, I'm no perl expert, so I'm throwing this open to the floor...

Thanks.

Eric

Hi

Can anyone help track down a bug in dhcp.cgi, in the latest version from
CVS?

Changes in the web page aren't being saved to the underlying config and
settings files in a consistent fashion.

When you add a fixed lease, sometimes it appears in
/var/ipcop/dhcp/fixleases, sometimes it doesn't.

Eric

PS I've also just found a similar problem in hosts.cgi
Perhaps it's the record sorting that's causing the trouble?

Hi

I just ran the perfTest.sh against my development box* running v1.4.2, then
installed v.1.4.3 from a homebuilt iso, and ran the tests again.

Results were:

v1.4.2
real   1m0.454s
user   0m2.253s
sys    0m0.339s

v1.4.3
real    23.228s
user     2.180s
sys      0.302s

After the first run, the times for v1.4.3 dropped to:

v1.4.3
real    19.192s
user     2.217s
sys      0.256s

So I think I can claim a performance increase of between 2.5 and 3 times
previous version (250% to 300% improvement, in marketing terms).

Well done Mark!

Eric

* Development box has an AMD K6-2 500MHz processor in a Jetway 531CF
motherboard, 192Mb of RAM, and a Seagate ST320014A 20Gb harddrive.

On 27 Jan 2005 at 19:46, Gilles Espinasse wrote:

> It is a move in the good direction. This will improve add-on quality
> and security. We have to warn the add-on maintainers, the first testers
> and in the update. 

Agree 100% with this.  
--
Angus Scott-Fleming
GeoApps, Tucson, Arizona
1-520-290-5038 / fax 1-208-248-3124
+-----------------------------------+

Hello Alf-Ivar,

Friday, January 28, 2005, 7:41:30 AM, you wrote:

> Franck Bourdonnec <fr...@fr...> writes:

>> Hello,
>> this is only my opinion:
>>
>> Ipcop without add-on is like windows XP home / XP  pro diff.
>>
>> Introducing the ' use strict ' brakes every add-on.

> Every?  IMHO a Perl program that brakes from "use strict" should not
> be running on a firewall, ie. if some Perl software now ("use strict"
> was introduced in Perl 5, so only Perl 4 programs should not have it,
> IMNSHO) does not use this fine thing I would rather not use the
> software on something that is supposed to be secure.

I HAVE to jump in on this one.

I too have notice upgrade==broken mods.

And all I do is iptables blocking.

ANY Firewall, Should be able to at least dump a current bogon list
into iptables rules; to nuke bad/wrong cidr's. YES? We don't want
traffic from them. I won't get into individual IP's that one may want
to stop "annoying traffic."

I personally . . pretty much don't care personally about fine grained
filtering on ads, or spyware.  But malicious cidr's.... that's another
story. Good thing I have an OLD iso. Yep.

OTOH, I have to agree that security experts know theri safe coding
practices or I wouldn't still be with ipcop. I can hack code to bend
to my needs, but is it safe? I don't know. I ain't an expert. Mods are
mods.  Creative names for mods are obscurity, wish I knew more about
perl. But I don't and frankly won't EVER have time to learn to be perl
master coder. So, I guess what MAY help, would be some ROUGH
explanation of how new changes work.

e.g. how source of $xxx works. A rough road map, where it starts, what
it effects, etc. Then I as a lame hack can find out roughly how it
works and then work out how to make a mod work WITH it.

I prolly explained that poorly. Oh well.

Yes Code things securely. No don't do drastic changes without some
kind of warning. In comments or SOMEWHERE.

How about a comment or explanation on operation of $tr ? for example.
I sort of get it, but I sort of don't.

I am just brainstorming... not flaming.

love.
peace.

-- 
Best regards,
 phil                            mailto:ph...@os...

> We must advertise all add-on writers. And it won't be easy because
> now, the guy must have a new ipcop/beta plus maintain during a certain
> time version pre 1.4.3 and 1.4.3. And when this will be done : 1.5
> with new incompatibility (maybe).
> Or ipcop must include definitly some of them...?
>
> Maybe jump to 1.5 to mark clearly the break ?

Perhaps one way to handle add-ons (not in this version, obviously) and their fragility with regards to IPCop updates is to have the IPCop web site be a plug-in framework where each add-on/plug-in is a system call that generates the HTML to fit within the IPCop web page HTML.  This would be similar to making a web service call and dumping the output into an HTML stream.  This would allow IPCop to change however it wanted (almost) and not break the add-ons.  As for the language strings, a cgi wrapper around the language files would allow the add-ons to generate/keep their own subset in whatever source code language the add-on developer uses.  This type of mechanism would split the dependency of the add-on on the IPCop web framework and allow both to change independant of the other.

--
Tim Butterfield
http://www.timbutterfield.com/

Le Vendredi 28 Janvier 2005 19:52, Mark Wormgoor a =E9crit :
> Hi,
>
> I hadn't realised that about the addons.  I think we can remove strict
> from the header.pl, general-functions.pl and include lang.pl and
> general.pl from header.pl, which should make all the addons work again
> (I think).
>
> It won't matter for the cgi's, since a file will be required only once
> and they still have the 'use strict' on them.
>
> (Above is completely untested and may not be true)
>
> Kind regards,
>
> Mark

If you remove strict (or Package?) then, normal ipcop's cgi=20
become mad !

Every call to a function must have "General::" added.


A good perl program might correct automatically this ?


=46ranck

Le Vendredi 28 Janvier 2005 19:46, vous avez =E9crit :
> Hi,
> I have no idea how you got permission denied on /var/ipcop/certs.  I
> have checked the code, my local build and my test machine and all have
> this, which is correct:
> root:/# ls -al /var/ipcop/certs/
> drwxr-xr-x   2 nobody nobody 4096 Jan 28 14:35 ..
> -rw-r--r--   1 nobody nobody    0 Jan 28 14:35 index.txt
> -rw-r--r--   1 nobody nobody    3 Jan 28 14:35 serial
>
> Kind regards,
>
> Mark

My fault ! The script made to replace 'CONFIG_ROOT' and restore
permissions (after big cvs update) did it. Need to be corrected!


Bye bye

=46ranck