ipcop-devel Mailing List for IPCop Firewall

----- Original Message ----- 
From: <rs...@be...>
To: <ipc...@li...>
Sent: Thursday, May 24, 2007 5:28 PM
Subject: [IPCop-devel] Possible Bug???


> Hello all,
>
> I am running 1.4.15 with red/green/orange/blue interfaces with snort
enabled
> on red and green.  I have noticed that after scheduled reboots snort dies
on
> the red interface.  I have the reboot scheduled for 3AM so I am not sure
if
> it is not coming up at the reboot or fails shortly after.  If I go to the
> shutdown tab and reboot everything runs fine until the next scheduled
> reboot.  This has been a consistent behavior.
>
> The machine should be more than capable of handling snort on 2 interfaces
in
> my small home network.  The machine is a Dell Optiplex GX260 with a 2.4Ghz
> processor with 1Gb of RAM.  Memory usage pretty much stays around 25%.
>
> I didn't have a lot of time this morning to thoroughly go through the logs
but from
> what I was able to go through I didn't notice anything out of the
ordinary.
>
Yes there is bugs.
I find during tests one bug in snort-2.6.1.3 (and similary in 2.6.1.5) and
others in the way we restart snort.

Snort need to be restarted when rules are updated and or that the IP change
on red interface and less frequently when network is reconfigured.

After SIGTERM is send to an instance running at one interface, this instance
will terminate only if a
traffic flow to that interface. In case no traffic is send (this is what I
have tested) or received (not tested), this instance wait.
So the original instance may not terminate and not release the corresponding
pid lock.

As we have previously not done anything special in our code to manage an
instance that does not terminate, a new instance will start on that same
interface and fail to start because of the remaining pid lock.
When data is send (and maybe received) on that interface, the original
instance will terminate and snort is no more running on that interface.
Not what is intended...

It is unlikly that RED interface does not receive Internet garbage unless a
router/firewall is already cleaning that way.

A new sort of attack : deny of service on snort by silent during restart ;-)

Looking at our code I find that during boot we start snort on red interface
twice.
That's not so good too, related to the time to start and the possibility to
hit this 'silent' bug.

