ipcop-devel Mailing List for IPCop Firewall

Hi

The Language Database now has 975 phrases in it, with only the section on
'VPN stuff' remaining to be added for v1.4.0.

Chinese, Cesky, Dansk, Deutsch, Ellinika, Magyar, Latino and Norsk are
up-to-date, or only have a few phrases missing.

Portugues do Brasil, Portugues, Nederlands, Suomi, Fran=E7ais, Italiano,
Espanol, Svenska and T=FCrk=E7e at the moment have between 100 and 200 phrases
that need to be translated.

If you can help fill in the gaps, please visit http://www.ipcop.org/langs/
You need to be registered on the Twiki to be able to edit the phrases.

If you are interested, you can see what still has to be added to the
database by downloading the latest version of en.pl in CVS, and looking for
the section marked '# VPN stuff', which has about 118 phrases in it.

http://cvs.sourceforge.net/viewcvs.py/ipcop/ipcop/langs/en/cgi-bin/en.pl

Thanks.

Eric

Steve,

>
>>>On Thu, Oct 30, 2003 at 10:46:06PM -0800, Steve Garcia wrote:
>>>
>>>I told him that once I got the firewall up, we'd be able to block his 
>>>classroom from the net during his class.
>>> 
>>>Or maybe using cron.
>>>
>>>  
>>>
>>    
>>
If you just want to block web surfing why not use Squid ACLs. You can 
put times in them so you don't have to use cron. You do have to make 
sure everyone uses the proxy though!

Pete

Hi Steve.
Not sure if this can be done, but blocking by mac address is probably a much better idea if it can be done.
Changing one's ip address to an ip in the range that will work isn't all that had to do if the person has admin privs on the machine their sitting at.

Tommy

On Thu, Oct 30, 2003 at 10:46:06PM -0800, Steve Garcia wrote:
> I'm setting up an IPCop installation to isolate our department, to be 
> implemented over Christmas break.  It will have perhaps 150 or so 
> machines behind it, including a few servers and a bunch of workstations.
> 
> One of the other instructors came to me and asked if I could put a block 
> on his classroom to prevent his students from surfing the net during 
> class.  That classroom is on a single switch -- I could temporarily pull 
> the plug during his class, but that would also cut them off from the 
> server, which won't work.
> 
> I told him that once I got the firewall up, we'd be able to block his 
> classroom from the net during his class.
> 
> But the more I think about it, the less certain I am that I *can* do 
> that.  It's easy to block things coming in, but would it be possible 
> with IPCop to block a particular IP range from accessing the outside?  
> I'm sure there wouldn't be a way to do it from within the interface, but 
> possibly with a custom IPTables rule?  I could invoke it with a script 
> and cancel it with another, either linked to the interface or via SSH.  
> Or maybe using cron.
> 
> Trouble is, I don't understand IPTables well enough to know whether this 
> would be possible, much less how to craft such a rule.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel

I'm setting up an IPCop installation to isolate our department, to be 
implemented over Christmas break.  It will have perhaps 150 or so 
machines behind it, including a few servers and a bunch of workstations.

One of the other instructors came to me and asked if I could put a block 
on his classroom to prevent his students from surfing the net during 
class.  That classroom is on a single switch -- I could temporarily pull 
the plug during his class, but that would also cut them off from the 
server, which won't work.

I told him that once I got the firewall up, we'd be able to block his 
classroom from the net during his class.

But the more I think about it, the less certain I am that I *can* do 
that.  It's easy to block things coming in, but would it be possible 
with IPCop to block a particular IP range from accessing the outside?  
I'm sure there wouldn't be a way to do it from within the interface, but 
possibly with a custom IPTables rule?  I could invoke it with a script 
and cancel it with another, either linked to the interface or via SSH.  
Or maybe using cron.

Trouble is, I don't understand IPTables well enough to know whether this 
would be possible, much less how to craft such a rule.

thanks gilles,=20
if you remember i also was interested in this feature, i sent you my
modifications for 1.3.0 to get it working a while ago,=20
i will try asap too=20
thanks !
markus

On 27-Oct-2003 Ren=E9 Schuster wrote:
> Gilles Espinasse wrote in mailinglist.IPCop-Devel:
>=20
>> You can try http://perso.wanadoo.fr/gesp/ipcop-1.4.0a2.iso, fresh buil=
d
>> of this night with DHCP support over PPTP
>=20
> Thanks a lot, I will try as soon as possible and let you know.
>=20
> --=20
> So long,
>               -Ren=E9
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: The SF.net Donation Program.
> Do you like what SourceForge.net is doing for the Open
> Source Community?  Make a contribution, and help us add new
> features and functionality. Click here: http://sourceforge.net/donate/
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>=20

