ipcop-devel Mailing List for IPCop Firewall

Feature Requests item #1625488, was opened at 2007-01-01 09:45
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=1625488&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 major version
Status: Open
Priority: 5
Private: No
Submitted By: Ben (benny_boi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add IBM ServerRaid support

Initial Comment:
Despite following custom build instructions and enabling the appropriate drivers for IBM ServerRaid, the installation code doesn't pick up RAID arrays (does it look for /dev/sdXX ?). Is there any way this can be enabled?

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

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

----- Original Message ----- 
From: gnukid
To: ipc...@li...
Sent: Sunday, December 31, 2006 4:27 PM
Subject: [IPCop-devel] Optimization flags cause build problems

> Hello, This is a follow-up from my past thread (problem compiling
ipcop-1.4.11). I originally
>  thought that the problem was reiserfs. I had formatted the build
partition using reiserfs. I later
> created another partition, with ext2.
>
> The build went smoothly. the i386 image was generated flawlessly.
>
> Then, I changed the make.sh script flags :
> CFLAGS="-02 -march=pentium2 -mcpu=pentium2"
> CXXFLAGS="-O2 -march=pentium2 -mcpu=pentium2"
>
There, it's your game
When this had failed on reiserfs, what it with those changes or standard
code?

Gilles

Hello, This is a follow-up from my past thread (problem compiling
ipcop-1.4.11). I originally thought that the problem was reiserfs. I had
formatted the build partition using reiserfs. I later created another
partition, with ext2.

The build went smoothly. the i386 image was generated flawlessly.

Then, I changed the make.sh script flags :
CFLAGS="-02 -march=pentium2 -mcpu=pentium2"
CXXFLAGS="-O2 -march=pentium2 -mcpu=pentium2"

I made similar amendments to the config/kernel/ files.
replacing them with M686=y.

The build failed exactly with the same errors as on the reiserfs partition.
It failed to generate the installer (scsi.img, initrd)


-- 
`` GNU is the system ; Ututo is the distro ; Linux is one of its kernel.''
gnukid

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpIaSBhbGws
DQoNCkkgaGF2ZSBmb3IgYSBsb25nIHRpbWUgaGFkIG11Y2ggdG8gZG8gd2l0aCBteSBwYXllZCB3
b3JrIHdoaWNoIGhhdmUNCmxlZnQgbGl0dGxlIHRpbWUgZG9pbmcgc29tZXRoaW5nIGVsc2UuIEkg
aGF2ZSBob3dldmVyIGhhZCBzb21lIHNwYXJlDQp0aW1lIGluIHRoZSBDaHJpc3RtYXMgaG9saWRh
eXMgd2hpY2ggaGF2ZSBnaXZlbiBtZSB0aW1lIHRvIG1vcmUgb3IgbGVzcw0KY29tcGxldGUgdGhl
IGJhY2stZW5kIGZyYW1ld29yayBmb3IgdGhlIG5ldyBtb2R1bGFyIFVJLiBBdCBwcmVzZW50IGl0
IGlzDQphYmxlIHRvLCBkeW5hbWljYWxseSwgYXQgcnVudGltZSB0byBsb2FkIGFueSBwYWNrYWdl
IC0gZXh0ZW50aW9uIC0gYW5kDQppbmNvcnBvcmF0ZSBhbnkgbW9kdWxlLCBjbGFzcyBvciBmdW5j
dGlvbiBpbiB0aGUgcnVudGltZS4gT25seSB0aGluZw0KbWlzc2luZyBpcyB0byBhdXRvbWF0aWNh
bGx5IHVwZGF0ZSB0aGUgR1VJIGFjY29yZGluZ2x5Lg0KDQpJdCBpcyBteSBob3BlIHRoYXQgSSBp
biB0aGUgdmVyeSBuZWFyIGZ1dHVyZSB3aWxsIGhhdmUgYSBkZW1vIHNpdGUNCm9ubGluZSBmb3Ig
dGVzdGluZy4NCg0KVGhlIGJlbmVmaXRzIHRvIHRoaXMgZGVzaWduIGFyZSBhbiBvcGVuIEFQSSBm
b3IgMy1wYXJ0eSBleHRlbnNpb25zIGFuZA0KYSB3YXkgdG8gdGFpbG9yIHNwZWNpYWxpemVkIEdV
SSdzDQoNClRoZSBjb25zIGFyZSB0aGF0IHRoZSBlbnRpcmUgR1VJIG5lZWRzIHRvIGJlIHJld3Jp
dHRlbiBpbiBQeXRob24gdG8gYmUNCmFibGUgdG8gdXRpbGl6ZSB0aGUgZnJhbWV3b3JrLCBjdXJy
ZW50IEdVSSBpcyBhYmxlIHRvIHdvcmsgc3RpbGwgc28gdGhlDQp0cmFuc2l0aW9uIGNhbiBiZSBt
YWRlIGdyYWR1YWxseS4NCg0KSGFwcHkgbmV3IHllYXIgdG8gYWxsOi0pDQoNCi0gLS0gDQpIaWxz
ZW4vUmVnYXJkcw0KTWljaGFlbCBSYXNtdXNzZW4NCg0KR2V0IG15IHB1YmxpYyBHbnVQRyBrZXlz
Og0KbWljaGFlbCA8YXQ+IHJhc211c3NlbiA8ZG90PiBjYw0KaHR0cDovL2tleXNlcnZlci52ZXJp
ZGlzLmNvbToxMTM3MS9wa3MvbG9va3VwP29wPWdldCZzZWFyY2g9MHhEM0M5QTAwRQ0KbWlyIDxh
dD4gZGF0YW5vbSA8ZG90PiBuZXQNCmh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRpcy5jb206MTEzNzEv
cGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4RTUwMUY1MUMNCm1pciA8YXQ+IG1pcmFzIDxkb3Q+
IG9yZw0KaHR0cDovL2tleXNlcnZlci52ZXJpZGlzLmNvbToxMTM3MS9wa3MvbG9va3VwP29wPWdl
dCZzZWFyY2g9MHhFM0U4MDkxNw0KLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRmV3IHRoaW5ncyBhcmUgaGFyZGVyIHRvIHB1
dCB1cCB3aXRoIHRoYW4gdGhlIGFubm95YW5jZSBvZiBhIGdvb2QNCmV4YW1wbGUuIC0tICJNYXJr
IFR3YWluLCBQdWRkJ25oZWFkIFdpbHNvbidzIENhbGVuZGFyIg0KLS0tLS1CRUdJTiBQR1AgU0lH
TkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuNiAoR05VL0xpbnV4KQ0KDQppRDhEQlFG
Rmw2KzFWRXJZVmVQb0NSY1JBaFp3QUo5OW8xSDRzdTJhM2FJQmlEQnh1c2RlbjdSNnB3Q2VQUE4z
DQpwcHFSTHlSMU5RTnZ0cDJ1UnJITS9MWT0NCj1IZ2g1DQotLS0tLUVORCBQR1AgU0lHTkFUVVJF
LS0tLS0NCg==

On 12/30/06, gnukid <gn...@gm...> wrote:
> I would like to know when  will ipcop-1.4.12 be released.

Should be out within a week or so. A test version will be available in
a day or two.

> Is the build stable ?

Yes. There are a number of new drivers, and new kernel that need to be
tested/bedded in.

Eric

> > root@ipcop:/etc/rc.d # A: HTTP::Response=HASH(0x827e1c0)
> >
> > Firstly, can anyone confirm this behaviour, so we can eliminate

> Is this with 1.4.12?

Yes, a heavily battered test version. The problem could be local to my
development box.

I recently started to get warnings that the availaable patches list
was over seven days old. /var/ipcop/patches/available should be
updated every time IPCop connects, but my updatelists.pl script fails,
except when run from the webGUI or the command line.

> > operator error. Secondly, what do the HTTP Response HASH codes
> > represent?
> The HASH code simply means that Response is a reference to a Hash at
> instance 0x827e1c0.
> A Hash can be decoded this way:
> while ( my ($key, $value) = each(%hash) ) {
>     print "$key => $value\n";
> }
>
> If Response is a hash reference:
> while ( my ($key, $value) = each(%$hash_ref) ) {
>     print "$key => $value\n";
> }
>
> My guess would be that the script expects either a scalar or a hash but
> receives a hashref
>
> - --
> Hilsen/Regards
> Michael Rasmussen

One of the hash codes represents a 'successful' HTTP Response, which
allows the script to complete, and the other, I presume, does not.

Eric

LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBTdW4s
IDMxIERlYyAyMDA2IDExOjE3OjAxICswMDAwDQoiRXJpYyBPYmVybGFuZGVyIiA8ZXJpYy5vYmVy
bGFuZGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IHJvb3RAaXBjb3A6L2V0Yy9yYy5kICMgQTogSFRU
UDo6UmVzcG9uc2U9SEFTSCgweDgyN2UxYzApDQo+IA0KPiBGaXJzdGx5LCBjYW4gYW55b25lIGNv
bmZpcm0gdGhpcyBiZWhhdmlvdXIsIHNvIHdlIGNhbiBlbGltaW5hdGUNCklzIHRoaXMgd2l0aCAx
LjQuMTI/DQo+IG9wZXJhdG9yIGVycm9yLiBTZWNvbmRseSwgd2hhdCBkbyB0aGUgSFRUUCBSZXNw
b25zZSBIQVNIIGNvZGVzDQo+IHJlcHJlc2VudD8NClRoZSBIQVNIIGNvZGUgc2ltcGx5IG1lYW5z
IHRoYXQgUmVzcG9uc2UgaXMgYSByZWZlcmVuY2UgdG8gYSBIYXNoIGF0DQppbnN0YW5jZSAweDgy
N2UxYzAuDQpBIEhhc2ggY2FuIGJlIGRlY29kZWQgdGhpcyB3YXk6DQp3aGlsZSAoIG15ICgka2V5
LCAkdmFsdWUpID0gZWFjaCglaGFzaCkgKSB7DQogICAgcHJpbnQgIiRrZXkgPT4gJHZhbHVlXG4i
Ow0KfQ0KDQpJZiBSZXNwb25zZSBpcyBhIGhhc2ggcmVmZXJlbmNlOg0Kd2hpbGUgKCBteSAoJGtl
eSwgJHZhbHVlKSA9IGVhY2goJSRoYXNoX3JlZikgKSB7DQogICAgcHJpbnQgIiRrZXkgPT4gJHZh
bHVlXG4iOw0KfQ0KDQpNeSBndWVzcyB3b3VsZCBiZSB0aGF0IHRoZSBzY3JpcHQgZXhwZWN0cyBl
aXRoZXIgYSBzY2FsYXIgb3IgYSBoYXNoIGJ1dA0KcmVjZWl2ZXMgYSBoYXNocmVmDQoNCi0gLS0g
DQpIaWxzZW4vUmVnYXJkcw0KTWljaGFlbCBSYXNtdXNzZW4NCg0KR2V0IG15IHB1YmxpYyBHbnVQ
RyBrZXlzOg0KbWljaGFlbCA8YXQ+IHJhc211c3NlbiA8ZG90PiBjYw0KaHR0cDovL2tleXNlcnZl
ci52ZXJpZGlzLmNvbToxMTM3MS9wa3MvbG9va3VwP29wPWdldCZzZWFyY2g9MHhEM0M5QTAwRQ0K
bWlyIDxhdD4gZGF0YW5vbSA8ZG90PiBuZXQNCmh0dHA6Ly9rZXlzZXJ2ZXIudmVyaWRpcy5jb206
MTEzNzEvcGtzL2xvb2t1cD9vcD1nZXQmc2VhcmNoPTB4RTUwMUY1MUMNCm1pciA8YXQ+IG1pcmFz
IDxkb3Q+IG9yZw0KaHR0cDovL2tleXNlcnZlci52ZXJpZGlzLmNvbToxMTM3MS9wa3MvbG9va3Vw
P29wPWdldCZzZWFyY2g9MHhFM0U4MDkxNw0KLSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGVzdCBpbnB1dCBmb3IgdmFsaWRp
dHkgYW5kIHBsYXVzaWJpbGl0eS4NCiAgICAgICAgICAgIC0gVGhlIEVsZW1lbnRzIG9mIFByb2dy
YW1taW5nIFN0eWxlIChLZXJuaWdoYW4gJiBQbGF1Z2hlcikNCi0tLS0tQkVHSU4gUEdQIFNJR05B
VFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS40LjYgKEdOVS9MaW51eCkNCg0KaUQ4REJRRkZs
NTdHVkVyWVZlUG9DUmNSQW8vcUFLQ2dzVGZEWi85bnozKzIxTFlKTHdnQlU3OWtmUUNmUTNGVQ0K
S2NjSys5L3dSUTdIR1dlRE9ETUxrMXM9DQo9WC9sUQ0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0t
LS0tDQo=

I've noticed strange behaviour of the updatelists.pl script when it's
run from a command line, versus when it is run from within the
/etc/rc.d/rc.updatered script.

root@ipcop:/etc/rc.d # updatelists.pl
A: HTTP::Response=HASH(0x827fe30)

or...

root@ipcop:/etc/rc.d # ./rc.updatered
rc.updatered: ./rc.updatered locking for 27297
2006/12/29 18:30:12| Creating Swap Directories
rc.updatered: unlocking from 27297
root@ipcop:/etc/rc.d # A: HTTP::Response=HASH(0x827e1c0)
Could not download patches list. HTTP::Response=HASH(0x827e1c0) at
/usr/local/bin/updatelists.pl line 20.

I put some print statements into updatelists.pl to see what the value
of $return was, and is different depending on whether it is called by
rc.updatered or run directly.

Firstly, can anyone confirm this behaviour, so we can eliminate operator error.
Secondly, what do the HTTP Response HASH codes represent?

Thanks

Eric

gnukid wrote:

> I would like to know when  will ipcop-1.4.12 be released.

The release will be shortly after it's finished ;-)

> Is the build stable ?

Fairly stable

> Which cvs snapshot must we download to compile it ?

IPCOP_v1_4_0


cheers Olaf

-- 

A weizen a day helps keep the doctor away.

I would like to know when  will ipcop-1.4.12 be released.

Is the build stable ?

Which cvs snapshot must we download to compile it ?

-- 
`` GNU is the system ; Ututo is the distro ; Linux is one of its kernel.''
gnukid

Gilles Espinasse wrote:
> I had to set restrictions on ipcop-cvs list to fight spam.
> Only members of the list could post and messages from all members will be
> moderated with one exception.
> 
> Messages on ipcop-cvs from Alan, Achim, Yvan, Eric O, Franck, Harry, Robert,
> Olaf and me will be accepted without moderation need or list membership when
> they arrive from their sourceforge mail address.
> 
> Direct reply to a message received from ipcp-cvs list could not work as the
> sender address would not look to come from sourceforge. You could redirect
> the reply on ipcop-devel as it look more appropriate to discuss about a
> change.
> 
> If you are a registred developper on ipcop project and intend to commit
> again, send me a mail so your commit message could  be accepted.
> 
> Send me a message if I fail to set that properly or miss someone that is
> active actually.
> 
> Filter was wrongly set with my first commit message on pppsetup.cgi on v1.4
> but after fixing the problem, same message for same commit on v1.5 reach the
> list.
> 
> Gilles


Gilles,

thanks for taking care of this!

IvanK.

Feature Requests item #1624352, was opened at 2006-12-29 14:31
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=1624352&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: c!ph3r (c_7)
Assigned to: Nobody/Anonymous (nobody)
Summary: [web interface] style definitions

Initial Comment:
I have some Problems to customize the web-interface. It's easy to modify the images and the stylesheet, but some style properties (mostly colors and background images) are defined in html.
For example it's not possible to change the color of the box content area without modifying the cgi scipts.

It would be a great feature to have something like a style chooser, which make it possible to select a style identified by a folder (name) which contains images and the stylesheet.

If all css properties are assigned with classes in a stylesheet, the dynamic part concerning appearance would be the <style> section, because an image's path is handled relative to the .css file.

I'm sorry for my terrible english :-)

Greetings from Switzerland

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

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

Selon gnukid <gn...@gm...>:

> When I try to compile ipcop-1.4.11, The build fails at the installer st=
age.
> initrd fails to create the cdinitrc.gz file. TThe error is Unexpected E=
OF in
> archieve. The error comes from gzip.
>
I don't know what it could be the cause.
If you run ./make.sh prefetch, if there is no md5 error in any files, all=
 files
should be ok to gunzip.

Could you send the exact error message and a few lines before?

Gilles

When I try to compile ipcop-1.4.11, The build fails at the installer stage.
initrd fails to create the cdinitrc.gz file. TThe error is Unexpected EOF in
archieve. The error comes from gzip.

-- 
`` GNU is the system ; Ututo is the distro ; Linux is one of its kernel.''
gnukid

I had to set restrictions on ipcop-cvs list to fight spam.
Only members of the list could post and messages from all members will be
moderated with one exception.

Messages on ipcop-cvs from Alan, Achim, Yvan, Eric O, Franck, Harry, Robert,
Olaf and me will be accepted without moderation need or list membership when
they arrive from their sourceforge mail address.

Direct reply to a message received from ipcp-cvs list could not work as the
sender address would not look to come from sourceforge. You could redirect
the reply on ipcop-devel as it look more appropriate to discuss about a
change.

If you are a registred developper on ipcop project and intend to commit
again, send me a mail so your commit message could  be accepted.

Send me a message if I fail to set that properly or miss someone that is
active actually.

Filter was wrongly set with my first commit message on pppsetup.cgi on v1.4
but after fixing the problem, same message for same commit on v1.5 reach the
list.

Gilles

May you all have a happy new year and thank you all from a grateful IPCOP user
-- 
TTFN
   Caparo

----- Original Message ----- 
From: "Olaf Westrik" <wei...@ip...>
To: "IPCop devel" <ipc...@li...>
Sent: Saturday, December 23, 2006 4:10 PM
Subject: [IPCop-devel] make.sh prefetch


> Hi Team,
>
>
> if I looked correctly there is a call to stdumount missing at the end of
> the loadsrc() sequence
> This basically leaves all the mounts in place after a ./make.sh prefetch
>
> Or is there some side effect I've missed when stdumount is added ?
> (tinkering with make.sh is not my favourite pastime)
>
>
> cheers Olaf
>
You are right.
I had seen some problems before to commit 1.129.2.169 and it's half repared.

If I remember well, I stop because othersrc does not work well too (and I
still need to fix that).
It should load files to /tmp and copy only if md5 is right (and the othersrc
package is not yet uploaded on sourceforge, so it's not easy to test).

I will fix the missing umount, I have other changes on make.sh to apply.

Gilles
Gilles

Hi Team,


if I looked correctly there is a call to stdumount missing at the end of 
the loadsrc() sequence
This basically leaves all the mounts in place after a ./make.sh prefetch

Or is there some side effect I've missed when stdumount is added ?
(tinkering with make.sh is not my favourite pastime)


cheers Olaf

-- 

A weizen a day helps keep the doctor away.

----- Original Message ----- 
From: "Gilles Espinasse" <g....@fr...>
To: "IPCOP devel" <ipc...@li...>
Sent: Thursday, December 21, 2006 3:15 PM
Subject: Re: Planning for 1.4.12 release


>
> ----- Original Message ----- 
> From: "Gilles Espinasse" <g....@fr...>
> To: "IPCOP devel" <ipc...@li...>
> Sent: Tuesday, December 19, 2006 4:05 PM
> Subject: Planning for 1.4.12 release
>
>
> I am late because of some investigations with smp/UP compilation and some
> troubles to solve.
>
I am now splitting the update in two parts because of update size limits on
small configuration.

I think I have still a full day to job to end that change and finish the
kernel update script.

Because of this delay, v1.4.12/1.4.13 update will not be ready for testing
before 25 december.
We will wait a few days for early testers before the release.
The appropriate date should be first january 2006.

Gilles

----- Original Message ----- 
From: "Gilles Espinasse" <g....@fr...>
To: "IPCOP devel" <ipc...@li...>
Sent: Tuesday, December 19, 2006 4:05 PM
Subject: Planning for 1.4.12 release


> I would freeze v1.4.12 tomorrow 18h and release on the next morning until
> sunday for testing.

I am late because of some investigations with smp/UP compilation and some
troubles to solve.

> - tg3-3.66d  replacing kernel include driver
done
> - velocityget-1.22 (VIA gigabit new driver)
done
> - openssh-4.5p1    (I have to do that in my basket)
> - wanpipe-2.3.4.2 (I have to finalize that)
half-done
This take me time as some bugs have been introduced in wanpipe-2.3.4 between
beta10 to 2.3.4-3
Compilation is now fixed.

I have some minor changes in new installation messages and still openssh to
work at.
You could still commit (fixes only) until midnight as I will be forced to
recompile again.

Gilles

> Some parts would welcome testing feedback (mainly e1000, tg3 drivers, o=
ur
> wanpipe implementation).

I'm replacing hardware right now, so could fit in testing for Wanpipe &
tg3 drivers this week. I'm abroad for three weeks after Thursday though.

Any problems with the wanpipe build? My build has been fine with 2.3.4
beta12 but haven't tried the release 2.3.4 yet.

Andre

I would freeze v1.4.12 tomorrow 18h and release on the next morning until
sunday for testing.

This version will mainly include :
-kernel 2.4.33.5+WE18+wireless_tools.28
-gzip-1.3.5 patched
- apache-1.3.37
- basp-0.9.3
- dhcp-3.0.5,
- e1000-7.3.15 replacing kernel include driver
- fcron-3.0.1
- gnupg-1.4.6
- openssl-0.9.7l
- pulsar-4.0.22
- rp-pppoe-3.8
- tg3-3.66d  replacing kernel include driver
- velocityget-1.22 (VIA gigabit new driver)
- openssh-4.5p1    (I have to do that in my basket)
- wanpipe-2.3.4.2 (I have to finalize that)

Some parts would welcome testing feedback (mainly e1000, tg3 drivers, our
wanpipe implementation).


A version 1.4.12 for alpha will be released mostly two days after.
There will not be an update for alpha in 1.4.12 from previous releases but
for next releases, it should be available.

Gilles

Le mardi 19 d=E9cembre 2006 12:32, Gilles Espinasse a =E9crit=A0:
> As I would find more free place on driver.img (to add some more nic
> drivers), I want to exclude wireless drivers from floppy driver.img=
.
>
> I don't think install only with a blue interface and no green is
> operational.
> - install from network only set the green interface,
> - actual setup interface does not allow to change green driver.
>
> Does somebody think it could cause a problem?
>
> Nothing would be changed once IPCop is installed.
>
> Gilles
>
Hello Gilles,
Unless setup is asking (which is not the case) for wifi
information (ssid, channel, key...) there is not real
support for wireless (wifi)...
=3D>drivers are optionnal.

Franck

As I would find more free place on driver.img (to add some more nic
drivers), I want to exclude wireless drivers from floppy driver.img.

I don't think install only with a blue interface and no green is
operational.
- install from network only set the green interface,
- actual setup interface does not allow to change green driver.

Does somebody think it could cause a problem?

Nothing would be changed once IPCop is installed.

Gilles

Hi all,

i'm trying to upgrade openswan on ipcop but i've got a question about nat traversal patch. In lfs/openswan, patch is not applied but in configuration file when i create a vpn, i can see "nat_traversal=yes". Hos is it possible to enable nat traversal if patch is not applied at compilation time?

Thanks a lot for your help.

ludovic.