First time,
rc.sysinit
=>rc.network
=>rc.netaddress.up
=>rc.red start ((if autoconnect=on)
=>rc.updatered

Second time
rc.sysinit
=> restartsnort red blue orange green

I will remove that second call in restartsnort red, unless somebody explain
why it is needed.
The first instance has even not totally finished to start before to receive
SIGTERM.

Gilles

Bugs item #1728880, was opened at 2007-05-31 13:22
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=1728880&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: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Egon Fernolend (egonf)
Assigned to: Nobody/Anonymous (nobody)
Summary: ddns.cgi: comma in password

Initial Comment:
ddns.cgi does not check the password entered by the user 
if the password-string contains a comma "," 
but is writing the values(hostname,domain,password,...)
to "ddns/config" as a comma separated list.

greetings 
Egon

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

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

In message <E1H...@sc...>, 
SourceForge.net <no...@so...> wrote
> my IPCOP is the first intellegent stop for my wireless clients ... if 
>I could use its cached DNS services that it already delivers to GREEN,
[...]
>I did do some reading up before I posted this, but if there are 
>existing solutions, please advise.

To achieve this, just set the Primary DNS server address in Blue 
Interface DHCP settings to be equal to the address of the green port.

-- 
Bob Evans

Feature Requests item #1727929, was opened at 2007-05-29 23:34
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=1727929&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: minus35 (errtjie)
Assigned to: Nobody/Anonymous (nobody)
Summary: DNS on BLUE

Initial Comment:
Dear father Christmas,

I would like a DNS service on BLUE option. 

For 2 main reasons: my IPCOP is the first intellegent stop for my wireless clients ... if I could use its cached DNS services that it already delivers to GREEN, I can save small bandwidth, offer quicker DNS therefore snappier browsing, not have to use my upstream ISP DNS, which is sometimes problematic (also my ADSL modem simply passes up DNS requests to the problematic ISP)

I wanted a second GREEN subnet, and I see there are other requests for "multiple green" facilities. Whilst adding a DNS option does not make GREEN as funtional as BLUE, it certainly makes it a very good second choice. And ideal for dumb client configurations with just one IP number.

I did do some reading up before I posted this, but if there are existing solutions, please advise.

Fantastic product. Thanks guys.



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

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

On Tuesday 29 May 2007 10:06:50 am Ivan Kabaivanov wrote:
> On Monday 28 May 2007 18:13, David W Studeman wrote:
> > On Monday 28 May 2007 04:58:43 am Gilles Espinasse wrote:
> > > ----- Original Message -----
> > > From: "David W Studeman" <avi...@ai...>
> > > To: <ipc...@li...>
> > > Sent: Monday, May 28, 2007 3:03 AM
> > > Subject: Re: [IPCop-devel] Toolchain for SVN build.
> > >
> > > > On Sunday 27 May 2007 03:40:12 pm Gilles Espinasse wrote:
> > > > > ----- Original Message -----
> > > > > From: "David W Studeman" <avi...@ai...>
> > > > > To: <ipc...@li...>
> > > > > Sent: Monday, May 28, 2007 12:31 AM
> > > > > Subject: [IPCop-devel] Toolchain for SVN build.
> > > >
> > > > I'm using OpenSuSE 10.2 which is a 64 bit distro but has 32 bit
> > >
> > > development
> > >
> > > > tools included. So far I get two errors but can't make sense out of
> > > > them.
> > >
> > > I'm
> > >
> > > > not sure if I'm supposed to be able to attach a log here or not but
> > > > I'll
> > >
> > > try.
> > >
> > > messages of more than 40 kb are not allowed but as the message was
> > > directly addressed to me, this was not a problem for me.
> > > It look there is some different issues related to 64 to 32 compilation.
> > > Even at the first distcc compilation, there is those sort of warnings
> > > that are not present on a 32 bit:
> > > src/climasq.c: In function 'dcc_support_masquerade':
> > > src/climasq.c:77: warning: passing argument 2 of 'dcc_abspath' with
> > > different width due to prototype
> > >
> > > Concerning gcc, the issue is indicated by this warning message
> > > /tools_i486/i686-pc-linux-gnu/bin/ld: warning: i386:x86-64 architecture
> > > of input file
> > > `../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o)' is
> > > incompatible with i386 output
> > >
> > > Then it segfault
> > > build/genmodes -h > tmp-modes.h
> > > /bin/sh: line 1: 26930 Segmentation fault      build/genmodes -h
> > >
> > > >tmp-modes.h
> > >
> > > We may need to borrow some patches and instructions from CLFS that
> > > could solve your issue with gcc :
> > > http://svn.cross-lfs.org/svn/repos/cross-lfs/trunk/patches/gcc-4.2.0-cr
> > >os s_ search_paths-1.patch
> > > http://svn.cross-lfs.org/svn/repos/cross-lfs/trunk/patches/binutils-2.1
> > >7- ge nscripts_multilib-1.patch
> > >
> > > Ivan, what do you mind of those patches?
> > > There was a version for gcc-4.1.2 before the upgrade to gcc-4.2.0
> > >
> > > Gilles
> >
> > Thanks for looking into this Gilles. I hope I'm not eating up too much of
> > your time on this. I did notice that it now doesn't matter whether I use
> > a 64 bit native shell or a 32 bit shell on my system for the svn trunk
> > version, the make.sh is mapping the architecture to 486 which is a nice
> > touch. With the 1.4 branch I have to go 32 bit or it looks for a 64 bit
> > toolchain and thinks it is going to compile a 64 bit version of IPCop. I
> > take it that eventually this branch will go into alpha, beta and then
> > release as 2.0?
>
> Dave,
>
> I'm not familiar with 64bit on intel/amd -- is just the kernel 64 bit, or
> are both the kernel *and* userland 64bit?
>
> We may have to do what we do for sparc -- force a 32bit userland with 64bit
> kernel.  How do you start a 32bit shell in OpenSUSE?  Is that SUSE specific
> or is it a standard package for all ia_64 distros?
>
> IvanK.
>
Actually, OpenSuSE 64 bit also has 32 bit compatibility and the full gamut of 
32 bit development libraries as well but yes, the userland is 64 bit as well 
but 32 bit programs run just as they would on a 32 bit machine. I do have the 
option of opening up a 32 bit shell which is how I have been compiling custom 
builds of 1.4 for a few years now. In the latest SVN trunk which calls itself 
1.9, the make.sh already tells the system to do a 486 build so I get about as 
far before my error on gcc in both a 64 bit and 32 bit shell. In a nutshell, 
I can run both 32 and 64 bit programs and compile both 32 and 64 bit 
programs. 


Dave

On Monday 28 May 2007 18:13, David W Studeman wrote:
> On Monday 28 May 2007 04:58:43 am Gilles Espinasse wrote:
> > ----- Original Message -----
> > From: "David W Studeman" <avi...@ai...>
> > To: <ipc...@li...>
> > Sent: Monday, May 28, 2007 3:03 AM
> > Subject: Re: [IPCop-devel] Toolchain for SVN build.
> >
> > > On Sunday 27 May 2007 03:40:12 pm Gilles Espinasse wrote:
> > > > ----- Original Message -----
> > > > From: "David W Studeman" <avi...@ai...>
> > > > To: <ipc...@li...>
> > > > Sent: Monday, May 28, 2007 12:31 AM
> > > > Subject: [IPCop-devel] Toolchain for SVN build.
> > >
> > > I'm using OpenSuSE 10.2 which is a 64 bit distro but has 32 bit
> >
> > development
> >
> > > tools included. So far I get two errors but can't make sense out of
> > > them.
> >
> > I'm
> >
> > > not sure if I'm supposed to be able to attach a log here or not but
> > > I'll
> >
> > try.
> >
> > messages of more than 40 kb are not allowed but as the message was
> > directly addressed to me, this was not a problem for me.
> > It look there is some different issues related to 64 to 32 compilation.
> > Even at the first distcc compilation, there is those sort of warnings
> > that are not present on a 32 bit:
> > src/climasq.c: In function 'dcc_support_masquerade':
> > src/climasq.c:77: warning: passing argument 2 of 'dcc_abspath' with
> > different width due to prototype
> >
> > Concerning gcc, the issue is indicated by this warning message
> > /tools_i486/i686-pc-linux-gnu/bin/ld: warning: i386:x86-64 architecture
> > of input file
> > `../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o)' is
> > incompatible with i386 output
> >
> > Then it segfault
> > build/genmodes -h > tmp-modes.h
> > /bin/sh: line 1: 26930 Segmentation fault      build/genmodes -h
> >
> > >tmp-modes.h
> >
> > We may need to borrow some patches and instructions from CLFS that could
> > solve your issue with gcc :
> > http://svn.cross-lfs.org/svn/repos/cross-lfs/trunk/patches/gcc-4.2.0-cros
> >s_ search_paths-1.patch
> > http://svn.cross-lfs.org/svn/repos/cross-lfs/trunk/patches/binutils-2.17-
> >ge nscripts_multilib-1.patch
> >
> > Ivan, what do you mind of those patches?
> > There was a version for gcc-4.1.2 before the upgrade to gcc-4.2.0
> >
> > Gilles
>
> Thanks for looking into this Gilles. I hope I'm not eating up too much of
> your time on this. I did notice that it now doesn't matter whether I use a
> 64 bit native shell or a 32 bit shell on my system for the svn trunk
> version, the make.sh is mapping the architecture to 486 which is a nice
> touch. With the 1.4 branch I have to go 32 bit or it looks for a 64 bit
> toolchain and thinks it is going to compile a 64 bit version of IPCop. I
> take it that eventually this branch will go into alpha, beta and then
> release as 2.0?
>