Hi,

> Oct 29 13:28:11 firewall pluto[14299]: ERROR: "KDI" #235: pclose failed for
> up-client command. Errno 10: No child processes

A quick google got me to this URL.  I have not yet fully read it, but it
seems to have something to do with the way we start FreeS/Wan:
http://lists.freeswan.org/pipermail/users/2003-February/018136.html

Kind regards,

Mark
-- 
***************************************************************
* |\    /|      |  /|  /       Mark Wormgoor                  *
* | \  / |      | / | /        mailto:ma...@wo...       *
* |  \/  |ark   |/  |/ormgoor  http://www.wormgoor.com/mark/  *
***************************************************************

In message <01f501c39e79$508aa200$0a0a10ac@darrenc>
          Darren Critchley <da...@kd...> wrote:

> I have tracked it down to the safe_system command not the actual ethernet
> address.

> The while loop that takes the aliases down, is checking for a 0 return from
> safe_system, but,  when ifconfig has an error, we are dumped out of the
> setaliases program, instead of exiting the while loop cleanly.

Are you sure this is the problem? ifdown eth0:0 does indeed result in
'SIOCSIFFLAGS: Cannot assign requested address' being written to stderr, but
in my tests safe_system correctly returns the resulting return code fine and
does not cause the program to exit. safe_system is pretty old and well tested
code (there used to be something very similar in one of the linux man pages).

Unfortuantely I don't have the ability to test setaliases itself, but I don't
think safe_system is to blame. Checking the source safe_system was also used
in setaliases in 1.3.0 so I don't see how it can suddenly be broken now when
it wasn't before.

-- 
 Robert Kerr

Myself and a friend have been working on a 1.3 version for some time. We
have stats, but because we used the data from the MRTG log used for the
traffic graph instead of the original method, the result turned out
innacurate. 

Hence I haven't sent it back to Joe Caturbican, or Mark WoormGoor. My friend
Drew has been too busy lately to have time to re-engineer the data backend
for the mod. 
RGDS Ray

-----Original Message-----
From: buliwyf [mailto:bu...@gm...]
Sent: Thursday, 30 October 2003 8:04 AM
To: ipc...@li...
Subject: [IPCop-devel] Traffic Addons


Hello

On the ipcop Homepage are links to some Addons.
One of these Addons is a net Traffic Addon which shows
the sum of traffic on the Interfaces for Day,week,Month
and so on.
Link http://www.zpdee.net/~joecat/ipcoptraffic.html
Unfortunately this doesn't work on Ipcop 1.3 any more, but
this kind of Information would be very useful.
Will there be something like that on 1.4.0 or 1.3.1

<snip>

cYa buliwyf

-- 
buliwyf         mailto:Bu...@gm...    ICQ: 18164192   Blue Skies
IRC-net:#spooky
Key ID:         0x44C9AF63
Fingerprint:    4B9E CB70 9792 6640 D7E2  EEA0 2FBA 09C6 44C9 AF63



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
IPCop-devel mailing list
IPC...@li...
https://lists.sourceforge.net/lists/listinfo/ipcop-devel

I have tracked it down to the safe_system command not the actual ethernet
address.

The while loop that takes the aliases down, is checking for a 0 return from
safe_system, but,  when ifconfig has an error, we are dumped out of the
setaliases program, instead of exiting the while loop cleanly.

I have tried this on two systems now with the same results.

Darren

Is anyone using aliases on their Ipcop v 1.4x?

I was just testing it out on mine, and it generates an error. I do have a
static address on red.

When I call the setaliases program from the command line, it generates the
following error:
SIOCSIFFLAGS: Cannot assign requested address

This is caused by trying to do the following:
/sbin/ifconfig eth1:0 down

Apparently it would appear that eth1:0 is an illegal address.

I checked the archives to see if it had been modified recently, but nothing
showed up.

Is there anyone else on the list to confirm this? I think the code needs a
bit of modification to exclude the 0 from the command.

Darren

Ok, here's the error message that I am getting from my Ipcop when it tries
to rekey the vpn

Oct 29 13:26:09 firewall pluto[14299]: "KDI" #232: initiating Quick Mode
PSK+ENCRYPT+TUNNEL+PFS to replace #231
Oct 29 13:26:09 firewall pluto[14299]: ERROR: "KDI" #232: pclose failed for
up-client command. Errno 10: No child processes