Dave,

I'm not familiar with 64bit on intel/amd -- is just the kernel 64 bit, or are 
both the kernel *and* userland 64bit?

We may have to do what we do for sparc -- force a 32bit userland with 64bit 
kernel.  How do you start a 32bit shell in OpenSUSE?  Is that SUSE specific 
or is it a standard package for all ia_64 distros?

IvanK.

Feature Requests item #1727477, was opened at 2007-05-29 08:56
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=1727477&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: Grebbler (grebbler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Port Forwarding Groups

Initial Comment:
Would it be possible to have the ability to control Port Forwarding in groups?  

EX: A game I have needs 19 port entries that I have to enable each time I get an urge to play it.  I am either inclined to leave them open which makes me uneasy or not play the game (which makes me grouchy).   So being able to use one checkbox to enable a predefined port group would be great.  Also do the collision check for enabled groups only and displaying the group comment or ID string in the conflict error would be fine.  Another cool refinement to this would be ability to change the destination IP for a group.  ie: Wife or kid on my main rig and I need to change the port forwards to the basement rig for a bit.  

Failing that, changing the web admin page so I could tick off the ports I want enabled/disabled then hit APPLY to set them in one go rather than the "Click, wait for reset, Click, wait for reset.." thing would be much better.

Thx.

Greb

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

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

Feature Requests item #1727421, was opened at 2007-05-29 15:01
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=1727421&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: icarus-il (yanivf)
Assigned to: Nobody/Anonymous (nobody)
Summary: DNS forwarding

Initial Comment:
it would be nice to have DNS FORWARDING at ipcop.

example:
my domain name is example.com all my computers get this name as dns sufix... and now i install some test domain in my network new-example.com i can't configure ipcop to forward all *.new-example.com to a specific dns server.

thanks


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

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

Hi Gilles,

Thanks for helping me.

I finally succeeded in getting the Wanpipe drivers to work.  I did this 
by modifying the IPCop build environment so that the Wanpipe drivers and 
utilities would compile during the standard IPcop build process.  Yes, I 
know they compiled before, but they didn't work, at least not on the 
S514 and A101 cards I have on hand.

I feel these modifications, or a variation, should be included in the 
standard IPcop.  I would be very happy not to have to go through all of 
this again.  ;-)

I tested PPP and CHDLC protocols between two IPcops using a T1 crossover 
cable.  I also tested that the ATM and Frame Relay drivers would load 
without error upon "wanrouter start"...they should work also.

I primarily modified the lfs/wanpipe file (attached).  I modified it to 
use the latest stable version of the Wanpipe drivers (2.3.4-9) and to 
compile all _default_ (option 1) protocols, rather than the selected few 
before.  I also slightly modified the ROOTFILES.i386 so as not to 
include one unimportant utility I couldn't get to compile.

Once I installed IPcop from the new .iso:

I used 'wancfg' to configure the interfaces.

I modified rc.local to 'wanrouter start' and 'route add' the static 
routes over the T1 (in my case) interfaces.

I modified rc.firewall.local to add the 'iptables' firewall commands to 
accept all traffic on the trusted T1 interfaces.

I did not attempt any other scripting or web interfacing as I am no 
programmer and I don't have those abilities.  It would be great to be 
able to use a Wanpipe interface as a Red or second Green interface...

I also wrote a simple howto and posted it on my web site.

http://www.sonoracomm.com/index.php?option=com_content&task=view&id=188

I hope this helps.  If I can be of more assistance, please e-mail me at 
the address below.

Thanks everyone for this great project!

G

-- 

=============================
Gene Cooper
Sonora Communications, Inc.
936 W. Prince Road
Tucson, AZ  85705

(520) 293-8461 x101
(520) 888-4060 fax

gc...@so...

On Monday 28 May 2007 04:58:43 am Gilles Espinasse wrote:
> ----- Original Message -----
> From: "David W Studeman" <avi...@ai...>
> To: <ipc...@li...>
> Sent: Monday, May 28, 2007 3:03 AM
> Subject: Re: [IPCop-devel] Toolchain for SVN build.
>
> > On Sunday 27 May 2007 03:40:12 pm Gilles Espinasse wrote:
> > > ----- Original Message -----
> > > From: "David W Studeman" <avi...@ai...>
> > > To: <ipc...@li...>
> > > Sent: Monday, May 28, 2007 12:31 AM
> > > Subject: [IPCop-devel] Toolchain for SVN build.
> >
> > I'm using OpenSuSE 10.2 which is a 64 bit distro but has 32 bit
>
> development
>
> > tools included. So far I get two errors but can't make sense out of them.
>
> I'm
>
> > not sure if I'm supposed to be able to attach a log here or not but I'll
>
> try.
>
> messages of more than 40 kb are not allowed but as the message was directly
> addressed to me, this was not a problem for me.
> It look there is some different issues related to 64 to 32 compilation.
> Even at the first distcc compilation, there is those sort of warnings that
> are not present on a 32 bit:
> src/climasq.c: In function 'dcc_support_masquerade':
> src/climasq.c:77: warning: passing argument 2 of 'dcc_abspath' with
> different width due to prototype
>
> Concerning gcc, the issue is indicated by this warning message
> /tools_i486/i686-pc-linux-gnu/bin/ld: warning: i386:x86-64 architecture of
> input file `../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o)' is
> incompatible with i386 output
>
> Then it segfault
> build/genmodes -h > tmp-modes.h
> /bin/sh: line 1: 26930 Segmentation fault      build/genmodes -h
>
> >tmp-modes.h
>
> We may need to borrow some patches and instructions from CLFS that could
> solve your issue with gcc :
> http://svn.cross-lfs.org/svn/repos/cross-lfs/trunk/patches/gcc-4.2.0-cross_
>search_paths-1.patch
> http://svn.cross-lfs.org/svn/repos/cross-lfs/trunk/patches/binutils-2.17-ge
>nscripts_multilib-1.patch
>
> Ivan, what do you mind of those patches?
> There was a version for gcc-4.1.2 before the upgrade to gcc-4.2.0
>
> Gilles
>


Thanks for looking into this Gilles. I hope I'm not eating up too much of your 
time on this. I did notice that it now doesn't matter whether I use a 64 bit 
native shell or a 32 bit shell on my system for the svn trunk version, the 
make.sh is mapping the architecture to 486 which is a nice touch. With the 
1.4 branch I have to go 32 bit or it looks for a 64 bit toolchain and thinks 
it is going to compile a 64 bit version of IPCop. I take it that eventually 
this branch will go into alpha, beta and then release as 2.0?


Dave

Bugs item #1727132, was opened at 2007-05-28 17:55
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=1727132&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: Web Proxy
Group: 1.4.15
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: hescominsoon (hescominsoon)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unable to use transprent proxy on blue

Initial Comment:
if i use the transparent proxy on the blue network i get the following:

The following error was encountered:

Invalid Request
Some aspect of the HTTP Request is invalid. Possible problems:

Missing or unknown request method
Missing URL
Missing HTTP Identifier (HTTP/1.0)
Request is too large
Content-Length missing for POST or PUT requests
Illegal character in hostname; underscores are not allowed
Your cache administrator is webmaster.



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

Generated Sun, 13 May 2007 22:34:30 GMT by stonefirewall.firewall
(squid/2.6.STABLE9)

If i turn the transparent proxy off on blue everything works fine.
Transparent proxy on green works without incident.

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

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

Bugs item #1726908, was opened at 2007-05-28 15:17
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=1726908&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: Documentation
Group: 1.4.15
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Schubi (schubi87)
Assigned to: Harry Goldschmitt (goldharv)
Summary: DHCP fixed hostname

Initial Comment:
there is no description for the field "Hostname or FQDN:"   ("Current fixed leases"/"Add a new fixed lease")
i guessed to a add a new entry in the hostname table. As if I'd use the edit host page. 
But this didn't work. So I guess that I missunderstood the meaning of the field.


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

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

----- Original Message ----- 
From: "David W Studeman" <avi...@ai...>
To: <ipc...@li...>
Sent: Monday, May 28, 2007 3:03 AM
Subject: Re: [IPCop-devel] Toolchain for SVN build.


> On Sunday 27 May 2007 03:40:12 pm Gilles Espinasse wrote:
> > ----- Original Message -----
> > From: "David W Studeman" <avi...@ai...>
> > To: <ipc...@li...>
> > Sent: Monday, May 28, 2007 12:31 AM
> > Subject: [IPCop-devel] Toolchain for SVN build.
> >
>
> I'm using OpenSuSE 10.2 which is a 64 bit distro but has 32 bit
development
> tools included. So far I get two errors but can't make sense out of them.
I'm
> not sure if I'm supposed to be able to attach a log here or not but I'll
try.
>
messages of more than 40 kb are not allowed but as the message was directly
addressed to me, this was not a problem for me.
It look there is some different issues related to 64 to 32 compilation.
Even at the first distcc compilation, there is those sort of warnings that
are not present on a 32 bit:
src/climasq.c: In function 'dcc_support_masquerade':
src/climasq.c:77: warning: passing argument 2 of 'dcc_abspath' with
different width due to prototype

Concerning gcc, the issue is indicated by this warning message
/tools_i486/i686-pc-linux-gnu/bin/ld: warning: i386:x86-64 architecture of
input file `../build-i686-pc-linux-gnu/libiberty/libiberty.a(hashtab.o)' is
incompatible with i386 output