Hitting the refresh in the interfaces accomplishes this:
Oct 29 13:28:10 firewall pluto[14299]: forgetting secrets
Oct 29 13:28:10 firewall pluto[14299]: loading secrets from
"/etc/ipsec.secrets"
Oct 29 13:28:11 firewall pluto[14299]: "KDI": deleting connection
Oct 29 13:28:11 firewall pluto[14299]: "KDI" #233: deleting state
(STATE_QUICK_I1)
Oct 29 13:28:11 firewall pluto[14299]: "KDI" #219: deleting state
(STATE_MAIN_I4)
Oct 29 13:28:11 firewall pluto[14299]: | from whack: got --esp=3des
Oct 29 13:28:11 firewall pluto[14299]: | from whack: got --ike=3des
Oct 29 13:28:11 firewall pluto[14299]: added connection description "KDI"
Oct 29 13:28:11 firewall pluto[14299]: packet from XX.XX.XX.XX:500:
Informational Exchange is for an unknown (expired?) SA
Oct 29 13:28:11 firewall pluto[14299]: "KDI" #234: initiating Main Mode
Oct 29 13:28:11 firewall pluto[14299]: "KDI" #234: Main mode peer ID is
ID_IPV4_ADDR: 'XX.XX.XX.XX'
Oct 29 13:28:11 firewall pluto[14299]: "KDI" #234: ISAKMP SA established
Oct 29 13:28:11 firewall pluto[14299]: "KDI" #235: initiating Quick Mode
PSK+ENCRYPT+TUNNEL+PFS
Oct 29 13:28:11 firewall pluto[14299]: ERROR: "KDI" #235: pclose failed for
up-client command. Errno 10: No child processes

Doing a ping does not restart.

Executing an ipsecctrl S restarts the vpn and reconnects without problems.

Darren

Hello

On the ipcop Homepage are links to some Addons.
One of these Addons is a net Traffic Addon which shows
the sum of traffic on the Interfaces for Day,week,Month
and so on.
Link http://www.zpdee.net/~joecat/ipcoptraffic.html
Unfortunately this doesn't work on Ipcop 1.3 any more, but
this kind of Information would be very useful.

Extremely useful for people which only have a special
amount of Data Transfer per month from there Provider.

Perhaps an Option can be added to the Profiles (sum of
Traffic) and People see how much free Traffic they have
for this month and how much is already used.

Is an Addon available which works under 1.3?
If Yes, where can i get it?
Or can The Addon mentioned above be fixed so it works with 1.3?

Will there be something like that on 1.4.0 or 1.3.1


cYa buliwyf

-- 
buliwyf         mailto:Bu...@gm...    ICQ: 18164192   Blue Skies   IRC-net:#spooky
Key ID:         0x44C9AF63
Fingerprint:    4B9E CB70 9792 6640 D7E2  EEA0 2FBA 09C6 44C9 AF63

Morten Christensen wrote:
> Darren Critchley wrote:
>
>> I am still having trouble reconnecting my vpn. At the office is a
>> 1.3 box, at my home office is a 1.4 box.
>> When the vpn goes down for whatever reason, I hit the restart button
>> in the GUI, and nothing happens, but, if I drop down to the command
>> line, and issue an ipsecctrl D and then an ipsecctrl S then it will
>> reconnect and everything is fine.
>>
>> Is this just happening to me, is it a 1.3/1.4 compatibility issue,
>> is it a one off?
>>
>>
>
> We run 1.3.0 at office.
>
> I have tried 1.4.0a1 at home, but when I was at work the vpn was down
> all the time, and I could not get the tunnel open from the 1.3-end.
>
> My impression was, that it was easy to open the tunnel from the
> 1.4-side
> by pinging through it.
>
> Now I am back on 1.3.1a5 at home, and the vpn-tunnel is always on.

That is usually how I test the tunnel, try to ping a machine that is always
up on the 1.3 side. My pings fail and don't seem to initiate the vpn.
Problem is too, all the error messages that superfreeswan has are not
documented like they are for freeswan, in fact I can't find much in the way
of docs for superfreeswan (unless we are expected to track down the docs for
each patch that is in there)

Next time it happens I'l ltry and post my error message (I'm usually in a
rush and don't have time as I need access to the office lan to deal with
customers, fixing a bug in ipcop becomes secondary, but I will try to post
next time)

Darren

Darren Critchley wrote:

>I am still having trouble reconnecting my vpn. At the office is a 1.3 box,
>at my home office is a 1.4 box.
>When the vpn goes down for whatever reason, I hit the restart button in the
>GUI, and nothing happens, but, if I drop down to the command line, and issue
>an ipsecctrl D and then an ipsecctrl S then it will reconnect and everything
>is fine.
>
>Is this just happening to me, is it a 1.3/1.4 compatibility issue, is it a
>one off?
>  
>

We run 1.3.0 at office.

I have tried 1.4.0a1 at home, but when I was at work the vpn was down 
all the time, and I could not get the tunnel open from the 1.3-end.

My impression was, that it was easy to open the tunnel from the 1.4-side 
by pinging through it.

Now I am back on 1.3.1a5 at home, and the vpn-tunnel is always on.


--
mvh
Morten Christensen

I am still having trouble reconnecting my vpn. At the office is a 1.3 box,
at my home office is a 1.4 box.
When the vpn goes down for whatever reason, I hit the restart button in the
GUI, and nothing happens, but, if I drop down to the command line, and issue
an ipsecctrl D and then an ipsecctrl S then it will reconnect and everything
is fine.

Is this just happening to me, is it a 1.3/1.4 compatibility issue, is it a
one off?

Just wondering.

Darren

----- Original Message ----- 
From: "Roger Murer" <r....@ti...>
To: "Gilles Espinasse" <gil...@wa...>
Cc: "IPCOP devel" <ipc...@li...>
Sent: Tuesday, October 28, 2003 5:31 PM
Subject: Re: [IPCop-devel] broken rc.firewall and rc.updatered


> Gilles Espinasse wrote:
> > I know yet I broke rc.firewall and rc.updatered with one change
> > 
> > It should have been
> > line 29 of rc.updatered and line 93 of rc.firewall
> >  if [ [ "$TYPE" = "PPTP" -o "$PROTOCOL" = "RFC1483" ] -a "$METHOD" =
> > "DHCP" ]; then
> > 
> Hello all
> 
> In todays snpashot 20031028 there seems still to be a problem with 
> rc.firewall.
> A ./rc.firewall gives: ./rc.firewall: [: too many arguments
> I could pinpoint it to line 93, but don't know how to fix it.
> 
> Kind regards,
> Roger

Thank
 
Alan already apply a fix for rc.updatered

I do the same for rc.firewall

Driver Version : 3.2.11
Release Date : 21-Oct-2003

Changes in this version...

- TxDma restart bug fixed (Alcatel DSLAMs)
- GtiTrellis default now on

New drivers can be compiled using the Engine at http://adsl4linux.no-ip.org

A precompiled driver for IPCop1.3 can be downloaded at 
http://adsl4linux.no-ip.org/download.html

Driver Version : 3.2.11
Release Date : 21-Oct-2003

Changes in this version...

- TxDma restart bug fixed (Alcatel DSLAMs)
- GtiTrellis default now on

New drivers can be compiled using the Engine at http://adsl4linux.no-ip.org

A precompiled driver for IPCop1.3 can be downloaded at 
http://adsl4linux.no-ip.org/download.html

In message <200...@c2...>
          Arnt Karlsen <ar...@c2...> wrote:

> On Sun, 26 Oct 2003 14:56:35 GMT,
> Robert Kerr <Lit...@xs...> wrote in message
> <e92...@bl...>:

> > In message <200...@c2...>
> >           Arnt Karlsen <ar...@c2...> wrote:

> > > ..now we run _all_ file systems write-able, which leaves
> > > un-neccessary potential exploitable vulnerabilities, open.

> > I think saying it leaves vulnerabilities open is probably
> > misrepresenting the problem. The filesystem permissions normally
> > restrict people writing places they shouldn't, unless the permissions
> > are setup wrong you have to be root already before the mount options
> > matter. If you're root then you're not really going to have much
> > difficulty remounting the filesystems. Leaving the filesystems
> > writable doesn't open up anything... it just makes things slightly
> > easier than they could otherwise be.

> ..you left out "potential".  Once Microsoft is gone, the crackers
> gonna come after us, and we do have holes, weeding out not
> needed binaries and writeable assets such as disks etc, will
> help make ipcop more secure, or less unsecure, by making
> it easier to manage and debug.  The easiest thing to do, is weed
> out stuff we don't need; _no_ firewall needs adduser, badblocks, cal,
> dd, e2label, fdisk, groupmod etc etc, to firewall.

Some of these could probably be removed in 1.4 actually... though 1.5 will
give us a lot more flexibility to pick and chose the programs and options
that are available. It's also worth looking at the permissions of these,
because the default redhat permissions tend to give all users r-x on
binaries, which is generally unnecessary. Ideally it'd be nice to have a list
of every program present and why it's included. There are some things like
squid, snort and apache that technically have no reason to exist on a
firewall, but we still have for usability and maintainability reasons.

> ..these "not needed in firewall service but for maintenance only",
> can be ripped out on root's logout, and can be scp'd back in next
> time they're needed.  Or, they can be put in /usr/local and mounted
> as needed.  /usr/local can be a loopmounted file, nfs-mount, and
> it can be encrypted etc.

An encrypted fs wouldn't be a bad idea... but an nfs mount is, I have less
trust in the nfs utilities than any of the other things you've said don't
belong on a firewall. There's also the risk that someone could intercept and
modify the nfs traffic between ipcop ad the nfs server, trojaning the
binaries as you run them.

> ..this root logout binary massacre can be made dependant on the
> configuration, I have 3 nics in my ipcop, red goes thru an wifi AP, so I
> do not need isdn, asdl, ibod, ipppd etc on my box, nor do I need nic
> modules other than ne.o and tulip.o for my ISA ne coax card and the 2
> tulips.

> ..similarly, a dialup'er with one 3com905 will not need my tulip or ne
> modules, but his own 3c59x.o and the modem stuff.  A hole in "my"
> tulip.o could be used to pry open his box.  If present.  ;-)