Then it segfault
build/genmodes -h > tmp-modes.h
/bin/sh: line 1: 26930 Segmentation fault      build/genmodes -h
>tmp-modes.h

We may need to borrow some patches and instructions from CLFS that could
solve your issue with gcc :
http://svn.cross-lfs.org/svn/repos/cross-lfs/trunk/patches/gcc-4.2.0-cross_search_paths-1.patch
http://svn.cross-lfs.org/svn/repos/cross-lfs/trunk/patches/binutils-2.17-genscripts_multilib-1.patch

Ivan, what do you mind of those patches?
There was a version for gcc-4.1.2 before the upgrade to gcc-4.2.0

Gilles

Gilles

Hello Sen,

Monday, May 28, 2007, 1:24:28 AM, you wrote:

SHT> Hi Chris,

SHT> It works! Yes, the kernel should be 2.4.34.
SHT> If it is possible, please tell me how did you compile the cipe1.6 for ipcop?
SHT> Or any documentation shows how to do that, if the kernel of the ipcop gets
SHT> change on next version, I know what to do with it.
SHT> Otherwise, I need to either rely on someone to provide me a compiled version
SHT> like you did this time or stick with the old version of ipcop.
SHT> Certainly, there must be a way to do so.

SHT> Thanks again.

SHT>> -----Original Message-----
SHT>> From: Chris Hemsing [mailto:C.H...@gm...]
SHT>> Sent: Sunday, 27 May 2007 8:04 PM
SHT>> To: Sen Ho Tam
SHT>> Subject: Re: [IPCop-devel] CIPE problem

SHT>> Hello Sen,

SHT>> Friday, May 25, 2007, 7:12:13 AM, you wrote:

SHT>> Find attached cipe 1.6 for ipcop.
SHT>> However note: I've had no chance to test it!
SHT>> Also note: the kernel was 2.4.34 NOT 2.4.32 as you say in your mail.
SHT>> Good luck with it.
SHT>> In case it works, then tell that to the list, so others that may need
SHT>> it know of it.

SHT>> You will want to do a

SHT>> depmod

SHT>> after the install and the try to

SHT>> modprobe cipcb


SHT>> On the long run you should consider openvpn and drop cipe!

SHT>> Cheers,
SHT>> Chris

SHT>>> Hi all,

 

SHT>>> Anyone knows of how to compile a CIPE then copy the compiled cipcb.o
SHT>>> into
SHT>>> the /lib/moduels/version-num/kernel/misc of the IPCOP 1.4.15 machine?

SHT>>> Since the IPCOP does not have the sources and the gcc compiler, I can
SHT>>> not
SHT>>> compile CIPE within the IPCOP.

 

SHT>>> If I compile CIPE in another machine, I can not find the right kernel
SHT>>> version 2.4.32 to match that.

 

SHT>>> Any hints.

 

SHT>>> Regards,

 

 

SHT>>> Sen Ho Tam


Nice, that it works.
To compile, you must do, what has already been answered on the list:
build it from scratch from the sources on some system and then add
cipe.
In case you can't compile/crosscompile ask me again if the
kernel changes.

Again, CIPE has been dead for many years. You should seriously
consider installing openvpn on your remote sites.

Cheers,
Chris

On Sunday 27 May 2007 03:40:12 pm Gilles Espinasse wrote:
> ----- Original Message -----
> From: "David W Studeman" <avi...@ai...>
> To: <ipc...@li...>
> Sent: Monday, May 28, 2007 12:31 AM
> Subject: [IPCop-devel] Toolchain for SVN build.
>
> > Hello all! I decided to grab the head trunk for IPCop which calls itself
>
> 1.9
>
> > now and I cannot get through the gcc portion of building my toolchain
>
> whereas
>
> > I had been able to on 1.4 and what used to be 1.5. Has anyone
> > successfully built this yet? If so, anyplace I can grab the tarball and
> > checksum? I
>
> take
>
> > it that eventually this will be realeased as 2.0 instead of 1.5? SVN sure
>
> is
>
> > easy to update once you have the trunk downloaded.
> >
> > Dave
>
> We are some of us that are able to build until the end where the iso is
> created.
> I have build from gentoo (not up to date actually) and from debian sarge.
> As I rebuild mostly each time the toolchain to verify the build, md5sum
> vary.
> I could upload one toolchain package on sourceforge but I think it's too
> early.
>
> >From what base are you building?
>
> What is the error?
>
> Gilles
>

I'm using OpenSuSE 10.2 which is a 64 bit distro but has 32 bit development 
tools included. So far I get two errors but can't make sense out of them. I'm 
not sure if I'm supposed to be able to attach a log here or not but I'll try.


Dave

----- Original Message ----- 
From: "David W Studeman" <avi...@ai...>
To: <ipc...@li...>
Sent: Monday, May 28, 2007 12:31 AM
Subject: [IPCop-devel] Toolchain for SVN build.


> Hello all! I decided to grab the head trunk for IPCop which calls itself
1.9
> now and I cannot get through the gcc portion of building my toolchain
whereas
> I had been able to on 1.4 and what used to be 1.5. Has anyone successfully
> built this yet? If so, anyplace I can grab the tarball and checksum? I
take
> it that eventually this will be realeased as 2.0 instead of 1.5? SVN sure
is
> easy to update once you have the trunk downloaded.
>
> Dave
>
We are some of us that are able to build until the end where the iso is
created.
I have build from gentoo (not up to date actually) and from debian sarge.
As I rebuild mostly each time the toolchain to verify the build, md5sum
vary.
I could upload one toolchain package on sourceforge but I think it's too
early.

>From what base are you building?
What is the error?

Gilles

 Hello all! I decided to grab the head trunk for IPCop which calls itself 1.9 
now and I cannot get through the gcc portion of building my toolchain whereas 
I had been able to on 1.4 and what used to be 1.5. Has anyone successfully 
built this yet? If so, anyplace I can grab the tarball and checksum? I take 
it that eventually this will be realeased as 2.0 instead of 1.5? SVN sure is 
easy to update once you have the trunk downloaded. 

Dave 

Bob Staaf wrote:

>> -----Original Message-----
>> From: Chris Taylor [mailto:ch...@eq...] 
>>> rs...@be... wrote:
>>> Hello all,

>>> I am running 1.4.15 with red/green/orange/blue interfaces with snort
>>> enabled on red and green.  I have noticed that after scheduled reboots
>>> snort dies on the red interface.  I have the reboot scheduled for 3AM so I
>>> am not sure if it is not coming up at the reboot or fails shortly after.
>>> If I go to the shutdown tab and reboot everything runs fine until the next
>>> scheduled reboot.  This has been a consistent behavior.

>>> The machine should be more than capable of handling snort on 2 interfaces
>>> in my small home network.  The machine is a Dell Optiplex GX260 with a
>>> 2.4Ghz processor with 1Gb of RAM.  Memory usage pretty much stays around
>>> 25%.

>>> I didn't have a lot of time this morning to thoroughly go through the
>>> logs but from what I was able to go through I didn't notice anything out
>>> of the ordinary.

>>> Thanks

>>> Bob

>> Why are you rebooting it nightly?
>> This is linux. Reboots are not necessary in all but the most extreme 
>> cases, except to update the kernel...
>> Logs would be required, along with more detail, before we could begin to 
>> diagnose it.

> Thanks for your reply but I don't believe I said anywhere that I was
> rebooting nightly.