I'm not so sure about this.. the only NIC drivers loaded are going to be the
ones you're using. The only way I can see the unloaded kernel modules being a
problem is if they could be loaded by an attacker, and if they can do that
they can likely insert whatever malicious code they desire - game over.
People often start with a green/red setup then add orange at a later date, at
which point they may find they do need those extra NIC drivers they didn't at
the start.

There's no harm in removing extra modules if you're sure you don't need them,
but making this a default action sacrifices flexibility for little gain. If
you're going to sacrifice that flexibility then a much better thing to do is
compile all the drivers you need into a static kernel with no module support.
Removing module support altogether makes it much more difficult for an
attacker to insert a kernel level rootkit. This is something that can only be
done on a per machine basis though.

Removing unused adsl, isdn, etc probably has more merit as any user can run
these where inserting modules is a root only task. Again though, unless
they're up and running by default or are installed setuid root the risk is
probably minimal.

> > It's certainly worth considering the mount options carefully and we
> > desperately need a more flexible partitioning system in the installer.

> ..true.  My suggested defaults, and with sfdisk to overrule it?
> "Experts only, No Mercy!!!" etc.  'mount' and most other binaries
> can be compiled with the wee subset of compile time options we
> need for ipcop.  If we never use fat32 diskettes, we do not need
> fat32 support in ipcop's 'mount', etc.  Bonus is the binaries get
> smaller and safer.

Seeing as 1.5's new installer is likely to be based on the old redhat one
we'll probably end up with disk druid for partitioning. I expect it will be
an advanced option with some sensible defaults. Quite what the default
partitioning scheme will be is going to take a while to work out I think.

> > IPCop style defaults for shorewall would be pretty easy... and I don't
> > think adapting the GUI to write shorewall config files would be too
> > hard either. Making setup and all the init scripts cope with a bunch
> > of extra interfaces would probably be more taxing.

> ..not needed, if we do it the shorewall way.  I used it and webmin
> on a makeshift AP I made out of a thinkpad with RH-7.3.  Webmin
> also has its own webserver, so we could drop Apache too.

Unless shorewall changed recently we still need to have code to bring up the
interfaces. This will get pretty hairy once you start allowing multiple reds,
etc.

I think I trust apache more as a webserver than webmin, but the default
redhat apache is certainly overkill for what we're doing, at the very least
it could do with some unneeded modules being cut. Replacing it with something
slimline like fnord or mini_httpd may be better in the long run.

> > I'm not entirely sure that moving to shorewall will be worthwhile once
> > the firewall rule editor for 1.4 is finished though.

> ..this rule editor is patterned after the webmin "Firewall" module?
> I'm not too impressed by it.

Pass... I've never used webmin, and the rule editor isn't complete.

-- 
 Robert Kerr