> I intended to follow up with logs this weekend when I have more time.  So
> far this problem is just a tad annoying otherwise I would have made the
> time.

> Thanks again

> Bob

KK. Will be read the logs when they arrive.
For reference, the rebooting nightly was inferred from the mention of
'the reboot scheduled for 3AM' - lacking any other information than this
I (and from what I can see, others) assumed this to be nightly.

Chris

Bob Staaf wrote:

>> -----Original Message-----
>> From: Chris Taylor [mailto:ch...@eq...] 
>>> rs...@be... wrote:
>>> Hello all,

>>> I am running 1.4.15 with red/green/orange/blue interfaces with snort
>>> enabled on red and green.  I have noticed that after scheduled reboots
>>> snort dies on the red interface.  I have the reboot scheduled for 3AM so I
>>> am not sure if it is not coming up at the reboot or fails shortly after.
>>> If I go to the shutdown tab and reboot everything runs fine until the next
>>> scheduled reboot.  This has been a consistent behavior.

>>> The machine should be more than capable of handling snort on 2 interfaces
>>> in my small home network.  The machine is a Dell Optiplex GX260 with a
>>> 2.4Ghz processor with 1Gb of RAM.  Memory usage pretty much stays around
>>> 25%.

>>> I didn't have a lot of time this morning to thoroughly go through the
>>> logs but from what I was able to go through I didn't notice anything out
>>> of the ordinary.

>>> Thanks

>>> Bob

>> Why are you rebooting it nightly?
>> This is linux. Reboots are not necessary in all but the most extreme 
>> cases, except to update the kernel...
>> Logs would be required, along with more detail, before we could begin to 
>> diagnose it.

> Thanks for your reply but I don't believe I said anywhere that I was
> rebooting nightly.

> I intended to follow up with logs this weekend when I have more time.  So
> far this problem is just a tad annoying otherwise I would have made the
> time.

> Thanks again

> Bob

KK. Will be read the logs when they arrive.
For reference, the rebooting nightly was inferred from the mention of
'the reboot scheduled for 3AM' - lacking any other information than this
I (and from what I can see, others) assumed this to be nightly.

Chris

Bob Staaf wrote:

>> -----Original Message-----
>> From: Chris Taylor [mailto:ch...@eq...] 
>>> rs...@be... wrote:
>>> Hello all,

>>> I am running 1.4.15 with red/green/orange/blue interfaces with snort
>>> enabled on red and green.  I have noticed that after scheduled reboots
>>> snort dies on the red interface.  I have the reboot scheduled for 3AM so I
>>> am not sure if it is not coming up at the reboot or fails shortly after.
>>> If I go to the shutdown tab and reboot everything runs fine until the next
>>> scheduled reboot.  This has been a consistent behavior.

>>> The machine should be more than capable of handling snort on 2 interfaces
>>> in my small home network.  The machine is a Dell Optiplex GX260 with a
>>> 2.4Ghz processor with 1Gb of RAM.  Memory usage pretty much stays around
>>> 25%.

>>> I didn't have a lot of time this morning to thoroughly go through the
>>> logs but from what I was able to go through I didn't notice anything out
>>> of the ordinary.

>>> Thanks

>>> Bob

>> Why are you rebooting it nightly?
>> This is linux. Reboots are not necessary in all but the most extreme 
>> cases, except to update the kernel...
>> Logs would be required, along with more detail, before we could begin to 
>> diagnose it.

> Thanks for your reply but I don't believe I said anywhere that I was
> rebooting nightly.

> I intended to follow up with logs this weekend when I have more time.  So
> far this problem is just a tad annoying otherwise I would have made the
> time.

> Thanks again

> Bob

KK. Will be read the logs when they arrive.
For reference, the rebooting nightly was inferred from the mention of
'the reboot scheduled for 3AM' - lacking any other information than this
I (and from what I can see, others) assumed this to be nightly.

Chris

This patch is to add a option to the menu to add IPs that are not on a 
connected to an interface. This is for a ipcop box protecting several 
vlans on a multi vlan switch/router. This would make ipcop more flexible 
for larger environments. I have it running now and it seems to work OK. 
Please consider it for addition to the code line.

Patch File is at:
http://data.unixsage.com/ipcop-1.4.15.zip

Thanks,
John

----- Original Message ----- 
From: <rs...@be...>
To: <ipc...@li...>
Sent: Thursday, May 24, 2007 5:28 PM
Subject: [IPCop-devel] Possible Bug???


> Hello all,
>
> I am running 1.4.15 with red/green/orange/blue interfaces with snort
enabled
> on red and green.  I have noticed that after scheduled reboots snort dies
on
> the red interface.  I have the reboot scheduled for 3AM so I am not sure
if
> it is not coming up at the reboot or fails shortly after.  If I go to the
> shutdown tab and reboot everything runs fine until the next scheduled
> reboot.  This has been a consistent behavior.
>
could be improved now on cvs
Frank has implemented a loop that wait until snort terminate before to
restart snort.
I don't know why the behavior is not the same during shutdown or reboot but
it may be a timing issue related to setting RED link down and up in a
shorter time during reboot than a shutdown and later a start.
I should verify the difference between shutdown and reboot code.
...
Gilles

Bugs item #1725582, was opened at 2007-05-25 08:16
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=1725582&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: Red Network and Auto Link Negotiation Not working

Initial Comment:
The Red interface does not properly negotiate the correct link speed if the opposing end is set to something other than auto by the ISP.

I have seen this with versions 1.4.8-15.  I have used 3c905b/c Intel Ether 100/VE and RTL 8139s nics. I have used both embedded and stand alone nics.

The scenario is as follows. The ISP delivers their device and gets it work there with their test equipment. When they leave the device so happens to be configured for 10mbs half duplex which what I have seen the most but not always. 

You install IP Cop and the internet connection appears to work but when you start looking at the connection statistics you will start to see a number of errors and across many of the error counters and at times the link to the internet will randomly fail. 

I have been able to reproduce this problem easily buy using an older 10mbs hubs and switches.  Thats where I first uncovered the problem while trying to use older stuff for someone.

Is there a way to get the auto negotiation to work properly or have in the UI the ability to adjust the interface settings to suit what the ISP is using for their device? In my case they tend to deliver the devices with 10mpbs half duplex. It has spanned mulitple ISP's in different states with different equipment vendors. 

I normally call the ISP and get their technical support on line and see if they can fix the problem which they can normally do. :-)

Super product and great work. Cudos to everyone.


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

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

>-----Original Message-----
>From: Chris Taylor [mailto:ch...@eq...] 
>>rs...@be... wrote:
>> Hello all,
>> 
>> I am running 1.4.15 with red/green/orange/blue interfaces with snort
>>enabled on red and green.  I have noticed that after scheduled reboots
>>snort dies on the red interface.  I have the reboot scheduled for 3AM so I
>>am not sure if it is not coming up at the reboot or fails shortly after.
>>If I go to the shutdown tab and reboot everything runs fine until the next
>>scheduled reboot.  This has been a consistent behavior.
>> 
>> The machine should be more than capable of handling snort on 2 interfaces
>>in my small home network.  The machine is a Dell Optiplex GX260 with a
>>2.4Ghz processor with 1Gb of RAM.  Memory usage pretty much stays around
>>25%.
>> 
>> I didn't have a lot of time this morning to thoroughly go through the
>>logs but from what I was able to go through I didn't notice anything out
>>of the ordinary.
>> 
>> Thanks
>> 
>> Bob
>> 
>
>Why are you rebooting it nightly?
>This is linux. Reboots are not necessary in all but the most extreme 
>cases, except to update the kernel...
>Logs would be required, along with more detail, before we could begin to 
>diagnose it.

Thanks for your reply but I don't believe I said anywhere that I was
rebooting nightly.

I intended to follow up with logs this weekend when I have more time.  So
far this problem is just a tad annoying otherwise I would have made the
time.

Thanks again

Bob

On Friday 25 May 2007 01:19:01 am Chris Taylor wrote:
> rs...@be... wrote:
> > Hello all,
> >
> > I am running 1.4.15 with red/green/orange/blue interfaces with snort
> > enabled on red and green.  I have noticed that after scheduled reboots
> > snort dies on the red interface.  I have the reboot scheduled for 3AM so
> > I am not sure if it is not coming up at the reboot or fails shortly
> > after.  If I go to the shutdown tab and reboot everything runs fine until
> > the next scheduled reboot.  This has been a consistent behavior.
> >
> > The machine should be more than capable of handling snort on 2 interfaces
> > in my small home network.  The machine is a Dell Optiplex GX260 with a
> > 2.4Ghz processor with 1Gb of RAM.  Memory usage pretty much stays around
> > 25%.
> >
> > I didn't have a lot of time this morning to thoroughly go through the
> > logs but from what I was able to go through I didn't notice anything out
> > of the ordinary.
> >
> > Thanks
> >
> > Bob
>
> Why are you rebooting it nightly?
> This is linux. Reboots are not necessary in all but the most extreme
> cases, except to update the kernel...
> Logs would be required, along with more detail, before we could begin to
> diagnose it.
>
>

I was wondering the same thing. I can't even remember the last time my IPCop 
was rebooted. If you use Squid with a sizeable cache, everytime you reboot, 
all your cached pages that were previously running in memory, now have to be 
sucked back up off the hard drive which is about several hundred times slower 
than retrieving cached pages out of memory. Many people don't realize that 
squid tries to cache as much as it can in memory depending on amount of 
physical memory you have and of course backs it up on the drive as well but 
why keep dumping everything you have ready in memory?

Dave