Roger Murer wrote:
> Gilles Espinasse wrote:
> 
>> I know yet I broke rc.firewall and rc.updatered with one change
>>
>> It should have been
>> line 29 of rc.updatered and line 93 of rc.firewall
>>  if [ [ "$TYPE" = "PPTP" -o "$PROTOCOL" = "RFC1483" ] -a "$METHOD" =
>> "DHCP" ]; then
>>
> Hello all
> 
> In todays snpashot 20031028 there seems still to be a problem with 
> rc.firewall.
> A ./rc.firewall gives: ./rc.firewall: [: too many arguments
> I could pinpoint it to line 93, but don't know how to fix it.
> 

Hello again

I fixed it like this:
if  [ "$METHOD" = "DHCP" ] ; then
   if  [ "$RED_TYPE" = "PPTP" -o "$PROTOCOL" = "RFC1483" ] ; then
...
...

The line:
if [ [ "$RED_TYPE" = "PPTP" -o "$PROTOCOL" = "RFC1483" ] -a "$METHOD" = 
"DHCP" ]; then

seems not to work.

Roger

-- 
Roger Murer
E-Mail: r....@ti...

Gilles Espinasse wrote:
> I know yet I broke rc.firewall and rc.updatered with one change
> 
> It should have been
> line 29 of rc.updatered and line 93 of rc.firewall
>  if [ [ "$TYPE" = "PPTP" -o "$PROTOCOL" = "RFC1483" ] -a "$METHOD" =
> "DHCP" ]; then
> 
Hello all

In todays snpashot 20031028 there seems still to be a problem with 
rc.firewall.
A ./rc.firewall gives: ./rc.firewall: [: too many arguments
I could pinpoint it to line 93, but don't know how to fix it.

Kind regards,
Roger

-- 
Roger Murer
E-Mail: r....@ti...

In message <065601c39ce3$12c4c320$01b5a8c0@PII350>
          "Gilles Espinasse" <gil...@wa...> wrote:

> My problem related to connecting to my network this morning was in fact a
> problem with dhcp server not running.
> If nothing is set into BLUE_DEV restartdhcp fail with Bad BLUE_DEV:
> I set BLUE_DEV=eth2 and this allow dhcp to start.
> Should we not test if enable_blue is set before to verify that BLUE_DEV is
> a valid device?

Oops, my bad. The checks used by VALID_DEVICE are more strict that the code
they replace. Before an empty string would have been considered a totally
valid device - which is fine if you have no blue but would cause all sorts of
trouble if blue was set to enabled but the device was somehow unassigned.

I've fixed this in CVS, however... I wonder what would happen if you get in a
state where blue was once present but has been removed and there are still
enable_blue files hanging around. The setup program tends to be very bad at
catching all related files if you change something. It's also not so great at
sanity checking user input which probably leaves it prone to break things in
amusing ways.

-- 
 Robert Kerr

----- Original Message -----
From: "Mark Wormgoor" <ma...@wo...>
To: "IPCOP devel" <ipc...@li...>
Sent: Monday, October 27, 2003 9:00 AM
Subject: Re: [IPCop-devel] Pending problems on V1.4.0a2


*snip
> > If PPPoE connection work well, but reconnection is still problematic.
> > when doing rc.red start, the first attempt is successfull maybe 9 time
in 10
> > trial.
>
> I really don't know what's causing this.  It seems like there's no packets
> coming in.
>
Curiously, if instead of killall -KILL usr/sbin/pppoe, I do killall -1
/usr/sbin/pppoe, reconnection is immediate at the first attempt and with
absolutly no delay.



My problem related to connecting to my network this morning was in fact a
problem with dhcp server not running.
If nothing is set into BLUE_DEV restartdhcp fail with Bad BLUE_DEV:
I set BLUE_DEV=eth2 and this allow dhcp to start.
Should we not test if enable_blue is set before to verify that BLUE_DEV is a
valid device?

Hi again,

 >I just built ipcop-1.4 from the latest cvs (today). System is RH 
Enterprise Linux ES 2.1 (based on RH 7.2). No errors but >the created 
floppy bootimage is not bootable. mkisofs is version 1.10.

I just downloaded the fresh iso from Rene Schuster. Thx a lot to Rene..
That floppyimage works. Seems to be a RH Enterprise problem. :(

Thx a lot for your patience

Dave

Gilles Espinasse wrote in mailinglist.IPCop-Devel:

> You can try http://perso.wanadoo.fr/gesp/ipcop-1.4.0a2.iso, fresh build
> of this night with DHCP support over PPTP

Thanks a lot, I will try as soon as possible and let you know.

--=20
So long,
		-Ren=E9=